9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: roger peppe <rogpeppe@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] typed sh (was: what features would you like in a shell?)
Date: Thu, 16 Apr 2009 18:24:36 +0100	[thread overview]
Message-ID: <df49a7370904161024x193d1162s43ee4acbc56f0a78@mail.gmail.com> (raw)
In-Reply-To: <20090406035529.C9F5A5B21@mail.bitblocks.com>

2009/4/6 Bakul Shah <bakul+plan9@bitblocks.com>:
> On Thu, 02 Apr 2009 20:28:57 BST roger peppe <rogpeppe@gmail.com>  wrote:
>> a pipeline is an amazingly powerful thing considering
>> that it's not a turing-complete abstraction.
>
> "f | g" is basically function composition, where f and g are
> stream functions. Of course, this simple analogy breaks down
> the moment we add more input/output channels -- may be that
> is why anything beyond a simple pipeline seems to get people
> in trouble (see the rc output redirection thread).

actually, the analogy works fine if we add more
input channels - it's multiple output channels
that make things hard, as they mean that you have
an arbitrary directed graph rather than a tree, which doesn't
have such a convenient textual representation
and is harder to comprehend to boot.

in alphabet, i had a diagnostic channel, which was strictly
textual and not easily accessible from the language, which
was arguably not the best solution, but i didn't want things
to get too complex.

> To go beyond simple char streams, one can for example build a
> s-expr pipeline: a stream of self identifying objects of a
> few types (chars, numbers, symbols, lists, vectors).

the difficulty with s-exprs (and most nested structures, e.g. XML)
from a pipeline point of view is
that their nested nature means that any branch might contain unlimited
quantities
of stuff, so you can't always process in O(1) space, which is one of the
things i really like about pipeline processing.

i found a nice counter-example in the fs stuff - the fundamental type
was based around a "conditional-push" protocol for sending trees
of files - the sender sends some information on a file/directory
and the receiver replies whether to descend into that file or
not. the tree had a canonical order (alphabetical on name), so
tree merging could be done straightforwardly in O(1) space.

this kind of streaming "feels" like a regular pipeline, but you can't
do this with a regular pipeline. for instance, a later element in the
pipeline can prevent an earlier from descending into a part
of the file system that might block indefinitely.

every language has a trade-off between typed and untyped representations;
with alphabet i was trying to create something where it was *possible*
to create new kinds of types where necessary (as in the fs example),
but where it wouldn't be customary or necessary to do so in the
vast majority of cases.

perhaps it was folly, but i still think it was an interesting experiment,
and i don't know of anything similar.



  parent reply	other threads:[~2009-04-16 17:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-02 18:48 fgergo
2009-04-02 19:28 ` roger peppe
2009-04-02 20:27   ` tlaronde
2009-04-06  3:55   ` Bakul Shah
2009-04-06 11:09     ` erik quanstrom
2009-04-06 15:40       ` Bakul Shah
2009-04-06 16:02         ` erik quanstrom
2009-04-06 16:22           ` [9fans] typed sh maht
2009-04-06 16:56             ` erik quanstrom
2009-04-06 16:50           ` [9fans] typed sh (was: what features would you like in a shell?) Bakul Shah
2009-04-06 21:18           ` John Stalker
2009-04-16 17:24     ` roger peppe [this message]
2009-04-16 18:52       ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=df49a7370904161024x193d1162s43ee4acbc56f0a78@mail.gmail.com \
    --to=rogpeppe@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).