+1
Jacques
On 09/05/2011 6:49 PM, Daniel Fischer wrote:
I would like to propose the elimination of the special error case
gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"
to replace it with
gcd 0 0 = 0
(which would be an automatic consequence of removing the above line).
Rationale:
1. I
In all honesty what I want is a solution to the problems clearly
outlined in the first two sections of his proposal.
People may not be clamouring for this (yet), but that maybe simply
because they've gotten used to the de facto Haskell style of giant type
classes and never seriously asking the
I tried to see the discussion that led to class aliases being rejected
as a proposal, but could not find links on the Wiki. In fact, in Trac
(#101) that proposal is still a 'maybe', but with no updates. Is there
a competing proposal that got accepted?
[Without a mechanism like class aliases,
There is a general solution, but it essentially involves polymorphism
a-la-Omega (or as in Coq's Calculus of Inductive Constructions).
The most general description of (Tree Int) is as the Stream
S = [Int, Tree, Id, Id, ...]
You are now attempting to pull-off exactly 2 "terms" from that Stream.
Arie Peterson wrote:
J. Garrett Morris wrote (to Bulat Ziganshin):
Yes - you've reiterated Wadler's original design, with an automatic
creation of a type class. Erwig and Peyton-Jones, _Pattern Guards and
Transformational Patterns_
(http://research.microsoft.com/~simonpj/Papers/pat.htm) ment
Malcolm Wallace wrote:
If you restrict yourself to programs entirely written by humans, I
agree completely. But if you consider programs written by programs
(say Template Haskell to be specific, but it could be via many other
means), such degenerate types occur rather often.
I find the "pr
Stephanie Weirich wrote:
I don't think we want to allow types like:
forall . Int or forall a b. Int
These types are mostly bugs. Furthermore, rejecting them doesn't limit
expressiveness: they should both be "equivalent" to Int, so user could
just write Int. I can't really think ho
Claus Reinke wrote:
My own awkward-looking translations were driven by having
found two tool's in Haskell that come close to this ideal, even
if the syntax is awkward: the mapping of pattern-match failure
to "fail" in do-notation, and the use of "fail msg=mzero" in
MonadPlus. By these means, matc
John Meacham wrote:
On Tue, Feb 28, 2006 at 12:44:04AM -0500, Cale Gibbard wrote:
I'm almost scared to ask: does this mean we need negative zero as well?
good point. probably.
If the point is to allow floating-point conversion to go through Ratio
correctly, you might have to do
Lennart Augustsson wrote:
Jacques Carette wrote:
Personally I think that this ought to be resolved by static means --
and yes, by the linker, as it can't be done properly earlier.
But there are cases that cannot be resolved statically.
On the other hand, they are probably rare enou
Cale Gibbard wrote:
Hmm... however, could we not assign to each instance a unique
identifier which could be compared? Say a cryptographic hash of the
source code for the instance? (Which of course would never be exposed
to the user.) That should be enough to tell them apart.
By the way, this is t
11 matches
Mail list logo
