It's a pity you removed the export statement

[shortweekend]

You certainly had practical reasons to remove the export statement but I think it was very handy not to add a lot of local statements to avoid global symbols.

Thanks and keep up the good work. Nyanga is coming up nicely.

[richardhundt]

On 3/23/14 4:59 PM, shortweekend wrote:

You certainly had practical reasons to remove the |export| statement but I think it was very handy not to add a lot of |local| statements to avoid global symbols.

No, hold up. Not prefixing stuff with local does not create globals. It does, however, make the symbols publicly visible by default (i.e. exported by default). If you want to create a global you need to explicitly assign to _G. That's it.

The export statement was just sugar for the following:

return {
   async = async
   yield = yield
   Fiber = Fiber
}

at the bottom of your module. Export just hid that from you, but that's exactly what it did. In fact, if you want to control exactly what is publicly visible, then just return a table at the end of the module. I think it's just a little less magic and simplifies the parser and compiler too.

And yep, there were some reasons.

My take on module privacy is that there will be occasions where you get a module in which you didn't write, but which you need to override something internal to it, so to paraphrase Larry Wall: In Nyanga you don't go into a module's living room because you weren't invited, not because it has a shotgun.

There were a few more practical reasons. Having module level symbols anchored in the module's environment (i.e. _M), means that we can clone functions (see Function::clone), create threads (see net.zmq.ZMQThread::fork), eval (i.e. the REPL), serialization/deserialization, etc. All these require compiling a function at runtime and giving it its parent environment.

Thanks and keep up the good work. Nyanga is coming up nicely.

Thanks for the bug reports and feedback!

— Reply to this email directly or view it on GitHub https://github.com/richardhundt/nyanga/issues/42.

[shortweekend]

Sorry for the confusion. In fact by "global" I meant "exported by default" and yes I liked the "magic" because the "export" sugar made it less verbose. I do however understand your reasons to remove it. They make perfect sense. Thanks

[richardhundt]

On 3/23/14 7:23 PM, shortweekend wrote:

Sorry for the confusion. In fact by "global" I meant "exported by default" and yes I liked the "magic" because the "export" sugar made it less verbose. I do however understand your reasons to remove it. They make perfect sense. Thanks

Ah, okay... I've reconsidered. Since Nyanga is really just sugar for Lua anyway, I've added the export statement again. I've been undecided about this part of the language for ages, but it really doesn't hurt to have it.

— Reply to this email directly or view it on GitHub https://github.com/richardhundt/nyanga/issues/42#issuecomment-38391457.

[richardhundt]

On 3/23/14 8:11 PM, Richard Hundt wrote:

Ah, okay... I've reconsidered. Since Nyanga is really just sugar for Lua anyway, I've added the export statement again. I've been undecided about this part of the language for ages, but it really doesn't hurt to have it. Just to clarify this a bit more. The semantics of export is different to the way it was before. It means that if you don't say export, then everything is public by default. Previously nothing was exported unless you said so. Currently the only way to export nothing is to use return at the end of the module. But I can't think of a use case for a module which exports nothing.

So it's a compromise, but I'm willing to discuss it if you want.

[richardhundt]

On 3/23/14 8:22 PM, Richard Hundt wrote:

On 3/23/14 8:11 PM, Richard Hundt wrote:

Ah, okay... I've reconsidered. Since Nyanga is really just sugar for Lua anyway, I've added the export statement again. I've been undecided about this part of the language for ages, but it really doesn't hurt to have it. Just to clarify this a bit more. The semantics of export is different to the way it was before. It means that if you don't say export, then everything is public by default. Previously nothing was exported unless you said so. Currently the only way to export nothing is to use return at the end of the module. But I can't think of a use case for a module which exports nothing.

So it's a compromise, but I'm willing to discuss it if you want.

one more thing... sorry... to save having to prefix private stuff with local, you can wrap declarations in do ... end:

class Public
   --
end

do
   class Private
      --
   end
   class AlsoPrivate
      --
   end
end
-- only Public is exported by default