Re: suggestions for new version

[Mark@... (Mark Ian Barlow)]

N.B: I already made this suggestion to lhf in an earlier private email, but
     I thought it might be worth airing it again here on the list to see if
     there is any other support out there for the idea:

It seems to me (having tried it) that Lua is quite powerful enough to
perform well as an embedded language in another sense; the one where you
use cigarette-packet-sized PCBs and microcontrollers.

Previously this has been the province of Forth and stripped-down dialects of
Basic. Forths are generally the fastest, most compact and the most daunting to
non-technical users. These days you cannot really expect someone who just
bought a hardware widget to write Forth, just because they asked you to make
it fully user-programmable. Basics are, well, *very* basic and usually
incapable of providing the reflexive features you need to do this sort of
thing.

If you *don't* make a short-production-run device fully user-programmable,
and try to anticipate every use it will ever be put to, you are just letting
yourself in for endless support that erodes any profit you managed to
make selling the original device. :-[

I've seen at least one Forth that was as portable as Lua (written in ANSI C)
and it was actually not a lot faster. As RAM prices and their chip footprints
shrink, and microcontrollers get more powerful Lua's many advantages begin
look eminently affordable. Portable byte-code is great for cross-compilation
too; you don't _need_ a cross-compiler!

BUT...

Embedded systems don't generally have file (or even console) I/O. Often
there's just a serial port. You can often get a crippled "libc.lib" for
these systems that provides do-nothing stubs for the I/O functions.

You could eliminate iolib and tell your users they cannot use readfrom() etc.
You could also provide basic console I/O via your serial line, and define
an 'error' fallback that wrote the string to it but you would still need:

>>> A function lua_dochunk(void *) that executed a down-loaded copy of
    luac.out, held somewhere in memory.

As far as I can see this is *all* you would need, provided you are prepared
to fiddle with the linker and maybe write a few missing stubs yourself; a
cost I, at least, would be prepared to accept.

What do you think?
Is there anyone else out there thinking of doing this?
Have you already done it?

--  Mark Ian Barlow                Non-Linear Control Consultants Ltd.
    -----------------------------------------------------------------
    Mark@nlcc.demon.co.uk            Voice / Fax: +44 (0)1207 562 154