On Jan 2, 2008 11:07 AM, David Brown <[EMAIL PROTECTED]> wrote: > 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.
I'm counting keystrokes. In Python, I think the count is 3: Shift + :; then Enter In Cobra, it's 2: Enter Tab > 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. The parser is built and working. It wasn't a big deal to handle indentation... > 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. True, but most of my conventions are conventional. Capped classes. Lower case args. I admit I'm taking it further than most languages, but that's the point: semi-normalized syntax. > >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). Sure, but my point still stands even with the inconsistencies you mentioned: We have lots of rules about English capitalization, punctuation and so on that enable us to read a wide variety of texts. I think the challenge here is that by the time people reach adulthood, these rules are so ingrained that they're taken for granted. I don't think people realize how much benefit they get from these rules. > >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. Yes, there is a warning about extra top level parens. > >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. 1 indent = 4 spaces or 1 tab Display width of tabs = 4 > 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. It's quite clear that I will offend people no matter what I do... > 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. It can do this because you contributed two extra keystrokes beforehand: [Shift] [:;] That's not exactly "automatic"... > 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. Exactly! -Chuck -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
