Re: eval'ing a self-referential vector

[Jim Blandy <jimb@red-bean.com>]

> I was expecting a reply saying either the eval of a vector
> is a domain error, not that the error need be detected (is it? a
> glance at r5rs suggests it is though guile can certainly provide a meaning)
> or that the copy must be made for some reason and supporting self-referential
> vectors is undefined or some such (like for equal?).

Well, if there's a reasonable algorithm for doing it, and the
alternative is having Guile use up all the memory on your machine and
then crash, wouldn't you rather I said it was a bug that should be
fixed?  :)

Here's R5RS's position on this issue:
- The argument to Eval must be a valid expression represented as
  Scheme data, and therefore must not be cyclic.  (6.5)
- "It is an error for an operation to be presented with an argument
  that it is not specified to handle." (1.3.3)
- "An error situation that implementations are not required to detect
  is usually referred to simply as `an error.'" (1.3.2)

So we don't have to catch it.  But I'd rather we did.  So this is a
bug, albiet not the highest priority.

> But, I'll take your reply at face value ...
> If there's no reason, I'll repeat my question: why copy at all?
> Why not just have scm_copy_tree return vectors unchanged?
> (this assumes there are no other users that depend on this behaviour so
> the obvious implicit assumption is that if there are then eval would call
> something else).

We have to copy the list structure because the evaluator modifies it
as it goes, transforming it into a representation which is faster to
interpret.  The modified structure contains values which are dangerous
if they escape to the lisp level (i.e., you can crash Guile if you get
your hands on them).

I think we copy the vectors on the general principle that you
shouldn't be able to change the effect of procedures by
surreptitiously modifying the quoted constants you pass to eval.  Eval
should treat your expression as source.