Mikael Djurfeldt <address@hidden> writes:
> The interface of (value-history) would instead have a lazy-binder
> which provides a syntax transformer for every $... actually being
> used. The $... identifier would expand into a list-ref into the value
> history.
A few more suggestions:
If I write (define (foo x) (+ $$0 x)) at the repl, then I expect 'foo'
to continue to refer to the same entry in the value history, even after
the value history is later extended.
Well, this could be interpreted in two ways. What I expect is that $$0 always refers to the last entry of the value history, even if it has been extended, such that $$0 will evaluate to new values as new values are pushed onto value history.
This is also the effect we get if $$0 expands to (list-ref value-history 0).
I'm also a bit concerned about the efficiency implications of expanding
these variable references into 'list-ref' calls when the history grows
large. If I write a loop that evaluates $$0 a million times, I'd prefer
to avoid a million 'list-ref' calls.
Maybe this is a Microsoft-style argument, but do we really expect users to use value history in that way? If so, I guess value-history could be stored in a dynamically enlarged vector.
To address these concerns, I'd like to suggest a slightly different
approach:
* $0, $1, ... would continue to be ordinary variable bindings in
(value-history), as they are now.
* The 'count' in 'save-value-history' would be made into a top-level
variable in (ice-9 history).
(This (count) is what I had in mind for $<N>: $<N> -> (list-ref value-history (- count <N>)) )
* $$0, $$1, $$2, ... would be handled by a lazy-binder, providing a
syntax transformer that looks at the value of 'count' at macro
expansion time, and expands into the appropriate variable
reference $N.
For example, if $5 is the most recent value, $$0 would expand into $5
instead of (list-ref ...). This would eliminate my concerns over
efficiency.
What do you think?
This would then have the problem that $$0 would get a more complex meaning: It would mean "the most recent result at the time of macro expansion" rather than "the most recent result".
If efficiency really is a concern, I would expect that vector references would be rather efficient after compilation.
Best regards,
Mikael