Hello,
while I agree that operators are usually more useful als type
constructors than as type variables, I’m wondering if it is future-proof
to completely get rid of a possibility for infix type variables. With
the type class system getting stronger and stronger, would this not mean
that there
Sorry to pick on your post in particular Matthew, but I have been seeing a lot
of this on the Haskell lists lately.
I find it completely unreasonable for a reply to a very long post to quote the
entire text, only to add a single line at the bottom (or worse, embedded in the
middle somewhere).
Hi,
One could also argue that a good email client should automatically hide
long quotes. In fact, I guess many people are not even aware of the problem
because their client does this.
Cheers,
Pedro
On Thu, Jan 19, 2012 at 11:14, Malcolm Wallace malcolm.wall...@me.comwrote:
Sorry to pick on
Hi,
On 01/19/2012 10:22 AM, Jos Pedro Magalhes wrote:
One could also argue that a good email client should automatically hide
long quotes. In fact, I guess many people are not even aware of the
problem because their client does this.
But then what is the point of including the text in the
On 19/01/2012, Malcolm Wallace malcolm.wall...@me.com wrote:
I find it completely unreasonable for a reply to a very long post to quote
the entire text, only to add a single line at the bottom (or worse, embedded
in the middle somewhere). In this case, there are 7 pages of quotation
before
On 19/01/2012, Joachim Breitner m...@joachim-breitner.de wrote:
(I have no good idea, but here is at least one: A dot '.' as the first
character indicates a type variable; compared to a ':' this is a
non-capitalized character).
So that all symbols that start in dot are variables, and all
Hi,
Am Donnerstag, den 19.01.2012, 07:11 -0500 schrieb Matthew Farkas-Dyck:
On 19/01/2012, Joachim Breitner m...@joachim-breitner.de wrote:
(I have no good idea, but here is at least one: A dot '.' as the first
character indicates a type variable; compared to a ':' this is a
On Thu, Jan 19, 2012 at 07:11:19AM -0500, Matthew Farkas-Dyck wrote:
Sometimes I thought to use ∀ to quantify over type variables, as
over term variables, at least as an option.
Do you mean that in
f :: (x, X, (+), (:+))
only x would be a type variable and X, (+), (:+) would be type
On January 19, 2012 05:14:30 Malcolm Wallace wrote:
I find it completely unreasonable for a reply to a very long post to quote
the entire text, only to add a single line at the bottom (or worse,
embedded in the middle somewhere).
+1
___
To my
Dear GHC team,
I am testing the IO operations of GHC with the Unix named pipes
[..]
Albert Y. C. Lai writes on 19 Jan 2012
Main.hs does not open fromA at all. (fromA_IO is dead code.) This causes
fifo2.c to be hung whenever it opens fromA. From the man page of mkfifo(3)
on Linux:
On 19/01/2012, Ian Lynagh ig...@earth.li wrote:
Do you mean that in
f :: (x, X, (+), (:+))
only x would be a type variable and X, (+), (:+) would be type
constructors, but that in
g :: forall y, Y, (*), (:*) .
(x, X, (+), (:+), y, Y, (*), (:*))
y, Y, (*), (:*) would be
Hello,
I met strange behavior of let in ghci 7.0.4. The following works well.
:m Data.List
let compFst (n1,s1) (n2,s2) = compare n1 n2
maximumBy compFst [(1, boo), (3, foo), (2, woo)]
(3,foo)
But if I bind maximumBy compFst to chooseMax with let, it causes
error:
let chooseMax = maximumBy
On Thu, Jan 19, 2012 at 10:55 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hello,
I met strange behavior of let in ghci 7.0.4. The following works well.
You're running into the monomorphism restriction:
http://www.haskell.org/haskellwiki/Monomorphism_restriction
let chooseMax = maximumBy
Antoine,
You're running into the monomorphism restriction:
http://www.haskell.org/haskellwiki/Monomorphism_restriction
Oh. Thanks.
You can also turn off the restriction at the command-line with the
argument '-XNoMonomorphismRestriction', I think.
I will use ghci
14 matches
Mail list logo
