Re: ? assignments are not expressions ?

[Will Leshner <will@...>]

Sorry I confused (assignment) statements with expressions. I was thinking of
scheme in which everything is either an atom or an expression. But I do
think that it could be quite powerful (or confusing?) to have that same
concept in Lua. I noticed this right away when I typed "a = 3" at the
command-line prompt and got nothing back. If I did that with a scheme
interpreter I would have gotten 3 back.

> From: Reuben Thomas <rrt@dcs.gla.ac.uk>
> Reply-To: lua-l@tecgraf.puc-rio.br
> Date: Tue, 27 Mar 2001 09:59:15 +0100 (BST)
> To: Multiple recipients of list <lua-l@tecgraf.puc-rio.br>
> Subject: Re: ? assignments are not expressions ?
> 
>> Personally, I think all expressions should return values. To me, Lua feels a
>> lot like scheme, except that expressions don't return values. Another thing
> ^^^^^^^^^^^
> Surely "assignments"?
> 
>> you could do if assignments returned values is:
>> 
>> x = y = z = 0
> 
> I agree that it's a pity that not everything returns a value (but it's only
> worth doing if all statements return a value e.g. the value of an
> if...then...else...end should be the value of whichever branch of the if is
> executed; the value of a block of statements is the value of the last
> statement; the value of a while or for block is the value of the last
> iteration &c.
> 
>>> I don't really agree. You just have to use some self-discipline. And if
>>> you don't like the costruct, you're not forced to use it... But you
>>> can't deny that
>>> 
>>> while ( X = read() )
>>> do
>>> print ( X )
>>> end
>>> 
>>> is by far nicer and CLEARER than
>>> 
>>> X = read()
>>> while X
>>> do
>>> print ( X )
>>> X = read()
>>> end
> 
> But I'm still worried about allowing assignments everywhere, because it can
> indeed introduce subtle bugs (although using := for assignment and = for
> equality would make life a lot better, because then the bugs become much
> less obscure (and are often just syntax errors)).
> 
> The nastiness of the code above is really an artefact of not having loops in
> which you can test the condition anywhere. You could rewrite it:
> 
> while 1 do
> X = read()
> if not(X) then break end
> print (X)
> end
> 
> which would look nicer as:
> 
> repeat
> X = read()
> while X
> print (X)
> end
> 
> ...but of the languages I know, only Forth allows this sort of construct
> (and it's forced to, because of postfix evaluation). This to my mind would
> be a much nicer addition to the language: you can write while...endwhile
> loops with it:
> 
> repeat
> while foo
> ...
> end
> 
> repeat...until loops:
> 
> repeat
> ...
> while foo
> end
> 
> and in-between loops, as above. You could even have multiple whiles (because
> the semantics of while is just "while cond" = "if not (cond) then break
> end"). You can of course have unending loops by having no while or break.
> And the current while syntax could be retained as syntactic sugar:
> 
> while foo do --> repeat while foo
> 
> although there is a subtle issue that the current syntax is effectively
> while foo <block>, whereas it translates to something that pushes code
> inside the <block>. Fortunately, you can't current write while foo
> <statement>, so there's no real problem (also, blocks of statements are not
> first class, so you can't have while foo b, where b is a variable whose
> value is a block).
> 
> Anyway, just my heap o' change.
> 
> -- 
> http://sc3d.org/rrt/
> L'art des vers est de transformer en beautés les faiblesses (Aragon)
> 
>