Since I've seen some Forth expertise/interest in evidence here, so I'll
permit myself some observations on Lua/Python/Forth.
Lua's scripting command syntax is pretty simple, though different from
Python's. It is reference- and not variable-oriented (that is, "variables"
are merely holders for references, not values) and smacks of Python in this
regard. Functions are first-class objects; again, very similar to Python.
The big differences (for me) are two:
1) Lua is designed to be driven "from the outside" by an embedding host
program and needs to be extended via C to fulfill its stated purpose of
providing an embeddable, extendable scripting language, so the Lua C API is
much more important to me as a Lua programmer than the Python API has been
to me as a Python programmer.
2) The Lua API is stack-based, so your C extension code pushes, pops and
otherwise manipulates values on the Lua stack. These values aren't simple
processor scalars; you can push a table onto the stack, whose elements can
be tables containing tables and so on and so forth. Speaking of forth, the
Lua C API has very much the flavor of Forth on steroids. You play the same
kind of stack games, but the command prompt on the other side of Lua can be
used like an object-oriented scripting language.
One very cool aspect of Lua is that the entire state of a "Lua virtual
machine" is encapsulated in the "Lua state" data structure. This means no
hidden global variable sharing at the C language level, so you can easily
instantiate a new Lua "session" to handle each concurrent incoming socket
session in a server if you wish, and keep them all perfectly separate. To
me, that means that I can extend Lua with the appropriate C routines and
then script socket sessions in an object-oriented fashion without leaving
the comfort of my C compiler (old habits die hard). While this would be a
useless tour de force on the PC or Unix, it's actually very useful on my old
Tandem K100 4-CPU fault-tolerant system. The file system has only one level
of directory per disk volume (ack!) and so a port of Python or Java would
only be an exercise in masochism. Later Tandems sport a POSIX personality
(called OSS, or Open Systems Services), but my K100 dates from an earlier
time when mainframes still roamed the earth. Flattening the Lua source tree
to fit on the K100 wasn't too hard, and there isn't anything in Lua's
operation that requires directory nesting in the filesystem.
Aside:
It was kind of fun to draw on my previous experience with Forth in grokking
the Lua C API. For a real blast from the past, check out the Open Firmware
initiative, which has adopted Forth as the language of it's BIOS code
loader. In the future, you may be able to buy some hardware, talk to a
little Forth kernel in ROM somewhere, decide how to load a real machine
BIOS, and then set it going prior to the actual OS boot.
Before reading about Open Firmware, I had assumed that Forth had completely
dropped out of sight. Anyone else aware of counterexamples ?
permit myself some observations on Lua/Python/Forth.
Lua's scripting command syntax is pretty simple, though different from
Python's. It is reference- and not variable-oriented (that is, "variables"
are merely holders for references, not values) and smacks of Python in this
regard. Functions are first-class objects; again, very similar to Python.
The big differences (for me) are two:
1) Lua is designed to be driven "from the outside" by an embedding host
program and needs to be extended via C to fulfill its stated purpose of
providing an embeddable, extendable scripting language, so the Lua C API is
much more important to me as a Lua programmer than the Python API has been
to me as a Python programmer.
2) The Lua API is stack-based, so your C extension code pushes, pops and
otherwise manipulates values on the Lua stack. These values aren't simple
processor scalars; you can push a table onto the stack, whose elements can
be tables containing tables and so on and so forth. Speaking of forth, the
Lua C API has very much the flavor of Forth on steroids. You play the same
kind of stack games, but the command prompt on the other side of Lua can be
used like an object-oriented scripting language.
One very cool aspect of Lua is that the entire state of a "Lua virtual
machine" is encapsulated in the "Lua state" data structure. This means no
hidden global variable sharing at the C language level, so you can easily
instantiate a new Lua "session" to handle each concurrent incoming socket
session in a server if you wish, and keep them all perfectly separate. To
me, that means that I can extend Lua with the appropriate C routines and
then script socket sessions in an object-oriented fashion without leaving
the comfort of my C compiler (old habits die hard). While this would be a
useless tour de force on the PC or Unix, it's actually very useful on my old
Tandem K100 4-CPU fault-tolerant system. The file system has only one level
of directory per disk volume (ack!) and so a port of Python or Java would
only be an exercise in masochism. Later Tandems sport a POSIX personality
(called OSS, or Open Systems Services), but my K100 dates from an earlier
time when mainframes still roamed the earth. Flattening the Lua source tree
to fit on the K100 wasn't too hard, and there isn't anything in Lua's
operation that requires directory nesting in the filesystem.
Aside:
It was kind of fun to draw on my previous experience with Forth in grokking
the Lua C API. For a real blast from the past, check out the Open Firmware
initiative, which has adopted Forth as the language of it's BIOS code
loader. In the future, you may be able to buy some hardware, talk to a
little Forth kernel in ROM somewhere, decide how to load a real machine
BIOS, and then set it going prior to the actual OS boot.
Before reading about Open Firmware, I had assumed that Forth had completely
dropped out of sight. Anyone else aware of counterexamples ?
Comment