[Haskell-cafe] Re: Cleaning up threads
Mitar mmi...@gmail.com wrote: I run multiple threads where I would like that exception from any of them (and main) propagate to others but at the same time that they can gracefully cleanup after themselves (even if this means not exiting). I have this code to try, but cleanup functions (stop) are interrupted. How can I improve this code so that this not happen? In general it's better to avoid using killThread. There are much cleaner ways to tell a thread to exit. A very common piece of code found in my applications is this: data StateCmd s = GetState (s - IO ()) | ModifyState (s - s) | Quit (() - IO ()) | SetState s stateThread :: s - IO (StateCmd s - IO ()) stateThread initialState = do cmdVar - newEmptyMVar forkIO . runContT return . fmap fst . runStateT initialState . forever $ do cmd - inBase $ takeMVar cmdVar case cmd of GetState c- get = inBase . c ModifyState f - sets_ f Quit c- inBase (c ()) abort () SetState x- set x return (putMVar cmdVar) askThread :: (c - IO ()) - ((r - IO ()) - c) - IO r askThread sendCmd cmdName = do result - newEmptyMVar sendCmd $ cmdName (putMVar result) takeMVar result The 'stateThread' function gives a computation, which starts a thread to maintain state of a certain type. It returns a function to send commands to this thread. Those commands, which don't require an answer like SetState and ModifyState, can be sent right away using this command. For those, which will give an answer like GetState and Quit, exists a convenience function askThread. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do expression definition
Hello.
http://www.haskell.org/onlinereport/exps.html#sect3.14 a obscure (to me) note
which says
As indicated by the translation of do, variables bound by let have fully
polymorphic types while those defined by - are lambda bound and are thus
monomorphic.
What actually does it mean?
And, also, would it make any difference if
do {p - e; stmts} = let ok p = do {stmts}
ok _ = fail ...
in e = ok
is redefined as e = (\p - do {stmts})?
Thanks, Alexander
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Disable LINE Pragma handling in GHC
JP Moresmau schrieb: Users may not want to edit the files directly, but they'll be happy to be able to open them with proper syntax highlighting, for example. Sure, but is showing the line numbers of the original file a bug or a feature? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: ecu-0.0.0
Brandon S Allbery KF8NH schrieb: On 9/11/10 13:46 , Henning Thielemann wrote: Would it be better to write canlib in a way that works on both Windows and Unix? Otherwise all packages that import canlib have to add this switch. The phrasing of the original request leads me to believe that this is outside of the OP's control. Then a canlib-auto package on top of canlib and canlib-windows would still be an option. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do expression definition
On Mon, 13 Sep 2010, Alexander Kotelnikov wrote:
Hello.
http://www.haskell.org/onlinereport/exps.html#sect3.14 a obscure (to me) note
which says
As indicated by the translation of do, variables bound by let have fully polymorphic
types while those defined by - are lambda bound and are thus monomorphic.
What actually does it mean?
It means that variables bound by let, may be instantiated to different
types later.
And, also, would it make any difference if
do {p - e; stmts} = let ok p = do {stmts}
ok _ = fail ...
in e = ok
is redefined as e = (\p - do {stmts})?
It would not make a difference because the (=)-expression is what the
do-expression is expanded to.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interruptable event loop
Hi! I have X11 code which looks something like the following. The problem is that TimerInterrupt gets sometimes thrown in a way that it kills the whole main thread. Probably it gets thrown in the middle of some nested function which unblocked exceptions. I found: http://hackage.haskell.org/trac/ghc/ticket/1036#comment:4 but this is not yet in GHC stable version. Is there some workaround for this? Because I have problems compiling current Haskell platform with GHC head. currentThread - myThreadId _ - forkIO $ timer currentThread block $ run display run display = do ... allocaXEvent $ \event - do interrupted - catch (unblock $ nextEvent' display event return False) (\(_ :: TimerInterrupt) - return True) ... run display -- A version of nextEvent that does not block in foreign calls nextEvent' :: Display - XEventPtr - IO () nextEvent' d p = do pend - pending d if pend /= 0 then nextEvent d p else do threadWaitRead (fromIntegral . connectionNumber $ d) nextEvent' d p data TimerInterrupt = TimerInterrupt deriving (Show, Typeable) instance Exception TimerInterrupt timer :: ThreadId - IO () timer t = do threadDelay redrawInterval throwTo t TimerInterrupt timer t Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do expression definition
2010/9/13 Henning Thielemann lemm...@henning-thielemann.de: It means that variables bound by let, may be instantiated to different types later. Can you give an example, please? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Do expression definition
On 09/13/2010 12:23 PM, Michael Lazarev wrote: 2010/9/13 Henning Thielemannlemm...@henning-thielemann.de: It means that variables bound by let, may be instantiated to different types later. Can you give an example, please? testOk = let f = id in (f 42, f True) --testNotOk :: Monad m = m (Int, Bool) --testNotOk = do f - return id -- return (f 42, f True) Try uncommenting the 'testNotOk' definition. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Do expression definition
On 13 Sep 2010, at 10:28, Gleb Alexeyev wrote: On 09/13/2010 12:23 PM, Michael Lazarev wrote: 2010/9/13 Henning Thielemannlemm...@henning-thielemann.de: It means that variables bound by let, may be instantiated to different types later. Can you give an example, please? testOk = let f = id in (f 42, f True) --testNotOk :: Monad m = m (Int, Bool) --testNotOk = do f - return id -- return (f 42, f True) Try uncommenting the 'testNotOk' definition. There's no later here at all. Two seperate definitions in a Haskell program act as if they have always been defined, are defined, and always will be defined, they are not dealt with in sequence (except for pattern matching but that doesn't apply here). Instead, what's going on here is scoping. The f in testOk is a different f to the one in testNotOkay, distinguished by their scope. Finally, this is not how you use a let in a do expression, here's how you should do it: testOk2 :: Monad m = m (Int, Bool) testOk2 = do let f = id return (f 42, f True) Thanks Tom Davie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] benchmarking c/c++ and haskell
Does it help to compile with ghc --make -O2 -funbox-strict-fields ?? David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Do expression definition
On 09/13/2010 12:38 PM, Thomas Davie wrote: On 13 Sep 2010, at 10:28, Gleb Alexeyev wrote: On 09/13/2010 12:23 PM, Michael Lazarev wrote: 2010/9/13 Henning Thielemannlemm...@henning-thielemann.de: It means that variables bound by let, may be instantiated to different types later. Can you give an example, please? testOk = let f = id in (f 42, f True) --testNotOk :: Monad m = m (Int, Bool) --testNotOk = do f- return id -- return (f 42, f True) Try uncommenting the 'testNotOk' definition. There's no later here at all. Two seperate definitions in a Haskell program act as if they have always been defined, are defined, and always will be defined, they are not dealt with in sequence (except for pattern matching but that doesn't apply here). Instead, what's going on here is scoping. The f in testOk is a different f to the one in testNotOkay, distinguished by their scope. Finally, this is not how you use a let in a do expression, here's how you should do it: testOk2 :: Monad m = m (Int, Bool) testOk2 = do let f = id return (f 42, f True) I don't understand, I'm afraid. Michael Lazarev asked for example on the difference between let-bound and lambda-bound values. testNotOk definition mirrors the structure of the testOk definition, but testNotOk is, pardon my pun, not ok, because f is let-bound and, therefore, monomorphic, while f in the first definition is polymorphic. I never implied that definitions are processed in some sort of sequence, nor I stated that the two f's are somehow related. Thanks Tom Davie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] benchmarking c/c++ and haskell
2010/9/13 David Virebayre dav.vire+hask...@gmail.com: Does it help to compile with ghc --make -O2 -funbox-strict-fields ?? No, it doesn't. Can I assume you don't have the problem I described? Thanks, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Do expression definition
On Mon, 13 Sep 2010, Gleb Alexeyev wrote: On 09/13/2010 12:38 PM, Thomas Davie wrote: There's no later here at all. Two seperate definitions in a Haskell program act as if they have always been defined, are defined, and always will be defined, they are not dealt with in sequence (except for pattern matching but that doesn't apply here). I don't understand, I'm afraid. Michael Lazarev asked for example on the difference between let-bound and lambda-bound values. testNotOk definition mirrors the structure of the testOk definition, but testNotOk is, pardon my pun, not ok, because f is let-bound and, therefore, monomorphic, while f in the first definition is polymorphic. I never implied that definitions are processed in some sort of sequence, nor I stated that the two f's are somehow related. I think the later refered to my words. With later I meant somewhere below the binding in the do-block. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Do expression definition
On 09/13/2010 12:45 PM, Gleb Alexeyev wrote: is, pardon my pun, not ok, because f is let-bound and, therefore, monomorphic This line doesn't make sense, I was too hasty to hit the 'Send' button, I meant to write 'lambda-bound', of course, apologies for that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Do expression definition
Thanks for examples and pointers. Since I came from Lisp, it never occurred to me that let and lambda are different constructs in Haskell. I thought that let x = y in f is really (\x - f) y It turns out that let is about declarations which are not the same as function applications above. So, here is a little followup for this experiment. Prelude :t (\f - (f 42, f True)) interactive:1:10: No instance for (Num Bool) arising from the literal `42' at interactive:1:10-11 Possible fix: add an instance declaration for (Num Bool) In the first argument of `f', namely `42' In the expression: f 42 In the expression: (f 42, f True) If I understand correctly, compiler first checks f 42, and deduces that f must be of type (Num a) = a - b. Then it checks f True, and it does not satisfy the previously deduced type for f, because type of True is not in Num class. This works: Prelude :t (\f - (f 42, f 41.9)) (\f - (f 42, f 41.9)) :: (Fractional t1) = (t1 - t) - (t, t) It just managed to deduce a type for f :: (Fractional t1) = (t1 - t) And this, of course, works: Prelude let f = id in (f 42, f True) (42,True) If I understand correctly again, it happens because f is a definition, which gets substituted to f 42 and to f True. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Text performance problem
I really didn't expect mapAccumL to have quadratic complexity. Thank you a lot for the fix! On Mon, Sep 13, 2010 at 5:06 AM, Bryan O'Sullivan b...@serpentine.comwrote: On Sun, Sep 12, 2010 at 12:23 PM, Petr Prokhorenkov prokhoren...@gmail.com wrote: I experienced a following problem while dealing with some text processing. Thanks for the report and the test case. There's nothing wrong with your code - read on for details. You ran into one of the few functions in Data.Text that I copied straight over from the list implementation due to it not being used often. Unfortunately, that implementation constructs a new Text value (using cons) on every iteration through the loop, and as you might expect that's very slow even on tiny inputs, as it has quadratic behaviour. I've rewritten both strict and lazy mapAccumL and mapAccumR to use as much of the stream fusion machinery as possible. (By the way, there's an interesting fact behind why those functions started out life as they did: you can't write mapAccum functions using only stream machinery, due to their types, and the strict code is more work to write if you can't use the stream machinery. In the early days it just wasn't worth writing the more complex variants of them, as I had more pressing performance concerns at the time.) Where the old version of mapAccumL caused your test case to take 5 seconds to process an 11KB file (ouch!), with the rewritten version, your code can process an 81MB file in the same amount of time, without any changes to your code, and that O(n^2) behaviour is gone :-) text 0.8.1.0 is now up on hackage, with the fix included. Enjoy! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] benchmarking c/c++ and haskell
On Monday 13 September 2010 11:50:14, Vo Minh Thu wrote: 2010/9/13 David Virebayre dav.vire+hask...@gmail.com: Does it help to compile with ghc --make -O2 -funbox-strict-fields ?? No, it doesn't. Can I assume you don't have the problem I described? Currently, GHC's native code generator is not too good at optimising loops. It might help if you compile via C, ghc -O2 -fexcess-precision -fvia-C -optc-O3 On my box, that gives a 2× speedup (unfortunately, that means it takes almost three times as long as the C version instead of 6×). If you have the llvm backend for GHC, that is supposedly better for such code. Thanks, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] benchmarking c/c++ and haskell
2010/9/13 Daniel Fischer daniel.is.fisc...@web.de: On Monday 13 September 2010 11:50:14, Vo Minh Thu wrote: 2010/9/13 David Virebayre dav.vire+hask...@gmail.com: Does it help to compile with ghc --make -O2 -funbox-strict-fields ?? No, it doesn't. Can I assume you don't have the problem I described? Currently, GHC's native code generator is not too good at optimising loops. It might help if you compile via C, ghc -O2 -fexcess-precision -fvia-C -optc-O3 On my box, that gives a 2× speedup (unfortunately, that means it takes almost three times as long as the C version instead of 6×). With your options, the Haskell code is only 1.5x slower. But still... If you have the llvm backend for GHC, that is supposedly better for such code. ... the post is from 2008. No LLVM goodness. So I thought GHC 6.12.1 (not the latest and greatest HEAD) would be enough. Thanks, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
On Sat, Sep 11, 2010 at 12:17:27PM -0700, Jason Dagit wrote: From the FAQ linked by Paolo: http://www.haskell.org/cabal/FAQ.html#dependencies-conflict To avoid this problem in the future, avoid upgrading core packages. The latest version of cabal-install has disabled the upgrade command to make it a bit harder for people to break their systems in this way. It's not always possible. In particular, random-1.0.0.2 (shipped with GHC 6.12.*) depends on the time package, of which more recent versions have been released. That can trigger rebuilding of random-1.0.0.2, and thus haskell98-1.0.1.1. It might help if the release of random with GHC 7.0 had a tight dependency on the version of the time package shipped with it. Maybe all the core packages need tight dependencies. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do expression definition
On Mon, Sep 13, 2010 at 8:21 AM, Alexander Kotelnikov sa...@myxomop.com wrote:
And, also, would it make any difference if
do {p - e; stmts} = let ok p = do {stmts}
ok _ = fail ...
in e = ok
is redefined as e = (\p - do {stmts})?
This is the magic that allows pattern-match failure in a do expression
to return a normal result. Notice that fail and not error is
called - each Monad has its own fail method, so that for example:
uncons :: [a] - Maybe (a, [a])
uncons xs = do { (x:xs) - return xs; return (x, xs) }
evaluates to Nothing rather than causing an exception when xs is empty.
That this implementation detail ends up in the Monad class is regarded
by many as untidy, though.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] record update
Am Samstag, den 11.09.2010, 11:21 -0600 schrieb Jonathan Geddes:
I know that record updates is a topic that has become a bit of a dead
horse, but here I go anyway:
I find that most of the record updates I read and write take the form
someUpdate :: MyRecord - MyRecord
someUpdate myRecord = myRecord
{ field1 = f $ field1 myRecord
, field2 = g $ field2 myRecord
, field3 = h $ filed3 myRecord
}
I find myself wishing I could write something more like
someUpdate :: MyRecord - MyRecord
someUpdate myRecord = myRecord
{ field1 = f
, field2 = g
, field3 = h
}
with equivalent semantics. Here = reads is transformed by. Operator
= could still be used for assignment as in current record updates.
The best part about such an extension, in my opinion, is that it would
open the door for anonymous lambda record updates. Something like:
someUpdate :: MyRecord - MyRecord
someUpdate = \{field1 = f, field2 = g, field3 = h}
again, with the same semantics. This becomes possible because you no
longer need to refer to the record within the {} part of the update.
This would be useful, for example, in the State monad. We could write:
someStateTransform :: State MyRecord ()
someStateTransform = do
modify $ \{field1 = (++!)}
...
where currently we see code like
someStateTransform :: State MyRecord ()
someStateTransform = do
modify $ \record-record{field1 = (++!) $ field1 record}
...
which repeats the record name 3 times and the field name twice. The
repetition just feels out of place next to all the other terse,
readable Haskell code in the program.
So what do my fellow haskellers think? Is this idea worth writing up a
proposal for?
Alternatively, can you offer me some advice on writing code in Haskell
2010 that avoids the ugly, repetitive style of record update?
--Jonathan
You might want to have a look at the records package:
http://hackage.haskell.org/package/records
Here is a code example:
import Data.Kind
import Data.TypeFun
import Data.Record
import Data.Record.Combinators
data Surname = Surname deriving (Show)
data Age = Age deriving (Show)
data Room= Roomderiving (Show)
instance Name Surname where name = Surname
instance Name Age where name = Age
instance Name Roomwhere name = Room
oldData = X : Surname := Jeltsch
: Age := 31
: Room:= EH/202
`withStyle` Id KindStar
newData = modify (X : Age := (+2) : Room := const HG/2.39) oldData
Evaluating newData gives you:
X : Surname := Jeltsch : Age := 33 : Room := HG/2.39
If you have any question regarding the records package, please ask,
since I’m its author. :-)
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] record update
For completeness, using fclabels (yet another record package) you can write it
like this:
{-# LANGUAGE TemplateHaskell #-}
module Records where
import Data.Record.Label
data MyRecord = MyRecord { _field1 :: String, _field2 :: Int, _field3 :: Bool
}
$(mkLabels [''MyRecord])
modifyThree f g h = modL field1 f
. modL field2 g
. modL field3 h
-chris
On 11 sep 2010, at 19:21, Jonathan Geddes wrote:
I know that record updates is a topic that has become a bit of a dead
horse, but here I go anyway:
I find that most of the record updates I read and write take the form
someUpdate :: MyRecord - MyRecord
someUpdate myRecord = myRecord
{ field1 = f $ field1 myRecord
, field2 = g $ field2 myRecord
, field3 = h $ filed3 myRecord
}
I find myself wishing I could write something more like
someUpdate :: MyRecord - MyRecord
someUpdate myRecord = myRecord
{ field1 = f
, field2 = g
, field3 = h
}
with equivalent semantics. Here = reads is transformed by. Operator
= could still be used for assignment as in current record updates.
The best part about such an extension, in my opinion, is that it would
open the door for anonymous lambda record updates. Something like:
someUpdate :: MyRecord - MyRecord
someUpdate = \{field1 = f, field2 = g, field3 = h}
again, with the same semantics. This becomes possible because you no
longer need to refer to the record within the {} part of the update.
This would be useful, for example, in the State monad. We could write:
someStateTransform :: State MyRecord ()
someStateTransform = do
modify $ \{field1 = (++!)}
...
where currently we see code like
someStateTransform :: State MyRecord ()
someStateTransform = do
modify $ \record-record{field1 = (++!) $ field1 record}
...
which repeats the record name 3 times and the field name twice. The
repetition just feels out of place next to all the other terse,
readable Haskell code in the program.
So what do my fellow haskellers think? Is this idea worth writing up a
proposal for?
Alternatively, can you offer me some advice on writing code in Haskell
2010 that avoids the ugly, repetitive style of record update?
--Jonathan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Interruptable event loop
Hi! OK, System.Timeout's timeout does not have this problem. ;-) Mitar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Full strict functor by abusing Haskell exceptions
I started experiment with strict functors. I come to: import Control.Exception import Foreign import Prelude hiding (catch) data StrictMonad a = StrictMonad a deriving Show instance Functor StrictMonad where f `fmap` StrictMonad v = return $ f v instance Applicative StrictMonad where pure = return (*) = ap instance Monad StrictMonad where return x = unsafePerformIO $ do (return $! x) `catch` \(SomeException _) - return x return $! StrictMonad x StrictMonad v = f = f v It seems to be valid IMHO Functor and Monad (I haven't prove it) as long as functions terminates. Some time ago there was post stating that there is not possible strict 'interesting' functor - I guess that the above is 'interesting' (and due to halting problem I guess it is not possible to create strict Functor which would deal with that problem). Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Differences with Hayoo and Hoogle: Searching For Monoids
Hi all, I was trying to read the documentation on monoids and the Sum type. When I searched Hayoo for Monoid or Data.Monoid, the Data.Monoid module in base did not show up - Hoogle found it without a problem. The same goes for the Sum type, Hayoo does not seem to find it but Hoogle does. -deech ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Text performance problem
On Mon, Sep 13, 2010 at 3:26 AM, Petr Prokhorenkov prokhoren...@gmail.comwrote: I really didn't expect mapAccumL to have quadratic complexity. Thank you a lot for the fix! No problem. By the way, in my benchmarks, mapAccumL on Text is now faster than on ByteString :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: Type families - how to resolve ambiguities?
On Sun, Sep 12, 2010 at 9:24 AM, Dominique Devriese dominique.devri...@cs.kuleuven.be wrote: However, it would make more sense to have it be a type family, without the overhead of data (both in space and in typing). You can make Tensor a data family and use newtype instances. As I understand these, there should not be a space overhead. The only overhead I would expect this to introduce is the extra newtype constructor. Which is only at programming time; newtype constructors do not exist at runtime. They get erased after typechecking. This also means that pattern matching against newtype constructors cannot fail. For example: data family F a data instance F Bool = B () newtype instance F Int = I () fBool :: F Bool - Int f1 (B _) = 3 fInt :: F Int - Int f2 (I _) = 4 main = do print (fInt undefined) print (fBool undefined) This program should print 4 and then exit with an error. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
On Sun, Sep 12, 2010 at 20:46, Tillmann Rendel ren...@mathematik.uni-marburg.de wrote: Paolo Giarrusso wrote: in a tracker entry you linked to, http://hackage.haskell.org/trac/hackage/ticket/704, duncan argues that we also want to be able to do things like linking multiple versions of a Haskell package into a single application. [snip] Even with the technical ability to link all of foo, bar, pair-1 and pair-2 together, I don't see how this program could be reasonably compiled. Therefore, I think that the notion of consistent install plans is relevant semantically, not just to work around some deficiency in the linking system. Your case is valid, but OTOH there other cases to support: if I link together two programs which use _internally_ different versions of regex packages, cabal should support that - and here I guess we agree. The issue is how to express or recognise the distinction. I had this kind of scenario in mind, and that's why I proposed using versioned typenames for typechecking - your example program would then be caught as ill-typed. However, that's not enough, because the correct solution is to use the same pair version. - OTOH, Program would probably have its own cabal file, which could maybe list a dependency on pair. But I don't like this solution - the developer shouldn't have to do this. - The nicer alternative would be to extract, from the types used in the .hi files, whether they mention pair at all - like here, and unlike the case when the different packages are used internally. This solution is perfect but takes extra work which I can't estimate. Actually, some more work would maybe be needed to cope with cross-module inlining, but I believe that this can be done by cabal, by just looking at .hi files, without further changes to GHC - after versioned typechecking is introduced if missing, anyway. And maybe some interface to .hi files should be exposed. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
On Sep 13, 1:52 pm, Ross Paterson r...@soi.city.ac.uk wrote: On Sat, Sep 11, 2010 at 12:17:27PM -0700, Jason Dagit wrote: To avoid this problem in the future, avoid upgrading core packages. The latest version of cabal-install has disabled the upgrade command to make it a bit harder for people to break their systems in this way. It's not always possible. In particular, random-1.0.0.2 (shipped with GHC 6.12.*) depends on the time package, of which more recent versions have been released. That can trigger rebuilding of random-1.0.0.2, and thus haskell98-1.0.1.1. My case was similar, old-locale had been upgraded. And currently, haskell98 would not necessarily be rebuilt automatically - it would just break. The point is that time should _not_ be upgradeable with the current system, for the same reason as cabal upgrade is disabled. The alternative is to allow Cabal to rebuild itself _and_ GHC (and everything) safely. BTW, I just realized that thanks to static linking, the ghc and cabal binaries should never stop working - only using those libraries for building packages could break. If you always upgrade locally, you can always remove packages from the user DB as I did. It might help if the release of random with GHC 7.0 had a tight dependency on the version of the time package shipped with it. Maybe all the core packages need tight dependencies. If you mean it as a hack for cabal's brokenness, it could be OK, but otherwise than that, I believe it's a bad idea. GHC itself does not depend on any specific package; it's the compiled GHC package which has a tight dependency. So I don't like the concept. Furthermore, if a GHC release (whichever it is) had a tight dependency, that would be annoying for when you want to compile that release against different libraries - if that is supposed to work. But actually, on my system I can't see ghc in cabal's DB; I can see that in the ghc-pkg database for binaries, but there all dependencies are tight, probably because they are dependencies among installed packages. Have a look: $ cabal info QuickCheck [...] Dependencies: mtl -any, base =4 5, random -any, base =3 4, random -any, base 3, ghc -any, extensible- exceptions -any $ ghc-pkg describe QuickCheck | grep depends depends: base-3.0.3.1 random-1.0.0.1 Best regards -- Paolo Giarrusso, PhD student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock again
Andrew Coppin wrote: Also, I commented that the links generated were broken, but it appears that if you have a sufficiently new version of Haddock, the links work just fine. (In other words, this particular bug is already fixed.) Heh, nope. The correct information is actually this: It *always* worked with IE, and never did work with Firefox. Anyway, I've filed tickets again HP for the various documentation glitches. We'll see what happens with that... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: A new cabal odissey: cabal-1.8 breaking its own neck by updating its dependencies
Hi all, I would like to share a new very cool result given by the current Cabal: if packages FOO, BAR and FOOBAR exist, such that FOO depends on BAR which depends on FOOBAR, and all three are installed, you just can't safely upgrade FOOBAR. When the same version of BAR is ever recompiled against the new FOOBAR, its ABI might change and FOO _will_ thus break if you're not very lucky. Call it the No Upgrade Theorem, if you want. Note that upgrades of FOO and BAR can still be safe: the key hypothesis is a dependency chain of 3 packages, and the thesis is that the deepest of the three ones in the chain (FOOBAR in the above example) can't be upgraded safely. Not that it's necessarily Cabal's fault, IMHO. Given this kind of cross-module inlining, proper dependency handling (which includes what we discussed) seems insanely complicated to get right. Of course, Cabal can be fixed, but I would call that a major achievement. On Sep 13, 12:53 am, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: On 9/11/10 15:43 , Daniel Fischer wrote: On Saturday 11 September 2010 20:38:21, Paolo Giarrusso wrote: - is there a specification of which are the core packages? core as in *do not update*? Basically, what comes with GHC shouldn't be updated. Though I heard updating Cabal was okay. Some consistency would be nice; IIRC GHC refers to them as boot libraries. Boot libraries clearly refers to GHC bootstrapping. But with a statically linked GHC (like on my system at least, and maybe everywhere), GHC dependencies are irrelevant, only transitive dependency closure of (those used by Cabal + those used by any programs (base, ghc-prim, rts, integer...)) are relevant. Which includes an additional package, pretty, and excludes many other. To verify this theory, I upgraded bytestring (on which GHC but not Cabal depend), and I can still configure+build+copy packages. But of course, bytestring fulfills the hypothesis of the above theorem, so installing a package with enough dependencies might trigger actual breakage. That's however not because ghc depends on bytestring. Only Cabal is special, because if you break that you can't recompile anything any more, and because recompiling Cabal dependencies and Cabal takes special effort (as said elsewhere). That's why core packages should include just cabal (recursive) deps. Fixing the No Upgrade Theorem is easier, just recompile more stuff and/or give more warnings. -- Paolo Giarrusso - Ph.D. Student http://www.informatik.uni-marburg.de/~pgiarrusso/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Differences with Hayoo and Hoogle: Searching For Monoids
On Sep 13, 6:27 pm, aditya siram aditya.si...@gmail.com wrote: Hi all, I was trying to read the documentation on monoids and the Sum type. When I searched Hayoo for Monoid or Data.Monoid, the Data.Monoid module in base did not show up - Hoogle found it without a problem. The same goes for the Sum type, Hayoo does not seem to find it but Hoogle does. I also observed regularly that Hayoo is somewhat cooler, but misses base - I thought it was simply restricted to hackage, but base is on hackage, surprisingly. Can anybody find map from the Prelude? I also tried map package:base or map module:Prelude. And map is the example on the Hayoo homepage. Paolo -- http://www.informatik.uni-marburg.de/~pgiarrusso ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Full strict functor by abusing Haskell exceptions
On Sep 13, 6:25 pm, Maciej Piechotka uzytkown...@gmail.com wrote: I started experiment with strict functors. I come to: import Control.Exception import Foreign import Prelude hiding (catch) data StrictMonad a = StrictMonad a deriving Show instance Functor StrictMonad where f `fmap` StrictMonad v = return $ f v instance Applicative StrictMonad where pure = return (*) = ap instance Monad StrictMonad where return x = unsafePerformIO $ do (return $! x) `catch` \(SomeException _) - return x return $! StrictMonad x StrictMonad v = f = f v It seems to be valid IMHO Functor and Monad (I haven't prove it) as long as functions terminates. Here, I just believe you, and assume you mean that some non- terminating function would give problems to your strict functor, i.e. it wouldn't satisfy the functor/monad laws. Then, I also wonder if the functor you have is any different from an identity functor - I see why the monad could be strict. Some time ago there was post stating that there is not possible strict 'interesting' functor - I guess that the above is 'interesting' (and due to halting problem I guess it is not possible to create strict Functor which would deal with that problem). I'm no expert, but since a functor on the Hask category must work on all functions available there, it looks like you proved that yours is not a functor and can't be fixed; maybe, that means that no strict functor exist. Your function is probably valid in a different category, containing mostly the same objects but just total functions - if it is a valid category; I wonder what would happen when arrows in this category were applied on undefined, but maybe this means that objects in this category should not contain undefined as an element; at that point, you are in a strongly normalizing programming language and probably strict makes no sense. Then, I would also like to understand what exactly a strict functor is, in detail, and/or a link to the post you reference. Best regards Paolo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Do expression definition
On Sep 13, 12:22 pm, Michael Lazarev lazarev.mich...@gmail.com wrote: Thanks for examples and pointers. Since I came from Lisp, it never occurred to me that let and lambda are different constructs in Haskell. You're not alone, I didn't believe my eyes when I first read about the difference (I learned Scheme, but the difference doesn't really matter here) Prelude :t (\f - (f 42, f True)) interactive:1:10: No instance for (Num Bool) [...] If I understand correctly, compiler first checks f 42, and deduces that f must be of type (Num a) = a - b. Then it checks f True, and it does not satisfy the previously deduced type for f, because type of True is not in Num class. That's a reasonable explanation - I don't know details about the order, and :t (\f - (f True, f 42)) gives the same mistake; I believe that type-checking is still in order (left-to-right or right-to-left, we can't say) but whether (Num t) and Bool is deduced first does not matter, because unifying them is commutative. This works: Prelude :t (\f - (f 42, f 41.9)) (\f - (f 42, f 41.9)) :: (Fractional t1) = (t1 - t) - (t, t) It just managed to deduce a type for f :: (Fractional t1) = (t1 - t) Yes, but that's not polymorphic in the sense people are using - ghc searched for a common type, and realized that there's a whole class of types where both 42 and 41.9 belong - Fractional. And this, of course, works: Prelude let f = id in (f 42, f True) (42,True) If I understand correctly again, it happens because f is a definition, which gets substituted to f 42 and to f True. Almost true. In evaluating let a = b, b must be evaluated before binding it to a, and a value has a type. Actually, one can define the substitution semantics you describe, but interesting things happen then. Section 22.7 of Types and Programming Languages from Pierce discusses exactly this, in the context of ML* - I guess you can also Google for let-polymorphism. The real thing is that when you write let f = id in, the type of a is deduced (internally a - a), and then generalized (internally forall a. a - a). The difference is that in the first case, GHC will try to discover what type a is by unifying it with the type of arguments of f - unification would produce type equations a = Int, a = Bool in the above example. The forall prevents that. Note that I wrote internally, even if you can actually write both types (the second with an extension, IIRC) because in many cases when you write a top-level type-signature: f :: a - a that is also implicitly generalized. * Note that in the end Pierce explains a problem with polymorphic references and its solution, but this does not applies to Haskell because of the lack of side effects (or you could say that unsafePerformIO does allow such things, and that's why it's not type- safe). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
