Re: peval with extensible or arbitrary-precision arithmetic

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <address@hidden> 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’.