Re: Guile compilation (getting started playing around)

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> For example, at first I was presuming that wrt macros, in the long run
> the hobbit-translator should never even see them, that they should be
> expanded completely while generating primitive-rep, but will that
> actually work?

I think so.  Why not?

> What effect would that have on the ability to re-define macros at
> runtime (I've seen the threads discussing the propagation of
> redefined macros.)?

I'd like to handle this issue externaly from the compiler, with a
Makefilish `defsystem' kind of thing, maybe.

> As a practical question, one of the things I recall being discussed
> was how code like this should be handled:
> 
>   (define *debugging?* #t)
>   ...
>   (define-macro (ifdebug . code)
>     (if *debugging?*
>       `(begin ,@code)
>       #t))
> 
> Should it be allowed?

Yes, I'd say it should be allowed.

> If so, what should it really do in a full hobbit-style system where
> compilation is completely separate from execution?

It will lead to errors when *debugging?* is not defined at compile
time when the macro transformer is executed.
 
> For example, perhaps we decide that running arbitrary code at compile
> time is a good idea (which is probably true for some special
> applications).

Yes, I think we should allow this in general.

> If so, then we could introduce new constructs to make such bits
> explicit.  i.e.
> 
>   (define-at-compile-time foo 42)
> 
> or we could consider what other systems like comon lisp (and AIR
> RScheme) have done (i.e. constructs like eval-when, etc.) i.e. in CL:
> 
>   (eval-when (:compile-toplevel :load-toplevel :execute)
>     ..)

We already have this. ;) There is `eval-case' and, in (ice-9 syncase),
`eval-when'.  They don't recognize `compile-toplevel' yet, of course.

> I tend to think that whatever solution we choose, being explict rather
> than trying to devise a clever DWIM system is often best.

Yep, exactly my opinion.