2011/10/5 Simon Peyton-Jones :
> | In the spirit of "don't let the perfect be the enemy of the good"
> | though, I'm solidly in favor of the original proposal as it is.
>
> This is my thought too. George is proposing to extend Haskell's existing
> mechanism for numeric literals (namely, replace
On Sun, Oct 9, 2011 at 10:54 AM, Roman Cheplyaka wrote:
> * Jan-Willem Maessen [2011-10-08 12:32:18-0400]
>> It seems to be a common misconception that eta-abstracting your
>> functions in this way will speed up or otherwise improve your code.
>>
>> Simon PJ has already provided a good explanatio
On Oct 6, 2011, at 10:30 AM, Roman Leshchinskiy wrote:
> Manuel M T Chakravarty wrote:
>> Roman Leshchinskiy:
>>>
>>> What data structures other than lists do we want to construct using list
>>> literals? I'm not really sure what the use cases are.
>>
>> Parallel arrays! (I want to get rid of o
Thanks to all of you for providing feedback on my proposal and for providing
alternatives.
In this email, I will try to collect all proposals and give pros and cons for
each of those (although I will try to provide a good argumentation, some of
them might be subjective).
Inspired by Simon's an
On Sun, Oct 09, 2011 at 03:30:20PM +0200, Jean-Marie Gaillourdet wrote:
Hi Daniel,
On 09.10.2011, at 14:45, Daniel Fischer wrote:
On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
This seems to be a Heisenbug as it is extremely fragile, when adding a
"| grep 1" to the while l
Excerpts from Greg Weber's message of Sun Oct 09 12:39:03 -0400 2011:
> So first of all I am wondering if a sum type comparison does in fact scale
> linearly or if there are optimizations in place to make the lookup constant
> or logarithmic. Second, I as wondering (for the routing case) if Haskell
We have a couple use cases in Yesod that can potentially match many
different patterns. Routing connects the url of an http request to a Haskell
function. The current code just uses a pattern match, which scales linearly.
So if a site has a hundred different routes (urls), it could take 100
compari
On 09.10.2011, at 18:13, Daniel Fischer wrote:
> On Sunday 09 October 2011, 17:51:06, Jean-Marie Gaillourdet wrote:
>>> That sounds plausible. Do you see any workaround? Perhaps repeatedly
>>> evaluating typeOf?
>>
>> typeOf' seems to be a working workaround:
>>
>> typeOf' val
>>| t1 == t2
On Sunday 09 October 2011, 17:51:06, Jean-Marie Gaillourdet wrote:
> > That sounds plausible. Do you see any workaround? Perhaps repeatedly
> > evaluating typeOf?
>
> typeOf' seems to be a working workaround:
>
> typeOf' val
> | t1 == t2 = t1
> | otherwise = typeOf' val
> where
> t
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu wrote:
> Quoting Jean-Marie Gaillourdet :
>
>> That sounds plausible. Do you see any workaround? Perhaps repeatedly
>> evaluating typeOf?
>
> If there's a concurrency bug, surely the workaround is to protect calls to
> the non-thread-safe funct
On 09.10.11 15:45, Felipe Almeida Lessa wrote:
On Sun, Oct 9, 2011 at 8:26 AM, Roman Beslik wrote:
Why the following code does not work?
data Empty
quodlibet :: Empty -> a
quodlibet x = case x of
"parse error (possibly incorrect indentation)"
Works for me:
data Empty
quodlibet :: Em
Quoting Jean-Marie Gaillourdet :
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
If there's a concurrency bug, surely the workaround is to protect
calls to the non-thread-safe function with a lock.
typeOfWorkaround lock v = do
() <- take
Hi,
On 09.10.2011, at 17:37, Jean-Marie Gaillourdet wrote:
> Hi,
>
> On 09.10.2011, at 17:27, Daniel Fischer wrote:
>
>> That's what I expect.
>> I think what happens is:
>>
>> -- from Data.Typeable
>>
>> cache = unsafePerformIO $ ...
>>
>>
>> mkTyConKey :: String -> Key
>> mkTyConKey str
Hi,
On 09.10.2011, at 17:27, Daniel Fischer wrote:
> Jean-Marie Gaillourdet:
>> the Eq instance of TypeRep shows the same non-deterministic behavior:
>
> Of course, equality on TypeReps is implemented by comparison of the Keys.
>
> On Sunday 09 October 2011, 16:40:13, Jean-Marie Gaillourdet wro
Jean-Marie Gaillourdet:
> the Eq instance of TypeRep shows the same non-deterministic behavior:
Of course, equality on TypeReps is implemented by comparison of the Keys.
On Sunday 09 October 2011, 16:40:13, Jean-Marie Gaillourdet wrote:
> Hi Daniel,
> I've been chasing the source of the non-dete
On 09.10.2011, at 16:40, Jean-Marie Gaillourdet wrote:
> I will report a bug.
http://hackage.haskell.org/trac/ghc/attachment/ticket/5540/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/
* Jan-Willem Maessen [2011-10-08 12:32:18-0400]
> It seems to be a common misconception that eta-abstracting your
> functions in this way will speed up or otherwise improve your code.
>
> Simon PJ has already provided a good explanation of why GHC eta
> expands. Let me take another tack and desc
Hi Daniel,
On 09.10.2011, at 16:24, Daniel Fischer wrote:
> On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote:
>> Hi Daniel,
>>
>> On 09.10.2011, at 14:45, Daniel Fischer wrote:
>>> On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
This seems to be a Heise
Hi,
the Eq instance of TypeRep shows the same non-deterministic behavior:
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
main :: IO ()
main =
do { fin1 <- newEmptyMVar
; fin2 <- newEmptyMVar
; forkIO $ return (typeOf ()) >>= evaluate >>= pu
On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote:
> Hi Daniel,
>
> On 09.10.2011, at 14:45, Daniel Fischer wrote:
> > On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
> >> This seems to be a Heisenbug as it is extremely fragile, when adding
> >> a "| grep 1" to t
Hi Daniel,
On 09.10.2011, at 14:45, Daniel Fischer wrote:
> On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
>> This seems to be a Heisenbug as it is extremely fragile, when adding a
>> "| grep 1" to the while loop it seems to disappears. At least on my
>> computers.
>
> Still
On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
> This seems to be a Heisenbug as it is extremely fragile, when adding a
> "| grep 1" to the while loop it seems to disappears. At least on my
> computers.
Still produces 1s here with a grep.
>
> All this was done on several Mac
On Sun, Oct 9, 2011 at 8:26 AM, Roman Beslik wrote:
> Why the following code does not work?
>> data Empty
>> quodlibet :: Empty -> a
>> quodlibet x = case x of
> "parse error (possibly incorrect indentation)"
Works for me:
data Empty
quodlibet :: Empty -> a
quodlibet x = case x of _ -> un
Hi,
I am working on a library I'd like to release to hackage very soon, but I've
found a problem with supporting GHC 6.12 and GHC 7.0.
Consider the following program:
import Control.Concurrent
import Data.Typeable
main :: IO ()
main =
do { fin1 <- newEmptyMVar
; fin2 <- newEmptyMVar
Hi.
Why the following code does not work?
> data Empty
> quodlibet :: Empty -> a
> quodlibet x = case x of
"parse error (possibly incorrect indentation)"
This works in Coq, for instance. Demand for empty types is not big, but
they are useful for generating finite types:
> Empty ≅ {}
> Maybe Em
25 matches
Mail list logo
