peval with extensible or arbitrary-precision arithmetic

peval with extensible or arbitrary-precision arithmetic

[Mark H Weaver]

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

Re: peval with extensible or arbitrary-precision arithmetic

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <mhw@netris.org> skribis:

> 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.

Sorry, the headers are misleading: it’s not about whether a primitive
allocates new storage, but whether it allocates storage for a *mutable*
object.  For instance, that ‘+’ allocates storage for a bignum doesn’t
matter as they are immutable.

> 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.

Yes, good point.  Well, wait and see?  :-)

Surely the current assumption will have to be revisited then.  But I
can’t tell exactly how until we have an actual API, which will probably
be in 2.2.

[...]

> 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.

Note that arithmetic operators were already inlined before peval.

> 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.

You must be right (GCC uses MPFR for constant folding).  I’ll change
primitives.scm to that effect, then.

Thanks for your feedback!

Ludo’.