Hi,
I am completely new to Lisp and am currently trying to make sense out
of a lisp program, and hopefully someone can help me out on the
following issue. If i run this program using Allegro CL, everything
works just fine and the program completes. Now if I try to run the
*exact* same code base with clisp (I also tried cmu lisp) an error
occurs during processing (same error for both clisp and cmu lisp).
I cannot fully make sense out of the lisp syntax yet, and so i'd
rather not include any code here. What I would like to know is how to
proceed to figure out why things work with one interpreter and not
with the other. Are there any known syntactic difference between
allegro lisp and other lisp implementations ?
sorry I cannot be more specific, but hopefully someone can give me
some pointers ~
cheers,
-y
········@gmail.com wrote:
> Hi,
>
> I am completely new to Lisp and am currently trying to make sense out
> of a lisp program, and hopefully someone can help me out on the
> following issue. If i run this program using Allegro CL, everything
> works just fine and the program completes. Now if I try to run the
> *exact* same code base with clisp (I also tried cmu lisp) an error
> occurs during processing (same error for both clisp and cmu lisp).
>
> I cannot fully make sense out of the lisp syntax yet, and so i'd
> rather not include any code here.
Go ahead, c.l.l is pretty much a teaching forum.
> What I would like to know is how to
> proceed to figure out why things work with one interpreter and not
> with the other.
ACL compiles and has a separate more forgiving interpreter, FYI and also
this may be what you are seeing, the interpreter looks the other way a
lot. CMUCL only compiles (even at the REPL). CLisp I do not know, I
guess it always compiles to byte codes.
> Are there any known syntactic difference between
> allegro lisp and other lisp implementations ?
Yep. ACL let's a lot of things slide. Lispworks is another stricter
implementation.
Furthermore, the standard has many places where it says "implementation
independent", and a lot of these have to do with the kind of strange
code nobbs tend to write.
I suggest you get your code to work on CLisp and see what you learn.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Ken Tilton wrote:
>
>
> ········@gmail.com wrote:
>
>> Hi,
>>
>> I am completely new to Lisp and am currently trying to make sense out
>> of a lisp program, and hopefully someone can help me out on the
>> following issue. If i run this program using Allegro CL, everything
>> works just fine and the program completes. Now if I try to run the
>> *exact* same code base with clisp (I also tried cmu lisp) an error
>> occurs during processing (same error for both clisp and cmu lisp).
>>
>> I cannot fully make sense out of the lisp syntax yet, and so i'd
>> rather not include any code here.
>
>
> Go ahead, c.l.l is pretty much a teaching forum.
>
>> What I would like to know is how to
>> proceed to figure out why things work with one interpreter and not
>> with the other.
>
>
> ACL compiles and has a separate more forgiving interpreter, FYI and also
> this may be what you are seeing, the interpreter looks the other way a
> lot. CMUCL only compiles (even at the REPL). CLisp I do not know, I
> guess it always compiles to byte codes.
>
>> Are there any known syntactic difference between
>> allegro lisp and other lisp implementations ?
>
>
> Yep. ACL let's a lot of things slide.
And here I mean even the compiler is more lax than Lispworks.
> Lispworks is another stricter
> implementation.
>
> Furthermore, the standard has many places where it says "implementation
> independent",
er, "dependent", meaning the standard does not specify what should
happen, and so implementations may vary.
kt
and a lot of these have to do with the kind of strange
> code nobbs tend to write.
>
> I suggest you get your code to work on CLisp and see what you learn.
>
> kt
>
>
>
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
From: Madhu
Subject: Re: Difference between Allegro CL 8 and clisp ?
Date:
Message-ID: <m3iqx0fhec.fsf@meer.net>
* Ken Tilton <·························@cv.net> :
|
| ACL compiles and has a separate more forgiving interpreter, FYI and
| also this may be what you are seeing, the interpreter looks the other
| way a lot. CMUCL only compiles (even at the REPL). CLisp I do not
| know, I guess it always compiles to byte codes.
While CMUCL has a byte compiler and a native compiler, it does not do
compilation at the REPL [by default unless specified explicitly]
You are perhaps thinking of SBCL or OPENMCL which compiled everything at
the repl, but I believe ITA has funded Juho Snellman to write a
barebones interpreter for SBCL
--
Madhu
Madhu <·······@meer.net> writes:
> You are perhaps thinking of SBCL or OPENMCL which compiled everything at
> the repl, but I believe ITA has funded Juho Snellman to write a
> barebones interpreter for SBCL
Why? What would a barebones interpreter for SBCL help anyone with?
P� Sun, 01 Jun 2008 14:00:01 +0200, skrev Chris Barts
<··············@gmail.com>:
> Madhu <·······@meer.net> writes:
>
>> You are perhaps thinking of SBCL or OPENMCL which compiled everything at
>> the repl, but I believe ITA has funded Juho Snellman to write a
>> barebones interpreter for SBCL
>
> Why? What would a barebones interpreter for SBCL help anyone with?
Debugging? Particularly macro code. It's handy to be able to expand a
macro each time during testing without a full recompile. Or not worrying
about optimizations messing up the stack (tail recursion).
--------------
John Thingstad
From: Madhu
Subject: Re: Difference between Allegro CL 8 and clisp ?
Date:
Message-ID: <m3lk1prxiu.fsf@meer.net>
* ··············@gmail.com <··············@chbarts.motzarella.org> :
Wrote on Sun, 01 Jun 2008 06:00:01 -0600:
|> You are perhaps thinking of SBCL or OPENMCL which compiled everything at
|> the repl, but I believe ITA has funded Juho Snellman to write a
|> barebones interpreter for SBCL
|
| Why? What would a barebones interpreter for SBCL help anyone with?
Not sure. I noticed the following comment on a CLL post:
···················································@vasara.proghammer.com
* Juho Snellman <··············@vasara.proghammer.com> :
Wrote on 28 Jan 2008 19:44:20 +0200:
| I wouldn't neccessarily talk about optimizations. Assuming that the
| code does not have sufficient type declarations for aliens, both SBCL
| and CMUCL will go through the process of invoking that
| machinery. It's just that SBCL invokes it with the interpreter, while
| CMUCL (lacking a real interpreter) has to call the compiler.
[Now CMUCL has a real interpreter --- it converts to IR1 and interprets
the IR1. I termed the interpreter which CMUCL is, in the above
comment, said to lack" "barebones"]
--
Madhu
Madhu <·······@meer.net> writes:
> * ··············@gmail.com <··············@chbarts.motzarella.org> :
> * Juho Snellman <··············@vasara.proghammer.com> :
> Wrote on 28 Jan 2008 19:44:20 +0200:
> | I wouldn't neccessarily talk about optimizations. Assuming that the
> | code does not have sufficient type declarations for aliens, both SBCL
> | and CMUCL will go through the process of invoking that
> | machinery. It's just that SBCL invokes it with the interpreter, while
> | CMUCL (lacking a real interpreter) has to call the compiler.
>
> [Now CMUCL has a real interpreter --- it converts to IR1 and interprets
> the IR1. I termed the interpreter which CMUCL is, in the above
> comment, said to lack" "barebones"]
In CL terms CMUCL doesn't really have an interpreter, since it'll
always do at least minimal compilation. I did not mean for "real" to
be any kind of value judgement on the merits of interpreting the AST
vs. partially compiling and interpreting the compiler's intermediate
representation.
It just happens that in the above case the overhead of doing even the
initial parts of the compilation in Python is enormous compared to the
cost of the actual operation being performed.
--
Juho Snellman
Chris Barts <··············@gmail.com> writes:
> Madhu <·······@meer.net> writes:
> > You are perhaps thinking of SBCL or OPENMCL which compiled everything at
> > the repl, but I believe ITA has funded Juho Snellman to write a
> > barebones interpreter for SBCL
>
> Why? What would a barebones interpreter for SBCL help anyone with?
I'm not sure where that "barebones" is coming. SBCL has an interpreter
for the full CL language. It's not enabled by default, you need to set
a special variable (see http://www.sbcl.org/manual/Interpreter.html).
The main reason for it existing is that there are some special cases
where the overhead of calling the compiler for each call to EVAL is
unacceptable. The original use case was speeding up builds, but there
are other uses too.
A secondary benefit is that it's really nice to have the interpreter
available when you're hacking the compiler -- if you break the
compiler in the running image, you can still fix it using the
interpreter rather than restarting the whole Lisp.
And to give credit where it's due, the interpreter was originally
written by Brian Downing. I just cleaned it up for inclusion to SBCL.
--
Juho Snellman
Juho Snellman wrote:
> Chris Barts <··············@gmail.com> writes:
>> Madhu <·······@meer.net> writes:
>>> You are perhaps thinking of SBCL or OPENMCL which compiled everything at
>>> the repl, but I believe ITA has funded Juho Snellman to write a
>>> barebones interpreter for SBCL
>> Why? What would a barebones interpreter for SBCL help anyone with?
>
> I'm not sure where that "barebones" is coming. SBCL has an interpreter
> for the full CL language. It's not enabled by default, you need to set
> a special variable (see http://www.sbcl.org/manual/Interpreter.html).
>
> The main reason for it existing is that there are some special cases
> where the overhead of calling the compiler for each call to EVAL is
> unacceptable. The original use case was speeding up builds, but there
> are other uses too.
>
> A secondary benefit is that it's really nice to have the interpreter
> available when you're hacking the compiler -- if you break the
> compiler in the running image, you can still fix it using the
> interpreter rather than restarting the whole Lisp.
>
> And to give credit where it's due, the interpreter was originally
> written by Brian Downing. I just cleaned it up for inclusion to SBCL.
>
This reply is really to the question
What would a interpreter help anyone with?
I have fantasies of building something that requires servers to talk to each other by sending
snippets of lisp. You don't necessarily want that one liner rpc to be compiled.
(I am assuming the compiler, interpreter, compiled code, and interpreted code can co-exist at the
same time on sbcl)
Another application may be logging. Instead of logging some home grown format, you could log S-exp .
Then processing the log would be just reading and evaluating each s-exp. It would be more practical
to interpret each s-exp than compile a whole log file. This may sound impractical and may be it is,
but I have done something similar in Java. It was not exactly logging. Basically it was web service
where each request resulted in some javascript (using the Rhino javascript engine in Java) being
executed to process the data. The application processed at least a million requests each day running
about 10 small javascript snippets per each request on a single box. Ran for 30+ days at a time
before being restarted for upgrade or other reasons (so I don't really know how long it can run).
Since I was too lazy to find out how to pre-compile them, it ended up interpreting them, which meant
Java created and garbage collected a whole lot of classes (rhino essentially creates a java class
for each snippet). The details of why/how don't really matter, bottom line - it was performant
enough and gave me flexibility (if you know the difference between Java and Javascript) at
sufficient throughput. I can think of doing similar things in Lisp. If that is not practical for
fundamental theoretical reasons or simply because we don't have Lisp environments designed to handle
that, I don't know.
I guess another choice would be to use a cl-python or whatever similar. But the reason to do that
should be because that DSL is a better language for your particular domain, not because we don't
have a efficient means of doing what I have described using CL itself.
-Antony
In article <································@comcast.com>,
lisp linux <·········@lisp.linux> wrote:
> Juho Snellman wrote:
> > Chris Barts <··············@gmail.com> writes:
> >> Madhu <·······@meer.net> writes:
> >>> You are perhaps thinking of SBCL or OPENMCL which compiled everything at
> >>> the repl, but I believe ITA has funded Juho Snellman to write a
> >>> barebones interpreter for SBCL
> >> Why? What would a barebones interpreter for SBCL help anyone with?
> >
> > I'm not sure where that "barebones" is coming. SBCL has an interpreter
> > for the full CL language. It's not enabled by default, you need to set
> > a special variable (see http://www.sbcl.org/manual/Interpreter.html).
> >
> > The main reason for it existing is that there are some special cases
> > where the overhead of calling the compiler for each call to EVAL is
> > unacceptable. The original use case was speeding up builds, but there
> > are other uses too.
> >
> > A secondary benefit is that it's really nice to have the interpreter
> > available when you're hacking the compiler -- if you break the
> > compiler in the running image, you can still fix it using the
> > interpreter rather than restarting the whole Lisp.
> >
> > And to give credit where it's due, the interpreter was originally
> > written by Brian Downing. I just cleaned it up for inclusion to SBCL.
> >
>
> This reply is really to the question
> What would a interpreter help anyone with?
>
> I have fantasies of building something that requires servers to talk to each other by sending
> snippets of lisp. You don't necessarily want that one liner rpc to be compiled.
> (I am assuming the compiler, interpreter, compiled code, and interpreted code can co-exist at the
> same time on sbcl)
>
> Another application may be logging. Instead of logging some home grown format, you could log S-exp .
> Then processing the log would be just reading and evaluating each s-exp. It would be more practical
> to interpret each s-exp than compile a whole log file.
Assuming that you have lines like:
(do-this 'baz 3)
(do-that 'bar 4)
I would just READ the line, check its contents and then
call the function:
(let ((*read-eval* nil))
(let ((line (read)))
(when (valid-line-p line)
(destructuring-bind (function . args) line
(apply function args)))))
No compiler or interpreter needed.
I would want to avoid executing code directly from the network or from logs.
> This may sound impractical and may be it is,
> but I have done something similar in Java. It was not exactly logging. Basically it was web service
> where each request resulted in some javascript (using the Rhino javascript engine in Java) being
> executed to process the data. The application processed at least a million requests each day running
> about 10 small javascript snippets per each request on a single box. Ran for 30+ days at a time
> before being restarted for upgrade or other reasons (so I don't really know how long it can run).
> Since I was too lazy to find out how to pre-compile them, it ended up interpreting them, which meant
> Java created and garbage collected a whole lot of classes (rhino essentially creates a java class
> for each snippet). The details of why/how don't really matter, bottom line - it was performant
> enough and gave me flexibility (if you know the difference between Java and Javascript) at
> sufficient throughput. I can think of doing similar things in Lisp. If that is not practical for
> fundamental theoretical reasons or simply because we don't have Lisp environments designed to handle
> that, I don't know.
> I guess another choice would be to use a cl-python or whatever similar. But the reason to do that
> should be because that DSL is a better language for your particular domain, not because we don't
> have a efficient means of doing what I have described using CL itself.
>
> -Antony
--
http://lispm.dyndns.org/
Rainer Joswig wrote:
> Assuming that you have lines like:
>
> (do-this 'baz 3)
> (do-that 'bar 4)
>
> I would just READ the line, check its contents and then
> call the function:
>
> (let ((*read-eval* nil))
> (let ((line (read)))
> (when (valid-line-p line)
> (destructuring-bind (function . args) line
> (apply function args)))))
>
> No compiler or interpreter needed.
Thank you.
I am curious, does anyone actually do something like this. I am not talking about the specific code
above, but the general idea of executing logs as lisp code. (I know playing logs is normal for
databases)
>
> I would want to avoid executing code directly from the network or from logs.
>
Yes, sure.
-Antony
In article
<····································@k37g2000hsf.googlegroups.com>,
········@gmail.com wrote:
> Hi,
>
> I am completely new to Lisp and am currently trying to make sense out
> of a lisp program, and hopefully someone can help me out on the
> following issue. If i run this program using Allegro CL, everything
> works just fine and the program completes. Now if I try to run the
> *exact* same code base with clisp (I also tried cmu lisp) an error
> occurs during processing (same error for both clisp and cmu lisp).
>
> I cannot fully make sense out of the lisp syntax yet, and so i'd
> rather not include any code here. What I would like to know is how to
> proceed to figure out why things work with one interpreter and not
> with the other.
Hmm, why not look at the error message and see what it says?
> Are there any known syntactic difference between
> allegro lisp and other lisp implementations ?
>
> sorry I cannot be more specific, but hopefully someone can give me
> some pointers ~
>
> cheers,
>
> -y
--
http://lispm.dyndns.org/
Rainer Joswig wrote:
> In article
> <····································@k37g2000hsf.googlegroups.com>,
> ········@gmail.com wrote:
>
>
>>Hi,
>>
>>I am completely new to Lisp and am currently trying to make sense out
>>of a lisp program, and hopefully someone can help me out on the
>>following issue. If i run this program using Allegro CL, everything
>>works just fine and the program completes. Now if I try to run the
>>*exact* same code base with clisp (I also tried cmu lisp) an error
>>occurs during processing (same error for both clisp and cmu lisp).
>>
>>I cannot fully make sense out of the lisp syntax yet, and so i'd
>>rather not include any code here. What I would like to know is how to
>>proceed to figure out why things work with one interpreter and not
>>with the other.
>
>
> Hmm, why not look at the error message and see what it says?
Does that matter? I think they asked the right question. Seeing
different implementations of my new language do radically different
things would suddenly be vastly more fascinating than the actual error,
because I then would be thinking about dumping the new language
altogether -- who needs a language with a Probability Drive?
Lisps do vary (contra something else offered on this thread) -- maybe
only at the 0.1% level or even less, it's a big language, helluva
denominator not to mention index -- but they do vary: porting from ACL
to Lispworks (after a year's work) is a day or two of rooting these
things out.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
ECLM rant:
http://video.google.com/videoplay?docid=-1331906677993764413&hl=en
ECLM talk:
http://video.google.com/videoplay?docid=-9173722505157942928&q=&hl=en
Hi all,
IMHO, Allegro compared to CLisp :
> Allegro more : reliable, quick, interpreter and a super
Compiler; better support; Allegro Cache/Graph, more libraries; 17
years average for support;
in final : a better future.
CLisp : just good to learn Lisp, but I prefer Allegro CL in non
Commercial licence.
Best Regards,
Christophe
From: Edi Weitz
Subject: Re: Difference between Allegro CL 8 and clisp ?
Date:
Message-ID: <u4p8j6edu.fsf@agharta.de>
On Tue, 27 May 2008 09:22:05 -0400, Ken Tilton <···········@optonline.net> wrote:
> Does that matter? I think they asked the right question. Seeing
> different implementations of my new language do radically different
> things would suddenly be vastly more fascinating than the actual
> error, because I then would be thinking about dumping the new
> language altogether -- who needs a language with a Probability
> Drive?
You're talking about C++?
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
········@gmail.com writes:
> I am completely new to Lisp and am currently trying to make sense out
> of a lisp program, and hopefully someone can help me out on the
> following issue. If i run this program using Allegro CL, everything
> works just fine and the program completes. Now if I try to run the
> *exact* same code base with clisp (I also tried cmu lisp) an error
> occurs during processing (same error for both clisp and cmu lisp).
It would be nice if you showed us the exact error messages.
> I cannot fully make sense out of the lisp syntax yet, and so i'd
> rather not include any code here. What I would like to know is how to
> proceed to figure out why things work with one interpreter and not
> with the other.
Reading the error messages should give good hints.
> Are there any known syntactic difference between
> allegro lisp and other lisp implementations ?
No, there's no syntactic difference. For the common parts, there
should be no semantic difference either. But implementations are
allowed to provide extensions to Common Lisp, and most do, and program
that use these extensions are not conformant when they can't behave
properly on implementations that don't have them. (I use here a
slightly more lax definition of conformant than
http://www.lisp.org/HyperSpec/Body/glo_c.html#conforming_program).
Said simply, your program probably use a library that is available
only in ACL. You probably will have to learn lisp, and port this
program from ACL to Common Lisp, or to CMUCL and/or CLISP. (This might
be easy enough if the non standard code is well localized and
equivalent features exist in the other implementations).
--
__Pascal Bourguignon__
y> works just fine and the program completes. Now if I try to run the
y> *exact* same code base with clisp (I also tried cmu lisp) an error
y> occurs during processing (same error for both clisp and cmu lisp).
in most cases error messages are quite informative, so a good
starting point is actually reading the error message.
y> What I would like to know is how to
y> proceed to figure out why things work with one interpreter and not
y> with the other.
there are two possiblities: either you program relies on non-standard
feature, or there is a bug in one of implementations.
as with any error that is not obvious, best thing to analyze why it's wrong
is to make smallest reproducing example. if you have it, you can analyze
it if it conforms to specification, or ask help in this group, if nothing
else helps..