[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marijn
Subject: Re: Adding to guile curly-infix (SRFI 105), neoteric- & sweet-expressions
Date: Mon, 27 Aug 2012 13:20:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120723 Thunderbird/14.0

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:

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?


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

PS "{x + y) actually generates {+ x y)"
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]