Hi Ludovic!
Thanks for your work on partial evaluation, this is very exciting! :)
I have a few comments on your v2.0.2-70-gcf14f30 commit:
> + (define (pure-expression? x)
> + ;; Return true if X is pure---i.e., if it is known to have no
> + ;; effects and does not allocate new storage. Note: <module-ref> is
> + ;; not "pure" because it loads a module as a side-effect.
> + (let loop ((x x))
> + (match x
[...]
> + (($ <application> _ ($ <primitive-ref> _ name) args)
> + (and (effect-free-primitive? name)
> + (not (constructor-primitive? name))
> + (every loop args)))
[...]
> (define *effect-free-primitives*
> - '(values
> + `(values
> eq? eqv? equal?
> = < > <= >= zero?
> + * - / 1- 1+ quotient remainder modulo
As currently implemented, `pure-expression?' does not behave as its
header comment claims, because in most cases the arithmetic operators
_do_ allocate storage.
Unfortunately, there's another complication as well. As you know, there
are plans to eventually add support for arbitrary-precision floats, at
which point the result of arithmetic operators will depend not only on
their arguments, but also on the value of a fluid which specifies the
desired precision.
I can anticipate the usefulness of other fluids as well, e.g. ones that
influence what types of numeric representations are used. For example,
some day we might want to add a fluid to control whether exact rationals
are created by default. Along a similar vein, I can foresee adding
things like fixed-point precision numbers, exact complex numbers in
polar form, infinite-precision reals (as many digits as you want,
computed lazily), or even symbolic representations of exact irrationals,
and these features would require more fluids to control their usage.
Even today, the arithmetic operators are extensible with GOOPS, and for
some representations it is advantageous to control the behavior of the
associated methods using fluids.
For now, one reasonable compromise would be for peval to perform
arithmetic operations only when the results are exact. Allowing peval
to safely perform inexact arithmetic is a more difficult problem.
Thoughts?
Mark
