Newsgroups: comp.lang.scheme,alt.lang.scheme.scsh
Path: cantaloupe.srv.cs.cmu.edu!rochester!udel!news.mathworks.com!tank.news.pipex.net!pipex!peer-news.britain.eu.net!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: Perl, English, syntax for Scheme and shells (was Re: scsh in scm ...)
Message-ID: <DKq4wy.11z.0.macbeth@cogsci.ed.ac.uk>
Organization: Centre for Cognitive Science, Edinburgh, UK
References: <87loo1lnde.fsf@organon.serpentine.com> <1996Jan2.182220.11213@netlabs.com> <4cc999$424@jive.cs.utexas.edu>
Date: Fri, 5 Jan 1996 20:00:34 GMT
Lines: 101

In article <4cc999$424@jive.cs.utexas.edu> wilson@cs.utexas.edu (Paul Wilson) writes:

>The idea I'm toying with is to eliminate most of the parentheses in
>normal Scheme expressions, in a fairly straightforward way---by making
>them implicit in common expression types.  (Note: the following has
>not been thoroughly thought out.  Comments welcome, and flames to
>dev/null.)
>
>For example,
>
>   (define (foo bar baz)
>      (if bar
>          (quux (bleen baz))
>          (quux baz)))
>
>would look something like
>
>   def (foo bar baz)
>      if bar
>      then (quux (bleen baz))
>      else (quux baz)
>      fi
>   fed

Humm.  I think there are some good possibilities somewhere around
there.

One thing about Lisp-style syntax that's often not known / realized
outside the Lisp community is that the parens aren't as big a problem
as they seem, in part because, in well-indented code, you don't have
to pay close attention to the parens when reading.  Arity (e.g. car
takes one arg) and indentation already make the meaning sufficiently
clear.  It would be nice if we could exploit this.  (And maybe we
can gain something in simplicity by making indentation matter?)

And, of course, f(x) and (f x) are pretty close, so those parens
shouldn't be very objectionable.

Some infix operators might still be desirable.

But now I'm starting to lose the sense that this is much different
from other alternative syntaxes.  Perhaps it would be reassuring if
there were simple rules for converting back and forth (rather as
there were for the old-time Lisp M- and S-expressions).

>Note that I'm not defending Tcl here.  I personally can't stand Tcl, which
>is why I'm interested in coming up with a "command syntax" for Scheme shell
>programming.  Tcl has horrid rules for when things are evaluated and
>when they are not, with the wrong defaults.

Just so.  I've been surprised by "scripting languages" that seemed
rather complex as languages without having very interesting data
structures when Scheme/Lisp already seemed to provide a better model,
and was pretty easy to implement.

Unfortunately, most Scheme implementations have't been very suitable
for "scripting".

>  (Like many shell languages,
>you have to force evaluation of a variable, because the default is that
>things are not evaluated.  I prefer Lisp and Scheme's default, which
>is that things *are* evaluated, which would be a problem in that lots
>of literals would have to be quoted, except that many common literals
>are "self evaluating."  Apparently Ousterhout and most shell language
>designers have never caught on to self-evaluating literals, because
>they never learned Lisp.  So you end up with things like [set $a $a+1].
>I firmly believe that Scheme is a better basis for such things, if
>we come up with some handy syntax that can easily be explained.

I agree that Scheme is a better basis, but some careful thought,
tested on a range of examples, is needed.

In shell languages people expect symbols to be self-evaluating,
which is why you end up saying $a when you want one evaluated.
I don't think this is due only to muddled-thinking or ignorance.

>      (John Ellis?) did a Lisp shell several years ago, where any
>      unbound function name was assumed to be an indication that
>      the programmer meant to call a UNIX program.  So, for example,
>      if rm was bound, (rm foo) meant call the rm procedure, but if
>      rm was unbound, the shell would look for a unix program named
>      rm, and call it with the argument foo.

Shells also have command hashing, where they more or less figure out,
at some point(s), what all the available commands are.  "look for"
sounds slower than it probably would be in practice.

>      I think that for little scripts, something like this is a good
>      way to go.  This raises the question of how to decide when to
>      do it, and how to present the choice to the user.  I'd think
>      that for a shell language, this should be the default, but
>      the programmer should be able to turn it off.

How about setting the "path" to null?

>Comments?

Well, sort of.

-- jeff

