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