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 -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
