Hello Mark,
On Wed 25 Jan 2012 03:30, Mark H Weaver m...@netris.org 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
.
`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.
That's actually not what I meant, although I'm not convinced that we
fully understand the implications of exposing even that much. One
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
Peter TB Brett pe...@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
(and 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
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
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
functionality?
They are related questions
On Tue 24 Jan 2012 14:25, Mark H Weaver m...@netris.org 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
of this thread ;-)
On Tue 24 Jan 2012 14:25, Mark H Weaver m...@netris.org writes:
Andy Wingo wi...@pobox.com writes:
None of the interfaces that I proposed leak internal psyntax
representations.
`syntax-local-binding' leaks the internal representations used for
bindings.
You mean, whether
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.
That's actually not what I meant, although I'm
Heya Mark,
On Fri 20 Jan 2012 23:03, Mark H Weaver m...@netris.org 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, that this is simply
Andy Wingo wi...@pobox.com writes:
On Fri 20 Jan 2012 23:03, Mark H Weaver m...@netris.org 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
the fact with `the-environment' in psyntax, it's in the
default environment, of course; though with autoloads one can get around
that...
With `the-environment' in a module, in 2.0.4 we could have three
functions added to psyntax: syntax-local-binding,
syntax-locally-bound-identifiers, and syntax
Andy Wingo wi...@pobox.com 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
Hi,
Mark H Weaver m...@netris.org 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)))
Put another way: if anyone uses `syntax
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 representations will
interfere with our ability
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 longer sufficient to simulate a lexical.
Why do you say
'
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 longer sufficient to simulate
On Tue 17 Jan 2012 00:27, Andy Wingo wi...@pobox.com 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
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 patches
welcome
Andy Wingo wi...@pobox.com 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
Hi Andy!
Andy Wingo wi...@pobox.com 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
Hi Andy!
Thanks again for working on this.
Andy Wingo wi...@pobox.com 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 this
Hi Mark,
On Mon 16 Jan 2012 21:36, Mark H Weaver m...@netris.org 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
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 ()
((_ id
On Sun 15 Jan 2012 18:00, Andy Wingo wi...@pobox.com 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 wi...@pobox.com
Date: Sun, 15 Jan 2012 17:51:02 +0100
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 to get
@@ -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-identifier=? #f)
+(define bound-identifiers #f)
(define syntax-local-binding #f)
;; $sc-dispatch is an implementation
28 matches
Mail list logo
