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