[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Well, the manual doesn't mention this restriction and, rather than
> fixing the manual, I wanted to understand the rationale behind this
> restriction.
That's fair enough. I guess the rationale is that the unit of
evaluation (as presented in backtraces for example) is a list, so it
is useful for source properties to be stored on lists when those are
read.
> I see no reason not to allow source properties to be attached to
> arbitrary non-immediates. The fact that this "won't work" for symbols
> is not, IMO, a sufficiently good reason to the current restriction. For
> instance, one might want to have the following definition of `eval':
>
> (let ((real-eval eval))
> (set! eval
> (lambda (expr env)
> (let ((props (source-properties expr))
> (result (real-eval expr env)))
> (if (or (vector? result) (record? result) (pair? result))
> (set-source-properties! result props))
> result))))
>
> This allows to keep source information further at run-time.
Yes, but why is that useful?
(So far, I think I'd vote for fixing the manual rather than extending
source properties ...)
Neil
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
