#3631: Overload the Prelude iterate to support list input
---------------------------------+------------------------------------------
Reporter: shelbymoore3 | Owner:
Type: feature request | Status: closed
Priority: normal | Milestone:
Component: Prelude | Version: 6.10.4
Severity: normal | Resolution: wontfix
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Comment (by shelbymoore3):
Replying to [comment:8 [email protected]]:
> It is exactly to encourage participation and consensus (rather than
drive-by changes) that the Library submission guidelines exist. If you
are not yet at a stage where you can create a patch yourself, then the
best advice would be to post ideas on a mailing list like haskell-cafe@ or
libraries@,...
I didn't realize there was list specific to libraries. haskell-cafe@
would be much too noisy for such a small tweak change proposal as this.
> ...in order to create discussion, gather support, and maybe persuade
someone else to implement your idea as a patch.
That is reasonable, except that small tweaks can be easily buried in a
mailing list. I think a database format is preferable. I can't imagine
the efficiency having my TODO list of ideas for some of the major projects
I have worked on, being spread out in a mailing list. Also it is well
known that consensus is not the way to write the best software. Small
teams slaughter large monoliths.
Perhaps libraries@ is focused enough. I am not going to bother, I was
just passing along to remind you guys that you forgot to generalize
`iterate` for lists. Aren't lists a very important fundamental data
structure in Haskell that is covered by just about every other library
function?
But no big deal, I can write my own function. Why bother helping you by
passing along the missing `iterate` for lists.
> Posting ill-formed ideas to a bug-tracker (intended for a small number
of core developers) is much less productive than using a dedicated
discussion forum filled with many helpful users.
This idea is not ill-formed.
> > > * If you did change the Prelude `iterate` rather than adding a new
function, then you would probably break lots of code
> >
> > How so? I have overloaded `iterate` on input and output type. Thus
my proposed function shouldn't even be selected by the compiler for use
with existing usage of `iterate`.
>
> The Prelude 'iterate' is not currently overloaded, so making it
overloaded may force type-inference changes in many usage positions, some
of which may now become ambiguous and hence be rejected.
Perhaps that is because type inference doesn't scale and should be avoided
entirely, except for local usage:
http://lambda-the-ultimate.org/node/1277 (see slide #67)
Any one who relies on type inference globally can except such domino
cascades generally.
> Furthermore, your proposed overloading is not parametric in a way that
can easily be captured by type classes. What is the least generalisation
of the the two signatures for iterate?
>
> {{{
> iterate :: (a -> a) -> a -> [a]
> iterate :: ([a] -> [a]) -> [a] -> [a]
> }}}
>
> Hint: there isn't one.
If I am not mistake, a type class can specify the signature that it
expects.
> If it is a new function, unrelated to the existing one, then propose a
new name for it, and you will likely find people more receptive to the
suggestion.
The name of a function implies its general semantics (function/purpose),
and the type signature further narrows the semantics.
> "Won't fix" is not a moral judgement - it is just a bug-tracker tag. It
usually means the ticket is incomplete, or posted to the wrong place, or
that a reported bug is not a bug at all.
Incomplete would be a more accurate tag than "won't fix". You do not know
you won't end up fixing this when someone completes the library patch, or
if you do, then your suggestion to me above was to waste my time.
> The bug-tracker is usually not the best place to post new ideas for
feature requests, at least until they have been suggested and discussed in
a open forum like a mailing list or IRC channel. Acceptance and
refinement by the wider community is crucial.
Yeah and it only took 20 years for Haskell to get here.
It is not totally unreasonable, except it doesn't scale. You are going to
have adjust if Haskell is going to move out of the research and into
mainstream, then busy business people are going to come and make quick
inputs, and if you shut them out, then you are shooting yourself in the
foot. We do not have time to go figure out all the little nuances of
where you do you "consensus" communications on the side. Becoming a
tenured member of the community should not be a requirement, because it
does not scale.
You are really intelligient, but please do not forget the exponential
function and the concept of scale.
Best regards. I did not modify the ticket status.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3631#comment:9>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
