Next Version of Lua?

classic Classic list List threaded Threaded
143 messages Options
1 ... 345678
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Florian Weimer
* Roberto Ierusalimschy:

> Any comment about this?
>
>   http://lua-users.org/lists/lua-l/2005-09/msg00548.html

"until" could have been "break if", and the "repeat ... until exp"
could have been "repeat ... break if exp end", where "repeat ... end"
is an endless loop.

This is the way Ada addresses the scoping issue.  It hasn't got much
choice, though, because Ada blocks cannot contain variable
declarations, and the variable would be out of scope at the end of the
loop.  (Ada hasn't got "continue", either, but there's a "goto".
Looking at my small (by Ada standards) code base, I use goto for two
purposes: emulating "continue" in line-oriented parsers, and retrying
a computation from an exception handler.  "exit when" (the "break if"
equivalent) is much more common.)
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Roberto Ierusalimschy
> * Roberto Ierusalimschy:
>
> > Any comment about this?
> >
> >   http://lua-users.org/lists/lua-l/2005-09/msg00548.html
>
> "until" could have been "break if", and the "repeat ... until exp"
> could have been "repeat ... break if exp end", where "repeat ... end"
> is an endless loop.

It is, and that is the problem. If you have repeat + continue, it
becomes this:

  repeat ... continue ... break if exp; end

With this interpretation, the continue goes to the end of the loop,
bypassing the "break if exp". This is not what most people expect
from continue.

BTW, this is completely parallel with while, which may read
as "repeat break if not exp; ... end". But this intepretation has
no problems with continue.

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

Re: Next Version of Lua?

Florian Weimer
* Roberto Ierusalimschy:

>> * Roberto Ierusalimschy:
>>
>> > Any comment about this?
>> >
>> >   http://lua-users.org/lists/lua-l/2005-09/msg00548.html
>>
>> "until" could have been "break if", and the "repeat ... until exp"
>> could have been "repeat ... break if exp end", where "repeat ... end"
>> is an endless loop.
>
> It is, and that is the problem. If you have repeat + continue, it
> becomes this:
>
>   repeat ... continue ... break if exp; end
>
> With this interpretation, the continue goes to the end of the loop,
> bypassing the "break if exp". This is not what most people expect
> from continue.

Heh, nice catch.  Perhaps "continue" is simply not that useful with
loops where the exit condition is checked at the end.

Unfortunately, I avoid such loops in my coding (independently of the
language), so I haven't got example to check if it would be useful in
some cases at least.  (I use "continue" regularly in for and while
loops in other languages, FWIW.)

> BTW, this is completely parallel with while, which may read
> as "repeat break if not exp; ... end". But this intepretation has
> no problems with continue.

Oh, I still remember that when I first tried to implement "continue"
with a goto, I put the label at the beginning of the loop body, and
was surprised when it didn't work as expected.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Florian Weimer
In reply to this post by Olivier Hamel
* Olivier Hamel:

> Coroutines:
> * VM: Coco patch integration?

It's probably better to promote a coding style where a C function
which wants to support coroutine.yield puts its internal state on the
heap, so that it can resume computation later.  This is how coroutines
are often implemented on the JVM.

> Syntax:
> * Lexer Only: A continue statement is in dire need, I've found myself
> often wrapping large segments (read: rest of loop code) in a big
> if-then-end block because I couldn't do if-then-continue-end

I'm not sure if this is a real burden.  Local functions help a lot to
structure the code (if top performance is not a concern).

> The alternate suggestion of using ';' to elaborate when to use
> multiple returns might be better (feedback on this please?)?

I don't like how this breaks backwards compatibility in a very subtle
way.

> And that's all I can think of at the moment... I'll be sure to chip
> in anything else I can think of...

Some mechanism to hook into scope exit (to clean up resources) would
be very helpful.  But ask me in a year or two again, when I've written
more Lua code. 8-)
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Asko Kauppi
In reply to this post by Niklas Frykholm

Well... Do you think you can both eat and save the pie?  :/

Seriously, only the string type of the built-ins allows for variable  
length. If you don't want to grow Value, you'll need to do something  
similar to string. I bet it will make them immutable, as strings are.

So why not just use strings to store the 3D values?  As binaries.  
You'll make C side code to create them of course:

        local v= vec3d( 0.123, 1.234, 2.345 )
        print( v.x, v.y, v.z ) -- cannot be done since it's a string
        print( v ) -- would give binary garbage

And you cannot override add and sub and mul and... either.   Meaning  
you want userdata.

Case closed?  :))


Niklas Frykholm kirjoitti 11.6.2009 kello 12:30:

> Yes, that would work and wouldn't be too tricky. The drawback is that
> you would have to increase the size of the Value union to have room
> for the biggest value type you wanted to support. Support for Vector3
> would triple the size of Value and double the size of TValue. Which
> would mean close to doubling the memory footprint of a running lua
> application.
>
> I'm targetting game consoles, where increasing the script memory from
> 30 MB to 50 MB or even 40 MB is a big deal... so I can't really go
> that path.
>
> // Niklas
>
> 2009/6/10 Asko Kauppi <[hidden email]>:
>> About the complex type, LNUM patch allows all Lua numbers to be  
>> complex
>> (compile with LNUM_COMPLEX defined; C99 required for C complex  
>> support).
>>
>> The approach could of course be extended to making a native 3D vector
>> datatype, as well.
>>
>> -asko
>>
>>
>> Niklas Frykholm kirjoitti 10.6.2009 kello 17:42:
>>
>>> 2009/6/10 Duncan Cross <[hidden email]>:
>>>>
>>>> On Wed, Jun 10, 2009 at 2:55 PM, Niklas  
>>>> Frykholm<[hidden email]>
>>>> wrote:
>>>>>
>>>>> 2009/6/10 Olivier Hamel <[hidden email]>:
>>>>> Currently, if you want to create Complex or Vector3 type you  
>>>>> have to
>>>>> do it as a table or a userdata. And if you do a serious ammount of
>>>>> processing on them, the ammount of garbage generated by simple
>>>>> arithmetic operations will soon put a significant strain on the
>>>>> system. (You could use a pool of such objects, but that would mean
>>>>> resorting to manual memory management with all its pains -  
>>>>> especially
>>>>> when you are using it for something as simple as numbers.)
>>>>
>>>> Perhaps I am misunderstanding, but if the pool is a table that has
>>>> been set to have weak values (i.e. its metatable's __mode field  
>>>> is set
>>>> to 'v'), you should not have to do any manual memory management -
>>>> values that only exist in the pool will be eligible for garbage
>>>> collection.
>>>
>>> My description was a bit short, but the whole point of having a pool
>>> was to avoid generating garbage. (By using a free object from the
>>> pool, rather than creating a new one, whenever a new object is
>>> needed.) But this requires us to manually track which objects in the
>>> pool are free or not (i.e., manual memory management).
>>>
>>> If the objects in the pool are eligible for garbage collection, then
>>> the pool doesn't really buy us anything. We will generate the same
>>> ammount of garbage with the pool as without it.
>>>
>>> // Niklas
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

steve donovan
On Thu, Jun 11, 2009 at 6:19 PM, Asko Kauppi<[hidden email]> wrote:
>
> And you cannot override add and sub and mul and... either.   Meaning you
> want userdata.
>
> Case closed?  :))

Thinking about 3D vectors as objects, I'm sure a C++ application would
struggle with lots of tiny objects like that, and it would certainly
cause a lot of allocation churn unless some clever reusing was going
on.  Surely the userdata needed here is an _array_ of 3D vectors, to
efficiently handle the storage and processing of many vectors?

steve d.
Reply | Threaded
Open this post in threaded view
|

Next Version of Lua

Michael Newberry
In reply to this post by Florian Weimer
If you are taking suggestions for the next Lua release, mine would is that
it would be nice to have more detailed compiler messages.

For example, considering assignment instead of a test:

    a = 1
    if a = 1 then foo end

gives
    Error: Loading Module 'Script Document1': :2: `then' expected near `='

With some fonts, =  looks a lot like  ==.  If the test is complex, finding a
buried = can get hairy. Would it be possible to flag that as looking like
the programmer intended to do a test and accidentally did an assignment?

Here's another one:

    `=' expected near `ot'

is thrown by

    ifn ot CMyClass then

OK, I know this is obvious, but this one sometimes gets tough if you have
the right combination of characters.

There are plenty more examples where a more sophisticated error message
would be a great help.

Thanks,

Michael

Reply | Threaded
Open this post in threaded view
|

2D/3D vectors (Re: Next Version of Lua?)

Asko Kauppi
In reply to this post by steve donovan

steve donovan kirjoitti 11.6.2009 kello 19:29:

> On Thu, Jun 11, 2009 at 6:19 PM, Asko Kauppi<[hidden email]>  
> wrote:
>>
>> And you cannot override add and sub and mul and... either.    
>> Meaning you
>> want userdata.
>>
>> Case closed?  :))
>
> Thinking about 3D vectors as objects, I'm sure a C++ application would
> struggle with lots of tiny objects like that, and it would certainly
> cause a lot of allocation churn unless some clever reusing was going
> on.  Surely the userdata needed here is an _array_ of 3D vectors, to
> efficiently handle the storage and processing of many vectors?
>
> steve d.

This brings to mind the way I solved it for FMI's server (a separate  
mail today).

A Matrix2D object keeps internally two references to Matrix objects (x  
and y). This makes the "array of float" be the only needed  
abstraction, and others are derived from it.

The approach has many implied benefits, s.a. avoidance of C++ copy  
constructors in many cases (we can push a new reference to the .x part  
since its already a Lua object). Also, optimized arithmetic operations  
(SSE code) can be applied to Matrix2D without any rewrite.

-asko


Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Petite Abeille
In reply to this post by Philippe Lhoste

On Jun 11, 2009, at 12:30 PM, Philippe Lhoste wrote:

> Perhaps I am abnormal, but I use both continue and do ... while (or  
> repeat ... until) in languages that allow them. Not necessarily  
> together...

Perhaps I'm abnormal as well, but at least in Lua, I tend to avoid  
while/repeat/break/etc and instead favor 'for' loop with a custom  
iterator that "does the right thing" (sm)...

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? - Bitwise Ops & Enum/Flags

Olivier Hamel
In reply to this post by Jim Mellander

Jim Mellander wrote:

> My 2nd favorite language (awk as implemented in gawk), which also uses a
> double as the numeric type, takes the following tack when doing bitwise ops:
>
> "For all of these functions, first the double-precision floating-point
> value is converted to the widest C unsigned integer type, then the
> bitwise operation is performed. If the result cannot be represented
> exactly as a C double, leading nonzero bits are removed one by one until
> it can be represented exactly. The result is then converted back into a
> C double. (If you don't understand this paragraph, don't worry about it.)"
>
> from http://www.gnu.org/manual/gawk/html_node/Bitwise-Functions.html
>  
That would be the behavior I'd expect from a bitwise-aware-Lua.
> Philippe Lhoste <[hidden email]>
>
> Why?
>
> Indeed, they are useful to combine flags (DS_MODALFRAME | DS_3DLOOK | DS_FIXEDSYS |
> WS_POPUP | WS_CAPTION | WS_SYSMENU) but also to get R, G, B, A components out of a RGBA
> number and to parse some binary file formats, for small bit maps, and so on.
This brings up 2 good points. (Please keep in mind I'm writing from a
game dev PoV.)

1 - Enumerations:

Enumerations are something that could be either done in Lua, or in the
VM (Faster/Prettier).

Lua example:

-- More on this typecheck thing in another message I'll send after this,
though you should be able to guess easily what I mean
local function typecheck(varUnknown, strTypeName)
    <snip snip, check the type to insure it matches the expected type>
    <if not matching then an error /w require 'C-Lua' styled message
else just bail out>
end

local HackEnumCntr = 0 -- Hack enumeration incremental counter

function enum(strEnumSetName, tblEnumList)
    typecheck(strEnumSetName, "string")
    typecheck(tblEnumList, "table")
   
    for k, v in ipairs(tblEnumList) do
        HackEnumCntr = HackEnumCntr + 1
        _G[k] = 2^HackEnumCntr -- Figure something for handling over
overflows?
        -- Is it even a possible concern? Never was in my experience...
    end
end

enum("Test", {"Div", "Multi", "Add", "Sub", "Exp", "Assign", "Call"}) --
Create the set

Note that it's not permitted to do:

enum "Test"
{
    "Div",
    "Multi",
    "Add",
    "Sub",
    "Assign",
    "Call"
}

And most certainly not (unless you added some clever metatables to the
env table and recorded the order & keys):

enum Test
{
    Div,
    Multi,
    Add,
    Sub,
    Assign,
    Call
}

As for an example in the VM, that's a bit too involved an implementation
to do just for a discussion, though it would make sense to put them
where high speed access is possible (registry? might cause problems...)
and give them incremental powers of two. This could be reset to zero for
each new set (safer, less likely to overflow if you have a ridiculous
number of them), or kept global (more susceptible to overflows, but all
enums are unique, even from other sets).

I'm not sure this is a good idea to make this a vanilla Lua VM feature,
because that would involve a new keyword. (And if I had a choice between
adding an enum keyword and a continue keyword, I'd pick continue!)


2 - Bitwise Ops:

As Philippe was so kind to point out, though flags using bitwise-or-ing
is a nice feature, it would be more beneficial to have full bitwise ops
for numbers. Data processing directly in Lua of what is usually
manipulated only by C/compiled languages is of interest to quite a few
people I'd believe, myself included. Jim have an account of how (g)awk
handles bitwise ops which was basically what I'd envisioned for Lua
bitwise ops.


Important Note - Avoiding the Swiss Army Chainsaw:

That said, the Lua authors do have an (very) valid interest in keeping
Lua from becoming another chainsaw (or so this is the reason I gather
behind being careful of adding things on a whim).

Enumerations/Flags are two things that could be kept from vanilla Lua,
since I don't know how important such a feature would be to other users
of the language and it it's a rather 'loud' thing to add, since:
1. It's a syntax similar to table construction
2. It introduces another (pseudo?) structure-ish entity to the language
3. It doesn't benefit the language as a whole, it's more a  
(multiple-?)domain specific feature

However bitwise ops are important to mos people (everyone?) who do any
sort of in-depth data-comm/handling with C/compiled languages, since it
allows us to implement/develop/prototype algorithm in Lua. It also
allows us to handle C data more effectively as well (Philippe's bitmaps,
for example, and binary formats too). Although it could be done with
bitlib (Lua-side), I don't think Philippe (or myself) would be happy
manipulating tiny datums with lots of table ops (if you loop at bitlib
it uses a lot of tables behind the scene, but it does produce correct
results, it's not very nice when you're trying to keep GC cycles to a
minimum too).

Olivier

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? - Bitwise Ops & Enum/Flags

Olivier Hamel
Olivier Hamel wrote:

> Note that it's not permitted to do:
>
> enum "Test"
> {
>    "Div",
>    "Multi",
>    "Add",
>    "Sub",
>    "Assign",
>    "Call"
> }
Gah! I'm an idiot, Sorry! Here:

function enum(strEnumSetName, tblEnumList)
    typecheck(strEnumSetName, "string")
    typecheck(tblEnumList, "table")
    return function()
        for k, v in ipairs(tblEnumList) do
           HackEnumCntr = HackEnumCntr + 1
          _G[k] = 2^HackEnumCntr -- Figure something for handling over
overflows?
           -- Is it even a possible concern? Never was in my experience...
        end
    end
end

Olivier
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? - Bitwise Ops & Enum/Flags

Henk Boom-2
2009/6/11 Olivier Hamel <[hidden email]>:

> Olivier Hamel wrote:
>>
>> Note that it's not permitted to do:
>>
>> enum "Test"
>> {
>>   "Div",
>>   "Multi",
>>   "Add",
>>   "Sub",
>>   "Assign",
>>   "Call"
>> }
>
> Gah! I'm an idiot, Sorry! Here:
>
> function enum(strEnumSetName, tblEnumList)
>   typecheck(strEnumSetName, "string")
>   typecheck(tblEnumList, "table")
>   return function()
>       for k, v in ipairs(tblEnumList) do
>          HackEnumCntr = HackEnumCntr + 1
>         _G[k] = 2^HackEnumCntr -- Figure something for handling over
> overflows?
>          -- Is it even a possible concern? Never was in my experience...
>       end
>   end
> end

I'm guessing you meant to move "tblEnumList" into the internal
function's args, right?

function enum(strEnumSetName)
  typecheck(strEnumSetName, "string")
  typecheck(tblEnumList, "table")
  return function(tblEnumList)
      for k, v in ipairs(tblEnumList) do
         HackEnumCntr = HackEnumCntr + 1
        _G[k] = 2^HackEnumCntr -- Figure something for handling over
overflows?
         -- Is it even a possible concern? Never was in my experience...
      end
  end
end
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua

David Manura
In reply to this post by Michael Newberry
On Thu, Jun 11, 2009 at 12:45 PM, Michael Newberry wrote:
> it would be nice to have more detailed compiler messages.
> For example, considering assignment instead of a test:
>
>   a = 1
>   if a = 1 then foo end
>
> gives
>   Error: Loading Module 'Script Document1': :2: `then' expected near `='

The error does make sense in a way.  "a" forms a complete expression.
"if <exp>" should be followed by "then".

But you are correct in that the problem almost certainly lies with an
incorrect expression rather than the "then".  Here's a patch:

--- lua-5.1.4/src/lparser.c
+++ lua-5.1.4-better-errors/src/lparser.c
@@ -1132,6 +1132,8 @@
   int condexit;
   luaX_next(ls);  /* skip IF or ELSEIF */
   condexit = cond(ls);
+  if (ls->t.token == '=')
+    error_expected(ls, TK_EQ);
   checknext(ls, TK_THEN);
   block(ls);  /* `then' part */
   return condexit;

Example:

  if a = 1 then print() end
  --> stdin:1: '==' expected near '='

> Here's another one:
>
>   `=' expected near `ot'
>
> is thrown by
>
>   ifn ot CMyClass then

That form is more difficult in general.  Unless the compiler guesses
than "ifn" really means "if", then it instead sees something
equivalent to "a b c then", just with different letters.  "a b c then"
is interpreted as a statement.  It is a statement that starts with a
primary expression "a" (i.e. lparser.c:exprstat).  That primary
expression is not followed by a comma, so it can't be an expression
list in an assignment (i.e. lparser.c:assignment).  Neither is it a
function call.  The only thing left is an assignment, but it can't be
that either since the primary expression is not followed by "=".  It
only reports not seeing "=".

You might do this patch on assignments:

--- lua-5.1.4/src/lparser.c
+++ lua-5.1.4-better-errors-2/src/lparser.c
@@ -944,7 +944,12 @@
   }
   else {  /* assignment -> `=' explist1 */
     int nexps;
-    checknext(ls, '=');
+    if (ls->t.token != '=') {
+      luaX_syntaxerror(ls,
+        luaO_pushfstring(ls->L, LUA_QL(",") ", " LUA_QL("(") ", or "
+                                LUA_QL("=") " expected"));
+    }
+    luaX_next(ls);
     nexps = explist1(ls, &e);
     if (nexps != nvars) {
       adjust_assign(ls, nvars, nexps, &e);

Example:

  ifn ot CMyClass then print() end
  --> stdin:1: ',', '(', or '=' expected near 'ot'

though I suspect it's now more fragile (less locality) if you later
want to patch Lua with some syntax extension.  Perhaps your extension
will allow some other token to following prefix expressions, and you
are expected to remember to fix the above code in the assignment
function accordingly.

Going further with patching,

@@ -1225,6 +1230,13 @@
   /* stat -> func | assignment */
   FuncState *fs = ls->fs;
   struct LHS_assign v;
+  luaX_lookahead(ls);
+  if (ls->t.token == TK_NAME && ls->lookahead.token == TK_NAME &&
+      ls->t.seminfo.ts->tsv.len > 2 &&
+      strstr(getstr(ls->t.seminfo.ts), "if") == getstr(ls->t.seminfo.ts)
+  ) {
+    luaX_syntaxerror(ls, "did you mean 'if'?");
+  }
   primaryexp(ls, &v.v);
   if (v.v.k == VCALL)  /* stat -> func */
     SETARG_C(getcode(fs, &v.v), 1);  /* call statement uses no results */

gives something like you want:

  ifn ot CMyClass then print() end
  --> stdin:1: did you mean 'if'? near 'ot'

Maybe the better solution, to avoid spaghetti code is to backtrack on
syntax errors, assign probabilities to error messages, and report the
errors in decreasing order of probability.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (__iter metamethod)

David Manura
In reply to this post by Luiz Henrique de Figueiredo
On Wed, Jun 10, 2009 at 8:10 AM, John Hind wrote:
> Could I push my luck by asking if there is a position on '__iter'?

What's your opinion about this?

  for k,v in obj:it() do
    ...
  end
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

David Manura
In reply to this post by Mark Hamburg
On Wed, Jun 10, 2009 at 4:08 PM,  wrote:
> Still it would be good to provide better support for ... in more contexts
> barring conflicts with existing syntax so that the quadratic tendencies of
> select could be minimized.

Previous discussions:

  http://lua-users.org/lists/lua-l/2008-04/msg00205.html
  http://lua-users.org/lists/lua-l/2006-04/msg00120.html

I do, however, question why #... and #(...) and also ...[i] and
(...)[i] necessarily must have the same meaning given that f(...) and
f((...)) have different meanings.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (__setindex metamethod)

David Manura
In reply to this post by Mark Hamburg
On Wed, Jun 10, 2009 at 11:34 AM, Mark Hamburg wrote:
> With regard to __setindex ...

Something I haven't been entirely comfortable with metatables is how
they don't completely virtualize indexing.  You have an index and then
you have a raw index.  Some operations index their arguments; others
raw index.  The proposed __pairs/__ipairs/__len (__next?) in 5.2
overcome some problems though.
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Mark Hamburg
In reply to this post by David Manura
On Jun 11, 2009, at 8:27 PM, David Manura wrote:

> On Wed, Jun 10, 2009 at 4:08 PM,  wrote:
>> Still it would be good to provide better support for ... in more  
>> contexts
>> barring conflicts with existing syntax so that the quadratic  
>> tendencies of
>> select could be minimized.
>
> Previous discussions:
>
>  http://lua-users.org/lists/lua-l/2008-04/msg00205.html
>  http://lua-users.org/lists/lua-l/2006-04/msg00120.html
>
> I do, however, question why #... and #(...) and also ...[i] and
> (...)[i] necessarily must have the same meaning given that f(...) and
> f((...)) have different meanings.

Yes, it's been a pet bugaboo for me. Even if for realistic numbers of  
arguments the quadratic complexity doesn't bite one, I feel dirty  
writing such code knowing it's there and on the other hand knowing  
that the linear algorithms carry extra cost is again annoying because  
it means that in the realistic case, they actually are less efficient  
(though not by much).

I should probably just get over it (one way or the other).

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua?

Mark Hamburg
On Jun 11, 2009, at 9:13 PM, Mark Hamburg wrote:

> I should probably just get over it (one way or the other).

My real key wishes for the next version of Lua probably center around  
easier data privacy and encapsulation through things like keys that  
are guaranteed to be skipped by the pairs iterator.

Well, that and method currying (obj:method not followed by a parameter  
list yields a function that calls method on object) and support for  
obj:[ method ]() as a way to call a dynamically identified method on  
an object. I should go try writing a patch for the latter since I  
think it's a relatively isolated change to syntax and code generation.

Unlike some who rebel against the colon syntax, I think we should just  
embrace it as the standard way to do message sends in Lua.

Mark

Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua

Patrick Donnelly
In reply to this post by David Manura
Hi David,

On Thu, Jun 11, 2009 at 8:58 PM, David Manura<[hidden email]> wrote:

> On Thu, Jun 11, 2009 at 12:45 PM, Michael Newberry wrote:
>> it would be nice to have more detailed compiler messages.
>> For example, considering assignment instead of a test:
>>
>>   a = 1
>>   if a = 1 then foo end
>>
>> gives
>>   Error: Loading Module 'Script Document1': :2: `then' expected near `='
>
> The error does make sense in a way.  "a" forms a complete expression.
> "if <exp>" should be followed by "then".
>
> But you are correct in that the problem almost certainly lies with an
> incorrect expression rather than the "then".  Here's a patch:
>
> --- lua-5.1.4/src/lparser.c
> +++ lua-5.1.4-better-errors/src/lparser.c
> @@ -1132,6 +1132,8 @@
>   int condexit;
>   luaX_next(ls);  /* skip IF or ELSEIF */
>   condexit = cond(ls);
> +  if (ls->t.token == '=')
> +    error_expected(ls, TK_EQ);
>   checknext(ls, TK_THEN);
>   block(ls);  /* `then' part */
>   return condexit;
>
> Example:
>
>  if a = 1 then print() end
>  --> stdin:1: '==' expected near '='

I don't agree with this because it implies that Lua only expects the
'==' token after 'a'. I think that could be more confusing.

--
-Patrick Donnelly

"Let all men know thee, but no man know thee thoroughly: Men freely
ford that see the shallows."

- Benjamin Franklin
Reply | Threaded
Open this post in threaded view
|

Re: Next Version of Lua? (__iter metamethod)

steve donovan
In reply to this post by David Manura
On Fri, Jun 12, 2009 at 5:12 AM, David Manura<[hidden email]> wrote:
>  for k,v in obj:it() do
>    ...
>  end

For Penlight, I've standardized on this for all collection classes.
Although list:iter() currently just runs over the values, not the
keys, whereas map:iter() goes over the key/value pairs, which could be
a suprise.
1 ... 345678