Features you would like to see

classic Classic list List threaded Threaded
114 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Features you would like to see

Patrick Donnelly-3
I'm curious what features people would like to see added to Lua.
Generally I'm content with the way things are. But there are some
things...

I'd like to see some sort of "default" value for function arguments
added. Something along the lines of:

function foo(a or 5)
  ...
end;

I wouldn't be very afraid of problems from passing nil or false to
such a function, as you wouldn't have a default value if you might
expect that as an argument. Yes I realize you can just have: function
foo(a or 5) a = a or 5; ... end;. Syntactic sugar maybe?

I'd like to see some sort of table.hole value for table arrays. I know
this has been talked about a lot.

What features would you like to see added?

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

David Manura
Patrick Donnelly writes:
> I'm curious what features people would like to see added to Lua.

See http://lua-users.org/wiki/FeatureProposals .

Some of my own favorites include

 http://lua-users.org/wiki/ResourceAcquisitionIsInitialization
   (RAII or scope guards to more effectively solve some cleanup problems)
 http://lua-users.org/wiki/LuaModuleFunctionCritiqued
   (modules should not touch global variables)
 http://lua-users.org/wiki/StatementsInExpressions
   (e.g. the "let" syntax)
 http://lua-users.org/wiki/LuaVirtualization
   (e.g. __len, __pairs, and other metamethods on tables)

Possibly also: macros (in the LISP sense).

> I'd like to see some sort of "default" value for function arguments
> added. Something along the lines of:
> 
> function foo(a or 5)
>   ...
> end;
> ..... a = a or 5; ... end;. Syntactic sugar maybe?

Function argument processing involves a lot of things, including type and range
checking for named and positional elements.  I think the above might add more
complexity to the language but only address one special case.

> I'd like to see some sort of table.hole value for table arrays.

I think the more fundamental issue is in the limited expressibility of varargs
in the absence of tables -- http://lua-users.org/wiki/VarargTheSecondClassCitizen



Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Rob Kendrick
In reply to this post by Patrick Donnelly-3
Patrick Donnelly wrote:
I'd like to see some sort of "default" value for function arguments
added. Something along the lines of:

function foo(a or 5)
  ...
end;

I'm not sure it's worth complicating the compiler for this, given you
can do a = a or 5.

I suspect this could be done reasonably easily using token filters.
Perhaps Daniel or Asko will curry one up for us.

What features would you like to see added?

There isn't a lot that I want that can't be emulated in another way.
For example, something I find quite useful is array slicing:

 a = { 1, 2, 3, 4, 5 }
 two, three, four = a[2..4]

But this can easily be done with a simple function, such as this naive
example:

 function slice(t, s, e)
   local r = {}
   for i = s, e do
	r[#r+1] = t[i]
   end
   return unpack(r)
 end

 two, three, four = slice(a, 2, 4)

Or perhaps even:

 a.slice = slice
 two, three, four = a:slice(2, 4)

B.


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Stephen Kellett
In reply to this post by Patrick Donnelly-3
Patrick Donnelly wrote:
I'm curious what features people would like to see added to Lua.

This comment is from the perspective of a software tool developer. In that context I am talking about inspecting Lua internals and Lua objects from C.

I'd like to see the ability to actually get a class name for a class object. Currently when you query an object for its type (from C) you just get "Table", which is not very useful. Its much more useful to know that a "Weeble" object is possibly leaking (look there are 10,000 of the critters!) rather than noticing the Table count has increased by 10,000.

I was talking with Bob Pappas from Adobe(*) yesterday (we were talking about the Lua Memory Validator product I am involved with) and this issue came up - he had lots of Table objects but we couldn't tell which class/type each object was. It limits the info you can get from a tool like Lua Memory Validator (or any tools like it, not that I am aware of any others for Lua).

Cheers

Stephen
(*) Sorry the name dropping but I've mentioned this because it did happen and it shows that big names are using Lua and interested in issues such as this.

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Rob Kendrick
Stephen Kellett wrote:

I'd like to see the ability to actually get a class name for a class object. Currently when you query an object for its type (from C) you just get "Table", which is not very useful. Its much more useful to know that a "Weeble" object is possibly leaking (look there are 10,000 of the critters!) rather than noticing the Table count has increased by 10,000.

Isn't the usual way of solving this problem to keep a mapping in the registry between the meta-table and type name?

B.


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Stephen Kellett
Rob Kendrick wrote:
Stephen Kellett wrote:

I'd like to see the ability to actually get a class name for a class object. Currently when you query an object for its type (from C) you just get "Table", which is not very useful. Its much more useful to know that a "Weeble" object is possibly leaking (look there are 10,000 of the critters!) rather than noticing the Table count has increased by 10,000.

Isn't the usual way of solving this problem to keep a mapping in the registry between the meta-table and type name?

I don't know. I'm not the most skilled Lua user going. I know a fair bit about Lua internals (and various other scripting languages) but I'm not that experienced at actually using Lua (most of my work is in C++ and assembly).

How would I check that from C?

Now that you've pointed me in direction I'll get out Roberto's book and have a read about Tables and the registry.

Stephen

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Duncan Cross
Take a look at the auxiliary library functions luaL_newmetatable and
luaL_getmetatable. First call luaL_newmetatable with the name of your
class in the initialization of your program, then luaL_getmetatable
(note its entirely separate functionality to lua_getmetatable) with
the class name whenever you need it. Internally these functions are
creating and using the registry mapping, but you shouldn't need to
understand all that to use them (though it would probably be useful
anyway).

On 8/17/07, Stephen Kellett <[hidden email]> wrote:
> Rob Kendrick wrote:
> > Stephen Kellett wrote:
> >
> >> I'd like to see the ability to actually get a class name for a class
> >> object. Currently when you query an object for its type (from C) you
> >> just get "Table", which is not very useful. Its much more useful to
> >> know that a "Weeble" object is possibly leaking (look there are 10,000
> >> of the critters!) rather than noticing the Table count has increased
> >> by 10,000.
> >
> > Isn't the usual way of solving this problem to keep a mapping in the
> > registry between the meta-table and type name?
>
> I don't know. I'm not the most skilled Lua user going. I know a fair bit
> about Lua internals (and various other scripting languages) but I'm not
> that experienced at actually using Lua (most of my work is in C++ and
> assembly).
>
> How would I check that from C?
>
> Now that you've pointed me in direction I'll get out Roberto's book and
> have a read about Tables and the registry.
>
> Stephen
>

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Fabien-3
In reply to this post by Rob Kendrick

There isn't a lot that I want that can't be emulated in another way.
For example, something I find quite useful is array slicing:

  a = { 1, 2, 3, 4, 5 }
  two, three, four = a[2..4]

You might like metalua's "clist" macro, which adds lists by comprehension and slicing, letting you write stuff like:

-{extension "clist"
}
-- integers from 2 to 50, by steps of 2:
x = { i for i = 2, 50, 2 }

-- the same, obtained by filtering over all integers <= 50:
y = { i for i = 1, 50 if i%2== 0 }

-- prime numbers, implemented in an inefficient way:
local sieve, n = { i for i=2, 100 }, 1
while n < #sieve do
sieve = {
i for i in values(sieve[1 ... n]);
i for i in values(sieve[n+1 ... #sieve]) if i%sieve[n] ~= 0 }
n += 1
end
table.print(sieve) 
Notice that "..." is used rather than "..": the former would cause plenty of mess with concatenation, especially when concatenation is overloaded by metatables.

As for the "function(x or 5)" syntax, it could be implemented roughly that way (naive, dirty, untested code):
mlp.func_val = gg.sequence{

"(", gg.list{ gg.sequence{ mlp.expr, gg.onkeyword { "or", mlp.expr } },
terminators = ")", separators = "," }, ")", mlp.block, "end",
builder = func_val_builder }
function func_val_builder(x)
   local params, body = unpack(x)
   for i, p in pairs(params) do
      assert(p[1].tag=='Id' or p[1].tag=='Dots' and i==#params,
             "Function parameters must be identifiers or a final vararg")
      if p[2] then
         assert(p[1].tag=='Id', "No default allowed for vararg")
         local var, default = unpack(p)
         table.insert(body, 1, +{ (-{var}) = -{var} or -{default} })
      end
   end
   return `Function{
{ p[1] for _, p in pairs(params) }, body }
end

Notice also that this hack is non-composing: other macros overloading the function definition parser would break it, and you'd better think twice before doing such a dangerous thing. My personal feeling is that this syntax sugar is not helpful enough to justify a brittle extension. Generally speaking, such monkey patching of mlp should only be done in very special situations, and should trigger your design smell detector.

-- Fabien.
Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Thomas Lauer-3
In reply to this post by Patrick Donnelly-3
"Patrick Donnelly" <[hidden email]> wrote:

> What features would you like to see added?

* an optional mode (similar to a C/C++ #pragma?) that requires *all*
  variables, local and global, to be explicitly declared

* a full and orthogonal set of metamethods and raw... functions
  (already beaten to death elsewhere)

* continue (alas, that requires changing repeat ... until semantics)

* a standardised way to set and query metadata for userdata, tables and
  classes (along the lines of what Stephen mentioned)

* breaking out of nested loops

* function module() could do with some tightening

* ...

Mainly, it's global variables springing into existence when you least
expect them. Most of the rest is indeed sugar: for such a small language
Lua is amazingly full-featured.

-- 
cheers  thomasl

web : http://thomaslauer.com/start


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Roberto Ierusalimschy
In reply to this post by Rob Kendrick
> But this can easily be done with a simple function, such as this naive
> example:
> 
>  function slice(t, s, e)
>    local r = {}
>    for i = s, e do
> 	r[#r+1] = t[i]
>    end
>    return unpack(r)
>  end

An easier implementation:

  slice = unpack

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Roberto Ierusalimschy
In reply to this post by Thomas Lauer-3
> > What features would you like to see added?
> 
> * an optional mode (similar to a C/C++ #pragma?) that requires *all*
>   variables, local and global, to be explicitly declared

Have you tried the 'strict' module?

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Steve Heller
In reply to this post by Patrick Donnelly-3
On Thu, 16 Aug 2007 23:06:32 -0600, "Patrick Donnelly"
<[hidden email]> wrote:

>I'm curious what features people would like to see added to Lua.
>Generally I'm content with the way things are. But there are some
>things...

Type declarations, including declarations for a (specific)
user-defined type. This would have to be ptional, of course, but with
a switch to make them required. This is pretty much the only
significant thing that a language like C++ has that Lua doesn't have
(other than a modest difference in performance), and the lack of it
makes large-scale programming in Lua much more difficult and
uncertain.

Steve


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

David Given
In reply to this post by Patrick Donnelly-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Donnelly wrote:
[...]
> What features would you like to see added?

I'd like a goto.

The whole goto-considered-harmful myth has done the world a vast disservice.
goto is *entirely* the right construct for dealing with certain software
problems: for example, state machines. (And, in fact, Dijkstra was completely
up front about this in his original paper.) They're also very handy for doing
things like cleanup on error:

	if not function1() then
		goto exit
	end
	if not function2() then
		goto cleanup1_and_exit
	end
	if not function3() then
		goto cleanup2_and_exit
	end
	return success

	cleanup3()
cleanup2_and_exit:
	cleanup2()
cleanup1_and_exit:
	cleanup1()
	return failure

The alternative approach is to use lots of nested if statements, which can
quickly get out of control if your logic is at all complicated --- and if you
need an exit strategy from within, say, a loop, you're basically stuffed. You
have to either duplicate code or use flag variables.

(They can also be trivially used for 'continue' and multi-level 'break'.)

...and while I'm whinging, it would also be nice to have some
try/catch/finally/throw syntactic sugar around pcall and error. I know it's
Not The Lua Way to provide high-level functionality like that, but exceptions
are so useful, and doing them yourself with pcall is so wordy, that I reckon
it's worth doing in this case.

- --
âââ ïïïïïïïïïïïïïï âââ http://www.cowlark.com âââââââââââââââââââ
â
â "There does not now, nor will there ever, exist a programming language in
â which it is the least bit hard to write bad programs." --- Flon's Axiom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxZ14f9E0noFvlzgRAvhBAJ9x8IcZm9vnUTJ6hlJo11W0C7723wCeLNaU
RUSmsCHdCwuKC357y04HTeY=
=KcSr
-----END PGP SIGNATURE-----



Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Rob Kendrick
In reply to this post by Roberto Ierusalimschy
Roberto Ierusalimschy wrote:

An easier implementation:

  slice = unpack

Aha. I didn't realise unpack took such arguments. You learn something every day.

B.

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Javier Guerra Giraldez
In reply to this post by Thomas Lauer-3
On Friday 17 August 2007, Thomas Lauer wrote:
> * continue (alas, that requires changing repeat ... until semantics)

so far, this is the only suggestion i'd really like


-- 
Javier

Attachment: pgpbDY_79Mdsr.pgp
Description: PGP signature

Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Thomas Lauer-3
In reply to this post by Roberto Ierusalimschy
[hidden email] (Roberto Ierusalimschy) wrote:

> > * an optional mode (similar to a C/C++ #pragma?) that requires *all*
> >   variables, local and global, to be explicitly declared
> 
> Have you tried the 'strict' module?

Sure and it certainly helps. But 'strict' is sort of checking for
globals through the (metatable) backdoor. I'd much prefer the compiler
complaining rather than having runtime checks do all the work.

-- 
cheers  thomasl

web : http://thomaslauer.com/start


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Steve Heller
In reply to this post by Steve Heller
On Fri, 17 Aug 2007 08:05:55 -0500, Steve Heller
<[hidden email]> wrote:

>On Thu, 16 Aug 2007 23:06:32 -0600, "Patrick Donnelly"
><[hidden email]> wrote:
>
>>I'm curious what features people would like to see added to Lua.
>>Generally I'm content with the way things are. But there are some
>>things...
>
>Type declarations, including declarations for a (specific)
>user-defined type. This would have to be ptional, of course, but with
>a switch to make them required. 

Make that "optional", not "ptional". Although that might be an
excellent word if it existed!

>This is pretty much the only
>significant thing that a language like C++ has that Lua doesn't have
>(other than a modest difference in performance), and the lack of it
>makes large-scale programming in Lua much more difficult and
>uncertain.
>
>Steve

Steve


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Evan DeMond
In reply to this post by David Manura

Possibly also: macros (in the LISP sense).

Having received a lot of training in the dark arts of Scheme, this idea is the most tantalizing to me so far (can't believe no one picked up on it yet!), but:

* I'm not sure how it'd fit in with Lua philosophy. In its favor, it's an extremely powerful generic tool upon which a lot of things could be implemented; this seems to me in keeping with the rationale behind Lua's generic structures such as tables which support a slew of different programming paradigms. However, would we just be muddling Lua's identity up too much with the realm of functional languages at this point?
* I'm not sure offhand how costly the implementation would be (I'm guessing it'd be pretty non-trivial)
* I'd like to brainstorm up some potential use cases to convince me it'd be worthwhile =)

As an appetizer, I've seen Scheme turned into a logic programming language (along the lines of Prolog) by a few crafty professors/instructors (Dan Friedman, Will Byrd, Oleg Kiselyov) with a clever but comparatively small set of Scheme macros. http://kanren.sourceforge.net/

Evan D.
 


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

David Dunham
In reply to this post by Patrick Donnelly-3
On 16 Aug 2007, at 22:06, Patrick Donnelly wrote:

I'm curious what features people would like to see added to Lua.
Generally I'm content with the way things are. But there are some
things...

As a rookie, I'd like to see print(table) actually print the table fields instead of the word table.

David Dunham   Macintosh Game Developer
GameHouse Studios     +1 206 926 5722     www.gamehouse.com
    "They said it couldn't be done but sometimes it doesn't
     work out that way." -- Casey Stengel


Reply | Threaded
Open this post in threaded view
|

Re: Features you would like to see

Thomas Breuel
In reply to this post by Evan DeMond
Scheme is a great language--a language designed for computer scientists and experienced programmers to play around with new ideas.  Lua is a widely used extension language for general users.  Once macros are available in a programming language, readers can tell much less about what a piece of code does than if macros are not available.

Most uses of macros can be handled more cleanly with a compact lambda or block construct, plus some simple operators.  I think Lua already has pretty good support for that, but maybe a more Smalltalk/Ruby-like block syntax could improve things a little further.

Cheers,
Thomas.

On Aug 17, 2007, at 6:44 AM, Evan DeMond wrote:


Possibly also: macros (in the LISP sense).

Having received a lot of training in the dark arts of Scheme, this idea is the most tantalizing to me so far (can't believe no one picked up on it yet!), but:

* I'm not sure how it'd fit in with Lua philosophy. In its favor, it's an extremely powerful generic tool upon which a lot of things could be implemented; this seems to me in keeping with the rationale behind Lua's generic structures such as tables which support a slew of different programming paradigms. However, would we just be muddling Lua's identity up too much with the realm of functional languages at this point?
* I'm not sure offhand how costly the implementation would be (I'm guessing it'd be pretty non-trivial)
* I'd like to brainstorm up some potential use cases to convince me it'd be worthwhile =)

As an appetizer, I've seen Scheme turned into a logic programming language (along the lines of Prolog) by a few crafty professors/instructors (Dan Friedman, Will Byrd, Oleg Kiselyov) with a clever but comparatively small set of Scheme macros. http://kanren.sourceforge.net/

Evan D.
 



1234 ... 6