Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LuaJIT 3.0 proposed syntax extensions

github.com

Post reply on HN
Print view View original

71–80 of 170 posts

Re: LuaJIT 3.0 proposed syntax extensions

#71

Post by mingodad »

For others interested in alternative syntax to the Lua VM/API sometime ago I've created LJS https://github.com/mingodad/ljs and also https://github.com/mingodad/ljsjit, I've also included an utility lua2ljs program based on the Lemon parser and re2c that convert Lua scripts to LJS with line by line synchronization https://github.com/mingodad/ljs/tree/master/lua2ljs, to test it I've also translated a few non trivial projects (https://github.com/mingodad/ZeroBraneStudioLJS , https://github.com/mingodad/raptorjit-ljs, https://github.com/mingodad/snabb-ljs, https://github.com/mingodad/premake-core/tree/ljs, https://github.com/mingodad/CorsixTH-ljs).

I'm proud of it and thankfull to the Lua/Luajit projects.

Re: LuaJIT 3.0 proposed syntax extensions

#72

Post by valorzard »

ianm218 wrote: post #34

Tangently related but I’ve been deep in Lua recently working on a rust implementation that supports Lua 5.1-5.5 in one Rust Binary https://github.com/ianm199/omnilua . My ultimate goal was to support LuaJIT in Rust as well but this does not make it easier.

Also, one issue I have with this repo is that, since so much of it seems to use Claude, as an actual human I struggle to read and parse any of the information.

For example, what’s the performance like?

Re: LuaJIT 3.0 proposed syntax extensions

#73

Post by Joker_vD »

_flux wrote: post #65
Joker_vD wrote: post #58

Earlier quoted context omitted.

Well, I believe there could be some complications with parsing related to the fact that Lua grammar doesn't really requires semicolons between the statements. But other than that, yeah, detecting "if" in the expression position is pretty unambiguous. No idea why most languages went with "cond-expr ? then-expr : else-expr" bracketed syntax instead.

Surely the most likely explanation is familiary from C? But e.g. ml-family languages (like OCaml, F#, Haskell) and Rust just have the *if* expression that has a non-void value. If your language accepts expressions as statements (most do?), then I think that should just be compatible out of the box.

Yes, but why C had that syntax? Oh, right, because it didn't use if-then[-else]-end for the conditional statement, and reusing if(cond)[-else] with prohibited braces would be awkward.

Oh, and Lua most famously does not accept expressions as statements. Which, now that I think of it, would actually evade most of the parsing complications.

Re: LuaJIT 3.0 proposed syntax extensions

#76

Post by astrobe_ »

kibwen wrote: post #27

Please don't, inscrutable bitwise operators are an accident of the past even in systems languages, let alone in a scripting language. I'm not against infix operators for bitwise operations, just please spell them out with keywords rather than giving them sigils. Likewise, going from `and` and `or` to `&&` and `||` would be a dispiriting regression. This is something that Zig got right.

You can have them in C/C++ at least [1]

[1] https://en.cppreference.com/cpp/language/operator_alternativ...

Re: LuaJIT 3.0 proposed syntax extensions

#78

Post by Mond_ »

Dylan16807 wrote: post #61
kibwen wrote: post #27

Please don't, inscrutable bitwise operators are an accident of the past even in systems languages, let alone in a scripting language. I'm not against infix operators for bitwise operations, just please spell them out with keywords rather than giving them sigils. Likewise, going from `and` and `or` to `&&` and `||` would be a dispiriting regression. This is something that Zig got right.

What kind of person understands and needs bitwise operators but can't easily remember & | ~ and the arrows for shift? It's very little information. The part I'd call a hassle is the different kinds of right shift but you have that same hassle if you use keywords. I like using the and/or keywords for logical operations. Now let's make bitwise look significantly different from that.

It's not about having to remember them, it's that you shouldn't waste these short single symbols on operations that are only rarely used.

This stuff (especially the ternary) are a step backwards. There is just no reason to waste | on a bitwise or that gets used at 1% of the frequency of the standard or. In the future you might have a better use for it (pipeline syntax, sum or union types come to mind in other languages).

I dislike basically everything about these syntax extensions.

Re: LuaJIT 3.0 proposed syntax extensions

#79

Post by camgunz »

One of the interesting things about Lua is because they don't really maintain compatibility between major versions, there isn't a huge ecosystem, and as a result there's less friction against making your own, slightly incompatible version. When you add on the simplicity of implementing the language, it's created a really diverse set of lua-alikes. Weird (and cool) for a language to have a diverse ecosystem of implementations, but not necessarily libraries.

Re: LuaJIT 3.0 proposed syntax extensions

#80

Post by lionkor »

doophus wrote: post #67
Ardren wrote: post #49

> For compatibility with other computer languages, the following classic Lua operators can be written in a more customary syntax: Why though? What does changing `and` to `&&` actually achieve? Were people confused? Changing the syntax seems very surface level. It's not actually fixing any problems, just making Lua no longer look like Lua. It's not going to help anyone write/learn Lua. It will make everything more com…

> Why though? What does changing `and` to `&&` actually achieve? Were people confused? Also consider AI, that has a greater training base of JavaScript than Lua. So making Lua look more like JS, should improve output and reduce mistakes.

No, don't consider AI.
Post reply on HN