Function definitions in table constructors

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

Function definitions in table constructors

Tim Hunter
Why does this work:

t = {
   f = function()
	    print("hello")
       end
}

But this doesn't?

t = {
   function f()
	print("hello")
   end
}



Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

steve donovan
A good question. Arguably the second form would be very useful for
class definitions. But table constructors currently only take values,
like the anonymous function in the first example.

steve d.

On Thu, Feb 21, 2008 at 3:30 AM, Tim Hunter <[hidden email]> wrote:
> Why does this work:
>
>  t = {
>     f = function()
>             print("hello")
>         end
>  }
>
>  But this doesn't?
>
>  t = {
>     function f()
>         print("hello")
>     end
>  }
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

Mark Meijer-2
I've been wondering the same thing, especially as "function foo()" is
just syntactic sugar for "foo = function()". But I'm guessing it has
something to do with how the parser is built.

I do think it would be nice to allow it. Given the fact that keywords
(such as "function") are not allowed as names (i.e. string keys using
the "table.key" or "table:key" syntax), I think it shouldn't be much
of a problem for the parser.


On 21/02/2008, steve donovan <[hidden email]> wrote:
> A good question. Arguably the second form would be very useful for
>  class definitions. But table constructors currently only take values,
>  like the anonymous function in the first example.
>
>  steve d.
>
>
>  On Thu, Feb 21, 2008 at 3:30 AM, Tim Hunter <[hidden email]> wrote:
>  > Why does this work:
>  >
>  >  t = {
>  >     f = function()
>  >             print("hello")
>  >         end
>  >  }
>  >
>  >  But this doesn't?
>  >
>  >  t = {
>  >     function f()
>  >         print("hello")
>  >     end
>  >  }
>  >
>  >
>  >
>

Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

Alex Davies
It's quite an easy change to the parser, see: http://lua-users.org/lists/lua-l/2008-01/msg00525.html

The patch is a little different though - for my oo system I prefer to have implicit selfs inside table functions, just look for the comment inside function "funcfield" to alter this behaviour. I think really it should be in the core, given that as original poster said it's supposed to be just syntactic sugar.

Oh, the patch also makes commas optional following an inline function.

- Alex

(P.S. my emails been really unreliable, this message didn't appear on the list hours ago when I first tried, so I'm really hoping I won't flood the list when whatever's causing the problem unclogs)

On Thu Feb 21 10:56 , 'Mark Meijer' <[hidden email]> sent:

I've been wondering the same thing, especially as "function foo()" is
just syntactic sugar for "foo = function()". But I'm guessing it has
something to do with how the parser is built.

I do think it would be nice to allow it. Given the fact that keywords
(such as "function") are not allowed as names (i.e. string keys using
the "table.key" or "table:key" syntax), I think it shouldn't be much
of a problem for the parser.

Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

Duncan Cross
On Thu, Feb 21, 2008 at 2:00 PM, Alex Davies <[hidden email]> wrote:
> It's quite an easy change to the parser, see:
>  http://lua-users.org/lists/lua-l/2008-01/msg00525.html
>
>  The patch is a little different though - for my oo system I prefer to have
>  implicit selfs inside table functions,

Perhaps the best solution would be to combine this with a second,
independent change that takes:

   function :anonmethod(a,b,c)
      ...
   end

as syntactic sugar for:

   anonmethod = function(self,a,b,c)
      ...
   end

so table-constructor methods have a lightweight syntax.

Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

Mark Hamburg-4
on 2/21/08 1:39 PM, Duncan Cross at [hidden email] wrote:

> On Thu, Feb 21, 2008 at 2:00 PM, Alex Davies <[hidden email]> wrote:
>> It's quite an easy change to the parser, see:
>>  http://lua-users.org/lists/lua-l/2008-01/msg00525.html
>> 
>>  The patch is a little different though - for my oo system I prefer to have
>>  implicit selfs inside table functions,
> 
> Perhaps the best solution would be to combine this with a second,
> independent change that takes:
> 
>    function :anonmethod(a,b,c)
>       ...
>    end
> 
> as syntactic sugar for:
> 
>    anonmethod = function(self,a,b,c)
>       ...
>    end
> 
> so table-constructor methods have a lightweight syntax.

But to really make it pay off one needs some way to also remove the need for
a comma after the end.

Mark



Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

Miles Bader-2
Mark Hamburg <[hidden email]> writes:
>> so table-constructor methods have a lightweight syntax.
>
> But to really make it pay off one needs some way to also remove the need for
> a comma after the end.

Yeah, I've always found the need for "," or ";" inside table
constructors inside tables annoying...  Do things become overly
ambiguous without them though?

-Miles

-- 
Selfish, adj. Devoid of consideration for the selfishness of others.

Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

Edgar Toernig
Miles Bader wrote:
>
> Mark Hamburg <[hidden email]> writes:
> >> so table-constructor methods have a lightweight syntax.
> >
> > But to really make it pay off one needs some way to also remove the need for
> > a comma after the end.
> 
> Yeah, I've always found the need for "," or ";" inside table
> constructors inside tables annoying...  Do things become overly
> ambiguous without them though?

I have that in my Lua dialect and there are some pitfalls but
I never stepped into one.  I usually use commas but omit them
when they are annoying, i.e. after function statements.
IMHO, if you can manage the different precedences of + and * you
can handle this, too.
 
Excerpt from http://goron.de/~froese/sol/Diffs2Lua

---snip---
      - Commas and semicolons are optional but may be used to
        avoid ambiguities.  There's no semantic difference
        between a comma and a semicolon.

            { a=1  b=2  c=3, d=4; e=5;,; 32 f, (1+2)*3 }

        Be careful when a field is followed by a string constant,
        a table constructor, or a parenthesized or negated
        expression:

            { f    "foo" }   vs   { f, "foo" }
            { {}   {} }      vs   { {}, {} }
            { a=1  (2+3) }   vs   { a=1, (2+3) }
            { a=1  -2 }      vs   { a=1, -2 }

        It's recommended to be not too economic with commas ;-)

      - Named functions may be used as rec-fields:

            {
              function foo() .... end
              function bar() .... end
            }
---snip---

Ciao, ET.

Reply | Threaded
Open this post in threaded view
|

Re: Function definitions in table constructors

Alex Davies
In reply to this post by Mark Hamburg-4
Although I haven't tested it, I believe this would make the function :method syntax work:

(Original almost-diff: http://lua-users.org/lists/lua-l/2008-01/msg00525.html)

static void funcfield (LexState *ls, struct ConsControl *cc) {
 FuncState *fs = ls->fs;
 int reg = fs->freereg;
 expdesc key, val;
 int rkkey;
+  int needself;
 checknext(ls, TK_FUNCTION);
+  needself = testnext(ls, ':');
 checkname(ls, &key);
 luaY_checklimit(fs, cc->nh, MAX_INT, "items in a constructor");
 cc->nh++;
 rkkey = luaK_exp2RK(fs, &key);
- body(ls, &val, 1 /* set to 0 to disable implicit self */, ls->linenumber);
+  body(ls, &val, needself, ls->linenumber);
luaK_codeABC(fs, OP_SETTABLE, cc->t->u.s.info, rkkey, luaK_exp2RK(fs, &val));
 fs->freereg = reg;
}

And commas can be made optional following inline functions without ambiguouity (the patch does indeed make them optional). They can't with the current means of declaring a function though:

tab = {
 field = (function() end) "test",
 field = function() end or function() end,
 etc = ...
}

- Alex

----- Original Message ----- From: "Mark Hamburg" <[hidden email]>
To: "Lua list" <[hidden email]>
Sent: Friday, February 22, 2008 7:07 AM
Subject: Re: Function definitions in table constructors


on 2/21/08 1:39 PM, Duncan Cross at [hidden email] wrote:

On Thu, Feb 21, 2008 at 2:00 PM, Alex Davies <[hidden email]> wrote:
It's quite an easy change to the parser, see:
 http://lua-users.org/lists/lua-l/2008-01/msg00525.html

The patch is a little different though - for my oo system I prefer to have
 implicit selfs inside table functions,

Perhaps the best solution would be to combine this with a second,
independent change that takes:

   function :anonmethod(a,b,c)
      ...
   end

as syntactic sugar for:

   anonmethod = function(self,a,b,c)
      ...
   end

so table-constructor methods have a lightweight syntax.

But to really make it pay off one needs some way to also remove the need for
a comma after the end.

Mark