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