Re: Any LuaJIT "continue" patch?

  • From: Laurent Deniau <Laurent.Deniau@xxxxxxx>
  • To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
  • Date: Sat, 15 Apr 2017 08:37:42 +0000


On 14 Apr 2017, at 23:01, Some Guy <someguynamedpie@xxxxxxxxx> wrote:

I personally think it'd do LuaJIT a lot of good to start diverging from Lua a 
little bit to improve the language as a whole. It has so much potential but a 
lot of it is unmet because of the desire to maintain compatibility.

I think that it is important to keep some backward compatibility with some 
level of Lua (e.g. 5.2 - ENV_) for the libraries compatibility. Otherwise, it 
will end up with the same problem as PyPy and Python, the former needs to 
rewrite libraries like Numpy to take into account the change of semantic if 
their GC (python use RefCount, and not GCed), and stay  behing.

Nevertheless, I will not drop my own lambda syntax extension nor my local “in" 
table extension of LuaJIT, as they prove to be extremely useful since I 
introduced them a year ago. Since they do not change the semantic of Lua, they 
could be integrated for free to LuaJIT with full backward compatibility. Same 
for .. (concat) without surrounding spaces required or +litteral_num (unary 
plus).

I will also keep my xrange type extension but I will probably move the current 
primitive type extension to the auto-detection for the structure definition, 
i.e. if the structure is not defined with the right fields semantic, 1..5 will 
have the (weird) Lua semantic “15", otherwise it will create a range object 
also proven to be very useful. In this case, it will be also backward 
compatible (from memory, I will use lj_ctype_getname and lj_ctype_getfield to 
select the FFI defined struct).

At this point, though, Lua 5.3 is out with things like bitwise operators and 
LuaJIT is slowly aging when it comes to syntactical sugar. Things like 
continue would be great if they were integrated into the language and given 
FFI exists, it seems silly to use the pretense of compatibility anymore. As 
long as there are no substantial API changes, everything should work as it 
always has been but the quality of life improvements that would come with 
things like this are insurmountably large and would do great good in boosting 
LuaJIT's popularty.

Best,
Laurent.

--
Laurent Deniau                           http://cern.ch/mad
Accelerators Beam Physics        mad@xxxxxxx
CERN, CH-1211 Geneva 23       Tel: +41 (0) 22 767 4647


On Fri, Apr 14, 2017 at 2:50 AM, Glenn Maynard <glenn@xxxxxxxx 
<mailto:glenn@xxxxxxxx>> wrote:
In case anyone else wants it, a first pass implementation of this is here:

https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77843b8e1fa6e5312726
 
<https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77843b8e1fa6e5312726>


On Thu, Apr 13, 2017 at 5:17 PM, Glenn Maynard <glenn@xxxxxxxx 
<mailto:glenn@xxxxxxxx>> wrote:
You can use goto in place of all flow control, but this isn't BASIC.  Goto 
isn't a substitute for continue.



On Thu, Apr 13, 2017 at 8:07 AM, Lennart Bernhardt <l.bernhardt@xxxxxxx 
<mailto:l.bernhardt@xxxxxxx>> wrote:
You can just use a goto like so: 

for i=1,10 do
  if i % 2 == 0 then goto continue end
  print(i)
  ::continue::
end

On Thu, Apr 13, 2017 at 6:07 AM, Glenn Maynard <glenn@xxxxxxxx 
<mailto:glenn@xxxxxxxx>> wrote:
I'm testing out converting a Lua project to LuaJIT, and dealing with a few 
langauge patches we use that need to be reimplemented.

One adds continue (http://www.corsix.org/luacontinue/continue.patch ;
<http://www.corsix.org/luacontinue/continue.patch>), which is indispensable.  
Is there any similar patch for LuaJIT?  I'm guessing this can be done 
entirely within the parser without touching codegen.

-- 
Glenn Maynard





-- 
Glenn Maynard




-- 
Glenn Maynard



Attachment: smime.p7s
Description: S/MIME cryptographic signature

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 04-2017