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

*To*: dwheeler@xxxxxxxxxxxx*Subject*: Re: SRFI 105: Curly-infix-expressions*From*: Alan Manuel Gloria <almkglor@xxxxxxxxx>*Date*: Mon, 27 Aug 2012 08:54:07 +0800*Cc*: shiro@xxxxxxxx, srfi-105@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-105@xxxxxxxxxxxxxxxxx*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V7Hg3J6Pjcm1YST9YIDzxalrrlsRKFqvxTHHENHyJYE=; b=l911/igIZ47is5QFpB5zf6amXkay4w70m0Tn+9dI28Xg4dMJps9bDYukESJINBPD0s 061mMDp/3Fivdn5xoasL/pxIwuktjiEqMza6+PELUJikOKaVcqBobRAXIkXYk1Sqa6e6 Db3st5hC92/yvfs7SJXp3kGJiTkomSqwND+UFwb+X61KjSRPZiIq6F+QQA63CxPUA1A7 +ifsqxSK1FTBU0TQjolRtz4as7nuL69qqjk+dlQVIvlxoZk/ZLKszdklY3pzB40T1rt+ B7CASqyhm+491+25js52ycXyvoiDH7t6scSsbV9VdID52S1gE0t613vjYLNRm3tbs5yH juzQ==*In-reply-to*: <E1T5nSK-00084G-6i@xxxxxxxxxxxxxxxxx>*References*: <20120826.105059.1023874946313453129.shiro@xxxxxxxx> <E1T5nSK-00084G-6i@xxxxxxxxxxxxxxxxx>

On Mon, Aug 27, 2012 at 8:45 AM, David A. Wheeler <dwheeler@xxxxxxxxxxxx> wrote: > Shiro Kawai: >> (I'm aware of the readable S-expression project, and I see >> n-expressions allows this denseness visual queue. If so, >> I think it is actually better idea to submit one srfi for >> both in it, instead of having c-expr and n-expr individually. >> It's the *combination* that addresses the problem). > > Fair point. We actually debated whether or not to put them together, or write them separately. > > Neoteric-expressions are strictly more succinct than curly-expressions, because they also add a traditional-like function call notation f(...), and because they provide a simplification for a common case, f{...} ("calculate infix, then pass the result to f"). > > We decided to write them separately (in another SRFI not yet submitted) because curly-infix does NOT require a change to the Scheme specification. The Scheme spec doesn't include {...} at all, so curly-infix as written is strictly backwards-compatible. In contrast, at the top level, neoteric-expressions change the language, because f(x) is interpreted as (f x) instead of as two datums (f and (x)). Granted, anyone who is writing "f(x)" for two datums is nuts, and I've never seen Scheme code written in such a bizarre way. But I was trying to be conservative. Perhaps we've been too conservative, and we should just standardize neoteric-expressions (with curly-infix as a subset). We could just rename the SRFI, and bundle them together; that'd be easy to do. On the other hand, *I* (almkglor) have seen Scheme code that looks like this: (let ([x foo][y bar]) ...) (I'll have to hunt down that link again, but Ive seen that syntax used consistently as a coding style) The [x foo][y bar] bit gets interpreted differently in n-exprs vs. s-exprs or c-exprs. Sincerely, AmkG

**Follow-Ups**:**Re: SRFI 105: Curly-infix-expressions***From:*David A. Wheeler

**References**:**Re: SRFI 105: Curly-infix-expressions***From:*Shiro Kawai

**Re: SRFI 105: Curly-infix-expressions***From:*David A. Wheeler

- Prev by Date:
**Re: SRFI 105: Curly-infix-expressions** - Next by Date:
**Re: SRFI 105: Curly-infix-expressions** - Previous by thread:
**Re: SRFI 105: Curly-infix-expressions** - Next by thread:
**Re: SRFI 105: Curly-infix-expressions** - Index(es):