MIT 6.001

[James A. Crippen]

On Mon, 9 Nov 1998, Ray Dillinger wrote:

> Excuse me?  It's as much a LISP as any other dialect -- Common
> Lisp, Scheme, Elisp, Symbolics LISP, etc, as well as other
> dialects, even non-standard ones like that implemented by scsh
> (which is "almost" scheme... ) are all under the "big tent"....
> LISP is a large family of languages, not a single standard.

I suppose that I should say "not a pure LISP" tho scheme and friends are
all 'lispish' languages.  Maybe we need some exact way of referring to
the LISP family of languages vs some flavor of Lisp which has
[Ll][Ii][Ss][Pp] in its name, or resembles McCarthy's LISP close enough to
merit the name.  How 'bout 'LISP' to be the family, and 'a Lisp' for some
Lisp language that purports to be descended and has clear features of Lisp
vs others.  Scheme's -? is markedly different from the -p of Lisp, and
I've always felt that this was a distinctive feature of Lisp vs other LISP
languages.  Maybe I'm just babbling.  Whatever.
 
> There is no standard for LISP, per se, at least not one that's
> been implemented in the last twenty years.  If you want to go
> back to when McCarthy was developing it, I think that's the last
> time LISP was really just *one* language.  And that's not a
> dialect I'd really like to work with now that we've spent so
> many years developing the ideas and forms.  

I've got a LISP 1.5 or very similar somewhere.  IIRC it's for running on
Bob Supnik's PDP11 emulator or somesuch.  I'll look.  It might be
interesting for historical reasons if anything.
 
> Huh??  The REPL *is* a CLI interface. The reason nobody else has
> written another CLI for scsh is probably because (personal
> opinion follows) it's the best of all possible CLI interfaces.

I have to disagree.  Scsh is truly much better than, say, sh, which has
minimal command line editing capabilities, but in comparison with the
ifaces of bash and zsh which support emacs-like point movement and such,
and have a history system, schs's iface tends to get somewhat aggravating.
On top of that, if your terminal is malconfigured you have to deal with
the ^H problem (esp if you don't have terminak docs available, like on a
PR1ME terminal I once worked on) amongst other terminak-lossage.  The
input system of scsh is still wanting much refinement IMHO, and should
find some way to integrate the GNU readline library for all those nifty
command line editing features.  Most things beyond the input system are
remarkable thourough, and very satisfying.  But lacking the ability to go
back a line and change some typo drives me nuts!  If I was more motivated
I'd add the support myself, but I just haven't had the bother.  Maybe I'll
look into it, but since the scsh team has (seemingly to me) been avoiding
it I have somewhat mixed feelings about the task.  Time to print out the
bash source and see how they do it, I suppose.
 
> Of course, the power is unparalleled in CLI's, as you note:  I
> find it a lot clearer than most CLI's. 
> 
> But the coolest thing about a REPL shell, really, is that it's
> the *same* language you use to do programming.  I'd like to see
> more "standard" commands for it, but absolutely do *NOT* want to
> see more another *mode* of interaction with it.

Oh, not really a mode, per se, but just a more advanced input system from
the terminal.  Perhaps I should have made that more clear in my previous
mesg.
 
> Having a REPL command-line provides a learning curve with no
> sharp edges for people getting into programming, which *is*
> important.  It provides a shell you can get used to, and then
> you don't have to ask idiot questions like "how do I list a
> directory or read a file in this programming language", because
> once you get the command line, you already know.

I quite agree, and I think that we've had a bit of confusion here.  I
don't mean to make the /language/ any different, but just the way it
handles control characters, terminal escape codes, and the like.  Being
able to go back some lines would be nice too.  I think that that would
require a heavy amount of curses programming, tho, and C is /not/ my
favorite language.

  And
> conversely, your programming talent, practice, and expertise
> will make you wizardly at the command line.  A REPL command line
> is one of the primary *features* I want in a LISP operating
> system, not something that "will do until we get a real CLI
> ready."  Scsh is my default shell for exactly that reason.

I agree, most wholeheartedly AAMOF.  The REPL is vital to maintaining the
LISP look-n-feel, and on top of that is really vital to the entire LISP
system.  A LISP language w/o a repl is somewhat stunted, and probably
doesn't have a decent method of dealing with reatables or the like.  REPLs
don't just provide a method of code input, they are the one of the main
reasons why LISP can be so useful.  Not being able to fiddle with the
reader, ro the eval fn would just cripple anyLISP system.
 
> Sadly, there are things you "just can't do" in Scsh, which you
> address below (termcap functions).  These are not a matter of
> having a different interaction mode, these are a matter of the
> language needing to be extended...  :-)  I think we agree though 
> on the basic form of what we want....

So we do.  Great minds think alike ;-)
 
I jusdt thought of another thing.  Somewhere in the library is an
INTERLISP manual.  I remember from it a bit about the input syntax that
struck me as somewhat unique and interesting.  INTERLISP had a sort of
EVALQUOTE instead of the usual EVAL, ie itperformed some strange parsing
on its input before it evald.  I don't recall what, tho.  I'll read up on
that and return.  The one thing that I did remember was that the input
syntax was more like
* foo(bar baz)
instead of the usual
* (foo bar baz)
and I seem to remember this method allowed much simpler cmdline
interaction.  Maybe I'm wrong, but as I said I'll look it up.  Some
stripping of parens is in order if scsh is going to be useful as an
interaction shell, as most people dont want to type
* (list-directory ".")
or similar to get things done.  I think most people would agree that saying
* ls(.)
or so would be easier.  (LISPers will agree that we are not 'most
people' however.)  Nice thing is that that all can be implemented as
scheme fns in some startup file, but some predefd defns are in order to
keep things close to sane.

BTW, I agree that modees are bad, and I dislike modeful things in general.
The only reason I tolerate vi is because as a *nix user it's guaranteed,
whereas emacs isn't.  (And on my 486 it's a often quite a bit faster in
many cases.)

Oh, INTERLISP's input syntax had a /lot/ to do with the way DWIM worked,
too.  And DWIM is, well, hairy.

cheers,
james

--
James A. Crippen, CS/Math tenured undergrad	<<Lambda calculus	.-.
crippenj@saturn.math.uaa.alaska.edu		  über alles!>>		   \
If the future isn't what it used to be, does that mean that the past	   /\
is subject to change in times to come?					  /  \