unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Peter TB Brett <peter@peter-b.co.uk>
To: guile-devel@gnu.org
Subject: Re: syntax-local-binding
Date: Tue, 24 Jan 2012 10:30:40 +0000	[thread overview]
Message-ID: <we1md3a9pf3j.fsf@ssclt001.ee.surrey.ac.uk> (raw)
In-Reply-To: 87zkdem58t.fsf@pobox.com

Andy Wingo <wingo@pobox.com> writes:

> On Mon 23 Jan 2012 22:03, Mark H Weaver <mhw@netris.org> 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 <peter@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre




  parent reply	other threads:[~2012-01-24 10:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-15 17:00 syntax-local-binding Andy Wingo
2012-01-15 17:22 ` syntax-local-binding Andy Wingo
2012-01-19 11:41   ` syntax-local-binding Andy Wingo
2012-01-20 20:26     ` syntax-local-binding Mark H Weaver
2012-01-20 21:23       ` syntax-local-binding Andy Wingo
2012-01-20 22:03         ` syntax-local-binding Mark H Weaver
2012-01-22  0:03           ` syntax-local-binding Ludovic Courtès
2012-01-23 16:05           ` syntax-local-binding Andy Wingo
2012-01-23 21:03             ` syntax-local-binding Mark H Weaver
2012-01-23 22:19               ` syntax-local-binding Andy Wingo
2012-01-24  2:11                 ` syntax-local-binding Mark H Weaver
2012-01-24 11:42                   ` syntax-local-binding Andy Wingo
2012-01-24 17:29                     ` syntax-local-binding Noah Lavine
2012-01-24 10:30                 ` Peter TB Brett [this message]
2012-01-24 10:38                   ` syntax-local-binding David Kastrup
2012-01-24 11:26                   ` syntax-local-binding Andy Wingo
2012-01-24 13:25                     ` syntax-local-binding Mark H Weaver
2012-01-24 20:28                       ` mark uniqueness (Was: Re: syntax-local-binding) Andy Wingo
2012-01-25  0:26                         ` mark uniqueness Mark H Weaver
2012-01-25  9:02                           ` Andy Wingo
2012-01-24 21:22                       ` syntax-local-binding Andy Wingo
2012-01-25  2:30                         ` syntax-local-binding Mark H Weaver
2012-01-25  7:49                           ` syntax-local-binding Stefan Israelsson Tampe
2012-01-25 11:18                           ` syntax-local-binding Andy Wingo
2012-01-25 13:18                           ` syntax-local-binding Ludovic Courtès
2012-01-25 18:08                             ` syntax-local-binding Mark H Weaver
2012-01-26 11:21                             ` syntax-local-binding Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=we1md3a9pf3j.fsf@ssclt001.ee.surrey.ac.uk \
    --to=peter@peter-b.co.uk \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).