Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
On Wed, Aug 29, 2012 at 9:49 AM, David A. Wheeler dwhee...@dwheeler.com wrote:
Please let us know what youd need to have it implemented within Guile,
or, even better, send a patch. ;-)
Okay! Since we already have it implemented on *top* of guile, I have hopes
that it'll be relatively easy to implement *in* guile.
I think Nala Ginrut once posted a patch that would allow read to
optionally recognize braces as delimiters. I guess thats a starting
point?
Yes, { and } as delimiters makes the rest much easier.
Heya Ludo',
Regarding sweet-expressions, #-handling in Guile becomes
an issue.
Specifically, in our existing code on top of Guile, we had to
reimplement # handling to properly handle #| |#, #! !# and
#; comments.
Since indentation is significant in sweet-expressions, it
is necessary to ensure that a reader that finds a hash-based
comment does not consume any whitespace after the
comment, and should instead somehow signal the
discovery of the comment.
In our current code, the hash-handler returns an empty
list if it found a #||# #!!# #; comment, or returns a
singleton list with the item it found.
If Guile's hash-handling in its reader has a similar protocol,
then it can be adapted for use with the sweet-expression
reader.
Otherwise, if the hash-handling effectively tail-calls back
to the top-level read after finding a comment, then the
routine needs to be changed so that the sweet-expression
reader can use it (as otherwise there will be two
implementations of hash-handling).
Other than that, for now I don't know of what else is
needed on top of { }-as-delimiter and an alternative
entry point for handling hash objects on the reader.
Sincerely,
AmkG
Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
On Tue, Aug 28, 2012 at 10:57 AM, Noah Lavine noah.b.lav...@gmail.com wrote: Hello, On Mon, Aug 27, 2012 at 12:30 AM, Alan Manuel Gloria almkg...@gmail.com wrote: However, it leads to an edge case in Guile 2.0 where disabling autocompilation leads to the module-loading C code path going through a direct C call to the C implementation of primitive-load, a path that only triggers if autocompilation disabled (when autocompilation is enabled, it goes through a hook in the language support for Scheme, which uses the 'read function we've rebound). Hmm, interesting. That sounds like a bug, but I'd like one of the Guile maintainers to clarify that this isn't intended before I look at it more. Is this triggered when you're trying to load a module full of infix expressions? Yes, with autocompilation off. If so, how do you tell Guile that the module is supposed to use infix expressions instead of s-expressions? By re-binding (via set!) 'read and 'primitive-load. On Guile 1.6 and 1.8, IIRC the C code uses the binding for 'primitive-load to handle loading module loading. On Guile 2.0, the compilation hook for the Scheme language uses the 'read Scheme binding (IIRC). Replacing the 'read and 'primitive-load bindings works for 1.6 and 1.8, and 2.0 with autocompilation enabled. With autocompilation off, Guile ends up calling the primitive-load C implementation directly as a C call, instead of the old behavior of calling 'primitive-load in the Scheme side. Our strategy, basically, was to completely replace the reader, as that had seemed to work in 1.6 and 1.8 at the REPL. I modified it later to replace 'primitive-load too, so that 'primitive-load uses the Scheme binding for 'read, which made it work in 1.6 and 1.8 during module loading. Sincerely, AmkG
Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
Hi David, Thanks for the note. I must confess I’m slightly skeptical about the chances of success of this approach. However, I’m happy you’re trying, and the fact that you take a principled approach, with the various syntactic extensions defined separately seems great to me. Please let us know what you’d need to have it implemented within Guile, or, even better, send a patch. ;-) I think Nala Ginrut once posted a patch that would allow ‘read’ to optionally recognize braces as delimiters. I guess that’s a starting point? Thanks, Ludo’.
Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
Ludovic Courtès
Thanks for the note. I must confess Im slightly skeptical about the
chances of success of this approach.
Nothing ventured, nothing gained.
However, Im happy youre trying,
and the fact that you take a principled approach, with the various
syntactic extensions defined separately seems great to me.
Thanks!
Please let us know what youd need to have it implemented within Guile,
or, even better, send a patch. ;-)
Okay! Since we already have it implemented on *top* of guile, I have hopes
that it'll be relatively easy to implement *in* guile.
I think Nala Ginrut once posted a patch that would allow read to
optionally recognize braces as delimiters. I guess thats a starting
point?
Yes, { and } as delimiters makes the rest much easier.
--- David A. Wheeler
Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
Hello, On Mon, Aug 27, 2012 at 12:30 AM, Alan Manuel Gloria almkg...@gmail.com wrote: However, it leads to an edge case in Guile 2.0 where disabling autocompilation leads to the module-loading C code path going through a direct C call to the C implementation of primitive-load, a path that only triggers if autocompilation disabled (when autocompilation is enabled, it goes through a hook in the language support for Scheme, which uses the 'read function we've rebound). Hmm, interesting. That sounds like a bug, but I'd like one of the Guile maintainers to clarify that this isn't intended before I look at it more. Is this triggered when you're trying to load a module full of infix expressions? If so, how do you tell Guile that the module is supposed to use infix expressions instead of s-expressions? I had also considered adding support for sweet-expressions in a language module for Guile, but this would require 2.0 (my own personal needs mean that I need it to work way back in 1.6) , and I couldn't figure out a way to tell Guile to start the REPL in sweet-expression language (or any language other than Scheme for that matter). Guile versions before 2.0 don't have support for multiple languages. The big change in the 2.0 release was the move from a direct interpreter to a virtual machine, which made multi-language support practical (and also made Guile much faster). Sincerely, AmkG Hoping this is helpful, Noah
Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
All: I'd really like feedback on proposed new SRFIs, and I'd like to help get these SRFIs implemented in guile. Background: The readable group has developed and refined 3 new reader abbreviations for Scheme: curly-infix-, neoteric-, and sweet-expressions. Each builds on the previous one; details are here: http://readable.sourceforge.net We plan to submit all three abbreviations as three separate SRFIs. The first one, curly-infix-expressions, is new draft SRFI 105, and we'd ESPECIALLY like comments on that: http://srfi.schemers.org/srfi-105/ The whole point of a SRFI is to get it *implemented*, so if you have a comment (such as a *problem* with them or getting any of them implemented in guile), please let us know!! The best way to comment is the mailing lists (for the SRFIs or via readable.sourceforge.net), so that everyone can discuss and address them. Also, I'd be happy to help get these implemented as part of guile. We have a current implementation that builds on *top* of guile (by completely re-implementing the reader), but it'd far better to have these built-in. Thanks for your time! --- David A. Wheeler
Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
hi Wheeler! I ever port the sweet-expression as a language module for Guile, and I have such an honor to say it's based on your work. There're still some bugs I need to face. But it works fine already. https://gitorious.org/nacre/guile-sweet Anyway, I'd like to see it becomes SRFIs. I've proposed it to be one of official language module since there's multi-language feature in Guile-2.x. And it's more convenient to do that if we make sweet-expression the SRFIs. On Sun, 2012-08-26 at 13:02 -0400, David A. Wheeler wrote: All: I'd really like feedback on proposed new SRFIs, and I'd like to help get these SRFIs implemented in guile. Background: The readable group has developed and refined 3 new reader abbreviations for Scheme: curly-infix-, neoteric-, and sweet-expressions. Each builds on the previous one; details are here: http://readable.sourceforge.net We plan to submit all three abbreviations as three separate SRFIs. The first one, curly-infix-expressions, is new draft SRFI 105, and we'd ESPECIALLY like comments on that: http://srfi.schemers.org/srfi-105/ The whole point of a SRFI is to get it *implemented*, so if you have a comment (such as a *problem* with them or getting any of them implemented in guile), please let us know!! The best way to comment is the mailing lists (for the SRFIs or via readable.sourceforge.net), so that everyone can discuss and address them. Also, I'd be happy to help get these implemented as part of guile. We have a current implementation that builds on *top* of guile (by completely re-implementing the reader), but it'd far better to have these built-in. Thanks for your time! --- David A. Wheeler
Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
nalaginrut nalagin...@gmail.com:
I ever port the sweet-expression as a language module for Guile, and I
have such an honor to say it's based on your work.
There're still some bugs I need to face. But it works fine already.
https://gitorious.org/nacre/guile-sweet
Awesome! Thanks!
We've made some tweaks recently, though nothing that would invalidate existing
code using it. But now, for example, you can use f{- x} to mean (f (- x)).
Anyway, I'd like to see it becomes SRFIs. I've proposed it to be one of
official language module since there's multi-language feature in
Guile-2.x.
And it's more convenient to do that if we make sweet-expression the SRFIs.
Agreed. We'll see how it goes.
--- David A. Wheeler
Re: Adding to guile curly-infix (SRFI 105), neoteric- sweet-expressions
On Mon, Aug 27, 2012 at 12:16 PM, David A. Wheeler
dwhee...@dwheeler.com wrote:
nalaginrut nalagin...@gmail.com:
I ever port the sweet-expression as a language module for Guile, and I
have such an honor to say it's based on your work.
There're still some bugs I need to face. But it works fine already.
https://gitorious.org/nacre/guile-sweet
Awesome! Thanks!
We've made some tweaks recently, though nothing that would invalidate
existing code using it. But now, for example, you can use f{- x} to mean (f
(- x)).
Anyway, I'd like to see it becomes SRFIs. I've proposed it to be one of
official language module since there's multi-language feature in
Guile-2.x.
And it's more convenient to do that if we make sweet-expression the SRFIs.
Agreed. We'll see how it goes.
Heya Nala Ginrut!
We noticed recently your effort in updating sweet-expressions to the
latest Guile.
We've also added support for some amount of attaching source locations
to read-in objects, and also indepedently updated it to work on recent
Guile 2.0.
I did much of the updating (at that time we had been unaware of your
work). We did this by replacing the binding for 'read and
primitive-load on Guile, as it seemed to give the best coverage across
1.6, 1.8, and 2.0.
However, it leads to an edge case in Guile 2.0 where disabling
autocompilation leads to the module-loading C code path going through
a direct C call to the C implementation of primitive-load, a path that
only triggers if autocompilation disabled (when autocompilation is
enabled, it goes through a hook in the language support for Scheme,
which uses the 'read function we've rebound).
I had also considered adding support for sweet-expressions in a
language module for Guile, but this would require 2.0 (my own personal
needs mean that I need it to work way back in 1.6) , and I couldn't
figure out a way to tell Guile to start the REPL in sweet-expression
language (or any language other than Scheme for that matter).
Sincerely,
AmkG
