* Re: [TUHS] OK, keep going on type checking
2020-01-13 2:13 [TUHS] OK, keep going on type checking Warren Toomey
@ 2020-01-13 22:38 ` Christopher Browne
2020-01-14 1:58 ` Richard Salz
0 siblings, 1 reply; 3+ messages in thread
From: Christopher Browne @ 2020-01-13 22:38 UTC (permalink / raw)
To: Warren Toomey; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]
On Sun, 12 Jan 2020 at 21:13, Warren Toomey <wkt@tuhs.org> wrote:
> 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!
>
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?"
[-- Attachment #2: Type: text/html, Size: 4784 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread