Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!sun-barr!lll-winken!uunet!mcsun!ukc!edcastle!aiai!jeff
From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.scheme
Subject: Re: To Lisp, or not to Lisp; that is the question.
Message-ID: <4322@skye.ed.ac.uk>
Date: 15 Mar 91 20:17:58 GMT
References: <9103080432.AA06368@kolyma> <455@data.UUCP> <4299@skye.ed.ac.uk> <PCG.91Mar13191008@aberdb.test.aber.ac.uk>
Reply-To: jeff@aiai.UUCP (Jeff Dalton)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 68

In article <PCG.91Mar13191008@aberdb.test.aber.ac.uk> pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) writes:
>On 11 Mar 91 18:23:32 GMT, jeff@aiai.ed.ac.uk (Jeff Dalton) said:
>
>jeff> But the language / environment distinction is also used _against_
>jeff> Lisp.  For example, I've heard people claim that no one really likes
>jeff> Lisp as a language.  It's the the _environment_ they like.  [I think
>jeff> this claim is false, by the way.]
>
>Actually I think exactly the opposite; 

Ok, but I didn't have you in mind for this example in any case.

>I love Scheme (and Lisp) as *languages*,

It's good to see we agree on some things.

>                                         and I think that their
>usual environments are regrettably overdone and isolated from the
>larger environment in which they are run, and so on.

I am a bit puzzled by this.  Most of the Lisps I use have a fairly
minimal environment (trace, step, a debugger); most of my programming
environment is in the editor.

Moreover, it's hard to see why these environmental features make
the environment overdone.

>jeff> I do not agree that EVAL is environment.  EVAL might be provided as
>jeff> part of the environment in Scheme -- because it's not part of the
>jeff> language.  But that does not mean it is inherently environmental.
>
>EVAL is the "compiler", really. An argument can be made that the 'C'
>environment is the whole of Unix, yet, so maybe since you can after all
>in 'C' write things to a file and then 'system("cc -c ...");' you can
>claim you have eval in 'C', in its environment, just like Scheme.

There are a number of evaluators (interpreters and compilers) for
languages inside Lisp.  LOOP and FORMAT are large-ish examples, but
many other things can be seen that way as well.  That does not make
them part of the environment, so why should an evaluator in a language
L suddenly be environment when the language it evaluates is L rather
than something else.

You are moreover wrong about C.  For C to have something equivalent
to EVAL it is not enough that it be able to write source code to
files and then call the operating system to compile the file.
It would also have to be able to load the compiled code into the
running C program that wrote the file and called the compiler.

And even that wouldn't be fully equivalent, because code passed
to a Lisp EVAL can contain objects that cannot be written to
files.

>jeff> In most Lisps, it is part of the language.  In this it is
>jeff> different from LOAD.  EVAL is not just another way to get programs
>jeff> into execution.  It is not just an alternative to LOADing them, or
>jeff> typing "lisp <filename>" to the shell.
>
>It depends on whether you look at the Lisp implementation as a virtual
>machine on its own, or on whether you see it as a module of the
>environment of the underlying OS. In the former case, EVAL is indeed
>part of the 'language' :-).

I think you are being confused by the idea that EVAL is the compiler.
If that was all there was too it, there'd be no reason to want to have
EVAL in Scheme.

-- jeff