On Sat, 01 Jan 2011 18:36:17 -0500
bearophile <bearophileHUGS@lycos.com> wrote:

> spir:
> 
> > (Even reproduced "elif"
> 
> Python doesn't have the switch statement, so to write a switch you sometimes use a sequence of if statements, in this case "elif" helps keep the code more tidy:
> 
> x = 3
> if x == 0:
>     pass
> elif x = 1:
>     pass
> else:
>     pass

Sorry, my words were too imprecise; and too strong for such a little issues. I aggre with you, but it's not my point (I wrote "elif" in quote: it's about the term). "elif" is nearly unguessable: should be "elseif" or "elsif" (--> Lua does it right).

> > and kept the stupid ':' of Python ;-).

Sorry again, for "stupid".

> It comes from usability studies on the ABC language. If you are going to use a Python-like syntax, then removing those ":" is stupid.

IIRC, said usability studies were about indented code structure (as opposed to token-delimited structure). I have never read anything in studies about ':'. This non-token, that does not mean anything, should at best be optional, just like the ';' statement terminator (which is allowed in python, but no one uses it outside multi-statement lines, probably because, precisely, it does not mean anything).
When I used python everyday, I constantly repeted 2 syntax errors:
* forgetting ':' (just like forgetting ';' in D)
* using '=' instead of '==' (obvious reason, same in D)
These are for me 2 grammatical design errors.

> > "Parameters are constant in the procedure body. Their value cannot be changed because this allows the compiler to implement parameter passing in the most efficient way.
> 
> I have missed that part of the docs. What kind of "most efficient way"?

nsure. I guess the author refers to the possibility to pass _any_ non-var parameter by ref under the hood if more efficient, since it won't be changed. (arrays, which have copy semantics in Nimrod , its tuples ~ structs, and object types also are value types apparently)
I plan to do the same for my toy project one day. Pleased to see I'm not the only fool ;-)


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

spir:

> "elif" is nearly unguessable: should be "elseif" or "elsif" (--> Lua does it right).

"elif" is 4 chars long, as "else", this is not a random choice.


> IIRC, said usability studies were about indented code structure (as opposed to token-delimited structure). I have never read anything in studies about ':'.

This is from Guido's blog: http://python-history.blogspot.com/2009/02/early-language-design-and-development.html

>However, ABC’s authors did invent the use of the colon that separates the lead-in clause from the indented block. After early user testing without the colon, it was discovered that the meaning of the indentation was unclear to beginners being taught the first steps of programming. The addition of the colon clarified it significantly: the colon somehow draws attention to what follows and ties the phrases before and after it together in just the right way.<

Bye,
bearophile

On Sun, 02 Jan 2011 04:58:28 -0500
bearophile <bearophileHUGS@lycos.com> wrote:

> - I like the idea of AST macros, they are powerful, but they add a significant amount of complexity to the language. So I am not pushing a lot for them, despite I almost hate string mixings and creating code with string snippets.

I feel exactly the same.

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> spir:
> > "elif" is nearly unguessable: should be "elseif" or "elsif" (--> Lua does it
right).
> "elif" is 4 chars long, as "else", this is not a random choice.

Less is not more in this case. I agree with elsif (Perl does it right too :)

Iain Buclaw:

> Less is not more in this case. I agree with elsif (Perl does it right too :)

I was talking about vertical alignments (4 with 4), not about saving one or two chars :-)

Bye,
bearophile