|
|
123
|
|
I quite like the modest tincture of redundancy in
Lua's syntax. In fact I have a habit of decorating
the one-serves-all 'end' with a comment:
end -- if, end -- while, end -- function, end -- do.
I would not have objected if each kind of 'end' had
been given its own token, or would that have been
too reminiscent of prim old Pascal?
--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/
|
|
|
On 8/27/05, Gavin Wraith < [hidden email]> wrote:
I quite like the modest tincture of redundancy in
Lua's syntax. In fact I have a habit of decorating
the one-serves-all 'end' with a comment:
end -- if, end -- while, end -- function, end -- do.
I would not have objected if each kind of 'end' had
been given its own token, or would that have been
too reminiscent of prim old Pascal?
The `end-sth' property is present in Ada, Dylan and other
languages. In some of them the additional word is not
mandatory.
Another option is the ending word being the reverse of
the opening one: if -- fi, do -- od etc. Example is Algol 68.
As for Pascal, it has neither of these. There, the body of
a control statement is just another statement, simple or
compound (begin -- end). An exception of this rule
(which introduces a bit of inconsistency in the language)
is the repeat -- end loop.
|
|
|
In message <a542ea6105082810204b6d9cd3@...> you wrote:
> > I would not have objected if each kind of 'end' had
> > been given its own token, or would that have been
> > too reminiscent of prim old Pascal?
> >
>
> The `end-sth' property is present in Ada, Dylan and other
> languages. In some of them the additional word is not
> mandatory.
> Another option is the ending word being the reverse of
> the opening one: if -- fi, do -- od etc. Example is Algol 68.
I always thought that very ugly.
> As for Pascal, it has neither of these. There, the body of
> a control statement is just another statement, simple or
> compound (begin -- end). An exception of this rule
> (which introduces a bit of inconsistency in the language)
> is the repeat -- end loop.
My apologies to Pascal. It is a long time since I was exposed
to it, but I remember it as verbose.
--
Gavin Wraith ([hidden email])
Home page: http://www.wra1th.plus.com/
|
|
|
Gavin Wraith wrote:
The `end-sth' property is present in Ada, Dylan and other
languages. In some of them the additional word is not
mandatory.
Another option is the ending word being the reverse of
the opening one: if -- fi, do -- od etc. Example is Algol 68.
I always thought that very ugly.
Me too. I never user Algol, but I remember a language doing that (which
one?), and I didn't liked it.
As for Pascal, it has neither of these. There, the body of
a control statement is just another statement, simple or
compound (begin -- end). An exception of this rule
(which introduces a bit of inconsistency in the language)
is the repeat -- end loop.
My apologies to Pascal. It is a long time since I was exposed
to it, but I remember it as verbose.
Well, Basic, at least Visual Basic, does that:
End If
End Sub
End With
End Select
etc.
Only End is mandatory, but I used to add the optional word all the time.
Same for Next <VariableLoopName>, the variable being optional.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
|
|
|
On Mon, 2005-08-29 at 10:45 +0200, Philippe Lhoste wrote:
> Gavin Wraith wrote:
> >> The `end-sth' property is present in Ada, Dylan and other
> >> languages. In some of them the additional word is not
> >> mandatory.
> >> Another option is the ending word being the reverse of
> >> the opening one: if -- fi, do -- od etc. Example is Algol 68.
<snip>
> Well, Basic, at least Visual Basic, does that:
> End If
> End Sub
> End With
> End Select
> etc.
>
> Only End is mandatory, but I used to add the optional word all the time.
> Same for Next <VariableLoopName>, the variable being optional.
I always found this very useful - it meant that the compiler whinged at
if you got it wrong - it's useful for confirming where each structure
ends in your mind. Alas, I don't think this kind of thing is possible
to be implemented optionally in Lua, as it is in Basic, as the compiler
wouldn't be able to tell the difference between the end or a beginning
of a block. :-/
--
Rob Kendrick
|
|
|
On Monday 29 August 2005 13.26, Rob Kendrick wrote:
[...]
> > Only End is mandatory, but I used to add the optional word all the
> > time. Same for Next <VariableLoopName>, the variable being
> > optional.
>
> I always found this very useful - it meant that the compiler whinged
> at if you got it wrong - it's useful for confirming where each
> structure ends in your mind.
I've found that proper indentation, and an editor with the good old
(at least in the Un*x world) "highlight matching brace" feature,
pretty much eliminates the need for this kind of language features.
Besides, in many languages, you're hard pushed to make anything
compile at all, if there is one brace too few or too many - although
at least some of the GNU compilers tend to completely freak out and
crash or give incomprehensible error messages in some of those cases.
However, I can't remember seeing an editor with a "highlight matching
keyword" feature... One would need a list of open/close keyword
pairs, so this propably falls in the language aware syntax
highlighting domain - but most serious editors do that anyway, these
days.
> Alas, I don't think this kind of thing is possible to be implemented
> optionally in Lua, as it is in Basic, as the compiler wouldn't be
> able to tell the difference between the end or a beginning of a
> block. :-/
Well, if the "end of statement" rule is a problem, there's always the
option of doing it in the form of "semi synonyms" that allow you to
replace 'end' with 'endif', 'endsub' or similar. The token
substitution filter would double as a hook for the extra checking.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
|
|
|
On 29-Aug-05, at 7:58 AM, David Olofson wrote:
However, I can't remember seeing an editor with a "highlight matching
keyword" feature...
The standard vim lua highlighter has the nice feature of colouring the
end in function ... end a different colour than the end in do ... end.
This combined with the fact that it stops highlighting 'end' altogether
when you leave out a then, for example, makes most such simple errors
immediately obvious.
|
|
|
David Olofson wrote:
> However, I can't remember seeing an editor with a
> "highlight matching keyword" feature...
Rici Lake wrote:
> The standard vim lua highlighter has the nice feature of
> colouring the end in function ... end a different colour
> than the end in do ... end.
Also, Vim's matchit plugin allows jumping between control
flow keywords with the same key ("%") that normally jumps to
the matching parenthesis. Do ":help matchit" for more
details.
According to the documentation it supports Lua
out-of-the-box, but my copy didn't, so I had to add:
" Lua
au FileType lua if !exists("b:match_words") |
\ let b:match_words =
\ '\<\%(do\|function\|if\)\>:' .
\ '\<\%(return\|else\|elseif\)\>:' .
\ '\<end\>,' .
\ '\<repeat\>:\<until\>'
\ | endif
--
Aaron
|
|
|
El 29/08/2005, a las 20:38, Aaron Brown escribió:
I also think that the dangling keywords after "end" are totally
unneccessary. In fact, being concise is one of the things a I love
from C; typing much more than '{' and '}' is wasted time. The Lua
'do...end' is only three extra letters, which I find acceptable, but
for example Pascal "begin...end" blocks have _six_ extra letters...
Just my opinion.
The standard vim lua highlighter has the nice feature of colouring
the end in function ... end a different colour than the end in
do ... end.
Also, Vim's matchit plugin allows jumping between control flow
keywords with the same key ("%") that normally jumps to the
matching parenthesis. Do ":help matchit" for more details. [...]
WOW! Great Vim-tip for all the Vim users :-D
Dind't know about matchit, it's very nice. Thanks for the tip.
--
Adrian Perez
GPUL/CLUG member » http://gpul.org
Por los puntos #20 y #54.
Attachment:
PGP.sig
Description: Mensaje firmado digitalmente
|
|
|
On Tuesday 30 August 2005 10:17, Adrian Perez wrote:
> The Lua
> 'do...end' is only three extra letters, which I find acceptable, but
> for example Pascal "begin...end" blocks have _six_ extra letters...
It's all a matter of the way you think language semantics should work...
A statement like 'if', in an Algol-based language like Lua, works on statement
lists:
if { expression } { list to execute if true } { list to execute if false }
You really need a way of delimiting the statement lists. Lua and Pascal
believe that the syntax to do this belongs in the thing that is performing
the action --- if...then...else...endif. C and Javascript believe that it's
better to have seperate syntax for doing this; the thing that performs the
action operates on a *single* statement --- but you can wrap up a statement
list into a single statement.
Ultimately, this is purely a matter of personal preference, which means that
the only opinion that matters is that of the Lua devs. (As its their
language.) *My* personal preference is to go with the C-like style, but
that's only because I grew up on C.
--
+- David Given --McQ-+ "A character is considered to be a letter if and
| [hidden email] | only if it is a letter or digit (Â20.5.16) but is
| ([hidden email]) | not a digit (Â20.5.14)." --- SMSDN Java
+- www.cowlark.com --+ documentation
Attachment:
pgpCpaqCpejo2.pgp
Description: PGP signature
|
|
|
On 30-Aug-05, at 4:17 AM, Adrian Perez wrote:
I also think that the dangling keywords after "end" are totally
unneccessary. In fact, being concise is one of the things a I love
from C; typing much more than '{' and '}' is wasted time. The Lua
'do...end' is only three extra letters, which I find acceptable, but
for example Pascal "begin...end" blocks have _six_ extra letters...
On the other hand, { and } are harder to type. Anyway, I think your
count is selective:
int i; for (i = 1; i <= 10; ++i) { ... }
for i = 1, 10 do ... end
Advantage: Lua, 16 fewer keystrokes
if (a < 0) { ... } else if (a > 0) { ... } else { ... }
if a < 0 then ... elseif a > 0 then ... else ... end
Advantage: Lua, 3 fewer keystrokes
And in both cases, the Lua was much easier to type; far fewer uses of
the shift key.
:)
R
|
|
|
On 8/30/05, David Given <[hidden email]> wrote:
> ...Lua and Pascal believe that the syntax to do this belongs in
> the thing that is performing the action --- if...then...else...endif.
> C and Javascript believe that it's better to have seperate syntax
> for doing this; the thing that performs the action operates on a
> *single* statement --- but you can wrap up a statement list into
> a single statement.
Actually, in this respect Pascal is no different from C, except
for using `begin' and `end' instead of { and }. I pointed out this
in a previous posting in the thread.
One can observe that there are several possibilities here.
-- Explicit, keyword-delimited start, end, and inner parts of
control statements (Lua, Ada, Clu, Modula, Dylan, etc).
The are variants of this, but in any case the keywords
in use are specific to the corresponding control statements.
-- As above, but with dedicated characters or combinations
instead of keywords.
-- Each part of a control statement is a statement, including a
compound statement (a block). So there has to be a universal
construct for building a block, such as do--end, begin--end,
{--}, [--] etc, to be used wherever the body (or part) of a control
statement must be compound (Pascal, C and descendants).
-- There is only one, universally applied kind of a block
statement (as above), but it is mandatory to use it wherever
a statement is nested within a control statement -- no simple
statements allowed as parts (bodies) of control statements
(Perl, Rebol).
-- Using offset to indicate nesting (occam, Miranda, Haskell,
Python). In Haskell, one has the choice between using
offsets and delimiting with braces: { and }.
> Ultimately, this is purely a matter of personal preference
Well, not only. The languages of the third group mentioned
are notorious for having to disambiguate where an `else' belongs
when `if's are nested. That problem, btw, would have been
avoided, had the language designers introduced something else
(say, `when') for one-branched `if's, and left the `if' for two-branch
use only.
> ... the only opinion that matters is that of the Lua devs
Of course. We are only talking. :)
Cheers,
B.B.
|
|
|
El 30/08/2005, a las 15:57, Rici Lake escribió:
On 30-Aug-05, at 4:17 AM, Adrian Perez wrote:
On the other hand, { and } are harder to type. Anyway, I think your
count is selective:
int i; for (i = 1; i <= 10; ++i) { ... }
for i = 1, 10 do ... end
Advantage: Lua, 16 fewer keystrokes [...]
I didn't think about that, so now it's official... Lua also beats C!
(when comparing typing amount, BTW)
xD
--
Adrian Perez
GPUL/CLUG member » http://gpul.org
Por los puntos #20 y #54.
Attachment:
PGP.sig
Description: Mensaje firmado digitalmente
|
|
|
Sorry, just couldn't resist the following :)
On 8/30/05, Rici Lake <[hidden email]> wrote:
> int i; for (i = 1; i <= 10; ++i) { ... }
> for i = 1, 10 do ... end
>
> Advantage: Lua, 16 fewer keystrokes
Not so. Having once defined
#define DO(var,from,to) for (var=from; var<=to; ++var)
then
DO(i,1,10) {...}
|
|
|
On 30-Aug-05, at 10:23 AM, Boyko Bantchev wrote:
Sorry, just couldn't resist the following :)
On 8/30/05, Rici Lake <[hidden email]> wrote:
int i; for (i = 1; i <= 10; ++i) { ... }
for i = 1, 10 do ... end
Advantage: Lua, 16 fewer keystrokes
Not so. Having once defined
#define DO(var,from,to) for (var=from; var<=to; ++var)
then
DO(i,1,10) {...}
That fails to declare i. Actually, I should have written the C line as
follows:
{ int i; for (i = 1; i <= 10; ++i) { ... } }
You could actually write that as a macro in C9x, taking advantage of
the bizarre syntax for declaring control variables inside for
expressions. But afaik there is no way of doing that in C90.
|
|
|
Adrian Perez wrote:
...
On the other hand, { and } are harder to type. Anyway, I think your
count is selective:
int i; for (i = 1; i <= 10; ++i) { ... }
for i = 1, 10 do ... end
Advantage: Lua, 16 fewer keystrokes [...]
I didn't think about that, so now it's official... Lua also beats C!
(when comparing typing amount, BTW)
I hate weighing in on things like this, but there are many more cases
where Lua not only requires more keystroked, but is more arcane as well.
At risk of being beaten up endlessly, how is this done in Lua?
struct list { struct list* next } list;
list* l;
... fill the list ...
for (list* p = l; p != 0; p = p->next) { ... }
How is that done in Lua? This is both trying to illustrate that C's for
loop has nice flexibility, and trying to understand how you would do
something like this in Lua! I would do it like this:
local l = { }
... fill the list
local p = l
while p ~= nil do
...
p = p.next
end
Any nicer ways?
--
chris marrin ,""$,
[hidden email] b` $ ,,.
mP b' , 1$'
,.` ,b` ,` :$$'
,|` mP ,` ,mm
,b" b" ,` ,mm m$$ ,m ,`P$$
m$` ,b` .` ,mm ,'|$P ,|"1$` ,b$P ,` :$1
b$` ,$: :,`` |$$ ,` $$` ,|` ,$$,,`"$$ .` :$|
b$| _m$`,:` :$1 ,` ,$Pm|` ` :$$,..;"' |$:
P$b, _;b$$b$1" |$$ ,` ,$$" ``' $$
```"```'" `"` `""` ""` ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'
|
|
|
On 8/30/05, Rici Lake <[hidden email]> wrote:
> That fails to declare i. Actually, I should have written the C line
> as follows:
>
> { int i; for (i = 1; i <= 10; ++i) { ... } }
>
> You could actually write that as a macro in C9x, taking advantage
> of the bizarre syntax for declaring control variables inside for
> expressions. But afaik there is no way of doing that in C90.
I think this abides by C90:
#define DO(var,from,to,body) {int var; for (var=from; var<=to; ++var) {body}}
I ran it with DO(i,0,9, printf("i = "); printf("%d\n",i););
through gcc and it worked as needed.
|
|
|
El 30/08/2005, a las 18:22, Chris Marrin escribió:
I hate weighing in on things like this, but there are many more
cases where Lua not only requires more keystroked, but is more
arcane as well.
At risk of being beaten up endlessly, how is this done in Lua?
struct list { struct list* next } list;
list* l;
... fill the list ...
for (list* p = l; p != 0; p = p->next) { ... }
How is that done in Lua? This is both trying to illustrate that C's
for loop has nice flexibility, and trying to understand how you
would do something like this in Lua! I would do it like this:
local l = { }
... fill the list
local p = l
while p ~= nil do
...
p = p.next
end
Any nicer ways?
I propose the following:
local l = { }
... fill the list
for _,value in l do
...
end
Of course, you may also write:
local l = { }
... fill the list
table.foreachi(l, function(_,value) ... end)
=)
--
Adrian Perez
GPUL/CLUG member » http://gpul.org
Por los puntos #20 y #54.
Attachment:
PGP.sig
Description: Mensaje firmado digitalmente
|
|
|
On 30-Aug-05, at 11:22 AM, Chris Marrin wrote:
I would do it like this:
local l = { }
... fill the list
local p = l
while p ~= nil do
...
p = p.next
end
Any nicer ways?
Write an iterator function.
do
local function nextlist(field, l)
return l and l[field]
end
function eachlist(l, field)
field = field or "next"
return nextlist, field, {[field] = l}
end
end
list = {"a", next = {"b", next = {"c"}}}
for l in eachlist(list) do print(l[1]) end
-- maybe I didn't want to use "next"
list = {"a", parent = {"b", parent = {"c"}}}
for l in eachlist(list, "parent") do print(l[1]) end
Whether that's nicer or not depends on your perspective, I guess. The
redundant table constructor is a bit irritating, and in any event it's
going to be somewhat slower than the while loop. On the other hand,
it's a nice simple syntax which makes it easy to see what's going on.
(Open to being criticised for doing the Lua equivalent of Boyko's DO
macro)
R
|
|
|
Adrian Perez wrote:
...
How is that done in Lua? This is both trying to illustrate that C's
for loop has nice flexibility, and trying to understand how you would
do something like this in Lua! I would do it like this:
local l = { }
... fill the list
local p = l
while p ~= nil do
...
p = p.next
end
Any nicer ways?
I propose the following:
local l = { }
... fill the list
for _,value in l do
...
end
Of course, you may also write:
local l = { }
... fill the list
table.foreachi(l, function(_,value) ... end)
But that's not the same. That just iterates over the properties of a
single table. I want a linked list of tables, where each table contains
a 'next' property which refers to the next table in the list. The last
table would have a next value of nil. You could argue that you SHOULD do
it as a single table of properties, but that doesn't illustrate the
example :-)
--
chris marrin ,""$,
[hidden email] b` $ ,,.
mP b' , 1$'
,.` ,b` ,` :$$'
,|` mP ,` ,mm
,b" b" ,` ,mm m$$ ,m ,`P$$
m$` ,b` .` ,mm ,'|$P ,|"1$` ,b$P ,` :$1
b$` ,$: :,`` |$$ ,` $$` ,|` ,$$,,`"$$ .` :$|
b$| _m$`,:` :$1 ,` ,$Pm|` ` :$$,..;"' |$:
P$b, _;b$$b$1" |$$ ,` ,$$" ``' $$
```"```'" `"` `""` ""` ,P`
"As a general rule,don't solve puzzles that open portals to Hell"'
|
123
|
Locked
