Re: Narrowing vs. rewriting
Phil,
Thanks for offering the Haskell version of these examples.
> I don't find either Sergio's and Harold's examples very convincing,
> as both are easy to program in Haskell.
I think that you dismissing this a bit too quickly. I'll let
Harold argue about his example. Concerning permute, the Haskell
version loses some points.
1. Permute does not return a permution. Its return value must be
processed in its entirety to use a permutation. For example,
think about using permutations for the N-queen problem. I
would argue that there is less abstraction and more hassle for
using the Haskell program.
2. Permute uses four more functions, i.e., take, drop, length,
and .., two additional types, i.e., integers and list of
permutations, and the idea and notation of list comprehesion.
I would argue that there is less expressiveness and
declarativeness.
3. We should look at an English description of the program.
This is indicative of how natural is the code with respect
to the way the programmer thinks about a solution.
My guess is that for the Haskell version the English
description would not be very good.
4. The efficiency depends on the implementation, but it is easy
to argue that there is a loss of efficiency in creating the
list of permutations and later garbage-collecting it.
5. The fact that the order in which permutations are generated
is explict is not an advantage, but lack of abstraction and
declarativeness. If the order were important, the program
should not have been non-deterministic.
5. The fact that the example is easy to code in Haskell does not
make it less convincing, perhaps the opposite because of its
immediateness and ease of understanding. I would argue that
the example is easy to code in other languages, too, but this
is not a good reason to dismiss Haskell or functional programming.
Following the original question, the point here is whether
narrowing is a price too high to pay for the above advantages, if
any advantage is perceived. Perception is subjective, but I would
say "NO". Narrowing does not cost very much and it pays off in
this example.
Regards,
Sergio
Received on Do Jul 03 1997 - 20:49:00 CEST
This archive was generated by hypermail 2.3.0
: Do Jun 20 2024 - 07:15:05 CEST