Has Lua reached perfection?

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
Soni They/Them L. <[hidden email]> wrote:

> I want a switch where you can use math.random() in switch cases and it
> lazy-evaluates them and just works.

What practical use would that even have?

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Soni "They/Them" L.


On 2018-01-28 12:04 PM, Paige DePol wrote:
> Soni They/Them L. <[hidden email]> wrote:
>
>> I want a switch where you can use math.random() in switch cases and it
>> lazy-evaluates them and just works.
> What practical use would that even have?
>
> ~Paige
>
>

It's equivalent to if...elseif chains and supports ==

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
Soni They/Them L. <[hidden email]> wrote:

>
>
> On 2018-01-28 12:04 PM, Paige DePol wrote:
>> Soni They/Them L. <[hidden email]> wrote:
>>
>>> I want a switch where you can use math.random() in switch cases and it
>>> lazy-evaluates them and just works.
>> What practical use would that even have?
>>
>> ~Paige
>
> It's equivalent to if...elseif chains and supports ==

I meant using math.random() as a case value.

I think I'd need to see a code example of what you mean
to understand how this switch block would work.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Soni "They/Them" L.


On 2018-01-28 12:19 PM, Paige DePol wrote:

> Soni They/Them L. <[hidden email]> wrote:
>
>>
>> On 2018-01-28 12:04 PM, Paige DePol wrote:
>>> Soni They/Them L. <[hidden email]> wrote:
>>>
>>>> I want a switch where you can use math.random() in switch cases and it
>>>> lazy-evaluates them and just works.
>>> What practical use would that even have?
>>>
>>> ~Paige
>> It's equivalent to if...elseif chains and supports ==
> I meant using math.random() as a case value.
>
> I think I'd need to see a code example of what you mean
> to understand how this switch block would work.
>
> ~Paige
>
>

It's just a natural consequence of evaluating them in-order and
supporting ==, like a desugaring into if...elseif chains.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
Soni They/Them L. <[hidden email]> wrote:

> On 2018-01-28 12:19 PM, Paige DePol wrote:
>> Soni They/Them L. <[hidden email]> wrote:
>>
>>> On 2018-01-28 12:04 PM, Paige DePol wrote:
>>>> Soni They/Them L. <[hidden email]> wrote:
>>>>
>>>>> I want a switch where you can use math.random() in switch cases and it
>>>>> lazy-evaluates them and just works.
>>>> What practical use would that even have?
>>>>
>>>> ~Paige
>>> It's equivalent to if...elseif chains and supports ==
>> I meant using math.random() as a case value.
>>
>> I think I'd need to see a code example of what you mean
>> to understand how this switch block would work.
>>
>> ~Paige
>
> It's just a natural consequence of evaluating them in-order and supporting
> ==, like a desugaring into if...elseif chains.

So, you're saying you'd want something like "case math.random() == 12"?

The case blocks themselves are already essentially == comparisons to the initial
value being switch'd... so couldn't you just do "switch math.random()" and then
do case blocks for each random value you wanted results for? Without you giving
some sort of pseudo-code example I am just grasping at your meaning here! ;)

I also came up short trying to search for examples for what you are asking by
searching for "lazy evaluation switch case" but that came up blank for the most
part. However, I did discover that the language Python also does not have any
support for switch/case, and their reasoning[1] seems to be the same as Lua:


You can do this easily enough with a sequence of if... elif... elif... else.
For cases where you need to choose from a very large number of possibilities,
you can create a dictionary mapping case values to functions to call.

There have been some proposals for switch statement syntax, but there is no
consensus (yet) on whether and how to do range tests. See PEP 275[2] for
complete details and the current status.


By the status of the PEP it doesn't look like Python will be getting a native
switch/case statement any time soon. However, it looks like I pretty much
implemented PEP 275 for Lua! :)

~Paige

[1] https://docs.python.org/2/faq/design.html#why-isn-t-there-a-switch-or-case-statement-in-python

[2] https://www.python.org/dev/peps/pep-0275/


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Soni "They/Them" L.


On 2018-01-28 12:49 PM, Paige DePol wrote:

> Soni They/Them L. <[hidden email]> wrote:
>
>> On 2018-01-28 12:19 PM, Paige DePol wrote:
>>> Soni They/Them L. <[hidden email]> wrote:
>>>
>>>> On 2018-01-28 12:04 PM, Paige DePol wrote:
>>>>> Soni They/Them L. <[hidden email]> wrote:
>>>>>
>>>>>> I want a switch where you can use math.random() in switch cases and it
>>>>>> lazy-evaluates them and just works.
>>>>> What practical use would that even have?
>>>>>
>>>>> ~Paige
>>>> It's equivalent to if...elseif chains and supports ==
>>> I meant using math.random() as a case value.
>>>
>>> I think I'd need to see a code example of what you mean
>>> to understand how this switch block would work.
>>>
>>> ~Paige
>> It's just a natural consequence of evaluating them in-order and supporting
>> ==, like a desugaring into if...elseif chains.
> So, you're saying you'd want something like "case math.random() == 12"?
>
> The case blocks themselves are already essentially == comparisons to the initial
> value being switch'd... so couldn't you just do "switch math.random()" and then
> do case blocks for each random value you wanted results for? Without you giving
> some sort of pseudo-code example I am just grasping at your meaning here! ;)
>
> I also came up short trying to search for examples for what you are asking by
> searching for "lazy evaluation switch case" but that came up blank for the most
> part. However, I did discover that the language Python also does not have any
> support for switch/case, and their reasoning[1] seems to be the same as Lua:
>
>
> You can do this easily enough with a sequence of if... elif... elif... else.
> For cases where you need to choose from a very large number of possibilities,
> you can create a dictionary mapping case values to functions to call.
>
> There have been some proposals for switch statement syntax, but there is no
> consensus (yet) on whether and how to do range tests. See PEP 275[2] for
> complete details and the current status.
>
>
> By the status of the PEP it doesn't look like Python will be getting a native
> switch/case statement any time soon. However, it looks like I pretty much
> implemented PEP 275 for Lua! :)
>
> ~Paige
>
> [1] https://docs.python.org/2/faq/design.html#why-isn-t-there-a-switch-or-case-statement-in-python
>
> [2] https://www.python.org/dev/peps/pep-0275/
>
>

switch x do
case math.random() do print "a" end
case math.random() do print "b" end
case math.random() do print "c" end
else do print "e" end
end

-- desugars into

if x == math.random() then print "a"
elseif x == math.random() then print "b"
elseif x == math.random() then print "c"
else print "e" end


--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
Soni They/Them L. <[hidden email]> wrote:

> switch x do
> case math.random() do print "a" end
> case math.random() do print "b" end
> case math.random() do print "c" end
> else do print "e" end
> end
>
> -- desugars into
>
> if x == math.random() then print "a"
> elseif x == math.random() then print "b"
> elseif x == math.random() then print "c"
> else print "e" end

Okay, so we are taking about the same thing... though I still don't
necessarily see a practical use for this specific example.

With the current version of my switch/case patch providing a fallback to
using if/else for a switch construct with non-constant blocks isn't possible.

However, using my Token Storage system I could easily defer the non constant
case blocks... though the issue with fallthrough would still exist using
if/else constructs for non-constant values, which is the usual problem when
'desugaring' switch/case blocks that use fallthrough.

I suppose one fix to the issue would be to simply disallow fallthrough and
force a break for switch constructs that have non-constant case values.

Hmm, thanks for bringing this idea up, Soni. What you request may actually
be possible... I will have to tinker with some code and see what I can come
up with for non-constant case blocks! :)

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Soni "They/Them" L.


On 2018-01-28 01:58 PM, Paige DePol wrote:

> Soni They/Them L. <[hidden email]> wrote:
>
>> switch x do
>> case math.random() do print "a" end
>> case math.random() do print "b" end
>> case math.random() do print "c" end
>> else do print "e" end
>> end
>>
>> -- desugars into
>>
>> if x == math.random() then print "a"
>> elseif x == math.random() then print "b"
>> elseif x == math.random() then print "c"
>> else print "e" end
> Okay, so we are taking about the same thing... though I still don't
> necessarily see a practical use for this specific example.
>
> With the current version of my switch/case patch providing a fallback to
> using if/else for a switch construct with non-constant blocks isn't possible.
>
> However, using my Token Storage system I could easily defer the non constant
> case blocks... though the issue with fallthrough would still exist using
> if/else constructs for non-constant values, which is the usual problem when
> 'desugaring' switch/case blocks that use fallthrough.
>
> I suppose one fix to the issue would be to simply disallow fallthrough and
> force a break for switch constructs that have non-constant case values.
>
> Hmm, thanks for bringing this idea up, Soni. What you request may actually
> be possible... I will have to tinker with some code and see what I can come
> up with for non-constant case blocks! :)

Can you use goto across elseif yet?

if x then
   goto ::y::
elseif y then
   ::y::
end

If not, that could be an interesting syntax extension. Only across a
single elseif tho.

>
> ~Paige
>
>

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
Soni They/Them L. <[hidden email]> wrote:

> On 2018-01-28 01:58 PM, Paige DePol wrote:
>>
>> I suppose one fix to the issue would be to simply disallow fallthrough and
>> force a break for switch constructs that have non-constant case values.
>
> Can you use goto across elseif yet?
>
> if x then
>   goto ::y::
> elseif y then
>   ::y::
> end
>
> If not, that could be an interesting syntax extension. Only across a single elseif tho.

No, and this would potentially be quite a bit harder to implement with Lua's
single pass compiler. I assume you mention this as a way of implementing a
fallthrough for non-constant case blocks.

However, in a switch/case with a mix of constant and non-constant case blocks
the constant ones would be checked first via lookup table, and if that failed
then the non-constant blocks would be checked via if/else, and if all blocks
failed the 'else' block would be executed.

Forbidding fallthrough in switch/case constructs with non-constant case blocks
would be the easiest implementation, simply because the bytecode could wind up
being out-of-order from how the source code was written and jumping into an
elseif/else block via goto is currently not supported.

However, the PC of each case or if block could be recorded at compile time
and direct OP_JMPs could be added to jump around to support fallthrough.
This would effectively give the ability to "goto" into an else block, albeit
only when compiling switch/case blocks and not via a 'goto' statement.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Soni "They/Them" L.


On 2018-01-28 02:48 PM, Paige DePol wrote:

> Soni They/Them L. <[hidden email]> wrote:
>
>> On 2018-01-28 01:58 PM, Paige DePol wrote:
>>> I suppose one fix to the issue would be to simply disallow fallthrough and
>>> force a break for switch constructs that have non-constant case values.
>> Can you use goto across elseif yet?
>>
>> if x then
>>    goto ::y::
>> elseif y then
>>    ::y::
>> end
>>
>> If not, that could be an interesting syntax extension. Only across a single elseif tho.
> No, and this would potentially be quite a bit harder to implement with Lua's
> single pass compiler. I assume you mention this as a way of implementing a
> fallthrough for non-constant case blocks.
>
> However, in a switch/case with a mix of constant and non-constant case blocks
> the constant ones would be checked first via lookup table, and if that failed
> then the non-constant blocks would be checked via if/else, and if all blocks
> failed the 'else' block would be executed.
>
> Forbidding fallthrough in switch/case constructs with non-constant case blocks
> would be the easiest implementation, simply because the bytecode could wind up
> being out-of-order from how the source code was written and jumping into an
> elseif/else block via goto is currently not supported.
>
> However, the PC of each case or if block could be recorded at compile time
> and direct OP_JMPs could be added to jump around to support fallthrough.
> This would effectively give the ability to "goto" into an else block, albeit
> only when compiling switch/case blocks and not via a 'goto' statement.
>
> ~Paige
>
>

But what if a non-constant case comes first, and the constant case has
the same value? Shouldn't the non-constant case run, rather than the
constant case? I think it should.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
Soni They/Them L. <[hidden email]> wrote:

> On 2018-01-28 01:58 PM, Paige DePol wrote:
>> However, in a switch/case with a mix of constant and non-constant case blocks
>> the constant ones would be checked first via lookup table, and if that failed
>> then the non-constant blocks would be checked via if/else, and if all blocks
>> failed the 'else' block would be executed.
>
> But what if a non-constant case comes first, and the constant case has the
> same value? Shouldn't the non-constant case run, rather than the constant
> case? I think it should.

Mixing constant and non-constant values in a switch block is always going to
have some trade offs. In the case where there would be conflict like you've
mentioned it would then be up to the coder to use the most relevant construct.

If I were to allow constant and non-constant values in case blocks, which
after all this discussion I am not even sure is a good idea, I would say
the constant value lookup would be done followed by the if/else construct
for non-constant values. Thus the constant values would have priority.

Otherwise, for the example you gave... just use if/else in the first place,
or only use non-constant or non-conflicting values as case values?

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Soni "They/Them" L.


On 2018-01-28 03:19 PM, Paige DePol wrote:

> Soni They/Them L. <[hidden email]> wrote:
>
>> On 2018-01-28 01:58 PM, Paige DePol wrote:
>>> However, in a switch/case with a mix of constant and non-constant case blocks
>>> the constant ones would be checked first via lookup table, and if that failed
>>> then the non-constant blocks would be checked via if/else, and if all blocks
>>> failed the 'else' block would be executed.
>> But what if a non-constant case comes first, and the constant case has the
>> same value? Shouldn't the non-constant case run, rather than the constant
>> case? I think it should.
> Mixing constant and non-constant values in a switch block is always going to
> have some trade offs. In the case where there would be conflict like you've
> mentioned it would then be up to the coder to use the most relevant construct.
>
> If I were to allow constant and non-constant values in case blocks, which
> after all this discussion I am not even sure is a good idea, I would say
> the constant value lookup would be done followed by the if/else construct
> for non-constant values. Thus the constant values would have priority.
>
> Otherwise, for the example you gave... just use if/else in the first place,
> or only use non-constant or non-conflicting values as case values?
>
> ~Paige
>
>

Why not make it explicit? If you want the constant cases to come first,
put the constant cases first?

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Tony Papadimitriou
In reply to this post by Francisco Olarte
-----Original Message-----
From: Francisco Olarte

>On Sun, Jan 28, 2018 at 1:09 PM, Tony Papadimitriou <[hidden email]> wrote:
>...
>> The only thing I would certainly add to Lua is a `yield` keyword to
>> complement `return` similar to Python’s way.
>>
>> The current method (or hack) of implementing co-routines is unnecessarily
>> verbose and often resulting in hard to understand code.
>
>How do you think this will improve?

Re-read the sentence just above your question to see how.

>In Lua? Coroutines are what they have been in nearly every other
>system I've used, same functions as packages I've used in C, C++,
>Pascal and even assembler ( 8 bit one ). Nothing especial to be done
>in any function used in a coroutine heavy program, just a couple
>function calls.

An what more 'special' is done with Python's `yield`?  You just
replace `return` with `yield` and you turn any function into a
co-routine.  Can't get much simpler.

I didn't talk about changing how co-routines are implemented internally,
(and, as a user, it's none of my business), just how one has to implement
them in their own Lua code.  Call it 'syntactic sugar' if you like.
Same as having `a = function() end` be (almost) equivalent to
`function a() end`

In other words, I prefer this:

function xxx(n)
  for i = 1, n do yield i*i end
end

to this:

function xxx(n)
  return coroutine.wrap(function() for i = 1, n do coroutine.yield(i*i) end
end)
end

Now, if the latter is more appealing to you, good for you.
"In matters of taste, there can be no disputes."

>Francisco Olarte.

Tony P.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
In reply to this post by Soni "They/Them" L.
Soni They/Them L. <[hidden email]> wrote:

>> Otherwise, for the example you gave... just use if/else in the first place,
>> or only use non-constant or non-conflicting values as case values?
>>
>> ~Paige
>
> Why not make it explicit? If you want the constant cases to come first,
> put the constant cases first?

Due to the nature of how the switch/case works the case values would have
to be broken down into two distinct categories; constant and non-constant.
I would say that the constant value case blocks have priority as they are
known at compile time and are explicitly declared, the non-constant ones
therefore would be checked after the constant ones... were I to implement
the ability to have non-constant case blocks at all.

With the example you gave you could just use an if/else statement. The idea
of switch/case, and the way I implemented it, is not just to be syntactic
sugar for if/else blocks but to offer more performance when selecting code
paths from many known-at-compile-time options.

I like the idea of being able to specify non-constant case values, however,
there will have to be some limitations due to the nature of the problem.
Also, arguably, once you start executing functions to obtain case values
the entire point of switch/case, the speed improvement, goes away as well.

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Soni "They/Them" L.


On 2018-01-28 05:37 PM, Paige DePol wrote:

> Soni They/Them L. <[hidden email]> wrote:
>
>>> Otherwise, for the example you gave... just use if/else in the first place,
>>> or only use non-constant or non-conflicting values as case values?
>>>
>>> ~Paige
>> Why not make it explicit? If you want the constant cases to come first,
>> put the constant cases first?
> Due to the nature of how the switch/case works the case values would have
> to be broken down into two distinct categories; constant and non-constant.
> I would say that the constant value case blocks have priority as they are
> known at compile time and are explicitly declared, the non-constant ones
> therefore would be checked after the constant ones... were I to implement
> the ability to have non-constant case blocks at all.
>
> With the example you gave you could just use an if/else statement. The idea
> of switch/case, and the way I implemented it, is not just to be syntactic
> sugar for if/else blocks but to offer more performance when selecting code
> paths from many known-at-compile-time options.
>
> I like the idea of being able to specify non-constant case values, however,
> there will have to be some limitations due to the nature of the problem.
> Also, arguably, once you start executing functions to obtain case values
> the entire point of switch/case, the speed improvement, goes away as well.

I've checked the asm output of rustc over and over. It doesn't have jump
tables. I couldn't get it to produce jump tables no matter what I tried.

Jump tables are unnecessary. The syntax sugar is nice when comparing the
same variable to many many values, as it avoids typos (e.g. `hello == 1`
in the first "if", `helo == 2` in the second "if").

> ~Paige
>
>

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Dibyendu Majumdar
In reply to this post by Paige DePol
Hi,

On 28 January 2018 at 01:06, Paige DePol <[hidden email]> wrote:
> One of my goals with Lua++ is to allow fully backwards compatible parsing
> of Lua code, which will be placed fully in a namespace. If the backwards
> compatibility is not necessary then it can be compiled without that support,
> much as Lua does for it's own compatibility. Other than adding new features
> to the language I have tried to keep the existing syntax as compatible as
> possible, however, my parser will have two modes available when parsing
> source code; Lua mode and Lua++ mode as there are some syntax differences.
>

I think it is very hard to get traction on any new language ... there
have been several clones of Lua; not sure any of them succeeded. Even
though Ravi is a superset of Lua 5.3, and adds a JIT, I am not sure
anyone is using it - and that is after 2 years of development. I have
watched some languages try for 10 years or more to establish
themselves but they are still struggling. My advice would be to
maintain 100% compatible with Lua - at least that way users who
currently use Lua can try out your language without having to rewrite
/ change their existing code.

Good luck!

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
Dibyendu Majumdar <[hidden email]> wrote:

> On 28 January 2018 at 01:06, Paige DePol <[hidden email]> wrote:
>> One of my goals with Lua++ is to allow fully backwards compatible parsing
>> of Lua code, which will be placed fully in a namespace. If the backwards
>> compatibility is not necessary then it can be compiled without that support,
>> much as Lua does for it's own compatibility. Other than adding new features
>> to the language I have tried to keep the existing syntax as compatible as
>> possible, however, my parser will have two modes available when parsing
>> source code; Lua mode and Lua++ mode as there are some syntax differences.
>
> I think it is very hard to get traction on any new language ... there
> have been several clones of Lua; not sure any of them succeeded. Even
> though Ravi is a superset of Lua 5.3, and adds a JIT, I am not sure
> anyone is using it - and that is after 2 years of development. I have
> watched some languages try for 10 years or more to establish
> themselves but they are still struggling. My advice would be to
> maintain 100% compatible with Lua - at least that way users who
> currently use Lua can try out your language without having to rewrite
> / change their existing code.

For sure, this really is one reason why I want to maintain compatibility
with Lua... honestly, if I didn't I don't think the name Lua++ would even
be appropriate to use! ;)

I have wanted to have "my own" programming language for years, but never
really knew were to start... Lua has provided me with a great learning
opportunity and I am taking advantage of it as much as I can.

Honestly, even if nobody ever uses Lua++ it is the learning experience
that I am doing it for. I am trying my best to build the system up as
a series of patches that people can apply individually to Lua as well
for creating their own custom builds of the language.

Most of my coding career, before my partner got sick and I have had to
take care of her full time, has been writing code for other people. At
least now I am writing code for myself, and hopefully building up a bit
of a portfolio via Lua patches and eventually Lua++ itself.

I have been keeping an eye on Ravi, by the way, as you've been working
on the various JIT methods. One day I would like to add JIT to Lua++ and
I hope the work you're doing now will be of some use to me in the future!

Keep up the good work, and good luck to you on Ravi as well! :)

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Paige DePol
In reply to this post by Soni "They/Them" L.
Soni They/Them L. <[hidden email]> wrote:

> I've checked the asm output of rustc over and over. It doesn't have jump
> tables. I couldn't get it to produce jump tables no matter what I tried.
>
> Jump tables are unnecessary. The syntax sugar is nice when comparing the
> same variable to many many values, as it avoids typos (e.g. `hello == 1`
> in the first "if", `helo == 2` in the second "if").

I like my patch which uses jump tables to allow both computed goto syntax
along with faster code branching over a large number of possible choices,
as well as the ability to fallthrough case blocks, which can not currently
be done with just an if/else construct in vanilla Lua.

You are, of course, more than welcome to develop your own patch for creating
a switch/case patch which is just syntactic sugar for an if/else construct.

I may add non-constant case values at some point, if I do maybe I'll revert
the entire switch/case to if/else, or maybe just give const values priority
over non-constant values... but honestly, at this point adding support for
non-constant values is not a priority as there is always if/else for them!

I do agree that switch/case syntax does help remove potential typos in the
names of variables... then again, so would a 'strict' mode! ;)

~Paige


Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

Dirk Laurie-2
In reply to this post by Soni "They/Them" L.
2018-01-28 18:23 GMT+02:00 Soni "They/Them" L. <[hidden email]>:

> Can you use goto across elseif yet?
>
> if x then
>   goto ::y::
> elseif y then
>   ::y::
> end
>

I suspect you have not used 'goto' very often in your own
programs. It's just 'y'.

Reply | Threaded
Open this post in threaded view
|

Re: Has Lua reached perfection?

nobody
In reply to this post by Dibyendu Majumdar
On 2018-01-28 01:44, Dibyendu Majumdar wrote:
> It takes good taste and years of effort to create a language such as
> Lua. Despite some 'warts' overall Lua 5.3 appears to have reached a
> state of perfection (or maturity) in my view.

Maturity – yes, definitely.  Perfection - nope, long way to go still.
(That will probably always be true...)  But it's *A LOT* closer to that
than any other (practical) language that I know.

The way it looks to me right now, 5.4 will bring us closer by reducing
temptations to veer off the "Lua way":  The generational GC makes
throwaway structures cheaper, which means you're more likely to use them
and not write "manual" / lower-level code for the sake of "speed".
(Even if it doesn't measurably impact actual speed... most likely, one
never measured anyway. ^,^)

Varargs becoming tables also feels like a step in the right direction,
but I expect that there will be some quirks for the next version to
fix... and that's fine!  5.3 brought sub-types (int/float), which at
least "feel" a bit clunky still...  which is a _good_ thing:  Rough bits
persist if they're not too much of a problem, the team doesn't pick the
first "solution" that comes running along and freezes it in place.  New
things are allowed to stay a little rough & floaty... in time, they fall
into place. [1] (Recall bit library / operators, function environments /
_ENV, tag methods / metamethods, ... (oh right: varargs too ^,^) –
there's no holy cow inside Lua, what must change will change.)

Beside incoming improvements, present Lua also contains lots of tiny
warts... NaN being unusable as a table key is one of the bigger kinks –
a "discontinuity" in the type/value space that's hard to check for and
generates complexity whenever you have to deal with it.  (And no library
ever checks/handles this... because that would be clunky & slow(er), and
so you're stuck writing your own code.) [2]

`__eq` expecting both types _and_ metamethod to match is another one:
By setting a metamethod, I communicate that it can handle values of that
type; by setting the same metamethod/closure on multiple types, I
communicate that it knows how to handle all of these... and yet, Lua
insists that primitive types must match and thereby prevents useful
"duck typing".  (i^2 == -1 is false or (i^2)^0.5 is nan... or maybe
you've written some pretty complex code for a magic workaround.  Same
for mixing tables/userdata and not having to wrap or convert stuff.
This is a deviation from the "mechanism not policies" philosophy that,
irrespective of whether this will or should change, is a surprise / a
discontinuity that results in more complex code, and is therefore not
yet perfect.)

The awesome thing about Lua is that pretty much all the other
"discontinuities" / kinks that I can think of can be fixed _from inside
the language_, often even locally / without affecting other libraries!
(And if I'll run into some other thing that cannot be "configured away"
at runtime, Lua is very hackable!  So it's probably not that much of a
problem.)

-- nobody

[1] To try and make more clear (or confusing ^,^) what I mean here...
 From my perspective, it seems the Lua authors seek saddle points, not
local optima.  (Whether intentional or accidental / as a side-effect of
something else, I do not know.)  The big difference is that at saddle
points, movement is cheap, while at local optima, you'd first have to
climb back out to get going.  I think this is a big part of what makes
Lua what it is, and you can see it practically everywhere.

[2] Your(?) idea from a while back of making NaN false doesn't fix this
– it adds another kink that permits a simple approximate test but...
well, suddenly, not all numbers are `true` and you have one other
discontinuity to worry about.  The best thing that I could think of, so
far, is to have special case logic for the float paths in the table
code, possibly substituting a single "canonical" NaN (recall that
there's billions of them... =/) for use as a key.  Last time I patched
this (...5.2? 5.3.1/2? In 5.3.3/4(?) some table code changed, so it
broke...) I was able to hide most of the code on error paths / behind
checks that already existed.  But people always worry about speed... so
let's just see what happens.

123