lua-users home
lua-l archive

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




On Fri, Jul 5, 2019 at 6:15 PM Sergey Kovalev <kovserg33@gmail.com> wrote:
сб, 6 июл. 2019 г. в 00:24, Coda Highland <chighland@gmail.com>:
> I'm really not a big fan of that. Not only does that have a ton more overhead thanks to needing to construct extra closures, but it messes with control flow -- you can't, for example, optionally return from the code.
You could follow rule: one enter one exit point. So you will no need
in return. Here return used to live then scope, like break in a loop.
Restrictions are always be. There is a lot of cases where you need no
return at all.

No, thank you. I really don't have any interest in going back to programming in Pascal. One enter is fine, but one exit is unnecessarily restrictive -- even loops have break statements, and that's multiple exits. 
 
> At that point, it's barely even syntactic sugar; if you're ALREADY writing a worker function and passing it to another function ("scope" instead of "pcall" but still...) and you have to inspect the return values either way, what have you really gained?
If there was a reference counting we could use meta-method
__unreferenced like __gc to achieve behaviour desired. But there
isn't. So it could be done only with functions.

You mean... the very functionality you're trying to suggest this workaround function to deal with not having? Gee, I wonder why people have been saying it's a good idea.

 
> The advantage of having the syntactical support built into the language itself instead of provided via meta-programming is that it means you can take advantage of all of the other features of the language. I wholly believe that <toclose> serves a purpose that CANNOT be elegantly and efficiently replicated without it. And that's exactly what you should be looking for when adding something to a language.

Lua is small language with simple but powerful syntax. Why we want
worthless increase complexity, instead expressiveness. Why
meta-programming should not be used?
There you need extra speed and very fine stack tuning in files open?
Can you give examples?

It's nice to have the ability to do metaprogramming, of course. I'm glad that Lua is a flexible enough language to make it possible. But when it takes a huge glob of metaprogramming to make a syntactically-awkward way of doing something, and the language creators are offering a way to provide the very tool you said would make it work better, then... why resist that feature? it's an opt-in feature, too, and Lua's optimizations still work if you don't use it. pcall() is capable of doing this all by itself without anything fancier, but it's awkward to program with and pure-Lua metaprogramming can't solve the problems it has.
 
Lua has coroutines. How you will manage finally blocks there. Also
there are a lot of options how to behave in case of errors, returns or
context switching in finally blocks.

Coroutines have the same problem with <toclose>. Coroutines have the same problem with your scope() function, too. You have to choose the right tool for the job, and if you have a resource that really has to be cleaned up in a coroutine that might never run to completion, then that's what __gc is for. <toclose> and finally and scopes, regardless of how you implement them, are for fine-grained control when you need to make sure that a function doesn't exit without running a certain piece of code.