syntax closures

syntax closures

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

____ FUN with syntax case ____

Hi all, I wanted to resurrect the idea of a syntactic closure. I did some
thinking and
decided on the following system:

The low level routine is a special macro 'syntax-closure' put in (ice-9
syntax-closure)
The macro has the following ideom

  (syntax-closure closure-object template1 ...)

e.g.

  #`(syntax-closure #,(lambda (x y) (f x 1 y)) #'(+ x z) #'w)

1. Note that we use #, to insert a function object into the syntax
expression
2. The idea is to capture the syntactic environment in template1 ... and
 call the
    closure with the captured syntactic elements and insert the resulting
syntax into
.

The code for syntax-closure is simple:

(define-syntax-rule (syntax-closure f x ...)
  (let-syntax ((capture (lambda (stx)
                          (syntax-case stx ()
                            ((_ y (... ...))
                             (apply f #'(y (... ...))))))))
    (capture x ...)))

And with this tool we can device a very useful reader extension #_ e.g.

(define (syntax-closure-reader chr port)
  (define (g-loop x)
    (let loop ((x x) (a '()) (g '()) (t '()))
      (match x
        (((and stx ('syntax x)) . l)
         (let ((gen (gensym "template")))
           (loop l (cons gen a) (cons gen g) (cons x t))))
        ((x . l)
         (loop l (cons x a) g t))
        (()
         (values (reverse a) (reverse g) (reverse t))))))

  (let ((code (read port)))
    (match code
      ((F X ...)
       (call-with-values (lambda () (g-loop X))
         (lambda (args gensyms template)
           `(syntax-closure
             (unsyntax (lambda ,gensyms
                         (,F ,@args)))
             ,@template))))
      (_ (error "wrong format in syntax-closure-reader")))))

(read-hash-extend #\_ syntax-closure-reader)

And with this we can now do

  (define (g x) x)
  (define-syntax f (lambda (x) #`(let ((x 1)) #_(g #'x))))

leading to

scheme@(guile-user)> f
$2 = 1

The reader extension will be of the form
#_(F a ...)

And all (syntax x) arguments in a ... will be automatically captured from
the environment
e.g. #_ is as #, but with the syntax arguments correctly captured from the
surrounding
environment.

With this tool we will get close enough to srfi-72 and that code will not
be needed.

I'm I out of the blue here?

The question for me is how to treat this code, as a library of it's own
supporting e.g.
racket and guile and other schemes with the syntax case system, or should
we try to make this reader extension as nice as possible and incorporate
the code in guile. Is #_ ok? do you have any other suggestion?

Regards
/Stefan

[-- Attachment #2: Type: text/html, Size: 4006 bytes --]

Re: syntax closures

[Andy Wingo]

Hi,

On Thu 17 Jan 2013 21:51, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

> Hi all, I wanted to resurrect the idea of a syntactic closure. I did
> some thinking and

Meta: I seem to be receiving your mails with this really strange line
wrapping.  It's been this way for a while, and it makes it difficult to
read your mails.  Would you mind taking a look at your editor and
setting the fill column to 72 characters?  Thanks :)

> 2. The idea is to capture the syntactic environment in template1 ... and
>  call the
>     closure with the captured syntactic elements and insert the
> resulting syntax into
> .

Into what?

> (read-hash-extend #\_ syntax-closure-reader)

Have you tried having your srfi-72 module export a binding for unsyntax?

> The question for me is how to treat this code, as a library of it's
> own supporting e.g. racket and guile and other schemes with the
> syntax case system, or should we try to make this reader extension as
> nice as possible and incorporate the code in guile. Is #_ ok? do you
> have any other suggestion?

I would prefer not to include it in the core; in my ignorance I do not
see the need, especially if it can be implemented in a library.  Of
course it may make sense to bundle a srfi-72 implementation with guile,
but ideally we can do so without affecting the core.

Regards,

Andy
-- 
http://wingolog.org/

Re: syntax closures

[Stefan Israelsson Tampe]

Hi


On Tue, Jan 22, 2013 at 1:56 PM, Andy Wingo <wingo@pobox.com> wrote:
>
> Hi,
>
> On Thu 17 Jan 2013 21:51, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
> > Hi all, I wanted to resurrect the idea of a syntactic closure. I did
> > some thinking and
>
> Meta: I seem to be receiving your mails with this really strange line
> wrapping.  It's been this way for a while, and it makes it difficult to
> read your mails.  Would you mind taking a look at your editor and
> setting the fill column to 72 characters?  Thanks :)

I'm using a web interface, poor me, I'll try to use a proper client
after this mail.

> > 2. The idea is to capture the syntactic environment in template1 ... and
> >  call the
> >     closure with the captured syntactic elements and insert the
> > resulting syntax into
> > .
>
> Into what?

Heh, I misstakenly pushed a send shortcut that mixed badly with emacs
keybindings. Anyway the captured syntaxes is then inserted in their positions.
There are a few caveats with the approach, see the code file in the repo for
a discussion of that.

> > (read-hash-extend #\_ syntax-closure-reader)
>
> Have you tried having your srfi-72 module export a binding for unsyntax?

I would like to use that of cause, but does it mix well with other
already written code?

> > The question for me is how to treat this code, as a library of it's
> > own supporting e.g. racket and guile and other schemes with the
> > syntax case system, or should we try to make this reader extension as
> > nice as possible and incorporate the code in guile. Is #_ ok? do you
> > have any other suggestion?
>
> I would prefer not to include it in the core; in my ignorance I do not
> see the need, especially if it can be implemented in a library.  Of
> course it may make sense to bundle a srfi-72 implementation with guile,
> but ideally we can do so without affecting the core.

I would like to be able to set this feature on per port bases just
like we do with
other reader features. Don't know to what a degree you need to do to
achieve this.
Is it something that a library can do? This relates to the previous
question. Anyway
I just thoght your thoughts and published a repo,

https://gitorious.org/syntax-closures

And I also suggeted to ijp to put it into guild-hall.

Regards
Stefan

Re: syntax closures

[Andy Wingo]

On Tue 22 Jan 2013 17:19, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:

>> > (read-hash-extend #\_ syntax-closure-reader)
>>
>> Have you tried having your srfi-72 module export a binding for unsyntax?
>
> I would like to use that of cause, but does it mix well with other
> already written code?

It should work in a modular fashion.  #,foo reads as (unsyntax foo), and
the meaning of that depends on the binding of unsyntax that is current.

Andy
-- 
http://wingolog.org/

Re: syntax closures

[Stefan Israelsson Tampe]

Hi wingo:

Yes this is something I can do. But on a second thought I can't find a way to
handle unsyntax-splicing without a splicing macro. Modding #, and not #,@
just screams for difficult errors to show up. Therefor I will in stead
just write
another macro unsyntax-72 that people can use.

btw, I tried to get gnus working but cannot send mail from it :-(

/Stefan

On Tue, Jan 22, 2013 at 5:38 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Tue 22 Jan 2013 17:19, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
>>> > (read-hash-extend #\_ syntax-closure-reader)
>>>
>>> Have you tried having your srfi-72 module export a binding for unsyntax?
>>
>> I would like to use that of cause, but does it mix well with other
>> already written code?
>
> It should work in a modular fashion.  #,foo reads as (unsyntax foo), and
> the meaning of that depends on the binding of unsyntax that is current.
>
> Andy
> --
> http://wingolog.org/

Re: syntax closures

[Stefan Israelsson Tampe]

Ok, the unsyntax-72 code cannot be cleanly done I think. You really need
to use a reader macro. I leave the code base modding the reader char #.
as before and will simple wait for a a possibility of per port reader
option to be configured
via a library.

/Stefan

On Tue, Jan 22, 2013 at 5:38 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Tue 22 Jan 2013 17:19, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
>>> > (read-hash-extend #\_ syntax-closure-reader)
>>>
>>> Have you tried having your srfi-72 module export a binding for unsyntax?
>>
>> I would like to use that of cause, but does it mix well with other
>> already written code?
>
> It should work in a modular fashion.  #,foo reads as (unsyntax foo), and
> the meaning of that depends on the binding of unsyntax that is current.
>
> Andy
> --
> http://wingolog.org/

Re: syntax closures

[Stefan Israelsson Tampe]

Hi,

I managed to do what you said, the result is at

https://gitorious.org/syntax-closures

I changed it so that it is enough to do

(use-modules (srfi srfi-72))

and hacking along with it using both
#, and #,@

Especially #,@ was difficult but using the ck macro
the appending become more natural. I would expect
the code to be quite expensive computationally though.

On a side note, the quasisyntax expander will severely
transform syntaxes of the form (a b c #,@( ...) a) though
and therefore any macro that assume that this list can have
some form on say 'a b c', will fail because the whole list will
be transformed by quasisyntax. It is possible to introduce splicing
macros in psyntax I think and then the system would be even more
true to the srfi-72. Because I suspect that the srfi-72 spec and
the huge transformation of the list e.g. append macros, does not
mix well.

Anyway it was a fun hack, thanks!
/Stefan

On Tue, Jan 22, 2013 at 5:38 PM, Andy Wingo <wingo@pobox.com> wrote:
> On Tue 22 Jan 2013 17:19, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>
>>> > (read-hash-extend #\_ syntax-closure-reader)
>>>
>>> Have you tried having your srfi-72 module export a binding for unsyntax?
>>
>> I would like to use that of cause, but does it mix well with other
>> already written code?
>
> It should work in a modular fashion.  #,foo reads as (unsyntax foo), and
> the meaning of that depends on the binding of unsyntax that is current.
>
> Andy
> --
> http://wingolog.org/

Re: syntax closures

[Alex Shinn]

[-- Attachment #1: Type: text/plain, Size: 695 bytes --]

On Thu, Jan 24, 2013 at 8:24 AM, Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

> Hi,
>
> I managed to do what you said, the result is at
>
> https://gitorious.org/syntax-closures
>
> I changed it so that it is enough to do
>
> (use-modules (srfi srfi-72))
>

Note SRFI-72 is not an implementation of syntactic-closures.
It's an alternate hygiene algorithm closer to the R6RS one which
includes a compatible syntax-case and some convenience utilities.

Syntactic-closures never had a formal specification, just
an informal description and reference implementation, so
it's not clear to me if SRFI-72's make-capturing-identifier is
equivalent to the synclos free variables.

-- 
Alex

[-- Attachment #2: Type: text/html, Size: 1375 bytes --]

Re: syntax closures

[Stefan Israelsson Tampe]

Hi Alex!

> Note SRFI-72 is not an implementation of syntactic-closures.
> It's an alternate hygiene algorithm closer to the R6RS one which
> includes a compatible syntax-case and some convenience utilities.

To comments to this:
1. The main reason for SRFI-72 is to e.g. capture the let bound y in
the syntax in
     (define y 1)
     (define (f x) x)
     (let-syntax ((g (lambda (x) #`(let ((y 2)) #,(f #'y))))) g)
     -> 2
   And the same with #,@. In SRFI-72 they design a whole new hygiene
   method etc. for that. What I tried to do was to get this result as well at
   good approximation within the current syntax system.

2. I was actually hesistant to call this srfi-72 because of trying to
do what it want
   more than what it say's. A main trick to simulate the effect was to introduce
   a closure in the syntax at one point and therefore a choose the name
   syntax-closure not knowing that there is an already a notion of
that in the wild
   sorry!


> Syntactic-closures never had a formal specification, just
> an informal description and reference implementation, so
> it's not clear to me if SRFI-72's make-capturing-identifier is
> equivalent to the synclos free variables.

yeah I could be out of the blue saying srfi-72. Maybe the algorithm
needs a srfi
of it's own because it does useful stuff and integrates well with
standard syntax-case
systems which srfi-72 don't. And of cause the mentioning of synclos could be
confusing.

/Stefan

Re: syntax closures

[Alex Shinn]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Thu, Jan 24, 2013 at 4:11 PM, Stefan Israelsson Tampe <
stefan.itampe@gmail.com> wrote:

>
> 2. I was actually hesistant to call this srfi-72 because of trying to
> do what it want
>    more than what it say's. A main trick to simulate the effect was to
> introduce
>    a closure in the syntax at one point and therefore a choose the name
>    syntax-closure not knowing that there is an already a notion of
> that in the wild
>

Oh - I thought you were referring to the existing syntactic-closures.
I guess it's a plausible enough name to reuse coincidentally...

Carry on then :)

-- 
Alex

[-- Attachment #2: Type: text/html, Size: 1105 bytes --]

Re: syntax closures

[Mikael Djurfeldt]

Just saw this.

Right, "syntactic closures" is the name of a macro system by Alan
Bawden and Jonathan Rees:

http://en.wikipedia.org/wiki/Syntactic_closures

http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Syntactic-Closures.html#Syntactic-Closures

So, it would be good to choose a different name if what you are doing
is different.

BTW, the sc-macro-transformer facility of MIT-scheme would be nice to have. :-)

Best regards,
Mikael D.

On Thu, Jan 24, 2013 at 9:45 AM, Alex Shinn <alexshinn@gmail.com> wrote:
> On Thu, Jan 24, 2013 at 4:11 PM, Stefan Israelsson Tampe
> <stefan.itampe@gmail.com> wrote:
>>
>>
>> 2. I was actually hesistant to call this srfi-72 because of trying to
>> do what it want
>>    more than what it say's. A main trick to simulate the effect was to
>> introduce
>>    a closure in the syntax at one point and therefore a choose the name
>>    syntax-closure not knowing that there is an already a notion of
>> that in the wild
>
>
> Oh - I thought you were referring to the existing syntactic-closures.
> I guess it's a plausible enough name to reuse coincidentally...
>
> Carry on then :)
>
> --
> Alex
>

Re: syntax closures

[Stefan Israelsson Tampe]

I didn't know that this was a taken name already,

Let's call it guile-srfi-72, In the end it is a srfi-72 simulator that mix
well with the current guile macro system but is not a perfect replacement
(yet)

I'll check it out, But srfi-72 really covers a need I have when
writing macros with
syntax-parse.

I'll check the sc-macro-transformer out.

/Stefan

On Thu, Feb 14, 2013 at 10:42 AM, Mikael Djurfeldt <mikael@djurfeldt.com> wrote:
> Just saw this.
>
> Right, "syntactic closures" is the name of a macro system by Alan
> Bawden and Jonathan Rees:
>
> http://en.wikipedia.org/wiki/Syntactic_closures
>
> http://www.gnu.org/software/mit-scheme/documentation/mit-scheme-ref/Syntactic-Closures.html#Syntactic-Closures
>
> So, it would be good to choose a different name if what you are doing
> is different.
>
> BTW, the sc-macro-transformer facility of MIT-scheme would be nice to have. :-)
>
> Best regards,
> Mikael D.
>
> On Thu, Jan 24, 2013 at 9:45 AM, Alex Shinn <alexshinn@gmail.com> wrote:
>> On Thu, Jan 24, 2013 at 4:11 PM, Stefan Israelsson Tampe
>> <stefan.itampe@gmail.com> wrote:
>>>
>>>
>>> 2. I was actually hesistant to call this srfi-72 because of trying to
>>> do what it want
>>>    more than what it say's. A main trick to simulate the effect was to
>>> introduce
>>>    a closure in the syntax at one point and therefore a choose the name
>>>    syntax-closure not knowing that there is an already a notion of
>>> that in the wild
>>
>>
>> Oh - I thought you were referring to the existing syntactic-closures.
>> I guess it's a plausible enough name to reuse coincidentally...
>>
>> Carry on then :)
>>
>> --
>> Alex
>>

Re: syntax closures

[Mark H Weaver]

Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
> Let's call it guile-srfi-72, In the end it is a srfi-72 simulator [...]

I'm pretty sure this is also false.  One of the main points of SRFI-72
is the improved hygiene algorithm, which is quite different than psyntax
in its details.  Unless I'm mistaken, you have picked out only one small
aspect of SRFI-72 that happens to be relevant to what you're doing.

Therefore, I don't think it should be called SRFI-72 either.

      Mark

Re: syntax closures

[Stefan Israelsson Tampe]

How about

h-quasisyntax

for hygienic quasisyntax ?


On Fri, Feb 15, 2013 at 5:16 AM, Mark H Weaver <mhw@netris.org> wrote:
> Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>> Let's call it guile-srfi-72, In the end it is a srfi-72 simulator [...]
>
> I'm pretty sure this is also false.  One of the main points of SRFI-72
> is the improved hygiene algorithm, which is quite different than psyntax
> in its details.  Unless I'm mistaken, you have picked out only one small
> aspect of SRFI-72 that happens to be relevant to what you're doing.
>
> Therefore, I don't think it should be called SRFI-72 either.
>
>       Mark

Re: syntax closures

[Stefan Israelsson Tampe]

BTW.

Of cause if you read the doc's for srfi-72 you will see a whole
different machinery that brings many features, they explicitly states
6 facts in the abstract for which I adress one in the code.

On the other hand when they try to sell it it they just uses examples
for the case for witch I try to implement a solution for. So in this
light I would say that I practically cover 90% of srfi-72 intention.
But from a theoretical standpoint I would just say 10%.

/Stefan

On Fri, Feb 15, 2013 at 5:16 AM, Mark H Weaver <mhw@netris.org> wrote:
> Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
>> Let's call it guile-srfi-72, In the end it is a srfi-72 simulator [...]
>
> I'm pretty sure this is also false.  One of the main points of SRFI-72
> is the improved hygiene algorithm, which is quite different than psyntax
> in its details.  Unless I'm mistaken, you have picked out only one small
> aspect of SRFI-72 that happens to be relevant to what you're doing.
>
> Therefore, I don't think it should be called SRFI-72 either.
>
>       Mark