Re: eval-when and eval-case issues.

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> > Well, with both cond-expand and psyntax's eval-when, non-top-level
> > invocations are forbidden.  This seems like a wise restriction to
> > start with, we can always relax it later if it seems necessary and
> > the behavior can be clearly described.
> 
> Hmm, I feel that allowing eval-when in non-toplevel forms is important
> since macros might expand into it.

Well, I believe that eval-when is already not allowed anywhere but the
top level, though I'd have to double check to be sure, but note that
top level here may mean top level *after* macro expansions, which
seems to cover most of the cases I can think of.

> Yes, me too.  `eval' should probably be conceptually equivalent to
> `compile' followed by `execute'; `load' is conceptually equivalent
> to `eval'uating all forms one after the other.

OK, so I'm going to see how far I get trying to enhance eval-case to
support compile-toplevel.  Any form inside a compile-toplevel case
will *only* be evaluated at compile time.  I may also support "and"
and "or" combinations of load-toplevel and compile-toplevel, but we'll
see.

Then the compile strategy will be (in not-quite-right psuedo code):

  (load filename)  ;; To make sure macros are defined.

  (with-input-from-file filename
    (lambda ()
      (do ((next-form (read) (read)))
          ((eof-object? next-form))
        (write (deep-expand next-form) compilation-tmp-output-port))))

  (compile-file compilation-tmp-output-name))
   
and deep-expand (in this lame example) will handle expanding the
correct eval-case cases.

This may get me pretty close to being able to have gnucash be mostly
compilable.  We still won't want to compile everything, but trying to
compile everything is a good test.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930