Have one-argument '<? et al function as 'make<? et al
Alan Manuel Gloria
(26 Feb 2014 04:16 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al
Kevin Wortman
(28 Feb 2014 06:39 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al
Alan Manuel Gloria
(28 Feb 2014 22:00 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al
Kevin Wortman
(09 Mar 2014 05:03 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al
John Cowan
(09 Mar 2014 19:49 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al
John Cowan
(05 Mar 2014 01:36 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al Alan Manuel Gloria (15 Mar 2014 10:02 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al
Alan Manuel Gloria
(15 Mar 2014 10:08 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al
John Cowan
(15 Mar 2014 16:15 UTC)
|
Re: Have one-argument '<? et al function as 'make<? et al Alan Manuel Gloria 15 Mar 2014 10:02 UTC
On Wed, Mar 5, 2014 at 9:12 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote: > Alan Manuel Gloria scripsit: > >> This is a rather SRFI-105-centric proposal, but I'd like to propose >> that, if '<? and friends are given a single comparator argument, it >> return a function predicate: > > I don't understand why this proposal in any way benefits SRFI 105-based > code. Can you explain further? Mostly just a way of writing it shorter. With make<?: {x (make<? c) y (make<? c) z} ; ((make<? c) x y z) With <? operating as make<? does now: {x (<? c) y (<? c) z} ; ((<? c) x y z) That's it, that's the only advantage for SRFI-105. It's not clear to me if (<? c) would mean anything useful anyway, so why not, but... > >> Admittedly, it's possible to just use 'make<? and friends if we're >> going to use SRFI-105 anyway, but it seems clearer to use <? if >> SRFI-105 is something to support. > > I don't see why. The idea of <? and friends is that they are generalizations > of < and friends (also string<? and friends, etc.); that is, they are > predicates. Rather than having the function be either a predicate or > a predicate-maker, my idea is to separate the two purposes, so that > in one case we always get a boolean result, in the other case a procedure. ...Well, I suppose I can agree with you here, there is such a thing as clarity. This is scheme, after all, not Perl, so something that is convenient a few times for some people is not something to be recklessly added to the language. Sincerely, Amkg