suggestions for new version

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

suggestions for new version

Luiz Henrique de Figueiredo-2
We are planning a new version of Lua.
Any suggestions for improvements/corrections/etc.?
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

The Arrow
Maybe some kind of "search path" system for files "included" with dofile()?
Like the unix PATH, LD_LIBRARY_PATH and MANPATH environment variables.

/ Joachim
------------------------------------------------------------------------
  The Arrow              Arrow@Shadow World - mud.fukt.hk-r.se 4000

  Joachim Pileborg       Email: [hidden email]
  Tranbärsvägen 22:19    http://www.fukt.hk-r.se/~pilen/
  37238 Ronneby
  SWEDEN                 Cellular phone: 070-5189944
------------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

Francis Burton-2
In reply to this post by Luiz Henrique de Figueiredo-2
Though I'm not a language expert, I would say that Lua the language
is pretty much perfect -- at least, very difficult to change without
detracting from its elegant design, and probably breaking a whole load 
of existing code. What I personally would like to see is some GUI
library stuff, or examples of GUI-type constructs and projects done 
using Lua. At least, this is something I have in mind to do myself, if 
I can find the time.

Francis
-- 
Dr Francis L Burton,          |  [hidden email]
West Medical Building,        |
University of Glasgow,        |  Tel +44-141-330-6598
Glasgow, G12 8QQ, Scotland.   |  Fax +44-141-330-4612

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

Luiz Henrique de Figueiredo-2
In reply to this post by Luiz Henrique de Figueiredo-2
>Though I'm not a language expert, I would say that Lua the language
>is pretty much perfect -- at least, very difficult to change without

thanks!

>What I personally would like to see is some GUI library stuff

try tkLua. there's a link for it in Lua's home page.
--lhf

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

Mark Ian Barlow
In reply to this post by Luiz Henrique de Figueiredo-2
wish[1]  An efficient case selection structure would be nice, to avoid the
         overhead of long if-elseif...else-end constructs. I can do something
         similar (but not very efficient) now with:

           dostring(switch_list[selector])

         ...or with a table of functions which are used for their side-effects,
         but it would be hard for someone else reading the code to see what was
         happening; much better to localise the code at the point in the source
         where it is to be used.

         I presume it would be fairly easy for the compiler to plant a hidden
         jump table without requiring any new opcodes or anything.

         I'm not very bothered about having C's "fall-through" switch
         architecture, however. I'd happily give up typing 'break' at the
         end of cases and just accept an implicit and un-overrideable one.

         I don't really miss 'for' loops, but the above is an efficieny issue
         so I thought I'd raise it.

wish[2]  A hook into the raw uncompiled input before the lexer sees it, so I
         can use a regexp parser to add my own syntactic sugar for the "end
         user". I can see a use for this in providing meaningful operations
         on userdata, and it would fit in well with lua's policy regarding
         debugging: don't provide a pre-processor, just the hooks to allow
         one to be built.



Other minor things:

*  hex literals and bit-operators are useful if you are talking to hardware,
   but the operators would need a new fallback for the cases where casting
   a double to an int leads to loss of information (a 'range' fallback?).
   I've implemented the operators as functions (looks ugly) and patched
   "lex.c" manually to get the literals already, so _my_ vote goes to
   the form '#1234abcd' (case-insensitive), since that would give me
   *forwards* compatibility! ;-)

*  iolib lacks the converse of ascii(str), but it's trivial to write
   a C function for char(n).


That's just about all I can think of; I *like* the elegant terseness in
lua so I wouldn't want to see a great deal more...

-- 
Mark Ian Barlow                Non-Linear Control Consultants Ltd.
-----------------------------------------------------------------
[hidden email]            Voice / Fax: +44 (0)1207 562 154

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

John Fletcher
> Subject:       suggestions for new version

> We are planning a new version of Lua.
> Any suggestions for improvements/corrections/etc.?
> --lhf
> 
 
I am trying to build a persistent database and use numeric keys.  The 
standard persistent examples dump out as

mytable = {
1 = "something",
2 = "another one",
}

which won't read in again.  So I have to do

mytable = {}
mytable[1] = "something"
mytable[2] = "another one"

which breaks the sequence of actions.

Please supply a mechanism to easily make numeric keys persistent 
(even when mixed with non-numeric keys).

John Fletcher
---------------------------------------------------------------------
Dr John P. Fletcher          Tel: (44) 121 359 3611 ext 4625
Department of Chemical Engineering and Applied Chemistry (CEAC),
Aston University,            Fax: (44) 121 359 4094
Aston Triangle,              Email: [hidden email]
BIRMINGHAM B4 7ET  U.K.   
---------------------------------------------------------------------
CEAC Web site http://www.ceac.aston.ac.uk/
---------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: suggestions for new version

Roberto Ierusalimschy
In reply to this post by Mark Ian Barlow
> *  iolib lacks the converse of ascii(str), but it's trivial to write
>    a C function for char(n).
The "oficial" way to do that is:

   format('%c', n)

That is why the function "char" is not provided.

-- Roberto