Re: [Haskell-cafe] can Haskell do everyting as we want?
On 4 August 2010 10:42, Rogan Creswick cresw...@gmail.com wrote: Haskell has very limited support for high-level Natural Language Processing [snip] This isn't a fault of the language, it just I have some hope that jvm-bridge can be resurrected to bind to OpenNLP, but that's something I've only spent a few days thinking about. (I'd love to have some pointers / help / documentation on jvm-bridge, if anyone has insights :) --Rogan Thanks. -- Qi Qi ___ 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 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: parsec2 - a fork or parsec circa 2.1
On 2 August 2010 16:24, Jean-Philippe Bernardy berna...@chalmers.se wrote: Can you explain why you could not use the parsec name, with revision number (say) 2.2? This would help improve hackage/cabal/... versioning mechanism. I think the idea is to give it more prominence: if you go to http://hackage.haskell.org/package/parsec, the version that hits you immediately is 3.1.0; it isn't as immediately obvious that there is a new parsec-2.x version out. That said, if parsec2 is only a bug-fix branch of parsec-2.x, is there any particular reason work couldn't be done to improve the performance of parsec-3 when using the compatibility layer (and even improving the performance of parsec-3 overall) rather than a specific branch/fork? Unless the API changes from either parsec-2.x or the compatibility modules in parsec-3, I'm not sure how much use this would be; as it stands, in Gentoo we already tweak a lot of package cabal files to remove the upper bounds on parsec some of them impose, and we're likely to do the same to make packages that use parsec2 just use normal parsec instead. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem installing pivotal
On 3 August 2010 15:02, rustom rustompm...@gmail.com wrote: I tried to install pivotal According to the site I must do: ghc --make Main -fglasgow-exts -package plugins I get cant satisfy package plugins Which version of GHC are you using? If you're using 6.12, then you're out of luck: plugins won't work with it yet. I believe the more general problem is that one has to choose between 'direct' cabal installs and using debian's packages. At least this is the same situation Ive seen before in python, ruby etc. Preferably, use a distro package if there is one. If there isn't, then use cabal-install to install it to your home directory (which means you'll have to maintain it yourself). So this is really 2 questions: 1. How to remove this error and install pivotal cabal install pivotal (if you have GHC-6.10.*) 2. Is it better to install haskell-platform or is it better to have a minimal install of ghc and then use hackage/cabal [Or is this a type- wrong question :-) ] In general, I recommend you stick with your distribution's packages as much as possible (assuming they're kept up to date) and only resort to cabal-install when necessary; distribution packages typically interact with the system (in terms of non-Haskell dependencies, etc.) better. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 1 August 2010 20:43, Ertugrul Soeylemez e...@ertes.de wrote: Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: No, a pure function is one without any side effects. There are no functions with side effects in Haskell, unless you use hacks like unsafePerformIO. Every Haskell function is perfectly referentially transparent, i.e. pure. At code-writing time, yes; at run-time there are side effects... In terms of what a function does, is readFile actually pure? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 2 August 2010 14:47, Lyndon Maydwell maydw...@gmail.com wrote: I thought it was pure as, conceptually, readFile isn't 'run' rather it constructs a pure function that accepts a unique world state as a parameter. This might be totally unrealistic, but this is how I see IO functions remaining pure. Is this a good mental model? That is what I believe Ertugrul is aiming at, but I believe that that is a rule-lawyering interpretation in trying to argue that all of Haskell is pure. We could use this same argument to state that _all_ programming languages are pure, as they too have implict World state variables that get passed around. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Can we come out of a monad?
On 2 August 2010 14:59, Lyndon Maydwell maydw...@gmail.com wrote: That's true I suppose, although since there are no implicit parameters in haskell, it really has to be a DSL in implementation, rather than just theory right? http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/other-type-extensions.html#implicit-parameters You were saying? ;p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new Cabal user question -- installing to Haskell Platform on Windows network drive?
On 30 July 2010 13:32, Peter Schmitz ps.hask...@gmail.com wrote: I have a question about finding the Gtk2Hs demos (the demos written in Haskell). They're not there: http://osdir.com/ml/haskell-cafe@haskell.org/2010-07/msg00724.html -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need Control.Monad.State
On 28 July 2010 12:39, michael rice nowg...@yahoo.com wrote: How do I import Control.Monad.State? Install and use the mtl library (comes with the Haskell platform), monads-fd (almost identical API to mtl; the point of this is that mtl uses some extension: the non-extension bits are in the transformers library and monads-fd extends transformers by using extensions to implement mtl functionality) or monads-tf (a different approach to what monads-fd does using different extensions). To check if you have mtl installed (substitute the other package names if necessary): ghc-pkg list mtl If it isn't installed, you can use cabal-install to install it: cabal install mtl -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need Control.Monad.State
On 28 July 2010 13:03, michael rice nowg...@yahoo.com wrote: [mich...@localhost ~]$ ghc-pkg list mtl /usr/lib/ghc-6.12.1/package.conf.d [mich...@localhost ~]$ Installed? No; if it was installed it would specify a version. Michael --- On Tue, 7/27/10, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: From: Ivan Miljenovic ivan.miljeno...@gmail.com Subject: Re: [Haskell-cafe] Need Control.Monad.State To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Tuesday, July 27, 2010, 10:51 PM On 28 July 2010 12:39, michael rice nowg...@yahoo.com wrote: How do I import Control.Monad.State? Install and use the mtl library (comes with the Haskell platform), monads-fd (almost identical API to mtl; the point of this is that mtl uses some extension: the non-extension bits are in the transformers library and monads-fd extends transformers by using extensions to implement mtl functionality) or monads-tf (a different approach to what monads-fd does using different extensions). To check if you have mtl installed (substitute the other package names if necessary): ghc-pkg list mtl If it isn't installed, you can use cabal-install to install it: cabal install mtl -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need Control.Monad.State
On 28 July 2010 13:17, michael rice nowg...@yahoo.com wrote:
See below. Lot's of warnings. Is the install OK? If so, can I use the same
*import*?
Yeah, the install is OK. The meaning of the warnings are:
* Warning: -fallow-undecidable-instances is deprecated: this GHC
option has changed name, but the mtl package still uses the old name.
* Warning: Module `Prelude' is deprecated: mtl doesn't specify any
bounds on the version of the base library to be used (mainly because
of historic reasons when it wasn't changing much and the Haskell
community wasn't stressing versioning as much; note that the last
version of mtl was released almost 2 years ago). Because a lot of
packages broke when GHC-6.10.4 started shipping with base-4 (along
with base-3 for compatability purposes) due to the differences in how
exceptions were handled, if there is no upper bound on the version of
base to be used then cabal-install plays it safe and uses base-3.
However, the next version of GHC (6.14, which should be coming out
later this year) will not ship with base-3, so GHC-6.12 included that
warning message for people that kept trying to use base-3 that their
code won't work with 6.14.
So yes, now you can use import Control.Monad.State.
Michael
--- On Tue, 7/27/10, Ivan Miljenovic ivan.miljeno...@gmail.com wrote:
If it isn't installed, you can use cabal-install to install it:
cabal install mtl
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
[mich...@localhost ~]$ cabal install mtl
Resolving dependencies...
Downloading mtl-1.1.0.2...
Configuring mtl-1.1.0.2...
Preprocessing library mtl-1.1.0.2...
Building mtl-1.1.0.2...
[ 1 of 21] Compiling Control.Monad.Identity ( Control/Monad/Identity.hs,
dist/build/Control/Monad/Identity.o )
Control/Monad/Cont.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Cont/Class.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Error.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Error/Class.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Identity.hs:1:0:
Warning: Module `Prelude' is deprecated:
You are using the old package `base' version 3.x.
Future GHC versions will not support base version 3.x. You
should update your code to use the new base version 4.x.
Control/Monad/List.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/RWS/Lazy.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/RWS/Strict.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Reader.hs:2:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Reader/Class.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/State/Lazy.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/State/Strict.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Writer.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Writer/Class.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Writer/Lazy.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
Control/Monad/Writer/Strict.hs:1:11:
Warning: -fallow-undecidable-instances is deprecated: use
-XUndecidableInstances or pragma {-# LANGUAGE UndecidableInstances #-} instead
[ 2 of 21] Compiling Control.Monad.Writer.Class (
Control/Monad/Writer/Class.hs, dist/build/Control/Monad/Writer/Class.o )
Control/Monad/Writer/Class.hs:1:0:
Warning: Module `Prelude' is deprecated
Re: [Haskell-cafe] Need Control.Monad.State
On 28 July 2010 14:07, aditya siram aditya.si...@gmail.com wrote: I didn't realize the State monad wasn't part of the base install. Any particular reason for this? Because there's no reason for it to be? GHC is bundled with enough libraries as it is (and with the exception of Cabal, it's not safe to upgrade any of them). However, mtl _is_ part of the Haskell Platform, so in that sense it's part of the _recommended_ base install... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is 'flip' really necessary?
On 26 July 2010 16:33, David Virebayre dav.vire+hask...@gmail.com wrote: On Sun, Jul 25, 2010 at 11:53 PM, Edward Z. Yang ezy...@mit.edu wrote: An interesting alternate spin on flip is infix notation combined with partial application, such as: (`foobar` 3) which is equivalent to \x - foobar x 3 I frequently use this, although the jury's out on whether or not it's more readable. I had HLint suggest me this : before : listeEtagTot = concatMap (flip listeEtagArm cfgTypesTringle) listeArmOrd after : listeEtagTot = concatMap (`listeEtagArm` cfgTypesTringle) listeArmOrd However, if you had something like this, I think the flip version is nicer: With flip: foo = map (f . flip g x) Without flip: foo = map (f . (`g` x)) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] ad large file and match lines to a pattern
On 26 July 2010 00:48, grzyb zbigniew.grzy...@gmail.com wrote: Hi, I'm a beginner in haskell, I was trying to write the following code, but I still encourage some problems, can you help me with that? I need to read a large file and try to match each line to a pattern which is int,int value=string for example: 0,1 value=string1 1,5 value=string2 when the line matches the pattern then I need to get those 3 values (int, int, string) and pass them to my function. Whilst you can probably use the ReadS (or ReadP if you don't care about backwards compatability) parsers for the Read class to do this, I highly recommend you instead learn and use a proper parsing library such as parsec, polyparse or uuparsing-lib for this (as you'll undoubtedly be wanting to do more extensive parsing at a later date). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type problems
On 25 July 2010 05:50, Tobias Brandt tob.bra...@googlemail.com wrote: You have to fix the type of 1 and 6, e.g. by writing x - randomRIO (1, 6) :: IO Int or x - randomRIO (1, 6 :: Int) GHCi defaults integral numbers to Int, that's why it works there. The default numeric type is Integer, not Int. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Experiences with cabal-install and Hackage
On 23 July 2010 02:31, Daniel Fischer daniel.is.fisc...@web.de wrote: On Thursday 22 July 2010 18:23:32, Stephen Tetley wrote: Hiding unmaintained libraries seems contrary to Hackage's spirit - if you want to depend on an unmaintained library why not volunteer to be the maintainer. I think it was more meant to be fails to build and not updated for (= k months) == move to packages/notshiny Which doesn't help if the package doesn't build due to a missing C library, inconsistent dependencies (Hackage using two different versions of bytestring is a common problem I've come across), or is meant for a different (i.e. non-Linux) OS than the one Hackage is on. If it doesn't build and nobody seems to care about it anymore, why let it clutter the pkg-list, that's crowded enough even without zombies. Because it could be a package that builds if you install the correct C library first, and it hasn't been updated for k months because there's no need to. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On documentation
On 22 July 2010 18:33, David Waern david.wa...@gmail.com wrote: [snip] We currently only support concrete examples (i.e. unit tests), but the plan is to add support for QuickCheck properties. Would you have some kind of inbuilt time limit (similar to what mueval has) for very long/complex QC tests? I have some that take quite a while to run... David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On documentation
On 21 July 2010 15:28, Richard O'Keefe o...@cs.otago.ac.nz wrote: I'm giving some lectures this week about how to _read_ programs, and I've had some things to say about JavaDoc and wondered whether to show some examples of Haddock. I took a certain library that has been mentioned recently in this mailing list. (I shall not identify it. The author deserves praise for his/her contribution, not a public mauling, and the reason for the message is that that package is not unusual.) The reason I chose it was that I thought actually, I should learn how to use that, never mind the students. Upon looking at the Haddock web page, - reaction one this is pretty flashy. - reaction two, but WHERE IS THE DOCUMENTATION? These are good points and I agree with the rest of your email as well (which I've removed for the sake of brevity). However, I would like to offer two qualifiers that I myself have found when writing documentation for my own libraries: * When writing the code, it's obvious what it does; as such you may think any documentation you may offer is trivial (down the track, however...). * The author is familiar with a library; as such it may not be obvious what extra documentation could be needed. As such, if you're a user of a library and you think it's documentation could be improved, maybe try telling the maintainer that (this kind of prompting is why I bothered to make a website for my graphviz library). As a kind of a wishlist, having more markup support would possibly improve the quality of documentation (rather than being limited to normal text, monospace text and italic text; I've often times wanted to make something bold in my Haddock documentation to emphasise it but alas Haddock doesn't support it). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Re: ANNOUNCE: container-classes-0.0.0.0
On 18 July 2010 23:35, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: * Someone's asked me why I don't define a Traversable-like class. The reason is is that I haven't gotten around to it yet ;-) (as well as a great many other things). Ugh, I got Traversable mixed up with Foldable (I didn't get enough sleep on the weekend and I should hit the sack now). I've integrated fold right into the definition of Container, and everything else comes straight from that so I didn't see the point of making an explicit sub-class (or a super-class, take your pick) just for that. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: ANNOUNCE: container-classes-0.0.0.0
On 18 July 2010 23:35, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: * Someone's asked me why I don't define a Traversable-like class. The reason is is that I haven't gotten around to it yet ;-) (as well as a great many other things). Ugh, I got Traversable mixed up with Foldable (I didn't get enough sleep on the weekend and I should hit the sack now). I've integrated fold right into the definition of Container, and everything else comes straight from that so I didn't see the point of making an explicit sub-class (or a super-class, take your pick) just for that. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Design for 2010.2.x series Haskell Platform site
On 19 July 2010 04:16, Don Stewart d...@galois.com wrote: Hackage doesn't yet provide support for changelogs. However, it does provide support for repository links, from which we can construct a changelog. That's right: you have to read each repo to get the full changelog, unless the author has been nice to add it to the .cabal file. I think it would be nice if Cabal had (optional) readme and changelog (or just an overall generic documentation) field, so if a package had such a file then Hackage could show it. I think what we need is: * Every HP package has to have a .cabal file with the source repository type and link. For FGL, I'm trying to track down a copy of the old repository that used to be on darcs.haskell.org. Once I've done that I can update it and then publish that in the new code.haskell.org repository. If we have the source repo and type, I can write a tool to extract the changelogs between each release automatically. http://hackage.haskell.org/package/change-monger ? However, an explicit higher-order Changelog is usually preferable IMHO as it can describe what's actually changed rather than whoops, I missed another corner case in my previous patch. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hierarchical modules issue
On 19 July 2010 14:31, Jonathan Geddes geddes.jonat...@gmail.com wrote: Now when I'm working in a subdirectory, say Foo where the modules are named Foo.Bar, Foo.Baz, Foo.etc., and I try to compile Bar.hs which imports Foo.Baz, the compiler looks for the file Foo/Baz.hs. The problem is that I'm already in the directory Foo and so the compiler fails to find the file for the module Foo.Baz. If I compile the whole project from the root project directory where the main file is, the compiler finds every module just fine. A similar query was just asked: http://www.haskell.org/pipermail/haskell-cafe/2010-July/080523.html It seams very strange to me that when the compiler is compiling a module named Foo.Bar and there is an import for Foo.Baz, the compiler doesn't look in the directory where Foo.Bar is located (the current dir)! Run ghc[i] from the root (source) directory of your project, not within the hierarchy (note that haskell-mode for emacs tries to do this by finding where the .cabal file is, etc.). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Re: New FGL naming survey
Thank you for all the people who have voted; we so far have 42 results in about 12 hours. Some indication of the results so far: * 62% prefer inductive-graphs * 62% have indicated that they use fgl or do some graph-related stuff (no correlation, just an interesting coincidence; I have not as yet done the number crunching to tell what the most popular name is for people that actually use fgl or other graph stuff). * Someone stated that ponies smell sweaty... not sure how that's relevant, but OK. * At least two people prefer the new name as it isn't an acronym (one because acronyms aren't needed and the term functional is redundant, the other because the term graph isn't directly in the package name). * Martin Erwig himself said that he thinks we should keep using the name fgl. So, keep the votes coming in (I actually didn't expect this many already)! On 14 July 2010 00:24, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Whether or not the new FGL that Thomas Bereknyei and I are working on should keep the name was a semi-hot issue when we first mentioned the fact that we were working on a new version about a month ago. As such, I've created a survey here to try and find out what the Haskell community overall thinks we should call it: https://spreadsheets.google.com/viewform?formkey=dGpzMmFnUWY3Uktodk5wdHlLQk5kT1E6MA More info can be found on the actual survey page. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: New FGL naming survey
Thank you for all the people who have voted; we so far have 42 results in about 12 hours. Some indication of the results so far: * 62% prefer inductive-graphs * 62% have indicated that they use fgl or do some graph-related stuff (no correlation, just an interesting coincidence; I have not as yet done the number crunching to tell what the most popular name is for people that actually use fgl or other graph stuff). * Someone stated that ponies smell sweaty... not sure how that's relevant, but OK. * At least two people prefer the new name as it isn't an acronym (one because acronyms aren't needed and the term functional is redundant, the other because the term graph isn't directly in the package name). * Martin Erwig himself said that he thinks we should keep using the name fgl. So, keep the votes coming in (I actually didn't expect this many already)! On 14 July 2010 00:24, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Whether or not the new FGL that Thomas Bereknyei and I are working on should keep the name was a semi-hot issue when we first mentioned the fact that we were working on a new version about a month ago. As such, I've created a survey here to try and find out what the Haskell community overall thinks we should call it: https://spreadsheets.google.com/viewform?formkey=dGpzMmFnUWY3Uktodk5wdHlLQk5kT1E6MA More info can be found on the actual survey page. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Please report any bug of gtk2hs-0.11.0!
On 14 July 2010 14:52, bri...@aracnet.com wrote: Short version of this post: Looks like the intsall depends on alex and that dependencies doesn't appear to be handled, i.e. I had to install alex before proceeding. Yes, cabal-install isn't able to cope with the build-tools dependencies. why do is it called gtk2hs if you are actually installing package gtk ;-) The overall meta-project is called gtk2hs, and all these libraries used to come together in one big package called gtk2hs. Where's the demo directory ?! Does it say there's one? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] EnumMap 0.0.2 and Containers-0.3
On 12 July 2010 13:04, Max Cantor mxcan...@gmail.com wrote: Is there a reason that EnumMap specifically requires containers 0.3 or just a matter of not having been tested? It seems to compile just fine (but with one warning for a deprecated call). Because it hasn't been updated since containers-0.3 came out, and most programmers don't have crystal balls to be able to see in the future and see if their code will work with future versions of their dependencies. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On 8 July 2010 17:07, a...@spamcop.net wrote: G'day all. Quoting Ertugrul Soeylemez e...@ertes.de: Do you realize at what level we are complaining? Yes, we're complaining at the level of the frustrated idealist, which is what many Haskell programmers are. So true... :-( /me is still upset that reading a file requires IO... :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] does () match with a??
On 8 July 2010 10:55, Hector Guilarte hector...@gmail.com wrote:
Hey everyone,
I'm making a Game Monad for an assignment (yes, homework) . Here's a little
explanation of what I need to do (I can't use anything from Control.Monad.*,
I need to do everything myself):
I need to define my newtype Game and make it's Monad instance
I need to make the function :
runGame :: Game a -- A particular game
- Int -- Initial amount of lives
- Maybe (a , Int ) -- Result and remaining lives.
I need to make the instance for this class:
class Monad m = GameMonad m where
extraLife :: m ()
getLives :: m Int
checkPoint :: m a - m a
die :: m a
now what I've done (I was inspired by the State Monad)
I defined my Game type as follows:
newtype Game r = Game { execGame :: Int - Maybe (r,Int) }
My Monad instance like this:
instance Monad Game where
return a = Game $ \r - Just (a,r)
m = k = Game $ \r - let x = execGame m r
in case x of
Just (a, r') - execGame (k a) r'
Nothing - Nothing
and my GameMonad instance:
instance GameMonad Game where
extraLife = Game $ \l - Just ((),l+1)
getLives = Game $ \l - Just (l,l)
die = do
n - getLives
Game $ \_ - Just ((),n-1) -- Here's the problem
so, what's bothering me? Look at the type signature of die in the GameMonad
class, it's supposed to return something of type (m a), but I don't know
what to return in that case, and whatever I try to return it doesn't work,
because when I try to compile it says that it couldn't match expected type
'a' against infered type 'whatever' ('whatever' being anything, from (), to
string, or a number). shouldn't 'a' match with anything I put there?
Note that I can't change the signatures because they were giving to me that
way and I already checked with teacher if they were right. (I fixed it
returning Maybe (Maybe a, Int) instead, but I can't change the signature of
the function runGame)
The `die' function doesn't make much sense, because as you've intuited
it must be of _any_ type. You could have die = return undefined
which matches the type signature, but isn't very helpfull, especially
if you try to use the value inside the Monad.
The only other option you have is to use `error', similar to the
default fail method in Monad but with a set message.
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On 8 July 2010 13:36, Ertugrul Soeylemez e...@ertes.de wrote:
To be honest, I don't know any strength of MTL compared to transformers
and monadLib. Actually even transformers is quite primitive compared to
monadLib. The only real advantage is that it has flipped run functions
and a built-in MaybeT.
mtl's advantages: wide pre-existing user base, etc.
transformers (especially when used with monads-{fd,tf}) advantage over
monadLib: pre-existing type aliases, documentation, easier to port old
code that was using mtl.
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Transformers versus monadLib versus...
On 8 July 2010 13:48, Ertugrul Soeylemez e...@ertes.de wrote:
Ivan Miljenovic ivan.miljeno...@gmail.com wrote:
On 8 July 2010 13:36, Ertugrul Soeylemez e...@ertes.de wrote:
To be honest, I don't know any strength of MTL compared to
transformers and monadLib. Actually even transformers is quite
primitive compared to monadLib. The only real advantage is that it
has flipped run functions and a built-in MaybeT.
mtl's advantages: wide pre-existing user base, etc.
As said, I don't think this is a valid argument. Windows has a much
larger user base than Linux. C++ has a much larger user base than
Haskell. We still use Haskell, and many of us use Linux.
My point was, was that if you need to pick a monad transformer library
and you've never done any before, then some people are likely to
choose mtl because it's currently the most-used library, it comes with
the platform and if they need to interact with another package that
uses a monad transformer library then it's more likely to be using mtl
than anything else.
transformers (especially when used with monads-{fd,tf}) advantage over
monadLib: pre-existing type aliases, documentation, easier to port old
code that was using mtl.
If you don't use monadLib-specific features, then most code will run in
monadLib as well as transformers without changes. The Haddock
documentation of monadLib is quite brief, but if you know how to use
monad transformers, you won't have any problems.
I for one don't know how to use monad transformers (I mean, I've read
the section in RWH and could figure it out, but off the top of my head
I can't recall how to do all the lifting stuff, etc.).
And I don't know what you mean by pre-existing type aliases.
http://hackage.haskell.org/packages/archive/transformers/0.2.1.0/doc/html/Control-Monad-Trans-State-Lazy.html#t%3AState
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Canonical Graphviz code
Graphviz (http://graphviz.org/) has the option to convert provided Dot
code for visualising a graph into a canonical form. For example, take
the sample Dot code:
| digraph foo {
| a [color=blue];
| subgraph cluster_bar {
| a [label=hi!]
| b [color=blue, label=bye!];
| b - c;
| }
| a - b;
| a - c;
| c - d;
| d [color=red]
`
Calling dot -Tcanon on this produces:
,
| digraph foo {
| node [label=\N];
| subgraph cluster_bar {
| a [label=hi!, color=blue];
| b [label=bye!, color=blue];
| b - c;
| a - b;
| a - c;
| }
| d [color=red];
| c - d;
| }
`
Note in particular the following:
* The addition of the top-level node [label=\N] attribute; this
happens automatically even if all nodes have their own custom label.
* The two `a' nodes are merged into the inner-most cluster/subgraph
that they are defined in (since they represent the same node).
* The attributes for `b' are re-ordered.
* The a - b and a - c edges are shifted into the cluster, since
all of the related nodes are in that cluster (note that the `c' node
is implicitly defined there since an edge involving it is defined
there).
* The c - d edge is shifted to being _after_ the definition of the
`d' node (in fact, in each grouping all nodes are defined before
edges).
I've recently thought up a way that I can duplicate this functionality
(in terms of what it does, not necessarily the actual output) in my
graphviz library (http://hackage.haskell.org/package/graphviz),
however I'm not sure how closely to follow what Graphviz does. What
would the community prefer out of the following (including a mixture,
such as options 2 and 3):
1) Match Graphviz's output as much as possible (note that the ordering
of the attributes won't happen this way, since I'll be sorting them
alphabetically rather than working out Graphviz's arcane rules).
1a) As with 1), but don't worry about defining extra attributes such
as node [label=\N].
2) Explicitly define nodes that are only mentioned in edges (e.g.
actually define a `c' node, even if it doesn't have any extra
attributes). Note that this already happens if such an edge is
specified inside a different cluster than the already known node is
in; in that case then the stand-alone node is defined in the cluster
its edge is defined in, and the actual edge is moved into the outer
context that combines the two clusters.
2a) As with 2), but define all edges in the overall graph rather than
grouping them internally inside clusters, etc.
3) Group common attributes together as much as possible (e.g. inside
the bar cluster, define another subgroup which has a top-level
attribute node [color=blue] and define the `a' and `b' nodes in
there). Not sure how well this will work with edges though, and is
probably not possible in conjunction with option 2a). This is a bit
tricky and subtle: if `a' and `b' are already in such a subgraph, but
an edge specifying one of them is defined _before_ the subgraph is
defined, then that node will have an explicit color attribute defined
of (i.e. empty string), though I would classify this as a bug.
4) As an alternate to option 3), remove all explicit top-level node
and edge attributes and move them all to the affected node and edge
definitions themselves; this may require option 2).
I'm also willing to hear and consider other possible variants;
however, I'm only going to code (at most) one.
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hs-cryptohash 0.4
On 2 July 2010 16:57, Joachim Breitner m...@joachim-breitner.de wrote: Am Freitag, den 02.07.2010, 12:55 +1000 schrieb Ivan Miljenovic: This can be resolved by putting the build-depends line in the if statement (and should maybe put up the top of the executable section to make it more obvious): the latter was not possible last time I checked. Do you mean putting the if statement at the top of the executable section? Works for me: http://hackage.haskell.org/packages/archive/graphviz/2999.9.0.0/graphviz.cabal (also in other cases that I've looked at). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie question about using WinGHCi
On 1 July 2010 16:04, Christopher Tauss ctau...@gmail.com wrote:
Hello -
I just a day or so ago downloaded Hakell and am playing around with it, and
I came upon this problem with WinGHCi:
I am able to enter a multi-line do statement that works if I use brackets
and semi-colon like so:
Prelude :{
Prelude| let main2 = do {
Prelude| putStrLn Please enter your name: ;
Prelude| name - getLine;
Prelude| putStrLn (Hello, ++ name ++ , how are you?) }
Prelude| :}
Prelude main2
Please enter your name:
CT
Hello, CT, how are you?
Prelude
Note there is no indentation. This makes sense to me because the :{ :}
just take all the lines in between and make it one line.
But it seems to me to be IMPOSSIBLE to input this into WinGHCi using
indentation like most of the code samples seem to do.
Should I just be satisfied that it works using brackets/ semi-colons? Or is
there something obvious that I am missing that allows for indentation?
Typically, ghci (including WinGHCI) and Hugs are used to evaluate and
experiment with code, rather than writing it. Write your actual code
in a file and load it with :load (or :l for short) into ghci.
In this sense, they aren't real REPLs in that you can't define new
data types, classes, etc. in them (you can write functions with a let
statement, but it gets cumbersome for long functions).
It might be better off thinking of the prompt as being individual
lines in a big do-block for a specialised version of the IO monad (in
the sense that normally just entering 5+4 wouldn't typecheck let
alone print the result, etc.).
Thanks in advance. It's issues lik this that keep me up into the depths of
night.
Hopefully you can now get to sleep ;-)
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] chart broken under 6.12 according to criterion
On 1 July 2010 19:16, Tom Doris tomdo...@gmail.com wrote: According to the criterion.cabal file shipped with the latest (0.5.0.1) version of criterion, the Chart package is broken under GHC 6.12: When Bryan last released Criterion, gtk2hs (and hence Chart) was unbuildable on GHC 6.12 (which was what Bryan was using) unless you manually patched it (shameless plugwhich was fixed a while back in Gentoo/shameless plug). As such, he wasn't able to test whether or not the Chart functionality worked (which it didn't with the latest version of Chart, due to a small API change). I have since sent him a patch to enable it (including to use the latest version of Chart available at that time); since then he has told me that he's been too busy to look at it as he's got a lot on his plate at the moment. Note that this predated the Cabalisation of gtk2hs, so my patch would probably need tweaking, but I assume the time issue is still a problem. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hs-cryptohash 0.4
On 1 July 2010 17:25, Vincent Hanquez t...@snarc.org wrote: The main reason for this library is the lack of incremental api exposed by current digest libraries, and filling the void about some missing digest algorithms; Also the speed comes as a nice bonus. Can you explain what you mean by incremental API? I'm looking forward to hear any comments, (I'm not going to comment on the API decisions as I've never used any hashing functionality in my code and I thus wouldn't know what is good or bad.) First of all, Hackage couldn't seem to build it: http://hackage.haskell.org/packages/archive/cryptohash/0.4/logs/failure/ghc-6.12 Secondly, at the moment even if you disable the testing flag, whilst the executable isn't built Cabal still pulls in HUnit as a dependency. This can be resolved by putting the build-depends line in the if statement (and should maybe put up the top of the executable section to make it more obvious): if flag(unittest) Buildable: True Build-depends: base = 3 5, HUnit, bytestring else Buildable: False Furthermore, the flag `test' is more common for enabling test suites than `unittest'. Oh, and in case it isn't obvious to people, the package name on hackage is just cryptohash, not hs-cryptohash. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Associated types
On 2 July 2010 04:48, David Menendez d...@zednenem.com wrote: Maybe you're thinking of equality superclasses. In another thread, this example came up: | class (DerivedOf a ~ derived) = Typecheck a derived where which doesn't work yet, but should work in 6.14. I've asked Manuel Chakravarty about this, and he isn't sure if it will be ready in time for 6.14 :( -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
On 29 June 2010 15:20, Michael Snoyman mich...@snoyman.com wrote: As far as I know, the only issue with depending on both is the conflicting orphan Monad instance for Either. Can anyone either confirm or deny this? Since you're being naughty and using package-qualified imports, it should be OK (in terms of working). On Tue, Jun 29, 2010 at 5:11 AM, Antoine Latter aslat...@gmail.com wrote: It looks like good work, but I would be hesitent about depending on a package which pulled in both mtl and tranformers. Maybe that's just superstition - I haven't tried it. Antoine On Jun 28, 2010 5:51 PM, Michael Snoyman mich...@snoyman.com wrote: Hi all, I'll admit, the original idea for this package was something to place in ACME ;). However, it's goal is to solve a real problem: the lack of good instances on the Either type. As a brief summary, Either has no Applicative or Monad instances in the base library, has 2 reasonable definitions for Applicative, and there are conflicting orphan instances in the mtl and transformers packages. Also, the ErrorT transformer in those two packages introduces a superclass constraint many people would like to avoid. neither supplies three datatypes: AEither, MEither and MEitherT. AEither provides the Monoid version of the Applicative instance, MEither is the monadic version, and MEitherT is a monad transformer. The package provides instances for both the transformers and mtl libraries for MonadTrans, MonadIO and MonadCatchIO. The code is up on github[1], let me know what you think. Michael [1] http://github.com/snoyberg/neither ___ 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 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for comments: neither package
On 29 June 2010 15:38, Michael Snoyman mich...@snoyman.com wrote: On Tue, Jun 29, 2010 at 8:24 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 29 June 2010 15:20, Michael Snoyman mich...@snoyman.com wrote: As far as I know, the only issue with depending on both is the conflicting orphan Monad instance for Either. Can anyone either confirm or deny this? Since you're being naughty and using package-qualified imports, it should be OK (in terms of working). Is naughty simply tongue-in-cheek, or are there detriments to it? You know, besides not all compilers supporting them... A bit of both. Someone (dons?) had a good discussion on the Haskell reddit about why you shouldn't use them, but I can't seem to find it at the moment (I did find this one, but I seem to recall a better discussion: http://www.reddit.com/r/haskell/comments/bfcfs/haskells_big_three/c0mhqtg ). Otherwise, the documentation for it discourages its use: http://haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#package-imports -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why this doesn't type checked
On 28 June 2010 05:52, Victor Nazarov asviraspossi...@gmail.com wrote: Having this in my mind I've decided that this code should be rewritten without undefined being mentioned. But I need some type signature and it should mention Int type. So I've got an idea about what I've called fantom type functions. So wee need type families for it to work. Sounds like http://www.haskell.org/haskellwiki/Phantom_type But as Daniel said, you seem to be trying to solve a problem that doesn't exist! -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: signficant improvements to the containers package
On 24 June 2010 16:57, Don Stewart d...@galois.com wrote: Some people might be quite excited by Milan's work on significant performance improvements to the containers package... This looks quite nice; good work Milan!!! As an aside, Alex Mason and I are discussing the possibility of taking advantage of AusHack *shameless plug* to write some kind of classes for the different types of containers with a hierarchy. I know about ListLike, but there doesn't seem to be any applicable classes for generic containers (i.e. the abstract API of a Set; something like ListLike would then be an extension on it) and for lookup data structures (Map k a, [(k, a)], etc.). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: signficant improvements to the containers package
On 24 June 2010 17:15, Stephen Tetley stephen.tet...@gmail.com wrote: There are some classes for bulk types in Simon Peyton-Jones's paper Bulk Types with Class. Cool, I'll have a look. Personally, I'll take a lot of convincing that a class approach will be better than using the module system... My rational for a class approach is that rather than having your library spit out a list of values, etc. you let the consumer pick which data type they prefer (if they're going to be just converting your list into a Set, then why not give them a Set to start with?). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: signficant improvements to the containers package
On 24 June 2010 17:55, Stephen Tetley stephen.tet...@gmail.com wrote: On 24 June 2010 08:20, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: My rational for a class approach is that rather than having your library spit out a list of values, etc. you let the consumer pick which data type they prefer (if they're going to be just converting your list into a Set, then why not give them a Set to start with?). That's a bit more interesting, at least to my tastes. In my own work I often use specialised container types: e.g. rather than use a 'safe list' library that avoids certain list ops or wraps them as Maybe's, I prefer using a OneList: data OneList a = One a | Cons a (OneList a) Hmmm. /me makes a note to see whether or not having an empty value is a requirement of such classes... With structures like a OneList their construction is more 'primary' than their manipulation. That's to say clearly when you build a OneList it can't be empty (and you obviously don't want it to be), but as a structure its not conducive to many manipulations, e.g: you can't filter it, as filtering can produce an empty list but the data type can't. Yeah, which can be a problem. Some algebra of constructors and destructors would be useful here, to get the filterInto function for example: filterInto :: Consable c = (a - Bool) - OneList a - c a Consable could be the Coll class from Bulk Types with Class or probably better, a smaller one with just empty and cons, or even just cons inheriting Monoid. Unfortunately inheriting Monoid puts legitimacy on (++) which we know is bad on regular lists, and should discouraged where feasible. Similarly size in the Coll class is bad on regular lists... it goes on until will have single operation type classes for all the collection operations. If you inherit Monoid, then Bytestring can't be an instance of the class... This dichotomy is a problem: we'd like to have as many possible types be instances of such classes as possible; however, if we do that then we can't use pre-existing classes such as Functor since Set isn't an instance of Functor, etc. Anyway, since I've brought the whole thing up now rather than in the blog post I was planning to write this weekend, what are people's thoughts on preferred extension used: * MPTCs + fundeps Pros: older tech, more widely understood/used, ListLike already uses it Cons: I don't like the fact that the element type becomes a first class member of the type class; I'd prefer writing SetLike s = Value s - s - s to SetLike s v = v - s - s as IMHO the class represents the data type/structure and not the value it stores (that's a sub-part). * Type Families (actually using an Associated Type) Pros: IMHO cleaner type sigs (see above), in Fun with Type Families, the authors call Type Families more like functional programming whereas fundeps are more like logic programming, and also state that type families play nicer with GADTs, etc. Cons: newer tech, so still being developed and used, etc. In particular, superclass constraints are not yet implemented in GHC (i.e. can't say something like class (SetLike l, Value l ~ (k, v)) = MapLike l where ... Unlike the choice of which gets used in FGL, I would like to think that this kind of set of classes would be more widely used in the community and will use whichever type of extension seems to be consensus as the better one (at least for this situation). If anyone knows a good site to be able to make an actual poll for this, that would probably be even better (or should we just have a wiki page where people put their names under whichever they think is better and then just tally up the number of names for each?). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question regarding deepseq (Control.DeepSeq)
On 25 June 2010 10:57, Frank Moore fmo...@gmail.com wrote: Hello Haskellers, I am new to programming in Haskell and I am having trouble understanding exactly when statements become evaluated. My goal is to try and measure how long a computation takes without having to use a show function. The code I am trying to use is below (taken in part from RWH chapter 25) -- import Data.List (foldl') import Data.Time.Clock (diffUTCTime, getCurrentTime) import Control.DeepSeq (deepseq) mean :: [Double] - Double mean xs = s / fromIntegral n where (n,s) = foldl' k (0,0) xs k (n,s) x = n `seq` s `seq` (n+1,s+x) main = do let as = [1..1e7] :: [Double] start - getCurrentTime let meanOver2 = deepseq (mean as) `seq` (mean as) / fromIntegral 2 end - getCurrentTime putStrLn (show (end `diffUTCTime` start)) putStrLn (show meanOver2) - My understanding of deepseq was that it evaluates (mean as) completely before continuing, and then the show would not take any time, but instead all the time is spent in the show meanOver2 function. I feel like I am missing something fundamental here. Any suggestions? Thanks for your help. It does... but because you don't save the result it doesn't keep the result (you're wanting Common Sub-expression Elimination, which GHC doesn't do). Try this: let meanAs = mean as meanOver2 = meanAs `deepSeq` meanAs / 2 Note that your usage of fromIntegral isn't required, as that is automatically done for any integral literal (but if you had 2 in an Int variable then you would need fromIntegral). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question regarding deepseq (Control.DeepSeq)
On 25 June 2010 11:19, Frank Moore frankmo...@math.cornell.edu wrote: Thanks for the reply. My main is now: main = do let as = [1..2e7] :: [Double] start - getCurrentTime let meanAs = mean as let meanOver2 = meanAs `deepseq` meanAs / 2 end - getCurrentTime putStrLn (show (end `diffUTCTime` start)) start - getCurrentTime putStrLn (show meanOver2) end - getCurrentTime putStrLn (show (end `diffUTCTime` start)) The time is still spent on the show meanOver2 command :( Well, yes, because the seq'ing is still happening as part of meanOver2. The alternative is to have yet another let statement which is just let meanAs' = meanAs `deepSeq` meanAs and then have meanOver2 = meanAs' / 2. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Mining Twitter data in Haskell and Clojure
On 25 June 2010 12:32, braver delivera...@gmail.com wrote: Simon -- so how can I get me a new ghc now? From git, I suppose? (It used to live in darcs...) Still does if I recall correctly. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: signficant improvements to the containers package
On 25 June 2010 14:41, David Menendez d...@zednenem.com wrote: On Thu, Jun 24, 2010 at 3:08 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: As an aside, Alex Mason and I are discussing the possibility of taking advantage of AusHack *shameless plug* to write some kind of classes for the different types of containers with a hierarchy. I know about ListLike, but there doesn't seem to be any applicable classes for generic containers (i.e. the abstract API of a Set; something like ListLike would then be an extension on it) and for lookup data structures (Map k a, [(k, a)], etc.). Be sure to look into Okasaki's work on Edison. It has classes for sequences (list-like structures) and collections (sets, heaps) and associations (maps, priority queues) and a paper discussing the design decisions. Yeah, we will be. The reason this came up: Thomas Berekneyi wanted to use such classes for the rewrite of FGL, and when he discussed it on #haskell people generally indicated that edison was the best out there but was a bit long in the tooth and something like it should be re-written (though no-one seemed to volunteer... hmmm... :p). For example: it's a little weird that edison re-exports Data.Set and uses it for the instance with a type alias (same with map, Seq, etc.) rather than just using Data.Set itself. I also find the structuralInvariant and instanceName fields to be a little odd, whereas strict can now be shifted off to DeepSeq (or whatever the class is called). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: srec-0.0.0
For those others like me who have no idea what s-record files are: http://en.wikipedia.org/wiki/S-record On 23 June 2010 03:36, Tom Hawkins tomahawk...@gmail.com wrote: A little library for reading s-record files: http://hackage.haskell.org/package/srec -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] checking types with type families
On 23 June 2010 13:46, Evan Laforge qdun...@gmail.com wrote: I have a parameterized data type: data Val result = VNum Double | VThunk (SomeMonad result) type Environ result = Map Symbol (Val result) I have a class to make it easier to typecheck Vals: class Typecheck a where from_val :: Val result - Maybe a I think your problem here is that there's no mention of `a' on the left-hand size of from_val's type signature; you either need to use MPTC+fundep to associate what result is compared to a, or else use a phantom type parameter of Val to make it data Val result a = ... and then from_val :: Val result a - Maybe a. SPJ's paper on type families has this situation arising in the section on defining a graph class. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new recursive do notation (ghc 6.12.x) spoils layout
On 22 June 2010 03:18, John Lask jvl...@hotmail.com wrote: I just want my nice neat layout back. I have just spent an inordinate amount of time updating code when if the parser recognised do rec as a recursive group it would have been a drop in replacement and taken me one tenth of the time. Why can't we have this? At a guess: because no-one has implemented such functionality yet. Are you volunteering? :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is Haskell unsuitable for?
On 16 June 2010 16:00, Michael Snoyman mich...@snoyman.com wrote: On Wed, Jun 16, 2010 at 8:51 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: Next you'll say there's no need for anyone to ask whether they prefer vi or emacs... ;-) Of course *real* programmers use ed. It is the standard editor[1]. Michael [1] http://www.gnu.org/fun/jokes/ed.msg.html Except that due to Haskell's pervading influence we've all become lazy... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is Haskell unsuitable for?
On 16 June 2010 15:45, Roman Cheplyaka r...@ro-che.info wrote: * aditya siram aditya.si...@gmail.com [2010-06-15 19:47:37-0400] Hi all, Haskell is a great language and in a lot of ways it still hasn't found a niche, but that's part of what is great about it. But I wanted to ask people are more experienced with Haskell - what kinds of problems is it unsuited for? Have you ever regretted using it for something? Meaning if you could write the program over you would do it in another language. This topic was already discussed on this list, you might want to search the archives. Spoilsport! :p Next you'll say there's no need for anyone to ask whether they prefer vi or emacs... ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Possible solution to the FGL naming/compatability issue
Last night (AEST), Edward Kmett semi-convinced (in the sense that I'm not sure whether his examples are really those that someone would want/need or just thinking of possible future problems) me that some users may have a need for FGL to keep having explicit graphs with kind * - * - *. With his prompting, I may have a possible solution: duplicate the classes. We would have an InductiveGraph class (call it the parametric version) that requires graphs to have kind * - * - *, and then another class (call it the extended version) that removes this restriction. The parametric version would be closer to a drop-in replacement to the current FGL setup (see below for more details) and the extended one would provide all of the functionality requested, with some kind of semi-automatic lifting/unlifting for graph types that are instances of both. Now, this parametric version will still not be a drop-in for the current FGL, for several reasons: * I want to have one overall InductiveGraph class rather than two separate Graph and DynGraph classes * Context will still be an actual data type rather than a 4-tuple and LEdge would be come (Edge, Label) rather than (Node, Node, Label) [I'm still debating whether to keep Edge as a datatype as needed for the Type Familiy version or if it should just be a tuple). * Some function names will be changed (e.g. fromContexts rather than buildGr). * The Data.Graph.Inductive.Query stuff is going to be split out into its own separate library, the Data.Graph.Inductive.Graphviz stuff is going to be removed, etc. * With the removal of the sub-libraries, I'm seriously considering moving the class definitions from Data.Graph.Inductive.Graph to just Data.Graph.Inductive. There are also some caveats/design decisions with this solution: * There will obviously be duplication. With that said, do we try to make the two classes semi-drop-ins (same class name, methods, etc. but with different types) or think up new method names for the extended version? * How transparently can/will we make the lifting/unlifting? * If we want the parametric version to still have the ability to specify a custom node type, then it will still need either MPTCs + fundeps or Type Families (i.e. extensions); otherwise we stick with the current type Node = Int (or maybe replace it with some opaque abstract type down the track as suggested by Heinrich Apfelmus). * If we want to provide the ability to restrict the types of the labels in the parametric version, then we would need MPTCs (Type Families won't work since the label types won't be part of the class definition then unless we use MPTCs, and in that case there's not really any point in using Type Families). Thus we once again need extensions. * My semi-end goal is to build a proper hierarchy of graph types/libraries, such that the only thing FGL provides is the extra aspect/concept of inductive graphs. If we extend this parametric vs extended split down to the set of base graph classes, then we're going to have even more duplication and this kind of setup (where Foo depends on Bar means class (Bar a) = Foo a where ...): - fgl-parametric will depend on graph-parametric - fgl-extended will depend on graph-extended - There will be lifting/unlifting between graph-parametric and graph-extended - There will be lifting/unlifting between fgl-parametric and fgl-extended As such, an FGL graph of kind * - * - * being treated as an extended graph will have two possible ways (depending on the function in question) will have two graph hierarchies two choose from, and two possible points at which it can be lifted/unlifted (at the graph level and the fgl level). This could get confusing. That said, there is one other benefit of this parametric vs extended split: the types of the mapping functions in http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs won't be as weird... So, what are people's thoughts/opinions on this kind of setup? Note that I haven't started coding it yet, so I'm not sure how well it will work in practice... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Possible solution to the FGL naming/compatability issue
Last night (AEST), Edward Kmett semi-convinced (in the sense that I'm not sure whether his examples are really those that someone would want/need or just thinking of possible future problems) me that some users may have a need for FGL to keep having explicit graphs with kind * - * - *. With his prompting, I may have a possible solution: duplicate the classes. We would have an InductiveGraph class (call it the parametric version) that requires graphs to have kind * - * - *, and then another class (call it the extended version) that removes this restriction. The parametric version would be closer to a drop-in replacement to the current FGL setup (see below for more details) and the extended one would provide all of the functionality requested, with some kind of semi-automatic lifting/unlifting for graph types that are instances of both. Now, this parametric version will still not be a drop-in for the current FGL, for several reasons: * I want to have one overall InductiveGraph class rather than two separate Graph and DynGraph classes * Context will still be an actual data type rather than a 4-tuple and LEdge would be come (Edge, Label) rather than (Node, Node, Label) [I'm still debating whether to keep Edge as a datatype as needed for the Type Familiy version or if it should just be a tuple). * Some function names will be changed (e.g. fromContexts rather than buildGr). * The Data.Graph.Inductive.Query stuff is going to be split out into its own separate library, the Data.Graph.Inductive.Graphviz stuff is going to be removed, etc. * With the removal of the sub-libraries, I'm seriously considering moving the class definitions from Data.Graph.Inductive.Graph to just Data.Graph.Inductive. There are also some caveats/design decisions with this solution: * There will obviously be duplication. With that said, do we try to make the two classes semi-drop-ins (same class name, methods, etc. but with different types) or think up new method names for the extended version? * How transparently can/will we make the lifting/unlifting? * If we want the parametric version to still have the ability to specify a custom node type, then it will still need either MPTCs + fundeps or Type Families (i.e. extensions); otherwise we stick with the current type Node = Int (or maybe replace it with some opaque abstract type down the track as suggested by Heinrich Apfelmus). * If we want to provide the ability to restrict the types of the labels in the parametric version, then we would need MPTCs (Type Families won't work since the label types won't be part of the class definition then unless we use MPTCs, and in that case there's not really any point in using Type Families). Thus we once again need extensions. * My semi-end goal is to build a proper hierarchy of graph types/libraries, such that the only thing FGL provides is the extra aspect/concept of inductive graphs. If we extend this parametric vs extended split down to the set of base graph classes, then we're going to have even more duplication and this kind of setup (where Foo depends on Bar means class (Bar a) = Foo a where ...): - fgl-parametric will depend on graph-parametric - fgl-extended will depend on graph-extended - There will be lifting/unlifting between graph-parametric and graph-extended - There will be lifting/unlifting between fgl-parametric and fgl-extended As such, an FGL graph of kind * - * - * being treated as an extended graph will have two possible ways (depending on the function in question) will have two graph hierarchies two choose from, and two possible points at which it can be lifted/unlifted (at the graph level and the fgl level). This could get confusing. That said, there is one other benefit of this parametric vs extended split: the types of the mapping functions in http://code.haskell.org/FGL/fgl/Data/Graph/Inductive/Graph.hs won't be as weird... So, what are people's thoughts/opinions on this kind of setup? Note that I haven't started coding it yet, so I'm not sure how well it will work in practice... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
On 10 June 2010 12:38, sterl s.clo...@gmail.com wrote: There's a big range of issues here, and to be honest I'm not sure if our ability to distinguished between them is helped by the title of this thread, which somewhat begs the question. That is to say, it isn't clear to me that calling the proposed changes to the fgl rewriting a library is necessarily accurate -- it seems more the case that these are incremental improvements of a library that require breaking API changes. Except it is a re-write in the truest sense of the word: we started completely from scratch. We did compare our API with the current API (in an attempt to keep function names, etc. the same where possible because I'm hopeless at choosing names) but we didn't exactly take the class as-is and then change it. On the other hand, we were both familiar with the current version of FGL and how it's layed out, so there's probably some implicit influences from there as well. Oh the other hand, it can also be considered as incremental improvements: we wanted to keep the terminology and fundamental concepts as similar as possible to avoid having a jarrring change in how its used. Instead, we focused on improving the current version: using explicit data types for Context and Edge (for why Edge needs a data type of its own, read the Graph section of Fun with type functions by Oleg, SPJ and Chung-chieh Shan) rather than tuple aliases; allowing restrictions on the label types (though we've just come across a problem where this doesn't play nicely with mapping functions); increasing the scope for per-instance optimisations, etc. So in a sense we did a re-write that happened to come close to the current definition. This is not to say that this is because the current API is close to an ideal perfect API, but rather because we were focussing on developing something _like_ the current version without worrying about compatability too much. So on the concrete issue at hand, I'd be for the new fgl version being developed under some new provisional name, and taking pains to provide a compatibility layer where possible. Then, after we see what the changes really are, coming to some informed decision on whether to rebrand it as the real fgl version 6. If so, the old stable fgl can be put up on hackage as fgl98, which lets packages which want to stick with it do so while avoiding any possibility of the dread diamond dependency. Considering the rename the old version issues first: * It won't solve the problem of people not specifying correct constraints on the version of fgl used, since it means they'd have to edit their dependencies to use fgl98 or whatever anyway. * Calling it fgl98 is on a slippery slope: what happens when GHC-6.14 comes out with Haskell2010 support? Do we then release an fgl2010 version as well? (I believe Ross brought this problem up already). * I'm wanting people to move _off_ of the old version of fgl. The only real advantage (though how practical this will be in the real world is debateable IMHO) is that the current version doesn't use any extensions whereas the new one does (and they're needed to provide the asked-for functionality of letting instance writers constrain the types of labels - i.e. the reason why Set isn't an instance of Functor - and to have custom Node types). Since (like it or not) for the most part when people write Haskell code they use GHC and GHC supports these extensions, I do not think this is that much of a problem (I am open to being convinced otherwise about this though; I think it would be _great_ if there were other Haskell compilers that were as good as if not better than GHC in terms of runtime, etc. ... until I start considering how to manage two different compilers in Gentoo, etc. :p). As for having a temporary name for the testing releases, I am open to doing so, but this in affect pollutes the package name-space with packages that shouldn't/wouldn't be used. I would prefer to host it elsewhere and just tell people to grab a copy and see what they think rather than use a temporary name and then change it later when its stabilised. It would be preferable IMO that if we were going to change package names then it should be done once and then not changed again. More broadly, we have to accept that breaking API changes are an irritating but necessary fact of life. As much as the parsec and quickcheck issues have caused some modest pain, there's been equal hassle from things like the strictness behavior of binary, or even the type change in tagsoup. Splitting out Category from Arrow caused me probably the most hassle. In retrospect it was the right thing to do. But how it was done was particularly abrupt and painful. Exceptions got it right in pretty much every respect, but still migration necessarily took some work. We want our packages to grow, including our core packages. Otherwise we get fragmentation and duplicated effort. When we want to grow, but don't know
Re: [Haskell-cafe] Strange discrepancy between Emacs interpreter and command-line on windows
On 10 June 2010 14:28, Arnaud Bailly arnaud.oq...@gmail.com wrote: I did: ghc-pkg unregister bytestring-0.9.1.6 then restarted emacs and it works now. Don't now if ther weill be side-effects on other packages... ghc-pkg check will tell if you if there are any breakages. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf
On 9 June 2010 12:11, Jason Dagit da...@codersbase.com wrote: Or write translator tools for upgrading to the new API :) Pipe dream? Maybe. Too an extent, yes: the types are more generalised so it's going to be difficult to do automatic translations. However, Thomas has demonstrated that you can write any instance of the new class as an instance of the old classes and vice versa just using class methods... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] Please check your dependencies on fgl
Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. As such, if your code uses fgl you should ensure that the specification of the package in your .cabal file has an explicit upper bound (or indeed just set fgl == 5.4.2.2) to avoid any problems when we release 6.0.0.0 (we're trying to avoid the problems that plagued KDE-4 by not claiming in the slightest that the initial few versions are intended for end users). I have already directly emailed the maintainers of any and all packages I could find on Hackage (using Roel van Dijk's wonderful reverse-dependency mirror at http://bifunctor.homelinux.net/~roel/hackage/packages/hackage.html), but just in case I've missed one or there's an as-yet-unreleased package somewhere in the works, here is the official heads up. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Please check your dependencies on fgl
Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. As such, if your code uses fgl you should ensure that the specification of the package in your .cabal file has an explicit upper bound (or indeed just set fgl == 5.4.2.2) to avoid any problems when we release 6.0.0.0 (we're trying to avoid the problems that plagued KDE-4 by not claiming in the slightest that the initial few versions are intended for end users). I have already directly emailed the maintainers of any and all packages I could find on Hackage (using Roel van Dijk's wonderful reverse-dependency mirror at http://bifunctor.homelinux.net/~roel/hackage/packages/hackage.html), but just in case I've missed one or there's an as-yet-unreleased package somewhere in the works, here is the official heads up. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PDF generation?
On 6 June 2010 00:37, Maciej Piechotka uzytkown...@gmail.com wrote: PDF is not just simplified, compressed encoding of PostScript. Or at least - LaTeX have some features PDF-only. For example PDF can have hyper-links (both to local and external content). It can be scripted in JavaScript (don't ask me why) and can have form (OK. So I can fill them and print probably). The form stuff is also for online submission, and the javascript allows editing of what is possible. For example (requires Adobe Reader plugin, which I don't have and thus haven't seen it myself) this form (I believe) auto-fills in some details and saves a copy online, etc.: https://forms.australia.gov.au/forms/aec/Electoral%20enrolment/ Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simplest reference for how to build GHC head + get it running w/ cabal/haskell-platform?
On 4 June 2010 00:57, Ryan Newton new...@mit.edu wrote: What's the easiest reference for how to build GHC head and get it up and running with cabal/haskell-platform? I simply installed 6.12 + haskell-platform then built ghc-6.13.xx and rebuilt only the packages I needed with cabal install --reinstall. Perhaps this is not the recommended way. You have to rebuild _everything_ with the new version of GHC. Indeed, something must be wrong because I can't build certain packages. (I have problems with base dependencies.) For example: $ cabal install QuickCheck Resolving dependencies... cabal: cannot configure QuickCheck-1.2.0.0. It requires base ==3.* For the dependency on base ==3.* there are these packages: base-3.0.3.1 and base-3.0.3.2. However none of them are available. base-3.0.3.1 was excluded because of the top level dependency base -any base-3.0.3.2 was excluded because of the top level dependency base -any Looks like GHC-6.13 has dropped base-3 compatability; as such, QuickCheck-1.x will not build as there is no variant that works with base-4. Is there any particular reason why you're not using QuickCheck-2.y ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Sum type branches as extended types (as Type!Constructor)
On 4 June 2010 03:18, Ozgur Akgun ozgurak...@gmail.com wrote:
On 3 June 2010 16:14, Gabriel Riba griba2...@gmail.com wrote:
Maybe we could take out importance on the number of _ wildcards
(constructor
arity) with a syntax like.
li @ (Cons ...)
li @ (Nil ...)
can't you already use {} to get rid of the underscores?
li@(Cons {})
li@(Nil {})
Even better: you shouldn't need the parentheses:
l...@cons{}
l...@nil{}
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Problems with Haskell Platform
On 4 June 2010 10:27, Jens Petersen peter...@haskell.org wrote: On 31 May 2010 20:14, Pete Chown 1...@234.cx wrote: I was just thinking, interactions between Cabal and the distribution package manager could get worse, as shared Haskell libraries become more common. Suppose a distribution ships a package 'foo', but not a package 'bar' which depends on it. The 'foo' package includes shared libraries. The user now installs 'bar' using Cabal. This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager. This is a good valid point and one I have been worrying about myself sometimes. I often find myself hitting Ctrl-C at cabal install HACKAGE to run yum install ghc-DEPENDENCY-devel and before returning to run cabal install again. It would be nice to automate this in some way - cabal-install plugins, anyone?? How difficult is it just to create an RPM for yourself and then put it up in some repository for other people to use? I never use cabal-install to install packages at home (with the exception of testing versions of libraries I'm writing as I'm writing them); instead I create a new ebuild for whatever I want and then put that in the Haskell overlay for Gentoo. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Problems with Haskell Platform
On 31 May 2010 20:14, Pete Chown 1...@234.cx wrote: I was just thinking, interactions between Cabal and the distribution package manager could get worse, as shared Haskell libraries become more common. Suppose a distribution ships a package 'foo', but not a package 'bar' which depends on it. The 'foo' package includes shared libraries. The user now installs 'bar' using Cabal. This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager. Why won't it? This, of course, depends on how the distribution ships `foo' in regards to static/shared libraries and what the user's options to Cabal/cabal-install are. In Gentoo, for example, we at the moment only build static libraries, mainly because there has been no pressing need/request for shared libraries; however it would definitely be possible to add support for them (might be difficult dependency-wise if shared library support it optional, but this is also a problem we haven't resolved yet for profiling libraries). If 'foo' is built as a shared library, programs built by the user will not work for anyone else. Other users will have the distribution's build of 'foo' rather than Cabal's build. If 'foo' is built statically, it's not quite so bad, but the user will not get the benefits that could come from using shared libraries. In general, even if some application is built statically then it won't work on other machines due to different C library versions (GMP, etc.), so I don't think this is such a big deal. Of course, the big thing here is whether Linux distributions, etc. should ship static or shared libraries by default. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Problems with Haskell Platform
On 3 June 2010 00:37, Ben Millwood hask...@benmachine.co.uk wrote: It's worth noting, though, that cabal-install doesn't track installed packages itself, GHC does. And this is why cabal-install can't tell you when there are new versions of executable-only packages (e.g. happy) available: it doesn't even know that happy is installed let alone what version is installed. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Sockets get bound to wrong port on Windows
Sorry for the double-reply Matthias, but I forgot to CC -cafe (GMail labs isn't working, so reply-to-all is no longer the default for me :( ). On 3 June 2010 13:10, Matthias Reisner matthias.reis...@googlemail.com wrote: there's something wrong with port numbers in the Network.Socket module of package network. Printing values gives: *Main PortNum 47138 *Main PortNum 47138 This happens to me as well (self-built GHC 6.12.2 with network 2.2.1.7 on some random Ubuntu version I use at uni). So I thought it's just an error in the show instance of PortNumber, which shows the bytes flipped. But if I use the following code snippet sock - socket AF_INET Datagram 0 bindSocket sock $ SockAddrInet (PortNum ) iNADDR_ANY to bind a socket to port , netstat and TCPView reveal that the socket is actually bound to the wrong port 47138. I'm using network-2.2.1.7 on Windows XP. Is that a bug or am I doing something wrong here? Tried testing this as well; not sure how to test if the binding worked but netstat --numeric-ports didn't contain or 47138. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Gtk2hs-users] Problem when installing gtk2hs.
On 27 May 2010 16:46, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: I only have one alex installed under ~/.cabal/bin. It seems working with shell environment, but not cabal. This sounds like a similar problem to one that occurred a couple of months ago. If you use ~/.cabal/bin/ for your PATH variable, try replacing that with $HOME/.cabal/bin/. On Thu, May 27, 2010 at 1:40 PM, Axel Simon axel.si...@in.tum.de wrote: Hi Magicloud, On May 27, 2010, at 4:11, Magicloud Magiclouds wrote: Hi, I have met similar problem before, and I do not know what to do. # cabal install --reinstall gtk2hs-buildtools Resolving dependencies... Configuring gtk2hs-buildtools-0.9... cabal: alex is required but it could not be found. cabal: Error: some packages failed to install: gtk2hs-buildtools-0.9 failed during the configure step. The exception was: ExitFailure 1 # alex -v Alex version 2.3.3, (c) 2003 Chris Dornan and Simon Marlow I don't think this is due to us. Are there perhaps other alex installations on your path? Or in ~/.cabal/bin? Axel -- 竹密岂妨流水过 山高哪阻野云飞 -- ___ Gtk2hs-users mailing list gtk2hs-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-users -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC
On 27 May 2010 17:55, Michael Snoyman mich...@snoyman.com wrote: Two comments: * The exclamation point seems good enough for attributes. I copied that for Hamlet as well. * If you're standardizing on UTF-8, why not support bytestrings? I'm aware that a user could shoot him/herself in the foot by passing in non-UTF8 data, but I would imagine the performance gains would outweigh this. My recent benchmarks on the BigTable benchmark[1] imply a huge performance gap between ByteStrings and other contenders. Wow, I find it rather surprising that String out-performs Text; any idea why that is? I wonder if you're just using it wrong... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC
On 27 May 2010 18:23, Michael Snoyman mich...@snoyman.com wrote: On Thu, May 27, 2010 at 11:16 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: On 27 May 2010 17:55, Michael Snoyman mich...@snoyman.com wrote: Two comments: * The exclamation point seems good enough for attributes. I copied that for Hamlet as well. * If you're standardizing on UTF-8, why not support bytestrings? I'm aware that a user could shoot him/herself in the foot by passing in non-UTF8 data, but I would imagine the performance gains would outweigh this. My recent benchmarks on the BigTable benchmark[1] imply a huge performance gap between ByteStrings and other contenders. Wow, I find it rather surprising that String out-performs Text; any idea why that is? I wonder if you're just using it wrong... Could be, I'd be very happy if that were the case. All of the benchmarks are available on Github, and the bytestring[1], text[2] and string[3] versions are all rather short. Does using lazy Text values improve this? I find it a little strange that you concatenate so many individual Strings that much. Also, how about explicitly using Text values rather than OverloadedStrings? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code: BlazeHTML RFC
On 27 May 2010 18:33, Michael Snoyman mich...@snoyman.com wrote: I don't do any string concatenation (look closely), I was very careful to avoid it. I tried with lazy text as well: it was slower. This isn't surprising, since lazy text- under the surface- is just a list of strict text. And the benchmark itself already has a lazy list of strict text. Using lazy text would just be adding a layer of wrapping. I don't know what you mean by explicitly using Text values; you mean calling pack manually? That's really all that OverloadedStrings does. You can try out lots of different variants on that benchmark. I did that already, and found this to be the fastest version. Fair enough. Now that I think about it, I recall once trying to have pretty generate Text values rather than String for graphviz (by using fullRender, so it was still using String under the hood until it came time to render) and it too was much slower than String (unfortunately, I didn't record a patch with these changes so I can't just go back and play with it anymore as I reverted them all :s). Maybe Bryan can chime in with some best-practices for using Text? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Math questions
On 28 May 2010 09:37, Richard O'Keefe o...@cs.otago.ac.nz wrote: On May 27, 2010, at 11:50 PM, Yitzchak Gale wrote: agree100 = (==) `on` for [1..100] Search for on and for in the Haskell 98 Report and you will not find them. If you want to tell someone to use them, you ought to tell them where to find them. You mean like this? http://haskell.org/hoogle/?hoogle=on http://haskell.org/hoogle/?hoogle=for -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Math questions
On 28 May 2010 14:52, Richard O'Keefe o...@cs.otago.ac.nz wrote: Yes, that kind of thing. Remember, this was a BEGINNER-type question. If one is giving a *serious* answer, it has to be an answer a beginner (who has almost certainly never heard of Traversable) can make sense of, and if it uses functions that are pretty much certain not to be in said beginner's text book, said beginner has to be told quite clearly where to find them. I think this is an example of the Haskell effect (more typically seen on #haskell), which can be categorised as follows: 1) Someone asks a (usually rather simple) question. 2) People discuss this and provide several straightforward and relevant answers. 3) Out of curiosity (and probably a fair dose of masochism) others then start to golf the solution into the most interesting approach possible. 4) The person that asked the question initially gets lost (but is quite often awed at all the amazing stuff that's going on around them zooming past at light speed). 5) People suddenly remember that there was an initial question and make an attempt to explain the more advanced solutions to the person that asked the question in the first place. 6) They smile and nod and pretend they understand whilst putting a note onto their copious TODO list to someday sit down and try to work out wtf was going on. 7) ??? 8) Profit!!! -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chuch encoding of data structures in Haskell
On 28 May 2010 15:18, wren ng thornton w...@freegeek.org wrote: Stefan Monnier wrote: churchedBool :: t - t - t Important detail: the precise type is ∀t. t → t → t. encodeBool x = \t e - if x then t else e So the type of encodeBool should be: Bool → ∀t. t → t → t whereas Haskell will infer it to be ∀t. Bool → t → t → t Those are the same type. I can see a slight distinction between them, based upon when the quantification occurs (the former returns a function that work on all t, the latter will do that encoding for all t). For most purposes there is no difference, but IIUC the former will let you do hlist style stuff post-encoding whilst the latter doesn't. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to deal with huge text file?
On 25 May 2010 16:12, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Yes, this code works with a little hack. Thank you. I'm scared to ask: what pray tell is this little hack? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to deal with huge text file?
On 25 May 2010 11:41, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I have a file including some operation logs, in the format of the following. And I have some code to analyze it. Well, it ate all my memories. --- log: Log for item A === 09:10 read accountA 09:20 read accountB Log for item B --- code: file - U.readFile filename Which module have you imported there with the `U'? For large text files, you probably want to use either lazy Bytestrings or lazy Text values. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to deal with huge text file?
On 25 May 2010 12:02, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: U is for UTF8 module. And I will try the modules you mentioned. Although I thought Haskell IO is lazy enough If you're only streaming data, it probably would be. However, you seem to keep some of it in memory, which is what the problem is. You might be able to fix this by doing main = readFile filename = liftM separateOutput = mapM_ foo. However, it depends on what separateOutput does. Also, consider using when (from Control.Monad) instead of your if statement. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to deal with huge text file?
On 25 May 2010 12:20, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: This is the function. The problem sure seems like something was preserved unexpected. But I cannot find out where is the problem. seperateOutput file = let content = lines file indexOfEachOutput_ = fst $ unzip $ filter (\(i, l) - Log for `isPrefixOf` l ) $ zip [0..] content indexOfEachOutput = indexOfEachOutput_ ++ [length content] in Expensive bit map (\(a, b) - drop a $ take b content ) $ zip indexOfEachOutput $ tail indexOfEachOutput You're not streaming the String; you're also keeping it around to calculate the length (I'm also not sure how GHC optimises that if at all; it might even re-evaluate the length each time you use indexOfEachOutput. The zipping of indexOfEachOutput should be OK without that length at the end, as it will lazy construct the zipped list (only evaluating up to two values at a time). However, you'd be better off using zipWith f rather than map f . zip. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best way to instance Fix?
On 24 May 2010 11:13, Sam Martin sam.mar...@geomerics.com wrote:
Hi!
I'm trying to work out the best way to generate (ideally derive) instances
for the Fix type. Here's a cut down example:
data Greet x = AlloAllo x x | AuRevoir deriving Show
newtype Fix f = In { out :: f (Fix f) } -- deriving Show -- DOESN'T COMPILE
I think this is because for Fix to have a Show instance, it needs f to
have a Show instance, which only works if the parameter passed to it
has a Show instance, which means Fix needs to have a Show instance,
etc. My guess is that the deriving tool doesn't like infinite
loops...
-- workaround
instance Show (Fix Greet) where show (In i) = In ++ show i
Are you using OverlappingInstances or something to get this to work?
In other words, given a number of parametised types that I can derive, say,
Ord, Eq and Show for, how should I go about getting the instances for the
Fix-d version of them as well? I've tried a few things, but no luck so far.
Does (==) = (==) `on` out works for the Eq instance?
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Retrospective type-class extension
On 20 May 2010 14:42, Tony Morris tonymor...@gmail.com wrote: We all know that class (Functor f) = Monad f is preferable but its absence is a historical mistake. We've all probably tried once: instance (Functor f) = Monad f where Do you mean the reverse of this (instance (Monad m) = Functor m where) ? ... However, is there a type system extension (even proposed but not implemented) that allows me to retrospectively apply such a notion? Ideally something like this would be handy if it could somehow be retrospectively applied: Monad - Applicative - Pointed - Functor -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intuitive function given type signature
This looks suspiciously like homework... 2010/5/19 R J rj248...@hotmail.com: What are some simple functions that would naturally have the following type signatures: f :: (Integer - Integer) - Integer I can only think of one solution to this but it doesn't guarantee that it returns a value... g :: (Integer - Integer) - (Integer - Integer) Infinite possible functions. Don't forget, this is equivalent to: g :: (Integer - Integer) - Integer - Integer -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intuitive function given type signature
2010/5/19 Miguel Mitrofanov miguelim...@yandex.ru: On 19 May 2010, at 08:35, Ivan Miljenovic wrote: 2010/5/19 R J rj248...@hotmail.com: What are some simple functions that would naturally have the following type signatures: f :: (Integer - Integer) - Integer I can only think of one solution to this but it doesn't guarantee that it returns a value... I can think of infinitely many solutions. Dammit, you're right; I was trying to be too clever :s -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ShowList magic
On 17 May 2010 12:56, Abby Henríquez Tejera parad...@gmail.com wrote:
I'm a Haskell newbie and there's a bit of Haskell code that I don't
understand how it works. In the prelude, defining the class Show, the
function showList is implemented twice, one for String and another one
for other lists:
showList cs = showChar '' . showl cs
where showl = showChar ''
showl ('':cs) = showString \\\ . showl cs
showl (c:cs) = showLitChar c . showl cs
This is the default implementation; if an instance doesn't define
showList then this value is used.
showList [] = showString []
showList (x:xs) = showChar '[' . shows x . showl xs
where showl [] = showChar ']'
showl (x:xs) = showChar ',' . shows x .
showl xs
This is how the Show instance for Char defines showList (i.e. it
overrides the default one).
There would then be something like:
instance (Show a) = Show [a] where
show = showList
So, depending on the type used, it will either use the special ..
method (for String = [Char]) or the default one (or another special
one if another data type overrides the default implementation for
Show).
See http://book.realworldhaskell.org/read/using-typeclasses.html for
more information.
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] ANNOUNCE: Introducing Sifflet, visual functional programming language
On 14 May 2010 11:50, Gregory D. Weber gdwe...@iue.edu wrote: Introducing Sifflet -- version 0.1.5, first public release! Sifflet is a visual, functional programming language. Sifflet programmers define functions by drawing diagrams. Sifflet shows how a function call is evaluated on the diagram. It is intended as an aid for learning about recursion. So is Sifflet meant to be a full-featured programming language used for real world programs? If so, how well does it scale? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Package removal
On 14 May 2010 12:44, Yang Zhang yanghates...@gmail.com wrote: How do ghc users on Linux (esp. Debian/Ubuntu) systems remove packages? I uninstall the system package I used to install that package. However, this doesn't work for cabal-install... AFAICT there's only cabal unregister, Do you mean ghc-pkg unregister? and no way to remove files but manually, which is tricky when these packages are interspersed with other files in /usr/local. I found some old mailing list threads mentioning that this is an open issue, but as I'm currently facing this, I'm wondering if there's been any news on this front. Nope. Maybe using something like stow with this if you're installing it into /usr/local anyway... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
On 13 May 2010 17:09, Heinrich Apfelmus apfel...@quantentunnel.de wrote:
Ah, ok, you want graphs that only work with one node type. If there is
at most one such graph for each node type, you could make a data type
family and retain the parameter, though
data family Graph node :: * - *
data family Graph Int a b = PatriciaTree a b
data family Graph node a b = GenericTree
But it seems that this doesn't work because the cases overlap.
Yup: PatriciaTree, VectorGraph, etc.
However, I can't see any reason why someone would only want to use even
Int values. As I think I've said before (I've been making these
arguments in various threads and discussions, so I'm not sure if I've
said it here): the vertex type is just an _index_ to ensure consistency,
etc; it is _not_ IMHO meant to represent the actual data: that's what
the labels are for.
Yes, the integers are just indexes. Of course, the example with the even
integers is a bit silly; but if the integers are actually indexes, then
it's conceptually cleaner to make them abstract, i.e.
data Node -- constructors are not exported
and provide combinators to operate on these abstract indexes, including
a corresponding Data.Graph.Inductive.NodeMap module.
I'd like to see such an abstract Node type, because then the library
will provide all operations I need. It took me some time to figure out
how to best use Int as indexes in my example code; an abstract Node
type and a good NodeMap module would have made my life much easier.
I'm not sure I understand what you're saying here: first you said you
wanted to be able to specify a vertex type, now you're saying that you
don't want to know what the vertex type even is (except that it's some
abstract Node type)? Whilst this would make graph usage safer/more
robust, this seems to contradict your earlier arguments...
Darn, I meant
data Graph node a b =
Graph { internal :: Graph Int a b, nodes :: Map Int a }
The idea is to use Ints internally and only store a loose association
to the custom vertex type. In particular, no Map a Int is required,
only from Int to a . Now, I realize that the other way round is
required as well for querying the context of a node in a graph.
What's the point of that useless node type parameter then? And how
does the nodes map differ from just getting the graph label?
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
On 13 May 2010 18:14, Henning Thielemann
schlepp...@henning-thielemann.de wrote:
Heinrich Apfelmus schrieb:
Yes, the integers are just indexes. Of course, the example with the even
integers is a bit silly;
... might be useful for bipartite graphs
So, a K_{0,n} bipartite graph? :p
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
On 13 May 2010 04:12, Brent Yorgey byor...@seas.upenn.edu wrote: * Demand More of Your Automata by Aran Donohue Great, because of Aran I now can't change some of the bits of API in graphviz without making the code examples in his article break... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
On 11 May 2010 00:08, Henning Thielemann lemm...@henning-thielemann.de wrote: Because looking up the Map is already very convenient. Why shall I go via the graph? In the Make example, the graph represents relations between files. It is not important what particular shell commands must be run for generating one file from other ones. Why bothering the topological sort algorithm with that information then? You're splitting apart related data into _three_ different data structures (the graph, vertex labels and edge labels)? _That_ doesn't make sense. For starters, you have to ensure you keep them in sync (which FGL will already do for you). As for the Make example; who said you had to put the shell commands as labels? But I think that a label that indicates which cluster a particular node belongs to makes sense to be part of the graph itself rather than in an auxiliary data structure. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
On 11 May 2010 00:22, Henning Thielemann lemm...@henning-thielemann.de wrote: On Tue, 11 May 2010, Ivan Miljenovic wrote: You're splitting apart related data into _three_ different data structures (the graph, vertex labels and edge labels)? _That_ doesn't make sense. There are no edge labels, only vertex labels. And yes, I find separation of data structures for separation of concerns a good strategy. Think about it this way: you want to delete a vertex. With your approach, you have to do the following: 1) Delete it from the graph (which takes care of deleting any edges incident with that vertex) 2) Delete it from your vertex-label mapping 3) If you also have edge labels, delete it from your edge-label mapping for all edges incident with that vertex. As such, you have to do a lot of bookkeeping to keep your graph + associated mappings in a consistent state which FGL currently provides for you _for free_. These mappings are an integral part _of_ the graph, not just something extra that tags along. Keeping them all together helps avoid an inconsistent state. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What do _you_ want to see in FGL?
On 11 May 2010 00:16, Henning Thielemann lemm...@henning-thielemann.de wrote: On Tue, 11 May 2010, Ivan Lazar Miljenovic wrote: Henning Thielemann lemm...@henning-thielemann.de writes: I do not see why there is the need for any type extension, at all. Consider cabal-sort, a very basic program, that is Haskell-98 today, will no longer run in Hugs and JHC (untested so far) because it uses FGL's topological sort when FGL upgraded to associated types. How should it be able to specify a fixed type value for the vertex type? We can't specify that g :: * - * - * - * because the vertex type should _not_ be a parameter in that sense (since for many graphs it won't be, and we need some way of specifying what it is). If I understand you right, you say that explicit type parameters for labels are ok, because I can set them to () if not needed, but for an alternative node type you find an explicit type parameter inappropriate? An explicit type parameter for the vertex type is not appropriate for this reason: you don't want to change it. If we had that g :: * - * - * - *, then you'd have to explicitly carry around your vertex type with you everywhere for all functions with the hint that it might be possible to change (like the label types are). Now, when using a generic Map-based graph representation, this is unavoidable; but when using a custom type with a given fixed vertex type, it should be implicit what that vertex type is without having to carry it around and specify it in the type signature. By specifying it as an Associated Type when defining the instance, that type is accessible to functions that need it and can be ignored for those that don't. For labels, however, we _have_ to have them as type parameters to be able to have mapping functions (how else do you indicate that the type of the labels has changed?). What you seem to want is an explicit hierarchy of graphs where labels are an extra. There are two (feasible) options that I see to this: 1) My so-far-mainly-vapourware generic graph class (see http://code.haskell.org/~ivanm/Graph.hs for a draft) has a base graph class that specifies what the label types are as ATs but allows you to fix them when defining an instance (you still need to set that the label type is (), but there will be convenience functions for use for labels of that type). This has the added advantage of you being able to treat Cabal's PackageIndex type as a graph in its own right (as it is). Currently we're taking a few ideas from this for FGL, but FGL will probably always require the double-label kind that it currently has (with the idea being that FGL is a nice wrapper around the set of classes). The main problem with this at the moment is that there's no real way to bridge the gap: the current type checker doesn't allow equality constraints in superclass contexts (so there's no way of stating that the VLabel type of a graph corresponds to its first type parameter, etc.). 2) Edward Kmett has some interesting notions in terms of _annotated_ graphs. I'm not sure if I follow exactly how it will work, but from what I understand it might be possible to add labels to a graph as an annotated extension. Whichever way ends up getting implemented and chosen, it will not affect FGL: its graphs will always require two type parameters for the labels (however, you _will_ be able to create a new instance which forces those labels to always be () if you so wish). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why cannot ghc find a existng module ?
Does ghc-pkg check complain? Is the version of GHC being used the same one that was used to build xmonad-contrib? What does ghc-pkg field xmonad-contrib exposed-modules | grep LayoutHints say? On 10 May 2010 14:59, zaxis z_a...@163.com wrote: %pacman -Q|grep xmonad xmonad 0.9.1-4 xmonad-contrib 0.9.1-2 %%xmonad --recompile Error detected while loading xmonad configuration file: /home/sw2wolf/.xmonad/xmonad.hs xmonad.hs:20:7: Could not find module `XMonad.Layout.LayoutHints': Use -v to see a list of the files searched for. %ghc-pkg list|grep xmonad xmonad-0.9.1 xmonad-contrib-0.9.1 %pacman -Ql xmonad-contrib|grep LayoutHints xmonad-contrib /usr/lib/ghc-6.12.1/site-local/xmonad-contrib-0.9.1/XMonad/Layout/LayoutHints.hi Sincerely! - e^(π⋅i) + 1 = 0 -- View this message in context: http://old.nabble.com/Why-cannot-ghc-find-a-existng-module---tp28507704p28507704.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 -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why cannot ghc find a existng module ?
(Note that this really should be on the xmonad mailing list, but anyway...).
On 10 May 2010 15:09, zaxis z_a...@163.com wrote:
There is no any complain by ghc-pkg.
%ghc-pkg field xmonad-contrib exposed-modules | grep LayoutHints
XMonad.Layout.LayoutCombinators XMonad.Layout.LayoutHints
Try rm ~/.xmonad/xmonad.{hi,o} and then xmonad --recompile again.
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why cannot ghc find a existng module ?
I suggest you either go on #xmonad and ask the people there, or send
an email to the xmonad mailing list with your config attached.
On 10 May 2010 15:37, zaxis z_a...@163.com wrote:
%rm ~/.xmonad/xmonad.{hi,o}
%ls ~/.xmonad
history xmonad-i386-linux* xmonad.errors xmonad.hs
%xmonad --recompile
Error detected while loading xmonad configuration file:
/home/sw2wolf/.xmonad/xmonad.hs
xmonad.hs:20:7:
Could not find module `XMonad.Layout.LayoutHints':
Use -v to see a list of the files searched for.
Please check the file for errors.
Ivan Lazar Miljenovic wrote:
(Note that this really should be on the xmonad mailing list, but
anyway...).
On 10 May 2010 15:09, zaxis z_a...@163.com wrote:
There is no any complain by ghc-pkg.
%ghc-pkg field xmonad-contrib exposed-modules | grep LayoutHints
XMonad.Layout.LayoutCombinators XMonad.Layout.LayoutHints
Try rm ~/.xmonad/xmonad.{hi,o} and then xmonad --recompile again.
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
-
e^(π⋅i) + 1 = 0
--
View this message in context:
http://old.nabble.com/Why-cannot-ghc-find-a-existng-module---tp28507704p28507878.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
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: gt-tools-0.1.4
On 7 May 2010 12:12, Felipe Lessa felipe.le...@gmail.com wrote: On Thu, May 06, 2010 at 09:30:50PM +0300, Sergei Trofimovich wrote: /me wonders if Miss lambdabot might like to have such functionality. What do you think? Do the terms of use of Google Translate allow it? I can't see any reason why you can't do this: http://translate.google.com/toolkit/TOS.html Also, look at all the Firefox extensions that do it: https://addons.mozilla.org/en-US/firefox/search?q=Google+Translate -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Would it be evil to add deriving Typeable to newtype Q?
On 6 May 2010 02:17, Leonel Fonseca leone...@gmail.com wrote: Is it reasonable to add deriving Typeable to newtype Q? With GeneralizedNewtypeDeriving you mean? If so, then I don't see why it would be a problem. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in a Mathematics AI strike force ?
Well, based on what you want your priorites to be, I might bow out then (at least until you start wanting to have graph-centric operations in there, then I might pitch in). On 6 May 2010 04:23, Alp Mestanogullari a...@mestan.fr wrote: We also have patch-tag project : https://patch-tag.com/r/alpmestan/hasklab/home Any particular reason for using patch-tag rather than code.haskell.org? For the wiki? My main objection to patch-tag is that projects are tied to the user who created them; as such, if you later on decide to leave the project then the entire thing has to be cloned and everyone's URLs will need changing (for homepage, etc.). This applies to github, etc. as well; I don't feel that they are ideal hosting sites for multi-user projects specifically because of this. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: lhs2TeX - lhs2TeX.fmt missing
On 6 May 2010 04:18, Pierre-Etienne Meunier pierreetienne.meun...@gmail.com wrote: By the way, if someone on this list has got too much time, he could write something that would fulfill the goals of literate programming -- à la web and cweb. Knuth was able to make books with his source code. I believe that lhs2tex is great for classes about haskell or fp, but I never found it satisfying for programs with several modules, for instance. I think the main difference between cweb and literate haskell is that the former allows documentation _anywhere_, whereas with literate haskell you can't suddenly cut out of a code block to have a discussion on what the next line means (instead you need to have an explicit comment). Unless GHC[i] starts stripping out all non-code from literate haskell files and joining all the code blocks together, I'm not sure if this situation can be remedied. El 05/05/2010, a las 12:42, Ozgur Akgun escribió: OK, I've found them! They were under /Users/username/.cabal/share/lhs2tex-1.15 and this path was not in the search path of lhs2TeX. I'm using Snow Leoprad. This might be a bug I guess? Not quite; the lhs2tex documentation says you need to put those .fmt, .sty, etc. files in a texmf directory. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell and scripting
On 6 May 2010 08:25, Gregory Crosswhite gcr...@phys.washington.edu wrote: On May 5, 2010, at 3:09 PM, Daniel Fischer wrote: Learning Lisp dialects is much harder (to a large part because of the parentheses, which makes them near impossible to parse). On the contrary, the whole point of parentheses is that it makes Lisp *easier* to parse... for computers. :-) With the added advantage of making it easier for text editors to do automatic indentation properly for precisely the same reason (this is probably the only flaw with Haskell's indentation-centric coding style). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs to mercurial migration
2010/5/6 Günther Schmidt gue.schm...@web.de: I'm switching from darcs to mercurial with some of my projects. Out of curiosity, why? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in a Mathematics AI strike force ?
On 6 May 2010 11:17, Alp Mestanogullari a...@mestan.fr wrote: On Thu, May 6, 2010 at 2:19 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: Well, based on what you want your priorites to be, I might bow out then (at least until you start wanting to have graph-centric operations in there, then I might pitch in). Well, we do now want it to be graph-centric, but graphs definitely play a role here! We may want to implement algorithms relying on graphs. OK, how about we do it this way: I'm currently involved in working on FGL with Louis Wasserman and Thomas Bereknyei and so can't really get involved with your strikeforce atm, but if you have an queries or want something done contact me and I'll see what I can do. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Would it be evil to add deriving Typeable to newtype Q?
Re-CC'ing -cafe:
On 6 May 2010 12:54, Leonel Fonseca leone...@gmail.com wrote:
I wasn't aware of GeneralizedNewtypeDeriving.
I just edited the source file Language.Haskell.TH.Syntax
and left:
newtype Q a = Q { unQ :: forall m. Quasi m = m a }
deriving Typeable
Hang on, is Q something actually in the template-haskell library? In
that case, you can't just do deriving (Typeable) .
However, you might be able to generate the Typeable instance using
DrIFT (see http://hackage.haskell.org/package/DrIFT-cabalized for a
cabal-install-able package).
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] macosx-app for wxHaskell
On 6 May 2010 13:25, Bill Atkins watk...@alum.rpi.edu wrote: In order to run apps built with wxHaskell on OS X, you're supposed to wrap the binary using a script called macosx-app (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X). Unfortunately, after running cabal install wx this file is not in ~/.cabal - it's also not in the wxHaskell source. Does anyone know where I can find it? This thread looks relevant: http://www.mail-archive.com/wxhaskell-us...@lists.sourceforge.net/msg00826.html However, it seems that macosx-app has disappeared with the cabalisation of wxhaskell :s -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
