Hacker News Reader

Comment by saulpw | Hacker News Reader

> The build-time "yacc and lex"-based level compiler, the "yacc and lex"-based dungeon compiler, and the quest text file processing previously done by NetHack's "makedefs" utility, have been replaced with Lua text alternatives that are loaded and processed by the game during play.

This is very likely a good choice for multiple reasons, but it's truly the end of an era. (NetHack predates Lua, which has been around since 1993.) Lex and yacc are dead, long live lex and yacc!

View on HN

Lua is not on base on most distros, that's sad. Also it stops being as portable.

By Amiga 68k platforms then. And maybe DOS.

Also, there no official Nethack i686 builds.

If I were them I'd try some micro-language from https://t3x.org as a pre-processor and bundle it. The T3X0 language itself can do wonders and even be ported to DOS with ease.

EDIT: ok, Lua can be portable and even they got DOS ports, this is great.

There are also official Amiga binaries. :)

The Amiga port was resurrected just a few weeks ago.

https://mastodon.social/@ipaschke@cyberplace.social/11625728...

Great; hope they can made further ports to m68k Macs and Ataris.

> By Amiga 68k platforms then.

https://nethack.org/v500/ports/download-amiga.html

> And maybe DOS.

https://nethack.org/v500/ports/download-msdos.html

The lua 5.4 sources are less than 1 megabyte in size and are MIT licensed. You can link against it but it's just as easy to directly compile it into your application directly.

Good, kinda like JimTCL-small then :)

> Lua is not on base on most distros, that's sad. Also it stops being as portable.

Huh? Usually programs just embed a Lua interpreter, I think. Famously light.

Nethack embeds Lua 5.4.8, so you don't need it installed from a distribution's package manager. As long as your system can build C99* it can build Lua. And given that Nethack 5.0.0 is C99, this dependency is not reducing portability any further.

* Lua has a LUA_USE_C89 flag so it may be more portable than Nethack 5.0.0 at this point.

> LUA_USE_C89

How much functionality/performance does one lose with this flag? Genuine question, I don't know.

If C89 and C99 were equally performant/functional, it would seem logical to just target C89 (since any C99 compiler should be able to compile C89 too). There must be some reason it's a flag.

I downloaded a Lua 5.4.8 source tarball and checked all the uses of LUA_USE_C89 (manually, without AI):

luaconf.h:50-655

- windows builds always use C89 (quote: "broadly, Windows is C89")

- in C99 Lua uses 'strtod' and 'sprintf' for hex number conversions. Otherwise, Lua provides its own implementation.

- no math function variants with l_ and f_ prefixes in C89

- optional lua_KContext type is not available with C89

llimits.h:79

- type definition C99: uintptr.t vs C89: size_t

llimits.h:184

- in C99 or GCC Lua has a pragma for inlining functions, otherwise it's macro'ed to nothing

lmathlib.c:176

- math_log has an additional optimization in C99

    if (base == l_mathop(2.0))
      res = l_mathop(log2)(x);
    else

lmathlib.c:285

- LUA_RAND32 define might fail to find 64-bit type (comment says it's for testing)

loslib.c:36

- `strftime()` only supports one-char options in C89

lprefix.h:14

- no _XOPEN_SOURCE with C89 (POSIX/XSI stuff) - no _LARGEFILE_SOURCE with C89 (manipulation of large files in gcc and other compilers)

both of these defines don't appear anywhere else in Lua source code

Thank you for looking through that; that's very interesting and helpful.

Reply on news.ycombinator.com