[Haskell-cafe] Re: Parameterized monad transformers
Also, maybe the lifting operation could be plift :: (PMonad m) = m s1 s2 a - t m s1 s2 s s a where s1 and s2 are passed to the underlying type constructor. That way, the kind of m would be * - * - * - * and the kind of t would be (* - * - * - *) - * - * - * - * - * - * so we see how if we apply the first three types we get * - * - * - *, which is the kind of m. Just thinking out loud basically :] Cheerio! - BONUS ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confused by SYB example with zipping
Hello Henry,
Changes to GHC regarding the treatment of higher-rank types required a few
changes to that test too. You have to eta-expand the application of mkTT and
give it a type signature. Therefore, main becomes
print $ gzip (\x y - mkTT maxS x y) genCom1 genCom2
and you have to add the type signature
mkTT :: (Typeable a, Typeable b, Typeable c) = (a - a - a) - b - c -
Maybe c .
Then this example should work.
As to why exactly these changes are necessary, you might want to check the
GHC manual section on arbitrary-rank polymorphism (
http://haskell.org/ghc/docs/latest/html/users_guide/other-type-extensions.html#universal-quantification
).
Cheers,
Pedro
On Sat, Feb 14, 2009 at 21:55, Henry Laxen nadine.and.he...@pobox.comwrote:
Dear Group,
When trying to run the example at:
http://www.cs.vu.nl/boilerplate/testsuite/gzip/Main.hs
ghc 6.10.1 says
A pattern type signature cannot bind scoped type variables `a'
unless the pattern has a rigid type context
In the pattern: f :: a - a - a
In the definition of `mkTT':
mkTT (f :: a - a - a) x y
= case (cast x, cast y) of {
(Just (x' :: a), Just (y' :: a)) - cast (f x' y')
_ - Nothing }
In the definition of `main':
main = print $ gzip (mkTT maxS) genCom1 genCom2
where
genCom1 = everywhere (mkT (double Joost)) genCom
genCom2 = everywhere (mkT (double Marlow)) genCom
double x (E (p@(P y _)) (S s)) | x == y = E p (S (2 * s))
double _ e = e
maxS (S x) (S y) = S (max x y)
Failed, modules loaded: CompanyDatatypes.
-
I must admit I don't really know what to make of this. Any insights would
be appreciated.
Thanks.
Henry Laxen
___
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: forall ST monad
Peter Verswyvelen wrote: I'm having trouble understanding the explanation of the meaning of the signature of runST at http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types I could try to read the article a couple of times again, but are there any other good readings about these existentially quantified types and how the ST monad works? Maybe http://en.wikibooks.org/wiki/Haskell/Polymorphism can help? Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: hslibsvm-2.88.0.1 - A FFI binding to LibSVM
The result of the fact that I needed to use a support vector machine and didn't want to leave haskell land. LibSVM is a support vector machine library written in C++ with an exposed C interface. More information about LibSVM can be found at: http://www.csie.ntu.edu.tw/~cjlin/libsvm/ This is my first haskell package so any suggestions for improvement are welcome. kind regards Stephan Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Well, I think a type system like Clean's that had linear/uniqueness types could fix the issue by actually checking that the state is single-threaded (and thus stop you from applying it to a forking monad). But there's a fundamental operational problem that ST makes destructive updates, so to support it as a monad transformer in general you'd need a type system that actually introduced fork operations (which linear implicit parameters used to do in GHC , but they were removed because they were quite complicated semantically and noone really used them). From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Louis Wasserman Sent: 16 February 2009 03:31 To: Dan Doel Cc: Henning Thielemann; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl Okay, I tested it out and the arrow transformer has the same problem. I realized this after I sent the last message -- the point is that at any particular point, intuitively there should be exactly one copy of a State# s for each state thread, and it should never get duplicated; allowing other monads or arrows to hold a State# s in any form allows them to hold more than one, violating that goal. I'm not entirely convinced yet that there isn't some really gorgeous type system magic to fix this issue, like the type-system magic that motivates the type of runST in the first place, but that's not an argument that such magic exists...it's certainly an interesting topic to mull. Louis Wasserman wasserman.lo...@gmail.com On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel dan.d...@gmail.com wrote: On Sunday 15 February 2009 9:44:42 pm Louis Wasserman wrote: Hello all, I just uploaded stateful-mtl and pqueue-mtl 1.0.1. The ST monad transformer and array transformer have been removed -- I've convinced myself that a heap transformer backed by an ST array cannot be referentially transparent -- and the heap monad is now available only as a basic monad and not a transformer, though it still provides priority queue functionality to any of the mtl wrappers around it. stateful-mtl retains a MonadST typeclass which is implemented by ST and monad transformers around it, allowing computations in the the ST-bound heap monad to perform ST operations in its thread. Since this discussion had largely led to the conclusion that ST can only be used as a bottom-level monad, it would be pretty uncool if ST computations couldn't be performed in a monad using ST internally because the ST thread was hidden and there was no way to place ST computations 'under' the outer monad. Anyway, it's essentially just like the MonadIO typeclass, except with a functional dependency on the state type. There was a question I asked that never got answered, and I'm still curious: would an ST *arrow* transformer be valid? Arrows impose sequencing on their operations that monads don't... I'm going to test out some ideas, I think. Your proposed type: State (Kleisli []) x y = (s, x) - [(s, y)] is (roughly) isomorphic to: x - StateT s [] y = x - s - [(s, y)] The problem with an ST transformer is that the state parameter needs to be used linearly, because that's the only condition under which the optimization of mutable update is safe. ST ensures this by construction, as opposed to other languages (Clean) that have type systems that can express this kind of constraint directly. However, with STT, whether the state parameter is used linearly is a function of the wrapped monad. You'd have to give a more fleshed out version of your proposed state arrow transformer, but off the top of my head, I'm not sure it'd be any better. -- Dan == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-beginners] Re: [Haskell-cafe] Re: permuting a list
Heinrich Apfelmus wrote: Alberto Ruiz wrote: How about using random doubles? randomPerm xs = fmap (map snd . sort . flip zip xs) rs where rs = fmap (randoms . mkStdGen) randomIO :: IO [Double] Interesting idea. The chance of duplicates should be negligible now, but that's because we're using a large amount of random bits, far more than n! would require. Another possibility is using infinite lists of random bits as keys. Then we only extract from the random number generator the number of bits required to avoid duplicates. -Alberto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: The Typeclassopedia, and request for feedback
Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Here's the abstract: The standard Haskell libraries feature a number of type classes with algebraic or categorical underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs. The goal of this article is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-feedback/ happy haskelling! -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Amazing
Michael D. Adams mdmko...@gmail.com writes: A bit hurray for strong typing! Don't forget Algebraic Data Types. Those seem to also avoid many of the sorts of errors that you would see in OO or struct-based (i.e. C) programming. I think the combination of algebraic data types and strong typing is very potent. Good data modeling lets you build data types that encode/model the legal/valid domain for the data in your application. The narrower your data model, the less room for nonsensical programs. Strong typing enforces the limitations in the data model, and prevents programmers from cheating. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: hslibsvm-2.88.0.1 - A FFI binding to LibSVM
Hi Stephan, it seems you beat me ;-) I've been working on the same thing as well. You'll find my effort at http://bitbucket.org/pao/hsvm/. What is missing is: - the final bindings to complete the API - haddock documentation - cabal setup Unfortunately the commit log are in italian (I didn't plan upfront to publish the repo). I'll try to look at your code ASAP. I'd really like to join our efforts. Ciao Pao S. Günther wrote: The result of the fact that I needed to use a support vector machine and didn't want to leave haskell land. LibSVM is a support vector machine library written in C++ with an exposed C interface. More information about LibSVM can be found at: http://www.csie.ntu.edu.tw/~cjlin/libsvm/ This is my first haskell package so any suggestions for improvement are welcome. kind regards Stephan Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: permuting a list
Paul Johnson p...@cogito.org.uk writes: See http://okmij.org/ftp/Haskell/perfect-shuffle.txt I should have read that first time round! -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Low-level high-level languages?
Maurício briqueabra...@yahoo.com writes: Hi, I've checked this 'BitC' language (www.bitc-lang.org). It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Hume http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml might be worth a look. I've never tried it, and since one of the top chaps associated with it said to me that he loathes Haskell, I'm not sure I should mention it here :-) -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: The Typeclassopedia, and request for feedback
Hi Brent, I want to congratulate you on your article! An excellent piece of work which should be compulsory reading for all serious haskell programmers :) My one suggestion would be that you expand on some of the examples; for example, in the monoid section, you refer to various cool applications of Monoid, but do not include them in the paper. Dedicated readers might follow up on your (rather long!) references list, but many will not, and it is a shame if they miss the elegance that Monoid permits. I think that if you would inline some of these examples, the article would be even better :) Thanks for writing it! Edsko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: The Typeclassopedia, and request for feedback
Brent Yorgey wrote: My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-feedback/ This is really great! Thanks for doing this. Regards, -- Jochem Berndsen | joc...@functor.nl GPG: 0xE6FABFAB ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Low-level high-level languages?
http://www.ats-lang.org/ 2009/2/16 Jon Fairbairn jon.fairba...@cl.cam.ac.uk Maurício briqueabra...@yahoo.com writes: Hi, I've checked this 'BitC' language (www.bitc-lang.org). It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Hume http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml might be worth a look. I've never tried it, and since one of the top chaps associated with it said to me that he loathes Haskell, I'm not sure I should mention it here :-) -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ 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] ANN: The Typeclassopedia, and request for feedback
Wonderful, thank you! On Mon, Feb 16, 2009 at 4:29 AM, Brent Yorgey byor...@seas.upenn.edu wrote: Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Here's the abstract: The standard Haskell libraries feature a number of type classes with algebraic or categorical underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs. The goal of this article is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-feedback/ happy haskelling! -Brent ___ 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] Looping after compiling with cabal
L.S., I have updated wxFruit to compile with GHC 6.10.1, but when I compil using the commands: runhaskell Setup configurerunhaskell Setup buildrunhaskell Setup install and run paddle.exe, I get the message: paddle: loop If I compile with: ghc --make paddle , the game starts normally. Any idea how I can solve this? Some more data: Using: Yampa-0.9.2.3 wxFruit-0.1.1 from Hackage, updated GHC 6.10.1 Windows XP Compile sessions: [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updatedghc --make paddle [1 of 2] Compiling WXFruit ( WXFruit.hs, WXFruit.o ) [2 of 2] Compiling Main ( paddle.hs, paddle.o ) Linking paddle.exe ... This paddle.exe works fine [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updatedrunhaskell Setup configurerunhaskell Setup buildrunhaskell Setup install Configuring wxFruit-0.1.2... Preprocessing library wxFruit-0.1.2... Preprocessing executables for wxFruit-0.1.2... Building wxFruit-0.1.2... [1 of 1] Compiling WXFruit ( WXFruit.hs, dist\build\WXFruit.o ) C:\Programs\ghc\ghc-6.10.1\bin\ar.exe: creating dist\build\libHSwxFruit-0.1.2.a [1 of 2] Compiling WXFruit ( WXFruit.hs, dist\build\paddle\paddle-tmp\WXFruit.o ) Linking dist\build\paddle\paddle.exe ... Installing library in C:\Program Files\Haskell\wxFruit-0.1.2\ghc-6.10.1 Installing executable(s) in C:\Program Files\Haskell\bin Registering wxFruit-0.1.2... Reading package info from dist\\installed-pkg-config ... done. Writing new package config file... done. [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updatedcd dist\build\paddle [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updated\dist\build\paddlepaddle paddle: loop -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looping after compiling with cabal
Hi Henk-Jan, I believe cabal adds a -O on the command line, perhaps try ghc --make -O (after deleting all object files) Thanks Neil On Mon, Feb 16, 2009 at 12:04 PM, Henk-Jan van Tuyl hjgt...@chello.nl wrote: L.S., I have updated wxFruit to compile with GHC 6.10.1, but when I compil using the commands: runhaskell Setup configurerunhaskell Setup buildrunhaskell Setup install and run paddle.exe, I get the message: paddle: loop If I compile with: ghc --make paddle , the game starts normally. Any idea how I can solve this? Some more data: Using: Yampa-0.9.2.3 wxFruit-0.1.1 from Hackage, updated GHC 6.10.1 Windows XP Compile sessions: [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updatedghc --make paddle [1 of 2] Compiling WXFruit ( WXFruit.hs, WXFruit.o ) [2 of 2] Compiling Main ( paddle.hs, paddle.o ) Linking paddle.exe ... This paddle.exe works fine [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updatedrunhaskell Setup configure runhaskell Setup buildrunhaskell Setup install Configuring wxFruit-0.1.2... Preprocessing library wxFruit-0.1.2... Preprocessing executables for wxFruit-0.1.2... Building wxFruit-0.1.2... [1 of 1] Compiling WXFruit ( WXFruit.hs, dist\build\WXFruit.o ) C:\Programs\ghc\ghc-6.10.1\bin\ar.exe: creating dist\build\libHSwxFruit-0.1.2.a [1 of 2] Compiling WXFruit ( WXFruit.hs, dist\build\paddle\paddle-tmp\WXFruit.o ) Linking dist\build\paddle\paddle.exe ... Installing library in C:\Program Files\Haskell\wxFruit-0.1.2\ghc-6.10.1 Installing executable(s) in C:\Program Files\Haskell\bin Registering wxFruit-0.1.2... Reading package info from dist\\installed-pkg-config ... done. Writing new package config file... done. [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updatedcd dist\build\paddle [...]\Haskell\GUI\wxHaskell\wxFruit-0.1.1.updated\dist\build\paddlepaddle paddle: loop -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ 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] Re: Amazing
Am Sonntag, 15. Februar 2009 23:00 schrieb Peter Verswyvelen:
But if I understand it correctly, dependent types are a bit like that,
values and types can inter-operate somehow?
With dependent types, parameters of types can be values. So you can define a
data type List which is parameterized by the length of the list (and the
element type):
data List :: Nat - * - * where -- The kind of List contains a type.
Nil :: List 0 el
Cons :: el - List len el - List (succ len) el
And you have functions where the result type can depend on the actual
argument:
replicate :: {len :: Nat} - el - List len el
-- We have to name the argument so that we can refer to it.
So the type of replicate 0 'X' will be List 0 Char and the type of
replicate 5 'X' will be List 5 Char.
Dependent typing is very good for things like finding index-out-of-bounds
errors and breach of data structure invariants (e.g., search tree balancing)
at compile time. But you can even encode complete behavioral specifications
into the types. For example, there is the type of all sorting functions.
Properly implemented Quicksort and Mergesort functions would be values of
this type but the reverse function wouldn’t. Personally, I have also thought
a bit about dependently typed FRP where types encode temporal specifications.
Dependent types are really interesting. But note that you can simulate them to
a large degree in Haskell, although especially dependent functions like
replicate above need nasty workarounds. You may want to have a look at
Haskell packages like type-level.
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ann: Yogurt-0.3
Dear Haskellers, I'm pleased to announce the release of Yogurt-0.3! This version improves over 0.2 in several ways: * It compiles and runs with GHC 6.10. * The Mud monad is now built on top of IO. * Vars are expressed as IORefs. No more unsafeCoerce needed. * Forking of threads is supported, with callback into the Mud monad: type RunMud = forall a. Mud a - IO a forkWithCallback :: (RunMud - IO ()) - Mud ThreadId * Timers are no longer a primitive: they can be expressed as function of forkWithCallback. * Refactorings in the architecture: the features are a strict superset of the previous version while the number of lines of code has decreased by 10%. All feedback is appreciated! Thanks to Saizan on #haskell for helping me work around the predicative types. :-) The code is available at Google: http://code.google.com/p/yogurt-mud/ Kind regards, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Sonntag, 15. Februar 2009 17:50 schrieb Peter Verswyvelen: I'm having trouble understanding the explanation of the meaning of the signature of runST Were you just reading the documentation of Grapefruit’s era parameters or why are you studying ST? ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess shutting file handles
Neil Mitchell wrote: Hi However the createProcess command structure has the close_fds flag, which seems like it should override that behaviour, and therefore this seems like a bug in createProcess. close_fds :: Bool Close all file descriptors except stdin, stdout and stderr in the new process This refers to inheriting open unix file descriptors (or Win32 HANDLEs) in the child process. It's not the same as closing the Haskell98 Handles in the parent process that you pass to the child process. So lets not talk about if the current behaviour is a bug or not. It's reasonably clear (if not brilliantly well documented) that it's the intended behaviour. The thing we want to talk about is what reason is there for the current behaviour, if that's necessary and if it is the sensible default behaviour. As I said before I don't know why it is the way it is. I'm cc'ing the ghc users list in the hope that someone there might know. One guiding principle of resource management is that whoever opens/allocates something should release/free it. i.e. if you did the malloc you do the free. For that reason it seems weird that I call openFile but someone else calls hClose on my behalf. Plus, in my particular application, the above behaviour is necessary or I'm going to have to write to a file, open that file, and copy it over to my intended file (which is what I will end up doing, no doubt!) I don't remember exactly why it's done this way, but it might have something to do with trying to maintain the (possibly ill-conceived) Haskell98 file-locking principle. System.Posix.handleToFd also closes the Handle, FWIW. There's nothing stopping you from re-opening the file and seeking to the end, as a workaround. I could probably be convinced without much difficulty that we should stop closing these Handles; however I do have a vague feeling that I'm forgetting something! Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Samstag, 14. Februar 2009 23:13 schrieben Sie: Great, does it run well on Windows and Mac platforms in addition to Linux platform which should run fine? Actually, I have no idea. ;-) Well, Grapefruit is a pure Haskell library without any own binding to C libraries or whatever. For GUI stuff, Grapefruit relies completely on Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t tested it so far. Earlier Grapefruit code was successfully executed on the Windows box of my co-developer. On the other hand, Grapefruit is designed to be implemented on top of different toolkits, although currently there is only the Gtk2Hs backend. So if you want to write a backend based on the Win32 API or Cocoa, this would be very welcome. :-) I am planning to create video phone software and I was looking for good GUI toolkit that supports FRP so it looks like it is right time to use Grapefruit :) This would be really great. Writing applications with Grapefruit gives me useful feedback and pressure for improvement. Note that currently the set of supported widgets is very low but this is likely to change during the next weeks and it should often be very easy to port Gtk2Hs widgets to Grapefruit. Thanks Jamie Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: Hi Wolfgang, I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. I believe for this to make it happen, I would have to output FLTK's C++ into C then create bindings for Haskell (via FFI). Is that doable or an quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. Jamie Clark Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:26 schrieben Sie: One more thing, would Grapefruit work with files created by Glade (UI builder)? No, it won’t, I’m afraid. There is, for example, the principal problem that Glade is GTK+-specific (as far as I know) while Grapefruit shall have a toolkit-independent library interface. However, I don’t think it is such a good idea to support traditional GUI builders. These builders typically let you design a static interface but you have to code event handlers or similar stuff completely by hand and you have practically no support for dynamic user interfaces (user interfaces that change their structure). On the other hand, Grapefruit uses arrow notation for composing user interfaces so that the source code already reflects the visual appearence of the GUI to a certain degree. For example, you just list the widgets of a box and say what their input and output signals are. That said, I still think it might be a good idea to use a GUI builder together with Grapefruit. But such a builder should be specifically designed for Grapefruit, in my opinion. I already have some rough ideas in my mind about how such a builder could work. I’d want it to cover also the communication between the UI components (using signals) and maybe even dynamic user interfaces. If you are interested in my ideas, please ask. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: The Typeclassopedia, and request for feedback
Brent Yorgey wrote: If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. Splendid and outstanding! I do, however, wonder about the publication format. Wouldn't a hyperlinked collection of pages be more suitable for The Typeclassopedia? I imagine something like one HTML page for each class, references as inline hyperlinks and the class diagram being the hub, with each box being a link to the corresponding page. Of course, the drawback of a more hypertext-like format would be that it can't be published in the gem that is the Monad.Reader. :( Or can it? Thanks to the Simple Permissive License under which the Monad.Reader publishes, this is not necessarily a dichotomy, though. We can always convert it to hypertext afterwards. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Aha! Wolfgang is a man who knows his own code :) Yes, I've seen this a couple of times but when I saw it again in Grapefruit, I wanted to know how this usage of existentials worked, since I'm sooo curious to find out how you managed to use the type system for solving some of the typical FRP problems. I have plenty of references now to study, so hopefully I will get one step further with Grapefruit. Thanks! On Mon, Feb 16, 2009 at 1:30 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Sonntag, 15. Februar 2009 17:50 schrieb Peter Verswyvelen: I'm having trouble understanding the explanation of the meaning of the signature of runST Were you just reading the documentation of Grapefruit's era parameters or why are you studying ST? ;-) Best wishes, Wolfgang ___ 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] ANNOUNCE: first Grapefruit release
Am Sonntag, 15. Februar 2009 16:27 schrieben Sie: Hi Wolfgang, Thank you for the excellent introduction Oh, I thought that you didn’t send you original question to the list and therefore answered you only privately. So the others don’t know yet the introduction you refer to (but see below). (this would be good material to put on your Wiki). Done. :-) http://haskell.org/haskellwiki/Grapefruit/Comparison_to_other_FRP_libraries Conal, are you listening? If yes, could you please look over this page to make sure that I described your work correctly? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
On Mon, Feb 16, 2009 at 2:30 AM, wren ng thornton w...@freegeek.org wrote: Louis Wasserman wrote: I follow. The primary issue, I'm sort of wildly inferring, is that use of STT -- despite being pretty much a State monad on the inside -- allows access to things like mutable references? That's exactly the problem. The essential reason for ST's existence are STRefs which allow mutability. I'd like to point out one other thing that ST provides, which is often forgotten. It provides *polymorphic* references. That is, we can create new references of any type. So ST is a really magical beast. Not only does it provide mutation, it also provides mutable references. And these are two different features. Now, everyone agrees that mutation is not something that you can implement in a functional language, so ST cannot be implemented in Haskell for that reason. It has to be given as a primitive. But what about polymorphic references? Can they be implemented in Haskell? The Claessen conjecture (after Koen Claessen) is that they cannot be implemented in Haskell. See the following email for more details: http://www.haskell.org/pipermail/haskell/2001-September/007922.html One could try and separate mutation and polymorphic references and give them as two different primitives and implement ST on top of that. But I haven't seen anyone actually trying that (or needing it for that matter). Cheers, Josef ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: first Grapefruit release
Am Samstag, 14. Februar 2009 23:37 schrieb Roman Cheplyaka: * Wolfgang Jeltsch g9ks1...@acme.softbase.org [2009-02-14 17:19:09+0100] Dear friends of Haskell and Functional Reactive Programming, its my pleasure to announce the first official release of Grapefruit, a library for Functional Reactive Programming (FRP) with a focus on user interfaces. With Grapefruit, you can implement reactive and interactive systems in a declarative style. User interfaces are described as networks of communicating widgets and windows. Communication is done via different kinds of signals which describe temporal behavior. Greetings! Does this version not support Codebreaker and CircuitingObjects examples shown on the wiki page? Or there's another reason why they are not included in the grapefruit-examples? Sadly, both are not supported at the moment. The reasons are described under http://haskell.org/haskellwiki/Grapefruit#Versions: Grapefruit underwent fundamental interface and implementation changes before this release. A version from before these changes is available as the “classic” version. In contrast to the released version, the classic version contains support for animated graphics, incrementally updating list signals and a restricted form of dynamic user interfaces (user interfaces whose widget structure may change). These features are expected to come back in future releases. CircuitingObjects needs the graphics support (obviously) and Codebreaker needs at least incrementally updating list signals. I want to start hacking on these kind of signals today, so I hope that Codebreaker can soon run again. Maybe there is someone interested in helping me with the graphics support? There is already quite some stuff implemented (thanks to Matthias Reisner), it’s just that this is based on the classic interface of Grapefruit. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess shutting file handles
However the createProcess command structure has the close_fds flag, which seems like it should override that behaviour, and therefore this seems like a bug in createProcess. close_fds :: Bool Close all file descriptors except stdin, stdout and stderr in the new process This refers to inheriting open unix file descriptors (or Win32 HANDLEs) in the child process. It's not the same as closing the Haskell98 Handles in the parent process that you pass to the child process. So lets not talk about if the current behaviour is a bug or not. It's reasonably clear (if not brilliantly well documented) that it's the intended behaviour. The thing we want to talk about is what reason is there for the current behaviour, if that's necessary and if it is the sensible default behaviour. As I said before I don't know why it is the way it is. I'm cc'ing the ghc users list in the hope that someone there might know. One guiding principle of resource management is that whoever opens/allocates something should release/free it. i.e. if you did the malloc you do the free. For that reason it seems weird that I call openFile but someone else calls hClose on my behalf. Plus, in my particular application, the above behaviour is necessary or I'm going to have to write to a file, open that file, and copy it over to my intended file (which is what I will end up doing, no doubt!) I don't remember exactly why it's done this way, but it might have something to do with trying to maintain the (possibly ill-conceived) Haskell98 file-locking principle. System.Posix.handleToFd also closes the Handle, FWIW. There's nothing stopping you from re-opening the file and seeking to the end, as a workaround. openFile file AppendMode is how I ended up doing it, which saves writing a seek in there. It works just fine, merely at the cost of closing/opening handles more than necessary. I could probably be convinced without much difficulty that we should stop closing these Handles; however I do have a vague feeling that I'm forgetting something! Documenting it more clearly would be helpful. As for changing the behaviour - while I think the other way round would be much better, it brings up loads of reverse compatibility headaches, so I'm not sure its worth it. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Looping after compiling with cabal
Am Montag, 16. Februar 2009 13:07 schrieb Neil Mitchell: Hi Henk-Jan, I believe cabal adds a -O on the command line, perhaps try ghc --make -O (after deleting all object files) If it’s the -O option what causes the loop then it is problably because of this: http://hackage.haskell.org/trac/ghc/ticket/2722 Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
2009/2/16 Josef Svenningsson josef.svennings...@gmail.com: On Mon, Feb 16, 2009 at 2:30 AM, wren ng thornton w...@freegeek.org wrote: Louis Wasserman wrote: I follow. The primary issue, I'm sort of wildly inferring, is that use of STT -- despite being pretty much a State monad on the inside -- allows access to things like mutable references? That's exactly the problem. The essential reason for ST's existence are STRefs which allow mutability. I'd like to point out one other thing that ST provides, which is often forgotten. It provides *polymorphic* references. That is, we can create new references of any type. So ST is a really magical beast. Not only does it provide mutation, it also provides mutable references. And these are two different features. Now, everyone agrees that mutation is not something that you can implement in a functional language, so ST cannot be implemented in Haskell for that reason. It has to be given as a primitive. But what about polymorphic references? Can they be implemented in Haskell? The Claessen conjecture (after Koen Claessen) is that they cannot be implemented in Haskell. See the following email for more details: http://www.haskell.org/pipermail/haskell/2001-September/007922.html One could try and separate mutation and polymorphic references and give them as two different primitives and implement ST on top of that. But I haven't seen anyone actually trying that (or needing it for that matter). Actually, I was interested in making a state holding polymorphic references in the state monad, so that the state could be passed around. I made an attempt, and if my memory serves me right, it worked like this : It was based on Dynamics, with an IntMap indexed, indirectly, by TypeRep, yielding, for each type, a new IntMap, providing references for any value of that type. In fact, I think the next stpe would be to have some TH to generate specific state monads to hold references on specific types. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Montag, 16. Februar 2009 14:21 schrieben Sie: Aha! Wolfgang is a man who knows his own code :) Yes, I've seen this a couple of times but when I saw it again in Grapefruit, I wanted to know how this usage of existentials worked, since I'm sooo curious to find out how you managed to use the type system for solving some of the typical FRP problems. Note that in Grapefruit I not only use rank-2 polymorphism (corresponding to existentials) but also impredicative polymorphism, namely in FRP.Grapefruit.Signal.switch. However, the idea behind using impredicativity here is the same as the reason for using rank-2 in Control.Monad.ST.runST, FRP.Grapefruit.Circuit.create and Graphics.UI.Grapefruit.Circuit.run. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Wolfgang == Wolfgang Jeltsch g9ks1...@acme.softbase.org writes: Wolfgang This would be really great. Writing applications with Wolfgang Grapefruit gives me useful feedback and pressure for Wolfgang improvement. Note that currently the set of supported Wolfgang widgets is very low but this is likely to change during Wolfgang the next weeks and it should often be very easy to port Wolfgang Gtk2Hs widgets to Grapefruit. So I have an application that I am developing. The UI module includes the following: import Graphics.UI.Gtk import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG import Graphics.UI.Gtk.Gdk.EventM Can you tell from that list if i am likely to be able to rewrite it to use Grapefruit? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Samstag, 14. Februar 2009 23:13 schrieben Sie: Great, does it run well on Windows and Mac platforms in addition to Linux platform which should run fine? Actually, I have no idea. ;-) Well, Grapefruit is a pure Haskell library without any own binding to C libraries or whatever. For GUI stuff, Grapefruit relies completely on Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t tested it so far. Earlier Grapefruit code was successfully executed on the Windows box of my co-developer. On the other hand, Grapefruit is designed to be implemented on top of different toolkits, although currently there is only the Gtk2Hs backend. So if you want to write a backend based on the Win32 API or Cocoa, this would be very welcome. :-) Great. Well thought out design :) Other possible backends would be FLTK, GLUI, XBMC/Boxee (for set-top box apps) as well Qt and wxWidgets. I guess backends using Win32 API/Cocoa and FLTK would be the least bloated ones. I am planning to create video phone software and I was looking for good GUI toolkit that supports FRP so it looks like it is right time to use Grapefruit :) This would be really great. Writing applications with Grapefruit gives me useful feedback and pressure for improvement. Note that currently the set of supported widgets is very low but this is likely to change during the next weeks and it should often be very easy to port Gtk2Hs widgets to Grapefruit. Awesome! I'll be looking forward start using Grapefruit soon! :) Thanks Jamie Best wishes, Wolfgang Jamie Clark___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Low-level high-level languages?
What was that stripped-down low-level version of C I saw coming out of ... was it Microsoft Research? C-- or something. Unfortunately, the name appears to be immune to Googling. 2009/2/16 Alberto G. Corona agocor...@gmail.com http://www.ats-lang.org/ 2009/2/16 Jon Fairbairn jon.fairba...@cl.cam.ac.uk Maurício briqueabra...@yahoo.com writes: Hi, I've checked this 'BitC' language (www.bitc-lang.org). It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Hume http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml might be worth a look. I've never tried it, and since one of the top chaps associated with it said to me that he loathes Haskell, I'm not sure I should mention it here :-) -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.htmlhttp://www.chaos.org.uk/%7Ejf/Stuff-I-dont-want.html (updated 2009-01-31) ___ 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 -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: Hi Wolfgang, I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. Ok, great I ll have to use them then I will see and know what improvement is needed. I believe for this to make it happen, I would have to output FLTK's C++ into C then create bindings for Haskell (via FFI). Is that doable or an quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. That would be very helpful, I ll be looking forward. Best wishes, Wolfgang Jamie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Low-level high-level languages?
Google doesn't hear you ? Yell louder ! http://www.cminusminus.org/ 2009/2/16 Fraser Wilson blancoli...@gmail.com: What was that stripped-down low-level version of C I saw coming out of ... was it Microsoft Research? C-- or something. Unfortunately, the name appears to be immune to Googling. 2009/2/16 Alberto G. Corona agocor...@gmail.com http://www.ats-lang.org/ 2009/2/16 Jon Fairbairn jon.fairba...@cl.cam.ac.uk Maurício briqueabra...@yahoo.com writes: Hi, I've checked this 'BitC' language (www.bitc-lang.org). It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Hume http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml might be worth a look. I've never tried it, and since one of the top chaps associated with it said to me that he loathes Haskell, I'm not sure I should mention it here :-) -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ 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 -- http://thewhitelion.org/mysister ___ 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] ANN: The Typeclassopedia, and request for feedback
Super! Also, best definition of bottom I've yet seen -- ignoring _|_, which is a party pooper. Like good code, it's short, to the point, and obviously correct. Thanks for this. It's great to have it all in one place, and so entertainingly presented. cheers, Fraser. On Mon, Feb 16, 2009 at 10:29 AM, Brent Yorgey byor...@seas.upenn.eduwrote: Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Here's the abstract: The standard Haskell libraries feature a number of type classes with algebraic or categorical underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs. The goal of this article is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdfhttp://www.cis.upenn.edu/%7Ebyorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-feedback/ happy haskelling! -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:26 schrieben Sie: One more thing, would Grapefruit work with files created by Glade (UI builder)? No, it won’t, I’m afraid. There is, for example, the principal problem that Glade is GTK+-specific (as far as I know) while Grapefruit shall have a toolkit-independent library interface. However, I don’t think it is such a good idea to support traditional GUI builders. These builders typically let you design a static interface but you have to code event handlers or similar stuff completely by hand and you have practically no support for dynamic user interfaces (user interfaces that change their structure). On the other hand, Grapefruit uses arrow notation for composing user interfaces so that the source code already reflects the visual appearence of the GUI to a certain degree. For example, you just list the widgets of a box and say what their input and output signals are. Make sense. That said, I still think it might be a good idea to use a GUI builder together with Grapefruit. But such a builder should be specifically designed for Grapefruit, in my opinion. I already have some rough ideas in my mind about how such a builder could work. I’d want it to cover also the communication between the UI components (using signals) and maybe even dynamic user interfaces. If you are interested in my ideas, please ask. That would be a great addition to Grapefruit. Time for me to read fully about FRP and arrow notation and go from there! Best wishes, Wolfgang Jamie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: The Typeclassopedia, and request for feedback
Am Montag, 16. Februar 2009 10:29 schrieb Brent Yorgey: Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Good decision (not in any way suggesting that HWN isn't a great thing, too)! http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-fee dback/ happy haskelling! -Brent Hah, seems I'm the first to point out a flaw in it: Bottom of page 13: Also, note that although _ m = m would be a type-correct implementation of (), it The remainder of the sentence is missing. I'm not yet through it, but so far it has been excellent. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 15:13 schrieben Sie: So I have an application that I am developing. The UI module includes the following: import Graphics.UI.Gtk import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG import Graphics.UI.Gtk.Gdk.EventM Can you tell from that list if i am likely to be able to rewrite it to use Grapefruit? No, this won’t work at the moment. As I already said, Grapefruit’s widget support is very restricted at the moment. (And if I say “very” I really mean it.) So Grapefruit is worlds apart from what the catch-all Graphics.UI.Gtk import provides. And there is no graphics support at the moment, so there is nothing equivalent to the Cairo interface. Coming up with a sensible purely-functional, toolkit-independent, reactive graphics interface will also need some design work. Until now, I concentrated on getting Grapefruit’s core well. This includes a scalable FRP implementation, a record system (since you don’t want to provide an input signal for every attribute of every single widget in practice) and support for writing/extending Grapefruit UI backends without writing lots of boilerplate code. Providing a wide variety of ready-to-use widgets, graphics primitives, etc. is future work which, hopefully, I can delegate largely to interested third parties. ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: The Typeclassopedia, and request for feedback
Positively brilliant. What else can be said? Time for Brent to sign a Haskell recipes deal with O'Reilly (or whatever the next normal book should be). On Mon, Feb 16, 2009 at 4:29 AM, Brent Yorgey byor...@seas.upenn.eduwrote: Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Here's the abstract: The standard Haskell libraries feature a number of type classes with algebraic or categorical underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs. The goal of this article is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-feedback/ happy haskelling! -Brent ___ 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: [Haskell] ANNOUNCE: first Grapefruit release
Wolfgang == Wolfgang Jeltsch g9ks1...@acme.softbase.org writes: Hello Wolfgang, congratulation for your Grapefruit release! Wolfgang This would be really great. Writing applications with Wolfgang Grapefruit gives me useful feedback and pressure for Wolfgang improvement. Note that currently the set of supported widgets Wolfgang is very low but this is likely to change during the next weeks Wolfgang and it should often be very easy to port Gtk2Hs widgets to Wolfgang Grapefruit. Hey, this sounds wonderful :-D Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgp45LJUmrNGt.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
2009/2/16 Gour g...@mail.inet.hr Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? LOL. Funny typo. If the apps quit soon we're in trouble! :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
I would actually quite like to integrate Hieroglyph with Grapefruit, which would give you your Cairo support and give me a sensible way to implement events outside of my really rather broken model. On Mon, Feb 16, 2009 at 10:04 AM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Montag, 16. Februar 2009 15:13 schrieben Sie: So I have an application that I am developing. The UI module includes the following: import Graphics.UI.Gtk import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG import Graphics.UI.Gtk.Gdk.EventM Can you tell from that list if i am likely to be able to rewrite it to use Grapefruit? No, this won't work at the moment. As I already said, Grapefruit's widget support is very restricted at the moment. (And if I say very I really mean it.) So Grapefruit is worlds apart from what the catch-all Graphics.UI.Gtk import provides. And there is no graphics support at the moment, so there is nothing equivalent to the Cairo interface. Coming up with a sensible purely-functional, toolkit-independent, reactive graphics interface will also need some design work. Until now, I concentrated on getting Grapefruit's core well. This includes a scalable FRP implementation, a record system (since you don't want to provide an input signal for every attribute of every single widget in practice) and support for writing/extending Grapefruit UI backends without writing lots of boilerplate code. Providing a wide variety of ready-to-use widgets, graphics primitives, etc. is future work which, hopefully, I can delegate largely to interested third parties. ;-) Best wishes, Wolfgang ___ 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] Re: [Haskell] ANNOUNCE: first Grapefruit release
Peter == Peter Verswyvelen bugf...@gmail.com writes: Peter 2009/2/16 Gour g...@mail.inet.hr Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? Peter LOL. Funny typo. If the apps quit soon we're in trouble! Peter :-) Nay - it just shows the GHC optimiser is performing beyond our wildest dreams :-) -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work rather
well. The most basic implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m = MonadST ...
newtype FooT m e = FooT (StateT Foo m e)
instance (Monad m, MonadST s m) = Monad (FooT m) where ...
instance (Monad m, MonadST s m) = MonadBar (FooT m) where
operations using an ST state
instance (Monad m, MonadST s m) = MonadST s (FooT m) where ...
The point here is that a MonadST instance guarantees that the bottom monad
is an ST -- and therefore single-threaded of necessity -- and grants any
ST-based monad transformers on top of it access to its single state thread.
The more fully general approach to guaranteeing an underlying monad is
single-threaded would be to create a dummy state parameter version of each
single-threaded monad -- State, Writer, and Reader -- and add a typeclass
called MonadThreaded or something.
The real question with this approach would be how to go about unwrapping
ST-based monad transformers in this fashion: I'm thinking that you would
essentially perform unwrapping of the outer monad using an ST computation
which gets lifted to the next-higher monad. So, say, for example:
newtype MonadST s m = ArrayT e m a = ArrayT {execArrayT :: StateT (STArray
s Int e) m a}
runArrayT :: (Monad m, MonadST s m) = Int - ArrayT e m a - m a
runArrayT n m = liftST (newArray_ (0, n-1)) = evalStateT (execArrayT m)
Key points:
- A MonadST s m instance should *always* imply that the bottom-level monad
is of type ST s, preferably a bottom level provided when defining a monad by
stacking transformers. The fact that the bottom monad is in ST should
guarantee single-threaded, referentially transparent behavior.
- A non-transformer implementation of an ST-bound monad transformer would
simply involve setting the bottom monad to ST, rather than Identity as for
most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type. After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should propagate
MonadST.
I'm going to go try implementing this idea in stateful-mtl now...
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Well, I think a type system like Clean's that had linear/uniqueness types
could fix the issue by actually checking that the state is single-threaded
(and thus stop you from applying it to a forking monad). But there's a
fundamental operational problem that ST makes destructive updates, so to
support it as a monad transformer in general you'd need a type system that
actually introduced fork operations (which linear implicit parameters used
to do in GHC , but they were removed because they were quite complicated
semantically and noone really used them).
--
*From:* haskell-cafe-boun...@haskell.org [mailto:
haskell-cafe-boun...@haskell.org] *On Behalf Of *Louis Wasserman
*Sent:* 16 February 2009 03:31
*To:* Dan Doel
*Cc:* Henning Thielemann; haskell-cafe@haskell.org
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Okay, I tested it out and the arrow transformer has the same problem. I
realized this after I sent the last message -- the point is that at any
particular point, intuitively there should be exactly one copy of a State# s
for each state thread, and it should never get duplicated; allowing other
monads or arrows to hold a State# s in any form allows them to hold more
than one, violating that goal.
I'm not entirely convinced yet that there *isn't* some really gorgeous
type system magic to fix this issue, like the type-system magic that
motivates the type of runST in the first place, but that's not an argument
that such magic exists...it's certainly an interesting topic to mull.
Louis Wasserman
wasserman.lo...@gmail.com
On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel dan.d...@gmail.com wrote:
On Sunday 15 February 2009 9:44:42 pm Louis Wasserman wrote:
Hello all,
I just uploaded stateful-mtl and pqueue-mtl 1.0.1. The ST monad
transformer and array transformer have been removed -- I've convinced
myself that a heap transformer backed by an ST array cannot be
referentially transparent -- and the heap monad is now available only as
a
basic monad and not a transformer, though it still provides priority
queue
functionality to any of the mtl wrappers around it. stateful-mtl
retains a
MonadST typeclass which is implemented by ST and monad transformers
around
it, allowing computations in the the ST-bound heap monad to perform ST
operations in its thread.
Since this discussion had largely led to the conclusion that ST can only
be
used as a bottom-level monad, it would be
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
I don't think this can be right, because the m - s dependency will
contradict the universal quantification of s required by runST. In other
words, unwrapping the transformers will leave you with an ST computation
for a specific s, which runST will reject.
From: Louis Wasserman [mailto:wasserman.lo...@gmail.com]
Sent: 16 February 2009 16:01
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work rather
well. The most basic implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m = MonadST ...
newtype FooT m e = FooT (StateT Foo m e)
instance (Monad m, MonadST s m) = Monad (FooT m) where ...
instance (Monad m, MonadST s m) = MonadBar (FooT m) where
operations using an ST state
instance (Monad m, MonadST s m) = MonadST s (FooT m) where ...
The point here is that a MonadST instance guarantees that the bottom
monad is an ST -- and therefore single-threaded of necessity -- and
grants any ST-based monad transformers on top of it access to its single
state thread.
The more fully general approach to guaranteeing an underlying monad is
single-threaded would be to create a dummy state parameter version of
each single-threaded monad -- State, Writer, and Reader -- and add a
typeclass called MonadThreaded or something.
The real question with this approach would be how to go about unwrapping
ST-based monad transformers in this fashion: I'm thinking that you would
essentially perform unwrapping of the outer monad using an ST
computation which gets lifted to the next-higher monad. So, say, for
example:
newtype MonadST s m = ArrayT e m a = ArrayT {execArrayT :: StateT
(STArray s Int e) m a}
runArrayT :: (Monad m, MonadST s m) = Int - ArrayT e m a - m a
runArrayT n m = liftST (newArray_ (0, n-1)) = evalStateT (execArrayT
m)
Key points:
- A MonadST s m instance should always imply that the bottom-level monad
is of type ST s, preferably a bottom level provided when defining a
monad by stacking transformers. The fact that the bottom monad is in ST
should guarantee single-threaded, referentially transparent behavior.
- A non-transformer implementation of an ST-bound monad transformer
would simply involve setting the bottom monad to ST, rather than
Identity as for most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type. After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should propagate
MonadST.
I'm going to go try implementing this idea in stateful-mtl now...
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Well, I think a type system like Clean's that had
linear/uniqueness types could fix the issue by actually checking that
the state is single-threaded (and thus stop you from applying it to a
forking monad). But there's a fundamental operational problem that ST
makes destructive updates, so to support it as a monad transformer in
general you'd need a type system that actually introduced fork
operations (which linear implicit parameters used to do in GHC , but
they were removed because they were quite complicated semantically and
noone really used them).
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Louis Wasserman
Sent: 16 February 2009 03:31
To: Dan Doel
Cc: Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Okay, I tested it out and the arrow transformer has the same
problem. I realized this after I sent the last message -- the point is
that at any particular point, intuitively there should be exactly one
copy of a State# s for each state thread, and it should never get
duplicated; allowing other monads or arrows to hold a State# s in any
form allows them to hold more than one, violating that goal.
I'm not entirely convinced yet that there isn't some really
gorgeous type system magic to fix this issue, like the type-system magic
that motivates the type of runST in the first place, but that's not an
argument that such magic exists...it's certainly an interesting topic to
mull.
Louis Wasserman
wasserman.lo...@gmail.com
On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel dan.d...@gmail.com
wrote:
On Sunday 15 February 2009 9:44:42 pm Louis Wasserman
wrote:
Hello all,
I just uploaded stateful-mtl and
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Peter == Peter Verswyvelen bugf...@gmail.com writes: Peter LOL. Funny typo. If the apps quit soon we're in trouble! :-) Well, let's do some LOL-ing on my own account... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpyn3RTL8clR.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
But the m - s dependency will have been removed by the time runST gets a
hold of it! It works, I just tested it.
*Control.Monad.Array.ArrayM :t runST (runArrayT 5 Nothing getContents)
runST (runArrayT 5 Nothing getContents) :: [Maybe a]
*Control.Monad.Array.ArrayM runST (runArrayT 5 Nothing getContents)
[Nothing,Nothing,Nothing,Nothing,Nothing]
There is, unfortunately, one last key point needed in this approach: the
transformer cannot implement MonadTrans, which requires that it work for all
monads. The hack I added is
class MonadSTTrans s t where
stLift :: MonadST s m = m a - t m a
instance MonadTrans t = MonadSTTrans s t where
stLift = lift
which, as a side effect, makes explicit the distinction between normal monad
transformers and ST-wrapped monad transformers.
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 10:04 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
I don't think this can be right, because the m - s dependency will
contradict the universal quantification of s required by runST. In other
words, unwrapping the transformers will leave you with an ST computation for
a specific s, which runST will reject.
--
*From:* Louis Wasserman [mailto:wasserman.lo...@gmail.com]
*Sent:* 16 February 2009 16:01
*To:* Sittampalam, Ganesh
*Cc:* Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work rather
well. The most basic implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m = MonadST ...
newtype FooT m e = FooT (StateT Foo m e)
instance (Monad m, MonadST s m) = Monad (FooT m) where ...
instance (Monad m, MonadST s m) = MonadBar (FooT m) where
operations using an ST state
instance (Monad m, MonadST s m) = MonadST s (FooT m) where ...
The point here is that a MonadST instance guarantees that the bottom monad
is an ST -- and therefore single-threaded of necessity -- and grants any
ST-based monad transformers on top of it access to its single state thread.
The more fully general approach to guaranteeing an underlying monad is
single-threaded would be to create a dummy state parameter version of each
single-threaded monad -- State, Writer, and Reader -- and add a typeclass
called MonadThreaded or something.
The real question with this approach would be how to go about unwrapping
ST-based monad transformers in this fashion: I'm thinking that you would
essentially perform unwrapping of the outer monad using an ST computation
which gets lifted to the next-higher monad. So, say, for example:
newtype MonadST s m = ArrayT e m a = ArrayT {execArrayT :: StateT (STArray
s Int e) m a}
runArrayT :: (Monad m, MonadST s m) = Int - ArrayT e m a - m a
runArrayT n m = liftST (newArray_ (0, n-1)) = evalStateT (execArrayT m)
Key points:
- A MonadST s m instance should *always* imply that the bottom-level monad
is of type ST s, preferably a bottom level provided when defining a monad by
stacking transformers. The fact that the bottom monad is in ST should
guarantee single-threaded, referentially transparent behavior.
- A non-transformer implementation of an ST-bound monad transformer would
simply involve setting the bottom monad to ST, rather than Identity as for
most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type. After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should propagate
MonadST.
I'm going to go try implementing this idea in stateful-mtl now...
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Well, I think a type system like Clean's that had linear/uniqueness
types could fix the issue by actually checking that the state is
single-threaded (and thus stop you from applying it to a forking monad).
But there's a fundamental operational problem that ST makes destructive
updates, so to support it as a monad transformer in general you'd need a
type system that actually introduced fork operations (which linear implicit
parameters used to do in GHC , but they were removed because they were
quite complicated semantically and noone really used them).
--
*From:* haskell-cafe-boun...@haskell.org [mailto:
haskell-cafe-boun...@haskell.org] *On Behalf Of *Louis Wasserman
*Sent:* 16 February 2009 03:31
*To:* Dan Doel
*Cc:* Henning Thielemann; haskell-cafe@haskell.org
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Okay, I tested it out and the arrow transformer has the same problem.
I realized this after I sent the
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
I apologize, I did not mean to be rude at all, I found it a great typo to summarize the previous attempts for doing fully functional GUIs in Haskell. 2009/2/16 Gour g...@mail.inet.hr Peter == Peter Verswyvelen bugf...@gmail.com writes: Peter LOL. Funny typo. If the apps quit soon we're in trouble! :-) Well, let's do some LOL-ing on my own account... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ___ 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] ANNOUNCE: pqueue-mtl, stateful-mtl
Oh, I see, every derived monad has to have an 's' in its type somewhere.
From: Louis Wasserman [mailto:wasserman.lo...@gmail.com]
Sent: 16 February 2009 16:17
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
But the m - s dependency will have been removed by the time runST gets
a hold of it! It works, I just tested it.
*Control.Monad.Array.ArrayM :t runST (runArrayT 5 Nothing getContents)
runST (runArrayT 5 Nothing getContents) :: [Maybe a]
*Control.Monad.Array.ArrayM runST (runArrayT 5 Nothing getContents)
[Nothing,Nothing,Nothing,Nothing,Nothing]
There is, unfortunately, one last key point needed in this approach: the
transformer cannot implement MonadTrans, which requires that it work for
all monads. The hack I added is
class MonadSTTrans s t where
stLift :: MonadST s m = m a - t m a
instance MonadTrans t = MonadSTTrans s t where
stLift = lift
which, as a side effect, makes explicit the distinction between normal
monad transformers and ST-wrapped monad transformers.
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 10:04 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
I don't think this can be right, because the m - s dependency
will contradict the universal quantification of s required by runST. In
other words, unwrapping the transformers will leave you with an ST
computation for a specific s, which runST will reject.
From: Louis Wasserman [mailto:wasserman.lo...@gmail.com]
Sent: 16 February 2009 16:01
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work
rather well. The most basic implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m = MonadST ...
newtype FooT m e = FooT (StateT Foo m e)
instance (Monad m, MonadST s m) = Monad (FooT m) where ...
instance (Monad m, MonadST s m) = MonadBar (FooT m) where
operations using an ST state
instance (Monad m, MonadST s m) = MonadST s (FooT m) where ...
The point here is that a MonadST instance guarantees that the
bottom monad is an ST -- and therefore single-threaded of necessity --
and grants any ST-based monad transformers on top of it access to its
single state thread.
The more fully general approach to guaranteeing an underlying
monad is single-threaded would be to create a dummy state parameter
version of each single-threaded monad -- State, Writer, and Reader --
and add a typeclass called MonadThreaded or something.
The real question with this approach would be how to go about
unwrapping ST-based monad transformers in this fashion: I'm thinking
that you would essentially perform unwrapping of the outer monad using
an ST computation which gets lifted to the next-higher monad. So, say,
for example:
newtype MonadST s m = ArrayT e m a = ArrayT {execArrayT ::
StateT (STArray s Int e) m a}
runArrayT :: (Monad m, MonadST s m) = Int - ArrayT e m a - m
a
runArrayT n m = liftST (newArray_ (0, n-1)) = evalStateT
(execArrayT m)
Key points:
- A MonadST s m instance should always imply that the
bottom-level monad is of type ST s, preferably a bottom level provided
when defining a monad by stacking transformers. The fact that the
bottom monad is in ST should guarantee single-threaded, referentially
transparent behavior.
- A non-transformer implementation of an ST-bound monad
transformer would simply involve setting the bottom monad to ST, rather
than Identity as for most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type. After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should
propagate MonadST.
I'm going to go try implementing this idea in stateful-mtl
now...
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Well, I think a type system like Clean's that had
linear/uniqueness types could fix the issue by actually checking that
the state is single-threaded (and thus stop you from applying it to a
forking monad). But there's a fundamental operational problem that ST
makes
Re: [Haskell-cafe] ANN: The Typeclassopedia, and request for feedback
On Mon, Feb 16, 2009 at 11:53 AM, Daniel Fischer daniel.is.fisc...@web.de wrote: Hah, seems I'm the first to point out a flaw in it: Bottom of page 13: Also, note that although _ m = m would be a type-correct implementation of (), it The remainder of the sentence is missing. Sorry, I've already reported this one, it's waiting for moderation on the blog post ;). -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HaskellDB is alive?
On Sat, Feb 14, 2009 at 2:43 AM, Felipe Lessa felipe.le...@gmail.com wrote: Hello! There was a new HaskellDB release, but I didn't see any announcement here. Is it back alive? What happened to 0.11? 0.11 existed in the repository but was never uploaded to Hackage. I updated the HDBC backends and rolled the version numbers. Look for more in the future. Thanks =) -- Felipe. ___ 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] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 16:43 schrieb Peter Verswyvelen: 2009/2/16 Gour g...@mail.inet.hr Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? LOL. Funny typo. If the apps quit soon we're in trouble! :-) I’m sure that current Grapefruit applications will be quitted soon by their users. :-D Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hslogger bugs or features - patches
You didn't notice setHandlers? -- | Set the 'Logger'\'s list of handlers to the list supplied. -- All existing handlers are removed first. setHandlers :: LogHandler a = [a] - Logger - Logger It is perfectly valid to set the root logger's handlers to [] if you want it to do nothing at all. Which type to assign to [] ? Right now I'm using instance HL.LogHandler () where -- doh! find a better way to pass an empty list below setLevel = error should never be rearched getLevel = error should never be rearched emit = error should never be rearched close = error should never be rearched HL.updateGlobalLogger (HL.addHandler fh . HL.setHandlers ([] :: [()]) ) ... But I'm not satisfied with that. But I couldn't find a better solution either. Eg I've tried [] :: [SyslogHandler] (SyslogHandler is not exported, is it?) [] :: [GenericHandler ()] (GenericHandler isn't exported either?) Sincerly Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 16:27 schrieb Gour: Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? I have no concrete anticipation. It depends very much on the community. If there is notable interest and this interest makes people hacking on Grapefruit then it might not take so long until you can write real-world apps in Grapefruit. I’m really interested in developing Grapefruit further. However, I also have to do a PhD, etc. and so I need others which help. But I will try to help the helpers as much as possible and also hack myself. Various immediate reactions to my release announcement make me hopeful that there might be indeed notable Grapefruit development from other people than me. Best wishes, Wolfgang P.S.: The “hack myself” might not be a typo but it’s maybe a funny blooper. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
I just posted stateful-mtl and pqueue-mtl 1.0.2, making use of the new
approach to single-threaded ST wrapping. I discovered while making the
modifications to both packages that the MonadSTTrans type class was
unnecessary, enabling a cleaner integration with mtl proper. I'm pretty
confident that this approach is airtight, but let me know if you encounter
contradictions or problems.
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 10:21 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Oh, I see, every derived monad has to have an 's' in its type somewhere.
--
*From:* Louis Wasserman [mailto:wasserman.lo...@gmail.com]
*Sent:* 16 February 2009 16:17
*To:* Sittampalam, Ganesh
*Cc:* Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
But the m - s dependency will have been removed by the time runST gets a
hold of it! It works, I just tested it.
*Control.Monad.Array.ArrayM :t runST (runArrayT 5 Nothing getContents)
runST (runArrayT 5 Nothing getContents) :: [Maybe a]
*Control.Monad.Array.ArrayM runST (runArrayT 5 Nothing getContents)
[Nothing,Nothing,Nothing,Nothing,Nothing]
There is, unfortunately, one last key point needed in this approach: the
transformer cannot implement MonadTrans, which requires that it work for all
monads. The hack I added is
class MonadSTTrans s t where
stLift :: MonadST s m = m a - t m a
instance MonadTrans t = MonadSTTrans s t where
stLift = lift
which, as a side effect, makes explicit the distinction between normal
monad transformers and ST-wrapped monad transformers.
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 10:04 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
I don't think this can be right, because the m - s dependency will
contradict the universal quantification of s required by runST. In other
words, unwrapping the transformers will leave you with an ST computation for
a specific s, which runST will reject.
--
*From:* Louis Wasserman [mailto:wasserman.lo...@gmail.com]
*Sent:* 16 February 2009 16:01
*To:* Sittampalam, Ganesh
*Cc:* Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
*Subject:* Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Overnight I had the following thought, which I think could work rather
well. The most basic implementation of the idea is as follows:
class MonadST s m | m - s where
liftST :: ST s a - m a
instance MonadST s (ST s) where ...
instance MonadST s m = MonadST ...
newtype FooT m e = FooT (StateT Foo m e)
instance (Monad m, MonadST s m) = Monad (FooT m) where ...
instance (Monad m, MonadST s m) = MonadBar (FooT m) where
operations using an ST state
instance (Monad m, MonadST s m) = MonadST s (FooT m) where ...
The point here is that a MonadST instance guarantees that the bottom monad
is an ST -- and therefore single-threaded of necessity -- and grants any
ST-based monad transformers on top of it access to its single state thread.
The more fully general approach to guaranteeing an underlying monad is
single-threaded would be to create a dummy state parameter version of each
single-threaded monad -- State, Writer, and Reader -- and add a typeclass
called MonadThreaded or something.
The real question with this approach would be how to go about unwrapping
ST-based monad transformers in this fashion: I'm thinking that you would
essentially perform unwrapping of the outer monad using an ST computation
which gets lifted to the next-higher monad. So, say, for example:
newtype MonadST s m = ArrayT e m a = ArrayT {execArrayT :: StateT
(STArray s Int e) m a}
runArrayT :: (Monad m, MonadST s m) = Int - ArrayT e m a - m a
runArrayT n m = liftST (newArray_ (0, n-1)) = evalStateT (execArrayT m)
Key points:
- A MonadST s m instance should *always* imply that the bottom-level
monad is of type ST s, preferably a bottom level provided when defining a
monad by stacking transformers. The fact that the bottom monad is in ST
should guarantee single-threaded, referentially transparent behavior.
- A non-transformer implementation of an ST-bound monad transformer would
simply involve setting the bottom monad to ST, rather than Identity as for
most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type. After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should propagate
MonadST.
I'm going to go try implementing this idea in stateful-mtl now...
Louis Wasserman
wasserman.lo...@gmail.com
On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
ganesh.sittampa...@credit-suisse.com wrote:
Well, I think a type system like Clean's that had linear/uniqueness
types could
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 17:46 schrieb Wolfgang Jeltsch: Am Montag, 16. Februar 2009 16:27 schrieb Gour: Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? I have no concrete anticipation. It depends very much on the community. If there is notable interest and this interest makes people hacking on Grapefruit then it might not take so long until you can write real-world apps in Grapefruit. By the way, are there people out there who would like to hack on Grapefruit during the Utrecht Hackathon [1]? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 18:05 schrieb Fraser Wilson: I'd love to hack on Grapefruit. That’s great! I'll do some study (and take a break from my own world-changing functional GUI :-) I tried to check out your repository at http://thewhitelion.org/darcs/barrie/ but darcs get failed with some complaint about cached patches or so. :-( I use darcs 2.2.1. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Peter Verswyvelen-2 wrote: I'm having trouble understanding the explanation of the meaning of the signature of runST at http://en.wikibooks.org/wiki/Haskell/Existentially_quantified_types I could try to read the article a couple of times again, but are there any other good readings about these existentially quantified types and how the ST monad works? Existential quantification can be discussed without reference to runST, and the more I reread the wikibooks link you gave, the more I'm convinced the runST section doesn't belong there. The tenuous connection between them is higher-ranked types. You can't do much with existential quantification without invoking them. That one presupposes the other does not necessitate its converse. Despite its rank-2 type, runST really doesn't have anything to do with e.q. -- View this message in context: http://www.nabble.com/forall---ST-monad-tp22024677p22042542.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Yeah, I lack some darcs fu unfortunately. I understood it was just a matter of copying a repository. I'll have a look, and by have a look I mean bother #haskell :-) Cheers, Fraser Sent from my iPhone On 16 feb 2009, at 18:51, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Montag, 16. Februar 2009 18:05 schrieb Fraser Wilson: I'd love to hack on Grapefruit. That’s great! I'll do some study (and take a break from my own world-changing functional GUI :-) I tried to check out your repository at http://thewhitelion.org/darcs/barrie/ but darcs get failed with some complaint about cached patches or so. :-( I use darcs 2.2.1. Best wishes, Wolfgang ___ 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] Arch Haskell News: Feb 16 2009
Arch now has 926 Haskell packages in AUR. That’s an increase of 27 new packages in the last 8 days, or 3.38 new Haskell apps a day. This weekly news includes: * Noteworthy updates: grapefruit, haskelldb, gtk2hs * A video on how to use Arch packages * Updated releases by category Read it all: http://archhaskell.wordpress.com/2009/02/16/arch-haskell-news-feb-16-2009/ Enjoy! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 19:08 schrieben Sie: Yeah, I lack some darcs fu unfortunately. I understood it was just a matter of copying a repository. I'll have a look, and by have a look I mean bother #haskell :-) If you don’t use this lazy fetch feature (or whatever it is called) then you can just copy your repository. Personally, I have very uncomfortable feelings about this lazy patch fetching since I fear it might be all too easy to loose data somewhere. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Montag, 16. Februar 2009 19:04 schrieb Kim-Ee Yeoh: Despite its rank-2 type, runST really doesn't have anything to do with existential quantification. First, I thought so too but I changed my mind. To my knowledge a type (forall a. T[a]) - T' is equivalent to the type exists a. (T[a] - T'). It’s the same as in predicate logic – Curry-Howard in action. However, if we talk about existential types in Haskell, we usually mean these special algebraic data types whose declarations have a forall part before a data constructor. So it’s better to talk about rank-2 (or rank-n) polymorphism when talking about runST. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Am Montag, 16. Februar 2009 19:22 schrieb Wolfgang Jeltsch: Am Montag, 16. Februar 2009 19:04 schrieb Kim-Ee Yeoh: Despite its rank-2 type, runST really doesn't have anything to do with existential quantification. First, I thought so too but I changed my mind. To my knowledge a type (forall a. T[a]) - T' is equivalent to the type exists a. (T[a] - T'). It’s the same as in predicate logic – Curry-Howard in action. Oops, this is probably not true. The statement holds for classical predicate logic with only non-empty domains. But in constructivist logic only the first of the above statements follows from the second, not the other way round. So arguing with the Curry-Howard isomorphism fails and indeed, the two types are not equivalent. There is just a function from the second to the first (it’s the function application function ($) actually). Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN : Crypto 4.2.0 Related News
Hello Haskellers, I'm pleased to announce version 4.2.0 of Crypto has been uploaded to Hackage that I am taking over maintenance of the library from Dominic Steinitz. As of this release it should be cabal install'able on GHC 6.10.1. I'm also pleased to announce that the darcs repo will be moving from code.haskell.org to being hosted on Patch-Tag at http://patch-tag.com/repo/crypto/home. You don't need to sign up for Patch-Tag to use the read only repos, but you will need an account if you want to be given write access to the crypto repository. Please feel free to e-mail me with any issues or questions. Cheers, Creighton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Functional GUIs again
Since I'm congenitally lazy, and writing a GUI by hand in the IO monad is ... not what I expect from a beautiful program, and because what I often need is a GUI that manipulates a state, and because I don't understand arrows, and having been intrigued by a recent cafe thread, I threw together a prototype GUI library with the following features: - the GUI is defined on three levels: gadgets, widgets and styles - gadgets are functions on a state - widgets are data structures which define the layout - styles are ways to modify the appearance of widgets The following quick example shows a text box and a button. Clicking on the button reverses the text in the text box. module Main where import Barrie demoWidget :: Widget demoWidget = vbox [ui demo entry textBox, ui demo command (labelButton click me)] type DemoState = String type DemoGadget = Gadget DemoState demoGUI :: DemoGadget demoGUI = localG demo gui [editorG demo entry id const, commandG demo command reverse] main = gtkMain demoGUI demoWidget Hello, world Two gadgets are used: editorG :: String - (a - b) - (b - a - a) - Gadget a commandG :: String - (a - a) - Gadget a The editor gadget can show a value from a state, and update a state with a value. The command gadget can transform a state to a new state. gtkMain connects the gadgets to a widget, which specifies layout using the vbox, attaching the editor gadget to a text box, and the command gadget to a button. Well, that's all pretty trivial. The key thing for me was that I can easily slap a GUI onto the the front of a class of applications, which happen to be the sort of applications I've been writing lately. Also, arbitrary parts of the GUI can respond to things that happen miles away, without really having to worry about it too much. In barrie-0.1 and 0.2, which used stream-based approaches, the problem of getting state from one end of the application to the other was non-trivial. I'll sketch another quick example: data BridgeGame = ... And a bunch of things you can do with the state: makeBid :: Bid - BridgeGame - BridgeGame playCard :: Card - BridgeGame - BridgeGame For bidding, each bid is represented by a gadget: bidG :: Bid - Gadget BridgeGame bidG bid = enabled (bidOK bid) $ CommandG (show bid) (makeBid bid) 'enabled' switches the gadget on if its first argument returns true when applied to the current state. However, the decision about what to do with a disabled gadget is made by its corresponding widget. We get one button for each bid: biddingG :: Gadget BridgeGame biddingG = localG bidding (map bidG allBids) And they can be displayed in any old order using a widget: biddingW :: Widget biddingW = vbox (map suitBids [Club, Diamond, Heart, Spade] ++ [ntBids]) where suitBids suit = hbox $ map (bidButton . flip Bid suit) [1 .. 7] ntBids = hbox $ map (bidButton . NT) [1 .. 7] bidButton bid = ui (show bid) $ labelButton (show bid) (You're right, double, redouble and pass are not represented. They make the lines too long). Screenshot here: http://thewhitelion.org/images/4D.png I've just bid four diamonds, so everything lower than that is automatically disabled. Currently, Barrie implements buttons, text boxes, labels, vertical/horizontal layout, single-column lists and drop lists. It current uses Gtk2hs for rendering, but it's GUI-agnostic (in fact, the first renderer was putStrLn/getLine). You can have a look by using darcs: darcs get http://thewhitelion.org/darcs/barrie Or get the tarball at http://thewhitelion.org/haskell/barrie-0.3.0-src.tar.gz One note: this is not intended to be a theoretically sound approach, merely a way of getting something done quickly. I would expect it to be most useful in putting a GUI front-end onto an existing application, in particular, an application that is driven by user actions which update a state; e.g. a calculator, a bridge game, a 4th edition DD character creator (but that leads to a critical mass of nerdiness, so it's off the table for now) cheers, Fraser. -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 19:27 schrieben Sie: Ah. Copy, don't darcs get. If you copy a repository which was itself fetched from somewhere using this lazy patch fetching feature, you’ll probably experience problems too. If it’s the repository you work in and you never fetched any patches into it, you might be successful. This is how I understand it. We see that this lazy patch fetching thing is dangerous. ;-) If you want to take a look, I'd love to hear your thought. demos/BarrieCalc has some commentary, and the other applications in demos are all very simple. I just executed the demos. At the moment, I have no time to look at the code but I think I will have a look in the future. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN : Crypto 4.2.0 Related News
wchogg: Hello Haskellers, I'm pleased to announce version 4.2.0 of Crypto has been uploaded to Hackage that I am taking over maintenance of the library from Dominic Steinitz. As of this release it should be cabal install'able on GHC 6.10.1. I'm also pleased to announce that the darcs repo will be moving from code.haskell.org to being hosted on Patch-Tag at http://patch-tag.com/repo/crypto/home. You don't need to sign up for Patch-Tag to use the read only repos, but you will need an account if you want to be given write access to the crypto repository. Please feel free to e-mail me with any issues or questions. Great! Good to see the torch passed on. Packaged up for Arch, http://aur.archlinux.org/packages.php?ID=17492 -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional GUIs again
You must have missed the bit about congenitally lazy :-) Username requested ... cheers, Fraser. On Mon, Feb 16, 2009 at 8:10 PM, Lennart Augustsson lenn...@augustsson.netwrote: Put it on hackage! 2009/2/16 Fraser Wilson blancoli...@gmail.com: Since I'm congenitally lazy, and writing a GUI by hand in the IO monad is ... not what I expect from a beautiful program, and because what I often need is a GUI that manipulates a state, and because I don't understand arrows, and having been intrigued by a recent cafe thread, I threw together a prototype GUI library with the following features: - the GUI is defined on three levels: gadgets, widgets and styles - gadgets are functions on a state - widgets are data structures which define the layout - styles are ways to modify the appearance of widgets The following quick example shows a text box and a button. Clicking on the button reverses the text in the text box. module Main where import Barrie demoWidget :: Widget demoWidget = vbox [ui demo entry textBox, ui demo command (labelButton click me)] type DemoState = String type DemoGadget = Gadget DemoState demoGUI :: DemoGadget demoGUI = localG demo gui [editorG demo entry id const, commandG demo command reverse] main = gtkMain demoGUI demoWidget Hello, world Two gadgets are used: editorG :: String - (a - b) - (b - a - a) - Gadget a commandG :: String - (a - a) - Gadget a The editor gadget can show a value from a state, and update a state with a value. The command gadget can transform a state to a new state. gtkMain connects the gadgets to a widget, which specifies layout using the vbox, attaching the editor gadget to a text box, and the command gadget to a button. Well, that's all pretty trivial. The key thing for me was that I can easily slap a GUI onto the the front of a class of applications, which happen to be the sort of applications I've been writing lately. Also, arbitrary parts of the GUI can respond to things that happen miles away, without really having to worry about it too much. In barrie-0.1 and 0.2, which used stream-based approaches, the problem of getting state from one end of the application to the other was non-trivial. I'll sketch another quick example: data BridgeGame = ... And a bunch of things you can do with the state: makeBid :: Bid - BridgeGame - BridgeGame playCard :: Card - BridgeGame - BridgeGame For bidding, each bid is represented by a gadget: bidG :: Bid - Gadget BridgeGame bidG bid = enabled (bidOK bid) $ CommandG (show bid) (makeBid bid) 'enabled' switches the gadget on if its first argument returns true when applied to the current state. However, the decision about what to do with a disabled gadget is made by its corresponding widget. We get one button for each bid: biddingG :: Gadget BridgeGame biddingG = localG bidding (map bidG allBids) And they can be displayed in any old order using a widget: biddingW :: Widget biddingW = vbox (map suitBids [Club, Diamond, Heart, Spade] ++ [ntBids]) where suitBids suit = hbox $ map (bidButton . flip Bid suit) [1 .. 7] ntBids = hbox $ map (bidButton . NT) [1 .. 7] bidButton bid = ui (show bid) $ labelButton (show bid) (You're right, double, redouble and pass are not represented. They make the lines too long). Screenshot here: http://thewhitelion.org/images/4D.png I've just bid four diamonds, so everything lower than that is automatically disabled. Currently, Barrie implements buttons, text boxes, labels, vertical/horizontal layout, single-column lists and drop lists. It current uses Gtk2hs for rendering, but it's GUI-agnostic (in fact, the first renderer was putStrLn/getLine). You can have a look by using darcs: darcs get http://thewhitelion.org/darcs/barrie Or get the tarball at http://thewhitelion.org/haskell/barrie-0.3.0-src.tar.gz One note: this is not intended to be a theoretically sound approach, merely a way of getting something done quickly. I would expect it to be most useful in putting a GUI front-end onto an existing application, in particular, an application that is driven by user actions which update a state; e.g. a calculator, a bridge game, a 4th edition DD character creator (but that leads to a critical mass of nerdiness, so it's off the table for now) cheers, Fraser. -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Don't use the data (context) = type = constructors syntax, it doesn't do what you want. All it does is add the context to the constructor B while not providing it to any of the functions that use it. A better solution is data Bar a = forall b. Foo a b = B a b or, equivalently, using GADT syntax: data Bar a where B :: Foo a b = a - b - Bar a Pattern matching on B will bring the Foo a b context into scope which will fix b via the functional dependency. However, I prefer this way of solving the problem: class Foo a where type FooVal a ... data Bar a = B a (FooVal a) -- ryan 2009/2/16 Louis Wasserman wasserman.lo...@gmail.com: Is there a way of exploiting functional dependencies in the following fashion? class Foo a b | a - b where... data Foo a b = Bar a = B a b This is not ambiguous, because the functional dependency ensures a unique b if one exists. Can this be done without mentioning b as a type variable in Bar? Louis Wasserman wasserman.lo...@gmail.com ___ 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] forall ST monad
Correct. And under the hood, GHC does implement runST in its existential dual form using a hidden State# type. I wonder however, if we're wandering too far away from the OP's query about grokking runST and how the ST monad works. I'd imagine that means he'd like to see how rank-2 polymorphism keeps different threads separated, something which doesn't require existentials, much less the perforce crippled (because constructivist) duality between the two flavors of quantification. Wolfgang Jeltsch-2 wrote: Am Montag, 16. Februar 2009 19:22 schrieb Wolfgang Jeltsch: Am Montag, 16. Februar 2009 19:04 schrieb Kim-Ee Yeoh: Despite its rank-2 type, runST really doesn't have anything to do with existential quantification. First, I thought so too but I changed my mind. To my knowledge a type (forall a. T[a]) - T' is equivalent to the type exists a. (T[a] - T'). It’s the same as in predicate logic – Curry-Howard in action. Oops, this is probably not true. The statement holds for classical predicate logic with only non-empty domains. But in constructivist logic only the first of the above statements follows from the second, not the other way round. So arguing with the Curry-Howard isomorphism fails and indeed, the two types are not equivalent. There is just a function from the second to the first (it’s the function application function ($) actually). -- View this message in context: http://www.nabble.com/forall---ST-monad-tp22024677p22044960.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional GUIs again
Oh, cheers! Newtype deriving is more general than I expected. Thanks for
the comment.
I've requested a hackage account, so I expect it to be there shortly :-)
cheers,
Fraser.
On Mon, Feb 16, 2009 at 9:12 PM, Ryan Ingram ryani.s...@gmail.com wrote:
Tiny code-review comment:
data Style = Style [(String, StyleValue)]
deriving (Read, Show)
instance Monoid Style where
mempty = Style []
mappend (Style xs) (Style ys) = Style (xs ++ ys)
=
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
newtype Style = Style [(String, StyleValue)]
deriving (Read, Show, Monoid)
Also, put it on hackage! :) It looks pretty cool.
-- ryan
2009/2/16 Fraser Wilson blancoli...@gmail.com:
Since I'm congenitally lazy, and writing a GUI by hand in the IO monad is
... not what I expect from a beautiful program, and because what I often
need is a GUI that manipulates a state, and because I don't understand
arrows, and having been intrigued by a recent cafe thread, I threw
together
a prototype GUI library with the following features:
- the GUI is defined on three levels: gadgets, widgets and styles
- gadgets are functions on a state
- widgets are data structures which define the layout
- styles are ways to modify the appearance of widgets
The following quick example shows a text box and a button. Clicking on
the
button reverses the text in the text box.
module Main where
import Barrie
demoWidget :: Widget
demoWidget = vbox [ui demo entry textBox,
ui demo command (labelButton click me)]
type DemoState = String
type DemoGadget = Gadget DemoState
demoGUI :: DemoGadget
demoGUI = localG demo gui [editorG demo entry id const,
commandG demo command reverse]
main = gtkMain demoGUI demoWidget Hello, world
Two gadgets are used:
editorG :: String - (a - b) - (b - a - a) - Gadget a
commandG :: String - (a - a) - Gadget a
The editor gadget can show a value from a state, and update a state with
a
value. The command gadget can transform a state to a new state. gtkMain
connects the gadgets to a widget, which specifies layout using the vbox,
attaching the editor gadget to a text box, and the command gadget to a
button.
Well, that's all pretty trivial. The key thing for me was that I can
easily
slap a GUI onto the the front of a class of applications, which happen to
be
the sort of applications I've been writing lately. Also, arbitrary parts
of
the GUI can respond to things that happen miles away, without really
having
to worry about it too much. In barrie-0.1 and 0.2, which used
stream-based
approaches, the problem of getting state from one end of the application
to
the other was non-trivial.
I'll sketch another quick example:
data BridgeGame = ...
And a bunch of things you can do with the state:
makeBid :: Bid - BridgeGame - BridgeGame
playCard :: Card - BridgeGame - BridgeGame
For bidding, each bid is represented by a gadget:
bidG :: Bid - Gadget BridgeGame
bidG bid = enabled (bidOK bid) $ CommandG (show bid) (makeBid bid)
'enabled' switches the gadget on if its first argument returns true when
applied to the current state. However, the decision about what to do
with a
disabled gadget is made by its corresponding widget.
We get one button for each bid:
biddingG :: Gadget BridgeGame
biddingG = localG bidding (map bidG allBids)
And they can be displayed in any old order using a widget:
biddingW :: Widget
biddingW = vbox (map suitBids [Club, Diamond, Heart, Spade] ++ [ntBids])
where suitBids suit = hbox $ map (bidButton . flip Bid suit) [1 .. 7]
ntBids = hbox $ map (bidButton . NT) [1 .. 7]
bidButton bid = ui (show bid) $ labelButton (show bid)
(You're right, double, redouble and pass are not represented. They make
the
lines too long).
Screenshot here: http://thewhitelion.org/images/4D.png
I've just bid four diamonds, so everything lower than that is
automatically
disabled.
Currently, Barrie implements buttons, text boxes, labels,
vertical/horizontal layout, single-column lists and drop lists. It
current
uses Gtk2hs for rendering, but it's GUI-agnostic (in fact, the first
renderer was putStrLn/getLine).
You can have a look by using darcs:
darcs get http://thewhitelion.org/darcs/barrie
Or get the tarball at
http://thewhitelion.org/haskell/barrie-0.3.0-src.tar.gz
One note: this is not intended to be a theoretically sound approach,
merely
a way of getting something done quickly. I would expect it to be most
useful in putting a GUI front-end onto an existing application, in
particular, an application that is driven by user actions which update a
state; e.g. a calculator, a bridge game, a 4th edition DD character
creator
(but that leads to a critical mass of nerdiness, so it's off the table
Re: [Haskell-cafe] Looping after compiling with cabal
On Mon, 16 Feb 2009 14:56:01 +0100, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Montag, 16. Februar 2009 13:07 schrieb Neil Mitchell: Hi Henk-Jan, I believe cabal adds a -O on the command line, perhaps try ghc --make -O (after deleting all object files) If it’s the -O option what causes the loop then it is problably because of this: http://hackage.haskell.org/trac/ghc/ticket/2722 Best wishes, Wolfgang It is the -O option. How do I get/install the patch mentioned in this ticket? -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Low-level high-level languages?
C-- is kind of dead; it lives on in spirit as a data type used by the back end of GHC, but there hasn't been much development in C-- as a language proper in a while. LLVM seems to be gaining momentum in that space; Lennart has been posting some experiments with generating LLVM code in Haskell in his blog: http://augustss.blogspot.com/ Neither of these are really designed to be directly authored by humans; they are targeted as intermediate languages which are compiled into by some sort of front-end. -- ryan 2009/2/16 Fraser Wilson blancoli...@gmail.com: What was that stripped-down low-level version of C I saw coming out of ... was it Microsoft Research? C-- or something. Unfortunately, the name appears to be immune to Googling. 2009/2/16 Alberto G. Corona agocor...@gmail.com http://www.ats-lang.org/ 2009/2/16 Jon Fairbairn jon.fairba...@cl.cam.ac.uk Maurício briqueabra...@yahoo.com writes: Hi, I've checked this 'BitC' language (www.bitc-lang.org). It uses some ideas we see in Haskell, although with different realization, and target mainly reliable low level code, like micro-kernels (although I think it could be used anywhere C is also used, including writing libraries Haskell could call with FFI). Do you guys know of other languages like that that I could check? Hume http://www-fp.cs.st-andrews.ac.uk/hume/index.shtml might be worth a look. I've never tried it, and since one of the top chaps associated with it said to me that he loathes Haskell, I'm not sure I should mention it here :-) -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31) ___ 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 -- http://thewhitelion.org/mysister ___ 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: ANNOUNCE: pqueue-mtl, stateful-mtl
Louis Wasserman wasserman.lo...@gmail.com wrote in article ab4284220902160801x51e6c3b6m3a7ee0698ac97...@mail.gmail.com in gmane.comp.lang.haskell.cafe: The point here is that a MonadST instance guarantees that the bottom monad is an ST -- and therefore single-threaded of necessity -- and grants any ST-based monad transformers on top of it access to its single state thread. This approach sounds like Fluet and Morrisett's monadic regions (ICFP 2004, JFP 2006), for which Oleg and I produced a easier-to-use implementation (Haskell 2008). You may find these papers helpful! http://ttic.uchicago.edu/~fluet/research/rgn-monad/ http://okmij.org/ftp/Haskell/regions.html#light-weight -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Attending a mathematics lecture is like walking through a thunderstorm at night. Most of the time you are lost, wet and miserable but at rare intervals there is a flash of lightening and the whole countryside is lit up. - Tom Koerner ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
On Monday 16 February 2009 8:44:21 am Josef Svenningsson wrote:
On Mon, Feb 16, 2009 at 2:30 AM, wren ng thornton w...@freegeek.org wrote:
Louis Wasserman wrote:
I follow. The primary issue, I'm sort of wildly inferring, is that use
of STT -- despite being pretty much a State monad on the inside --
allows access to things like mutable references?
That's exactly the problem. The essential reason for ST's existence are
STRefs which allow mutability.
I'd like to point out one other thing that ST provides, which is often
forgotten. It provides *polymorphic* references. That is, we can
create new references of any type.
So ST is a really magical beast. Not only does it provide mutation, it
also provides mutable references. And these are two different
features. Now, everyone agrees that mutation is not something that you
can implement in a functional language, so ST cannot be implemented in
Haskell for that reason. It has to be given as a primitive. But what
about polymorphic references? Can they be implemented in Haskell? The
Claessen conjecture (after Koen Claessen) is that they cannot be
implemented in Haskell. See the following email for more details:
http://www.haskell.org/pipermail/haskell/2001-September/007922.html
One could try and separate mutation and polymorphic references and
give them as two different primitives and implement ST on top of that.
But I haven't seen anyone actually trying that (or needing it for that
matter).
There are a couple approximations you can make for polymorphic references. For
one, you can encode the types of all the references you've made so far in the
type of the monad, so you get a type like:
ST r vec1 vec2 a
where vec1 is the types of references coming in, and vec2 is the same going
out. For instance:
newSTRef :: ST r vec1 (t ::: vec2) (STRef r t)
Or something of that sort. I've fooled with something like this, and it works
somewhat, but the obvious problem is that how many and what type of references
you use has to be statically known, which isn't true for ST.
Someone already mentioned using Dynamic as an alternate base (for instance,
use a Map of dynamics for underlying storage). Of course, the implementation
of Dynamic in GHC uses unsafeCoerce, just like ST, so you may not count that.
However, using GADTs, you can implement Dynamic safely for a closed universe
of types. So you could create a polymorphic reference monad for whatever such
universe you wished. Further, if you actually had open GADTs, you could
actually add the relevant type-rep constructor for every type you declared.
For instance, jhc's implementation of type classes internally uses such a
GADT, so one could theoretically make a safe Dynamic, and thus a safe
polymorphic reference monad.
-- Dan
P.S. Here's some code:
{-# LANGUAGE GeneralizedNewtypeDeriving, Rank2Types #-}
module ST where
import Control.Monad.State
import Data.Dynamic
import Data.Maybe
import qualified Data.IntMap as I
newtype ST r a = ST { unST :: State (I.IntMap Dynamic,Int) a } deriving Monad
newtype STRef r t = STR Int
newSTRef :: Typeable t = t - ST r (STRef r t)
newSTRef v = ST $ do (m, i) - get
put (I.insert i (toDyn v) m, i+1)
return (STR i)
modifySTRef :: Typeable t = STRef r t - t - ST r ()
modifySTRef (STR j) v = ST $ do (m, i) - get
put (I.insert j (toDyn v) m, i)
return ()
readSTRef :: Typeable t = STRef r t - ST r t
readSTRef (STR j) = ST $ do (m, i) - get
return . fromJust . fromDynamic $ m I.! j
runST :: (forall r. ST r a) - a
runST st = evalState (unST st) (I.empty, 0)
test v f = runST (do r - newSTRef v
modifySTRef r (f v)
readSTRef r)
{- test 1 (+1) == 2 -}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl
Dan Doel wrote: Someone already mentioned using Dynamic as an alternate base (for instance, use a Map of dynamics for underlying storage). Of course, the implementation of Dynamic in GHC uses unsafeCoerce, just like ST, so you may not count that. However, using GADTs, you can implement Dynamic safely for a closed universe of types. So you could create a polymorphic reference monad for whatever such universe you wished. Further, if you actually had open GADTs, you could actually add the relevant type-rep constructor for every type you declared. For instance, jhc's implementation of type classes internally uses such a GADT, so one could theoretically make a safe Dynamic, and thus a safe polymorphic reference monad. Apart from the other inconveniences, all of these solutions involve runtime overhead, which is a shame. Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional GUIs again
On Mon, 2009-02-16 at 20:30 +0100, Fraser Wilson wrote: You must have missed the bit about congenitally lazy :-) Username requested ... See http://hackage.haskell.org/packages/accounts.html All you need to do is email Ross and ask. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
On Mon, 2009-02-16 at 19:36 +0100, Wolfgang Jeltsch wrote: Am Montag, 16. Februar 2009 19:22 schrieb Wolfgang Jeltsch: Am Montag, 16. Februar 2009 19:04 schrieb Kim-Ee Yeoh: Despite its rank-2 type, runST really doesn't have anything to do with existential quantification. First, I thought so too but I changed my mind. To my knowledge a type (forall a. T[a]) - T' is equivalent to the type exists a. (T[a] - T'). It’s the same as in predicate logic – Curry-Howard in action. Oops, this is probably not true. The statement holds for classical predicate logic with only non-empty domains. But in constructivist logic only the first of the above statements follows from the second, not the other way round. Not only that, but giving runST an existential type would defeat its safety properties. Taking the `let open' syntax from `First-class Modules for Haskell' [1], we can say let open runST' = runST in let ref = runST' $ newSTRef 0 !() = runST' $ writeSTRef ref 1 !() = runST' $ writeSTRef ref 2 in runST' $ readSTRef ref This type-checks because the let open gives us the *same* skolemized constant for s everywhere in the sequel. Now, the above de-sugars to let open runST' = runST in let ref = runST' $ newSTRef 0 x = runST' $ writeSTRef ref 1 y = runST' $ writeSTRef ref 2 in case x of () - case y of () - runST' $ readSTRef ref Haskell's semantics (if we could write runST in Haskell) would let us re-order the cases in this instance --- with changes the over-all value from 2 to 1. In fact, if you inline x and y, you can discard the cases entirely, so the expression has value 0. Summary: Existential types are not enough for ST. You need the rank 2 type, to guarantee that *each* application of runST may (potentially) work with a different class of references. (A different state thread). jcc [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/first-class-modules/index.htm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional GUIs again
Now that I re-read my email, it looks like I'm saying Username requested in the sense of OK, Cafe people, treat this as a user name request and step to it. What I meant was that I have requested a username (via the email), and once I have an account I'll put it on hackage. Sorry for the confusion. Also, a patch that derives the Monoid instance for Style has been pushed. Let me explain why I love this mailing list. I hadn't really looked at Monoids, but then their utility fell out of the recent discussion about whether they should be called Monoids or ... whatever the other name was. And now I see them all over the place, and I'm a better person for it. Surely this is too much to be considered actual programming! cheers, Fraser. On Mon, Feb 16, 2009 at 10:40 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Mon, 2009-02-16 at 20:30 +0100, Fraser Wilson wrote: You must have missed the bit about congenitally lazy :-) Username requested ... See http://hackage.haskell.org/packages/accounts.html All you need to do is email Ross and ask. Duncan -- http://thewhitelion.org/mysister ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Infinite types should be optionally allowed
On Sat, Feb 14, 2009 at 2:06 PM, Job Vranish jvran...@gmail.com wrote: I'm pretty sure that the problem is decidable, at least with haskell 98 types (other type extensions may complicate things a bit). It ends up being a graph unification algorithm. I've tried some simple algorithms and they seem to work. What do you mean by the inference engine is only half of the story? From what I understand, the inference engine infers types via unification, if the types unify, then the unified types are the inferred types, if the types don't unify, then type check fails. Am I missing/misunderstanding something? Sorry it took me so long to respond. It took a while to formulate this example. Here are two (convoluted) functions, passed to the fixtypes inference engine: Expr y (b (c i) (c (b b (b c (c i) (fix b . (a - b - (a - c - d) - d) - c) - c Expr y (b (c i) (b (c (b b (b c (c i (b (c i) k))) (fix c . ((a - ((b - c) - d) - (a - d - e) - e) - f) - f) These are somewhat complex types; sorry about that. But here's a challenge: is one of these types more general than the other? For example, if you wrote the first term and gave the second signature, should it typecheck? If you figure it out, can you give an algorithm for doing so? I'm not going to say how I came up with these functions, because that would give away the answer :-) Luke I almost think that the problem might be solvable by just generating the appropriate newtype whenever an infinite type shows up, and doing the wrapping/unwrapping behind the scenes. This would be a hacked up way to do it, but I think it would work. On Fri, Feb 13, 2009 at 6:09 PM, Luke Palmer lrpal...@gmail.com wrote: On Fri, Feb 13, 2009 at 4:04 PM, Luke Palmer lrpal...@gmail.com wrote: On Fri, Feb 13, 2009 at 3:13 PM, Job Vranish jvran...@gmail.com wrote: There are good reasons against allowing infinite types by default (mostly, that a lot of things type check that are normally not what we want). An old haskell cafe conversation on the topic is here: http://www.nabble.com/There%27s-nothing-wrong-with-infinite-types!-td7713737.htmlhttp://www.nabble.com/There%27s-nothing-wrong-with-infinite-types%21-td7713737.html However, I think infinite types should be allowed, but only with an explicit type signature. In other words, don't allow infinite types to be inferred, but if they are specified, let them pass. I think it would be very hard to shoot yourself in the foot this way. Oops! I'm sorry, I completely misread the proposal. Or read it correctly, saw an undecidability hiding in there, and got carried away. What you are proposing is called equi-recursive types, in contrast to the more popular iso-recursive types (which Haskell uses). There are plentiful undecidable problems with equi-recursive types, but there are ways to pull it off. The question is whether these ways play nicely with Haskell's type system. But because of the fundamental computational problems associated, there needs to be a great deal of certainty that this is even possible before considering its language design implications. That inference engine seems to be a pretty little proof-of-concept, doesn't it? But it is sweeping some very important stuff under the carpet. The proposal is to infer the type of a term, then check it against an annotation. Thus every program is well-typed, but it's the compiler's job to check that it has the type the user intended. I like the idea. But the inference engine is only half of the story. It does no type checking. Although checking is often viewed as the easier of the two problems, in this case it is not. A term has no normal form if and only if its type is equal to (forall a. a). You can see the problem here. Luke Newtype is the standard solution to situations where you really need an infinite type, but in some cases this can be a big annoyance. Using newtype sacrifices data type abstraction and very useful type classes like Functor. You can use multiparameter type classes and functional dependencies to recover some of the lost abstraction, but then type checking becomes harder to reason about and the code gets way more ugly (If you doubt, let me know, I have some examples). Allowing infinite types would fix this. I'm imagining a syntax something like this: someFunctionThatCreatesInfiniteType :: a - b | b = [(a, b)] Thoughts? Opinions? Am I missing anything obvious? - Job ___ 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] Functional GUIs again
Hi Fraser, That's some great hacking you did :-) What version of GTK2HS did you use? I get various compiler errors when using the latest GTK2HS 0.10.0. Cheers, Peter 2009/2/16 Fraser Wilson blancoli...@gmail.com Now that I re-read my email, it looks like I'm saying Username requested in the sense of OK, Cafe people, treat this as a user name request and step to it. What I meant was that I have requested a username (via the email), and once I have an account I'll put it on hackage. Sorry for the confusion. Also, a patch that derives the Monoid instance for Style has been pushed. Let me explain why I love this mailing list. I hadn't really looked at Monoids, but then their utility fell out of the recent discussion about whether they should be called Monoids or ... whatever the other name was. And now I see them all over the place, and I'm a better person for it. Surely this is too much to be considered actual programming! cheers, Fraser. On Mon, Feb 16, 2009 at 10:40 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Mon, 2009-02-16 at 20:30 +0100, Fraser Wilson wrote: You must have missed the bit about congenitally lazy :-) Username requested ... See http://hackage.haskell.org/packages/accounts.html All you need to do is email Ross and ask. Duncan -- http://thewhitelion.org/mysister ___ 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] ANN: The Typeclassopedia, and request for feedback
On Mon, 2009-02-16 at 15:30 +0100, Fraser Wilson wrote: Super! Also, best definition of bottom I've yet seen -- ignoring _| _, which is a party pooper. Like good code, it's short, to the point, and obviously correct. This brings up something I've thought about: On page 8, it is said that Pointed doesn't need to be checked because the theorem comes for free, but the free theorems paper was based upon total functions only; does having _|_ affect the free theorem for Pointed? - George 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
Re: [Haskell-cafe] parallelism or concurrency ? if they are different
On Fri, 13 Feb 2009 11:09:35 +0100, Paolino paolo.verone...@gmail.com wrote: When I came to haskell, I arrived with a small and only evolutionary background in programming. First monad I met was MonadState StdGen m. Everything was in someway acceptable, I had no problem in explicitating the need for the generator. The lesson was referential transparency. To me referential tranparency is still obscure as a feature. Not using the monad , my functions pass around a generator, then they are repeatable, same generator , same computation. Years pass by, now evolutionary algorithms need to scale multicores. But multicore can be used with threads or par, the difference is that par is pure, because it respects referential transparency. But threads not. They are always unrespectful ? Or it's an implementation issue of preemptive choice? Can I have a baton to pass around like I had for random generator, so that the computation ends without IO (unsafe performed) , without breaking tranparency, something like (runIOThreads :: ThreadsIO a - ThreadsBaton - a) ? From Real World Haskell my algorithm have to be parallelized as they don't do some kind of IO, they don't deal with the world, but where is it stated that it is possible to write them with par (I couldn't) ? More , I'm not caring that my computation is unrepeatable, for me it's fine that the runtime system gives me the cached results for same arguments computation. The fact that it doesn't ,and recompute the function giving out something fuzzily different from before, is enough to coerce me to spit out IO values ? Finally, why and where the optimizer will substitute a value with its definition, so that it possibly get computed twice ? Thanks paolino I am not an expert in this matter, but as nobody answered sofar (perhaps people were frightened off by a lack of structure in your text), I will try to give some pointers: - You can start a function with parameters in a thread like this threadId - forkIO (foo 42) where foo has type Int - IO () - Communication between threads can be done with MVars, see: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent-MVar.html - You can find concurrency demos at: http://www.haskell.org/haskellwiki/Concurrency_demos - Links to articles about parallelism: http://www.haskell.org/haskellwiki/Blog_articles/Parallel - To prevent recomputing, read: http://www.haskell.org/haskellwiki/Memoization -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Complex C99 type in Foreign
On 2009-02-14, Maurício briqueabra...@yahoo.com wrote: The way you wrote CComplex a, is it possible to write foreign import ccall somename somename :: CComplex CDouble - IO CComplex CDouble Ah, no, I'm afraid not, I misunderstood what you wanted. You do indeed need to go through CPtr (CComplex CDouble) with this scheme. I think having direct access at this level requires modifying the compiler. The FFI spec really does need to be updated to C99. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functional GUIs again
Hi Peter, Thanks! I haven't tried to compile with 0.10.0 but I can guess that the errors arise from the use of ListStore. I'm not sure what the best approach is here. Is 0.9.13 over now? If so, then I'll upgrade and fix it. For now it would certainly make sense to put the dependency into the cabal file, which I'm ashamed to say never occorred to me. cheers, Fraser On 17 feb 2009, at 00:29, Peter Verswyvelen bugf...@gmail.com wrote: That's some great hacking you did :-) What version of GTK2HS did you use? I get various compiler errors when using the latest GTK2HS 0.10.0. Cheers, Peter 2009/2/16 Fraser Wilson blancoli...@gmail.com Now that I re-read my email, it looks like I'm saying Username requested in the sense of OK, Cafe people, treat this as a user name request and step to it. What I meant was that I have requested a username (via the email), and once I have an account I'll put it on hackage. Sorry for the confusion. Also, a patch that derives the Monoid instance for Style has been pushed. Let me explain why I love this mailing list. I hadn't really looked at Monoids, but then their utility fell out of the recent discussion about whether they should be called Monoids or ... whatever the other name was. And now I see them all over the place, and I'm a better person for it. Surely this is too much to be considered actual programming! cheers, Fraser. On Mon, Feb 16, 2009 at 10:40 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Mon, 2009-02-16 at 20:30 +0100, Fraser Wilson wrote: You must have missed the bit about congenitally lazy :-) Username requested ... See http://hackage.haskell.org/packages/accounts.html All you need to do is email Ross and ask. Duncan -- http://thewhitelion.org/mysister ___ 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] Haskell.org GSoC
Daniel Kraft wrote: Do you think something would be especially nice to have and is currently missing? Have type class aliases been implemented yet? This proposal (or parts or it) seems like a very useful compiler extension to have, and might be an interesting GSoC project. http://repetae.net/recent/out/classalias.html Kind regards, Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN : Crypto 4.2.0 Related News
On Mon, Feb 16, 2009 at 12:48 PM, Creighton Hogg wch...@gmail.com wrote: Hello Haskellers, I'm pleased to announce version 4.2.0 of Crypto has been uploaded to Hackage that I am taking over maintenance of the library from Dominic Steinitz. As of this release it should be cabal install'able on GHC 6.10.1. I'm also pleased to announce that the darcs repo will be moving from code.haskell.org to being hosted on Patch-Tag at http://patch-tag.com/repo/crypto/home. You don't need to sign up for Patch-Tag to use the read only repos, but you will need an account if you want to be given write access to the crypto repository. Please feel free to e-mail me with any issues or questions. Cheers, Creighton It's nice to see dogfooding of haskell frameworks - are there any announcements or blog postings anywhere for Patch-Tag? Maybe I missed something. Also I'm getting a 'not authorized' message when opening the above link. -Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN : Crypto 4.2.0 Related News
On Mon, Feb 16, 2009 at 7:30 PM, Antoine Latter aslat...@gmail.com wrote: On Mon, Feb 16, 2009 at 12:48 PM, Creighton Hogg wch...@gmail.com wrote: Hello Haskellers, I'm pleased to announce version 4.2.0 of Crypto has been uploaded to Hackage that I am taking over maintenance of the library from Dominic Steinitz. As of this release it should be cabal install'able on GHC 6.10.1. I'm also pleased to announce that the darcs repo will be moving from code.haskell.org to being hosted on Patch-Tag at http://patch-tag.com/repo/crypto/home. You don't need to sign up for Patch-Tag to use the read only repos, but you will need an account if you want to be given write access to the crypto repository. Please feel free to e-mail me with any issues or questions. Cheers, Creighton It's nice to see dogfooding of haskell frameworks - are there any announcements or blog postings anywhere for Patch-Tag? Maybe I missed something. Also I'm getting a 'not authorized' message when opening the above link. Ah, the repo was accidentally marked private. I've fixed that now. There have been a few bits of news about Patch-Tag so far, actually, but I think a good place to look right now is their blog http://blog.patch-tag.com/. Cheers, C ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: The Typeclassopedia, and request for feedback
Natural numbers under min don't form a monoid, only naturals under max do (so you can have a zero element) Brent Yorgey wrote: Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Here's the abstract: The standard Haskell libraries feature a number of type classes with algebraic or categorical underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs. The goal of this article is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-fee dback/ happy haskelling! -Brent ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: The Typeclassopedia, and request for feedback
I'm really confused that when I replied (not reply-to-all, not reply-to-list, just reply) to that message, it went to the lists and not to you Brent! (KMail 1.10.3) -- so I totally edited the To lines, to send this message... Brent Yorgey wrote: Hi all, If you've noticed the lack of a HWN this week, that's because I've been doggedly finishing my article entitled 'The Typeclassopedia', which I have just submitted for publication in the Monad.Reader. Here's the abstract: The standard Haskell libraries feature a number of type classes with algebraic or categorical underpinnings. Becoming a fluent Haskell hacker requires intimate familiarity with them all, yet acquiring this familiarity often involves combing through a mountain of tutorials, blog posts, mailing list archives, and IRC logs. The goal of this article is to serve as a starting point for the student of Haskell wishing to gain a firm grasp of its standard type classes. The essentials of each type class are introduced, with examples, commentary, and extensive references for further reading. My hope is that this will be a valuable resource to the Haskell community, especially those who are learning. Any feedback would be greatly appreciated, especially if it helps improve the article before publication. A draft can be found here: http://www.cis.upenn.edu/~byorgey/papers/typeclassopedia-draft-090216.pdf Also see my blog post for a bit more info: http://byorgey.wordpress.com/2009/02/16/the-typeclassopedia-request-for-fee dback/ happy haskelling! -Brent ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: The Typeclassopedia, and request for feedback
Isaac Dupree wrote: Natural numbers under min don't form a monoid, only naturals under max do (so you can have a zero element) Though, FWIW, you can use Nat+1 with the extra value standing for Infinity as the identity of min (newtype Min = Maybe Nat). I bring this up mainly because it can be helpful to explain how we can take the almost monoid of m...@nat and monoidize it. Showing how this is similar to and different from m...@nat is enlightening. Showing the min monoid on negative naturals with 0 as the identity, and no need for the special +1 value, would help drive the point home. (Also, the min/max duality is mirrored in intersection/union on sets where we need to introduce either the empty set (usually trivial) or the universal set (usually overlooked).) Or maybe that would be better explained in a reference rather than the main text. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANN: The Typeclassopedia, and request for feedback
On Mon, Feb 16, 2009 at 8:13 PM, wren ng thornton w...@freegeek.org wrote: Isaac Dupree wrote: Natural numbers under min don't form a monoid, only naturals under max do (so you can have a zero element) Though, FWIW, you can use Nat+1 with the extra value standing for Infinity as the identity of min (newtype Min = Maybe Nat). Indeed, as well as you can use lazy naturals with infinity as the unit: data Nat = Zero | Succ Nat infinity = Succ infinity min Zero _ = Zero min _ Zero = Zero min (Succ x) (Succ y) = Succ (min x y) I bring this up mainly because it can be helpful to explain how we can take the almost monoid of m...@nat and monoidize it. Showing how this is similar to and different from m...@nat is enlightening. Showing the min monoid on negative naturals with 0 as the identity, and no need for the special +1 value, would help drive the point home. (Also, the min/max duality is mirrored in intersection/union on sets where we need to introduce either the empty set (usually trivial) or the universal set (usually overlooked).) Or maybe that would be better explained in a reference rather than the main text. -- Live well, ~wren ___ 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] Memory
Hello All, The kind people at #haskell suggested I come to haskell-cafe for questions about haskell performance issues. I'm new to haskell, and I'm having a hard time understanding how to deal with memory leaks. I've been playing with some network server examples and I noticed with each new connection, the memory footprint increases by about 7k However, the leaks don't seem to have anything to do with the networking code. Actually I get a huge leak just from using using 'forever'. import Control.Monad import System.IO main = forever $ putStrLn hi When I run it for a few seconds with profiling... total time =0.36 secs (18 ticks @ 20 ms) total alloc = 54,423,396 bytes (excludes profiling overheads) Can this be right? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory
inbuninbu: Hello All, The kind people at #haskell suggested I come to haskell-cafe for questions about haskell performance issues. I'm new to haskell, and I'm having a hard time understanding how to deal with memory leaks. I've been playing with some network server examples and I noticed with each new connection, the memory footprint increases by about 7k However, the leaks don't seem to have anything to do with the networking code. Actually I get a huge leak just from using using 'forever'. import Control.Monad import System.IO main = forever $ putStrLn hi When I run it for a few seconds with profiling... total time =0.36 secs (18 ticks @ 20 ms) total alloc = 54,423,396 bytes (excludes profiling overheads) Can this be right? did you compile with optimisations on? $ ghc -O2 A.hs --make $ time ./A +RTS -sstderr 17,880 bytes maximum residency (1 sample(s)) 18,984 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 9951 collections, 0 parallel, 0.07s, 0.07s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time0.00s ( 0.00s elapsed) MUT time4.45s ( 16.08s elapsed) GCtime0.07s ( 0.07s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time4.52s ( 16.16s elapsed) %GC time 1.5% (0.5% elapsed) Alloc rate1,173,414,505 bytes per MUT second Productivity 98.5% of total user, 27.5% of total elapsed ./A +RTS -sstderr 4.52s user 10.61s system 93% cpu 16.161 total So it's allocating small cells, frequently, then discarding them -- and running in constant space. Looking further, forever :: (Monad m) = m a - m b forever a = a forever a Well, here, the result is thrown away anyway. And the result is (), so I'd expect constant space. Looks good to me. Did you run it without optimisations, on , perhaps? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory
On 17/02/2009, at 3:56 PM, Jeff Douglas wrote: Hello All, The kind people at #haskell suggested I come to haskell-cafe for questions about haskell performance issues. I'm new to haskell, and I'm having a hard time understanding how to deal with memory leaks. I've been playing with some network server examples and I noticed with each new connection, the memory footprint increases by about 7k However, the leaks don't seem to have anything to do with the networking code. Actually I get a huge leak just from using using 'forever'. import Control.Monad import System.IO main = forever $ putStrLn hi When I run it for a few seconds with profiling... total time =0.36 secs (18 ticks @ 20 ms) total alloc = 54,423,396 bytes (excludes profiling overheads) Can this be right? I don't think there should be a space leak in the code you posted. On my mac, OS X 10.5.6, GHC version 6.8.3, it appears to run in constant space with or without optimisation. GHCi seems to gobble a little bit of memory (but that could be incidental). My terminal application does gobble memory for a while (and then frees it), but that is presumably because it is hammering the buffer (and it nearly sets my lap on fire when running). Perhaps you could post more details about how it is compiled, and what versions of things are being used. How are you detecting the leak (via top?). Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory
Thanks Guys, Not only did I not run optimizations, I misread the profile. It looks like it was an imaginary problem from the beginning. I guess I should go through all the profiling documentation more carefully. Jeff On Tue, Feb 17, 2009 at 2:46 PM, Bernie Pope bj...@csse.unimelb.edu.au wrote: On 17/02/2009, at 3:56 PM, Jeff Douglas wrote: Hello All, The kind people at #haskell suggested I come to haskell-cafe for questions about haskell performance issues. I'm new to haskell, and I'm having a hard time understanding how to deal with memory leaks. I've been playing with some network server examples and I noticed with each new connection, the memory footprint increases by about 7k However, the leaks don't seem to have anything to do with the networking code. Actually I get a huge leak just from using using 'forever'. import Control.Monad import System.IO main = forever $ putStrLn hi When I run it for a few seconds with profiling... total time =0.36 secs (18 ticks @ 20 ms) total alloc = 54,423,396 bytes (excludes profiling overheads) Can this be right? I don't think there should be a space leak in the code you posted. On my mac, OS X 10.5.6, GHC version 6.8.3, it appears to run in constant space with or without optimisation. GHCi seems to gobble a little bit of memory (but that could be incidental). My terminal application does gobble memory for a while (and then frees it), but that is presumably because it is hammering the buffer (and it nearly sets my lap on fire when running). Perhaps you could post more details about how it is compiled, and what versions of things are being used. How are you detecting the leak (via top?). Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
