headers
Unknown | 1 Dec 1997 11:06

Re: access to lua arrays from within C code

>I have a C function that expects char *argv[] as an argument.
>The natural representation for argv in Lua would be as a table
>with elements 1, 2, 3, etc.
>
>What is the recommended method of getting access to the array elements
>from within my C code?

The easiest solution is something like:

/* CAUTION: untested code ahead */

 lua_Object t=lua_getparam(1);

 for (i=0; i<N; i++)
 {
  lua_Object v;
  lua_beginblock();
  lua_pushobject(t);
  lua_pushnumber(i);
  v=lua_gettable()
  if (v==LUA_NOOBJECT || lua_isnil(v)) break;
  argv[i]=lua_getnumber(v);
  lua_endblock();
 }

 argc=i;
 myfunction(argc,argv);

Another solution is to use "call" in lua:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Norman Ramsey | 2 Dec 1997 14:10

Re: access to lua arrays from within C code

 > >I have a C function that expects char *argv[] as an argument.
 > >The natural representation for argv in Lua would be as a table
 > >with elements 1, 2, 3, etc.
 > >
 > >What is the recommended method of getting access to the array elements
 > >from within my C code?

 >  for (i=0; i<N; i++)
 >  {
 >   lua_Object v;
 >   v=lua_param(i)
 >   if (v==LUA_NOOBJECT || lua_isnil(v)) break;
 >   argv[i]=lua_getnumber(v);
 >  }

I must not have stated my question very carefully.
I have something like this for treating a table as an array:

<<print the elements in [[list]] as indexed by small integers>>=
for (i = 1; ; i++) {
  lua_Object o;
  lua_pushobject(list);
  lua_pushnumber((double)i);
  o = lua_getsubscript();
  if (lua_isnil(o)) break;
  s = lua_getstring(o);
  if (!s) lua_error("argument is not a string");
  printf("  %s\n", s);
}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Watson | 4 Dec 1997 19:55
Picon

true, false, and nil

I keep banging up against the overloaded meaning of nil: something has
no value and something is false.

This overloading causes me problems when I have tables in which a
value can be absent, present and true, or present and false.

Furthermore, Lua is supposed to be useful as a configuration language.
Which of the following do you prefer?

	dothis = true
	dothat = false
	
	dothis = not nil
	dothat = nil

(A false solution to this second problem is to set "true = not nil".
This idea has been explored extensively in C which has a somewhat
similar problem. You end up with situtations where a variable can be
true but not equal to the value of "true", for example, the value "2"
is true, but is not equal to "not nil".)

Can someone persuade me that the current situation is a Good Thing
and that a proper boolean type would not be a great improvement?

Alan Watson
Permalink | Reply | 6 comments |
headers
Alan Watson | 5 Dec 1997 22:05
Picon

Re: true, false, and nil

> if you really need to distinguish between "absent" and "present and false",
> then, yes, you need a representation for false that is diferent from nil.
> for example, true=1 false=0

This means that the expression "not true == false" is false. I
wouldn't like to write, let alone revise, such a program. (Similar
arguments hold for "typedef enum { false, true } boolean;" in C.)

> on the other hand, i think the "right" way to handle defaults is to use
> the "index" tag method, if you want to make distinguish between "absent" and
> "present and false",

I don't understand what you mean. Can you elaborate, please?

> for configuration, i prefer:
> 
> writelog=nil
> sendmail=1

To use Hermia's words from A Midsummer Night's Dream: "I am amazed,
and know not what to say."

> i'm not trying to persuade you of anything, of course.
> but we don't think we need a boolean type.

Well, can you at least help me understand why you made this design
decision. For example, can you give me a single advantage of the
current design over one with a true boolean? I just don't get it.

Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Jeske | 7 Dec 1997 10:54

Re: true, false, and nil

I agree 100% with Alan here.

I really dislike using "nil" to mean anything other than "absent".

On Thu, Dec 04, 1997 at 05:02:32PM -0200, Alan Watson wrote:
> I keep banging up against the overloaded meaning of nil: something has
> no value and something is false.
> 
> This overloading causes me problems when I have tables in which a
> value can be absent, present and true, or present and false.
> 
> Furthermore, Lua is supposed to be useful as a configuration language.
> Which of the following do you prefer?
> 
> 	dothis = true
> 	dothat = false
> 	
> 	dothis = not nil
> 	dothat = nil
> 
> (A false solution to this second problem is to set "true = not nil".
> This idea has been explored extensively in C which has a somewhat
> similar problem. You end up with situtations where a variable can be
> true but not equal to the value of "true", for example, the value "2"
> is true, but is not equal to "not nil".)
> 
> Can someone persuade me that the current situation is a Good Thing
> and that a proper boolean type would not be a great improvement?
> 
> Alan Watson
(Continue reading)

Permalink | Reply | 5 comments |
headers
Steve Dekorte | 9 Dec 1997 08:18

Visual Lua


Is there a web page for the "Visual Lua" research project?

Steve Dekorte
Permalink | Reply | 4 comments |
headers
David Jeske | 10 Dec 1997 02:48

Lua 3.1: Fixing varargs from Lua?

In the great anticipation of Lua 3.1 (which I'm _really_ looking forward to),
I thought of another language mis-feature which I'm not happy about. 

I don't like that you can't accept variable arguments to a Lua function, and
I don't like that you can't compose an argument list to pass to another
function. 

The var-args case is pretty well known and understood. The best "solution" I
can think of is to set varargs as a property of the function. Basically,
create the function, and then specify it as a varargs function, which will
set a tag method for handling function calls. Then that tag method (written
in C) will gather up the arguments, put them into a Lua table, and pass them
in as one table argument.

function a_varargs_fn(myargs)

   -- myargs should be a table of arguments
end

make_varargs(a_varargs_fn);

Second, consider writing a "perform" function in Lua, which takes as
arguments "a table", "a method name", and "an argument list" It's easy to
resolv the method from the method name, but there is no way to call that
method with an arbitrary list of arguments. 

Again, this could be facilitated from C, so that you would pass your method
and table of arguments to a "call_function_with_args". That C function would
then pull args out of the table and dispatch them to the function call.
(Continue reading)

Permalink | Reply | 0 comments |
headers
rw20 | 10 Dec 1997 17:17
Picon
Favicon

locals again

Since my last posting about locals I've spent a 
fair amount of time thinking about the issue.  I still
think defaulting to global access is a real problem for
me.  While explaining Lua to some folks for whom I wrote 
a little preprocessor using Lua, I realized that explaining
and supporting the global default model to semi-technical
users is not ideal.

Yesterday, I sat down to work with setting up tag methods 
to at least deliver runtime warnings.  My idea was to make 
it illegal to access globals unless their name started with 
'g' and the second letter was a capital.  As some of you 
probably know, I found that you can't set the get and set
global methods for some built-in types.  Looking at the 
C source code this seems to be prevented by a valid_events
table.  Can I change that table and get access to those
tags?

Anyway, there only seems to be a few other solutions:

1. a method type function definition that defaults to
local.  This could be considered a complication to the
language, but one doesn't have to even explain it to 
users (actually, some of use would stop explaining the
current function...end statement).
	method f(x)
		y=10 -- this is a local
		return x+y
	end
(Continue reading)

Permalink | Reply | 3 comments |
headers
Unknown | 11 Dec 1997 15:01

Re: locals again

I`m replying to the list before this turns into a major "war" about
taste in language design.

>From rw20 <at> cornell.edu Thu Dec 11 10:52:12 1997

>Since my last posting about locals I've spent a 
>fair amount of time thinking about the issue.  I still
>think defaulting to global access is a real problem for me.

Of course, the easy answer here is:
	"if it's a real problem for you, do not use Lua." :-)
However, I'm not looking for easy answers here.

Making all variables global by default was a decision taken in the very early
days of the design.
The rationale is that Lua is designed to be used as a configuration language,
where end users will hardly ever write their own functions.
Now imagine the mess of having to write

	global fgcolor="red"
	global bgcolor="white"
	global tolerance=0.001

This seems quite verbose and useless, from the point of view of the end user.
So the decision of having globals by default makes sense to us ;-) and
we don't feel we need to change it.
Moreover, we cannot change it without breaking *lots* of Lua code.

>While explaining Lua to some folks for whom I wrote 
>a little preprocessor using Lua, I realized that explaining
(Continue reading)

Permalink | Reply | 4 comments |
headers
rw20 | 11 Dec 1997 16:30
Picon
Favicon

Re: locals again

Thanks for the well thought out reply.  I'll try to look through your 
code this afternoon.

> Now imagine the mess of having to write
> 
> 	global fgcolor="red"
> 	global bgcolor="white"
> 	global tolerance=0.001
> 
> This seems quite verbose and useless, from the point of view of the end user.
> So the decision of having globals by default makes sense to us ;-) and
> we don't feel we need to change it.
> Moreover, we cannot change it without breaking *lots* of Lua code.

Sorry I wasn't clear.  I'm suggesting a change that would only change
global access within a "method...end'' block.  It wouldn't break any code,
but it would make Lua more capable of supporting different programming
methods and goals.  I really love Lua and respect all the design choices
that went into it.  For my needs, having a default-to-local access block
for functions would be of great help.  I'd add it to the language myself,
but I haven't yet been able to unravel the mystery that is the parser. 

To summarize my suggestion:
1. within a method...end block, all variable access and assignment is 
   assumed to be local 
2. the global keyword (only needed inside method...end) means, the
   very next word is a global variable name

Seems simple enough to me.  If I could get some pointers on how to add it
myself (is there a lex file we don't have?), I'd be happy to produce an
(Continue reading)

Permalink | Reply | 0 comments |

Gmane