#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 |
---------------------------------+------------------------------------------
Changes (by [email protected]):
* status: reopened => closed
* resolution: => wontfix
Comment:
Replying to [comment:7 shelbymoore3]:
> > Thanks for the suggestion, but if you would like to propose changes to
the libraries, please see:
> > http://www.haskell.org/haskellwiki/Library_submissions
>
> Thanks for the pointer very much. That sure seems like overkill in
terms of someone who just wants to spend a few minutes to contribute an
idea. Are you sure you want to squelch the ideas-only submissions? I
think successful mainstream paradigms encourage participation.
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@,
in order to create discussion, gather support, and maybe persuade someone
else to implement your idea as a patch. 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.
> > * 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. 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.
> But of course this change has nothing to do with current uses of
`iterate`. It is a new function which iterates on entire lists in "free
point" style of functional composition. That is the whole point.
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.
> Let's be careful to not jump too quickly to "won't fix" or "we don't
accept ideas here".
"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.
> Why can't you have an area of this hackage of open suggestions for
library enhancements, so that others can implement and apply the head
patches at their leisure?
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3631#comment:8>
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
