[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: David A. Wheeler
Subject: Re: Adding to guile curly-infix (SRFI 105), neoteric- & sweet-expressions
Date: Fri, 31 Aug 2012 23:16:24 -0400 (EDT)

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

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

reply via email to

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