Which eval is better, Common Lisp or Scheme? I was warned that
Common Lisp eval does not understand local variables, but one
specific implementation does. Which one? Is it same for Scheme?
Is there any significant difference?
Majorinc wrote:
> Which eval is better, Common Lisp or Scheme?
If you're working on a Common Lisp program, calling the Scheme eval is
probably going to be quite expensive, since you have to either
instantiate an entire Scheme image, or else call into an existing one
(perhaps across process boundaries with some RPC mechanism or
whatever).
The reverse is also true.
So my recommendation is to stick to the eval in whichever language you
are working with.
"Kaz Kylheku" <········@gmail.com> writes:
> Majorinc wrote:
>> Which eval is better, Common Lisp or Scheme?
>
> If you're working on a Common Lisp program, calling the Scheme eval is
> probably going to be quite expensive, since you have to either
> instantiate an entire Scheme image, or else call into an existing one
> (perhaps across process boundaries with some RPC mechanism or
> whatever).
>
> The reverse is also true.
>
> So my recommendation is to stick to the eval in whichever language you
> are working with.
Well, there is an implementation of R4RS on Common Lisp: Pseudo Scheme.
Invoking scheme eval from Common Lisp, or Common Lisp function from
scheme is not more costly than invoking any other function.
[17]> (scheme)
This is Pseudoscheme 2.12.
scheme[18]> (define (p . r)
(if (and (pair? r) (string? (car r)) (null? (cdr r)))
(display (car r))
(apply (cl:function cl:format) r)))
p defined.
scheme[19]> (p "Hello")
Hello
"Hello"
scheme[20]> (p '() "~(~{~A~^ ~}~)~%" '(hello world))
"hello world
"
scheme[21]> (quit)
;; Back to Common Lisp, let's call some scheme function:
[18]> (scheme::p "Hello")
Hello
"Hello"
[19]> (scheme::p nil "~:(~{~A~^ ~}~)~%" '(hello world))
"Hello World
"
[20]>
Actually, you can even use Common Lisp special operators in Scheme, as
you can see from the CL:FUNCTION example above.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
Pascal Bourguignon <······@informatimago.com> writes:
> Well, there is an implementation of R4RS on Common Lisp: Pseudo Scheme.
>
> Invoking scheme eval from Common Lisp, or Common Lisp function from
> scheme is not more costly than invoking any other function.
How does it implement call-with-current-continuation? Does it rely on
tail call optimization of the host language to ensure TCO of Scheme?
These issues make me hard to believe that it can use the host calling
convention directly and at the same time implement R4RS. And if it
doesn't use the native calling convention, it's hard to be as efficient.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Pascal Bourguignon <······@informatimago.com> writes:
>
> > Well, there is an implementation of R4RS on Common Lisp: Pseudo Scheme.
> >
> > Invoking scheme eval from Common Lisp, or Common Lisp function from
> > scheme is not more costly than invoking any other function.
>
> How does it implement call-with-current-continuation? Does it rely on
> tail call optimization of the host language to ensure TCO of Scheme?
>
> These issues make me hard to believe that it can use the host calling
> convention directly and at the same time implement R4RS. And if it
> doesn't use the native calling convention, it's hard to be as efficient.
It's actually not that hard to automatically convert between CPS
calling conventions and normal CL conventions. In the cases where you
don't actually capture the current continuation, Python generally
produces ever-so-slightly better code for CPS transformed code than
normal CL.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Marcin 'Qrczak' Kowalczyk wrote:
> Pascal Bourguignon <······@informatimago.com> writes:
>
>>Well, there is an implementation of R4RS on Common Lisp: Pseudo Scheme.
>>
>>Invoking scheme eval from Common Lisp, or Common Lisp function from
>>scheme is not more costly than invoking any other function.
>
> How does it implement call-with-current-continuation?
Pseudoscheme's call/cc only supports one-shot escaping continuations.
(All the others are useless anyway... ;-)
> Does it rely on
> tail call optimization of the host language to ensure TCO of Scheme?
Yes. These restrictions are also described in the documentation of
Pseudoscheme.
> These issues make me hard to believe that it can use the host calling
> convention directly and at the same time implement R4RS. And if it
> doesn't use the native calling convention, it's hard to be as efficient.
It's called "Pseudo" for a reason...
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
This is just my two cents, but I'd steer clear of trying to muck around
with local variables and eval under Common Lisp. I say this because, in
the course of writing the handy little DSL interpreter, I ran into the
hairiness of dealing with eval's peculiarities and was forced into
making temporary dynamically scoped global variables. I felt dirty
afterwards... ;)
So, I'd say try to find a way to use eval without relying on local
variables. If you can't, just be prepared to code up some potentially
hairy work-arounds (look into special variables and their ilk, that let
you sidestep some of the common problems involving eval and scopes).
-Ryan Kaulakis
Majorinc wrote:
> Which eval is better, Common Lisp or Scheme? I was warned that
> Common Lisp eval does not understand local variables, but one
> specific implementation does. Which one? Is it same for Scheme?
> Is there any significant difference?
>
>
>
rmk216 wrote:
> This is just my two cents, but I'd steer clear of trying to muck around
> with local variables and eval under Common Lisp. I say this because, in
> the course of writing the handy little DSL interpreter, I ran into the
> hairiness of dealing with eval's peculiarities and was forced into
> making temporary dynamically scoped global variables. I felt dirty
> afterwards... ;)
Did you use PROGV?
Kaz Kylheku wrote:
> rmk216 wrote:
>
>>This is just my two cents, but I'd steer clear of trying to muck around
>>with local variables and eval under Common Lisp. I say this because, in
>>the course of writing the handy little DSL interpreter, I ran into the
>>hairiness of dealing with eval's peculiarities and was forced into
>>making temporary dynamically scoped global variables. I felt dirty
>>afterwards... ;)
>
>
> Did you use PROGV?
>
I think it worked out to be something like this after all of my macros
were done:
(defparameter *global-var* nil)
(eval (progn (read-from-string "(let (*global-var*)
(declare (special *global-var*))
;;junk that uses *global-var*
)")))
The code in the middle of all that has access to all top-level forms and
variables, and can use the special variable to access things of the same
name in the current scope (though I never tried using it for *exactly*
what you've mentioned, so I'd check to see if the special variable's
initialization overwrites the local value automatically).
I took a look at progv, but I didn't use it for reasons I can't
remember. I'd imagine that it might be useful here.
Majorinc wrote:
> Which eval is better, Common Lisp or Scheme? I was warned that
> Common Lisp eval does not understand local variables, but one
> specific implementation does. Which one? Is it same for Scheme?
> Is there any significant difference?
I doubt Scheme is different. Supposedly you can use EVAL inside
environments, but only MIT Scheme (as used in SICP) does AFAIK.
Standard Scheme only lets you EVAL stuff in the "standard environment",
where the usual function bindings exist.
--
Suffering from Gates-induced brain leakage...
Ulrich Hobelmann wrote:
> Majorinc wrote:
>
>> Which eval is better, Common Lisp or Scheme? I was warned that Common
>> Lisp eval does not understand local variables, but one specific
>> implementation does. Which one? Is it same for Scheme? Is there any
>> significant difference?
>
> I doubt Scheme is different. Supposedly you can use EVAL inside
> environments, but only MIT Scheme (as used in SICP) does AFAIK. Standard
> Scheme only lets you EVAL stuff in the "standard environment", where the
> usual function bindings exist.
CLisp and ISLISP also allow you to capture lexical environments and
later on execute forms in those lexical environments. IIRC, CLisp only
allows this for interpreted code, and ISLISP is interpreted anyway.
(Take this with a grain of salt, though.)
The two evals in Common Lisp and Scheme are just different interfaces. A
concrete implementation can always add more interfaces. None of them is
inherently "better" in any way. (Scheme's eval can probably be used to
write portable code that automagically works in implementations that
happen to support first-class lexical environments, but that's most
likely only a slight advantage.)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> CLisp and ISLISP also allow you to capture lexical environments and
> later on execute forms in those lexical environments. IIRC, CLisp
> only allows this for interpreted code, and ISLISP is interpreted
> anyway.
Do you mean that the ISLISP specification mandates that programs must
be interpreted?
Lars Brinkhoff wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>CLisp and ISLISP also allow you to capture lexical environments and
>>later on execute forms in those lexical environments. IIRC, CLisp
>>only allows this for interpreted code, and ISLISP is interpreted
>>anyway.
>
> Do you mean that the ISLISP specification mandates that programs must
> be interpreted?
Oops - my mistake. Thanks for asking which allows me to correct it.
OpenLisp, which is an implementation of ISLISP, allows you to capture
lexical environments and execute forms in them. ISLISP doesn't define
this and can most certainly be compiled, just like Common Lisp.
Thanks again,
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Majorinc wrote:
> Which eval is better, Common Lisp or Scheme? I was warned that
> Common Lisp eval does not understand local variables, but one
> specific implementation does. Which one? Is it same for Scheme?
> Is there any significant difference?
Scheme's eval is a two-argument eval that takes an environment
as its second argument. The standard provides accessors that
return particular environments (top level, current, R5RS, empty)
and these are implemented in most schemata.
What is required to make this maximally useful is mutable
environments. This is not guaranteed by the standard.
It is implemented in many schemata (Chicken, DrScheme, PLT,
Mit/GNU, etc) but omitted in several (GUILE, Stalin, etc).
In other words, if you want to evaluate an expression and
find out what it returns in any of the given environments,
you can use eval to do that in a standards-compliant way.
If you want to use variables bound to environments to implement
your own module system, that's okay too; you just define the
module-name variables, then use a let* or lambda to create
an environment in which given variables are bound to things
you want in your module, then set! in that environment to
bind a module-name variable to the current environment. Then
you can use eval with the environment name to access your
module's functions, etc. (There are a few broken schemes
where this doesn't work because you can't put an environment
in a variable as a value. I think GUILE has this problem.)
But the standard doesn't guarantee that these environments
will be mutable. IOW, executing a "define" or "set!" or
equivalent via eval is not guaranteed to change anything
in the named environment, so your "modules" in the above
system are going to be either static-only, or rely on more
than the standard guarantees. To be fair, in most schemata,
environments are mutable. Stalin is the only one I can
think of where they aren't, and that might have been fixed.
I don't think I really have enough experience with CL's eval
to comment on it, but as far as I can see it seems to refer
to the current (mutable) environment only, which makes it
a semantic equivalent to (eval ... (current-environment))
in any scheme that has mutable environments.
Bear
In article <·························@news.sonic.net>,
Ray Dillinger <····@sonic.net> wrote:
> I don't think I really have enough experience with CL's eval
> to comment on it, but as far as I can see it seems to refer
> to the current (mutable) environment only, which makes it
> a semantic equivalent to (eval ... (current-environment))
> in any scheme that has mutable environments.
It uses the null lexical environment, but of course it runs in the
current dynamic environment, so in some ways it's like what you say.
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
In article <·························@news.sonic.net>, ····@sonic.net
says...
> I don't think I really have enough experience with CL's eval
> to comment on it, but as far as I can see it seems to refer
> to the current (mutable) environment only, which makes it
> a semantic equivalent to (eval ... (current-environment))
> in any scheme that has mutable environments.
Hm, it looks as important difference to dig bit deaper.
Thanks to all who responded.