The Unix Heritage Society mailing list
 help / color / Atom feed
* [TUHS] OK, keep going on type checking
@ 2020-01-13  2:13 Warren Toomey
  2020-01-13 22:38 ` Christopher Browne
  0 siblings, 1 reply; 3+ messages in thread
From: Warren Toomey @ 2020-01-13  2:13 UTC (permalink / raw)
  To: tuhs

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!

Cheers, Warren

^ permalink raw reply	[flat|nested] 3+ messages in thread

* 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 --]

<div dir="ltr"><div dir="ltr">On Sun, 12 Jan 2020 at 21:13, Warren Toomey &lt;<a href="mailto:wkt@tuhs.org">wkt@tuhs.org</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">All, I&#39;ve had a few subscribers argue that the type checking<br>
thread was still Unix-related, so feel free to keep posting<br>
here in TUHS. But if it does drift away to non-Unix areas,<br>
please pass it over to COFF.<br>
<br>
Thanks &amp; apologies for being too trigger-happy!<br></blockquote><div><br></div><div>Discussion is just busy enough that it&#39;s good to keep things somewhat on</div><div>track :-).</div><div><br></div><div>I have something that has been lurking on my ToDo list that&#39;s on this trail</div><div>in what I&#39;d think is a relevant way :-)</div>~/GitWeb&gt; task project:shell | cat<br>ID Active Age Project Tag  Description Urg<br>-- ------ --- ------- ---- ----------- ----<br>24 2w     4w  shell   unix Oh Types      14</div><div class="gmail_quote"><br></div><div class="gmail_quote">Oh is a claimant to the notion of trying to evolve shells to &quot;better.&quot;</div><div class="gmail_quote"><a href="https://github.com/michaelmacinnis/oh">https://github.com/michaelmacinnis/oh</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">The name is probably not for the best, but it seems interesting.</div><div class="gmail_quote">MacInnis noted several problems common to shells, and somewhat</div><div class="gmail_quote">strong typing falls into the set of would-be solutions.  He noticed that</div><div class="gmail_quote">there have been lots of attempts to create shells that are embedded</div><div class="gmail_quote">in other languages, which seems universally to lead to them falling</div><div class="gmail_quote">into being curiosities.  Embedding scripts in Lisp or Python or Perl</div><div class="gmail_quote">never seems to turn out.  The pains he points at are...</div><div class="gmail_quote">- Undefined variables lead to bugs.  set -e -u and such may help, but are optional...</div><div class="gmail_quote">- automatically varadic functions can easily just lose parameters</div><div class="gmail_quote">- splitting lists on whitespace blows up when files are allowed to have spaces in their names</div><div class="gmail_quote">- return values intentionally look like process return codes, which can be good, or not...</div><div class="gmail_quote">- global variables are mostly all you have, preventing having much modularity</div><div class="gmail_quote">- variable expansions/rewrites have sometimes tortured syntax</div><div class="gmail_quote"><br></div><div class="gmail_quote">He built a shell that has a Scheme lying in behind (which I partly like, and partly</div><div class="gmail_quote">find suspicious).  Mechanisms to address the above are:</div><div class="gmail_quote">- data and code have the same syntax (conses)</div><div class="gmail_quote">- a richer type set (strings, symbols, return codes, a number tower of Int/Float/Rational, lists, environments)</div><div class="gmail_quote">- first class environments that support modularity</div><div class="gmail_quote">- Fexprs (see John N Shutt&#39;s thesis, vau: the ultimate abstraction) allow implementing your own control structures<br></div><div class="gmail_quote">- dynamic communications patterns (Rob Pike did a paper on this, on Squeak)</div><div class="gmail_quote">The early bits point at Scheme; dynamic comm points at Go channels, and the shell is written in Go.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I have had this percolating in my head the last few weeks, and I watched the recent <br></div><div class="gmail_quote">conversation about what &quot;:&quot; means with interest, as Oh makes interesting use of :,</div><div class="gmail_quote">using it to indicate that the remaining portion of a command line is to be evaluated/expanded, thus:<br></div><div class="gmail_quote">oh$ write: div 65536 256 2 (add 4 3)<br>128/7</div><div class="gmail_quote">oh$ define lc3: quote: a b c<br>oh$ echo $lc3<br>a b c</div><div class="gmail_quote"><br></div><div class="gmail_quote">For a wee while, I was getting quite tortured by its interpretation (that I had not yet internalized) of :</div><div class="gmail_quote"><br></div><div class="gmail_quote">I have been unable as of yet to decide if the author&#39;s on to something, or if this is a mere curiosity.<br></div><div class="gmail_quote">-- <br></div><div dir="ltr" class="gmail_signature">When confronted by a difficult problem, solve it by reducing it to the<br>question, &quot;How would the Lone Ranger handle this?&quot;<br></div></div>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [TUHS] OK, keep going on type checking
  2020-01-13 22:38 ` Christopher Browne
@ 2020-01-14  1:58   ` Richard Salz
  0 siblings, 0 replies; 3+ messages in thread
From: Richard Salz @ 2020-01-14  1:58 UTC (permalink / raw)
  To: Christopher Browne; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

A custom struct conveys information to those applications that have the
struct compiled-in (assuming C).
A string version of the same struct data also works for those applications
that would know the struct, but is also useful to a whole bunch of other
tools.
Yeah, there's round-off errors for floating point numbers I suppose, but
the trade-off seems like infinite to approximately zero, no?

[-- Attachment #2: Type: text/html, Size: 476 bytes --]

<div dir="ltr"><div dir="ltr"><div>A custom struct conveys information to those applications that have the struct compiled-in (assuming C).</div><div>A string version of the same struct data also works for those applications that would know the struct, but is also useful to a whole bunch of other tools.</div><div>Yeah, there&#39;s round-off errors for floating point numbers I suppose, but the trade-off seems like infinite to approximately zero, no?<br></div></div></div>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git