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

*To*: Shiro Kawai <shiro@xxxxxxxx>*Subject*: Re: SRFI 105: Curly-infix-expressions*From*: Alan Manuel Gloria <almkglor@xxxxxxxxx>*Date*: Tue, 28 Aug 2012 01:34:37 +0800*Cc*: dwheeler@xxxxxxxxxxxx, 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; bh=bKBaIAuCx5RxTKnodG//C1sZeiTyqtb2yusjwq87Mt8=; b=f+27hcYptUs8MJ8JILn1eAnXuJwU12Qkska33R7mFaaknE5bLCb+WzrnH+30b95rBE PbbaVCpY+jwCjiYBJniu41ooQQVXLG0OIyB6kcgtvKXac5QE/F6ivlYg8bpd3SdtFGPh Yu/s2KfOa7eUeBWNPNYXTp5kg1AvMhZMqY9cJShtOv3WLQVAhqsQkKOU3jpQg+GIitqb Z3CgCtxVQQMKk5zYQUVxsTImtDhI9X0pKvrQPvFtIb9MkUsbZttB0COPK6QZpqTg/fIs fgO3ZRbV3pm/yHHjTTiyP/r2llOji2HugMyEYR1vBb8XJ0LFZqGV8J+cnd6ncWSHQu/6 ge/g==*In-reply-to*: <20120827.065822.680075645630499491.shiro@xxxxxxxx>*References*: <CAF+kUQWBRMkf48gjQdp9GoEhiv9t209=f_t=iWtxCd5m_Zv5zw@xxxxxxxxxxxxxx> <20120826.213139.1108322852317673718.shiro@xxxxxxxx> <CAF+kUQWF+jgTu_VVdDoeUA4yeu4GDx=YPKREkqPm8AoYbmzZ+g@xxxxxxxxxxxxxx> <20120827.065822.680075645630499491.shiro@xxxxxxxx>

On Tue, Aug 28, 2012 at 12:58 AM, Shiro Kawai <shiro@xxxxxxxx> wrote: > From: Alan Manuel Gloria <almkglor@xxxxxxxxx> > Subject: Re: SRFI 105: Curly-infix-expressions > Date: Mon, 27 Aug 2012 15:58:36 +0800 > >> The way the current spec is done allows for code like the >> following: >> >> (define {a // b} >> {(unwrap-par-monad a) parallel (unwrap-par-monad b)}) > > Kind of cute, though I wonder if this can be extended > to handle variable arity operators. David A. Wheeler and me kinda considered the following transformation: { x a . y } => (a x . y) The proposal was that the "list length" operation would consider improper lists to be of size 1, so {x a . y} would be considered an odd length, at least 3, etc. basically triggering the "simple" rule. > >> (define-syntax o >> (syntax-rules () >> ({a o b} >> (lambda (x) (b (a x)))) >> ({a o b o rest o ...} >> {{a o b} o rest o ...}))) >> >> Again, this takes advantage of the fact that >> {a o b o rest o ...} means (o a b rest ...) > > This is also cute, though it effectively changes the > surface meaning of "x ...". > > These two examples are interesting. They don't appeal to me > enough to convince me non-macro approach is good, but others > may feel differently. How about including them in the rationale > section to explain why reader transformation is necessary? > > --shiro Yes, I probably should. Sincerely, AmkG

**References**:**Re: SRFI 105: Curly-infix-expressions***From:*Alan Manuel Gloria

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

**Re: SRFI 105: Curly-infix-expressions***From:*Alan Manuel Gloria

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

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