lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Withuot closures, Lua code would be much lessa efficient. Closures avoid lot of duplication of values and allows smaller and simpler stack frames, when most other values will be already in the parent environement (whose properties, alias "global variables" but this is an incorrect term as Lua has absolutely no static variables, all of them are embedded in a closure, the closures forming their own stack, independant of the call stack because function calls do not necessarily create a call stack frame, e.g. in trail calls, and do not necessarily create a closure, unless specifically instructed in the called function by explicit settings using fsetenv).
This offers the full flexibility and efficiency of Lua (the same also applies to _javascript_ that has the same mechanism and is based on exactly the same concepts, with in fact minor syntaxic differences, but with stronger semantic definitions and a more precise security model for access control).
So the good question is just how Lua and _javascript_/ECMAscript are differentiated: they are in fact very similar (except for their default library)


Le sam. 16 mai 2020 à 12:06, Lorenzo Donati <lorenzodonatibz@tiscali.it> a écrit :
On 13/05/2020 00:47, William Ahern wrote:
> On Tue, May 12, 2020 at 08:50:03AM -0700, Andrea wrote:

[snip]

> variables. Lua is a functional languge that permits OOP with some syntactic
> sugar and metatable semantics. In modern functional languages closures are

Not to be a nitpicker (and I'm not arguing against what you say in the
rest of your post), but calling Lua a functional language seems a bit
too strong to me.

I completely agree that functional features (especially closures) are
quite a fundamental part of Lua, but so are more imperative features.

Lua code can be written in a pure imperative style, without using
functional features and heavily relying on side effects, and it doesn't
seem unnatural or harder.

At the same time, I agree that (with proper conditions, i.e. function
definitions, and practice) you /can/ write Lua code that looks mostly
functional and doesn't feel alien.

The fact is, IMO, Lua cannot be framed in either category, since it
supports both paradigms (with a slight imperative flavour,
out-of-the-box) with ease. And that is one of its selling point.


[snip]

> _______________________________________________
> lua-l mailing list -- lua-l@lists.lua.org
> To unsubscribe send an email to lua-l-leave@lists.lua.org
>

Cheers!

-- Lorenzo
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org