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 John Cowan 15 Mar 2014 16:15 UTC
Alan Manuel Gloria scripsit: > The above function will work properly on an empty list (we assume > empty list is sorted) if (<? c) returns #t. But if (<? c) were to > return a function, it would instead return a function (well, a > function *is* a true value, so it will still work 99.99% of the > time....) An implementation could add the behavior that (<? comp) and (<? comp obj) always return #t, but given that < does not do this, I'm reluctant to make it part of this SRFI, as I suspect it will only be used rarely. It would be easy to roll your own predicate `monotonically-increasing?` if you want it to handle lists; it would probably be more efficient than using `apply` anyhow. -- At the end of the Metatarsal Age, the dinosaurs John Cowan abruptly vanished. The theory that a single xxxxxx@ccil.org catastrophic event may have been responsible http://www.ccil.org/~cowan has been strengthened by the recent discovery of a worldwide layer of whipped cream marking the Creosote-Tutelary boundary. --Science Made Stupid