Unicode

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

Re: language experimentation [was: co-routines]

Steve Dekorte-4
Nick Trout wrote:
> I think newsgroups are not quite as intimidating as mailing lists and you'll 
> probably get more traffic generated. You would probably get a broader range 
> of users creating input asking more varied questions? This would be be good 
> all round? 

One problem with a usenet group is that alot of folks(like myself) don't have
usenet access. Mailing list servers like mailman have usenet gateways though.
Maybe one could be set up for this list?

Steve

Reply | Threaded
Open this post in threaded view
|

Re: language experimentation [was: co-routines]

Luiz Henrique de Figueiredo
In reply to this post by Tom Wrensch
>One problem with a usenet group is that alot of folks(like myself) don't have
>usenet access.

Can't everyone read usenet news using DejaNews?
But then it would be a web interface and lua-l at eGroups would be easier.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: language experimentation [was: co-routines]

Steve Dekorte-4
Luiz Henrique de Figueiredo wrote:
> >One problem with a usenet group is that alot of folks(like myself) don't have 
> >usenet access. 
>  
> Can't everyone read usenet news using DejaNews? 
> But then it would be a web interface and lua-l at eGroups would be easier. 

Right. And I don't think either remembers which posts you've already seen.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Reuben Thomas-3
In reply to this post by Edgar Toernig
> Discussions are very difficult if you get no response...  I guess that
> most subscribers are programmers but there have been not very much
> discussions about new ideas and their implementation.  Pretty strange.

The majority of people on this list seem to be people with a pressing need
for a scripting language to embed. Also, they're using Lua as part of
their work.

Not so many who are looking at Lua for fun.

I am interested in language changes, but so far have been preoccupied with
my EPOC port, which has borne much fruit: AFAICS Lua has jumped from
nowhere to be the third most interesting (and possibly used) language on
EPOC.

I did look at the code a couple of days ago thinking about reversing local
and global default scope, but as yet I haven't got my head round it. I'm
interested in Sol to see the sort of techniques involved in changing
Lua; I understand that the local/global thing's already been done, along
with some other changes I like the sound of.

I'm quite happy to share ideas.

The main one I haven't seen on the list yet is making code first class. A
code block should be a table of statements, so instead of

do ... end

you write (in unsugared notation)

{ ... }

This allows code to be manipulated by programs. It should be kept in
compiled form (so I'm not quite sure how to deconstruct code, as in Lisp
or Smalltalk), and you could have a modification flag on tables so as not
to have to recompile them every time they are executed.

-- 
http://sc3d.org/rrt/ | maxim, n.  wisdom for fools


Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Alan Watson-4
> The main one I haven't seen on the list yet is making code first class. A
> code block should be a table of statements, so instead of
> 
> do ... end
> 
> you write (in unsugared notation)
> 
> { ... }
> 
> This allows code to be manipulated by programs. 

I think this can be accomplished this by keeping an array of
strings, modifying the strings as required, and then having
a "dotable" function that concatenates the strings and then
does a "dostring". It's not especially clean, but I think it
covers all you need. Am I missing something?

Regards,

Alan
-- 
Dr Alan Watson
Instituto de Astronomía UNAM

Reply | Threaded
Open this post in threaded view
|

Code representation - just musing

Adolf Mathias
Alan Watson wrote:
> 
> > The main one I haven't seen on the list yet is making code first class. A
> > code block should be a table of statements, so instead of
> >
> > do ... end
> >
> > you write (in unsugared notation)
> >
> > { ... }
> >
> > This allows code to be manipulated by programs.
> 
> I think this can be accomplished this by keeping an array of
> strings, modifying the strings as required, and then having
> a "dotable" function that concatenates the strings and then
> does a "dostring". It's not especially clean, but I think it
> covers all you need. Am I missing something?

Phantastic ideas - some of my thoughts

a block is either:
- a string containing Sol/Lua code
- a table containing a sequence of blocks
- a function application; how should that look?
- a table containing blocks whose results should be concatenated

I'm not quite sure whether a distinction between block and expression
needs to be maintained. There is none in Scheme/Lisp.

Regards,
  Dolfi

ot
Reply | Threaded
Open this post in threaded view
|

co-routines [was Re: Unicode]

ot
In reply to this post by Edgar Toernig
--- In lua-l@y..., Edgar Toernig <froese@g...> wrote:
> Discussions are very difficult if you get no response...  I guess 
that
> most subscribers are programmers but there have been not very much
> discussions about new ideas and their implementation.  Pretty 
strange.

I have been reading lua-l on egroups for about a year now, but  I 
decided to subscribe just to reply to this message.

The main reason I use lua is as a small, fast, embedded, C-callable 
scripting language. There are other languages I have evaluated for 
this purpose: Scheme (libscheme, UMBscheme and Tinyscheme), s-lang, 
Small (a C-alike), various small Forth implementations (FICL, 4th), 
and various small Basics (YABL, SmallBasic, Bywater Basic).

Small, Forth and Basic I discarded because they lacked enough 
variable types (notably floating point), and have limiting semantics. 
Scheme is my personal favourite, but implementations suffer from a 
lack of speed, plus the syntax is a problem from a maintenance and 
widespread useability viewpoint.  S-lang and Lua have easily 
learnable, conventional syntaxes. Lua wins out over s-lang because it 
is (a) very small and (b) has better semantics.

What I am *not* looking for is an everything-but-the-kitchen-sink 
language. That niche is already filled with the likes of Tcl, Perl, 
Python, Ruby, Pike etc, and turning Lua into such a language would be 
a tremendous duplication of effort.

I am also not looking for a language with cute, advanced features. 
Small extension languages rarely require them in practice: how often 
are continuations needed in scripts? R5RS Scheme is a fine language 
to experiment in; this is a very small niche indeed.

I am currently very satisfied with Lua 4.0; coroutines would be a 
welcome addition, and a little more support for modules and 
namespaces would be nice, but a lot of the extra syntactic sugar 
being proposed is IMHO simply not neccessary.

Cheers,
Elliott Oti


Reply | Threaded
Open this post in threaded view
|

Re: language experimentation [was: co-routines]

Magnus Lie Hetland
In reply to this post by Luiz Henrique de Figueiredo
> >One problem with a usenet group is that alot of
> >folks(like myself) don't have
> >usenet access.
> 
> Can't everyone read usenet news using DejaNews?
> But then it would be a web interface

Only for those who don't have access to usenet...
For those of us who *do*, the usenet solution is
definitely a plus. (At least for the ones of us
who like usenet :)

> and lua-l at eGroups would be easier.

I think that would be lua-l at yahoogroups as of
about a week ago... (No more egroups...)

> --lhf


--

  Magnus Lie Hetland      (magnus at hetland dot org)

 "Reality is what refuses to disappear when you stop
  believing in it"                 -- Philip K. Dick



Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Reuben Thomas-3
In reply to this post by ot
On Fri, 2 Feb 2001 [hidden email] wrote:

> I am currently very satisfied with Lua 4.0; coroutines would be a
> welcome addition, and a little more support for modules and
> namespaces would be nice, but a lot of the extra syntactic sugar
> being proposed is IMHO simply not neccessary.

Many of the proposals are more in the spirit of Scheme: they actually
simplify the semantics and syntax of Lua, rather than adding sugar. This is
certainly my own interest. In many cases, they also, commendably, don't lose
performance.

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


Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Reuben Thomas-3
In reply to this post by Alan Watson-4
On Thu, 1 Feb 2001, Alan Watson wrote:

> > The main one I haven't seen on the list yet is making code first class. A
> > code block should be a table of statements, so instead of
> >
> > do ... end
> >
> > you write (in unsugared notation)
> >
> > { ... }
> >
> > This allows code to be manipulated by programs.
>
> I think this can be accomplished this by keeping an array of
> strings, modifying the strings as required, and then having
> a "dotable" function that concatenates the strings and then
> does a "dostring". It's not especially clean, but I think it
> covers all you need. Am I missing something?

Just that I'm interested in making code first class, and having no
difference between code and tables.

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


Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Edgar Toernig
In reply to this post by Roberto Ierusalimschy
Wow.  First thanks very much for the detailed answer.

Roberto Ierusalimschy wrote:
> 
> > Could you be a little bit more specific?  Just some functions to save/set
> > L->stack & co and a registration for lock-callbacks on table-set/get?
> > Or something more sophisticated?  What about the GC?
> 
> We broke the lua_State in two structs; the lua_State itself has the
> thread-specific data, and it points to the other structure with the
> "global" data. There is only one new function (let us call it lua_newstack,
> we don't know the final name): the call lua_newstack(L, stacksize) returns
> a new lua_State sharing the global state with L. Actually, lua_open is now
> a macro lua_newstack(NULL, stacksize).

Sounds familiar :-)  I can't remember why I didn't follow that way but
at least one reason was, that it takes to GC passes to collect all data
from the threads (first to collect the userdata that holds the state and
another one for the objects used by that thread).  And it's slower.  But
not that obtrusive like the implementation in Sol-41 and much more ver-
satile.

I tried that in Sol-42 (same location).  I noticed two points:  you need
something to pass data from one state to another.  Your solution with
lua_ref(L1)/lua_getref(L2) is IMHO not correct.  You may raise an error
in the wrong state.  I made a sol_receivevalue(L, otherL, otherIndex)
to get objects from another (suspended) state.  That may only raise
errors in the current state.

Another point is that I have globals for each state.  At the moment
(with the standard API) it seems impossible to change globals for
other states without a new API function.

Btw, does it makes sense to have state-local hooks or/and a state-local
registry?

> About the locks: we considered the whole core of Lua as one single critical
> region (it is too complicated and too expensive to lock every single
> internal operation that can have impact in other threads). So all API
> functions have a pair of macros LUA_LOCK/LUA_UNLOCK around them. On the
> other side, whenever Lua calls C, in unlocks its core. So, unless you are
> in a closed loop completely inside Lua, you have plenty of opportunites to
> switch treads.

Sounds like the "Big Kernel Lock" in first Linux SMP kernels.  The problem
was that it scaled very bad.  Basically you limit the use of Lua to one
state at a time.  I guess, people not bothered by that could just as
easy use coroutines ;-)

Don't you think that a handful of locks could work?  Especially the stack
does not need a lock and I guess that's the most used location.
Hmm... even one lock for only L->gstate (my pointer to the global state)
could be possible/better?  (I have no pthread enabled system to test
any of this.)

I once hear about Windows, that dlls do this kind of locking by default
to protect them against other threads (only heard, not sure).  You wouldn't
even need the LUA_LOCK/UNLOCK for a Lua.dll.  I guess Windows-guys would
like your simple locking ;-)

Ciao and thanks again, ET.


Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Edgar Toernig
In reply to this post by Reuben Thomas-3
Reuben Thomas wrote:
> 
> Not so many who are looking at Lua for fun.

Oh, come on.  Programming is fun.  And Lua is for programers :-)

> The main one I haven't seen on the list yet is making code first class. A
> code block should be a table of statements, so instead of
> 
> do ... end
> 
> you write (in unsugared notation)
> 
> { ... }
> 
> This allows code to be manipulated by programs.

If I understand you right, you want to play with code like you can in
Lisp or Scheme?  Is that even reasonable for a language with syntax and
lexical semantics?  And by the way, I don't like self modifying code ;-)

Ciao, ET.



Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Steve Dekorte-4
In reply to this post by Roberto Ierusalimschy
> > > This allows code to be manipulated by programs. 

I'm very much interested in this as well.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Steve Dekorte-4
In reply to this post by Roberto Ierusalimschy
 Edgar Toernig wrote:
> If I understand you right, you want to play with code like you can in 
> Lisp or Scheme?  Is that even reasonable for a language with syntax and 
> lexical semantics?  And by the way, I don't like self modifying code ;-) 

You have code modifying code every time you edit a source file inside 
a text editing program - it's just linked to keyboard events.

There are important uses for having easier access to code at runtime. 
You could more easily create a graphical interface to programming lua code, 
for example. It would also greatly simply constructing class browsers and
other code visualization tools.

Steve

Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

John Belmonte-2
In reply to this post by Edgar Toernig
Edgar Toernig wrote:
> Reuben Thomas wrote:
> > This allows code to be manipulated by programs.
>
> If I understand you right, you want to play with code like you can in
> Lisp or Scheme?  Is that even reasonable for a language with syntax and
> lexical semantics?  And by the way, I don't like self modifying code ;-)

Self-modifying code seems scary to me (I think the last time I did it was on my Vic-20).
However being able to generate code from within a program is quite useful.  I'm using this now
to generate Lua code from a simple macro syntax suitable for script writers.

What Reuben wants to do is interesting, but possibly it can be implemented transparently with
existing (or slightly improved... subtle hint) extension facilities.

-John



Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Reuben Thomas-3
In reply to this post by Edgar Toernig
> > Not so many who are looking at Lua for fun.
>
> Oh, come on.  Programming is fun.  And Lua is for programers :-)

I like that!

> If I understand you right, you want to play with code like you can in
> Lisp or Scheme?  Is that even reasonable for a language with syntax and
> lexical semantics?  And by the way, I don't like self modifying code ;-)

The syntax bit is a good point. Dealing with while, for &c. is a little
awkward. Actually, I'm not exactly sure what I want, but I don't think I
want self-modifying code. However, I'd like to be able to interchange data
and code, e.g. think of function applications as much the same as
constructors, and assignments as the same as fields. So maybe I only want to
be able to modify simple statements, not blocks. I haven't really thought
through what I'd do with it yet; it just seemed that blocks could easily be
the same as tables, and that would remove another irregularity from Lua/Sol.

-- 
http://sc3d.org/rrt/ | perfect, a.  unsatirizable


Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Edgar Toernig
In reply to this post by Steve Dekorte-4
I guess he refers to my statement:
  And by the way, I don't like self modifying code ;-)

Steve Dekorte wrote:
>
> You have code modifying code every time you edit a source file inside
> a text editing program - it's just linked to keyboard events.

Yeah, but that's not self modifying code.  That's 'froese' modified code ;)
 
> There are important uses for having easier access to code at runtime.

Taking up your argumentation I could say: every piece of Lua code can
be represented as a string.  And Lua has string manipulation facilities *ig*

> You could more easily create a graphical interface to programming lua code,
> for example.

IMHO that's already possible.  And I don't think, that some code fiddling
features would help here.  You normally operate at a much higher level
than simple statements (framework of predefined data structures and
functions or a meta language).

> It would also greatly simply constructing class browsers and
> other code visualization tools.

And IMHO that requires either a language with very descriptive (and
restrict) data definition features (normally strong typed) or - for
more "free style" languages - a defined style to describe your data.
And this second method is always available.

Ciao, ET.



Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Edgar Toernig
In reply to this post by Reuben Thomas-3
Reuben Thomas wrote:
>
> So maybe I only want to
> be able to modify simple statements, not blocks. I haven't really thought
> through what I'd do with it yet; it just seemed that blocks could easily be
> the same as tables, and that would remove another irregularity from Lua/Sol.

I think, in these kind of language you simply have this irregularity.
Maybe you've been too long in the Lisp camp? ;)

If you really want something like that, what about this?

x = code[[ for i=1,$n do $body end  write"done\n"]]
x.n=5
x.body=code[[write(i)]]
x(foo)
-->12345done

This should be possible within Lua.

Ciao, ET.


PS: Btw, why does dostring rejects precompiled code at the moment?  Is it
considered too dangerous?  Afaics it should work.



Reply | Threaded
Open this post in threaded view
|

Re: co-routines [was Re: Unicode]

Edgar Toernig
In reply to this post by Edgar Toernig
I, Edgar Toernig wrote:
> 
> Hmm... even one lock for only L->gstate (my pointer to the global state)
> could be possible/better?

That was a quick shot.  Forget it.  It wouldn't protect the shared objects,
only the global state.

Ciao, ET.


Reply | Threaded
Open this post in threaded view
|

RTTI

Joshua Ritter
In reply to this post by Edgar Toernig
Ok.. I am pretty new to Lua...

I have an extensive RTTI information system built into my cpp class
hierarchy.  This includes the variables that make up the class (for
serialization primarily) and also the classes functions.. return
type/parameter types/ and a functor (function pointer) to the associated
function...

Following the example of how toLua generates bindings... I am teaching my
system to automatically bind these classes to Lua... it is working
fabulously...

I have run into a small snag however...

All function tags callback to the same static int luacallback(lua_State* ls)
function I have defined... what I need to get from here is:

A) the "class" of the table
B) the _name_ of the field (function)

so a table of "type" cpClass with a function called setName.. called from
Lua as:

class = cpClass:new()
class:setName("whewp")

would end up in the callback static int luacallback(lua_State* ls)

How do I get the cpClass and the setName here so I can match the arguments
and call the appropriate function?

Thanks!
-J



123