Re: Lua Future (Was: Re: The ~)

[erik@... (Erik Hougaard)]

Luiz Henrique de Figueiredo wrote:
> That's ok.
> We'd still prefer that you called it Lua, of course, keeing the syntax intact,
> but you're free to do as you wish, as long as you comply with our requests set
> in the COPYRIGHT notice.
I do belive that I'm very complient to your copyright notice. I'm not
hiding the fact that its "based on" Lua so my users could go hunting for
Lua code to use in uCore - But there is not forum for Lua source - only
C source libraries etc. can be found ? Is this anything you have
considered ?

> >1. Binary Tree sorting on tables instead of hash. Or maybe some sort of
> >plugin system
> I don't understand. The language does not have hash -- it has tables, which
> up to now have been implemented as hash tables, in several diferent ways,
> without anyone being aware of it.

This is correctly a implementation request and not language change .. I
though that it would be rather cool to have a "plug-in" sorting/indexing
system for the tables. So people how need raw speed could use a hash
based system, but people how need some kind of sorting could use some
sort of tree system!

> >1. Case statement
> Probably not going to happen.

I know this one is very high on many peoples list.. A case statement is
very must used in business applications (such as mine) and without it,
some of the code seems a bit combersome cause the of many elseif in a
row.
 
> >1. Language constants - That would compile to values.
> What do you mean here? a=1+2 being changed to a=3?

That would be nice :-) but it more in the ShowWindow(Mycontrol,SW_HIDE)
where SW_HIDE is a constant that would get compiled to value. Right now
if people are going to implement a GUI (thoose bastards always have tons
of constants) they are going to reside in the global variable room and
cause they are constants why not eliminate then. In C this is done in
the preprocessor.
 
> >1. BCD support for embedded platforms without floating point.
> If your C compiler for an embedded platform supports BCD, then it should be
> simple to use it instead of doubles. Keep tuned for a LTN about using ints
> instead of doubles, coming soon :-)

Well I have Lua running with only INTs on my Coldfire board (In the
heart of my robot - pictures will be supplied later), but most embedded
C compilers do not natively support BCD and with embedded platforms the
choice of compileres is not big - Usually there is just couble per
platform (And they are tied together with In Circuit
Debuggers/downloaders/emulators etc.).
 
> That's right: Lua is Open Source but it's not an "Open Source" project,
> in the sense of several people contributing code. But then again you're free
> to take an existing implementation and starting your own "Open Source" project
> based on it. Actually, a different implementation of Lua would be great!

Well that would make a interesting project, as soon as uCore is out the
door :-) But with more implementations languages thend to either freeze
or seperate into different languages - look how the ML scene is very
seperated one the different implementations ;-( 

> We also need development tools, such as an IDE, including a debugger.
> The best compliment you could pay Lua would be to have such a project being
> run outside of TeCGraf, with no direct participation of the Lua team.
> We would still be very happy to answer any questions about Lua, of course.

Well I have been talking with the other guys, and maybe we could make
some sort of release of uCore. uCore is basicly a IDE for Lua with
debugger, database, network and all the stuff. The funny part is that
the uCore IDE is written in uCore itself (thereby Lua). We use uCore to
write a ERP pakage called uCore Financials. Lets see what the lawlers
think. I any case I will properly ask for beta testers on the list a
little later.

/Erik