#3631: Overload the Prelude iterate to support list input
---------------------------------+------------------------------------------
Reporter: shelbymoore3 | Owner:
Type: feature request | Status: reopened
Priority: normal | Milestone:
Component: Prelude | Version: 6.10.4
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Changes (by shelbymoore3):
* status: closed => reopened
* resolution: wontfix =>
Comment:
Replying to [comment:6 igloo]:
> 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.
> However, a few things come to mind with your proposed change:
> * 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`.
> * Your definition retains the whole list, so could cause space leaks
That is the whole point. "space leak" means lazy evaluation cache, which
is precisely what one wants sometimes, and when they don't want it, one
should use another construct:
http://www.coolpage.com/commentary/economic/shelby/Functional_Programming_Essence.html#Allocation_Size_Determinism
> * `last` takes time linear in the length of its input, so performance
where you want the last element (as current uses of `iterate` do) will not
be good
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.
Let's be careful to not jump too quickly to "won't fix" or "we don't
accept ideas here". Sorry I am not yet knowledgeable about applying a
patch to the source code of the libraries. I do not think that should be
an impediment to submitting an idea. 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?
Thanks for making those points, so I could clarify.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3631#comment:7>
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
