Re: Lua OS

[Jay Carlson <nop@...>]

On Apr 24, 2012, at 1:02 PM, steve donovan wrote:

> On Tue, Apr 24, 2012 at 6:13 PM, Jay Carlson <nop@nop.com> wrote:
>> My (sketchy) belief is that Lua syntax is not flexible enough to be
>> ergonomic for bouncing in and out of process interaction,
> 
> Fair enough, given that Bash is a silly programming language ;)

"On second thought, let's not go to Camelot. It is a silly place."

> The right tools for the job ...  I'm working on a little shell called
> luaish, which was an spin-off from my linenoise experiments.  

linenoise is just killing me; one of my nervous habits when thinking about what I'm typing is C-a C-k C-y, which is idempotent and mostly has the same result as C-e. Also, C-r is like the whole reason to have persistent history and it's still in the todo list. busybox has this problem too, but at least I can probably hook the lua version if it really bugs me enough.

Of all the readline bindings, the one I wish somebody had told me about earlier was C-o. On line n in history, pressing C-o is like pressing RET, then placing the cursor at the end of line n+1. So after you've found something with C-r, you can run the next sequence of commands with C-o C-o C-o.

> It does
> completion on global Lua variables (st<tab>.s<tab> gives you
> string.sub, for instance), shortcuts (like 'fn' for function) but also
> has a shell sub-mode; if a line begins with . then it's assumed to be
> a shell command, _plus_ the completion then works on filenames.  So
> the languages are kept quite separate.

That usage model makes language mixing not quite so bad. Much to new (and old) Lua programmers' confusion, each line of input to lua.exe is considered its own chunk; every now and then I still type "local a=1" and wonder why "a" isn't defined after that.

If you wanted your own shell language, the restriction to top-level chunks means there is not a lexical capture problem; any variables referenced in a ".grep $pattern" line would have to come from _G anyway. One thing you could do is

  DISPLAY=":1" 
  export"DISPLAY"

and all that implies about the interaction between the Unix environment and _G.

To allow use of shell commands inside of Lua, you could interpret

  .a: grep $pattern

as something like "function a() shell_dostring[[grep $pattern]] end" which would let you later do

  for _,pattern in ipairs(l) do a() end

Writing it that way then begs for

  .b: grep $pattern $1

The important bit would be that the $ syntax doesn't split; it's like shell single-quoting. It is not a string expansion. You'd write

  CFLAGS="-O2 -msoft-float -Wall"

and ".cc $CFLAGS a.c" would come out as

  cc '-O2 -msoft-float -Wall' a.c

What you really meant was

  CFLAGS=split"-O2 -msoft-float -Wall"

I suppose $@CFLAGS could do the split for you, or maybe $@CFLAGS means "I know what I'm doing, just pass this through." I dunno, I'm just using a hammer to attach /bin/rc to lua with a screw.

Lua's syntax feels less...ugly to append to strings than to append to arrays:

  libs = libs .. 'rt'
  libs[#libs+1] = 'rt'

This isn't really fair, since one is an operation on values and another is a mutator. I kinda wish libs[#+1]  worked. Still, []#+ all feel spiky or something. In makefiles, people lean heavily on

  libs += rt

and now that I think of it, allowing a +=  statement on tables is safer than binary + since the mutation is clear. I guess Array isn't so bad...

-- 
Jay

Twitter is the cocaine at the Web 2.0 disco.