guile-devel
[Top][All Lists]
Advanced

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

Re: syntax-local-binding


From: Peter TB Brett
Subject: Re: syntax-local-binding
Date: Tue, 24 Jan 2012 10:30:40 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Mon 23 Jan 2012 22:03, Mark H Weaver <address@hidden> writes:
>> Your priorities are reversed from what they ought to be.
>>
>> What you _should_ be worried about is making commitments in our API that
>> we must continue to support forever.  This is a _real_ problem, since it
>> constrains our ability to modify our implementation in the future.
>
> I know I'm going to sound like Mr. Collins in Pride and Prejudice here,
> but I flatter myself that I know a thing or two about managing change --
> I mean, replacing the lazy-memoizing evaluator with the compiler,
> retrofitting psyntax into Guile, the whole subr mess, etc.  There is
> always room to improve, of course, as in all human endeavor, but for now
> it does seem that Guile is getting more powerful _and_ more limpid over
> time.
>
> But frankly though, regarding change, while we do need the freedom to
> modify some things, some other practical freedoms just don't make the
> cost/benefit cut, for me.  For example, considering replacing psyntax,
> which seems to be in the back of your mind here.  This conservatism is
> preventing Guile from adding features.  And we do need features --
> local-eval and syntax-parse among them.

I'm sorry to say it, Andy, but I'm pretty certain that Mark's correct in
this case.  When you're making additions to a body of code that's
expected to be very widely used in a very diverse variety of
applications (such as, for example, the Linux kernel, or glibc), one
must be *incredibly careful* not to expose implementation details,
because users *will* depend on them and complain bitterly when they are
changed or removed.  I don't feel that your approach to this issue is
consistent with your wishes to massively increase Guile usage during
2012.

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) which Mark has managed to avoid.  I am at a loss to understand
why you are so vehemently opposed to using Mark's approach (even if only
in the short term while you two find a mutually-agreeable solution), and
I urge you to reconsider.

This is just my £0.02, and as "mere user" of Guile my opinion is
probably of little value in this discussion.  And as Mark pointed out,
you've clearly made your decision on this; I'm not holding much hope of
changing your mind.

Thanks for all your continuing work on Guile.

Regards,

                             Peter

-- 
Peter Brett <address@hidden>
Remote Sensing Research Group
Surrey Space Centre




reply via email to

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