#5781: Add Data.List.at :: [a] - Int - Maybe a
-+--
Reporter: nh2 | Owner:
Type: feature request | Status: new
Priority: normal|
#5783: Data.Text.isPrefixOf fails to terminate
---+
Reporter: reinerp | Owner:
Type: bug | Status: new
Priority: highest
#5784: Forked thread running infinite loop blocks other threads from running
--+-
Reporter: joeyadams| Owner:
Type: bug | Status: closed
#5797: readRawBufferPtr cannot be interrupted by exception on Windows with
-threaded
---+
Reporter: joeyadams | Owner:
Type: bug | Status: new
#5775: Inconsistency in demand analysis
-+--
Reporter: rl| Owner:
Type: bug | Status: new
Priority: normal|
#5781: Add Data.List.at :: [a] - Int - Maybe a
-+--
Reporter: nh2 | Owner:
Type: feature request | Status: new
Priority: normal|
#5800: hp2ps produces unescaped backslashes for nested functions
-+--
Reporter: jkff | Owner:
Type: bug | Status: new
#5797: readRawBufferPtr cannot be interrupted by exception on Windows with
-threaded
---+
Reporter: joeyadams | Owner:
Type: bug | Status: new
#5797: readRawBufferPtr cannot be interrupted by exception on Windows with
-threaded
---+
Reporter: joeyadams | Owner:
Type: bug | Status: new
#5788: Missing document about RTS's -T option
+---
Reporter: shelarcy | Owner:
Type: bug| Status: closed
Priority: normal |
#5785: Test failures on i386 with LLVM backend
--+-
Reporter: dterei | Owner: dterei
Type: bug | Status: closed
Priority:
#5742: compiler option -XDoRec crash
---+
Reporter: Huenniger | Owner: simonpj
Type: bug | Status: closed
Priority:
#5773: main = forever (putStrLn = getLine) continuously saturates a CPU when
compiled
--+-
Reporter: lpsmith | Owner: simonmar
Type: bug | Status:
#5760: lib/settings file wrong
---+
Reporter: rl| Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
Component:
#5781: Add Data.List.at :: [a] - Int - Maybe a
---+
Reporter: nh2 | Owner:
Type: feature request | Status: closed
Priority: normal|
#5784: Forked thread running infinite loop blocks other threads from running
--+-
Reporter: joeyadams| Owner:
Type: bug | Status: closed
#5781: Add Data.List.at :: [a] - Int - Maybe a
---+
Reporter: nh2 | Owner:
Type: feature request | Status: closed
Priority: normal|
#5784: Forked thread running infinite loop blocks other threads from running
--+-
Reporter: joeyadams| Owner:
Type: bug | Status: closed
#5801: Document GHC Optimisation Passes
---+
Reporter: dterei | Owner: dterei
Type: task | Status: new
Priority: normal |
#5797: readRawBufferPtr cannot be interrupted by exception on Windows with
-threaded
---+
Reporter: joeyadams | Owner:
Type: bug | Status: new
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
*
*** Final Call for Participation ***
VSTTE 2012
Verified Software: Theories, Tools and Experiments
January 28-29, 2012
Philadelphia, USA (co-located with POPL and VMCAI)
On Thu, Jan 19, 2012 at 5:26 AM, Michael Snoyman mich...@snoyman.comwrote:
We can still have a conduit-based version of WAI and Warp, even if an
underlying package uses enumerator. The enumerator usage from
asn1-data doesn't leak into WAI or Warp at all[1]. We could ask
Vincent to consider
On 01/19/2012 08:14 AM, Gregory Collins wrote:
Speaking of the migration issue; it should be possible to have an
enumerator - conduit wrapper library to help people continue to use
their enumerator-based code for awhile (and vice-versa).
A bit out of topic and definitely not answering the
John Meacham j...@repetae.net writes:
now, you might say we can just move hackage out of the US
This might actually make things worse. The President's office is against
hurting US industry, and wants it to be mainly used to attack foreign
sites. They will not only order takedowns, but use DNS
On Thu, Jan 19, 2012 at 10:35 AM, Vincent Hanquez t...@snarc.org wrote:
On 01/19/2012 08:14 AM, Gregory Collins wrote:
Speaking of the migration issue; it should be possible to have an
enumerator - conduit wrapper library to help people continue to use
their enumerator-based code for
On Thu, Jan 19, 2012 at 10:14 AM, Gregory Collins
g...@gregorycollins.net wrote:
On Thu, Jan 19, 2012 at 5:26 AM, Michael Snoyman mich...@snoyman.com
wrote:
We can still have a conduit-based version of WAI and Warp, even if an
underlying package uses enumerator. The enumerator usage from
Hi,
I've got a program that seems to spend much of its time allocating
short-lived objects, which therefore don't show up in +RTS -hy or alike.
Is there a way to get a breakdown by type of the objects that are being
*allocated* but not necessarily retained (disappear after gen0)?
--
Eugene
I've just spent most of a morning trying to get bootstrap.sh
from the cabal-install package to work. The trick is to use
ghc-pkg init pathname to initialise the package file - simply
adding an empty package file or directory doesn't work.
Whoever is responsible for cabal-install, could you
Hello,
I'm trying to use the fftw binding, and its functions operate on CArrays of
Complex. My data is coming from hsndfile, so it starts out as a Vector of
Double. How do I convert this data to CArray? The API functions in the
CArray module don't seem to indicate how.
Thanks.
On 19.01.2012 22:15, Dominic Espinosa wrote:
Hello,
I'm trying to use the fftw binding, and its functions operate on CArrays of
Complex. My data is coming from hsndfile, so it starts out as a Vector of
Double. How do I convert this data to CArray? The API functions in the
CArray module don't
On Thu, Jan 19, 2012 at 1:15 PM, Dominic Espinosa dces...@fastmail.fm wrote:
Hello,
I'm trying to use the fftw binding, and its functions operate on CArrays of
Complex. My data is coming from hsndfile, so it starts out as a Vector of
Double. How do I convert this data to CArray? The API
Dear all,
I wanted to voice support for a partial type annotations. Here's my
usage scenario: I have a monad for an imperative EDSL, which has an
associated expression data type,
class (Monad m, Expression (ExprTyp m)) = MyDSLMonad m where
data ExprTyp m :: * - *
and you write
On 20.01.2012 00:37, Nicholas Tung wrote:
Dear all,
I wanted to voice support for a partial type annotations. Here's my
usage scenario: I have a monad for an imperative EDSL, which has an
associated expression data type,
I wanted such extension more than once. For me it's useful when
I have two types A and B, and I want to express that the composition of two
functions f :: B - A and g :: A - B gives me the identity idA = f . g ::
A - A. I don't need g . f :: B - B to be the identity on B, so I want a
weaker statement than isomorphism.
I understand that:
(1) If I look at it
On Thu, Jan 19, 2012 at 3:24 PM, Sean Leather leat...@cs.uu.nl wrote:
I have two types A and B, and I want to express that the composition of two
functions f :: B - A and g :: A - B gives me the identity idA = f . g :: A
- A. I don't need g . f :: B - B to be the identity on B, so I want a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2012 07:24 AM, Sean Leather wrote:
I have two types A and B, and I want to express that the composition of two
functions f :: B - A and g :: A - B gives me the identity idA = f . g ::
A - A. I don't need g . f :: B - B to be the identity
On Thu, Jan 19, 2012 at 10:15 AM, Dominic Espinosa dces...@fastmail.fm wrote:
Hello,
I'm trying to use the fftw binding, and its functions operate on CArrays of
Complex. My data is coming from hsndfile, so it starts out as a Vector of
Double. How do I convert this data to CArray? The API
Am 19.01.2012 um 22:24 schrieb Sean Leather:
I have two types A and B, and I want to express that the composition of two
functions f :: B - A and g :: A - B gives me the identity idA = f . g :: A
- A. I don't need g . f :: B - B to be the identity on B, so I want a
weaker statement than
A is a retract of B.
http://nlab.mathforge.org/nlab/show/retract
g is the section, f is the rectraction. You seem to have it already.
The definition needn't be biased toward one of the functions.
On Thu, Jan 19, 2012 at 4:24 PM, Sean Leather leat...@cs.uu.nl wrote:
I have two types A and
Oleg has described a grody hack which achieves this effect.
http://okmij.org/ftp/Haskell/types.html#partial-sigs
I agree more first class support for this would be nice.
Edward
Excerpts from Nicholas Tung's message of Thu Jan 19 15:37:28 -0500 2012:
Dear all,
I wanted to voice
On Thu, Jan 19, 2012 at 13:16, Aleksey Khudyakov
alexey.sklad...@gmail.comwrote:
On 20.01.2012 00:37, Nicholas Tung wrote:
Dear all,
I wanted to voice support for a partial type annotations. Here's my
usage scenario: I have a monad for an imperative EDSL, which has an
associated
On Thu, Jan 19, 2012 at 15:02, Edward Z. Yang ezy...@mit.edu wrote:
Oleg has described a grody hack which achieves this effect.
http://okmij.org/ftp/Haskell/types.html#partial-sigs
I agree more first class support for this would be nice.
Edward
That's an amusing hack, but does it
Today I learned (tldr; TIL) that the fail in the Monad class was added
as a hack to deal with the consequences of the decision to remove
unfailable patterns from the language. I will attempt to describe the
story as I have picked it up from reading around, but please feel free
to correct me on
Hello Gregory,
The original (1998!) conversation can be found here:
http://www.mail-archive.com/haskell@haskell.org/msg03002.html
I think Simon Peyton-Jones' example really sums up the whole issue:
But [MonadZero] really sticks in my craw. How can we explain this:
f ::
Oh, I'm sorry! On a closer reading of your message, you're asking not
only asking why 'fail' was added to Monad, but why unfailable patterns
were removed.
Well, from the message linked:
In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable
(it can't fail to match). But
On 01/20/12 13:23, Edward Z. Yang wrote:
In Haskell 1.4 g would not be in MonadZero because (a,b) is unfailable
(it can't fail to match). But the Haskell 1.4 story is unattractive
becuase
a) we have to introduce the (new) concept of unfailable
b) if you add
On Thu, Jan 19, 2012 at 10:43 PM, Gregory Crosswhite
gcrosswh...@gmail.com wrote:
first, that the notion of unfailable was not removed from the language
so much as not added in the first place
No, this is not correct. Unfailable patterns were specified in Haskell
1.4 (or, they were called
Aw, that is really suboptimal. Have you filed a bug?
Edward
Excerpts from Michael Snoyman's message of Thu Jan 19 23:29:59 -0500 2012:
On Fri, Jan 20, 2012 at 5:23 AM, Edward Z. Yang ezy...@mit.edu wrote:
Oh, I'm sorry! On a closer reading of your message, you're asking not
only asking why
On Fri, Jan 20, 2012 at 6:41 AM, Edward Z. Yang ezy...@mit.edu wrote:
Aw, that is really suboptimal. Have you filed a bug?
I think it's a feature, not a bug. When dealing with monads that
provide nice[1] implementations of `fail`, you can (ab)use this to
avoid writing a bunch of case
It's not obvious that this should be turned on by -Wall, since
you would also trigger errors on uses like:
[ x | Just x - xs ]
T_T
But I do think it ought to be an option.
Cheers,
Edward
Excerpts from Michael Snoyman's message of Thu Jan 19 23:52:10 -0500 2012:
On Fri, Jan 20, 2012 at
On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang ezy...@mit.edu wrote:
It's not obvious that this should be turned on by -Wall, since
you would also trigger errors on uses like:
[ x | Just x - xs ]
I was going to say, perhaps refutable matches were considered
important was because back then
As expected, no warnings. But if I change this unfailable code above
to the following failable version:
data MyType = Foo | Bar
test myType = do
Foo - myType
return ()
I *still* get no warnings! We didn't make sure the compiler spits out
warnings. Instead, we
On Jan 20, 2012 8:31 AM, John Meacham j...@repetae.net wrote:
As expected, no warnings. But if I change this unfailable code above
to the following failable version:
data MyType = Foo | Bar
test myType = do
Foo - myType
return ()
I *still* get no warnings!
In the spirit of Oleg's hack, but with nicer combinator support, you can
use the patch combinators I just uploaded to Hackage (prompted by this
thread):
http://hackage.haskell.org/package/patch-combinators
Your example then becomes:
my_code_block = do
x - instruction1 -:: tCon
On 01/20/12 14:52, Michael Snoyman wrote:
Essentially, I would want:
SomeConstr args - someAction
to be interpreted as:
temp - someAction
case temp of
SomeConstr args -
I completely agree; perhaps what we really want though is something
more akin to a language extension --- say,
On Thu, Jan 19, 2012 at 11:11 PM, Dan Doel dan.d...@gmail.com wrote:
No, this is not correct. Unfailable patterns were specified in Haskell
1.4 (or, they were called failure-free there; they likely existed
earlier, too, but I'll leave the research to people who are
interested). They were new
On Fri, Jan 20 2012 at 06:22 +0100, Evan Laforge wrote:
On Thu, Jan 19, 2012 at 8:53 PM, Edward Z. Yang ezy...@mit.edu wrote:
It's not obvious that this should be turned on by -Wall, since
you would also trigger errors on uses like:
[ x | Just x - xs ]
[...]
I would have suggested that
71 matches
Mail list logo
