Adding to guile curly-infix (SRFI 105), neoteric- & sweet-expressions

Adding to guile curly-infix (SRFI 105), neoteric- & sweet-expressions

[David A. Wheeler]

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]

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

[David A. Wheeler]

nalaginrut <nalaginrut@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

[Alan Manuel Gloria]

On Mon, Aug 27, 2012 at 12:16 PM, David A. Wheeler
<dwheeler@dwheeler.com> wrote:
> nalaginrut <nalaginrut@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

Re: Adding to guile curly-infix (SRFI 105), neoteric- & sweet-expressions

[Marijn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi David,

On 26-08-12 19:02, 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

I watched your presentation and you have a pleasant voice.

I don't have anything to remark about (your) syntax for infix notation.

About the proposed function call syntax (really dislike the `neoteric'
(new poetic?) name), I do want to make some remarks. It seems that
your transformation rules depend on a non-parenthesized context (or
some other unspecified constraint), otherwise your rule e{...} |-> (e
{...}) can be applied to itself and leads to e{...} |-> ((((e
{...})))) among other things, such as:

cons{1}{2} |-> (cons{1}){2} |-> (cons 1){2} |-> ((cons 1){2}) |->
((cons 1) 2)

but also

cons{1}{2} |-> cons{1} 2 |-> cons 1 2 |-> (cons 1 2).

Using `f(1 2) |-> (f 1 2)' you can push open parens left meaning (a (b
c)) is equal to ((a b c)).

Can you shed some light on these issues?

Marijn

> 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/

PS "{x + y) actually generates {+ x y)"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlA7V/4ACgkQp/VmCx0OL2wVzQCgwCUu6DMR1owjKRoqxe4RZxl9
M3sAmgKB0Ww/99MBJ1RIVultm6R+SbcI
=lUEC
-----END PGP SIGNATURE-----

Re: Adding to guile curly-infix (SRFI 105), neoteric- & sweet-expressions

[Noah Lavine]

Hello,

On Mon, Aug 27, 2012 at 12:30 AM, Alan Manuel Gloria <almkglor@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

Re: Adding to guile curly-infix (SRFI 105), neoteric- & sweet-expressions

[Alan Manuel Gloria]

On Tue, Aug 28, 2012 at 10:57 AM, Noah Lavine <noah.b.lavine@gmail.com> wrote:
> Hello,
>
> On Mon, Aug 27, 2012 at 12:30 AM, Alan Manuel Gloria <almkglor@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

[Ludovic Courtès]

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

[David A. Wheeler]

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

[Alan Manuel Gloria]

On Wed, Aug 29, 2012 at 9:49 AM, David A. Wheeler <dwheeler@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

[David A. Wheeler]

Marijn:
> About the proposed function call syntax (really dislike the `neoteric'
> (new poetic?) name),

Why? And do you have some suggested alternatives?  We used to call them "modern", but abbreviating that to "m-expressions" was confusing.  Something beginning with "n" preferred.

> I do want to make some remarks. It seems that
> your transformation rules depend on a non-parenthesized context (or
> some other unspecified constraint), otherwise your rule e{...} |-> (e
> {...}) can be applied to itself and leads to e{...} |-> ((((e
> {...})))) among other things, such as:

No, if I understand you correctly, because the e{...} transformation rule *ONLY* applies when there is no space between "e" and the opening brace.  The result puts a space BETWEEN the e and the opening brace, so that is the end.  E.G.:

f{n - 1} maps to (f {n - 1}) maps to (f (- n 1))

> cons{1}{2} |-> (cons{1}){2} |-> (cons 1){2} |-> ((cons 1){2}) |->
> ((cons 1) 2)

Yes, that's correct.

> but also
> 
> cons{1}{2} |-> cons{1} 2 |-> cons 1 2 |-> (cons 1 2).

No.  The spec is that they go left-to-right, so the leftmost {1} gets applied first, and thus the previous result is as shown.

> Can you shed some light on these issues?

Well, I *hope* that helps.  I'd be happy to try to explain things, and certainly want to know of problems.  If you want to get into details, I suggest joining the SRFI-105 mailing list or the "readable-discuss" mailing lists, since the guile-devel list isn't really the right list for that.

--- David A. Wheeler