On Sun, 12 Jan 2020 at 21:13, Warren Toomey <wkt(a)tuhs.org> wrote: Discussion is just busy enough that it's good to keep things somewhat on track :-). I have something that has been lurking on my ToDo list that's on this trail in what I'd think is a relevant way :-) ~/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." https://github.com/michaelmacinnis/oh 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. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"