Re: "namespaces" ?

[Edgar Toernig <froese@...>]

Peter Prade wrote:
> 
> > often anyway.  I.e. you want to write t:append(e) instead
> > of Table.append(t,a) or x:sin() instead of Number.sin(x).
> 
> hmm, what makes x:sin() preferable over sin(x) ?

It was about  x:sin()  versus  Number.sin(x).

> the whole idea of putting global functions into modules is to
> not pollute the global namespace.

Ehh, no.  The idea is to allow different versions of the function
to exist in different namespaces.

But namespaces become fruitless if you have to select the namespace
each time explicitely.  The namespaces become a simple prefix.  You
want some mechanism to let the compiler automatically select the
right namespace.

I.e. in typed languages the compiler may choose the namespace based
on the type of the object:

  Number x
  Bignum y
  ...
  print(sin(x), sin(y))

Here sin(x) will invoke Number's sin and sin(y) will call Bignum's sin.
[1]

In Lua this is not possible.  The type is not known by the compiler and
the namespaces are dynamic (may change at run-time).  So by writing
x:sin() you tell the compiler to take the sin from x's namespace (what-
ever that may be).

> I think in this case it might be easier to stick with sin(x) - i think
> x:sin() looks somehow ridiculous...

If you want to map the sin function to the global namespace you can
still add: function sin(x) return x:sin() end.

Ciao, ET.


[1] 'print' itself may become ugly in these languages.  It accepts all
kind of types. (There's a reason for C++'s  '<<' print syntax...)  In
Lua that would become easy: just call x:tostring for each argument x.