From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 95e16b98 for ; Mon, 13 Jan 2020 22:38:42 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 938CA9BCC3; Tue, 14 Jan 2020 08:38:41 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3D26A9B841; Tue, 14 Jan 2020 08:38:19 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="iOeb8Rxt"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 194879B841; Tue, 14 Jan 2020 08:38:17 +1000 (AEST) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by minnie.tuhs.org (Postfix) with ESMTPS id 7D7239B804; Tue, 14 Jan 2020 08:38:16 +1000 (AEST) Received: by mail-vs1-f47.google.com with SMTP id y125so6980401vsb.6; Mon, 13 Jan 2020 14:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+KroZzT3/a9ZtBx5dLjFA87EmnbEh1HZmL5Q93Ohzps=; b=iOeb8RxtaEgbPTd+dPTRx9043Ploc08FGnJn8moItYQqrVH2bxxzSZJPUWwSa0wFCM sWkKVzXr300s2ajLNcLxe7jZISl/FnBxdppRokUpFgfpvyCePP7woPAo8YEPHXwcpIF4 QMEKbq6jYJn38ASPB8lXq62l72S9NZhcwuypwOguCOHB5tYl2Fw/r/QRNd2nnHcDaI54 PN4Q60TKsREa3FVlBF9TWGXQ9p7oyZLZ18aUYemKTiGlMAIAxtlCs3A7YJTxMatx0t99 S5rgnYVH+PIm+rGA1OrAE9caYipw+4CY9K7rRrNwkr9LMpBs0l5Byxb4LwYUL4zqjGQ1 jL2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+KroZzT3/a9ZtBx5dLjFA87EmnbEh1HZmL5Q93Ohzps=; b=c8WnxR+ltZ0+KWXmurf4rhCCR3HKlHeMp3IDC60fczyuNL04SJitH13dlkIzXesyiu CoDbxExkJ6PTQ+zcrdjZLRND0dVjWZ5P/oKKhCrKEEm9SB/Kr/jzARsM7QDSG5Nc4lCy S9n+purl58+sNWEPcraVorVXH9KGolBMVRe1Wb1WAVGBqgmr2QyJpWQSL9IdSYvnM+EC hGKS5zaKB8wgb6irgVFRfG3S5I+5AX2se1K5QbBWQaz3RHMmUjOQoZxLKZ3pp8y/PoJQ fmXnE/Dx2sYMkC3rJeNn3a/Si8Oe4sSjMmzDjMeF/pDRWnfmJzG+/Lec8O53dXx+pSKY GlYw== X-Gm-Message-State: APjAAAW6ewYS5qDvYathFoLAzqD0wdWExjE8dv9tKmyyQZ3nzEkvisLN Xl5jIjlk6J+8KRWWj+7UzrW8Hhm8hoR90Iv2DrPQ4MMZtcyVXg== X-Google-Smtp-Source: APXvYqwDfhav+Skssn/iEU829OM5UkncauSXFiqs8l9gCpqOm8SPMbUkwrtF+nwYxoRl9mQzlWugW2BzCgWkLqxHT94= X-Received: by 2002:a67:be13:: with SMTP id x19mr9791015vsq.20.1578955095245; Mon, 13 Jan 2020 14:38:15 -0800 (PST) MIME-Version: 1.0 References: <20200113021303.GA7633@minnie.tuhs.org> In-Reply-To: <20200113021303.GA7633@minnie.tuhs.org> From: Christopher Browne Date: Mon, 13 Jan 2020 17:38:03 -0500 Message-ID: To: Warren Toomey Content-Type: multipart/alternative; boundary="00000000000091868d059c0d217a" Subject: Re: [TUHS] OK, keep going on type checking X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000091868d059c0d217a Content-Type: text/plain; charset="UTF-8" On Sun, 12 Jan 2020 at 21:13, Warren Toomey 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?" --00000000000091868d059c0d217a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, 12 Jan 2020 at 21:13, Warren Toom= ey <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 thin= gs somewhat on
track :-).

I have somethi= ng 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 =C2=A0Description Urg
-- -----= - --- ------- ---- ----------- ----
24 2w =C2=A0 =C2=A0 4w =C2=A0shell = =C2=A0 unix Oh Types =C2=A0 =C2=A0 =C2=A014

Oh is a claimant to the notion of try= ing to evolve shells to "better."
https://github.com/micha= elmacinnis/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 i= nto the set of would-be solutions.=C2=A0 He noticed that
there have been lots of attempts to create shells that are em= bedded
in other languages, which seems univ= ersally to lead to them falling
into being = curiosities.=C2=A0 Embedding scripts in Lisp or Python or Perl
never seems to turn out.=C2=A0 The pains he points at a= re...
- Undefined variables lead to bugs.= =C2=A0 set -e -u and such may help, but are optional...
- automatically varadic functions can easily just lose paramet= ers
- splitting lists on whitespace blows u= p when files are allowed to have spaces in their names
- return values intentionally look like process return codes, w= hich can be good, or not...
- global variab= les 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, a= nd partly
find suspicious).=C2=A0 Mechanism= s to address the above are:
- data and code= have the same syntax (conses)
- a richer t= ype set (strings, symbols, return codes, a number tower of Int/Float/Ration= al, lists, environments)
- first class envi= ronments that support modularity
- Fexprs (= see John N Shutt's thesis, vau: the ultimate abstraction) allow impleme= nting your own control structures
- dyn= amic communications patterns (Rob Pike did a paper on this, on Squeak)
The early bits point at Scheme; dynamic comm po= ints at Go channels, and the shell is written in Go.

I have had this percolat= ing in my head the last few weeks, and I watched the recent
conversation about what ":" means with inte= rest, as Oh makes interesting use of :,
usi= ng it to indicate that the remaining portion of a command line is to be eva= luated/expanded, thus:
oh$ write: div 6= 5536 256 2 (add 4 3)
128/7
oh$ define lc= 3: quote: a b c
oh$ echo $lc3
a b c
<= br>
For a wee while, I was getting quite to= rtured by its interpretation (that I had not yet internalized) of :

I have been u= nable as of yet to decide if the author's on to something, or if this i= s a mere curiosity.
--
When confronted by a difficult problem= , solve it by reducing it to the
question, "How would the Lone Rang= er handle this?"
--00000000000091868d059c0d217a--