[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: syntax-local-binding

From: Ludovic Courtès
Subject: Re: syntax-local-binding
Date: Wed, 25 Jan 2012 14:18:03 +0100
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

Hello Happy Guilers!  :-)

Sorry for remaining silent in this heated thread (I spent my spare time
on other practical issues for 2.0.4, and felt I lacked the competence.)

My overall feeling is that providing a 1.8-compatible ‘local-eval’ in
2.0 is great, but that it’s essentially one bug to be fixed among many

Thus, I appreciate all the work Andy and you have put into it, and I’m
glad it will be helpful to Guile users such as Lilypond.  However, I
think, that we should keep in mind that Guile is not just about
‘local-eval’, and that there are other great things to work on together.

As for the technical aspects:

Mark H Weaver <address@hidden> skribis:

> Andy Wingo <address@hidden> writes:
>> On Tue 24 Jan 2012 14:25, Mark H Weaver <address@hidden> writes:
>>> Andy Wingo <address@hidden> writes:
>>>> None of the interfaces that I proposed leak internal psyntax
>>>> representations.
>>> `syntax-local-binding' leaks the internal representations used for
>>> bindings.
>> You mean, whether something is a lexical, or a macro, or a global, or
>> whatever; OK.
> That's actually not what I meant, although I'm not convinced that we
> fully understand the implications of exposing even that much.  One thing
> that is already clear is that `identifier-syntax' and `local-eval' were
> previously capable of emulating variables perfectly before, whereas in
> the presence of `syntax-local-binding' they no longer are.
> This is a perfect example of how added flexibility in one aspect can
> lead to _reduced_ flexibility in other aspects.  I think we need more
> time to consider the implications of this.

I agree.  Yet, it’s the kind of API that is useful internally for
different purposes beyond ‘local-eval’, as this discussion showed,

So, IIUC, the tension is:

  1. Such as API is desirable for Guile-internal consumption.

  2. Exposing it to users may restrict our ability to change the
     implementation in the future, just like ‘the-environment’ did.

I haven’t fully thought about it, but one possible trade-off would be to
mark ‘syntax-local-binding’ & co. as internal, somehow arrange to make
them visible only from some (system ...) module, and document them in
the “Implementation” chapter.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]