 |
lua-l archive |
|
|
||
|
On 16/05/2020 12:22, Philippe Verdy wrote:
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)
To which part of my post are you replying? I can't understand what's your point in relation to what I've said in my post.
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 somesyntacticsugar and metatable semantics. In modern functional languages closuresare 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.orgCheers! -- 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
_______________________________________________ lua-l mailing list -- lua-l@lists.lua.org To unsubscribe send an email to lua-l-leave@lists.lua.org