-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.
I
I have nothing new to say here, so I'll spare you all my increasingly
frustrated repetitions. I need to walk away for a while. Do what you
feel is best. Good luck.
Mark
.
As for the technical aspects:
Mark H Weaver skribis:
> Andy Wingo writes:
>> On Tue 24 Jan 2012 14:25, Mark H Weaver writes:
>>
>>> Andy Wingo writes:
>>>
>>>> None of the interfaces that I proposed leak internal psyntax
>>>> represent
Hello Mark,
On Wed 25 Jan 2012 03:30, Mark H Weaver writes:
>> Perhaps, though, at this point we're just going to have to agree to
>> disagree;
>
> This is a euphemism for "sorry, but we're doing it my way".
Just a few days ago, you said:
On Sun 22 Jan 2012 13:23, Mark H Weaver writes:
> If
a
small set of accessors that logicaly is about getting information that are
defined as scheme and not as something that is internal I would say that
the burden is to a large degree an illusion.
For example the use of syntax-local-binding in syntax-parse is to
(define-syntax class data) or (let
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.
e duration of this thread ;-)
On Tue 24 Jan 2012 14:25, Mark H Weaver writes:
> Andy Wingo writes:
>
>> None of the interfaces that I proposed leak internal psyntax
>> representations.
>
> `syntax-local-binding' leaks the internal representations used for
> b
On Tue 24 Jan 2012 14:25, Mark H Weaver writes:
> I don't see why we need universally-unique gensyms
> I've already explained why they are not needed
> for macros compiled in another session.
Ah, I forgot to reply to that. I found it:
On Mon 16 Jan 2012 14:28, Mark H Weaver writes:
> The rea
to this argument. There are two separate
questions being debated as one question. Here they are:
1. Do we forsee a need to deprecate the syntax-local-binding
functionality in the future, for instance to move away from psyntax?
2. Is this version of syntax-local-binding the best interface to this
f
eed 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 int
the past), one must not forget about the present :)
> 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 provides binding information for an identifier.
Racket pr
On Tue 24 Jan 2012 11:30, Peter TB Brett 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
Peter TB Brett 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
Andy Wingo writes:
> On Mon 23 Jan 2012 22:03, Mark H Weaver 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
>> constrain
Andy Wingo 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 f
of taste, but however
> strongly you may feel about that, it is a purely _internal_
> implementation issue. The really important thing is that it commits us
> to _nothing_. There's nothing stopping us from radically reimplementing
> it later. In particular, there's nothi
Andy Wingo writes:
> On Fri 20 Jan 2012 23:03, Mark H Weaver writes:
>
>> (let ((x 1))
>> (syntax-local-binding #'x))
>>
>> is not equivalent to:
>>
>> (let ((x 1))
>> (local-eval '(syntax-local-binding #'x) (the-en
Heya Mark,
On Fri 20 Jan 2012 23:03, Mark H Weaver writes:
> (let ((x 1))
> (syntax-local-binding #'x))
>
> is not equivalent to:
>
> (let ((x 1))
> (local-eval '(syntax-local-binding #'x) (the-environment)))
Indeed; bummer! I think, though,
Hi,
Mark H Weaver skribis:
> Because it breaks your nice equivalence. For example:
>
> (let ((x 1))
> (syntax-local-binding #'x))
>
> is not equivalent to:
>
> (let ((x 1))
> (local-eval '(syntax-local-binding #'x) (the-environment)))
&
nding.
>>>
>>> `macro'
>>> A syntax transformer, either local or global. The value is
>>> the transformer procedure.
>>
>> Ironically, `syntax-local-binding' renders the current simple
>> implementation strategy of
A syntax transformer, either local or global. The value is
>> the transformer procedure.
>
> Ironically, `syntax-local-binding' renders the current simple
> implementation strategy of `the-environment' inadequate, because
> identifier-syntax is no long
the transformer procedure.
Ironically, `syntax-local-binding' renders the current simple
implementation strategy of `the-environment' inadequate, because
identifier-syntax is no longer sufficient to simulate a lexical.
More importantly, this exposing of internal binding representat
Hello,
I have now pushed an implementation of syntax-local-binding to
stable-2.0, with the following documentation. In the spirit of Eli's
note on Racket's syntax-local-value, it also works with identifiers that
are bound at the module level or the top level. Comments and patch
On Tue 17 Jan 2012 00:27, Andy Wingo writes:
> TBH I think this is the best thing we can do for local-eval. We
> preserve flexibility for local-eval, make other experiments possible,
> and the local-eval implementation is a bit more perspicacious, as the
> scoping is more lexical (in the same fi
Andy Wingo writes:
> What if instead we implemented closure serialization somehow? Then we
> would handle procedural macros too, and bound-identifiers would still be
> sufficient.
>
> Maybe that idea is a little too crazy.
Are we still talking about Scheme? The language with
call-with-current-
Hi Mark,
On Mon 16 Jan 2012 21:36, Mark H Weaver writes:
> Thanks again for working on this.
And thank you again for all your work, and patience with my
pigheadedness.
> if you insist in this foolish quest to banish `the-environment' to
> sleep in the shed as a second-class citizen, I cannot s
Hi Andy!
Thanks again for working on this.
Andy Wingo writes:
* Why are you adding anti-marks here?
>>>
>>> As the changelog noted (and a comment should have noted ;), the
>>> identifiers are anti-marked so that syntax transformers can introduce
>>> them, as-is.
>>>
>>> The purpose of t
Hi Mark,
Thanks for the comments :)
On Mon 16 Jan 2012 14:28, Mark H Weaver writes:
> Andy Wingo writes:
+ (cons (wrap (car symnames)
+ (anti-mark (make-wrap (car marks) subst))
>>>
>>> * Why are you adding anti-marks here?
>>
>
Hi Andy!
Andy Wingo writes:
>>> + (cons (wrap (car symnames)
>>> + (anti-mark (make-wrap (car marks) subst))
>>
>> * Why are you adding anti-marks here?
>
> As the changelog noted (and a comment should have noted ;), the
> identifiers are an
sible using syntax objects.
>
> * I guess this last sentence should now be removed. Also, remember
> that if pattern variables aren't reimplemented, this limitation needs to
> be documented.
Yes.
>> +(define (partition-identifiers ids)
>> + (let lp (
cdd8d1..b8aa842 100644
> --- a/module/ice-9/boot-9.scm
> +++ b/module/ice-9/boot-9.scm
> @@ -389,6 +389,7 @@ If there is no handler at all, Guile prints an error and
> then exits."
> (define generate-temporaries #f)
> (define bound-identifier=? #f)
> (define free-id
Hi Mark,
I had made some noise about preferring an implementation of local-eval
based on primitives from psyntax. But, I didn't clarify my argument by
providing the primitives. Here are some patches that provide
syntax-local-binding, as I noted in my previous mail, and also a
procedure t
On Sun 15 Jan 2012 18:00, Andy Wingo writes:
> Attached is a patch that implements a new accessor,
> syntax-local-binding.
Here 'tis!
>From 09ba44abeb47cdf4ec61df6f7386217f0cbe30c7 Mon Sep 17 00:00:00 2001
From: Andy Wingo
Date: Sun, 15 Jan 2012 17:51:02 +0100
Subject: [PAT
Hi list,
Attached is a patch that implements a new accessor,
syntax-local-binding. It's like syntax-local-value, but can also
determine if an identifier is a pattern var or a normal lexical.
> (define-syntax local-binding
(lambda (x)
(syntax-case x ()
34 matches
Mail list logo
