The compiler doesn't like loops in general.
I recently made a function that had a while loop inside a for loop: it
refused to (JIT-) compile.
I had to use goto instead.
On 15 April 2017 at 10:37, Laurent Deniau <Laurent.Deniau@xxxxxxx> wrote:
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
<+41%2022%20767%2046%2047>
On Fri, Apr 14, 2017 at 2:50 AM, Glenn Maynard <glenn@xxxxxxxx> wrote:
In case anyone else wants it, a first pass implementation of this is here:
https://github.com/zewt/LuaJIT/commit/c0e38bacba15d0259c3b77
843b8e1fa6e5312726
On Thu, Apr 13, 2017 at 5:17 PM, Glenn Maynard <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>
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> 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),
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
