Lua is about to become history

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

Lua is about to become history

Luiz Henrique de Figueiredo
Our paper on the evolution of Lua has been accepted for presentation
at HOPL III, the third ACM Conference on the History of Programming
Languages!

The current version of the paper is available at
        http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf

For the final version, the committee has asked for more historical detail.
So, it's time to draw on the community's collective memory! If you have
any comments on the paper, specially something that we have missed or
misrepresented in our account, please drop us a line or post here.
All comments are welcome.

Thank you very much. We hope to see you in San Diego in 2007.
(HOPL III will be part of FCRC 2007. See http://www.acm.org/fcrc/ .
Perhaps we can have a Lua Workshop 2007 there as well...)
--lhf
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Bret Victor
Luiz Henrique de Figueiredo <lhf <at> tecgraf.puc-rio.br> writes:

> The current version of the paper is available at
> http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf

I thought of a couple additions which might be interesting
to readers.

Section 7.1, first paragraph:

> We have resisted user pressure for including other data
> structures, mainly ‘real’ arrays and tuples, first by being
> stubborn, but also by providing tables with an efficient
> implementation and a flexible design.

You might want to mention that userdata can be used to
implement arbitrary low-level data structures with a
transparent interface, as a further example of Lua's
extensibility.

Section 7.1, fifth paragraph:

> Since its first version Lua has had “real” users, that is,
> users others than ourselves, who care not about the
> language itself but only about how to use it productively.
> Users have always given important contributions to the
> language, through suggestions, complaints, use reports,
> and questions.

You might want to mention (if it's actually true!) that Lua
has experienced more backwards-incompatible changes
than most languages as it evolved, and that its current
simplicity and elegance owe a lot to having discarded
cruft as better ideas came along.  You can discuss why
the Lua userbase is tolerant of backwards-incompatibility:
that an interpreter is typically embedded into apps, that
the userbase is relatively small and enthusiastic, etc.

-Bret


Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

John Belmonte
In reply to this post by Luiz Henrique de Figueiredo
Luiz wrote:
> For the final version, the committee has asked for more historical detail.
> So, it's time to draw on the community's collective memory! If you have
> any comments on the paper, specially something that we have missed or
> misrepresented in our account, please drop us a line or post here.
> All comments are welcome.

Skimming the paper I didn't notice it mentioned, but you might say
something about how the Lua global scope has evolved from a special case
with separate meta-mechanisms to yet another use of tables (see
<http://lua-users.org/lists/lua-l/2000-04/msg00079.html> where I made
the case for this).

--John
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Daniel Collins
In reply to this post by Luiz Henrique de Figueiredo
> Skimming the paper I didn't notice it mentioned, but you
> might say something about how the Lua global scope has
> evolved from a special case with separate meta-mechanisms to yet
another use of tables > (see <http://lua-users.org/lists/lua-l/2000->
04/msg00079.html>
> where I made the case for this).

It's already in there :-) Halfway through page 14, section "6.2 Tables":
"Lua 4.0 introduced the table of globals, which is an ordinary Lua table
that can
be manipulated like any other table."

I read the whole thing this morning. The only suggestions I could come
up with are a couple of minor grammatical corrections which I will email
directly.

- DC

Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Peter Sommerfeld-4
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo wrote
> If you have any comments on the paper, specially
> something that we have missed or misrepresented
> in our account, please drop us a line or post
> here. All comments are welcome.

It should be more emphasized that the interpreter
can easily be adjusted to the requirements of users
or different platforms: using Integers, C++ exceptions,
stripped down versions etc.

My 2 Cents

Peter


Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

David Burgess
Luas evolution and success is in part due to the sustained
responsiveness of the Lua team to reported bugs and defiencies.
>From my perspective, the Lua team take a "hunt and destroy"
approach to bugs. This responsiveness and the resultant stability,
encourages users of Lua to report their problems, which in turn
creates a better more stable product. (This is a circular argument).

Whilst it is mentioned in the document, one cannot overstate the
importance of the Lua teams resistance to adding feature for the sake
of feature. The decison processes of Roberto, Luiz et al are, in hindsight,
pretty good.

DB

 Luiz Henrique de Figueiredo wrote
> ... All comments are welcome.
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Thatcher Ulrich
In reply to this post by Luiz Henrique de Figueiredo
Very nice!  I'm flattered to be credited in the coroutines section!

I think it should be noted that my yield patch was based on some
advice from Bret Mogilefsky, in an email he sent to the Lua mailing
list on 8 Sep 1997.  I found his original message here:
http://lua-users.org/lists/lua-l/1997-09/msg00004.html, and then a
more explicit roadmap here:
http://lua-users.org/lists/lua-l/2000-10/msg00187.html

-T

On 4/30/06, Luiz Henrique de Figueiredo <[hidden email]> wrote:

> Our paper on the evolution of Lua has been accepted for presentation
> at HOPL III, the third ACM Conference on the History of Programming
> Languages!
>
> The current version of the paper is available at
>         http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf
>
> For the final version, the committee has asked for more historical detail.
> So, it's time to draw on the community's collective memory! If you have
> any comments on the paper, specially something that we have missed or
> misrepresented in our account, please drop us a line or post here.
> All comments are welcome.
>
> Thank you very much. We hope to see you in San Diego in 2007.
> (HOPL III will be part of FCRC 2007. See http://www.acm.org/fcrc/ .
> Perhaps we can have a Lua Workshop 2007 there as well...)
> --lhf
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Reuben Thomas-5
In reply to this post by John Belmonte
"[Lua] now supports extensible semantics, anonymous functions, full
lexical closures, proper tail recursion, and coroutines".

Curiously, this list of features is what many languages are proud of
adding as they evolve. It sounds like "Lua started off as a quick hack
with interesting features a, b, and c but has now added all the usual
features of Lisp." You could phrase it alternatively: "Lua now has all
the features expected from a modern dynamic language, as well as
refining its own distinctive features".

--
http://rrt.sc3d.org/ | frog, n.  a prince waiting for the right kiss
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

John D. Ramsdell-2
In reply to this post by Luiz Henrique de Figueiredo
> From: Bret Victor <[hidden email]>
...
> You might want to mention (if it's actually true!) that Lua
> has experienced more backwards-incompatible changes
> than most languages as it evolved, and that its current
> simplicity and elegance owe a lot to having discarded
> cruft as better ideas came along.  You can discuss why
> the Lua userbase is tolerant of backwards-incompatibility:
> that an interpreter is typically embedded into apps, that
> the userbase is relatively small and enthusiastic, etc.

Bret,

I think you have to be very careful about making this case.  How
tolerant of backwards-incompatibility do you thing the Lua user base
would be if the Lua authors modernized the language to support
zero-based array and string indexing?  The greater difficulty of
writing correct code using one-based array indexing was obvious to all
when Fortran and C were two of the few major languages available, and
the lesson was not lost by the designers of the current popular
languages, such as Python.  But at this stage, do you really think
that wart can be fixed?

John
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Reuben Thomas-5
On Wed, 3 May 2006, John D. Ramsdell wrote:

> I think you have to be very careful about making this case.  How
> tolerant of backwards-incompatibility do you thing the Lua user base
> would be if the Lua authors modernized the language to support
> zero-based array and string indexing?  The greater difficulty of
> writing correct code using one-based array indexing was obvious to all
> when Fortran and C were two of the few major languages available, and
> the lesson was not lost by the designers of the current popular
> languages, such as Python.  But at this stage, do you really think
> that wart can be fixed?

Icon and Lua both demonstrate the benefit of 1-based indexing over
0-based: the ability to count forward from the start of a string and
backwards from the end symmetrically: 1 points to (just before) the
first character and -1 to (just before) the last. Hence, 0 points to
the end of the string, which seems a little odd, but if you use
zero-based addressing, you can no longer point to the end of the string.

There's another argument about whether you point at characters or the
gaps between them: if you insist on pointing at characters, you lose the
property

   string.len(string.sub(s, a, b)) == b - a

for a, b of the same sign (and you STILL can't point at the end of a
string!).

It's not at all clear to me that 1-based indexing is inherently worse.
It gets you into trouble when you mix arrays and pointers, but who does
that nowadays? APL, a language whose numerical properties are most
carefully thought out, defaults to 1-based.

--
http://rrt.sc3d.org/ | Floc: an egregiously good aperitif
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Chris Marrin
Reuben Thomas wrote:

> On Wed, 3 May 2006, John D. Ramsdell wrote:
>
>> I think you have to be very careful about making this case.  How
>> tolerant of backwards-incompatibility do you thing the Lua user base
>> would be if the Lua authors modernized the language to support
>> zero-based array and string indexing?  The greater difficulty of
>> writing correct code using one-based array indexing was obvious to all
>> when Fortran and C were two of the few major languages available, and
>> the lesson was not lost by the designers of the current popular
>> languages, such as Python.  But at this stage, do you really think
>> that wart can be fixed?
>
>
> Icon and Lua both demonstrate the benefit of 1-based indexing over
> 0-based: the ability to count forward from the start of a string and
> backwards from the end symmetrically: 1 points to (just before) the
> first character and -1 to (just before) the last. Hence, 0 points to the
> end of the string, which seems a little odd, but if you use zero-based
> addressing, you can no longer point to the end of the string.
>
> There's another argument about whether you point at characters or the
> gaps between them: if you insist on pointing at characters, you lose the
> property
>
>   string.len(string.sub(s, a, b)) == b - a
>
> for a, b of the same sign (and you STILL can't point at the end of a
> string!).
>
> It's not at all clear to me that 1-based indexing is inherently worse.
> It gets you into trouble when you mix arrays and pointers, but who does
> that nowadays? APL, a language whose numerical properties are most
> carefully thought out, defaults to 1-based.
>

Please lets not start this religious war. The only important thing to
note here is that Lua is NOT an inherantly 1-based language. I use 0
based arrays all the time. I even occasionally create arrays that start
at -3 or 7. The only part of the language that cares about this is in
the construction of numerically indexed table literals, whose first
element is placed at one. Neither 0 nor 1 based arrays are better or
worse. You just need to understand the language constructs and use them
correctly.

--
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"'
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Francis Burton
In reply to this post by Luiz Henrique de Figueiredo
Luiz Henrique de Figueiredo <lhf <at> tecgraf.puc-rio.br> wrotes:
> The current version of the paper is available at
> http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf

"The Evolution of Lua"

Evolution? Hmmm. Some would call it Intelligent Design! :-)

Francis

Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Boyko Bantchev
In reply to this post by Reuben Thomas-5
On 5/3/06, Reuben Thomas <[hidden email]> wrote:
> Icon and Lua both demonstrate the benefit of 1-based indexing over
> 0-based: the ability to count forward from the start of a string and
> backwards from the end symmetrically: 1 points to (just before) the
> first character and -1 to (just before) the last. Hence, 0 points to
> the end of the string, which seems a little odd, but if you use
> zero-based addressing, you can no longer point to the end of the string.

Actually you can.  Consider a string or array of four elements,
e.g. "ABCD":

  A   B   C   D        the string
0   1   2   3   4      forward indexing
-5  -4  -3  -2  -1     backward indexing


All you lose is the `symmetry' of counting, which is
questionable in the 1-based variant anyway.  Why is it
questionable?  When you go backwards, `before' should
mean `after', and `pointing just before' should be
`pointing just after' a character.  In these terms, with
1-based indexing forward and 0-based backward,
1 points to (just before) the first character while -1
points to (just after) the last but one.
Besides, the very fact of using the 0 -- be it for
forward or for backward indexing -- destroys symmetry:
(negatives ballance with positives, 0 stands for itself).
True symmetry is chimeric here, regardles of 0/1-based
indexing.

> There's another argument about whether you point at characters or the
> gaps between them: if you insist on pointing at characters, you lose the
> property
>
>   string.len(string.sub(s, a, b)) == b - a
>
> for a, b of the same sign ...

Pointing at the gaps suggests half-open ranges
(one end is included, the other is excluded), and so,
to the extent half-open ranges suggest 0-based
indexing, your argument actually supports 0-based
indexing :)

> APL, a language whose numerical properties are most
> carefully thought out, defaults to 1-based.

APL allows for both 1-based and 0-based indexing.
Its modern successors, J and K, however, both use
0-based only.

Cheers,
  Boyko
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Reuben Thomas-5
On Wed, 3 May 2006, Boyko Bantchev wrote:

> Besides, the very fact of using the 0 -- be it for
> forward or for backward indexing -- destroys symmetry:
> (negatives ballance with positives, 0 stands for itself).
> True symmetry is chimeric here, regardles of 0/1-based
> indexing.

With floating-point or sign-bit arithmetic, you can use +/-0!

--
http://rrt.sc3d.org/ | art, n.  romanticized mundanity
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Mark Hamburg-4
In reply to this post by Reuben Thomas-5
on 5/3/06 2:42 AM, Reuben Thomas at [hidden email] wrote:

> "[Lua] now supports extensible semantics, anonymous functions, full
> lexical closures, proper tail recursion, and coroutines".
>
> Curiously, this list of features is what many languages are proud of
> adding as they evolve. It sounds like "Lua started off as a quick hack
> with interesting features a, b, and c but has now added all the usual
> features of Lisp." You could phrase it alternatively: "Lua now has all
> the features expected from a modern dynamic language, as well as
> refining its own distinctive features".

Paul Graham made a remark to the effect that all languages attempt to turn
themselves into LISP as they evolve.

As for the 0 v 1 debate, it may be worth calling some attention to in the
history since it is a moderately controversial choice. As for the "correct"
answer, on the one hand Dijkstra made remarks to the effect of expecting
that everyone knows you should start counting at zero. On the other hand,
most real world enumerations start with one rather than zero. Counting from
zero generally labels one as a geek. Probably the greatest issue with the
choice is that for a language that is frequently embedded within C and C++
programs, it requires a mental translation for programmers switching back
and forth and introduces design questions when bridging data structures
between the worlds.

Mark

Reply | Threaded
Open this post in threaded view
|

OT: Re: Lua is about to become history

Diego Nehab-3
In reply to this post by Reuben Thomas-5
Hi,

>> Besides, the very fact of using the 0 -- be it for
>> forward or for backward indexing -- destroys symmetry:
>> (negatives ballance with positives, 0 stands for itself).
>> True symmetry is chimeric here, regardles of 0/1-based
>> indexing.
>
> With floating-point or sign-bit arithmetic, you can use +/-0!

This might be the first time in history that someone
found a good use for +/-0... :)

[]s,
Diego.
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Michael Newberry
In reply to this post by Mark Hamburg-4
Regarding counting from 0 or 1, I would offer a data point with regard to
users / customers: Over the course of years, our users who are engineers and
scientists, but not software developers, gave us feedback about this. They
wanted things to start at 1. Internally, our C++ code always worked with
0-based collections and so we "naturally" reported results in this way.
However we found that the user base was generally far happier with results
reported as starting at 1.

Michael

----- Original Message -----
From: "Mark Hamburg" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Wednesday, May 03, 2006 9:31 AM
Subject: Re: Lua is about to become history


> on 5/3/06 2:42 AM, Reuben Thomas at [hidden email] wrote:
>
>> "[Lua] now supports extensible semantics, anonymous functions, full
>> lexical closures, proper tail recursion, and coroutines".
>>
>> Curiously, this list of features is what many languages are proud of
>> adding as they evolve. It sounds like "Lua started off as a quick hack
>> with interesting features a, b, and c but has now added all the usual
>> features of Lisp." You could phrase it alternatively: "Lua now has all
>> the features expected from a modern dynamic language, as well as
>> refining its own distinctive features".
>
> Paul Graham made a remark to the effect that all languages attempt to turn
> themselves into LISP as they evolve.
>
> As for the 0 v 1 debate, it may be worth calling some attention to in the
> history since it is a moderately controversial choice. As for the
> "correct"
> answer, on the one hand Dijkstra made remarks to the effect of expecting
> that everyone knows you should start counting at zero. On the other hand,
> most real world enumerations start with one rather than zero. Counting
> from
> zero generally labels one as a geek. Probably the greatest issue with the
> choice is that for a language that is frequently embedded within C and C++
> programs, it requires a mental translation for programmers switching back
> and forth and introduces design questions when bridging data structures
> between the worlds.
>
> Mark
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Roberto Ierusalimschy
In reply to this post by Mark Hamburg-4
> Paul Graham made a remark to the effect that all languages attempt to turn
> themselves into LISP as they evolve.

I guess he really thinks so; but it is not true :)

"Original" Lisp had no lexical closures, no pattern matching, no
coroutines (or threads or continuations, for that matter), no API to
other languages, no exception handling, no module system, and I think it
did not require proper tail calls.  (What it had always excelled was in
"extensible semantis", aka macros.)

-- Roberto
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Reuben Thomas-5
In reply to this post by Chris Marrin
On Wed, 3 May 2006, Chris Marrin wrote:

> The only important thing to note here is that Lua is NOT an inherantly
> 1-based language.

That relies on pedantry: the string library IS inherently 1-based.

> I use 0 based arrays all the time.

This is an interesting point, though since non-positive numbers never
get into the array part of a table, there's a performance bias towards
1-based arrays.

--
http://rrt.sc3d.org/ | certain, a.  insufficiently analysed
Reply | Threaded
Open this post in threaded view
|

Re: Lua is about to become history

Norman Ramsey-2
In reply to this post by Roberto Ierusalimschy
 > > Paul Graham made a remark to the effect that all languages attempt to turn
 > > themselves into LISP as they evolve.
 >
 > I guess he really thinks so; but it is not true :)
 >
 > "Original" Lisp had no lexical closures, no pattern matching, no
 > coroutines (or threads or continuations, for that matter), no API to
 > other languages, no exception handling, no module system, and I think it
 > did not require proper tail calls.  (What it had always excelled was in
 > "extensible semantis", aka macros.)

Hurrah!  I've never liked that bit of parochialism and am happy to see
it debunked.  (Though I do think parallel evolution of languages,
e.g., in acquiring lexical closures, is a fascinating phenomenon.)

Now, to get really off topic, what shall we do about 'every program
evolves until it is powerful enough to read mail'? :-)


Norman
12