From: David Alan Black <dblack@...>
Date: 2001-03-13T06:21:50+09:00
Subject: [ruby-talk:12530] Re: Haskell goodies, RCR and challenge

Hello --

On Tues, 13 Mar 2001, Conrad Schneiker wrote:

> David Alan Black wrote: 
> 
> # > 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. 
> 
> One of the things that make Perl, Python, and Ruby very  useful for
> many common tasks is that they include lots of 'extra' functions with
> respect to C, ksh, and so on, so that you don't have to waste time
> reinventing semi-trivial wheels. 

[...]

> This of course means that many people will often not find
> several-to-many of these functions all that useful.  But on the
> average, it makes the language overall more useful to more
> people--that is, at least as long as you don't go completely 
> hog wild--or should that be, as long as you don't go completely
> mad cow. }8<D

I agree completely.  I don't have any principled objection to
#partition -- it's only in the context of the kind of
opinion-gathering Matz is doing on this that I would volunteer this
kind of statement (or guess) about whether I think it's worth putting
it in the core.  It's not the kind of thing (by contrast) where, if it
were already there, I would be lobbying to have it removed.

> # 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 [...].
> 
> Then by all means, please propose them.

I've never hesitated to do so :-)  I would put Array/Hash translation
methods (Array#to_h(value), Array#hash_with(anArray), etc.) a lot
higher on the list than partition, for example.  But in the end, I
don't think "we need XX more" is a good argument against having YY, if
we also need YY.  As I said before, "[...]"  -- though I think my
exact words were closer to: "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.
> 
> IMO, that is OK (and is to be expected whenever you are selecting some
> subset of functions most likely to be useful in the borrowing
> language).  Perl and Python (seem to have) copied useful functions
> found in Lisp (with some renaming and modification)  that allow you to
> do *some* things in a *somewhat* Lisp-like way, without emulating the
> Lisp paradigm. IMO, Perl and Python are better for it. 

Absolutely.  In the present case, it's not that I don't think we
should have such things happening in Ruby -- and of course we already
do.  It's just that something struck me about the way the discussion
went from Robert's original notion of a kind of emulation layer, or at
least relatively integral package of related, similarly
Haskell-derived functions, to the level of discussing the merits of
one or two methods outside the context of the package, but somehow as
if we were still discussing the package.  I don't mean to put this or
that statement under too much of a microscope -- it was more of a
cumulative impression that sparked my remarks.


David

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