[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] compile-time eval-time mismatch

From: felix winkelmann
Subject: Re: [Chicken-users] compile-time eval-time mismatch
Date: Wed, 8 Dec 2004 12:58:17 +0100

On Wed, 8 Dec 2004 05:33:47 -0500, Michele Simionato
<address@hidden> wrote:
> Thanks Felix, I think this is the THIRD time I ask you about eval-when.
> For same reason, I cannot get my mind around it. I also made you to
> change the documentation, but still it is not 100% clear to me how to
> use it.

I will try to revise it.

> For instance, now I understand why
> works only with the "load" option (BTW, "load" is the most confusing name
> one can imagine) but I still I do not understand why

Yes, "load" is a historical name, taken over from Lisp (and Chez Scheme).
> (eval-when
>   (compile eval)
>   (define (make-macro name)
>     (eval `(define-macro (,name x) x)))
>   (make-macro 'identity-macro) )
> (display (identity-macro 2))
> does NOT work if I give the "load" option [with an absolutely
> misterious error message :-(].

In this case, the error occurs from the fact that the evaluator
(at run-time) does only understand R5RS (minus define-syntax).
This is intended to keep the stuff that is slurped in by default small,
since run-time evaluation is in many cases not necessary
(You can of course add a `(include "chicken-more-macros")'
at the start of your file to make the non-standard macro definitions
available at run-time, but I guess this isn't what you like
to hear).

> Why it has to be so cumbersome??

In part because you want the same code to execute in numerous,
quite different situations: in the interpreter (where eval- and run-time
are the same), at compile-time in the compiler and at run-time in
compiled executables.
This is a fundamental problem, partly (but IMHO not completely) 
solved by PLTs  module system (it just separates the different
levels in a stricter fashion).
The other part is that Chicken tries to keep things not necessarily
needed out of the code that is linked/compiled into a created
executable. This admittedly results in somewhat unintuitive behaviour,
once one tries to mix these different execution contexts. Add
the fact that separate compilation must be possible and gets even
more complicated. Things would be much easier if there would just
exist an interpreter, or a compiler that holds everything in a
memory image, and where compile-time and run-time are less strictly

Here another attempt to clarify eval-when:

'eval': execute the body in the interpreter (csi), and in csi only.
'load': execute the code in compiled code, not in interpreted (by csi) code.
'compile': execute the code during compilation (with csc/chicken).

So we have actually two problems here:

1) the naming of the situations in `eval-when'. I will add aliases for
   eval/load/compile  to make this clearer (any suggestions are welcome).
2) The provided macro system for code evaluated at run-time in compiled
  executables. By default there is effectively none (well, it's the normal
  low-level one, but it doesn't provide a way to define macros).
  This is bad, I'll change it to allow `define-macro' actually to be used.

Sorry for the confusion this seems to create.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]