Son of Lua - Sol

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

Son of Lua - Sol

Edgar Toernig
Hi,

wishes for coroutines have come up again lately.  So I thought
I make a first snapshot of Sol.  It's a heavily modified Lua
that contains coroutines, unified methods and a lot of other
things I wanted to try out.

It's far from finished yet.  Especially the documentation is
nearly non existent.  I wouldn't advise Sol to anyone who has
not at least some experience with Lua.  It's work in progress
and not debugged very well (ok, no _known_ bugs).  And, it's
incompatible with Lua.  It has some minor syntax changes, some
semantic differences, a changed C API, ...

This file http://froese.exit.de/sol/Diffs2Lua (and of course the
sources) is the only documentation available at the moment.

The snapshot is here: http://froese.exit.de/sol/sol-0.41.tar.gz

I've indented and renamed the source.  To let you see what was
changed in the code I've uploaded a version of Lua with only the
whitespace/renaming changes.  Diffs between this version and
the 0.41 version shows you what I've changed from Lua.  It's
here: http://froese.exit.de/sol/sol-0.4.tar.gz

The tarred version is #defed for coroutines (in src/scoro.h).
But that will only work on x86/linux.  The low level coroutine
support is in src/llcoro.[ch].  Good luck ;)

I do this just for fun.  I've no project (at the moment *g*) that
makes use of Sol.  It's just to try out things, see what can be
made better (IMHO of course ;) or different.  Ideas, discussion,
questions, comments, ... are really welcome.

Ciao, ET.


Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

John Belmonte-2
That's a lot of neat stuff, wish I had time to play with it...

It's also a lot of code to maintain.  Do you plan on tracking Lua releases?

-John


----- Original Message ----- 
From: "Edgar Toernig" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, January 31, 2001 11:14 AM
Subject: Son of Lua - Sol


> Hi,
> 
> wishes for coroutines have come up again lately.  So I thought
> I make a first snapshot of Sol.  It's a heavily modified Lua
> that contains coroutines, unified methods and a lot of other
> things I wanted to try out.



Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Russell Y. Webb
In reply to this post by Edgar Toernig
Cool stuff.  I've built alternate Luas too, though not as modified as yours.

The main thing I did was to make a 'global' keyword and make Lua default to
creating locals inside a function, of course read access to globals was
still there by default (in one version just for global functions):

b = 10
c = 1
function test(x) 
global c;
    b = "this does not change the global";
    c = "but this does";
    print(10); -- this uses the read access to globals
end

--Russ


Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Reuben Thomas-3
> The main thing I did was to make a 'global' keyword and make Lua default to
> creating locals inside a function, of course read access to globals was
> still there by default (in one version just for global functions):
>
> b = 10
> c = 1
> function test(x)
> global c;
>     b = "this does not change the global";
>     c = "but this does";
>     print(10); -- this uses the read access to globals
> end

I was wondering about doing this the other day; this is the sort of thing
I'd love to see too.

I'd not thought of the problem that you really want global functions to be
implicitly available, but not global variables, but of course there's no
difference between them in Lua (it's the type of the contents of the
variable, not that of the variable itself). Nasty...

-- 
http://sc3d.org/rrt/ | Caution Children At Play Drive Slowly


Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Russell Y. Webb
Making all globals read-only by default seemed like a good solution to me.
Then 'global x' gives you write access to the global.

Of course you can have a 'local' key word which then switches off write
access to a global.

Russ

> From: Reuben Thomas <[hidden email]>
> Reply-To: [hidden email]
> Date: Wed, 31 Jan 2001 10:22:19 +0000 (GMT)
> To: Multiple recipients of list <[hidden email]>
> Subject: Re: Son of Lua - Sol
> 
>> The main thing I did was to make a 'global' keyword and make Lua default to
>> creating locals inside a function, of course read access to globals was
>> still there by default (in one version just for global functions):
>> 
>> b = 10
>> c = 1
>> function test(x)
>> global c;
>> b = "this does not change the global";
>> c = "but this does";
>> print(10); -- this uses the read access to globals
>> end
> 
> I was wondering about doing this the other day; this is the sort of thing
> I'd love to see too.
> 
> I'd not thought of the problem that you really want global functions to be
> implicitly available, but not global variables, but of course there's no
> difference between them in Lua (it's the type of the contents of the
> variable, not that of the variable itself). Nasty...
> 
> -- 
> http://sc3d.org/rrt/ | Caution Children At Play Drive Slowly
> 


Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Edgar Toernig
In reply to this post by John Belmonte-2
John Belmonte wrote:
> 
> That's a lot of neat stuff, wish I had time to play with it...

Because my Playstation is breaking apart I have some time now *g*

> Do you plan on tracking Lua releases?

<joke>No.  I expect Lua to track Sol releases.</joke>

Well, I don't think that it's possible to apply all my changes to
newer versions of Lua.  But I'll try to incorporate important or
interesting changes back into Sol.

Ciao, ET.



Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Edgar Toernig
In reply to this post by Russell Y. Webb
Hi,

"Russell Y. Webb" wrote:
> 
> b = 10
> c = 1
> function test(x)
> global c;
>     b = "this does not change the global";
>     c = "but this does";
>     print(10); -- this uses the read access to globals
> end
> 

I thought about this myself.  But it complicates the parser a lot.
(Especially: a,b,c,d=foo4()  where a and d are new locals, b an old
local and c a global).  And you may get some strange semantics.  
Are your patches anywhere to have a look at?

Ciao, ET.



Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Russell Y. Webb
My patches were to 3.0 and not really extensively tested.  I had the luxury
of using Lex and Yak back then.

The trick was to do some conditional check upon write to globals and make
sure that write access was on for them.  If writing to globals is rare (as
it should be usually) then the performance hit was small.

Russ

> From: Edgar Toernig <[hidden email]>
> Reply-To: [hidden email]
> Date: Wed, 31 Jan 2001 21:15:51 +0100
> To: Multiple recipients of list <[hidden email]>
> Subject: Re: Son of Lua - Sol
> 
> Hi,
> 
> "Russell Y. Webb" wrote:
>> 
>> b = 10
>> c = 1
>> function test(x)
>> global c;
>> b = "this does not change the global";
>> c = "but this does";
>> print(10); -- this uses the read access to globals
>> end
>> 
> 
> I thought about this myself.  But it complicates the parser a lot.
> (Especially: a,b,c,d=foo4()  where a and d are new locals, b an old
> local and c a global).  And you may get some strange semantics.
> Are your patches anywhere to have a look at?
> 
> Ciao, ET.
> 
> 


Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Chris Tavares
In reply to this post by Edgar Toernig
Actually, the semantics here are identical to Python's - read goes to
"nearest" variable scope (local if there's a local value, global otherwise)
and writes go to local scope unless told otherwise.

Or am I misunderstanding how this works?

-Chris

----- Original Message -----
From: "Edgar Toernig" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Wednesday, January 31, 2001 12:15 PM
Subject: Re: Son of Lua - Sol


> Hi,
>
> "Russell Y. Webb" wrote:
> >
> > b = 10
> > c = 1
> > function test(x)
> > global c;
> >     b = "this does not change the global";
> >     c = "but this does";
> >     print(10); -- this uses the read access to globals
> > end
> >
>
> I thought about this myself.  But it complicates the parser a lot.
> (Especially: a,b,c,d=foo4()  where a and d are new locals, b an old
> local and c a global).  And you may get some strange semantics.
> Are your patches anywhere to have a look at?
>
> Ciao, ET.
>


Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

John Belmonte-2
In reply to this post by Edgar Toernig
Why do we have this restriction in Lua?  Shouldn't "function var(...)" just be sugar for "var =
function(...)"?

-John


>>>> From Sol "DIFFERENCES TO LUA 4.0"
- In a function definition the name may be an arbitrary sequence of names separated by '.' or
':'.

      function a.b.c() ... end

  (Lua allows only _one_ '.' or ':'.)
<<<<



Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Roberto Ierusalimschy
> Why do we have this restriction in Lua?  Shouldn't "function var(...)"
> just be sugar for "var = function(...)"?

It is too complicated to do the "full sugar". For instance, you can write

  foo(x,y,z).x = function (a,b,c) end

But if you try

  function foo(x,y,z).x (a,b,c)
  end

the parser would have a hard time to realize that (x,y,z) is not the
parameter list of the function.

With the options Lua gives you, you can always "factor out" the prefix
and use the sugar, like this:

  obj = foo(x,y,z)

  function obj.x (a,b,c)
  end

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

John Belmonte-2
Roberto Ierusalimschy wrote:
> But if you try
>
>   function foo(x,y,z).x (a,b,c)
>   end
>
> the parser would have a hard time to realize that (x,y,z) is not the
> parameter list of the function.

I don't need the full sugar (the embedded function call), just one more teaspoon to cover a very
common case:

    function mylib.MyClass:method() ... end

Let's try the "accepted syntax":

    -- oops, you can't do this!
    mylib.MyClass:method = function() ... end

So now we're down to:

    mylib.MyClass.method = function(self) end

Which makes it very hard to identify class members functions in your code, even with syntax
highlighting.  And you've lost the method definition sugar.

The "temp variable" workaround is the worst looking of all, and defeats trying to keep
everything inside mylib:

    local temp = mylib.MyClass
    function temp:method() ... end

Please consider Edgar's function definition extension for Lua.

Thanks,
-John



Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Eduardo Ochs-2
In reply to this post by Edgar Toernig
What about accepting the ugly stuff if it comes inside parentheses,
like in

    function (mylib.MyClass):method() ... end

contrasted to the problematic

    function mylib.MyClass:method() ... end

?

This isn't accepted right now, but I think that allowing it would be a
simple (and reasonably elegant) change and wouldn't break anything or
create any ambiguities.

Cheers,
  Eduardo Ochs
  http://angg.twu.net/
  http://www.mat.puc-rio.br/
  [hidden email]


John Belmonte wrote:
> I don't need the full sugar (the embedded function call), just one
> more teaspoon to cover a very common case:
>
>     function mylib.MyClass:method() ... end
>
> Let's try the "accepted syntax":
>
>     -- oops, you can't do this!
>     mylib.MyClass:method = function() ... end
>
> So now we're down to:
>
>     mylib.MyClass.method = function(self) end
>
> Which makes it very hard to identify class members functions in your
> code, even with syntax highlighting.  And you've lost the method
> definition sugar.
>
> The "temp variable" workaround is the worst looking of all, and
> defeats trying to keep everything inside mylib:
>
>     local temp = mylib.MyClass
>     function temp:method() ... end
>
> Please consider Edgar's function definition extension for Lua.

Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Roberto Ierusalimschy
> What about accepting the ugly stuff if it comes inside parentheses,
> like in
> 
>     function (mylib.MyClass):method() ... end
> 
> contrasted to the problematic
> 
>     function mylib.MyClass:method() ... end


This last form is not problematic. What is problematic is function calls. 
This solution with parentheses has the advantage that you can write 
anything inside it; the bad side is that you must put the parentheses. The 
"just-one-more-teaspoon" solution allows only more dots, but does someone 
needs more than that? Of course, we can have both! Allow multiple dots 
without parentheses, and just anything with them. But the point is: do
people really need this? Belmonte showed a real common case for multiple
dots. How frequent do we need to declare something like this?

  function a(x).foo (y) ... end


-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Edgar Toernig
In reply to this post by John Belmonte-2
John Belmonte wrote:
>     function mylib.MyClass:method() ... end
> 
> Let's try the "accepted syntax":
> 
>     -- oops, you can't do this!
>     mylib.MyClass:method = function() ... end
> 
> So now we're down to:
> 
>     mylib.MyClass.method = function(self) end

That was the main reason why I removed this "automatic" self.  The
other one was because of possible name collisions (btw the same reason
why I replaced the "..." with "name[]" - no magic locals anymore *g*).

> Please consider Edgar's function definition extension for Lua.

It was only one word to change (an if into a while).  And I see
no reason why it shouldn't be like that.  A similar simple change
was necessary for "x = (a or b)[foo]".

The other request like "function foo(x).y(...)" are IMHO too strange.
They cannot be parsed with an LL(n) parser (any fixed n) and are only
confusing to readers of the code (function foo(x).y:n(bar).z(baz)...).

Ciao, ET.



Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Edgar Toernig
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:
> 
> The
> "just-one-more-teaspoon" solution allows only more dots, but does someone
> needs more than that?

I don't think so.  But I'm not God ;)

> How frequent do we need to declare something like this?
> 
>   function a(x).foo (y) ... end

Beside the point that it looks ugly (so I don't want to need it *g*), do
you think it can even be implemented in a reasonable way?

Ciao, ET.


Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

John Belmonte-2
In reply to this post by Edgar Toernig
Edgar Toernig wrote:

> It was only one word to change (an if into a while).  And I see
> no reason why it shouldn't be like that.

Yeah I found this out myself and made a patch.  I chose to only allow the ':' token before the
last name because it's the only way that makes sense to me.  I will post the patch to
http://lua.swiki.net/5 shortly.

> The other request like "function foo(x).y(...)" are IMHO too strange.

I totally agree.  I'm trying my best to write readable (and hence maintainable) Lua code and
such constructs are quite the opposite.

-John



Reply | Threaded
Open this post in threaded view
|

Re: Son of Lua - Sol

Edgar Toernig
John Belmonte wrote:
> 
> Edgar Toernig wrote:
> 
> > It was only one word to change (an if into a while).  And I see
> > no reason why it shouldn't be like that.
> 
> Yeah I found this out myself and made a patch.  I chose to only allow
> the ':' token before the last name because it's the only way that makes
> sense to me.

Yes, for Lua a colon in the middle wouldn't make sense.  In Sol the colon
is a new operator with a special semantic in function calls and it makes
sense (a:b.c != a.b.c).

Ciao, ET.