All, I've had a few subscribers argue that the type checking
thread was still Unix-related, so feel free to keep posting
here in TUHS. But if it does drift away to non-Unix areas,
please pass it over to COFF.

Thanks & apologies for being too trigger-happy!

~/GitWeb> task project:shell | cat
ID Active Age Project Tag  Description Urg
-- ------ --- ------- ---- ----------- ----
24 2w     4w  shell   unix Oh Types      14

Oh is a claimant to the notion of trying to evolve shells to "better."

The name is probably not for the best, but it seems interesting.

MacInnis noted several problems common to shells, and somewhat

strong typing falls into the set of would-be solutions.  He noticed that

there have been lots of attempts to create shells that are embedded

in other languages, which seems universally to lead to them falling

into being curiosities.  Embedding scripts in Lisp or Python or Perl

never seems to turn out.  The pains he points at are...

- Undefined variables lead to bugs.  set -e -u and such may help, but are optional...

- automatically varadic functions can easily just lose parameters

- splitting lists on whitespace blows up when files are allowed to have spaces in their names

- return values intentionally look like process return codes, which can be good, or not...

- global variables are mostly all you have, preventing having much modularity

- variable expansions/rewrites have sometimes tortured syntax

He built a shell that has a Scheme lying in behind (which I partly like, and partly

find suspicious).  Mechanisms to address the above are:

- data and code have the same syntax (conses)

- a richer type set (strings, symbols, return codes, a number tower of Int/Float/Rational, lists, environments)

- first class environments that support modularity

- Fexprs (see John N Shutt's thesis, vau: the ultimate abstraction) allow implementing your own control structures

- dynamic communications patterns (Rob Pike did a paper on this, on Squeak)

The early bits point at Scheme; dynamic comm points at Go channels, and the shell is written in Go.

I have had this percolating in my head the last few weeks, and I watched the recent

conversation about what ":" means with interest, as Oh makes interesting use of :,

using it to indicate that the remaining portion of a command line is to be evaluated/expanded, thus:

oh$ write: div 65536 256 2 (add 4 3)
128/7

oh$ define lc3: quote: a b c
oh$ echo $lc3
a b c

For a wee while, I was getting quite tortured by its interpretation (that I had not yet internalized) of :

I have been unable as of yet to decide if the author's on to something, or if this is a mere curiosity.

--