Re: A question about a scheme function with two input notes

[David Kastrup]

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.

-- 
David Kastrup