Jean Abou Samra <jean@abou-samra.fr> writes:
Le 30/12/2022 à 13:51, David Kastrup a écrit :
However, it doesn't work right now for local variables,
like function parameters, in #{ ... #}.
I think you may underestimate the cost of magic involved with making #/$
integrate into local Scheme scoping. If you want Scheme semantics, $
offers those along with Scheme syntax.
What is the cost of that magic precisely?
In the basic case of \ being used outside #{ #}, the extra cost
of \ being supported in #{ #} would be an assv-ref into an
empty alist of closures, i.e., ~0 cost.
While parsing #{ #}, we'd catch \ in addition to # and $.
We already read the entire #{ #} for that. I don't think
catching \ would add much overhead to it.
You conflate "parsing" and "reading". For #{...#}, there is a
rudimentary scan for # and $ that tends to deliver false positives
(which then just don't get evaluated later on) and may get confused into
overlooking actual positives. \ offers a lot more potential for getting
this wrong.
It would also make Guile evaluate one (lambda () <variable>) per use
of \ in #{ #}, which I don't believe is costly.
It is. The optimisation of not putting up closures for most constants
made a relevant performance difference.
While evaluating the \, the parser would need to do an assv-ref
into the closure alist, which in most cases will have under
10 elements (the number of '#' / '$' / '\' in the #{ #} expression).
If the linear cost of assv-ref is a concern, an obvious improvement
is to use a hash table.
The number of non-constant #/$ in a #{ ... #} will have a large hit rate
of actually needed scoping. I don't see this for \xxx .
Overall, I don't see what could have a worrisome cost.
Did I miss something?
See above. And there is absolutely no associated gain at all since
$identifier will work just fine where scoping is needed. The gain of
"people using Scheme but not understanding it might by chance escape
trivial errors" is not really a gamechanger.
OpenPGP_signature