Hello --

On Mon, 12 Mar 2001, Conrad Schneiker wrote:

> Matz wrote:
> 
> # I'd like to put this particular one into RCR and get comments from
> # people in the community.  Mike, Please?
> # 
> # Choices are:
> # 
> #   * partition
> #   * bisect
> #   * whatever else
> #   * no, we don't need it.
> 
> FWIW, I vote for 'partition':
>     * Compatibility with Haskell usage (presumably).
>     * Nearly identical to C++ partition function.
>     * Fairly natural term for native English programmers.

I'd go along with this, based on the word of people who know more
about functional programming and Haskell than I do.  But the whole
notion of Haskell compatibility worries me a little.  (See below.)

> 'bisect' -- I disagree:
>     * Misleading, suggests cutting in half.
>     * Not most commonly used term, AFAIK.

I agree -- I mean, I disagree -- I mean, I agree with Conrad,
who disagrees with 'bisect' :-)


> Don't need -- I disagree:
>     * A matter of degree: C doesn't have min and max, but Ruby does.

I'm not sure about this.  I've never missed it.  It can be added to
Enumerable, already, in one line (though obviously core inclusion
would mean speed).  There are certainly many other
Enumerable/Array/Hash things that I would consider much more
important, though of course when it comes to useful/important
enhancements, there's no particular quota.

As for Haskell and functional programming:

I'm confused about the whole status of these things, with respect to
Ruby.  There's been talk from time to time about borrowing standard
functions from Haskell, or emulating a functional paradigm in Ruby.
It always starts out sounding intriguing and well-defined, but then
seems to end up as a kind of miscellany of possibly useful functions.

At that point, the relation to functional programming becomes unclear,
and I would suspect/speculate that someone really immersed in the
world of functional programming would not accept the idea that
transliterating a few functions to an OO language really establishes
any meaningful connection with functional programming.

I'm not saying that the functions we're talking about are trivial or
bad.  Nor am I saying that, if they're adopted into the core, we
should deliberately create non-standard names for them.  I'm just a
little uneasy about describing a very partial, very selective
borrowing from functional programming as really signifying a relation
between functional programming and Ruby.

In fact... I think this kind of thing (a functional programming
emulation layer, or something) is perfect for a nicely-crafted,
self-standing library, in Ruby.  And I think that may even be where
this particular thread started :-)


David

-- 
David Alan Black
home: dblack / candle.superlink.net
work: blackdav / shu.edu
Web:  http://pirate.shu.edu/~blackdav