unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Andy Wingo <wingo@pobox.com>
Cc: Peter TB Brett <peter@peter-b.co.uk>, guile-devel@gnu.org
Subject: Re: syntax-local-binding
Date: Tue, 24 Jan 2012 08:25:52 -0500	[thread overview]
Message-ID: <874nvls04f.fsf@netris.org> (raw)
In-Reply-To: <87d3a9mjcy.fsf@pobox.com> (Andy Wingo's message of "Tue, 24 Jan 2012 12:26:53 +0100")

Andy Wingo <wingo@pobox.com> writes:

> On Tue 24 Jan 2012 11:30, Peter TB Brett <peter@peter-b.co.uk> 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	other threads:[~2012-01-24 13:25 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                 ` syntax-local-binding Peter TB Brett
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                     ` Mark H Weaver [this message]
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=874nvls04f.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guile-devel@gnu.org \
    --cc=peter@peter-b.co.uk \
    --cc=wingo@pobox.com \
    /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).