Re: [GHC] #937: ghc-pkg should splice $topdir on Windows
#937: ghc-pkg should splice $topdir on Windows --+- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal| Milestone: 6.6.1 Component: Compiler |Version: 6.6 Severity: normal| Resolution: Keywords:| Difficulty: Easy (1 hr) Testcase: N/A | Architecture: Multiple Os: Windows | --+- Comment (by duncan): The first option seems most sensible to me. It'd also mean that nothing in Cabal or Haddock would need fixing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/937 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #730: ghc needs a man page
#730: ghc needs a man page --+- Reporter: [EMAIL PROTECTED] | Owner: igloo Type: task | Status: closed Priority: normal| Milestone: 6.6.1 Component: Build System |Version: 6.4.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | --+- Changes (by igloo): * resolution: = fixed * status: new = closed Comment: I've now wired this into the build system. Set GhcManpages=YES in mk/build.mk if you want to build the manpage. Thanks Ian -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/730 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1038: selector thunks not working? space leak in standard example
#1038: selector thunks not working? space leak in standard example
---+
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 6.6
Severity: normal |Keywords:
Difficulty: Unknown |Testcase:
Architecture: x86 | Os: Multiple
---+
I thought that GHC evaluates THUNK_SELECTORS and thus eliminates the
space leak in this infamous example [Hughes83][Wadler87][Sparud93]:
{{{
module Main where
surprise xs = b1 ++ [0,0] ++ b2
where
(b1,b2) = break (==0) xs
strictFromTo :: Int - Int - [Int]
strictFromTo i m = takeWhile (= m) $ strictFrom i
strictFrom :: Int - [Int]
strictFrom x = let x' = x + 1 in seq x' $ x' : strictFrom x'
main = print (length $ surprise $ strictFromTo (-100) 1)
-- space leak, w/ or w/o optimization
main2 = print (length $ strictFromTo (-100) 1)
-- runs in constant space, w/ or w/o optimization
}}}
However, this program does not run in constant space, even with -O2.
I get the same results on
GHC6.6 Mac OS X Intel
GHC6.2.1 Linux Intel
GHC6.4.1 Linux Intel
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1038
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #1039: Control.Monad.Identity documentation
#1039: Control.Monad.Identity documentation --+- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.6 Severity: normal |Keywords: Difficulty: Easy (1 hr)|Testcase: Architecture: Multiple | Os: Multiple --+- Control.Monad.Identity Haddock documentation. Converted the module documentation to Haddock format. From Jeff Newbern's permission included description from his tutorial All About Monads (http://www.nomaware.com/monads/). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1039 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1039: Control.Monad.Identity documentation
#1039: Control.Monad.Identity documentation ---+ Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) |Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | ---+ Comment (by guest): Proposal deadline is December 19 (in 2 weeks). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1039 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Building HEAD with -fasm: error in package 'unix'
Hi, I have built GHC HEAD yesterday. My build.mk is: GhcCompilerWays = GhcRTSWays = thr GhcLibWays = SRC_HC_OPTS = -O GhcHcOpts = -O GhcLibHcOpts = -O Options -O and -fvia-C have separated recently. So libraries and the stage2 compiler were compiled by the native code generator. The build finished without any errors, but the following command failed: $ ./compiler/stage2/ghc-inplace --interactive -package ghc ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. ghc-6.7: /home/wld/test/fptools/libraries/unix/HSunix.o: unknown symbol `lstat' Loading package unix-1.0 ... linking ... ghc-6.7: unable to load package `unix-1.0' I think, the reason of this error is that 'lstat' is a macro but the native generator do not look into C headers to find a real name. -- V.Rudenko -- λ is the ultimate ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building GHC quickly
Donald Bruce Stewart wrote: simonmarhaskell: Donald Bruce Stewart wrote: Had a go today building GHC on a multcore linux box, with -j, just to see how fast it would go. Summary: you can build GHC from scratch in less than 10 minutes these days! More details here: http://cgi.cse.unsw.edu.au/~dons/blog/2006/12/03#build_ghc_fast I'd be interested in how long it takes if you turn on -O for the stage 1 compiler only. The point being that it'll be slower to compile stage 1, but that compiler is then used to build all the libraries and stage 2, so the benefit of having an optimised stage 1 might outweigh the time it takes to build it. Yes! 7 mins 49 seconds, with: SRC_HC_OPTS = -H64m -Onot -fasm GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -Onot -fasm GhcLibHcOpts= -Onot -fasm GhcLibWays = SplitObjs = NO and -j10, on a 4 core linux machine. Great - although with unoptimised libraries this build isn't really much use except as a sanity check. How much extra time does it take if you optimise the libraries? When the new 16 core box arrives, I'll set up a nightly build to ensure the -jN building keeps working. Nice :) Hopefully we'll have BuildBot set up soon, so adding new nightly builds will be easy. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
generic ghc binary Linux (x86_64) misses libHSghc
having just installed http://www.haskell.org/ghc/dist/6.6/ghc-6.6-x86_64-unknown-linux.tar.bz2 it occurs that libHSghc.a is missing, but ghc-pkg lists (ghc-6.6). Christian [EMAIL PROTECTED]:~/haskell/linux64 ghci -package ghc ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.6, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package template-haskell ... linking ... done. Loading package readline-1.0 ... linking ... done. Loading package unix-1.0 ... linking ... done. Loading package Cabal-1.1.6 ... linking ... done. Loading package regex-base-0.71 ... linking ... done. Loading package regex-posix-0.71 ... linking ... done. Loading package regex-compat-0.71 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package ghc-6.6 ... ghc-6.6: can't load .so/.DLL for: HSghc (libHSghc.so: cannot open shared object file: No such file or directory) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Safepoint does not work as documented in paper
Chris Kuklewicz wrote:
One odd problem: The paper on async exception defines:
safePoint = unblock (return ())
but this simply does not work in my testing. Ever. Even using
{-# NOINLINE safePoint #-} or -Onot
By comparision, this does work: safepoint = unblock (print safe)
So how can such a safePoint be written?
The window in 'unblock (return ())' is tiny, I'm not really surprised if
nothing ever gets through it. You might have more luck with 'unblock yield'.
(BTW, I think glasgow-haskell-users@haskell.org is a more appropriate list, so
I'm replying there instead).
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Safepoint does not work as documented in paper
Simon Marlow wrote:
Chris Kuklewicz wrote:
One odd problem: The paper on async exception defines:
safePoint = unblock (return ())
but this simply does not work in my testing. Ever. Even using
{-# NOINLINE safePoint #-} or -Onot
By comparision, this does work: safepoint = unblock (print safe)
So how can such a safePoint be written?
The window in 'unblock (return ())' is tiny, I'm not really surprised if
nothing ever gets through it. You might have more luck with 'unblock yield'.
(BTW, I think glasgow-haskell-users@haskell.org is a more appropriate list,
so I'm replying there instead).
Cheers,
Simon
That works, thanks.
It is funny, the killThread thread is halted and waiting for the async signal to
be delivered, and the running thread got through eleven (unblock (print
sleeper)) statements before noticing that it had been told to die. Using
your (unblock yield) worked
I had thought that unblock would always check the queue of incoming async
signals but this is obviously not the case. The Asynchronous Exceptions in
Haskell paper says:
As soon as a thread exits the scope of a block, and at regular intervals during
execution inside unblock, its pending exceptions queue must be checked. If there
are pending exceptions, the first one is removed from the queue and delivered to
the thread.
...which is why I have the wrong expectation. Is there a better resource for
how GHC actually implements block/unblock/throwTo ? Searching for throwTo on
the wiki gets me nothing.
--
Chris
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Safepoint does not work as documented in paper
Chris Kuklewicz wrote:
Simon Marlow wrote:
Chris Kuklewicz wrote:
One odd problem: The paper on async exception defines:
safePoint = unblock (return ())
but this simply does not work in my testing. Ever. Even using
{-# NOINLINE safePoint #-} or -Onot
By comparision, this does work: safepoint = unblock (print safe)
So how can such a safePoint be written?
The window in 'unblock (return ())' is tiny, I'm not really surprised if
nothing ever gets through it. You might have more luck with 'unblock yield'.
(BTW, I think glasgow-haskell-users@haskell.org is a more appropriate list, so
I'm replying there instead).
Cheers,
Simon
That works, thanks.
It is funny, the killThread thread is halted and waiting for the async signal to
be delivered, and the running thread got through eleven (unblock (print
sleeper)) statements before noticing that it had been told to die. Using
your (unblock yield) worked
I had thought that unblock would always check the queue of incoming async
signals but this is obviously not the case. The Asynchronous Exceptions in
Haskell paper says:
As soon as a thread exits the scope of a block, and at regular intervals during
execution inside unblock, its pending exceptions queue must be checked. If there
are pending exceptions, the first one is removed from the queue and delivered to
the thread.
There's one major difference between what's described in that paper and what's
actually implemented: GHC's throwTo is synchronous; it doesn't return until the
exception has been delivered.
We went to-and-fro on this issue several times during the design, and I forget
the reason we finally went with the asynchronous version of throwTo for the
paper; maybe we were thinking about distributed applications where a synchronous
throwTo would be more difficult to implement. The synchronous version is often
easier to program with, so that's what we've got in GHC, and you can get the
asynchronous version by adding a forkIO around it.
Now, this leads to the reason why 'unblock (return ())' doesn't work as you
expected. When a thread executes throwTo and the target thread is inside a
block, the source thread blocks. when the target thread hits an unblock, it
wakes up the source thread, but unless it context switches before entering a
blocked state again, when the source thread finally runs it'll find the target
thread in a blocked state and have to go back to sleep.
...which is why I have the wrong expectation. Is there a better resource for
how GHC actually implements block/unblock/throwTo ? Searching for throwTo on
the wiki gets me nothing.
I should write something in the commentary sometime...
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] GHC Error question
[redirecting to ghc users]
It looks like a splendid error to me. The call of compile1 is obliged to pass
to compile1 a dictionary of type (Builder b box), *for any type box*. There
are no further constraints on box, so compile1 can make no assumptions about
how the caller chooses to instantiate 'box'.
But in the body you'll need a dictionary of type (Builder b box1), but there is
nothing to ensure that the caller chooses the right box.
Maybe you want the Builder class to have a functional dependency (b - box), so
that fixing b fixes box.
I can't say more without seeing the code. can you give a small repo case?
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Norman
| Ramsey
| Sent: 05 December 2006 21:21
| To: haskell@haskell.org
| Cc: [EMAIL PROTECTED]
| Subject: [Haskell] GHC Error question
|
| Without going too deep into the details of my type classes, I have
| written the following code (focusing on compile1):
|
| {-# OPTIONS -fglasgow-exts #-}
|
| compile1 :: (Builder b box) = t - Name - Ir.ANF - b t
| compile1 f x body = do env - compile body empty
| wire (Arg W) (env x)
| return f
|
| compile :: (Builder b box) = Ir.ANF - Env box - b (Env box)
|
| class (Monad b) = Builder b box where
| wire:: Source box - Sink box - b ()
| ...
|
| type Env box = Name - Sink box
|
| This program is rejected by GHC with the following message:
|
| Ccomp.hs:54:23:
| Could not deduce (Builder b box1) from the context (Builder b box)
| arising from use of `wire' at Ccomp.hs:54:23-42
| Possible fix:
| add (Builder b box1) to the type signature(s) for `compile1'
| In the expression: wire (Arg W) (env x)
| In a 'do' expression: wire (Arg W) (env x)
| In the expression:
| do env - compile body empty
|wire (Arg W) (env x)
|return f
|
| Note that compile1 has an explicit type signature much along the lines
| suggested by GHC. If I *remove* this type signature, the function
| compiles successfully, and ghci reporets this type for compile1:
|
| compile1 :: (Builder t box) = t1 - Name - Ir.ANF - t t1
|
| I believe this signature is isomorphic to the explicit signature I had
| attempted to use.
|
| Am I misusing the type-class system in some way, or should I be
| reporting a bug in GHC?
|
|
| Norman
|
| ___
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] GHC Error question
[redirecting to ghc users]
It looks like a splendid error to me.
I'm not sure if you meant the error or the message was splendid :-)
I yelled for help because my usual strategy failed. That strategy is
1. Remove the type annotation.
2. Get ghci to tell me what the 'right type' is.
3. Put the 'right type' in the type annotation.
I find it a bit depressing that the most general type inferred by ghci
does not work as a type signature.
I can't say more without seeing the code. can you give a small repo case?
Yes, here's a case that fits in one screen of emacs :-)
{-# OPTIONS -fglasgow-exts #-}
module Ccomp where
type Name = String
data Inface = N | W
data Outface = S | E
data Sink box = Boxin Inface box | Result
data Source box = Boxout Outface box | Arg Inface
data Command = Send0
class (Monad b) = Builder b box where
box :: Command - b box
wire :: Source box - Sink box - b ()
type Env box = Name - Sink box
empty = \x - error (x ++ not connected or multiply connected in circuit)
-- either of these explicit signatures causes the compiler to fail
-- although the inferred signature is the second.
--compile1 :: (Builder b box) = Name - Name - ANF - b Name
compile1 :: (Builder t box) = t1 - Name - ANF - t t1 -- generated by ghci
compile1 f x body = do env - compile body empty
wire (Arg W) (env x)
return f
data ANF = ANF ()
compile :: (Builder b box) = ANF - Env box - b (Env box)
compile (ANF m) out = undefined
| This program is rejected by GHC with the following message:
|
| Ccomp.hs:54:23:
| Could not deduce (Builder b box1) from the context (Builder b box)
| arising from use of `wire' at Ccomp.hs:54:23-42
| Possible fix:
| add (Builder b box1) to the type signature(s) for `compile1'
| In the expression: wire (Arg W) (env x)
| In a 'do' expression: wire (Arg W) (env x)
| In the expression:
| do env - compile body empty
|wire (Arg W) (env x)
|return f
|
| Note that compile1 has an explicit type signature much along the lines
| suggested by GHC. If I *remove* this type signature, the function
| compiles successfully, and ghci reporets this type for compile1:
|
| compile1 :: (Builder t box) = t1 - Name - Ir.ANF - t t1
|
| I believe this signature is isomorphic to the explicit signature I had
| attempted to use.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [Haskell] GHC Error question
I agree that this is confusing. Here is a cut-down example:
class C a b where
op :: a - a
-- f :: C a b = a - a
f x = op x
It doesn't get much simpler than that! With the type sig, GHC can't see that
the (C a b) provided can satisfy the (C a b1) which arises from the call to op.
However, without the constraint, GHC simply abstracts over the constrains
arising in the RHS, namely (C a b1), and hence infers the type
f :: C a b1 = a - a
It is extremely undesirable that the inferred type does not work as a type
signature, but I don't see how to fix it
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users-
| [EMAIL PROTECTED] On Behalf Of Norman Ramsey
| Sent: 06 December 2006 01:41
| To: Simon Peyton-Jones
| Cc: GHC users
| Subject: Re: [Haskell] GHC Error question
|
| [redirecting to ghc users]
|
| It looks like a splendid error to me.
|
| I'm not sure if you meant the error or the message was splendid :-)
| I yelled for help because my usual strategy failed. That strategy is
|
| 1. Remove the type annotation.
| 2. Get ghci to tell me what the 'right type' is.
| 3. Put the 'right type' in the type annotation.
|
| I find it a bit depressing that the most general type inferred by ghci
| does not work as a type signature.
|
| I can't say more without seeing the code. can you give a small repo case?
|
| Yes, here's a case that fits in one screen of emacs :-)
|
|
| {-# OPTIONS -fglasgow-exts #-}
| module Ccomp where
|
| type Name = String
|
| data Inface = N | W
| data Outface = S | E
|
| data Sink box = Boxin Inface box | Result
| data Source box = Boxout Outface box | Arg Inface
|
| data Command = Send0
|
| class (Monad b) = Builder b box where
| box :: Command - b box
| wire :: Source box - Sink box - b ()
|
| type Env box = Name - Sink box
|
| empty = \x - error (x ++ not connected or multiply connected in circuit)
|
| -- either of these explicit signatures causes the compiler to fail
| -- although the inferred signature is the second.
| --compile1 :: (Builder b box) = Name - Name - ANF - b Name
| compile1 :: (Builder t box) = t1 - Name - ANF - t t1 -- generated by ghci
| compile1 f x body = do env - compile body empty
|wire (Arg W) (env x)
|return f
|
| data ANF = ANF ()
|
| compile :: (Builder b box) = ANF - Env box - b (Env box)
| compile (ANF m) out = undefined
|
| | This program is rejected by GHC with the following message:
| |
| | Ccomp.hs:54:23:
| | Could not deduce (Builder b box1) from the context (Builder b box)
| | arising from use of `wire' at Ccomp.hs:54:23-42
| | Possible fix:
| | add (Builder b box1) to the type signature(s) for `compile1'
| | In the expression: wire (Arg W) (env x)
| | In a 'do' expression: wire (Arg W) (env x)
| | In the expression:
| | do env - compile body empty
| |wire (Arg W) (env x)
| |return f
| |
| | Note that compile1 has an explicit type signature much along the lines
| | suggested by GHC. If I *remove* this type signature, the function
| | compiles successfully, and ghci reporets this type for compile1:
| |
| | compile1 :: (Builder t box) = t1 - Name - Ir.ANF - t t1
| |
| | I believe this signature is isomorphic to the explicit signature I had
| | attempted to use.
| ___
| 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
[Haskell] Re: haddock not finding base lib docs -- $topdir ?
Conal Elliott wrote: I'm running haddock for the first time, via cabal. I get the following message when i do runhaskell Setup.hs haddock on monadLib: Warning: cannot use package base-2.0: HTML directory $topdir\html\libraries\base does not exist. I do have c:/ghc/ghc-6.6/doc/html/libraries/base/. Is there some way i can let cabal know how to find it? What is $topdir about? This is due to the way GHC is installed on Windows, the package database doesn't have hardcoded pathnames, the idea being that you can move your GHC anywhere in the filesystem and it will still work. Unfortunately this means that Haddock can't find the documentation for the packages. One workaround is to specify the paths by hand, using Haddock's --read-interface flag. You're using Haddock via Cabal though, so that doesn't work too well. The other workaround is to find GHC's package.conf file and replace the string $topdir with the literal path (c:/ghc/ghc-6.6 in your case - perhaps you have to append /doc for the haddock fields, though). I'll file a bug report against Cabal, we should really make this work. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: haddock not finding base lib docs -- $topdir ?
Simon Marlow wrote: Conal Elliott wrote: I'm running haddock for the first time, via cabal. I get the following message when i do runhaskell Setup.hs haddock on monadLib: Warning: cannot use package base-2.0: HTML directory $topdir\html\libraries\base does not exist. I do have c:/ghc/ghc-6.6/doc/html/libraries/base/. Is there some way i can let cabal know how to find it? What is $topdir about? This is due to the way GHC is installed on Windows, the package database doesn't have hardcoded pathnames, the idea being that you can move your GHC anywhere in the filesystem and it will still work. Unfortunately this means that Haddock can't find the documentation for the packages. One workaround is to specify the paths by hand, using Haddock's --read-interface flag. You're using Haddock via Cabal though, so that doesn't work too well. The other workaround is to find GHC's package.conf file and replace the string $topdir with the literal path (c:/ghc/ghc-6.6 in your case - perhaps you have to append /doc for the haddock fields, though). I'll file a bug report against Cabal, we should really make this work. I just noticed we have a bug open for this in GHC's bug tracker: http://hackage.haskell.org/trac/ghc/ticket/937 So it should get fixed for 6.6.1. Cheers, SImon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] How to use STM in GUI applications?
Lemmih wrote: On 12/4/06, Thorsten Seitz [EMAIL PROTECTED] wrote: Hello, I'm very intrigued by the concepts of STM but I'm having difficulties to see how a TVar based model can be used by a GUI application (e.g. Gtk2hs): For example, I'd like to update the GUI (e.g. changing widget sensitivity) upon changes in the model. But changing the sensitivity of a widget is an IO operation which cannot be initiated atomically by a model change which is an STM operation. Therefore the GUI change cannot be executed atomically together with the model change. This means for example that I can still press a button although the model has changed such that the button action is not allowed anymore. All I can do is check the condition of the model when the button is pressed and then ignore the button press which is not very satisfying for the user. Is it simply not appropriate to use TVar based models in a GUI application? Maybe STM should be more used like a service for MVar based GUI models? How about making a list of IO actions to be executed when the transaction commits? That onCommit list and its execution can be done by using the slightly modified/enhanced/wrapped AdvSTM monad. A complex example that also can queue actions on retry is at http://haskell.org/haskellwiki/?title=New_monads/MonadAdvSTM#Helper_Thread_Code But for just onCommit the simpler code at http://haskell.org/haskellwiki/New_monads/MonadAdvSTM#Just_onCommit should work. Cheers, Chris ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: haddock not finding base lib docs -- $topdir ?
This is due to the way GHC is installed on Windows, the package database doesn't have hardcoded pathnames, the idea being that you can move your GHC anywhere in the filesystem and it will still work. this is an essential feature (for instance, running GHC from a USB or network drive, or just unpacking snapshots without using installers), please do not start splicing in absolute paths! Unfortunately this means that Haddock can't find the documentation for the packages. this part I do not understand - if GHC and ghc-pkg can find the packages, why can't Haddock? wouldn't it just be a case of making $topdir be in a fixed relationship to the output of ghc --print-libdir? or should there be a way to query ghc-pkg for the list of package location roots? as you say, the main docs will be in a known location relative to GHC, but perhaps docs in general should be be in a known location relative to their packages, which ghc-pkg (or other tools for other implementations) should be able to locate? One workaround is to specify the paths by hand, using Haddock's --read-interface flag. You're using Haddock via Cabal though, so that doesn't work too well. The other workaround is to find GHC's package.conf file and replace the string $topdir with the literal path (c:/ghc/ghc-6.6 in your case - perhaps you have to append /doc for the haddock fields, though). will all docs be moved into `ghc --print-libdir`\\doc? what about local/user package databases? Claus ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] What guarantees (if any) do interruptible operations have in presence of asynchronous exceptions?
From the discussion of Help needed interrupting accepting a network connection, what we have so far is: * To break out of an accept call, an asynchronous exception is needed. * The presence of asynchronous exceptions complicates the other code used to report if accept completed or was interrupted, whether that code is written using MVar's or STM. Thus the next question is what guarantees, if any, do interruptible operations possess? For example, suppose that inside of a block, a putMVar operation was guaranteed to either interrupt and allow an asynchronous exception to be raised, or to complete the putMVar operation, but not both. If this were true, then if you caught an asynchronous exception from the putMVar operation, you'd know that a value was not put into the MVar by the operation. Then it would be easy to program with MVar's in the presence of asynchronous exceptions. When you caught an asynchronous exception, you could set a flag, and then redo the putMVar. The same question can be asked of other interruptible operations. For the accept call itself, is it guaranteed (inside of a block) to either accept a connection, or be interrupted and allow an asynchronous exception to be raised, but not both? For STM, is atomically an interruptible operation? If it is, what guarantees does it offer in the presence of asynchronous exceptions? ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Bug: Safepoint does not work as documented in paper
One odd problem: The paper on async exception defines:
safePoint = unblock (return ())
but this simply does not work in my testing. Ever. Even using
{-# NOINLINE safePoint #-} or -Onot
By comparision, this does work: safepoint = unblock (print safe)
So how can such a safePoint be written?
--
Chris
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] What guarantees (if any) do interruptible operations have in presence of asynchronous exceptions?
Making small programs to test these properties is a good sanity check. For instance I just leaned that safePoint = unblock ( return () ) does not work. What I think happens: Cat Dancer wrote: From the discussion of Help needed interrupting accepting a network connection, what we have so far is: * To break out of an accept call, an asynchronous exception is needed. * The presence of asynchronous exceptions complicates the other code used to report if accept completed or was interrupted, whether that code is written using MVar's or STM. Thus the next question is what guarantees, if any, do interruptible operations possess? During unblock anything can happen. During block: No async. exceptions are raised, unless... ...the block is lifted by an interruptible operation The will only happen when that operation must block. For example, suppose that inside of a block, a putMVar operation was guaranteed to either interrupt and allow an asynchronous exception to be raised, or to complete the putMVar operation, but not both. A putMVar will only allow interruptions insofar as it must wait for the MVar to become empty. So while it is waiting on the MVar it may receive an async. exception and so will not perform the put operation. If this were true, then if you caught an asynchronous exception from the putMVar operation, you'd know that a value was not put into the MVar by the operation. I think that should be a safe assumption when running under block. Then it would be easy to program with MVar's in the presence of asynchronous exceptions. When you caught an asynchronous exception, you could set a flag, and then redo the putMVar. If you call that easy then sure. The same question can be asked of other interruptible operations. For the accept call itself, is it guaranteed (inside of a block) to either accept a connection, or be interrupted and allow an asynchronous exception to be raised, but not both? That should be true, for the same reason as putMVar. For STM, is atomically an interruptible operation? If it is, what guarantees does it offer in the presence of asynchronous exceptions? block (atomically stm) is interruptible when the operation stm uses retry and perhaps when it has to be re-attempted due to conflicting updates. If it runs without conflict and commits then it cannot be interrupted by an async exception. If (atomically stm) is interrupted then it is rolled back and will have had no visible side effects. -- Chris ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] What guarantees (if any) do interruptible operations have in presence of asynchronous exceptions?
On 12/5/06, Chris Kuklewicz [EMAIL PROTECTED] wrote: Making small programs to test these properties is a good sanity check. For instance I just leaned that safePoint = unblock ( return () ) does not work. Maybe if you do something to allocate some memory inside of the unblock? If this were true, then if you caught an asynchronous exception from the putMVar operation, you'd know that a value was not put into the MVar by the operation. I think that should be a safe assumption when running under block. I think and should be is nice, how do we find out if it's really true -- for sure? Then it would be easy to program with MVar's in the presence of asynchronous exceptions. When you caught an asynchronous exception, you could set a flag, and then redo the putMVar. If you call that easy then sure. For STM, is atomically an interruptible operation? If it is, what guarantees does it offer in the presence of asynchronous exceptions? block (atomically stm) is interruptible when the operation stm uses retry and perhaps when it has to be re-attempted due to conflicting updates. If it runs without conflict and commits then it cannot be interrupted by an async exception. If (atomically stm) is interrupted then it is rolled back and will have had no visible side effects. Easy in the sense that the pattern of trying an operation, setting a flag if an asynchronous exception is raised, and redoing the operation can be encapsulated in a function. That function can then be used with any interruptible operation (such as putMVar, or atomically, or accept) *if* the operation guarantees that inside of a block it will either perform its operation, or interrupt and allow an asynchronous to be raised, but not both. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] What guarantees (if any) do interruptible operations have in presence of asynchronous exceptions?
Cat Dancer wrote: On 12/5/06, Chris Kuklewicz [EMAIL PROTECTED] wrote: Making small programs to test these properties is a good sanity check. For instance I just leaned that safePoint = unblock ( return () ) does not work. Maybe if you do something to allocate some memory inside of the unblock? If this were true, then if you caught an asynchronous exception from the putMVar operation, you'd know that a value was not put into the MVar by the operation. I think that should be a safe assumption when running under block. I think and should be is nice, how do we find out if it's really true -- for sure? Read the papers the have been written about the design (see the wiki for links) and ask the developers of the compiler you are using. nicely. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] GHC Error question
Without going too deep into the details of my type classes, I have
written the following code (focusing on compile1):
{-# OPTIONS -fglasgow-exts #-}
compile1 :: (Builder b box) = t - Name - Ir.ANF - b t
compile1 f x body = do env - compile body empty
wire (Arg W) (env x)
return f
compile :: (Builder b box) = Ir.ANF - Env box - b (Env box)
class (Monad b) = Builder b box where
wire:: Source box - Sink box - b ()
...
type Env box = Name - Sink box
This program is rejected by GHC with the following message:
Ccomp.hs:54:23:
Could not deduce (Builder b box1) from the context (Builder b box)
arising from use of `wire' at Ccomp.hs:54:23-42
Possible fix:
add (Builder b box1) to the type signature(s) for `compile1'
In the expression: wire (Arg W) (env x)
In a 'do' expression: wire (Arg W) (env x)
In the expression:
do env - compile body empty
wire (Arg W) (env x)
return f
Note that compile1 has an explicit type signature much along the lines
suggested by GHC. If I *remove* this type signature, the function
compiles successfully, and ghci reporets this type for compile1:
compile1 :: (Builder t box) = t1 - Name - Ir.ANF - t t1
I believe this signature is isomorphic to the explicit signature I had
attempted to use.
Am I misusing the type-class system in some way, or should I be
reporting a bug in GHC?
Norman
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] cabal + haddock on Windows default paths working?
When I configure libraries (monadLib, arrows) with default locations and then cabal-haddock my own library, I get this sort of warning: Warning: cannot use package arrows-0.2: HTML directory C:\\Program Files\\Common Files\\arrows-0.2\\doc\\html does not exist. That directory *does* exist, however, and contains the arrow library's haddock-generated files. Any ideas? Is any Windows haddock user *not* having this problem? Am I running into a bug in handling of path names with embedded spaces? Thanks,- Conal ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: haddock not finding base lib docs -- $topdir ?
Thanks for the explanation suggestions, Simon. Your other workaround worked for me: I replaced $topdir\\html with c:\\ghc\\ghc-6.6\\doc\\html in my package.conf. Note the *doc*, so a straightforward $topdir splice would not do the trick. Cheers, - Conal On 12/5/06, Simon Marlow [EMAIL PROTECTED] wrote: Conal Elliott wrote: I'm running haddock for the first time, via cabal. I get the following message when i do runhaskell Setup.hs haddock on monadLib: Warning: cannot use package base-2.0: HTML directory $topdir\html\libraries\base does not exist. I do have c:/ghc/ghc-6.6/doc/html/libraries/base/. Is there some way i can let cabal know how to find it? What is $topdir about? This is due to the way GHC is installed on Windows, the package database doesn't have hardcoded pathnames, the idea being that you can move your GHC anywhere in the filesystem and it will still work. Unfortunately this means that Haddock can't find the documentation for the packages. One workaround is to specify the paths by hand, using Haddock's --read-interface flag. You're using Haddock via Cabal though, so that doesn't work too well. The other workaround is to find GHC's package.conf file and replace the string $topdir with the literal path (c:/ghc/ghc-6.6 in your case - perhaps you have to append /doc for the haddock fields, though). I'll file a bug report against Cabal, we should really make this work. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] cabal + haddock on Windows default paths working?
It seems like Cabal is looking for directory html i.e. with trailing space. This sounds like a bug. Cheers, Krasimir On 12/5/06, Conal Elliott [EMAIL PROTECTED] wrote: When I configure libraries (monadLib, arrows) with default locations and then cabal-haddock my own library, I get this sort of warning: Warning: cannot use package arrows-0.2: HTML directory C:\\Program Files\\Common Files\\arrows-0.2\\doc\\html does not exist. That directory *does* exist, however, and contains the arrow library's haddock-generated files. Any ideas? Is any Windows haddock user *not* having this problem? Am I running into a bug in handling of path names with embedded spaces? Thanks,- Conal ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] using greencard to write COM in haskell
Hello Anatoly, Tuesday, December 5, 2006, 1:32:27 AM, you wrote: Also, I would like to have my haskell programs use my implementation of realloc which takes a context, is there an easy way to change ghc to use it? I guess I should start looking at the ghc source. for which operations? if you mean using it for Haskell objects - it's impossible, because ghc by itself has very sophisticated memory control strategy -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] unexpected compiler behavior
Hi, I am newbie in Haskell and do not understand why the interpreted mode differs from the compiled program. I run this code main = do putStr line1 x-getLine putStr line2 y-getLine return (x++y) either under runhugs or runghc or in a console under ghci and works properly, that is, first displays line1 and then prompts for the corresponding inputs through the keyboard, and so on. However, if I compile the code with the command line ghc --make Main.hs -o main and launch the compiled program main, then at first prompts for the input lines through the keyboard and then displays the strings line1 line2. I have read in the tutorials that the command do implies an ordered execution and this only occurs in interpreted mode. Using the monadic notation , = occurs the same unordered behavior. ¿How can I avoid the unordered execution of this code in a compiled program? Thanks in advance. jepalomar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unexpected compiler behavior
The problem is most likely that line-buffered (or possibly block-buffered) IO is turned on, which means that buffers will only automatically be flushed to the display at the ends of lines. You can fix it by importing System.IO, and either calling (hFlush stdout) explicitly, or by calling (hSetBuffering NoBuffering stdout) at the start of your program. On 05/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I am newbie in Haskell and do not understand why the interpreted mode differs from the compiled program. I run this code main = do putStr line1 x-getLine putStr line2 y-getLine return (x++y) either under runhugs or runghc or in a console under ghci and works properly, that is, first displays line1 and then prompts for the corresponding inputs through the keyboard, and so on. However, if I compile the code with the command line ghc --make Main.hs -o main and launch the compiled program main, then at first prompts for the input lines through the keyboard and then displays the strings line1 line2. I have read in the tutorials that the command do implies an ordered execution and this only occurs in interpreted mode. Using the monadic notation , = occurs the same unordered behavior. ¿How can I avoid the unordered execution of this code in a compiled program? Thanks in advance. jepalomar ___ 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
Re: [Haskell-cafe] unexpected compiler behavior
jepalomar23: Hi, I am newbie in Haskell and do not understand why the interpreted mode differs from the compiled program. I run this code main = do putStr line1 x-getLine putStr line2 y-getLine return (x++y) either under runhugs or runghc or in a console under ghci and works properly, that is, first displays line1 and then prompts for the corresponding inputs through the keyboard, and so on. However, if I compile the code with the command line ghc --make Main.hs -o main and launch the compiled program main, then at first prompts for the input lines through the keyboard and then displays the strings line1 line2. I have read in the tutorials that the command do implies an ordered execution and this only occurs in interpreted mode. Using the monadic notation , = occurs the same unordered behavior. ?How can I avoid the unordered execution of this code in a compiled program? Sounds like the difference in buffering between the interactive environments and compiled code. Try: import System.IO main = do hSetBuffering stdout NoBuffering putStr line1 x - getLine putStr line2 y - getLine print (x++y) Running this: $ ./a.out line1 1 line2 2 12 -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock not finding base lib docs -- $topdir ?
[ moving to haskell-cafe@haskell.org ] Claus Reinke wrote: This is due to the way GHC is installed on Windows, the package database doesn't have hardcoded pathnames, the idea being that you can move your GHC anywhere in the filesystem and it will still work. this is an essential feature (for instance, running GHC from a USB or network drive, or just unpacking snapshots without using installers), please do not start splicing in absolute paths! Don't worry, we don't intend to do that. Unfortunately this means that Haddock can't find the documentation for the packages. this part I do not understand - if GHC and ghc-pkg can find the packages, why can't Haddock? wouldn't it just be a case of making $topdir be in a fixed relationship to the output of ghc --print-libdir? well yes, but Haddock doesn't invoke 'ghc --print-libdir'. I think it would be better for ghc-pkg to hide $topdir from everyone by replacing it with its value in any ghc-pkg output. After all, $topdir is just a hack to make the GHC tree location-independent on Windows, it's not a documented feature of the package system. or should there be a way to query ghc-pkg for the list of package location roots? as you say, the main docs will be in a known location relative to GHC, but perhaps docs in general should be be in a known location relative to their packages, which ghc-pkg (or other tools for other implementations) should be able to locate? One workaround is to specify the paths by hand, using Haddock's --read-interface flag. You're using Haddock via Cabal though, so that doesn't work too well. The other workaround is to find GHC's package.conf file and replace the string $topdir with the literal path (c:/ghc/ghc-6.6 in your case - perhaps you have to append /doc for the haddock fields, though). will all docs be moved into `ghc --print-libdir`\\doc? No. Docs can be installed wherever you like. Cabal has a policy for installation locations on Windows, which you can override if you want. what about local/user package databases? Same here, you can install things wherever you like. In fact, installing things inside the GHC tree isn't recommended. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Picking out elements of a heterogenous list
Hi Haskell-ers, So I think I understand the idea of creating a heterogenous list using typeclasses and existentials, but I don't see how to filter the list to retrieve elements of the list that are of only one type. More concretely, taking the example herehttp://haskell.org/haskellwiki/Existential_typehow could we take a list of shapes [Shape] and pull out all objects that are Squares? I don't see an obvious way this makes sense. Is there a way of doing heterogenous lists that would make this possible? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Picking out elements of a heterogenous list
To: Creighton Hogg [EMAIL PROTECTED] Subject: Re: [Haskell-cafe] Picking out elements of a heterogenous list From: Steve Schafer [EMAIL PROTECTED] Date: Tue, 05 Dec 2006 12:33:16 -0500 On Tue, 5 Dec 2006 11:08:07 -0600, you wrote: Hi Haskell-ers, So I think I understand the idea of creating a heterogenous list using typeclasses and existentials, but I don't see how to filter the list to retrieve elements of the list that are of only one type. More concretely, taking the example herehttp://haskell.org/haskellwiki/Existential_typehow could we take a list of shapes [Shape] and pull out all objects that are Squares? I don't see an obvious way this makes sense. Is there a way of doing heterogenous lists that would make this possible? Use filter, passing it a predicate that returns True for Squares and False otherwise: isASquare :: Shape - Bool isASquare (Square _) = True isASquare _ = False filter isASquare myShapes Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Picking out elements of a heterogenous list
On Tue, Dec 05, 2006 at 11:08:07AM -0600, Creighton Hogg wrote: Hi Haskell-ers, So I think I understand the idea of creating a heterogenous list using typeclasses and existentials, but I don't see how to filter the list to retrieve elements of the list that are of only one type. More concretely, taking the example herehttp://haskell.org/haskellwiki/Existential_typehow could we take a list of shapes [Shape] and pull out all objects that are Squares? I don't see an obvious way this makes sense. Is there a way of doing heterogenous lists that would make this possible? It's ugly but you could stick converters in the class itself: class MyClass a where isTypeA :: a - Maybe A isTypeA _ = Nothing isTypeB :: a - Maybe B isTypeB _ = Nothing isTypeC :: a - Maybe C isTypeC _ = Nothing This limits you to a finite number of specific types, but I suspect that's unavoidable. Actually, your list can have any number of types in it, but you can only extract a fixed set of types. Another perhaps prettier way to do this would be to use an ADT to hold the elements of your list, so that the existentials could be reconstructed by pattern matching: data FunnyElement = ElemA A | ElemB B | ElemC C Again, it only works for lists containing a fixed set of types. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Download locations for former-base libraries?
Hi, I am working on updating and splitting things out of MissingH. MissingH is going to depend on regex-compat, HUnit, QuickCheck, and FilePath, among others. For each such library, I need to be able to tell users where they can go to download the dependency. But I'm having a lot of trouble finding canonical download locations. For instance, the homepage of regex-compat, according to http://darcs.haskell.org/packages/regex-compat/regex-compat.cabal, is http://sourceforge.net/projects/lazy-regex. But the software available for download there doesn't even provide Text.Regex. Of course, just saying download the latest version with darcs isn't useful, either. People that want to use my package shouldn't have to have darcs, and they also shouldn't have to fight with broken development software. Or should I be telling people to download the GHC 6.6 extralibs source? That doesn't seem quite right either; it's packaged as a tar.bz2, but what would a Windows user with HUGS do? That person probably couldn't even unpack it. Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Download locations for former-base libraries?
Hi Of course, just saying download the latest version with darcs isn't useful, either. People that want to use my package shouldn't have to have darcs, and they also shouldn't have to fight with broken development software. Or should I be telling people to download the GHC 6.6 extralibs source? That doesn't seem quite right either; it's packaged as a tar.bz2, but what would a Windows user with HUGS do? That person probably couldn't even unpack it. I started doing some work towards this on windows: http://www-users.cs.york.ac.uk/~ndm/projects/windows.php I found that generally working out of the darcs repo's is both horribly unreliable, but the easiest way to go about it, because its more consistent. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Download locations for former-base libraries?
On Tue, Dec 05, 2006 at 12:18:25PM -0600, John Goerzen wrote: For each such library, I need to be able to tell users where they can go to download the dependency. But I'm having a lot of trouble finding canonical download locations. For instance, the homepage of regex-compat, according to http://darcs.haskell.org/packages/regex-compat/regex-compat.cabal, is http://sourceforge.net/projects/lazy-regex. But the software available for download there doesn't even provide Text.Regex. Of course, just saying download the latest version with darcs isn't useful, either. People that want to use my package shouldn't have to have darcs, and they also shouldn't have to fight with broken development software. You could direct them to http://hackage.haskell.org/packages/unstable/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Picking out elements of a heterogenous list
I generally use the Typeable class for this. In that example, you'd want: class Typeable a = Shape_ a instead of just class Shape_ a and then your filter predicate would look like: isSquare :: Shape - Bool isSquare (Shape s) = typeOf s == typeOf square where square :: Square ; square = undefined (warning: I didn't try this code.) That adds a little overhead (particularly in that everything must now derive Typeable) but is one of the better solutions I've seen. /g On 12/5/06, Creighton Hogg [EMAIL PROTECTED] wrote: Hi Haskell-ers, So I think I understand the idea of creating a heterogenous list using typeclasses and existentials, but I don't see how to filter the list to retrieve elements of the list that are of only one type. More concretely, taking the example here how could we take a list of shapes [Shape] and pull out all objects that are Squares? I don't see an obvious way this makes sense. Is there a way of doing heterogenous lists that would make this possible? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- It is myself I have never met, whose face is pasted on the underside of my mind. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GADT vs Arrows for parsers/FSMs/etc.
It seems like Haskell has two emerging idioms for parsing and fsms: GADTs and Arrows. I am thinking about using one of these idioms to represent server structure in a future version of HAppS but I'm not sure where to start. Why would one choose one or the other? -Alex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GADT vs Arrows for parsers/FSMs/etc.
Hi It seems like Haskell has two emerging idioms for parsing and fsms: GADTs and Arrows. What about something else? If you limit yourself to the two things that look new and cool (where emerging is another word for new, and idiom seems to be the current Haskell word for cool), you miss out on all the tried and tested stuff. I am thinking about using one of these idioms to represent server structure in a future version of HAppS but I'm not sure where to start. Why would one choose one or the other? I would pick Arrows (over GADTs) because Arrows are Haskell, and are supported by multiple Haskell compilers. Other than that (as far as I was aware) these two things are massively different, so I wouldn't have thought it was a one or the other choice usually. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Download locations for former-base libraries?
Ross Paterson wrote: You could direct them to http://hackage.haskell.org/packages/unstable/ Is that site guaranteed to have the same packages/versions as the ghc extralibs has? Oh, and BTW, does cabal-put work with the current cabal in GHC 6.6 these days? I would love to be able to upload my packages to your repo automatically, but not at the cost of installing a different Cabal on my box. Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] state updates and efficiency
I am writing some code with complex nested state. I have a question
about performance with respect to the State monad and the Reader monad.
This is somewhat long, so a quick summary of the question up front:
Can the compiler optimize out state updates that dont change the
state?
The question inline with the code:
module Test where
import Control.Monad.State
import Control.Monad.Reader
I have some nested state. This is a simplified example where
we have one record inside another. In my real-world example there
is more nesting and there are lists and maps involved as well.
data T1 = T1 { f1 :: Int, f2 :: T2 } deriving(Show)
data T2 = T2 { f3 :: Int, f4 :: Int } deriving(Show)
I want to build generic modifiers and reuse them often.
A good example is modifying a numeric value:
adjNum :: (Num a) = a - State a ()
adjNum n = modify (+ n)
I'm going to be writing state code for my T1 structure which is my
master structure. If I'm going to be able to reuse adjNum I am
going to have to run a nested state action inside an enclosing
state monad. I can build a lifter that does this as long as
I know how to extract the nested state and set it back in the
enclosing state:
withInnerM :: (o - i) - (i - o - o) - State i a - State o a
withInnerM gettor settor act = do
outer - get
let inner = gettor outer
(ret, inner') = runState act inner
outer' = settor inner' outer
put outer'
return ret
Now we can make lifters for each of the fields:
withF1M = withInnerM f1 (\f r - r {f1=f})
withF2M = withInnerM f2 (\f r - r {f2=f})
withF3M = withInnerM f3 (\f r - r {f3=f})
withF4M = withInnerM f4 (\f r - r {f4=f})
which lets us write some state code for T1 using building blocks like
adjNum. For example, the following code will add a value to
f1, add another value to f2's f3 and finally return the value of f2's
f4:
tweakT1 :: Int - Int - State T1 Int
tweakT1 v1 v3 = do
withF1M $ adjNum v1
withF2M $ withF3M $ adjNum v3
withF2M $ withF4M $ get
My question here has to do with efficiency. In order to update
f2's f3 a new T2 had to be constructed and used to construct a
new T1. There's no way around this (I assume). But when doing
a mere get of f4, there's no reason why we should have to build a
new T2 and then a new T1 since nothign changed. But that's how
the code is written.
We could write a different lifter that does not perform a state
put on the return path. If we did this with the state monad then
someone could accidentally use that non-modify version of the lifter
and lose an update. So instead I chose to use the Reader monad and
let the type system enforce the difference between lifters that
modify (M) and those that just read (R). This involved two kinds
of lifters.
The first lifter runs a Reader action inside of a State monad:
withRead :: Reader s a - State s a
withRead act = do
s - get
return $ runReader act s
The second lifter runs a nested Reader action inside of an enclosing
Reader monad. It is similar in spirit to withInnerM:
withInnerR :: (o - i) - Reader i a - Reader o a
withInnerR gettor act = do
i - asks gettor
return $ runReader act i
again we can generate lifters for each field:
withF1R = withInnerR f1
withF2R = withInnerR f2
withF3R = withInnerR f3
withF4R = withInnerR f4
And finally we can use a reader monad to eliminate the extra state
updates from our previous tweakT1 implementation:
tweakT1' :: Int - Int - State T1 Int
tweakT1' v1 v3 = do
withF1M $ adjNum v1
withF2M $ withF3M $ adjNum v3
withRead $ withF2R $ withF4R $ ask
main = do
let x = T1 1 (T2 3 4)
print $ runState (tweakT1 5 6) x
print $ runState (tweakT1' 5 6) x
My question here is: is it worth it?
If I run
v1 = T2 1 1
v2 = v1 {f3 = 1}
is the compiler smart enough to notice that the record update doesn't
result in a change, and avoid constructing an entirely new T2?
If so, then I think the original implementation TweakT1 would be
about as efficient as the more complicated TweakT1'. Otherwise,
I think the latter would be a lot more efficient when the state is
large and complex.
Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Download locations for former-base libraries?
On Tue, Dec 05, 2006 at 02:57:36PM -0600, John Goerzen wrote: Ross Paterson wrote: You could direct them to http://hackage.haskell.org/packages/unstable/ Is that site guaranteed to have the same packages/versions as the ghc extralibs has? For the extralibs, those version numbers denote the versions bundled with GHC 6.6. Later versions will have different numbers. (And maybe the directory name could change; unstable sounds a bit unsettling for non-Debian users.) Oh, and BTW, does cabal-put work with the current cabal in GHC 6.6 these days? I would love to be able to upload my packages to your repo automatically, but not at the cost of installing a different Cabal on my box. The old cabal-put is no longer in use -- now there's just a script of the same name on hackage.haskell.org, which you have to be in group hackage to use. Isaac would presumably be happy to add you. There's no upload tool yet, for lack of someone to write it, but I hope the new version will be just a password-protected CGI file upload. That would be less secure than a public key setup, but would avoid needing special software on the client side. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HOgg 0.2.0 Released
HOgg 0.2.0 Released --- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. http://snapper.kfish.org/~conrad/software/hogg/ This is the initial public release. The focus is on correctness of Ogg parsing and production. The capabilities of the hogg commandline tool are roughly on par with those of the oggz* tools[0], although hogg does not yet provide an equivalent to oggz-validate. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt Installation I am very interested in hearing about problems with building or installing the package, particularly from people who are not yet familiar with building from Haskell source. You need ghc instead of gcc; it compiles to a binary: $ ./Setup.hs configure $ ./Setup.hs build $ sudo ./Setup.hs install Building of this release has been tested with: * GHC versions 6.4 and 6.6 [2] * The Haskell build system Cabal versions 1.1.3, 1.1.4, 1.1.6, and the current development trunk. [3] * fps (Data.ByteString.Lazy) version 0.7, and development trunk. [4] Note that if you are using the recently-released GHC 6.6 then you will not need separate installs of Cabal or fps. You will however need to remove the word fps from the hogg.cabal file; see the README for details. The GHC and Cabal versions listed above span the packages available in most current distributions. I've tested on Debian unstable, Ubuntu Dapper and Ubuntu Edgy. I'm particularly interested to hear reports of build success or failure on other distributions or operating systems. [2] GHC: http://www.haskell.org/ghc/ [3] Cabal: http://www.haskell.org/cabal/ [4] fps: http://www.cse.unsw.edu.au/~dons/fps.html Usage - $ hogg help Usage: hogg subcommand [options] filename ... Commands: help Display help for a specific subcommand Reporting: info Display information about the file and its bitstreams dump Hexdump packets of an Ogg file pagedump Display page structure of an Ogg file dumpraw Dump raw (unparsed) page data Extraction: rip Rip selected logical bistreams from an Ogg file (default: all) reconstruct Reconstruct an Ogg file by doing a full packet demux Editing: merge Merge, interleaving pages in order of presentation time addskel Write a Skeleton logical bitstream Source -- Source code is available from the darcs repository at: darcs get http://snapper.kfish.org/~conrad/software/hogg/ cheers, Conrad. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] There's nothing wrong with infinite types!
I'm sure anyone who's used Haskell for any significant length of time has received this error message: Occurs check: cannot construct the infinite type: t = t - t1 I for one took that as a challenge, and have implemented a type inference engine for infinite types. Expr s (a - b - c) - (a - b) - a - c Expr skk a - a Expr s(skk)(skk) (fix a . (a - b)) Expr Points of interest: * There are NO error conditions. it-unifier can assign a type to every syntactically valid expression of combinatory logic. * Typechecking is guaranteed to terminate in a linear number of steps, an (apparently) stronger guarantee than that provided by DHM. * (Mostly theoretical, since it-unify does not yet support sums or products): Fixpoint types subsume declared recursive datatypes. e.g: type List a = fix l . Either () (a,l) darcs get http://members.cox.net/stefanor/fixtypes/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Halp- haskell logic prover
Hey all, I've just finished my logic prover. I've been working on this as an undergraduate project with my advisor. Right now it only supports simple first order logic but in the spring I'll be adding predicates. Theres also a simple gui written in java 5 which is in the darcs repository. Comments are welcome! -Dan http://haskell.org/haskellwiki/Libraries_and_tools/Theorem_provers http://taz.cs.wcupa.edu/~dmead/code/halp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] There's nothing wrong with infinite types!
G'day all. Quoting Stefan O'Rear [EMAIL PROTECTED]: I for one took that as a challenge, and have implemented a type inference engine for infinite types. Very nice! But there's plenty wrong with infinite types... The fact is that infinite types are almost never what you want. In the few situations where it is (usually in data structures), using newtype usually isn't a huge imposition. What you end up with instead is a bunch of programs that are obviously wrong becoming well-typed. Consider the following program: search p [] = error not found search p (x:xs) | p x = x | otherwise = search p xs Let's mutate the otherwise case with some common and some not-so-common bugs: search p [] = error not found search p (x:xs) | p x = x | otherwise = xs search p [] = error not found search p (x:xs) | p x = x | otherwise = search p search p [] = error not found search p (x:xs) | p x = x | otherwise = search xs search p [] = error not found search p (x:xs) | p x = x | otherwise = search search p [] = error not found search p (x:xs) | p x = x | otherwise = p How many of these buggy versions would be type-correct if Haskell allowed infinite types? I'll wait while you go and check with your type checked. ... Are you surprised? I was. Just about every dumb change I could think of making to the otherwise case resulted in what would be a type- correct function, if we allowed infinite types! It wouldn't be so bad if it were unusual cases, but a lot of common programmer mistakes (like leaving arguments off a recursive function call) are only caught because of the occurs check. Catching programmer mistakes is one of the reasons why people like Haskell so much. Given that we have a servicable workaround (newtype), it would be a mistake to allow types like this. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Beginner: IORef constructor?
On 05/12/2006, at 1:00 PM, Benjamin Franksen wrote: Bernie Pope wrote: If you want a global variable then you can use something like: import System.IO.Unsafe (unsafePerformIO) global = unsafePerformIO (newIORef []) But this is often regarded as bad programming style (depends who you talk to). Besides, isn't this example /really/ unsafe? I thought, at least the IORef has to be monomorphic or else type safety is lost? Perhaps your question is rhetorical, but in case it is not, then yes, we ought to make it a monomorphic type. This little example seg-faults on my mac, and no doubt on other machines as well: import System.IO.Unsafe (unsafePerformIO) import Data.IORef global = unsafePerformIO (newIORef []) main = do modifyIORef global (id :) x - readIORef global print ((head x + 1) :: Int) It writes the identity function onto the front of the global variable, and then reads it back as an int, and tries to do addition on it. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
