syntax likes and dislikes (RE: Evaluating LUA)

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

syntax likes and dislikes (RE: Evaluating LUA)

Asko Kauppi-2
I'm a C programmer since 10+ years, and never got to think of this syntax
difference until you mentioned it. To me, clearly separate syntaxes is
better than some that are "close by". In school, learning Swedish and German
at the same time was a challenge since there's so much similarities. 

For me, the only "C-like" syntactical thing that I miss (in Lua) is the +=
etc. notations.

- asko


> -----Original Message-----
> From:	Joshua Jensen [SMTP:[hidden email]]
> Sent:	Saturday, August 10, 2002 12:21 AM
> To:	Multiple recipients of list
> Subject:	RE: Evaluating LUA
> 
> > > I actually like the fact that Lua is not C-like.  There are already 
> > > too many C-like languages and it becomes rather confusing 
> > to have to 
> > > deal with all the variations-on-a-theme.  Lua's choice of syntax 
> > > avoids that problem.
> > 
> 
> Except it's the biggest hangup when trying to convert C and Javascript
> users... "Why do tables use braces and functions do not?" ... and
> they're the main people I always try and get to use Lua.
> 
> -Josh
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.


Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Dan Partelly
Of course, its an extremly personal thing. I just happen to think if -
then - end has a great redundancy. if {} is much more conchise.

Dan

----- Original Message -----
From: "Asko Kauppi" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Cc: <[hidden email]>
Sent: Monday, August 12, 2002 9:16 AM
Subject: syntax likes and dislikes (RE: Evaluating LUA)


>
> I'm a C programmer since 10+ years, and never got to think of this syntax
> difference until you mentioned it. To me, clearly separate syntaxes is
> better than some that are "close by". In school, learning Swedish and
German
> at the same time was a challenge since there's so much similarities.
>
> For me, the only "C-like" syntactical thing that I miss (in Lua) is the +=
> etc. notations.
>
> - asko
>
>
> > -----Original Message-----
> > From: Joshua Jensen [SMTP:[hidden email]]
> > Sent: Saturday, August 10, 2002 12:21 AM
> > To: Multiple recipients of list
> > Subject: RE: Evaluating LUA
> >
> > > > I actually like the fact that Lua is not C-like.  There are already
> > > > too many C-like languages and it becomes rather confusing
> > > to have to
> > > > deal with all the variations-on-a-theme.  Lua's choice of syntax
> > > > avoids that problem.
> > >
> >
> > Except it's the biggest hangup when trying to convert C and Javascript
> > users... "Why do tables use braces and functions do not?" ... and
> > they're the main people I always try and get to use Lua.
> >
> > -Josh
> ###########################################
> This message has been scanned by F-Secure Anti-Virus for Microsoft
Exchange.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Reuben Thomas-5
> Of course, its an extremly personal thing. I just happen to think if -
> then - end has a great redundancy. if {} is much more conchise.

This is a silly argument. But I'm in a silly mood...

Semantically, it's exactly the same thing (or put another way, the 
abstract syntax is the same).

Otherwise, there are two things to count: characters and tokens. if () {} 
wins on characters (6-9, not counting spaces). if then end wins on tokens 
(3-5). Of course, if () wins in the case that you only need a block, not a 
statement, in both ways. But it sacrifices consistency to achieve this.

-- 
http://www.mupsych.org/~rrt/ | plagiarism, n.  the mind burgles



Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Dan Partelly
My friend, as I statuated, this is not an argument, is a personal thing.
Maybe you like blondes and I like readheads. This dont makes you stupid, as
liking {} dont make me silly.
Im not here on this list to argue about what I like and what I dont like, im
here to learn using LUA efficinetly.  I statuated what I like and what I
dont like, you can do the same, I could not care less.

Ciao, Dan


----- Original Message -----
From: "Reuben Thomas" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Monday, August 12, 2002 3:16 PM
Subject: Re: syntax likes and dislikes (RE: Evaluating LUA)


> > Of course, its an extremly personal thing. I just happen to think if -
> > then - end has a great redundancy. if {} is much more conchise.
>
> This is a silly argument. But I'm in a silly mood...
>
> Semantically, it's exactly the same thing (or put another way, the
> abstract syntax is the same).
>
> Otherwise, there are two things to count: characters and tokens. if () {}
> wins on characters (6-9, not counting spaces). if then end wins on tokens
> (3-5). Of course, if () wins in the case that you only need a block, not a
> statement, in both ways. But it sacrifices consistency to achieve this.
>
> --
> http://www.mupsych.org/~rrt/ | plagiarism, n.  the mind burgles
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

RLak
In reply to this post by Asko Kauppi-2
>> Of course, its an extremly personal thing. I just happen to think if -
>> then - end has a great redundancy. if {} is much more conchise.

> This is a silly argument. But I'm in a silly mood...

> Semantically, it's exactly the same thing (or put another way, the
> abstract syntax is the same).

> Otherwise, there are two things to count: characters and tokens. if () {}
> wins on characters (6-9, not counting spaces). if then end wins on tokens
> (3-5). Of course, if () wins in the case that you only need a block, not
a
> statement, in both ways. But it sacrifices consistency to achieve this.

Not to mention the dangling else semi-ambiguity, which is my personal
dislike
for the C syntax. I have always found it disconcerting that you have to put
a ;
in:
   if (a > 0) y = a;
   else y = 1 - a;

To me, the Pascal-like Lua syntax is clearer -- but it's just
a personal prejudice, to be sure.

On a semi-related topic, how do you all indent Lua "if" statements?
Do you put the "then" on the same line as the "if" or on a line by itself?

Rici



Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Peter Loveday-2
> On a semi-related topic, how do you all indent Lua "if" statements?
> Do you put the "then" on the same line as the "if" or on a line by itself?

    if xxx then
        ...
        ...
    else
        ...
        ...
    end


Love, Light and Peace,

- Peter Loveday
Director of Development, eyeon Software



rje
Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

rje
In reply to this post by RLak
On Mon, Aug 12, 2002 at 10:45:48AM -0500, [hidden email] wrote:

<snip>

> Not to mention the dangling else semi-ambiguity, which is my personal
> dislike
> for the C syntax. I have always found it disconcerting that you have to put
> a ;
> in:
>    if (a > 0) y = a;
>    else y = 1 - a;
> 
> To me, the Pascal-like Lua syntax is clearer -- but it's just
> a personal prejudice, to be sure.

I personally dislike both C's and Lua's ways :)  The BASIC programmer
inside me likes to end structures with a specific ending, like ENDIF or
NEXT rather than the more generic "end" - In my experience it means it's
easier to detect certian types of error.  Where most BASIC's have the
parameters to NEXT optional, if you do supply it, the interpreter will
make sure you're not overlapping your loops etc.  I tend, when writing
quite complex code in Lua, to put a comment after the end to specify
exactly what it's ending, a for loop, and if etc.  Of course, the
compiler doesn't pay attention to these.

> On a semi-related topic, how do you all indent Lua "if" statements?
> Do you put the "then" on the same line as the "if" or on a line by itself?

if (foo == bar) then
  wibble;
end;

or, sometimes if (foo == bar) then wibble; end;

I seem to be mildly unusual in my use of ; at the end of statements from
what I've seen, too.  Don't know why, just seems to make it easier to
read.

Cheers,
-- 
Rob Kendrick - http://www.nun.org.uk/
Water, taken in moderation cannot hurt anybody.
		-- Mark Twain

Reply | Threaded
Open this post in threaded view
|

Loops and 'continue' keyword

Joshua Jensen
I scanned through the list archives to try and remember why this was
taken away.  I have a _continual_ need for having the C-like 'continue'
behavior in loops.  Oftentimes, I structure my C code in such a way that
using continue decreases the number of 'if' statement indentation levels
and alleviates the need for 'else' in many cases.

Refresh my memory... why was it removed?  It sure would be a nice
feature to have back in.

Thanks,
Josh


Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Edgar Toernig
In reply to this post by Dan Partelly
My 2 cent:

> I just happen to think if - then - end has a great redundancy.
> if {} is much more conchise.

Most of the time I have no problem with if-then-end.  The only
place it bothers me is in cases like this:

  if x then return x end
  if not x then break end
  ...

IMHO, the additional tokens "then" and "end" only obfuscate the real
meaning of the statements.  I would prefer:

  if x return x
  if not x break
  ...

that is: without a "then" only a single statement is taken and an
"else" is not allowed (same could be done with for, while, ...).

I would have already submitted a PowerPatch but unfortunately, this
syntax does not work because of the optional argument of "return"
which requires a terminating token (end, else, elseif, until, semi-
colon, or EOF).  Without one, "return" is ambigious:

  if x return
  foo()

could be:

  if x then return foo() end

And I don't like the idea to make i.e. a semicolon a requirement in
this case.

So, unless someone has a clever idea for that I guess I'll stick with
the current syntax.

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: Loops and 'continue' keyword

Luiz Henrique de Figueiredo
In reply to this post by Joshua Jensen
>Refresh my memory... why was it removed?

"continue" was never included in Lua. Perhaps it was only discussed when we
introduced "break".
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Loops and 'continue' keyword

Joshua Jensen
> >Refresh my memory... why was it removed?
> 
> "continue" was never included in Lua. Perhaps it was only 
> discussed when we introduced "break". --lhf

That could be it.  I don't have a copy of Lua older than 4.0, so I
couldn't check.  I seem to recall I modified a copy of Lua to make it
happen for me.

Well, consider it an official request for inclusion, then.  I believe it
can help make cleaner, more concise script code, in the same vein that
it cuts back on number of indentation levels for my C code.  Would be
cool to have...

-Josh


Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Eric Tetz-2
In reply to this post by Edgar Toernig
--- Edgar Toernig <[hidden email]> wrote:
> IMHO, the additional tokens "then" and "end" only obfuscate the real
> meaning of the statements.  I would prefer:

Well, 'end' is hard to get rid of, but 'then' is already totally unneeded by the compiler.  It
could be made optional by tweaking one line of code, with zero side effects. Same goes for the
"do" following "for" and "while" loops, totally unneeded.

I would love to see these superfluous tokens be made optional, given us a slightly leaner,
Python-esque source.

__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

Reply | Threaded
Open this post in threaded view
|

RE: syntax likes and dislikes (RE: Evaluating LUA)

John Passaniti-4
> Well, 'end' is hard to get rid of, but 'then'
> is already totally unneeded by the compiler.  
> It could be made optional by tweaking one line 
> of code, with zero side effects. Same goes for 
> the "do" following "for" and "while" loops, 
> totally unneeded.

I had always just assumed that 'DO' and 'THEN' were necessary because of
some ambiguity regarding parsing the conditional expression prior to it.
But after reading your message, I looked deeper and found that DO and
THEN do indeed seem superfluous.  

Here's a diff off the current version, on lparser.c.  Works for me!
Would be nice if the Lua authors considered making DO and THEN optional.

811c811
<   check(ls, TK_DO);
---
>   optional(ls, TK_DO);
841c841
<   check(ls, TK_DO);
---
>   optional(ls, TK_DO);
908c908
<   check(ls, TK_THEN);
---
>   optional(ls, TK_THEN);



Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Edgar Toernig
In reply to this post by Eric Tetz-2
Eric Tetz wrote:
> --- Edgar Toernig <[hidden email]> wrote:
> > IMHO, the additional tokens "then" and "end" only obfuscate the real
> > meaning of the statements.  I would prefer:
> 
> Well, 'end' is hard to get rid of, but 'then' is already totally unneeded
> by the compiler.  It could be made optional by tweaking one line of code,
> with zero side effects. Same goes for the "do" following "for" and "while"
> loops, totally unneeded.
> 
> I would love to see these superfluous tokens be made optional, given us a
> slightly leaner, Python-esque source.

Hehe, part of Sol's changelog:

>sol 0.61 Thu, 02 Aug 2001 03:17:36 +0200 by froese
>Version-Log:         made 'then' and 'do' optional

But later on I decided that it's a bad idea[1] exactly because that
would prohibit a later change I described in my previous posting.
I.e. if someday I decide that a semicolon is a required statement
terminator I could implement single statement if's, while's, and for's.
But when 'do' and 'then' are already optional you cannot decide any
more whether it's a short or long form.

Ciao, ET.


[1] ... but forgot to undo it.

Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Kelmar K. Firesun
In reply to this post by John Passaniti-4
----- Original Message ----- 
From: "John Passaniti" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Monday, August 12, 2002 3:09 PM
Subject: RE: syntax likes and dislikes (RE: Evaluating LUA)


> > Well, 'end' is hard to get rid of, but 'then'
> > is already totally unneeded by the compiler.  
> > It could be made optional by tweaking one line 
> > of code, with zero side effects. Same goes for 
> > the "do" following "for" and "while" loops, 
> > totally unneeded.
> 
> I had always just assumed that 'DO' and 'THEN' were necessary because of
> some ambiguity regarding parsing the conditional expression prior to it.
> But after reading your message, I looked deeper and found that DO and
> THEN do indeed seem superfluous.  
> 

] ... SNIP ... [

I've always had the mind set that the "IF test THEN action END" 
statements were not only chosen because they reduce compiling and
parsing ambiguities, but also because they are clearer for new 
programmers whats going on then a slightly more cryptic C like 
syntax "IF (test) action"

With the current syntax you can almost form statements that read
much like an English sentence:

if not exiting then
    continue
end

Opposed to:

if (!exiting)
    continue;

Certainly the C syntax has its advantages, less typing comes to mind,
but isn't Lua supposed to be designed for non-programmers as well?

Kelmar K. Firesun (IRL: Bryce Simonds)


Reply | Threaded
Open this post in threaded view
|

RE: syntax likes and dislikes (RE: Evaluating LUA)

Nick Trout-4
In reply to this post by Asko Kauppi-2
> I've always had the mind set that the "IF test THEN action END" 
> statements were not only chosen because they reduce compiling and
> parsing ambiguities, but also because they are clearer for new 
> programmers whats going on then a slightly more cryptic C like 
> syntax "IF (test) action"
> 
> With the current syntax you can almost form statements that read
> much like an English sentence:
> 
> if not exiting then
>     continue
> end
> 
> Opposed to:
> 
> if (!exiting)
>     continue;
> 
> Certainly the C syntax has its advantages, less typing comes to mind,
> but isn't Lua supposed to be designed for non-programmers as well?


Personally speaking I agree with this sentiment. I dont think there should
be optional keywords. I think Lua is easy to scan read and not verbose. It
could be said that if you dont want to confuse beginners with this then dont
tell them about the feature, but then when you have things like standard
libraries you may get mixtures of coding style, which doesnt always lead to
clarity.

It would be nice to be able to have single statements if conditionals, eg.
"if <condition> return|break" but since there is ambiguity we'll have to
make do with blocks. I dont remember many mails complaining about this. Its
just an unfortunate side effect of the optional ";". I just wonder if "then"
and "do" were made option if this would force other quirks further down the
line when people want to extend Luas syntax again.

Nick





Reply | Threaded
Open this post in threaded view
|

RE: syntax likes and dislikes (RE: Evaluating LUA)

John Passaniti-4
In reply to this post by Kelmar K. Firesun
> With the current syntax you can almost
> form statements that read much like
> an English sentence:

Find the 'then' in the following English sentence:

	If Sue is hungry she'll eat the apple.

I honestly don't believe that removing DO and THEN from non-programmer's
introduction to Lua is going to be the biggest stumbling block they'll have
with the language!

My interest in removing unnecessary syntax is not to reduce typing, but to
make Lua a smaller and more trim language.  Admittedly, making two keywords
optional doesn't substantially result in a leaner language, but it is
consistent with the Lua author's stated goals.




Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Dan Partelly
I for one, Im completly for eliminating redundancy.

----- Original Message -----
From: "John Passaniti" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Tuesday, August 13, 2002 6:29 PM
Subject: RE: syntax likes and dislikes (RE: Evaluating LUA)


> > With the current syntax you can almost
> > form statements that read much like
> > an English sentence:
>
> Find the 'then' in the following English sentence:
>
> If Sue is hungry she'll eat the apple.
>
> I honestly don't believe that removing DO and THEN from non-programmer's
> introduction to Lua is going to be the biggest stumbling block they'll
have
> with the language!
>
> My interest in removing unnecessary syntax is not to reduce typing, but to
> make Lua a smaller and more trim language.  Admittedly, making two
keywords
> optional doesn't substantially result in a leaner language, but it is
> consistent with the Lua author's stated goals.
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: syntax likes and dislikes (RE: Evaluating LUA)

Reuben Thomas-5
In reply to this post by John Passaniti-4
> Find the 'then' in the following English sentence:
> 
> 	If Sue is hungry she'll eat the apple.

Let's see...first she nibbles a biscuit,

Then if Sue is hungry she'll eat the apple.

Or maybe she often gets peckish in the afternoon, and saves part of her 
lunch until tea-time.

If Sue is hungry she'll eat the apple then.

Or maybe this is an old English text

If Sue is hungry she'll eat the napple.

> My interest in removing unnecessary syntax is not to reduce typing, but
> to make Lua a smaller and more trim language.  Admittedly, making two
> keywords optional doesn't substantially result in a leaner language, but
> it is consistent with the Lua author's stated goals.

I agree. Assuming you're not going to make Lua properly functional, and
hence require ; after statements, you might as well remove while's do and
then. Their function at the moment is purely visual (as demonstrated by
the patch), and can equally be achieved with indenting.

Making them optional for 5.0 would satisfy all but the crustiest of 
crusties.

Someone said it could lead to greater diversity of style in, for example,
libraries. As the maintainer of stdlib, I've developed a standard coding
style, and frankly do and then are the least of my worries. There's
indentation (thanks, lua-mode.el!), variable naming, and vaguer,
philosophical things to worry about too. As far as code layout goes, 
having full reflexive access to Lua programs is much more effective (so 
you can load code in and spit it out in the layout you want) than any 
syntax changes.

-- 
http://www.mupsych.org/~rrt/
Reality is what refuses to disappear when you stop believing in it (Dick)






Reply | Threaded
Open this post in threaded view
|

Re: syntax likes and dislikes (RE: Evaluating LUA)

Christian Vogler-2
On Tue, Aug 13, 2002 at 04:52:51PM +0100, Reuben Thomas wrote:
> There's indentation (thanks, lua-mode.el!)

Eargh. Just for the record, if "then" and "do" become optional,
adapting lua-mode.el looks nontrivial to me, because then the block
boundaries cannot be keyword-based anymore. To get indentation right,
it might then even be necessary to implement a full-blown
recursive-descent parser. Talk about overkill.

Just thought that I should mention this as a potential tradeoff.

Regards
- Christian

12