Am Mittwoch, 22. März 2006 14:19 schrieb Bulat Ziganshin:
> Hello Wolfgang,
>
> you said WHAT you think but not said WHY? my motivation is to be able
> to use myriads of already implemented algorithms on new datatypes
I think, I already tried to explain why I think the way I think in an earlier
m
On Thu, 23 Mar 2006, Claus Reinke wrote:
Ah, I see. You are suggesting to introduce phantom type parameters to fake
polymorphism for types which aren't really polymorphic. This might be
acceptable as a temporary workaround but I don't think it is a good
long-term solution. The ML implementatio
Ah, I see. You are suggesting to introduce phantom type parameters to fake
polymorphism for types which aren't really polymorphic. This might be
acceptable as a temporary workaround but I don't think it is a good
long-term solution. The ML implementation is not really comparable to this
as inst
Hello,
it seems that there is not yet a ticket about putting seq into a type class
(again).
In my opinion, having seq available for every type is a serious flaw. One
problem is that the law f = \x -> f x doesn't hold anymore since the equation
is false for f = _|_. There was also a discussio
On 23 March 2006 02:24, Ben Rudiak-Gould wrote:
> Bulat Ziganshin wrote:
>> Taral wrote:
>>> I don't see that more optimization follows from the availability
>>> of information regarding the strictness of a function result's
>>> subcomponents.
>>
>> ghc uses unboxed tuples just for such sort of o
On Thu, 23 Mar 2006, Claus Reinke wrote:
class Graph (g e v) where
src :: e -> g e v -> v
tgt :: e -> g e v -> v
we associate edge and node types with a graph type by
making them parameters, and extract them by matchi
