guile-devel
[Top][All Lists]
Advanced

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

Re: syntax-local-binding


From: Mark H Weaver
Subject: Re: syntax-local-binding
Date: Tue, 24 Jan 2012 08:25:52 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Tue 24 Jan 2012 11:30, Peter TB Brett <address@hidden> writes:
>
>> It seems pretty clear to me that the only (debatable) downside to using
>> Mark's implementation is that some definitions end up in the "wrong"
>> module, while your implementation has several potentially *major*
>> problems (including the necessity of providing universally unique
>> gensyms)
>
> Let's be clear here: the universally-unique gensym issue is something
> that Guile *already* has, in version 2.0.0, 2.0.1, etc.

I don't see why we need universally-unique gensyms unless your approach
to `local-eval' is used.  I've already explained why they are not needed
for macros compiled in another session.

>> It concerns me when I see internal psyntax representations exported in
>> our API.
>
> None of the interfaces that I proposed leak internal psyntax
> representations.

`syntax-local-binding' leaks the internal representations used for
bindings.  I gave an example where this would constrain our ability to
change the binding representation for syntactic keywords, and your
response was to point out that my particular example could be done in a
different way without changing the representation.  Your response
demonstrated the weakness of my particular example, while underscoring
my main point: that this constrains our internal representation choices.

>> I just have one final request: please at least change the lexical
>> environments in your `local-eval' implementation to use the future-proof
>> `evaluator procedure' representation, as I have done in mine.
>
> For the reasons I mentioned in my mail yesterday at 12:52 UTC, I really
> don't see the point, as we have more effective means of dealing with
> future change than introducing an abstraction there.

Your suggested "more effective means" is to introduce a new type
<lexical-environment-2> and continue supporting <lexical-environment>.
No thanks.

> But if it will make you happy, sure.  I'm quite tired of this topic
> ;-)

Yes, it would make me happy, thank you.  And believe me, I'm tired of
this topic too.  I thought I was mostly finished working on `local-eval'
three weeks ago, when I produced my simple patch, which I _still_ think
is superior to yours in the most important respect, namely in the
commitments that it forces us to make.

    Regards,
      Mark



reply via email to

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