In article <qijlonf7cgm.fsf@lambda.ai.mit.edu>,
Olin Shivers <shivers@ai.mit.edu> wrote:
> From: wilson@cs.utexas.edu (Paul Wilson)
> Newsgroups: comp.lang.scheme,alt.lang.scheme.scsh
> Date: 2 Jan 1996 15:49:29 -0600
>
> [...]
>
>Actually, I think the literal-by-default choice is better adapted to shells
>than the variable-by-default choice. Most tokens in my interactive
>commands -- and even in my /bin/sh shell scripts -- are intended as
>constant file-names, program switches, or arguments. If you notice,
>I *kept* this design decision in scsh.
I had noticed this, and I wasn't criticising it---it's one of the things
I like about scsh, which I like pretty well generally.
[...]
> 1. Can we come up with a command syntax that's nice and terse for
> scripting purposes, but doesn't make it hard to write larger
> routines? Ideally, I'd like a syntax that works for both
> scripting and "real" programming, so I don't have to switch
> syntaxes. (Naturally, there would be no problem of interoperability
> of code written in different Scheme syntaxes---it's just sugar.)
>
>I claim scripting is real programming. Do this. Do that. Branch. Loop.
>It's not worth it to try and tease these two apart; they blur into each other.
Agreed.
> 2. How do we distinguish between calls to built-in or user-defined
> Scheme functions and commands that are sent to programs outside
> Scheme? For scsh, you currently have to explicitly indicate
> that you want to run a UNIX program by using a (run ...) form
> or whatever. I think this may be the right default for
> nontrivial programs, but for many scripts it's awkward. Somebody
> (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.
>
>Argh. This is the fundamental error of just about everyone who tries the
>functional-language-Unix-shell game. I discuss this at length in my paper on
>scsh. (See the section on the Tao of Scheme and Unix.) The two paradigms do not
>match semantically, so trying to match them up syntactically is bound to
>lose. (BTW -- if you want to track down the Ellis paper Paul mentions above,
>my scsh paper cites it.)
I wasn't really advocating trying to unify the semantics of UNIX and
Scheme---I agree that that can't be done well in the general case.
And I think it's dangerous to have things defaulting to "run whatever's
out there if you can't figure out in here." But there's a convenience
issue here.
I was really more interested in syntactic convenience for a very terse
interactive-or-trivial-scripting mode. For typing commands or scripts
of a few dozen lines at most, I think it's reasonable to default
to running a UNIX program. This would just be syntactic sugar for
a (run ...) form, and it'd be understood---one hopes---that it's *just*
a terseness hack.
I don't think this is horribly ugly, even if it's not something you want
to have as the default in nontrivial programs. Normal Scheme already does
things based on the binding of whatever symbol is in the head position
of a form. E.g., if there's a procedural binding, then the argument
forms are evaluated in the usual way, but if there's a macro binding,
they're not. We just add the rule that if there's no Scheme binding,
it's a run command.
The nice thing about this is that you can combine the conveniences
of Ellis's Lisp shell and scsh. You use a syntactic default akin
to macros to detect when there's an implicit run, and it controls
the evaluation of arguments---namely by implicitly backquoting them.
You get terse run commands, and terse arguments---you don't have to
quote filenames, etc.
The downside is that this requires people to know the difference
between procedure names and program names, so that they can read the
code without confusing program-running with procedure calling. In
practice, I don't think this is a problem. Scheme looks different
enough from UNIX that most people will have no problem discriminating
between Scheme procedures and UNIX commands.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|