lua-users home
lua-l archive

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


Top posting because that’s how this thread is:

Another thing, be careful about assuming what is hard and what isn’t. If parity with the C API is not important, you’re probably right, exceptions wouldn’t be that hard. C does not have exceptions, so implementing them in Lua, while maintaining parity with the C API (you can build up anything in the C API that you can in the language) isn’t as straightforward as you’re making it out to be. 

Andrew Starks

From: lua-l-bounces@lists.lua.org on behalf of Kurieita <devkurieita@gmail.com>
Sent: Thursday, May 30, 2019 06:11
To: Lua mailing list
Subject: Re: Classes, exceptions and enums
 
I was reading the source for 5.4 and there are basic implementation for const variable which I like because I would've asked for const too since its something that would be useful to.
The enums problem is a thing that I didn't really think about, thanks for pointing that out. I do disagree tho that you said "const variable bring less value to the language" if I understood that correctly.
Even as an embedded language added enums might be troublesome but added basic try/catch syntax wouldn't really be bloat or troublesome. There are plently of basic Lua implementation for it but not the actual syntax.



On Wed, May 29, 2019 at 9:00 PM David Favro <lua@meta-dynamic.com> wrote:
On 5/29/19 5:47 AM, Kurieita wrote:
> I been using Lua for years now and one thing that I hate is that is does not
> support native classes, exceptions or enums as many other languages does.
[...]
> Enums can be done simply with a table or a much more powerful metatables
> enum system
>
> To implement them is
> 1) time consuming .
> 2) defeats the whole purpose of the DRY (Do not repeat yourself) rule.
>
> 3) and make the code harder to read since they are not native and someone
> have to read the implementation for them.

Having used Lua as a general-purpose language for ~8 years (or attempted
anyhow), I more-or-less agree with your general points, but I view saying
"enum is missing" as a convoluted way to say that you want constants and
static typing (or type annotations), and probably a little syntax to define
the enum.  Lua has neither constants nor static types/annotations (both of
which would be welcome by me), so the building blocks are not there to
create a good enumerated type concept.

Without these required components, an inferior but workable concept of enum
can be implemented with existing Lua facilities (as you noted) e.g. as a
table with some arbitrary values assigned to named keys [1], or something a
little more sophisticated via considerable metatable complexity [2].

I confess that I am ignorant of the difficulty in implementing constants and
static types, but my impression is that constants is the less difficult of
the two, and adds less 'bloat' to the runtime [3], but also less value to
the language.

-- David

[1]: I am not intimately familiar with Python but my understanding is that
it does not enforce type-checking on enums even at runtime, so it really
doesn't offer much more than Lua already has.  I.e., in Python the result of
an equality comparison operator between two values of differing enum types
is not considered an error, it just evaluates to false (please correct me if
I'm wrong).  In my opinion, unless the programmer explicitly indicates
otherwise, this almost always represents a bug, and should not be permitted
(for best results via 'static analysis' AKA 'at compile time', but even a
runtime error is better than no error).

[2]: A metatable implementation could attempt run-time type-checking, but
this is undermined by the == operator's refusal to call __eq() on differing
types [pre-5.3 they must have *exactly* the same __eq metamethod; even in
5.3, although the behavior improved, __eq() still will not be called on a
primitive type other than table or userdata].

[3]: I haven't been following 5.4 developments too closely but there was
some list discussion that constants might be coming, or perhaps not.