implicit parameters

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

implicit parameters

John Belmonte-2
from Sol Diffs2Lua:

>>>
- Removed the implicit self parameter in function definitions of the
  special form function foo:bar(...)...end.  You have to name _all_
  arguments.

    function foo:bar(a,b,c) --> function foo:bar(self,a,b,c)
<<<

I have to agree with Edgar here.  What is the point of an implicit self in the parameter list
when in the function we have to spell out member variable accesses anyway?  It's like the
monster child of C++ and Python.

>>>
- Vararg syntax has changed.  Instead of ... that generates an
  automatic arg parameter you now have to write name[].  So a
  vararg function looks like this:

    function foo:bar(...) --> function foo:bar(self, arg[])
<<<

I like this too.  However maybe a syntax like the following is better since it can be backwards
compatible with Lua if you allow the name to be omitted:

    function foo(x, y, arg...)

-John



Reply | Threaded
Open this post in threaded view
|

Re: implicit parameters

Edgar Toernig
Hi,

John Belmonte wrote:
> >>>
> - Vararg syntax has changed.  Instead of ... that generates an
>   automatic arg parameter you now have to write name[].  So a
>   vararg function looks like this:
> 
>     function foo:bar(...) --> function foo:bar(self, arg[])
> <<<
> 
> I like this too.  However maybe a syntax like the following is
> better since it can be backwards compatible with Lua if you allow
> the name to be omitted:
> 
>     function foo(x, y, arg...)

I chose the arg[] form because of future changes.  The idea was
to make it valid in other places, too.  Mainly:

	local a,b,c[] = foo()

and

	foo(a,b,c[])

It basically becomes a pack/unpack operator.  And, I wanted to
reserve the dots (...) for an optimized version of that, namely
when you do not access the variable arguments but simply pass
them to other functions like this:

	function foo(x, y, ...)
		bar(x+y, ...)
	end

Here the varargs are really anonymous and, more important, it's
not necessary to create a real table!  Would greatly enhance the
performance of typical wrapper functions.

Ciao, ET.


Reply | Threaded
Open this post in threaded view
|

Re: implicit parameters

Nick Trout-2
In reply to this post by John Belmonte-2
>>>
- Removed the implicit self parameter in function definitions of the
  special form function foo:bar(...)...end.  You have to name _all_
  arguments.

    function foo:bar(a,b,c) --> function foo:bar(self,a,b,c)
<<<
>I have to agree with Edgar here.  What is the point of an implicit self in
the parameter list
when in the function we have to spell out member variable accesses anyway?
It's like the
monster child of C++ and Python.
>>>
- Vararg syntax has changed.  Instead of ... that generates an
  automatic arg parameter you now have to write name[].  So a
  vararg function looks like this:

    function foo:bar(...) --> function foo:bar(self, arg[])
<<<

I agree with both of the above! It stops people confusing a.b() and a:b() as
well I think which takes a bit of getting your head round. It makes the code
much clearer to read, ie. these "magical" variables doesnt appear from
nowhere :-) Its difficult to explain to novices why it appears in some
places and not others! As mentioned, Python uses this syntax. I keep going
back to Python as a reference language but thats because its really nice to
use and easy to maintain because of its clarity. You can just look at a
piece of code and not have to work out the context (ie. are we in a class,
do we have variable argument syntax...).

Have you though about adding augmented operators eg. +=, -= etc in Sol?

N




Reply | Threaded
Open this post in threaded view
|

Re: augmented operators (was: implicit parameters)

Edgar Toernig
Hi,

Nick Trout wrote:
> 
> Have you though about adding augmented operators eg. +=, -= etc in Sol?

I guess every C programmers comes to the point to think about
this ;-)  But I came to the same conclusion as the Lua team:
I do not plan to add them to Sol.  IMHO it's not worth the
trouble.

The only good thing an them is that it's a little bit shorter
to write.  On some occasions it may even be much shorter.  But
besides that it gives nearly nothing except a more complicated
system.  And some constructs would be just weird and give no
_obvious_ results (ie "a,b += c" is what?).

One may think that it could be faster to execute.  But it isn't
if you want the semantic of "a += b" is "a = a + b" (with "a"
evaluated only once).  There are two types of storage in Lua/Sol:
tables and locals.  For tables you have to perform the two
accesses to the table (read and write) because of possible tag-
methods (get/settable).  Nothing to optimize here.  Locals could
be optimized with a special instruction but again you have to
consider tag methods for "+" and that reduces the possible
optimization to <numlocvar>+=<num> [1].

One could try to make += and co special operators (ie "incr_by",
"mul_by", ...) with appropriate tag methods.  But that requires
references to objects and these only exist for tables, not for
locals.  (Btw, the same problem exists for "++" and "--".)
Beside that it would make the language more complicated.

Result: you would only get some very expensive syntactic sugar ;)

Ciao, ET.

[1] This case could be optimized even without the special
syntax.  But I think it won't be noticeable in any reasonable
application so I'm not trying to do this at the moment.  But
if somebody has a nice patch for this ...


Reply | Threaded
Open this post in threaded view
|

Re: augmented operators (was: implicit parameters)

Nick Trout-2
Nick Trout wrote:
>
> Have you though about adding augmented operators eg. +=, -= etc in Sol?
>>One may think that it could be faster to execute.  But it isn't
if you want the semantic of "a += b" is "a = a + b" (with "a"
evaluated only once).  There are two types of storage in Lua/Sol:
tables and locals.  For tables you have to perform the two
accesses to the table (read and write) because of possible tag-
methods (get/settable).  Nothing to optimize here.  Locals could
be optimized with a special instruction but again you have to
consider tag methods for "+" and that reduces the possible
optimization to <numlocvar>+=<num> [1].
One could try to make += and co special operators (ie "incr_by",
"mul_by", ...) with appropriate tag methods.  But that requires
references to objects and these only exist for tables, not for
locals.  (Btw, the same problem exists for "++" and "--".)
Beside that it would make the language more complicated.
>>Result: you would only get some very expensive syntactic sugar ;)

I hadnt really though about the tag methods complication. From your
description of the implementation I agree it would be quite complicated for
little gain. I had thought it might be faster, but not necessary so it
seems.

Cheers,
Nick.