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