Hans-J. Kuckhoff wrote:
>
> Hi!
> Does anyone know where I can get a free release of a
> LISP-Interpreter running under DOS or Windows 3.x or
> Windows 95?
>
> Many thanks in advance
XLISP http://www.teleport.co/~almy/xlisp.html
CLISP ftp://ma2s2.mathematik.uni-karlsruhe.de/pub/lisp/clisp
ACL http://www.franz.com
····@toppoint.de (Hans-J. Kuckhoff) writes:
>Does anyone know where I can get a free release of a
>LISP-Interpreter running under DOS or Windows 3.x or
>Windows 95?
If you mean the Common Lisp dialect, you're pretty much out of
luck. All the systems listed in the FAQ are either compilers or
bytecode machine.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
···············@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536
"As far as I'm concerned, if something is so complicated that you can't ex-
plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
Martin Cracauer (········@wavehh.hanse.de) wrote:
: ····@toppoint.de (Hans-J. Kuckhoff) writes:
: >Does anyone know where I can get a free release of a
: >LISP-Interpreter running under DOS or Windows 3.x or
: >Windows 95?
: If you mean the Common Lisp dialect, you're pretty much out of
: luck. All the systems listed in the FAQ are either compilers or
: bytecode machine.
That doesn't mean that these systems don't include interpreters. When
I held a Lisp course in 1993, the students used CLISP on DOS boxes.
Of course, CLISP is bigger than what you'd expect as it includes also
a compiler.
Jo"rg Ho"hle.
············@gmd.de http://zeus.gmd.de/~hoehle/amiga-clisp.html
Joerg Hoehle (······@zeus.gmd.de) wrote:
: Martin Cracauer (········@wavehh.hanse.de) wrote:
: : [in] the Common Lisp dialect...
: : ...All the systems listed in the FAQ are either compilers or
: : bytecode machine.
: That doesn't mean that these systems don't include interpreters. When
: I held a Lisp course in 1993, the students used CLISP on DOS boxes...
I think the confusion might be between "interpreted" and "interactive".
If I understand correctly, systems like CLISP, GCL, and CMUCL will compile
functions as you type them in, often to some sort of byte code. This is a
one-pass incremental compilation, like what's done in Forth, I believe. To
the user, this compilation process is invisible, and is indistinguishable
from using an interpreter except that things run more quickly. Have I got
that right?
A "real" interpreter would store your functions in essentially the form you
typed them (it might lex them to tokens; the Commodore 64 Basic interpreter
did this), and interpret them from scratch each time it ran them.
There's the more obvious form of compiling (compile-file) which offers
further speed-ups, and is more remniscent of batch-compiled languages like
C or Pascal. I think this is typically a two-pass process.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
With a mighty <··········@world.std.com>,
·····@world.std.com uttered these wise words...
> I think the confusion might be between "interpreted" and "interactive".
> If I understand correctly, systems like CLISP, GCL, and CMUCL will compile
> functions as you type them in, often to some sort of byte code. This is a
> one-pass incremental compilation, like what's done in Forth, I believe. To
> the user, this compilation process is invisible, and is indistinguishable
> from using an interpreter except that things run more quickly. Have I got
> that right?
This is certainly possible. However, IME most Forth systems use two
modes of operation: 'compile' and 'immediate'. In compile mode, you're
defining a Forth definition, so a token may be compiled to a threaded
address. In 'immediate' mode, the code is used immediately.
In both modes, a token may be looked up in the dictionary (Forth's
symbol table), but the value of the 'state' variable determines
whether Forth is in 'compile' or 'immediate' mode.
In a similar way, some Lisps may either interpret or compile an
expression, but in both cases (depending the implementation, or the
current mode, or whatever) the expression source may be 'read',
producing a symbolic expression. This is a simplication, of course.
Like Forth, implementations may vary, and there may be steps (like
macro expansion) that I've left out for the sake of clarity.
Your point about about the compilation process being invisible is
correct. By a strict definition, even the 'read' function does some
'compiling', but we rarely need to worry about the details. If you
want to extend any part of the process, which many Lisp and Forth
systems allow you to do, then it can get much more interesting!
> A "real" interpreter would store your functions in essentially the form you
> typed them (it might lex them to tokens; the Commodore 64 Basic interpreter
> did this), and interpret them from scratch each time it ran them.
A Basic that uses tokens still has to 'compile' the source code into
the token form, which is why they're sometimes called 'tokenising'
interpreters. Lisp uses a more sophisticated form of this, with
sexprs, but the basic (no pun intended!) principle is the same.
Forth systems tend to use threaded code, so the 'tokens' will actually
be pointers to the code. Here we might get into a discussion of the
differences between direct and direct threading - but let's not go
that far! There are books that cover this in more detail, if you're
curious. Some Forths compile to native code.
In the late 80s, I wrote a Forth compiler in C (for boostrapping a
more conventional Forth compiler) that produced source code for an
assembler, using direct threading. A few years ago I re-wrote it to
produce an image containing the binary threaded code directly, this
time using indirect threaded code.
I'm now wondering about how to produce C code, probably using more
than a single pass. It may depend on how much I want to optimise the
code. I don't know if I'll ever write such a compiler, but I'm
certainly interested in techniques for optimising the stack operators.
Simulating the effects on the runtime stack within the compiler is an
obvious starting point. Native coded Forths can use the CPU registers
for the top stack positions, so a compiler that produces C code could
use C variables, plus a real stack for the stack operations that can't
be optimised. 'Optimising' in this context would mean translating
Forth's operations into things that a C compiler can understand.
> There's the more obvious form of compiling (compile-file) which offers
> further speed-ups, and is more remniscent of batch-compiled languages like
> C or Pascal. I think this is typically a two-pass process.
I would expect it to be at least a two-pass process. ;) We can always
make things more complicated if we want to. If we can sacrifice
some features, then we can make things simpler and clearer, too. This
is the core of the Forth approach compiling, I think.
We can gain as well as lose things from the use of simplicity. This is
true of both Lisp and Forth, IMHO. It's what attracts me to such
languages, and perhaps what some people who criticise them find so
difficult understand. I suspect that it's also possible to understand
these qualities, and yet still fail to appreciate them.
Perhaps it's a Zen thing?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
In article <··········@world.std.com>, Will Ware <·····@world.std.com> wrote:
>Joerg Hoehle (······@zeus.gmd.de) wrote:
>: Martin Cracauer (········@wavehh.hanse.de) wrote:
>: : [in] the Common Lisp dialect...
>: : ...All the systems listed in the FAQ are either compilers or
>: : bytecode machine.
>: That doesn't mean that these systems don't include interpreters. When
>: I held a Lisp course in 1993, the students used CLISP on DOS boxes...
>
>I think the confusion might be between "interpreted" and "interactive".
>If I understand correctly, systems like CLISP, GCL, and CMUCL will compile
>functions as you type them in, often to some sort of byte code. This is a
I think this whole issue is a red herring. A guy asks for a Lisp
interpreter, people make suggestions, and then start arguing about
"interpreter" vs. "compiler". My guess is that the original poster
wanted a Lisp system, and didn't really care whether it used an
interpreter, a compiler, or small furry demons. It's the sort of
question that somebody unfamiliar with Lisp typically asks. Given
that, he may well not have realized that Lisp is typically a
compiled language nowadays. Certainly we need to tell him that,
but suggesting that ACL Lite/CLISP/whatever aren't what he asked for
is disingenuous.
--
David H. Thornley, known to the Wise as ········@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
With a mighty <··········@epx.cis.umn.edu>,
········@cs.umn.edu uttered these wise words...
> I think this whole issue is a red herring. A guy asks for a Lisp
> interpreter, people make suggestions, and then start arguing about
> "interpreter" vs. "compiler". My guess is that the original poster
> wanted a Lisp system, and didn't really care whether it used an
> interpreter, a compiler, or small furry demons. It's the sort of
> question that somebody unfamiliar with Lisp typically asks. Given
> that, he may well not have realized that Lisp is typically a
> compiled language nowadays. Certainly we need to tell him that,
> but suggesting that ACL Lite/CLISP/whatever aren't what he asked for
> is disingenuous.
I agree. If someone asks me for an "interpreter", I might give them an
interactive system with compiler. If someone asks me for a compiler, I
might do exactly the same thing! On the other hand, I might give them
an interpreter. Implementations for a lot of languages blur such
distinctions. I prefer to say "Lisp system" (I also say "Forth
system"), instead of "Lisp compiler" or "Lisp interpreter".
When anyone gets confused by all this, I tend to refer them to my
favourite book on compiler theory. ;-) Here it is (just in case):
Writing Interactive Compilers and Interpreters
P.J. Brown
John Wiley & Sons Ltd
ISBN 0 471 27609 X hbk
ISBN 0471 100722 pbk
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer <············@nospam.wildcard.demon.co.uk> wrote:
+---------------
| I agree. If someone asks me for an "interpreter", I might give them an
| interactive system with compiler. If someone asks me for a compiler, I
| might do exactly the same thing! On the other hand, I might give them
| an interpreter.
+---------------
To me those terms have always connated a desired style of usage, more
than a strict definition of implementation. When I hear "interpreter",
I think of something that (hopefully!) has a small memory footprint
and start-up time, even at the cost of not having the best possible
CPU performance for that language, and is thus suited to relatively
"small" interactive uses (trying things out, simple student exercises,
small-to-medium "shell scripts", prototype CGI-BIN scripts, etc).
And when I hear "compiler", I think of something that pushes the
runtime CPU performance to the *opposite* extreme, even at the
cost of high "start-up time" (compilation time) and relatively
large memory footprint (while compiling). And hopefully the compiler
includes a way of creating "standalone" programs from its output
that are more quick-starting than the compiler itself.
Even the simplest "pure interpreter" will hand the *output* of "read" to
"eval", not the input -- so there's already *some* "compiling" going on.
Some "byte-code compilers" would fall in the first performance category,
some wouldn't. Aan almost no "highly-optimizing compiler" would fall in
the first category, unless it also contained a lighter-weight interactive
REPL (which still "compiles" to some intermediate representation, just
not particularly optimized) which only calls the "real" compiler when
instructed to.
And that, to me, is the point. Lisp compilers as usually implemented
are nearly unique among language systems in allowing users to somewhat
change their point of view *during* a single session or execution.
(I say "somewhat" only because I suspect that highly-optimizing Lisp
compilers will suffer in the "start-up time" metric, even when you
don't compile anything.)
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
With a mighty <··········@tokyo.engr.sgi.com>,
····@rigden.engr.sgi.com uttered these wise words...
> To me those terms have always connated a desired style of usage, more
> than a strict definition of implementation. When I hear "interpreter",
> I think of something that (hopefully!) has a small memory footprint
> and start-up time, even at the cost of not having the best possible
> CPU performance for that language, and is thus suited to relatively
> "small" interactive uses (trying things out, simple student exercises,
> small-to-medium "shell scripts", prototype CGI-BIN scripts, etc).
Interpreters certainly tend to be simpler than compilers, and this may
help explain the difference in size. However, a lot of implementations
can blur the distinctions. A Basic "interpreter" could be very simple,
and small, but there's no reason why a Basic could not use a
sophisticated compiler, so that the user would never "see" the
compiler working, and yet it produced good quality native code. This
is exactly what many Lisp systems do!
It may be that Basic systems tend to be simple interpreters, but there
may be other reasons for that. Most Basics that I've seen were stored
in ROM, which places some strict constraints on a language
implementation. If you really wanted to fit a Lisp into a 12K ROM,
then I'm sure it could be done, but I doubt it would be a very large
dialect of Lisp, or that it would compile to native code.
Today, it's rather unusual for micros to include a language in ROM,
but there may be exceptions. Perhaps someone will suggest OpenBoot...
> And when I hear "compiler", I think of something that pushes the
> runtime CPU performance to the *opposite* extreme, even at the
> cost of high "start-up time" (compilation time) and relatively
> large memory footprint (while compiling). And hopefully the compiler
> includes a way of creating "standalone" programs from its output
> that are more quick-starting than the compiler itself.
Take a look at a Forth compiler. My first Forth system was less than
8K. A smaller language that uses a threaded code compiler might be
even smaller. The fact that the perception of compilers tends to be
for languages like C doesn't prove anything interesting. It only tells
that most people don't have wide enough experience of languages and
the compilers that implement them. Even some books on compiler theory
display a bias for batch compilers.
> Even the simplest "pure interpreter" will hand the *output* of "read" to
> "eval", not the input -- so there's already *some* "compiling" going on.
> Some "byte-code compilers" would fall in the first performance category,
> some wouldn't. Aan almost no "highly-optimizing compiler" would fall in
> the first category, unless it also contained a lighter-weight interactive
> REPL (which still "compiles" to some intermediate representation, just
> not particularly optimized) which only calls the "real" compiler when
> instructed to.
By PJ Brown's definition of a "pure interpreter", there'd be no
translation of source code into any other form. Instead, the source
code would be directly interpreted. By that definition, most language
implementations fail. His definition of a "pure compiler" is equally
strict, with similar results.
So, almost every language will be imnplemented using something that
mixes compiler with interpreting. The printf function in C and the
format function in Common Lisp are examples of interpreting that can
be done at runtime, dispite the possibilty of compilation to native
code. C and CL are implemented by both compilers and interpreters.
> And that, to me, is the point. Lisp compilers as usually implemented
> are nearly unique among language systems in allowing users to somewhat
> change their point of view *during* a single session or execution.
Forth is another language that can do this. In fact, it's expected
that Forth programmers will use this, and they frequently do. You
could even argue that changing the 'state' variable does this, so you
can't even compile new code without doing it. Words like 'does>' can
create some interesting problems for a meta-compiler, just like some
Lisp features do.
> (I say "somewhat" only because I suspect that highly-optimizing Lisp
> compilers will suffer in the "start-up time" metric, even when you
> don't compile anything.)
The obvious answer is to not start your language system each time you
need it, but to always have it loaded and running. Both Lisp and Forth
have been used instead of the OS itself, so you might have a system
that gives you no choice. Basic, too, has been used like this.
Languages like C come from a batch environment, or at least the
thinking that goes with it. The spirit of punched cards lives on. Many
of the problems with with C "environments" (a contradiction in terms,
I feel) is that the people who design them don't appear to appreciate
that these machines are interactive. Perhaps they're also ignorant of
techniques like incremental compiling, but there are now C++ compilers
that vendors claim are "incremental". Well, sometimes they are.
They're certainly _not_ interactive, no matter how many features may
be used via a mouse or keyboard.
In other words, "start up" metrics are only of interest to people who
still think they're using a batch environment. I'd love it if they
were, as we could then be free to create more interactive systems.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer <············@nospam.wildcard.demon.co.uk> wrote:
+---------------
| In other words, "start up" metrics are only of interest to people who
| still think they're using a batch environment.
+---------------
Or are using a system such as Unix in which "processes" are considered
to be composable elements of tasks. I wonder how you would deal with
the notion of, say, CGI-BIN scripts if the HTTP server and the CGI-BIN
interpreter/compiled-language were *not* [for whatever reason] the same
memory image or even written in the same language?
It is for applications like this -- as well as writing other "small"
scripts (and/or compiled programs) intended to be used in Unix pipes --
that I am concerned about start-up time.
Unfortunately, I see it as a fact(?) of the marketplace that if in order
to be useful a Lisp system has to take over *all* the applications of that
system, nobody will buy it. Conversely, if Lisp-based software can displace
this little piece and that little piece, then pretty soon...
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
With a mighty <··········@tokyo.engr.sgi.com>,
····@rigden.engr.sgi.com uttered these wise words...
> Or are using a system such as Unix in which "processes" are considered
> to be composable elements of tasks. I wonder how you would deal with
> the notion of, say, CGI-BIN scripts if the HTTP server and the CGI-BIN
> interpreter/compiled-language were *not* [for whatever reason] the same
> memory image or even written in the same language?
Some servers let you put your CGI code into dynamically linked
libraries. The server loads the code on demand, and unloaded after an
inactivity timeout. There's support using this technique with Perl,
Prolog, and soon Smalltalk. It should also be possible to add such
support to a Lisp that supports DLLs, like ILOG Talk.
> It is for applications like this -- as well as writing other "small"
> scripts (and/or compiled programs) intended to be used in Unix pipes --
> that I am concerned about start-up time.
Ah, yes. Unix. I'm told that not all Unices support dynamically linked
libraries. If my employer had chosen Linux instead of NT for our web
server, then I might now be writing CGI that uses dynamic linking,
thus avoiding problems with startup issues. So, I'm unable to say that
I _know_ it can be done, but that's only because I'm not sufficiently
familiar with the details of dynamic linking for Linux. However, I'd
be suprised if this were not possible for a Linux based web server, or
indeed many other kinds of server running on a Unix machine that
supports dynamic linking.
> Unfortunately, I see it as a fact(?) of the marketplace that if in order
> to be useful a Lisp system has to take over *all* the applications of that
> system, nobody will buy it. Conversely, if Lisp-based software can displace
> this little piece and that little piece, then pretty soon...
I don't see it as a fact. Perhaps it's more like an assumption made by
some Lisp people who don't use dynamic linking? So far, I only know of
one Lisp that uses DLLs for Windows, which is a platform that exploits
dynamic linking just about everywhere you look. Basic, Prolog,
Smalltalk, and Perl can all exploit it. There's an APL that uses it
via OLE (by saving the workspace as an OLE object, which you can then
embed in other documents), and I wouldn't be suprised if there're also
COBOL and Fortran compilers that can use it.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Cyber Surfer <············@nospam.wildcard.demon.co.uk> wrote:
+---------------
| > Or are using a system such as Unix in which "processes" are considered
| > to be composable elements of tasks. I wonder how you would deal with
| > the notion of, say, CGI-BIN scripts if the HTTP server and the CGI-BIN
| > interpreter/compiled-language were *not* [for whatever reason] the same
| > memory image or even written in the same language?
|
| Some servers let you put your CGI code into dynamically linked
| libraries. The server loads the code on demand, and unloaded after an
| inactivity timeout. There's support using this technique with Perl,
| Prolog, and soon Smalltalk. It should also be possible to add such
| support to a Lisp that supports DLLs, like ILOG Talk.
+---------------
That only works if your server is written in a language whose calling
sequences are compatible with the language your CGI-BINs-in-a-DLL are
written in. Which starts to look like a "single-language system" again --
nice in theory but not generally applicable in the broader market.
Or else you load up the HTTP server with all the complexity to handle
all the FFIs to all those languages. Again, not possible unless you
control the server.
+---------------
| > It is for applications like this -- as well as writing other "small"
| > scripts (and/or compiled programs) intended to be used in Unix pipes --
| > that I am concerned about start-up time.
|
| Ah, yes. Unix. I'm told that not all Unices support dynamically linked
| libraries.
+---------------
Again, DLLs are not really the issue -- single-process vs multi-process is.
Without loss of generality, let's assume for the moment that all Unix-like
systems support DLLs (or, as they are called more often in that environment,
DSOs), and that each of your CGI-BIN scripts are written using *some*
language that supports separating the program into a tiny "main" program
and a bigger DLL/DSO called by the "main". [Note that in Unix, DSOs aren't
themselves "executable"; they must be linked to by some running executable,
either their usual default "main" or some other running program, e.g., the
HTTP server. When an executable program that was link-edited against a set
of DSOs is run, this runtime linkage is automagic, e.g, via "rld". Or if
you want to bolt on a DSO you weren't linked with, you just call "dlopen()".]
In the Unix-like world, you're still left with the following issues:
1. The HTTP server must know how to identify those executables which are
written as tiny-main+DLL/DSO and which ones aren't. When called to
execute one that is, instead of fork/exec'ing the program (as it would
normally do for an executable) it must do a "dlopen()" of the DSO and
call the entry point that the tiny "main" would have called, with the
correct calling sequence and arguments. [I'm hand-waving over the
issue of most CGI-BINs being "scripts" which call interpreters to
execute them. I'm assuming that the server would be smart enough to
example the first line of a script, notice that it said "#!/path/to/foo",
try to assimilate the "foo" program's DSO, and call the appropriate
point (see below) with the appropriate args (see below), including a
filepath to the script.]
2. Each "main" may (in fact, almost always does!) have its own way
to pass command-line args to the DSO. How is the server to know?
(...without, say, decompiling the executable?) There are no common
standards in this area. (...unless the server has been configured
*ahead of time* for each and every language or application environment
it has to work with.)
3. Even if the server "knows" how to package up the info it would have
passed on the command line into a form acceptable to the DSO, is the
language the server is written in compatible with the runtime calling-
sequence conventions and the environment of the DSO? E.g., what if the
DSO contains its *own* garbage collector, incompatible with the server's?
+---------------
| If my employer had chosen Linux instead of NT for our web server, then
| I might now be writing CGI that uses dynamic linking, thus avoiding
| problems with startup issues.
+---------------
As noted above, merely having dynamic linking doesn't solve the problem.
Doesn't even come close!
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com
Silicon Graphics, Inc. http://reality.sgi.com/rpw3/
2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979
Mountain View, CA 94043 PP-ASEL-IA
With a mighty <··········@tokyo.engr.sgi.com>,
····@rigden.engr.sgi.com uttered these wise words...
> That only works if your server is written in a language whose calling
> sequences are compatible with the language your CGI-BINs-in-a-DLL are
> written in. Which starts to look like a "single-language system" again --
> nice in theory but not generally applicable in the broader market.
This isn't the problem that you suggest it is, as the convention is to
use the "Pascal linkage". Almost the entire Win32 API uses this
convention, so it's hard to avoid supporting it, whatever language you
use.
> Or else you load up the HTTP server with all the complexity to handle
> all the FFIs to all those languages. Again, not possible unless you
> control the server.
See above. This problem was fixed years ago, for Windows. Perhaps this
could also be done for Unix, but I dunno.
> As noted above, merely having dynamic linking doesn't solve the problem.
> Doesn't even come close!
Are you saying that Unix has trouble with something that NT software
does all the time? Good grief. It's nothing like that hard to write a
DLL for NT. Falling off a log is harder.
Are you sure that every Unix has this problem? Wouldn't it be possible
to use POSIX thread functions in the same way that web servers for NT
are NT's thread functions? I don't want to wander into the thread vs
fork debate, but I wonder if forking could be the cause of the
complications that you've described.
I've changed the subject, as I think that we've moved away from the
issues that began this thread (no pun intended).
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
>>"RW" == Rob Warnock schrieb am 11 Mar 1997 23:22:57 GMT:
RW> Again, DLLs are not really the issue -- single-process vs
RW> multi-process is.
[Interesting discussion of problems using DSOs, which I take as an
abbreveation for dynamic/distributed shared objects, right ?]
RW> As noted above, merely having dynamic linking doesn't solve the
RW> problem. Doesn't even come close!
Aren't these problems addressed by Corba and/or DCE-RPC ? These are
protocolls which specify how interfaces between (distributed) objects
must be specified to be used by other objects (which don't need to be
written in the same language, because an object server feeds them
the necessary objects) ?
As far as I understand these issues, ILU from Xerox is such an
interface specification language, and interfaces to/from Lisp exist.
Holger
--
holger_schauer :-
mail_address(···············@gmd.de"),
project("BGP-MS/AVANTI, GMD Sankt Augustin, FIT.MMK"),
www_home_page("http://www.uni-koblenz.de/~schauer/index.html").
(^:= A donkey came to my office. It had a theory about people anaphora...
David H. Thornley (········@cs.umn.edu) wrote:
: In article <··········@world.std.com>, Will Ware <·····@world.std.com> wrote:
: >I think the confusion might be between "interpreted" and "interactive".
: I think this whole issue is a red herring. A guy asks for a Lisp
: interpreter, people make suggestions, and then start arguing about
: "interpreter" vs. "compiler". My guess is that the original poster
: wanted a Lisp system, and didn't really care whether it used an
: interpreter, a compiler, or small furry demons.
You're probably right about what the guy was looking for. I had hoped my
post would clarify some of the responses he'd gotten up to that point that
might have left him confused. I could have been more straightforward about
trying to clear things up. I'll try that now.
For technical reasons, modern Lisps aren't considered "interpreters", but
they seem like it to the user. The three big free ones I'm aware of are
CLISP (which as far as I know, runs on Unix, DOS, and Win95/NT), GCL (Unix
only, I think), and CMUCL (also Unix only, I think). I have no truck with
Macintoshes, I know there's a commercial thing called Macintosh Common
Lisp but I don't know what free Lisps exist for the Mac, if any. So those
are all Common Lisp systems.
The other fairly popular dialect is Scheme, and there are lots of Scheme
systems (also technically not considered "interpreters", but they feel like
it to the user). I've been using MzScheme and its GUI-enhanced version,
MrEd. There are others such as SCM (easy to extend with C code), STk
(another Scheme with a GUI), SIOD, Guile, and gobs more. MrEd is nice
because once you have a program working on one platform, it becomes very
portable. I write chemistry software on a Linux box and then I can run it
on Win95. MrEd also runs on 68K and PPC Macs.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
Hi,
Will Ware (·····@world.std.com) wrote:
: Joerg Hoehle (······@zeus.gmd.de) wrote:
: : Martin Cracauer (········@wavehh.hanse.de) wrote:
: : : [in] the Common Lisp dialect...
: : : ...All the systems listed in the FAQ are either compilers or
: : : bytecode machine.
: : That doesn't mean that these systems don't include interpreters. When
: : I held a Lisp course in 1993, the students used CLISP on DOS boxes...
: I think the confusion might be between "interpreted" and "interactive".
: If I understand correctly, systems like CLISP, GCL, and CMUCL will compile
: functions as you type them in, often to some sort of byte code. This is a
: one-pass incremental compilation, like what's done in Forth, I believe.
I don't want to enter the interpreter vs. compiler discussion, I just
want to state facts about CLISP.
CLISP does not compile functions into either machine or byte code as
you type them in. You need to call COMPILE for that. CLISP has a
real interpreter that does the (IF (ATOM form) (IF (SYMBOLP form) ...)
#|else cons|# ...) thing described in the books (see
src/eval.d:eval1). You can fully work with a CLISP image that does
not have the sexp to byte code compiler in it (implemented in
src/compiler.lsp). The Amiga port of CLISP contains such an image
which is less than half the size of the normal one. Building a CLISP
without the byte code interpreter (written in C, see src/bytecode.d)
must be possible, but would require changing C code.
Thus CLISP contains a "real" interpreter by what most people
understand. It *also* contains a compiler, compiling to byte code,
but does not compile on the fly, except for files with the very useful
:COMPILE argument to LOAD.
Now the question is: why did the original poster care to specify that
an interpreter is wanted?
Regards,
Jo"rg Ho"hle.
············@gmd.de http://zeus.gmd.de/~hoehle/amiga-clisp.html
With a mighty <··········@omega.gmd.de>,
······@zeus.gmd.de uttered these wise words...
> Thus CLISP contains a "real" interpreter by what most people
> understand. It *also* contains a compiler, compiling to byte code,
> but does not compile on the fly, except for files with the very useful
> :COMPILE argument to LOAD.
This is why the distinctions we're making are so interesting. With
CLISP, the user has some control over the details of the compilation
process. This is a little more profund than merely telling a compiler
what kind of optimisations to use, like you can with many C compilers.
Of course, with C the choice between "compiling" and "interpreting"
may be made when you choose the language implementation. CLISP let's
you make the choice for each function.
I'm assuming that the distinction between bytecodes are native code
are not as relevant as the distinction between symbolic expressions
and the "compiled" code. That's a whole subject all by itself!
> Now the question is: why did the original poster care to specify that
> an interpreter is wanted?
A few possibilities spring to mind. One is that the original poster
didn't appreciate the distinctions that we're making. Another is that
they fully understood all the issues, but prefered to say
"interpreter" instead of something more general, like "language
system". This would be a personal choice, I think, and we've seen
nothing to suggest any intend to confuse anyone.
The answer to your question _could_ be relevant, but that could depend
on the answer itself. I'm more interested in the question: Have we
succeeded in answering the question asked by the original poster, and
are they satisfied with the answers that we've given? Like your
question, only one person can answer it...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
····@toppoint.de (Hans-J. Kuckhoff) writes:
>Does anyone know where I can get a free release of a
>LISP-Interpreter running under DOS or Windows 3.x or
>Windows 95?
Try Harlequin's FreeLisp.