Re: index tag method

[Edgar Toernig <froese@...>]

Hi,

John Belmonte wrote:
> 
> Edgar Toernig wrote:
> >
> > Syntax: No.  I think that the elements present in Sol are sufficient.
> > Semantics: Yes.  IMHO some changes (methods) would make it better.
> 
> I can't argue with that, but I'm trying to work out a practical solution for
> Lua.  Until Lua becomes Sol or Sol becomes Lua, Sol being sufficient doesn't
> help this particular task.

I doubt that Lua ever becomes Sol ;-)  But maybe they take some ideas.
About the "sufficient": s/present in Sol/present in Lua\/Sol/.  The few
syntactical changes in Sol only makes some things a little bit nicer,
mainly:

Foo = {
	function foo1() ... end
	function foo2() ... end
	...
}

That is normal function definitions within tables without the need for ','.

> > Concept: Modules exports one table (or more).  This table holds exported
> > functions and data objects (File.open, File.stdout, Socket.connect).
> 
> Already with that start I think a problem exists.

I disagree ;-)  Yes, you could do something like
	Foo = module "mod_foo_filename"
and move the policy to the user of the module.  I would call this gutless ;-)
You already have a namespace collision in the file name.  And what is if two
modules want to use the same third module?  Load it twice because noone knows
if anyone else has already loaded it?[1]  I think it's much easier for everyone
if you just say: mod_foo has the file name "foo_filename" and exports the
table "Foo".  Now every user of mod_foo knows how to access it, even the module
itself may refer to Foo.foo1.  Yes, that's policy.  And it requires some
discipline.  But at some place you _have_ to define such things.  If you don't
do it at the module layer you do it within your application and have interoper-
ation problems again.  (And problems reading others code ;-)

([1] You could do some management within the module load function to handle
the "more users" case.  But IMHO that results in too much policy.  It would
require a pretty strong module definition (like: a module has to export ex-
actly one table).  I would prefer a minimum policy that is still flexible.)

> To code readable modules (that is, without making a rats nest of upvalues)
> the module's table needs to be a global.  To make a global you have to pick
> a name, and therefore will have name clash problems.

It's right that writing static/private functions in Lua is not very nice.
You normally use locals and upvalues.  IMHO just playing around with the
global table during module load time will not work.  Maybe it can be made
more friendly by switching local/global default semantics?  Or by redefin-
ing the global scope to always be that that was active during load time?

I'm still thinking about that.  Up to now I stick with the local+upvalues
or simply put private data into the exported table too ;-)

> The way I'm thinking to get around this is with get/settable hooks, assuming
> a Lua change where global accesses trigger those hooks.

There are already get/settable (or even get/setglobal) hooks for globals!?!
*puzzled*

> First I'm working on that Lua change which I believe is helpful in any
> case.  When that's done I may take a stab at a module/namespace solution.

Just report your results/findings/ideas ;-)

> Anyway I think there are several ways to deal with these issues and it's
> good that a few approaches are being explored.

I fully agree!

Ciao, ET.