Email list hosting service & mailing list manager

New release of SRFI 114 with implementation John Cowan (04 Dec 2013 04:16 UTC)
Re: New release of SRFI 114 with implementation Arthur A. Gleckler (04 Dec 2013 05:52 UTC)
Re: New release of SRFI 114 with implementation John Cowan (04 Dec 2013 20:28 UTC)
Re: New release of SRFI 114 with implementation Michael Sperber (04 Dec 2013 08:38 UTC)
Re: New release of SRFI 114 with implementation John Cowan (04 Dec 2013 13:52 UTC)
Re: New release of SRFI 114 with implementation Shiro Kawai (04 Dec 2013 13:54 UTC)
Re: New release of SRFI 114 with implementation John Cowan (04 Dec 2013 20:49 UTC)
Re: New release of SRFI 114 with implementation Shiro Kawai (04 Dec 2013 23:46 UTC)
Re: New release of SRFI 114 with implementation John Cowan (05 Dec 2013 18:35 UTC)
Re: New release of SRFI 114 with implementation Shiro Kawai (05 Dec 2013 22:08 UTC)
Re: New release of SRFI 114 with implementation Kevin Wortman (08 Dec 2013 02:32 UTC)
Re: New release of SRFI 114 with implementation John Cowan (08 Dec 2013 03:13 UTC)
Re: New release of SRFI 114 with implementation Kevin Wortman (08 Dec 2013 03:45 UTC)
Re: New release of SRFI 114 with implementation John Cowan (08 Dec 2013 17:01 UTC)
Re: New release of SRFI 114 with implementation Kevin Wortman (09 Dec 2013 00:10 UTC)
Re: New release of SRFI 114 with implementation John Cowan (09 Dec 2013 00:30 UTC)

Re: New release of SRFI 114 with implementation John Cowan 05 Dec 2013 18:35 UTC

Shiro Kawai scripsit:

> Right.  And the current description doesn't prohibit
> default-comparator to compare comparators.  So if you get some
> arbitrary Scheme objects and want to apply =? etc., you have to
> pass the comparator argument explicitly anyway.  You can omit the
> comparator only when you're absolutely sure the first argument isn't a
> comparator.  Thus I feel that omitting the explicit comparator isn't
> that useful, and it isn't worth regarding to the risk of forgetting
> the possibility of obj1 happening to be a comparator (it would make a
> hard-to-reveal bug).

Okay, I'm convinced, especially by the last point.  I've changed my copy
of the SRFI and the implementation, but I'll wait on pushing this to the
site.

> I agree with those disadvantages, and I'm not saying the standard
> should use closures.  My point is to allow implementations to use
> closures if it wants to.

This argument seems to be perfectly general.  As we know, closures can
emulate any data structure, so what is the argument for making, say,
pairs and procedures disjoint?  Well, it's more convenient to be able
to do type dispatching without worrying about whether pairs might be
procedures.  I think the same argument applies here.

> Or to allow a 'map' with suitable entries i.e. in Clojure notation,
> something like {:type? type-pred, :equal? equal-proc, :hash hash-proc}

Now the situation becomes more complicated yet: comparators might be
hash tables or procedures or even both (since hash tables might be
procedures).  I fear this will upset Scheme's existing balance between
rigid (though dynamic) typing and duck typing.

--
Evolutionary psychology is the theory           John Cowan
that men are nothing but horn-dogs,             http://www.ccil.org/~cowan
and that women only want them for their money.  xxxxxx@ccil.org
        --Susan McCarthy (adapted)