From: Bruno.Verlyck@inria.fr
To: zack@cs.unibo.it
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Cash 0.20
Date: Wed, 28 Aug 2002 16:05:04 +0200 [thread overview]
Message-ID: <200208281405.g7SE54E30702@waco.inria.fr> (raw)
In-Reply-To: <20020828132641.GD3270@cs.unibo.it> (zack@cs.unibo.it)
Date: Wed, 28 Aug 2002 15:26:41 +0200
From: Stefano Zacchiroli <zack@cs.unibo.it>
Mail-Followup-To: Inria Ocaml Mailing List <caml-list@inria.fr>
On Wed, Aug 28, 2002 at 03:01:32PM +0200, Bruno.Verlyck@inria.fr wrote:
> API of Scsh (0.5.3), the Scheme Shell by Olin Shivers. It's designed for
> writing standalone Unix programs and shell scripts (but rather *not* for
> interactive command use).
Do you have planned a future "interactive command use" release?
No. One of Olin Shivers points in designing Scsh was that an
interactive command language has to be terse to the point of being
write-only. (See below an excerpt of
http://www.scsh.net/docu/scsh-paper/scsh-paper-Z-H-4.html.
Read the intro -- the `Prologue' --, too: it's delightful!)
He chose to focus on the programming language side. As command
languages, shells are very hard to beat.
Of course, you can still type
ledit cash
followed by `open Cash;;' and get an interactive top-level where you
can type OCaml expressions :-).
Bruno.
Unix shells, such as sh or csh, provide two things at once: an
interactive command language and a programming language. Let us
focus on the latter function: the writing of ``shell scripts'' --
interpreted programs that perform small tasks or assemble a
collection of Unix tools into a single application.
[..]
There is a tension between the shell's dual role as interactive
command language and shell-script programming language. A command
language should be terse and convenient to type. It doesn't have to
be comprehensible. Users don't have to maintain or understand a
command they typed into a shell a month ago. A command language can
be ``write-only,'' because commands are thrown away after they are
used. However, it is important that most commands fit on one line,
because most interaction is through tty drivers that don't let the
user back up and edit a line after its terminating newline has been
entered. This seems like a trivial point, but imagine how irritating
it would be if typical shell commands required several lines of
input. Terse notation is important for interactive tasks.
Shell syntax is also carefully designed to allow it to be parsed
on-line -- that is, to allow parsing and interpretation to be
interleaved. This usually penalizes the syntax in other ways (for
example, consider rc's clumsy if/then/else syntax [rc]).
Programming languages, on the other hand, can be a little more
verbose, in return for generality and readability. The programmer
enters programs into a text editor, so the language can spread out a
little more.
The constraints of the shell's role as command language are one of
the things that make it unpleasant as a programming language.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
prev parent reply other threads:[~2002-08-28 14:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-28 13:01 Bruno.Verlyck
2002-08-28 13:26 ` Stefano Zacchiroli
2002-08-28 14:05 ` Bruno.Verlyck [this message]
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=200208281405.g7SE54E30702@waco.inria.fr \
--to=bruno.verlyck@inria.fr \
--cc=caml-list@inria.fr \
--cc=zack@cs.unibo.it \
/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