Re: ANNOUNCE: GHC 7.10.1 Release Candidate 3
On 16 March 2015 at 21:30, Austin Seipp wrote: > We are pleased to announce the third release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc3 > https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/ I noticed that the Haddock docs return 404s: https://downloads.haskell.org/~ghc/7.10.1-rc3/docs/html/libraries/Prelude.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Thread behavior in 7.8.3
Hi Michael, Are you already using usb-1.3.0.0? If not, could you upgrade and test again? That release fixed the deadlock that Ben and Carter where talking about. Good luck, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proving properties of type-level natural numbers obtained from user input
On 25 November 2014 at 19:34, Richard Eisenberg wrote: > If I were you, I would just write `g` using unsafeCoerce in the right spot, > instead of bothering with all the singletons, which would have to use > unsafety anyway. Thanks, I hadn't considered this yet. Cheers, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proving properties of type-level natural numbers obtained from user input
Hi Alexander,
Thanks for your answer! This provides a lot of ideas how to proceed.
I'm unsure about the following though:
> lessThen :: KnownNat m => SomeNat -> Proxy m -> Maybe (Proof (n <= m) (Proxy
> n))
> lessThen (SomeNat p) k
>| natVal p <= natVal k = Just (Proof $ Tagged (Proxy :: Proxy n))
>| otherwise = Nothing
Doesn't this mean lessThen returns a Proxy n for all (n :: Nat) and
not just the Nat inside the SomeNat?
I also see that p is only used for comparing it to k. It's not used to
produce the return value.
Cheers,
Bas
On 25 November 2014 at 19:55, Alexander V Vershilov
wrote:
> Hi, Richard, Bas.
>
> Maybe I didn't spell it properly but my point was to create a data
> type that carry a proof
> without exposing it's constructor and having clever constructor only,
> then the only place
> where you need to check will be that constructor.
>
> Also it's possible to write in slightly clearer, but again it's
> possible to make a mistake here
> and it will be a false proof.
>
>> lessThen :: KnownNat m => SomeNat -> Proxy m -> Maybe (Proof (n <= m) (Proxy
>> n))
>> lessThen (SomeNat p) k
>>| natVal p <= natVal k = Just (Proof $ Tagged (Proxy :: Proxy n))
>>| otherwise = Nothing
>
> Of cause solution using singletons could solve this problem much better.
>
> --
> Alexander
>
> On 25 November 2014 at 21:34, Richard Eisenberg wrote:
>> Hi Bas,
>>
>> I believe to do this "right", you would need singleton types. Then, when you
>> discover that the number is bounded by 255, you would also discover that the
>> type is bounded by 255, and you'd be home free.
>>
>> Unfortunately, I there isn't currently a way to do comparison on
>> GHC.TypeLits Nats with singletons. (There is a module
>> Data.Singletons.TypeLits in the `singletons` package, but there's a comment
>> telling me TODO in the part where comparison should be implemented.) If it
>> were implemented, it would have to use unsafeCoerce, as there's no built-in
>> mechanism connecting runtime numbers with TypeLits.
>>
>> If I were you, I would just write `g` using unsafeCoerce in the right spot,
>> instead of bothering with all the singletons, which would have to use
>> unsafety anyway.
>>
>> The solution Alexander provides below doesn't quite build a proof, I think.
>> Tellingly, if we omit the `natVal p <= 255` check, everything else still
>> compiles. Thus, the `Proof` type he uses can be built even if the fact
>> proven is false. That said, I don't know if my solution is any better,
>> crucially relying on unsafeCoerce.
>>
>> Richard
>>
>> On Nov 25, 2014, at 4:52 AM, Alexander V Vershilov
>> wrote:
>>
>>> Hi,
>>>
>>> Following approach can work, the idea is to define a type that will
>>> carry a proof (constraint) that we want to check. Here I have reused
>>> Data.Tagged, but it's possible to introduce your own with concrete
>>> constraints.
>>>
>>>> {-# LANGUAGE DataKinds #-}
>>>> {-# LANGUAGE GADTs #-}
>>>> {-# LANGUAGE TypeOperators #-}
>>>> {-# LANGUAGE KindSignatures #-}
>>>> {-# LANGUAGE PolyKinds #-}
>>>> {-# LANGUAGE UndecidableInstances #-}
>>>> import GHC.TypeLits
>>>> import GHC.Exts
>>>> import Data.Proxy
>>>> import Data.Tagged
>>>> import System.Environment
>>>
>>> New constraint carrying data type
>>>
>>>> newtype Proof a b = Proof { unProof :: Tagged a b }
>>>
>>> Runtime check for unknown naturals
>>>
>>>> fromSome :: SomeNat -> Maybe (Proof (n <= 255) (Proxy n))
>>>> fromSome (SomeNat p)
>>>> | natVal p <= 255 = Just (Proof $ Tagged (Proxy :: Proxy n))
>>>> | otherwise = Nothing
>>>
>>> Compiletime converter for known naturals
>>>
>>>> fromKnown :: (KnownNat n, n <= 255) => Proxy n -> Proof (n <= 255) (Proxy
>>>> n)
>>>> fromKnown n = Proof $ Tagged n
>>>
>>> Function to test:
>>>
>>>> f2 :: (c ~ (n <= 255)) => Proof c (Proxy n) -> ()
>>>> f2 _ = ()
>>>
>>> Example of use:
>>>
>>>> main :: IO ()
>>>> main = do
>>>>[arg] <- getArgs
>>>>let n = read arg :: Integer
>>>>
>>>>case someNatVal n of
>>>> Nothing -> error "Input is not
Proving properties of type-level natural numbers obtained from user input
Hi,
I have another type-level programming related question:
> {-# LANGUAGE GADTs #-}
> {-# LANGUAGE TypeOperators #-}
> {-# LANGUAGE ScopedTypeVariables #-}
> {-# LANGUAGE KindSignatures #-}
>
> import GHC.TypeLits
Say I have a Proxy p of some type-level natural number:
> p :: forall (n :: Nat). Proxy n
> p = Proxy
Imagine I get p from user input like this:
> main :: IO ()
> main = do
> [arg] <- getArgs
> let n = read arg :: Integer
>
> case someNatVal n of
> Nothing -> error "Input is not a natural number!"
> Just (SomeNat (p :: Proxy n)) -> ...
I also have a function f which takes a proxy of a natural number but
it has the additional constraint that the number should be lesser than
or equal to 255:
> f :: forall (n :: Nat). (n <= 255) => proxy n -> ()
> f _ = ()
How do I apply f to p?
Obviously, applying it directly gives the type error:
> f p
:179:1:
Couldn't match expected type ‘'True’ with actual type ‘n0 <=? 255’
The type variable ‘n0’ is ambiguous
In the expression: f p
In an equation for ‘it’: it = f p
I imagine I somehow need to construct some Proof object using a function g like:
> g :: forall (n :: Nat). proxy n -> Proof
> g _ = ...
Where the Proof constructor encapsulates the (n <= 255) constraint:
> data Proof where
> NoProof :: Proof
> Proof :: forall (n :: Nat). (n <= 255)
> => Proxy n -> Proof
With g in hand I can construct c which patterns matches on g p and
when there's a Proof the (n <= 255) constraint will be in scope which
allows applying f to p:
> c :: ()
> c = case g p of
> NoProof -> error "Input is bigger than 255!"
> Proof p -> f p
But how do I define g?
Cheers,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Caching intermediate powers in GHC.Float
Does the following make sense: https://ghc.haskell.org/trac/ghc/ticket/9120 Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Private classes
Hi Joachim, I used the following in the past: module M (PublicClass(..)) where class HiddenClass a class HiddenClass a => PublicClass a where ... instance HiddenClass SomeType instance PublicClass SomeType where ... Now users of M can't declare instances of PublicClass because they don't have its superclass HiddenClass in scope. Regards, Bas On Aug 17, 2013 8:10 PM, "Joachim Breitner" wrote: > Hi, > > for some reason I was under the impression that if I don’t export the > methods of a class, then no user of my module can create instances. But > I was wrong and in fact they can; the methods will just all be bound to > "error ...". > > Is there really no way to create a class so that no-one else can create > any instances? > > Greetings, > Joachim > > -- > Joachim “nomeata” Breitner > m...@joachim-breitner.de • http://www.joachim-breitner.de/ > Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C > Debian Developer: nome...@debian.org > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On 6 September 2012 18:05, Ian Lynagh wrote: > The GHC Team is pleased to announce a new major release of GHC, 7.6.1. Great! > * It is now possible to defer type errors until runtime using the > -fdefer-type-errors flag. In section 7.13.1 it says: ...given the following code: x :: Int x = 0 y :: Char y = x z :: Int z = y evaluating x will result in a runtime type error. Shouldn't this be: evaluating z will result in a runtime type error. Cheers, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New INLINE pragma syntax idea, and some questions
On 4 August 2012 15:53, Brandon Simmons wrote: > The only thing that bothers me about this foldl is the presence of z0 xs0, > which I think > are only there on the LHS to indicate to GHC where it should inline. Are these really needed? Since GHC only inlines functions which are "fully applied" (where according to [1] "fully applied" means applied to as many arguments as appear (syntactically) on the LHS of the function definition) I think it's more desirable to remove these arguments (or at least the xs0) since then the function is more likely to be inlined in cases such as: sum = foldl (+) 0 [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#inline-pragma ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type error when deriving Generic for an associated data type
On 12 July 2012 12:33, Andres Löh wrote: > Your example compiles for me with HEAD (but fails with 7.4.1 and > 7.4.2, yes). I've not tested if it also "works". Great, I will wait for a new release then. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Type error when deriving Generic for an associated data type
Hi,
I'm hitting on an issue when deriving Generic for an associated data type:
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DeriveGeneric #-}
import GHC.Generics
class Foo a where
data T a :: *
instance Foo Int where
data T Int = Bla deriving Generic
Couldn't match type `Rep (T Int)' with `M1 t0 t1 (M1 t2 t3 U1)'
Expected type: Rep (T Int) x
Actual type: M1 t0 t1 (M1 t2 t3 U1) x
In the pattern: M1 (M1 U1)
In an equation for `to': to (M1 (M1 U1)) = Bla
In the instance declaration for `Generic (T Int)'
The GHC trac seems to be down. Is this a known issue?
Cheers,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault/access violation in generated code
On 23 June 2012 02:40, Ian Lynagh wrote:
>
> Hi Bas,
>
> On Sun, Jun 17, 2012 at 05:11:35PM +0200, Bas van Dijk wrote:
>>
>> module Main where
>>
>> import Foreign
>> import qualified Foreign.Concurrent as FC
>> import Control.Concurrent
>> import Bindings.Libusb.InitializationDeinitialization
>>
>> main :: IO ()
>> main = do
>> ctxPtr <- alloca $ \ctxPtrPtr -> do
>> _ <- c'libusb_init ctxPtrPtr
>> peek ctxPtrPtr
>>
>> fp <- newForeignPtr p'libusb_exit ctxPtr
>> -- fp <- FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr
>>
>> threadDelay 300
>> print $ fp == fp
>
> What happens if you just call
> c'libusb_exit ctxPtr
> at the end, instead of using a finalizer?
Then I don't get an error. So executing the following program with the
argument "fp" gives an error (although this time I don't get an access
violation but instead Windows pops up a dialog box indicating an
error) and without an argument I get no error:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.C.Types
import Control.Concurrent
import System.Environment
main :: IO ()
main = do
ctxPtr <- alloca $ \ctxPtrPtr -> do
_ <- c'libusb_init ctxPtrPtr
peek ctxPtrPtr
args <- getArgs
case args of
["fp"] -> do
fp <- newForeignPtr p'libusb_exit ctxPtr
threadDelay 100
print $ fp == fp
_ -> c'libusb_exit ctxPtr
data C'libusb_context = C'libusb_context
foreign import stdcall "libusb_init" c'libusb_init
:: Ptr (Ptr C'libusb_context) -> IO CInt
foreign import stdcall "&libusb_exit" p'libusb_exit
:: FunPtr (Ptr C'libusb_context -> IO ())
foreign import stdcall "libusb_exit" c'libusb_exit
:: Ptr C'libusb_context -> IO ()
> Are you able to reproduce this with just a .c file that is compiled and
> linked with the program, rather than needing libusb? That would make it
> easier to reproduce, to understand, and to add a test.
I'm not sure how to do this. I guess just copying the libusb .c and .h
files to the same directory as the .hs file is not enough since libusb
requires a configure phase.
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Segmentation fault/access violation in generated code
I just tried building the following program with the new GHC
win64_alpha1 and apart from warnings from using the unsupported
stdcall calling convention running the program doesn't give a
segmentation fault as it does when building the program with
GHC-7.4.2:
{-# LANGUAGE ForeignFunctionInterface #-}
module Main where
import Foreign
import Foreign.C.Types
main :: IO ()
main = do
ctxPtr <- alloca $ \ctxPtrPtr -> do
_ <- c'libusb_init ctxPtrPtr
peek ctxPtrPtr
fp <- newForeignPtr p'libusb_exit ctxPtr
threadDelay 100
print $ fp == fp
data C'libusb_context = C'libusb_context
foreign import stdcall "libusb_init" c'libusb_init
:: Ptr (Ptr C'libusb_context) -> IO CInt
foreign import stdcall "&libusb_exit" p'libusb_exit
:: FunPtr (Ptr C'libusb_context -> IO ())
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Segmentation fault/access violation in generated code
Hello, I'm trying to solve #5254 (http://hackage.haskell.org/trac/ghc/ticket/5254). The issue can be isolated to the following short program which only uses bindings-libusb (http://hackage.haskell.org/packages/archive/bindings-libusb/1.4.4.1/doc/html/Bindings-Libusb-InitializationDeinitialization.html): -- module Main where import Foreign import qualified Foreign.Concurrent as FC import Control.Concurrent import Bindings.Libusb.InitializationDeinitialization main :: IO () main = do ctxPtr <- alloca $ \ctxPtrPtr -> do _ <- c'libusb_init ctxPtrPtr peek ctxPtrPtr fp <- newForeignPtr p'libusb_exit ctxPtr -- fp <- FC.newForeignPtr ctxPtr $ c'libusb_exit ctxPtr threadDelay 300 print $ fp == fp -- When I run this program on Windows I get the following error after 3 seconds: >example.exe True Segmentation fault/access violation in generated code The error disappears when I change the newForeignPtr line to the commented FC.newForeignPtr line. Any idea why this is happening? I don't know if it has anything to do with it but note that the libusb FFI functions are using the stdcall calling convention on Windows. I'm using GHC-7.4.2 but this error also occurs in previous versions. To reproduce this just download libusb (I recommend http://libusbx.org/) and when cabal installing bindings-libusb tell it the path to the include and library files, as in: cabal install bindings-libusb --extra-include-dirs="...\libusb\include\libusb-1.0" --extra-lib-dirs="...\libusb\MinGW32\dll" and make sure the libusb-1.0.dll is in your working directory when running the example program. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird behavior of the NonTermination exception
On 4 May 2012 14:12, Simon Marlow wrote: > The forked thread is deadlocked, so the MVar is considered unreachable and > the main thread is also unreachable. Hence both threads get sent the > exception. > > The RTS does this analysis using the GC, tracing the reachable objects > starting from the roots. It then send an exception to any threads which > were not reachable, which in this case is both the main thread and the > child, since neither is reachable. > > We (the user) knows that waking up the child thread will unblock the main > thread, but the RTS doesn't know this, and it's not clear how it could find > out easily (i.e. without multiple scans of the heap). Thanks Simon, I learned something new today. Cheers, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird behavior of the NonTermination exception
On 3 May 2012 18:14, Bas van Dijk wrote: > Now it seems the thread is killed while delaying. But why is it > killed? Oh I realise the forked thread is killed because the main thread terminates because it received a BlockedIndefinitelyOnMVar exception and then all daemonic threads are killed. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird behavior of the NonTermination exception
On 3 May 2012 17:31, Edward Z. Yang wrote: > Excerpts from Bas van Dijk's message of Thu May 03 11:10:38 -0400 2012: >> As can be seen, the putMVar is executed successfully. So why do I get >> the message: "thread blocked indefinitely in an MVar operation"? > > GHC will send BlockedIndefinitelyOnMVar to all threads involved > in the deadlock, so it's not unusual that this can interact with > error handlers to cause the system to become undeadlocked. But why is the BlockedIndefinitelyOnMVar thrown in the first place? According to the its documentation and your very enlightening article it is thrown when: "The thread is blocked on an MVar, but there are no other references to the MVar so it can't ever continue." The first condition holds for the main thread since it's executing takeMVar. But the second condition doesn't hold since the forked thread still has a reference to the MVar. I just tried delaying the thread before the putMVar: - main :: IO () main = do mv <- newEmptyMVar _ <- forkIO $ do catch action (\e -> putStrLn $ "I solved the Halting Problem: " ++ show (e :: SomeException)) putStrLn "Delaying for 2 seconds..." threadDelay 200 putStrLn "putting MVar..." putMVar mv () putStrLn "putted MVar" takeMVar mv - Now I get the following output: loop: thread blocked indefinitely in an MVar operation I solved the Halting Problem: <> Delaying for 2 seconds... Now it seems the thread is killed while delaying. But why is it killed? It could be a BlockedIndefinitelyOnMVar that is thrown. However I get the same output when I catch and print all exceptions in the forked thread: main :: IO () main = do mv <- newEmptyMVar _ <- forkIO $ handle (\e -> putStrLn $ "Oh nooo:" ++ show (e :: SomeException)) $ do catch action (\e -> putStrLn $ "I solved the Halting Problem: " ++ show (e :: SomeException)) putStrLn "Delaying for 2 seconds..." threadDelay 200 putStrLn "putting MVar..." putMVar mv () putStrLn "putted MVar" takeMVar mv Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Weird behavior of the NonTermination exception
Hello, Before I turn the following into a ticket I want to ask if I miss something obvious: When I run the following program: - import Prelude hiding (catch) import Control.Exception import Control.Concurrent main :: IO () main = do mv <- newEmptyMVar _ <- forkIO $ do catch action (\e -> putStrLn $ "I solved the Halting Problem: " ++ show (e :: SomeException)) putStrLn "putting MVar..." putMVar mv () putStrLn "putted MVar" takeMVar mv action :: IO () action = let x = x in x - I get the output: $ ghc --make Loop.hs -o loop -O2 -fforce-recomp && ./loop [1 of 1] Compiling Main ( Loop.hs, Loop.o ) Linking loop ... loop: thread blocked indefinitely in an MVar operation I solved the Halting Problem: <> putting MVar... putted MVar As can be seen, the putMVar is executed successfully. So why do I get the message: "thread blocked indefinitely in an MVar operation"? Note that if I change the action to a normal error the message disappears. I discovered this bug when hunting for another one. I have a Haskell web-server where one of the request handlers contained a loop. All exceptions thrown by handlers are caught and logged. When executing the looping handler I noticed ~0% CPU usage so I assumed that the handler wasn't actually looping because a NonTermination exception was thrown. However for some reason the NonTermination exception was not caught and logged. I haven't yet isolated this bug into a small test-case but when trying that I discovered the above. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: default instance for IsString
On 23 April 2012 20:34, J. Garrett Morris wrote: > On Mon, Apr 23, 2012 at 9:58 AM, Yitzchak Gale wrote: >> In addition, OverloadedStrings is unsound. > > No. OverloadedStrings treats string literals as applications of > fromString to character list constants. fromString can throw errors, > just like fromInteger; this is no less sound than any Haskell function > throwing an exception. But it would be safer if those errors were moved to compile time by treating overloaded literals as Template Haskell splices. As in: 1 would be translated to: $(fromIntegerLit 1) where: class FromIntegerLit a where fromIntegerLit :: Integer -> Q (Exp a) (this assumes that Exp is parameterized by the type of the value it splices to which is currently not the case. However you can work around this by using a Proxy or Tagged value.) An instance for Integer is trivial: instance FromIntegerLit Integer where fromIntegerLit = litE . integerL The extra safety comes when giving an instance for natural numbers, for example: newtype Nat = Nat Integer instance FromIntegerLit Nat where fromIntegerLit n | n < 0 = error "Can't have negative Nats" | otherwise = 'Nat `appE` fromIntegerLit n Note that the error will be thrown at compile time when the user has written a negative Nat literal. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Changes to Typeable
On 11 February 2012 00:30, John Meacham wrote:
> Would it be useful to make 'Proxy' an unboxed type itself? so
>
> Proxy :: forall k . k -> #
>
> This would statically ensure that no one accidentally passes ⊥ as a parameter
> or will get anything other than the unit 'Proxy' when trying to evaluate it.
> So the compiler can unconditionally elide the parameter at runtime. Pretty
> much exactly how State# gets dropped which has almost the same definition.
Or don't use an argument at all:
class Typeable t where
typeRep :: Tagged t TypeRep
newtype Tagged s b = Tagged { unTagged :: b }
See:
http://hackage.haskell.org/packages/archive/tagged/0.2.3.1/doc/html/Data-Tagged.html
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHCi-7.4.1: Importing a non existing module succeeds
Should I file a bug for this: GHCi 7.2.2: > import I.Do.Not.Exist : Could not find module `I.Do.Not.Exist' Use -v to see a list of the files searched for. GHCi 7.4.1: > import I.Do.Not.Exist > (and for the record: I.Do.Not.Exist does not exist) Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Error when deriving Typeable for associated type
Hello,
Given the following program:
---
{-# LANGUAGE DeriveDataTypeable, TypeFamilies #-}
import Data.Typeable
class C a where
data T a :: *
data MyType1 = MyType1 deriving Typeable
data MyType2 = MyType2 deriving Typeable
instance C MyType1 where
data T MyType1 = A1 deriving (Typeable)
instance C MyType2 where
data T MyType2 = A2 deriving (Typeable)
---
I get the following unexpected error:
TF_Data.hs:12:34:
Duplicate instance declarations:
instance Typeable1 T -- Defined at TF_Data.hs:12:34
instance Typeable1 T -- Defined at TF_Data.hs:15:34
When looking at the output of -ddump-deriv I see that the following
instance is generated:
instance Typeable1 T where ...
I would have expected that the following instances were generated instead:
instance Typeable1 (T MyType1) where ...
instance Typeable1 (T MyType2) where ...
Is this a bug in GHC?
Thanks,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Error when building cabal package with template haskell configured for profiling
On 27 January 2012 15:14, Felipe Almeida Lessa wrote: > On Fri, Jan 27, 2012 at 12:06 PM, Bas van Dijk wrote: >> $ cabal configure --ghc-options="-O2 -prof -auto-all -caf-all" > > Why aren't you using the specific options for profiling? > > $ cabal configure --help | grep profiling > -p --enable-library-profiling Enable Library profiling > --disable-library-profiling Disable Library profiling > --enable-executable-profiling Enable Executable profiling > --disable-executable-profiling Disable Executable profiling This gives the following error: $ cabal configure --enable-executable-profiling ... $ cabal build ... cannot find normal object file `' while linking an interpreted expression However when I apply the same trick as before, first building normally then building with profiling enabled, it works: $ cabal configure ... $ cabal build ... $ cabal configure --enable-executable-profiling ... $ cabal build ... success! Thanks for the hint! Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Error when building cabal package with template haskell configured for profiling
Hello, I would like to profile a cabal package that contains template haskell code. However I get the following error: $ cabal configure --ghc-options="-O2 -prof -auto-all -caf-all" ... $ cabal build ... Dynamic linking required, but this is a non-standard build (eg. prof). You need to build the program twice: once the normal way, and then in the desired way using -osuf to set the object file suffix. What's the best way to solve this? Currently I do a cabal build -v and copy the ghc --make ... command line. Then I first build the program normally (without -prof) and then build it with -prof and -osuf p_o like the error messages suggests. This is annoying however. Is there a ticket for this bug? Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ConstraintKinds and default associated empty constraints
That would be nice. It would also be nice to be able to use _ in type signatures as in: const :: a -> _ -> a const x _ = x During type checking each _ could be replaced by a new unique type variable. Visa versa should also be possible: during type inferencing each unique type variable could be replaced by a _. Bas On Jan 9, 2012 6:22 AM, "wren ng thornton" wrote: > On 1/8/12 8:32 AM, Bas van Dijk wrote: > >> On 23 December 2011 17:44, Simon >> Peyton-Jones> >> wrote: >> >>> My attempt at forming a new understanding was driven by your example. >>> >>> class Functor f where >>>type C f :: * -> Constraint >>>type C f = () >>> >>> sorry -- that was simply type incorrect. () does not have kind * -> >>> Constraint >>> >> >> So am I correct that the `class Empty a; instance Empty a` trick is >> currently the only way to get default associated empty constraints? >> > > Couldn't the following work? > >class Functor f where >type C f :: * -> Constraint >type C f _ = () > > It seems to me that adding const to the type level (either implicitly or > explicitly) is cleaner and simpler than overloading () to be Constraint, > *->Constraint, *->*->Constraint,... > > -- > Live well, > ~wren > > __**_ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.**org > http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users<http://www.haskell.org/mailman/listinfo/glasgow-haskell-users> > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ConstraintKinds and default associated empty constraints
On 23 December 2011 17:44, Simon Peyton-Jones wrote: > My attempt at forming a new understanding was driven by your example. > > class Functor f where > type C f :: * -> Constraint > type C f = () > > sorry -- that was simply type incorrect. () does not have kind * -> > Constraint So am I correct that the `class Empty a; instance Empty a` trick is currently the only way to get default associated empty constraints? Will this change in GHC-7.4.1? (For example by having an overloaded `()`) The reason I ask is I would like to know if it's already feasible to start proposing adding these associated constraints to Functor, Applicative and Monad. Cheers, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ConstraintKinds and default associated empty constraints
On 22 December 2011 09:31, Simon Peyton-Jones wrote: > What about > > class Functor f where > type C f :: * -> Constraint > type C f = () > > After all, just as (Ord a, Show a) is a contraint, so is (). But there's a kind mis-match there. `C f` should have kind `* -> Constraint` but () has kind *. Or do I have to enable some language extension to make this work? Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ConstraintKinds and default associated empty constraints
On 22 December 2011 01:58, wrote: > Quoting Bas van Dijk : > >> I'm playing a bit with the new ConstraintKinds feature in GHC >> 7.4.1-rc1. I'm trying to give the Functor class an associated >> constraint so that we can make Set an instance of Functor. The >> following code works but I wonder if the trick with: class Empty a; >> instance Empty a, is the recommended way to do this: > > > Maybe something like this? > > class Functor f where > type C f a :: Constraint > type C f a = () > > instance Functor Set where > type C Set a = Ord a > > ~d > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Yes I already tried that, but the following gives a type error: instance Functor [] where fmap = map testList = fmap (+1) [1,2,3] Could not deduce (C [] b0) arising from a use of `fmap' In the expression: fmap (+ 1) [1, 2, 3] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ConstraintKinds and default associated empty constraints
I'm playing a bit with the new ConstraintKinds feature in GHC
7.4.1-rc1. I'm trying to give the Functor class an associated
constraint so that we can make Set an instance of Functor. The
following code works but I wonder if the trick with: class Empty a;
instance Empty a, is the recommended way to do this:
{-# LANGUAGE ConstraintKinds, TypeFamilies, FlexibleInstances #-}
import GHC.Prim (Constraint)
import Prelude hiding (Functor, fmap)
import Data.Set (Set)
import qualified Data.Set as S (map, fromList)
class Functor f where
type C f :: * -> Constraint
type C f = Empty
fmap :: (C f a, C f b) => (a -> b) -> f a -> f b
class Empty a; instance Empty a
instance Functor Set where
type C Set = Ord
fmap = S.map
instance Functor [] where
fmap = map
testList = fmap (+1) [1,2,3]
testSet = fmap (+1) (S.fromList [1,2,3])
Cheers and thanks for a great new feature!
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 22 December 2011 00:10, José Pedro Magalhães wrote:
> Hi Bas,
>
> On Wed, Dec 21, 2011 at 23:02, Bas van Dijk wrote:
>>
>> On 21 December 2011 19:29, Ian Lynagh wrote:
>> > * There is a new feature constraint kinds (-XConstraintKinds):
>> >
>> > http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
>>
>> I'm trying to run the ConstraintKinds example from the documentation:
>>
>> {-# LANGUAGE ConstraintKinds, TypeFamilies #-}
>> type family Typ a b :: Constraint
>> type instance Typ Int b = Show b
>> type instance Typ Bool b = Num b
>>
>> But GHC complains:
>> Not in scope: type constructor or class `Constraint'
>>
>> Do I have to import some GHC module for this?
>
>
> Yes: GHC.Prim.
>
> (Which reminds me, Simon, we had agreed to re-export Constraint from
> GHC.Exts, but it wasn't clear to me how to do this, since Constraint is a
> kind, not a type, so it can't just go on the export list of the module...)
>
>
> Cheers,
> Pedro
>
>>
>>
>> Cheers,
>>
>> Bas
>>
>>
>> ___
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users@haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
Thanks Pedro, that works. I already read through the docs of GHC.Prim
but could not find it:
http://www.haskell.org/ghc/dist/stable/docs/html/libraries/ghc-prim-0.2.0.0/GHC-Prim.html
I guess haddock is not smart enough to understand kinds yet...
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 21 December 2011 19:29, Ian Lynagh wrote:
> * There is a new feature constraint kinds (-XConstraintKinds):
>
> http://www.haskell.org/ghc/dist/stable/docs/html/users_guide/constraint-kind.html
I'm trying to run the ConstraintKinds example from the documentation:
{-# LANGUAGE ConstraintKinds, TypeFamilies #-}
type family Typ a b :: Constraint
type instance Typ Int b = Show b
type instance Typ Bool b = Num b
But GHC complains:
Not in scope: type constructor or class `Constraint'
Do I have to import some GHC module for this?
Cheers,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.4.1 Release Candidate 1
On 21 December 2011 19:29, Ian Lynagh wrote: > Please test as much as possible; bugs are much cheaper if we find them > before the release! I'm trying to build bindings-levmar with the new GHC but get the errors as reported here: https://bitbucket.org/mauricio/bindings-dsl/issue/7/build-errors-with-ghc-741-rc1 Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC HEAD build error
On 7 December 2011 16:54, Ian Lynagh wrote: > This is probably caused by old header files in includes/. Updating to > the latest HEAD and making clean should fix it. I already performed a make clean so that doesn't fix it. Fortunately a make maintainer-clean does. Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC HEAD build error
Hello,
I'm trying to build GHC HEAD but get the following error:
"inplace/bin/ghc-stage1" -H64m -O0 -fasm -Iincludes -Irts
-Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i
-irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build
-Irts/dist/build/autogen-optc-O2 -c
rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o
rts/HeapStackCheck.cmm:159:305: parse error on input `('
The bug is in the GC_GENERIC macro on line 99:
Capability_interrupt(MyCapability()) != 0 :: CInt
However, I can't spot the problem.
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Why no multiple default method implementations?
On 24 November 2011 16:46, José Pedro Magalhães wrote:
> Hi Bas,
>
> On Thu, Nov 24, 2011 at 09:23, Bas van Dijk wrote:
>>
>> Hello,
>>
>> Now that we have DefaultSignatures, why is it not allowed to have
>> multiple default method implementations, as in:
>>
>> {-# LANGUAGE DefaultSignatures #-}
>>
>> class Foo a where
>> foo :: a
>> foo = error "foo"
>>
>> default foo :: Num a => a
>> foo = 1
>>
>> GHC complains: "Conflicting definitions for `foo'"
>>
>> The following use of multiple default signatures also gives the same
>> error:
>>
>> class Foo a where
>> foo :: a
>>
>> default foo :: Fractional a => a
>> foo = 0.5
>>
>> default foo :: Num a => a
>> foo = 1
>>
>> Couldn't GHC always pick the most specific default method, just as it
>> does with instances when OverlappingInstances is enabled?
>
> As far as I understand, GHC never looks at the context to decide which
> instance is
> applicable: http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/type-class-extensions.html#instance-overlap
> Your instances above are duplicates.
Right. The reason I asked is that I'm adding default generic
implementations for the 'arbitrary' and 'shrink' methods of the
Arbitrary type class of QuickCheck:
class Arbitrary a where
arbitrary :: Gen a
shrink :: a -> [a]
shrink _ = []
default arbitrary :: (Generic a, GArbitrary (Rep a)) => Gen a
arbitrary = fmap to gArbitrary
default shrink :: (Generic a, GArbitrary (Rep a)) => a -> [a]
shrink = map to . gShrink . from
However the normal default implementation of 'shrink' conflicts with
the generic default implementation. So I had to remove it and manually
add it to each of the instances that previously implicitly used the
default implementation.
This is not a big deal though.
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why no multiple default method implementations?
Hello,
Now that we have DefaultSignatures, why is it not allowed to have
multiple default method implementations, as in:
{-# LANGUAGE DefaultSignatures #-}
class Foo a where
foo :: a
foo = error "foo"
default foo :: Num a => a
foo = 1
GHC complains: "Conflicting definitions for `foo'"
The following use of multiple default signatures also gives the same error:
class Foo a where
foo :: a
default foo :: Fractional a => a
foo = 0.5
default foo :: Num a => a
foo = 1
Couldn't GHC always pick the most specific default method, just as it
does with instances when OverlappingInstances is enabled?
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.2.2
On 12 November 2011 00:18, Ian Lynagh wrote: > Looks fine to me. Perhaps you have a cached copy? You're right. Sorry for the noise. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 7.2.2
On 11 November 2011 22:03, Ian Lynagh wrote: > The GHC Team is pleased to announce a new bugfix release of GHC, 7.2.2. Yay! These GHC releases always feel like little presents... I noticed the links to modules in base in the latest docs point to the previous base library causing 404 errors: http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Cheers, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type error: Expected type: T. Actual type T ???
I reported this in the issue tracker: http://hackage.haskell.org/trac/ghc/ticket/5595 Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type error: Expected type: T. Actual type T ???
On 30 October 2011 02:29, wren ng thornton wrote: > ... Shouldn't the type of foo be: > > forall t m a > . (Monad m, MonadTransControl t) > => (Run t -> m a) > -> t m a > > ? Yes, that's the proper quantification. One more fact: when I change the associated type synonym to a associated data type the error disappears. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Type error: Expected type: T. Actual type T ???
Hello,
I'm working on a new design of monad-control[1]. However I get a type
error I don't understand. Here's an isolated example:
{-# LANGUAGE UnicodeSyntax, RankNTypes, TypeFamilies #-}
class MonadTransControl t where
type St t ∷ * → *
liftControl ∷ Monad m ⇒ (Run t → m α) → t m α
restore ∷ Monad o ⇒ St t γ → t o γ
type Run t = ∀ n β. Monad n ⇒ t n β → n (St t β)
foo :: (Monad m, MonadTransControl t) => (Run t -> m α) -> t m α
foo f = liftControl f
Type checking 'foo' this gives the following error:
Couldn't match expected type `Run t' with actual type `Run t'
Expected type: Run t -> m α
Actual type: Run t -> m α
In the first argument of `liftControl', namely `f'
In the expression: liftControl f
When I remove the type annotation of 'foo' the program type checks.
But when I ask ghci the type of 'foo' it tells me it's the same type:
> :t foo
foo :: (Monad m, MonadTransControl t) => (Run t -> m α) -> t m α
Is this a bug in GHC?
I'm using ghc-7.2.1.
Regards,
Bas
[1] http://hackage.haskell.org/package/monad-control
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC infinite loop when building vector program
Thanks Daniel for confirming this. I suspect this is caused by some rewrite rules in vector. So I reported it in their issue-tracker: http://trac.haskell.org/vector/ticket/63 Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC infinite loop when building vector program
On 11 October 2011 21:11, Bas van Dijk wrote: > Note that the program also builds fine when I change the 'f' and 'z' to: > > f = flip (:) > z = [] > Oops, I meant to say: Note that the program also builds fine when I change the 'f' and 'z' to: f = (+) z = 0 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC infinite loop when building vector program
Hello, When benchmarking my new vector-bytestring[1] package I discovered that building the following program causes GHC to go into, what seems to be, an infinite loop: import Data.Vector (Vector) import qualified Data.Vector.Generic as VG main = print $ VG.foldl f z (VG.fromList [] :: Vector Int) f = flip (:) z = [] I build it with: $ ghc --make vectorGHCloop.hs -O2 It compiles fine without the -O2 or if you specify -fno-enable-rewrite-rules. So it's probably a loop in a rule somewhere. Note that the program also builds fine when I change the 'f' and 'z' to: f = flip (:) z = [] I use vector-0.9 and ghc-7.2.1. Regards, Bas [1] https://github.com/basvandijk/vector-bytestring ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: REQ: add a non-closing version of handleToFd
On 6 October 2011 14:58, Simon Marlow wrote:
> ... What you can do is make a withHandleFD:
>
> withHandleFD :: Handle -> (FD -> IO a) -> IO a
>
> it's still quite dodgy, depending on what you do with the FD. Perhaps it
> should be called unsafeWithHandleFD.
>
> Anyway, patches gratefully accepted...
Maybe something like this together with a big warning message
explaining the danger:
{-# LANGUAGE NamedFieldPuns #-}
module System.Posix.IO where
import Control.Concurrent.MVar (MVar)
unsafeWithHandleFd :: Handle -> (Fd -> IO a) -> IO a
unsafeWithHandleFd h@(FileHandle _ m) f = unsafeWithHandleFd' h m f
unsafeWithHandleFd h@(DuplexHandle _ _ w) f = unsafeWithHandleFd' h w f
unsafeWithHandleFd' :: Handle -> MVar Handle__ -> (Fd -> IO a) -> IO a
unsafeWithHandleFd' h m f =
withHandle' "unsafeWithHandleFd" h m $ \h_@Handle__{haDevice} ->
case cast haDevice of
Nothing -> ioError (ioeSetErrorString (mkIOError IllegalOperation
"unsafeWithHandleFd"
(Just h) Nothing)
"handle is not a file descriptor")
Just fd -> do
x <- f (Fd (FD.fdFD fd))
return (h_, x)
I'm not sure about the DuplexHandle case. I mimicked handleToFd by
only converting the write side but I have no idea why that is correct.
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting the file descriptor from a handle, without closing it
On 1 October 2011 08:30, Volker Wysk wrote:
> 1.
>
> data FD = FD {
> fdFD :: {-# UNPACK #-} !CInt,
> fdIsNonBlocking :: {-# UNPACK #-} !Int
> }
>
> What is that exclamation mark?
That's a strictness annotation and is haskell98/2010:
http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-680004.2
And that "{-# UNPACK #-}"?
To quote:
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#unpack-pragma
"The UNPACK indicates to the compiler that it should unpack the
contents of a constructor field into the constructor itself, removing
a level of indirection"
> 2.
>
> handleToFd' :: Handle -> Handle__ -> IO (Handle__, Fd)
> handleToFd' h h_@Handle__{haType=_,..} = do
> case cast haDevice of
> -- ...
>
> haDevice should be a function. How could you cast it?
Note the .. in the record pattern. That is a language extension called
RecordWildCards. It replaces each elided field f by the pattern f = f:
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#record-wildcards
> 3.
>
> data Handle__
> = forall dev enc_state dec_state .
> (IODevice dev, BufferedIO dev, Typeable dev) =>
> Handle__ {
> -- ...
> }
> deriving Typeable
>
> What's that "forall" thing?
Handle__ is an existentially quantified data constructors:
http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type-extensions.html#existential-quantification
> 4.
>
> handleToFd' h h_@Handle__{haType=_,..} = do
> case cast haDevice of
> Nothing -> -- ...
> Just fd -> do
> -- ...
> return (Handle__{haType=ClosedHandle,..},
> Fd (fromIntegral (FD.fdFD fd)))
>
> What's this ".." inside "Handle__{haType=ClosedHandle,..}"?
See answer of 2
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Associativity of the generic representation of sum types
2011/9/22 Bas van Dijk : > I will make an official ticket for this. Done: http://hackage.haskell.org/trac/ghc/ticket/5499 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Associativity of the generic representation of sum types
2011/9/22 Bas van Dijk : > I just discovered the predicate: > > -- | Marks if this constructor is a record > conIsRecord :: t c (f :: * -> *) a -> Bool > > I think this can solve my problem. I think I have solved the bug now using conIsRecord. This is the new implementation: https://github.com/basvandijk/aeson/blob/newGenerics/Data/Aeson/Types/Internal.hs#L889 However, I would still very much like to have the information, whether a constructor is a record or not, statically available. This has two advantages: * More efficient: programs can make a static instead of a dynamic choice. * No more ugly undefined instances: because the information is not statically available I need to add several "undefined" instances like: instance GFromRecord (a :+: b) where gParseRecord = undefined instance GFromRecord U1 where gParseRecord = undefined instance GFromRecord (K1 i c) where gParseRecord = undefined instance GFromRecord (M1 i c f) where gParseRecord = undefined These instances will never be evaluated at runtime. They only exist to satisfy the type-checker. So I propose making the following changes to GHC.Generics: Add a phantom type to C that specifies whether it's a record or not using the (empty) datatypes: data Record data Product Maybe it's also nice to have the type synonyms: type R1 = M1 (C Record) type P1 = M1 (C Product) I will make an official ticket for this. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Associativity of the generic representation of sum types
2011/9/22 Bas van Dijk : > What would make all this much easier is if the meta-information of > constructors had a flag which indicated if it was a record or not. > Could this be added? I just discovered the predicate: -- | Marks if this constructor is a record conIsRecord :: t c (f :: * -> *) a -> Bool I think this can solve my problem. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Associativity of the generic representation of sum types
Hi José, I have another related question: (Excuse me for the big email, I had trouble making it smaller) I discovered a bug in my code that converts a product into a JSON value. I would like to convert products without field selectors into Arrays (type Array = Vector Value) and products with field selectors (records) into Objects (type Object = Map Text Value). Currently my code makes the wrong assumption that product types are build in a right associative way so that I can simply do this: - -- Products without field selectors: instance (GToJSON a, Flatten b) => GToJSON (S1 NoSelector a :*: b) where gToJSON = toJSON . flatten -- Other products, so products with field selectors (records): instance (GObject a, GObject b) => GToJSON (a :*: b) where gToJSON = Object . gObject - Note that flatten converts the product into a list of Values: - class Flatten f where flatten :: f a -> [Value] instance (GToJSON a, Flatten b) => Flatten (S1 NoSelector a :*: b) where flatten (m1 :*: r) = gToJSON m1 : flatten r instance (GToJSON a) => Flatten (S1 NoSelector a) where flatten m1 = [gToJSON $ unM1 m1] - and gObject convert the product into an Object: - class GObject f where gObject :: f a -> Object instance (GObject a, GObject b) => GObject (a :*: b) where gObject (a :*: b) = gObject a `M.union` gObject b instance (Selector s, GToJSON a) => GObject (S1 s a) where gObject = M.singleton (pack (selName m1)) (gToJSON (unM1 m1)) - The problem of course is that products have a tree-shape (as in: (a :*: b) :*: (c :*: d)) which causes the wrong instance to be selected. I tried to solve it in the following way: There's only one GToJSON instance for products: - instance (ToValue (ProdRes (a :*: b)), GProductToJSON a, GProductToJSON b) => GToJSON (a :*: b) where gToJSON = toValue . gProductToJSON - It uses the overloaded helper function gProductToJSON which converts a product into a ProdRes. A ProdRes is an associated type family which for products without field selectors equals a difference list of Values and for records equals an Object: - class GProductToJSON f where type ProdRes f :: * gProductToJSON :: f a -> ProdRes f instance GToJSON a => GProductToJSON (S1 NoSelector a) where type ProdRes (S1 NoSelector a) = DList Value gProductToJSON = singleton . gToJSON instance (Selector s, GToJSON a) => GProductToJSON (S1 s a) where type ProdRes (S1 s a) = Object gProductToJSON m1 = M.singleton (pack (selName m1)) (gToJSON (unM1 m1)) - The gProductToJSON for products recursively converts the left and right branches to a ProdRes and unifies them using 'union': - instance (GProductToJSON a, GProductToJSON b, ProdRes a ~ ProdRes b) => GProductToJSON (a :*: b) where type ProdRes (a :*: b) = ProdRes a -- or b gProductToJSON (a :*: b) = gProductToJSON a `union` gProductToJSON b class Union r where union :: r -> r -> r instance Union (DList Value) where union = append instance Union Object where union = M.union - Finally, the overloaded toValue turns the ProdRes into a JSON value. - class ToValue r where toValue :: r -> Value instance ToValue (DList Value) where toValue = toJSON . toList instance ToValue Objectwhere toValue = Object - Difference lists are simply: - type DList a = [a] -> [a] toList :: DList a -> [a] toList = ($ []) singleton :: a -> DList a singleton = (:) append :: DList a -> DList a -> DList a append = (.) - The problem with this code is that I get the following error: Conflicting family instance declarations: type ProdRes (S1 NoSelector a) type ProdRes (S1 s a) I was under the impression that GHC would be able to resolve this simply by choosing the most specific type (just as it does with type classes). Unfortunately it doesn't. So I'm a bit stuck now. How would you solve it? What would make all this much easier is
Re: Associativity of the generic representation of sum types
2011/9/22 José Pedro Magalhães : > Hi Bas, > > On Thu, Sep 22, 2011 at 03:55, Bas van Dijk wrote: >> >> Hello, >> >> I just used the new GHC generics together with the DefaultSignatures >> extension to provide a default generic implementation for toJSON and >> parseJSON in the aeson package: >> >> https://github.com/mailrank/aeson/pull/26 >> >> It appears that the generic representation of a sum type has a tree shape >> as in: >> >> (a :+: b) :+: (c :+: d) > > That is correct. > >> >> In my case this tree-shaped representation is problematic when parsing >> a JSON value to this type. My overloaded parsing function is >> parameterized with a key which specifies which of the a, b, c or d >> constructors to parse. When it encounters a constructor it checks if >> it matches the key, if so it is parsed, if not parsing will fail. >> Because of the tree-shaped representation of sum types I have to >> recursively parse the left and right branch and join them using <|>: >> >> >> https://github.com/basvandijk/aeson/blob/d5535817ceb192aa9d7d0d0b291e1901f3fbb899/Data/Aeson/Types/Internal.hs#L1003 >> >> I don't know for sure but I suspect that this can cause memory leaks >> since the <|> has to keep the right value in memory when it is parsing >> the left. > > It is not immediately clear to me why this would cause memory leaks... > >> >> Ideally the generic representation of sum types is right associative as >> in: >> >> a :+: (b :+: (c :+: d)) >> >> This way I only have to check if 'a' matches, if it does the right >> branch can be forgotten. >> >> Is there a good reason for not having it right associative? > > The reason is performance. In particular for large datatypes with many > constructors, a balanced sum-of-products performs better than a right-nested > one. Also, it makes things like writing generic space-efficient > encoders/decoders easier. > > But I would be very interested in understanding if/how the balanced view > leads to a space leak, so please let me know if you can provide some more > information. > > > Thanks, > Pedro > >> >> Regards, >> >> Bas >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > Hi José, After thinking about this some more, I don't think I need to worry about space leaks. The only worry I have is that in the following code: class GFromSum f where gParseSum :: Pair -> Parser (f a) instance (GFromSum a, GFromSum b) => GFromSum (a :+: b) where gParseSum keyVal = fmap L1 (gParseSum keyVal) <|> fmap R1 (gParseSum keyVal) instance (Constructor c, GFromJSON a) => GFromSum (C1 c a) where gParseSum (key, value) | key == pack (conName (undefined :: t c a p)) = gParseJSON value | otherwise = notFound $ unpack key notFound :: String -> Parser a notFound key = fail $ "The key \"" ++ key ++ "\" was not found" when gParseSum determines that the key equals the name of the constructor, it is going to parse the value. However what happens when the parsing of the value fails? Ideally it would immediately terminate. However because of the <|> it will try all other branches. This is unnecessary computation. Fortunately parsing those other branches will immediately fail because non will have a constructor that equals the key. So maybe I'm just worrying to much :-) Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Associativity of the generic representation of sum types
Hello, I just used the new GHC generics together with the DefaultSignatures extension to provide a default generic implementation for toJSON and parseJSON in the aeson package: https://github.com/mailrank/aeson/pull/26 It appears that the generic representation of a sum type has a tree shape as in: (a :+: b) :+: (c :+: d) In my case this tree-shaped representation is problematic when parsing a JSON value to this type. My overloaded parsing function is parameterized with a key which specifies which of the a, b, c or d constructors to parse. When it encounters a constructor it checks if it matches the key, if so it is parsed, if not parsing will fail. Because of the tree-shaped representation of sum types I have to recursively parse the left and right branch and join them using <|>: https://github.com/basvandijk/aeson/blob/d5535817ceb192aa9d7d0d0b291e1901f3fbb899/Data/Aeson/Types/Internal.hs#L1003 I don't know for sure but I suspect that this can cause memory leaks since the <|> has to keep the right value in memory when it is parsing the left. Ideally the generic representation of sum types is right associative as in: a :+: (b :+: (c :+: d)) This way I only have to check if 'a' matches, if it does the right branch can be forgotten. Is there a good reason for not having it right associative? Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to synchronously shutdown the event manager loop
On 31 August 2011 01:11, Bas van Dijk wrote: > So it seems like a bug in GHC. I will create a ticket in the morning. Ticket created: http://hackage.haskell.org/trac/ghc/ticket/5443 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to synchronously shutdown the event manager loop
On 31 August 2011 00:15, Bas van Dijk wrote: > I see what I can do. I'm first going to export the 'finished' function > from GHC.Event and use that to wait till the loop finishes and see if > that solves my problem. Waiting till the loop finishes doesn't solve the problem. Here's an isolated program with the same problem that doesn't use the usb library: import Control.Concurrent import GHC.Event main = do em <- new forkIO $ loop em threadDelay 200 shutdown em threadDelay 200 When executed it prints: example: ioManagerWakeup: write: Bad file descriptor example: ioManagerDie: write: Bad file descriptor So it seems like a bug in GHC. I will create a ticket in the morning. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to synchronously shutdown the event manager loop
On 30 August 2011 17:39, Bryan O'Sullivan wrote: > On Tue, Aug 30, 2011 at 6:49 AM, Bas van Dijk wrote: >> >> As you see I also kill the thread which is running the event manager >> loop. However I think this is not the right way to do it because when >> I use the library I see the following message being continually >> printed after the `Ctx` is finalized: >> >> ghc: ioManagerWakeup: write: Bad file descriptor > > I'm afraid we don't provide a way to shut down an event manager > synchronously at the moment. You'll have to submit a patch if you want to > add that capability. I see what I can do. I'm first going to export the 'finished' function from GHC.Event and use that to wait till the loop finishes and see if that solves my problem. BTW to reproduce the problem (if you're interested) you can use the following program: (make sure to use the latest usb sources from git) import System.USB (newCtx) import Control.Concurrent (threadDelay) import System.Mem (performGC) main :: IO () main = do _ <- newCtx threadDelay 200 performGC threadDelay 200 running this yields: example: ioManagerWakeup: write: Bad file descriptor example: ioManagerDie: write: Bad file descriptor > Perhaps you could add a way to specify an "onShutdown > :: IO ()" hook that would be called by the event manager thread once it > shuts down. That's a possibility. BTW is there a reason 'shutdown' needs to be asynchronous or was it just easier to implement it this way? Otherwise I think a synchronous 'shutdown' is easier to work with. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc fails to build due to trust issues
On 30 August 2011 23:57, austin seipp wrote: > 7.2.1 shipped without explicitly trusting the `base' package (an > accident, IIRC.) You can fix this and resume your build by saying: > > $ ghc-pkg-7.2.1 trust base > > and everything should be OK. Thanks that works! Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc fails to build due to trust issues
Hello, I'm trying to build recent ghc-HEAD using ghc-7.2.1 but get the following error: libraries/filepath/System/FilePath/Internal.hs:81:1: base:Data.List can't be safely imported! The package (base) the module resides in isn't trusted. I guess a "-trust base" flag has to be passed to ghc somewhere. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to synchronously shutdown the event manager loop
Hello, In my (still unreleased) usb-1.0 (https://github.com/basvandijk/usb) library I use the GHC event manager for managing events from the underlying `libusb` C library. To work with the library a user has to initialize it using: newCtx ∷ IO Ctx The `Ctx` then allows the user to see the USB devices attached to the system using: getDevices ∷ Ctx → IO [Device] From thereon a user can open devices using: openDevice ∷ Device → IO DeviceHandle and perform IO with them: readBulk ∷ DeviceHandle → EndpointAddress → Size → Timeout → IO (B.ByteString, Status) Internally the synchronous `readBulk` is implemented using asynchronous IO: first a request to read bytes from a USB device is asynchronously submitted. Then it waits on a lock (`takeMVar lock`). When the bytes are read an event is fired on a certain file descriptor. The GHC event manager then wakes up and calls a callback which will release the lock (`putMVar lock ()`). I choose to have one event loop per session (`Ctx`) with the usb library. This means that I make a new `EventManager` in `newCtx`: evtMgr ← EventManager.new register the `libusb` file descriptors with the event manager and fork a thread which will `loop` the `EventManager`: tid <- forkIOWithUnmask $ \unmask → unmask $ EventManager.loop evtMgr The underlying `libusb` C library needs to be deinitialized when you're done with it. However for safety and ease of use a user of my Haskell library doesn't need to explicitly deinitialize the library. Instead this happens automatically when the garbage collector collects an unreferenced `Ctx` by registering (using `Foreign.Concurrent.newForeignPtr`) the following finalizer with the `Ctx` foreign pointer: -- Stop the event handling loop by killing its thread: killThread tid ... -- Finally deinitialize libusb: c'libusb_exit ctxPtr As you see I also kill the thread which is running the event manager loop. However I think this is not the right way to do it because when I use the library I see the following message being continually printed after the `Ctx` is finalized: ghc: ioManagerWakeup: write: Bad file descriptor Note that when I remove the `killThread tid` the messages disappear. It seems that killing the event manager loop is not allowed. Is there another way of shutting down the event manager loop? I know I can shut it down by using the `shutdown` function. However this function is asynchronous. This won't work because I need to make sure the event loop is shutdown before I exit the `libusb` library (because that will close the file descriptors that the event loop is working with). I see the event manager provides the `finished` function which will poll the manager to see if it stopped looping. This function is not exported however. Is it possible to export this function? It would be even nicer to have a synchronous shutdown function so that I don't need to setup a loop that waits till the manager has been shut down. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
On 29 August 2011 11:11, Aleksey Khudyakov wrote:
>> "Option 3 avoids that problem but risks perplexity: if I make use of
>> some cool package which introduces some Foo :: * -> *, I might notice
>> that Foo is a monad and add a Monad Foo instance in my own code,
>> expecting the Applicative Foo instance to be generated in concert; to
>> my horror, I find my code has subtle bugs because the package
>> introduced a different, non-monadic, Applicative Foo instance which
>> I'm accidentally using instead."
>>
>> talks about "subtle bugs". Could you give an example of such a bug?
>>
>> I would expect that the non-monadic Applicative Foo instance is always
>> somehow "compatible" with the monadic one. However I don't have a
>> clear definition of "compatible" yet...
>>
> I think it's something like that. Module Foo defines list and make
> ZipList-like Applicative instance. Would you add standard list monad
> you have a bug.
>
> But if you add monad instance which is not compatible with existing
> applicative you have bug whether you use extension or not.
>
> module Foo where
> data [a] = a : [a] | []
>
> instance Functor [] where
> fmap = map
> instamce Applicative [] where
> pure = repeat
> (<*>) = zipWith ($)
>
> module Main where
> instance Monad [] where
> return x = [x]
> (>>=) = concatMap
>
Indeed. So in other words your saying that if a programmer uses a
module which defines a stream-like list type like for example:
newtype StreamList a = SL { toList :: [a] }
instance Functor StreamList where
fmap f (SL xs) = SL (map f xs)
instance Applicative StreamList where
pure x = SL $ repeat x
SL fs <*> SL xs = SL $ zipWith ($) fs xs
And she decides to add a monad instance like the regular list monad:
instance Monad StreamList where
return x = SL [x]
xs >>= f = SL $ concatMap (toList . f) $ toList xs
That would be a mistake on her part since 'ap' would not be equivalent to '<*>'.
The correct monad instance should be something like:
instance Monad StreamList where
return = pure
xs >>= f = SL $ join $ fmap (toList . f) $ toList xs
where
join :: [[a]] -> [a]
join [] = []
join ([]:xss) = join (map tail xss)
join ((x:xs):xss) = x : join (map tail xss)
where 'ap' does equal '<*>' (not tested nor proofed yet though).
I think a good definition of "compatible" would be that forall mf mx.
ap mf mx = mf <*> mx.
So I would still like to see an example where a user defined,
non-monadic '<*>' causes bugs because it's not compatible to the
intrinsic one.
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass defaults
On 22 August 2011 10:10, Simon Peyton-Jones wrote: > | > I don't completely understant how does it work. Does client need to enable > | > language extension to get default instances? > | > | I think that the extension would only be required to *define them*, > | not for them to be generated. The more conservative choice would > | indeed be to require the extension for both, though. > > Yes. I've clarified > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances to say > this. > > | > Also proposal cannot fix Functor/Applicative/Monad problem without > breaking > | > client code. It requires explicit opt-out but client may define > Applicative > | > instance. And unless "hiding" is added it will result in compile error. > | > | I think the intention (at least as I understand it) is that a > | superclass default is only used to generate an instance if there is > | not already some suitable instance in scope, just like a default > | method is only used if there is not some explicit definition for the > | method in the instance. > > Actually that is not what Conor and I proposed. See > http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances. Under > "Variations" we discuss the "silent-opt-out" choice. But it's bad enough > knowing exactly what instances are in scope (given that they are not named), > let alone having that control what further instances are or are not > generated! For superclass defaults there is no such ambiguity. > > Simon > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > Won't option 1 "Reject this as a duplicate instance declaration, which indeed it is." conflict with design goal 1: "a class C can be re-factored into a class C with a superclass S, without disturbing any clients"? Take the transformers package for example. It defines lot's of instances of Functor and Applicative for its monad transformers. Doesn't transformers have to be changed if we go for option 1 (by either dropping the Functor and Applicative instances or listing hiding clauses in the Monad instances) thereby seriously conflicting with the design goal of not disturbing any clients. I expected the semantics to be like option 3: "Allow the explicit to supersede the intrinsic default silently". It has the advantage of: 1) Not disturbing any client code. 2) Giving the ability to define optimized implementations if you're not happy with the default ones (without using the hiding mechanism). 3) Feeling very much like the semantics of default methods thereby conforming to the rule of least surprise. The argument against option 3, which I quote: "Option 3 avoids that problem but risks perplexity: if I make use of some cool package which introduces some Foo :: * -> *, I might notice that Foo is a monad and add a Monad Foo instance in my own code, expecting the Applicative Foo instance to be generated in concert; to my horror, I find my code has subtle bugs because the package introduced a different, non-monadic, Applicative Foo instance which I'm accidentally using instead." talks about "subtle bugs". Could you give an example of such a bug? I would expect that the non-monadic Applicative Foo instance is always somehow "compatible" with the monadic one. However I don't have a clear definition of "compatible" yet... Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Build failure of syb-with-class with ghc-7.2.1
On 9 August 2011 15:15, Sergei Trofimovich wrote: >> the HEAD of syb-with-class fails with the following error when build >> with ghc-7.2.1 and template-haskell-2.6: >> >> http://code.google.com/p/syb-with-class/issues/detail?id=4 >> >> Is this a bug in TH? > > Very likely: > http://hackage.haskell.org/trac/ghc/ticket/5362 Thanks. The error is different but at the same location. I filed a new ticket for this: http://hackage.haskell.org/trac/ghc/ticket/5398 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Build failure of syb-with-class with ghc-7.2.1
Hello, the HEAD of syb-with-class fails with the following error when build with ghc-7.2.1 and template-haskell-2.6: http://code.google.com/p/syb-with-class/issues/detail?id=4 Is this a bug in TH? Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On 20 June 2011 11:54, John Lato wrote: > Is it easy to check, out of those 344, how many would build if the > dependency on haskell98 were removed? You could write a script that will download them all, remove the haskell98 dep. and cabal build the package. > (Bas, your link doesn't work for me BTW, can't resolve the IP. May be my > uni's dns cache.) It seems my dyndns account is removed! You can still access our server via its IP number: http://81.26.216.99/~roel/hackage/packages/hackage.html Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On 17 June 2011 16:47, Simon Peyton-Jones wrote: > So: Under Plan A, some Hackage packages will become un-compilable, > and will require source code changes to fix them. I do not have > any idea how many Hackage packages would fail in this way. Of the 372 direct reverse dependencies of haskell98: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/haskell98-1.1.0.1#direct there are 344 which also depend on base (See http://hpaste.org/47933 for calculating the intersection). Am I correct that a package which depends on both base and haskell98 will always fail to build when the Prelude is also exported from haskell98? (Unless of course the package uses the PackageImports extension) I don't know how many of these 344 packages use PackageImports or have upper bounds on their haskell98 dependency (I guess not many). So I guess many of these 344 will break. Still I'm in favour of plan A since it's simple and discourages mixing haskell98 with more modern modules. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Are FFI calls interruptible?
On 24 April 2011 18:58, Edward Z. Yang wrote: > Well, that will result in a race where, if the foreign call gets interrupted, > the asynchronous exception will get queued up and fire immediately once > the FFI call completes, Well the whole block of code is under a mask_ so if FFI calls are not interruptible the queued up exceptions should not be fired. I did a quick test that throwed 1000 exceptions to a thread executing that piece of code but with the uninterruptibleMask_ only around the 'acquire lock'. As expected only the first one got through. > thus enabling libusb_cancel_transfer to be called > but not acquire lock to be called. Is that the desired semantics? No, the desired semantics are that after calling the asynchronous libusb_cancel_transfer, we must wait for the transfer to terminate. Although it's correct to put the uninterruptibleMask_ only around the 'acquire lock' I think I leave it as it is. If for some reason the interruptibility of FFI calls changes in the future I will be safe. Better be safe than sorry. Edward, thanks for your insights. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Are FFI calls interruptible?
On 24 April 2011 10:26, Edward Z. Yang wrote: > No, you have to use the 'interruptible' keyword. Good, I need them to be uninterruptible. So I guess I can apply uninterruptibleMask_ only to the 'acquire lock' in the following code from my usb library: https://github.com/basvandijk/usb/blob/async/System/USB/Internal.hs#L1593 Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Are FFI calls interruptible?
Hello, Quick question: are safe/unsafe FFI calls interruptible? Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: C-- source highlighting using source-highlight
On 14 April 2011 17:04, Johan Tibell wrote: > I've thrown together a small source-highlight language file for C--. > You can use it to e.g. highlight C-- code when piped through less. Nice! It would also be nice to have highlighted C-- output in ghc-core[1] too! Bas [1] http://hackage.haskell.org/package/ghc-core ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fix context reduction stack overflow in dimensional
On 29 March 2011 14:12, Bjorn Buckwalter wrote: > On Tue, Mar 29, 2011 at 15:46, Bas van Dijk wrote: >> >> Attached is a patch that fixes a context reduction stack overflow in >> your dimensional package. > > Thanks Bas, was the build failure on GHC 7.0.3? I don't believe this > problem occurred on 7.0.1 and 7.0.2 although I'm not sure about the > latter. I'm a little behind on GHC versions myself, waiting for 7.0.3 > to get in the HP. Yes, I'm using GHC-7.0.3 >> I noticed something weird though (that's why I'm CCing the ghc list). >> When I cabal build dimensional-0.8.2 I first get the context reduction >> stack overflow when I then build it again I get the error again (as >> expected). However when I try to build it for the third time it >> succeeds! Why is this? >> >> I attached the build log. > > It looks like the first two times it build all seven modules, failing > on CGS, while the last time it decides to build only CGS. Strange > indeed. > > Anyway, I'll upload a patched dimensional to Hackage right now. But > I'll need to figure out how to get my ssh key on code.haskell.org > before I can push the patch to the repo... Just mail your public key to supp...@community.haskell.org. Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fix context reduction stack overflow in dimensional
Dear Bjorn, Attached is a patch that fixes a context reduction stack overflow in your dimensional package. I noticed something weird though (that's why I'm CCing the ghc list). When I cabal build dimensional-0.8.2 I first get the context reduction stack overflow when I then build it again I get the error again (as expected). However when I try to build it for the third time it succeeds! Why is this? I attached the build log. Regards, Bas fix-context-reduction-stack-overflow.dpatch Description: Binary data bas@pcbas:~/Downloads/dimensional$ cabal clean cleaning... bas@pcbas:~/Downloads/dimensional$ cabal configure Resolving dependencies... Configuring dimensional-0.8.2... bas@pcbas:~/Downloads/dimensional$ cabal build Preprocessing library dimensional-0.8.2... Building dimensional-0.8.2... [1 of 7] Compiling Numeric.Units.Dimensional ( Numeric/Units/Dimensional.lhs, dist/build/Numeric/Units/Dimensional.o ) [2 of 7] Compiling Numeric.Units.Dimensional.Quantities ( Numeric/Units/Dimensional/Quantities.lhs, dist/build/Numeric/Units/Dimensional/Quantities.o ) [3 of 7] Compiling Numeric.Units.Dimensional.SIUnits ( Numeric/Units/Dimensional/SIUnits.lhs, dist/build/Numeric/Units/Dimensional/SIUnits.o ) [4 of 7] Compiling Numeric.Units.Dimensional.Prelude ( Numeric/Units/Dimensional/Prelude.hs, dist/build/Numeric/Units/Dimensional/Prelude.o ) [5 of 7] Compiling Numeric.Units.Dimensional.NonSI ( Numeric/Units/Dimensional/NonSI.lhs, dist/build/Numeric/Units/Dimensional/NonSI.o ) [6 of 7] Compiling Numeric.Units.Dimensional.Extensible ( Numeric/Units/Dimensional/Extensible.lhs, dist/build/Numeric/Units/Dimensional/Extensible.o ) [7 of 7] Compiling Numeric.Units.Dimensional.CGS ( Numeric/Units/Dimensional/CGS.lhs, dist/build/Numeric/Units/Dimensional/CGS.o ) Numeric/Units/Dimensional/CGS.lhs:304:11: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dSucc :: N.Succ t'0 (N.Pos Zero) co :: a' ~ N.Pos Zero $dSucc :: N.Succ a' (N.Pos (N.Pos Zero)) co :: a'1 ~ N.Pos (N.Pos Zero) $dSucc :: N.Succ a'1 (N.Pos (N.Pos (N.Pos Zero))) co :: a'2 ~ N.Pos (N.Pos (N.Pos Zero)) $dSucc :: N.Succ a'2 (N.Pos Pos3) co :: a'3 ~ N.Pos Pos3 $dSub :: Numeric.NumType.Sub a'3 Zero (N.Pos Pos3) co :: a1 ~ Zero $dNegate :: N.Negate a1 Zero co :: n'' ~ Zero $dDiv :: N.Div n'' (N.Pos (N.Pos Zero)) Zero co :: a ~ Zero $dNegate :: N.Negate a Zero $dNegate :: N.Negate (N.Pos a) (N.Neg Zero) $dNegate :: N.Negate p'' (N.Neg Zero) $dNegate :: N.Negate (N.Pos p'') (N.Neg (N.Neg Zero)) $dDiv :: N.Div (N.Neg n) (N.Pos (N.Pos Zero)) (N.Neg Neg1) $dDiv :: N.Div it0 (N.Pos (N.Pos Zero)) (N.Neg Neg1) $dMul :: N.Mul Neg2 Pos2 it0 In the expression: fromSI c In an equation for `c_cgs': c_cgs = fromSI c Numeric/Units/Dimensional/CGS.lhs:305:11: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dSucc :: N.Succ c (N.Pos Zero) co :: a' ~ N.Pos Zero $dSucc :: N.Succ a' (N.Pos Pos1) co :: a'1 ~ N.Pos Pos1 $dSucc :: N.Succ a'1 (N.Pos Pos2) co :: a'2 ~ N.Pos Pos2 $dSucc :: N.Succ a'2 (N.Pos Pos3) co :: a'3 ~ N.Pos Pos3 $dSub :: Numeric.NumType.Sub a'3 Zero (N.Pos Pos3) co :: a1 ~ Zero $dNegate :: N.Negate a1 Zero co :: n'' ~ Zero $dDiv :: N.Div n'' (N.Pos (N.Pos Zero)) Zero co :: a ~ Zero $dNegate :: N.Negate a Zero $dNegate :: N.Negate (N.Pos a) (N.Neg Zero) $dNegate :: N.Negate p'' (N.Neg Zero) $dNegate :: N.Negate (N.Pos p'') (N.Neg (N.Neg Zero)) $dDiv :: N.Div (N.Neg n) (N.Pos (N.Pos Zero)) (N.Neg Neg1) $dDiv :: N.Div it0 (N.Pos (N.Pos Zero)) (N.Neg Neg1) $dMul :: N.Mul Neg2 Pos2 it0 In the expression: toSI c_cgs :: Capacitance Double In an equation for `c'': c' = toSI c_cgs :: Capacitance Double bas@pcbas:~/Downloads/dimensional$ cabal build Preprocessing library dimensional-0.8.2... Building dimensional-0.8.2... [7 of 7] Compiling Numeric.Units.Dimensional.CGS ( Numeric/Units/Dimensional/CGS.lhs, dist/build/Numeric/Units/Dimensional/CGS.o ) [1 of 7] Compiling Numeric.Units.Dimensional ( Numeric/Units/Dimensional.lhs, dist/build/Numeric/Units/Dimensional.p_o ) [2 of 7] Compiling Numeric.Units.Dimensional.Quantities ( Numeric/Units/Dimensional/Quantities.lhs, dist/build/Numeric/Units/Dimensional/Quantities.p_o ) [3 of 7] Compiling Numeric.Units.Dimensional.SIUnits ( Numeric/Units/Dimensional/SIUnits.lhs, dist/build/Numeric/Units/Dimensional/SIUnits.p_o ) [4 of 7] Compiling Numeric.Units.Dimensional.Prelude ( Numeric/Units/Dimensional/Prelude.hs, dist/build/Numeric/Units/Dimensional/Prelude.p_o ) [5 of 7] Compiling Numeric.Units.Dimensional.NonSI ( Numeric/Units/Dimensional/NonSI.lhs, dist/build/Numeric/Units/Dimensional/NonSI.p_o ) [6 of 7] Compiling Numeric.Units.Dimensional.Extensible ( Nume
Re: 7.0.3
On 15 March 2011 18:04, Ian Lynagh wrote: > We want to keep the changes in this release to a minimum, to minimise > the chance of regressions, but if you think we've missed any critical > issues please let us know. Absolutely not critical but it would be nice if you could merge my patch in: http://hackage.haskell.org/trac/ghc/ticket/5006 Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2
On 21 February 2011 13:50, Ian Lynagh wrote: > Can you file a ticket... Done: http://hackage.haskell.org/trac/ghc/ticket/4974 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 2
On 20 February 2011 22:16, Ian Lynagh wrote: > We are pleased to announce the second release candidate for GHC 7.0.2 Congratulations! I may have found a bug (not sure if it's in ghc or cabal): $ cabal install unix-compat Resolving dependencies... Configuring unix-compat-0.2.1.1... cabal: Missing dependency on a foreign library: * Missing header file: HsUnixCompat.h HsUnixCompat.h is required by the cabal file: $ cat unix-compat.cabal | grep include include-dirs: include includes: HsUnixCompat.h install-includes: HsUnixCompat.h ...and is included in the package's include directory: $ ls include/ HsUnixCompat.h Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Some patches for GHC
On Fri, Dec 31, 2010 at 8:04 PM, Ian Lynagh wrote: > On Wed, Dec 22, 2010 at 02:02:18PM +0100, Bas van Dijk wrote: >> >> I was just wondering if somebody could review (and hopefully apply) >> some of or all the patches in: >> >> http://hackage.haskell.org/trac/ghc/attachment/ticket/4834/ghc_new_monad_hierarchy.dpatch >> >> Note that these patches are independent of the newly proposed monad >> hierarchy. > > I'm lost. #4834 claims to be a proposal with a deadline of 1 Feb 2011. > If these patches are unrelated, can you make a separate ticket for them > please? No problem: http://hackage.haskell.org/trac/ghc/ticket/4881 Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 1
On Thu, Dec 16, 2010 at 7:36 PM, Ian Lynagh wrote: > > We are pleased to announce the first release candidate for GHC 7.0.2: > > http://www.haskell.org/ghc/dist/7.0.2-rc1/ > > This includes the source tarball, installers for OS X and Windows, and > bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > I just noticed I get the following error when I run 'cabal haddock' in one of my projects (configured with ghc-7.0.1.20101215): haddock: could not execute: /home/ian/local/bin/gcc Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Some patches for GHC
Hello, I was just wondering if somebody could review (and hopefully apply) some of or all the patches in: http://hackage.haskell.org/trac/ghc/attachment/ticket/4834/ghc_new_monad_hierarchy.dpatch Note that these patches are independent of the newly proposed monad hierarchy. Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 1
On Fri, Dec 17, 2010 at 7:58 PM, Ian Lynagh wrote: > Can you tell me what these commands say, please?: Oops! The i386 version works so I guess I mistakenly assumed I was on a 64bit system. Sorry for the noise. In case you still want to know: > uname -a Linux hfd 2.6.35-22-generic-pae #35-Ubuntu SMP Sat Oct 16 22:16:51 UTC 2010 i686 GNU/Linux > file utils/ghc-pwd/dist/build/tmp/ghc-pwd utils/ghc-pwd/dist/build/tmp/ghc-pwd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped > ldd utils/ghc-pwd/dist/build/tmp/ghc-pwd not a dynamic executable > utils/ghc-pwd/dist/build/tmp/ghc-pwd -bash: utils/ghc-pwd/dist/build/tmp/ghc-pwd: cannot execute binary file $ cat /proc/cpuinfo | grep "model name" model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.2 Release Candidate 1
On Thu, Dec 16, 2010 at 7:36 PM, Ian Lynagh wrote: > > We are pleased to announce the first release candidate for GHC 7.0.2: > > http://www.haskell.org/ghc/dist/7.0.2-rc1/ > > This includes the source tarball, installers for OS X and Windows, and > bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > > Thanks > Ian, on behalf of the GHC team > > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > I get the following error while configuring: b...@hfd:~/download$ wget http://www.haskell.org/ghc/dist/7.0.2-rc1/ghc-7.0.1.20101215-x86_64-unknown-linux.tar.bz2 ... b...@hfd:~/download$ tar -xf ghc-7.0.1.20101215-x86_64-unknown-linux.tar.bz2 b...@hfd:~/download$ cd ghc-7.0.1.20101215/ b...@hfd:~/download/ghc-7.0.1.20101215$ ./configure --prefix=$HOME/ghcs/ghc-7.0.1.20101215 checking for path to top of build tree... ./configure: line 1686: utils/ghc-pwd/dist/build/tmp/ghc-pwd: cannot execute binary file configure: error: cannot determine current directory Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Functor => Applicative => Monad
On Sun, Dec 12, 2010 at 12:48 PM, John Smith wrote: > There's a ticket at http://trac.haskell.org/haskell-platform/ticket/155, Thanks! But why create a ticket for the Haskell Platform? This is a change in the base library so we should follow the library submission process[1] and create[2] a ticket in the ghc trac. Regards, Bas [1] http://www.haskell.org/haskellwiki/Library_submissions [2] http://hackage.haskell.org/trac/ghc/newticket?type=proposal&component=libraries/base&milestone=Not+GHC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Functor => Applicative => Monad
On Wed, Dec 1, 2010 at 10:02 AM, John Smith wrote: > Regarding recent concerns as to whether Pointed is actually useful (and if > it is, is that Pointed Functors or pure Pointed?), how about a slightly more > modest reform? > > class Functor f where > map :: (a -> b) -> f a -> f b > > class Functor f => Applicative f where > pure :: a -> f a > (<*>) :: f (a -> b) -> f a -> f b > (*>) :: f a -> f b -> f b > (<*) :: f a -> f b -> f a > > class Applicative m => Monad m where > (>>=) :: m a -> (a -> m b) -> m b > f >>= x = join $ map f x > > join :: m (m a) -> m a > join x = x >>= id > > (unrelated, but also valid) > > instance MonadPlus m => Monoid (m a) where > mempty = mzero > mappend = mplus > > > module Legacy where > > fmap :: Functor f => (a -> b) -> f a -> f b > fmap = map > > liftA :: Applicative f => (a -> b) -> f a -> f b > liftA = map > > liftM :: Monad m => (a -> b) -> m a -> m b > liftM = map > > ap :: Monad m => m (a -> b) -> m a -> m b > ap = (<*>) > > (>>) :: Monad m => m a -> m b -> m b > (>>) = (*>) > > concat :: [[a]] -> [a] > concat = join > > etc. > > And for those who really want a list map, > > listMap :: (a -> b) -> [a] -> [b] > listMap = map > Linked are some patch bundles that provide an initial implementation of the new hierarchy: * http://code.haskell.org/~basvandijk/ghc_new_monad_hierarchy.dpatch This patch bundle is to prepare ghc for the new hierarchy. Most importantly it adds Functor and Applicative instances for all monads in ghc. Note that these patches are useful on their own and don't depend on the new hierarchy so they can be applied even when this proposal is not accepted. * http://code.haskell.org/~basvandijk/base_new_monad_hierarchy.dpatch This patch actually implements the new hierarchy. I tried to be even more conservative than the current proposal, namely 'return' and '>>' are still methods of Monad but have now been given default implementations in terms of Applicative. Also all names have been kept intact (fmap is still named fmap): class Functor f where fmap :: (a -> b) -> f a -> f b (<$) :: a -> f b -> f a (<$) = fmap . const class Functor f => Applicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b (*>) :: f a -> f b -> f b a *> b = fmap (const id) a <*> b (<*) :: f a -> f b -> f a a <* b = fmap const a <*> b class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b m >>= f = join $ fmap f m join :: m (m a) -> m a join m = m >>= id (>>) :: m a -> m b -> m b (>>) = (*>) return :: a -> m a return = pure fail :: String -> m a fail s = error s Also see the generated library documentation: http://bifunctor.homelinux.net/~bas/doc/ghc/html/libraries/base-4.4.0.0/ Note that I am in favour of removing 'return', '>>' and 'fail' from Monad and renaming 'fmap' to 'map'. But I think it's better to do this as a separate patch. Besides patching the base library and ghc, I also needed to patch lots of other libraries in my ghc root. To get these patches, simply pull from my local ghc repository. i.e.: darcs pull http://bifunctor.homelinux.net/~bas/ghc/ darcs pull http://bifunctor.homelinux.net/~bas/ghc/libraries/base Note that ghc requires the happy parser generator. When happy generates a parser it also generates a HappyIdentity type with an according Monad instance. The following patch makes happy also generate the needed Functor and Applicative instances (This patch is already send to happy's maintainer): http://bifunctor.homelinux.net/~bas/functor_and_applicative_instance_HappyIdentity.dpatch Feel free to ask questions or post comments about these patches. Regards, Bas P.S. John, did you already make a ticket for this proposal? I would like to attach my patches to it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
On Wed, Nov 10, 2010 at 2:39 PM, Mitar wrote: >> Strange. It would help if you could show more of of your code. > > I am attaching a sample program which shows this. I am using 6.12.3 on > both Linux and Mac OS X. And I run this program with runhaskell > Test.hs. Without "throwIO ThreadKilled" it outputs: > > Test.hs: MyTerminateException > MVar was successfully taken > > With "throwIO ThreadKilled" is as expected, just: > > MVar was successfully taken > > So MVar is filled. What means that thread gets exception after that. > But there is nothing after that. ;-) (At least nothing visible.) This is really interesting. Presumably what happens is that an exception is indeed thrown and then raised in the thread after the final action. Now if you synchronously throw an exception at the end it looks like it's raised before the asynchronous exception is raised. Hopefully one of the GHC devs (probably Simon Marlow) can confirm this behavior and shed some more light on it. Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
On Wed, Nov 10, 2010 at 10:50 AM, Mitar wrote: > Hi! > On Wed, Nov 10, 2010 at 8:54 AM, Bas van Dijk wrote: >> A ThreadKilled exception is not printed to stderr because it's not >> really an error and should not be reported as such. > > So, how to make custom exceptions which are "not really an error"? I would say that any exception which isn't handled must be considered an error, any exception which is handled is just an exceptional situation. For example if your application does not handle DivideByZero than it's an error if one is thrown. However, your application does handle MyTerminateException, so when one is thrown it will just be an exceptional situation that your application can handle. >> What do you mean by "hanging there". Are they blocked on an MVar? > > I have something like this: > > terminated <- newEmptyMVar > forkIO $ doSomething `catches` [ > Handler (\(_ :: MyTerminateException) -> return > ()), -- we just terminate, that is the idea at least > Handler (...) -- handle other exceptions > ] `finally` (putMVar terminated ()) > takeMVar terminated > > The problem is, that if I send multiple MyTerminateException > exceptions to the thread one of them is printed (or maybe even more, I > do not know, because I have many threads). My explanation is that > after the first one is handled and MVar is written, thread stays > "active", just no computation is evaluating. Because of that another > exception can be thrown at the thread. And then it is not handled > anymore and so the library prints the exception and exits the thread. First of all, are you sure you're using a unique MVar for each thread? If not, there could be the danger of deadlock. Secondly, it could just be the case that when you throw your first MyTerminateException it is catched by your handler which will then just return as expected. Finally the 'putMVar terminated ()' computation is performed. Now when you throw your second MyTerminateException during the execution of this computation, there's no handler any more to catch it so it will be reported. Finally, your code has dangerous deadlock potential: Because you don't mask asynchronous exceptions before you fork it could be the case that an asynchronous exception is thrown to the thread before your exception handler is registered. This will cause the thread to abort without running your finalizer: 'putMVar terminated ()'. Your 'takeMVar terminated' will then deadlock because the terminated MVar will stay empty. I've made this same error and have seen others make it too. For this reason I created the threads[1] package to deal with it once and for all. You could rewrite your code to something like: import qualified Control.Concurrent.Thread as Thread main = do (tid, wait) <- Thread.forkIO $ doSomething `catches` [ Handler (\(_ :: MyTerminateException) -> return ()) , Handler (...) ] _ <- wait Hopefully that helps. > If I change things into: > > `finally` (putMVar dissolved () >> throwIO ThreadKilled) > > it works as expected. Strange. It would help if you could show more of of your code. Regards, Bas [1] http://hackage.haskell.org/package/threads ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Printing of asynchronous exceptions to stderr
On Tue, Nov 9, 2010 at 5:37 PM, Mitar wrote: > Why is ThreadKilled not displayed by RTS when send to thread (and > unhandled), but any other exception is? A ThreadKilled exception is not printed to stderr because it's not really an error and should not be reported as such. It is also clear how to handle a ThreadKilled: just abort the thread and silently terminate. All other exceptions raised in or thrown to the thread which are not handled by the thread itself should be considered errors and reported as such. To see what happens under the hood look at the implementation of forkIO by clicking on the 'Source' link next to the type signature: http://hackage.haskell.org/packages/archive/base/4.2.0.2/doc/html/Control-Concurrent.html#v%3AforkIO The 'action_plus' that is forked catches all exceptions and handles them with childHandler: ... where action_plus = catchException action childHandler childHandler in turn calls real_handler to handle the exception but registers an exception handler so that exceptions raised by the real_handler are handled again recursively: childHandler :: SomeException -> IO () childHandler err = catchException (real_handler err) childHandler Now real_handler handles the exceptions BlockedIndefinitelyOnMVar, BlockedIndefinitelyOnSTM and ThreadKilled by just returning. All other exceptions are reported: real_handler :: SomeException -> IO () real_handler se@(SomeException ex) = -- ignore thread GC and killThread exceptions: case cast ex of Just BlockedIndefinitelyOnMVar-> return () _ -> case cast ex of Just BlockedIndefinitelyOnSTM-> return () _ -> case cast ex of Just ThreadKilled -> return () _ -> case cast ex of -- report all others: Just StackOverflow -> reportStackOverflow _ -> reportError se > For example, I am using custom exceptions to signal different kinds of > thread killing. Based on those my threads cleanup in different ways. > But after they cleanup they keep "running". Not really running as > their computations were interrupted. But simply hanging there. And if > then new custom exception arrives it is not handled anymore (as it is > after my normal exception handlers already cleaned everything) and it > is printed to stderr. What do you mean by "hanging there". Are they blocked on an MVar? > Now I added "`finally` throwIO ThreadKilled" at the end of my cleanup > computations to really kill the thread. So that possible later > exceptions are not delivered anymore. That shouldn't be necessary. If the cleanup action is the last action of the thread then the thread will terminate when it has performed the cleanup. > Why it is not so that after all computations in a thread finish, > thread is not killed/disposed of? It actually should. I think any other behavior is a bug. It would help if you could show us your code (or parts of it). Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Forall and type synonyms in GHC 7.0
On Mon, Nov 1, 2010 at 4:30 AM, Mario Blažević wrote:
> Before uploading a new version of my project on Hackage, I decided to
> future-proof it against GHC 7.0. I ran into several compile errors caused by
> the changes in let generalization, but these were easy to fix by adding
> extra type annotations. But then I ran into another problem that I can't fix
> so easily. Here is its trimmed-down reproduction:
>
>> {-# LANGUAGE RankNTypes #-}
>>
>> module Test where
>>
>> data Component c = Component {with :: c}
>>
>> pair1 :: (Bool -> c1 -> c2 -> c3) -> Component c1 -> Component c2 ->
>> Component c3
>> pair1 combinator (Component c1) (Component c2) = Component (combinator
>> True c1 c2)
>>
>> type PairBinder m = forall x y r. (x -> y -> m r) -> m x -> m y -> m r
>>
>> pair2 :: Monad m => (PairBinder m -> c1 -> c2 -> c3) -> Component c1 ->
>> Component c2 -> Component c3
>> pair2 combinator = pair1 (combinator . chooseBinder)
>>
>> chooseBinder :: Monad m => Bool -> PairBinder m
>> chooseBinder right = if right then rightBinder else leftBinder
>>
>> leftBinder :: Monad m => PairBinder m
>> leftBinder f mx my = do {x <- mx; y <- my; f x y}
>>
>> rightBinder :: Monad m => PairBinder m
>> rightBinder f mx my = do {y <- my; x <- mx; f x y}
>
> The general idea here, if you're intrigued, is that pair1 belongs to a
> generic module that packages things it knows nothing about into Components.
> The remaining definitions belong to a client of the generic module, and
> pair2 is a specialization of pair1 to components that have something to do
> with monads.
>
> Now this little test compiles fine with GHC 6.12.1, but GHC
> 7.0.0.20101029 reports the following error in the pair2 definition:
>
> TestForall.lhs:13:42:
> Couldn't match expected type `forall x y r.
> (x -> y -> m r) -> m x -> m y -> m r'
> with actual type `(x -> y -> m1 r) -> m1 x -> m1 y -> m1 r'
> Expected type: Bool -> PairBinder m
> Actual type: Bool -> (x -> y -> m1 r) -> m1 x -> m1 y -> m1 r
> In the second argument of `(.)', namely `chooseBinder'
> In the first argument of `pair1', namely
> `(combinator . chooseBinder)'
>
> I've tried adding extra type annotations without making any progress. At
> this point I'm beginning to suspect I ran into a bug in GHC 7.0, but I can't
> find it in GHC Trac; the only ticket that looks similar is #4347, but that
> one works for me. Is this a bug? If not, how do I make my code compile?
>
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
I had the exact same problem in my regional-pointers package in the
withArray function:
withArray ∷ (Storable α, MonadCatchIO pr)
⇒ [α]
→ (∀ s. RegionalPtr α (RegionT s pr) → RegionT s pr β)
→ pr β
I had to replace the original:
withArray vals = withArrayLen vals ∘ const
with:
withArray vals f = withArrayLen vals $ \_ → f
where:
withArrayLen ∷ (Storable α, MonadCatchIO pr)
⇒ [α]
→ (∀ s. Int → RegionalPtr α (RegionT s pr) → RegionT s pr β)
→ pr β
So unfortunately you gave to inline the function composition:
pair2 combinator = pair1 $ \b -> combinator (chooseBinder b)
Note that in the other thread I'm describing a similar problem in my
usb-safe package. Where in essence the problem is that the following
won't type check:
foo :: (forall s. ST s a) -> a
foo st = ($) runST st
but the following will:
foo :: (forall s. ST s a) -> a
foo st = runST st
and surprisingly the following will also type check:
foo :: (forall s. ST s a) -> a
foo st = runST $ st
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type error in GHC-7 but not in GHC-6.12.3
(resending this to the list because this failed yesterday because of
the mailinglist downtime)
On Sat, Oct 30, 2010 at 1:57 AM, Bas van Dijk wrote:
> I could isolate it a bit more if you want.
And so I did. The following is another instance of the problem I'm
having but set in a more familiar setting:
{-# LANGUAGE RankNTypes #-}
import Control.Monad.ST
foo :: (forall s. ST s a) -> a
foo st = ($) runST st
Couldn't match expected type `forall s. ST s a'
with actual type `ST s a'
In the second argument of `($)', namely `st'
Note that: 'foo st = runST st' type checks as expected.
Surprisingly 'foo st = runST $ st' also type checks!
I find the latter surprising because according to the report[1]: e1 op
e2 = (op) e1 e2. So either both should type check or both should fail.
I guess that a RULE somewhere eliminates the ($) before the
type-checker kicks in. I do find that a little strange because I
thought RULES where applied after type checking.
Regards,
Bas
[1] http://www.haskell.org/onlinereport/exps.html#operators
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.1 Release Candidate 2
On Sat, Oct 30, 2010 at 7:38 AM, Isaac Dupree
wrote:
> On 10/29/10 20:19, Bas van Dijk wrote:
>>
>> I'm not sure this is in rc2 since I'm using the latest ghc-HEAD
>> (7.1.20101029).
>>
>> In ghc< 7 you needed to import symbols like fromInteger, (>>=) and
>> fail when you used them indirectly. For example when using integer
>> literals or do-notation.
>>
>> I noticed that in my ghc-HEAD this isn't needed anymore:
>>
>> {-# OPTIONS_GHC -Wall #-}
>> {-# LANGUAGE NoImplicitPrelude #-}
>
> Yes, in HEAD only, NoImplicitPrelude no longer implies RebindableSyntax.
Thanks, for the explanation.
> http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=darcs_commitdiff;h=20101022143400-1287e-746a83b4269744bb54177753c8ff67bec542b46c.gz
>
>> import Control.Monad ( return )
>> import System.IO ( IO )
>> import Data.Int
>>
>> -- Only needed for ghc< 7.
>> -- In fact, the following gives a redundancy warning in ghc-7:
>> import Control.Monad ( (>>=), fail )
>> import Prelude ( fromInteger )
>
> However, a redundancy warning sounds wrong (or at least confusing). An
> "unused import" warning seems more appropriate to me, although it's a bit of
> a grey area. If you remove LANGUAGE NoImplicitPrelude from the module, what
> warning do you get? (maybe test that in HEAD as well as 6.12 or so)
Without NoImplicitPrelude:
$ /usr/bin/ghc-6.12.3 --make GHC7.hs -fforce-recomp
[1 of 1] Compiling Main ( GHC7.hs, GHC7.o )
GHC7.hs:9:0:
Warning: The import of `Control.Monad' is redundant
except perhaps to import instances from `Control.Monad'
To import instances alone, use: import Control.Monad()
GHC7.hs:10:0:
Warning: The import of `Prelude' is redundant
except perhaps to import instances from `Prelude'
To import instances alone, use: import Prelude()
Which is to be expected because the Prelude is imported implicitly.
I get the same warnings in ghc-HEAD with and without NoImplicitPrelude:
$ ~/ghc-HEAD/bin/ghc-7.1.20101029 --make GHC7.hs -Wall -fforce-recomp
[1 of 1] Compiling Main ( GHC7.hs, GHC7.o )
GHC7.hs:9:1:
Warning: The import of `Control.Monad' is redundant
except perhaps to import instances from `Control.Monad'
To import instances alone, use: import Control.Monad()
GHC7.hs:10:1:
Warning: The import of `Prelude' is redundant
except perhaps to import instances from `Prelude'
To import instances alone, use: import Prelude()
Thanks,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 7.0.1 Release Candidate 2
I'm not sure this is in rc2 since I'm using the latest ghc-HEAD (7.1.20101029).
In ghc < 7 you needed to import symbols like fromInteger, (>>=) and
fail when you used them indirectly. For example when using integer
literals or do-notation.
I noticed that in my ghc-HEAD this isn't needed anymore:
{-# OPTIONS_GHC -Wall #-}
{-# LANGUAGE NoImplicitPrelude #-}
import Control.Monad ( return )
import System.IO ( IO )
import Data.Int
-- Only needed for ghc < 7.
-- In fact, the following gives a redundancy warning in ghc-7:
import Control.Monad ( (>>=), fail )
import Prelude ( fromInteger )
main :: IO ()
main = do _ <- return (1 :: Int)
return ()
Is this intentional?
Regards,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Type error in GHC-7 but not in GHC-6.12.3
On Fri, Oct 29, 2010 at 5:42 PM, Simon Peyton-Jones
wrote:
> That looks odd.
>
> Can you isolate it for us? The easiest thing is usually to start with the
> offending code:
> withDeviceWhich ∷
> ∀ pr α
> . MonadCatchIO pr
> ⇒ USB.Ctx
> → (USB.DeviceDesc → Bool)
> → (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
> → pr α
> withDeviceWhich ctx p f = do
> devs ← liftIO $ USB.getDevices ctx
> useWhich devs withDevice p f
>
> Now add local definitions for each of the functions mentioned, with
> definition foo = undefined.
>
> useWhich ∷
> ∀ k desc e (m ∷ * → *) α
> . (GetDescriptor e desc, MonadIO m)
> ⇒ [e]
> → (e → k → m α)
> → (desc → Bool)
> → k
> → m α
> useWhich = undefined.
>
> Now all you need is the types involved, and you can probably define them as
>
> data RegionT s pr a
>
> etc
>
> That should give a standalone test case.
>
> Thanks!
>
> SImon
>
Ok, Here's the more isolated program which still gives the same error
as the full usb-safe (on the latest ghc-HEAD (7.1.20101029)):
USBSafeTest.hs:39:57:
Couldn't match expected type `forall s.
RegionalDeviceHandle (RegionT s pr)
-> RegionT s pr α'
with actual type `RegionalDeviceHandle (RegionT s pr)
-> RegionT s pr α'
In the fourth argument of `useWhich', namely `f'
In the expression: useWhich devs withDevice p f
In the expression:
do { devs <- return [Device];
useWhich devs withDevice p f }
{-# LANGUAGE UnicodeSyntax
, KindSignatures
, RankNTypes
, MultiParamTypeClasses
, FunctionalDependencies
#-}
import Data.List (find)
data Ctx = Ctx
data Device = Device
data DeviceDesc = DeviceDesc
data RegionalDeviceHandle (r ∷ * → *) = RegionalDeviceHandle
data RegionT s (pr ∷ * → *) α = RegionT
instance Monad pr ⇒ Monad (RegionT s pr) where
return = undefined
(>>=) = undefined
runRegionT ∷ (∀ s. RegionT s pr α) → pr α
runRegionT = undefined
openDevice ∷ Device → RegionT s pr (RegionalDeviceHandle (RegionT s pr))
openDevice = undefined
withDevice ∷ Monad pr
⇒ Device
→ (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
→ pr α
withDevice dev f = runRegionT $ openDevice dev >>= f
withDeviceWhich ∷ ∀ pr α
. Monad pr
⇒ Ctx
→ (DeviceDesc → Bool)
→ (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α)
→ pr α
withDeviceWhich ctx p f = do devs ← return [Device]
useWhich devs withDevice p f
useWhich ∷ ∀ k desc e (m ∷ * → *) α
. (GetDescriptor e desc)
⇒ [e]
→ (e → k → m α)
→ (desc → Bool)
→ k
→ m α
useWhich ds w p f = case find (p . getDesc) ds of
Nothing → error "not found"
Just d → w d f
class GetDescriptor α desc | α → desc, desc → α where
getDesc ∷ α → desc
instance GetDescriptor Device DeviceDesc where
getDesc = undefined
I could isolate it a bit more if you want.
Thanks,
Bas
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Type error in GHC-7 but not in GHC-6.12.3
Hello, I'm updating my usb-safe package for GHC-7: darcs get http://code.haskell.org/~basvandijk/code/usb-safe It depends on the HEAD version of regions: darcs get http://code.haskell.org/~basvandijk/code/regions I think I'm suffering from the new implied MonoLocalBinds extension (I'm using GADTs) as described in: http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 However, I'm not sure this is the problem because I'm not using local bindings and use explicit type signatures everywhere. I try to make a small isolated example when I have time but for now let's use the actual definitions: The following function type-checked fine in GHC-6.12.3 but fails in GHC-7.1.20101027: withDeviceWhich ∷ ∀ pr α . MonadCatchIO pr ⇒ USB.Ctx → (USB.DeviceDesc → Bool) → (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α) → pr α withDeviceWhich ctx p f = do devs ← liftIO $ USB.getDevices ctx useWhich devs withDevice p f The error I get is: Couldn't match expected type `forall s. RegionalDeviceHandle (RegionT s pr) -> RegionT s pr α' with actual type `RegionalDeviceHandle (RegionT s pr) -> RegionT s pr α' In the fourth argument of `useWhich', namely `f' These are the types and definitions of the other functions involved: useWhich ∷ ∀ k desc e (m ∷ * → *) α . (GetDescriptor e desc, MonadIO m) ⇒ [e] → (e → k → m α) → (desc → Bool) → k → m α useWhich ds w p f = case find (p ∘ getDesc) ds of Nothing → throw USB.NotFoundException Just d → w d f withDevice ∷ MonadCatchIO pr ⇒ USB.Device → (∀ s. RegionalDeviceHandle (RegionT s pr) → RegionT s pr α) → pr α withDevice dev f = runRegionT $ openDevice dev >>= f Note that when I inline the definition of useWhich it type-checks fine: withDeviceWhich ctx p f = do devs ← liftIO $ USB.getDevices ctx case find (p ∘ getDesc) devs of Nothing → throw USB.NotFoundException Just d → withDevice d f Since I'm not using local bindings and use explicit type signatures everywhere, I'm not sure MonoLocalBinds is the problem. Note that other applications of useWhich which also use RankNTypes type-check just fine in both GHC-6.12.3 and GHC-7.1.20101027: --- setConfigWhich ∷ ∀ pr cr α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ RegionalDeviceHandle pr → (USB.ConfigDesc → Bool) → (∀ sCfg. ConfigHandle sCfg → cr α) → cr α setConfigWhich h = useWhich (getConfigs h) setConfig getConfigs ∷ RegionalDeviceHandle r → [Config r] setConfig ∷ ∀ pr cr α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ Config pr → (∀ sCfg. ConfigHandle sCfg → cr α) → cr α --- withInterfaceWhich ∷ ∀ pr sCfg α . MonadCatchIO pr ⇒ ConfigHandle sCfg → (USB.Interface → Bool) → (∀ s. RegionalInterfaceHandle sCfg (RegionT s pr) → RegionT s pr α) → pr α withInterfaceWhich h = useWhich (getInterfaces h) withInterface getInterfaces ∷ ConfigHandle sCfg → [Interface sCfg] withInterface ∷ ∀ pr sCfg α . MonadCatchIO pr ⇒ Interface sCfg → (∀ s. RegionalInterfaceHandle sCfg (RegionT s pr) → RegionT s pr α) → pr α --- setAlternateWhich ∷ ∀ pr cr sCfg α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ RegionalInterfaceHandle sCfg pr → (USB.InterfaceDesc → Bool) → (∀ sAlt. AlternateHandle sAlt pr → cr α) → cr α setAlternateWhich h = useWhich (getAlternates h) setAlternate getAlternates ∷ RegionalInterfaceHandle sCfg r → [Alternate sCfg r] setAlternate ∷ ∀ pr cr sCfg α . (pr `AncestorRegion` cr, MonadCatchIO cr) ⇒ Alternate sCfg pr → (∀ sAlt. AlternateHandle sAlt pr → cr α) → cr α --- I'm happy to provide more info when needed. Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What does interruptibility mean exactly?
On Tue, Jun 15, 2010 at 12:41 PM, Simon Marlow wrote: > On 15/06/2010 09:00, Bas van Dijk wrote: >> >> On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart wrote: >>> >>> v.dijk.bas: >>>> >>>> Hello, >>>> >>>> I've a short question about interruptible operations. In the following >>>> program is it possible for 'putMVar' to re-throw asynchronous >>>> exceptions even when asynchronous exception are blocked/masked? >>>> >>>> newEmptyMVar>>= \mv -> block $ putMVar mv x >>>> >>>> The documentation in Control.Exception about interruptible >>>> operations[1] confused me: >>>> >>>> "Some operations are interruptible, which means that they can receive >>>> asynchronous exceptions even in the scope of a block. Any function >>>> which may itself block is defined as interruptible..." >>>> >>> >>> I think the best definition of interruptible is in this paper: >>> >>> www.haskell.org/~simonmar/papers/async.pdf >>> >>> Section 5.3 >>> >> >> Thanks for the link Don! Next time I will re-read the paper before asking >> ;-) >> >> The definition makes it clear indeed: >> >> "Any operation which may need to wait indefinitely for a resource >> (e.g., takeMVar) may receive asynchronous exceptions even within an >> enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE" >> >> So I guess I can update my threads package to use MVars again. Nice! >> because they were a bit faster in an informal benchmark I performed >> some time ago. > > This is currently true for takeMVar/putMVar but it is no longer true for > throwTo (in 6.14+). I'll update the docs to make that clear. The reason is > that throwTo now works by message passing when the target is on another CPU, > and we consider a thread that is waiting for a response to a message to be > blocked - even if the throwTo can in fact proceed immediately because the > target is interruptible. Thanks for the heads-up. BTW I just released threads-0.3 which, among other things, uses MVars again for waiting for the termination of a thread: http://hackage.haskell.org/package/threads-0.3 Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: What does interruptibility mean exactly?
On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart wrote: > > v.dijk.bas: >> Hello, >> >> I've a short question about interruptible operations. In the following >> program is it possible for 'putMVar' to re-throw asynchronous >> exceptions even when asynchronous exception are blocked/masked? >> >> newEmptyMVar >>= \mv -> block $ putMVar mv x >> >> The documentation in Control.Exception about interruptible >> operations[1] confused me: >> >> "Some operations are interruptible, which means that they can receive >> asynchronous exceptions even in the scope of a block. Any function >> which may itself block is defined as interruptible..." >> > > I think the best definition of interruptible is in this paper: > >www.haskell.org/~simonmar/papers/async.pdf > > Section 5.3 > Thanks for the link Don! Next time I will re-read the paper before asking ;-) The definition makes it clear indeed: "Any operation which may need to wait indefinitely for a resource (e.g., takeMVar) may receive asynchronous exceptions even within an enclosing block, BUT ONLY WHILE THE RESOURCE IS UNAVAILABLE" So I guess I can update my threads package to use MVars again. Nice! because they were a bit faster in an informal benchmark I performed some time ago. A later quote from 5.3 emphasizes the definition even more: "...an interruptible operation cannot be interrupted if the resource it is attempting to acquire is always available..." The following darcs patch makes the definition of interruptibility in the documentation in Control.Exception a bit clearer in this regard: http://bifunctor.homelinux.net/~bas/doc-interruptibility.dpatch Regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
What does interruptibility mean exactly?
Hello, I've a short question about interruptible operations. In the following program is it possible for 'putMVar' to re-throw asynchronous exceptions even when asynchronous exception are blocked/masked? newEmptyMVar >>= \mv -> block $ putMVar mv x The documentation in Control.Exception about interruptible operations[1] confused me: "Some operations are interruptible, which means that they can receive asynchronous exceptions even in the scope of a block. Any function which may itself block is defined as interruptible..." Do I need to interpret this as: 1) 'putMVar' is always interruptible because it's an operation that has the ability to block. For example when applied to a full MVar. or: 2) 'putMVar' is only interruptible when it actually blocks and not interruptible when it is sure that it will not block. For example when applied to an empty MVar like in the given program. The reason I'm asking is that in my threads library[2] I previously applied 'putMVar' to an empty MVar to signal the termination of a thread. However due to some comments in the topic about "Asynchronous Exception Wormholes" I got a bit scared that 'putMVar' might throw exceptions even in the scope of a block. Because this could cause dead-locks in my threads library, I rewrote it using TMVars which don't have interruptible operations. However, I'm still not sure about the exact semantics so I would like to clear this up. Regards, Bas [1] http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Control-Exception.html#13 [2] darcs get http://code.haskell.org/~basvandijk/code/threads/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: priority queues in containers
On Thu, Mar 18, 2010 at 10:39 PM, Milan Straka wrote: > personally I am against splitting containers. It is a collection of > several basic data structures with similar design decisions > (reasonably efficient, can be used persistently, decent API). > I think these structures should stay together, to have a library of data > structures for common usage. But when turning containers into a meta-package these structures will stay together while at the same time allowing people to use and upgrade them separately. regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: priority queues in containers
On Thu, Mar 18, 2010 at 4:43 PM, Louis Wasserman wrote: >> Submit this package for canonicalization as part of the Haskell Platform. >> I would for one would support its inclusion. > > This is an option I seriously hadn't considered. To be fair, that's because > I've never used the Platform myself, preferring rather to have the most > up-to-date version of GHC at all times, heh. That said, while I'd be okay > with this option, I'd prefer putting it into containers, because I feel like > a canonical, reliable priority queue implementation is the sort of thing a > self-respecting language ought to have built in. I don't like libraries getting bigger, I like them getting smaller. When they're smaller they're easier to understand and easier to upgrade. So I would also advice proposing your package for the HP (Haskell Platform). I'm even for splitting containers into sub-packages: maps, sets, sequence, graph and tree. Those sub-packages would then need to be added to the HP. Then we could turn containers into a meta-package that depends on these sub-packages (similar to how the HP works[1]). Finally we could deprecate containers and after some time remove it. (I'm also for splitting base even more... but one thing at a time) regards, Bas [1] http://hackage.haskell.org/platform/2009.2.0.2/haskell-platform.cabal ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Associativity of ViewPatterns
On Thu, Jan 7, 2010 at 11:02 AM, Simon Peyton-Jones wrote: > Yes I did. That too was an oversight. Thanks for pointing both out. Ok thanks (I asked just to make sure I don't have to create a ticket.) Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Associativity of ViewPatterns
On Wed, Jan 6, 2010 at 5:34 PM, Simon Peyton-Jones wrote: > Good point. I'll fix that, in HEAD at least. Thanks, BTW did you fix the infix instance headers problem in HEAD I previously mailed about? regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Associativity of ViewPatterns
Hello, Why is the following a syntax error: f (view1 -> view2 -> pattern) = ... and the following isn't: f (view1 -> (view2 -> pattern)) = ... I would prefer the first version. regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird warnings when using ViewPatterns
On Mon, Dec 21, 2009 at 10:17 PM, Bas van Dijk wrote: > On Mon, Dec 21, 2009 at 9:03 PM, Robert Greayer wrote: >> There's been some improvement at least in 6.12.1, see: >> http://hackage.haskell.org/trac/ghc/ticket/2395 > > Thanks for pointing me to the ticket! > > I'm emerging ghc-6.12.1 right now to try it out (I'm on Gentoo Linux). All weird warnings that I got when using ViewPatterns are gone when using 6.12.1. Thanks, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Weird warnings when using ViewPatterns
On Mon, Dec 21, 2009 at 9:03 PM, Robert Greayer wrote: > There's been some improvement at least in 6.12.1, see: > http://hackage.haskell.org/trac/ghc/ticket/2395 Thanks for pointing me to the ticket! I'm emerging ghc-6.12.1 right now to try it out (I'm on Gentoo Linux). regards, Bas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Weird warnings when using ViewPatterns
Hello,
In my usb-safe[1] library I make extensive use of the ViewPatterns[2]
language extension. However I get strange warnings when using them.
See for example the following function:
resetDevice ∷ (pr `ParentOf` cr, MonadIO cr)
⇒ RegionalDeviceHandle pr → cr ()
resetDevice (internalHandle → DeviceHandle { internalDevHndl
, configAlreadySetMVar
}) = ...
where:
type RegionalDeviceHandle r = RegionalHandle USB.Device r
internalHandle ∷ RegionalHandle resource r → Handle resource
and: 'Handle' is an associated data type with the following definition:
data Handle USB.Device = DeviceHandle
{ internalDevHndl ∷ USB.DeviceHandle
, configAlreadySetMVar ∷ MVar Bool
}
Note that I also use the NamedFieldPuns[3] language extension.
When compiling the module I get lots of warnings like this:
System/USB/Safe.hs:372:0:
Warning: Pattern match(es) are overlapped
In the definition of `resetDevice':
resetDevice ((internalHandle -> (DeviceHandle {internalDevHndl,
configAlreadySetMVar})))
=
...
System/USB/Safe.hs:372:0:
Warning: Pattern match(es) are non-exhaustive
In the definition of `resetDevice': Patterns not matched:
I don't understand which patterns are overlapped or which patterns are
not matched. Is this a GHC bug? Note that I'm using ghc-6.10.4 so it's
possible that it's fixed in 6.12.1.
regards,
Bas
[1] usb-safe:
http://hackage.haskell.org/package/usb-safe-0.4
or darcs get http://code.haskell.org/~basvandijk/code/usb-safe
[2]
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#view-patterns
[3]
http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#record-puns
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
