Introducing Cobra

[David Brown]

On Wed, Jan 02, 2008 at 10:39:26AM -0800, Chuck Esterbrook wrote:

>The indent for Cobra is exactly two: [Enter] [Tab]

With proper indentation support in the editor, the programmer should
_never_ have to explicitly indent the code.  I think that is largely why
the colon is present in python, to make this somewhat possible.

It can still be done, but the editor has to be taught a whole lot more
about the grammar of the language.

Honestly, lack of proper indentation support would be enough to keep me
from using a language.

>The colon is allowed because I don't want Python people to get
>frustrated when starting out with Cobra. *But* It generates a warning
>because Cobra has a theme of "syntax normalization" which I need to
>write about. Essentially, most Cobra programs look mostly the same so
>that code you see in a blog, email, wiki or in a project you just
>inherited differs more by semantics than syntax. Examples rules
>include:
>* Classes must be capped
>* Arguments and locals must start lower
>* Blocks must be indented

I would argue that the colon _is_ the normalized syntax, and that you have
to know more about the language to parse it without the colon present.

I would encourage you to pick a grammar and just use it.

You're defining the language, so you get to decide how much is style vs how
much is enforced.

>I got the idea straight out of English where everything I read has
>about the same syntax and consequently I dive immediately into
>semantics regardless of what I'm reading.

English grammar is a terrible place to look for inspiration for a
programming language.  In fact, _all_ spoken human languages are riddled
with inconsistencies, often around the core aspects of the languages
(prepositions, to-be, etc).

>The above rules generate errors. Some rules, like the extraneous
>colon, generate warnings. Another example warning is treating return
>like a function call instead of a statement:  return(x)
>
>Should be: return x

What about    return (x + 4)    ?

Warning about extra parens seems rather pedantic to me.

>Back to indentation: I think you're okay in vim with [Return] [Tab]
>but let me know if that's a problem. Indentation can be one tab or 4
>spaces. No mixture of tabs and spaces on the same line as that causes
>hell in Python.

_never_ hit tab in vim.  If you want manual indentation, set sw=4, and use
^T and ^D to adjust indentation.  Indentation depth and tab with are
unrelated.

Can I indent arbitrarily, or do you enforce a specific amount.  The python
parser has some strange rules for this that work well (other than the
oddities of tabs and spaces).  But, Python is perfectly happy with the
first indentation being 4 spaces, and the second level being a single tab.
There are numerous editors that will do this, since it is how tabs have
been defined for a long time.  If you're different, you'll need to be very
explicit about it.

Please do not assume that tabs are 4 spaces.  You will offend people by
doing that.  If you want indentation to be hard tabs, please _enforce_
that, and disallow spaces.  This is actually Guido's recommendation for
Python code.  Most Unix-like editors are configured to display tabs as 8
spaces, and it is frustrating to keep changing that for different
languages.

When I write Python, I'll type   'if foo:' and when I hit [Return] my
cursor is automatically indented one level.  It can do this because of the
standardized use of the ':' at the end of a line to indicate something is
expecting a block.

Having the editor auto-indent is often the quickest feedback that something
is syntaxically wrong.  Of course, it doesn't mean quite as much in Python,
since the indentation _is_ what determines the nesting.

Dave