From aslatter at gmail.com Sun Feb 1 01:13:35 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 1 01:03:52 2009 Subject: [Haskell-cafe] GHC 6.11 missing time package? In-Reply-To: <670e468e0901311954g554fb91eua74f1fcc44de367c@mail.gmail.com> References: <670e468e0901311954g554fb91eua74f1fcc44de367c@mail.gmail.com> Message-ID: <694519c50901312213i1dd09651m7955b711a061c7f1@mail.gmail.com> 2009/1/31 Lyle Kopnicky : > Hi folks, > I'm getting ready to release a piece of software. Unfortunately due to a bug > in GHC 6.10 on Windows it does not handle Ctrl+C properly. Since the bug has > been fixed (thank you Simon Marlow), I figured I'd download a 6.11 build (I > grabbed the 2009-01-29 version). > Unfortunately, my project won't build with it because it's missing the > time-1.1 package. This is sad because I had gone through the trouble to > rewrite my use of oldtime to use time, thinking it was more future-proof. Is > this an oversight in the nightly build, or is this package going out of GHC? > Thanks, > Lyle Hackage seems to have it: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/time Does that work? -Antoine From jgm at berkeley.edu Sun Feb 1 01:37:06 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Sun Feb 1 01:27:24 2009 Subject: [Haskell-cafe] Re: ANN: diagrams 0.2 In-Reply-To: References: <20090131223734.GA28526@seas.upenn.edu> Message-ID: <20090201063706.GC30336@berkeley.edu> +++ Braden Shepherdson [Jan 31 09 18:23 ]: > Brent Yorgey wrote: >> I am very pleased to announce the 0.2 release of the diagrams package, >> an embedded domain-specific language for creating simple graphics in a >> compositional style. This release includes a number of significant >> new features, including: >> >> * support for arbitrary straight and curved paths >> * more shape primitives, including polygons and rounded rectangles >> * support for rendering text >> * PNG, PDF, PS, and SVG output >> * built-in color support replaced with external dependence on the >> feature-rich colour library >> >> and many more! More information, examples, and installation >> instructions can be found at http://code.haskell.org/diagrams. More >> features are planned for future releases, so contributions and >> suggestions are welcome. >> >> (Please note: since diagrams depends on the Cairo library, which has >> unfortunately not been Cabalized, you cannot install the diagrams >> library with cabal-install, unless you already have the cairo package >> installed. See the above website for instructions.) >> >> A special thanks to Dougal Stanton for his contributions to the >> library and help in preparing this release. >> >> -Brent > > Would this make a handy plugin for gitit? I'm currently putting diagrams > together in xfig and saving them to my gitit tree while taking notes in > gitit, but being able to write diagrams code into gitit would be great. > > How easy or hard would this be to accomplish? Not too hard, I think. Here's code for something similar (for graphviz diagrams), derived from plugins/DotPlugin.hs in SVN pandoc. transform :: Block -> IO Block transform (CodeBlock (id, classes, namevals) contents) | "dot" `elem` classes = do let (name, outfile) = case lookup "name" namevals of Just fn -> ([Str fn], fn ++ ".png") Nothing -> ([], uniqueName contents ++ ".png") result <- readProcess "dot" ["-Tpng"] contents writeFile outfile result return $ Para [Image name (outfile, "")] transform x = return x -- | Generate a unique filename given the file's contents. uniqueName :: String -> String uniqueName = showDigest . sha1 . fromString The 'transform' function will transform delimited code blocks such as ~~~ {.dot name="diagram1"} digraph G {Hello->World} ~~~ into images generated by running the contents through graphviz's dot. To lift this into a transformation of Pandoc documents, you can use syb: convertGraphviz :: Pandoc -> IO Pandoc convertGraphviz = everywhereM (mkM transform) With minimal modifications, the same technique should work for diagrams... Best, John From lists at qseep.net Sun Feb 1 04:06:49 2009 From: lists at qseep.net (Lyle Kopnicky) Date: Sun Feb 1 03:57:04 2009 Subject: [Haskell-cafe] GHC 6.11 missing time package? In-Reply-To: <694519c50901312213i1dd09651m7955b711a061c7f1@mail.gmail.com> References: <670e468e0901311954g554fb91eua74f1fcc44de367c@mail.gmail.com> <694519c50901312213i1dd09651m7955b711a061c7f1@mail.gmail.com> Message-ID: <670e468e0902010106ted207a9j7dd0f199ae639bbd@mail.gmail.com> I tried building it from hackage. I got an error: Setup.hs: sh: createProcess: does not exist (No such file or directory) ...which is very similar to the error I get if I try to build it using 6.10: Setup.hs: sh: runGenProcess: does not exist (No such file or directory) I don't know if there's something wrong with the package, or I don't have something set up right to build it on Windows. On Sat, Jan 31, 2009 at 10:13 PM, Antoine Latter wrote: > 2009/1/31 Lyle Kopnicky : > > Hi folks, > > I'm getting ready to release a piece of software. Unfortunately due to a > bug > > in GHC 6.10 on Windows it does not handle Ctrl+C properly. Since the bug > has > > been fixed (thank you Simon Marlow), I figured I'd download a 6.11 build > (I > > grabbed the 2009-01-29 version). > > Unfortunately, my project won't build with it because it's missing the > > time-1.1 package. This is sad because I had gone through the trouble to > > rewrite my use of oldtime to use time, thinking it was more future-proof. > Is > > this an oversight in the nightly build, or is this package going out of > GHC? > > Thanks, > > Lyle > > Hackage seems to have it: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/time > > Does that work? > > -Antoine > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/3a3c52d6/attachment.htm From kamysh at kamysh.org Sun Feb 1 04:33:00 2009 From: kamysh at kamysh.org (Valentyn Kamyshenko) Date: Sun Feb 1 04:23:21 2009 Subject: [Haskell-cafe] circular dependencies in cabal Message-ID: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> Hello all, when I tried to install plugins package with cabal, I've got the following error: # sudo cabal install plugins --global Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 It looks like both versions of process package are currently required: # ghc-pkg unregister process-1.0.1.0 ghc-pkg: unregistering process-1.0.1.0 would break the following packages: haddock-2.3.0 ghc-6.10.1 Cabal-1.6.0.1 gnuplot-0.2 pandoc-1.0.0.1 Graphalyze-0.5 haddock-2.4.1 kibro-0.4.2 panda-2008.11.7 (use --force to override) # ghc-pkg unregister process-1.0.1.1 ghc-pkg: unregistering process-1.0.1.1 would break the following packages: haddock-2.3.0 ghc-6.10.1 haskell-src-1.0.1.3 polyparse-1.1 Graphalyze-0.5 cpphs-1.6 hscolour-1.10.1 haddock-2.4.1 HaXml-1.19.4 hcheat-2008.11.6 rss-3000.1.0 kibro-0.4.2 panda-2008.11.7 haskell98-1.0.1.0 hxt-8.2.0 hcheat-2008.11.14 hxt-filter-8.2.0 xml- parsec-1.0.3 graphviz-2008.9.20 readline-1.0.1.0 uulib-0.9.5 derive-0.1.4 hslogger-1.0.6 MissingH-1.0.2.1 HStringTemplateHelpers-0.0.3 HSHHelpers-0.17 haskell-src-exts-0.4.4 haskell-src-exts-0.4.4.1 haskell-src-exts-0.4.5 ConfigFile-1.0.4 HStringTemplateHelpers-0.0.4 haskell-src-exts-0.4.6 kibro-0.4.3 panda-2008.12.16 HStringTemplateHelpers-0.0.6 SybWidget-0.4.0 wxcore-0.10.5 wx-0.10.5 xtc-1.0 HStringTemplateHelpers-0.0.8 wxcore-0.10.7 wx-0.10.6 HNM-0.1 HNM-0.1.1 wxcore-0.10.12 wxcore-0.11.0 wx-0.11.0 HSHHelpers-0.18 haskell-src-exts-0.4.8 darcs-2.2.0 hslogger-1.0.7 MissingH-1.0.3 HSH-1.2.6 HStringTemplateHelpers-0.0.10 HSHHelpers-0.19 hscolour-1.11 HNM-0.1.2 pandoc-1.1 mps-2008.11.6 hcheat-2008.11.25 panda-2009.1.20 testpack-1.0.0 convertible-1.0.1 gnuplot-0.3 HDBC-2.0.0 HDBC-2.0.1 HDBC-sqlite3-2.0.0.0 HDBC- postgresql-2.0.0.0 (use --force to override) Any suggestions? -- Valentyn From me at twifkak.com Sun Feb 1 04:49:05 2009 From: me at twifkak.com (Devin Mullins) Date: Sun Feb 1 04:41:34 2009 Subject: [Haskell-cafe] Question re: denotational semantics in SPJ's "Implementation of FPLs" book Message-ID: <20090201094905.GA6361@twifkak.com> I'm reading SPJ's "The Implementation of Functional Programming Languages," and on page 32, it defines the multiplication operator in its extended lambda calculus as: Eval[[ * ]] a b = a x b Eval[[ * ]] _|_ b = _|_ Eval[[ * ]] a _|_ = _|_ Is that complete? What are the denotational semantics of * applied to things not in the domain of the multiplication operator x, such as TRUE (in the extended lambda defined by this book) and functions (in normal lambda calc)? Do these things just eval to bottom? Or is this just to be ignored, since the extended calculus will only be applied to properly "typed" expressions in the context of this book? From marco-oweber at gmx.de Sun Feb 1 04:57:34 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Sun Feb 1 04:47:53 2009 Subject: [Haskell-cafe] circular dependencies in cabal In-Reply-To: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> Message-ID: <20090201095734.GA11382@gmx.de> > Any suggestions? a) ignore it and hope you don't get segfaults or problems. b) choose one process libraries and rebuild the other packages using that one. About a) I'm not totally sure what could happen. I just can say That i've used different cabal versions and it went fine. I guess that the problem is A using P-1.0 B using P-1.2 you using A and B, passing data indirectly from A to B and A and B having different compilation options or different behaviour. I'm not too sure about this. Maybe this can give you an idea what could happen. On the other hand you do use runXY or system from process only without passing data from one to the other so chances are good that your app will work nevertheless. Marc Weber From kamysh at kamysh.org Sun Feb 1 05:14:00 2009 From: kamysh at kamysh.org (Valentyn Kamyshenko) Date: Sun Feb 1 05:04:20 2009 Subject: [Haskell-cafe] circular dependencies in cabal In-Reply-To: <20090201095734.GA11382@gmx.de> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <20090201095734.GA11382@gmx.de> Message-ID: <4AEA6C6A-1FDF-4EF6-8F62-F11273E71BD9@kamysh.org> well, the first and most immediate problem is that I can not even fetch the package from hackage using cabal: # cabal fetch plugins Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 however process-1.0.1.1 was excluded because ghc-6.10.1 requires process ==1.0.1.0 so, although I believe the problem with different versions of the same package to co-exist on my computer may be ignored in mane cases, this case makes life very inconvenient. -- Valentyn On Feb 1, 2009, at 1:57 AM, Marc Weber wrote: >> Any suggestions? > > a) ignore it and hope you don't get segfaults or problems. > > b) choose one process libraries and rebuild the other packages using > that one. > > > About a) > I'm not totally sure what could happen. I just can say That i've used > different cabal versions and it went fine. I guess that the problem is > > A using P-1.0 > B using P-1.2 > > you using A and B, passing data indirectly from A to B and A and B > having different compilation options or different behaviour. I'm not > too > sure about this. Maybe this can give you an idea what could happen. > On the other hand you do use runXY or system from process only without > passing data from one to the other so chances are good that your app > will work nevertheless. > > Marc Weber > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From gtener at gmail.com Sun Feb 1 05:38:46 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Sun Feb 1 05:29:01 2009 Subject: [Haskell-cafe] GHC 6.11 missing time package? In-Reply-To: <670e468e0902010106ted207a9j7dd0f199ae639bbd@mail.gmail.com> References: <670e468e0901311954g554fb91eua74f1fcc44de367c@mail.gmail.com> <694519c50901312213i1dd09651m7955b711a061c7f1@mail.gmail.com> <670e468e0902010106ted207a9j7dd0f199ae639bbd@mail.gmail.com> Message-ID: <220e47b40902010238y22d9d410wc047b20e4fdeedef@mail.gmail.com> It looks that you need MSYS or Cygwin to complete this build. Here you can find instructions regarding MSYS (and also GLUT, but you can ignore that part): http://www.haskell.org/pipermail/haskell-cafe/2007-September/031535.html All best Christopher Skrz?tnicki 2009/2/1 Lyle Kopnicky > I tried building it from hackage. I got an error: > Setup.hs: sh: createProcess: does not exist (No such file or directory) > > ...which is very similar to the error I get if I try to build it using > 6.10: > > Setup.hs: sh: runGenProcess: does not exist (No such file or directory) > > I don't know if there's something wrong with the package, or I don't have > something set up right to build it on Windows. > > On Sat, Jan 31, 2009 at 10:13 PM, Antoine Latter wrote: > >> 2009/1/31 Lyle Kopnicky : >> > Hi folks, >> > I'm getting ready to release a piece of software. Unfortunately due to a >> bug >> > in GHC 6.10 on Windows it does not handle Ctrl+C properly. Since the bug >> has >> > been fixed (thank you Simon Marlow), I figured I'd download a 6.11 build >> (I >> > grabbed the 2009-01-29 version). >> > Unfortunately, my project won't build with it because it's missing the >> > time-1.1 package. This is sad because I had gone through the trouble to >> > rewrite my use of oldtime to use time, thinking it was more >> future-proof. Is >> > this an oversight in the nightly build, or is this package going out of >> GHC? >> > Thanks, >> > Lyle >> >> Hackage seems to have it: >> >> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/time >> >> Does that work? >> >> -Antoine >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/a36727ab/attachment.htm From si at fh-wedel.de Sun Feb 1 07:37:50 2009 From: si at fh-wedel.de (Uwe Schmidt) Date: Sun Feb 1 07:27:58 2009 Subject: [Haskell-cafe] ANN: regex-xmlschema Message-ID: <200902011337.50730.si@fh-wedel.de> I'm pleased to announce (yet another) package for processing text with regular expressions: regex-xmlschema The W3C XML Schema specification (http://www.w3.org/TR/xmlschema11-2/#regexs) defines a language for regular expressions. This language is used in the XML Schema spec when defining the data type library part. This regex-xmlschema package contains a complete implementation of this spec. It is implemented with the technique of derivations of regular expression. Main features are: * full support of Unicode including all Unicode code blocks and character properties * a purely functional interface * 100% Haskell, no other packages except parsec needed * cabal build file * extensions for intersection, set difference, exclusive or and interleave of regular sets (regular expressions), * extensions for subexpression matches * functions for matching, for grep like searching, for stream like editing (sed like) and for tokenizing. With this package, it becomes rather easy to build lightweight tokenizers e.g. for colourizing arbitrary programming languages, like hscolor does it for Haskell. The package is available from Hackage: "http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-xmlschema", there's a darcs repo for the latest source: "http://darcs2.fh-wedel.de/hxt/regex/" and a wiki page, describing the extension and giving some examples for using the library: "http://www.haskell.org/haskellwiki/Regular_expressions_for_XML_Schema" Cheers, Uwe -- Uwe Schmidt FH Wedel http://www.fh-wedel.de/~si/ From pocmatos at gmail.com Sun Feb 1 07:54:11 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Sun Feb 1 07:44:29 2009 Subject: [Haskell-cafe] Verifying Haskell Programs Message-ID: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> Hi all, Much is talked that Haskell, since it is purely functional is easier to be verified. However, most of the research I have seen in software verification (either through model checking or theorem proving) targets C/C++ or subsets of these. What's the state of the art of automatically verifying properties of programs written in Haskell? Cheers, -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm From duncan.coutts at worc.ox.ac.uk Sun Feb 1 08:24:24 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 08:14:26 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <9810b81b0901301652g325fd30fk38e35451bcacc229@mail.gmail.com> <1233431697.26754.304.camel@localhost> Message-ID: <1233494664.26754.316.camel@localhost> On Sat, 2009-01-31 at 22:47 +0100, Peter Verswyvelen wrote: > I should have mentioned that my tests have been done only on Windows > and OSX. Ah, right. Well there are Win32 and Quartz backends too. > I guess I would have to try on a system that supports XRender to > compare. > Unfortunately, the target audience of our application are mostly > windows and OSX users, so although it would be great that Cairo > performs fast on unix variants, it would be of little value to us, > unless of course XRender also runs on Windows/OSX somehow :) I have heard that in some cases there is a mismatch in the semantics of Cairo and Quartz which requires falling back to software rendering in some cases. It may be you're hitting those cases. You could send your examples to the cairo folks: http://cairographics.org/FAQ/#profiling Duncan From allbery at ece.cmu.edu Sun Feb 1 08:53:57 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sun Feb 1 08:44:17 2009 Subject: [Haskell-cafe] hslogger bugs or features? In-Reply-To: <20090201012818.GA11418@gmx.de> References: <20090201012818.GA11418@gmx.de> Message-ID: <8EEE88AF-526C-4317-B581-A10B3055C574@ece.cmu.edu> On 2009 Jan 31, at 20:28, Marc Weber wrote: > tmp %./test1 > /tmp nixos > ALERT test, should be shown and should create the sublogger > ALERT test, should not be shown cause we have changed to EMERGENCY > > which is quite confusing because I haven't told hslogger explicitely > to use a log level printing ALERTs on "A.B.C". so I'd expect that only > the first message is shown. This behaviour is explained by the > inheritance of the loglevel when hslogger creates them (without > attaching handlers) automatically. > > I don't want the logging behaviour depend on wether a log line has > been > emitted before or not. > Do you agree? Have I missed something? At least some of what you've missed is that this is inherited from the C syslog library; possibly this should be using withSysLog (options) $ ... to bracket a use of syslog with appropriate openlog()/closelog() and changing top level options should only be attempted in the openlog() call. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/9cbce059/PGP.bin From thomas.dubuisson at gmail.com Sun Feb 1 09:24:41 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Sun Feb 1 09:14:55 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> Message-ID: <4c44d90b0902010624y1e5c8324gd4dc23775a1fd613@mail.gmail.com> On Sun, Feb 1, 2009 at 12:54 PM, Paulo J. Matos wrote: > What's the state of the art of automatically > verifying properties of programs written in Haskell? This is a large field that isn't as black and white as many people frame it. You can write a proof [1] then translate that into Haskell, you can write Haskell then prove key functions, using a case totality checker you could prove it doesn't have any partial functions that will cause an abnormal exit [2], some research has been performed into information flow at UPenn [3], and SPJ/Zu have been looking at static contract checking [4] for some time now - which I hope sees the light of day in GHC 6.12. While this work has been going on, folks at Portland State and a few others (such as Andy Gill [8], NICTA [5], and Peng Li to an extent) have been applying FP to the systems world [6] [7]. Hope this helps, Thomas [1] Perhaps using Isabelle, isabelle.in.tum.de. [2] Neil built CATCH for just this purpose (though it isn't in GHC yet), www-users.cs.york.ac.uk/~ndm/catch/ [3] www.cis.upenn.edu/~stevez/ [4] www.cl.cam.ac.uk/~nx200/ [5] http://ertos.nicta.com.au/research/l4/ [6] Strongly typed memory areas, http://web.cecs.pdx.edu/~mpj/pubs/bytedata.html [7] Some work on non-inference as well as thoughts on building a hypervisor, http://web.cecs.pdx.edu/~rebekah/ [8] Timber language - no, I haven't looked at it yet myself. http://timber-lang.org/ From ben_moseley at mac.com Sun Feb 1 09:26:15 2009 From: ben_moseley at mac.com (Ben Moseley) Date: Sun Feb 1 09:16:41 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <75cc17ac0901311254kc979fc4g8a101ebe46f6f04a@mail.gmail.com> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <7D3A02C1-FBF4-47B5-B9DA-1F6E63256CD9@mac.com> <75cc17ac0901311254kc979fc4g8a101ebe46f6f04a@mail.gmail.com> Message-ID: <043E4469-3F86-4520-932E-B39F41DA3F9D@mac.com> On 31 Jan 2009, at 20:54, Gregg Reynolds wrote: > On Sat, Jan 31, 2009 at 1:02 PM, Ben Moseley > wrote: >> You can view a polymorphic unary type constructor of type ":: a -> >> T" as a >> polymorphic function. > > Shouldn't that be * :: a -> T a ? Yes, you're right. And when I say "polymorphic unary type constructor" I really mean "polymorphic unary /data/ constructor" ... >> In general, polymorphic functions correspond roughly to natural >> transformations (in this case from the identity functor to T). > > > Are you saying a type constructor is a nat trans and not a functor > (component)? Nope ... what I was trying to say is that the data constructor bit is like a nat trans. (You're right that a unary type constructor often does correspond to a functor - providing there's a corresponding arrow/ function component). > Seems much more like a plain ol' functor mapping of > object to object to me - the objects being types. Can you clarify > what you mean about the correspondence with natural transformations? So, the idea is that any polymorphic Haskell function (including Data constructors) can be seen as a natural transformation - so a "function" from any object (ie type) to an arrow (ie function). So, take "listToMaybe :: [a] -> Maybe a" ... this can be seen as a natural transformation from the List functor ([] type constructor) to the Maybe functor (Maybe type constructor) which is a "function" from any type "a" (eg 'Int') to an arrow (ie Haskell function) eg "listToMaybe :: [Int] -> Maybe Int". Hope that makes somewhat more sense. Cheers, --Ben > I admit I haven't thought through "polymorphic function", mainly > because there doesn't seem to be any such beast in category theory, > and to be honest I've always thought the metaphor is misleading. > After all, a function by definition cannot be polymorphic. It seems > like fancy name for a syntactic convenience to me - a way to express > /intensionally/ a set of equations without writing them all out > explicitly. > > Thanks, > > gregg > >> >> --Ben >> >> On 31 Jan 2009, at 17:00, Gregg Reynolds wrote: >> >>> Hi, >>> >>> I think I've finally figured out what a monad is, but there's one >>> thing I haven't seen addressed in category theory stuff I've found >>> online. That is the relation between type constructors and data >>> constructors. >>> >>> As I understand it, a type constructor Tcon a is basically the >>> object >>> component of a functor T that maps one Haskell type to another. >>> Haskell types are construed as the objects of category >>> "HaskellType". >>> I think that's a pretty straightforward interpretation of the CT >>> definition of functor. >>> >>> But a data constructor Dcon a is an /element/ mapping taking >>> elements >>> (values) of one type to elements of another type. So it too can be >>> construed as a functor, if each type itself is construed as a >>> category. >>> >>> So this gives us two functors, but they operate on different things, >>> and I don't see how to get from one to the other in CT terms. Or >>> rather, they're obviously related, but I don't see how to express >>> that >>> relation formally. >>> >>> If somebody could point me in the right direction I'd be grateful. >>> Might even write a tutorial. Can't have too many of those. >>> >>> Thanks, >>> >>> Gregg >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> From duncan.coutts at worc.ox.ac.uk Sun Feb 1 09:38:09 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 09:28:09 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <20090131002952.GA31529@complete.org> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> Message-ID: <1233499089.26754.334.camel@localhost> On Fri, 2009-01-30 at 18:29 -0600, John Goerzen wrote: > On Fri, Jan 30, 2009 at 03:50:30PM -0800, Michael Snoyman wrote: > > >> [3 of 7] Compiling Database.HDBC.Statement ( Database/HDBC/Statement.hs, > > >> dist/build/Database/HDBC/Statement.o ) > > >> > > >> Database/HDBC/Statement.hs:113:9: > > >> Type constructor `Exception' used as a class > > >> In the instance declaration for `Exception SqlError' > > >> cabal: Error: some packages failed to install: > > >> HDBC-2.0.0 failed during the building phase. The exception was: > > >> exit: ExitFailure 1 > > That's *WEIRD*. > > It's as if you have the old base from GHC 6.8. Is cabal-install doing > something (weird|evil|smart) here? Yes. > Leads me to think even more that there's cabal-install trickery here. Yup. > Can someone enlighten us on that? Is cabal-install playing tricks > with base? Yes. The difference (in the released version of cabal-install) between the configure and install commands is that configure uses a dumb algorithm for deciding what versions of dependencies to use while install uses a smarter algorithm. Obviously this is confusing and in the next release configure will use the smart algorithm too. At the moment configure picks the latest versions of all packages irrespective of whether this is likely to work or not. For developers using ghc-6.10 with base 3 and 4 this means they end up with base 4. They then likely do not notice that their package actually needs base version 4. The install command uses the constraint solver and takes into account some global preferences from hackage. These are soft preferences / soft constraints. They do not override constraints specified in the .cabal file or on the command line. However for the huge number of packages on hackage that worked with ghc-6.8 but failed to specify a constraint on the version of base, using a preference of base 3 over base 4 enables those packages to continue to build. So in the next cabal-install release (which should be pretty soon now) configure will do the same thing and pick base 3 unless you specify build-depends base >= 4. So the solution is for HDBC-2.0 to specify the version of base that it needs more accurately. It appears that it does need version 4 so it should use: build-depends: base == 4.* On a similar issue, I am going to make Hackage enforce that packages specify an upper bounds on the version of base. Hopefully doing that will make people also consider the appropriate lower bound. I don't see an obvious way of automatically requiring accuracy in selecting the base version between 3 and 4. It is perfectly possible to have a package that works with both. Perhaps we should make not-specifying an upper bound an error and not specifying a lower bound a warning. Thoughts? Duncan From duncan.coutts at worc.ox.ac.uk Sun Feb 1 09:43:15 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 09:33:14 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <20090131003100.GB31529@complete.org> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <220e47b40901301552h50bade6fi472aa1d017b2adf3@mail.gmail.com> <20090131003100.GB31529@complete.org> Message-ID: <1233499395.26754.340.camel@localhost> On Fri, 2009-01-30 at 18:31 -0600, John Goerzen wrote: > I can't hard-code base >= 4 into .cabal because that would break for > GHC 6.8 users. I have CPP code that selects what to compile based on > GHC version. Ahh, but the version of base is no longer determined by the version of GHC, so using cpp tests on the ghc version is not right (besides it does not work for non-ghc if that is relevant). In future (from Cabal-1.6 onwards) you can use macros to test the version of the package rather than the version of ghc: #if MIN_VERSION_base(4,0,0) ... #endif but since you are trying to support ghc-6.8 (and Cabal-1.2) you cannot rely on these macros yet. You can use this trick: flag base4 library if flag(base4) build-depends: base >= 4 cpp-options: -DBASE4 else build-depends: base < 4 Duncan From duncan.coutts at worc.ox.ac.uk Sun Feb 1 09:53:31 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 09:43:35 2009 Subject: [Haskell-cafe] circular dependencies in cabal In-Reply-To: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> Message-ID: <1233500011.26754.346.camel@localhost> On Sun, 2009-02-01 at 01:33 -0800, Valentyn Kamyshenko wrote: > Hello all, > > when I tried to install plugins package with cabal, I've got the > following error: > > # sudo cabal install plugins --global > Resolving dependencies... > cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 > however > process-1.0.1.1 was excluded because ghc-6.10.1 requires process > ==1.0.1.0 For the most part I refer you to: http://haskell.org/pipermail/haskell-cafe/2009-January/054523.html However the difference is that you've got this problem only within the global package db rather than due to overlap in the global and user package db. > It looks like both versions of process package are currently required: It looks like you installed process-1.0.1.1 and then rebuilt almost every other package against it. Of course you cannot rebuild the ghc package but you did rebuild some of its dependencies which is why it now depends on multiple versions of the process package. Generally rebuilding a package without also rebuilding the packages that depend on it is a bit dodgy (it can lead to linker errors or segfaults). Unfortunately cabal-install does not prevent you from shooting yourself in the foot in these circumstances. > Any suggestions? Aim for a situation where you only have one version of the various core packages. If you do not need to install packages globally then installing them per-user means you at least cannot break the global packages. Duncan From niklas.broberg at gmail.com Sun Feb 1 09:56:19 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Feb 1 09:47:06 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <1233499089.26754.334.camel@localhost> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> Message-ID: > So in the next cabal-install release (which should be pretty soon now) > configure will do the same thing and pick base 3 unless you specify > build-depends base >= 4. ... and so there will never be any incentive for these many packages to migrate to base-4, which also has consequences for packages that do want to use base-4, but also want to depend on such packages. And so base-3 will live on in eternity, and there was never any point in doing that new base release at all. I really really think this is the wrong way to go. Occasional destruction is desperately needed for progress, else things will invariably stagnate. I would suggest as a less stagnating approach to issue a warning/hint when a package with no explicit version dependency for base fails to build. The hint could suggest to the user trying to build the package that they can use 'cabal instal --package=base-3'. Cheers, /Niklas From duncan.coutts at worc.ox.ac.uk Sun Feb 1 09:59:37 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 09:49:37 2009 Subject: [Haskell-cafe] 1,000 packages, so let's build a few! In-Reply-To: <20090131220253.GE24687@scytale.galois.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090131220253.GE24687@scytale.galois.com> Message-ID: <1233500377.26754.350.camel@localhost> On Sat, 2009-01-31 at 14:02 -0800, Don Stewart wrote: > > not really :) e.g. my output on a Windows Vista system with GHC > 6.10.1 > > cabal install sdl > > Configuring SDL-0.5.4... > > setup.exe: sh: runGenProcess: does not exist (No such file or directory) > Isn't this missing C library dependencies, which cabal head now warns > about? No, it's about packages using configure scripts which require MSYS on Windows. In principle we should be able to notice this while doing the package dependency planning and report that we cannot install the package because it needs sh.exe. Duncan From duncan.coutts at worc.ox.ac.uk Sun Feb 1 10:01:28 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 09:51:28 2009 Subject: [Haskell-cafe] 1,000 packages, so let's build a few! In-Reply-To: <20090201005031.GK24687@scytale.galois.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> Message-ID: <1233500488.26754.352.camel@localhost> On Sat, 2009-01-31 at 16:50 -0800, Don Stewart wrote: > Windows people need to set up a windows@haskell.org to sort out their > packaging issues, like we have for debian, arch, gentoo, freebsd and > other distros. > > Unless people take action to get things working well on their platform, > it will be slow going. Actually instead of going off into another mailing list I would encourage them to volunteer on the cabal-devel mailing list to help out. There is lots we could do to improve the experience on Windows and half the problem is we do not have enough people working on it or testing things. Duncan From bugfact at gmail.com Sun Feb 1 10:07:35 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sun Feb 1 09:57:50 2009 Subject: [Haskell-cafe] Panic with GTK2HS 0.10.0 RC under Vista with GHCi 6.10.1; GHCi or GTK bug? Message-ID: Often when trying to run my GTK2HS application the first time with GHCi I get : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This only occurs when I forgot to set my current directory correctly; then GHCi gives an error since it can't find modules GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Boxes.hs:23:17: Could not find module `NM8.GUI.Layout': Use -v to see a list of the files searched for. Failed, modules loaded: none. If I then correctly set my current directory using the :cd command, and try again, I get the panic crash. When I start GHCi again and immediately set the correct current directory, it works fine. I haven't tried to isolate the problem, but maybe others have experienced this problem? It's not really a show-stopper, just but a bit annoying -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/7a6e86bc/attachment.htm From duncan.coutts at worc.ox.ac.uk Sun Feb 1 10:10:34 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 10:00:34 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> Message-ID: <1233501034.26754.360.camel@localhost> On Sun, 2009-02-01 at 15:56 +0100, Niklas Broberg wrote: > > So in the next cabal-install release (which should be pretty soon now) > > configure will do the same thing and pick base 3 unless you specify > > build-depends base >= 4. > > ... and so there will never be any incentive for these many packages > to migrate to base-4, which also has consequences for packages that do > want to use base-4, but also want to depend on such packages. And so > base-3 will live on in eternity, and there was never any point in > doing that new base release at all. > I really really think this is the wrong way to go. Occasional > destruction is desperately needed for progress, else things will > invariably stagnate. I disagree. Having everything fail (we measured it as ~90% of hackage) when people upgraded to ghc-6.10 would have been a disaster. Do you recall the screaming, wailing and gnashing of teeth after the release of ghc-6.8 when most of hackage broke? We (I mean ghc and cabal hackers) got a lot of flak for not making the upgrade process easier and needlessly breaking everyone's perfectly good packages. This time round we went to a lot of effort to make the upgrade process smooth. And for the most part it was. Only a small proportion of hackage packages broke. Now I agree that there is a problem with new packages where the configure selects base 4 but install selects base 3. I've improved that in the darcs version. You're also right that during the lifespan of base 4 we need to encourage new releases to start working with it because we cannot stick with base 3 for ever. Doing that with warnings hints etc is the way to go. Destruction is not such a friendly approach. We do not need to make the users suffer, we just need to inform and persuade developers uploading new releases to do the right thing. Duncan From duncan.coutts at worc.ox.ac.uk Sun Feb 1 10:19:55 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 10:09:54 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> Message-ID: <1233501595.26754.370.camel@localhost> On Sun, 2009-02-01 at 15:56 +0100, Niklas Broberg wrote: > > So in the next cabal-install release (which should be pretty soon now) > > configure will do the same thing and pick base 3 unless you specify > > build-depends base >= 4. > > ... and so there will never be any incentive for these many packages > to migrate to base-4, which also has consequences for packages that do > want to use base-4, but also want to depend on such packages. Actually a package that uses base 4 can depend on other packages that use base 3. They all co-exist fine. This already happens now. > I would suggest as a less stagnating approach to issue a warning/hint > when a package with no explicit version dependency for base fails to > build. So my plan is to make hackage require an upper bound on the version of base for all new packages. That should avoid the need to use the preferences hack the next time around. As for what mechanisms we use to persuade package authors to use base 4 over base 3 for new releases, I'm open to suggestions. One possibility is to warn when configuring if we used the preference to select base 3 rather than 4. That is, if the solver had a free choice between 3 and 4 then that's probably a sign that it needs updating. Of course that doesn't help for packages that work with 3 or 4 perfectly well. We could try a mechanism for base not using the preference system but something more special. For example we could only apply the base 3 preference if there is no upper bound on the version of base. So if the package says: build-depends: base >= 3 && < 5 then we say great, and don't use any default preference (and thus pick base 4). If on the other hand the package says: build-depends: base Then we pick base 3 and we reject all new packages uploaded to hackage like this. They must all specify an upper bound. We could also warn at configuration time. So that's the suggestion, we'd only use the base 3 preference if there is no upper bound on the version of base. That means it should continue to work for old packages and new ones will default to base 4. What do you think? Duncan From niklas.broberg at gmail.com Sun Feb 1 11:22:11 2009 From: niklas.broberg at gmail.com (Niklas Broberg) Date: Sun Feb 1 11:12:25 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <1233501034.26754.360.camel@localhost> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> <1233501034.26754.360.camel@localhost> Message-ID: >> I really really think this is the wrong way to go. Occasional >> destruction is desperately needed for progress, else things will >> invariably stagnate. > > I disagree. Having everything fail (we measured it as ~90% of hackage) > when people upgraded to ghc-6.10 would have been a disaster. Do you > recall the screaming, wailing and gnashing of teeth after the release of > ghc-6.8 when most of hackage broke? We (I mean ghc and cabal hackers) > got a lot of flak for not making the upgrade process easier and > needlessly breaking everyone's perfectly good packages. 90%? That sounds like an awful lot for the relatively minor changes with base-4. I guess a number of packages will use exceptions, and others with use Data and Typeable, but 90%? I don't doubt you when you say that you measured it though, just marvelling. If 90% of hackage would truly break, then I agree that we might need more caution than my radical approach. But I'm not fully convinced there either. After all, unlike with the ghc-6.8 release, all that's needed for a package to work again is to upload a new .cabal that makes the dependency on base-3 explicit, if an author really doesn't want to update the codebase. And even for those packages where library authors don't do that simple step, all that's needed of the user of the library is to specify the base-3 constraint when running cabal-install. My main complaint is really that there is currently no incentive whatsoever for library authors to migrate. If we make base-4 the default, it will require just a little bit of work to make packages that depend on base-3 work anyway, as seen above. It's not so much work that it should incur any screaming, wailing and teeth gnashing. But it should be just enough work to encourage action in one way or another, either truly migrating the code or just making the dependency explicit as I noted above. I think it would be hard to find a more accurate, and non-intrusive, incentive. :-) I definitely agree with your suggestion to make hackage require an upper bound on base. But that's to make us future proof, it won't solve the issue here and now. Cheers, /Niklas From dev at mobileink.com Sun Feb 1 11:27:57 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Sun Feb 1 11:18:11 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <043E4469-3F86-4520-932E-B39F41DA3F9D@mac.com> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <7D3A02C1-FBF4-47B5-B9DA-1F6E63256CD9@mac.com> <75cc17ac0901311254kc979fc4g8a101ebe46f6f04a@mail.gmail.com> <043E4469-3F86-4520-932E-B39F41DA3F9D@mac.com> Message-ID: <75cc17ac0902010827n746316f7nc27b400b78603e60@mail.gmail.com> On Sun, Feb 1, 2009 at 8:26 AM, Ben Moseley wrote: > ]> > So, the idea is that any polymorphic Haskell function (including Data > constructors) can be seen as a natural transformation - so a "function" from > any object (ie type) to an arrow (ie function). So, take "listToMaybe :: [a] > -> Maybe a" ... this can be seen as a natural transformation from the List > functor ([] type constructor) to the Maybe functor (Maybe type constructor) > which is a "function" from any type "a" (eg 'Int') to an arrow (ie Haskell > function) eg "listToMaybe :: [Int] -> Maybe Int". > Aha, hadn't thought of that. In other terms, a natural transformation is how one gets from one lifted value to different lift of the same value - from a lift to a hoist, as it were. Just calling it a function doesn't do it justice. Very enlightening, thanks. I'm beginning to think Category Theory is just about the coolest thing since sliced bread. If I understand correctly, we can "represent" a data constructor in two ways (at least): qua functor: Dcon : a -> T a qua nat trans Dcon : Id a -> T a and thanks to the magic of CT we can think of these as "equivalent" (involving some kind of isomorphism). BTW, I should mention I'm not a mathematician, in case it's not blindingly obvious. My interest is literary - I'm just naive enough to think this stuff could be explained in plain English, but I'm not quite there yet. Thanks much, -gregg From sebastian.sylvan at gmail.com Sun Feb 1 11:50:46 2009 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sun Feb 1 11:41:28 2009 Subject: [Haskell-cafe] 1,000 packages, so let's build a few! In-Reply-To: <1233500377.26754.350.camel@localhost> References: <49848480.70106@btinternet.com><20090131203528.GC24687@scytale.galois.com><20090131220253.GE24687@scytale.galois.com> <1233500377.26754.350.camel@localhost> Message-ID: <4153454447CF40F49A48195EBE6B4CB0@SebastianPC> -------------------------------------------------- From: "Duncan Coutts" Sent: Sunday, February 01, 2009 2:59 PM To: "Don Stewart" Cc: Subject: Re: [Haskell-cafe] 1,000 packages, so let's build a few! > On Sat, 2009-01-31 at 14:02 -0800, Don Stewart wrote: > >> > not really :) e.g. my output on a Windows Vista system with GHC >> 6.10.1 >> > cabal install sdl > >> > Configuring SDL-0.5.4... >> > setup.exe: sh: runGenProcess: does not exist (No such file or >> > directory) > >> Isn't this missing C library dependencies, which cabal head now warns >> about? > > No, it's about packages using configure scripts which require MSYS on > Windows. > > In principle we should be able to notice this while doing the package > dependency planning and report that we cannot install the package > because it needs sh.exe. > I wonder *why* packages need sh though? Isn't cabal supposed to allow you to do that kind of scripting in Haskell rather than calling into platform-dependent shell scripts? Are there any specific reasons why people feel the need to use sh? If the package is unix-only for other reasons (e.g. bindings to X or whatever) then it's obviously not a problem, but it appears to me that there's lots of packages that should be portable in principle that won't build on windows because it needs to run sh... From duncan.coutts at worc.ox.ac.uk Sun Feb 1 11:59:12 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 11:49:14 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> <1233501034.26754.360.camel@localhost> Message-ID: <1233507552.26754.385.camel@localhost> On Sun, 2009-02-01 at 17:22 +0100, Niklas Broberg wrote: > >> I really really think this is the wrong way to go. Occasional > >> destruction is desperately needed for progress, else things will > >> invariably stagnate. > > > > I disagree. Having everything fail (we measured it as ~90% of hackage) > > when people upgraded to ghc-6.10 would have been a disaster. Do you > > recall the screaming, wailing and gnashing of teeth after the release of > > ghc-6.8 when most of hackage broke? We (I mean ghc and cabal hackers) > > got a lot of flak for not making the upgrade process easier and > > needlessly breaking everyone's perfectly good packages. > > 90%? That sounds like an awful lot for the relatively minor changes > with base-4. I guess a number of packages will use exceptions, and > others with use Data and Typeable, but 90%? I don't doubt you when you > say that you measured it though, just marvelling. http://www.haskell.org/pipermail/glasgow-haskell-users/2008-October/015654.html Most non-trivial packages either use exceptions or depend on a package that uses exceptions (or syb). The 90% is from memory however. I can't find our exact measurements. I think we may have given up trying to measure precisely after it became obvious that nothing was working. > If 90% of hackage would truly break, then I agree that we might need > more caution than my radical approach. But I'm not fully convinced > there either. I think in the end we managed to get it down to around 5% breakage which I felt was a pretty good result. > After all, unlike with the ghc-6.8 release, all that's > needed for a package to work again is to upload a new .cabal that > makes the dependency on base-3 explicit, For the most part that was all that was required for 6.8 too, to add dependencies on the new packages split out of base. People still complained. A lot. :-) > if an author really doesn't want to update the codebase. And even for > those packages where library authors don't do that simple step, all > that's needed of the user of the library is to specify the base-3 > constraint when running cabal-install. But people do not know that. It has to work by default (even if it warns). > My main complaint is really that there is currently no incentive > whatsoever for library authors to migrate. If we make base-4 the > default, it will require just a little bit of work to make packages > that depend on base-3 work anyway, as seen above. It's not so much > work that it should incur any screaming, wailing and teeth gnashing. > But it should be just enough work to encourage action in one way or > another, either truly migrating the code or just making the dependency > explicit as I noted above. I think it would be hard to find a more > accurate, and non-intrusive, incentive. :-) I think the right place to put incentives is in checks in new uploads to hackage. Making existing packages break should be avoided when possible, even when the changes the developer needs to make are trivial. Many many end users have no idea how to make these trivial changes and it is not our intention to punish them. From the perspective of an end user just trying to install something it either works or it doesn't. When a large proportion stop working is when the teeth gnashing starts. Also remember that many packages do not have very active maintainers. > I definitely agree with your suggestion to make hackage require an > upper bound on base. But that's to make us future proof, True. > it won't solve the issue here and now. What do you think about the suggestions in my other reply? I hope that is a reasonable suggestion to encourage a transition to base 4 without punishing end users. Duncan From jgm at berkeley.edu Sun Feb 1 12:07:53 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Sun Feb 1 11:58:09 2009 Subject: [Haskell-cafe] ANN: gitit 0.5.1 Message-ID: <20090201170753.GA8172@berkeley.edu> I've just uploaded gitit 0.5.1 to HackageDb. Gitit is a wiki program that uses git or darcs as a filestore and HAppS as a server. Changes: * Major code reorganization, making gitit more modular. * Gitit can now optionally be built using Happstack instead of HAppS (just use -fhappstack when cabal installing). * Fixed bug with directories that had the same names as pages. * Added code from HAppS-Extra to fix cookie parsing problems. * New command-line options for --port, --debug. * New debug feature prints the date, the raw request, and the processed request data to standard output on each request. * Files with ".page" extension can no longer be uploaded. * Apostrophes and quotation marks now allowed in page names. From duncan.coutts at worc.ox.ac.uk Sun Feb 1 12:10:36 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 12:00:49 2009 Subject: [Haskell-cafe] 1,000 packages, so let's build a few! In-Reply-To: <4153454447CF40F49A48195EBE6B4CB0@SebastianPC> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090131220253.GE24687@scytale.galois.com> <1233500377.26754.350.camel@localhost> <4153454447CF40F49A48195EBE6B4CB0@SebastianPC> Message-ID: <1233508236.26754.394.camel@localhost> On Sun, 2009-02-01 at 16:50 +0000, Sebastian Sylvan wrote: > >> Isn't this missing C library dependencies, which cabal head now warns > >> about? > > > > No, it's about packages using configure scripts which require MSYS on > > Windows. > > > > In principle we should be able to notice this while doing the package > > dependency planning and report that we cannot install the package > > because it needs sh.exe. > > > > I wonder *why* packages need sh though? Isn't cabal supposed to allow you to > do that kind of scripting in Haskell rather than calling into > platform-dependent shell scripts? It does enable people to make portable packages, yes. It does not prevent people from using ./configure scripts, though as a community we do try to encourage people only to use them where it is essential. > Are there any specific reasons why people feel the need to use sh? If you look at existing packages that use configure scripts you'll see some are pretty tricky, doing lots of checks in system header files for sizes of structures, values of constants and the presence of C functions in various header files. Some are trivial and should be done away with. For example the ones that just check if a C header / lib is present are unnecessary (and typically do not work correctly). The next point release of Cabal can do these checks automatically, eg: Configuring foo-1.0... cabal: Missing dependencies on foreign libraries: * Missing header file: foo.h * Missing C libraries: foo, bar, baz This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. > If the package is unix-only for other reasons (e.g. bindings to X or > whatever) then it's obviously not a problem, but it appears to me that > there's lots of packages that should be portable in principle that won't > build on windows because it needs to run sh... We need to do a survey of the existing packages that use configure scripts and identify what they are doing exactly. What we want to do is work out what checks they are performing and which ones could be turned into portable checks in cabal or in Setup.hs scripts. We want to know, if we added feature X to Cabal, then Y packages could give up their configure scripts. This would be an excellent task for some volunteer to take on. http://hackage.haskell.org/trac/hackage/ticket/482 Duncan From claus.reinke at talk21.com Sun Feb 1 12:21:08 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Sun Feb 1 12:11:32 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkitsdoesn't make any sense References: <20090127000544.3182da13@solaris><2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com><3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com><20090130215046.568edcc0@solaris><3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com><3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com><9810b81b0901301652g325fd30fk38e35451bcacc229@mail.gmail.com> <0E3EF5D5B7EF4243BE09BFF66F2E596A@cr3lt> Message-ID: <2B0BAAB0F63C4536ABACA446E05FA42A@cr3lt> > A common standard would be useful, but OpenVG doesn't look > like "ready soon". On the declarative side, there's also SVG.. Seems I've got to qualify that remark somewhat - apart from some commercial/closed-source implementations, there is also a open source ANSI C one (implemented on top of OpenGL, so it isn't quite the same as direct OpenGL hardware support, but it offers the same API and might be a good target for a Haskell binding..): http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html Also, an OpenVG backend for Cairo, which seems to have so many backends that it might be the safest user-level choice? http://lists.cairographics.org/archives/cairo/2008-January/012833.html http://lists.cairographics.org/archives/cairo/2008-January/012840.html Claus From dev at mobileink.com Sun Feb 1 12:36:11 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Sun Feb 1 12:26:25 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <49a77b7a0901311314q298a1986sbcab5cc95c32c186@mail.gmail.com> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <49a77b7a0901311314q298a1986sbcab5cc95c32c186@mail.gmail.com> Message-ID: <75cc17ac0902010936r523c6fd3i7064dc1e813e94b1@mail.gmail.com> On Sat, Jan 31, 2009 at 3:14 PM, David Menendez wrote: > > There's a paper about defining catamorphisms for GADTs and nested > recursive types that models type constructors that way. If you recall a title or author I'll google it. >> So this gives us two functors, but they operate on different things, >> and I don't see how to get from one to the other in CT terms. Or >> rather, they're obviously related, but I don't see how to express that >> relation formally. > > Again, what sort of relationship are you thinking of? Data Ok, good question. I guess the problem I'm having is one of abstraction management. CT prefers to disregard the "contents" of its objects, imposing a kind of blood-brain barrier between the object and its internal structure. Typical definitions of functor, for example, make no reference to the "elements" of an object; a functor is just a pair of morphisms, one taking objects to objects, the other morphisms to morphisms. This leaves the naive reader (i.e. me) to wonder how it is that the internal stuff is related to the functor stuff. For example: is it true that the object component of a functor necessarily "has" a bundle of specific functions relating the internal "elements" of the objects? If so, is the object component merely an abstraction of the bundle? Or is it ontologically a different thing? Hence my question about constructors in Haskell: the type constructor operates on the opaque object (type); the data constructor operates on the values (type as transparent object?). A type and its values seem to be different kinds of things, so there must be some way to explicitly account for their relationship. I figure either I'm missing something about functors, or I need a more sophisticated understanding of type-as-category. Anyway, thanks to you and the other responders I have enough to go away and figure it out (I hope). Thanks, gregg From aslatter at gmail.com Sun Feb 1 12:57:29 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 1 12:47:43 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX Message-ID: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> Funny story, If I do the following three things, I get errors on my Intel Mac OS 10.5: * Build an executable with Cabal * Have the executable have a build-dep of pcre-light in the .cabal * use haskeline in the executable itself I get crazy linker errors relating to haskeline and libiconv: Shell output: >>>>> $ cabal clean && cabal configure && cabal build cleaning... Configuring test-0.0.0... Preprocessing executables for test-0.0.0... Building test-0.0.0... [1 of 1] Compiling Main ( test.hs, dist/build/test/test-tmp/Main.o ) Linking dist/build/test/test ... Undefined symbols: "_iconv_open", referenced from: _s9Qa_info in libHShaskeline-0.6.0.1.a(IConv.o) "_iconv_close", referenced from: _iconv_close$non_lazy_ptr in libHShaskeline-0.6.0.1.a(IConv.o) "_iconv", referenced from: _sa0K_info in libHShaskeline-0.6.0.1.a(IConv.o) ld: symbol(s) not found collect2: ld returned 1 exit status <<<<< But all three above conditions need to be true - if I build using 'ghc --make' everything works great, even if the executable imports pcre-light and haskeline. If I have build-deps on haskeline and pcre-light, but don't actually import haskeline, everything also works great. Here are the files I've used: test.hs: >>>>> import System.Console.Haskeline main :: IO () main = print "Hello!" <<<<< test.cabal >>>>> Name: test version: 0.0.0 cabal-version: >= 1.2 build-type: Simple Executable test main-is: test.hs build-depends: base, haskeline, pcre-light>=0.3 <<<<< Is there some way I need to be building haskeline on OS X to make this work? Thanks, Antoine more details: >>>>> $ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library <<<<< >>>>> $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081007 <<<<< links: pcre-light: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light haskeline: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline From tom.davie at gmail.com Sun Feb 1 13:01:39 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sun Feb 1 12:51:59 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> Message-ID: <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it. Bob On 1 Feb 2009, at 18:57, Antoine Latter wrote: > Funny story, > > If I do the following three things, I get errors on my Intel Mac OS > 10.5: > > * Build an executable with Cabal > * Have the executable have a build-dep of pcre-light in the .cabal > * use haskeline in the executable itself > > I get crazy linker errors relating to haskeline and libiconv: > > Shell output: >>>>>> > $ cabal clean && cabal configure && cabal build > cleaning... > Configuring test-0.0.0... > Preprocessing executables for test-0.0.0... > Building test-0.0.0... > [1 of 1] Compiling Main ( test.hs, dist/build/test/test- > tmp/Main.o ) > Linking dist/build/test/test ... > Undefined symbols: > "_iconv_open", referenced from: > _s9Qa_info in libHShaskeline-0.6.0.1.a(IConv.o) > "_iconv_close", referenced from: > _iconv_close$non_lazy_ptr in libHShaskeline-0.6.0.1.a(IConv.o) > "_iconv", referenced from: > _sa0K_info in libHShaskeline-0.6.0.1.a(IConv.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > <<<<< > > But all three above conditions need to be true - if I build using 'ghc > --make' everything works great, even if the executable imports > pcre-light and haskeline. If I have build-deps on haskeline and > pcre-light, but don't actually import haskeline, everything also works > great. > > Here are the files I've used: > > test.hs: >>>>>> > import System.Console.Haskeline > > main :: IO () > main = print "Hello!" > <<<<< > > test.cabal >>>>>> > Name: test > version: 0.0.0 > cabal-version: >= 1.2 > build-type: Simple > > Executable test > main-is: test.hs > build-depends: base, haskeline, pcre-light>=0.3 > <<<<< > > Is there some way I need to be building haskeline on OS X to make > this work? > > Thanks, > Antoine > > more details: > >>>>>> > $ cabal --version > cabal-install version 0.6.0 > using version 1.6.0.1 of the Cabal library > <<<<< > >>>>>> > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version > 6.10.0.20081007 > <<<<< > > links: > pcre-light: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light > haskeline: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From aslatter at gmail.com Sun Feb 1 13:04:02 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 1 12:54:16 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> Message-ID: <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote: > This is caused by OS X's libiconv being entirely CPP macros, the FFI has > nothing to get hold of. IIRC there's a ghc bug report open for it. > > Bob > So why does it sometimes work? I can write and compile executables using haskeline, both with 'ghc --make' and 'cabal configure && cabal build'. This sounds like something I can patch haskeline to account for, then? Thanks, Antoine From dev at mobileink.com Sun Feb 1 13:04:11 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Sun Feb 1 12:54:27 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <4984D014.5010901@freegeek.org> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <4984D014.5010901@freegeek.org> Message-ID: <75cc17ac0902011004l71675254yc8fc8431191f4437@mail.gmail.com> On Sat, Jan 31, 2009 at 4:26 PM, wren ng thornton wrote: >> But a data constructor Dcon a is an /element/ mapping taking elements >> (values) of one type to elements of another type. So it too can be >> construed as a functor, if each type itself is construed as a >> category. > > Actually no, it's not a functor. It's a (collection of) morphism(s). Let's > again assume a single-argument Dcon for simplicity. The Haskell type |Dcon > :: forall a. a -> Tcon a| is represented by a collection of morphisms > |Dcon_{X} : X -> Tcon X| for each X in Ob(Hask). Ok, I see I elided that step. So my question is about the relation between the individual (specialized) Dcon and the associated Tcon. I.e. Dcon 3 is a value of type Tcon Int, inferred by the type system. So it looks to me like the relation between the Tcon functor and the Dcon functions is basically ad hoc. You use Tcon to construct new types; you can define any function you wish to map values into that type. The Haskell data notation is just a syntactic convenience for doing both at once, but the functor has no necessary relation to the functions. (Flailing wildly...) > > It's important to remember that Tcon is the object half of an *endo*functor > |Tcon : Hask -> Hask| and not just any functor. We can view the object half > of an endofunctor as a collection of morphisms on a category; not > necessarily real morphisms that exist within that category, but more like an > overlay on a graph. In some cases, this overlay forms a subcategory (that > is, they are all indeed morphisms in the original category). And this is > what we have with data constructors: they are (pieces of) the image of the > endofunctor from within the category itself. (unknotting arms...) Uh, er, hmm. I'm still having abstraction vertigo, since we have (I think) data constructors qua generic thingees that work at the level of the category, and the same, specialized to a type, qua functions that operate on the internals of the categorical objects. It's the moving back and forth from type and value that escapes me, and I'm not sure I'm even describing the issue properly. I shall go away and thing about this and then write the answer down. Thanks much, you've given me a lot to think about. -gregg From dev at mobileink.com Sun Feb 1 13:27:02 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Sun Feb 1 13:17:17 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <1233443464.17073.78.camel@derek-laptop> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <1233443464.17073.78.camel@derek-laptop> Message-ID: <75cc17ac0902011027y4854351axc19c9b932573a10d@mail.gmail.com> On Sat, Jan 31, 2009 at 5:11 PM, Derek Elkins wrote: >> >> But a data constructor Dcon a is an /element/ mapping taking elements >> (values) of one type to elements of another type. So it too can be >> construed as a functor, if each type itself is construed as a >> category. > > What are "elements" of a type? How are you "construing a type as a > category"? One answer is that you are viewing types as sets. Ignoring That's a good question. I've been hoping that viewing types as sets is good enough but that doesn't seem to be the case. > Most articles that apply CT to Haskell take one of two approaches. They > either talk about a category of Haskell types and functions with no > explanation of what those "actually" are, i.e. the understanding that it > behaves like (idealized) Haskell, or they refer to some existing > approach to (idealized) semantics, e.g. sets or domains. In either > case, the meaning of the objects and arrows is effectively taken for > granted. You can say that again. > > An approach along the lines you are suggesting would be useful for a > categorical semantics of Haskell, but it would just be one possible > semantics among many. For most of the aforementioned articles, the only > value of such a thing would be to be able to formally prove that the > constructions talked about exist (except that they usually don't for > technical reasons.) Usually in those articles, the readers are assumed > to know Haskell and to not know much about category theory, so trying to > explain types and functions to them categorically is unnecessary and > obfuscatory. It would make sense if you were going the other way, > explaining Haskell to categorists. Actually, what I have in mind using the concepts and terminology of CT to explain Haskell to ordinary programmers. The idea is not necessarily to prove stuff, but to build the intuitions needed to think about computing at a higher level of abstraction before proceeding to Haskell. I suspect this might be the quicker road to Haskell mastery; even if not it's a fun writing project. Call me nutty, but I think the basic concepts of CT - category, functor, natural transformation, monad - are actually pretty simple, even though it took much gnashing of teeth for me to acquire a basic intuition. You don't have to be a mathematician to see the basic structural ideas and get some idea of their usefulness, /if/ you have appropriate pedagogical material. Alas, I've found that clear, simple explanations are scattered across lots of different documents. Thanks for your help; I can see I've got a few more things to work on (like "type"). -gregg From aslatter at gmail.com Sun Feb 1 13:43:11 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 1 13:33:25 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> Message-ID: <694519c50902011043t379ff90ew90c233d8a13145f3@mail.gmail.com> On Sun, Feb 1, 2009 at 12:04 PM, Antoine Latter wrote: > On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote: >> This is caused by OS X's libiconv being entirely CPP macros, the FFI has >> nothing to get hold of. IIRC there's a ghc bug report open for it. >> >> Bob >> > > So why does it sometimes work? I can write and compile executables > using haskeline, both with 'ghc --make' and 'cabal configure && cabal > build'. > > This sounds like something I can patch haskeline to account for, then? > After a bit of digging, I saw this snippet in the .cabal file for the iconv package on hackage: >>>>> -- We need to compile via C because on some platforms (notably darwin) -- iconv is a macro rather than real C function. doh! ghc-options: -fvia-C -Wall <<<<< But it looks like the 'iconv' package is broken in the exact same way for me - I get the same crazy linker errors. Thanks, Antoine From mads_lindstroem at yahoo.dk Sun Feb 1 13:40:05 2009 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Sun Feb 1 13:36:21 2009 Subject: [Haskell-cafe] Howto debug erros occuring just by linking to non-Haskell libraries Message-ID: <1233513605.4413.26.camel@localhost.localdomain> Hi Haskeleers I am trying to track down the cause of an error occurring in the Linux version of wxHaskell. The error occurs before the main function is executed. That is, it occurs if one imports the wxHaskell libraries, and it occurs even if one do not execute any wxHaskell function. Specifically, GLib complains that a initialization-function has not been called. My guess is, that it has something to do with the wxWidgets (and gtk or glib) libraries wxHaskell links to. Some people have suggested it may be an error in the way GHC links with C libraries. But that is all guesswork, I would need something more solid if I were to file GHC bugreport. Here is a simple Haskell program to illustrate the problem: module Main where import Graphics.UI.WX main = print "sdfjkl" and when we compile and execute this program we get: (process:13986): GLib-GObject-CRITICAL **: gtype.c:2240: initialization assertion failed, use IA__g_type_init() prior to this function (process:13986): Gdk-CRITICAL **: gdk_cursor_new_for_display: assertion `GDK_IS_DISPLAY (display)' failed (process:13986): GLib-GObject-CRITICAL **: gtype.c:2240: initialization assertion failed, use IA__g_type_init() prior to this function (process:13986): Gdk-CRITICAL **: gdk_cursor_new_for_display: assertion `GDK_IS_DISPLAY (display)' failed "sdfjkl" So even if I do not call any wxHaskell functions, just by linking to wxHaskell, I get these errors. As Jeroen Janssen reports here http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00540.html , he is experiencing the same error, but his wxPython programs works. Thus, wxHaskell (or GHC or ...) must do something different. Could this error be related to the order which external libraries are loaded in? If so, do anybody know how to specify the load order? Can anybody help med with a good approach for debugging this error? Greetings, Mads Lindstr?m From dons at galois.com Sun Feb 1 13:57:47 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 1 13:48:03 2009 Subject: [Haskell-cafe] Complex C99 type in Foreign In-Reply-To: References: Message-ID: <20090201185747.GW24687@scytale.galois.com> briqueabraque: > Hi, > > Are there plans to include C99 'complex' type > in Foreign, maybe as CFloatComplex, CDoubleComplex > and CLongDoubleComplex? This seems an easy addition > to the standard and would allow binding of a few > interesting libraries, like GSL. > A separate library for new types to add to Foreign would be the easiest way forward. Just put the foreign-c99 package on Hackage? -- Don From tom.davie at gmail.com Sun Feb 1 14:01:08 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sun Feb 1 13:51:36 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <694519c50902011043t379ff90ew90c233d8a13145f3@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> <694519c50902011043t379ff90ew90c233d8a13145f3@mail.gmail.com> Message-ID: <580A2F1F-DF6C-4B7B-9929-16AA61389002@gmail.com> On 1 Feb 2009, at 19:43, Antoine Latter wrote: > On Sun, Feb 1, 2009 at 12:04 PM, Antoine Latter > wrote: >> On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie >> wrote: >>> This is caused by OS X's libiconv being entirely CPP macros, the >>> FFI has >>> nothing to get hold of. IIRC there's a ghc bug report open for it. >>> >>> Bob >>> >> >> So why does it sometimes work? I can write and compile executables >> using haskeline, both with 'ghc --make' and 'cabal configure && cabal >> build'. >> >> This sounds like something I can patch haskeline to account for, >> then? >> > > > After a bit of digging, I saw this snippet in the .cabal file for the > iconv package on hackage: > >>>>>> > -- We need to compile via C because on some platforms (notably > darwin) > -- iconv is a macro rather than real C function. doh! > ghc-options: -fvia-C -Wall > <<<<< > > But it looks like the 'iconv' package is broken in the exact same way > for me - I get the same crazy linker errors. Yep, darwin is OS X :) Bob From judah.jacobson at gmail.com Sun Feb 1 14:09:18 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Feb 1 13:59:32 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> Message-ID: <6d74b0d20902011109o3afe642er5637674b17d9c2ec@mail.gmail.com> On Sun, Feb 1, 2009 at 10:04 AM, Antoine Latter wrote: > On Sun, Feb 1, 2009 at 12:01 PM, Thomas Davie wrote: >> This is caused by OS X's libiconv being entirely CPP macros, the FFI has >> nothing to get hold of. IIRC there's a ghc bug report open for it. >> >> Bob >> > > So why does it sometimes work? I can write and compile executables > using haskeline, both with 'ghc --make' and 'cabal configure && cabal > build'. > > This sounds like something I can patch haskeline to account for, then? > The OS X system libiconv is actually OK; it's the MacPorts libiconv that has the CPP macros. When the cabal package depends on pcre-light it pulls in all of pcre-light's options; and like me, you probably compiled pcre-light to link against /opt/local/lib. To confirm this I ran "ghc --make -L/opt/local/lib test.hs" on my OS X machine and saw the same error as you. Thanks for the report; I'm not sure of what the right solution is, but I opened a ticket on Haskeline's bug tracker: http://trac.haskell.org/haskeline/ticket/74 Feel free to add comments, propose a fix or suggest a workaround. -Judah From bulat.ziganshin at gmail.com Sun Feb 1 14:19:18 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sun Feb 1 14:09:40 2009 Subject: [Haskell-cafe] pure crisis :) Message-ID: <593855719.20090201221918@gmail.com> Hello haskell-cafe, pure functional denotation for crisis: (_|_) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From pieter at laeremans.org Sun Feb 1 14:46:16 2009 From: pieter at laeremans.org (Pieter Laeremans) Date: Sun Feb 1 14:36:35 2009 Subject: [Haskell-cafe] Network.UrlDisp Message-ID: Hello, Has anyone some exampe usages of : Network.UrlDisp ? thanks in advance, Pieter -- Pieter Laeremans From aslatter at gmail.com Sun Feb 1 14:53:23 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 1 14:43:38 2009 Subject: [Haskell-cafe] Re: Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> Message-ID: <694519c50902011153j4ddf5631lca37ba22902f5ef5@mail.gmail.com> On Sun, Feb 1, 2009 at 11:57 AM, Antoine Latter wrote: > Funny story, > > If I do the following three things, I get errors on my Intel Mac OS 10.5: > > * Build an executable with Cabal > * Have the executable have a build-dep of pcre-light in the .cabal > * use haskeline in the executable itself > > I get crazy linker errors relating to haskeline and libiconv: > > Shell output: >>>>>> > $ cabal clean && cabal configure && cabal build > cleaning... > Configuring test-0.0.0... > Preprocessing executables for test-0.0.0... > Building test-0.0.0... > [1 of 1] Compiling Main ( test.hs, dist/build/test/test-tmp/Main.o ) > Linking dist/build/test/test ... > Undefined symbols: > "_iconv_open", referenced from: > _s9Qa_info in libHShaskeline-0.6.0.1.a(IConv.o) > "_iconv_close", referenced from: > _iconv_close$non_lazy_ptr in libHShaskeline-0.6.0.1.a(IConv.o) > "_iconv", referenced from: > _sa0K_info in libHShaskeline-0.6.0.1.a(IConv.o) > ld: symbol(s) not found > collect2: ld returned 1 exit status > <<<<< > > But all three above conditions need to be true - if I build using 'ghc > --make' everything works great, even if the executable imports > pcre-light and haskeline. If I have build-deps on haskeline and > pcre-light, but don't actually import haskeline, everything also works > great. > > Here are the files I've used: > > test.hs: >>>>>> > import System.Console.Haskeline > > main :: IO () > main = print "Hello!" > <<<<< > > test.cabal >>>>>> > Name: test > version: 0.0.0 > cabal-version: >= 1.2 > build-type: Simple > > Executable test > main-is: test.hs > build-depends: base, haskeline, pcre-light>=0.3 > <<<<< > > Is there some way I need to be building haskeline on OS X to make this work? > > Thanks, > Antoine > > more details: > >>>>>> > $ cabal --version > cabal-install version 0.6.0 > using version 1.6.0.1 of the Cabal library > <<<<< > >>>>>> > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.0.20081007 > <<<<< > > links: > pcre-light: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/pcre-light > haskeline: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskeline > For folks following along at home, the above example starts working again if I hard-code some LD flags into my example .cabal file: >>>>> Name: test version: 0.0.0 cabal-version: >= 1.2 build-type: Simple Executable test main-is: test.hs build-depends: base, iconv, pcre-light>=0.3 ld-options: -L/usr/lib -L/opt/local/lib <<<<< This way I make sure that I'm linking against the "good" version of iconv instead of the Mac Ports version. I'm not sure what a general solution is. -Antoine From jgoerzen at complete.org Sun Feb 1 14:58:32 2009 From: jgoerzen at complete.org (John Goerzen) Date: Sun Feb 1 14:48:52 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <1233501595.26754.370.camel@localhost> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> <1233501595.26754.370.camel@localhost> Message-ID: <4985FEE8.2030507@complete.org> Duncan Coutts wrote: > On Sun, 2009-02-01 at 15:56 +0100, Niklas Broberg wrote: >>> So in the next cabal-install release (which should be pretty soon now) >>> configure will do the same thing and pick base 3 unless you specify >>> build-depends base >= 4. >> ... and so there will never be any incentive for these many packages >> to migrate to base-4, which also has consequences for packages that do >> want to use base-4, but also want to depend on such packages. > > Actually a package that uses base 4 can depend on other packages that > use base 3. They all co-exist fine. This already happens now. > >> I would suggest as a less stagnating approach to issue a warning/hint >> when a package with no explicit version dependency for base fails to >> build. > > So my plan is to make hackage require an upper bound on the version of > base for all new packages. That should avoid the need to use the > preferences hack the next time around. Hrm. I can see why you might do that, if you keep the old base around. On the other hand, what if base 5 introduces less invasive changes? We have had, for awhile, a number of Haskell packages in Debian that require a version of GHC greater than version x and less than version x+1. This has not worked out entirely well for us. Granted, Cabal is different because GHC 6.10 has two versions of base. But still, I feel queasy about stating that my package won't work with base 5 when I haven't even seen base 5 yet. While we're at it, isn't this a more general problem that could occur elsewhere? Does base really need to be a special case? What if, say, utf8-string, binary, or some other commonly-used package had to break API? > As for what mechanisms we use to persuade package authors to use base 4 > over base 3 for new releases, I'm open to suggestions. Well, I'd say this will be difficult to achieve for at least two years, since GHC 6.8 is in current and future shipping versions of numerous Linux distributions, and such may well be the version of GHC most readily accessible to quite a few users. I am taking the approach of supporting *both*, but that is certainly not the most simple approach (it's not all that complex either, once you know how). -- John From bugfact at gmail.com Sun Feb 1 15:04:23 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sun Feb 1 14:54:49 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkitsdoesn't make any sense In-Reply-To: <2B0BAAB0F63C4536ABACA446E05FA42A@cr3lt> References: <20090127000544.3182da13@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <9810b81b0901301652g325fd30fk38e35451bcacc229@mail.gmail.com> <0E3EF5D5B7EF4243BE09BFF66F2E596A@cr3lt> <2B0BAAB0F63C4536ABACA446E05FA42A@cr3lt> Message-ID: Nice! Well well well, we have exciting times ahead! If this implementation is somewhat stable, I guess we need to put a binding on Hackage :) Of course Microsoft provides the new Direct2D API for something similar, but having a multi platform solution is preferable. I also played a bit with an implementation for rendering conics on the GPU: http://staffwww.itn.liu.se/~stegu/GLSL-conics/ That runs about 100 times faster as software rendered Cairo or GDI+ on my PC. On Sun, Feb 1, 2009 at 6:21 PM, Claus Reinke wrote: > A common standard would be useful, but OpenVG doesn't look >> like "ready soon". On the declarative side, there's also SVG.. >> > > Seems I've got to qualify that remark somewhat - apart from some > commercial/closed-source implementations, there is also a open > source ANSI C one (implemented on top of OpenGL, so it isn't > quite the same as direct OpenGL hardware support, but it offers > the same API and might be a good target for a Haskell binding..): > > > http://ivanleben.blogspot.com/2007/07/shivavg-open-source-ansi-c-openvg.html > > Also, an OpenVG backend for Cairo, which seems to have so many backends > that it might be the safest user-level choice? > > http://lists.cairographics.org/archives/cairo/2008-January/012833.html > http://lists.cairographics.org/archives/cairo/2008-January/012840.html > > Claus > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/b3d6e704/attachment.htm From paul at cogito.org.uk Sun Feb 1 15:24:06 2009 From: paul at cogito.org.uk (Paul Johnson) Date: Sun Feb 1 15:14:26 2009 Subject: [Haskell-cafe] pure crisis :) In-Reply-To: <593855719.20090201221918@gmail.com> References: <593855719.20090201221918@gmail.com> Message-ID: <498604E6.9070202@cogito.org.uk> Bulat Ziganshin wrote: > Hello haskell-cafe, > > pure functional denotation for crisis: > > (_|_) > See also: http://www.haskell.org/haskellwiki/Humor/Enron http://paulspontifications.blogspot.com/2008/09/why-banks-collapsed-and-how-paper-on.html Paul. From antony.courtney at gmail.com Sun Feb 1 17:37:20 2009 From: antony.courtney at gmail.com (Antony Courtney) Date: Sun Feb 1 17:27:32 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <87bptpjn9q.fsf@gaura-nitai.no-ip.org> <2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> Message-ID: <3be64c030902011437g5ad0d730v31fc011b59863335@mail.gmail.com> Hi Conal, On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott wrote: >> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice >> purely functional API. > > Jefferson Heard is working on such a thing, called Hieroglyph. [...] > > In the process, I realized more clearly that the *very goal* of making a > purely functional wrapper around an imperative library leads to muddled > thinking. It's easy to hide the IO without really eliminating it from the > semantics, especially if the goal is defined in terms of an IO-based > library. Much harder, and I think much more rewarding, is to design > semantically, from the ground up, and then figure out how to implement the > elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU > architectures, ...). Exciting! I was very much trying to achieve this with Haven back in 2002: http://www.haskell.org/haven As the slides on that page state pretty explicitly, I tried to focus on the semantics and to design a purely functional representation of a vector graphics scene that was not tied to any particular implementation. My primary claim for success is that the representation of Picture in Haven type checks and doesn't appeal to IO; IO only creeps in when we attempt to render a Picture. Does the Haven API live up to your goal of semantic purity for a vector graphics library? If not, where specifically does it fall short? I look forward to seeing and reading more about Hieroglyph. The typography and visual presentation of Jefferson's online booklet looks fantastic. A high quality, purely functional vector graphics API for Haskell with portable and robust implementations will be a great thing for the Haskell world. Regards, -Antony From duncan.coutts at worc.ox.ac.uk Sun Feb 1 17:44:21 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 17:34:19 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <4985FEE8.2030507@complete.org> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> <1233501595.26754.370.camel@localhost> <4985FEE8.2030507@complete.org> Message-ID: <1233528261.26754.411.camel@localhost> On Sun, 2009-02-01 at 13:58 -0600, John Goerzen wrote: > > So my plan is to make hackage require an upper bound on the version of > > base for all new packages. That should avoid the need to use the > > preferences hack the next time around. > > Hrm. I can see why you might do that, if you keep the old base around. > > On the other hand, what if base 5 introduces less invasive changes? Then it would not be base 5, it would be 4.something. That's the point of the versioning policy. http://haskell.org/haskellwiki/Package_versioning_policy > We have had, for awhile, a number of Haskell packages in Debian that > require a version of GHC greater than version x and less than version > x+1. This has not worked out entirely well for us. Granted, Cabal is > different because GHC 6.10 has two versions of base. > > But still, I feel queasy about stating that my package won't work with > base 5 when I haven't even seen base 5 yet. But it's easy to change it when you do see base 5 but it's annoying for everyone when it fails messily. If you take the conservative approach it's clear to end users and everyone else. We can track the status much more easily. > While we're at it, isn't this a more general problem that could occur > elsewhere? Does base really need to be a special case? What if, say, > utf8-string, binary, or some other commonly-used package had to break API? That is what the package versioning policy is for. Any package can opt-in to following it. In which case other packages that depend on said package can rely on it and use appropriate version constraints. All the core and platform packages follow the versioning policy. The plan is to add tool support to let packages declare that they follow the policy (eg: version-policy: PVP-1) and then we can check that the package really is following the policy and we can also make helpful suggestions to other packages that depend on it (ie tell them what version constraints to use). http://hackage.haskell.org/trac/hackage/ticket/434#comment:1 > > As for what mechanisms we use to persuade package authors to use base 4 > > over base 3 for new releases, I'm open to suggestions. > > Well, I'd say this will be difficult to achieve for at least two years, > since GHC 6.8 is in current and future shipping versions of numerous > Linux distributions, and such may well be the version of GHC most > readily accessible to quite a few users. However I'm not sure that it will be possible for ghc-6.12 to support base 3 4 and 5. Some kinds of changes (especially to types) make supporting multiple versions impossible. > I am taking the approach of supporting *both*, but that is certainly not > the most simple approach (it's not all that complex either, once you > know how). I'm not advocating dropping support for base 3. So I guess I am advocating supporting both. I'm also not sure we need everyone to switch now, but it'll become more important when we get nearer to ghc-6.12 next autumn. Duncan From mle+cl at mega-nerd.com Sun Feb 1 17:49:26 2009 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Sun Feb 1 17:39:42 2009 Subject: [Haskell-cafe] System.Posix.Files.isDirectory and System.Posix.Files.isSymbolicLink Message-ID: <20090202094926.0cd80828.mle+cl@mega-nerd.com> Hi all, The following code creates a symbolic link in the current directory and then uses System.Posix.Files.getFileStatus to get the status of the link. However, isDirectory returns True and isSymbolicLink returns False which is very different from what the stat() system call on a POSIX system would return. I consider this a bug. I'm using ghc-6.8.2. Has this been fixed in a later version? Cheers, Erik module Main where import qualified System.Directory import qualified System.Posix.Files main :: IO () main = do let linkName = "tmp-link" cwd <- System.Directory.getCurrentDirectory System.Posix.Files.createSymbolicLink "/tmp" linkName stat <- System.Posix.Files.getFileStatus linkName if System.Posix.Files.isDirectory stat then putStrLn "Is a directory?????" else putStrLn "Not a directory." if System.Posix.Files.isSymbolicLink stat then putStrLn "Is a symlink" else putStrLn "Not a symlink?????" -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin." - John Von Neumann (1951) From alistair at abayley.org Sun Feb 1 17:49:35 2009 From: alistair at abayley.org (Alistair Bayley) Date: Sun Feb 1 17:39:51 2009 Subject: [Haskell-cafe] Takusen 0.8.3 install problems In-Reply-To: <20090131231851.GI24687@scytale.galois.com> References: <20090131203027.GB24687@scytale.galois.com> <20090131231851.GI24687@scytale.galois.com> Message-ID: <79d7c4980902011449w4adb28a5ie5c37b582447fc9a@mail.gmail.com> >> > You can probably just remove the Setup.lhs and build with defaults >> > (we're doing that at galois, we use Takusen). >> > >> > -- Don I'm surprised this works, unless you also change the imports of Control.Exception to Control.OldException. The new exception module is part of the reason it's taking me a while to port to 6.10.1. Nearly there though; only the haddock failures to fix and then we can release. Alistair From dons at galois.com Sun Feb 1 17:52:25 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 1 17:42:42 2009 Subject: [Haskell-cafe] Takusen 0.8.3 install problems In-Reply-To: <79d7c4980902011449w4adb28a5ie5c37b582447fc9a@mail.gmail.com> References: <20090131203027.GB24687@scytale.galois.com> <20090131231851.GI24687@scytale.galois.com> <79d7c4980902011449w4adb28a5ie5c37b582447fc9a@mail.gmail.com> Message-ID: <20090201225225.GH24687@scytale.galois.com> alistair: > >> > You can probably just remove the Setup.lhs and build with defaults > >> > (we're doing that at galois, we use Takusen). > >> > > >> > -- Don > > I'm surprised this works, unless you also change the imports of > Control.Exception to Control.OldException. The new exception module is > part of the reason it's taking me a while to port to 6.10.1. Nearly > there though; only the haddock failures to fix and then we can > release. build-depends: base < 4 From mle+cl at mega-nerd.com Sun Feb 1 18:01:32 2009 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Sun Feb 1 17:51:47 2009 Subject: [Haskell-cafe] System.Posix.Files.isDirectory and System.Posix.Files.isSymbolicLink In-Reply-To: <20090202094926.0cd80828.mle+cl@mega-nerd.com> References: <20090202094926.0cd80828.mle+cl@mega-nerd.com> Message-ID: <20090202100132.744adca1.mle+cl@mega-nerd.com> Erik de Castro Lopo wrote: > The following code creates a symbolic link in the current directory > and then uses System.Posix.Files.getFileStatus to get the status of > the link. If I use getSymbolicLinkStatus instead of getFileStatus I get the result I expect. However, using getSymbolicLinkStatus instead of getFileStatus is highly counter-intuitive. Furthermore System.Directory.doesDirectoryExist seems to use getFileStatus so that if one tries to walk a directory tree one will also follow symlinks and if those links are circular you get an infinite loop. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- Christianity: The belief that some cosmic Jewish Zombie can make you live forever if you symbolically eat his flesh and telepathically tell him that you accept him as your master, so he can remove an evil force from your soul that is present in humanity because a rib-woman was convinced by a talking snake to eat from a magical tree. -- http://uncyclopedia.org/wiki/Christianity From dougal at dougalstanton.net Sun Feb 1 18:04:20 2009 From: dougal at dougalstanton.net (Dougal Stanton) Date: Sun Feb 1 17:54:34 2009 Subject: [Haskell-cafe] cabal list can't find Glob.cabal file? Message-ID: <2d3641330902011504y29469ee9xcebd4eb009578a00@mail.gmail.com> I get a curious message when trying to run 'cabal list': $ cabal list ....omit some lines... ...................... Latest version available: 0.3 Category: Network Synopsis: Pure bindings for the MaxMind IP database. License: OtherLicense cabal: Couldn't read cabal file "./Glob/0.1/Glob.cabal" Any ideas? As far as Hackage and the local index are concerned, 0.1 isn't even a recent version of Glob. Why should it be looking for the file? cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net From jefferson.r.heard at gmail.com Sun Feb 1 18:10:38 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Sun Feb 1 18:00:51 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <87bptpjn9q.fsf@gaura-nitai.no-ip.org> <2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> Message-ID: <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> Everyone, I'll be releasing Hieroglyph this week. Right now I'm unit testing and I've been out of town this past weekend without much opportunity to work on it. It's not yet a complete functional re-working of Cairo -- for instance, right now patterns aren't supported, and Pango layouts aren't either -- but it should become so. I'll also be forking Hieroglyph to develop a complete, pure-functional 2D graphics toolkit. -- Jeff 2009/1/31 Peter Verswyvelen : > Hi Conal, > Do you have any links to this interesting work of Jefferson Heard? Blogs or > something? I failed to Google it, I mainly found his OpenGL TrueType > bindings on Hackage and his > beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf > Regarding semantics, modern GPUs are able to render 2D graphics (e.g. filled > or stroked curves) as real functions / relations; you don't need fine > tessellation anymore since these computational monsters have become so fast > that per pixel inside / outside testing are feasible now. It's basically a > simple form of real-time ray-tracing :) A quick search revealed another > paper using these > techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf > Cheers, > Peter > 2009/1/31 Conal Elliott >> >> Hi Antony, >> >>> >>> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice >>> purely functional API. >> >> Jefferson Heard is working on such a thing, called Hieroglyph. Lately >> I've been helping him simplify the design and shift it toward a clear, >> composable semantic basis, i.e. "genuinely functional" (as in the Fruit >> paper), meaning that it can be understood & reasoned about in precise terms >> via model that is much simpler than IO. >> >> In the process, I realized more clearly that the *very goal* of making a >> purely functional wrapper around an imperative library leads to muddled >> thinking. It's easy to hide the IO without really eliminating it from the >> semantics, especially if the goal is defined in terms of an IO-based >> library. Much harder, and I think much more rewarding, is to design >> semantically, from the ground up, and then figure out how to implement the >> elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU >> architectures, ...). >> >> Regards, >> >> - Conal >> >> On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney >> wrote: >>> >>> On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan >>> wrote: >>> > On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney >>> > >>> > wrote: >>> >> >>> >> A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or >>> >> GDI+ on Windows ) supports things like computing tight bounding >>> >> rectangles for arbitrary shapes, hit testing for determining whether a >>> >> point is inside or outside a shape and constructive area geometry for >>> >> shape compositing and clipping without dropping down to a raster >>> >> representation. >>> > >>> > These are the kinds of capabilities provided by Cairo, which is very >>> > pleasant to use (PDF-style imaging model) and quite portable. There are >>> > already Cairo bindings provided by gtk2hs, too. >>> > >>> >>> Hi Bryan, >>> >>> Nice to hear from you! Been a while... >>> >>> Just had a quick look and it does indeed appear that Cairo now >>> supports some of the features I mention above (bounds calculations and >>> hit testing). Cairo has clearly come a long way from when I was last >>> working on Fruit and Haven in 2003/2004; back then it looked like it >>> only provided a way to render or rasterize vector graphics on to >>> bitmap surfaces and not much else. >>> >>> It's not clear to me if the Cairo API in its current form supports >>> vector-level clipping or constructive area geometry, and it looks like >>> the API is still pretty render-centric (e.g. is it possible to obtain >>> the vector representation of rendering text in a particular font?). >>> That might make it challenging to use Cairo for something like the >>> Haven API, but maybe one can live without that level of generality. >>> >>> In any case: delighted to see progress on this front! Hopefully some >>> enterprising Haskell hacker will wrap Cairo in a nice purely >>> functional API. >>> >>> -Antony >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From jefferson.r.heard at gmail.com Sun Feb 1 18:12:42 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Sun Feb 1 18:02:55 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <87bptpjn9q.fsf@gaura-nitai.no-ip.org> <2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> Message-ID: <4165d3a70902011512h36026e96h8a7860a06938f2bb@mail.gmail.com> Thanks, Peter, for the paper link... I'll look at this, as it's exactly what it sounds like I want for the future of Hieroglyph... 2009/1/31 Peter Verswyvelen : > Hi Conal, > Do you have any links to this interesting work of Jefferson Heard? Blogs or > something? I failed to Google it, I mainly found his OpenGL TrueType > bindings on Hackage and his > beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf > Regarding semantics, modern GPUs are able to render 2D graphics (e.g. filled > or stroked curves) as real functions / relations; you don't need fine > tessellation anymore since these computational monsters have become so fast > that per pixel inside / outside testing are feasible now. It's basically a > simple form of real-time ray-tracing :) A quick search revealed another > paper using these > techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf > Cheers, > Peter > 2009/1/31 Conal Elliott >> >> Hi Antony, >> >>> >>> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice >>> purely functional API. >> >> Jefferson Heard is working on such a thing, called Hieroglyph. Lately >> I've been helping him simplify the design and shift it toward a clear, >> composable semantic basis, i.e. "genuinely functional" (as in the Fruit >> paper), meaning that it can be understood & reasoned about in precise terms >> via model that is much simpler than IO. >> >> In the process, I realized more clearly that the *very goal* of making a >> purely functional wrapper around an imperative library leads to muddled >> thinking. It's easy to hide the IO without really eliminating it from the >> semantics, especially if the goal is defined in terms of an IO-based >> library. Much harder, and I think much more rewarding, is to design >> semantically, from the ground up, and then figure out how to implement the >> elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU >> architectures, ...). >> >> Regards, >> >> - Conal >> >> On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney >> wrote: >>> >>> On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan >>> wrote: >>> > On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney >>> > >>> > wrote: >>> >> >>> >> A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or >>> >> GDI+ on Windows ) supports things like computing tight bounding >>> >> rectangles for arbitrary shapes, hit testing for determining whether a >>> >> point is inside or outside a shape and constructive area geometry for >>> >> shape compositing and clipping without dropping down to a raster >>> >> representation. >>> > >>> > These are the kinds of capabilities provided by Cairo, which is very >>> > pleasant to use (PDF-style imaging model) and quite portable. There are >>> > already Cairo bindings provided by gtk2hs, too. >>> > >>> >>> Hi Bryan, >>> >>> Nice to hear from you! Been a while... >>> >>> Just had a quick look and it does indeed appear that Cairo now >>> supports some of the features I mention above (bounds calculations and >>> hit testing). Cairo has clearly come a long way from when I was last >>> working on Fruit and Haven in 2003/2004; back then it looked like it >>> only provided a way to render or rasterize vector graphics on to >>> bitmap surfaces and not much else. >>> >>> It's not clear to me if the Cairo API in its current form supports >>> vector-level clipping or constructive area geometry, and it looks like >>> the API is still pretty render-centric (e.g. is it possible to obtain >>> the vector representation of rendering text in a particular font?). >>> That might make it challenging to use Cairo for something like the >>> Haven API, but maybe one can live without that level of generality. >>> >>> In any case: delighted to see progress on this front! Hopefully some >>> enterprising Haskell hacker will wrap Cairo in a nice purely >>> functional API. >>> >>> -Antony >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From jefferson.r.heard at gmail.com Sun Feb 1 18:14:04 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Sun Feb 1 18:04:18 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> References: <20090127000544.3182da13@solaris> <2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> Message-ID: <4165d3a70902011514i108a34fcj14361bcefa1dc3eb@mail.gmail.com> Oh, and by functional, I mean that it isn't a complete re-wrapping of the library, not that you have IO creeping in all over the place. Pardon my unclearness. On Sun, Feb 1, 2009 at 6:10 PM, Jeff Heard wrote: > Everyone, I'll be releasing Hieroglyph this week. Right now I'm unit > testing and I've been out of town this past weekend without much > opportunity to work on it. It's not yet a complete functional > re-working of Cairo -- for instance, right now patterns aren't > supported, and Pango layouts aren't either -- but it should become so. > I'll also be forking Hieroglyph to develop a complete, > pure-functional 2D graphics toolkit. > > -- Jeff > > 2009/1/31 Peter Verswyvelen : >> Hi Conal, >> Do you have any links to this interesting work of Jefferson Heard? Blogs or >> something? I failed to Google it, I mainly found his OpenGL TrueType >> bindings on Hackage and his >> beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf >> Regarding semantics, modern GPUs are able to render 2D graphics (e.g. filled >> or stroked curves) as real functions / relations; you don't need fine >> tessellation anymore since these computational monsters have become so fast >> that per pixel inside / outside testing are feasible now. It's basically a >> simple form of real-time ray-tracing :) A quick search revealed another >> paper using these >> techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf >> Cheers, >> Peter >> 2009/1/31 Conal Elliott >>> >>> Hi Antony, >>> >>>> >>>> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice >>>> purely functional API. >>> >>> Jefferson Heard is working on such a thing, called Hieroglyph. Lately >>> I've been helping him simplify the design and shift it toward a clear, >>> composable semantic basis, i.e. "genuinely functional" (as in the Fruit >>> paper), meaning that it can be understood & reasoned about in precise terms >>> via model that is much simpler than IO. >>> >>> In the process, I realized more clearly that the *very goal* of making a >>> purely functional wrapper around an imperative library leads to muddled >>> thinking. It's easy to hide the IO without really eliminating it from the >>> semantics, especially if the goal is defined in terms of an IO-based >>> library. Much harder, and I think much more rewarding, is to design >>> semantically, from the ground up, and then figure out how to implement the >>> elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU >>> architectures, ...). >>> >>> Regards, >>> >>> - Conal >>> >>> On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney >>> wrote: >>>> >>>> On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan >>>> wrote: >>>> > On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney >>>> > >>>> > wrote: >>>> >> >>>> >> A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or >>>> >> GDI+ on Windows ) supports things like computing tight bounding >>>> >> rectangles for arbitrary shapes, hit testing for determining whether a >>>> >> point is inside or outside a shape and constructive area geometry for >>>> >> shape compositing and clipping without dropping down to a raster >>>> >> representation. >>>> > >>>> > These are the kinds of capabilities provided by Cairo, which is very >>>> > pleasant to use (PDF-style imaging model) and quite portable. There are >>>> > already Cairo bindings provided by gtk2hs, too. >>>> > >>>> >>>> Hi Bryan, >>>> >>>> Nice to hear from you! Been a while... >>>> >>>> Just had a quick look and it does indeed appear that Cairo now >>>> supports some of the features I mention above (bounds calculations and >>>> hit testing). Cairo has clearly come a long way from when I was last >>>> working on Fruit and Haven in 2003/2004; back then it looked like it >>>> only provided a way to render or rasterize vector graphics on to >>>> bitmap surfaces and not much else. >>>> >>>> It's not clear to me if the Cairo API in its current form supports >>>> vector-level clipping or constructive area geometry, and it looks like >>>> the API is still pretty render-centric (e.g. is it possible to obtain >>>> the vector representation of rendering text in a particular font?). >>>> That might make it challenging to use Cairo for something like the >>>> Haven API, but maybe one can live without that level of generality. >>>> >>>> In any case: delighted to see progress on this front! Hopefully some >>>> enterprising Haskell hacker will wrap Cairo in a nice purely >>>> functional API. >>>> >>>> -Antony >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > From bugfact at gmail.com Sun Feb 1 18:30:52 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Sun Feb 1 18:21:07 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> References: <20090127000544.3182da13@solaris> <2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> Message-ID: Cool! Looking forward to it. On Mon, Feb 2, 2009 at 12:10 AM, Jeff Heard wrote: > Everyone, I'll be releasing Hieroglyph this week. Right now I'm unit > testing and I've been out of town this past weekend without much > opportunity to work on it. It's not yet a complete functional > re-working of Cairo -- for instance, right now patterns aren't > supported, and Pango layouts aren't either -- but it should become so. > I'll also be forking Hieroglyph to develop a complete, > pure-functional 2D graphics toolkit. > > -- Jeff > > 2009/1/31 Peter Verswyvelen : > > Hi Conal, > > Do you have any links to this interesting work of Jefferson Heard? Blogs > or > > something? I failed to Google it, I mainly found his OpenGL TrueType > > bindings on Hackage and his > > beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf > > Regarding semantics, modern GPUs are able to render 2D graphics (e.g. > filled > > or stroked curves) as real functions / relations; you don't need fine > > tessellation anymore since these computational monsters have become so > fast > > that per pixel inside / outside testing are feasible now. It's basically > a > > simple form of real-time ray-tracing :) A quick search revealed another > > paper using these > > techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf > > Cheers, > > Peter > > 2009/1/31 Conal Elliott > >> > >> Hi Antony, > >> > >>> > >>> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice > >>> purely functional API. > >> > >> Jefferson Heard is working on such a thing, called Hieroglyph. Lately > >> I've been helping him simplify the design and shift it toward a clear, > >> composable semantic basis, i.e. "genuinely functional" (as in the Fruit > >> paper), meaning that it can be understood & reasoned about in precise > terms > >> via model that is much simpler than IO. > >> > >> In the process, I realized more clearly that the *very goal* of making a > >> purely functional wrapper around an imperative library leads to muddled > >> thinking. It's easy to hide the IO without really eliminating it from > the > >> semantics, especially if the goal is defined in terms of an IO-based > >> library. Much harder, and I think much more rewarding, is to design > >> semantically, from the ground up, and then figure out how to implement > the > >> elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU > >> architectures, ...). > >> > >> Regards, > >> > >> - Conal > >> > >> On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney > >> wrote: > >>> > >>> On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan > >>> wrote: > >>> > On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney > >>> > > >>> > wrote: > >>> >> > >>> >> A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or > >>> >> GDI+ on Windows ) supports things like computing tight bounding > >>> >> rectangles for arbitrary shapes, hit testing for determining whether > a > >>> >> point is inside or outside a shape and constructive area geometry > for > >>> >> shape compositing and clipping without dropping down to a raster > >>> >> representation. > >>> > > >>> > These are the kinds of capabilities provided by Cairo, which is very > >>> > pleasant to use (PDF-style imaging model) and quite portable. There > are > >>> > already Cairo bindings provided by gtk2hs, too. > >>> > > >>> > >>> Hi Bryan, > >>> > >>> Nice to hear from you! Been a while... > >>> > >>> Just had a quick look and it does indeed appear that Cairo now > >>> supports some of the features I mention above (bounds calculations and > >>> hit testing). Cairo has clearly come a long way from when I was last > >>> working on Fruit and Haven in 2003/2004; back then it looked like it > >>> only provided a way to render or rasterize vector graphics on to > >>> bitmap surfaces and not much else. > >>> > >>> It's not clear to me if the Cairo API in its current form supports > >>> vector-level clipping or constructive area geometry, and it looks like > >>> the API is still pretty render-centric (e.g. is it possible to obtain > >>> the vector representation of rendering text in a particular font?). > >>> That might make it challenging to use Cairo for something like the > >>> Haven API, but maybe one can live without that level of generality. > >>> > >>> In any case: delighted to see progress on this front! Hopefully some > >>> enterprising Haskell hacker will wrap Cairo in a nice purely > >>> functional API. > >>> > >>> -Antony > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe@haskell.org > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe@haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/ca2ca22d/attachment.htm From briqueabraque at yahoo.com Sun Feb 1 18:50:56 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Sun Feb 1 18:41:26 2009 Subject: [Haskell-cafe] Re: Complex C99 type in Foreign In-Reply-To: <20090201185747.GW24687@scytale.galois.com> References: <20090201185747.GW24687@scytale.galois.com> Message-ID: >> Are there plans to include C99 'complex' type >> in Foreign, maybe as CFloatComplex, CDoubleComplex >> and CLongDoubleComplex? This seems an easy addition >> to the standard and would allow binding of a few >> interesting libraries, like GSL. > > A separate library for new types to add to Foreign would be the easiest > way forward. Just put the foreign-c99 package on Hackage? As far as I know, this is not possible. (I tried for a long time to do that, actually, until I reallized it could not be done.) If it's not true, i.e., I could actually have some arbitrary sized parameter as argument to a function or as a return value (and not its pointer), what did I saw wrong? I understand only Foreign.C.C* types or forall a. => Foreign.Ptr.Ptr a can be used like that. Maur?cio From dons at galois.com Sun Feb 1 18:54:00 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 1 18:44:10 2009 Subject: [Haskell-cafe] Re: Complex C99 type in Foreign In-Reply-To: References: <20090201185747.GW24687@scytale.galois.com> Message-ID: <20090201235400.GL24687@scytale.galois.com> briqueabraque: > >>Are there plans to include C99 'complex' type > >>in Foreign, maybe as CFloatComplex, CDoubleComplex > >>and CLongDoubleComplex? This seems an easy addition > >>to the standard and would allow binding of a few > >>interesting libraries, like GSL. > > > >A separate library for new types to add to Foreign would be the easiest > >way forward. Just put the foreign-c99 package on Hackage? > > As far as I know, this is not possible. (I tried for > a long time to do that, actually, until I reallized > it could not be done.) > > If it's not true, i.e., I could actually have some > arbitrary sized parameter as argument to a function > or as a return value (and not its pointer), what > did I saw wrong? I understand only Foreign.C.C* > types or forall a. => Foreign.Ptr.Ptr a can be used > like that. Oh, you mean you need to teach the compiler about unboxed complex types? -- Don From duncan.coutts at worc.ox.ac.uk Sun Feb 1 19:01:49 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 18:51:48 2009 Subject: [Haskell-cafe] cabal list can't find Glob.cabal file? In-Reply-To: <2d3641330902011504y29469ee9xcebd4eb009578a00@mail.gmail.com> References: <2d3641330902011504y29469ee9xcebd4eb009578a00@mail.gmail.com> Message-ID: <1233532909.26754.420.camel@localhost> On Sun, 2009-02-01 at 23:04 +0000, Dougal Stanton wrote: > I get a curious message when trying to run 'cabal list': > > $ cabal list > > ....omit some lines... > ...................... > Latest version available: 0.3 > Category: Network > Synopsis: Pure bindings for the MaxMind IP database. > License: OtherLicense > > cabal: Couldn't read cabal file "./Glob/0.1/Glob.cabal" Cabal-1.4 cannot read some .cabal files that use new syntactic constructs added in Cabal-1.6. The cabal-install program does not handle this fact very gracefully. > Any ideas? As far as Hackage and the local index are concerned, 0.1 > isn't even a recent version of Glob. Why should it be looking for the > file? It's a good point, it should not need to parse the .cabal file of the older version. However that's just a performance thing, the newer versions will have the same issue. > cabal-install version 0.5.1 > using version 1.4.0.1 of the Cabal library The solution is to upgrade: $ cabal install cabal-install $ cabal --version cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library Duncan From duncan.coutts at worc.ox.ac.uk Sun Feb 1 19:05:08 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 18:55:05 2009 Subject: [Haskell-cafe] System.Posix.Files.isDirectory and System.Posix.Files.isSymbolicLink In-Reply-To: <20090202094926.0cd80828.mle+cl@mega-nerd.com> References: <20090202094926.0cd80828.mle+cl@mega-nerd.com> Message-ID: <1233533108.26754.424.camel@localhost> On Mon, 2009-02-02 at 09:49 +1100, Erik de Castro Lopo wrote: > Hi all, > > The following code creates a symbolic link in the current directory > and then uses System.Posix.Files.getFileStatus to get the status of > the link. > > However, isDirectory returns True and isSymbolicLink returns False > which is very different from what the stat() system call on a POSIX > system would return. I consider this a bug. No, it is the correct POSIX behaviour. You are thinking of lstat() which is what getSymbolicLinkStatus uses. The getFileStatus function calls stat(). The documentation makes this clear: http://www.haskell.org/ghc/docs/latest/html/libraries/unix/System-Posix-Files.html#5 getFileStatus :: FilePath -> IO FileStatus getFileStatus path calls gets the FileStatus information (user ID, size, access times, etc.) for the file path. Note: calls stat. getSymbolicLinkStatus :: FilePath -> IO FileStatus Acts as getFileStatus except when the FilePath refers to a symbolic link. In that case the FileStatus information of the symbolic link itself is returned instead of that of the file it points to. Note: calls lstat. Duncan From duncan.coutts at worc.ox.ac.uk Sun Feb 1 19:07:02 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 18:56:59 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <694519c50902011043t379ff90ew90c233d8a13145f3@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> <694519c50902011043t379ff90ew90c233d8a13145f3@mail.gmail.com> Message-ID: <1233533222.26754.426.camel@localhost> [re-sending the cc to -cafe as I sent from the wrong address the first time] On Sun, 2009-02-01 at 12:43 -0600, Antoine Latter wrote: > After a bit of digging, I saw this snippet in the .cabal file for the > iconv package on hackage: > > >>>>> > -- We need to compile via C because on some platforms (notably darwin) > -- iconv is a macro rather than real C function. doh! > ghc-options: -fvia-C -Wall > <<<<< > > But it looks like the 'iconv' package is broken in the exact same way > for me - I get the same crazy linker errors. Yes, the workaround of using -fvia-C stopped working in ghc-6.10. I will have to adapt the iconv package to use a C wrapper. Someone said that it is just the macports version of iconv that has this problem but I don't understand that at all. If we're using default ghc/gcc then we should not be looking in any non-standard include directories at all. The other thing that makes no sense is that the /usr/lib/libiconv.dywhatever file apparently contains both _iconv_open and _libiconv_open so why can't we link to the ordinary _iconv_open one? Duncan From s.clover at gmail.com Sun Feb 1 19:22:01 2009 From: s.clover at gmail.com (Sterling Clover) Date: Sun Feb 1 19:12:17 2009 Subject: [Haskell-cafe] Network.UrlDisp In-Reply-To: References: Message-ID: <784F94AD-DE51-4D46-90EC-36791848DC51@gmail.com> I'm not working on hvac at the moment, but the UrlDisp code was split out of it by Artyom Shalkhakov. So some of the old example code from hvac should still be of interest. The following, for example, was an implementation of a threaded message board: http://code.haskell.org/~sclv/hvac/Examples/hvac-board.hs Note that this code uses the infix combinators. After a chorus of "it's worse than perl!" went up, standard message dispatch combinators were added as well. I explained briefly how they worked here: http://fmapfixreturn.wordpress.com/2008/05/21/some-concepts-behind- hvac/#comment-94 The validation stuff used both in the code example and the blog post is not part of UrlDisp, by the way. Cheers, S. On Feb 1, 2009, at 2:46 PM, Pieter Laeremans wrote: > Hello, > > Has anyone some exampe usages of : Network.UrlDisp ? > > thanks in advance, > > Pieter > > -- > Pieter Laeremans > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From stephen.tetley at gmail.com Sun Feb 1 19:32:46 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sun Feb 1 19:23:00 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> Message-ID: <5fdc56d70902011632s6322eceeg7d31ec3de7d85963@mail.gmail.com> Hello I've written a Haskell binding to the Shiva-VG OpenVG implementation. Hopefully it should appear on Hackage in the next couple of days - but for the moment it is available here: http://slackwise.org/spt/files/OpenVG-0.1.tar.gz I've tested it on MacOSX leopard and Windows with MinGW / MSys, if anyone could check it on Linux that would be handy. Thanks. Best regards Stephen From mle+cl at mega-nerd.com Sun Feb 1 19:56:08 2009 From: mle+cl at mega-nerd.com (Erik de Castro Lopo) Date: Sun Feb 1 19:46:24 2009 Subject: [Haskell-cafe] System.Posix.Files.isDirectory and System.Posix.Files.isSymbolicLink In-Reply-To: <1233533108.26754.424.camel@localhost> References: <20090202094926.0cd80828.mle+cl@mega-nerd.com> <1233533108.26754.424.camel@localhost> Message-ID: <20090202115608.ac2bae02.mle+cl@mega-nerd.com> Duncan Coutts wrote: > No, it is the correct POSIX behaviour. You are thinking of lstat() which > is what getSymbolicLinkStatus uses. The getFileStatus function calls > stat(). Maybe this is a naming issue. In C I think of "lstat" as "stat" but don't follow link. If getSymbolicLinkStatus was instead called getFileStatusNoFollowLink I think there would be less chance of confusion. Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "I once worked for a company where as part of the BS5750 "Quality" process I attended a meeting where I was informed that it was Company Policy not to use free software. When I asked him for his written authorisation for me to remove X Windows from our Sun workstations, he backtracked." -- Phil Hunt From judah.jacobson at gmail.com Sun Feb 1 20:10:48 2009 From: judah.jacobson at gmail.com (Judah Jacobson) Date: Sun Feb 1 20:01:01 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <1233533222.26754.426.camel@localhost> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> <694519c50902011043t379ff90ew90c233d8a13145f3@mail.gmail.com> <1233533222.26754.426.camel@localhost> Message-ID: <6d74b0d20902011710k50306a0bn374e598a139a02a1@mail.gmail.com> On Sun, Feb 1, 2009 at 4:07 PM, Duncan Coutts wrote: > [re-sending the cc to -cafe as I sent from the wrong address the first time] > > On Sun, 2009-02-01 at 12:43 -0600, Antoine Latter wrote: > >> After a bit of digging, I saw this snippet in the .cabal file for the >> iconv package on hackage: >> >> >>>>> >> -- We need to compile via C because on some platforms (notably darwin) >> -- iconv is a macro rather than real C function. doh! >> ghc-options: -fvia-C -Wall >> <<<<< >> >> But it looks like the 'iconv' package is broken in the exact same way >> for me - I get the same crazy linker errors. > > Yes, the workaround of using -fvia-C stopped working in ghc-6.10. I will > have to adapt the iconv package to use a C wrapper. > > Someone said that it is just the macports version of iconv that has this > problem but I don't understand that at all. If we're using default > ghc/gcc then we should not be looking in any non-standard include > directories at all. The pcre library isn't installed by default, so an OS X users might get it from MacPorts (which installs it in /opt/local/lib). And when building the Haskell pcre-light package, they'd do something like cabal install pcre-light --extra-lib-dirs=/opt/local/lib But then any other package that depends on pcre-light will also get the same linker option. > The other thing that makes no sense is that > the /usr/lib/libiconv.dywhatever file apparently contains both > _iconv_open and _libiconv_open so why can't we link to the ordinary > _iconv_open one? The problem is that with -L/opt/local/lib (which is now passed to any package depending on pcre-light), the linker uses /opt/local/lib/libiconv.* and ignores /usr/lib/libiconv.* altogether. Hope that helps explain it better, -Judah From bjpop at csse.unimelb.edu.au Sun Feb 1 20:26:34 2009 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Sun Feb 1 20:17:02 2009 Subject: [Haskell-cafe] Question re: denotational semantics in SPJ's "Implementation of FPLs" book In-Reply-To: <20090201094905.GA6361@twifkak.com> References: <20090201094905.GA6361@twifkak.com> Message-ID: <1AE773E1-9295-48C6-AAFC-419CC17C2D8B@csse.unimelb.edu.au> On 01/02/2009, at 8:49 PM, Devin Mullins wrote: > I'm reading SPJ's "The Implementation of Functional Programming > Languages," and > on page 32, it defines the multiplication operator in its extended > lambda > calculus as: > Eval[[ * ]] a b = a x b > Eval[[ * ]] _|_ b = _|_ > Eval[[ * ]] a _|_ = _|_ > > Is that complete? What are the denotational semantics of * applied > to things > not in the domain of the multiplication operator x, such as TRUE (in > the > extended lambda defined by this book) and functions (in normal > lambda calc)? Do > these things just eval to bottom? Or is this just to be ignored, > since the > extended calculus will only be applied to properly "typed" > expressions in the > context of this book? Hi Devin, I don't think that the section of the book in question is intended to be rigorous. (page 30. "this account is greatly simplified"). As noted in the text, the domain of values produced by Eval is not specified, so it is hard to be precise (though there is a reference to Scott's Domain Theory). However, I agree with you that the equation for multiplication looks under-specified. Obviously any reasonable domain will include (non- bottom) values on which multiplication is not defined. Without any explicit quantification, it is hard to say what values 'a' and 'b' range over. It is possible that they range over the entire domain, or some proper subset. The text also assumes we all agree on the definition of the 'x' (multiplication) function. Though it ought to be specified in a more rigorous exposition. As you suggest, it may be possible to work around this by imposing some kind of typing restriction to the language, though this does not appear to be stated in this particular section of the book. Perhaps this is mentioned elsewhere; I have not checked. Another possible solution is to sweep it all into the definition of the 'x' function. But if that were so, why bother handling bottom explicitly, but not the other possible cases? I guess the best we can say is that the meaning of multiplication applied to non-bottom non-numeric arguments is not defined (in this section of the text). Cheers, Bernie. From briqueabraque at yahoo.com Sun Feb 1 20:32:19 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Sun Feb 1 20:22:43 2009 Subject: [Haskell-cafe] Re: Complex C99 type in Foreign In-Reply-To: <20090201235400.GL24687@scytale.galois.com> References: <20090201185747.GW24687@scytale.galois.com> <20090201235400.GL24687@scytale.galois.com> Message-ID: >>>> Are there plans to include C99 'complex' type >>>> in Foreign, maybe as CFloatComplex, CDoubleComplex >>>> and CLongDoubleComplex? (...) >>> A separate library for new types to add to Foreign would be the easiest >>> way forward. (...) >> If it's not true, i.e., I could actually have some >> arbitrary sized parameter as argument to a function >> or as a return value (and not its pointer), what >> did I saw wrong? (...) > Oh, you mean you need to teach the compiler about > unboxed complex types? I think so. Take this, for instance: #include double complex ccos(double complex z); float complex ccosf(float complex z); long double complex ccosl(long double complex z); To bind to ccos* functions I believe I would need a native CComplex. The GSL numeric library also makes use of something like that, although it defines its own 'complex' structure. I'm writing a binding to the standard C library, and at the same time collecting a list of standard types that could be usefull in Foreign. I'm thinking about writing a ticket to ask for inclusion of a few of them. 'int32_t' and 'int64_t' as, say, CInt32 and CInt64 could be nice for portability. Maur?cio From conal at conal.net Sun Feb 1 20:36:01 2009 From: conal at conal.net (Conal Elliott) Date: Sun Feb 1 20:26:13 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <3be64c030902011437g5ad0d730v31fc011b59863335@mail.gmail.com> References: <20090127000544.3182da13@solaris> <87bptpjn9q.fsf@gaura-nitai.no-ip.org> <2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <3be64c030902011437g5ad0d730v31fc011b59863335@mail.gmail.com> Message-ID: Hi Antony, My primary claim for success is that the > representation of Picture in Haven type checks and doesn't appeal to > IO; IO only creeps in when we attempt to render a Picture. You did something much more meaningful to me that what you say here. It is easy to define a type that satisfies these conditions but is as semantically intractable as IO. As an absurd demonstration, clone some large chunk of the current set of IO primitive interfaces (return, (>>=), getChar, forkIO, various FFI-imported things, ...) into a GADT called NotIO. Then write a 'render :: NotIO a -> IO a' that interprets NotIO as IO. One could call NotIO a "purely functional wrapper". Or we could just use IO itself. In the words of Lewis Carroll: > "That's another thing we've learned from your Nation," said Mein Herr, > "map-making. But we've carried it much further than you. What do you > consider the largest map that would be really useful?" > > *"About six inches to the mile."* > > "Only six inches!"exclaimed Mein Herr. "We very soon got to six yards to > the mile. Then we tried a hundred yards to the mile. And then came the > grandest idea of all! We actually made a map of the country, on the scale of > a mile to the mile!" > > *"Have you used it much?" I enquired.* > > "It has never been spread out, yet," said Mein Herr: "the farmers objected: > they said it would cover the whole country, and shut out the sunlight! So we > now use the country itself, as its own map, and I assure you it does nearly > as well. > While my example and Lewis Carroll's are intentionally absurd, I'm concerned that "purely functional wrappers" can be just as meaningless but less aparently so. I think what you did in Haven (based on memories of our conversations at the time and looking at your slides just now) is substantively different. You gave precise, complete, and tractably simple *denotation* to your types. Complete enough to define the correctness of the rendering process. Does the Haven API live up to your goal of semantic purity for a > vector graphics library? If not, where specifically does it fall short? > Yes, if my understanding about denotational precision and completeness is correct. Is it? Regards, - Conal On Sun, Feb 1, 2009 at 2:37 PM, Antony Courtney wrote: > Hi Conal, > > On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott wrote: > >> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice > >> purely functional API. > > > > Jefferson Heard is working on such a thing, called Hieroglyph. [...] > > > > In the process, I realized more clearly that the *very goal* of making a > > purely functional wrapper around an imperative library leads to muddled > > thinking. It's easy to hide the IO without really eliminating it from > the > > semantics, especially if the goal is defined in terms of an IO-based > > library. Much harder, and I think much more rewarding, is to design > > semantically, from the ground up, and then figure out how to implement > the > > elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU > > architectures, ...). > > Exciting! > > I was very much trying to achieve this with Haven back in 2002: > > http://www.haskell.org/haven > > As the slides on that page state pretty explicitly, I tried to focus > on the semantics and to design a purely functional representation of a > vector graphics scene that was not tied to any particular > implementation. My primary claim for success is that the > representation of Picture in Haven type checks and doesn't appeal to > IO; IO only creeps in when we attempt to render a Picture. > > Does the Haven API live up to your goal of semantic purity for a > vector graphics library? If not, where specifically does it fall > short? > > I look forward to seeing and reading more about Hieroglyph. The > typography and visual presentation of Jefferson's online booklet looks > fantastic. A high quality, purely functional vector graphics API for > Haskell with portable and robust implementations will be a great thing > for the Haskell world. > > Regards, > > -Antony > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/71e00d29/attachment.htm From j.vimal at gmail.com Sun Feb 1 21:07:55 2009 From: j.vimal at gmail.com (Vimal) Date: Sun Feb 1 20:58:08 2009 Subject: [Haskell-cafe] UDP In-Reply-To: <4984C720.3080802@btinternet.com> References: <497C91D1.4050102@btinternet.com> <4984C720.3080802@btinternet.com> Message-ID: 2009/2/1 Andrew Coppin : > > Yeah, I just assumed that the bind step was only necessary for > connection-oriented protocols. (Interestingly enough, the matching "send" > program doesn't bind at all, yet seems to work fine...) > socket() system call creates a socket (a descriptor) that you can identify. bind() creates an identity for the socket so that applications outside can refer to it (using ip:port); it also enables the kernel to pass the received data to your application. sendto() doesn't require that identity. -- Vimal From duncan.coutts at worc.ox.ac.uk Sun Feb 1 21:16:08 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 1 21:06:06 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <6d74b0d20902011710k50306a0bn374e598a139a02a1@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> <694519c50902011043t379ff90ew90c233d8a13145f3@mail.gmail.com> <1233533222.26754.426.camel@localhost> <6d74b0d20902011710k50306a0bn374e598a139a02a1@mail.gmail.com> Message-ID: <1233540968.26754.468.camel@localhost> On Sun, 2009-02-01 at 17:10 -0800, Judah Jacobson wrote: > > Someone said that it is just the macports version of iconv that has this > > problem but I don't understand that at all. If we're using default > > ghc/gcc then we should not be looking in any non-standard include > > directories at all. > > The pcre library isn't installed by default, so an OS X users might > get it from MacPorts (which installs it in /opt/local/lib). And when > building the Haskell pcre-light package, they'd do something like > > cabal install pcre-light --extra-lib-dirs=/opt/local/lib > > But then any other package that depends on pcre-light will also get > the same linker option. Yes. Sigh. A limitation of the C linker search path model. > > The other thing that makes no sense is that > > the /usr/lib/libiconv.dywhatever file apparently contains both > > _iconv_open and _libiconv_open so why can't we link to the ordinary > > _iconv_open one? > > The problem is that with -L/opt/local/lib (which is now passed to any > package depending on pcre-light), the linker uses > /opt/local/lib/libiconv.* and ignores /usr/lib/libiconv.* altogether. > > Hope that helps explain it better, Yes, thanks. I wonder if it wouldn't be better to search the standard lib dirs first. I'm sure the whole issue is a can of worms. Duncan From antony.courtney at gmail.com Sun Feb 1 21:58:32 2009 From: antony.courtney at gmail.com (Antony Courtney) Date: Sun Feb 1 21:48:45 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <2518b95d0901292321i444fabb7m854304c35bfcbc6@mail.gmail.com> <3be64c030901300851maff3882y211908f3193b5c7a@mail.gmail.com> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <3be64c030902011437g5ad0d730v31fc011b59863335@mail.gmail.com> Message-ID: <3be64c030902011858t7c8af2ablbc4efd0902c8b008@mail.gmail.com> >> My primary claim for success is that the >> representation of Picture in Haven type checks and doesn't appeal to >> IO; IO only creeps in when we attempt to render a Picture. > > You did something much more meaningful to me that what you say here. > Thanks. ;-) > [...] > > I think what you did in Haven (based on memories of our conversations at the > time and looking at your slides just now) is substantively different. You > gave precise, complete, and tractably simple *denotation* to your types. > Complete enough to define the correctness of the rendering process. > >> Does the Haven API live up to your goal of semantic purity for a >> vector graphics library? If not, where specifically does it fall short? > > Yes, if my understanding about denotational precision and completeness is > correct. Is it? > Yes and no. "Yes" in the sense that every type in Haven had a simple definition using Haskell's type system and I used these types to specify signatures of a set of functions for 2D geometry that was relatively complete. "No" in the sense that I never bothered to implement the various geometric functions directly in Haskell; I depended on the underlying implementation to do so. For simple things like points, lines and affine transforms I don't think this should be too controversial, but it's a bit less clear for clipping and constructive area geometry on complicated Bezier paths. From a library user's point of view there isn't much distinction between what I did and a pure implementation, but I can't really claim it's a rigorous or complete semantics without a pure reference implementation, and there's obviously no way to prove claims such as "Shapes form a monoid" without giving a direct definition of the composition and clipping operators. -Antony From wasserman.louis at gmail.com Sun Feb 1 22:06:19 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Sun Feb 1 21:56:31 2009 Subject: [Haskell-cafe] Newtype deriving with functional dependencies Message-ID: Is there any sensible way to make newtype FooT m e = FooT (StateT Bar m e) deriving (MonadState) work to give instance MonadState Bar (FooT m e)? That is, I'm asking if there would be a semantically sensible way of modifying GeneralizedNewtypeDeriving to handle multi-parameter type classes when there is a functional dependency involved, assuming by default that the newtype is the more general of the types, perhaps? Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090201/fce8fce1/attachment.htm From kamysh at kamysh.org Sun Feb 1 22:10:11 2009 From: kamysh at kamysh.org (Valentyn Kamyshenko) Date: Sun Feb 1 22:00:38 2009 Subject: [Haskell-cafe] circular dependencies in cabal In-Reply-To: <1233500011.26754.346.camel@localhost> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> Message-ID: <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> So, in practical terms, you suggest that no new version of the package that ghc package depends on (directly or indirectly) should ever be installed? For example, as soon as process-1.0.1.1 is installed on my computer, I'll have this problem with every package that depends on "process"? Another question: would not cabal-install automatically fetch the most recent version of the "process" package, as soon as I will try to install a package that depends on it (such as, for example, "plugins")? -- Valentyn. On Feb 1, 2009, at 6:53 AM, Duncan Coutts wrote: > On Sun, 2009-02-01 at 01:33 -0800, Valentyn Kamyshenko wrote: >> Hello all, >> >> when I tried to install plugins package with cabal, I've got the >> following error: >> >> # sudo cabal install plugins --global >> Resolving dependencies... >> cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 >> however >> process-1.0.1.1 was excluded because ghc-6.10.1 requires process >> ==1.0.1.0 > > For the most part I refer you to: > > http://haskell.org/pipermail/haskell-cafe/2009-January/054523.html > > However the difference is that you've got this problem only within the > global package db rather than due to overlap in the global and user > package db. > >> It looks like both versions of process package are currently >> required: > > It looks like you installed process-1.0.1.1 and then rebuilt almost > every other package against it. Of course you cannot rebuild the ghc > package but you did rebuild some of its dependencies which is why it > now > depends on multiple versions of the process package. > > Generally rebuilding a package without also rebuilding the packages > that > depend on it is a bit dodgy (it can lead to linker errors or > segfaults). > Unfortunately cabal-install does not prevent you from shooting > yourself > in the foot in these circumstances. > >> Any suggestions? > > Aim for a situation where you only have one version of the various > core > packages. If you do not need to install packages globally then > installing them per-user means you at least cannot break the global > packages. > > Duncan > From dgorin at dc.uba.ar Sun Feb 1 22:59:11 2009 From: dgorin at dc.uba.ar (=?ISO-8859-1?Q?Daniel_Gor=EDn?=) Date: Sun Feb 1 22:49:32 2009 Subject: [Haskell-cafe] Newtype deriving with functional dependencies In-Reply-To: References: Message-ID: <7E1B23F2-766D-4613-A1DF-AE737D9C3199@dc.uba.ar> On Feb 2, 2009, at 1:06 AM, Louis Wasserman wrote: > Is there any sensible way to make > > newtype FooT m e = FooT (StateT Bar m e) deriving (MonadState) > > work to give instance MonadState Bar (FooT m e)? > > That is, I'm asking if there would be a semantically sensible way of > modifying GeneralizedNewtypeDeriving to handle multi-parameter type > classes when there is a functional dependency involved, assuming by > default that the newtype is the more general of the types, perhaps? > > Louis Wasserman > wasserman.louis@gmail.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe did you try this? newtype FooT m e = FooT (StateT Bar m e) deriving (Monad, MonadState Bar) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/f5d1a530/attachment.htm From jefferson.r.heard at gmail.com Sun Feb 1 23:13:26 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Sun Feb 1 23:03:39 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <5fdc56d70902011632s6322eceeg7d31ec3de7d85963@mail.gmail.com> References: <20090127000544.3182da13@solaris> <20090130215046.568edcc0@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> <5fdc56d70902011632s6322eceeg7d31ec3de7d85963@mail.gmail.com> Message-ID: <4165d3a70902012013r380a49edy48abb26fc1b8d8ac@mail.gmail.com> I will happily check it on Linux. I'm only vaguely familiar with OpenVG... In theory it's a good API, and would support exactly what I'd need for a backend to Hieroglyph that isn't Cairo based, but we'd still need a good image API and probably to bind to Pango to get text and layout support. For Image APIs, by the way, I suggest that someone, maybe me, but someone, look at the VIPS toolkit, as it's probably already the most Haskell-like toolkit, as it's lazy and concurrent all the way down past the C layer and supports fully composable operators. The authors haven't formalized it as far as functional programming goes, but it was definitely in the back of their brains when they were coming up with it. The other advantage is that the V stands for Very Large. VIPS can handle images of unlimited size. -- Jeff On Sun, Feb 1, 2009 at 7:32 PM, Stephen Tetley wrote: > Hello > > I've written a Haskell binding to the Shiva-VG OpenVG implementation. > > Hopefully it should appear on Hackage in the next couple of days - but > for the moment it is available here: > > > http://slackwise.org/spt/files/OpenVG-0.1.tar.gz > > I've tested it on MacOSX leopard and Windows with MinGW / MSys, if > anyone could check it on Linux that would be handy. > Thanks. > > > Best regards > > Stephen > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ramsdell0 at gmail.com Sun Feb 1 23:26:12 2009 From: ramsdell0 at gmail.com (John D. Ramsdell) Date: Sun Feb 1 23:16:24 2009 Subject: [Haskell-cafe] Parallel term reduction Message-ID: <7687290b0902012026s2a2e0619tecc227d33ec56afc@mail.gmail.com> I have a reduction system in which a rule takes a term and returns a set of terms. The reduction system creates a tree that originates at a starting value called the root. For most problems, the reduction system terminates, but a step count limit protects from non-termination. Rule application is expensive, so it is essential that a rule is never applied to the same problem twice. This check makes my program sequential, in that parallel annotations don't improve performance on SMPs. There isn't even an obvious place to add them in my program, at least not to me. How do people write parallel reduction systems that avoid redundant rule application? John > module Main (main) where > import System.Time (ClockTime(..), getClockTime > data Eq a => Item a > = Item { item :: a, > parent :: Maybe (Item a) } > instance Eq a => Eq (Item a) where > x == y = item x == item y The reduction system takes a rule, a step count, and an initial value, and computes a tree of reductions. The order of the items in the returned list is irrelevant, because the tree is assembled as a post processing step. > reduce :: (Eq a, Monad m) => (a -> [a]) -> Int -> a -> m [Item a] > reduce rule limit root = > step rule limit [top] [top] > where > top = Item { item = root, parent = Nothing } step rule limit seen todo, where seen in the items already seen, and todo is the items on the queue. > step :: (Eq a, Monad m) => (a -> [a]) -> Int -> > [Item a] -> [Item a] -> m [Item a] > step _ limit _ _ > | limit <= 0 = fail "Step limit exceeded" > step _ _ seen [] = return seen > step rule limit seen (next : rest) = > loop seen rest children > where > children = map child (rule (item next)) > child i = Item { item = i, parent = Just next } > loop seen rest [] = > step rule (limit - 1) seen rest > loop seen rest (kid : kids) = > if elem kid seen then > loop seen rest kids > else > loop (kid : seen) (rest ++ [kid]) kids A silly rule > rule :: Int -> [Int] > rule n = filter (>= 0) [n - 1, n - 2, n - 3] > secDiff :: ClockTime -> ClockTime -> Float > secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) > = fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1) > main :: IO () > main = > do > t0 <- getClockTime > ns <- reduce rule 20000 5000 > t1 <- getClockTime > putStrLn $ "length: " ++ show (length ns) > putStrLn $ "time: " ++ show (secDiff t0 t1) ++ " seconds" The makefile ------------ PROG = reduce GHCFLAGS = -Wall -fno-warn-name-shadowing -O %: %.lhs ghc $(GHCFLAGS) -o $@ $< all: $(PROG) clean: -rm *.o *.hi $(PROG) From DekuDekuplex at Yahoo.com Sun Feb 1 23:49:05 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Sun Feb 1 23:39:36 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> Message-ID: On Sun, 01 Feb 2009 15:01:28 +0000, Duncan Coutts wrote: >On Sat, 2009-01-31 at 16:50 -0800, Don Stewart wrote: > >> Windows people need to set up a windows@haskell.org to sort out their >> packaging issues, like we have for debian, arch, gentoo, freebsd and >> other distros. >> >> Unless people take action to get things working well on their platform, >> it will be slow going. > >Actually instead of going off into another mailing list I would >encourage them to volunteer on the cabal-devel mailing list to help out. >There is lots we could do to improve the experience on Windows and half >the problem is we do not have enough people working on it or testing >things. That sounds like a great idea, but what specifically should Windows users do to help out? If we try to install a package on Windows and encounter a bug that we can't figure out, would it be sufficient to subscribe at http://www.haskell.org/mailman/listinfo/cabal-devel and to submit a bug report to cabal-devel@haskell.org ? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From artyom.shalkhakov at gmail.com Sun Feb 1 23:55:52 2009 From: artyom.shalkhakov at gmail.com (Artyom Shalkhakov) Date: Sun Feb 1 23:46:04 2009 Subject: [Haskell-cafe] Network.UrlDisp In-Reply-To: References: Message-ID: <2076f2f90902012055x3abcaacdx25270d70806fe321@mail.gmail.com> Hello, 2009/2/2 Pieter Laeremans : > Has anyone some exampe usages of : Network.UrlDisp ? I'll write it up in a few days. Right now, you can read the blog posts of Sterling Clover, topics covered there still apply. I would be grateful if anybody told me how to upload Haddock documentation to Hackage. The code itself contains documentation, but I couldn't get it to show up on Hackage. Cheers, Artyom Shalkhakov. From byorgey at seas.upenn.edu Mon Feb 2 00:55:22 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Mon Feb 2 00:45:33 2009 Subject: [Haskell-cafe] Network.UrlDisp In-Reply-To: <2076f2f90902012055x3abcaacdx25270d70806fe321@mail.gmail.com> References: <2076f2f90902012055x3abcaacdx25270d70806fe321@mail.gmail.com> Message-ID: <20090202055522.GA12528@seas.upenn.edu> On Mon, Feb 02, 2009 at 10:55:52AM +0600, Artyom Shalkhakov wrote: > Hello, > > 2009/2/2 Pieter Laeremans : > > Has anyone some exampe usages of : Network.UrlDisp ? > > I'll write it up in a few days. Right now, you can read the blog posts > of Sterling Clover, topics covered there still apply. > > I would be grateful if anybody told me how to upload Haddock > documentation to Hackage. The code itself contains documentation, > but I couldn't get it to show up on Hackage. Haddock documentation is automatically built for packages on Hackage, but you might have to wait a while (up to a day?) for it to get built. If there are still no links to Haddock documentation, check the build log. -Brent From artyom.shalkhakov at gmail.com Mon Feb 2 01:03:03 2009 From: artyom.shalkhakov at gmail.com (Artyom Shalkhakov) Date: Mon Feb 2 00:53:15 2009 Subject: [Haskell-cafe] Network.UrlDisp In-Reply-To: <20090202055522.GA12528@seas.upenn.edu> References: <2076f2f90902012055x3abcaacdx25270d70806fe321@mail.gmail.com> <20090202055522.GA12528@seas.upenn.edu> Message-ID: <2076f2f90902012203p3cec2021q15f6922c0cbcdb94@mail.gmail.com> Hello, 2009/2/2 Brent Yorgey : >> I would be grateful if anybody told me how to upload Haddock >> documentation to Hackage. The code itself contains documentation, >> but I couldn't get it to show up on Hackage. > > Haddock documentation is automatically built for packages on Hackage, > but you might have to wait a while (up to a day?) for it to get built. > If there are still no links to Haddock documentation, check the build > log. Everything seems to be fine. Thanks! Cheers, Artyom Shalkhakov. From doublef-ctm at yandex.ru Mon Feb 2 03:04:26 2009 From: doublef-ctm at yandex.ru (Sergey Zaharchenko) Date: Mon Feb 2 02:51:13 2009 Subject: [Haskell-cafe] pure crisis :) Message-ID: <20090202080426.GA15341@shark.localdomain> Hello Bulat! Sun, Feb 01, 2009 at 10:19:18PM +0300 you wrote: > Hello haskell-cafe, > pure functional denotation for crisis: > (_|_) Thus, when people try to evaluate the amount of savings they have left, their behavior frequently becomes _undefined_ :) -- DoubleF -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/7c41a25b/attachment.bin From lrpalmer at gmail.com Mon Feb 2 04:15:08 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 2 04:05:24 2009 Subject: [Haskell-cafe] Parallel term reduction In-Reply-To: <7687290b0902012026s2a2e0619tecc227d33ec56afc@mail.gmail.com> References: <7687290b0902012026s2a2e0619tecc227d33ec56afc@mail.gmail.com> Message-ID: <7ca3f0160902020115k2b4974e7w6b560ebcc7badc73@mail.gmail.com> I spent four hours investigating this problem! Thank you very much for the excellent brainfood, and challenging Haskell's claim to be rawkin' at parallelism. I think, though it took much experimentation, that I have confirmed that it is :-) On Sun, Feb 1, 2009 at 9:26 PM, John D. Ramsdell wrote: > > I have a reduction system in which a rule takes a term and returns a > set of terms. > The reduction system creates a tree that originates at a starting > value called the root. > For most problems, the reduction system terminates, but a step count > limit protects > from non-termination. That's typically a bad idea. Instead, use laziness to protect from nontermination. For example, in this case, we can output a collection of items lazily, and then take a finite amount of the output (or check whether the output is longer than some length), without having to evaluate all of it. Here's my writeup of my solution, in literate Haskell. It doesn't output the exact same structure as yours, but hopefully you can see how to tweak it to do so. > {-# LANGUAGE RankNTypes #-} > > *import* *qualified* Data.MemoCombinators *as* Memo > *import* *qualified* Data.Set *as* Set > *import* Control.Parallel (par) > *import* *qualified* Control.Parallel.Strategies *as* Par > *import* Data.Monoid (Monoid(..)) > *import* Control.Monad.State > *import* *qualified* Data.DList *as* DList > *import* Debug.Trace > *import* Control.Concurrent First, I want to capture the idea of a generative set like you're doing. GenSet is like a set, with the constructor "genset x xs" which says "if x is in the set, then so are xs". I'll represent it as a stateful computation of the list of things we've seen so far, returning the list of things we've seen so far. It's redundant information, but sets can't be consumed lazily, thus the list (the set will follow along lazily :-). Remember that State s a is just the function (s -> (s,a)). So we're taking the set of things we've seen so far, and returning the new elements added and the set unioned with those elements. > *newtype* GenSet a > = GenSet (State (Set.Set a) (DList.DList a)) > > genset :: (Ord a) => a -> GenSet a -> GenSet a > genset x (GenSet f) = GenSet $ *do* > seen <- gets (x `Set.member`) > *if* seen > *then* return mempty > *else* fmap (DList.cons x) $ > modify (Set.insert x) >> f > > toList :: GenSet a -> [a] > toList (GenSet f) = DList.toList $ evalState f Set.empty GenSet is a monoid, where mappend is just union. > *instance* (Ord a) => Monoid (GenSet a) *where* > mempty = GenSet (return mempty) > mappend (GenSet a) (GenSet b) = > GenSet (liftM2 mappend a b) Okay, so that's how we avoid exponential behavior when traversing the tree. We can now just toss around GenSets like they're sets and everything will be peachy. Here's the heart of the algorithm: the reduce function. To avoid recomputation of rules, we could just memoize the rule function. But we'll do something a little more clever. The function we'll memoize ("parf") first sparks a thread computing its *last* child. Because the search is depth-first, it will typically be a while until we get to the last one, so we benefit from the spark (you don't want to spark a thread computing something you're about to compute anyway). > reduce :: (Ord a) => Memo.Memo a -> (a -> [a]) -> a -> [a] > reduce memo f x = toList (makeSet x) > *where* > makeSet x = genset x . mconcat . map makeSet . f' $ x > f' = memo parf > parf a = *let* ch = f a *in* > ch `seq` (f' (last ch) `par` ch) The ch `seq` is there so that the evaluation of ch and last ch aren't competing with each other. Your example had a few problems. You said the rule was supposed to be expensive, but yours was cheap. Also, [x-1,x-2,x-3] are all very near each other, so it's hard to go do unrelated stuff. I made a fake expensive function before computing the neighbors, and tossed around some prime numbers to scatter the space more. > rule :: Int -> [Int] > rule n = expensive `seq` > [next 311 4, next 109 577, next 919 353] > *where* > next x y = (x * n + y) `mod` 5000 > expensive = sum [1..50*n] > > main :: IO () > main = *do* > *let* r = reduce Memo.integral rule 1 > print (length r) The results are quite promising: % ghc --make -O2 rules2 -threaded % time ./rules2 5000 ./rules2 13.25s user 0.08s system 99% cpu 13.396 total % time ./rules2 +RTS -N2 5000 ./rules2 +RTS -N2 12.52s user 0.30s system 159% cpu 8.015 total That's 40% decrease in running time! Woot! I'd love to see what it does on a machine with more than 2 cores. Enjoy! Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/eea28e20/attachment-0001.htm From lrpalmer at gmail.com Mon Feb 2 04:21:54 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 2 04:12:06 2009 Subject: [Haskell-cafe] Parallel term reduction In-Reply-To: <7ca3f0160902020115k2b4974e7w6b560ebcc7badc73@mail.gmail.com> References: <7687290b0902012026s2a2e0619tecc227d33ec56afc@mail.gmail.com> <7ca3f0160902020115k2b4974e7w6b560ebcc7badc73@mail.gmail.com> Message-ID: <7ca3f0160902020121u5f01e34agc0a41dd93090825e@mail.gmail.com> On Mon, Feb 2, 2009 at 2:15 AM, Luke Palmer wrote: > I spent four hours investigating this problem! Thank you very much for the > excellent brainfood, and challenging Haskell's claim to be rawkin' at > parallelism. I think, though it took much experimentation, that I have > confirmed that it is :-) For those of you who don't like reading ugly gmail-mangled html, I posted my solution here: http://lukepalmer.wordpress.com/2009/02/02/parallel-rewrite-system/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/adff124f/attachment.htm From duncan.coutts at worc.ox.ac.uk Mon Feb 2 04:31:17 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 04:21:14 2009 Subject: [Haskell-cafe] circular dependencies in cabal In-Reply-To: <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> Message-ID: <1233567077.26754.475.camel@localhost> On Sun, 2009-02-01 at 19:10 -0800, Valentyn Kamyshenko wrote: > So, in practical terms, you suggest that no new version of the package > that ghc package depends on (directly or indirectly) should ever be > installed? > For example, as soon as process-1.0.1.1 is installed on my computer, > I'll have this problem with every package that depends on "process"? Installing process-1.0.1.1 is not itself a problem. It is a new version it does not clash with other versions. The problem is re-installing the same version as you already have installed. In particular re-installing the same version of a package as one that comes with ghc. It's generally not necessary to install new versions of the core packages however, so unless you really know that you need to it's probably simpler to avoid doing so. > Another question: would not cabal-install automatically fetch the most > recent version of the "process" package, as soon as I will try to > install a package that depends on it (such as, for example, "plugins")? No. That's the difference between "cabal install" and "cabal upgrade". The install command installs the latest version of a package but tries to use as many of your existing installed packages as possible. The upgrade command installs the latest version of a package but also tries to install the latest version of all the packages it depends on. That is probably how people are getting into this mess. Using upgrade is not necessarily such a good idea. It does not distinguish between the interesting packages you might want to upgrade and the core packages that your probably do not want to touch. Duncan From duncan.coutts at worc.ox.ac.uk Mon Feb 2 04:49:15 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 04:39:40 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> Message-ID: <1233568155.26754.489.camel@localhost> On Mon, 2009-02-02 at 13:49 +0900, Benjamin L.Russell wrote: > On Sun, 01 Feb 2009 15:01:28 +0000, Duncan Coutts > wrote: > > >On Sat, 2009-01-31 at 16:50 -0800, Don Stewart wrote: > > > >> Windows people need to set up a windows@haskell.org to sort out their > >> packaging issues, like we have for debian, arch, gentoo, freebsd and > >> other distros. > >> > >> Unless people take action to get things working well on their platform, > >> it will be slow going. > > > >Actually instead of going off into another mailing list I would > >encourage them to volunteer on the cabal-devel mailing list to help out. > >There is lots we could do to improve the experience on Windows and half > >the problem is we do not have enough people working on it or testing > >things. > > That sounds like a great idea, but what specifically should Windows > users do to help out? If we try to install a package on Windows and > encounter a bug that we can't figure out, would it be sufficient to > subscribe at http://www.haskell.org/mailman/listinfo/cabal-devel and > to submit a bug report to cabal-devel@haskell.org ? So on cabal-devel we are concerned with bugs and missing features in Cabal that make life hard for windows users. We cannot directly fix individual packages, there are too many and that is the job of the package maintainers. We are interested in solving the more systemic problems however. So for example working out if we can replace many of the configure scripts: http://hackage.haskell.org/trac/hackage/ticket/482 Or just improving the error message when we fail to run configure http://hackage.haskell.org/trac/hackage/ticket/403 Or support in the cabal-install planner for non-Haskell dependencies (so we can track dependencies on sh.exe or libs that are not available on Windows.) The point is to make best use of the available information to work out which packages have no hope of building on Windows. We also have a collection of tickets that primarily affect Windows: http://hackage.haskell.org/trac/hackage/query?status=new&status=assigned&status=reopened&platform=Windows&order=priority many of these need help from windows users, either to decide what the solution should be or to test the solution. Having more Cabal volunteers who use Windows would be great. I've recently been trying to solve some permissions problems on Windows which is pretty hard without having proper access to a Windows system. There are also some important tickets that are just sitting around waiting for some policy decision to be made. The couple people who used to advise us on these questions (like what default install locations should be etc) have not had time recently so these things just sit around with no decisions made. So actually just having more Windows users subscribed to cabal-devel and commenting on tickets would be very useful, even if you do not have much time for hacking. Duncan From dougal at dougalstanton.net Mon Feb 2 04:51:28 2009 From: dougal at dougalstanton.net (Dougal Stanton) Date: Mon Feb 2 04:41:42 2009 Subject: [Haskell-cafe] cabal list can't find Glob.cabal file? In-Reply-To: <1233532909.26754.420.camel@localhost> References: <2d3641330902011504y29469ee9xcebd4eb009578a00@mail.gmail.com> <1233532909.26754.420.camel@localhost> Message-ID: <2d3641330902020151j537b0589l761005080ff15d2c@mail.gmail.com> On Mon, Feb 2, 2009 at 12:01 AM, Duncan Coutts wrote: > The solution is to upgrade: > > $ cabal install cabal-install > > $ cabal --version > cabal-install version 0.6.0 > using version 1.6.0.1 of the Cabal library Yes, this was the problem, despite me upgrading cabal-install before mailing the list. Alas, an old cabal binary was being picked up from /usr/local/bin. Cheers for the help, D From ndmitchell at gmail.com Mon Feb 2 05:07:57 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Mon Feb 2 04:58:09 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <1233568155.26754.489.camel@localhost> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> Message-ID: <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> Hi > So actually just having more Windows users subscribed to cabal-devel and > commenting on tickets would be very useful, even if you do not have much > time for hacking. I believe that as soon as a Windows user starts doing that you'll start asking them for patches :-) There are a number of reasons that we have fewer Windows developers: * Some of it comes down to social reasons - for some reason it seems to be socially acceptable to belittle Windows (and Windows users) on the Haskell mailing lists and #haskell. * Some of it comes down to technical issues - for example not having cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake (although I've heard everyone argue against me, I've not yet heard a Windows person argue against me). * Part of it comes down to most developers not being Windows people. * A little is because Windows is a second class citizen even in the libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a badly typed expression! How would you like it if your OS was listed as Wine? Things like this tell me that Haskell isn't Windows friendly, at best its windows tolerant. * Things like Gtk2hs, which Windows users need building for them, don't release in sync with GHC, which makes it hard to use. * Windows machines don't usually have a C compiler, and have a very different environment - while the rest of the world is starting to standardise. I gave up on fighting the fight when people decided not to bundle cabal.exe with Windows - and now I'm too busy with my day job... Now I'd say Duncan is the most vocal and practical Windows developer, even overlooking the fact he doesn't run Windows. Thanks Neil From stephen.tetley at gmail.com Mon Feb 2 06:28:50 2009 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Mon Feb 2 06:19:01 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <4165d3a70902012013r380a49edy48abb26fc1b8d8ac@mail.gmail.com> References: <20090127000544.3182da13@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> <5fdc56d70902011632s6322eceeg7d31ec3de7d85963@mail.gmail.com> <4165d3a70902012013r380a49edy48abb26fc1b8d8ac@mail.gmail.com> Message-ID: <5fdc56d70902020328o1f7fb80bjc80b69ba0fa9cd9@mail.gmail.com> Hi Jeff Thanks. OpenVG is an interesting bit of kit, however... VGU - the higher level layer - would be hard pressed to be less like Haskell, you draw shapes and lines while passing a path handle around. Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the implementation of OpenVG that the Haskell binding works with supports OpenVG 1.0.1, so it doesn't handle text at all. Text functions were added to the OpenVG at version 1.1. In the short term, this limits the usefulness of OpenVG, but if the implementations develop it does look like a good prospect. Stephen 2009/2/2 Jeff Heard : > I will happily check it on Linux. I'm only vaguely familiar with > OpenVG... In theory it's a good API, and would support exactly what > I'd need for a backend to Hieroglyph that isn't Cairo based, but we'd > still need a good image API and probably to bind to Pango to get text > and layout support. > From gale at sefer.org Mon Feb 2 07:00:03 2009 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 2 06:50:14 2009 Subject: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX In-Reply-To: <6d74b0d20902011109o3afe642er5637674b17d9c2ec@mail.gmail.com> References: <694519c50902010957u2cf7a9f5i6899204c0d7988cf@mail.gmail.com> <3F2BBD7E-F3F9-4490-B700-759FBAD68CB7@gmail.com> <694519c50902011004j2b06de18g14e079b60fa33ef4@mail.gmail.com> <6d74b0d20902011109o3afe642er5637674b17d9c2ec@mail.gmail.com> Message-ID: <2608b8a80902020400k19e32dbco4f661b0334092a89@mail.gmail.com> Thomas Davie wrote: >>> This is caused by OS X's libiconv being entirely CPP >>> macros, the FFI has nothing to get hold of. >>> IIRC there's a ghc bug report open for it. Judah Jacobson wrote: > The OS X system libiconv is actually OK; it's the MacPorts libiconv > that has the CPP macros... > Thanks for the report; I'm not sure of what the right solution is, but > I opened a ticket on Haskeline's bug tracker Perhaps there should also be a ticket on MacPort's bug tracker? -Yitz From leather at cs.uu.nl Mon Feb 2 07:18:40 2009 From: leather at cs.uu.nl (Sean Leather) Date: Mon Feb 2 07:09:37 2009 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> Message-ID: <3c6288ab0902020418w40c48707y6881ea9976adf024@mail.gmail.com> Hi, I'm bringing up an old thread, because it's very relevant to my problem. On Tue, Nov 18, 2008 at 22:30, Duncan Coutts wrote: > On Tue, 2008-11-18 at 01:48 -0800, Jason Dusek wrote: > > I'd like to be able to do something like: > > > > if (template-haskell < 2.3) > > cpp-options: -D TH_THE_YOUNGER > > else > > cpp-options: -D TH_THE_ELDER > > > > I guess this kind of thing is not possible at present? > > It is possible, in two different ways. > > The easiest way is that if you're using Cabal-1.6 then it provides cpp > macros to test the version number of packages you're using. > > #if MIN_VERSION_template_haskell(2,3,0) > ... > #elseif > ... > #endif > > The alternative that works back to Cabal-1.2 is to use: > > flag newer-th > > ... > if flag(newer-th) > build-depends: template-haskell >= 2.3 > cpp-options: -D TH_THE_ELDER > else > build-depends: template-haskell < 2.3 > cpp-options: -D TH_THE_YOUNGER > Either I'm doing something wrong or this doesn't work for cabal-install and GHC 6.8.3. I used the "flag newer-th" approach in EMGM: https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/tags/emgm-0.2/emgm.cabal?view=markup [...] flag th23 description: Define a CPP flag that enables conditional compilation for template-haskell package version 2.3 and newer. Library [...] build-depends: base >= 3.0 && < 4.0, template-haskell < 2.4 -- Include deriveRep for Loc. This was introduced with -- template-haskell-2.3, included with GHC 6.10. if flag(th23) build-depends: template-haskell >= 2.3 cpp-options: -DTH_LOC_DERIVEREP else build-depends: template-haskell < 2.3 [...] When I run cabal install emgm (with GHC 6.8.3 and either Cabal 1.2 or 1.6), it tries (and fails) to install template-haskell-2.3. That's exactly what I don't want. Any suggestions? Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/046a5d36/attachment.htm From barsoap at web.de Mon Feb 2 07:23:22 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Feb 2 07:13:42 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense References: <20090127000544.3182da13@solaris> <3be64c030901301311w70a1446ct2ce836f888b9f4b5@mail.gmail.com> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> <5fdc56d70902011632s6322eceeg7d31ec3de7d85963@mail.gmail.com> <4165d3a70902012013r380a49edy48abb26fc1b8d8ac@mail.gmail.com> <5fdc56d70902020328o1f7fb80bjc80b69ba0fa9cd9@mail.gmail.com> Message-ID: <20090202132322.015f88aa@solaris> Stephen Tetley wrote: > Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the > implementation of OpenVG that the Haskell binding works with supports > OpenVG 1.0.1, so it doesn't handle text at all. > You know, if the Haskell bindings are compositable enough, it shouldn't be a problem to simply load bezier shapes from freetype into other libraries. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From wren at freegeek.org Mon Feb 2 07:29:45 2009 From: wren at freegeek.org (wren ng thornton) Date: Mon Feb 2 07:19:56 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <75cc17ac0902011004l71675254yc8fc8431191f4437@mail.gmail.com> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <4984D014.5010901@freegeek.org> <75cc17ac0902011004l71675254yc8fc8431191f4437@mail.gmail.com> Message-ID: <4986E739.8020906@freegeek.org> Gregg Reynolds wrote: > On Sat, Jan 31, 2009 at 4:26 PM, wren ng thornton wrote: > > > But a data constructor Dcon a is an /element/ mapping taking elements > > > (values) of one type to elements of another type. So it too can be > > > construed as a functor, if each type itself is construed as a > > > category. > > > > Actually no, it's not a functor. It's a (collection of) morphism(s). Let's > > again assume a single-argument Dcon for simplicity. The Haskell type |Dcon > > :: forall a. a -> Tcon a| is represented by a collection of morphisms > > |Dcon_{X} : X -> Tcon X| for each X in Ob(Hask). > > Ok, I see I elided that step. So my question is about the relation > between the individual (specialized) Dcon and the associated Tcon. > I.e. Dcon 3 is a value of type Tcon Int, inferred by the type system. > So it looks to me like the relation between the Tcon functor and the > Dcon functions is basically ad hoc. Pretty much. Well, it's not ad hoc, it's algebraic. Data constructors, by definition, don't perform any sort of introspection on the values they're given. Looking at it sideways, they're 'polymorphic' in the values of the type, and they preserve the structure of the value (namely just storing it). This makes data constructors more well behaved than arbitrary functions. The possible definitions of Haskell types are formed by the algebra consisting of that id function, products of algebras, coproducts of algebras, and equi-recursion (though removing this and using iso-recursion is easier for CT treatment). This well-behavedness is without even looking at polymorphic data constructors. To take a different tactic, consider the free monoid. Like all free things it is the monoid which consists of no more than what is necessary to satisfy the monoid laws (that is, it doesn't cost or require anything special; hence "free"). If you're familiar with Prolog, this is like the idea of uninterpreted predicates. The value of foo(bar) is: foo(bar). Since foo is uninterpreted, applying foo to bar means returning a value that reifies the application of foo to bar. Uninterpreted predicates are "free application"[1]. Data constructors in Haskell are just like this. Applying (:) to x and xs results in the value (x:xs). It is precisely because Dcons cannot inspect the values they are given that makes it so easy for Tcons to be functors. Since the only thing Dcons can do to values is id them up, this is definitionally structure preserving. Note that it's possible to have functors which do inspect the values but still preserve structure by transforming the values in some consistent manner. Because Dcons cannot do anything, this is why people often define "smart" constructors for dealing with abstract types or for maintaining invariants in types which have more structure than can be encoded in ADTs (or GADTs). For example, the bytestring-trie package defines a Trie type for patricia trees mapping ByteStrings to some value type. The basic type for Trie a has Empty, Arc :: ByteString -> Maybe a -> Trie a, and Branch :: Trie a -> Trie a -> Trie a. However, the actual abstract type has a number of invariants which restrict the domain of the type to be much smaller than what you would get with just that specification (e.g. an Arc with no value can't recurse as an Arc, the arcs should be collapsed into one). Smart constructors are an important technique and they can capture many interesting types which ADTs cannot, however when using smart constructors you've stepped outside of the warm confines of what the type system enforces for you. The Haskell type Trie a is not the same thing as the abstract type it's used to represent. By stepping outside of the type system, it's up to the programmer to prove that their abstract type does adhere to the laws for functors, monoids, or whatever. For ADTs, those proofs are already done for you (for functors at least) due to their regular nature. And I do mean "regular", ADTs are coproducts, products, and recursion just like the choice, extension, and Klene star of regular expressions. [1] Easing off from the free monoid, the free associative operator is free (binary) application extended by an equivalence relation for associativity. Thus, values generated by the free assoc-op represent equivalence classes over the application trees which could generate it. The free monoid is the same thing but extended by equivalence relations for the identity element (which is often written by writing nothing, hence it's also an equivalence relation over all possible insertions of the identity element). > > It's important to remember that Tcon is the object half of an *endo*functor > > |Tcon : Hask -> Hask| and not just any functor. We can view the object half > > of an endofunctor as a collection of morphisms on a category; not > > necessarily real morphisms that exist within that category, but more like an > > overlay on a graph. In some cases, this overlay forms a subcategory (that > > is, they are all indeed morphisms in the original category). And this is > > what we have with data constructors: they are (pieces of) the image of the > > endofunctor from within the category itself. > > (unknotting arms...) Uh, er, hmm. I'm still having abstraction > vertigo, since we have (I think) data constructors qua generic > thingees that work at the level of the category, and the same, > specialized to a type, qua functions that operate on the internals of > the categorical objects. It's the moving back and forth from type and > value that escapes me, and I'm not sure I'm even describing the issue > properly. I shall go away and thing about this and then write the > answer down. It won't help the vertigo any, but we can tune the level of abstraction in a few more ways. With some hand waving: * A type constructor is a bundle of polymorphic functions. * A polymorphic function is a bundle of monomorphic functions. * A monomorphic function is a bundle of unit functions (that is, functions from one specific value of the domain "value bundle" (aka "type"), to one specific value of the codomain's "value bundle"). In some ways each of these levels are similar to the others in terms of how they bundle things together so as to be "structure preserving" in the necessary ways. But in some ways, each of the levels are different in what it means to be "bundled". As you say, category theory does it's best to ignore what goes on inside of objects, instead it's all about what goes on between objects (and anything inside of objects is merely "structure" to be preserved). Set theory and domain theory tend to focus more on what goes on inside. Perhaps the simplest way to think of the relation is that the Tycon perspective yields a functor, whereas the Dcon perspective yields a natural transformation (eta : Id -> F, for some endofunctor F). I started writing up a post about this earlier in the context of polymorphic functions being natural transformations. But general polymorphic functions have some extra fiddly details that obscure the message (hence not sending the mail). For type constructors, though, it's straightforward. I'm guessing that your intuitions about the fact that there's stuff happening on multiple levels is coming from the natural transformation. The first few times you run into them, they tend to have that disorienting effect. Part of this disorientation, I think, stems from the fact that natural transformations are structure-preserving transformations from structure-preserving transformations to structure-preserving transformation (say what?). This shouldn't be that mindboggling since we frequently talk about functions from functions to functions (e.g. fmap_{F} :: (a -> b) -> (F a -> F b)), but the level of abstraction can make it difficult to pin down. Personally, I think the confusion is compounded by the way most CT tutorials introduce natural transforms. Usually they start with something like "this is a category", then move onto "this is a functor", then they say that functors are also morphisms in the category, Cat, of small categories; which is all good. (And already we have the morphism/functor and object/category vertigo.) But then, when explaining natural transformations they say something about them being "like functors but moreso", then everything comes crashing down because that often gets people visualizing functors on categories of categories, but those are just functors too. If we're looking at Cat, and we pick two objects X and Y (aka categories C and D), and then pick two morphisms f and g (aka functors F and G), a natural transformation is a structure preserving transformation from f into g. A key difference between this and a functor on Cat is that X and Y are fixed; we do not say "for all X, Y, and f : X->Y" like we would for a functor. YMMV, and all that. -- Live well, ~wren From iliya.kuznetsov at gmail.com Mon Feb 2 07:45:11 2009 From: iliya.kuznetsov at gmail.com (Iliya Kuznetsov) Date: Mon Feb 2 07:35:23 2009 Subject: [Haskell-cafe] cURL under Windows again Message-ID: Hello cafe-subscribers, I saw some issues about installing haskell bindings for cURL under Windows, and now I'm trapped too. So, here is actions' log for everything (very detail; you can PgDn to the end with questions): 1. Windows Vista without UAC 2. ghc-6.10.1-i386-windows.exe is installed to C:\Program Files\Haskell "C:\Program Files\Haskell\package.conf" wasn't touched after installation (Cabal nor manually) 3. MinGW-5.1.4 installed to C:\temp\MinGW 4. MSys-1.0 installed to C:\temp\msys\1.0\ 5. curl-7.19.3.tar.bz2 had taken from http://curl.haxx.se/download/curl-7.19.3.tar.bz2 6. Under msys, curl-7.19.3.tar.bz2 is untared into /home/Kuznetsov/curl-7.19.3 7. cURL is made as: cd curl-7.19.3 $ ./configure configure: Configured to build curl/libcurl: ... curl version: 7.19.3 Host setup: i686-pc-mingw32 Install prefix: /usr/local Compiler: gcc SSL support: no (--with-ssl / --with-gnutls) SSH support: no (--with-libssh2) zlib support: no (--with-zlib) krb4 support: no (--with-krb4*) GSSAPI support: no (--with-gssapi) SPNEGO support: no (--with-spnego) c-ares support: no (--enable-ares) ipv6 support: no (--enable-ipv6) IDN support: no (--with-libidn) Build libcurl: Shared=yes, Static=yes Built-in manual: no (--enable-manual) Verbose errors: enabled (--disable-verbose) SSPI support: no (--enable-sspi) ca cert bundle: no ca cert path: no LDAP support: enabled (winldap) LDAPS support: no (--enable-ldaps) $ make ... make[2]: Leaving directory `/home/Kuznetsov/curl-7.19.3/src' make[1]: Leaving directory `/home/Kuznetsov/curl-7.19.3/src' make[1]: Entering directory `/home/Kuznetsov/curl-7.19.3' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/Kuznetsov/curl-7.19.3' $ make install ... libtool: install: /bin/install -c .libs/libcurl.dll.a /usr/local/lib/libcurl.dll.a libtool: install: base_file=`basename libcurl.la` libtool: install: dlpath=`/bin/sh 2>&1 -c '. .libs/'libcurl.la'i; echo libcurl-4.dll'` libtool: install: dldir=/usr/local/lib/`dirname ../bin/libcurl-4.dll` libtool: install: test -d /usr/local/lib/../bin || mkdir -p /usr/local/lib/../bin libtool: install: /bin/install -c .libs/libcurl-4.dll /usr/local/lib/../bin/libcurl-4.dll libtool: install: chmod a+x /usr/local/lib/../bin/libcurl-4.dll libtool: install: if test -n '' && test -n 'strip --strip-unneeded'; then eval 'strip --strip-unneeded /usr/local/lib/../bin/libcurl-4.dll' || exit 0; fi libtool: install: /bin/install -c .libs/libcurl.lai /usr/local/lib/ libcurl.la libtool: install: /bin/install -c .libs/libcurl.a /usr/local/lib/libcurl.a libtool: install: chmod 644 /usr/local/lib/libcurl.a libtool: install: ranlib /usr/local/lib/libcurl.a ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-LLIBDIR' linker flag ... /bin/install -c -m 644 'curl.h' '/usr/local/include/curl/curl.h' /bin/install -c -m 644 'curlver.h' '/usr/local/include/curl/curlver.h' /bin/install -c -m 644 'easy.h' '/usr/local/include/curl/easy.h' /bin/install -c -m 644 'mprintf.h' '/usr/local/include/curl/mprintf.h' /bin/install -c -m 644 'stdcheaders.h' '/usr/local/include/curl/stdcheaders.h' /bin/install -c -m 644 'types.h' '/usr/local/include/curl/types.h' /bin/install -c -m 644 'multi.h' '/usr/local/include/curl/multi.h' /bin/install -c -m 644 'typecheck-gcc.h' '/usr/local/include/curl/typecheck-gcc.h' /bin/install -c -m 644 'curlbuild.h' '/usr/local/include/curl/curlbuild.h' /bin/install -c -m 644 'curlrules.h' '/usr/local/include/curl/curlrules.h' ... 8. $ which curl && curl /usr/local/bin/curl curl: try 'curl --help' for more information I have following files in C:\temp\msys\1.0\local\bin\ (/usr/local/bin in Unix-scheme): 02.02.2009 15:10 4 029 curl-config 02.02.2009 15:10 98 591 curl.exe 02.02.2009 15:09 262 934 libcurl-4.dll In /usr/local/include/curl ten includes: 02.02.2009 15:10 67 183 curl.h 02.02.2009 15:10 5 865 curlbuild.h 02.02.2009 15:10 7 478 curlrules.h 02.02.2009 15:10 2 799 curlver.h 02.02.2009 15:10 3 526 easy.h 02.02.2009 15:10 2 850 mprintf.h 02.02.2009 15:10 13 039 multi.h 02.02.2009 15:10 1 383 stdcheaders.h 02.02.2009 15:10 33 337 typecheck-gcc.h 02.02.2009 15:10 15 types.h ---- Sorry for many details, but now I can show the wrong behaviour of the haskell bindings for cURL under windows: 9. curl-1.3.4 is taken from hackage and unzipped to /home/Kuznetsov $ cd ~/curl-1.3.4 $ runhaskell Setup.hs configure --extra-include-dirs=/usr/local/include --extra-lib-dirs=/usr/local/lib Configuring curl-1.3.4... $ runhaskell Setup.hs build Preprocessing library curl-1.3.4... Building curl-1.3.4... [1 of 8] Compiling Network.Curl.Debug ( Network\Curl\Debug.hs, dist\build\Network\Curl\Debug.o ) [2 of 8] Compiling Network.Curl.Types ( Network\Curl\Types.hs, dist\build\Network\Curl\Types.o ) [3 of 8] Compiling Network.Curl.Post ( Network\Curl\Post.hs, dist\build\Network\Curl\Post.o ) [4 of 8] Compiling Network.Curl.Opts ( Network\Curl\Opts.hs, dist\build\Network\Curl\Opts.o ) [5 of 8] Compiling Network.Curl.Code ( Network\Curl\Code.hs, dist\build\Network\Curl\Code.o ) [6 of 8] Compiling Network.Curl.Info ( Network\Curl\Info.hs, dist\build\Network\Curl\Info.o ) Network\Curl\Info.hs:80:0: Warning: Defined but not used: `stringTag' Network\Curl\Info.hs:83:0: Warning: Defined but not used: `longTag' Network\Curl\Info.hs:86:0: Warning: Defined but not used: `doubleTag' Network\Curl\Info.hs:89:0: Warning: Defined but not used: `slistTag' [7 of 8] Compiling Network.Curl.Easy ( Network\Curl\Easy.hs, dist\build\Network\Curl\Easy.o ) [8 of 8] Compiling Network.Curl ( Network\Curl.hs, dist\build\Network\Curl.o ) C:\Program Files\Haskell\bin\ar.exe: creating dist\build\libHScurl-1.3.4.a $ runhaskell Setup.hs install Installing library in C:\Program Files\Haskell\curl-1.3.4\ghc-6.10.1 Registering curl-1.3.4... Reading package info from "dist\\installed-pkg-config" ... done. Writing new package config file... done. 10. In package.conf I have seen: InstalledPackageInfo {package = PackageIdentifier {pkgName = PackageName "curl", pkgVersion = Version {versionBranch = [1,3,4], versionTags = []}}, license = BSD3, copyright = "", maintainer = "Sigbjorn Finne < sigbjorn.finne@gmail.com>", author = "Sigbjorn Finne", stability = "", homepage = "", pkgUrl = "", description = "libcurl is a client-side URL transfer library, supporting FTP, FTPS, HTTP,\nHTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE.\nlibcurl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading,\nHTTP form based upload, proxies, cookies, user+password authentication\n(Basic, Digest, NTLM, Negotiate, Kerberos4), file transfer resume,\nhttp proxy tunneling and more!\n\nThis package provides a Haskell binding to libcurl.", category = "Network", exposed = True, exposedModules = ["Network.Curl","Network.Curl.Code"," Network.Curl.Info","Network.Curl.Opts","Network.Curl.Post","Network.Curl.Types","Network.Curl.Easy","Network.Curl.Debug"], hiddenModules = [], importDirs = ["C:\\Program Files\\Haskell\\curl-1.3.4\\ghc-6.10.1"], libraryDirs = ["C:\\Program Files\\Haskell\\curl-1.3.4\\ghc-6.10.1","C:/temp/msys/1.0/local/lib"], hsLibraries = ["HScurl-1.3.4"], extraLibraries = ["curl"], extraGHCiLibraries = [], includeDirs = ["C:/temp/msys/1.0/local/include"], includes = [], depends = [PackageIdentifier {pkgName = PackageName "base", pkgVersion = Version {versionBranch = [3,0,3,0], versionTags = []}},PackageIdentifier {pkgName = PackageName "bytestring", pkgVersion = Version {versionBranch = [0,9,1,4], versionTags = []}},PackageIdentifier {pkgName = PackageName "containers", pkgVersion = Version {versionBranch = [0,2,0,0], versionTags = []}}], hugsOptions = [], ccOptions = [], ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces = ["C:\\Program Files\\Haskell\\doc\\curl-1.3.4\\html\\curl.haddock"], haddockHTMLs = ["C:\\Program Files\\Haskell\\doc\\curl-1.3.4\\html"]} In "C:\Program Files\Haskell\curl-1.3.4\ghc-6.10.1\" I have seen HScurl-1.3.4.o , libHScurl-1.3.4.a and other Curl files. 11. Final tests: under msys: $ ghci Prelude> :m Network.Curl module `Network.Curl' is not loaded Bad, but not a disaster. under windows: C:\> ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m Network.Curl Prelude Network.Curl> let a = curlGet Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package curl-1.3.4 ... : curl: ?? ?????? ????????? ??????. (text in russian here because of localized Vista. The message is near "Can't load specified module") can't load .so/.DLL for: curl (addDLL: could not load DLL) Prelude Network.Curl> So, the question is why curl doesn't work? I tried to use Cabal but it failed with building too. How can I test the fact that C:\temp\msys\1.0\local\bin\libcurl-4.dll is used in curl-1.3.4 ? -- Iliya Kuznetsov +7-916-878-75-70 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/0d8b2bd1/attachment.htm From jwlato at gmail.com Mon Feb 2 08:22:37 2009 From: jwlato at gmail.com (John Lato) Date: Mon Feb 2 08:12:49 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! Message-ID: <9979e72e0902020522y53c8c6aamad4b03d560918e1f@mail.gmail.com> Duncan Coutts wrote: > > Some are trivial and should be done away with. For example the ones that > just check if a C header / lib is present are unnecessary (and typically > do not work correctly). The next point release of Cabal can do these > checks automatically, eg: > > Configuring foo-1.0... > cabal: Missing dependencies on foreign libraries: > * Missing header file: foo.h > * Missing C libraries: foo, bar, baz > This problem can usually be solved by installing the system > packages that provide these libraries (you may need the "-dev" > versions). If the libraries are already installed but in a > non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where > they are. Thank you! Thank you! Thank you! For those of us who want to write cross-platform (i.e. Windows) bindings to C libraries, this is great news. John Lato From gale at sefer.org Mon Feb 2 08:22:11 2009 From: gale at sefer.org (Yitzchak Gale) Date: Mon Feb 2 08:13:17 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <1233501034.26754.360.camel@localhost> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> <1233501034.26754.360.camel@localhost> Message-ID: <2608b8a80902020522r2302b4f4p96c29d8c6d516289@mail.gmail.com> Duncan Coutts wrote: >>> So in the next cabal-install release (which should be pretty soon now) >>> configure will do the same thing and pick base 3 unless you specify >>> build-depends base >= 4. Niklas Broberg wrote: >> I really really think this is the wrong way to go. Occasional >> destruction is desperately needed for progress, else things will >> invariably stagnate. > I disagree. Having everything fail... would have been a disaster... > during the lifespan of base 4 we need to encourage new > releases to start working with it... > Doing that with warnings hints etc is the way to go. No, that's not good enough either. Existing packages will just stay with old versions to avoid the work, and new packages will then also use old versions for maximum compatibility. The incentive is not strong enough. Those warnings and hints must have teeth. Comparing with what has happened in other languages, which have stagnated or not stagnated at various rates, it is clear that what we need is a well-defined deprecation process. The warnings should say something like: you had better upgrade this, otherwise it will stop working in the next version. Both maintainers and users should be aware of this threat. That way, code that is maintained will not stop working. There will be plenty of time to make the change. Code that is used but not maintained will generate a hue and cry among the users that will hopefully motivate someone to do something about it. Code that is not maintained and little used will eventually be destroyed, but that code is probably bitrotting in any case. The deprecation process can be as slow and fine-grained as we like. But there must be a well-defined point in the future when old unmaintained code will be allowed to stop working. > Destruction is not such a friendly approach. We do not > need to make the users suffer When done carefully, gradually, and with plenty of warning (at least one full version cycle), destruction is indeed friendly and helpful. It allows users to understand precisely what versions should be used, and when, in old, current, and future projects, while permitting Haskell to march steadily onward. -Yitz From manlio_perillo at libero.it Mon Feb 2 08:57:01 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Mon Feb 2 08:47:29 2009 Subject: [Haskell-cafe] UDP In-Reply-To: <4984C720.3080802@btinternet.com> References: <497C91D1.4050102@btinternet.com> <4984C720.3080802@btinternet.com> Message-ID: <4986FBAD.5060304@libero.it> Andrew Coppin ha scritto: > [...] > > Yeah, I just assumed that the bind step was only necessary for > connection-oriented protocols. (Interestingly enough, the matching > "send" program doesn't bind at all, yet seems to work fine...) > For a client (that is, when you call connect), the kernel chooses the source IP address once the socket is connected. Of course, for a server this is not feasible, since the address *must* be know to external programs, if they want to connect to the server. For more details, I really suggest to read a good book like "UNIX Network Programming", by W. Richard Stevens. Regards Manlio Perillo From jefferson.r.heard at gmail.com Mon Feb 2 09:26:59 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Mon Feb 2 09:17:10 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <20090202132322.015f88aa@solaris> References: <20090127000544.3182da13@solaris> <3be64c030901301356y5a01a55u38c6babc2bf41353@mail.gmail.com> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> <5fdc56d70902011632s6322eceeg7d31ec3de7d85963@mail.gmail.com> <4165d3a70902012013r380a49edy48abb26fc1b8d8ac@mail.gmail.com> <5fdc56d70902020328o1f7fb80bjc80b69ba0fa9cd9@mail.gmail.com> <20090202132322.015f88aa@solaris> Message-ID: <4165d3a70902020626n38f37bb1vb7b4ccc9ffe489b8@mail.gmail.com> That's my thought. On Mon, Feb 2, 2009 at 7:23 AM, Achim Schneider wrote: > Stephen Tetley wrote: > >> Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the >> implementation of OpenVG that the Haskell binding works with supports >> OpenVG 1.0.1, so it doesn't handle text at all. >> > You know, if the Haskell bindings are compositable enough, it shouldn't > be a problem to simply load bezier shapes from freetype into other > libraries. > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgoerzen at complete.org Mon Feb 2 09:30:56 2009 From: jgoerzen at complete.org (John Goerzen) Date: Mon Feb 2 09:21:09 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> Message-ID: <498703A0.9060102@complete.org> Neil Mitchell wrote: > * Part of it comes down to most developers not being Windows people. That certainly describes me. I find the platform annoying and stressful (all the worries about security). But another issue is: it's proprietary and expensive. The base OS isn't cheap, and doesn't even come with development tools. While GHC and friends do run on Windows for free, if you are trying to deal certain things (Windows GUIs, ODBC, etc.) it is difficult at best without shelling out the really big bucks for the Microsoft development environment. Having said that, I agree that good Windows support is a worthwhile goal for the community, and I very much appreciate patches and bug reports from Windows users. However, I am in somewhat of a difficult position when it comes to turning the latter into actual patches. Of course, MacOS X is also proprietary and expensive. But it has at least a bastardized POSIX core, and as such seems to never really need much porting from my Linux development environment. At least until Mac users start demanding resource fork and finder info support. ;-) -- John From emax at chalmers.se Mon Feb 2 09:35:01 2009 From: emax at chalmers.se (Emil Axelsson) Date: Mon Feb 2 09:25:13 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? Message-ID: <49870495.3010305@chalmers.se> Hello, Are there any Haskell tutorials suitable for people who don't (and possibly don't want to) know Haskell, but just want to use an embedded language that happens to be in Haskell? Such a tutorial would focus on using libraries rather than defining them. For example, it might explain how to interpret a type signature involving type classes, but not how to write one's own type class. Thanks, / Emil From dev at mobileink.com Mon Feb 2 10:16:43 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 2 10:06:55 2009 Subject: [Haskell-cafe] type metaphysics Message-ID: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> Hi, The concept of "type" seems to be a little like porno: I know it when I see it, but I can't define it (apologies to Justice Stewart). I've picked through lots of documents that discuss types in various ways, but I have yet to find one that actually says what a type "really" is. For example, definitions of the typed lambda calculus usually define some type symbols and rules like "a : T means a is of type T", and then reasoning ensues without discussion of what "type" means. The only discussion I've found that addresses this is at the Stanford Encyclopedia of Philosophy, article "Types and Tokens" [1]. It's all very philosophical, but there is one point there that I think has relevance to Haskell. It's in section 4.1, discussing the distinction between types and sets: "Another closely related problem also stems from the fact that sets, or classes, are defined extensionally, in terms of their members. The set of natural numbers without the number 17 is a distinct set from the set of natural numbers. One way to put this is that classes have their members essentially. Not so the species homo sapiens, the word 'the', nor Beethoven's Symphony No. 9. The set of specimens of homo sapiens without George W. Bush is a different set from the set of specimens of homo sapiens with him, but the species would be the same even if George W. Bush did not exist. That is, it is false that had George W. Bush never existed, the species homo sapiens would not have existed. The same species might have had different members; it does not depend for its existence on the existence of all its members as sets do." So it appears that one can think of a type as a predicate; any token (value?) that satisfies the predicate is a token (member?) of that type. This gives a very interesting way of looking at Haskell type constructors: a value of (say) Tcon Int is anything that satisfies "isA Tcon Int". The tokens/values of Tcon Int may or may not constitute a set, but even if they, we have no way of describing the set's extension. My hunch is that it /cannot/ be a set, although I'm not mathematician enough to prove it. My reasoning is that we can define an infinite number of data constructors for it, including at least all possible polynomials (by which I mean data constructors of any arity taking args of any type). To my naive mind this sounds suspiciously like the set of all sets, so it's too big to be a set. In any case, Tcon Int does not depend on any particular constructor, just as homo sapiens does not depend on any particular man. So it can't be a set because it doesn't have its members essentially. (I suspect this leads to DeepThink about classical v. constructivist mathematics, but that's a subject for a different discussion.) I'm not sure that works technically, but it seems kinda cool. My question for the list: is the collection of e.g. Tcon Int values a set, or not? If it is, how big is it? Thanks, gregg [1] http://plato.stanford.edu/entries/types-tokens/ From icfp.publicity at googlemail.com Mon Feb 2 10:30:52 2009 From: icfp.publicity at googlemail.com (Matthew Fluet (ICFP Publicity Chair)) Date: Mon Feb 2 10:21:02 2009 Subject: [Haskell-cafe] ICFP09 Final CFP Message-ID: <53ff55480902020730l2b41010cu69c2fcc80f7f60fa@mail.gmail.com> Final Call for Papers ICFP 2009: International Conference on Functional Programming Edinburgh, Scotland, 31 August - 2 September 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html ** Submission deadline: 2 March 2009 ** Submission URL: https://www.softconf.com/a/icfp09/ ICFP 2009 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects or concurrency. Particular topics of interest include * Language Design * Implementation * Software-Development Techniques * Foundations * Applications and Domain-Specific Languages * Functional Pearls The conference also solicits Experience Reports, which are short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application. Important Dates (at 20:00 UTC) ~~~~~~~~~~~~~~~ Submission: 2 March 2009 https://www.softconf.com/a/icfp09/ Author response: 21-23 April 2009 Notification: 5 May 2009 Final papers due: 8 June 2009 Call for Papers (full text) ~~~~~~~~~~~~~~~ http://web.cecs.pdx.edu/~apt/icfp09_cfp.html Call for Experience Reports (full text) ~~~~~~~~~~~~~~~~~~~~~~~~~~~ http://web.cecs.pdx.edu/~apt/icfp09_cfer.html Program Chair ~~~~~~~~~~~~~ Andrew Tolmach Department of Computer Science Portland State University P.O. Box 751, Portland, OR 97207 USA Email: apt@cs.pdx.edu Phone: +1 503 725 5492 Fax: +1 503 725 3211 Mail sent to the address above is filtered for spam. If you send mail and do not receive a prompt response, particularly if the deadline is looming, feel free to telephone. From a.d.clark at ed.ac.uk Mon Feb 2 10:35:34 2009 From: a.d.clark at ed.ac.uk (allan) Date: Mon Feb 2 10:25:57 2009 Subject: [Haskell-cafe] circular dependencies in cabal In-Reply-To: <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> Message-ID: <498712C6.3040002@ed.ac.uk> Hi Are you still in a "not-able-to-do-a-cabal-install" state? I had this problem as well and I solved it by simply deleting (or moving) my ~/.ghc directory and then re-installing ghc, as per this message: http://markmail.org/message/fraw3cw56squfeld Note: that this should only be used if you can't solve it the suggested way which is to look in your pkg database for packages registered in both user and global databases and unregister the user one. regards allan Valentyn Kamyshenko wrote: > So, in practical terms, you suggest that no new version of the package > that ghc package depends on (directly or indirectly) should ever be > installed? > For example, as soon as process-1.0.1.1 is installed on my computer, > I'll have this problem with every package that depends on "process"? > Another question: would not cabal-install automatically fetch the most > recent version of the "process" package, as soon as I will try to install > a package that depends on it (such as, for example, "plugins")? > > -- Valentyn. > > On Feb 1, 2009, at 6:53 AM, Duncan Coutts wrote: > >> On Sun, 2009-02-01 at 01:33 -0800, Valentyn Kamyshenko wrote: >>> Hello all, >>> >>> when I tried to install plugins package with cabal, I've got the >>> following error: >>> >>> # sudo cabal install plugins --global >>> Resolving dependencies... >>> cabal: dependencies conflict: ghc-6.10.1 requires process ==1.0.1.1 >>> however >>> process-1.0.1.1 was excluded because ghc-6.10.1 requires process >>> ==1.0.1.0 >> >> For the most part I refer you to: >> >> http://haskell.org/pipermail/haskell-cafe/2009-January/054523.html >> >> However the difference is that you've got this problem only within the >> global package db rather than due to overlap in the global and user >> package db. >> >>> It looks like both versions of process package are currently required: >> >> It looks like you installed process-1.0.1.1 and then rebuilt almost >> every other package against it. Of course you cannot rebuild the ghc >> package but you did rebuild some of its dependencies which is why it now >> depends on multiple versions of the process package. >> >> Generally rebuilding a package without also rebuilding the packages that >> depend on it is a bit dodgy (it can lead to linker errors or segfaults). >> Unfortunately cabal-install does not prevent you from shooting yourself >> in the foot in these circumstances. >> >>> Any suggestions? >> >> Aim for a situation where you only have one version of the various core >> packages. If you do not need to install packages globally then >> installing them per-user means you at least cannot break the global >> packages. >> >> Duncan >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From bugfact at gmail.com Mon Feb 2 10:40:44 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Feb 2 10:30:56 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <4165d3a70902020626n38f37bb1vb7b4ccc9ffe489b8@mail.gmail.com> References: <20090127000544.3182da13@solaris> <4165d3a70902011510s69747ec8jf7975e8eab315e8e@mail.gmail.com> <5fdc56d70902011632s6322eceeg7d31ec3de7d85963@mail.gmail.com> <4165d3a70902012013r380a49edy48abb26fc1b8d8ac@mail.gmail.com> <5fdc56d70902020328o1f7fb80bjc80b69ba0fa9cd9@mail.gmail.com> <20090202132322.015f88aa@solaris> <4165d3a70902020626n38f37bb1vb7b4ccc9ffe489b8@mail.gmail.com> Message-ID: Although efficient text rendering (or more generally, massive similar shape rendering) requires a lot of clever caching I guess :) On Mon, Feb 2, 2009 at 3:26 PM, Jeff Heard wrote: > That's my thought. > > On Mon, Feb 2, 2009 at 7:23 AM, Achim Schneider wrote: > > Stephen Tetley wrote: > > > >> Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the > >> implementation of OpenVG that the Haskell binding works with supports > >> OpenVG 1.0.1, so it doesn't handle text at all. > >> > > You know, if the Haskell bindings are compositable enough, it shouldn't > > be a problem to simply load bezier shapes from freetype into other > > libraries. > > > > -- > > (c) this sig last receiving data processing entity. Inspect headers > > for copyright history. All rights reserved. Copying, hiring, renting, > > performance and/or quoting of this signature prohibited. > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/ad28da40/attachment.htm From deniz.a.m.dogan at gmail.com Mon Feb 2 10:44:04 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Mon Feb 2 10:34:17 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: <49870495.3010305@chalmers.se> References: <49870495.3010305@chalmers.se> Message-ID: <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> 2009/2/2 Emil Axelsson : > Hello, > > Are there any Haskell tutorials suitable for people who don't (and possibly > don't want to) know Haskell, but just want to use an embedded language that > happens to be in Haskell? > > Such a tutorial would focus on using libraries rather than defining them. > For example, it might explain how to interpret a type signature involving > type classes, but not how to write one's own type class. > > Thanks, > > / Emil Hi, Emil I don't think it's a good idea (or even possible) to use a Haskell library without knowing anything about Haskell or functional programming. However, it shouldn't take too long to learn the very basics needed to get going, but this of course depends on the complexity of the library you're trying to use. Take some the time to read the parts that are relevant to you in e.g. Learn You a Haskell for Great Good (http://learnyouahaskell.com/) or Real World Haskell which has been published in book form, but is also available at http://book.realworldhaskell.org. If you haven't already taken the course "Introduction to Functional Programming given at Chalmers", you can take a look at the lecture slides and/or exercises/labs from the course at http://www.cs.chalmers.se/Cs/Grundutb/Kurser/funht/. I hope that helps. Deniz From martijn at van.steenbergen.nl Mon Feb 2 10:49:41 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Mon Feb 2 10:40:26 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> Message-ID: <49871615.2020806@van.steenbergen.nl> Hi Gregg, Firsly: I'm not an expert on this, so if anyone thinks I'm writing nonsense, do correct me. There are many answers to the question "what is a type?", depending on one's view. One that has been helpful to me when learning Haskell is "a type is a set of values." When seen like this it makes sense to write: () = { () } Bool = { True, False } Maybe Bool = { Nothing, Just True, Just False } Recursive data types have an infinite number of values. Almost all types belong to this group. Here's one of the simplest examples: data Peano = Zero | Suc Peano There's nothing wrong with a set with an infinite number of members. Gregg Reynolds wrote: > This gives a very interesting way of looking at Haskell type > constructors: a value of (say) Tcon Int is anything that satisfies > "isA Tcon Int". The tokens/values of Tcon Int may or may not > constitute a set, but even if they, we have no way of describing the > set's extension. Int has 2^32 values, just like in Java. You can verify this in GHCi: Prelude> (minBound, maxBound) :: (Int, Int) (-2147483648,2147483647) Integer, on the other hand, represents arbitrarily big integers and therefore has an infinite number of elements. > To my naive mind this sounds > suspiciously like the set of all sets, so it's too big to be a set. Here you're probably thinking about the distinction between countable and uncountable sets. See also: http://en.wikipedia.org/wiki/Countable_set Haskell has types which have uncountably many values. They are all functions of the form A -> B, where A is an infinite type (either countably or uncountably). If a set is countable, you can enumerate the set in such a way that you will reach each member eventually. For Haskell this means that if a type "a" has a countable number of values, you can define a list :: [a] that will contain all of them. I hope this helps! Let us know if you have any other questions. Martijn. From Andrew.Butterfield at cs.tcd.ie Mon Feb 2 11:05:13 2009 From: Andrew.Butterfield at cs.tcd.ie (Andrew Butterfield) Date: Mon Feb 2 10:55:24 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <49871615.2020806@van.steenbergen.nl> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> Message-ID: <498719B9.7040204@cs.tcd.ie> Martijn van Steenbergen wrote: > >> To my naive mind this sounds >> suspiciously like the set of all sets, so it's too big to be a set. > > Here you're probably thinking about the distinction between countable > and uncountable sets. See also: > > http://en.wikipedia.org/wiki/Countable_set No - it's even bigger than those ! He is thinking of proper classes, not sets. http://en.wikipedia.org/wiki/Class_(set_theory) -- -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Foundations and Methods Research Group Director. School of Computer Science and Statistics, Room F.13, O'Reilly Institute, Trinity College, University of Dublin http://www.cs.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- From lutz at iks-jena.de Mon Feb 2 11:09:16 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Mon Feb 2 10:59:29 2009 Subject: [Haskell-cafe] type metaphysics References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> Message-ID: * Martijn van Steenbergen wrote: > Int has 2^32 values, just like in Java. Haskell Report 6.4 (revised): The finite-precision integer type Int covers at least the range [ - 2^29, 2^29 - 1]. From dev at mobileink.com Mon Feb 2 11:09:53 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 2 11:00:03 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <498719B9.7040204@cs.tcd.ie> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <498719B9.7040204@cs.tcd.ie> Message-ID: <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> On Mon, Feb 2, 2009 at 10:05 AM, Andrew Butterfield wrote: > Martijn van Steenbergen wrote: >> >>> To my naive mind this sounds >>> suspiciously like the set of all sets, so it's too big to be a set. >> >> Here you're probably thinking about the distinction between countable and >> uncountable sets. See also: >> >> http://en.wikipedia.org/wiki/Countable_set > > No - it's even bigger than those ! > > He is thinking of proper classes, not sets. > > http://en.wikipedia.org/wiki/Class_(set_theory) Yes, that's my hypothesis: type constructors take us outside of set theory (ZF set theory, at least). I just can't prove it. Thanks, g From emax at chalmers.se Mon Feb 2 11:19:25 2009 From: emax at chalmers.se (Emil Axelsson) Date: Mon Feb 2 11:09:36 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> Message-ID: <49871D0D.6060101@chalmers.se> Hi Deniz, Deniz Dogan skrev: > I don't think it's a good idea (or even possible) to use a Haskell > library without knowing anything about Haskell or functional > programming. However, it shouldn't take too long to learn the very Well, I guess I was asking for a tutorial which covers everything except the parts that are not normally relevant for a DSEL user. For example, I would expect the following to be left out: * Definition of data types and classes * Laziness * Monad internals * IO * etc. Things that I think should be covered: * Polymorphism * Higher-order functions * Lists * Recursion * Monadic combinators * etc. Of course, the requirements may vary from case to case, but you get the idea. > Take some the time to > read the parts that are relevant to you in e.g. Learn You a Haskell > for Great Good (http://learnyouahaskell.com/) Seems like a nice and gentle tutorial, somewhat like what I imagined. However, it also seems a bit too "high school"-oriented for the audience I currently have in mind :) / Emil (who may try to write this tutorial himself at some point) From dev at mobileink.com Mon Feb 2 11:26:48 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 2 11:17:00 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <49871615.2020806@van.steenbergen.nl> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> Message-ID: <75cc17ac0902020826y399c58a3rea2c899126550c3@mail.gmail.com> Hi Martijn, On Mon, Feb 2, 2009 at 9:49 AM, Martijn van Steenbergen < martijn@van.steenbergen.nl> wrote: > > There are many answers to the question "what is a type?", depending on one's > view. > > One that has been helpful to me when learning Haskell is "a type is a set of > values." That's the way I've always thought of types, never having had a good reason to think otherwise. But it seems it doesn't work - type theory goes beyond set theory. I've even found an online book[1] that uses type theory to construct set theory! At least I think that's what it does (not that I understand it.) >> This gives a very interesting way of looking at Haskell type >> constructors: a value of (say) Tcon Int is anything that satisfies >> "isA Tcon Int". The tokens/values of Tcon Int may or may not >> constitute a set, but even if they, we have no way of describing the >> set's extension. > > Int has 2^32 values, just like in Java. You can verify this in GHCi: > Ok, but that's an implementation detail. My question is what is the theoretical basis of types. Notice that the semantics of Haskell's built-in types are a matter of social convention. The symbols used - Int, 0, 1, 2, ... - are well-known, and we agree not to add data constructors. But we could if we wanted to. Say, Foo :: Int -> Int. Then Foo 3 is an Int, distinct from all other Ints; in particular it is not equal to "3". I suspect a full definition of type would have to say something about operations. >> To my naive mind this sounds >> suspiciously like the set of all sets, so it's too big to be a set. > > Here you're probably thinking about the distinction between countable and > uncountable sets. See also: > It could be that values of a constructed type form an uncountably large set, rather than something too big to be a set at all. I'm afraid I don't know how to work with such critters. In any case, the more interesting thing (to me) is the notion that sets contain their members "essentially", but data types don't, as far as I can see. Thanks much, gregg [1] http://www.cs.chalmers.se/Cs/Research/Logic/book/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/8680a5b4/attachment.htm From lennart at augustsson.net Mon Feb 2 11:28:08 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 2 11:18:19 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <49871615.2020806@van.steenbergen.nl> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> Message-ID: The Haskell function space, A->B, is not uncountable. There is only a countable number of Haskell functions you can write, so how could there be more elements in the Haskell function space? :) The explanation is that the Haskell function space is not the same as the functions space in set theory. Most importantly Haskell functions have to be monotonic (in the domain theoretic sense), so that limits the number of possible functions. http://en.wikipedia.org/wiki/Domain_theory -- Lennart On Mon, Feb 2, 2009 at 3:49 PM, Martijn van Steenbergen wrote: > Hi Gregg, > > Firsly: I'm not an expert on this, so if anyone thinks I'm writing nonsense, > do correct me. > > There are many answers to the question "what is a type?", depending on one's > view. > > One that has been helpful to me when learning Haskell is "a type is a set of > values." When seen like this it makes sense to write: > () = { () } > Bool = { True, False } > Maybe Bool = { Nothing, Just True, Just False } > > Recursive data types have an infinite number of values. Almost all types > belong to this group. Here's one of the simplest examples: > > data Peano = Zero | Suc Peano > > There's nothing wrong with a set with an infinite number of members. > > Gregg Reynolds wrote: >> >> This gives a very interesting way of looking at Haskell type >> constructors: a value of (say) Tcon Int is anything that satisfies >> "isA Tcon Int". The tokens/values of Tcon Int may or may not >> constitute a set, but even if they, we have no way of describing the >> set's extension. > > Int has 2^32 values, just like in Java. You can verify this in GHCi: > > Prelude> (minBound, maxBound) :: (Int, Int) > (-2147483648,2147483647) > > Integer, on the other hand, represents arbitrarily big integers and > therefore has an infinite number of elements. > >> To my naive mind this sounds >> suspiciously like the set of all sets, so it's too big to be a set. > > Here you're probably thinking about the distinction between countable and > uncountable sets. See also: > > http://en.wikipedia.org/wiki/Countable_set > > Haskell has types which have uncountably many values. They are all functions > of the form A -> B, where A is an infinite type (either countably or > uncountably). > > If a set is countable, you can enumerate the set in such a way that you will > reach each member eventually. For Haskell this means that if a type "a" has > a countable number of values, you can define a list :: [a] that will contain > all of them. > > I hope this helps! Let us know if you have any other questions. > > Martijn. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgbailey at gmail.com Mon Feb 2 11:28:32 2009 From: jgbailey at gmail.com (Justin Bailey) Date: Mon Feb 2 11:18:42 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: <49870495.3010305@chalmers.se> References: <49870495.3010305@chalmers.se> Message-ID: It's not a tutorial but it covers all the relvant portions you asked about. Download the package, unzip it and you'll find my "Haskell Cheat Sheet" PDF inside: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet On Mon, Feb 2, 2009 at 6:35 AM, Emil Axelsson wrote: > Hello, > > Are there any Haskell tutorials suitable for people who don't (and possibly > don't want to) know Haskell, but just want to use an embedded language that > happens to be in Haskell? > > Such a tutorial would focus on using libraries rather than defining them. > For example, it might explain how to interpret a type signature involving > type classes, but not how to write one's own type class. > > Thanks, > > / Emil > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From lennart at augustsson.net Mon Feb 2 11:29:40 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 2 11:19:50 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> Message-ID: The Haskell function space, A->B, is not uncountable. There is only a countable number of Haskell functions you can write, so how could there be more elements in the Haskell function space? :) The explanation is that the Haskell function space is not the same as the functions space in set theory. Most importantly Haskell functions have to be monotonic (in the domain theoretic sense), so that limits the number of possible functions. http://en.wikipedia.org/wiki/Domain_theory -- Lennart On Mon, Feb 2, 2009 at 4:28 PM, Lennart Augustsson wrote: > The Haskell function space, A->B, is not uncountable. > There is only a countable number of Haskell functions you can write, > so how could there be more elements in the Haskell function space? :) > The explanation is that the Haskell function space is not the same as > the functions space in set theory. Most importantly Haskell functions > have to be monotonic (in the domain theoretic sense), so that limits > the number of possible functions. > > http://en.wikipedia.org/wiki/Domain_theory > > -- Lennart > > On Mon, Feb 2, 2009 at 3:49 PM, Martijn van Steenbergen > wrote: >> Hi Gregg, >> >> Firsly: I'm not an expert on this, so if anyone thinks I'm writing nonsense, >> do correct me. >> >> There are many answers to the question "what is a type?", depending on one's >> view. >> >> One that has been helpful to me when learning Haskell is "a type is a set of >> values." When seen like this it makes sense to write: >> () = { () } >> Bool = { True, False } >> Maybe Bool = { Nothing, Just True, Just False } >> >> Recursive data types have an infinite number of values. Almost all types >> belong to this group. Here's one of the simplest examples: >> >> data Peano = Zero | Suc Peano >> >> There's nothing wrong with a set with an infinite number of members. >> >> Gregg Reynolds wrote: >>> >>> This gives a very interesting way of looking at Haskell type >>> constructors: a value of (say) Tcon Int is anything that satisfies >>> "isA Tcon Int". The tokens/values of Tcon Int may or may not >>> constitute a set, but even if they, we have no way of describing the >>> set's extension. >> >> Int has 2^32 values, just like in Java. You can verify this in GHCi: >> >> Prelude> (minBound, maxBound) :: (Int, Int) >> (-2147483648,2147483647) >> >> Integer, on the other hand, represents arbitrarily big integers and >> therefore has an infinite number of elements. >> >>> To my naive mind this sounds >>> suspiciously like the set of all sets, so it's too big to be a set. >> >> Here you're probably thinking about the distinction between countable and >> uncountable sets. See also: >> >> http://en.wikipedia.org/wiki/Countable_set >> >> Haskell has types which have uncountably many values. They are all functions >> of the form A -> B, where A is an infinite type (either countably or >> uncountably). >> >> If a set is countable, you can enumerate the set in such a way that you will >> reach each member eventually. For Haskell this means that if a type "a" has >> a countable number of values, you can define a list :: [a] that will contain >> all of them. >> >> I hope this helps! Let us know if you have any other questions. >> >> Martijn. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From dons at galois.com Mon Feb 2 11:29:42 2009 From: dons at galois.com (Don Stewart) Date: Mon Feb 2 11:19:54 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <9979e72e0902020522y53c8c6aamad4b03d560918e1f@mail.gmail.com> References: <9979e72e0902020522y53c8c6aamad4b03d560918e1f@mail.gmail.com> Message-ID: <20090202162942.GB32310@scytale.galois.com> jwlato: > Duncan Coutts wrote: > > > > Some are trivial and should be done away with. For example the ones that > > just check if a C header / lib is present are unnecessary (and typically > > do not work correctly). The next point release of Cabal can do these > > checks automatically, eg: > > > > Configuring foo-1.0... > > cabal: Missing dependencies on foreign libraries: > > * Missing header file: foo.h > > * Missing C libraries: foo, bar, baz > > This problem can usually be solved by installing the system > > packages that provide these libraries (you may need the "-dev" > > versions). If the libraries are already installed but in a > > non-standard location then you can use the flags > > --extra-include-dirs= and --extra-lib-dirs= to specify where > > they are. > > Thank you! Thank you! Thank you! > > For those of us who want to write cross-platform (i.e. Windows) > bindings to C libraries, this is great news. It will be important now to report the lack of uses of these portability tests back to the authors of packages. A start would be to have hackage warn, I suppose. -- Don From gtener at gmail.com Mon Feb 2 11:30:01 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Mon Feb 2 11:20:12 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <498719B9.7040204@cs.tcd.ie> <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> Message-ID: <220e47b40902020830u60b48815xc00a62288ea87a5b@mail.gmail.com> Do they? Haskell is a programing language. Therefore legal Haskell types has to be represented by some string. And there are countably many strings (of which only a subset is legal type representation, but that's not important). All best Christopher Skrz?tnicki On Mon, Feb 2, 2009 at 17:09, Gregg Reynolds wrote: > On Mon, Feb 2, 2009 at 10:05 AM, Andrew Butterfield > wrote: > > Martijn van Steenbergen wrote: > >> > >>> To my naive mind this sounds > >>> suspiciously like the set of all sets, so it's too big to be a set. > >> > >> Here you're probably thinking about the distinction between countable > and > >> uncountable sets. See also: > >> > >> http://en.wikipedia.org/wiki/Countable_set > > > > No - it's even bigger than those ! > > > > He is thinking of proper classes, not sets. > > > > http://en.wikipedia.org/wiki/Class_(set_theory) > > Yes, that's my hypothesis: type constructors take us outside of set > theory (ZF set theory, at least). I just can't prove it. > > Thanks, > > g > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/0419a3a2/attachment.htm From lennart at augustsson.net Mon Feb 2 11:32:42 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 2 11:22:53 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020826y399c58a3rea2c899126550c3@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <75cc17ac0902020826y399c58a3rea2c899126550c3@mail.gmail.com> Message-ID: Thinking of types as sets is not a bad approximation. You need to add _|_ to your set of values, though. So, Bool={_|_, False, True}, Nat={_|_,Zero,Succ _|_, Succ Zero, ...} 2009/2/2 Gregg Reynolds : > Hi Martijn, > > On Mon, Feb 2, 2009 at 9:49 AM, Martijn van Steenbergen > wrote: >> >> There are many answers to the question "what is a type?", depending on >> one's >> view. >> >> One that has been helpful to me when learning Haskell is "a type is a set >> of >> values." > > That's the way I've always thought of types, never having had a good reason > to think otherwise. But it seems it doesn't work - type theory goes beyond > set theory. I've even found an online book[1] that uses type theory to > construct set theory! At least I think that's what it does (not that I > understand it.) > >>> This gives a very interesting way of looking at Haskell type >>> constructors: a value of (say) Tcon Int is anything that satisfies >>> "isA Tcon Int". The tokens/values of Tcon Int may or may not >>> constitute a set, but even if they, we have no way of describing the >>> set's extension. >> >> Int has 2^32 values, just like in Java. You can verify this in GHCi: >> > > Ok, but that's an implementation detail. My question is what is the > theoretical basis of types. > > Notice that the semantics of Haskell's built-in types are a matter of social > convention. The symbols used - Int, 0, 1, 2, ... - are well-known, and we > agree not to add data constructors. But we could if we wanted to. Say, Foo > :: Int -> Int. Then Foo 3 is an Int, distinct from all other Ints; in > particular it is not equal to "3". > > I suspect a full definition of type would have to say something about > operations. > >>> To my naive mind this sounds >>> suspiciously like the set of all sets, so it's too big to be a set. >> >> Here you're probably thinking about the distinction between countable and >> uncountable sets. See also: >> > > It could be that values of a constructed type form an uncountably large set, > rather than something too big to be a set at all. I'm afraid I don't know > how to work with such critters. > > In any case, the more interesting thing (to me) is the notion that sets > contain their members "essentially", but data types don't, as far as I can > see. > > Thanks much, > > gregg > > > [1] http://www.cs.chalmers.se/Cs/Research/Logic/book/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From emax at chalmers.se Mon Feb 2 11:39:28 2009 From: emax at chalmers.se (Emil Axelsson) Date: Mon Feb 2 11:29:39 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: References: <49870495.3010305@chalmers.se> Message-ID: <498721C0.40508@chalmers.se> Ah, that's nice! I never actually looked at your Cheat Sheet before (thought it would be much shorter and not very useful :) ). I will definitely forward this to the people in our project. Still on the lookout for a DSEL tutorial though... / Emil Justin Bailey skrev: > It's not a tutorial but it covers all the relvant portions you asked > about. Download the package, unzip it and you'll find my "Haskell > Cheat Sheet" PDF inside: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/CheatSheet > > > > On Mon, Feb 2, 2009 at 6:35 AM, Emil Axelsson wrote: >> Hello, >> >> Are there any Haskell tutorials suitable for people who don't (and possibly >> don't want to) know Haskell, but just want to use an embedded language that >> happens to be in Haskell? >> >> Such a tutorial would focus on using libraries rather than defining them. >> For example, it might explain how to interpret a type signature involving >> type classes, but not how to write one's own type class. >> >> Thanks, >> >> / Emil >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> From allbery at ece.cmu.edu Mon Feb 2 11:40:28 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Feb 2 11:30:51 2009 Subject: [Haskell-cafe] System.Posix.Files.isDirectory and System.Posix.Files.isSymbolicLink In-Reply-To: <20090202094926.0cd80828.mle+cl@mega-nerd.com> References: <20090202094926.0cd80828.mle+cl@mega-nerd.com> Message-ID: <36E85063-9635-4C1D-84C8-CE21E55D961F@ece.cmu.edu> On 2009 Feb 1, at 17:49, Erik de Castro Lopo wrote: > The following code creates a symbolic link in the current directory > and then uses System.Posix.Files.getFileStatus to get the status of > the link. > > However, isDirectory returns True and isSymbolicLink returns False > which is very different from what the stat() system call on a POSIX > system would return. I consider this a bug. Have you actually tried it? stat() on a symlink returns information about the target of the link; lstat() returns information about the link itself. These functions correspond to getFileStatus and getSymbolicLinkStatus respectively. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/57de0278/PGP.bin From martijn at van.steenbergen.nl Mon Feb 2 11:47:23 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Mon Feb 2 11:38:28 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> Message-ID: <4987239B.1020004@van.steenbergen.nl> Lennart Augustsson wrote: > The Haskell function space, A->B, is not uncountable. > There is only a countable number of Haskell functions you can write, > so how could there be more elements in the Haskell function space? :) > The explanation is that the Haskell function space is not the same as > the functions space in set theory. Most importantly Haskell functions > have to be monotonic (in the domain theoretic sense), so that limits > the number of possible functions. I was thinking about a fixed function type A -> B having uncountably many *values* (i.e. implementations). Not about the number of function types of the form A -> B. Is that what you meant? For example, fix the type to Integer -> Bool. I can't enumeratate all possible implementations of this function. Right? Martijn. From dev at mobileink.com Mon Feb 2 11:51:19 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 2 11:41:29 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <75cc17ac0902020826y399c58a3rea2c899126550c3@mail.gmail.com> Message-ID: <75cc17ac0902020851m22bb39a4r64693d25c200a93@mail.gmail.com> Hi and thanks for the response, On Mon, Feb 2, 2009 at 10:32 AM, Lennart Augustsson wrote: > Thinking of types as sets is not a bad approximation. You need to add > _|_ to your set of values, though. > > So, Bool={_|_, False, True}, Nat={_|_,Zero,Succ _|_, Succ Zero, ...} > I'm afraid I haven't yet wrapped my head around _|_ qua member of a set. In any case, I take it that sets being a reasonable /approximation/ of types means there is a difference. Back to metaphysics: you pointed out that the function space is countable, and Christopher noted that there are countably many strings that could be used to represent a function. So that answers my question about the size of e.g. Tcon Int. But then again, that's only if we're working under the assumption that the "members" of Tcon Int are those we can express with data constructors and no others. If we drop that assumption,then it seems we can't say much of anything about its size. FWIW, what started me on this is the observation that we don't really know anything about constructed types and values except that they are constructed. I.e. we know that "Foo 3" is the image of 3 under Foo, and that's all we know. Any thing else (like operations) we must construct out of stuff we do know (like Ints or Strings.) This might seem trivial, but to me it seems pretty fundamental, since it leads to the realization that we can use one thing (e.g. Ints) to talk about something we know nothing about, which seems to be what category theory is about. (Amateur speaking here.) Thanks, gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/b1fae972/attachment.htm From dpiponi at gmail.com Mon Feb 2 12:01:11 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Mon Feb 2 11:51:20 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <498719B9.7040204@cs.tcd.ie> <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> Message-ID: <625b74080902020901q33779f27kbcbee1b4a9b233d8@mail.gmail.com> On Mon, Feb 2, 2009 at 8:09 AM, Gregg Reynolds wrote: > Yes, that's my hypothesis: type constructors take us outside of set > theory (ZF set theory, at least). I just can't prove it. It's "too big" for Set Theory if you insist on representing functions in type theory as functions in set theory - ie. set(A -> B) = set(B)^set(A). But if you don't insist on such a constraint there's no problem with sets. -- Dan From lennart at augustsson.net Mon Feb 2 12:51:22 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 2 12:41:32 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020851m22bb39a4r64693d25c200a93@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <75cc17ac0902020826y399c58a3rea2c899126550c3@mail.gmail.com> <75cc17ac0902020851m22bb39a4r64693d25c200a93@mail.gmail.com> Message-ID: If we're talking Haskell types here I think it's reasonable to talk about the values of a type as those that we can actually express in the Haskell program, any other values are really besides the point. Well, if you have a more philosophical view of types then I guess there is a point, but I thought you wanted to know about Haskell types? There's nothing mysterious about _|_ being a member of a set. Say that you have a function (Int->Bool). What are the possible results when you run this function? You can get False, you can get True, and the function can fail to terminate (I'll include any kind of runtime error in this). So now we want to turn this bit of computing into mathematics, so we say that the result must belong to the set {False,True,_|_} where we've picked the name _|_ for the computation that doesn't terminate. Note that is is mathematics, there's no notion of non-termination here. The function simply maps to one of three values. There's a natural ordering of the elements {False,True,_|_}. The _|_ is less than False and less than True, whereas False and True are unordered with respect to each other. Think of this ordering as how much information you get. Non-termination is less information than a definite False or True. Domain theory deals with this kind of ordered sets. -- Lennart On Mon, Feb 2, 2009 at 4:51 PM, Gregg Reynolds wrote: > Hi and thanks for the response, > > On Mon, Feb 2, 2009 at 10:32 AM, Lennart Augustsson > wrote: >> >> Thinking of types as sets is not a bad approximation. You need to add >> _|_ to your set of values, though. >> >> So, Bool={_|_, False, True}, Nat={_|_,Zero,Succ _|_, Succ Zero, ...} > > I'm afraid I haven't yet wrapped my head around _|_ qua member of a set. In > any case, I take it that sets being a reasonable /approximation/ of types > means there is a difference. > > Back to metaphysics: you pointed out that the function space is countable, > and Christopher noted that there are countably many strings that could be > used to represent a function. So that answers my question about the size of > e.g. Tcon Int. But then again, that's only if we're working under the > assumption that the "members" of Tcon Int are those we can express with data > constructors and no others. If we drop that assumption,then it seems we > can't say much of anything about its size. > > FWIW, what started me on this is the observation that we don't really know > anything about constructed types and values except that they are > constructed. I.e. we know that "Foo 3" is the image of 3 under Foo, and > that's all we know. Any thing else (like operations) we must construct out > of stuff we do know (like Ints or Strings.) This might seem trivial, but to > me it seems pretty fundamental, since it leads to the realization that we > can use one thing (e.g. Ints) to talk about something we know nothing about, > which seems to be what category theory is about. (Amateur speaking here.) > > Thanks, > > gregg > From lennart at augustsson.net Mon Feb 2 12:56:28 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 2 12:46:39 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <4987239B.1020004@van.steenbergen.nl> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> Message-ID: You can enumerate all possible implementations of functions of type (Integer -> Bool). Just enumerate all strings, and give this to a Haskell compiler f :: Integer -> Bool f = if the compiler is happy you have an implementation. The enumerated functions do not include all mathematical functions of type (Integer -> Bool), but it does include the ones we usually mean by the type (Integer -> Bool) in Haskell. -- Lennart On Mon, Feb 2, 2009 at 4:47 PM, Martijn van Steenbergen wrote: > Lennart Augustsson wrote: >> >> The Haskell function space, A->B, is not uncountable. >> There is only a countable number of Haskell functions you can write, >> so how could there be more elements in the Haskell function space? :) >> The explanation is that the Haskell function space is not the same as >> the functions space in set theory. Most importantly Haskell functions >> have to be monotonic (in the domain theoretic sense), so that limits >> the number of possible functions. > > I was thinking about a fixed function type A -> B having uncountably many > *values* (i.e. implementations). Not about the number of function types of > the form A -> B. Is that what you meant? > > For example, fix the type to Integer -> Bool. I can't enumeratate all > possible implementations of this function. Right? > > Martijn. > From lrpalmer at gmail.com Mon Feb 2 13:06:04 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 2 12:56:15 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <4987239B.1020004@van.steenbergen.nl> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> Message-ID: <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> On Mon, Feb 2, 2009 at 9:47 AM, Martijn van Steenbergen < martijn@van.steenbergen.nl> wrote: > Lennart Augustsson wrote: > >> The Haskell function space, A->B, is not uncountable. >> There is only a countable number of Haskell functions you can write, >> so how could there be more elements in the Haskell function space? :) >> The explanation is that the Haskell function space is not the same as >> the functions space in set theory. Most importantly Haskell functions >> have to be monotonic (in the domain theoretic sense), so that limits >> the number of possible functions. >> > > I was thinking about a fixed function type A -> B having uncountably many > *values* (i.e. implementations). Not about the number of function types of > the form A -> B. Is that what you meant? > > For example, fix the type to Integer -> Bool. I can't enumeratate all > possible implementations of this function. Right? That question has kind of a crazy answer. In mathematics, Nat -> Bool is uncountable, i.e. there is no function Nat -> (Nat -> Bool) which has every function in its range. But we know we are dealing with computable functions, so we can just enumerate all implementations. So the computable functions Nat -> Bool are countable. However! If we have a function f : Nat -> Nat -> Bool, we can construct the diagonalization g : Nat -> Bool as: g n = not (f n n), with g not in the range of f. That makes Nat -> Bool "computably uncountable". In summary, the set of total computable functions Nat -> Bool is a countable set, but this fact is not observable by any algorithm. (so is it *really*countable after all? :-) Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/25c37219/attachment-0001.htm From dvde at gmx.net Mon Feb 2 13:25:02 2009 From: dvde at gmx.net (Daniel van den Eijkel) Date: Mon Feb 2 13:15:15 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> Message-ID: <49873A7E.60408@gmx.net> I had the same idea, here's my implemention, running on an old Winhugs 2001 (and GHC 6.8). regards, Daniel import System import Directory chars = map chr [32..126] string 0 = return "" string n = do c <- chars s <- string (n-1) return (c:s) mkfun n = do s <- string n return ("f :: Integer -> Bool; f = " ++ s) test fundef = do system ("del test.exe") writeFile "test.hs" (fundef ++ "; main = return ()") system ("ghc --make test.hs") b <- doesFileExist "test.exe" if b then putStrLn fundef else return () main = do let fundefs = [0..] >>= mkfun mapM_ test $ drop 1000 fundefs Lennart Augustsson schrieb: > You can enumerate all possible implementations of functions of type > (Integer -> Bool). > Just enumerate all strings, and give this to a Haskell compiler > f :: Integer -> Bool > f = > if the compiler is happy you have an implementation. > > The enumerated functions do not include all mathematical functions of > type (Integer -> Bool), but it does include the ones we usually mean > by the type (Integer -> Bool) in Haskell. > > -- Lennart > > On Mon, Feb 2, 2009 at 4:47 PM, Martijn van Steenbergen > wrote: > >> Lennart Augustsson wrote: >> >>> The Haskell function space, A->B, is not uncountable. >>> There is only a countable number of Haskell functions you can write, >>> so how could there be more elements in the Haskell function space? :) >>> The explanation is that the Haskell function space is not the same as >>> the functions space in set theory. Most importantly Haskell functions >>> have to be monotonic (in the domain theoretic sense), so that limits >>> the number of possible functions. >>> >> I was thinking about a fixed function type A -> B having uncountably many >> *values* (i.e. implementations). Not about the number of function types of >> the form A -> B. Is that what you meant? >> >> For example, fix the type to Integer -> Bool. I can't enumeratate all >> possible implementations of this function. Right? >> >> Martijn. >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/ec937f17/attachment.htm From dvde at gmx.net Mon Feb 2 13:34:18 2009 From: dvde at gmx.net (Daniel van den Eijkel) Date: Mon Feb 2 13:24:48 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <49873A7E.60408@gmx.net> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <49873A7E.60408@gmx.net> Message-ID: <49873CAA.9020704@gmx.net> oops, the '$ drop 1000' in the main function should not be there... Daniel van den Eijkel schrieb: > I had the same idea, here's my implemention, running on an old Winhugs > 2001 (and GHC 6.8). > regards, Daniel > > > import System > import Directory > > chars = map chr [32..126] > > string 0 = return "" > string n = do > c <- chars > s <- string (n-1) > return (c:s) > > mkfun n = do > s <- string n > return ("f :: Integer -> Bool; f = " ++ s) > > test fundef = do > system ("del test.exe") > writeFile "test.hs" (fundef ++ "; main = return ()") > system ("ghc --make test.hs") > b <- doesFileExist "test.exe" > if b then putStrLn fundef else return () > > main = do > let fundefs = [0..] >>= mkfun > mapM_ test $ drop 1000 fundefs > > Lennart Augustsson schrieb: >> You can enumerate all possible implementations of functions of type >> (Integer -> Bool). >> Just enumerate all strings, and give this to a Haskell compiler >> f :: Integer -> Bool >> f = >> if the compiler is happy you have an implementation. >> >> The enumerated functions do not include all mathematical functions of >> type (Integer -> Bool), but it does include the ones we usually mean >> by the type (Integer -> Bool) in Haskell. >> >> -- Lennart >> >> On Mon, Feb 2, 2009 at 4:47 PM, Martijn van Steenbergen >> wrote: >> >>> Lennart Augustsson wrote: >>> >>>> The Haskell function space, A->B, is not uncountable. >>>> There is only a countable number of Haskell functions you can write, >>>> so how could there be more elements in the Haskell function space? :) >>>> The explanation is that the Haskell function space is not the same as >>>> the functions space in set theory. Most importantly Haskell functions >>>> have to be monotonic (in the domain theoretic sense), so that limits >>>> the number of possible functions. >>>> >>> I was thinking about a fixed function type A -> B having uncountably many >>> *values* (i.e. implementations). Not about the number of function types of >>> the form A -> B. Is that what you meant? >>> >>> For example, fix the type to Integer -> Bool. I can't enumeratate all >>> possible implementations of this function. Right? >>> >>> Martijn. >>> >>> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/63f02503/attachment.htm From ketil at malde.org Mon Feb 2 13:39:44 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Feb 2 13:28:54 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> (Gregg Reynolds's message of "Mon\, 2 Feb 2009 09\:16\:43 -0600") References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> Message-ID: <87ocxkznrj.fsf@malde.org> Gregg Reynolds writes: > This gives a very interesting way of looking at Haskell type > constructors: a value of (say) Tcon Int is anything that satisfies > "isA Tcon Int". Reminiscent of arguments between dynamic and static typing camps - as far as I understand, a "dynamic type" is just a predicate. So division by zero is a "type error", since the domain of division is the type of all numbers except zero. In contrast, I've always thought of (static) types as disjoint sets of values. > My reasoning is that we can > define an infinite number of data constructors for it, including at > least all possible polynomials (by which I mean data constructors of > any arity taking args of any type). I guess I don't quite understand what you mean by "Tcon Int" above. Could you give a concrete example of such a type? > To my naive mind this sounds suspiciously like the set of all sets, > so it's too big to be a set. I suspect that since types and values are separate domains, you avoid the complications caused by self reference. > In any case, Tcon Int does not depend on any particular constructor, > just as homo sapiens does not depend on any particular man. So it > can't be a set because it doesn't have its members essentially. I don't follow this argument. Are you saying you can remove a data constructor from a type, and still have the same type? And because of this, the values of the type do not constitute a set? I guess it boils down to how "Tcon Int" does not depend on any particular constructor. -k -- If I haven't seen further, it is by standing in the footprints of giants From dev at mobileink.com Mon Feb 2 13:39:10 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 2 13:29:19 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <75cc17ac0902020826y399c58a3rea2c899126550c3@mail.gmail.com> <75cc17ac0902020851m22bb39a4r64693d25c200a93@mail.gmail.com> Message-ID: <75cc17ac0902021039h164bdd0fne3ada7a7b80a1fd8@mail.gmail.com> On Mon, Feb 2, 2009 at 11:51 AM, Lennart Augustsson wrote: > If we're talking Haskell types here I think it's reasonable to talk > about the values of a type as those that we can actually express in > the Haskell program, any other values are really besides the point. > Well, if you have a more philosophical view of types then I guess > there is a point, but I thought you wanted to know about Haskell > types? > The metaphysics thereof. ;) I want to situate them in the larger intellectual context to get a more precise answer to "what is a type, really?" > > There's nothing mysterious about _|_ being a member of a set. Say > that you have a function (Int->Bool). What are the possible results > when you run this function? You can get False, you can get True, and > the function can fail to terminate (I'll include any kind of runtime > error in this). > So now we want to turn this bit of computing into mathematics, so we > say that the result must belong to the set {False,True,_|_} where > we've picked the name _|_ for the computation that doesn't terminate. > Note that is is mathematics, there's no notion of non-termination > here. The function simply maps to one of three values. > I like that, thanks. -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/d54fcb5b/attachment.htm From leepike at gmail.com Mon Feb 2 13:43:05 2009 From: leepike at gmail.com (Lee Pike) Date: Mon Feb 2 13:33:18 2009 Subject: [Haskell-cafe] FP simulators for real-time systems? Message-ID: <5DBD4306-16F7-420C-A993-40BB0DE85DD2@gmail.com> Hello, I'm interested to hear if anyone out there has used Haskell (or other functional languages for that matter) to build simulators for real- time systems. I'm somewhat familiar with Timber and similar languages for actually constructing real-time systems. However, I'm more interested in documented uses of FP "out-of-the- box" to build simulators and associated test harnesses. Pointers to published papers are particularly appreciated. Thanks! Lee From dev at mobileink.com Mon Feb 2 14:13:43 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 2 14:04:03 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <87ocxkznrj.fsf@malde.org> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <87ocxkznrj.fsf@malde.org> Message-ID: <75cc17ac0902021113n2d566173sd84268acc11b8fca@mail.gmail.com> On Mon, Feb 2, 2009 at 12:39 PM, Ketil Malde wrote: > Gregg Reynolds writes: > > > This gives a very interesting way of looking at Haskell type > > constructors: a value of (say) Tcon Int is anything that satisfies > > "isA Tcon Int". > > Reminiscent of arguments between dynamic and static typing camps - as > far as I understand, a "dynamic type" is just a predicate. So > division by zero is a "type error", since the domain of division is > the type of all numbers except zero. > > In contrast, I've always thought of (static) types as disjoint sets of > values. > > > My reasoning is that we can > > define an infinite number of data constructors for it, including at > > least all possible polynomials (by which I mean data constructors of > > any arity taking args of any type). > > I guess I don't quite understand what you mean by "Tcon Int" above. > Could you give a concrete example of such a type? > Just shorthand for something like "data Tcon a = Dcon a", applied to Int. Any data constructor expression using an Int will yield a value of type Tcon Int. > > > To my naive mind this sounds suspiciously like the set of all sets, > > so it's too big to be a set. > > I suspect that since types and values are separate domains, you avoid > the complications caused by self reference. > > > In any case, Tcon Int does not depend on any particular constructor, > > just as homo sapiens does not depend on any particular man. So it > > can't be a set because it doesn't have its members essentially. > > I don't follow this argument. Are you saying you can remove a > data constructor from a type, and still have the same type? And > because of this, the values of the type do not constitute a set? > Yep. Well, that is /if/ you start from the "Open-World Assumption" - see http://en.wikipedia.org/wiki/Open_World_Assumption (very important in ontologies e.g. OWL and Description Logics). Just because we know that e.g. expressions like Dcon 3 yield values of type Tcon Int does not mean that we know that those are the only such expressions. So we can't really say anything about how big it can be. Who knows, it might actually be a useful distinction for an OWL reasoner in Haskell. > > I guess it boils down to how "Tcon Int" does not depend on any > particular constructor. > That seems like a good way of putting it. -g -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/d26de7ac/attachment.htm From jamiiecb at googlemail.com Mon Feb 2 14:15:03 2009 From: jamiiecb at googlemail.com (Jamie Brandon) Date: Mon Feb 2 14:05:14 2009 Subject: [Haskell-cafe] FP simulators for real-time systems? In-Reply-To: <5DBD4306-16F7-420C-A993-40BB0DE85DD2@gmail.com> References: <5DBD4306-16F7-420C-A993-40BB0DE85DD2@gmail.com> Message-ID: <10ed1a750902021115nfb5dce0y5bc1b3a53ba78381@mail.gmail.com> Opis is an ocaml library for implementing reactive systems where the same code can either be executed, run in a simulator or used as a specification in a formal model checker. The model checking is only possible because referential transparency massively reduces the state space of the program. http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/ Flask is a similar haskell project which generates code for sensor networks. I don't know if they've gone as far down the testing/modelling route. http://www.eecs.harvard.edu/~mainland/flask/ The general theme is promising - reducing mutable state makes it much easier to automate reasoning about code. Jamie On Mon, Feb 2, 2009 at 6:43 PM, Lee Pike wrote: > Hello, > > I'm interested to hear if anyone out there has used Haskell (or other > functional languages for that matter) to build simulators for real-time > systems. > > I'm somewhat familiar with Timber and similar > languages for actually constructing real-time systems. However, I'm more > interested in documented uses of FP "out-of-the-box" to build simulators > and associated test harnesses. > > Pointers to published papers are particularly appreciated. > > Thanks! > Lee > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jake at pikewerks.com Mon Feb 2 14:15:59 2009 From: jake at pikewerks.com (Jake McArthur) Date: Mon Feb 2 14:06:09 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: <49871D0D.6060101@chalmers.se> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49871D0D.6060101@chalmers.se> Message-ID: <4987466F.1010000@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Emil Axelsson wrote: | Well, I guess I was asking for a tutorial which covers everything except | the parts that are not normally relevant for a DSEL user. For example, I | would expect the following to be left out: | | * Definition of data types and classes | * Laziness | * Monad internals | * IO | * etc. | | Things that I think should be covered: | | * Polymorphism | * Higher-order functions | * Lists | * Recursion | * Monadic combinators | * etc. | | Of course, the requirements may vary from case to case, but you get the | idea. I think that the contents of the two lists would vary so dramatically from case to case that writing a generic tutorial of this sort would likely be impossible. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmHRm8ACgkQye5hVyvIUKk1+ACdF4b6m/+NWR56AqbTLhGWxb3b fFwAn3f6AHnbGionwlYsa47Vnz7ZW4VC =UTae -----END PGP SIGNATURE----- From mail at joachim-breitner.de Mon Feb 2 14:24:32 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon Feb 2 14:13:59 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> Message-ID: <1233602672.3890.65.camel@localhost> Hi, Am Montag, den 02.02.2009, 11:06 -0700 schrieb Luke Palmer: > That question has kind of a crazy answer. > > In mathematics, Nat -> Bool is uncountable, i.e. there is no function > Nat -> (Nat -> Bool) which has every function in its range. > > But we know we are dealing with computable functions, so we can just > enumerate all implementations. So the computable functions Nat -> > Bool are countable. > > However! If we have a function f : Nat -> Nat -> Bool, we can > construct the diagonalization g : Nat -> Bool as: g n = not (f n n), > with g not in the range of f. That makes Nat -> Bool "computably > uncountable". That argument has a flaw. Just because we have a function in the mathematical sense that sends ? to (Nat -> Bool) does not mean that we have Haskell function f of that type that we can use to construct g. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/19bf7473/attachment.bin From wchogg at gmail.com Mon Feb 2 14:39:23 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Mon Feb 2 14:29:33 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> Message-ID: <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> 2009/1/29 Conal Elliott : > Hi Achim, > > I came to the same conclusion: I want to sweep aside these OO, imperative > toolkits, and replace them with something "genuinely functional", which for > me means having a precise & simple compositional (denotational) semantics. > Something meaningful, formally tractable, and powefully compositional from > the ground up. As long as we build on complex legacy libraries (Gtk, > wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse yet, > drawn into) their ad hoc mental models and system designs. > > As Meister Eckhart said, "Only the hand that erases can write the true > thing." I think working on a purely functional widget toolkit would actually be a really cool project. Do you have any ideas, though, on what should be the underlying primitives? The initial gut feeling I have is that one should just ignore any notion of actually displaying widgets & instead focus on a clean algebra of how to 'add' widgets that relates the concepts of inheritance & relative position. What I mean by inheritance, here, is how to direct a flow of 'events'. I don't necessarily mean events in the Reactive sense, because I think it'd be important to make the model completely independent of how time & actual UI actions are handled. Any thoughts to throw in, here? Cheers, C From john at n-brain.net Mon Feb 2 14:58:45 2009 From: john at n-brain.net (John A. De Goes) Date: Mon Feb 2 14:49:00 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> Message-ID: <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> The actual presentation and layout of widgets would be better handled by a DSL such as CSS (which is, in fact, declarative in nature), while event logic would be best handled purely in Haskell. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: > 2009/1/29 Conal Elliott : >> Hi Achim, >> >> I came to the same conclusion: I want to sweep aside these OO, >> imperative >> toolkits, and replace them with something "genuinely functional", >> which for >> me means having a precise & simple compositional (denotational) >> semantics. >> Something meaningful, formally tractable, and powefully >> compositional from >> the ground up. As long as we build on complex legacy libraries (Gtk, >> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or >> worse yet, >> drawn into) their ad hoc mental models and system designs. >> >> As Meister Eckhart said, "Only the hand that erases can write the >> true >> thing." > > I think working on a purely functional widget toolkit would actually > be a really cool project. Do you have any ideas, though, on what > should be the underlying primitives? > > The initial gut feeling I have is that one should just ignore any > notion of actually displaying widgets & instead focus on a clean > algebra of how to 'add' widgets that relates the concepts of > inheritance & relative position. What I mean by inheritance, here, is > how to direct a flow of 'events'. I don't necessarily mean events in > the Reactive sense, because I think it'd be important to make the > model completely independent of how time & actual UI actions are > handled. > > Any thoughts to throw in, here? > > Cheers, > C > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From noteed at gmail.com Mon Feb 2 15:09:19 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 2 14:59:30 2009 Subject: [Haskell-cafe] why typeRepArgs (typeOf "hello") is [Char] ? Message-ID: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> Hello, With Data.Typeable : *Graph> typeRepArgs (typeOf 1) [] *Graph> typeRepArgs (typeOf 'a') [] *Graph> typeRepArgs (typeOf True) [] *Graph> typeRepArgs (typeOf "hello") [Char] I don't understand why the latter is not []. Could someone explain it ? Thank you, Thu From jonathanccast at fastmail.fm Mon Feb 2 15:11:58 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Feb 2 15:04:11 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <220e47b40902020830u60b48815xc00a62288ea87a5b@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <498719B9.7040204@cs.tcd.ie> <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> <220e47b40902020830u60b48815xc00a62288ea87a5b@mail.gmail.com> Message-ID: <1233605518.4102.16.camel@jcchost> On Mon, 2009-02-02 at 17:30 +0100, Krzysztof Skrz?tnicki wrote: > Do they? Haskell is a programing language. Therefore legal Haskell > types has to be represented by some string. And there are countably > many strings (of which only a subset is legal type representation, but > that's not important). Haskell possesses models[1] in which the carriers of all types are countable. Haskell also possesses the models[2] which do assign uncountable carriers to several Haskell types --- a -> b whenever a has an infinite carrier (and b is not a degenerate type of the form newtype B = B B ), [b] under the same conditions on b, etc. In many cases, these are the most insightful models, and I those models are what people mean when they talk about e.g. [Int] having an un-countable denotation. jcc [1] IIUC all models based on recursion theory have this property [2] IIUC most models based on domain theory have this property From jonathanccast at fastmail.fm Mon Feb 2 15:15:27 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Feb 2 15:07:37 2009 Subject: [Haskell-cafe] why typeRepArgs (typeOf "hello") is [Char] ? In-Reply-To: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> References: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> Message-ID: <1233605727.4102.20.camel@jcchost> On Mon, 2009-02-02 at 21:09 +0100, minh thu wrote: > Hello, > > With Data.Typeable : > > *Graph> typeRepArgs (typeOf 1) > [] > *Graph> typeRepArgs (typeOf 'a') > [] > *Graph> typeRepArgs (typeOf True) > [] > *Graph> typeRepArgs (typeOf "hello") > [Char] > > I don't understand why the latter is not []. Could someone explain it ? Because ("hello" :: [] Char)? Prelude> :t "hello" "hello" :: [Char] jcc From rmm-haskell at z.odi.ac Mon Feb 2 15:18:34 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Mon Feb 2 15:08:48 2009 Subject: [Haskell-cafe] why typeRepArgs (typeOf "hello") is [Char] ? In-Reply-To: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> References: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> Message-ID: The type of "hello" is String, which is [Char], which is really [] Char (that is, the list type of kind * -> *, applied to Char). 1, 'a', and True are all simple types (I'm sure there's a more particular term, maybe "monomorphic"?) with no type arguments. [] has a type argument, Char. Consider: Prelude Data.Typeable> typeRepArgs (typeOf (Just 1)) [Integer] and Prelude Data.Typeable> typeRepArgs (typeOf (Left 'a' :: Either Char Int)) [Char,Int] -- typeRepArgs is giving you the arguments of the root type application, [] (list) in your case, Maybe and Either for the two examples I gave. Does this make sense? -Ross On Feb 2, 2009, at 3:09 PM, minh thu wrote: > Hello, > > With Data.Typeable : > > *Graph> typeRepArgs (typeOf 1) > [] > *Graph> typeRepArgs (typeOf 'a') > [] > *Graph> typeRepArgs (typeOf True) > [] > *Graph> typeRepArgs (typeOf "hello") > [Char] > > I don't understand why the latter is not []. Could someone explain > it ? > > Thank you, > Thu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ketil at malde.org Mon Feb 2 15:25:11 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Feb 2 15:14:21 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902021113n2d566173sd84268acc11b8fca@mail.gmail.com> (Gregg Reynolds's message of "Mon\, 2 Feb 2009 13\:13\:43 -0600") References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <87ocxkznrj.fsf@malde.org> <75cc17ac0902021113n2d566173sd84268acc11b8fca@mail.gmail.com> Message-ID: <87k588zivs.fsf@malde.org> Gregg Reynolds writes: > Just shorthand for something like "data Tcon a = Dcon a", applied to Int. > Any data constructor expression using an Int will yield a value of type Tcon > Int. Right. But then the set of values is isomorphic to the set of Ints, right? >> I don't follow this argument. Are you saying you can remove a >> data constructor from a type, and still have the same type? And >> because of this, the values of the type do not constitute a set? > Yep. I don't see why you would consider it the same type. Since, given any two data types, I could remove all the data constructors, this would make them, and by extension, all types the same, wouldn't it? -k -- If I haven't seen further, it is by standing in the footprints of giants From noteed at gmail.com Mon Feb 2 15:27:47 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 2 15:17:56 2009 Subject: [Haskell-cafe] why typeRepArgs (typeOf "hello") is [Char] ? In-Reply-To: References: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> Message-ID: <40a414c20902021227g1d7f1082r8cb0a6041a781dde@mail.gmail.com> Thanks. Could you add to your explanation this one : *Graph> typeRepArgs (typeOf (+)) [Integer,Integer -> Integer] In fact, I tried to write a function that would give the types used by a function, for instance [Integer, Integer, Integer] for (+) (the last one would be the 'return' type). So I applied recursively typeRepArgs to the second element of the list (if any) (here, Integer -> Integer). It worked well until I tried it on a function like :: Char -> Int -> [Char] where the last recursive call gives [Char] instead of []. Is it possible to write such a function ? Thank you, Thu 2009/2/2 Ross Mellgren : > The type of "hello" is String, which is [Char], which is really [] Char > (that is, the list type of kind * -> *, applied to Char). > > 1, 'a', and True are all simple types (I'm sure there's a more particular > term, maybe "monomorphic"?) with no type arguments. > > [] has a type argument, Char. > > Consider: > > Prelude Data.Typeable> typeRepArgs (typeOf (Just 1)) > [Integer] > > and > > Prelude Data.Typeable> typeRepArgs (typeOf (Left 'a' :: Either Char Int)) > [Char,Int] > > -- typeRepArgs is giving you the arguments of the root type application, [] > (list) in your case, Maybe and Either for the two examples I gave. > > Does this make sense? > > -Ross > > On Feb 2, 2009, at 3:09 PM, minh thu wrote: > >> Hello, >> >> With Data.Typeable : >> >> *Graph> typeRepArgs (typeOf 1) >> [] >> *Graph> typeRepArgs (typeOf 'a') >> [] >> *Graph> typeRepArgs (typeOf True) >> [] >> *Graph> typeRepArgs (typeOf "hello") >> [Char] >> >> I don't understand why the latter is not []. Could someone explain it ? >> >> Thank you, >> Thu >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > From haskell at list.mightyreason.com Mon Feb 2 15:27:47 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Mon Feb 2 15:18:09 2009 Subject: [Haskell-cafe] ANN: regex-posix-unittest-1.0 AND regex-posix-0.94.1 AND regex-tdfa-0.97.1 Message-ID: <49875743.2090502@list.mightyreason.com> I have three announcements to make about regex-* related packages. The regex-posix-0.94.1 package update provides better semantics for multiple matches. Below version 0.94, if any match was empty the matching would stop. Now the empty match is returned and the position is incremented and the searching continues. The regex-tdfa-0.71.1 package update provides the same new multiple match semantics. It also fixes a bug I found. I know of no outstanding bugs in regex-tdfa, and version 0.71.1 now passes all the tests used in regex-posix-unittest-1.0 announced below. We should care about the correctness of our operating system libraries. To help with this, I have a NEW package to announce: regex-posix-unittest-1.0 The accompanying wiki page is http://www.haskell.org/haskellwiki/Regex_Posix This new package provides an executable called regex-posix-unittest which you can install as --user or --global. The regex-posix-unittest executable with no arguments runs a suite of unit tests, all of which are described by text files in the package, the format is documented in the wiki page. By editing the text files in the package you can add to or delete from the unit tests being run. With two arguments the program expects the text first and the pattern second and will run just that match and print all the results. How does regex-posix-unittest help us care about the OS libraries? The regex-posix distributed in the GHC bundle uses the OS C library's "regex.h" API. The regex-posix-unittest package will quite likely show you that your OS C library "regex.h" API is full of bugs. If you are on Linux, it will show you a plethora of GLIBC bugs in Posix conformance. If you are on OS X, FreeBSD, or NetBSD, it will show you many bugs including a critical bug where it fail to find a match where one actually exists. These bugs in the OS library are inherited by your "sed" program as well as regex-posix and Haskell. If you are on Windows, or OpenBSD, or Solaris, or anything else, then please update the wiki page at http://www.haskell.org/haskellwiki/Regex_Posix or email me with your results so I can update the wiki. You may have evil and ingenious tests of Posix extended regular expressions to add to the test suite. Adding them is easy and if you send them to me I will put them in an updated version of regex-posix-unittest. Cheers, Chris From rmm-haskell at z.odi.ac Mon Feb 2 15:38:58 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Mon Feb 2 15:29:12 2009 Subject: [Haskell-cafe] why typeRepArgs (typeOf "hello") is [Char] ? In-Reply-To: <40a414c20902021227g1d7f1082r8cb0a6041a781dde@mail.gmail.com> References: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> <40a414c20902021227g1d7f1082r8cb0a6041a781dde@mail.gmail.com> Message-ID: <08B5442A-1442-4D9A-81A8-7359BA7DAFC3@z.odi.ac> Sure: (+) :: Integer -> Integer -> Integer (really Num a => a -> a -> a, but we'll use the defaulted one) Which is really (+) :: -> Integer (-> Integer Integer) (that is, the function type constructor is * -> * -> * and right associative) So when you say typeRepArgs (typeOf (+)) you get Integer and (-> Integer Integer), which pretty-prints as (Integer -> Integer) It is possible, but you have to check if the type constructor is really a function type, e.g.: import Data.Typeable funTyCon :: TyCon funTyCon = mkTyCon "->" argsOf :: TypeRep -> [TypeRep] argsOf ty | typeRepTyCon ty == funTyCon = let (x:y:[]) = typeRepArgs ty in x : argsOf y | otherwise = [] *Main Data.Typeable> let f = (undefined :: Int -> Char -> String -> ()) *Main Data.Typeable> argsOf (typeOf f) [Int,Char,[Char]] -Ross On Feb 2, 2009, at 3:27 PM, minh thu wrote: > Thanks. Could you add to your explanation this one : > > *Graph> typeRepArgs (typeOf (+)) > [Integer,Integer -> Integer] > > In fact, I tried to write a function that would give the types used by > a function, > for instance [Integer, Integer, Integer] for (+) (the last one would > be the 'return' type). > So I applied recursively typeRepArgs to the second element of the list > (if any) (here, Integer -> Integer). > > It worked well until I tried it on a function like :: Char -> Int -> > [Char] where > the last recursive call gives [Char] instead of []. > > Is it possible to write such a function ? > > Thank you, > Thu > > > 2009/2/2 Ross Mellgren : >> The type of "hello" is String, which is [Char], which is really [] >> Char >> (that is, the list type of kind * -> *, applied to Char). >> >> 1, 'a', and True are all simple types (I'm sure there's a more >> particular >> term, maybe "monomorphic"?) with no type arguments. >> >> [] has a type argument, Char. >> >> Consider: >> >> Prelude Data.Typeable> typeRepArgs (typeOf (Just 1)) >> [Integer] >> >> and >> >> Prelude Data.Typeable> typeRepArgs (typeOf (Left 'a' :: Either Char >> Int)) >> [Char,Int] >> >> -- typeRepArgs is giving you the arguments of the root type >> application, [] >> (list) in your case, Maybe and Either for the two examples I gave. >> >> Does this make sense? >> >> -Ross >> >> On Feb 2, 2009, at 3:09 PM, minh thu wrote: >> >>> Hello, >>> >>> With Data.Typeable : >>> >>> *Graph> typeRepArgs (typeOf 1) >>> [] >>> *Graph> typeRepArgs (typeOf 'a') >>> [] >>> *Graph> typeRepArgs (typeOf True) >>> [] >>> *Graph> typeRepArgs (typeOf "hello") >>> [Char] >>> >>> I don't understand why the latter is not []. Could someone explain >>> it ? >>> >>> Thank you, >>> Thu >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> From noteed at gmail.com Mon Feb 2 15:49:57 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 2 15:40:07 2009 Subject: [Haskell-cafe] why typeRepArgs (typeOf "hello") is [Char] ? In-Reply-To: <08B5442A-1442-4D9A-81A8-7359BA7DAFC3@z.odi.ac> References: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> <40a414c20902021227g1d7f1082r8cb0a6041a781dde@mail.gmail.com> <08B5442A-1442-4D9A-81A8-7359BA7DAFC3@z.odi.ac> Message-ID: <40a414c20902021249o2c487ef8oedd463223af013e3@mail.gmail.com> Thanks a lot ! 2009/2/2 Ross Mellgren : > Sure: > > (+) :: Integer -> Integer -> Integer (really Num a => a -> a -> a, but > we'll use the defaulted one) > > Which is really > > (+) :: -> Integer (-> Integer Integer) (that is, the function type > constructor is * -> * -> * and right associative) > > So when you say typeRepArgs (typeOf (+)) you get Integer and (-> Integer > Integer), which pretty-prints as (Integer -> Integer) > > It is possible, but you have to check if the type constructor is really a > function type, e.g.: > > import Data.Typeable > > funTyCon :: TyCon > funTyCon = mkTyCon "->" > > argsOf :: TypeRep -> [TypeRep] > argsOf ty > | typeRepTyCon ty == funTyCon = let (x:y:[]) = typeRepArgs ty in x : > argsOf y > | otherwise = [] > > > *Main Data.Typeable> let f = (undefined :: Int -> Char -> String -> ()) > *Main Data.Typeable> argsOf (typeOf f) > [Int,Char,[Char]] > > -Ross > > > On Feb 2, 2009, at 3:27 PM, minh thu wrote: > >> Thanks. Could you add to your explanation this one : >> >> *Graph> typeRepArgs (typeOf (+)) >> [Integer,Integer -> Integer] >> >> In fact, I tried to write a function that would give the types used by >> a function, >> for instance [Integer, Integer, Integer] for (+) (the last one would >> be the 'return' type). >> So I applied recursively typeRepArgs to the second element of the list >> (if any) (here, Integer -> Integer). >> >> It worked well until I tried it on a function like :: Char -> Int -> >> [Char] where >> the last recursive call gives [Char] instead of []. >> >> Is it possible to write such a function ? >> >> Thank you, >> Thu >> >> >> 2009/2/2 Ross Mellgren : >>> >>> The type of "hello" is String, which is [Char], which is really [] Char >>> (that is, the list type of kind * -> *, applied to Char). >>> >>> 1, 'a', and True are all simple types (I'm sure there's a more particular >>> term, maybe "monomorphic"?) with no type arguments. >>> >>> [] has a type argument, Char. >>> >>> Consider: >>> >>> Prelude Data.Typeable> typeRepArgs (typeOf (Just 1)) >>> [Integer] >>> >>> and >>> >>> Prelude Data.Typeable> typeRepArgs (typeOf (Left 'a' :: Either Char Int)) >>> [Char,Int] >>> >>> -- typeRepArgs is giving you the arguments of the root type application, >>> [] >>> (list) in your case, Maybe and Either for the two examples I gave. >>> >>> Does this make sense? >>> >>> -Ross >>> >>> On Feb 2, 2009, at 3:09 PM, minh thu wrote: >>> >>>> Hello, >>>> >>>> With Data.Typeable : >>>> >>>> *Graph> typeRepArgs (typeOf 1) >>>> [] >>>> *Graph> typeRepArgs (typeOf 'a') >>>> [] >>>> *Graph> typeRepArgs (typeOf True) >>>> [] >>>> *Graph> typeRepArgs (typeOf "hello") >>>> [Char] >>>> >>>> I don't understand why the latter is not []. Could someone explain it ? >>>> >>>> Thank you, >>>> Thu >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> > > From conal at conal.net Mon Feb 2 16:15:07 2009 From: conal at conal.net (Conal Elliott) Date: Mon Feb 2 16:05:19 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> Message-ID: Could CSS give us semantic clarity? - Conal On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes wrote: > > The actual presentation and layout of widgets would be better handled by a > DSL such as CSS (which is, in fact, declarative in nature), while event > logic would be best handled purely in Haskell. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > > On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: > > 2009/1/29 Conal Elliott : >> >>> Hi Achim, >>> >>> I came to the same conclusion: I want to sweep aside these OO, imperative >>> toolkits, and replace them with something "genuinely functional", which >>> for >>> me means having a precise & simple compositional (denotational) >>> semantics. >>> Something meaningful, formally tractable, and powefully compositional >>> from >>> the ground up. As long as we build on complex legacy libraries (Gtk, >>> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse >>> yet, >>> drawn into) their ad hoc mental models and system designs. >>> >>> As Meister Eckhart said, "Only the hand that erases can write the true >>> thing." >>> >> >> I think working on a purely functional widget toolkit would actually >> be a really cool project. Do you have any ideas, though, on what >> should be the underlying primitives? >> >> The initial gut feeling I have is that one should just ignore any >> notion of actually displaying widgets & instead focus on a clean >> algebra of how to 'add' widgets that relates the concepts of >> inheritance & relative position. What I mean by inheritance, here, is >> how to direct a flow of 'events'. I don't necessarily mean events in >> the Reactive sense, because I think it'd be important to make the >> model completely independent of how time & actual UI actions are >> handled. >> >> Any thoughts to throw in, here? >> >> Cheers, >> C >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/ddb7fc02/attachment.htm From dave at zednenem.com Mon Feb 2 16:27:04 2009 From: dave at zednenem.com (David Menendez) Date: Mon Feb 2 16:17:15 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <75cc17ac0902010936r523c6fd3i7064dc1e813e94b1@mail.gmail.com> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <49a77b7a0901311314q298a1986sbcab5cc95c32c186@mail.gmail.com> <75cc17ac0902010936r523c6fd3i7064dc1e813e94b1@mail.gmail.com> Message-ID: <49a77b7a0902021327g4cee2d5fy7343d97af8a7e25e@mail.gmail.com> On Sun, Feb 1, 2009 at 12:36 PM, Gregg Reynolds wrote: > On Sat, Jan 31, 2009 at 3:14 PM, David Menendez wrote: >> >> There's a paper about defining catamorphisms for GADTs and nested >> recursive types that models type constructors that way. > > If you recall a title or author I'll google it. I believe it was "Foundations for Structural Programming with GADTs". >>> So this gives us two functors, but they operate on different things, >>> and I don't see how to get from one to the other in CT terms. Or >>> rather, they're obviously related, but I don't see how to express that >>> relation formally. >> >> Again, what sort of relationship are you thinking of? Data > > Ok, good question. I guess the problem I'm having is one of > abstraction management. CT prefers to disregard the "contents" of its > objects, imposing a kind of blood-brain barrier between the object and > its internal structure. Typical definitions of functor, for example, > make no reference to the "elements" of an object; a functor is just a > pair of morphisms, one taking objects to objects, the other morphisms > to morphisms. This leaves the naive reader (i.e. me) to wonder how it > is that the internal stuff is related to the functor stuff. Right. The reason the definition of functor doesn't say anything about the "internal stuff" is that there are plenty of categories where there *is* no internal stuff. So for categories like Set or Mon, where the objects to have elements, category theory uses morphisms to describe their internal structure. For example, a set is an object in Set, and its elements are morphisms from the singleton set. So if I have some operation that creates a monoid from a set, and transforms set functions into monoid homomorphisms in a way that respects identity functions and composition, then I have a functor from Set to Mon. (For example, the free monoid that Wren mentioned.) Whatever internal stuff is going on will be reflected in the morphism part of the functor, because otherwise the functor can't map the morphisms correctly. > For example: is it true that the object component of a functor > necessarily "has" a bundle of specific functions relating the internal > "elements" of the objects? If so, is the object component merely an > abstraction of the bundle? Or is it ontologically a different thing? Let me try to give an illustrative example. Consider a category A with a single object and a bunch of morphisms from that object to itself. Now, the object itself isn't interesting, which is why I didn't give it a name. It's not any kind of set, and the morphisms aren't functions: composition just combines them in some unspecified manner. Because A is a category, we know that there's an identity morphism id, such that f . id = f = id . f, and we know that f . (g . h) = (f . g) . h. In other words, the morphisms in a single-object category form a monoid. What's more, since we don't care about what the morphisms are, we can take any monoid and create a single-object category. For example, we could define a category Plus where the morphisms are natural numbers, the identity morphism is 0, and morphism composition is addition. Now let's say we have to single-object categories, A and B, and a functor F : A -> B. What do we know about F? We know that F maps the object in A to the object in B, and it maps the identity morphism in A to the identity morphism in B, and that for any morphisms f and g in A, F(f) . F(g) = F(f . g). In other words, F is a monoid homomorphism (that is, a mapping from one monoid to another that respects the identity and the monoid operation). We can define other functors, too. For example, a functor P : Plus -> Set. We'll map the object in Plus to N (the set of natural numbers), and every morphism n in Plus to a function (\x -> n + x) : N -> N. You can prove for yourself that P(0) gives the identity morphism for N, and that P(m + n) = P(m) . P(n). So P is a functor whose object component doesn't have a bundle of specific functions relating the internal elements of the objects. All the interesting stuff in P takes place in the morphism map. Does that help at all? (A side note: As I said, for any monoid X, we can create a category C(X), and it's obvious that for any monoid homomorphism f : X -> Y, we can create a functor C(f) : C(X) -> C(Y). It turns out that for any monoids X, Y, and Z and homomorphisms f : Y -> Z and g : X -> Y, C(f) . C(g) = C(f . g). So C is a functor from the category of monads to the category of categories.) -- Dave Menendez From conal at conal.net Mon Feb 2 16:28:11 2009 From: conal at conal.net (Conal Elliott) Date: Mon Feb 2 16:18:26 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> Message-ID: On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg wrote: > 2009/1/29 Conal Elliott : > > Hi Achim, > > > > I came to the same conclusion: I want to sweep aside these OO, imperative > > toolkits, and replace them with something "genuinely functional", which > for > > me means having a precise & simple compositional (denotational) > semantics. > > Something meaningful, formally tractable, and powefully compositional > from > > the ground up. As long as we build on complex legacy libraries (Gtk, > > wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse > yet, > > drawn into) their ad hoc mental models and system designs. > > > > As Meister Eckhart said, "Only the hand that erases can write the true > > thing." > > I think working on a purely functional widget toolkit would actually > be a really cool project. Do you have any ideas, though, on what > should be the underlying primitives? > Again, my goal would not be a "purely functional" library, because even IO is "purely functional". My goal is a "denotational" library, i.e., one that has an elegant (denotational) semantics, and hence is powerfully compositional and good for reasoning. The initial gut feeling I have is that one should just ignore any > notion of actually displaying widgets & instead focus on a clean > algebra of how to 'add' widgets that relates the concepts of > inheritance & relative position. What I mean by inheritance, here, is > how to direct a flow of 'events'. I don't necessarily mean events in > the Reactive sense, because I think it'd be important to make the > model completely independent of how time & actual UI actions are > handled. > > Any thoughts to throw in, here? > > Cheers, > C > The Fruit paper, "Genuinely Functional User Interfaces", gives a semantic model, which could be a starting place for thinking about possibilities. At the very least, I'd like to take it to 3D. The idea there is that a UI is a function from flows (behaviors/signals) to flows, where the input includes mouse & keyboard stuff and the output includes an image. An image is, as in Pan, a function from R^2 -> Color, where color includes partial opacity. When UIs are transformed in time and/or space, they correspondingly see inversely-transformed input, thanks to a general principle of transforming functions. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/f96a040f/attachment.htm From john at n-brain.net Mon Feb 2 16:29:52 2009 From: john at n-brain.net (John A. De Goes) Date: Mon Feb 2 16:20:04 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> Message-ID: <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: > Could CSS give us semantic clarity? - Conal > > On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes > wrote: > > The actual presentation and layout of widgets would be better > handled by a DSL such as CSS (which is, in fact, declarative in > nature), while event logic would be best handled purely in Haskell. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > > On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: > > 2009/1/29 Conal Elliott : > Hi Achim, > > I came to the same conclusion: I want to sweep aside these OO, > imperative > toolkits, and replace them with something "genuinely functional", > which for > me means having a precise & simple compositional (denotational) > semantics. > Something meaningful, formally tractable, and powefully > compositional from > the ground up. As long as we build on complex legacy libraries (Gtk, > wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or > worse yet, > drawn into) their ad hoc mental models and system designs. > > As Meister Eckhart said, "Only the hand that erases can write the true > thing." > > I think working on a purely functional widget toolkit would actually > be a really cool project. Do you have any ideas, though, on what > should be the underlying primitives? > > The initial gut feeling I have is that one should just ignore any > notion of actually displaying widgets & instead focus on a clean > algebra of how to 'add' widgets that relates the concepts of > inheritance & relative position. What I mean by inheritance, here, is > how to direct a flow of 'events'. I don't necessarily mean events in > the Reactive sense, because I think it'd be important to make the > model completely independent of how time & actual UI actions are > handled. > > Any thoughts to throw in, here? > > Cheers, > C > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/cd4432fb/attachment.htm From jonathanccast at fastmail.fm Mon Feb 2 16:33:40 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Mon Feb 2 16:25:52 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> Message-ID: <1233610420.4102.38.camel@jcchost> On Mon, 2009-02-02 at 13:28 -0800, Conal Elliott wrote: > On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg > wrote: > 2009/1/29 Conal Elliott : > > Hi Achim, > > > > I came to the same conclusion: I want to sweep aside these > OO, imperative > > toolkits, and replace them with something "genuinely > functional", which for > > me means having a precise & simple compositional > (denotational) semantics. > > Something meaningful, formally tractable, and powefully > compositional from > > the ground up. As long as we build on complex legacy > libraries (Gtk, > > wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling > against (or worse yet, > > drawn into) their ad hoc mental models and system designs. > > > > As Meister Eckhart said, "Only the hand that erases can > write the true > > thing." > > > I think working on a purely functional widget toolkit would > actually > be a really cool project. Do you have any ideas, though, on > what > should be the underlying primitives? > > Again, my goal would not be a "purely functional" library, because > even IO is "purely functional". My goal is a "denotational" library, > i.e., one that has an elegant (denotational) semantics, and hence is > powerfully compositional and good for reasoning. +1 jcc From dave at zednenem.com Mon Feb 2 16:37:24 2009 From: dave at zednenem.com (David Menendez) Date: Mon Feb 2 16:27:35 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <87k588zivs.fsf@malde.org> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <87ocxkznrj.fsf@malde.org> <75cc17ac0902021113n2d566173sd84268acc11b8fca@mail.gmail.com> <87k588zivs.fsf@malde.org> Message-ID: <49a77b7a0902021337j735b6a5ewba3b68169f7553bb@mail.gmail.com> On Mon, Feb 2, 2009 at 3:25 PM, Ketil Malde wrote: > Gregg Reynolds writes: > >> Just shorthand for something like "data Tcon a = Dcon a", applied to Int. >> Any data constructor expression using an Int will yield a value of type Tcon >> Int. > > Right. But then the set of values is isomorphic to the set of Ints, > right? Only if you're ignoring non-terminating values. Otherwise, you have to deal with the fact that Tcon Int contains _|_ and DCon _|_. -- Dave Menendez From wchogg at gmail.com Mon Feb 2 16:57:00 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Mon Feb 2 16:47:10 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> Message-ID: <814617240902021357o758b222ds6707e8e266c5772c@mail.gmail.com> On Mon, Feb 2, 2009 at 3:28 PM, Conal Elliott wrote: > On Mon, Feb 2, 2009 at 11:39 AM, Creighton Hogg wrote: >> >> I think working on a purely functional widget toolkit would actually >> be a really cool project. Do you have any ideas, though, on what >> should be the underlying primitives? > > Again, my goal would not be a "purely functional" library, because even IO > is "purely functional". My goal is a "denotational" library, i.e., one that > has an elegant (denotational) semantics, and hence is powerfully > compositional and good for reasoning. Well, that is essentially what I meant but your point about clarity is taken. A truly mathematical semantic model is above & beyond what is meant by "purely functional". >> The initial gut feeling I have is that one should just ignore any >> notion of actually displaying widgets & instead focus on a clean >> algebra of how to 'add' widgets that relates the concepts of >> inheritance & relative position. What I mean by inheritance, here, is >> how to direct a flow of 'events'. I don't necessarily mean events in >> the Reactive sense, because I think it'd be important to make the >> model completely independent of how time & actual UI actions are >> handled. >> >> Any thoughts to throw in, here? >> >> Cheers, >> C > > > The Fruit paper, "Genuinely Functional User Interfaces", gives a semantic > model, which could be a starting place for thinking about possibilities. At > the very least, I'd like to take it to 3D. The idea there is that a UI is a > function from flows (behaviors/signals) to flows, where the input includes > mouse & keyboard stuff and the output includes an image. An image is, as in > Pan, a function from R^2 -> Color, where color includes partial opacity. > When UIs are transformed in time and/or space, they correspondingly see > inversely-transformed input, thanks to a general principle of transforming > functions. Thanks. I'm reading it now. Cheers, C From dons at galois.com Mon Feb 2 17:03:44 2009 From: dons at galois.com (Don Stewart) Date: Mon Feb 2 16:54:26 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> Message-ID: <20090202220344.GA13113@whirlpool.galois.com> ndmitchell: > Hi > > > So actually just having more Windows users subscribed to cabal-devel and > > commenting on tickets would be very useful, even if you do not have much > > time for hacking. > > I believe that as soon as a Windows user starts doing that you'll > start asking them for patches :-) > > There are a number of reasons that we have fewer Windows developers: > > * Some of it comes down to social reasons - for some reason it seems > to be socially acceptable to belittle Windows (and Windows users) on > the Haskell mailing lists and #haskell. > > * Some of it comes down to technical issues - for example not having > cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake > (although I've heard everyone argue against me, I've not yet heard a > Windows person argue against me). > > * Part of it comes down to most developers not being Windows people. > > * A little is because Windows is a second class citizen even in the > libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a > badly typed expression! How would you like it if your OS was listed as > Wine? Things like this tell me that Haskell isn't Windows friendly, at > best its windows tolerant. > > * Things like Gtk2hs, which Windows users need building for them, > don't release in sync with GHC, which makes it hard to use. > > * Windows machines don't usually have a C compiler, and have a very > different environment - while the rest of the world is starting to > standardise. > > I gave up on fighting the fight when people decided not to bundle > cabal.exe with Windows - and now I'm too busy with my day job... Now > I'd say Duncan is the most vocal and practical Windows developer, even > overlooking the fact he doesn't run Windows. GHC doesn't bundle with cabal-install on any system. What is needed is not for the GHC team to be doing Windows platform packages, but for the Windows Haskell devs to build their own system, as happens on all the Unices. Take GHC's release, wrap it up with native installers, throw in useful libraries and executables like cabal. Done. It's not the GHC compiler team's job to build distro-specific bundles. So, windows@haskell.org anyone? Get the wiki going, get the set of tasks created. -- Don From ok at cs.otago.ac.nz Mon Feb 2 17:04:24 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Feb 2 16:54:43 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <498719B9.7040204@cs.tcd.ie> <75cc17ac0902020809l25bf1297jd327e827203b6e8d@mail.gmail.com> Message-ID: Talking about the class of all Haskell types is a little tricky. If one program has data Foo x = Ick x | Ack x and another program has data Bar y = Ack y | Ick y are {Program1}Foo and {Program2}Bar the same type or not? They are certainly isomorphic. Any Haskell program can be represented as a sequence of bytes. (Proof: take your source tree, and use tar, pax, cpio, or whatever.) There is therefore a countable infinity of Haskell programs. In Haskell 98, a program can generate at most a countable infinity of types (taking a 'type' here to be an element of the "Herbrand base" generated by the type constructors, speaking somewhat loosely). So surely there can be at most a countable infinity of Haskell types? From dons at galois.com Mon Feb 2 17:04:35 2009 From: dons at galois.com (Don Stewart) Date: Mon Feb 2 16:55:16 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> Message-ID: <20090202220435.GB13113@whirlpool.galois.com> pocmatos: > Hi all, > > Much is talked that Haskell, since it is purely functional is easier > to be verified. > However, most of the research I have seen in software verification > (either through model checking or theorem proving) targets C/C++ or > subsets of these. What's the state of the art of automatically > verifying properties of programs written in Haskell? > State of the art is translating subsets of Haskell to Isabelle, and verifying them. Using model checkers to verify subsets, or extracting Haskell from Agda or Coq. -- Don From lrpalmer at gmail.com Mon Feb 2 17:30:50 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 2 17:20:59 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <1233602672.3890.65.camel@localhost> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> Message-ID: <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> 2009/2/2 Joachim Breitner > Hi, > > Am Montag, den 02.02.2009, 11:06 -0700 schrieb Luke Palmer: > > > That question has kind of a crazy answer. > > > > In mathematics, Nat -> Bool is uncountable, i.e. there is no function > > Nat -> (Nat -> Bool) which has every function in its range. > > > > But we know we are dealing with computable functions, so we can just > > enumerate all implementations. So the computable functions Nat -> > > Bool are countable. > > > > However! If we have a function f : Nat -> Nat -> Bool, we can > > construct the diagonalization g : Nat -> Bool as: g n = not (f n n), > > with g not in the range of f. That makes Nat -> Bool "computably > > uncountable". > > That argument has a flaw. Just because we have a function in the > mathematical sense that sends ? to (Nat -> Bool) does not mean that we > have Haskell function f of that type that we can use to construct g. What argument? What was I trying to prove? But I admit that my notation is confusing; I am not distinguishing between Haskell types and their denotations. I'll be more precise: I will use N for the set of naturals, Nat for the Haskell type of (strict) naturals, 2 for the set {0,1}, Bool for the Haskell type True|False, (->) for a mathematical function, (~>) for a *total* computable function in Haskell. N -> 2 is uncountable, meaning there is no surjection N -> (N -> 2). Nat ~> Bool is countable, meaning there is a surjection N -> (Nat ~> Bool). Enumerate all program source codes (which is countable, so N -> SourceCode), and pick out the ones which denote a total computable function Nat ~> Bool. But Nat ~> Bool is *computably* uncountable, meaning there is no injective function Nat ~> (Nat ~> Bool), by the diagonal argument above. That's what I meant. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/f656bd2f/attachment.htm From ganesh.sittampalam at credit-suisse.com Mon Feb 2 17:32:47 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Feb 2 17:23:43 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <20090202220344.GA13113@whirlpool.galois.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> <20090202220344.GA13113@whirlpool.galois.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCB86@ELON17P32001A.csfb.cs-group.com> Don Stewart wrote: > GHC doesn't bundle with cabal-install on any system. > > What is needed is not for the GHC team to be doing Windows platform > packages, but for the Windows Haskell devs to build their own system, > as happens on all the Unices. > > Take GHC's release, wrap it up with native installers, throw in > useful libraries and executables like cabal. Done. > > It's not the GHC compiler team's job to build distro-specific bundles. > > So, windows@haskell.org anyone? Get the wiki going, get the set of > tasks created. Isn't the Haskell Platform going to do all this? Shouldn't interested people just help out there? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From mail at joachim-breitner.de Mon Feb 2 17:36:34 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon Feb 2 17:25:58 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> Message-ID: <1233614194.3890.84.camel@localhost> Hi, Am Montag, den 02.02.2009, 15:30 -0700 schrieb Luke Palmer: > That's what I meant. thanks for the clarification, I indeed were confused by the notation and saw Haskell functions where you meant mathematical functions. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/da11ffde/attachment.bin From ryani.spam at gmail.com Mon Feb 2 17:39:25 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Feb 2 17:29:36 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> Message-ID: <2f9b2d30902021439j7a9e8486q213de0cce5fbeb0b@mail.gmail.com> 2009/2/2 Luke Palmer : > However! If we have a function f : Nat -> Nat -> Bool, we can construct the > diagonalization g : Nat -> Bool as: g n = not (f n n), with g not in the > range of f. That makes Nat -> Bool "computably uncountable". This is making my head explode. How is g not in the range of f? In particular, f is a program, which I can easily implement; given: compiler :: String -> Maybe (Nat -> Bool) mkAllStrings :: () -> [String] -- enumerates all possible strings I can write f as f n = validPrograms () !! n where validPrograms = map fromJust . filter isJust . map compiler . mkAllStrings Now, in particular, mkAllStrings will generate the following string at some index, call it "stringIndexOfG": g n = not (f n n) This is a valid program, so the compiler will compile it successfully, and therefore there is some index "validProgramIndexOfG" less than or equal to "stringIndexOfG" which generates this program. But your argument seems to hold as well, so where is the contradiction? -- ryan From bugfact at gmail.com Mon Feb 2 17:40:56 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Feb 2 17:31:08 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: Well, that is also the idea behind Microsoft's WPF/XAML: they provide a declarative approach to describe the widget tree (specifying what it is, not what is does), and a GUI toolkit (Expression Blend) for artists and designers so they can use a high level tool to build the GUI. You can even define limited behavior and animation in a declarative way. However, I believe those "designer friendly" tools are not designed by designers but by programmers who claim to think what designers want. I work everyday with artists and designers, and these people are frustrated by the limitations and erratic behavior (read "side effects") of most "designer friendly" tools... Furthermore making even a simple GUI requires a lot of collaboration between the developer and the designer, and this screams for a language that both can understand and reason about :-) Also, this approach is nice for "simple" or (should I say mostly form-based GUIs), but as soon as you get into something more complicated, this design won't help you. For example, try to make a mathematical editor like that... or a diagram editor... IMO any GUI framework should work for complicated GUIs as well as easy form based one. I feel the model -> presentation -> view -> reactivity -> model' cycle is still the best approach today for building complex GUIs. Never start with widgets, these are just a possible representation of a model. Although this paradigm comes from Smalltalk, MVC is really functional in my opinion.. If you make that approach compositional *and* fast, you have a winner. Something like FRUIT on steroids (Grapefruit? ;-) but then of course you are stuck with the arrows syntax which feels like drawing graphical circuits with a text editor ;-) 2009/2/2 John A. De Goes > > The size, color, and layout of widgets has no effect on interaction > semantics and is best pushed elsewhere, into a designer-friendly realm such > as CSS. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: > > Could CSS give us semantic clarity? - Conal > > On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes wrote: > >> >> The actual presentation and layout of widgets would be better handled by a >> DSL such as CSS (which is, in fact, declarative in nature), while event >> logic would be best handled purely in Haskell. >> >> Regards, >> >> John A. De Goes >> N-BRAIN, Inc. >> The Evolution of Collaboration >> >> http://www.n-brain.net | 877-376-2724 x 101 >> >> >> On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: >> >> 2009/1/29 Conal Elliott : >>> >>>> Hi Achim, >>>> >>>> I came to the same conclusion: I want to sweep aside these OO, >>>> imperative >>>> toolkits, and replace them with something "genuinely functional", which >>>> for >>>> me means having a precise & simple compositional (denotational) >>>> semantics. >>>> Something meaningful, formally tractable, and powefully compositional >>>> from >>>> the ground up. As long as we build on complex legacy libraries (Gtk, >>>> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse >>>> yet, >>>> drawn into) their ad hoc mental models and system designs. >>>> >>>> As Meister Eckhart said, "Only the hand that erases can write the true >>>> thing." >>>> >>> >>> I think working on a purely functional widget toolkit would actually >>> be a really cool project. Do you have any ideas, though, on what >>> should be the underlying primitives? >>> >>> The initial gut feeling I have is that one should just ignore any >>> notion of actually displaying widgets & instead focus on a clean >>> algebra of how to 'add' widgets that relates the concepts of >>> inheritance & relative position. What I mean by inheritance, here, is >>> how to direct a flow of 'events'. I don't necessarily mean events in >>> the Reactive sense, because I think it'd be important to make the >>> model completely independent of how time & actual UI actions are >>> handled. >>> >>> Any thoughts to throw in, here? >>> >>> Cheers, >>> C >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/6efecb5d/attachment.htm From dpiponi at gmail.com Mon Feb 2 17:41:36 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Mon Feb 2 17:31:45 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> Message-ID: <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> 2009/2/2 Luke Palmer : > But Nat ~> Bool is computably uncountable, meaning there is no injective (surjective?) > function Nat ~> (Nat ~> Bool), by the diagonal argument above. Given that the Haskell functions Nat -> Bool are computably uncountable, you'd expect that for any Haskell function (Nat -> Bool) -> Nat there'd always be two elements that get mapped to the same value. So here's a programming challenge: write a total function (expecting total arguments) toSame :: ((Nat -> Bool) -> Nat) -> (Nat -> Bool,Nat -> Bool) that finds a pair that get mapped to the same Nat. Ie. f a==f b where (a,b) = toSame f -- Dan (PS I think this is hard. But my brain might be misfiring so it might be trivial.) From marco-oweber at gmx.de Mon Feb 2 17:43:28 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Feb 2 17:33:39 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> Message-ID: <20090202224328.GA7016@gmx.de> On Mon, Feb 02, 2009 at 10:07:57AM +0000, Neil Mitchell wrote: > Hi The nix package manager (although beeing primarly a linux tool) can run on cygwin as well (at least it did some time ago).. I'd suggest trying that to package windows libraries. It dose generate tag files for you automatically as well. At least it can build dependencies such as C libraries and so on for you automatically as well. Unfortunately I don't have time to work on the windows port. The cool thing about nix is: You can always switch back to the previous generation if something breaks. It organizes the packages like a memory management system. You only reference the target and the deps in between will be build / removed automatically for you if they are no longer used when running the nix garbage collector. There is another drawback: It definitely only works on a ntfs partition. On the other hand it does also support binary distributions and install software by clicking on links. In the end this is perfect for developping (IMHO) even if you have to learn a lot at the beginning. My major problem hindering my starting to work on this is that cygwin doesn't run on Vista running in kvm/ qemu. sh.exe exits and that's it. So if you have a solution for that I'd consider resuming work on it Sincerly Marc Weber From hjgtuyl at chello.nl Mon Feb 2 17:43:26 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Mon Feb 2 17:33:50 2009 Subject: [Haskell-cafe] pure crisis :) In-Reply-To: <593855719.20090201221918@gmail.com> References: <593855719.20090201221918@gmail.com> Message-ID: On Sun, 01 Feb 2009 20:19:18 +0100, Bulat Ziganshin wrote: > Hello haskell-cafe, > > pure functional denotation for crisis: > > (_|_) > Well, some experts say, the crisis has reached it's bottom. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From mail at joachim-breitner.de Mon Feb 2 17:44:51 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon Feb 2 17:34:16 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> Message-ID: <1233614691.3890.86.camel@localhost> Hi, Am Montag, den 02.02.2009, 14:41 -0800 schrieb Dan Piponi: > 2009/2/2 Luke Palmer : > > > But Nat ~> Bool is computably uncountable, meaning there is no injective (surjective?) > > function Nat ~> (Nat ~> Bool), by the diagonal argument above. > > Given that the Haskell functions Nat -> Bool are computably > uncountable, you'd expect that for any Haskell function (Nat -> Bool) > -> Nat there'd always be two elements that get mapped to the same > value. > > So here's a programming challenge: write a total function (expecting > total arguments) toSame :: ((Nat -> Bool) -> Nat) -> (Nat -> Bool,Nat > -> Bool) that finds a pair that get mapped to the same Nat. > > Ie. f a==f b where (a,b) = toSame f > -- > Dan > > (PS I think this is hard. But my brain might be misfiring so it might > be trivial.) > toSame _ = (const True, const True) ;-) Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/96238046/attachment.bin From marco-oweber at gmx.de Mon Feb 2 17:45:40 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Feb 2 17:35:51 2009 Subject: [Haskell-cafe] Bytestrings vs String? Message-ID: <20090202224540.GB24610@gmx.de> A lot of people are suggesting using Bytestrings for performance, strictness whatsoever reasons. However how well do they talk to other libraries? One I've in mind is hslogger right now. Should hslogger be implemented using Strings or Bytestrings ? Should there be two versions? hslogger-bytestring and hslogger-string? Or would it be better to implement one String class which can cope with everthing (performance will drop, won't it?) I feel it would make sense to talk about how to provide this? In the future I'd like to explore using haskell for web developement. So speed does matter. And I don't want my server to convert from Bytestrings to Strings and back multiple times.. So is the best we could do compile the same library twice using different flags ? One providing a Bytestring API, the other using Strings? Cluttering up code by from to Bytestring conversions doesn't look compelling to me. Thoughts? Marc Weber From dons at galois.com Mon Feb 2 17:52:18 2009 From: dons at galois.com (Don Stewart) Date: Mon Feb 2 17:43:04 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCB86@ELON17P32001A.csfb.cs-group.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> <20090202220344.GA13113@whirlpool.galois.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB86@ELON17P32001A.csfb.cs-group.com> Message-ID: <20090202225218.GE13113@whirlpool.galois.com> ganesh.sittampalam: > Don Stewart wrote: > > > GHC doesn't bundle with cabal-install on any system. > > > > What is needed is not for the GHC team to be doing Windows platform > > packages, but for the Windows Haskell devs to build their own system, > > as happens on all the Unices. > > > > Take GHC's release, wrap it up with native installers, throw in > > useful libraries and executables like cabal. Done. > > > > It's not the GHC compiler team's job to build distro-specific bundles. > > > > So, windows@haskell.org anyone? Get the wiki going, get the set of > > tasks created. > > Isn't the Haskell Platform going to do all this? Shouldn't interested > people just help out there? > The platform is a set of blessed libraries and tools. The distros will still need to package that. To do that for Windows, we're still going to need a windows packaging team, along side Debian, Arch, Gentoo, Mac etc. -- Don From marco-oweber at gmx.de Mon Feb 2 17:56:07 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Mon Feb 2 17:46:20 2009 Subject: [Haskell-cafe] hslogger bugs or features - patches In-Reply-To: <20090201012818.GA11418@gmx.de> References: <20090201012818.GA11418@gmx.de> Message-ID: <20090202225607.GB7016@gmx.de> > ====================================================================== > issue 1 > > That's not the most awkward thing: > When logging to "A.B.C" hslogger does add 3 loggers to the global > logger Map: > "A" > "A.B" > "A.B.C" > all three inheriting the default priority level of the default > rootLogger "" > > A test application illustrating this (feature ?) > > module Main where > -- packages: hslogger > import System.Log.Logger as HL > import System.Log.Handler.Simple as HL > > main = do > -- the default logger logs to stderr level WARNING > -- that's why the following message should be shown > > -- a) > logM "A.B.C" HL.ALERT "ALERT test, should be shown and should create the sublogger" > > -- b) > updateGlobalLogger rootLoggerName (setLevel EMERGENCY) > > logM "A.B.C" HL.ALERT "ALERT test, should not be shown cause we have changed to EMERGENCY" > > which prints: > > tmp %./test1 > /tmp nixos > ALERT test, should be shown and should create the sublogger > ALERT test, should not be shown cause we have changed to EMERGENCY I've written some patches increasing speed by 30%. See the benchmark. You can get them by cloning git://mawercer.de/hslogger; (branch hslogger_updates) I've replaced the internal representation (Map name Logger) by a tree. Only logging to a logger does no longer add a new node (which cloned the priority level in the past causing issue 1) The basic interface updateLogger name (set priority or add handlers) and logM is still the same. The logM is based on MonadIO now. So you no longer have to call liftIO yourself.. Also I've removed the standard setup logging to stderr. There is a setupLogging function instead.. Why? I can think of some use cases where logging to stderr doesn't make sense and it took me too much time figuring out how to remve the old stderr logger (I didn't find a nice solution without changing the exposed API) I don't want to start using my "personal" copy of hslogger. That's why I'd like to ask you wether you consider these changes beeing improvements although they break existing code (You'll have do add that initialization line) I also wonder wether it's worth using Bytestrings instead of Strings? I've not spend to much time on updating all the documentation yet.. If you'd like to ensure that a use case sill works add another test case please. You can also push to that git repository. Sincerly Marc Weber From jgoerzen at complete.org Mon Feb 2 17:58:28 2009 From: jgoerzen at complete.org (John Goerzen) Date: Mon Feb 2 17:48:40 2009 Subject: [Haskell-cafe] Bytestrings vs String? In-Reply-To: <20090202224540.GB24610@gmx.de> References: <20090202224540.GB24610@gmx.de> Message-ID: <49877A94.9020402@complete.org> Marc Weber wrote: > A lot of people are suggesting using Bytestrings for performance, > strictness whatsoever reasons. > > However how well do they talk to other libraries? > > One I've in mind is hslogger right now. > > Should hslogger be implemented using Strings or Bytestrings ? > > Should there be two versions? > > hslogger-bytestring and hslogger-string? > > Or would it be better to implement one String class which can cope > with everthing (performance will drop, won't it?) Not necessarily. hslogger could easily accept both, and deal with it appropriately under the hood. If whatever it prefers under the hood is supplied to it, I don't see any reason that performance would suffer. I very much suspect though that you would not likely see a measurable performance difference either way with hslogger in real-world situations. -- John From jgoerzen at complete.org Mon Feb 2 18:00:27 2009 From: jgoerzen at complete.org (John Goerzen) Date: Mon Feb 2 17:50:37 2009 Subject: [Haskell-cafe] Re: hslogger bugs or features? In-Reply-To: <20090201012818.GA11418@gmx.de> References: <20090201012818.GA11418@gmx.de> Message-ID: <49877B0B.5030905@complete.org> I haven't had the time to study your question in detail yet, but I would start by directing you here: http://www.python.org/doc/current/library/logging.html#module-logging hslogger is heavily based upon an earlier version of the Python logging module. I had some experience with it and found it to work well, and thus based the hslogger design upon it. -- John Marc Weber wrote: > Following the advice on the hslogger wiki > (http://software.complete.org/software/wiki/hslogger) > I'm posting my thoughts about hslogger here: > > What is wired? > This piece of code (src/System/Log/Logger.hs): > > parentHandlers name = > let pname = (head . drop 1 . reverse . componentsOfName) name > in do > [...] > next <- parentHandlers pname > return ((handlers parent) ++ next) > > Why? > Because when logging to "A.B.C" it splits the String once to get > ["A","B","C"], then it drops the last part and runs the same again for > "A.B" and so on.. > So A string is split > 3 times for one logging action. I think this is a > waste of cpu cycles.. I'm going to improve this. While reading the code > i noticed two issues: > > ====================================================================== > issue 1 > > That's not the most awkward thing: > When logging to "A.B.C" hslogger does add 3 loggers to the global > logger Map: > "A" > "A.B" > "A.B.C" > all three inheriting the default priority level of the default > rootLogger "" > > A test application illustrating this (feature ?) > > module Main where > -- packages: hslogger > import System.Log.Logger as HL > import System.Log.Handler.Simple as HL > > main = do > -- the default logger logs to stderr level WARNING > -- that's why the following message should be shown > > -- a) > logM "A.B.C" HL.ALERT "ALERT test, should be shown and should create the sublogger" > > -- b) > updateGlobalLogger rootLoggerName (setLevel EMERGENCY) > > logM "A.B.C" HL.ALERT "ALERT test, should not be shown cause we have changed to EMERGENCY" > > which prints: > > tmp %./test1 > /tmp nixos > ALERT test, should be shown and should create the sublogger > ALERT test, should not be shown cause we have changed to EMERGENCY > > which is quite confusing because I haven't told hslogger explicitely > to use a log level printing ALERTs on "A.B.C". so I'd expect that only > the first message is shown. This behaviour is explained by the > inheritance of the loglevel when hslogger creates them (without > attaching handlers) automatically. > > I don't want the logging behaviour depend on wether a log line has been > emitted before or not. > Do you agree? Have I missed something? > > > > solution: > > replacing > > data Logger = Logger { level :: Priority, > handlers :: [HandlerT], > name :: String} > > type LogTree = Map.Map String Logger > > by a real log tree: > > data LogTree = LogTree { > level :: Priority, -- level only applies to handlers, not to subLoggers > handlers :: [HandlerT], > subLoggers :: Map.Map String LogTree > } > > ====================================================================== > issue 2 > > The second ineresting point is (bug or feature?) that you can make the > root logger shut up by setting different log levels to sub loggers: > > this sample does illustrate it: > > module Main where > -- packages: hslogger > import System.Log.Logger as HL > import System.Log.Handler.Simple as HL > > main = do > updateGlobalLogger "" (setLevel DEBUG) > updateGlobalLogger "A" (setLevel EMERGENCY) > logM "A" HL.ALERT "ALERT test, should not be shown cause we have > changed to EMERGENCY" > > > It doesn't print anything although the default log handler on root (="") > is set to loglever DEBUG. So there is no way to get all logmessages > without removing all all setLevel calls to subloggers? > Is this desirable? > > ====================================================================== > my conclusion: > > About issue 1 I think its a bug > About issue 2 I don't know. I think there should be a way to get all log > messages. So I feel this is a bug as well. > > I neither have checkeg the logcxx nor log4j nor the reference > implementation in python. > > Thoughts? > > Sincerly > Marc Weber > From lrpalmer at gmail.com Mon Feb 2 18:14:49 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 2 18:04:58 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> Message-ID: <7ca3f0160902021514i554c8408h63bcc04fbba0bd54@mail.gmail.com> On Mon, Feb 2, 2009 at 3:41 PM, Dan Piponi wrote: > 2009/2/2 Luke Palmer : > > > But Nat ~> Bool is computably uncountable, meaning there is no injective > (surjective?) > > function Nat ~> (Nat ~> Bool), by the diagonal argument above. > > Given that the Haskell functions Nat -> Bool are computably > uncountable, you'd expect that for any Haskell function (Nat -> Bool) > -> Nat there'd always be two elements that get mapped to the same > value. > > So here's a programming challenge: write a total function (expecting > total arguments) toSame :: ((Nat -> Bool) -> Nat) -> (Nat -> Bool,Nat > -> Bool) that finds a pair that get mapped to the same Nat. > > Ie. f a==f b where (a,b) = toSame f Presumably under the condition that a /= b. It's unlikely that you can. At least you can't use Escardo's trick, because while the space of pairs of cantor spaces (cantor space = Nat -> Bool) is compact, the space of pairs of *different* cantors spaces is not. This is witnessed by the following function: f (a,b) = length (takeWhile id (zipWith (==) a b)) This function finds the first index at which they differ. Since they are guaranteed to be different, this function is total. Thus, if the space of nonequal cantor spaces were compact, then so too would be Nat, which we know is not the case. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/b0d8bc40/attachment.htm From rwbarton at math.harvard.edu Mon Feb 2 18:18:40 2009 From: rwbarton at math.harvard.edu (Reid Barton) Date: Mon Feb 2 18:08:54 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> Message-ID: <20090202231840.GB2182@rwbarton.mit.edu> On Mon, Feb 02, 2009 at 02:41:36PM -0800, Dan Piponi wrote: > 2009/2/2 Luke Palmer : > > > But Nat ~> Bool is computably uncountable, meaning there is no injective (surjective?) > > function Nat ~> (Nat ~> Bool), by the diagonal argument above. > > Given that the Haskell functions Nat -> Bool are computably > uncountable, you'd expect that for any Haskell function (Nat -> Bool) > -> Nat there'd always be two elements that get mapped to the same > value. > > So here's a programming challenge: write a total function (expecting > total arguments) toSame :: ((Nat -> Bool) -> Nat) -> (Nat -> Bool,Nat > -> Bool) that finds a pair that get mapped to the same Nat. > > Ie. f a==f b where (a,b) = toSame f (Warning: sketchy argument ahead.) Let f :: (Nat -> Bool) -> Nat be a total function and let g0 = const True. The application f g0 can only evaluate g0 at finitely many values, so f g0 = f (< k) for any k larger than all these values. So we can write > toSame f = (const True, head [ (< k) | k <- [1..], f (const True) == f (< k) ]) and toSame is total on total inputs. Regards, Reid From ramsdell0 at gmail.com Mon Feb 2 18:22:38 2009 From: ramsdell0 at gmail.com (John D. Ramsdell) Date: Mon Feb 2 18:12:48 2009 Subject: [Haskell-cafe] Parallel term reduction In-Reply-To: <7ca3f0160902020115k2b4974e7w6b560ebcc7badc73@mail.gmail.com> References: <7687290b0902012026s2a2e0619tecc227d33ec56afc@mail.gmail.com> <7ca3f0160902020115k2b4974e7w6b560ebcc7badc73@mail.gmail.com> Message-ID: <7687290b0902021522l21e1f517mda3c37d01ad53d57@mail.gmail.com> > On Sun, Feb 1, 2009 at 9:26 PM, John D. Ramsdell > wrote: >> >> I have a reduction system in which a rule takes a term and returns a >> set of terms. >> The reduction system creates a tree that originates at a starting >> value called the root. >> For most problems, the reduction system terminates, but a step count >> limit protects >> from non-termination. > > That's typically a bad idea. Instead, use laziness to protect from > nontermination. For example, in this case, we can output a collection of > items lazily, and then take a finite amount of the output (or check whether > the output is longer than some length), without having to evaluate all of > it. Very good suggestion. In my code, I should "take limit" on the generated list, and fail if the length of the list is limit. Sounds easy. I'll study your parallel solution tonight after work. Thank you. Here is an interesting fact about my term reduction system. The binary relation that defines reduction is slightly different from the usual. It's a relation between terms and sets of terms. Furthermore, some normal forms can be identified as answers, and some normal forms are dead ends. When applying a rule, it doesn't matter which set in the relation is used as the result. The answer normal forms will all be the same. If the rule produces the empty set for some choice, all other choices will lead only to normal forms that are dead ends. John From haskell at brecknell.org Mon Feb 2 18:23:46 2009 From: haskell at brecknell.org (Matthew Brecknell) Date: Mon Feb 2 18:14:02 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> Message-ID: <1233617026.8488.3.camel@localhost> Luke Palmer wrote: > and pick out the ones which denote a total computable function [...] How important is totality to this argument? If it is important, how do you decide it? From lrpalmer at gmail.com Mon Feb 2 18:30:57 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 2 18:21:07 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <1233617026.8488.3.camel@localhost> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> <1233617026.8488.3.camel@localhost> Message-ID: <7ca3f0160902021530s6de4cfb3v11ab9e85e674af82@mail.gmail.com> On Mon, Feb 2, 2009 at 4:23 PM, Matthew Brecknell wrote: > Luke Palmer wrote: > > and pick out the ones which denote a total computable function [...] > > How important is totality to this argument? If it is important, how do you > decide it? It is at the very essence of the argument; it is why there are countable sets which are computably uncountable: (nonconstructive) mathematics does not need to decide, only programs need to do that :-) Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/4105076b/attachment.htm From conal at conal.net Mon Feb 2 18:31:49 2009 From: conal at conal.net (Conal Elliott) Date: Mon Feb 2 18:22:00 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: Hi John, I'm not sure how to interpret your remarks about "has no effect" and "is best". I guess they're subjective opinions, but maybe I'm missing something objective in your intent. I can see, for instance, at least one way in which layout has a direct and enormous effect on interaction semantics. And while I can see some benefits in choosing CSS, I also see some significant drawbacks, and I wonder if you've factored these drawbacks into your "is best". - Conal 2009/2/2 John A. De Goes > > The size, color, and layout of widgets has no effect on interaction > semantics and is best pushed elsewhere, into a designer-friendly realm such > as CSS. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: > > Could CSS give us semantic clarity? - Conal > > On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes wrote: > >> >> The actual presentation and layout of widgets would be better handled by a >> DSL such as CSS (which is, in fact, declarative in nature), while event >> logic would be best handled purely in Haskell. >> >> Regards, >> >> John A. De Goes >> N-BRAIN, Inc. >> The Evolution of Collaboration >> >> http://www.n-brain.net | 877-376-2724 x 101 >> >> >> On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: >> >> 2009/1/29 Conal Elliott : >>> >>>> Hi Achim, >>>> >>>> I came to the same conclusion: I want to sweep aside these OO, >>>> imperative >>>> toolkits, and replace them with something "genuinely functional", which >>>> for >>>> me means having a precise & simple compositional (denotational) >>>> semantics. >>>> Something meaningful, formally tractable, and powefully compositional >>>> from >>>> the ground up. As long as we build on complex legacy libraries (Gtk, >>>> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse >>>> yet, >>>> drawn into) their ad hoc mental models and system designs. >>>> >>>> As Meister Eckhart said, "Only the hand that erases can write the true >>>> thing." >>>> >>> >>> I think working on a purely functional widget toolkit would actually >>> be a really cool project. Do you have any ideas, though, on what >>> should be the underlying primitives? >>> >>> The initial gut feeling I have is that one should just ignore any >>> notion of actually displaying widgets & instead focus on a clean >>> algebra of how to 'add' widgets that relates the concepts of >>> inheritance & relative position. What I mean by inheritance, here, is >>> how to direct a flow of 'events'. I don't necessarily mean events in >>> the Reactive sense, because I think it'd be important to make the >>> model completely independent of how time & actual UI actions are >>> handled. >>> >>> Any thoughts to throw in, here? >>> >>> Cheers, >>> C >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/70308280/attachment.htm From lrpalmer at gmail.com Mon Feb 2 18:54:23 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 2 18:44:32 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <20090202231840.GB2182@rwbarton.mit.edu> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> <20090202231840.GB2182@rwbarton.mit.edu> Message-ID: <7ca3f0160902021554i785069b0jcc88ac3f8a13f226@mail.gmail.com> On Mon, Feb 2, 2009 at 4:18 PM, Reid Barton wrote: > > So here's a programming challenge: write a total function (expecting > > total arguments) toSame :: ((Nat -> Bool) -> Nat) -> (Nat -> Bool,Nat > > -> Bool) that finds a pair that get mapped to the same Nat. > > > > Ie. f a==f b where (a,b) = toSame f > > (Warning: sketchy argument ahead.) Let f :: (Nat -> Bool) -> Nat be a > total function and let g0 = const True. The application f g0 can > only evaluate g0 at finitely many values, so f g0 = f (< k) for any k > larger than all these values. So we can write > > > toSame f = (const True, head [ (< k) | k <- [1..], f (const True) == f (< > k) ]) > > and toSame is total on total inputs. Well done! That's not sketchy at all! There is always such a k (when the result type of f has decidable equality) and it is the "modulus of uniform continuity" of f. This is computable directly, but the implementation you've provided might come up with a smaller one that still works (since you only need to differentiate between const True, not all other streams). I guess I should hold off on conjecturing the impossibility of things... :-) Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/5eac6b14/attachment.htm From benjovi at gmx.net Mon Feb 2 18:55:08 2009 From: benjovi at gmx.net (Benedikt Huber) Date: Mon Feb 2 18:45:18 2009 Subject: [Haskell-cafe] Re: type metaphysics In-Reply-To: <2f9b2d30902021439j7a9e8486q213de0cce5fbeb0b@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <2f9b2d30902021439j7a9e8486q213de0cce5fbeb0b@mail.gmail.com> Message-ID: <498787DC.5030709@gmx.net> Ryan Ingram schrieb: > 2009/2/2 Luke Palmer : >> However! If we have a function f : Nat -> Nat -> Bool, we can construct the >> diagonalization g : Nat -> Bool as: g n = not (f n n), with g not in the >> range of f. That makes Nat -> Bool "computably uncountable". > > This is making my head explode. How is g not in the range of f? > > In particular, f is a program, which I can easily implement; given: f is 'easy to implement' if it enumerates all functions, not just total ones. Otherwise, f is hard to implement ;) In the first case, if we have (f n n) = _|_, then g n = not (f n n) = _|_ as well, so the diagonalization argument does not hold anymore. But I do agree that proofs by contradiction do not map well to haskell ... benedikt > > compiler :: String -> Maybe (Nat -> Bool) > mkAllStrings :: () -> [String] -- enumerates all possible strings > > I can write f as > > f n = validPrograms () !! n > where > validPrograms = map fromJust . filter isJust . map compiler . mkAllStrings > > Now, in particular, mkAllStrings will generate the following string at > some index, call it "stringIndexOfG": > > > > > g n = not (f n n) > > This is a valid program, so the compiler will compile it successfully, > and therefore there is some index "validProgramIndexOfG" less than or > equal to "stringIndexOfG" which generates this program. > > But your argument seems to hold as well, so where is the contradiction? > > -- ryan From dbueno at gmail.com Mon Feb 2 19:27:28 2009 From: dbueno at gmail.com (Denis Bueno) Date: Mon Feb 2 19:17:37 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <20090202220435.GB13113@whirlpool.galois.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> Message-ID: <6dbd4d000902021627w7ec9e909x25a9221bf3993de6@mail.gmail.com> On Mon, Feb 2, 2009 at 15:04, Don Stewart wrote: > pocmatos: >> Hi all, >> >> Much is talked that Haskell, since it is purely functional is easier > > to be verified. > However, most of the research I have seen in software > verification > (either through model checking or theorem proving) > targets C/C++ or > subsets of these. What's the state of the art of > automatically > verifying properties of programs written in Haskell? >> > > State of the art is translating subsets of Haskell to Isabelle, and > verifying them. Using model checkers to verify subsets, or extracting > Haskell from Agda or Coq. Don, can you give some pointers to literature on this, if any? That is, any documentation of a verification effort of Haskell code with Isabelle, model checkers, or Coq? (It's not that I don't believe you -- I'd be really interested to read it!) Denis From dons at galois.com Mon Feb 2 19:28:22 2009 From: dons at galois.com (Don Stewart) Date: Mon Feb 2 19:19:03 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <6dbd4d000902021627w7ec9e909x25a9221bf3993de6@mail.gmail.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> <6dbd4d000902021627w7ec9e909x25a9221bf3993de6@mail.gmail.com> Message-ID: <20090203002822.GC13468@whirlpool.galois.com> dbueno: > On Mon, Feb 2, 2009 at 15:04, Don Stewart wrote: > > pocmatos: > >> Hi all, > >> > >> Much is talked that Haskell, since it is purely functional is easier > > > to be verified. > However, most of the research I have seen in software > > verification > (either through model checking or theorem proving) > > targets C/C++ or > subsets of these. What's the state of the art of > > automatically > verifying properties of programs written in Haskell? > >> > > > > State of the art is translating subsets of Haskell to Isabelle, and > > verifying them. Using model checkers to verify subsets, or extracting > > Haskell from Agda or Coq. > > Don, can you give some pointers to literature on this, if any? That > is, any documentation of a verification effort of Haskell code with > Isabelle, model checkers, or Coq? > > (It's not that I don't believe you -- I'd be really interested to read it!) All on haskell.org, http://haskell.org/haskellwiki/Research_papers/Testing_and_correctness#Verifying_Haskell_programs And there's been work since I put that list together. -- Don From dpiponi at gmail.com Mon Feb 2 19:29:41 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Mon Feb 2 19:19:50 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <20090202231840.GB2182@rwbarton.mit.edu> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> <20090202231840.GB2182@rwbarton.mit.edu> Message-ID: <625b74080902021629j7f632165r7ce521258da97855@mail.gmail.com> On Mon, Feb 2, 2009 at 3:18 PM, Reid Barton wrote: >> toSame f = (const True, head [ (< k) | k <- [1..], f (const True) == f (< k) ]) Nice! I like it because at first look it seems like there's no reason for this to terminate, but as you correctly argue, it always does. -- Dan From barsoap at web.de Mon Feb 2 20:11:06 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Feb 2 20:01:25 2009 Subject: [Haskell-cafe] Re: circular dependencies in cabal References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> <1233567077.26754.475.camel@localhost> Message-ID: <20090203021106.13b07e14@solaris> Duncan Coutts wrote: > That is probably how people are getting into this mess. Using upgrade > is not necessarily such a good idea. It does not distinguish between > the interesting packages you might want to upgrade and the core > packages that your probably do not want to touch. > There's no need to use cabal upgrade to get into this kind of mess, I successfully pulled conflicting cabal versions just by using cabal install. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From duncan.coutts at worc.ox.ac.uk Mon Feb 2 20:14:40 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 20:04:33 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> Message-ID: <1233623680.26754.519.camel@localhost> On Mon, 2009-02-02 at 10:07 +0000, Neil Mitchell wrote: > * Some of it comes down to technical issues - for example not having > cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake > (although I've heard everyone argue against me, I've not yet heard a > Windows person argue against me). There are reasonable arguments both ways. Listening to some people it would seem that cabal.exe is there to taunt people with the potential for usable packaging and then to punish them with broken packages, quirky dependency resolution and twisty inconsistent installed package graphs. There is a tension between getting it out there because it's useful, and not putting out something that is going to frustrate and annoy new users. With the current release that balance seems to be pretty fine. I hope that the next release will make it look a little more mature. For example look at how many people have been getting themselves into a complete mess recently from using cabal upgrade. There is a whole new world of exciting mess you can make when using easy automated tools with no safety catches. These are not problems that emerged at first because it was only developers who knew what they were doing who were using it at first. Now that more and more people are using it we're discovering these usability problems. I fear that if we'd gone any quicker that we'd have been completely swamped with bug reports and users might write the whole thing off. Given the available developer resources I don't see how we could have done significantly better (except perhaps by releasing even later). Duncan From duncan.coutts at worc.ox.ac.uk Mon Feb 2 20:32:03 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 20:21:57 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> Message-ID: <1233624723.26754.534.camel@localhost> On Mon, 2009-02-02 at 10:07 +0000, Neil Mitchell wrote: > Hi > > > So actually just having more Windows users subscribed to cabal-devel and > > commenting on tickets would be very useful, even if you do not have much > > time for hacking. > > I believe that as soon as a Windows user starts doing that you'll > start asking them for patches :-) Actually I deliberately didn't say that. I would be happy even with some people dispensing advise and testing things. > There are a number of reasons that we have fewer Windows developers: > > * Some of it comes down to social reasons - for some reason it seems > to be socially acceptable to belittle Windows (and Windows users) on > the Haskell mailing lists and #haskell. Yes plenty of it is social issues. Some of the perceptions in the other direction is that Windows users tend to expect everything to work and not be prepared to help. This may be what they're accustomed to but it tends to rub open source programmers up the wrong way. > * Some of it comes down to technical issues - for example not having > cabal.exe bundled with GHC 6.10.1 on Windows was a massive mistake > (although I've heard everyone argue against me, I've not yet heard a > Windows person argue against me). I think if it had been bundled with ghc-6.10 you'd have heard lots more Windows people complaining. > * Part of it comes down to most developers not being Windows people. > > * A little is because Windows is a second class citizen even in the > libraries, my OS is NOT mingw32 - mingw32 is not even an OS, its a > badly typed expression! How would you like it if your OS was listed as > Wine? Things like this tell me that Haskell isn't Windows friendly, at > best its windows tolerant. Note that cabal/hackage does not classify it that way. > * Things like Gtk2hs, which Windows users need building for them, > don't release in sync with GHC, which makes it hard to use. Hardly anything releases in sync with ghc and it's unrealistic to think that it can or should. The special problem for gtk2hs is that it has to be distributed as a binary so it's guaranteed not to work with new ghc releases where as most other packages will still build from source. Again this comes down to lack of developers and lack of access to Windows hardware. If we had the infrastructure we'd have auto-builders to make releases with new ghc releases. Perhaps that's something we can get people to work on. More automation is good. Building all of hackage on windows and reporting the results would be very useful to everyone. Not once but continuously. > * Windows machines don't usually have a C compiler, and have a very > different environment - while the rest of the world is starting to > standardise. > > I gave up on fighting the fight when people decided not to bundle > cabal.exe with Windows - and now I'm too busy with my day job... Now The more I think about it the more I think that we fortuitously made the right decision not to bundle cabal-install with ghc-6.10. We didn't decide to do it due to immaturity but in hindsight that would have been an excellent reason. As I said before, I hope we'll be able to fix enough of the things that it'll be ok for the first platform release. > I'd say Duncan is the most vocal and practical Windows developer, even > overlooking the fact he doesn't run Windows. I'm going to obtain a license and set up a VM. Duncan From duncan.coutts at worc.ox.ac.uk Mon Feb 2 20:34:34 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 20:24:28 2009 Subject: [Haskell-cafe] Re: circular dependencies in cabal In-Reply-To: <20090203021106.13b07e14@solaris> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> <1233567077.26754.475.camel@localhost> <20090203021106.13b07e14@solaris> Message-ID: <1233624874.26754.536.camel@localhost> On Tue, 2009-02-03 at 02:11 +0100, Achim Schneider wrote: > Duncan Coutts wrote: > > > That is probably how people are getting into this mess. Using upgrade > > is not necessarily such a good idea. It does not distinguish between > > the interesting packages you might want to upgrade and the core > > packages that your probably do not want to touch. > > > There's no need to use cabal upgrade to get into this kind of mess, I > successfully pulled conflicting cabal versions just by using cabal > install. Indeed, it's just easier to shoot yourself in the foot using upgrade. Would anyone object if I disable the upgrade command in the next version and not re-enable it until it works? Duncan From duncan.coutts at worc.ox.ac.uk Mon Feb 2 20:46:56 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 20:36:50 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <9979e72e0902020522y53c8c6aamad4b03d560918e1f@mail.gmail.com> References: <9979e72e0902020522y53c8c6aamad4b03d560918e1f@mail.gmail.com> Message-ID: <1233625616.26754.543.camel@localhost> On Mon, 2009-02-02 at 13:22 +0000, John Lato wrote: > Duncan Coutts wrote: > > > > Some are trivial and should be done away with. For example the ones that > > just check if a C header / lib is present are unnecessary (and typically > > do not work correctly). The next point release of Cabal can do these > > checks automatically, eg: > > > > Configuring foo-1.0... > > cabal: Missing dependencies on foreign libraries: > > * Missing header file: foo.h > > * Missing C libraries: foo, bar, baz > > This problem can usually be solved by installing the system > > packages that provide these libraries (you may need the "-dev" > > versions). If the libraries are already installed but in a > > non-standard location then you can use the flags > > --extra-include-dirs= and --extra-lib-dirs= to specify where > > they are. > > Thank you! Thank you! Thank you! Gleb Alexeyev did the majority of the work on this one. I'm most grateful to him for heeding my recent calls for more volunteers for Cabal hacking. > For those of us who want to write cross-platform (i.e. Windows) > bindings to C libraries, this is great news. Yes. The next step will be for the cabal-install dependency planner to use this information and to complain at the planning stage rather than failing once it starts to try to build things. Duncan From duncan.coutts at worc.ox.ac.uk Mon Feb 2 20:50:52 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 20:40:46 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <20090202162942.GB32310@scytale.galois.com> References: <9979e72e0902020522y53c8c6aamad4b03d560918e1f@mail.gmail.com> <20090202162942.GB32310@scytale.galois.com> Message-ID: <1233625852.26754.548.camel@localhost> On Mon, 2009-02-02 at 08:29 -0800, Don Stewart wrote: > jwlato: > > Duncan Coutts wrote: > > > > > > Some are trivial and should be done away with. For example the ones that > > > just check if a C header / lib is present are unnecessary (and typically > > > do not work correctly). The next point release of Cabal can do these > > > checks automatically, eg: > > > > > > Configuring foo-1.0... > > > cabal: Missing dependencies on foreign libraries: > > > * Missing header file: foo.h > > > * Missing C libraries: foo, bar, baz > > > This problem can usually be solved by installing the system > > > packages that provide these libraries (you may need the "-dev" > > > versions). If the libraries are already installed but in a > > > non-standard location then you can use the flags > > > --extra-include-dirs= and --extra-lib-dirs= to specify where > > > they are. > > > > Thank you! Thank you! Thank you! > > > > For those of us who want to write cross-platform (i.e. Windows) > > bindings to C libraries, this is great news. > > It will be important now to report the lack of uses of these portability > tests back to the authors of packages. Note that to get the above checks authors don't have to do anything except list the C libs in the extra-libraries field as normal. No Setup.hs code or ./configure scripts are required (though it should work with packages that do use ./configure scripts). > A start would be to have hackage warn, I suppose. I'm not quite sure what we can warn about here except the general use of configure scripts (which is not a good idea at least at the moment). We need to work out what everone is using them for first: http://hackage.haskell.org/trac/hackage/ticket/482 Duncan From wren at freegeek.org Mon Feb 2 20:51:47 2009 From: wren at freegeek.org (wren ng thornton) Date: Mon Feb 2 20:41:56 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> Message-ID: <4987A333.9010909@freegeek.org> Gregg Reynolds wrote: > Hi, > > The concept of "type" seems to be a little like porno: I know it when > I see it, but I can't define it (apologies to Justice Stewart). I've > picked through lots of documents that discuss types in various ways, > but I have yet to find one that actually says what a type "really" is. > For example, definitions of the typed lambda calculus usually define > some type symbols and rules like "a : T means a is of type T", and > then reasoning ensues without discussion of what "type" means. The non-explication of types is intentional: by not saying anything about what a type is (other than that values/expressions can have one) that frees the theory to operate generally, regardless of what types actually are in any specific instantiation. When trying to say as little as possible, people frequently refer to them as "sorts". By calling them "types" we often mean we know a little bit more about them than sorts; though the terminology is relatively interchangeable. Not that this helps you any. > The only discussion I've found that addresses this is at the Stanford > Encyclopedia of Philosophy, article "Types and Tokens" [1]. It's all > very philosophical, but there is one point there that I think has > relevance to Haskell. It's in section 4.1, discussing the distinction > between types and sets: The type--token distinction uses a different notion of type. In this context "type" means a sort of platonic notion of some thing (a value idealized), whereas "tokens" are specific instantiations/references to that thing. Consider, for example, the English word "Foo". When discussing Foo generally as a word in the English language, we're discussing the type Foo. But if I'm doing natural language parsing on this email, each time that three-letter sequence occurs is a different token (or instance, or use-in-context) of the type. In NLP/MT the distinction is helpful because, due to context, different tokens of the same type may need different treatment even though they're "the same word". For example, if "the" occurs fifteen times in a sentence, we probably shouldn't translate all of them into a single occurence of "der" in the German translation. Mathematically this is the same distinction between the idea of 1 (choose any particular idea), vs the usage of 1. Due to referential transparency we don't tend to worry about this in Haskell since all tokens are interchangeable. Consider instead an object-oriented language. We can have an object over here that is "1", and it's separate from an object over there that's also "1". We can have mutation which makes one of the tokens different, say "2", without affecting the other token (though now they are no longer tokens of the same type). This is different from making the *type* different, which would affect all its tokens. (And philosophically it matters because of the relation to whether the presence or absence of a token is effectful on the definitions of other things, e.g. sets or species as in your citation.) Obviously this has some relation to the programmatic theory of types, but it's indirect. In the NLP/MT context the mapping from tokens to types is fairly straightforward, but in general there's the question of how we do the mapping which depends entirely on what our types look like. For example, is "Fooing" or "Fooer" a token of Foo, or do there exist types Fooing and Fooer instead? Usually in programming, singleton types aren't too helpful and so we use types that include all the "inflected forms" as well. But there are times when we do want to break these types apart into smaller types (via OOP inheritance, via case matching, via distinguishing instances of the same value,...). -- Live well, ~wren From duncan.coutts at worc.ox.ac.uk Mon Feb 2 20:56:17 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 20:46:11 2009 Subject: [Haskell-cafe] ANN: HDBC v2.0 now available In-Reply-To: <2608b8a80902020522r2302b4f4p96c29d8c6d516289@mail.gmail.com> References: <20090130212802.GA30247@complete.org> <0CDBC386-49A8-4310-97D8-817C8FB0B919@kamysh.org> <220e47b40901301545k4eb90e8cq639d2ddeaac1fc61@mail.gmail.com> <29bf512f0901301550g14a58afmd571d446b9f28d3d@mail.gmail.com> <20090131002952.GA31529@complete.org> <1233499089.26754.334.camel@localhost> <1233501034.26754.360.camel@localhost> <2608b8a80902020522r2302b4f4p96c29d8c6d516289@mail.gmail.com> Message-ID: <1233626177.26754.553.camel@localhost> On Mon, 2009-02-02 at 15:22 +0200, Yitzchak Gale wrote: > Duncan Coutts wrote: > >>> So in the next cabal-install release (which should be pretty soon now) > >>> configure will do the same thing and pick base 3 unless you specify > >>> build-depends base >= 4. > > Niklas Broberg wrote: > >> I really really think this is the wrong way to go. Occasional > >> destruction is desperately needed for progress, else things will > >> invariably stagnate. > > > I disagree. Having everything fail... would have been a disaster... > > during the lifespan of base 4 we need to encourage new > > releases to start working with it... > > Doing that with warnings hints etc is the way to go. > > No, that's not good enough either. Existing packages > will just stay with old versions to avoid the work, and > new packages will then also use old versions for > maximum compatibility. > > The incentive is not strong enough. Those warnings > and hints must have teeth. > > Comparing with what has happened in other languages, > which have stagnated or not stagnated at various rates, > it is clear that what we need is a well-defined deprecation > process. > The warnings should say something like: you had better > upgrade this, otherwise it will stop working in the next > version. Both maintainers and users should be aware of > this threat. I shouldn't worry. The next major version of ghc probably will not have base 3 any more. So the question is how we check and what warnings we give and to who. My current suggestion is to require upper bounds on the version of base and to warn when we end up selecting base 3 for older packages that do not specify an upper bound. Perhaps at some point we should start warning when the upper bound people specify for new uploads is < 4. What do you think the policy and mechanism should be? Duncan From duncan.coutts at worc.ox.ac.uk Mon Feb 2 21:03:53 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 2 20:53:46 2009 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <3c6288ab0902020418w40c48707y6881ea9976adf024@mail.gmail.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> <3c6288ab0902020418w40c48707y6881ea9976adf024@mail.gmail.com> Message-ID: <1233626633.26754.561.camel@localhost> On Mon, 2009-02-02 at 13:18 +0100, Sean Leather wrote: > Either I'm doing something wrong or this doesn't work for > cabal-install and GHC 6.8.3. I used the "flag newer-th" approach in > EMGM: > > > https://svn.cs.uu.nl:12443/viewvc/dgp-haskell/EMGM/tags/emgm-0.2/emgm.cabal?view=markup > > [...] > > flag th23 > description: Define a CPP flag that enables conditional compilation > for template-haskell package version 2.3 and newer. > > Library > > [...] > > build-depends: base >= 3.0 && < 4.0, > template-haskell < 2.4 > > -- Include deriveRep for Loc. This was introduced with > -- template-haskell-2.3, included with GHC 6.10. > if flag(th23) > build-depends: template-haskell >= 2.3 > cpp-options: -DTH_LOC_DERIVEREP > else > build-depends: template-haskell < 2.3 > > [...] > > When I run cabal install emgm (with GHC 6.8.3 and either Cabal 1.2 or > 1.6), it tries (and fails) to install template-haskell-2.3. That's > exactly what I don't want. Any suggestions? No immediate workarounds, though you could perhaps try reversing the condition or the default of the flag. Though that might just reverse the problem case. Presumably the template-haskell-2.3 package does not build with ghc-6.8 but fails to correctly specify the version of base or ghc that it requires. If it did then we would have a better chance to get this right. In general this is going to be hard. The solver is not that smart and it deliberately does no backtracking (as a defence against searching too much given that it has no smart methods for pruning the search space). This is just the kind of situation where we need a proper solver which is probably a couple months work. Another possible workaround... If you avoid using the flag hack then the solver would not have to choose so early which version of template-haskell to commit to and it would be able to pick the right version later. Though then you need an alternative method of finding which version of template-haskell you ended up with. You could do it with some custom code in Setup.hs. Duncan From briqueabraque at yahoo.com Mon Feb 2 21:08:17 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Mon Feb 2 20:58:36 2009 Subject: [Haskell-cafe] Re: Complex C99 type in Foreign In-Reply-To: <20090201235400.GL24687@scytale.galois.com> References: <20090201185747.GW24687@scytale.galois.com> <20090201235400.GL24687@scytale.galois.com> Message-ID: >>>> Are there plans to include C99 'complex' type >>>> in Foreign, maybe as CFloatComplex, CDoubleComplex >>> A separate library for new types to add to Foreign would be the easiest >>> way forward. Just put the foreign-c99 package on Hackage? >> (...) I could actually have some >> arbitrary sized parameter as argument to a function >> or as a return value (and not its pointer), what >> did I saw wrong? I understand only Foreign.C.C* >> types or forall a. => Foreign.Ptr.Ptr a can be used >> like that. > > Oh, you mean you need to teach the compiler about unboxed complex types? > I'm sorry, maybe I didn't understand you well. Are you saying that I could get this 'CComplex' type using unboxed types and other things already available? Maur?cio From ryani.spam at gmail.com Mon Feb 2 21:12:38 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Mon Feb 2 21:02:50 2009 Subject: [Haskell-cafe] Re: type metaphysics In-Reply-To: <498787DC.5030709@gmx.net> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <2f9b2d30902021439j7a9e8486q213de0cce5fbeb0b@mail.gmail.com> <498787DC.5030709@gmx.net> Message-ID: <2f9b2d30902021812r5bfc5e36o5f0a46d662e76fff@mail.gmail.com> On Mon, Feb 2, 2009 at 3:55 PM, Benedikt Huber wrote: > f is 'easy to implement' if it enumerates all functions, not just total > ones. Otherwise, f is hard to implement ;) > > In the first case, if we have (f n n) = _|_, then g n = not (f n n) = _|_ as > well, so the diagonalization argument does not hold anymore. Thanks for the insight, I see the contradiction! Luke said: > But we know we are dealing with computable functions, so we can just > enumerate all implementations. So the computable functions > Nat -> Bool are countable. The contradiction is this: f, as specified by Luke enumerates all computable functions. But f is uncomputable! So while we can show that the number of computable functions is at most countable (due to the number of programs being countable), we cannot actually enumerate which ones they are. Since f is uncomputable, so is g. Therefore, there is no diagonalization; even if we had a magic oracle that enumerated the set of computable functions, g would not be present, since it is not computable! On the other hand, if we allow f to construct nonterminating functions, as in my implementation, g does not diagonalize, as Benedikt pointed out! -- ryan From allbery at ece.cmu.edu Mon Feb 2 21:32:13 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Feb 2 21:22:50 2009 Subject: [Haskell-cafe] why typeRepArgs (typeOf "hello") is [Char] ? In-Reply-To: <40a414c20902021227g1d7f1082r8cb0a6041a781dde@mail.gmail.com> References: <40a414c20902021209q5fea55c7na3a46421fa0d5735@mail.gmail.com> <40a414c20902021227g1d7f1082r8cb0a6041a781dde@mail.gmail.com> Message-ID: <56972640-E590-437A-8ABD-E3D41064BAF6@ece.cmu.edu> On 2009 Feb 2, at 15:27, minh thu wrote: > Thanks. Could you add to your explanation this one : > > *Graph> typeRepArgs (typeOf (+)) > [Integer,Integer -> Integer] The actual representation of an n-argument function in Haskell is a single-argument function that returns an (n-1)-argument function. (Technically, Haskell function applications are uncurried.) This is reflected in typing by (->) being right associative: > (+) :: Num a => a -> a -> a :: Num a => a -> (a -> a) the former being how we usually think about it and the latter being how Haskell actually sees it. The typeRepArgs of (+) are set by this and by defaulting due to the monomorphism restriction to give you [Integer,Integer -> Integer] which corresponds to > (+) :: Integer -> (Integer -> Integer) :: Integer -> Integer -> Integer which is the previous definition, swapping the internal and external forms and filling in Integer for (Num a =>) a via defaulting. > In fact, I tried to write a function that would give the types used by > a function, > for instance [Integer, Integer, Integer] for (+) (the last one would > be the 'return' type). > So I applied recursively typeRepArgs to the second element of the list > (if any) (here, Integer -> Integer). > > It worked well until I tried it on a function like :: Char -> Int -> > [Char] where > the last recursive call gives [Char] instead of []. To get information about higher-kinded types, you want typeRepTyCon: > Prelude Data.Typeable> typeRepTyCon (typeOf (+)) > -> which is how you should determine that you want to deconstruct a function type. Or for the final argument in your case: > Prelude Data.Typeable> typeRepTyCon (typeOf "foo") > [] There's the [] you wanted. typeRepArgs then informs us that the tycon [] is applied to a sing;e type argument: > Prelude Data.Typeable> typeRepArgs (typeOf "foo") > [Char] so the final argument type is ([] Char) (better known as [Char]). The fact that it comes out as [Char] may be confusing you; the length of the list represents the number of type arguments the tycon takes, so you've been given a Char and need typeRepTyCon to get the rest of the story. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/c71dc9e2/PGP.bin From monnier at iro.umontreal.ca Mon Feb 2 22:14:48 2009 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon Feb 2 22:05:09 2009 Subject: [Haskell-cafe] Re: Verifying Haskell Programs References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> Message-ID: > State of the art is translating subsets of Haskell to Isabelle, and > verifying them. Using model checkers to verify subsets, or extracting > Haskell from Agda or Coq. Another state of the art is to use type classes, GADTs, and/or type functions, to specify and prove the properties you want about your program. Basically using similar techniques as used in dependently typed languages. Stefan From kamysh at kamysh.org Mon Feb 2 22:16:59 2009 From: kamysh at kamysh.org (Valentyn Kamyshenko) Date: Mon Feb 2 22:07:18 2009 Subject: [Haskell-cafe] Re: circular dependencies in cabal In-Reply-To: <1233624874.26754.536.camel@localhost> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> <1233567077.26754.475.camel@localhost> <20090203021106.13b07e14@solaris> <1233624874.26754.536.camel@localhost> Message-ID: <7802E7F3-4D3A-4D8E-8765-2CB2BA4D39A6@kamysh.org> Hi Duncan, The major problem that I see is with # cabal update # cabal upgrade sequence of operations (that is, upgrading all installed packages). I use this regularly to keep packages that I use (or are going to use) up to date. This is the functionality that, I suppose, everybody expects from the system like hackage/cabal. And, so far as I can see, the major problem is that 'cabal upgrade' will happily upgrade packages, that the core package depends on, and eventually will create configuration with circular dependencies. Can we do something simple - like, for example, forbidding updates of the packages that the core depends on (directly and indirectly)? -- Valentyn. On Feb 2, 2009, at 5:34 PM, Duncan Coutts wrote: > On Tue, 2009-02-03 at 02:11 +0100, Achim Schneider wrote: >> Duncan Coutts wrote: >> >>> That is probably how people are getting into this mess. Using >>> upgrade >>> is not necessarily such a good idea. It does not distinguish between >>> the interesting packages you might want to upgrade and the core >>> packages that your probably do not want to touch. >>> >> There's no need to use cabal upgrade to get into this kind of mess, I >> successfully pulled conflicting cabal versions just by using cabal >> install. > > Indeed, it's just easier to shoot yourself in the foot using upgrade. > > Would anyone object if I disable the upgrade command in the next > version > and not re-enable it until it works? > > Duncan > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From wren at freegeek.org Mon Feb 2 22:41:57 2009 From: wren at freegeek.org (wren ng thornton) Date: Mon Feb 2 22:32:08 2009 Subject: [Haskell-cafe] Bytestrings vs String? In-Reply-To: <20090202224540.GB24610@gmx.de> References: <20090202224540.GB24610@gmx.de> Message-ID: <4987BD05.4020307@freegeek.org> Marc Weber wrote: > A lot of people are suggesting using Bytestrings for performance, > strictness whatsoever reasons. > > However how well do they talk to other libraries? I'm not sure how you mean? For passing them around: If someone's trying to combine your library (version using ByteStrings) and another Haskell library that uses ByteStrings, then everything works fine--- assuming both libraries are compiled against the same version of the bytestring library. As I recall, ByteStrings are designed to ease passing to C code across the FFI too, in case someone wants to use your library with some FFI C code. If someone's trying to combine your library with another library that uses String, they'll need to add conversions. (All of this is symmetric for a version of your library using String with another library using ByteStrings.) The big compatibility issue I can see is the question of what a given ByteString *means*. In particular, via the Data.ByteString.Char8 module it encodes only ASCII characters, not all of Unicode like [Char] does. There are libraries for lossless encoding of [Char] into ByteStrings, but in general there can be encoding mismatch problems if, say, your library uses UTF8-encoded ByteStrings but the other library treats them like Char8-encoded (or UTF16BE, UTF16LE, FooBar,...), potentially mangling or hallucinating multi-byte characters. In general, if you're concerned about performance (or believe your users will be) then ByteStrings are a good bet. Just make it clear in the documentation what sort of encoding you use (or whether your library is encoding agnostic). For hslogger specifically, it looks like most of the Strings are arguments which will typically be written as literals. Thus, to minimize boilerplate, if you do switch to ByteStrings then you may want to provide a module that does all the String->ByteString conversions for the user. If you have a good program for testing real world use of hslogger, before committing to the change I'd suggest benchmarking (in time and in space) the differences between the current String implementation and a proposed ByteString implementation. > Should there be two versions? > > hslogger-bytestring and hslogger-string? I'd just stick with one (with a module for hiding the conversions, as desired). Duplicating the code introduces too much room for maintenance and compatibility issues. > Or would it be better to implement one String class which can cope > with everthing (performance will drop, won't it?) It'd be a very large class if you do it generally[1], and large classes like that are generally frowned on (for good or ill). If you only need a small subset of string operations then it may be more feasible to have a smaller class with only those operations. [1] See everything hidden from the Prelude in http://hackage.haskell.org/packages/archive/list-extras/0.2.2.1/doc/html/src/Prelude-Listless.html or see what all is offered by Data.ByteString vs the Prelude. > In the future I'd like to explore using haskell for web developement. > So speed does matter. And I don't want my server to convert from > Bytestrings to Strings and back multiple times.. That's the big thing. The more people that use ByteStrings the less need there is to convert when combining libraries. That said, ByteStrings aren't a panacea; lists and laziness are very useful. -- Live well, ~wren From allbery at ece.cmu.edu Mon Feb 2 22:46:36 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Mon Feb 2 22:36:59 2009 Subject: [Haskell-cafe] Bytestrings vs String? In-Reply-To: <20090202224540.GB24610@gmx.de> References: <20090202224540.GB24610@gmx.de> Message-ID: On 2009 Feb 2, at 17:45, Marc Weber wrote: > Or would it be better to implement one String class which can cope > with everthing (performance will drop, won't it?) There is already an IsString class, although IIRC it deals solely with converting String to/from a member of IsString. Most of the rest involves invoking functions as S.whatever and then importing some variant of Data.ByteString or Data.List qualified as S. (The latter is kinda unfortunate, but Data.String was taken to provide the IsString class. Code would look a bit saner if Data.String reexported Data.List for this usage model; note that this model only makes sense with IsString, so it would be a hopefuly backward compatible addition.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/459b9ab5/PGP.bin From john at n-brain.net Mon Feb 2 23:14:08 2009 From: john at n-brain.net (John A. De Goes) Date: Mon Feb 2 23:04:21 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: <2A620A8F-AB5C-4E36-B038-008870758CCA@n-brain.net> How do you define "layout" in a way that has a "direct an enormous effect on interaction semantics"??? Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 2, 2009, at 4:31 PM, Conal Elliott wrote: > Hi John, > > I'm not sure how to interpret your remarks about "has no effect" and > "is best". I guess they're subjective opinions, but maybe I'm > missing something objective in your intent. I can see, for > instance, at least one way in which layout has a direct and enormous > effect on interaction semantics. And while I can see some benefits > in choosing CSS, I also see some significant drawbacks, and I wonder > if you've factored these drawbacks into your "is best". > > - Conal > > 2009/2/2 John A. De Goes > > The size, color, and layout of widgets has no effect on interaction > semantics and is best pushed elsewhere, into a designer-friendly > realm such as CSS. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > On Feb 2, 2009, at 2:15 PM, Conal Elliott wrote: > >> Could CSS give us semantic clarity? - Conal >> >> On Mon, Feb 2, 2009 at 11:58 AM, John A. De Goes >> wrote: >> >> The actual presentation and layout of widgets would be better >> handled by a DSL such as CSS (which is, in fact, declarative in >> nature), while event logic would be best handled purely in Haskell. >> >> Regards, >> >> John A. De Goes >> N-BRAIN, Inc. >> The Evolution of Collaboration >> >> http://www.n-brain.net | 877-376-2724 x 101 >> >> >> On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: >> >> 2009/1/29 Conal Elliott : >> Hi Achim, >> >> I came to the same conclusion: I want to sweep aside these OO, >> imperative >> toolkits, and replace them with something "genuinely functional", >> which for >> me means having a precise & simple compositional (denotational) >> semantics. >> Something meaningful, formally tractable, and powefully >> compositional from >> the ground up. As long as we build on complex legacy libraries (Gtk, >> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or >> worse yet, >> drawn into) their ad hoc mental models and system designs. >> >> As Meister Eckhart said, "Only the hand that erases can write the >> true >> thing." >> >> I think working on a purely functional widget toolkit would actually >> be a really cool project. Do you have any ideas, though, on what >> should be the underlying primitives? >> >> The initial gut feeling I have is that one should just ignore any >> notion of actually displaying widgets & instead focus on a clean >> algebra of how to 'add' widgets that relates the concepts of >> inheritance & relative position. What I mean by inheritance, here, >> is >> how to direct a flow of 'events'. I don't necessarily mean events in >> the Reactive sense, because I think it'd be important to make the >> model completely independent of how time & actual UI actions are >> handled. >> >> Any thoughts to throw in, here? >> >> Cheers, >> C >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/fe713366/attachment.htm From ramsdell0 at gmail.com Mon Feb 2 23:33:51 2009 From: ramsdell0 at gmail.com (John D. Ramsdell) Date: Mon Feb 2 23:24:01 2009 Subject: [Haskell-cafe] Parallel term reduction In-Reply-To: <7ca3f0160902020115k2b4974e7w6b560ebcc7badc73@mail.gmail.com> References: <7687290b0902012026s2a2e0619tecc227d33ec56afc@mail.gmail.com> <7ca3f0160902020115k2b4974e7w6b560ebcc7badc73@mail.gmail.com> Message-ID: <7687290b0902022033s3aba45cfn8848e530fb3b6006@mail.gmail.com> Luke, I read your solution but didn't understand how it applies to my problem. I must not have explained the problem well enough. Let me try again. I have a reduction system in which a rule takes a term and returns a set of terms. The terms can be compared for equality, but they are not ordered. The reduction system creates a tree that originates at a starting value called the root using breadth first search. For most problems, the reduction system terminates, but a step count limit protects from non-termination. Rule application is expensive, so it is essential that a rule is never applied to the same problem twice. This check makes my program sequential, and I could find no place to add parallel annotations that might help. The key function in the enclosed code is the step function. It's where all the time is spent. To allow effective use of more than one core, doesn't one have to figure out how to allow parts of the seen list to be searched simultaneously? Isn't that search the performance bottleneck? John > module Main (main) where > import System.Time (ClockTime(..), getClockTime) > import Data.Tree (Tree(..), flatten) > import Data.Maybe (isNothing) The reduction system takes a rule, a step count, and an initial value, and computes a tree of reductions. > reduce :: (Eq a, Monad m) => (a -> [a]) -> Int -> a -> m (Tree a) > reduce rule limit root = > step rule limit [top] [top] > where > top = Item { item = root, parent = Nothing } The Item data structure stores the information about a reduction step in a form that can be used to construct the final answer as a tree. > data Eq a => Item a > = Item { item :: a, > parent :: Maybe (Item a) } > instance Eq a => Eq (Item a) where > x == y = item x == item y The step function is where nearly all of the time is used. It is called as: step rule limit seen todo where seen is the items already seen, and todo is the items on the queue. The order of the items in the seen list is irrelevant, because the tree is assembled as a post processing step. > step :: (Eq a, Monad m) => (a -> [a]) -> Int -> > [Item a] -> [Item a] -> m (Tree a) > step _ limit _ _ > | limit <= 0 = fail "Step limit exceeded" > step _ _ seen [] = tree seen > step rule limit seen (next : rest) = > loop seen rest children > where > children = map child (rule (item next)) > child i = Item { item = i, parent = Just next } > loop seen rest [] = > step rule (limit - 1) seen rest > loop seen rest (kid : kids) = > if elem kid seen then > loop seen rest kids > else > loop (kid : seen) (rest ++ [kid]) kids The next two functions assemble the answer into a tree. Sequential search is just fine for tree building. > tree :: (Eq a, Monad m) => [Item a] -> m (Tree a) > tree items = > case filter (isNothing . parent) items of > [root] -> return (build items (item root)) > _ -> fail "bad tree" > build :: Eq a => [Item a] -> a -> Tree a > build items root = > Node { rootLabel = root, > subForest = map (build items . item) children } > where > children = filter child items > child i = maybe False ((== root) . item) (parent i) A silly rule > rule :: Int -> [Int] > rule n = filter (>= 0) [n - 1, n - 2, n - 3] > secDiff :: ClockTime -> ClockTime -> Float > secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) > = fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1) > main :: IO () > main = > do > t0 <- getClockTime > t <- reduce rule 20000 5000 > let ns = length (flatten t) > t1 <- getClockTime > putStrLn $ "length: " ++ show ns > putStrLn $ "time: " ++ show (secDiff t0 t1) ++ " seconds" The makefile ------------ PROG = reduce GHCFLAGS = -Wall -package containers -fno-warn-name-shadowing -O %: %.lhs ghc $(GHCFLAGS) -o $@ $< all: $(PROG) clean: -rm *.o *.hi $(PROG) From barsoap at web.de Mon Feb 2 23:47:25 2009 From: barsoap at web.de (Achim Schneider) Date: Mon Feb 2 23:37:44 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> <2A620A8F-AB5C-4E36-B038-008870758CCA@n-brain.net> Message-ID: <20090203054725.17d39555@solaris> "John A. De Goes" wrote: > How do you define "layout" in a way that has a "direct an enormous > effect on interaction semantics"??? > http://www.youtube.com/watch?v=faJ8N0giqzw -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From oleg at okmij.org Tue Feb 3 00:14:45 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Feb 3 00:06:36 2009 Subject: [Haskell-cafe] Re: type metaphysics Message-ID: <20090203051445.C90A2AB11@Adric.metnet.fnmoc.navy.mil> I believe the original notion of type by Russell is most insightful, bridging the semantic notion of type (type as a set of values) and the syntactic notion (type system as a syntactic discipline, a statically decidable restriction on terms). That point is discussed at some length in Sec 3 (pp. 7-8) of http://okmij.org/ftp/Computation/FLOLAC/lecture.pdf The one of the main points of these FLOLAC lecture notes was to justify and illustrate the claim that A type is a (quickly decidable) approximation of a dynamic behavior that can be derived from the form of an expression. (The other claim was the relationship between sharing and polymorphism). Incidentally, Russell has published his paper that introduced types as we in Computer Science know them in 1908. Last year there was 100th anniversary of types. I have been trying to prompt people to have a party and celebrate the occasion -- alas, to no avail. From john at n-brain.net Tue Feb 3 00:32:01 2009 From: john at n-brain.net (John A. De Goes) Date: Tue Feb 3 00:22:12 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <20090203054725.17d39555@solaris> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> <2A620A8F-AB5C-4E36-B038-008870758CCA@n-brain.net> <20090203054725.17d39555@solaris> Message-ID: Perhaps I should have been more precise: How do you define "layout" and "interaction semantics" in such a way that the former has a *necessarily* direct, enormous impact on the latter? HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 2, 2009, at 9:47 PM, Achim Schneider wrote: > "John A. De Goes" wrote: > >> How do you define "layout" in a way that has a "direct an enormous >> effect on interaction semantics"??? >> > http://www.youtube.com/watch?v=faJ8N0giqzw > > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ekirpichov at gmail.com Tue Feb 3 01:08:10 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Tue Feb 3 00:58:18 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <7ca3f0160902021554i785069b0jcc88ac3f8a13f226@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <49871615.2020806@van.steenbergen.nl> <4987239B.1020004@van.steenbergen.nl> <7ca3f0160902021006y724540adq31ec040ae396a2c2@mail.gmail.com> <1233602672.3890.65.camel@localhost> <7ca3f0160902021430w3dd10c06tf07708c2056aad31@mail.gmail.com> <625b74080902021441r7a1f354arcc9dfa9c571f41b0@mail.gmail.com> <20090202231840.GB2182@rwbarton.mit.edu> <7ca3f0160902021554i785069b0jcc88ac3f8a13f226@mail.gmail.com> Message-ID: <5e0214850902022208x2b960112if5ccc758547c9a11@mail.gmail.com> Luke, sorry for being offtopic, but you are more and more intriguing me with topology. I wonder if any stuff from it has, apart from applications in computability/complexity, also computational applications as useful as monoids or rings do (i.e. parallel prefix sums). 2009/2/3 Luke Palmer : > On Mon, Feb 2, 2009 at 4:18 PM, Reid Barton > wrote: >> >> > So here's a programming challenge: write a total function (expecting >> > total arguments) toSame :: ((Nat -> Bool) -> Nat) -> (Nat -> Bool,Nat >> > -> Bool) that finds a pair that get mapped to the same Nat. >> > >> > Ie. f a==f b where (a,b) = toSame f >> >> (Warning: sketchy argument ahead.) Let f :: (Nat -> Bool) -> Nat be a >> total function and let g0 = const True. The application f g0 can >> only evaluate g0 at finitely many values, so f g0 = f (< k) for any k >> larger than all these values. So we can write >> >> > toSame f = (const True, head [ (< k) | k <- [1..], f (const True) == f >> > (< k) ]) >> >> and toSame is total on total inputs. > > Well done! That's not sketchy at all! There is always such a k (when the > result type of f has decidable equality) and it is the "modulus of uniform > continuity" of f. This is computable directly, but the implementation > you've provided might come up with a smaller one that still works (since you > only need to differentiate between const True, not all other streams). > > I guess I should hold off on conjecturing the impossibility of things... :-) > > Luke > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dev at mobileink.com Tue Feb 3 01:15:07 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Tue Feb 3 01:05:16 2009 Subject: [Haskell-cafe] Re: type metaphysics In-Reply-To: <20090203051445.C90A2AB11@Adric.metnet.fnmoc.navy.mil> References: <20090203051445.C90A2AB11@Adric.metnet.fnmoc.navy.mil> Message-ID: <75cc17ac0902022215k3e4ba108g511e390aadbfc349@mail.gmail.com> On Mon, Feb 2, 2009 at 11:14 PM, wrote: > > I believe the original notion of type by Russell is most insightful, > bridging the semantic notion of type (type as a set of values) and the > syntactic notion (type system as a syntactic discipline, a statically > decidable restriction on terms). > > That point is discussed at some length in Sec 3 (pp. 7-8) of > http://okmij.org/ftp/Computation/FLOLAC/lecture.pdf > > Fantastic! That's exactly the sort (heh) of thing I was looking for. > Incidentally, Russell has published his paper that introduced types as > we in Computer Science know them in 1908. Last year there was 100th > anniversary of types. I have been trying to prompt people to have a > party and celebrate the occasion -- alas, to no avail. > Also the 100th anniversary of Zermelo's "Untersuchungen ?ber die Grundlagen der Mengenlehre I" (Investigations in the foundations of set theory) - pretty tough competition. Maybe a "Set Theory v. Type Theory All-star Smackdown" would draw a crowd. Lots of beer, mud-wrestling, monster trucks, that sort of thing. Thanks much, gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/69e56666/attachment.htm From dev at mobileink.com Tue Feb 3 01:55:22 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Tue Feb 3 01:45:31 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <87k588zivs.fsf@malde.org> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <87ocxkznrj.fsf@malde.org> <75cc17ac0902021113n2d566173sd84268acc11b8fca@mail.gmail.com> <87k588zivs.fsf@malde.org> Message-ID: <75cc17ac0902022255j697f3c5dga63ee972784b496@mail.gmail.com> On Mon, Feb 2, 2009 at 2:25 PM, Ketil Malde wrote: > Gregg Reynolds writes: > > > Just shorthand for something like "data Tcon a = Dcon a", applied to Int. > > Any data constructor expression using an Int will yield a value of type > Tcon > > Int. > > Right. But then the set of values is isomorphic to the set of Ints, > right? > The values constructed by that particular constructor, yes; good point. Isomorphic, but not the same. (And also, if we have a second constructor, what's our cardinality? The first one "uses up" all the integers, no? Since we can define "aleph" constructors, each of which can yield "aleph" values, well that's a lot of values.) > > >> I don't follow this argument. Are you saying you can remove a > >> data constructor from a type, and still have the same type? And > >> because of this, the values of the type do not constitute a set? > > > Yep. > > I don't see why you would consider it the same type. Since, given any > two data types, I could remove all the data constructors, this would > make them, and by extension, all types the same, wouldn't it? > I don't think so; considered as sets, they have different intensions, and considered as predicates, they're clearly distinct even if there are no objects. Different names (descriptions), different things, unless we declare they are equal. You would probably find "When is one thing equal to another thing", by Barry Mazur (at http://www.math.harvard.edu/~mazur/). A fascinating discussion of equality in the context of category theory. See also "On Sense and Intension" at http://consc.net/papers.html -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/dea78e33/attachment.htm From barsoap at web.de Tue Feb 3 02:12:09 2009 From: barsoap at web.de (Achim Schneider) Date: Tue Feb 3 02:02:32 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> <2A620A8F-AB5C-4E36-B038-008870758CCA@n-brain.net> <20090203054725.17d39555@solaris> Message-ID: <20090203081209.37a00941@solaris> "John A. De Goes" wrote: > > Perhaps I should have been more precise: > > How do you define "layout" and "interaction semantics" in such a way > that the former has a *necessarily* direct, enormous impact on the > latter? > > HTML/CSS is a perfect example of how one can decouple a model of > content from the presentation of that content. The developer writes > the content model and the controller, while UX guys or designers get > to decide how it looks. > HTML, or rather XML, would be layout to me. GUI's usually don't serve static content, and allowing a CSS layer to position eg. a filter GUI that supports chaining up any amount of filters by slicing them apart and positioning them on top of each other (maybe because someone didn't notice that you can use more than one filter) wrecks havoc on both usability and the semantics. "Wrecks havoc on the semantics" in the sense of that if a thing is editable, the semantics should guarantee that it is, indeed, editable. Likewise, if something is marked as visible (and such things are explicit in the model, not defined by an outer layer), the semantics should guarantee that it is visible. That, and I don't intend to write a browser. There will be, of course, a separation between what is displayed and how things are displayed, because that's the very sense of a widget toolkit. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From tom.davie at gmail.com Tue Feb 3 02:42:31 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Feb 3 02:32:45 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <20090203081209.37a00941@solaris> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> <2A620A8F-AB5C-4E36-B038-008870758CCA@n-brain.net> <20090203054725.17d39555@solaris> <20090203081209.37a00941@solaris> Message-ID: On 3 Feb 2009, at 08:12, Achim Schneider wrote: > "John A. De Goes" wrote: > >> >> Perhaps I should have been more precise: >> >> How do you define "layout" and "interaction semantics" in such a way >> that the former has a *necessarily* direct, enormous impact on the >> latter? >> >> HTML/CSS is a perfect example of how one can decouple a model of >> content from the presentation of that content. The developer writes >> the content model and the controller, while UX guys or designers get >> to decide how it looks. >> > HTML, or rather XML, would be layout to me. GUI's usually don't serve > static content, and allowing a CSS layer to position eg. a filter GUI > that supports chaining up any amount of filters by slicing them apart > and positioning them on top of each other (maybe because someone > didn't > notice that you can use more than one filter) wrecks havoc on both > usability and the semantics. > > "Wrecks havoc on the semantics" in the sense of that if a thing is > editable, the semantics should guarantee that it is, indeed, editable. > Likewise, if something is marked as visible (and such things are > explicit in the model, not defined by an outer layer), the semantics > should guarantee that it is visible. I mostly don't get how a topic discussing how to do GUIs in a beautiful, consistent, composable, orthogonal, functional way got onto the topic of "oh hay, you could do it with html and css". Sure, those two may be declarative languages, but that doesn't make either of them fill the list of features required above! Bob From gleb.alexeev at gmail.com Tue Feb 3 02:48:09 2009 From: gleb.alexeev at gmail.com (Gleb Alexeyev) Date: Tue Feb 3 02:38:15 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <1233625616.26754.543.camel@localhost> References: <9979e72e0902020522y53c8c6aamad4b03d560918e1f@mail.gmail.com> <1233625616.26754.543.camel@localhost> Message-ID: Duncan Coutts wrote: > Gleb Alexeyev did the majority of the work on this one. I'm most > grateful to him for heeding my recent calls for more volunteers for > Cabal hacking. > I guess you're overstating my contribution a little, but thanks :). From ndmitchell at gmail.com Tue Feb 3 03:26:23 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue Feb 3 03:16:33 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <20090202220344.GA13113@whirlpool.galois.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> <20090202220344.GA13113@whirlpool.galois.com> Message-ID: <404396ef0902030026g4230e893r980db1353fed1bf7@mail.gmail.com> Hi > GHC doesn't bundle with cabal-install on any system. > > What is needed is not for the GHC team to be doing Windows platform > packages, but for the Windows Haskell devs to build their own system, as > happens on all the Unices. > > Take GHC's release, wrap it up with native installers, throw in useful > libraries and executables like cabal. Done. GHC already takes the GHC release, bundles it up with a native installer, and then throws in useful executables like gcc. It just stops one hop short of "done". Windows is special, we already treat Windows special, but currently its just short of useable. Duncan: Saying cabal.exe isn't mature enough to go in 6.10 is a perfect reason, but one that you never gave at the time. If it isn't ready, then that's fine. But if thats the case, will it be in 6.12, or will the standard Windows instructions involve hunting around haskell.org for a prebuild Cabal.exe? Thanks Neil From pocmatos at gmail.com Tue Feb 3 03:31:00 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Tue Feb 3 03:21:09 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <20090202220435.GB13113@whirlpool.galois.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> Message-ID: <11b141710902030031t26fbccw3a219ceb8fdc9b26@mail.gmail.com> On Mon, Feb 2, 2009 at 10:04 PM, Don Stewart wrote: > pocmatos: >> Hi all, >> >> Much is talked that Haskell, since it is purely functional is easier > > to be verified. > However, most of the research I have seen in software > verification > (either through model checking or theorem proving) > targets C/C++ or > subsets of these. What's the state of the art of > automatically > verifying properties of programs written in Haskell? >> > > State of the art is translating subsets of Haskell to Isabelle, and > verifying them. Using model checkers to verify subsets, or extracting > Haskell from Agda or Coq. > Any references to publications related to this? > -- Don > -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm From pocmatos at gmail.com Tue Feb 3 03:31:40 2009 From: pocmatos at gmail.com (Paulo J. Matos) Date: Tue Feb 3 03:21:48 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <20090203002822.GC13468@whirlpool.galois.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> <6dbd4d000902021627w7ec9e909x25a9221bf3993de6@mail.gmail.com> <20090203002822.GC13468@whirlpool.galois.com> Message-ID: <11b141710902030031nd6682a2o8e82299843c7f068@mail.gmail.com> On Tue, Feb 3, 2009 at 12:28 AM, Don Stewart wrote: > dbueno: >> On Mon, Feb 2, 2009 at 15:04, Don Stewart wrote: >> > pocmatos: >> >> Hi all, >> >> >> >> Much is talked that Haskell, since it is purely functional is easier > >> > to be verified. > However, most of the research I have seen in software >> > verification > (either through model checking or theorem proving) >> > targets C/C++ or > subsets of these. What's the state of the art of >> > automatically > verifying properties of programs written in Haskell? >> >> >> > >> > State of the art is translating subsets of Haskell to Isabelle, and >> > verifying them. Using model checkers to verify subsets, or extracting >> > Haskell from Agda or Coq. >> >> Don, can you give some pointers to literature on this, if any? That >> is, any documentation of a verification effort of Haskell code with >> Isabelle, model checkers, or Coq? >> >> (It's not that I don't believe you -- I'd be really interested to read it!) > > > All on haskell.org, > > http://haskell.org/haskellwiki/Research_papers/Testing_and_correctness#Verifying_Haskell_programs > > And there's been work since I put that list together. > Opps, sorry, missed this message. Should read everything before replying! :) > -- Don > -- Paulo Jorge Matos - pocmatos at gmail.com Webpage: http://www.personal.soton.ac.uk/pocm From DekuDekuplex at Yahoo.com Tue Feb 3 03:46:54 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Tue Feb 3 03:37:16 2009 Subject: [Haskell-cafe] Re: pure crisis :) References: <593855719.20090201221918@gmail.com> Message-ID: <1p0go41u579p2vig3us8d35mo2psr1fm4j@4ax.com> On Mon, 02 Feb 2009 23:43:26 +0100, "Henk-Jan van Tuyl" wrote: > >On Sun, 01 Feb 2009 20:19:18 +0100, Bulat Ziganshin > wrote: > >> Hello haskell-cafe, >> >> pure functional denotation for crisis: >> >> (_|_) >> > >Well, some experts say, the crisis has reached it's bottom. Yet some say that the bottom of the crisis is still undefined. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From apfelmus at quantentunnel.de Tue Feb 3 04:10:58 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Tue Feb 3 04:00:36 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: John A. De Goes wrote: > > The size, color, and layout of widgets has no effect on interaction > semantics and is best pushed elsewhere, into a designer-friendly realm > such as CSS. Yes, layout can be separated from interaction. It's just that I don't consider CSS friendly at all, I'd say it's a 0th order language. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] -> Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Regards, apfelmus -- http://apfelmus.nfshost.com From marco-oweber at gmx.de Tue Feb 3 04:19:26 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Feb 3 04:09:40 2009 Subject: [Haskell-cafe] Re: hslogger bugs or features? In-Reply-To: <49877B0B.5030905@complete.org> References: <20090201012818.GA11418@gmx.de> <49877B0B.5030905@complete.org> Message-ID: <20090203091926.GA10222@gmx.de> Hi John, thank you for your feedback: I've taken the time to rewrite the example (issue1) using the python logging system. I came up with: import logging logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s %(message)s', filename='/tmp/myapp.log', filemode='w') logging.getLogger('').setLevel(logging.DEBUG) loggerSub = logging.getLogger('A.B.C') loggerSub.critical('CRITICAL test, should be shown and should create the sublogger') logging.getLogger('').setLevel(logging.WARNING) loggerSub.debug('WARNING test, should not be shown cause we have changed to WARNING') which only logs the first line but not the second one 2009-02-03 11:14:52,058 CRITICAL CRITICAL test, should be shown and should create the sublogger hackage hslogger does clone the priority setting for A.B.C (in getLogger). The cloned value is no longer affected by when changing the top level logging priority. So this example makes hackage hslogger log both lines. So I consider this a beeing a (small) bug. Sincerly Marc Weber From blancolioni at gmail.com Tue Feb 3 04:28:48 2009 From: blancolioni at gmail.com (Fraser Wilson) Date: Tue Feb 3 04:19:05 2009 Subject: [Haskell-cafe] Why binding to existing widget toolkits doesn't make any sense In-Reply-To: <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> Message-ID: You know, I read the Fudgets thesis, and threw together an experiment which used Glade for layout and Haskell for semantics [1]. As somebody else noted, this isn't really a clean division, because of things like editable flags in the layout. The darcs repository has a couple of demo applications, there's also a Bridge game that doesn't quite work (not included), and I understand that Arrows would solve all my problems, but I still don't grok them, alas. What I found was that wiring the events through the application in a nice, functional way was quite tricky, but it was unclear whether this was just an API problem, or something more fundamental. The entire state seems to turn up in every connection between widgets (which really suggests that it's imperative with a veneer of declarative style, which of course it is). For example, you need a changed flag in the state of the text editor. This is updated by a signal from the text widget, and read by the main window (because it affects the title bar text), the File/New and File/Open menu items (need to put up a "Save Changes?" message box) and the main window destroy handler (same thing, but it also needs some way of cancelling the action). Unfortunately, the main window is at one end of the event chain, while the menu is all the way over on the other side. This leads to tricky composition, and widgets which pass the entire state to each other because there's one little bit of information they might need. A related issue is that the application is like a river, in which events flow from one end to the other. Send events back the other way is ugly. Some sort of blackboard design might work better. This conversation made me start thinking about replacing Glade with a Haskell layout language, but I still don't know how to solve the above problems. I should read the FRP papers again. cheers, Fraser. [1] http://thewhitelion.org/darcs/barrie On Mon, Feb 2, 2009 at 8:58 PM, John A. De Goes wrote: > > The actual presentation and layout of widgets would be better handled by a > DSL such as CSS (which is, in fact, declarative in nature), while event > logic would be best handled purely in Haskell. > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > > On Feb 2, 2009, at 12:39 PM, Creighton Hogg wrote: > > 2009/1/29 Conal Elliott : >> >>> Hi Achim, >>> >>> I came to the same conclusion: I want to sweep aside these OO, imperative >>> toolkits, and replace them with something "genuinely functional", which >>> for >>> me means having a precise & simple compositional (denotational) >>> semantics. >>> Something meaningful, formally tractable, and powefully compositional >>> from >>> the ground up. As long as we build on complex legacy libraries (Gtk, >>> wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling against (or worse >>> yet, >>> drawn into) their ad hoc mental models and system designs. >>> >>> As Meister Eckhart said, "Only the hand that erases can write the true >>> thing." >>> >> >> I think working on a purely functional widget toolkit would actually >> be a really cool project. Do you have any ideas, though, on what >> should be the underlying primitives? >> >> The initial gut feeling I have is that one should just ignore any >> notion of actually displaying widgets & instead focus on a clean >> algebra of how to 'add' widgets that relates the concepts of >> inheritance & relative position. What I mean by inheritance, here, is >> how to direct a flow of 'events'. I don't necessarily mean events in >> the Reactive sense, because I think it'd be important to make the >> model completely independent of how time & actual UI actions are >> handled. >> >> Any thoughts to throw in, here? >> >> Cheers, >> C >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- http://thewhitelion.org/mysister -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/86abaf14/attachment-0001.htm From leather at cs.uu.nl Tue Feb 3 04:38:14 2009 From: leather at cs.uu.nl (Sean Leather) Date: Tue Feb 3 04:28:29 2009 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <1233626633.26754.561.camel@localhost> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> <3c6288ab0902020418w40c48707y6881ea9976adf024@mail.gmail.com> <1233626633.26754.561.camel@localhost> Message-ID: <3c6288ab0902030138o4b4e41bag61f2bd07f3baf4ad@mail.gmail.com> > Presumably the template-haskell-2.3 package does not build with ghc-6.8 > but fails to correctly specify the version of base or ghc that it > requires. If it did then we would have a better chance to get this > right. > Yes, this is certainly an issue in general with template-haskell-2.3. How do we fix this? > Another possible workaround... > > If you avoid using the flag hack then the solver would not have to > choose so early which version of template-haskell to commit to and it > would be able to pick the right version later. Though then you need an > alternative method of finding which version of template-haskell you > ended up with. You could do it with some custom code in Setup.hs. > I don't mind using a different approach. How do I detect which version of template-haskell I'm using in Setup.lhs that is backwords compatible to Cabal 1.2? I would like to support both template-haskell-2.2 and -2.3 by deriving EMGM type representations for it, but the later has the 'Loc' datatype. So, I'm currently using the CPP flag to determine whether 'Loc' is available or not: *#ifdef TH_LOC_DERIVEREP **-- This type is only provided in template-haskell-2.3 (included with GHC 6.10) **-- and up. *$(derive ''Loc) *#endif * Thanks, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/44eb7102/attachment.htm From mad.one at gmail.com Tue Feb 3 04:40:47 2009 From: mad.one at gmail.com (Austin Seipp) Date: Tue Feb 3 04:30:58 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <11b141710902030031t26fbccw3a219ceb8fdc9b26@mail.gmail.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> <11b141710902030031t26fbccw3a219ceb8fdc9b26@mail.gmail.com> Message-ID: <1233653807-sup-5310@existential.local> Excerpts from Paulo J. Matos's message of Tue Feb 03 02:31:00 -0600 2009: > Any references to publications related to this? While it's not Haskell, this code may be of interest to you: http://pauillac.inria.fr/~xleroy/bibrefs/Leroy-compcert-06.html This paper is about the development of a compiler backend using the Coq proof assistant, which takes Cminor (a C-like language) and outputs PowerPC assembly code. Coq is used both to program the compiler and prove it is correct. Austin From mad.one at gmail.com Tue Feb 3 04:43:55 2009 From: mad.one at gmail.com (Austin Seipp) Date: Tue Feb 3 04:34:06 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <1233653807-sup-5310@existential.local> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> <11b141710902030031t26fbccw3a219ceb8fdc9b26@mail.gmail.com> <1233653807-sup-5310@existential.local> Message-ID: <1233654185-sup-7549@existential.local> Excerpts from Austin Seipp's message of Tue Feb 03 03:40:47 -0600 2009: > ... After noticing that I didn't give a link to the code in the last message, I searched and found this more up to date page I think: http://compcert.inria.fr/doc/index.html > Austin From marco-oweber at gmx.de Tue Feb 3 04:50:19 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Feb 3 04:40:30 2009 Subject: [Haskell-cafe] Bytestrings vs String? parameters within package names? In-Reply-To: <4987BD05.4020307@freegeek.org> References: <20090202224540.GB24610@gmx.de> <4987BD05.4020307@freegeek.org> Message-ID: <20090203095019.GB10222@gmx.de> On Mon, Feb 02, 2009 at 10:41:57PM -0500, wren ng thornton wrote: > Marc Weber wrote: > > Should there be two versions? > > hslogger-bytestring and hslogger-string? > > I'd just stick with one (with a module for hiding the conversions, as > desired). Duplicating the code introduces too much room for maintenance and > compatibility issues. > > That's the big thing. The more people that use ByteStrings the less need > there is to convert when combining libraries. That said, ByteStrings aren't > a panacea; lists and laziness are very useful. Hi wren, In the second paragraph you agree that there will be less onversion when using only one type of strings. You're also right about encoding. About laziness you'r partially right: There is also Bytestring.Lazy which is a basically a list of (non lazy) Bytestring > Duplicating the code introduces too much room for maintenance and > compatibility issues. I didn't mean duplicating the whole library. I was thinking about a cabal flag the cabal file: flag bytestring Default: False Description: enable this to use Bytestrings everywhere instead of strings [... now libs and executables: ...] if flag(bytestring) cpp-options: -DUSE_BYTESTRING An example module module Example where #ifdef Strings import Data.List as S #endif #ifdef USE_BYTESTRINGS import Data.ByteString as S #endif #ifdef USE_LAZY_BYTESTRINGS import Data.ByteString.LAZY as S #endif #ifdef USE_UNICODE_BYTESTRING_LIKE_STRINGS -- two bytes per char or more? -- they can also be lazy such as Strings however one array element can -- have more than one byte import Data.Vector as S #endif Of course all four modules import Data.List as S import Data.ByteString as S import Data.ByteString.LAZY as S import Data.Vector as S must expose the same API.. Of course cluttering up all files using those ifdefs isn't a nice option either. But one could move this selection into the cabal file either depending on one of those (no yet existing) packages: string-string string-bytestring string-utf8-bytestring string-bytestring string-bytestring-lazy Then you could replace one implementation by the other and recompile and see wether the results differ. Of course we must take care that we can keep laziness if required. However using different packages exposing the same API (same modules and same name will cause trouble if you really have to use both implementations at some time. I only konw that there has been some discussion about how to tell ghc to use a module from a particual package. ..) So I'd like to propose another way: {-# LANGUAGE CPP #-} import Data.STRING as S and tell .cabal to define STRING representing either of the different string implementations. I think this would be most portable and you can additionally import other String modules as well. So for now I think it would be best if you could teach cabal to change names depending on flags: Name: hslogger-${STRING_TYPE} flag: use_strings set STRING_TYPE = String flag: use_bytestrings set STRING_TYPE = Bytestring ..... Don't think about this issue how it is now or how much effort it would be to rewrite everything. Think about it how you'd like to work using haskell in about a year. Marc From ganesh.sittampalam at credit-suisse.com Tue Feb 3 04:50:39 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Tue Feb 3 04:41:30 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <20090202225218.GE13113@whirlpool.galois.com> References: <16442B752A06A74AB4D9F9A5FF076E4B4DCB86@ELON17P32001A.csfb.cs-group.com> <20090202225218.GE13113@whirlpool.galois.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCB8A@ELON17P32001A.csfb.cs-group.com> Don Stewart wrote: > ganesh.sittampalam: >> Don Stewart wrote: >>> So, windows@haskell.org anyone? Get the wiki going, get the set of >>> tasks created. >> >> Isn't the Haskell Platform going to do all this? Shouldn't >> interested people just help out there? >> > > The platform is a set of blessed libraries and tools. The distros > will still need to package that. > > To do that for Windows, we're still going to need a windows packaging > team, along side Debian, Arch, Gentoo, Mac etc. http://www.haskell.org/haskellwiki/Haskell_Platform section 4 talks about making distributions. So what should people be trying to do? Focus on (a) general infrastructure for packaging any Haskell library/binary on Windows (etc), or on (b) the specific task of packaging the Haskell Platform? If (b) then I don't think a whole new mailing list/wiki etc is worthwhile. (a) would obviously be nicer but is no doubt a much harder problem - I guess we'd want to start with Bamse and perhaps make use of the "nestedInstalls" feature somehow. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From duncan.coutts at worc.ox.ac.uk Tue Feb 3 04:52:02 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 3 04:41:58 2009 Subject: [Haskell-cafe] Cabal and more than one version In-Reply-To: <3c6288ab0902030138o4b4e41bag61f2bd07f3baf4ad@mail.gmail.com> References: <42784f260811180148v7c48ed46p18132f44a377f8bf@mail.gmail.com> <1227043805.21705.42.camel@dell.linuxdev.us.dell.com> <3c6288ab0902020418w40c48707y6881ea9976adf024@mail.gmail.com> <1233626633.26754.561.camel@localhost> <3c6288ab0902030138o4b4e41bag61f2bd07f3baf4ad@mail.gmail.com> Message-ID: <1233654722.26754.569.camel@localhost> On Tue, 2009-02-03 at 10:38 +0100, Sean Leather wrote: > > Presumably the template-haskell-2.3 package does not build > with ghc-6.8 > but fails to correctly specify the version of base or ghc that > it > requires. If it did then we would have a better chance to get > this > right. > > Yes, this is certainly an issue in general with template-haskell-2.3. > How do we fix this? We patch the .cabal file in the current darcs version so that its fixed in the next release. > Another possible workaround... > > If you avoid using the flag hack then the solver would not > have to > choose so early which version of template-haskell to commit to > and it > would be able to pick the right version later. Though then you > need an > alternative method of finding which version of > template-haskell you > ended up with. You could do it with some custom code in > Setup.hs. > > I don't mind using a different approach. How do I detect which version > of template-haskell I'm using in Setup.lhs that is backwords > compatible to Cabal 1.2? You get access to the LocalBuildInfo which contains the packageDeps, the exact package identifiers. You can find the package you're after and find its version. Then you can do one of two things. You could generate a .h file either during post-conf or pre-build or you could add a cpp option by updating the localPkgDescr in the LocalBuildInfo to add an extra cpp option. It's not necessarily short or pretty, but it should be possible to make it work with Cabal-1.2 and 1.6. Duncan From duncan.coutts at worc.ox.ac.uk Tue Feb 3 04:53:59 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 3 04:43:55 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <404396ef0902030026g4230e893r980db1353fed1bf7@mail.gmail.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> <20090202220344.GA13113@whirlpool.galois.com> <404396ef0902030026g4230e893r980db1353fed1bf7@mail.gmail.com> Message-ID: <1233654839.26754.573.camel@localhost> On Tue, 2009-02-03 at 08:26 +0000, Neil Mitchell wrote: > Hi > > > GHC doesn't bundle with cabal-install on any system. > > > > What is needed is not for the GHC team to be doing Windows platform > > packages, but for the Windows Haskell devs to build their own system, as > > happens on all the Unices. > > > > Take GHC's release, wrap it up with native installers, throw in useful > > libraries and executables like cabal. Done. > > GHC already takes the GHC release, bundles it up with a native > installer, and then throws in useful executables like gcc. It just > stops one hop short of "done". Windows is special, we already treat > Windows special, but currently its just short of useable. Right, that's the job the platform will take on. > Duncan: Saying cabal.exe isn't mature enough to go in 6.10 is a > perfect reason, but one that you never gave at the time. If it isn't > ready, then that's fine. But if thats the case, will it be in 6.12, or > will the standard Windows instructions involve hunting around > haskell.org for a prebuild Cabal.exe? It'll be in the first platform release which will be well before ghc 6.12. BTW, I think I've been missing your advice and cajoling about Windows platforms. It's been rather quiet recently. Duncan From duncan.coutts at worc.ox.ac.uk Tue Feb 3 05:04:03 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 3 04:53:57 2009 Subject: [Haskell-cafe] Re: circular dependencies in cabal In-Reply-To: <7802E7F3-4D3A-4D8E-8765-2CB2BA4D39A6@kamysh.org> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> <1233567077.26754.475.camel@localhost> <20090203021106.13b07e14@solaris> <1233624874.26754.536.camel@localhost> <7802E7F3-4D3A-4D8E-8765-2CB2BA4D39A6@kamysh.org> Message-ID: <1233655443.26754.579.camel@localhost> On Mon, 2009-02-02 at 19:16 -0800, Valentyn Kamyshenko wrote: > Hi Duncan, > > The major problem that I see is with > # cabal update > # cabal upgrade > sequence of operations (that is, upgrading all installed packages). Right, that's exactly what doesn't work well and that I'm proposing to temporarily disable. > I use this regularly to keep packages that I use (or are going to use) > up to date. > This is the functionality that, I suppose, everybody expects from the > system like hackage/cabal. > > And, so far as I can see, the major problem is that 'cabal upgrade' > will happily upgrade packages, that the core package depends on, and > eventually will create configuration with circular dependencies. > Can we do something simple - like, for example, forbidding updates of > the packages that the core depends on (directly and indirectly)? Yes and there are a couple of additional ways we could improve it. But I'm thinking it'd be better to release before those things are done, and so in the mean time disable upgrade. In the mean time we can make it list the available packages that are newer than the installed ones and you get to pick manually which ones are sensible to install. Duncan From bit at mutantlemon.com Tue Feb 3 06:48:28 2009 From: bit at mutantlemon.com (Bit Connor) Date: Tue Feb 3 06:38:38 2009 Subject: [Haskell-cafe] FP simulators for real-time systems? In-Reply-To: <5DBD4306-16F7-420C-A993-40BB0DE85DD2@gmail.com> References: <5DBD4306-16F7-420C-A993-40BB0DE85DD2@gmail.com> Message-ID: <6205bd290902030348q6c578f45v9c9d52d4035b0fb9@mail.gmail.com> On Mon, Feb 2, 2009 at 10:43 AM, Lee Pike wrote: > I'm interested to hear if anyone out there has used Haskell (or other > functional languages for that matter) to build simulators for real-time > systems. This is probably not exactly what you are thinking of, but there is OmegaGB, a game boy emulator written in Haskell: http://www.mutantlemon.com/omegagb/ Peace, Bit From barsoap at web.de Tue Feb 3 07:57:32 2009 From: barsoap at web.de (Achim Schneider) Date: Tue Feb 3 07:47:50 2009 Subject: [Haskell-cafe] GUI semantics [was: Achim ranting] References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> Message-ID: <20090203135732.79389049@solaris> First of all, thanks. I had almost judged the cafe to be unable to discuss any UI issue except rendering backends. Fraser Wilson wrote: > You know, I read the Fudgets thesis, and threw together an experiment > which used Glade for layout and Haskell for semantics [1]. As > somebody else noted, this isn't really a clean division, because of > things like editable flags in the layout. The darcs repository has a > couple of demo applications, there's also a Bridge game that doesn't > quite work (not included), and I understand that Arrows would solve > all my problems, but I still don't grok them, alas. > It depends on what you may flag as editable. I just re-watched Conal's techtalk about TV's, which short-circuited a few neurons that were held apart by things like Functors and the ilk: Flagging an input as editable or not is OK, flagging an output is not (duh). In retrospect, TV's appear to me as being too denotationalistic[1]: From what I can tell, the way a String is displayed is _solely_ controlled by the run* functions. In a line-oriented text environment there's only one way, so it doesn't matter, but in a GUI, you might want to display it either as a label, or as an input-disabled textbox (so the user can copy the string). It might also be the text of a button, or the label of a node edge in a graph editor. Reactive gives us a way to describe the String (and other things) as a function of time, now we need to figure out how to describe the rest of its properties: A thing is not only defined by its inherent properties, but also by its interaction with the rest of the world. A hungry cat next to a mouse behaves different from a hungry cat next to a stone; how can we make a String aware of being the input of a label vs. being the input of a textbox, without shoving all knowledge of interaction into the world itself? Can we avoid specifying "into textbox" or "into label" (or "in 14.5pt slanted Helvetica") if we don't care or the rendering backend just doesn't support it? Can we specify a new renderer that knows about a new attribute, and enrich our model with that attribute without changing the whole core? > What I found was that wiring the events through the application in a > nice, functional way was quite tricky, but it was unclear whether > this was just an API problem, or something more fundamental. The > entire state seems to turn up in every connection between widgets > (which really suggests that it's imperative with a veneer of > declarative style, which of course it is). > I've also noticed this. Right now, my code would thread one event stream through everything, splitting and rejoining as necessary, but always uni-directional and staying one stream[2]. If I wanted feedback (I do, but haven't actually implemented it), I'd send an event down the stream, collect it at the end, and sink it back into the beginning (via IO, that is, threads and mvars). I bet there's a way to define fixpoints on event streams so that feedback does not have to take a full round-trip, and, most importantly, can flow on more paths than one, and I'm absolutely positive that it would break my current model (which, most likely, would be a good thing to do). I'm also not using Behaviours at all, which annoys me: I'd say "textbox, change the string of that label if you're changed", not "label, you form a Widget behaviour influenced by the string output of that Widget over there (which happens to be a textbox)". I guess that once I understand what fixpoints mean in this context, stuff will clear up a lot. [1] TM. [2] It is modelled as a tuple of two streams of different type, one getting drained by handling functions, the other filled. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From dev at mobileink.com Tue Feb 3 09:09:22 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Tue Feb 3 08:59:30 2009 Subject: [Haskell-cafe] type and data constructors in CT In-Reply-To: <49a77b7a0902021327g4cee2d5fy7343d97af8a7e25e@mail.gmail.com> References: <75cc17ac0901310900g42e3043q3892d6862f9c26e8@mail.gmail.com> <49a77b7a0901311314q298a1986sbcab5cc95c32c186@mail.gmail.com> <75cc17ac0902010936r523c6fd3i7064dc1e813e94b1@mail.gmail.com> <49a77b7a0902021327g4cee2d5fy7343d97af8a7e25e@mail.gmail.com> Message-ID: <75cc17ac0902030609y2483e6a6j7e1139d8c069d9e1@mail.gmail.com> On Mon, Feb 2, 2009 at 3:27 PM, David Menendez wrote: > Does that help at all? > I think it does. But ... it gives me crazy ideas. Like: a functor is a kind of magic non-computing function! That's why they didn't call it a function? We know it maps A to FA, but we don't know how (maybe we don't care): there's no algorithm, just a functorific magic carpet that transports us across the border to FA. We couldn't compute FA even if we wanted to - different categories are like alternate universes, it would be like producing a widget in an alternate physical universe, we have no way of even thinking of how to do that. Ditto for data constructors as natural transformations: they don't compute, they just do magic. They're the CT surgeon's devious way of working on the guts of a categorical object without getting his hands dirty with mundane functions - getting from value A to (an?) image value of A under the functor F, which we cannot do directly by algorithm or computation. We do not - can not - have an actual function that computes A's image. We have to work indirectly, using non-computing magic carpets - first Id takes us to Id A, then we follow the nat trans to FA. Ok, that probably triggers the gag reflex for a real mathematician, but it sure sounds like a good story to me (remember, I'm taking notes for a guide/tutorial for newbies that may or may not ever get written.) Thanks very much for the help, -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/f7cc2484/attachment.htm From jgoerzen at complete.org Tue Feb 3 10:15:37 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 10:05:45 2009 Subject: [Haskell-cafe] Re: hslogger bugs or features? In-Reply-To: <20090201012818.GA11418@gmx.de> References: <20090201012818.GA11418@gmx.de> Message-ID: <49885F99.8000305@complete.org> Marc Weber wrote: > Following the advice on the hslogger wiki > (http://software.complete.org/software/wiki/hslogger) > I'm posting my thoughts about hslogger here: Hi Marc, Thanks for posting this. Let's start with a big-picture architecture overview. What need does hslogger anticipate meeting? * Big applications have varied logging needs. * Small applications want to keep logging simple. * It is often desirable to enable or disable logging about certain types of things. * It is also often desirable to enable or disable logging above a certain threshold of importance. * The vast majority of apps want to set logging preferences once and then forget about them, having decided what to do by reading a config file, command line, or whatever. * There can be many different ways to output logging messages: syslog, stderr, files, etc. A given app may want to use more than one of them. There are a lot of logging frameworks out there. Many of them fail the "keep logging simple" test. Many others fail the "varied needs" test. One that failed neither in my experience was the Python logging infrastructure, so I based hslogger around its interface. hslogger has served me pretty well since, though I wish it were a bit stronger on the simple side. > This piece of code (src/System/Log/Logger.hs): > > parentHandlers name = > let pname = (head . drop 1 . reverse . componentsOfName) name > in do > [...] > next <- parentHandlers pname > return ((handlers parent) ++ next) > > Why? > Because when logging to "A.B.C" it splits the String once to get > ["A","B","C"], then it drops the last part and runs the same again for > "A.B" and so on.. > So A string is split > 3 times for one logging action. I think this is a > waste of cpu cycles.. I'm going to improve this. While reading the code > i noticed two issues: It may be, but really this is trivially tiny. The effort required to do that is almost certainly exceptionally tiny compared just to the effort required to actually output the log message. If you have a simple fix, that's fine, but let's not complicate the code to save a 2 CPU cycles in a process that can't possibly use less than 1000 :-) > ====================================================================== > issue 1 > > That's not the most awkward thing: > When logging to "A.B.C" hslogger does add 3 loggers to the global > logger Map: Only if you haven't logged to it before. > "A" > "A.B" > "A.B.C" > all three inheriting the default priority level of the default > rootLogger "" According to the docs: First of all, whenever you first access a given logger by name, it magically springs to life. It has a default 'Priority' of 'DEBUG' and an empty handler list -- which means that it will inherit whatever its parents do. It's not setting the priority to the rootLogger default; it's setting it to DEBUG. Your test doesn't invalidate this. > A test application illustrating this (feature ?) > > module Main where > -- packages: hslogger > import System.Log.Logger as HL > import System.Log.Handler.Simple as HL > > main = do > -- the default logger logs to stderr level WARNING > -- that's why the following message should be shown > > -- a) > logM "A.B.C" HL.ALERT "ALERT test, should be shown and should create the sublogger" > > -- b) > updateGlobalLogger rootLoggerName (setLevel EMERGENCY) > > logM "A.B.C" HL.ALERT "ALERT test, should not be shown cause we have changed to EMERGENCY" > > which prints: > > tmp %./test1 > /tmp nixos > ALERT test, should be shown and should create the sublogger > ALERT test, should not be shown cause we have changed to EMERGENCY > > which is quite confusing because I haven't told hslogger explicitely > to use a log level printing ALERTs on "A.B.C". so I'd expect that only No, you told it that things logged to the root logger directly have a certain preference. You have never expressed any preference whatsoever on the A.B.C logger. If you wish to set a global preference on the level of logging to occur, you would be better served to do so in the configuration for the handler. From the docs: To give you one extra little knob to turn, 'LogHandler's can also have importance levels ('Priority') associated with them in the same way that 'Logger's do. They act just like the 'Priority' value in the 'Logger's -- as a filter. It's useful, for instance, to make sure that under no circumstances will a mere 'DEBUG' message show up in your syslog. Since handlers are inherited down the logger chain, you can easily tweak the priority associated with the handlers at the root logger level and have an instant impact on all the others. The point of the priority attached to a logger is to be able to disable messages *about* certain things. The point of the priority attached to a handler is to be able to disable messages *below a certain importance level globally*. So I think you're trying to turn the wrong knob to achieve your desired goal. > ====================================================================== > issue 2 > > The second ineresting point is (bug or feature?) that you can make the > root logger shut up by setting different log levels to sub loggers: > > this sample does illustrate it: It doesn't illustrate that. You logged to the "A" logger, not the root logger. Let's look at it below. > > module Main where > -- packages: hslogger > import System.Log.Logger as HL > import System.Log.Handler.Simple as HL > > main = do > updateGlobalLogger "" (setLevel DEBUG) > updateGlobalLogger "A" (setLevel EMERGENCY) > logM "A" HL.ALERT "ALERT test, should not be shown cause we have > changed to EMERGENCY" > It doesn't print anything although the default log handler on root (="") > is set to loglever DEBUG. So there is no way to get all logmessages So what you've done here is tell hslogger that for log events regarding "A", you don't want to hear about anything unless it's an EMERGENCY. And hslogger followed your instructions directly. > without removing all all setLevel calls to subloggers? > Is this desirable? I don't understand the problem. If you told hslogger that you didn't want to hear about stuff about "A", why do you not like that it is following your instructions? Note that you didn't actually change the priority of the handler up there. You changed the priority of the *logger*. Remember, logger priorities aren't inherited. As I said, I think your whole problem would be solved if you simply changed the priority of the handler associated with the root logger. -- John From jgoerzen at complete.org Tue Feb 3 10:37:50 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 10:27:59 2009 Subject: [Haskell-cafe] hslogger bugs or features - patches In-Reply-To: <20090202225607.GB7016@gmx.de> References: <20090201012818.GA11418@gmx.de> <20090202225607.GB7016@gmx.de> Message-ID: <498864CE.4090902@complete.org> Marc Weber wrote: > > I've written some patches increasing speed by 30%. See the benchmark. Hi Marc, Patches are always great to see! Where is this benchmark? Can you separate out your speed changes (which I take it have no impact on functionality or API) from your other changes? I am not certain that I would want to apply the other changes. > You can get them by cloning git://mawercer.de/hslogger; > (branch hslogger_updates) > > I've replaced the internal representation (Map name Logger) by a tree. > Only logging to a logger does no longer add a new node (which cloned the > priority level in the past causing issue 1) As I said, I'm not really convinced this is a real issue. I'm still open to it though -- but I'm unconvinced that the change in API is worth it at this point. > Also I've removed the standard setup logging to stderr. There is a > setupLogging function instead.. I'm not sure what you mean the "standard setup logging to stderr". Do you mean the default root handler? > Why? I can think of some use cases where logging to stderr doesn't make > sense and it took me too much time figuring out how to remve the old > stderr logger (I didn't find a nice solution without changing the > exposed API) You didn't notice setHandlers? -- | Set the 'Logger'\'s list of handlers to the list supplied. -- All existing handlers are removed first. setHandlers :: LogHandler a => [a] -> Logger -> Logger It is perfectly valid to set the root logger's handlers to [] if you want it to do nothing at all. > I don't want to start using my "personal" copy of hslogger. That's why > I'd like to ask you wether you consider these changes beeing > improvements although they break existing code (You'll have do add that > initialization line) At this point, I'm not convinced that the API changes are actual improvements. But I'm not saying "never". > I also wonder wether it's worth using Bytestrings instead of Strings? To what end? The only reason I can think of is UTF-8 output. (does putStr output UTF-8 these days, or still truncate the 24 bits above the low 8 like it used to? I haven't checked.) -- John From jgoerzen at complete.org Tue Feb 3 10:41:38 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 10:31:47 2009 Subject: [Haskell-cafe] Bytestrings vs String? parameters within package names? In-Reply-To: <20090203095019.GB10222@gmx.de> References: <20090202224540.GB24610@gmx.de> <4987BD05.4020307@freegeek.org> <20090203095019.GB10222@gmx.de> Message-ID: <498865B2.4090300@complete.org> Marc Weber wrote: > On Mon, Feb 02, 2009 at 10:41:57PM -0500, wren ng thornton wrote: >> Marc Weber wrote: >>> Should there be two versions? >>> hslogger-bytestring and hslogger-string? >> I'd just stick with one (with a module for hiding the conversions, as >> desired). Duplicating the code introduces too much room for maintenance and >> compatibility issues. >> >> That's the big thing. The more people that use ByteStrings the less need >> there is to convert when combining libraries. That said, ByteStrings aren't >> a panacea; lists and laziness are very useful. > > Hi wren, > > In the second paragraph you agree that there will be less onversion when > using only one type of strings. Incidentally, I already wrote a library that abstracts the difference between a String and a ByteString: ListLike. I don't think anybody, including me, even uses it now. Turns out that's not all that helpful an abstraction to make ;-) -- John From newsham at lava.net Tue Feb 3 10:54:01 2009 From: newsham at lava.net (Tim Newsham) Date: Tue Feb 3 10:44:27 2009 Subject: [Haskell-cafe] Verifying Haskell Programs In-Reply-To: <6dbd4d000902021627w7ec9e909x25a9221bf3993de6@mail.gmail.com> References: <11b141710902010454w55f2f5eey13ae1f352fe91170@mail.gmail.com> <20090202220435.GB13113@whirlpool.galois.com> <6dbd4d000902021627w7ec9e909x25a9221bf3993de6@mail.gmail.com> Message-ID: >> State of the art is translating subsets of Haskell to Isabelle, and >> verifying them. Using model checkers to verify subsets, or extracting >> Haskell from Agda or Coq. > > Don, can you give some pointers to literature on this, if any? That > is, any documentation of a verification effort of Haskell code with > Isabelle, model checkers, or Coq? Graham Hutton's _Programming in Haskell_ has a chapter on reasoning about Haskell code: http://www.cs.nott.ac.uk/~gmh/book.html I put together some exercises of some short proofs for small Haskell functions: http://www.thenewsh.com/~newsham/formal/problems/ I have a short article that covers proofs in Haskell and Isabelle: http://users.lava.net/~newsham/formal/reverse/ The seL4 project is specifying an OS in Haskell, proving it in Isabelle and translating it to C with proofs that connect the translations: http://ertos.nicta.com.au/research/sel4/ I have an article on the curry-howard correspondence http://www.thenewsh.com/~newsham/formal/curryhoward/ In systems like Coq you can write code and proofs of the code in the same language and even at the same time. The Coq'Art book is a good reference, as are Adam Chlipala's draft book and Harvard class materials and the _Type Theory & Functional Programming_ book. Full text for all but Coq'Art are online: http://www.labri.fr/perso/casteran/CoqArt/index.html http://www.cs.harvard.edu/~adamc/cpdt/ http://www.cs.harvard.edu/~adamc/cpdt/book/ http://www.cs.kent.ac.uk/people/staff/sjt/TTFP/ > Denis Tim Newsham http://www.thenewsh.com/~newsham/ From jgoerzen at complete.org Tue Feb 3 10:57:24 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 10:47:33 2009 Subject: [Haskell-cafe] Re: hslogger bugs or features? In-Reply-To: <20090203091926.GA10222@gmx.de> References: <20090201012818.GA11418@gmx.de> <49877B0B.5030905@complete.org> <20090203091926.GA10222@gmx.de> Message-ID: <49886964.3070509@complete.org> Marc Weber wrote: > Hi John, > > thank you for your feedback: > I've taken the time to rewrite the example (issue1) using the python > logging system. I came up with: I think what you're noticing is the NOTSET level in Python. Python creates new loggers with the priority NOTSET, which means it searches up the tree for a logger with a priority /= NOTSET, and uses the first priority it finds. hslogger doesn't have NOTSET, and each logger does have a specific priority. The Python NOTSET priority does sound like a useful addition to hslogger, though. I think it would solve what you're after with minimal invasiveness. > hackage hslogger does clone the priority setting for A.B.C (in getLogger). Yes, I see that; looks like the docs are incorrect on that point. But this only comes into play if you are changing the logging level on a particular subset of a running program. Does that really happen often in practice? I'd be happy to add NOTSET semantics to hslogger. -- John From marlowsd at gmail.com Tue Feb 3 11:42:44 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 3 11:32:58 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O Message-ID: <49887404.4070504@gmail.com> I've been working on adding proper Unicode support to Handle I/O in GHC, and I finally have something that's ready for testing. I've put a patchset here: http://www.haskell.org/~simonmar/base-unicode.tar.gz That is a set of patches against a GHC repo tree: unpack the tarball, and say 'sh apply /path/to/ghc/repo' to apply all the patches. Then clean your tree and build it from scratch (or if you're using the new GHC build system, just say 'make' ;-). It should validate, bar one or two minor failures. Oh, it doesn't work on Windows yet. That's the major thing left to do. If anyone else felt like tackling this I'd be delighted: all you have to do is implement a Win32 equivalent of the module GHC.IO.Encoding.Iconv (see below), everything else should work unchanged. Depending on whether any further changes are required, I may amend-record some of these patches, so treat them as temporary patches for testing only. Below is what will be the patch description in the patch for libraries/base. Comments/discussion please! Cheers, Simon Unicode-aware Handles ~~~~~~~~~~~~~~~~~~~~~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing encoding of the system. Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: hSetEncoding :: Handle -> TextEncoding -> IO () and various encodings: latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). Currently hSetEncoding is availble from GHC.IO.Handle, and the encodings are available from GHC.IO.Encoding. We may want to export these from somewhere more permanent; that's something for a library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance is about 30% slower on "hGetContents >>= putStr" than before. I've profiled it, and about 25% of this is in doing the actual encoding/decoding, the rest is accounted for by the fact that we're shuffling around 32-bit chars rather than bytes in the Handle buffer, so there's not much we can do to improve this. IO library restructuring ~~~~~~~~~~~~~~~~~~~~~~~~ The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) => dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' -> FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. -> IOMode -- ^ The mode in which the 'Handle' is to be used -> Maybe TextEncoding -- ^ text encoding to use, if any -> IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated warnings. I split modules into smaller parts in many places. For example, we now have GHC.IORef, GHC.MVar and GHC.IOArray containing the implementations of IORef, MVar and IOArray respectively. This was necessary for untangling dependencies, but it also makes things easier to follow. The new module structurue for the IO-relatied parts of the base package is: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc. From john at n-brain.net Tue Feb 3 11:49:54 2009 From: john at n-brain.net (John A. De Goes) Date: Tue Feb 3 11:40:04 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: On Feb 3, 2009, at 2:10 AM, Heinrich Apfelmus wrote: > It's just that I don't consider CSS friendly at all, I'd say it's a > 0th > order language. I never said, "CSS", I said "like CSS". > Layout combinators in the spirit of TeX or Lout are more > flexible while being simpler. In any case, a simple primitive > > grid :: [[Rect a]] -> Rect a > > that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 From jgoerzen at complete.org Tue Feb 3 12:03:58 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 11:54:12 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <49887404.4070504@gmail.com> References: <49887404.4070504@gmail.com> Message-ID: <498878FE.2040502@complete.org> Simon Marlow wrote: > I've been working on adding proper Unicode support to Handle I/O in GHC, > and I finally have something that's ready for testing. I've put a patchset > here: Yay! Comments below. > Comments/discussion please! Do you expect Hugs will be able to pick up all of this? > The only change to the existing behaviour is that by default, text IO > is done in the prevailing encoding of the system. Handles created by > openBinaryFile use the Latin-1 encoding, as do Handles placed in > binary mode using hSetBinaryMode. Sounds very good and reasonable. > We provide a way to change the encoding for an existing Handle: > > hSetEncoding :: Handle -> TextEncoding -> IO () > > and various encodings: > > latin1, > utf8, > utf16, utf16le, utf16be, > utf32, utf32le, utf32be, > localeEncoding, Will there also be something to handle the UTF-16 BOM marker? I'm not sure what the best API for that is, since it may or may not be present, but it should be considered -- and could perhaps help autodetect encoding. > Thanks to suggestions from Duncan Coutts, it's possible to call > hSetEncoding even on buffered read Handles, and the right thing > happens. So we can read from text streams that include multiple > encodings, such as an HTTP response or email message, without having > to turn buffering off (though there is a penalty for switching > encodings on a buffered Handle, as the IO system has to do some > re-decoding to figure out where it should start reading from again). Sounds useful, but is this the bit that causes the 30% performance hit? > Performance is about 30% slower on "hGetContents >>= putStr" than > before. I've profiled it, and about 25% of this is in doing the > actual encoding/decoding, the rest is accounted for by the fact that > we're shuffling around 32-bit chars rather than bytes in the Handle > buffer, so there's not much we can do to improve this. Does this mean that if we set the encoding to latin1, tat we should see performance 5% worse than present? 30% slower is a big deal, especially since we're not all that speedy now. > IO library restructuring > ~~~~~~~~~~~~~~~~~~~~~~~~ > > The major change here is that the implementation of the Handle > operations is separated from the underlying IO device, using type > classes. File descriptors are just one IO provider; I have also > implemented memory-mapped files (good for random-access read/write) > and a Handle that pipes output to a Chan (useful for testing code that > writes to a Handle). New kinds of Handle can be implemented outside > the base package, for instance someone could write bytestringToHandle. > A Handle is made using mkFileHandle: Very nice. That means I can eliminate all the HVIO stuff I have in MissingH, which does roughly the same thing. > with making new kinds of Handle. We could split up the layers further > later. Would it now be possible to make the Socket an instance of this typeclass, so we can work with it directly rather than having to convert it to a Handle first? Thanks, -- John From bugfact at gmail.com Tue Feb 3 12:09:26 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Feb 3 11:59:35 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes wrote: > I never said, "CSS", I said "like CSS". > Oh, I missed the "like" word! What do you mean with that? What aspects of CSS do you prefer to? In WPF a "style" is basically just a bunch of attribute key/value pairs. Layout combinators in the spirit of TeX or Lout are more >> flexible while being simpler. In any case, a simple primitive >> >> grid :: [[Rect a]] -> Rect a >> >> that arranges widgets in a rectangular grid should be enough for GUIs. >> > > > Spoken like a true programmer who knows nothing about usability. :-) Yes, layout must be very versatile and user definable. > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/c1193aa3/attachment.htm From conal at conal.net Tue Feb 3 12:27:46 2009 From: conal at conal.net (Conal Elliott) Date: Tue Feb 3 12:17:52 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> <2A620A8F-AB5C-4E36-B038-008870758CCA@n-brain.net> <20090203054725.17d39555@solaris> <20090203081209.37a00941@solaris> Message-ID: Thanks, Bob. On Mon, Feb 2, 2009 at 11:42 PM, Thomas Davie wrote: > > On 3 Feb 2009, at 08:12, Achim Schneider wrote: > > "John A. De Goes" wrote: >> >> >>> Perhaps I should have been more precise: >>> >>> How do you define "layout" and "interaction semantics" in such a way >>> that the former has a *necessarily* direct, enormous impact on the >>> latter? >>> >>> HTML/CSS is a perfect example of how one can decouple a model of >>> content from the presentation of that content. The developer writes >>> the content model and the controller, while UX guys or designers get >>> to decide how it looks. >>> >>> HTML, or rather XML, would be layout to me. GUI's usually don't serve >> static content, and allowing a CSS layer to position eg. a filter GUI >> that supports chaining up any amount of filters by slicing them apart >> and positioning them on top of each other (maybe because someone didn't >> notice that you can use more than one filter) wrecks havoc on both >> usability and the semantics. >> >> "Wrecks havoc on the semantics" in the sense of that if a thing is >> editable, the semantics should guarantee that it is, indeed, editable. >> Likewise, if something is marked as visible (and such things are >> explicit in the model, not defined by an outer layer), the semantics >> should guarantee that it is visible. >> > > > I mostly don't get how a topic discussing how to do GUIs in a beautiful, > consistent, composable, orthogonal, functional way got onto the topic of "oh > hay, you could do it with html and css". Sure, those two may be declarative > languages, but that doesn't make either of them fill the list of features > required above! > > > Bob > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/0edefb97/attachment.htm From marco-oweber at gmx.de Tue Feb 3 12:40:55 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Tue Feb 3 12:31:06 2009 Subject: [Haskell-cafe] hslogger bugs or features - patches In-Reply-To: <498864CE.4090902@complete.org> References: <20090201012818.GA11418@gmx.de> <20090202225607.GB7016@gmx.de> <498864CE.4090902@complete.org> Message-ID: <20090203174055.GB28471@gmx.de> Hi John, Yes, a NotSet corresponds to my new "Nothing" setting. Proably you're right that adding that would have been enogh. API changes: Probably you're talking about the introduction of those classes? The idea was to not have to split that String over and over again. This way I thought you could pass over the logger path (LoggerName ["A","B","C"]) directly.. > Where do I find the benchmark? Look it up in tests/Benchmark.hs and the .cabal file. I've added the benchmark first before having done most updates so that it's easier to compare the results. About the Bytestring thing I won't bother you until I'm sure it's worth it. You're right: in a ready to go application you always keep the default logger. But I want to use hslogger also to verify that my application does what I think it should be doing .. And while learning about hslogger you will do things in different order. Maybe its just that the most important parts about hslogger didn't came through to my mind. Maybe one can shorten that all to this. At least that's how my change are supposed to work: The logging sytem is based on a tree. To each tree node you can attach handlers. When a loogging action is performed the tree is traversed from the logger name up to the root. The first node having attached an logging priority will be used to decide wether the message gets logged at all. If its logged all the handlers having been attached to the visited nodes will be called. Conclusions: having this setup: "A.B.C" log priority EMERGENCY "" log priority DEBUG the handlers atteched to "" won't get debug messages send to the "A.B.C" logger. So there is no way to trace all messages without knowing about all sub logger level settings. Something like this would have been enough give me an idea what the library really does. Anyway the least thing I need is the NOTSET logger level setting. Wether we call it Nothing or NOTSET doesn't matter. Sincerly Marc Weber From apfelmus at quantentunnel.de Tue Feb 3 12:45:47 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Tue Feb 3 12:35:26 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: John A. De Goes wrote: >> Layout combinators in the spirit of TeX or Lout are more >> flexible while being simpler. In any case, a simple primitive >> >> grid :: [[Rect a]] -> Rect a >> >> that arranges widgets in a rectangular grid should be enough for GUIs. > > Spoken like a true programmer who knows nothing about usability. :-) Hehe, well given that CSS doesn't even have such a primitive... :) Regards, apfelmus -- http://apfelmus.nfshost.com From colin at colina.demon.co.uk Tue Feb 3 12:53:01 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Feb 3 12:43:11 2009 Subject: [Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O Message-ID: >>>>> "John" == John Goerzen writes: >> latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, >> localeEncoding, John> Will there also be something to handle the UTF-16 BOM John> marker? I'm not sure what the best API for that is, since John> it may or may not be present, but it should be considered -- John> and could perhaps help autodetect encoding. Not really. The UTF-16 BOM is only allowed for utf16. Utf16le and utf16be do not have a BOM. What it does is alloww you to auto-detect the endianness if utf16 has been requested as the encoding (if it is not present the big-endian is assumed). Ditto for utf32/utf32be/utf32le. A BOM is thesedays allowed (but deprecated - it should never have been allowed and originally wasn't) for utf8 also. But it has no value other than to introduce ambiguity. :-( -- Colin Adams Preston Lancashire From greenrd at greenrd.org Tue Feb 3 12:59:32 2009 From: greenrd at greenrd.org (Robin Green) Date: Tue Feb 3 12:59:12 2009 Subject: [Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: References: Message-ID: <20090203175932.650810f5@greenrd.org> Colin, I really don't see the point of putting your own name at the front of the subject line. It is redundant because it's already in the email headers. Perhaps this was a technical glitch? -- Robin From colin at colina.demon.co.uk Tue Feb 3 14:02:48 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Tue Feb 3 13:53:04 2009 Subject: [Colin Paul Adams] Re: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <20090203175932.650810f5@greenrd.org> (Robin Green's message of "Tue\, 3 Feb 2009 17\:59\:32 +0000") References: <20090203175932.650810f5@greenrd.org> Message-ID: >>>>> "Robin" == Robin Green writes: Robin> Colin, I really don't see the point of putting your own Robin> name at the front of the subject line. It is redundant Robin> because it's already in the email headers. Perhaps this was Robin> a technical glitch? I guess so - certainly I didn't type it. -- Colin Adams Preston Lancashire From conal at conal.net Tue Feb 3 14:39:10 2009 From: conal at conal.net (Conal Elliott) Date: Tue Feb 3 14:29:22 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS Message-ID: [Spin-off from the haskell-cafe discussion on functional/denotational GUI toolkits] I've been wondering for a while now what a well-designed alternative to CSS could be, where well-designed would mean consistent, composable, orthogonal, functional, based on an elegantly compelling semantic model (denotational). - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/d31b02e2/attachment.htm From jefferson.r.heard at gmail.com Tue Feb 3 14:50:44 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Tue Feb 3 14:40:51 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: References: Message-ID: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> Similarly, I've been wondering what's at the core of a GUI? It seems in recent years that more people have been moving towards web-based applications, and away from traditional GUIs, so the meaning of them may be changing. The old question seemed to be Page vs. Control-Board, but that seems like implementation, when the real essence of a GUI is taking in common kinds of user input and displaying output in a sensible way. Similarly, there are more ways to interact with a computer than ever before, from simple keyboard up through multitouch interfaces like the iPhone. It would be cool to me to see a semantic model that captures this. 2009/2/3 Conal Elliott : > [Spin-off from the haskell-cafe discussion on functional/denotational GUI > toolkits] > > I've been wondering for a while now what a well-designed alternative to CSS > could be, where well-designed would mean consistent, composable, orthogonal, > functional, based on an elegantly compelling semantic model (denotational). > > - Conal > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From john at n-brain.net Tue Feb 3 15:18:23 2009 From: john at n-brain.net (John A. De Goes) Date: Tue Feb 3 15:08:36 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: Nor does it need one: http://www.csszengarden.com/ Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 3, 2009, at 10:45 AM, Heinrich Apfelmus wrote: > John A. De Goes wrote: >>> Layout combinators in the spirit of TeX or Lout are more >>> flexible while being simpler. In any case, a simple primitive >>> >>> grid :: [[Rect a]] -> Rect a >>> >>> that arranges widgets in a rectangular grid should be enough for >>> GUIs. >> >> Spoken like a true programmer who knows nothing about usability. :-) > > Hehe, well given that CSS doesn't even have such a primitive... :) > > Regards, > apfelmus > > -- > http://apfelmus.nfshost.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From john at n-brain.net Tue Feb 3 15:19:03 2009 From: john at n-brain.net (John A. De Goes) Date: Tue Feb 3 15:09:11 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense Message-ID: <64AEC3F4-E553-453B-A826-F826F1BCFD50@n-brain.net> CSS is purely declarative in nature and entirely deterministic. Moreover, it's expressive power is such that you can completely and radically alter the look of a website with modifications to CSS alone (see Zen Garden). The grammar and semantics are relatively simple and can be interpreted and generated by tools, which means that a designer can work with CSS files without knowing anything about CSS. Is it perfect? No. But it's a lot better than trying to encode everything in a single language that only a software developer can safely work with. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 3, 2009, at 10:09 AM, Peter Verswyvelen wrote: > On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes > wrote: > I never said, "CSS", I said "like CSS". > > Oh, I missed the "like" word! What do you mean with that? What > aspects of CSS do you prefer to? In WPF a "style" is basically just > a bunch of attribute key/value pairs. > > > Layout combinators in the spirit of TeX or Lout are more > flexible while being simpler. In any case, a simple primitive > > grid :: [[Rect a]] -> Rect a > > that arranges widgets in a rectangular grid should be enough for GUIs. > > > Spoken like a true programmer who knows nothing about usability. :-) > > Yes, layout must be very versatile and user definable. > > > > Regards, > > John A. De Goes > N-BRAIN, Inc. > The Evolution of Collaboration > > http://www.n-brain.net | 877-376-2724 x 101 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/c9abe590/attachment.htm From bugfact at gmail.com Tue Feb 3 15:23:53 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Feb 3 15:14:01 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> References: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> Message-ID: Isn't CSS about giving a "style" to the "views" in the model-view-controller paradigm? So basically it is a way to change the look of a user interface, without having to change the user interface definition itself. But isn't this just an environment monad that has functions to convert a model into a view (= geometry = render function + picking function)? Plugin a different environment and voila, the widgets are painted and maybe even layed differently, but you don't have to change any code or data.... Of course what a "model" really is, is not fully clear: http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx On Tue, Feb 3, 2009 at 8:50 PM, Jeff Heard wrote: > Similarly, I've been wondering what's at the core of a GUI? It seems > in recent years that more people have been moving towards web-based > applications, and away from traditional GUIs, so the meaning of them > may be changing. The old question seemed to be Page vs. > Control-Board, but that seems like implementation, when the real > essence of a GUI is taking in common kinds of user input and > displaying output in a sensible way. Similarly, there are more ways > to interact with a computer than ever before, from simple keyboard up > through multitouch interfaces like the iPhone. It would be cool to me > to see a semantic model that captures this. > > 2009/2/3 Conal Elliott : > > [Spin-off from the haskell-cafe discussion on functional/denotational GUI > > toolkits] > > > > I've been wondering for a while now what a well-designed alternative to > CSS > > could be, where well-designed would mean consistent, composable, > orthogonal, > > functional, based on an elegantly compelling semantic model > (denotational). > > > > - Conal > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/1c698704/attachment.htm From jonathanccast at fastmail.fm Tue Feb 3 15:26:14 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Tue Feb 3 15:18:28 2009 Subject: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense In-Reply-To: References: <20090127000544.3182da13@solaris> <814617240902021139p7d9c722fl331c7cd193f3512d@mail.gmail.com> <710B10FE-3806-42BA-A6F5-926C12B8CBA0@n-brain.net> <8C2AF1CC-6B35-4539-977C-FEFCDD0057F9@n-brain.net> Message-ID: <1233692774.11492.5.camel@jcchost> On Tue, 2009-02-03 at 13:18 -0700, John A. De Goes wrote: > Nor does it need one: http://www.csszengarden.com/ Can I write one if I really, really want to? I don't think excluding programmers from control over layout is much better than excluding non-programmers, really. jcc From jgoerzen at complete.org Tue Feb 3 15:55:15 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 15:45:26 2009 Subject: [Haskell-cafe] hslogger bugs or features - patches In-Reply-To: <20090203174055.GB28471@gmx.de> References: <20090201012818.GA11418@gmx.de> <20090202225607.GB7016@gmx.de> <498864CE.4090902@complete.org> <20090203174055.GB28471@gmx.de> Message-ID: <4988AF33.3010207@complete.org> Hi Marc, I have pushed to my hslogger repo the optional priority for a logger support that we talked about, which is the Haskell version of Python's NOTSET. It is currently untested and represents only a minor API change. Please take a look and let me know your thoughts. It adds one new function to the API (clearLevel) and changes the return type of getLevel. Other than that, the changes are pretty much hidden from the public interface. I looked at your git repo, but I'm not going to pull anything from it right this minute. I would consider your performance change, but it was wrapped up with half a dozen other things in a single commit so I couldn't extract just it. If you would split up your changes into small bite-sized diffs, where each one makes exactly one change and is documented, I would be happy to take another look. As it is, each patch is touching too many unrelated areas for me to really bring them in. (I don't want API changes just for a performance improvement.) hslogger is used by a bunch of code all over the place, so I want to be very careful about what I do to it to avoid causing a lot of hassle for a lot of people. -- John From patai_gergely at fastmail.fm Tue Feb 3 15:59:52 2009 From: patai_gergely at fastmail.fm (Patai Gergely) Date: Tue Feb 3 15:50:01 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS Message-ID: <1233694792.14180.1298346729@webmail.messagingengine.com> > I've been wondering for a while now what a well-designed alternative > to CSS could be, where well-designed would mean consistent, composable, > orthogonal, functional, based on an elegantly compelling semantic model > (denotational). Well, if you think about CSS as in webpage styling, it's simply a way to override some attributes in the DOM tree. If you will, you can easily relate CSS selectors to your semantic editor combinators, since a concrete stylesheet makes explicit references to the structure of the document/interface it is associated with. One important difference is that in the case of CSS you don't need to mention all the intermediate nodes explicitly, which can make selectors shorter as well as "non-deterministic", i.e. they can match different structural patterns at the same time. Also, you can perform a kind of pattern matching (filtering by class/id names) besides just blindly walking down the tree along the type structure. I'd say these two features make it a direct generalisation of the SEC concept. Gergely -- http://www.fastmail.fm - The way an email service should be From jgoerzen at complete.org Tue Feb 3 16:04:04 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 15:54:15 2009 Subject: [Haskell-cafe] hslogger bugs or features - patches In-Reply-To: <4988AF33.3010207@complete.org> References: <20090201012818.GA11418@gmx.de> <20090202225607.GB7016@gmx.de> <498864CE.4090902@complete.org> <20090203174055.GB28471@gmx.de> <4988AF33.3010207@complete.org> Message-ID: <20090203210404.GA29567@hustlerturf.com> On Tue, Feb 03, 2009 at 02:55:15PM -0600, John Goerzen wrote: > I looked at your git repo, but I'm not going to pull anything from it > right this minute. I would consider your performance change, but it was > wrapped up with half a dozen other things in a single commit so I > couldn't extract just it. Also, there is *no way* I will apply any patch that removes my copyright notices, as your git branch does. -- John From tom.davie at gmail.com Tue Feb 3 16:06:05 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Feb 3 15:56:24 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: References: Message-ID: On 3 Feb 2009, at 20:39, Conal Elliott wrote: > [Spin-off from the haskell-cafe discussion on functional/ > denotational GUI toolkits] > > I've been wondering for a while now what a well-designed alternative > to CSS could be, where well-designed would mean consistent, > composable, orthogonal, functional, based on an elegantly compelling > semantic model (denotational). Can I start by replacing html please :) I'd like to separate the document in roughly the same way as html and css attempt to, meaning I'd like a document description language, and a styling description language. I can imagine the styling language having the meaning "function from documents onto geometry", but the document description language is harder. Ideally what I'd like to do with it is to make it describe *only* the logical structure of the information being conveyed ? sections, text, figures, tables (no, not for layout, for tabular data) etc. I can't though come up with a nice simple solution to that that (a) restricts users to really describing documents, not layout (b) still allows for composability in any sensible kind of way. Bob From alistair at abayley.org Tue Feb 3 16:08:38 2009 From: alistair at abayley.org (Alistair Bayley) Date: Tue Feb 3 15:58:50 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: References: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> Message-ID: <79d7c4980902031308r77be8e7erd037084a8ef07a52@mail.gmail.com> 2009/2/3 Peter Verswyvelen : > Isn't CSS about giving a "style" to the "views" in the model-view-controller > paradigm? So basically it is a way to change the look of a user interface, > without having to change the user interface definition itself. In theory CSS separates content from presentation. In reality it looks like it isn't really powerful enough. Serendipitously, this rant popped up on reddit recently: http://www.flownet.com/ron/css-rant.html Summary: CSS's failures mean that the rendering of a page depends on the order of elements in the content. We have CleverCSS: a little less ambitious than Conal and Jeff imagined, I think, but still an improvement over raw CSS: http://sandbox.pocoo.org/clevercss-hs/ Alistair From wren at freegeek.org Tue Feb 3 16:12:52 2009 From: wren at freegeek.org (wren ng thornton) Date: Tue Feb 3 16:03:06 2009 Subject: [Haskell-cafe] Bytestrings vs String? parameters within package names? In-Reply-To: <20090203095019.GB10222@gmx.de> References: <20090202224540.GB24610@gmx.de> <4987BD05.4020307@freegeek.org> <20090203095019.GB10222@gmx.de> Message-ID: <4988B354.6070507@freegeek.org> Marc Weber wrote: > wren ng thornton wrote: > > I'd just stick with one (with a module for hiding the conversions, as > > desired). Duplicating the code introduces too much room for maintenance and > > compatibility issues. > > > > That's the big thing. The more people that use ByteStrings the less need > > there is to convert when combining libraries. That said, ByteStrings aren't > > a panacea; lists and laziness are very useful. > > Hi wren, > > In the second paragraph you agree that there will be less onversion when > using only one type of strings. > > You're also right about encoding. > About laziness you'r partially right: There is also Bytestring.Lazy > which is a basically a list of (non lazy) Bytestring Sure, but lazy bytestrings are still chunk-wise strict. Sometimes even that isn't lazy enough (more often with non-string kinds of lists, granted). -- Live well, ~wren From lrpalmer at gmail.com Tue Feb 3 16:25:52 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Tue Feb 3 16:16:08 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: References: Message-ID: <7ca3f0160902031325p310ce5acub58fd7538a747c34@mail.gmail.com> On Tue, Feb 3, 2009 at 2:06 PM, Thomas Davie wrote: > > On 3 Feb 2009, at 20:39, Conal Elliott wrote: > > [Spin-off from the haskell-cafe discussion on functional/denotational GUI >> toolkits] >> >> I've been wondering for a while now what a well-designed alternative to >> CSS could be, where well-designed would mean consistent, composable, >> orthogonal, functional, based on an elegantly compelling semantic model >> (denotational). >> > > Can I start by replacing html please :) > > I'd like to separate the document in roughly the same way as html and css > attempt to, meaning I'd like a document description language, and a styling > description language. > > I can imagine the styling language having the meaning "function from > documents onto geometry", but the document description language is harder. > Ideally what I'd like to do with it is to make it describe *only* the > logical structure of the information being conveyed ? sections, text, > figures, tables (no, not for layout, for tabular data) etc. This is easy to me. Everything is content. Sections, text, figures, tables -- these are all static content. Functions are interactive content. Numbers are content, as are lists of content, maybe content ... The interesting part is how you display it. In the simplest sense, a "style" is just a function Style a = a -> Geometry. But work has been done, eg. with TVs, that have composition of content and composition of the display mirror each other. I'm not totally satisfied with TVs. For example, I think it's worth exploration describing *how* the content was composed, such that styling language maps compositions of content to compositions of geometry. Content is not interesting. The *mapping* from content to presentation is the important part. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/e4305938/attachment.htm From wren at freegeek.org Tue Feb 3 16:33:38 2009 From: wren at freegeek.org (wren ng thornton) Date: Tue Feb 3 16:23:46 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: References: Message-ID: <4988B832.9090409@freegeek.org> Thomas Davie wrote: > I can imagine the styling language having the meaning "function from > documents onto geometry", but the document description language is > harder. Ideally what I'd like to do with it is to make it describe > *only* the logical structure of the information being conveyed ? > sections, text, figures, tables (no, not for layout, for tabular data) > etc. I can't though come up with a nice simple solution to that that > (a) restricts users to really describing documents, not layout (b) still > allows for composability in any sensible kind of way. I can see LaTeX as demonstrating that there is no such (single) language. It seems to me that the elementary units (chapters, sections, paragraphs,...) depend almost entirely on the domain of the document (a book, an article,...). In a similar way, many of the most painful examples of HTML come from people bludgeoning the elementary units into misservice. XML escapes from this by only providing a syntax/ontology rather than a language per se. So it seems to me that a general document framework should be an ontology of what primitives could exist, rather than a set of actual primitives. Of course, an ontological framework is no good without some collection of example languages it describes. One of the big tricks here is not in what languages look like in isolation, but in how languages can be combined or extended. -- Live well, ~wren From RafaelGCPP.Linux at gmail.com Tue Feb 3 16:37:54 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Tue Feb 3 16:28:01 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition Message-ID: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Hello folks After a discussion on whether is possible to compile hmatrix in Windows, I decided to go crazy and do a LU decomposition entirely in Haskell... At first I thought it would be necessary to use a mutable or monadic version of Array, but then I figured out it is a purely interactive process. I am releasing this code fragment as LGPL. {- This program is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . -} import Data.Array.IArray type Dim=(Int,Int) lu::Array Dim Double -> (Array Dim Double,Array Dim Double) lu a = (aa l,aa u) where (l,u)=lu' a [] [] aa = accumArray (+) 0 (bounds a) lu'::(Floating e) => Array Dim e -> [(Dim,e)] -> [(Dim,e)] -> ([(Dim,e)],[(Dim,e)]) lu' a l u=if (ui==li) then ( ((ui,uj),1.0):l,((ui,uj),a!(ui,uj)):u) else (lu' an (l++ln) (u++un)) where k=li ((li,lj),(ui,uj))=bounds a lik i=(a!(i,k)/a!(k,k)) un=[((k,j),a!(k,j)) | j<-[lj..uj]] ln=((lj,lj),1.0):[((i,k),lik i) | i<-[li+1..ui]] an=array ((li+1,lj+1),(ui,uj)) [((i,j),e_an i j) | i<-[li+1..ui],j<-[lj+1..uj]] e_an i j=a!(i,j)-(lik i)*a!(k,j) Still needed: 1) Partial pivoting 2) Profiling... Lots! 3) Parallelize -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/54e6c578/attachment.htm From jake at pikewerks.com Tue Feb 3 16:42:24 2009 From: jake at pikewerks.com (Jake McArthur) Date: Tue Feb 3 16:32:32 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: <1233694792.14180.1298346729@webmail.messagingengine.com> References: <1233694792.14180.1298346729@webmail.messagingengine.com> Message-ID: <4988BA40.5060401@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patai Gergely wrote: | Well, if you think about CSS as in webpage styling, it's simply a way to | override some attributes in the DOM tree. If you will, you can easily | relate CSS selectors to your semantic editor combinators, since a | concrete stylesheet makes explicit references to the structure of the | document/interface it is associated with. One important difference is | that in the case of CSS you don't need to mention all the intermediate | nodes explicitly, which can make selectors shorter as well as | "non-deterministic", i.e. they can match different structural patterns | at the same time. Also, you can perform a kind of pattern matching | (filtering by class/id names) besides just blindly walking down the tree | along the type structure. I'd say these two features make it a direct | generalisation of the SEC concept. This reminds me of Scrap Your Boilerplate. Perhaps looking at SYB would be a reasonable start to generalizing SECs in this context? - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmIukAACgkQye5hVyvIUKkkrwCfaDJxjumLR92aIiGIvXtXH20G XiwAniEslqswXJYdeRW2hx2a6rdf3cdj =y/g1 -----END PGP SIGNATURE----- From malcolm.wallace at cs.york.ac.uk Tue Feb 3 16:48:21 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Feb 3 16:38:28 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> References: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> Message-ID: <65B0DCE7-2D1E-45F5-AD2C-47D5F1E7FE50@cs.york.ac.uk> Jeff Heard wrote: > Similarly, I've been wondering what's at the core of a GUI? It seems > in recent years that more people have been moving towards web-based > applications, and away from traditional GUIs, so the meaning of them > may be changing. The old question seemed to be Page vs. > Control-Board, but that seems like implementation, when the real > essence of a GUI is taking in common kinds of user input and > displaying output in a sensible way. I would go with Bret Victor's argument (http://worrydream.com/ MagicInk/) that the concept of user interface as primarily _interaction_ is misguided. What GUIs are really about is visual _presentation_ of information. The semantic questions are about what it means graphically to compose information sources. We spend more time reading, viewing, and absorbing that information, than rearranging it, or adding to it. Interaction changes the sources, or the way they compose, but is (or should be) fundamentally an infrequent activity. The better the visual presentation, the less you need to interact with it. Regards, Malcolm From jefferson.r.heard at gmail.com Tue Feb 3 16:53:48 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Tue Feb 3 16:43:57 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: <65B0DCE7-2D1E-45F5-AD2C-47D5F1E7FE50@cs.york.ac.uk> References: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> <65B0DCE7-2D1E-45F5-AD2C-47D5F1E7FE50@cs.york.ac.uk> Message-ID: <4165d3a70902031353l1de1ba71i2d77361ce1f41a8f@mail.gmail.com> Bret's argument, though, only applies to Information Software. Which... hey, if you want to go with describing fundamentally different approaches to GUIs based on the classifications he uses in his arguments, I think that's a better place to start than trying to figure out how to make a new denotationally-semantic GUI toolkit that works for everyone everywhere. On Tue, Feb 3, 2009 at 4:48 PM, Malcolm Wallace wrote: > Jeff Heard wrote: > >> Similarly, I've been wondering what's at the core of a GUI? It seems >> in recent years that more people have been moving towards web-based >> applications, and away from traditional GUIs, so the meaning of them >> may be changing. The old question seemed to be Page vs. >> Control-Board, but that seems like implementation, when the real >> essence of a GUI is taking in common kinds of user input and >> displaying output in a sensible way. > > I would go with Bret Victor's argument (http://worrydream.com/MagicInk/) > that the concept of user interface as primarily _interaction_ is misguided. > What GUIs are really about is visual _presentation_ of information. The > semantic questions are about what it means graphically to compose > information sources. We spend more time reading, viewing, and absorbing > that information, than rearranging it, or adding to it. > > Interaction changes the sources, or the way they compose, but is (or should > be) fundamentally an infrequent activity. The better the visual > presentation, the less you need to interact with it. > > Regards, > Malcolm > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From rodrigo.bonifacio at uol.com.br Tue Feb 3 16:58:51 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Tue Feb 3 16:49:00 2009 Subject: [Haskell-cafe] Converting Lists to Sets Message-ID: <4988be1b95af9_7919155555587eb423b@weasel6.tmail> Hi all, I'm trying to use the Funsat library. One of its data types is CNF: data CNF = CNF { numVars :: Int numClauses :: Int clauses :: Set Clause } I have a list of clauses, but I'm getting an error when converting such a list to a Set. Using the fromList function, the ghc compiler reports that the fromList function is not applicable to literals. type Clause = [Lit] newtype Lit = L { unLit :: Int } So, my question is: How can I solve this problem? Thanks in advance, Rodrigo. From barsoap at web.de Tue Feb 3 17:06:55 2009 From: barsoap at web.de (Achim Schneider) Date: Tue Feb 3 16:57:13 2009 Subject: [Haskell-cafe] Re: Elegant & powerful replacement for CSS References: <4988B832.9090409@freegeek.org> Message-ID: <20090203230655.4750f0fa@solaris> wren ng thornton wrote: > I can see LaTeX as demonstrating that there is no such (single) > language. It seems to me that the elementary units (chapters, > sections, paragraphs,...) depend almost entirely on the domain of the > document (a book, an article,...). > This is what I had in mind while I tried to write the plumbing to agar objects: Defining your own widgets. A library to do this, it seems would consist of things like ActionProducers instead of Buttons, and TextInput instead of TextBoxen and ListBoxen... that is, of Event ()'s and Behaviour/Event String's, alongside with high-level renderers, coupled with a feedback mechanism, that'll then be called Button and TextBox. A Listbox is already made out of such primitives, but this should be transparent to the developer. Another most important thing that I really want to have, is to enable the end-user to edit presentation, in a sensible way, like re-specifying the width of textboxen, add additional hiding panes etc. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Tue Feb 3 17:14:29 2009 From: barsoap at web.de (Achim Schneider) Date: Tue Feb 3 17:04:51 2009 Subject: [Haskell-cafe] Re: Elegant & powerful replacement for CSS References: <4165d3a70902031150x438afb52tc6039a3854f6115e@mail.gmail.com> <65B0DCE7-2D1E-45F5-AD2C-47D5F1E7FE50@cs.york.ac.uk> Message-ID: <20090203231429.63e70ef5@solaris> Malcolm Wallace wrote: > I would go with Bret Victor's argument (http://worrydream.com/ > MagicInk/) that the concept of user interface as primarily > _interaction_ is misguided. > I tend to disagree. But then I'm a game developer, not an HTML monk... what definitely makes sense, though, is to divide the gui visually along presentation of the world vs. presentation of your interface to the world. "presentation of your interface to the world" subsumes such things as the marker on the minimap that shows which part you are looking at, and what tool you selected to interact with it (say zoom, smudge, paintbrush) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From greenrd at greenrd.org Tue Feb 3 17:24:13 2009 From: greenrd at greenrd.org (Robin Green) Date: Tue Feb 3 17:23:56 2009 Subject: [Haskell-cafe] Converting Lists to Sets In-Reply-To: <4988be1b95af9_7919155555587eb423b@weasel6.tmail> References: <4988be1b95af9_7919155555587eb423b@weasel6.tmail> Message-ID: <20090203222413.19e79498@greenrd.org> On Tue, 3 Feb 2009 19:58:51 -0200 "rodrigo.bonifacio" wrote: > Hi all, > > I'm trying to use the Funsat library. One of its data types is CNF: > > data CNF = CNF { > numVars :: Int > numClauses :: Int > clauses :: Set Clause > } > > I have a list of clauses, but I'm getting an error when converting > such a list to a Set. Using the fromList function, the ghc compiler > reports that the fromList function is not applicable to literals. > > type Clause = [Lit] > > newtype Lit = L { > unLit :: Int > } > You don't provide your code or the exact error message, which makes it harder to diagnose - but I'd guess you are mistakenly trying to apply fromList to a *single* literal, rather than a *list* of literals. -- Robin From duncan.coutts at worc.ox.ac.uk Tue Feb 3 17:56:13 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 3 17:46:10 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <498878FE.2040502@complete.org> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> Message-ID: <1233701773.26754.590.camel@localhost> On Tue, 2009-02-03 at 11:03 -0600, John Goerzen wrote: > Will there also be something to handle the UTF-16 BOM marker? I'm not > sure what the best API for that is, since it may or may not be present, > but it should be considered -- and could perhaps help autodetect encoding. I think someone else mentioned this already, but utf16 (as opposed to utf16be/le) will use the BOM if its present. I'm not quite sure what happens when you switch encoding, presumably it'll accept and consider a BOM at that point. > > Thanks to suggestions from Duncan Coutts, it's possible to call > > hSetEncoding even on buffered read Handles, and the right thing > > happens. So we can read from text streams that include multiple > > encodings, such as an HTTP response or email message, without having > > to turn buffering off (though there is a penalty for switching > > encodings on a buffered Handle, as the IO system has to do some > > re-decoding to figure out where it should start reading from again). > > Sounds useful, but is this the bit that causes the 30% performance hit? No. You only pay that penalty if you switch encoding. The standard case has no extra cost. > > Performance is about 30% slower on "hGetContents >>= putStr" than > > before. I've profiled it, and about 25% of this is in doing the > > actual encoding/decoding, the rest is accounted for by the fact that > > we're shuffling around 32-bit chars rather than bytes in the Handle > > buffer, so there's not much we can do to improve this. > > Does this mean that if we set the encoding to latin1, tat we should see > performance 5% worse than present? No, I think that's 30% for latin1. The cost is not really the character conversion but the copying from a byte buffer via iconv to a char buffer. > 30% slower is a big deal, especially since we're not all that speedy now. Bear in mind that's talking about the [Char] interface, and nobody using that is expecting great performance. We already have an API for getting big chunks of bytes out of a Handle, with the new Handle we'll also want something equivalent for a packed text representation. Hopefully we can get something nice with the new text package. Duncan From wagner.andrew at gmail.com Tue Feb 3 18:02:10 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Tue Feb 3 17:52:16 2009 Subject: [Haskell-cafe] Converting Lists to Sets In-Reply-To: <20090203222413.19e79498@greenrd.org> References: <4988be1b95af9_7919155555587eb423b@weasel6.tmail> <20090203222413.19e79498@greenrd.org> Message-ID: Actually, a list of list of literals is needed, since it's a Set Clause, and a Clause is a [Literal]. On Tue, Feb 3, 2009 at 5:24 PM, Robin Green wrote: > On Tue, 3 Feb 2009 19:58:51 -0200 > "rodrigo.bonifacio" wrote: > > > Hi all, > > > > I'm trying to use the Funsat library. One of its data types is CNF: > > > > data CNF = CNF { > > numVars :: Int > > numClauses :: Int > > clauses :: Set Clause > > } > > > > I have a list of clauses, but I'm getting an error when converting > > such a list to a Set. Using the fromList function, the ghc compiler > > reports that the fromList function is not applicable to literals. > > > > type Clause = [Lit] > > > > newtype Lit = L { > > unLit :: Int > > } > > > > You don't provide your code or the exact error message, which makes > it harder to diagnose - but I'd guess you are mistakenly trying to apply > fromList to a *single* literal, rather than a *list* of literals. > -- > Robin > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/ab6b750c/attachment.htm From jgoerzen at complete.org Tue Feb 3 18:39:43 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 18:29:56 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <1233701773.26754.590.camel@localhost> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> Message-ID: <20090203233943.GA10645@complete.org> On Tue, Feb 03, 2009 at 10:56:13PM +0000, Duncan Coutts wrote: > > > Thanks to suggestions from Duncan Coutts, it's possible to call > > > hSetEncoding even on buffered read Handles, and the right thing > > > happens. So we can read from text streams that include multiple > > > encodings, such as an HTTP response or email message, without having > > > to turn buffering off (though there is a penalty for switching > > > encodings on a buffered Handle, as the IO system has to do some > > > re-decoding to figure out where it should start reading from again). > > > > Sounds useful, but is this the bit that causes the 30% performance hit? > > No. You only pay that penalty if you switch encoding. The standard case > has no extra cost. I'm confused. I thought the standard case was conversion to the system's local encoding? How is that different than selecting the same encoding manually? There always has to be *some* conversion from a 32-bit Char to the system's selection, right? What exactly do we have to do to avoid the penalty? > No, I think that's 30% for latin1. The cost is not really the character > conversion but the copying from a byte buffer via iconv to a char > buffer. Don't we already have to copy between a byte buffer and a char buffer, since read() and write() use a byte buffer? > > 30% slower is a big deal, especially since we're not all that speedy now. > > Bear in mind that's talking about the [Char] interface, and nobody using > that is expecting great performance. We already have an API for getting Yes, I know, but it's still the most convenient interface, and making it suck more isn't cool -- though there are certainly big wins here. -- John From flippa at flippac.org Tue Feb 3 19:15:48 2009 From: flippa at flippac.org (Philippa Cowderoy) Date: Tue Feb 3 19:06:02 2009 Subject: [Haskell-cafe] ANN: #haskell-in-depth IRC channel Message-ID: <1233706548.14308.125.camel@flippa-eee> Hi folks. As I've been daft enough to get a few things rolling, it looks like it's fallen on me to announce the new IRC channel, #haskell-in-depth. #haskell has been a roaring success over the last few years, as Don has repeatedly pointed out. Unfortunately that roar is starting to make it hard for some to participate - there's so much traffic that it can be difficult to fit an additional conversation in. We're starting to hit the limits as to how far one channel can take us, and that means we need to explore ways to divide up traffic. Actually, this isn't entirely new - a number of years ago now, #haskell-blah was formed as a space for off-topic (and sometimes less-than-worksafe) conversation among #haskell regulars. We also created #haskell-overflow, but it doesn't see much use except among some of the cabal implementors because it's hard to know when to take the conversation you're currently in to -overflow. We need channels that people start their conversations in, not ones to send people to! So we're trying a space for in-depth discussion. The new channel is open to everyone, just like #haskell. But just as we're hoping for certain kinds of discussion, there're others we want to avoid. If you need to know how to use monads so you can do IO, #haskell-in-depth isn't the place. On the other hand, if you want to discuss how Haskell's monads compare to the category theory or what the category theory can tell us about how individual monads relate to the language as a whole, -in-depth is a good place! In particular, we're hoping that the kind of category theory discussions that give the mistaken impression you actually need to know CT will increasingly live in #haskell-in-depth. We're not after a theory channel though - architectural discussion, compiler implementation, possible type system extensions, library design, all are good subjects. Anyway, I shouldn't ramble on for too long here - #haskell-in-depth is open for business and we look forward to seeing you there! -- Philippa Cowderoy From wagner.andrew at gmail.com Tue Feb 3 19:18:45 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Tue Feb 3 19:08:53 2009 Subject: [Haskell-cafe] ANN: #haskell-in-depth IRC channel In-Reply-To: <1233706548.14308.125.camel@flippa-eee> References: <1233706548.14308.125.camel@flippa-eee> Message-ID: Well-done! I've said for many months that we need a channel like this! On Tue, Feb 3, 2009 at 7:15 PM, Philippa Cowderoy wrote: > Hi folks. As I've been daft enough to get a few things rolling, it looks > like it's fallen on me to announce the new IRC channel, > #haskell-in-depth. > > #haskell has been a roaring success over the last few years, as Don has > repeatedly pointed out. Unfortunately that roar is starting to make it > hard for some to participate - there's so much traffic that it can be > difficult to fit an additional conversation in. We're starting to hit > the limits as to how far one channel can take us, and that means we need > to explore ways to divide up traffic. > > Actually, this isn't entirely new - a number of years ago now, > #haskell-blah was formed as a space for off-topic (and sometimes > less-than-worksafe) conversation among #haskell regulars. We also > created #haskell-overflow, but it doesn't see much use except among some > of the cabal implementors because it's hard to know when to take the > conversation you're currently in to -overflow. > > We need channels that people start their conversations in, not ones to > send people to! So we're trying a space for in-depth discussion. The new > channel is open to everyone, just like #haskell. But just as we're > hoping for certain kinds of discussion, there're others we want to > avoid. If you need to know how to use monads so you can do IO, > #haskell-in-depth isn't the place. On the other hand, if you want to > discuss how Haskell's monads compare to the category theory or what the > category theory can tell us about how individual monads relate to the > language as a whole, -in-depth is a good place! In particular, we're > hoping that the kind of category theory discussions that give the > mistaken impression you actually need to know CT will increasingly live > in #haskell-in-depth. > > We're not after a theory channel though - architectural discussion, > compiler implementation, possible type system extensions, library > design, all are good subjects. > > Anyway, I shouldn't ramble on for too long here - #haskell-in-depth is > open for business and we look forward to seeing you there! > > -- > Philippa Cowderoy > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/1aecc094/attachment.htm From barsoap at web.de Tue Feb 3 19:50:38 2009 From: barsoap at web.de (Achim Schneider) Date: Tue Feb 3 19:40:54 2009 Subject: [Haskell-cafe] Re: Elegant & powerful replacement for CSS References: Message-ID: <20090204015038.0e4accaa@solaris> Conal Elliott wrote: > [Spin-off from the haskell-cafe discussion on functional/denotational > GUI toolkits] > > I've been wondering for a while now what a well-designed alternative > to CSS could be, where well-designed would mean consistent, > composable, orthogonal, functional, based on an elegantly compelling > semantic model (denotational). > I think a very important thing to keep in mind while investigating web-technologies for pointers is that Haskell already comes with XML and XSLT (in the disguise of ADT's and functions), and that CSS is often abused for operations that are in the domain of XSLT. I don't believe that it's possible to draw a clear destinction between "concerns the programmer" and "concerns the designer". In fact, I get offended by the notion that I'm inherently incapable of distinguishing readable from unreadable text, and think that the notion of designers being unable to do anything but assembling a colourful collage of the data they're given is more of a self-fulfilling prophecy than a truth. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From conal at conal.net Tue Feb 3 20:00:54 2009 From: conal at conal.net (Conal Elliott) Date: Tue Feb 3 19:51:07 2009 Subject: [Haskell-cafe] Re: Elegant & powerful replacement for CSS In-Reply-To: <20090204015038.0e4accaa@solaris> References: <20090204015038.0e4accaa@solaris> Message-ID: amen & amen! thanks, achim. On Tue, Feb 3, 2009 at 4:50 PM, Achim Schneider wrote: > Conal Elliott wrote: > > > [Spin-off from the haskell-cafe discussion on functional/denotational > > GUI toolkits] > > > > I've been wondering for a while now what a well-designed alternative > > to CSS could be, where well-designed would mean consistent, > > composable, orthogonal, functional, based on an elegantly compelling > > semantic model (denotational). > > > I think a very important thing to keep in mind while investigating > web-technologies for pointers is that Haskell already comes with XML > and XSLT (in the disguise of ADT's and functions), and that CSS is > often abused for operations that are in the domain of XSLT. > > I don't believe that it's possible to draw a clear destinction between > "concerns the programmer" and "concerns the designer". In fact, I get > offended by the notion that I'm inherently incapable of distinguishing > readable from unreadable text, and think that the notion of designers > being unable to do anything but assembling a colourful collage of the > data they're given is more of a self-fulfilling prophecy than a truth. > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090203/f4596a95/attachment.htm From tanimoto at arizona.edu Tue Feb 3 20:26:58 2009 From: tanimoto at arizona.edu (Paulo Tanimoto) Date: Tue Feb 3 20:17:05 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Message-ID: Hi Rafael, 2009/2/3 Rafael Gustavo da Cunha Pereira Pinto : > > Hello folks > > > After a discussion on whether is possible to compile hmatrix in > Windows, I decided to go crazy and do a LU decomposition entirely in > Haskell... > > At first I thought it would be necessary to use a mutable or > monadic version of Array, but then I figured out it is a purely interactive > process. > > I am releasing this code fragment as LGPL. > Pretty cool, thanks for releasing this into the wild. I remember looking into this about a year ago. By the way, have you seen Matt's DSP library? http://haskelldsp.sourceforge.net/ He's got LU and others in there, if my memory serves me. The last release seems to be 2003, so it might be worth emailing him to see what happened and if he has plans for the future. Regards, Paulo From duncan.coutts at worc.ox.ac.uk Tue Feb 3 20:32:59 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 3 20:22:50 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <20090203233943.GA10645@complete.org> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> <20090203233943.GA10645@complete.org> Message-ID: <1233711179.26754.616.camel@localhost> On Tue, 2009-02-03 at 17:39 -0600, John Goerzen wrote: > On Tue, Feb 03, 2009 at 10:56:13PM +0000, Duncan Coutts wrote: > > > > Thanks to suggestions from Duncan Coutts, it's possible to call > > > > hSetEncoding even on buffered read Handles, and the right thing > > > > happens. So we can read from text streams that include multiple > > > > encodings, such as an HTTP response or email message, without having > > > > to turn buffering off (though there is a penalty for switching > > > > encodings on a buffered Handle, as the IO system has to do some > > > > re-decoding to figure out where it should start reading from again). > > > > > > Sounds useful, but is this the bit that causes the 30% performance hit? > > > > No. You only pay that penalty if you switch encoding. The standard case > > has no extra cost. > > I'm confused. I thought the standard case was conversion to the > system's local encoding? How is that different than selecting the > same encoding manually? Sorry, I think we've been talking at cross purposes. > There always has to be *some* conversion from a 32-bit Char to the > system's selection, right? Yes. In text mode there is always some conversion going on. Internally there is a byte buffer and a char buffer (ie UTF32). > What exactly do we have to do to avoid the penalty? The penalty we're talking about here is not the cost of converting bytes to characters, it's in switching which encoding the Handle is using. For example you might read some HTTP headers in ASCII and then switch the Handle encoding to UTF8 to read some XML. Switching the Handle encoding has a penalty. We have to discard the characters that we pre-decoded and re-decode the byte buffer in the new encoding. It's actually slightly more complicated because we do not track exactly how the byte and character buffers relate to each other (it'd be too expensive in the normal cases) so to work out the relationship when switching encoding we have to re-decode all the way from the beginning of the current byte buffer. The point is, in terms of performance we get the ability to switch handle encoding more or less for free. It has a cost in terms of code complexity. The simpler alternative design was that you would not be able to switch encoding on a read handle that used any buffering at the character level without loosing bytes. The performance penalty when switching encoding is the downside to the ordinary code path being fast. > > No, I think that's 30% for latin1. The cost is not really the character > > conversion but the copying from a byte buffer via iconv to a char > > buffer. > > Don't we already have to copy between a byte buffer and a char buffer, > since read() and write() use a byte buffer? In the existing Handle mechanism we read() into a byte buffer and then when doing say getLine or getContents we allocate [Char]'s in a loop reading bytes directly from the byte buffer. There is no separate character buffer. Duncan From wren at freegeek.org Tue Feb 3 21:05:08 2009 From: wren at freegeek.org (wren ng thornton) Date: Tue Feb 3 20:55:14 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <75cc17ac0902022255j697f3c5dga63ee972784b496@mail.gmail.com> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <87ocxkznrj.fsf@malde.org> <75cc17ac0902021113n2d566173sd84268acc11b8fca@mail.gmail.com> <87k588zivs.fsf@malde.org> <75cc17ac0902022255j697f3c5dga63ee972784b496@mail.gmail.com> Message-ID: <4988F7D4.6060703@freegeek.org> Gregg Reynolds wrote: > On Mon, Feb 2, 2009 at 2:25 PM, Ketil Malde wrote: > >> Gregg Reynolds writes: >> >>> Just shorthand for something like "data Tcon a = Dcon a", applied to Int. >>> Any data constructor expression using an Int will yield a value of type >> Tcon >>> Int. >> Right. But then the set of values is isomorphic to the set of Ints, >> right? >> > > The values constructed by that particular constructor, yes; good point. > Isomorphic, but not the same. (And also, if we have a second constructor, > what's our cardinality? The first one "uses up" all the integers, no? No. If we have the type (Either Integer Integer) we have W+W values. There's a tag to distinguish whether we chose the Left or Right variety of Integer, but having made that choice we still have the choice of any Integer. Thus, this type adds one extra bit to the size of the integers, doubling their cardinality. Which is why ADTs are often called "sum--product types". Replacing products and coproducts with, er, products and summations we can talk about the cardinality of types (ignoring _|_): |()| = 1 |Bool| = 1 + 1 |Maybe N| = 1 + |N| |(N,M)| = |N| * |M| |Either N M| = |N| + |M| etc Really we're just changing the evaluation function for our ADT algebra. Extending things to GADTs, this is also the reason why functions are called exponential and denoted as such in category theory: |N -> M| = |M| ^ |N| That's the number of functions that exist in that type. Not all of these are computable, however, as discussed elsewhere. -- Live well, ~wren From dbueno at gmail.com Tue Feb 3 22:34:56 2009 From: dbueno at gmail.com (Denis Bueno) Date: Tue Feb 3 22:25:06 2009 Subject: [Haskell-cafe] Converting Lists to Sets In-Reply-To: <4988be1b95af9_7919155555587eb423b@weasel6.tmail> References: <4988be1b95af9_7919155555587eb423b@weasel6.tmail> Message-ID: <6dbd4d000902031934i1e537ad5x915ea8cefb241b6@mail.gmail.com> On Tue, Feb 3, 2009 at 14:58, rodrigo.bonifacio wrote: > Hi all, > > I'm trying to use the Funsat library. One of its data types is CNF: > > data CNF = CNF { > numVars :: Int > numClauses :: Int > clauses :: Set Clause > } > > I have a list of clauses, but I'm getting an error when converting such a list to a Set. Using the fromList function, the ghc compiler reports that the fromList function is not applicable to literals. > > type Clause = [Lit] > > newtype Lit = L { > unLit :: Int > } > > So, my question is: How can I solve this problem? Assuming your list of clauses, you just need Data.Set.fromList: import qualified Data.Set as Set clauses :: [Clause] Set.fromList clauses :: Set Clause Denis From jgoerzen at complete.org Tue Feb 3 22:49:10 2009 From: jgoerzen at complete.org (John Goerzen) Date: Tue Feb 3 22:39:22 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <1233711179.26754.616.camel@localhost> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> <20090203233943.GA10645@complete.org> <1233711179.26754.616.camel@localhost> Message-ID: <49891036.1060100@complete.org> Duncan Coutts wrote: > Sorry, I think we've been talking at cross purposes. I think so. >> There always has to be *some* conversion from a 32-bit Char to the >> system's selection, right? > > Yes. In text mode there is always some conversion going on. Internally > there is a byte buffer and a char buffer (ie UTF32). > >> What exactly do we have to do to avoid the penalty? > > The penalty we're talking about here is not the cost of converting bytes > to characters, it's in switching which encoding the Handle is using. For > example you might read some HTTP headers in ASCII and then switch the > Handle encoding to UTF8 to read some XML. Simon referenced a 30% penalty. Are you saying that if we read from a Handle using the same encoding that we used when we first opened it, that we won't see any slowdown vs. the system in 6.10? > Switching the Handle encoding has a penalty. We have to discard the > characters that we pre-decoded and re-decode the byte buffer in the new > encoding. It's actually slightly more complicated because we do not Got it. That makes sense, as does the decision to optimize for the more common (not switching the encoding) case. -- John From DekuDekuplex at Yahoo.com Wed Feb 4 00:32:58 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Wed Feb 4 00:23:14 2009 Subject: [Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel References: <1233706548.14308.125.camel@flippa-eee> Message-ID: On Wed, 04 Feb 2009 00:15:48 +0000, Philippa Cowderoy wrote: >[...] > >If you need to know how to use monads so you can do IO, >#haskell-in-depth isn't the place. On the other hand, if you want to >discuss how Haskell's monads compare to the category theory or what the >category theory can tell us about how individual monads relate to the >language as a whole, -in-depth is a good place! In particular, we're >hoping that the kind of category theory discussions that give the >mistaken impression you actually need to know CT will increasingly live >in #haskell-in-depth. > >We're not after a theory channel though - architectural discussion, >compiler implementation, possible type system extensions, library >design, all are good subjects. Great work! I look forward to participating sometime in the near future. In that case, for people who need to know how to use monads so that they can do IO, why not create a #haskell-beginners channel? I have occasionally read posts of some users who were hesitant to participate in #haskell until they learned enough to keep up with the discussions there. If neither #haskell nor #haskell-in-depth is appropriate, perhaps they would feel more comfortable in a Haskell-beginners-specific channel? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From dan.doel at gmail.com Wed Feb 4 01:12:23 2009 From: dan.doel at gmail.com (Dan Doel) Date: Wed Feb 4 01:02:32 2009 Subject: [Haskell-cafe] type metaphysics In-Reply-To: <4988F7D4.6060703@freegeek.org> References: <75cc17ac0902020716k51d89157u8a9ae93771181dda@mail.gmail.com> <75cc17ac0902022255j697f3c5dga63ee972784b496@mail.gmail.com> <4988F7D4.6060703@freegeek.org> Message-ID: <200902040112.23944.dan.doel@gmail.com> On Tuesday 03 February 2009 9:05:08 pm wren ng thornton wrote: > Extending things to GADTs, this is also the reason why functions are > > called exponential and denoted as such in category theory: > |N -> M| = |M| ^ |N| > > That's the number of functions that exist in that type. Not all of these > are computable, however, as discussed elsewhere. This is all correct, except that exponentials are just part of algebraic data types, not generalized algebraic data types. Generalized algebraic data types are similar to inductive families, in that you can target constructors at specific type-indices, like so: data T t where I :: T Int P :: T a -> T b -> T (a,b) Both of those are genuine GADT constructors. There's also things like: E :: T a -> T b -> T b But those are doable by 'mere' ADTs plus existential quantification: data T b = ... | forall a. P (T a) (T b) -- Dan From kamysh at kamysh.org Wed Feb 4 01:26:44 2009 From: kamysh at kamysh.org (Valentyn Kamyshenko) Date: Wed Feb 4 01:16:57 2009 Subject: [Haskell-cafe] Re: circular dependencies in cabal In-Reply-To: <1233655443.26754.579.camel@localhost> References: <3C5DD03C-B814-43A1-A525-E852D1B305D1@kamysh.org> <1233500011.26754.346.camel@localhost> <2E238544-AD57-4D3A-9E50-A7B371D29449@kamysh.org> <1233567077.26754.475.camel@localhost> <20090203021106.13b07e14@solaris> <1233624874.26754.536.camel@localhost> <7802E7F3-4D3A-4D8E-8765-2CB2BA4D39A6@kamysh.org> <1233655443.26754.579.camel@localhost> Message-ID: Hi Duncan, I agree with your arguments. I think it is a less evil to disable 'cabal upgrade' until the problem is fixed. To have 'cabal upgrade' to ask for confirmation (and to allow user to select packages to be updated from the list) is even better. -- Valentyn. On Feb 3, 2009, at 2:04 AM, Duncan Coutts wrote: > On Mon, 2009-02-02 at 19:16 -0800, Valentyn Kamyshenko wrote: >> Hi Duncan, >> >> The major problem that I see is with >> # cabal update >> # cabal upgrade >> sequence of operations (that is, upgrading all installed packages). > > Right, that's exactly what doesn't work well and that I'm proposing to > temporarily disable. > >> I use this regularly to keep packages that I use (or are going to >> use) >> up to date. >> This is the functionality that, I suppose, everybody expects from the >> system like hackage/cabal. >> >> And, so far as I can see, the major problem is that 'cabal upgrade' >> will happily upgrade packages, that the core package depends on, and >> eventually will create configuration with circular dependencies. >> Can we do something simple - like, for example, forbidding updates of >> the packages that the core depends on (directly and indirectly)? > > Yes and there are a couple of additional ways we could improve it. But > I'm thinking it'd be better to release before those things are done, > and > so in the mean time disable upgrade. In the mean time we can make it > list the available packages that are newer than the installed ones and > you get to pick manually which ones are sensible to install. > > Duncan > From derek.a.elkins at gmail.com Wed Feb 4 01:35:09 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed Feb 4 01:25:26 2009 Subject: [Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel In-Reply-To: References: <1233706548.14308.125.camel@flippa-eee> Message-ID: <1233729309.27250.6.camel@derek-laptop> On Wed, 2009-02-04 at 14:32 +0900, Benjamin L.Russell wrote: > On Wed, 04 Feb 2009 00:15:48 +0000, Philippa Cowderoy > wrote: > > >[...] > > > >If you need to know how to use monads so you can do IO, > >#haskell-in-depth isn't the place. On the other hand, if you want to > >discuss how Haskell's monads compare to the category theory or what the > >category theory can tell us about how individual monads relate to the > >language as a whole, -in-depth is a good place! In particular, we're > >hoping that the kind of category theory discussions that give the > >mistaken impression you actually need to know CT will increasingly live > >in #haskell-in-depth. > > > >We're not after a theory channel though - architectural discussion, > >compiler implementation, possible type system extensions, library > >design, all are good subjects. > > Great work! I look forward to participating sometime in the near > future. > > In that case, for people who need to know how to use monads so that > they can do IO, why not create a #haskell-beginners channel? I have > occasionally read posts of some users who were hesitant to participate > in #haskell until they learned enough to keep up with the discussions > there. If neither #haskell nor #haskell-in-depth is appropriate, > perhaps they would feel more comfortable in a > Haskell-beginners-specific channel? Asking any Haskell-related question at any level is appropriate in #haskell, now as always. One of the implicit goals of the new channel is to minimize such "intimidation." The explicit goal of the new channel is to increase the newbie friendliness of #haskell. From dons at galois.com Wed Feb 4 01:37:54 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 4 01:28:31 2009 Subject: [Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel In-Reply-To: References: <1233706548.14308.125.camel@flippa-eee> Message-ID: <20090204063754.GB17095@whirlpool.galois.com> We explicitly want to avoid a newbie "trap" See the summary of the discussion that lead to the channel creation http://haskell.org/haskellwiki/IRC_channel/Phase_2 -- Don DekuDekuplex: > On Wed, 04 Feb 2009 00:15:48 +0000, Philippa Cowderoy > wrote: > > >[...] > > > >If you need to know how to use monads so you can do IO, > >#haskell-in-depth isn't the place. On the other hand, if you want to > >discuss how Haskell's monads compare to the category theory or what the > >category theory can tell us about how individual monads relate to the > >language as a whole, -in-depth is a good place! In particular, we're > >hoping that the kind of category theory discussions that give the > >mistaken impression you actually need to know CT will increasingly live > >in #haskell-in-depth. > > > >We're not after a theory channel though - architectural discussion, > >compiler implementation, possible type system extensions, library > >design, all are good subjects. > > Great work! I look forward to participating sometime in the near > future. > > In that case, for people who need to know how to use monads so that > they can do IO, why not create a #haskell-beginners channel? I have > occasionally read posts of some users who were hesitant to participate > in #haskell until they learned enough to keep up with the discussions > there. If neither #haskell nor #haskell-in-depth is appropriate, > perhaps they would feel more comfortable in a > Haskell-beginners-specific channel? > > -- Benjamin L. Russell > -- > Benjamin L. Russell / DekuDekuplex at Yahoo dot com > http://dekudekuplex.wordpress.com/ > Translator/Interpreter / Mobile: +011 81 80-3603-6725 > "Furuike ya, kawazu tobikomu mizu no oto." > -- Matsuo Basho^ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From tom.davie at gmail.com Wed Feb 4 01:42:44 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Wed Feb 4 01:32:54 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Message-ID: <286708A8-748D-4870-A24F-2E7F9B96E249@gmail.com> On 3 Feb 2009, at 22:37, Rafael Gustavo da Cunha Pereira Pinto wrote: > > Hello folks > > > After a discussion on whether is possible to compile > hmatrix in Windows, I decided to go crazy and do a LU decomposition > entirely in Haskell... > > At first I thought it would be necessary to use a mutable > or monadic version of Array, but then I figured out it is a purely > interactive process. > > I am releasing this code fragment as LGPL. Shinyness indeed ? a quick note though, as ghc doesn't support dynamic linking of Haskell code, the above is equivalent to the GPL. Would be lovely if you packaged this up and stuck it on Hackage :) Bob From wqeqweuqy at hotmail.com Wed Feb 4 02:15:49 2009 From: wqeqweuqy at hotmail.com (Neal Alexander) Date: Wed Feb 4 02:07:48 2009 Subject: [Haskell-cafe] Re: Purely funcional LU decomposition In-Reply-To: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Message-ID: Array is no good man! Quad Tree matrices perform much nicer from what I've seen. I wrote some matrix stuff based on D. Stott Parker's "Randomized Gaussian elimination" papers (http://www.cs.ucla.edu/~stott/ge/). He presents some recursive block based methods of solving without pivoting. I want to upload the full library to Hackage, but it'd be nice to have some people look through it before - mainly because i never took linear algebra heh. QuickCheck seems to be holding things together though. Check these definitions (where the input matrix has been pre-transformed with the butterfly if needed -- revertRBT . invert . applyRBT): gauss (M.Scalar v) = (M.Scalar 1, M.Scalar v) gauss (M.Matrix (a,b,c,d)) = (M.Matrix (l, M.Scalar 0, x, l'), M.Matrix (u, y, M.Scalar 0, u')) where (l,u) = gauss a (l',u') = gauss $ d - (x * y) x = c * (invert u) y = (invert l) * b invert (M.Scalar v) = M.Scalar (1 / v) invert (M.Matrix (a,b,c,d)) = M.Matrix (w,x,y,z) where w = aI - (aIb * y) x = negate $ aIb * z y = negate $ z * caI z = invert $ d - (caI * b) ----------- aI = invert a caI = c * aI aIb = aI * b benchmarked against (in order of speed): 1. Mesa GL math in C called through FFI. 2. Finger tree based port. 3. Mutable array based port. 2 and 3 were scrapped right away. Heres some of the benchmark vs the C version. ------------------------------------ Matrix Inversion - 999999999x ------------------------------------ ------- haskell ------------ ContextSwitches - 224017 First level fills = 0 Second level fills = 0 ETime( 0:00:41.328 ) UTime( 0:00:40.875 ) KTime( 0:00:00.000 ) ITime( 0:00:41.484 ) ---------- C --------------- ContextSwitches - 640016 First level fills = 0 Second level fills = 0 ETime( 0:01:56.109 ) UTime( 0:01:55.359 ) KTime( 0:00:00.000 ) ITime( 0:01:54.328 ) ------------------------------------ Matrix Inversion - 9999999x ------------------------------------ ------- haskell ------------ ContextSwitches - 6204 First level fills = 0 Second level fills = 0 ETime( 0:00:00.687 ) UTime( 0:00:00.421 ) KTime( 0:00:00.000 ) ITime( 0:00:01.031 ) ---------- C --------------- ContextSwitches - 7396 First level fills = 0 Second level fills = 0 ETime( 0:00:01.171 ) UTime( 0:00:01.171 ) KTime( 0:00:00.000 ) ITime( 0:00:01.250 ) ------------------------------------- Matrix multiplication - 999999999x ------------------------------------- ------- haskell ------------ ContextSwitches - 234644 First level fills = 0 Second level fills = 0 ETime( 0:00:42.093 ) UTime( 0:00:41.609 ) KTime( 0:00:00.000 ) ITime( 0:00:42.187 ) ---------- C --------------- ContextSwitches - 228596 First level fills = 0 Second level fills = 0 ETime( 0:00:41.609 ) UTime( 0:00:41.375 ) KTime( 0:00:00.000 ) ITime( 0:00:41.515 ) From ithika at gmail.com Wed Feb 4 04:35:03 2009 From: ithika at gmail.com (Dougal Stanton) Date: Wed Feb 4 04:25:08 2009 Subject: [Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel In-Reply-To: References: <1233706548.14308.125.camel@flippa-eee> Message-ID: <2d3641330902040135y1c6f19fbg8d869bfb359b7205@mail.gmail.com> On Wed, Feb 4, 2009 at 5:32 AM, Benjamin L. Russell wrote: > If neither #haskell nor #haskell-in-depth is appropriate, > perhaps they would feel more comfortable in a > Haskell-beginners-specific channel? The danger with that is the only people who go there are beginners looking for advice. Without advisers also, it would quickly wither. How has the beginners' mailing list worked out, in this regard? At least with a ML it's possible to set aside some part of the day to answering questions... the same is not really possible for 5-hour-old conversations on IRC. Cheers, D From RafaelGCPP.Linux at gmail.com Wed Feb 4 04:41:35 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Wed Feb 4 04:31:41 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <286708A8-748D-4870-A24F-2E7F9B96E249@gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> <286708A8-748D-4870-A24F-2E7F9B96E249@gmail.com> Message-ID: <351ff25e0902040141w20e86e27led615cb8bc5e3c55@mail.gmail.com> On Wed, Feb 4, 2009 at 04:42, Thomas Davie wrote: > > Shinyness indeed ? a quick note though, as ghc doesn't support dynamic > linking of Haskell code, the above is equivalent to the GPL. > I always use LGPL. Anyway, I will keep it that way, as I still have hopes on dynamic linking Haskell becoming a reality > > Would be lovely if you packaged this up and stuck it on Hackage :) I may do that when I am finished with all the other stuff. I am building a (very primitive) circuit simulator using Haskell. It is a toy I am doing just to learn Haskell (until now I learned how to use Arrays and Parsec)... > > > Bob -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/9a5f9299/attachment.htm From paolo at hypersonic.it Wed Feb 4 05:33:21 2009 From: paolo at hypersonic.it (Paolo Losi) Date: Wed Feb 4 05:23:35 2009 Subject: [Haskell-cafe] Re: Ready for testing: Unicode support for Handle I/O In-Reply-To: <49887404.4070504@gmail.com> References: <49887404.4070504@gmail.com> Message-ID: <49896EF1.3080700@hypersonic.it> Simon Marlow wrote: > The only change to the existing behaviour is that by default, text IO > is done in the prevailing encoding of the system. Handles created by > openBinaryFile use the Latin-1 encoding, as do Handles placed in > binary mode using hSetBinaryMode. wouldn't be semantically correct for a "binary handle" to "return" [Word8]? also switching from text to binary (hSetBinaryMode) doesn't seem "natural" I understand that this has "heavy" consequences... Pao From apfelmus at quantentunnel.de Wed Feb 4 05:53:01 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Wed Feb 4 05:42:32 2009 Subject: [Haskell-cafe] Re: Elegant & powerful replacement for CSS In-Reply-To: References: Message-ID: Conal Elliott wrote: > > I've been wondering for a while now what a well-designed alternative to CSS > could be, where well-designed would mean consistent, composable, orthogonal, > functional, based on an elegantly compelling semantic model (denotational). Me too. I think there are several aspects 1. Layout description, i.e. sidebar `besides` (content `above` footer) 2. Visual properties, like red borders or blue backgrounds. 3. Applying the style sheet to the document, i.e. to the semantic markup. Current CSS is very weak at point 1, a clean box model in the spirit of TeX or Lout http://en.wikipedia.org/wiki/Lout is preferable. Point 2 is solved fairly well by current CSS. Background and border colors are primitives, after all; so it boils down to a list of attributes. But a higher-order language is preferably as well, for example to capture common combinations in a variable instead of having to cascade it. Concerning point 3, CSS does ok for a hard-coded and specific output medium. Ideally, one and the same content could be visualized for different output media like web browsers (resizable), printer (PDF quality) or an overhead projector. I imagine some kind of macro language like LaTeX, Lout or XML "with macros"; but none of these examples are elegant enough for my taste. It should be possible to embed other languages for instance for mathematical formulas, highlighted source code, etc. I imagine that 3 is compiled to some kind of "CSS bytecode" consisting of 2 and 1. Regards, apfelmus -- http://apfelmus.nfshost.com From DekuDekuplex at Yahoo.com Wed Feb 4 06:11:08 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Wed Feb 4 06:01:21 2009 Subject: [Haskell-cafe] Re: ANN: #haskell-in-depth IRC channel References: <1233706548.14308.125.camel@flippa-eee> <2d3641330902040135y1c6f19fbg8d869bfb359b7205@mail.gmail.com> Message-ID: On Wed, 4 Feb 2009 09:35:03 +0000, Dougal Stanton wrote: >On Wed, Feb 4, 2009 at 5:32 AM, Benjamin L. Russell > wrote: > >> If neither #haskell nor #haskell-in-depth is appropriate, >> perhaps they would feel more comfortable in a >> Haskell-beginners-specific channel? > >The danger with that is the only people who go there are beginners >looking for advice. Without advisers also, it would quickly wither. > >How has the beginners' mailing list worked out, in this regard? At >least with a ML it's possible to set aside some part of the day to >answering questions... the same is not really possible for 5-hour-old >conversations on IRC. It seems to have been working out quite well. Last month, there were a total of 57 threads, including 192 messages in Haskell-Beginners. Most questions get responses within a few minutes. You can see the archives for last month at http://www.haskell.org/pipermail/beginners/2009-January/thread.html . -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From max.vasin at gmail.com Wed Feb 4 06:32:51 2009 From: max.vasin at gmail.com (Max Vasin) Date: Wed Feb 4 06:27:18 2009 Subject: [Haskell-cafe] Re: Ready for testing: Unicode support for Handle I/O In-Reply-To: <49896EF1.3080700@hypersonic.it> References: <49887404.4070504@gmail.com> <49896EF1.3080700@hypersonic.it> Message-ID: Paolo Losi ?????: > wouldn't be semantically correct for a "binary handle" > to "return" [Word8]? Wouldn't it be more correct to separate binary IO, which return [Word8] (or ByteString) and text IO which return [Char] and deal with text encoding? IIRC that was done in Bulat Ziganshin's streams library. -- WBR, Max Vasin. From artyom.shalkhakov at gmail.com Wed Feb 4 06:45:55 2009 From: artyom.shalkhakov at gmail.com (Artyom Shalkhakov) Date: Wed Feb 4 06:36:02 2009 Subject: [Haskell-cafe] ANN: UrlDisp, a friendly URL dispatching library Message-ID: <2076f2f90902040345t67fcfd17i713c1c646dc578a3@mail.gmail.com> Hello, I would like to announce the first release of UrlDisp. It's a small library for URL dispatching (aka routing). Right now it works with CGI, and should be compatible with FastCGI as well (not tested). Happstack compatibility is planned. Documentation and usage examples are available at HaskellWiki: Thanks to Sterling Clover for his HVAC; this is where inspiration came from. Cheers, Artyom Shalkhakov. From paolo at hypersonic.it Wed Feb 4 06:53:18 2009 From: paolo at hypersonic.it (Paolo Losi) Date: Wed Feb 4 06:43:32 2009 Subject: [Haskell-cafe] Re: Ready for testing: Unicode support for Handle I/O In-Reply-To: References: <49887404.4070504@gmail.com> <49896EF1.3080700@hypersonic.it> Message-ID: <498981AE.4040006@hypersonic.it> Max Vasin wrote: > Wouldn't it be more correct to separate binary IO, which > return [Word8] (or ByteString) and text IO which return > [Char] and deal with text encoding? IIRC that was done in > Bulat Ziganshin's streams library. That's exactly what I meant. Text IO could be then implemented on top of binary IO. Would it be possible to envision a solution that enables composition of IO low level strategies vs binary <-> text conversion strategies? Pao From redcom at fedoms.com Wed Feb 4 06:55:39 2009 From: redcom at fedoms.com (=?iso-8859-15?Q?G=FCnther_Schmidt?=) Date: Wed Feb 4 06:45:59 2009 Subject: [Haskell-cafe] Automation and COM Message-ID: Hi, has anyone yet been using Sigbjorns COM package? Sigbjorn hasn't had the time yet to gather some docs on how to use it, so I wonder if someone else could post some examples on how to use it. I'm asking because I need to do some COM stuff with excel, which I know how to do in another language, but can't seem to get it even started with haskell. Any help appreciated. G?nther From marlowsd at gmail.com Wed Feb 4 07:49:32 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 4 07:39:46 2009 Subject: [Haskell-cafe] Re: Open unqualified imports In-Reply-To: <20090119192254.GA12611@matrix.chaos.earth.li> References: <7597366a-f280-48f3-a900-a0aad0935965@a29g2000pra.googlegroups.com> <20090119192254.GA12611@matrix.chaos.earth.li> Message-ID: <49898EDC.5040301@gmail.com> Ian Lynagh wrote: > On Fri, Jan 16, 2009 at 06:42:46AM -0800, eyal.lotem@gmail.com wrote: >> Closed-unqualified import: >> import Data.Map(Map, lookup) > > One problem with this style is that you can get lots of conflicts from > your VCS if you have multiple people working on the same module. Right; in GHC we actively discourage the use of explict import lists (or closed-unqualified import to use the terminology of this thread). http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#Imports I find that the reasons not to use explicit import lists outweigh the reasons to use them, at least for code that I'm working on (rather than just reading). Ideally the import lists would be maintained automatically by an IDE, and would be intelligently handled by the VCS. Cheers, Simon From marlowsd at gmail.com Wed Feb 4 08:25:11 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 4 08:15:22 2009 Subject: [Haskell-cafe] Re: Ready for testing: Unicode support for Handle I/O In-Reply-To: <49896EF1.3080700@hypersonic.it> References: <49887404.4070504@gmail.com> <49896EF1.3080700@hypersonic.it> Message-ID: <49899737.5020106@gmail.com> Paolo Losi wrote: > Simon Marlow wrote: > >> The only change to the existing behaviour is that by default, text IO >> is done in the prevailing encoding of the system. Handles created by >> openBinaryFile use the Latin-1 encoding, as do Handles placed in >> binary mode using hSetBinaryMode. > > wouldn't be semantically correct for a "binary handle" > to "return" [Word8]? > > also switching from text to binary (hSetBinaryMode) > doesn't seem "natural" Yes, and as I said in the original message I haven't done the binary/text separation (yet). I agree it's something that should be done, and the current API leaves a lot to be desired, but the main goal was to get Unicode text I/O working without breaking any existing code (or at least without breaking any code that isn't already morally broken :-). As a side-effect I managed to do some useful refactoring which should make further separation of layers much easier. So you should think of this as a step in the right direction, with further steps to come in the future. A while back there was a lot of activity on developing new IO library designs. There are a bunch of these: Bulat's streams library, a variant of Bulat's done by Takano Akio, John Goerzen's HVIO, and I had a prototype streams library too. The problem is, it's a lot of work to make a complete IO library implementation, agree on the API, and migrate over from the old one. And while we're on the subject of redesigning IO libraries, it's not at all clear that the imperative approach is the right one either. Cheers, Simon From marlowsd at gmail.com Wed Feb 4 08:31:20 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 4 08:21:32 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <1233701773.26754.590.camel@localhost> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> Message-ID: <498998A8.1060909@gmail.com> Duncan Coutts wrote: > On Tue, 2009-02-03 at 11:03 -0600, John Goerzen wrote: > >> Will there also be something to handle the UTF-16 BOM marker? I'm not >> sure what the best API for that is, since it may or may not be present, >> but it should be considered -- and could perhaps help autodetect encoding. > > I think someone else mentioned this already, but utf16 (as opposed to > utf16be/le) will use the BOM if its present. > > I'm not quite sure what happens when you switch encoding, presumably > it'll accept and consider a BOM at that point. Yes; the utf16 and utf32 encodings accept a BOM (and generate a BOM in write mode). This caused interesting bugs when doing re-decoding after switching encodings, because the BOM constitutes state in the decoder, which means that decoding is not necessarily repeatable unless you save the state (which iconv doesn't provide a way to do). Are there other encodings that have this kind of state? If so, then they might be restricted to NoBuffering at least when switching encodings. Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed Feb 4 08:46:16 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 4 08:36:05 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <498998A8.1060909@gmail.com> References: <49887404.4070504@gmail.com> <498878FE.2040502@complete.org> <1233701773.26754.590.camel@localhost> <498998A8.1060909@gmail.com> Message-ID: <1233755176.26754.617.camel@localhost> On Wed, 2009-02-04 at 13:31 +0000, Simon Marlow wrote: > Duncan Coutts wrote: > > On Tue, 2009-02-03 at 11:03 -0600, John Goerzen wrote: > > > >> Will there also be something to handle the UTF-16 BOM marker? I'm not > >> sure what the best API for that is, since it may or may not be present, > >> but it should be considered -- and could perhaps help autodetect encoding. > > > > I think someone else mentioned this already, but utf16 (as opposed to > > utf16be/le) will use the BOM if its present. > > > > I'm not quite sure what happens when you switch encoding, presumably > > it'll accept and consider a BOM at that point. > > Yes; the utf16 and utf32 encodings accept a BOM (and generate a BOM in > write mode). This caused interesting bugs when doing re-decoding after > switching encodings, because the BOM constitutes state in the decoder, > which means that decoding is not necessarily repeatable unless you save the > state (which iconv doesn't provide a way to do). > > Are there other encodings that have this kind of state? If so, then they > might be restricted to NoBuffering at least when switching encodings. Yes, I believe there are some Asian encodings that are stateful. Duncan From jmaessen at alum.mit.edu Wed Feb 4 09:19:19 2009 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Wed Feb 4 09:09:27 2009 Subject: [Haskell-cafe] Elegant & powerful replacement for CSS In-Reply-To: References: Message-ID: You might be interested in some of the recent work by Leo Meyerovich et al. at Berkeley. They wanted to parallelize CSS processing, and found they had to construct a simplified, orthogonal version of CSS and express their algorithms in terms of that subset. This is very much work in progress, but there's a description and pointer to talk slides here: http://www.eecs.berkeley.edu/~lmeyerov/#projects Presumably their forthcoming HotPar paper will yield more details. -Jan-Willem Maessen On Feb 3, 2009, at 2:39 PM, Conal Elliott wrote: > [Spin-off from the haskell-cafe discussion on functional/ > denotational GUI toolkits] > > I've been wondering for a while now what a well-designed alternative > to CSS could be, where well-designed would mean consistent, > composable, orthogonal, functional, based on an elegantly compelling > semantic model (denotational). > > - Conal > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From RafaelGCPP.Linux at gmail.com Wed Feb 4 09:49:38 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Wed Feb 4 09:39:43 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Message-ID: <351ff25e0902040649o5e40f7b0ieb90913eba9262ed@mail.gmail.com> Matt's code is pretty comprehensive. His LU implementation is much cleaner, essentially because he used the "ijk" format, while I used the "kij". I'll take a look and e-mail him eventually. Thanks! On Tue, Feb 3, 2009 at 23:26, Paulo Tanimoto wrote: > Hi Rafael, > > 2009/2/3 Rafael Gustavo da Cunha Pereira Pinto >: > > > > Hello folks > > > > > > After a discussion on whether is possible to compile hmatrix in > > Windows, I decided to go crazy and do a LU decomposition entirely in > > Haskell... > > > > At first I thought it would be necessary to use a mutable or > > monadic version of Array, but then I figured out it is a purely > interactive > > process. > > > > I am releasing this code fragment as LGPL. > > > > Pretty cool, thanks for releasing this into the wild. I remember > looking into this about a year ago. By the way, have you seen Matt's > DSP library? > > http://haskelldsp.sourceforge.net/ > > He's got LU and others in there, if my memory serves me. The last > release seems to be 2003, so it might be worth emailing him to see > what happened and if he has plans for the future. > > Regards, > > Paulo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/07501d6a/attachment.htm From manlio_perillo at libero.it Wed Feb 4 10:42:03 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 10:32:39 2009 Subject: [Haskell-cafe] about integer and float operations Message-ID: <4989B74B.7090806@libero.it> Hi. During some experiments with Python and Haskell I found some important differences about how some integer and float operations are implemented. The first difference is about a `mod` b, when a and b are Float types. Python use the fmod function, and it also implement divmod; Haskell seems to lack support for this operation. The second difference is about the division of two integers. Consider this Python code: >>> from __future__ import division >>> def fac(n): ... return reduce(lambda a, b: a * (b + 1), xrange(n), 1) ... >>> float(fac(777)) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to float >>> fac(777) / fac(777) 1.0 Here CPython does not convert the two integers to float before to divide them, but make use of a special algorithm. GHC, instead, returns NaN I don't know if the implementations of divMod and "true" integer division in CPython are "robust", but there is some important reason why these operations are not supported in Haskell? Thanks Manlio Perillo From sethg at ropine.com Wed Feb 4 10:52:27 2009 From: sethg at ropine.com (Seth Gordon) Date: Wed Feb 4 10:42:31 2009 Subject: [Haskell-cafe] pure crisis :) In-Reply-To: <593855719.20090201221918@gmail.com> References: <593855719.20090201221918@gmail.com> Message-ID: <4989B9BB.8070502@ropine.com> Bulat Ziganshin wrote: > Hello haskell-cafe, > > pure functional denotation for crisis: > > (_|_) > Buy ?, sell ?! From gwern0 at gmail.com Wed Feb 4 10:56:42 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Feb 4 10:46:46 2009 Subject: [Haskell-cafe] Re: ANN: diagrams 0.2 In-Reply-To: <20090201063706.GC30336@berkeley.edu> References: <20090131223734.GA28526@seas.upenn.edu> <20090201063706.GC30336@berkeley.edu> Message-ID: On Sun, Feb 1, 2009 at 1:37 AM, John MacFarlane wrote: > Not too hard, I think. Here's code for something similar (for graphviz > diagrams), derived from plugins/DotPlugin.hs in SVN pandoc. > > transform :: Block -> IO Block > transform (CodeBlock (id, classes, namevals) contents) | "dot" `elem` classes = do > let (name, outfile) = case lookup "name" namevals of > Just fn -> ([Str fn], fn ++ ".png") > Nothing -> ([], uniqueName contents ++ ".png") > result <- readProcess "dot" ["-Tpng"] contents > writeFile outfile result > return $ Para [Image name (outfile, "")] > transform x = return x > > -- | Generate a unique filename given the file's contents. > uniqueName :: String -> String > uniqueName = showDigest . sha1 . fromString > > The 'transform' function will transform delimited code blocks such > as > > ~~~ {.dot name="diagram1"} > digraph G {Hello->World} > ~~~ > > into images generated by running the contents through graphviz's dot. To > lift this into a transformation of Pandoc documents, you can use syb: > > convertGraphviz :: Pandoc -> IO Pandoc > convertGraphviz = everywhereM (mkM transform) > > With minimal modifications, the same technique should work for > diagrams... > > Best, > John This certainly does seem reasonable, but I don't think the sandboxing/interpretation question is addressed. In your GraphViz example, you dump out to the 'dot' executable and it does things which you read back. But with Diagrams, we're interested in running arbitrary Haskell code - that's what makes Diagrams so useful, that we can exploit the full power of Haskell in our expressions. Now, to implement it, I would probably say to myself, "well, we'll create a temporary file, we'll write some basic imports into it, then we'll write the user's expression into it as the definition of a function 'foo', and main will be defined as 'main = renderFile foo'. Then we use 'runhaskell' on the temporary file to create the picture, delete the temp file, and bob's your uncle." Except of course there's nothing to prevent DoS attacks or other exploits in the arbitrary code. So do we accept this and say that this is a plugin one uses at one's own risk? -- gwern From newsham at lava.net Wed Feb 4 12:41:45 2009 From: newsham at lava.net (Tim Newsham) Date: Wed Feb 4 12:31:50 2009 Subject: [Haskell-cafe] Monad explanation Message-ID: I put up a small Monad explanation (I wouldn't quite call it a tutorial): http://www.thenewsh.com/~newsham/haskell/monad.html The intent here is to is to have a short description of what a Monad is that is approachable by Haskell beginners or non- Haskell programmers who are looking for an intuitive definition but may not yet have the background or the inclination to jump into full tutorial to tackle the subject. Tim Newsham http://www.thenewsh.com/~newsham/ From wagner.andrew at gmail.com Wed Feb 4 13:08:07 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Wed Feb 4 12:58:11 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: Message-ID: This is nice and simple. My only concern is I'm not sure there's enough of a distinction between "Monad" and "State Monad". That is, I'm not sure it's clear enough that the way you're binding the small programs together in the initial example is only one way you could bind them together, and thus it's only one instance of Monad. On Wed, Feb 4, 2009 at 12:41 PM, Tim Newsham wrote: > I put up a small Monad explanation (I wouldn't quite call it > a tutorial): > http://www.thenewsh.com/~newsham/haskell/monad.html > > The intent here is to is to have a short description of what > a Monad is that is approachable by Haskell beginners or non- > Haskell programmers who are looking for an intuitive definition > but may not yet have the background or the inclination to > jump into full tutorial to tackle the subject. > > Tim Newsham > http://www.thenewsh.com/~newsham/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/5e71c0b4/attachment.htm From matt at mattelder.org Wed Feb 4 13:37:23 2009 From: matt at mattelder.org (Matthew Elder) Date: Wed Feb 4 13:27:26 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! Message-ID: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> Hello Haskell Cafe, I just wanted to inform you that the Happstack project has shipped it's 0.1 release. For those of you who don't know, Happstack is the successor for the HAppS project. More details on the release can be found at http://blog.happstack.com/2009/02/03/happstack-01-released . Thanks for your time, Matthew Elder -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/3f269f63/attachment.htm From gale at sefer.org Wed Feb 4 14:07:13 2009 From: gale at sefer.org (Yitzchak Gale) Date: Wed Feb 4 13:57:18 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <4989B74B.7090806@libero.it> References: <4989B74B.7090806@libero.it> Message-ID: <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> Manlio Perillo wrote: > The first difference is about a `mod` b, when a and b are Float types. > Python use the fmod function, and it also implement divmod; Haskell seems to > lack support for this operation. Yes, Haskell does not implement the full IEEE. There are differing opinions about that: some say we should add it all in, and some say we should take it all out. Floating point is ugly, but useful. It seems that enough of IEEE is implemented for the vast majority of applications, so far. > The second difference is about the division of two integers. >>>> fac(777) / fac(777) > 1.0 > Here CPython does not convert the two integers to float before to divide > them, but make use of a special algorithm. > GHC, instead, returns NaN No, actually here Haskell shines. Perhaps this GHCi session will illuminate the issue for you: Prelude> let fac n = product [2..n] Prelude> fac 777 `div` fac 777 1 Prelude> fac 777 / fac 777 NaN In Haskell, the various integral and floating point types are completely separate. The literal 777 is overloaded - its type is 777 :: Num a => a so it can be used for both integral and floating point types. But the division operators are separate: div :: Integral a => a -> a -> a (/) :: Fractional a => a -> a -> a So when you use 777 together with /, the 777 is interpreted as a Fractional (defaulting to Double). And when you use it with div, the 777 is interpreted as an Integral (defaulting to Integer). Hope this helps, Yitz From dpiponi at gmail.com Wed Feb 4 14:09:46 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Wed Feb 4 13:59:51 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Message-ID: <625b74080902041109o4a219c3aj87738e7f9b4896bc@mail.gmail.com> 2009/2/3 Rafael Gustavo da Cunha Pereira Pinto : > After a discussion on whether is possible to compile hmatrix in > Windows, I decided to go crazy and do a LU decomposition entirely in > Haskell... > import Data.Array.IArray ... > e_an i j=a!(i,j)-(lik i)*a!(k,j) There are three different representations of arrays in this code: arrays, lists and a functional one where f represents an array with elements (f i j). Looks like a candidate for a stream fusion type thing so the user only writes code using one representation and some RULES switch back and forth between representations behind the scenes. -- Dan From gale at sefer.org Wed Feb 4 14:13:27 2009 From: gale at sefer.org (Yitzchak Gale) Date: Wed Feb 4 14:03:31 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> Message-ID: <2608b8a80902041113i5e7de4c0kfdaf434416b40825@mail.gmail.com> Manlio Perillo wrote: >> The first difference is about a `mod` b, when a and b are Float types. >> Python use the fmod function, and it also implement divmod; Haskell seems to >> lack support for this operation. I wrote: > Yes, Haskell does not implement the full IEEE. I spoke too soon. Data.Fixed.mod' supports this operation. I doubt that it is implemented via the IEEE primitive though. -Yitz From james.swaine at gmail.com Wed Feb 4 15:04:58 2009 From: james.swaine at gmail.com (James Swaine) Date: Wed Feb 4 14:55:04 2009 Subject: [Haskell-cafe] Data Parallel Haskell Question Message-ID: <5195fdde0902041204v6a1e2db0j31c29108a4abda7d@mail.gmail.com> I am somewhat of a beginner with DPH and wanted to ask a few (maybe elementary) questions. There appear to be two main libraries - regular and unlifted. I was a little unclear on the difference between the two and was hoping to get some clarification. If you use the 'regular' api, it seems that you can use the sort of 'syntactic sugar' language extensions (e.g. [: blah blah :]), but you are restricted to the somewhat limited Prelude explicitly written for use with code that is to be vectorised. If you use the 'unlifted' libraries, are you able to use functions/types from the standard Prelude? My problem is that I want to write a recursively-subdividing radix sort (for integer keys), where on each iteration I partition my keys into separate sets based on whether a certain bit is set or not. So I start with the most significant digit bit (say 31), and then work down to the least significant digit. I can write this in DPH just fine, but I'm getting 'panic' errors when I attempt to compile, and I wonder if it has something to do with the fact that I'm using the standard Data.Bits to inspect bits of each key. {-# LANGUAGE PArr, ParallelListComp #-} {-# OPTIONS -fvectorise #-} module RankPar(radix_sort) where import qualified Prelude import Data.Array.Parallel.PArray (fromList) import Data.Array.Parallel.Prelude ((+:+), fromPArrayP, not) import Data.Array.Parallel.Prelude.Int import Data.Bits {-# NOINLINE radix_sort #-} radix_sort :: Int -> [:Int:] -> [:Int:] radix_sort (-1) keys = keys radix_sort bit [:k:] = [:k:] radix_sort bit [: :] = [: :] radix_sort bit keys = (radix_sort (bit - 1) left) +:+ (radix_sort (bit - 1) right) where right = [: x | x <- keys, (testBit x bit) :] left = [: y | y <- keys, (not (testBit y bit)) :] Syntactically, this looks correct to me, but won't compile. Any ideas? Thanks all! -James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/68077690/attachment.htm From shooshpanchick at gmail.com Wed Feb 4 15:14:21 2009 From: shooshpanchick at gmail.com (Tymur Porkuian) Date: Wed Feb 4 15:04:27 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: Message-ID: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> For me, the key to understanding monads was that monad is "a value that know how to apply functions to itself". Or, more correctly, a container that knows how to apply functions to whatever is inside it. Before understanding this I read a lot of tutorials that presented monads as computations, IO sequencing structures, side effects encapsulation mechanisms, but it was a little bit too abstract, even though now From shooshpanchick at gmail.com Wed Feb 4 15:16:51 2009 From: shooshpanchick at gmail.com (Tymur Porkuian) Date: Wed Feb 4 15:06:56 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> Message-ID: <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> For me, the key to understanding monads was that monad is "a value that know how to apply functions to itself". Or, more correctly, a container that knows how to apply functions to whatever is inside it. Before understanding this I read a lot of tutorials that presented monads as computations, IO sequencing structures, side effects encapsulation mechanisms, but it was a little bit too abstract, even though now I know how they are used for these purposes. From dpiponi at gmail.com Wed Feb 4 15:20:22 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Wed Feb 4 15:10:27 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> Message-ID: <625b74080902041220m26388bfal824d3bd6f5dd00bb@mail.gmail.com> On Wed, Feb 4, 2009 at 12:16 PM, Tymur Porkuian wrote: > For me, the key to understanding monads was that monad is "a value > that know how to apply functions to itself". Or, more correctly, a > container that knows how to apply functions to whatever is inside it. You've just described a Functor rather than a Monad. :-) -- Dan From jonathanccast at fastmail.fm Wed Feb 4 15:24:23 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 4 15:14:30 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> Message-ID: <1233779063.6160.7.camel@jonathans-macbook> On Wed, 2009-02-04 at 22:16 +0200, Tymur Porkuian wrote: > For me, the key to understanding monads was that monad is "a value > that know how to apply functions to itself". Or, more correctly, a > container that knows how to apply functions to whatever is inside it. Close. (Monads are not `values' but types, but I'll let that slide). Remembering that all Haskell functions take a single argument, but we use currying to support an arbitrary number of arguments, we can arrange the Monad type class hierarchy like this: * Functor: A functor F allows a single function to be applied to a single F value. Multiple arguments (or none) are not supported; the definition of application does what you probably *don't* want if the function returns an F value itself. * Applicative: An applicative functor A allows a function of n arguments (for n >= 0) to be applied to n A values. However, the definition of application does what you probably *don't* want if the function returns an A value itself. * Monad: A monad M allows a function of n arguments (for n >= 0) to be applied to n M values; in addition, if the function returns an M value itself, you can combine that result with the arguments in a sensible way. jcc From RafaelGCPP.Linux at gmail.com Wed Feb 4 15:57:35 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Wed Feb 4 15:47:40 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <625b74080902041109o4a219c3aj87738e7f9b4896bc@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> <625b74080902041109o4a219c3aj87738e7f9b4896bc@mail.gmail.com> Message-ID: <351ff25e0902041257x72959e30l35a680076be94271@mail.gmail.com> On Wed, Feb 4, 2009 at 17:09, Dan Piponi wrote: > 2009/2/3 Rafael Gustavo da Cunha Pereira Pinto >: > > After a discussion on whether is possible to compile hmatrix in > > Windows, I decided to go crazy and do a LU decomposition entirely in > > Haskell... > > import Data.Array.IArray > ... > > e_an i j=a!(i,j)-(lik i)*a!(k,j) > > There are three different representations of arrays in this code: > arrays, lists and a functional one where f represents an array with > elements (f i j). Looks like a candidate for a stream fusion type > thing so the user only writes code using one representation and some > RULES switch back and forth between representations behind the scenes. > -- > Dan > Those different representations are derived from my (very) low Haskell handicap! :-D 1) I used lists for the intermediate L and U matrices so I wouldn't have the overhead of calling accumArray and assocs everywhere 2) I used the function that returns an array element just to shorten the line length, and to make sure I was typing it right! When I started this, I thought I would end with a couple of folds, but then I turned to the recursive version, so I could implement pivoting on matrix a' more easily. List comprehension also derived from this. I started thinking of a fold for L matrix and then it hit me that it was a list comprehension... Matt's DSP library has one of the most elegant implementations I saw, but it is harder to implement pivoting, which is really important for my application. lu :: Array (Int,Int) Double -- ^ A -> Array (Int,Int) Double -- ^ LU(A) lu a = a' where a' = array bnds [ ((i,j), luij i j) | (i,j) <- range bnds ] luij i j | i>j = (a!(i,j) - sum [ a'!(i,k) * a'!(k,j) | k <- [1 ..(j-1)] ]) / a'!(j,j) | i<=j = a!(i,j) - sum [ a'!(i,k) * a'!(k,j) | k <- [1 ..(i-1)] ] bnds = bounds a -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/5a34d28c/attachment.htm From manlio_perillo at libero.it Wed Feb 4 16:09:30 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 15:59:41 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> Message-ID: <498A040A.6030809@libero.it> Yitzchak Gale ha scritto: > Manlio Perillo wrote: > [...] >> The second difference is about the division of two integers. >>>>> fac(777) / fac(777) >> 1.0 >> Here CPython does not convert the two integers to float before to divide >> them, but make use of a special algorithm. >> GHC, instead, returns NaN > > No, actually here Haskell shines. Perhaps this GHCi session > will illuminate the issue for you: > > Prelude> let fac n = product [2..n] > Prelude> fac 777 `div` fac 777 > 1 > Prelude> fac 777 / fac 777 > NaN > No, this is not as complete as it is done in Python. In recent versions of Python you have two division operators. The `/` operator *always* perform a true division. As an example, the division of two integers return a float. The `//` operator *always* perform a "floor" division. This happens for both integers and floats: >>> 2.5 // 1.5 1.0 >>> 2.5 / 1.5 1.6666666666666667 In Haskell: Prelude> 2.5 `div` 1.5 :1:0: Ambiguous type variable `t' in the constraints: `Integral t' arising from a use of `div' at :1:0-12 `Fractional t' arising from the literal `1.5' at :1:10-12 Probable fix: add a type signature that fixes these type variable(s) (but this seems to be available with Data.Fixed, however on Debian Etch I still have GHC 6.8.2). As for your example: > Prelude> let fac n = product [2..n] > Prelude> fac 777 `div` (4 * fac 776) > 194 This is incorrect, because `div` returns an integer, but I want a float with the exact result (194.25 with Python). If I'm correct, there is no operator/function, in Haskell, that perform an exact division between two integers and return a float: exactDiv :: (Integral a, Real b) => a -> a -> b I personally prefer the Python solution, where we have two operators with the same behaviour over all the numbers. In Haskell, something like (/) :: (Num a, Real b) => a -> a -> b (//) :: (Num a, Integral b) => a -> a -> b > [...] Thanks Manlio Perillo From shooshpanchick at gmail.com Wed Feb 4 16:13:44 2009 From: shooshpanchick at gmail.com (Tymur Porkuian) Date: Wed Feb 4 16:03:48 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <1233779063.6160.7.camel@jonathans-macbook> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> <1233779063.6160.7.camel@jonathans-macbook> Message-ID: <7f22364a0902041313u2396d4d0g5d11a9e3fb1b1e1f@mail.gmail.com> Actually, I understand these types in terms of containers that override standard method of function application for their contents. In fact, there may be no contents, or several items, or nothing at all, or something strange, but the container behaves like there is a value of some type inside it. In these terms: Maybe - container that may or may not contain something [a] - container that contains several values and applies function to all of them State - container that has some other "secondary" value in it. IO - container that remembers passed functions and later will ask user for value, then apply functions to it. > * Monad: A monad M allows a function of n arguments (for n >= 0) to be > applied to n M values; in addition, if the function returns an M value > itself, you can combine that result with the arguments in a sensible > way. Here, what does "sensible" mean? What do we override? Also, would it be right to say that Arrow is a container for functions that overrides function chaining? From dpiponi at gmail.com Wed Feb 4 16:14:55 2009 From: dpiponi at gmail.com (Dan Piponi) Date: Wed Feb 4 16:05:00 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <351ff25e0902041257x72959e30l35a680076be94271@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> <625b74080902041109o4a219c3aj87738e7f9b4896bc@mail.gmail.com> <351ff25e0902041257x72959e30l35a680076be94271@mail.gmail.com> Message-ID: <625b74080902041314l5f388276t184ecf092c5bcfde@mail.gmail.com> On Wed, Feb 4, 2009 at 12:57 PM, Rafael Gustavo da Cunha Pereira Pinto wrote: > Those different representations are derived from my (very) low Haskell > handicap! :-D BTW That wasn't intended in any way as a criticism. I think it's interesting to look at real matrix code that people have written and think about what would be needed in a library to make it easier to write. -- Dan From dev at mobileink.com Wed Feb 4 16:20:24 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Wed Feb 4 16:10:30 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: Message-ID: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> On Wed, Feb 4, 2009 at 11:41 AM, Tim Newsham wrote: > I put up a small Monad explanation (I wouldn't quite call it > a tutorial): > http://www.thenewsh.com/~newsham/haskell/monad.html > "The values of the IO monad are programs that do IO. " That's a fairly common representation, seems to work for lots of people, but it caused me no end of trouble. Values are mathematical objects; how, I asked myself, can they possibly /be/ programs that do IO (or actions, or computations, or )? It doesn't make sense, says I, so I must be misunderstanding something about "values"; better spend hours and hours researching and trying to figure this out. But it turns out the answer is simple: they can't. They're not actions, or IO procedures, or anything else other than plain old mathematical values, no different than '2' or Int -> Char. They happen to correspond in some way to the external physical behavior of the program, but that correspondence is an implementation detail beyond the scope of the formal (mathematical) semantics of the language. You don't even need monads for this part; they only enter the picture in order to provide ordered evaluation. In fact there really aren't any "monadic values", since a monad is pure morphism; the values at issue are "functoric values" if anything. It's (the implementation of) getChar the does the IO, not IO Char. So you could say that the monad itself is a purely mathematical structure that has the felicitous if accidental side effect of imposing temporal sequence on the physical interpretation (events) associated with the program. -g -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/ef04c51a/attachment-0001.htm From jonathanccast at fastmail.fm Wed Feb 4 16:22:01 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 4 16:12:06 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <7f22364a0902041313u2396d4d0g5d11a9e3fb1b1e1f@mail.gmail.com> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> <1233779063.6160.7.camel@jonathans-macbook> <7f22364a0902041313u2396d4d0g5d11a9e3fb1b1e1f@mail.gmail.com> Message-ID: <1233782521.6160.18.camel@jonathans-macbook> On Wed, 2009-02-04 at 23:13 +0200, Tymur Porkuian wrote: > Actually, I understand these types in terms of containers that > override standard method of function application for their contents. Huh? You can't actually over-ride function application --- Haskell's built-in application always does exactly the same thing, at every type. You can, however, define new application-like operators that have other application-like behaviors. Haskell has a few of these: * return * (<$>) * (<*>) * (>>=) > In fact, there may be no contents, or several items, or nothing at > all, or something strange, but the container behaves like there is a > value of some type inside it. > > In these terms: > Maybe - container that may or may not contain something > [a] - container that contains several values and applies function to all of them > State - container that has some other "secondary" value in it. > IO - container that remembers passed functions and later will ask user > for value, then apply functions to it. Nice but irrelevant. And I think your definition of IO is wrong. > > * Monad: A monad M allows a function of n arguments (for n >= 0) to be > > applied to n M values; in addition, if the function returns an M value > > itself, you can combine that result with the arguments in a sensible > > way. > > Here, what does "sensible" mean? Sensible. As in, the definition of `join' in your monad can't be senseless, or irrelevant to the monad's intended use. > What do we override? join > Also, would it be right to say that Arrow is a container for functions > that overrides function chaining? No. jcc From manlio_perillo at libero.it Wed Feb 4 16:22:31 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 16:12:42 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A040A.6030809@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> Message-ID: <498A0717.8040809@libero.it> Manlio Perillo ha scritto: > [...] > > I personally prefer the Python solution, where we have two operators > with the same behaviour over all the numbers. > > In Haskell, something like > > (/) :: (Num a, Real b) => a -> a -> b This should be (/) :: (Num a, Fractional b) => a -> a -> b but I'm not sure it is correct. > (//) :: (Num a, Integral b) => a -> a -> b > Manlio Perillo From max.rabkin at gmail.com Wed Feb 4 16:26:32 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Wed Feb 4 16:16:44 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A040A.6030809@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> Message-ID: On Wed, Feb 4, 2009 at 1:09 PM, Manlio Perillo wrote: > In Haskell, something like > > (/) :: (Num a, Real b) => a -> a -> b You probably want (Real a, Fractional b) => a -> a -> b. Int is an instance of Real... Real is the class of types that can be converted to Rational. Then we can define (/.) :: (Real a1, Real a2, Fractional a) => a1 -> a2 -> a x /. y = fromRational $ toRational x / toRational y whose type is more general than the one I gave above, but we can restrict it to that by changing the signature, if you like. > (//) :: (Num a, Integral b) => a -> a -> b Again, Num is inappropriate, but we can define something similar: (//) :: (Integral b, Real a, Real a1) => a -> a1 -> b x // y = floor $ toRational x / toRational y Hope that helps, Max From rmm-haskell at z.odi.ac Wed Feb 4 16:26:52 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Wed Feb 4 16:17:01 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A0717.8040809@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> Message-ID: <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> Prelude> let i2fDiv a b = fromIntegral a / fromIntegral b Prelude> :t i2fDiv i2fDiv :: (Integral a, Fractional b, Integral a1) => a -> a1 -> b Prelude> 10 `i2fDiv` 3 3.3333333333333335 That what you're looking for? -Ross On Feb 4, 2009, at 4:22 PM, Manlio Perillo wrote: > Manlio Perillo ha scritto: >> [...] >> I personally prefer the Python solution, where we have two >> operators with the same behaviour over all the numbers. >> In Haskell, something like >> (/) :: (Num a, Real b) => a -> a -> b > > This should be > (/) :: (Num a, Fractional b) => a -> a -> b > > but I'm not sure it is correct. > >> (//) :: (Num a, Integral b) => a -> a -> b > > > Manlio Perillo > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From RafaelGCPP.Linux at gmail.com Wed Feb 4 16:31:35 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Wed Feb 4 16:21:39 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <625b74080902041314l5f388276t184ecf092c5bcfde@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> <625b74080902041109o4a219c3aj87738e7f9b4896bc@mail.gmail.com> <351ff25e0902041257x72959e30l35a680076be94271@mail.gmail.com> <625b74080902041314l5f388276t184ecf092c5bcfde@mail.gmail.com> Message-ID: <351ff25e0902041331i746e426cl207a340800fe687c@mail.gmail.com> On Wed, Feb 4, 2009 at 19:14, Dan Piponi wrote: > On Wed, Feb 4, 2009 at 12:57 PM, Rafael Gustavo da Cunha Pereira Pinto > wrote: > > > Those different representations are derived from my (very) low Haskell > > handicap! :-D > > BTW That wasn't intended in any way as a criticism. I think it's Not taken! > > interesting to look at real matrix code that people have written and > think about what would be needed in a library to make it easier to > write. > -- > Dan > What I miss most is a data structure with O(1) (amortized) direct access. One of the changes I thought today was to remove the ++ operator and create a list of lists that I would concat in the last call. -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/3663ed2f/attachment.htm From bugfact at gmail.com Wed Feb 4 16:32:33 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Wed Feb 4 16:23:26 2009 Subject: [Haskell-cafe] Re: Elegant & powerful replacement for CSS In-Reply-To: <20090204015038.0e4accaa@solaris> References: <20090204015038.0e4accaa@solaris> Message-ID: On Wed, Feb 4, 2009 at 1:50 AM, Achim Schneider wrote: > I don't believe that it's possible to draw a clear destinction between > "concerns the programmer" and "concerns the designer". In fact, I get > offended by the notion that I'm inherently incapable of distinguishing > readable from unreadable text, and think that the notion of designers > being unable to do anything but assembling a colourful collage of the > data they're given is more of a self-fulfilling prophecy than a truth. Having worked in the nexgen games industry with lots of designers and artists, I can only agree with Achim here. One cannot draw a hard line between programmers and designers, because these two come in all kinds of flavors ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/d43537f0/attachment.htm From manlio_perillo at libero.it Wed Feb 4 16:38:50 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 16:29:02 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> Message-ID: <498A0AEA.4000104@libero.it> Ross Mellgren ha scritto: > Prelude> let i2fDiv a b = fromIntegral a / fromIntegral b > Prelude> :t i2fDiv > i2fDiv :: (Integral a, Fractional b, Integral a1) => > a -> a1 -> b > Prelude> 10 `i2fDiv` 3 > 3.3333333333333335 > Prelude> fac 777 `i2fDiv` fac 777 NaN > That what you're looking for? > No. I'm looking for an exact integer division that avoids overflows, if possible. > -Ross > Manlio Perillo From thomas.dubuisson at gmail.com Wed Feb 4 16:42:56 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed Feb 4 16:33:26 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A0AEA.4000104@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> Message-ID: <4c44d90b0902041342v672507d2o9999b1a6223c56a@mail.gmail.com> > No. > I'm looking for an exact integer division that avoids overflows, if > possible. Use Data.Ratio: *Main Data.Ratio> (fac 777) / (4 * fac 776) :: Ratio Integer 777%4 Convert to a float , if you want, before displaying it. From gale at sefer.org Wed Feb 4 16:44:19 2009 From: gale at sefer.org (Yitzchak Gale) Date: Wed Feb 4 16:34:25 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A040A.6030809@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> Message-ID: <2608b8a80902041344n80ed676lf7d47ed792b6f009@mail.gmail.com> Manlio Perillo wrote: >>>>>> fac(777) / fac(777) >>> 1.0 >>> Here CPython does not convert the two integers to float before to divide >>> them, but make use of a special algorithm. >>> GHC, instead, returns NaN I wrote: >> No, actually here Haskell shines. Perhaps this GHCi session >> will illuminate the issue for you: >> Prelude> let fac n = product [2..n] >> Prelude> fac 777 `div` fac 777 >> 1 >> Prelude> fac 777 / fac 777 >> NaN > No, this is not as complete as it is done in Python. > The `/` operator *always* ...return a float... > The `//` operator *always* perform a "floor" division. > This happens for both integers and floats: > If I'm correct, there is no operator/function, in Haskell, that perform an > exact division between two integers and return a float: > exactDiv :: (Integral a, Real b) => a -> a -> b exactDiv :: (Real a, Real b, Fractional c) => a -> b -> c x `exactDiv` y = realToFrac x / realToFrac y Python does that same type coercion automatically at runtime. This can sometimes make your code look a bit neater, but other times really gets in the way. > I personally prefer the Python solution, where we have two operators with > the same behaviour over all the numbers. If you really like exactDiv better, you can define an operator to do it for you. But most people don't. Haskell gives you total control, since the types of everything are strictly defined at compile time. This has the extra advantage of giving you a really powerful type checker that can find many of your bugs at compile time. -Yitz From deniz.a.m.dogan at gmail.com Wed Feb 4 16:54:15 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Wed Feb 4 16:44:19 2009 Subject: [Haskell-cafe] Temporarily overriding Data.Generics Message-ID: <7b501d5c0902041354r66d8b262g22ffd165583a3d17@mail.gmail.com> Hi I'm currently working on "hacking" Data.Generics for my master thesis. I'm basically trying to find out whether it can be made a bit faster using e.g. rewrite rules. The problem I'm having is that I need an easy way to import my own modified version of Data.Generics (currently located in the same directory as my testing program) without unregistering or hiding syb-0.1.0.0 as base seems to depend on it. I've read the GHC user manual trying to find nice ways to do this using a bunch of different parameters to ghc, but I can't figure it out. Does anyone here know? Any help appreciated, Deniz From shooshpanchick at gmail.com Wed Feb 4 16:55:06 2009 From: shooshpanchick at gmail.com (Tymur Porkuian) Date: Wed Feb 4 16:45:10 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <1233782521.6160.18.camel@jonathans-macbook> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> <1233779063.6160.7.camel@jonathans-macbook> <7f22364a0902041313u2396d4d0g5d11a9e3fb1b1e1f@mail.gmail.com> <1233782521.6160.18.camel@jonathans-macbook> Message-ID: <7f22364a0902041355k54152e6tc19ff5b2541cf803@mail.gmail.com> > Huh? You can't actually over-ride function application --- Haskell's > built-in application always does exactly the same thing, at every type. It's a metaphor. In every case container has its own method of applying functions to its contents - e.g. instead of "f x" we write "x fmap f". > You can, however, define new application-like operators that have other > application-like behaviors. Haskell has a few of these: > > * return > * (<$>) > * (<*>) > * (>>=) I know Haskell, that's not what I'm talking about. What I'm trying to do is to create a simple explanation for monads that doesn't involve neither mathematics nor "computation" metaphor. From shooshpanchick at gmail.com Wed Feb 4 16:56:07 2009 From: shooshpanchick at gmail.com (Tymur Porkuian) Date: Wed Feb 4 16:46:12 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <7f22364a0902041355k54152e6tc19ff5b2541cf803@mail.gmail.com> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> <1233779063.6160.7.camel@jonathans-macbook> <7f22364a0902041313u2396d4d0g5d11a9e3fb1b1e1f@mail.gmail.com> <1233782521.6160.18.camel@jonathans-macbook> <7f22364a0902041355k54152e6tc19ff5b2541cf803@mail.gmail.com> Message-ID: <7f22364a0902041356v647a1b58vdd0f1683d766ceb1@mail.gmail.com> > It's a metaphor. In every case container has its own method of > applying functions to its contents - e.g. instead of "f x" we write "x > fmap f". x `fmap` f, of course From shooshpanchick at gmail.com Wed Feb 4 16:57:13 2009 From: shooshpanchick at gmail.com (Tymur Porkuian) Date: Wed Feb 4 16:47:17 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <7f22364a0902041356v647a1b58vdd0f1683d766ceb1@mail.gmail.com> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> <1233779063.6160.7.camel@jonathans-macbook> <7f22364a0902041313u2396d4d0g5d11a9e3fb1b1e1f@mail.gmail.com> <1233782521.6160.18.camel@jonathans-macbook> <7f22364a0902041355k54152e6tc19ff5b2541cf803@mail.gmail.com> <7f22364a0902041356v647a1b58vdd0f1683d766ceb1@mail.gmail.com> Message-ID: <7f22364a0902041357o3d0fcfd6oed531fc718118de6@mail.gmail.com> > x `fmap` f disregard that, f `fmap` x From gale at sefer.org Wed Feb 4 16:59:32 2009 From: gale at sefer.org (Yitzchak Gale) Date: Wed Feb 4 16:49:35 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A0AEA.4000104@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> Message-ID: <2608b8a80902041359n2484c338nb089b0301d08720f@mail.gmail.com> Manlio Perillo wrote: > No. > I'm looking for... Manlio - can you describe exactly what you want? Do you know exactly what you want? You have said that you want division like in Python - but that even that is not well defined: Python 2.6.1 >>> 3/5 0 Python 3.1 >>> 3/5 0.59999999999999998 Please tell us *exactly* what you want your division to do, on integers and on floating point. Or tell us you want division like / in Python 3.1, or whatever. -Yitz From manlio_perillo at libero.it Wed Feb 4 17:03:15 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 16:53:26 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> Message-ID: <498A10A3.60700@libero.it> Max Rabkin ha scritto: > [...] > > Then we can define > (/.) :: (Real a1, Real a2, Fractional a) => a1 -> a2 -> a > x /. y = fromRational $ toRational x / toRational y > [...] > > (//) :: (Integral b, Real a, Real a1) => a -> a1 -> b > x // y = floor $ toRational x / toRational y > > Hope that helps, > Max > Yes, thanks. However there is still a *big* problem: it is inefficient. Here is a Python version of the Chudnovsky algorithm [1] for computing Pi: http://paste.pocoo.org/show/102800/ On my system it takes 10 seconds. Here is an Haskell version: http://paste.pocoo.org/show/102801/ On my system it takes 30 seconds. Thanks Manlio Perillo [1] http://upload.wikimedia.org/math/6/6/8/6681cd21f3ca9bf13248a87d4202e06a.png From max.rabkin at gmail.com Wed Feb 4 17:08:05 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Wed Feb 4 16:58:10 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A10A3.60700@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> Message-ID: On Wed, Feb 4, 2009 at 2:03 PM, Manlio Perillo wrote: > Max Rabkin ha scritto: >> >> [...] >> >> Then we can define >> (/.) :: (Real a1, Real a2, Fractional a) => a1 -> a2 -> a >> x /. y = fromRational $ toRational x / toRational y > >> [...] >> >> (//) :: (Integral b, Real a, Real a1) => a -> a1 -> b >> x // y = floor $ toRational x / toRational y >> >> Hope that helps, >> Max >> > > Yes, thanks. > > However there is still a *big* problem: it is inefficient. It sure is. To get the type you asked for, one *has* to go via rationals. But... > Here is an Haskell version: > http://paste.pocoo.org/show/102801/ > > On my system it takes 30 seconds. You're only dividing integers by integers to get Doubles. x /. y = fromIntegral x / fromIntegral y works just fine in this case. --Max From manlio_perillo at libero.it Wed Feb 4 17:10:44 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 17:00:56 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902041359n2484c338nb089b0301d08720f@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> <2608b8a80902041359n2484c338nb089b0301d08720f@mail.gmail.com> Message-ID: <498A1264.9030400@libero.it> Yitzchak Gale ha scritto: > Manlio Perillo wrote: >> No. >> I'm looking for... > > Manlio - can you describe exactly what you want? > Do you know exactly what you want? > > You have said that you want division like in Python - > but that even that is not well defined: > > Python 2.6.1 >>>> 3/5 > 0 > You have to: from __future__ import division In Python 3.x this is now the default behaviour > Python 3.1 >>>> 3/5 > 0.59999999999999998 > > Please tell us *exactly* what you want your division to > do, on integers and on floating point. I'm posting more details in another response. Thanks Manlio Perillo From manlio_perillo at libero.it Wed Feb 4 17:13:41 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 17:03:50 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902041344n80ed676lf7d47ed792b6f009@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <2608b8a80902041344n80ed676lf7d47ed792b6f009@mail.gmail.com> Message-ID: <498A1315.7080201@libero.it> Yitzchak Gale ha scritto: > [...] > > exactDiv :: (Real a, Real b, Fractional c) => a -> b -> c > x `exactDiv` y = realToFrac x / realToFrac y > > Python does that same type coercion automatically at runtime. No, this is not correct. CPython converts to float only for a "simple" integer (since conversion from machine int to machine float will never overflow). For a "long integer" it uses a special algorithm for computing the division, that avoids overflow if the final result is in the range of a float. http://code.python.org/hg/trunk/file/tip/Objects/longobject.c#l2657 > [...] Thanks Manlio Perillo From manlio_perillo at libero.it Wed Feb 4 17:21:54 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 17:12:03 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A10A3.60700@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> Message-ID: <498A1502.6010801@libero.it> Manlio Perillo ha scritto: > [...] > Here is an Haskell version: > http://paste.pocoo.org/show/102801/ > > On my system it takes 30 seconds. > Sorry, I compiled without optimizations enabled. With -O2 it now runs in 20 seconds. What other optimizations should I enable? Thanks Manlio Perillo From thomas.dubuisson at gmail.com Wed Feb 4 17:25:22 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed Feb 4 17:15:27 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A1502.6010801@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <498A1502.6010801@libero.it> Message-ID: <4c44d90b0902041425p1c399394kcae6eb76325fa734@mail.gmail.com> > What other optimizations should I enable? -fexcess-precision or some such From manlio_perillo at libero.it Wed Feb 4 17:26:25 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 17:16:37 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> Message-ID: <498A1611.7090600@libero.it> Max Rabkin ha scritto: > [...] > >> Here is an Haskell version: >> http://paste.pocoo.org/show/102801/ >> >> On my system it takes 30 seconds. > > You're only dividing integers by integers to get Doubles. > > x /. y = fromIntegral x / fromIntegral y > > works just fine in this case. > No, this *does not works*. I get Nan as result, since fromIntegral a, when a is out of range of a double, returns Infinity. Prelude> (fromIntegral (fac 777)) :: Double Infinity CPython, does not try to convert to double, but, instead, to a scaled double. > --Max > Manlio Perillo From jonathanccast at fastmail.fm Wed Feb 4 17:29:29 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 4 17:19:35 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <7f22364a0902041355k54152e6tc19ff5b2541cf803@mail.gmail.com> References: <7f22364a0902041214y113213ffs7beec9e47b9991da@mail.gmail.com> <7f22364a0902041216t5fbd4d7wb3b6e0d4b0f76194@mail.gmail.com> <1233779063.6160.7.camel@jonathans-macbook> <7f22364a0902041313u2396d4d0g5d11a9e3fb1b1e1f@mail.gmail.com> <1233782521.6160.18.camel@jonathans-macbook> <7f22364a0902041355k54152e6tc19ff5b2541cf803@mail.gmail.com> Message-ID: <1233786569.6160.31.camel@jonathans-macbook> On Wed, 2009-02-04 at 23:55 +0200, Tymur Porkuian wrote: > > Huh? You can't actually over-ride function application --- Haskell's > > built-in application always does exactly the same thing, at every type. > It's a metaphor. Oh, right. That one word that means `inaccurate way of putting things'! Invoking it solves everything! I maintain that my claims were entirely accurate. I maintain your claims are in-accurate and confusing. > In every case container has its own method of > applying functions to its contents - e.g. instead of "f x" we write "x > fmap f". (NB. Typically only one of these will type-check; you know that, right?) jcc From manlio_perillo at libero.it Wed Feb 4 17:37:49 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 17:27:58 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <4c44d90b0902041425p1c399394kcae6eb76325fa734@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <498A1502.6010801@libero.it> <4c44d90b0902041425p1c399394kcae6eb76325fa734@mail.gmail.com> Message-ID: <498A18BD.9080801@libero.it> Thomas DuBuisson ha scritto: >> What other optimizations should I enable? > > -fexcess-precision or some such > There is pratically no performance gain (maybe about 1 second). Thanks Manlio Perillo From greenrd at greenrd.org Wed Feb 4 16:33:15 2009 From: greenrd at greenrd.org (Robin Green) Date: Wed Feb 4 17:46:58 2009 Subject: Reminder about hard questions about GHC (was [Haskell-cafe] Temporarily overriding Data.Generics) In-Reply-To: <7b501d5c0902041354r66d8b262g22ffd165583a3d17@mail.gmail.com> References: <7b501d5c0902041354r66d8b262g22ffd165583a3d17@mail.gmail.com> Message-ID: <20090204213315.51cba37b@greenrd.org> For low-level or obscure questions about GHC such as this, it might be better to use glasgow-haskell-users@haskell.org. There are one or two people who don't read haskell-cafe because it's so busy (and they're so busy). -- Robin On Wed, 4 Feb 2009 22:54:15 +0100 Deniz Dogan wrote: > Hi > > I'm currently working on "hacking" Data.Generics for my master thesis. > I'm basically trying to find out whether it can be made a bit faster > using e.g. rewrite rules. The problem I'm having is that I need an > easy way to import my own modified version of Data.Generics (currently > located in the same directory as my testing program) without > unregistering or hiding syb-0.1.0.0 as base seems to depend on it. > > I've read the GHC user manual trying to find nice ways to do this > using a bunch of different parameters to ghc, but I can't figure it > out. Does anyone here know? From gale at sefer.org Wed Feb 4 18:31:31 2009 From: gale at sefer.org (Yitzchak Gale) Date: Wed Feb 4 18:21:35 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A10A3.60700@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> Message-ID: <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> Manlio Perillo wrote: > However there is still a *big* problem: it is inefficient. > > Here is a Python version of the Chudnovsky algorithm [1] for computing Pi: > http://paste.pocoo.org/show/102800/ > On my system it takes 10 seconds. > Here is an Haskell version: > http://paste.pocoo.org/show/102801/ > On my system it takes 30 seconds. Ah, OK. Thanks. Now we have a well-defined problem. :) And that makes it clear that what you want is Python 3 division. Well, first of all, there are a few bugs in the Haskell version of your program - don't forget that unlike in Python, ranges in Haskell *include* the last number. Second, we should note that it is silly to compute 1000 terms in this sum. By the end, you are getting terms whose order of magnitude is 10 ^ (-15000). The Haskell version is spending a bit more time on those (useless) later terms. The reason is that in Haskell we are first reducing the fraction, then converting to Double. If you really did care about that amount of accuracy, you would leave the result as a Rational. Or as one of various other unlimited-precision floating point types that are available in Haskell libraries. This calculation in Haskell would take the same amount of time as it takes now. You would need to rewrite your Python program to do this, and I would guess it would run a lot slower. In our case, the Python division first does a quick estimate of the sizes of the two integers, and just returns zero if it sees that there will be underflow on conversion to double. So I made the following rough change to the Haskell: -- An exact division (/.) :: Integer -> Integer -> Double x /. y | y `div` x > 5*10^323 = 0 | otherwise = fromRational $ toRational x / toRational y Now the Haskell runs in about half the time as the Python on my machine. Obviously, the Haskell could easily be further optimized. -Yitz From manlio_perillo at libero.it Wed Feb 4 19:10:13 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 4 19:00:23 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> Message-ID: <498A2E65.4040805@libero.it> Yitzchak Gale ha scritto: > Manlio Perillo wrote: >> However there is still a *big* problem: it is inefficient. >> >> Here is a Python version of the Chudnovsky algorithm [1] for computing Pi: >> http://paste.pocoo.org/show/102800/ >> On my system it takes 10 seconds. >> Here is an Haskell version: >> http://paste.pocoo.org/show/102801/ >> On my system it takes 30 seconds. > > Ah, OK. Thanks. Now we have a well-defined problem. :) > Good :). > And that makes it clear that what you want is Python 3 > division. > > Well, first of all, there are a few bugs in the Haskell version > of your program - don't forget that unlike in Python, ranges > in Haskell *include* the last number. > Ah right, thanks! > Second, we should note that it is silly to compute > 1000 terms in this sum. By the end, you are getting > terms whose order of magnitude is 10 ^ (-15000). > Yes, of course. But I wrote the Python script as a response to a post on it.comp.lang.python, where an user was having overflow problems with a naive implementation of the algorithm. I have tested it with 1000 iterations just to check the raw performances. Then I tried to code it in Haskell, noting that there was no direct method for an exact division of two integer numbers. > The Haskell version is spending a bit more time on those > (useless) later terms. The reason is that in Haskell we are > first reducing the fraction, then converting to Double. If you > really did care about that amount of accuracy, you would > leave the result as a Rational. This is not possible, since there is an irrational number: c ** (3. / 2.). Moreover the sum of rational numbers is rather expensive, in this case. > [...] > In our case, the Python division first does a quick estimate > of the sizes of the two integers, and just returns zero if it > sees that there will be underflow on conversion to double. > So I made the following rough change to the Haskell: > > -- An exact division > (/.) :: Integer -> Integer -> Double > x /. y > | y `div` x > 5*10^323 = 0 > | otherwise = fromRational $ toRational x / toRational y > Right, but I would like to see a proper implemented function for exact integer division in GHC. > Now the Haskell runs in about half the time as the Python > on my machine. Obviously, the Haskell could easily be > further optimized. > > -Yitz > Thanks Manlio From jonathanccast at fastmail.fm Wed Feb 4 19:22:07 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Wed Feb 4 19:12:14 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A2E65.4040805@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> <498A2E65.4040805@libero.it> Message-ID: <1233793328.15770.2.camel@jonathans-macbook> On Thu, 2009-02-05 at 01:10 +0100, Manlio Perillo wrote: > Yitzchak Gale ha scritto: > > In our case, the Python division first does a quick estimate > > of the sizes of the two integers, and just returns zero if it > > sees that there will be underflow on conversion to double. > > So I made the following rough change to the Haskell: > > > > -- An exact division > > (/.) :: Integer -> Integer -> Double > > x /. y > > | y `div` x > 5*10^323 = 0 > > | otherwise = fromRational $ toRational x / toRational y > > > > Right, but I would like to see a proper implemented function for exact > integer division in GHC. (%) *is* a proper function for exact integer division. But you'll find plenty of Haskellers to balk at calling anything that returns a Double `proper'. jcc From lemming at henning-thielemann.de Wed Feb 4 19:22:29 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed Feb 4 19:12:33 2009 Subject: [Haskell-cafe] Re: Open unqualified imports In-Reply-To: <49898EDC.5040301@gmail.com> References: <7597366a-f280-48f3-a900-a0aad0935965@a29g2000pra.googlegroups.com> <20090119192254.GA12611@matrix.chaos.earth.li> <49898EDC.5040301@gmail.com> Message-ID: On Wed, 4 Feb 2009, Simon Marlow wrote: > Ian Lynagh wrote: >> On Fri, Jan 16, 2009 at 06:42:46AM -0800, eyal.lotem@gmail.com wrote: >>> Closed-unqualified import: >>> import Data.Map(Map, lookup) >> >> One problem with this style is that you can get lots of conflicts from >> your VCS if you have multiple people working on the same module. > > Right; in GHC we actively discourage the use of explict import lists (or > closed-unqualified import to use the terminology of this thread). > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#Imports > > I find that the reasons not to use explicit import lists outweigh the reasons > to use them, at least for code that I'm working on (rather than just > reading). > > Ideally the import lists would be maintained automatically by an IDE, and > would be intelligently handled by the VCS. This will work only if you exclusively import from modules of the same project, where you can choose identifiers to never clash, and external library modules where no functions are added anymore. Certainly for GHC this works since the compiler as basis tool must not depend on many libraries. However for me the situation is that I use many libraries, each maintained by only a few people. Within this kind of development name clashes are more likely than versioning conflicts. The only style that avoids both kinds of conflicts is the qualified import, which I try to use whereever possible. From alexander.dunlap at gmail.com Wed Feb 4 21:00:08 2009 From: alexander.dunlap at gmail.com (Alexander Dunlap) Date: Wed Feb 4 20:50:16 2009 Subject: [Haskell-cafe] Re: Open unqualified imports In-Reply-To: References: <7597366a-f280-48f3-a900-a0aad0935965@a29g2000pra.googlegroups.com> <20090119192254.GA12611@matrix.chaos.earth.li> <49898EDC.5040301@gmail.com> Message-ID: <57526e770902041800p655d6749r72496a1f2fb97c55@mail.gmail.com> On Wed, Feb 4, 2009 at 4:22 PM, Henning Thielemann wrote: > > On Wed, 4 Feb 2009, Simon Marlow wrote: > >> Ian Lynagh wrote: >>> >>> On Fri, Jan 16, 2009 at 06:42:46AM -0800, eyal.lotem@gmail.com wrote: >>>> >>>> Closed-unqualified import: >>>> import Data.Map(Map, lookup) >>> >>> One problem with this style is that you can get lots of conflicts from >>> your VCS if you have multiple people working on the same module. >> >> Right; in GHC we actively discourage the use of explict import lists (or >> closed-unqualified import to use the terminology of this thread). >> >> http://hackage.haskell.org/trac/ghc/wiki/Commentary/CodingStyle#Imports >> >> I find that the reasons not to use explicit import lists outweigh the >> reasons to use them, at least for code that I'm working on (rather than just >> reading). >> >> Ideally the import lists would be maintained automatically by an IDE, and >> would be intelligently handled by the VCS. > > This will work only if you exclusively import from modules of the same > project, where you can choose identifiers to never clash, and external > library modules where no functions are added anymore. Certainly for GHC this > works since the compiler as basis tool must not depend on many libraries. > However for me the situation is that I use many libraries, each maintained > by only a few people. Within this kind of development name clashes are more > likely than versioning conflicts. The only style that avoids both kinds of > conflicts is the qualified import, which I try to use whereever possible. Another solution would be an automated tool to add explicit import lists as part of the release process. Then you don't have to worry about maintaining them but once you do the final release, you know that it won't break if new functions are added to dependencies. Perhaps I will create such a tool sometime... Alex From ok at cs.otago.ac.nz Wed Feb 4 21:18:09 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Feb 4 21:08:16 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> Message-ID: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote: > That's a fairly common representation, seems to work for lots of > people, but it caused me no end of trouble. Values are mathematical > objects; how, I asked myself, can they possibly /be/ programs that > do IO (or actions, or computations, or )? It > doesn't make sense, says I, without reference to the rest of your message, of course values can /be/ programs. One of the fundamental insights in programming is that (all) programs are values, which, in combination with the observation that some programs exist, means that some values are programs. Indeed, in the pure lambda calculus, _everything_ is a function (= program). If you don't like it put that way, say that values can be _names for_ programs, or that values can _be treated as_ programs by interpreters. I'd rather not get too far into White Knight territory, though. From ok at cs.otago.ac.nz Wed Feb 4 21:41:27 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Feb 4 21:31:31 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A0AEA.4000104@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> Message-ID: <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> On 5 Feb 2009, at 10:38 am, Manlio Perillo wrote: > I'm looking for an exact integer division that avoids overflows, if > possible. What this sounds like to me is a request that the Prelude function 'fromRational' should work well. Since "The floating point literal f is equivalent to fromRational (n Ratio.% d), where fromRational is a method in class Fractional and Ratio.%constructs a rational from two integers, as defined in the Ratio library. The integers n and d are chosen so that n/d = f." If you cannot divide two Integers n, d accurately using (fromRational (n Ratio.% d) :: Double) that casts doubt on the trustworthiness of floating point literals. Suppose we have a function decodeIntegerAsFloat :: RealFloat a => Integer -> (Integer,a) such that if (s,m) = integer_to_scaled_float x then either x = 0 and s = 0 and m = 0 or x = m * 2**s (mathematically) and abs m \in [0.5,1.0). Then integer_ratio_as_float :: Floating a => Integer -> Integer -> a integer_ratio_as_float p q = (mp/mq)*(2.0^(sp-sq)) where (sp,mp) = decodeIntegerAsFloat p (sq,mq) = decodeIntegerAsFloat q You'd actually use scaleFloat; if the difference sp-sq is outside the range of Int the answer is going to be a signed zero or a signed infinity anyway. decodeIntegerAsFloat would sit very well in the RealFloat class alongside its model, decodeFloat. It has other uses. For example, you can use it to compute logarithms of Integers with much less worry about overflow. From barkmadley at gmail.com Wed Feb 4 22:09:33 2009 From: barkmadley at gmail.com (Mark Bradley) Date: Wed Feb 4 21:59:38 2009 Subject: [Haskell-cafe] pure crisis :) In-Reply-To: <4989B9BB.8070502@ropine.com> References: <593855719.20090201221918@gmail.com> <4989B9BB.8070502@ropine.com> Message-ID: On Thu, Feb 5, 2009 at 2:52 AM, Seth Gordon wrote: > Bulat Ziganshin wrote: >> >> Hello haskell-cafe, >> >> pure functional denotation for crisis: >> >> (_|_) >> > > Buy ?, sell ?! so you're saying the T industry is going to be the next growth industry? -markb > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From vigalchin at gmail.com Wed Feb 4 23:47:47 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Wed Feb 4 23:37:50 2009 Subject: [Haskell-cafe] darcs send errors that I don't understand .... Message-ID: <5ae4f2ba0902042047p4151f63bi9f013487d51cae16@mail.gmail.com> Shall I send this patch? (1/1) [ynWvpxqadjk], or ? for help: y Error in execvp: No such file or directory darcs: timer_settime: Invalid argument Failed to execute external command: /usr/sbin/sendmail -i -t Lowlevel error: execvp: Illegal seek Redirects: (File "/home/vigalchin/FTP/Ketil/biolib/darcsOuDSC9",Null,AsIs) Can anybody help me on the errors above? (The /usr/sbin/sendmail I think I understand ... probably haven't set up sendmail yet). Kind regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090204/22ce9e2a/attachment.htm From DekuDekuplex at Yahoo.com Thu Feb 5 00:38:10 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Thu Feb 5 00:28:24 2009 Subject: [Haskell-cafe] Re: Monad explanation References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> Message-ID: On Thu, 5 Feb 2009 15:18:09 +1300, "Richard O'Keefe" wrote: > >On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote: >> That's a fairly common representation, seems to work for lots of >> people, but it caused me no end of trouble. Values are mathematical >> objects; how, I asked myself, can they possibly /be/ programs that >> do IO (or actions, or computations, or )? It >> doesn't make sense, says I, > >without reference to the rest of your message, of course values can /be/ >programs. One of the fundamental insights in programming is that >(all) programs are values, which, in combination with the observation >that some programs exist, means that some values are programs. >Indeed, in the pure lambda calculus, _everything_ is a function (= >program). Indeed. Perhaps at least part of this confusion is caused by a difference in style of thinking between the functional and imperative programming paradigms; in functional programming, functions are first-class values, so they are treated just like any other values. Therefore, functional programs are values. This style of thinking contrasts with that of imperative programming, where programs are typically considered to be composed of statements which change global state when executed (see "Functional programming - HaskellWiki: 1 What is functional programming?" at http://www.haskell.org/haskellwiki/Functional_programming#What_is_functional_programming.3F . > >If you don't like it put that way, say that values can be _names for_ >programs, or that values can _be treated as_ programs by interpreters. >I'd rather not get too far into White Knight territory, though. Actually, I have a question myself on this issue. I had intended to give an example of a self-referential program that modifies itself to illustrate programs as first-class values, but then I just discovered that it seems that Haskell doesn't support reflection (see http://en.wikipedia.org/wiki/Reflection_(computer_science)). In particular, I just came across the following archived post in Haskell-Cafe, "Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.," dated "Mon, 18 Jun 2007 14:05:53 -0700" (see http://www.mail-archive.com/haskell-cafe@haskell.org/msg25257.html), in which Pasqualino 'Titto' Assini wrote as follows: >Most languages, even Java, have a reflection capability to dynamically inspect >an object. It is surprising that Haskell doesn't offer it. In the same thread, Claus Reinke, in his response, dated "Mon, 18 Jun 2007 15:45:50 -0700" (see http://www.mail-archive.com/haskell-cafe@haskell.org/msg25270.html), wrote as follows: >>Most languages, even Java, have a reflection capability to dynamically inspect >>an object. It is surprising that Haskell doesn't offer it. > >it has to be done with care, or it will invalidate *all* your nice reasoning >about haskell programs. random example > >reify (f . g) == [| f . g |] =/= [| \x-> f (g x) |] == reify (\x-> f (g x)) I tried looking up "self-reference" on HaskellWiki, but my search did not result in any hits. Is it possible to write a self-referential function in Haskell that modifies itself? My intuition is that this would violate referential transparency, so it is probably not possible, but as long as the program is only allowed to reference itself without actually modifying itself, then there should be a way. Alternatively, it should be possible for a Haskell program to create a copy of itself, and then to modify that copy, as long as referential transparency is not violated. To what extent are self-reference and reflection supported n Haskell? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From max.rabkin at gmail.com Thu Feb 5 00:43:04 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Thu Feb 5 00:33:07 2009 Subject: [Haskell-cafe] Re: Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> Message-ID: On Wed, Feb 4, 2009 at 9:38 PM, Benjamin L. Russell wrote: > Is it possible to write a self-referential function in Haskell that > modifies itself? Is it possible to write *any* kind of function in Haskell that modifies *anything*? --Max From magnus at therning.org Thu Feb 5 02:52:46 2009 From: magnus at therning.org (Magnus Therning) Date: Thu Feb 5 02:42:50 2009 Subject: [Haskell-cafe] darcs send errors that I don't understand .... In-Reply-To: <5ae4f2ba0902042047p4151f63bi9f013487d51cae16@mail.gmail.com> References: <5ae4f2ba0902042047p4151f63bi9f013487d51cae16@mail.gmail.com> Message-ID: 2009/2/5 Galchin, Vasili : > Shall I send this patch? (1/1) [ynWvpxqadjk], or ? for help: y > Error in execvp: No such file or directory > darcs: timer_settime: Invalid argument > Failed to execute external command: /usr/sbin/sendmail -i -t > Lowlevel error: execvp: Illegal seek > Redirects: (File "/home/vigalchin/FTP/Ketil/biolib/darcsOuDSC9",Null,AsIs) > > Can anybody help me on the errors above? (The /usr/sbin/sendmail I think I > understand ... probably haven't set up sendmail yet). What kind of system are you using? To me it looks like you haven't set up any mailserver, most mail servers come with a tool named 'sendmail' simply because there are a lot of programs that depend on it. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus identi.ca|twitter: magthe From DekuDekuplex at Yahoo.com Thu Feb 5 04:38:33 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Thu Feb 5 04:28:52 2009 Subject: [Haskell-cafe] Re: Monad explanation References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> Message-ID: On Wed, 4 Feb 2009 21:43:04 -0800, Max Rabkin wrote: >On Wed, Feb 4, 2009 at 9:38 PM, Benjamin L. Russell > wrote: >> Is it possible to write a self-referential function in Haskell that >> modifies itself? > >Is it possible to write *any* kind of function in Haskell that >modifies *anything*? While trying to research this issue, I came across a relevant archived thread in Haskell-Cafe, entitled "[Haskell-cafe] haskell and reflection," started by Greg Meredith, dated "Tue, 11 Sep 2007 07:09:22 -0700" (see http://www.mail-archive.com/haskell-cafe@haskell.org/msg29882.html), which at first had me worried. Specifically, Greg wrote as follows: >Am i wrong in my assessment that the vast majority of reflective machinery >is missing from Haskell? Specifically, > > - there is no runtime representation of type available for > programmatic representation > - there is no runtime representation of the type-inferencing or > checking machinery > - there is no runtime representation of the evaluation machinery > - there is no runtime representation of the lexical or parsing > machinery However, I was somewhat relieved to find that Haskell apparently does support, in at least one GHC extension to Haskell, a limited form of reflection. In the same thread, Reinier Lamers, in his response, dated "Tue, 11 Sep 2007 13:08:38 -0700" (see http://www.mail-archive.com/haskell-cafe@haskell.org/msg29898.html), wrote as follows: >Op 11-sep-2007, om 18:43 heeft Greg Meredith het volgende geschreven: > >[...] > >Template Haskell [1] is a system that lets you write programs that get >executed at *compile time*, and that produce parts of the Haskell program >to be compiled by manipulating a representation of the program as structured >data. It's a form of reflection restricted to compile time, if you'd ask me. > >[...] > >[1] http://www.haskell.org/haskellwiki/Template_Haskell According to the site referenced by the above-mentioned link, >Template Haskell is an extension to Haskell 98 that allows you to do type-safe >compile-time meta-programming, with Haskell both as the manipulating language >and the language being manipulated. This site is even referenced on the site for "The Meta-Programming Project" (see http://www.infosun.fim.uni-passau.de/cl/metaprog/index.php3), as follows: >Languages which we are using for meta-programming > > * Template Haskell, permits analysis of object programs Additionally, Don Stewart, in an earlier post in the same thread, dated "Thu, 13 Sep 2007 11:36:11 -0700" (see http://www.mail-archive.com/haskell-cafe@haskell.org/msg30009.html), wrote as follows: >lgreg.meredith: >> Haskellians, >> >> Am i wrong in my assessment that the vast majority of reflective machinery >> is missing from Haskell? Specifically, >> >> * there is no runtime representation of type available for programmatic >> representation > >> * there is no runtime representation of the type-inferencing or checking >> machinery > >> * there is no runtime representation of the evaluation machinery > >> * there is no runtime representation of the lexical or parsing machinery > >So there is library support for all of this, in various forms: > > * lexer, parser, type checker, evaluator: > ghc-api > hs-plugins > > * lexer, parser, pretty printer > many parser libs (Language.Haskell, Template Haskell) > > * runtime type representation > Data.Typeable > > * reflecting code to data: > Data.Generics As a sidenote, I discovered an interesting post and associated paper by Lauri Alanko, who in a post in the same thread, dated "Tue, 11 Sep 2007 10:12:09 -0700" (see http://www.mail-archive.com/haskell-cafe@haskell.org/msg29895.html), responded that while both structural and procedural reflection are possible in Haskell, because of static typing, type safety is nevertheless an issue: >On Tue, Sep 11, 2007 at 07:33:54AM -0700, Greg Meredith wrote: >> Our analysis suggested the following breakdown >> >> - Structural reflection -- all data used in the evaluation of programs >> has a programmatic representation >> - Procedural reflection -- all execution machinery used in the >> evaluation of programs has a programmatic representation >> >>[...] > >As for Haskell, there are various tools for both (at least >Data.Typeable and hs-plugins), but neither are truly type-safe: it is >possible to write code that uses these libraries and type-checks, yet >crashes. Static typing makes reflection very difficult to support >safely. >You might be interested in my MS thesis, where I explored these issues >in some more length: >http://www.cs.helsinki.fi/u/lealanko/alanko04types.pdf This thesis is entitled "Types and Reflection" (see the above-mentioned URL), and summarizes the problem as follows (see p. 1): >This thesis is about reflection in typed programming languages. The central >idea of this work, the thesis proper, can be summarized in three points: >. Typed reflection is a good thing. >. It has not yet been done properly. >. It is nevertheless possible. The basic problem with reflection in a statically typed language seems to be that "reflection wreaks havoc to the basic assumptions that type systems are based on" (see p. 11). Specifically, he explains as follows (see p. 38): >[A] type system verifies or infers universal properties about all >possible executions of a program by making a context-sensitive syntactic analysis of the >program?s structure. Usually this is possible because the computational rules for executing >the program are simple, tractable and most importantly syntax-directed: the evaluation >of each expression proceeds in a predictable fashion that is determined mostly by its syntactic >form and only to a limited extent by run-time state. For each expression there are >certain invariants that always hold for its evaluation, and these invariants can be expressed >in the expression?s type. > >In practice this means that we can prove the soundness of a type system with structural >induction over the terms, using the dynamic semantics of the language to show that the >evaluation of each expression will yield a well-typed result. > >In the presence of reflective operations this mode of reasoning no longer works. The >reason is that the effects of all primitive expressions on computational structures are no >longer simple and tractable: an absorption operation turns an arbitrary run-time value >into a computational structure, and there are therefore no simple invariants about the >operation?s behavior. > >This is of course an inherent property of reflection. Its idea, after all, is to allow the >program more freedom at run-time instead of completely predefining its behavior when >the program is written. Yet it is still a rarely used feature and it seems unreasonable that it >should make static typing completely unattainable. Thankfully, this proves not to be the >case. In Greg Meredith's solution, he writes as follows (see p. 42): >[T]here is a tradeoff to be made between static safety and dynamic flexibility. >It turns out that it is possible to do quite sophisticated run-time code manipulation while >still retaining fully static safety guarantees both of the original code and the generated >code. In Section 8.3: "Dynamics in Haskell," Meredith elucidates as follows (see p. 62): >The language Haskell [H98] has a powerful type system, but the standard version of the >language has no support for run-time type operations. However, there is a dynamics >library that has for a long time been included in many implementations [LPJ03, Section >8]. The library provides a datatype Dynamic and some machinery for injecting values >of different types into it and for extracting them out from it. Unfortunately, the user >of the library is required to obey certain programming conventions, and if they are not >followed, it is very easy to write code that breaks type safety. Moreover, the library >provides only limited support for dynamics. For instance, it is not possible to inject >polymorphic functions into a Dynamic. > >More recently, Cheney and Hinze [CH02a] and Baars and Swierstra [BS02] have developed >more flexible and type-safe frameworks for representing type information at runtime >in Haskell. In fact, dynamic values are only one of the possible applications of the >frameworks. Cheney and Hinze's system is then described in more detail. Meredith then concludes as follows (see p. 63): >The above system is quite remarkable. The type Rep [tau] bridges the gap between static and >dynamic type information while remaining completely type-safe even internally. Indeed, >the type representations are very much like reified types. They can be synthesized and >analyzed, and the isomorphisms allow a kind of absorption: conversion from run-time to >compile-time type information. Some problems relating to the need for programmer cooperation, the treatment of new named datatypes, and lack of full reflexivity are then described. Nevertheless, Meredith summarizes as follows (see p. 64): >Nevertheless, these "lightweight dynamics" are surprisingly powerful, considering that >they can be implemented in a statically typed language without extending the type system. >For example, Baars and Swierstra demonstrate how to write a type-safe eval function for a >simple language so that all type checking is done before the code is evaluated. Although >this is not full reflection due to the simplicity of the object language, the result is still >encouraging. For one thing, at least now a type can be pretty-printed even without the >presence of a value of that type. Apparently, there is hope for reflection in Haskell with such libraries. What would be especially interesting would be a specific example of a type-safe Haskell program that could modify itself at runtime. If anyone has any examples to cite, I would be very interested in reading about them in this thread. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From g9ks157k at acme.softbase.org Thu Feb 5 04:41:20 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 5 04:31:40 2009 Subject: [Haskell-cafe] build problems on Hackage Message-ID: <200902051041.20937.g9ks157k@acme.softbase.org> Hello all, alas, I couldn?t found any information about who is responsible for the build system on Hackage. So I address this issue to all of you. type-level built fine with GHC 6.8 but failed to build with GHC 6.10. The last line of the build log is this: > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing The complete log is at . This problem has the unfortunate consequence that type-equality-check cannot be built since it depends on type-level and nowadays only GHC 6.10 seems to be used for building packages on Hackage. This, in turn, will make almost all Grapefruit packages unbuildable when they are released (which is expected to happen soon). This, in turn, means almost no Grapefruit documentation on Hackage which, I think, would be very bad. So could someone please take the time and fix this problem soon? Thank you in advance. Best wishes, Wolfgang From dmehrtash at gmail.com Thu Feb 5 05:23:45 2009 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Thu Feb 5 05:13:48 2009 Subject: [Haskell-cafe] Re: Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> Message-ID: Can someone compare/contrast functions and computation? thanks daryoush On Thu, Feb 5, 2009 at 1:38 AM, Benjamin L. Russell wrote: > On Wed, 4 Feb 2009 21:43:04 -0800, Max Rabkin > wrote: > > >On Wed, Feb 4, 2009 at 9:38 PM, Benjamin L. Russell > > wrote: > >> Is it possible to write a self-referential function in Haskell that > >> modifies itself? > > > >Is it possible to write *any* kind of function in Haskell that > >modifies *anything*? > > While trying to research this issue, I came across a relevant archived > thread in Haskell-Cafe, entitled "[Haskell-cafe] haskell and > reflection," started by Greg Meredith, dated "Tue, 11 Sep 2007 > 07:09:22 -0700" (see > http://www.mail-archive.com/haskell-cafe@haskell.org/msg29882.html), > which at first had me worried. Specifically, Greg wrote as follows: > > >Am i wrong in my assessment that the vast majority of reflective machinery > >is missing from Haskell? Specifically, > > > > - there is no runtime representation of type available for > > programmatic representation > > - there is no runtime representation of the type-inferencing or > > checking machinery > > - there is no runtime representation of the evaluation machinery > > - there is no runtime representation of the lexical or parsing > > machinery > > However, I was somewhat relieved to find that Haskell apparently does > support, in at least one GHC extension to Haskell, a limited form of > reflection. In the same thread, Reinier Lamers, in his response, > dated "Tue, 11 Sep 2007 13:08:38 -0700" (see > http://www.mail-archive.com/haskell-cafe@haskell.org/msg29898.html), > wrote as follows: > > >Op 11-sep-2007, om 18:43 heeft Greg Meredith het volgende geschreven: > > > >[...] > > > >Template Haskell [1] is a system that lets you write programs that get > >executed at *compile time*, and that produce parts of the Haskell program > >to be compiled by manipulating a representation of the program as > structured > >data. It's a form of reflection restricted to compile time, if you'd ask > me. > > > >[...] > > > >[1] http://www.haskell.org/haskellwiki/Template_Haskell > > According to the site referenced by the above-mentioned link, > > >Template Haskell is an extension to Haskell 98 that allows you to do > type-safe > >compile-time meta-programming, with Haskell both as the manipulating > language > >and the language being manipulated. > > This site is even referenced on the site for "The Meta-Programming > Project" (see > http://www.infosun.fim.uni-passau.de/cl/metaprog/index.php3), as > follows: > > >Languages which we are using for meta-programming > > > > * Template Haskell, permits analysis of object programs > > Additionally, Don Stewart, in an earlier post in the same thread, > dated "Thu, 13 Sep 2007 11:36:11 -0700" (see > http://www.mail-archive.com/haskell-cafe@haskell.org/msg30009.html), > wrote as follows: > > >lgreg.meredith: > >> Haskellians, > >> > >> Am i wrong in my assessment that the vast majority of reflective > machinery > >> is missing from Haskell? Specifically, > >> > >> * there is no runtime representation of type available for > programmatic > >> representation > > > >> * there is no runtime representation of the type-inferencing or > checking > >> machinery > > > >> * there is no runtime representation of the evaluation machinery > > > >> * there is no runtime representation of the lexical or parsing > machinery > > > >So there is library support for all of this, in various forms: > > > > * lexer, parser, type checker, evaluator: > > ghc-api > > hs-plugins > > > > * lexer, parser, pretty printer > > many parser libs (Language.Haskell, Template Haskell) > > > > * runtime type representation > > Data.Typeable > > > > * reflecting code to data: > > Data.Generics > > As a sidenote, I discovered an interesting post and associated paper > by Lauri Alanko, who in a post in the same thread, dated "Tue, 11 Sep > 2007 10:12:09 -0700" (see > http://www.mail-archive.com/haskell-cafe@haskell.org/msg29895.html), > responded that while both structural and procedural reflection are > possible in Haskell, because of static typing, type safety is > nevertheless an issue: > > >On Tue, Sep 11, 2007 at 07:33:54AM -0700, Greg Meredith wrote: > >> Our analysis suggested the following breakdown > >> > >> - Structural reflection -- all data used in the evaluation of > programs > >> has a programmatic representation > >> - Procedural reflection -- all execution machinery used in the > >> evaluation of programs has a programmatic representation > >> > >>[...] > > > >As for Haskell, there are various tools for both (at least > >Data.Typeable and hs-plugins), but neither are truly type-safe: it is > >possible to write code that uses these libraries and type-checks, yet > >crashes. Static typing makes reflection very difficult to support > >safely. > > >You might be interested in my MS thesis, where I explored these issues > >in some more length: > >http://www.cs.helsinki.fi/u/lealanko/alanko04types.pdf > > This thesis is entitled "Types and Reflection" (see the > above-mentioned URL), and summarizes the problem as follows (see p. > 1): > > >This thesis is about reflection in typed programming languages. The > central > >idea of this work, the thesis proper, can be summarized in three points: > >. Typed reflection is a good thing. > >. It has not yet been done properly. > >. It is nevertheless possible. > > The basic problem with reflection in a statically typed language seems > to be that "reflection wreaks havoc to the basic assumptions that type > systems are based on" (see p. 11). Specifically, he explains as > follows (see p. 38): > > >[A] type system verifies or infers universal properties about all > >possible executions of a program by making a context-sensitive syntactic > analysis of the > >program's structure. Usually this is possible because the computational > rules for executing > >the program are simple, tractable and most importantly syntax-directed: > the evaluation > >of each expression proceeds in a predictable fashion that is determined > mostly by its syntactic > >form and only to a limited extent by run-time state. For each expression > there are > >certain invariants that always hold for its evaluation, and these > invariants can be expressed > >in the expression's type. > > > >In practice this means that we can prove the soundness of a type system > with structural > >induction over the terms, using the dynamic semantics of the language to > show that the > >evaluation of each expression will yield a well-typed result. > > > >In the presence of reflective operations this mode of reasoning no longer > works. The > >reason is that the effects of all primitive expressions on computational > structures are no > >longer simple and tractable: an absorption operation turns an arbitrary > run-time value > >into a computational structure, and there are therefore no simple > invariants about the > >operation's behavior. > > > >This is of course an inherent property of reflection. Its idea, after all, > is to allow the > >program more freedom at run-time instead of completely predefining its > behavior when > >the program is written. Yet it is still a rarely used feature and it seems > unreasonable that it > >should make static typing completely unattainable. Thankfully, this proves > not to be the > >case. > > In Greg Meredith's solution, he writes as follows (see p. 42): > > >[T]here is a tradeoff to be made between static safety and dynamic > flexibility. > >It turns out that it is possible to do quite sophisticated run-time code > manipulation while > >still retaining fully static safety guarantees both of the original code > and the generated > >code. > > In Section 8.3: "Dynamics in Haskell," Meredith elucidates as follows > (see p. 62): > > >The language Haskell [H98] has a powerful type system, but the standard > version of the > >language has no support for run-time type operations. However, there is a > dynamics > >library that has for a long time been included in many implementations > [LPJ03, Section > >8]. The library provides a datatype Dynamic and some machinery for > injecting values > >of different types into it and for extracting them out from it. > Unfortunately, the user > >of the library is required to obey certain programming conventions, and if > they are not > >followed, it is very easy to write code that breaks type safety. Moreover, > the library > >provides only limited support for dynamics. For instance, it is not > possible to inject > >polymorphic functions into a Dynamic. > > > >More recently, Cheney and Hinze [CH02a] and Baars and Swierstra [BS02] > have developed > >more flexible and type-safe frameworks for representing type information > at runtime > >in Haskell. In fact, dynamic values are only one of the possible > applications of the > >frameworks. > > Cheney and Hinze's system is then described in more detail. Meredith > then concludes as follows (see p. 63): > > >The above system is quite remarkable. The type Rep [tau] bridges the gap > between static and > >dynamic type information while remaining completely type-safe even > internally. Indeed, > >the type representations are very much like reified types. They can be > synthesized and > >analyzed, and the isomorphisms allow a kind of absorption: conversion from > run-time to > >compile-time type information. > > Some problems relating to the need for programmer cooperation, the > treatment of new named datatypes, and lack of full reflexivity are > then described. Nevertheless, Meredith summarizes as follows (see p. > 64): > > >Nevertheless, these "lightweight dynamics" are surprisingly powerful, > considering that > >they can be implemented in a statically typed language without extending > the type system. > >For example, Baars and Swierstra demonstrate how to write a type-safe eval > function for a > >simple language so that all type checking is done before the code is > evaluated. Although > >this is not full reflection due to the simplicity of the object language, > the result is still > >encouraging. For one thing, at least now a type can be pretty-printed even > without the > >presence of a value of that type. > > Apparently, there is hope for reflection in Haskell with such > libraries. > > What would be especially interesting would be a specific example of a > type-safe Haskell program that could modify itself at runtime. If > anyone has any examples to cite, I would be very interested in reading > about them in this thread. > > -- Benjamin L. Russell > -- > Benjamin L. Russell / DekuDekuplex at Yahoo dot com > http://dekudekuplex.wordpress.com/ > Translator/Interpreter/ Mobile: +011 81 80-3603-6725 > "Furuike ya, kawazu tobikomu mizu no oto." > -- Matsuo Basho^ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/4d35e324/attachment.htm From bugfact at gmail.com Thu Feb 5 05:43:52 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 5 05:33:55 2009 Subject: [Haskell-cafe] Crash using GHCi and GHC API under Windows Message-ID: We have a program that uses the GHC API to dynamically compile and run new code. We're using GHC 6.10.1 Under GHCi it works fine under OSX, but when running it on Windows, I get Loading package ghc-prim ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol _hs_gtWord64 whilst processing object file C:\app\ghc-6.10.1\ghc-prim-0.1.0.0\HSghc-prim-0.1.0.0.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. When compiling the program using GHC --make, it runs fine Is this a know issue? Other people encountered this? Thanks, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/1ce5da45/attachment.htm From manlio_perillo at libero.it Thu Feb 5 05:45:45 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Feb 5 05:35:59 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <1233793328.15770.2.camel@jonathans-macbook> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> <498A2E65.4040805@libero.it> <1233793328.15770.2.camel@jonathans-macbook> Message-ID: <498AC359.4060109@libero.it> Jonathan Cast ha scritto: > On Thu, 2009-02-05 at 01:10 +0100, Manlio Perillo wrote: >> Yitzchak Gale ha scritto: >>> In our case, the Python division first does a quick estimate >>> of the sizes of the two integers, and just returns zero if it >>> sees that there will be underflow on conversion to double. >>> So I made the following rough change to the Haskell: >>> >>> -- An exact division >>> (/.) :: Integer -> Integer -> Double >>> x /. y >>> | y `div` x > 5*10^323 = 0 >>> | otherwise = fromRational $ toRational x / toRational y >>> >> Right, but I would like to see a proper implemented function for exact >> integer division in GHC. > > (%) *is* a proper function for exact integer division. But you'll find > plenty of Haskellers to balk at calling anything that returns a Double > `proper'. > After a quick search I found the function fromRat in GHC.Float, that implement the division of two big integer returning a floating point number. However it only supports rationals, and with rational there is a performance problem caused by fraction reduction. I would like to do some test with fraction reduction disabled, but right now I don't have the time. Regards Manlio Perillo From manlio_perillo at libero.it Thu Feb 5 05:51:03 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Feb 5 05:41:15 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> Message-ID: <498AC497.5080907@libero.it> Richard O'Keefe ha scritto: > > On 5 Feb 2009, at 10:38 am, Manlio Perillo wrote: >> I'm looking for an exact integer division that avoids overflows, if >> possible. > > What this sounds like to me is a request that the Prelude > function 'fromRational' should work well. Just found that it actually works well, with Ratio Integer. There is a specialized function in GHC.Float that does the right job. > [...] > You'd actually use scaleFloat; if the difference sp-sq is outside > the range of Int the answer is going to be a signed zero or a signed > infinity anyway. decodeIntegerAsFloat would sit very well in the > RealFloat class alongside its model, decodeFloat. It has other uses. > For example, you can use it to compute logarithms of Integers with > much less worry about overflow. > By the way, in GHC.Float there is a (private): -- Compute the (floor of the) log of i in base b. -- Simplest way would be just divide i by b until it's smaller then b, -- but that would be very slow! We are just slightly more clever. integerLogBase :: Integer -> Integer -> Int Regards Manlio Perillo From gale at sefer.org Thu Feb 5 05:52:11 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 5 05:42:17 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> Message-ID: <2608b8a80902050252q2bbdc192oe5668b5053634e8b@mail.gmail.com> Manlio Perillo wrote: >> I'm looking for an exact integer division that avoids overflows, if >> possible. Richard O'Keefe wrote: > What this sounds like to me is a request that the Prelude > function 'fromRational' should work well... > If you cannot divide two Integers n, d accurately using > (fromRational (n Ratio.% d) :: Double) > that casts doubt on the trustworthiness of floating point literals. No, that works fine: Prelude Data.Ratio> fromRational $ (3*10^1000)%(2*10^1000+1) 1.5 > Suppose we have a function > decodeIntegerAsFloat :: RealFloat a => Integer -> (Integer,a) > such that if (s,m) = decodeIntegerAsFloat x > then either x = 0 and s = 0 and m = 0 > or x = m * 2**s (mathematically) and abs m \in [0.5,1.0). Yes, that is what Manlio wants. Sometimes you need to divide two very large Integers with a floating point number as result, without the overhead of constructing a Rational from them. > Then > integer_ratio_as_float :: Floating a => Integer -> Integer -> a > integer_ratio_as_float p q = (mp/mq)*(2.0^(sp-sq)) > where (sp,mp) = decodeIntegerAsFloat p > (sq,mq) = decodeIntegerAsFloat q > > You'd actually use scaleFloat; if the difference sp-sq is outside > the range of Int the answer is going to be a signed zero or a signed > infinity anyway. You have just duplicated the CPython interpreter source code snippet that Manlio linked to. > decodeIntegerAsFloat would sit very well in the > RealFloat class alongside its model, decodeFloat. It has other uses. I agree, though I'm not sure it needs to be a method. > For example, you can use it to compute logarithms of Integers with > much less worry about overflow. Actually, efficient integer-valued logarithms for Integers are exactly what you need to implement decodeIntegerAsFloat. Best would be if we could just read that off from the internal representation of an Integer. Would you like to file a GHC issue for that? In the meantime, we could already expose the integer log function in a library using an efficient algorithm. Thanks, Yitz From ndmitchell at gmail.com Thu Feb 5 05:55:32 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 5 05:45:36 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! In-Reply-To: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> References: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> Message-ID: <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> Hi Successor as in Happstack replaces HAppS entirely and all projects implemented in HAppS should aim to port to Happstack - or successor as in builds on the ideas in HAppS? Is HAppS now deprecated? Thanks Neil 2009/2/4 Matthew Elder : > Hello Haskell Cafe, > > I just wanted to inform you that the Happstack project has shipped it's 0.1 > release. For those of you who don't know, Happstack is the successor for the > HAppS project. More details on the release can be found at > http://blog.happstack.com/2009/02/03/happstack-01-released . > > Thanks for your time, > Matthew Elder > -- > Need somewhere to put your code? http://patch-tag.com > Want to build a webapp? http://happstack.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From gale at sefer.org Thu Feb 5 06:01:09 2009 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 5 05:51:11 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498AC497.5080907@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> <498AC497.5080907@libero.it> Message-ID: <2608b8a80902050301r50de8ea8pa41685979e1b6dfc@mail.gmail.com> Manlio Perillo wrote: > By the way, in GHC.Float there is a (private): > integerLogBase :: Integer -> Integer -> Int Yes, I have needed this function many times. Too bad it is not exposed. In this case, though, we only need base 2. For that, it would be nice if we could just read it directly from the internal representation of the Integer. -Yitz From simonpj at microsoft.com Thu Feb 5 06:09:09 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 5 05:56:31 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902050301r50de8ea8pa41685979e1b6dfc@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> <498AC497.5080907@libero.it> <2608b8a80902050301r50de8ea8pa41685979e1b6dfc@mail.gmail.com> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328C91CD4D@EA-EXMSG-C334.europe.corp.microsoft.com> | Manlio Perillo wrote: | > By the way, in GHC.Float there is a (private): | > integerLogBase :: Integer -> Integer -> Int | | Yes, I have needed this function many times. | Too bad it is not exposed. So use the libraries process to propose exposing it! Simon From temp.tsun at gmail.com Thu Feb 5 06:37:22 2009 From: temp.tsun at gmail.com (Tsunkiet Man) Date: Thu Feb 5 06:27:26 2009 Subject: [Haskell-cafe] Define variable types Message-ID: Hello, I'm new to Haskell and it seems like a very nice language to learn. However I'm not really familiar with the errormessages it produces. I am using a Helium interpreter. I've created the following module (however it is just a small sketch). I've written the following code: fac :: Int -> Int fac n = product[1..n] boven :: Int -> Int -> Int boven n k = (fac n) `div` fac k * fac (n-k) bin :: Int -> Int -> Int -> Int bin n k p |(n-k)>0 && k>0 = (boven n k) * (p^k) * (1-p)^(n-k) |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * (1/((1-p)^(-(n-k)))) When I load this into my interpreter it says: Compiling ./Test.hs (11,55): Type error in infix application expression : 1 / ((1 - p) ^ (-(n - k))) operator : / type : Float -> Float -> Float does not match : Int -> Int -> Int (12,47): Type error in infix application expression : 1 / (p ^ (-k)) operator : / type : Float -> Float -> Float does not match : Int -> Int -> a (12,62): Type error in infix application expression : 1 / ((1 - p) ^ (-(n - k))) operator : / type : Float -> Float -> Float does not match : Int -> Int -> a Compilation failed with 3 errors Some details that might be usefull: Line 11 is |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) Line 12 is |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * (1/((1-p)^(-(n-k)))) So my question is: how can I fix these errors? (I used these lines of codes because it is not possible to use a negative exponent in the Helium interpreter.) Thank you for answering my question! Greetings JTKM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/d7ab59f9/attachment.htm From manlio_perillo at libero.it Thu Feb 5 06:40:49 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Thu Feb 5 06:31:02 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902050252q2bbdc192oe5668b5053634e8b@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> <2608b8a80902050252q2bbdc192oe5668b5053634e8b@mail.gmail.com> Message-ID: <498AD041.1070200@libero.it> Yitzchak Gale ha scritto: > [...] > >> Suppose we have a function >> decodeIntegerAsFloat :: RealFloat a => Integer -> (Integer,a) >> such that if (s,m) = decodeIntegerAsFloat x >> then either x = 0 and s = 0 and m = 0 >> or x = m * 2**s (mathematically) and abs m \in [0.5,1.0). > > Yes, that is what Manlio wants. Sometimes you need to divide > two very large Integers with a floating point number as result, > without the overhead of constructing a Rational from them. > By the way: it is possible to use a private constructor (via some special GHC flag?). I would like to do a quick performance check using the existing fromRational specialization by constructing a Rational directly. I know that Haskell allows declaration hiding for program safety, but sometimes this can be a nuisance. > [...] Thanks Manlio Perillo From roma at ro-che.info Thu Feb 5 06:57:50 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu Feb 5 06:47:57 2009 Subject: [Haskell-cafe] Define variable types In-Reply-To: References: Message-ID: <20090205115750.GA28405@flit> * Tsunkiet Man [2009-02-05 12:37:22+0100] > Hello, > > I'm new to Haskell and it seems like a very nice language to learn. However > I'm not really familiar with the errormessages it produces. I am using a > Helium interpreter. I've created the following module (however it is just a > small sketch). I've written the following code: > > fac :: Int -> Int > fac n = product[1..n] > > boven :: Int -> Int -> Int > boven n k = (fac n) `div` fac k * fac (n-k) > > bin :: Int -> Int -> Int -> Int > bin n k p |(n-k)>0 && k>0 = (boven n k) * (p^k) * (1-p)^(n-k) > |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > (1/((1-p)^(-(n-k)))) > > When I load this into my interpreter it says: > > Compiling ./Test.hs > (11,55): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> Int > (12,47): Type error in infix application > expression : 1 / (p ^ (-k)) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a > (12,62): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a You can't use fractional division (/) with integers. You can convert integers to fractions using fromIntegral. E.g.: 1 / fromIntegral ((1 - p) ^ (-(n - k))) (literals like 1 doesn't need to be converted because they are polymorphic) -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From daniel.is.fischer at web.de Thu Feb 5 07:16:00 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Thu Feb 5 07:03:28 2009 Subject: [Haskell-cafe] Define variable types In-Reply-To: References: Message-ID: <200902051316.00758.daniel.is.fischer@web.de> Am Donnerstag, 5. Februar 2009 12:37 schrieb Tsunkiet Man: > Hello, > > I'm new to Haskell and it seems like a very nice language to learn. However > I'm not really familiar with the errormessages it produces. I am using a > Helium interpreter. I've created the following module (however it is just a > small sketch). I've written the following code: > > fac :: Int -> Int > fac n = product[1..n] > > boven :: Int -> Int -> Int > boven n k = (fac n) `div` fac k * fac (n-k) You want parentheses there: boven n k = fac n `div` (fac k * fac (n-k)) > > bin :: Int -> Int -> Int -> Int > bin n k p |(n-k)>0 && k>0 = (boven n k) * (p^k) * (1-p)^(n-k) > > |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > > (1/((1-p)^(-(n-k)))) > > When I load this into my interpreter it says: > > Compiling ./Test.hs > (11,55): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> Int > (12,47): Type error in infix application > expression : 1 / (p ^ (-k)) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a > (12,62): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a > Compilation failed with 3 errors > > Some details that might be usefull: > > Line 11 is |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > Line 12 is |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > (1/((1-p)^(-(n-k)))) > > So my question is: how can I fix these errors? Haskell doesn't do automatic type conversion, so you have to explicitly convert from one numerical type to another. Ints can only be divided using div (or quot), not by (/) which is the division operator of Fractional types (Float, Double, Rational...). However, I'm rather convinced the type signature you gave for bin is not what you want, I think p should be a floating point number, as should the resulting probability. That would give the type signature bin :: Int -> Int -> Float -> Float and the use of (/) is then legitimate. But you then must convert the binomial coefficient to a floating point number to be able to multiply it: bin n k p = fromIntegral (boven n k) * p^^k * (1-p)^^(n-k) Note I've used a different exponentiation operator, (^^), which supports negative exponents, thus avoid the branches. Since (^^) is Haskell98, Helium should have it. Another thing is the fact that the factorials will soon overflow using Int, so you should better use Integer and Double instead of Int and Float. > > (I used these lines of codes because it is not possible to use a negative > exponent in the Helium interpreter.) > > Thank you for answering my question! > > Greetings JTKM HTH, Daniel From ross at soi.city.ac.uk Thu Feb 5 07:16:23 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 5 07:06:28 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: <200902051041.20937.g9ks157k@acme.softbase.org> References: <200902051041.20937.g9ks157k@acme.softbase.org> Message-ID: <20090205121623.GA3405@soi.city.ac.uk> On Thu, Feb 05, 2009 at 10:41:20AM +0100, Wolfgang Jeltsch wrote: > type-level built fine with GHC 6.8 but failed to build with GHC > 6.10. The last line of the build log is this: > > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing Yes, haddock 2.4.1 (the most recent release) bombs on Data.TypeLevel.Num.Aliases. From miguelimo38 at yandex.ru Thu Feb 5 07:21:27 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Feb 5 07:11:34 2009 Subject: [Haskell-cafe] Define variable types In-Reply-To: <20090205115750.GA28405@flit> References: <20090205115750.GA28405@flit> Message-ID: <15161233836487@webmail90.yandex.ru> Note also that Helium ISN'T Haskell; it lacks hell of a lot of Haskell98 features (not to mention common extensions). 05.02.09, 14:57, "Roman Cheplyaka" : > * Tsunkiet Man [2009-02-05 12:37:22+0100] > > Hello, > > > > I'm new to Haskell and it seems like a very nice language to learn. However > > I'm not really familiar with the errormessages it produces. I am using a > > Helium interpreter. I've created the following module (however it is just a > > small sketch). I've written the following code: > > > > fac :: Int -> Int > > fac n = product[1..n] > > > > boven :: Int -> Int -> Int > > boven n k = (fac n) `div` fac k * fac (n-k) > > > > bin :: Int -> Int -> Int -> Int > > bin n k p |(n-k)>0 && k>0 = (boven n k) * (p^k) * (1-p)^(n-k) > > |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > > |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > > (1/((1-p)^(-(n-k)))) > > > > When I load this into my interpreter it says: > > > > Compiling ./Test.hs > > (11,55): Type error in infix application > > expression : 1 / ((1 - p) ^ (-(n - k))) > > operator : / > > type : Float -> Float -> Float > > does not match : Int -> Int -> Int > > (12,47): Type error in infix application > > expression : 1 / (p ^ (-k)) > > operator : / > > type : Float -> Float -> Float > > does not match : Int -> Int -> a > > (12,62): Type error in infix application > > expression : 1 / ((1 - p) ^ (-(n - k))) > > operator : / > > type : Float -> Float -> Float > > does not match : Int -> Int -> a > You can't use fractional division (/) with integers. You can convert > integers to fractions using fromIntegral. E.g.: > 1 / fromIntegral ((1 - p) ^ (-(n - k))) > (literals like 1 doesn't need to be converted because they are > polymorphic) > -- > Roman I. Cheplyaka :: http://ro-che.info/ > "Don't let school get in the way of your education." - Mark Twain > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From vandijk.roel at gmail.com Thu Feb 5 07:23:53 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Thu Feb 5 07:13:56 2009 Subject: [Haskell-cafe] Define variable types In-Reply-To: References: Message-ID: This is not really an answer to your question, but I think you could write a slightly more efficient function to calculate the binomial coefficient: fac :: Integer -> Integer fac n = product [1..n] -- |Product of all positive integers less than or equal to n but -- larger than s facFrom :: Integer -> Integer -> Integer facFrom s n | s > n = if s == 1 then 1 else 0 | otherwise = product [max (s + 1) 1 .. n] boven :: Integer -> Integer -> Integer boven n k = facFrom (n - k) n `div` fac k This exploits the fact that "fac n" contains the computation for "fac (n - k)". 2009/2/5 Tsunkiet Man : > Hello, > > I'm new to Haskell and it seems like a very nice language to learn. However > I'm not really familiar with the errormessages it produces. I am using a > Helium interpreter. I've created the following module (however it is just a > small sketch). I've written the following code: > > fac :: Int -> Int > fac n = product[1..n] > > boven :: Int -> Int -> Int > boven n k = (fac n) `div` fac k * fac (n-k) > > bin :: Int -> Int -> Int -> Int > bin n k p |(n-k)>0 && k>0 = (boven n k) * (p^k) * (1-p)^(n-k) > |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > (1/((1-p)^(-(n-k)))) > > When I load this into my interpreter it says: > > Compiling ./Test.hs > (11,55): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> Int > (12,47): Type error in infix application > expression : 1 / (p ^ (-k)) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a > (12,62): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a > Compilation failed with 3 errors > > Some details that might be usefull: > > Line 11 is |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > Line 12 is |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > (1/((1-p)^(-(n-k)))) > > So my question is: how can I fix these errors? > > (I used these lines of codes because it is not possible to use a negative > exponent in the Helium interpreter.) > > Thank you for answering my question! > > Greetings JTKM > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From martijn at van.steenbergen.nl Thu Feb 5 07:41:39 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Feb 5 07:31:41 2009 Subject: [Haskell-cafe] Define variable types In-Reply-To: References: Message-ID: <498ADE83.3040006@van.steenbergen.nl> Hallo Tsunkiet, Looking at http://www.cs.uu.nl/wiki/bin/view/Helium/ATourOfTheHeliumPrelude it seems you're looking for the /. operator, which is division on floating points. The / you're using only works on integers. Groetjes, Martijn. Tsunkiet Man wrote: > Hello, > > I'm new to Haskell and it seems like a very nice language to learn. > However I'm not really familiar with the errormessages it produces. I am > using a Helium interpreter. I've created the following module (however > it is just a small sketch). I've written the following code: > > fac :: Int -> Int > fac n = product[1..n] > > boven :: Int -> Int -> Int > boven n k = (fac n) `div` fac k * fac (n-k) > > bin :: Int -> Int -> Int -> Int > bin n k p |(n-k)>0 && k>0 = (boven n k) * (p^k) * (1-p)^(n-k) > |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > (1/((1-p)^(-(n-k)))) > > When I load this into my interpreter it says: > > Compiling ./Test.hs > (11,55): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> Int > (12,47): Type error in infix application > expression : 1 / (p ^ (-k)) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a > (12,62): Type error in infix application > expression : 1 / ((1 - p) ^ (-(n - k))) > operator : / > type : Float -> Float -> Float > does not match : Int -> Int -> a > Compilation failed with 3 errors > > Some details that might be usefull: > > Line 11 is |(n-k)<0 && k>0 = (boven n k) * (p^k) * (1/((1-p)^(-(n-k)))) > Line 12 is |(n-k)<0 && k<0 = (boven n k) * (1/(p^(-k))) * > (1/((1-p)^(-(n-k)))) > > So my question is: how can I fix these errors? > > (I used these lines of codes because it is not possible to use a > negative exponent in the Helium interpreter.) > > Thank you for answering my question! > > Greetings JTKM > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lemming at henning-thielemann.de Thu Feb 5 08:48:53 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 5 08:38:54 2009 Subject: [Haskell-cafe] Bytestrings vs String? parameters within package names? Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: Henning Thielemann Subject: Re: [Haskell-cafe] Bytestrings vs String? parameters within package names? Date: Thu, 05 Feb 2009 12:32:43 +0100 Size: 2810 Url: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/23c8a84b/attachment.eml From lemming at henning-thielemann.de Thu Feb 5 08:49:05 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 5 08:39:10 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: Henning Thielemann Subject: Re: [Haskell-cafe] Purely funcional LU decomposition Date: Thu, 05 Feb 2009 14:43:13 +0100 Size: 2285 Url: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/8354de02/attachment.eml From lemming at henning-thielemann.de Thu Feb 5 08:49:30 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 5 08:39:33 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: Henning Thielemann Subject: Re: [Haskell-cafe] Purely funcional LU decomposition Date: Thu, 05 Feb 2009 14:47:11 +0100 Size: 2483 Url: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/eb62d30f/attachment.eml From g9ks157k at acme.softbase.org Thu Feb 5 09:03:35 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 5 08:53:42 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: <20090205121623.GA3405@soi.city.ac.uk> References: <200902051041.20937.g9ks157k@acme.softbase.org> <20090205121623.GA3405@soi.city.ac.uk> Message-ID: <200902051503.35893.g9ks157k@acme.softbase.org> Am Donnerstag, 5. Februar 2009 13:16 schrieb Ross Paterson: > On Thu, Feb 05, 2009 at 10:41:20AM +0100, Wolfgang Jeltsch wrote: > > type-level built fine with GHC 6.8 but failed to build with GHC > > > > 6.10. The last line of the build log is this: > > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing > > Yes, haddock 2.4.1 (the most recent release) bombs on > Data.TypeLevel.Num.Aliases. Hackage uses Haddock 2.3.0, doesn?t it? Anyway, can something be done so that not all packages depending (directly or indirectly) on type-level are without documentation? For example, type-level could be installed on the Hackage server without documentation instead of not being installed at all. Best wishes, Wolfgang From david.waern at gmail.com Thu Feb 5 09:05:44 2009 From: david.waern at gmail.com (David Waern) Date: Thu Feb 5 08:55:46 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: <20090205121623.GA3405@soi.city.ac.uk> References: <200902051041.20937.g9ks157k@acme.softbase.org> <20090205121623.GA3405@soi.city.ac.uk> Message-ID: 2009/2/5 Ross Paterson : > On Thu, Feb 05, 2009 at 10:41:20AM +0100, Wolfgang Jeltsch wrote: >> type-level built fine with GHC 6.8 but failed to build with GHC >> 6.10. The last line of the build log is this: >> >> > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing > > Yes, haddock 2.4.1 (the most recent release) bombs on > Data.TypeLevel.Num.Aliases. In Haddock 2.4.0 we switched from using the compilation mode of the GHC API to a mode which does only typchecking. This broke Template Haskell support: http://trac.haskell.org/haddock/ticket/68 The problem is fixed in Haddock 2.4.2 which will be released with GHC 6.10.2. David From ross at soi.city.ac.uk Thu Feb 5 09:17:48 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 5 09:08:01 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: References: <200902051041.20937.g9ks157k@acme.softbase.org> <20090205121623.GA3405@soi.city.ac.uk> Message-ID: <20090205141748.GC3405@soi.city.ac.uk> On Thu, Feb 05, 2009 at 03:05:44PM +0100, David Waern wrote: > In Haddock 2.4.0 we switched from using the compilation mode of the > GHC API to a mode which does only typchecking. This broke Template > Haskell support: > > http://trac.haskell.org/haddock/ticket/68 > > The problem is fixed in Haddock 2.4.2 which will be released with GHC 6.10.2. Haddock 2.4.2 uses a different interface file format, right? (Not an insuperable problem -- just asking.) From jochem at functor.nl Thu Feb 5 09:23:10 2009 From: jochem at functor.nl (Jochem Berndsen) Date: Thu Feb 5 09:14:05 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! In-Reply-To: <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> References: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> Message-ID: <498AF64E.2080902@functor.nl> Neil Mitchell wrote: > Successor as in Happstack replaces HAppS entirely and all projects > implemented in HAppS should aim to port to Happstack - or successor as > in builds on the ideas in HAppS? Is HAppS now deprecated? The HAppS project has been abandoned, see http://groups.google.com/group/HAppS/msg/d128331e213c1031 . The Happstack project is intended to continue development. For more details, see http://happstack.com/faq.html . -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB From bugfact at gmail.com Thu Feb 5 09:44:02 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 5 09:34:08 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs Message-ID: I'm trying to switch from HG to Darcs, but I'm failing miserably in getting the same productivity. I often do bad checkins with Darcs, merely because the amount of information I get from Darcs is overwhelming and I don't have time to read the details of the large set of commands. With Mercurial, here's my basic workflow: 1) hg st lists just the filenames of changed, deleted, new files (with a char prefix to show what kind of change it is). I only want to see the filenames, not the lines/content. If I want to see changes in the content, I use hg diff using a visual differ. My brain is not capable of making sense of the textual diff. 2) modify .hgignore to make sure only these files are added that are part of the project. I want this process to be automated, I don't want to check each time which files to add, since this is error prone. 3) hg addrem this adds new files and removes deleted files from local repos. forgetting to add files is a common problem, and is really tricky since no record is made of these files, so if after a couple of versions if a developer finds out a file was missing, the history is useless since you can't reconstruct the old content of that local file anymore, and often it's impossible to give the local file to the other developers since it might be changed. I actually would like to have an option that automatically adds/deletes files on each commit, as it is easier to delete a file after it is checked in, than it is to reconstruct an old version from a local file you forgot to add. 4) hg commit -m "message" this commits my changes locally. I always do this before pulling since then I'm sure my changes are saved in the case a merge goes wrong. 5) hg pull -u this pulls in changes, and updates and merges the files, using a visual merger of my preference. 6) hg commit -m "merged" hg push only needed if I did a merge and want to push that merge. 7) back to 1) It would be nice to know how to do this using darcs, or if a better way exists using darcs, that would be handy too :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/6b200138/attachment.htm From mdmkolbe at gmail.com Thu Feb 5 09:44:39 2009 From: mdmkolbe at gmail.com (Michael D. Adams) Date: Thu Feb 5 09:34:40 2009 Subject: [Haskell-cafe] Re: Purely funcional LU decomposition In-Reply-To: References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Message-ID: On Wed, Feb 4, 2009 at 2:15 AM, Neal Alexander wrote: > Array is no good man! Quad Tree matrices perform much nicer from what I've > seen. I've co-authored a paper on that topic ("Seven at one stroke: results from a cache-oblivious paradigm for scalable matrix algorithms" http://portal.acm.org/citation.cfm?id=1178597.1178604). The current implementation is C based (to get base-case performance) but we would love to get that work ported to Haskell and a much more functional setting. Michael D. Adams From david.waern at gmail.com Thu Feb 5 09:45:05 2009 From: david.waern at gmail.com (David Waern) Date: Thu Feb 5 09:35:08 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: <20090205141748.GC3405@soi.city.ac.uk> References: <200902051041.20937.g9ks157k@acme.softbase.org> <20090205121623.GA3405@soi.city.ac.uk> <20090205141748.GC3405@soi.city.ac.uk> Message-ID: 2009/2/5 Ross Paterson : > On Thu, Feb 05, 2009 at 03:05:44PM +0100, David Waern wrote: >> In Haddock 2.4.0 we switched from using the compilation mode of the >> GHC API to a mode which does only typchecking. This broke Template >> Haskell support: >> >> http://trac.haskell.org/haddock/ticket/68 >> >> The problem is fixed in Haddock 2.4.2 which will be released with GHC 6.10.2. > > Haddock 2.4.2 uses a different interface file format, right? > (Not an insuperable problem -- just asking.) Yep, that's right. David From ross at soi.city.ac.uk Thu Feb 5 10:16:42 2009 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 5 10:06:46 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: <200902051503.35893.g9ks157k@acme.softbase.org> References: <200902051041.20937.g9ks157k@acme.softbase.org> <20090205121623.GA3405@soi.city.ac.uk> <200902051503.35893.g9ks157k@acme.softbase.org> Message-ID: <20090205151642.GD3405@soi.city.ac.uk> On Thu, Feb 05, 2009 at 03:03:35PM +0100, Wolfgang Jeltsch wrote: > Am Donnerstag, 5. Februar 2009 13:16 schrieb Ross Paterson: > > On Thu, Feb 05, 2009 at 10:41:20AM +0100, Wolfgang Jeltsch wrote: > > > type-level built fine with GHC 6.8 but failed to build with GHC > > > > > > 6.10. The last line of the build log is this: > > > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing > > > > Yes, haddock 2.4.1 (the most recent release) bombs on > > Data.TypeLevel.Num.Aliases. > > Hackage uses Haddock 2.3.0, doesn't it? The build client uses 2.4.1. I just tried with 2.3.0, and saw the same problem. > Anyway, can something be done so that not all packages depending (directly or > indirectly) on type-level are without documentation? For example, type-level > could be installed on the Hackage server without documentation instead of not > being installed at all. OK, I've done that. parameterized-data-0.1.3 now fails for other reasons, but the earlier ones are OK. From dev at mobileink.com Thu Feb 5 10:20:06 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 10:10:07 2009 Subject: [Haskell-cafe] evaluation semantics of bind Message-ID: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> I think I've just about got monads figured out, but there's one detail that still escapes me. As I understand it, a monad is a kind of programming trick the uses data dependency to force evaluation order. x >>= f means apply f to x; since the value of f x depends on the value of x, the evaluator must evaluate x before f x. However, consider: getChar >>= \x -> getChar An optimizer can see that the result of the first getChar is discarded and replace the entire expression with one getChar without changing the formal semantics. But that would change the behavior, so to get the desired behavior, there must be some principle that prevents this from happening, ensuring that x >>= f always evaluates f x. I can see that the monad laws ensure this But I haven't found anything that states this. Am I missing something? Thanks, gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/f57d25a6/attachment.htm From ekirpichov at gmail.com Thu Feb 5 10:26:15 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Feb 5 10:16:16 2009 Subject: [Haskell-cafe] Fastest regex package? Message-ID: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> Hello. What is the fastest regex package of the multitude of packages present on Hackage (namely, PCRE, PCRE-light, DFA, TDFA and many more)? My benchmark (parsing a huge logfile with a regex like "GET /foo.xml.*fooid=([0-9]++).*barid=([0-9]++)") shows that plain PCRE is the fastest one (I tried PCRE, PCRE-light and TDFA; DFA can't do capturing groups at all, TDFA was abysmally slow (about 20x slower than PCRE), and it doesn't support ++), but maybe have I missed any blazing-fast package? Even PCRE seems somewhat too slow to me - matching this regex eats 50% of the program time; considering that the only things it does is ungzipping the log and searching for the regex, this seems like far too much, the regex is not that complex to my mind. I tried to replace this regex by Data.ByteString.Search.KnuthMorrisPratt and BoyerMoore from stringsearch, but they work even twice slower. I also noticed that PCRE does about 2x fewer allocations than PCRE-Light, but is not much faster. However, PCRE, strangely, has a non-pure interface, I had to use it with unsafePerformIO. It's a pity I can't put these findings on haskellwiki to http://www.haskell.org/haskellwiki/Regular_expressions since I don't have an account and new accounts can't be created right now. Could anyone put them there? All in all, my question remains: what is the fastest way to do this kind of parsing on a lazy bytestring? From bulat.ziganshin at gmail.com Thu Feb 5 10:27:59 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 5 10:18:18 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <3410468369.20090205182759@gmail.com> Hello Gregg, Thursday, February 5, 2009, 6:20:06 PM, you wrote: > An optimizer can see that the result of the first getChar is > discarded and replace the entire expression with one getChar without > changing the formal semantics.? this is prohibited by using pseudo-value of type RealWorld which is passed through entire action stream. actually, order of execution is controlled by dependencies on this values http://haskell.org/haskellwiki/IO_inside -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From david.waern at gmail.com Thu Feb 5 10:28:34 2009 From: david.waern at gmail.com (David Waern) Date: Thu Feb 5 10:18:37 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: <20090205151642.GD3405@soi.city.ac.uk> References: <200902051041.20937.g9ks157k@acme.softbase.org> <20090205121623.GA3405@soi.city.ac.uk> <200902051503.35893.g9ks157k@acme.softbase.org> <20090205151642.GD3405@soi.city.ac.uk> Message-ID: 2009/2/5 Ross Paterson : > On Thu, Feb 05, 2009 at 03:03:35PM +0100, Wolfgang Jeltsch wrote: >> Am Donnerstag, 5. Februar 2009 13:16 schrieb Ross Paterson: >> > On Thu, Feb 05, 2009 at 10:41:20AM +0100, Wolfgang Jeltsch wrote: >> > > type-level built fine with GHC 6.8 but failed to build with GHC >> > > >> > > 6.10. The last line of the build log is this: >> > > > haddock: internal Haddock or GHC error: Maybe.fromJust: Nothing >> > >> > Yes, haddock 2.4.1 (the most recent release) bombs on >> > Data.TypeLevel.Num.Aliases. >> >> Hackage uses Haddock 2.3.0, doesn't it? > > The build client uses 2.4.1. I just tried with 2.3.0, and saw the > same problem. Oh, I'm sorry, seem like the problem was introduced in 2.3.0 (I should have checked the Trac ticket which clearly states that). I think 2.2.2 is fine, if that's of any help. David From ketil at malde.org Thu Feb 5 10:32:28 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Feb 5 10:21:26 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs In-Reply-To: (Peter Verswyvelen's message of "Thu\, 5 Feb 2009 15\:44\:02 +0100") References: Message-ID: <87vdrodhmb.fsf@malde.org> Peter Verswyvelen writes: > 1) hg st darcs cha -s > lists just the filenames of changed, deleted, new files (with a char prefix > to show what kind of change it is). > 2) modify .hgignore to make sure only these files are added that are part of > the project. I want this process to be automated, I don't want to check each > time which files to add, since this is error prone. I'm not sure what you want, but I only add files manually with darcs add > 3) hg addrem > this adds new files and removes deleted files from local repos. I don't quite understand what you're asking here. > 4) hg commit -m "message" > this commits my changes locally. I always do this before pulling since then > I'm sure my changes are saved in the case a merge goes wrong. darcs rec -m "message" > 5) hg pull -u > this pulls in changes, and updates and merges the files, using a visual > merger of my preference. darcs pull [-a] No visual merger, instead conflicts are marked and you need to work it out. This is a bit clumsy, but since darcs is smart about merging, it doesn't happen too often. > 6) hg commit -m "merged" > hg push darcs rec -m "merged" darcs send -k -- If I haven't seen further, it is by standing in the footprints of giants From roma at ro-che.info Thu Feb 5 10:32:37 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu Feb 5 10:22:43 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <20090205153237.GB11862@flit> * Gregg Reynolds [2009-02-05 09:20:06-0600] > I think I've just about got monads figured out, but there's one detail that > still escapes me. As I understand it, a monad is a kind of programming > trick the uses data dependency to force evaluation order. x >>= f means > apply f to x; since the value of f x depends on the value of x, the > evaluator must evaluate x before f x. However, consider: > > getChar >>= \x -> getChar > > An optimizer can see that the result of the first getChar is discarded and > replace the entire expression with one getChar without changing the formal > semantics. But that would change the behavior, so to get the desired > behavior, there must be some principle that prevents this from happening, > ensuring that x >>= f always evaluates f x. x >>= f doesn't mean apply f to x. It means, roughly, "construct (IO) action from actions x and f(..), so that they are executed sequentially and f depends on a resuls produced by x". Even if f does not depend on its argument, there's no reason for compiler to think that the first action may be ignored. If you think in terms of dependency, the second action depends on the state of the "world" left after executing x. So all IO actions take an implicit "world" argument and (>>=) operator implicitely passes modified "world" to the next action. > I can see that the monad laws ensure this But I haven't found anything that > states this. Am I missing something? -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From RafaelGCPP.Linux at gmail.com Thu Feb 5 10:32:48 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Thu Feb 5 10:22:53 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: References: Message-ID: <351ff25e0902050732w43b95a5bkddb05d2c30ae7ae1@mail.gmail.com> 2009/2/5 Henning Thielemann > > > ---------- Forwarded message ---------- > From: Henning Thielemann > To: Rafael Gustavo da Cunha Pereira Pinto > Date: Thu, 05 Feb 2009 14:43:13 +0100 > Subject: Re: [Haskell-cafe] Purely funcional LU decomposition > Rafael Gustavo da Cunha Pereira Pinto wrote: > >> >> interesting to look at real matrix code that people have written and >> think about what would be needed in a library to make it easier to >> write. >> -- >> Dan >> >> >> What I miss most is a data structure with O(1) (amortized) direct access. >> > > STArray and STUArray? > > > Are they? :-) -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/91c5f9b4/attachment.htm From bugfact at gmail.com Thu Feb 5 10:35:34 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 5 10:25:36 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs In-Reply-To: <87vdrodhmb.fsf@malde.org> References: <87vdrodhmb.fsf@malde.org> Message-ID: On Thu, Feb 5, 2009 at 4:32 PM, Ketil Malde wrote: > Peter Verswyvelen writes: > > > 1) hg st > > darcs cha -s That seems to list all changes in the history. hg st lists local changes only. Can be done using darcs? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/5fa4ed0a/attachment.htm From RafaelGCPP.Linux at gmail.com Thu Feb 5 10:39:10 2009 From: RafaelGCPP.Linux at gmail.com (Rafael Gustavo da Cunha Pereira Pinto) Date: Thu Feb 5 10:29:12 2009 Subject: [Haskell-cafe] Re: Purely funcional LU decomposition In-Reply-To: References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> Message-ID: <351ff25e0902050739t60ddd706r1e28d4818b4b4155@mail.gmail.com> On Wed, Feb 4, 2009 at 05:15, Neal Alexander wrote: > Array is no good man! Quad Tree matrices perform much nicer from what I've > seen. > > I wrote some matrix stuff based on D. Stott Parker's "Randomized Gaussian > elimination" papers (http://www.cs.ucla.edu/~stott/ge/). > He presents some recursive block based methods of solving without pivoting. > > I want to upload the full library to Hackage, but it'd be nice to have some > people look through it before - mainly because i never took linear algebra > heh. QuickCheck seems to be holding things together though. > > I read some of those papers and, yes, it is impressive. OTOH, I really need pivoting (some ill-conditioned matrices are expected), which they all claim to be hard to implement using quadtrees and I'm afraid that using RBTs might introduce other sources of error. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/1f14912d/attachment.htm From dev at mobileink.com Thu Feb 5 10:46:48 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 10:36:50 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <3410468369.20090205182759@gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <3410468369.20090205182759@gmail.com> Message-ID: <75cc17ac0902050746i7eba3defj9b3ea70b7621223b@mail.gmail.com> On Thu, Feb 5, 2009 at 9:27 AM, Bulat Ziganshin wrote: > Hello Gregg, > > Thursday, February 5, 2009, 6:20:06 PM, you wrote: > > > An optimizer can see that the result of the first getChar is > > discarded and replace the entire expression with one getChar without > > changing the formal semantics. > > this is prohibited by using pseudo-value of type RealWorld which is > passed through entire action stream. actually, order of execution is > controlled by dependencies on this values > > http://haskell.org/haskellwiki/IO_inside > > Thanks. I actually read that a few weeks ago and forgot all about it. So the gist is that type IO has special magic semantics. Formal, but hidden. Which means monad semantics are built in to the language, at least for that type. The Haskell Report doesn't seem to say anything about this, which seems odd. But then for non-IO monads, the optimization would be allowed, no? Of course; only the IO monad has external world behavior. Thanks, gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/5ea8a3d4/attachment.htm From roma at ro-che.info Thu Feb 5 10:47:28 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu Feb 5 10:37:34 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs In-Reply-To: References: <87vdrodhmb.fsf@malde.org> Message-ID: <20090205154728.GA27668@flit> * Peter Verswyvelen [2009-02-05 16:35:34+0100] > On Thu, Feb 5, 2009 at 4:32 PM, Ketil Malde wrote: > > > Peter Verswyvelen writes: > > > > > 1) hg st > > > > darcs cha -s > > > That seems to list all changes in the history. > > hg st lists local changes only. Can be done using darcs? darcs whatsnew -s -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From gleb.alexeev at gmail.com Thu Feb 5 10:53:52 2009 From: gleb.alexeev at gmail.com (Gleb Alexeyev) Date: Thu Feb 5 10:43:45 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: Gregg Reynolds wrote: > However, consider: > > getChar >>= \x -> getChar > > An optimizer can see that the result of the first getChar is discarded > and replace the entire expression with one getChar without changing the > formal semantics. Let's imagine that IO datatype is defined thus: >{-# LANGUAGE GADTs #-} >{-# LANGUAGE NoImplicitPrelude #-} >import Prelude(Monad, Char) >data IO a where > GetChar :: IO Char > Bind :: IO a -> (a -> IO b) -> IO b >getChar = GetChar >(>>=) = Bind It is perfectly possible to construct IO actions as values of this data type and execute them by some function evalIO :: IO -> Prelude.IO with the obvious definition. Now the question arises: do you think getChar >>= \x -> getChar would be optimized to getChar by compiler? If no, why would GHC want to do this optimization for standard IO? From ekirpichov at gmail.com Thu Feb 5 10:54:00 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Thu Feb 5 10:44:01 2009 Subject: [Haskell-cafe] Re: Fastest regex package? In-Reply-To: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> References: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> Message-ID: <5e0214850902050754i214a76f4j419c92f4ee518c1@mail.gmail.com> I was wrong about BoyerMoore: it works about 2x faster than PCRE for this example, so seems like it does the trick (although I suspect that one could do even faster, so the question remains). 2009/2/5 Eugene Kirpichov : > Hello. > > What is the fastest regex package of the multitude of packages present > on Hackage (namely, PCRE, PCRE-light, DFA, TDFA and many more)? > > My benchmark (parsing a huge logfile with a regex like "GET > /foo.xml.*fooid=([0-9]++).*barid=([0-9]++)") shows that plain PCRE is > the fastest one (I tried PCRE, PCRE-light and TDFA; DFA can't do > capturing groups at all, TDFA was abysmally slow (about 20x slower > than PCRE), and it doesn't support ++), but maybe have I missed any > blazing-fast package? > > Even PCRE seems somewhat too slow to me - matching this regex eats 50% > of the program time; considering that the only things it does is > ungzipping the log and searching for the regex, this seems like far > too much, the regex is not that complex to my mind. I tried to replace > this regex by Data.ByteString.Search.KnuthMorrisPratt and BoyerMoore > from stringsearch, but they work even twice slower. > > I also noticed that PCRE does about 2x fewer allocations than > PCRE-Light, but is not much faster. > However, PCRE, strangely, has a non-pure interface, I had to use it > with unsafePerformIO. > > It's a pity I can't put these findings on haskellwiki to > http://www.haskell.org/haskellwiki/Regular_expressions since I don't > have an account and new accounts can't be created right now. Could > anyone put them there? > > All in all, my question remains: what is the fastest way to do this > kind of parsing on a lazy bytestring? > From lennart at augustsson.net Thu Feb 5 11:00:58 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Feb 5 10:50:59 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902050746i7eba3defj9b3ea70b7621223b@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <3410468369.20090205182759@gmail.com> <75cc17ac0902050746i7eba3defj9b3ea70b7621223b@mail.gmail.com> Message-ID: There's nothing magic about IO when it comes to monad semantics. If you take ghc's implementation of IO, it's a state monad. The new state generated by x is passed to f, so there's no way to skip x. (Well, if the compiler can show that the state is not used anywhere then it can start removing things, but in that case there really is no change in semantics.) -- Lennart 2009/2/5 Gregg Reynolds : > On Thu, Feb 5, 2009 at 9:27 AM, Bulat Ziganshin > wrote: >> >> Hello Gregg, >> >> Thursday, February 5, 2009, 6:20:06 PM, you wrote: >> >> > An optimizer can see that the result of the first getChar is >> > discarded and replace the entire expression with one getChar without >> > changing the formal semantics. >> >> this is prohibited by using pseudo-value of type RealWorld which is >> passed through entire action stream. actually, order of execution is >> controlled by dependencies on this values >> >> http://haskell.org/haskellwiki/IO_inside >> > Thanks. I actually read that a few weeks ago and forgot all about it. So > the gist is that type IO has special magic semantics. Formal, but hidden. > Which means monad semantics are built in to the language, at least for that > type. The Haskell Report doesn't seem to say anything about this, which > seems odd. > > But then for non-IO monads, the optimization would be allowed, no? Of > course; only the IO monad has external world behavior. > > Thanks, > > gregg > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From jake at pikewerks.com Thu Feb 5 11:06:43 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 10:56:48 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <498B0E93.9090205@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregg Reynolds wrote: | As I understand it, a monad is a kind of programming trick the uses data dependency to force evaluation order. Actually, a monad does nothing more than supply some combinators. These combinators (and some trivial laws) are all you really need to know to understand monads. Specific monads are really just a case-by-case issue. Using some function names that are not used in the standard Haskell libraries, here are the important functions you have access to when you have a monad, all of which return monadic values: ~ point :: a -> f a ~ map :: (a -> b) -> f a -> f b ~ apply :: f (a -> b) -> f a -> f b ~ bind :: (a -> f b) -> f a -> f b I aligned the type signatures the way I did so you could see their similarities and differences more easily. point is the same as the return and pure functions. It lifts a pure value. map is the same as the (<$>), fmap, liftA, and liftM functions. It applies a pure function to a lifted value. apply is the same as the (<*>) and ap functions. It applies a lifted function to a lifted value. The type signature for bind is reversed from that of (>>=). It's the same as (=<<). I think it is more clear and better parallels the other functions I've already shown. It applies a "lifting" function to a lifted value. | since the value of f x depends on the value of x, the evaluator must evaluate x before f x This is actually not true. Remember, Haskell is a lazy language. x need not be evaluated before applying f to it. | However, consider: | | getChar >>= \x -> getChar | | An optimizer can see that the result of the first getChar is discarded and replace the entire expression with one getChar without changing the formal semantics. Consider how this expression would actually look in a Haskell program: ~ main :: IO () ~ main = getChar >>= \x -> getChar Remember, a type coincides with a value. That is, the entire main function is a _value_ of type IO (). The value, as it so happens, is an imperative program which the Haskell runtime performs. That is, the reduction semantics of IO expressions _produce_, rather than perform, actions. The actions are only performed by the runtime. Every monad has a "run" function. The IO monad's run function is the Haskell runtime. If you think of the IO monad as some sort of Writer monad, it is easy to see that Haskell's reduction semantics actually guarantee correct order of operations, and a semantics-preserving optimizer will not change it. In GHC, the IO monad is actually more like a State monad (over RealWorld). It is also easy to see that this preserves correct ordering of side-effects as well. I just wanted to present a different point of view. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLDpMACgkQye5hVyvIUKnUpwCfdAycTBv29wVt+J5VHZbNEQ3H 80kAnj7u7HS+5S1qxgzB90I7v+ftuazo =poXT -----END PGP SIGNATURE----- From dev at mobileink.com Thu Feb 5 11:08:05 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 10:58:06 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> Message-ID: <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> On Wed, Feb 4, 2009 at 8:18 PM, Richard O'Keefe wrote: > > On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote: > >> That's a fairly common representation, seems to work for lots of people, >> but it caused me no end of trouble. Values are mathematical objects; how, I >> asked myself, can they possibly /be/ programs that do IO (or actions, or >> computations, or )? It doesn't make sense, says I, >> > > without reference to the rest of your message, of course values can /be/ > programs. Not "programs", but "programs that do IO". The point of the idiom is that there's an external side effect involved. What sticks in my craw is that "a mathematical value with a non-mathematical side effect" is, well, non-mathematical and possibly nonsensical. I know it works for some (most?) people, but for me it lacks Geometry and Theology. -g -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/d8399e49/attachment.htm From dev at mobileink.com Thu Feb 5 11:18:38 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 11:08:38 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> On Thu, Feb 5, 2009 at 9:53 AM, Gleb Alexeyev wrote: > Let's imagine that IO datatype is defined thus: > > >{-# LANGUAGE GADTs #-} > >{-# LANGUAGE NoImplicitPrelude #-} > > >import Prelude(Monad, Char) > >data IO a where > > GetChar :: IO Char > > Bind :: IO a -> (a -> IO b) -> IO b > > >getChar = GetChar > >(>>=) = Bind > > It is perfectly possible to construct IO actions as values of this data > type and execute them by some function evalIO :: IO -> Prelude.IO with the > obvious definition. Now the question arises: do you think > getChar >>= \x -> getChar would be optimized to getChar by compiler? > I must be misunderstanding something. I don't know if it would be optimized out, but I see no reason why it couldn't be. There's no data dependency, right? -g -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/64031749/attachment.htm From jeremy at n-heptane.com Thu Feb 5 11:20:36 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Feb 5 11:10:37 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <87tz78onxn.wl%jeremy@n-heptane.com> Hello, The type IO (in many Haskell implemenations) is essentially: > type IO a = RealWorld -> (a, RealWorld) And >> would be implemented like: > (>>) :: IO a -> IO b -> IO b > action1 >>= action2 = \world0 -> > let (a, world1) = action1 world0 > (b, world2) = action2 world1 > in (b, world2) So, even though action2 does not depend on the 'a' value returned by action1, it does depend on the world value. Hence, the compiler will not optimize away the call to action1, because then it would not have a 'world1' value to pass to action2. It is the passing around of these 'world*' values that causes the IO operations to happen in the right order. Of course, this only works if the programmer is careful to ensure that each world variable is used exactly once, and that no functions are accidently skipped, etc. For example, lets say that (>>) was accidently defined like: > (>>) :: IO a -> IO b -> IO b > action1 >>= action2 = \world0 -> > let (a, world1) = action1 world0 > (b, world2) = action2 world0 -- oops, should be world1 > in (b, world2) now action1 would not be run. Since it is so easy to accidently screw up the passing around of world variables, we don't do it 'by hand'. We get it right once in the Monad instance, and then we don't have to worry about it anymore. - jeremy At Thu, 5 Feb 2009 09:20:06 -0600, Gregg Reynolds wrote: > > [1 ] > [1.1 ] > I think I've just about got monads figured out, but there's one detail that > still escapes me. As I understand it, a monad is a kind of programming > trick the uses data dependency to force evaluation order. x >>= f means > apply f to x; since the value of f x depends on the value of x, the > evaluator must evaluate x before f x. However, consider: > > getChar >>= \x -> getChar > > An optimizer can see that the result of the first getChar is discarded and > replace the entire expression with one getChar without changing the formal > semantics. But that would change the behavior, so to get the desired > behavior, there must be some principle that prevents this from happening, > ensuring that x >>= f always evaluates f x. > > I can see that the monad laws ensure this But I haven't found anything that > states this. Am I missing something? > > Thanks, > > gregg > [1.2 ] > > [2 ] > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From mail at justinbogner.com Thu Feb 5 11:26:16 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Feb 5 11:16:29 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <878wokhmtz.fsf@justinbogner.com> Gregg Reynolds writes: > I think I've just about got monads figured out, but there's one detail that > still escapes me. As I understand it, a monad is a kind of programming trick > the uses data dependency to force evaluation order. x >>= f means apply f to > x; since the value of f x depends on the value of x, the evaluator must > evaluate x before f x. However, consider: > > getChar >>= \x -> getChar > x >>= f does not mean "apply f to x", it means "do x, and then do f with the result of x". Bind is a sequencing operator rather than an application operator. From dev at mobileink.com Thu Feb 5 11:33:42 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 11:23:42 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <3410468369.20090205182759@gmail.com> <75cc17ac0902050746i7eba3defj9b3ea70b7621223b@mail.gmail.com> Message-ID: <75cc17ac0902050833w7cd69547y4b2ce1b5182136ae@mail.gmail.com> On Thu, Feb 5, 2009 at 10:00 AM, Lennart Augustsson wrote: > > There's nothing magic about IO when it comes to monad semantics. > If you take ghc's implementation of IO, it's a state monad. Doesn't that mean the semantics are defined by the implementation? My problem is that I'm not seeing how correct eval sequencing can be forced unless a magic token is passed around, which means that /some/ such hidden semantics must be part of the formal semantics of IO. In other words, it's not enough for it to be a monad, since >>= by itself cannot guarantee data dependency. If it doesn't pass around the World token, we don't get sequencing. -g From dev at mobileink.com Thu Feb 5 11:40:34 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 11:30:35 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <878wokhmtz.fsf@justinbogner.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> Message-ID: <75cc17ac0902050840n79467986oe2bbbdd292bcdef2@mail.gmail.com> On Thu, Feb 5, 2009 at 10:26 AM, wrote: > > x >>= f does not mean "apply f to x", it means "do x, and then do f with > the result of x". Bind is a sequencing operator rather than an > application operator. Sequencing is a side effect of data dependency. What I should have said is x >>= f means "evaluate x and f (in any order), /then/ apply f to x". In a non-IO monad, x can be discarded if f does not depend on it. -g From jake at pikewerks.com Thu Feb 5 11:43:54 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 11:33:58 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <878wokhmtz.fsf@justinbogner.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> Message-ID: <498B174A.202@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mail@justinbogner.com wrote: | Bind is a sequencing operator rather than an application operator. In my opinion, this is a common misconception. I think that bind would be nicer if its arguments were reversed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLF0oACgkQye5hVyvIUKnTeACfW3Kvlz2PLTQ6RzPGdF+aDRPa IKoAn2X7STrrKDUO3s9yUP5weTHcaG3Z =bBXE -----END PGP SIGNATURE----- From gleb.alexeev at gmail.com Thu Feb 5 11:49:02 2009 From: gleb.alexeev at gmail.com (Gleb Alexeyev) Date: Thu Feb 5 11:38:55 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> Message-ID: Gregg Reynolds wrote: > I must be misunderstanding something. I don't know if it would be > optimized out, but I see no reason why it couldn't be. There's no data > dependency, right? Of course there is data dependency. In my example, where IO is defined as a (generalized) algebraic datatype, the value of getChar is GetChar. The value of 'getChar >>= \x -> getChar' is 'Bind GetChar (\x -> GetChar'. 'x' is not used anywhere, but this doesn't change the fact that these are totally different values, no sane compiler would prove them equal. For some monads, the evaluation of 'a >>= \x -> b' yields b, but it's not true in general. From mail at justinbogner.com Thu Feb 5 11:54:33 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Feb 5 11:56:21 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <498B174A.202@pikewerks.com> (Jake McArthur's message of "Thu, 05 Feb 2009 10:43:54 -0600") References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> Message-ID: <87y6wkg6es.fsf@justinbogner.com> Oops, sent this off list the first time, here it is again. Jake McArthur writes: > mail@justinbogner.com wrote: > | Bind is a sequencing operator rather than an application operator. > > In my opinion, this is a common misconception. I think that bind would > be nicer if its arguments were reversed. If this is a misconception, why does thinking of it this way work so well? This idea is reinforced by the do notation syntactic sugar: bind can be represented by going into imperative land and "do"ing one thing before another. The fact that `x' may not actually have to happen before `f' is merely the typical sort of optimization we do in compilers for imperative languages: instructions that do not modify non-local state can be re-ordered, but IO cannot because it jumps elsewhere, no? From dev at mobileink.com Thu Feb 5 12:06:22 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 11:56:29 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> Message-ID: <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> On Thu, Feb 5, 2009 at 10:49 AM, Gleb Alexeyev wrote: > Gregg Reynolds wrote: > > I must be misunderstanding something. I don't know if it would be >> >> optimized out, but I see no reason why it couldn't be. There's no data >> dependency, right? > > Of course there is data dependency. In my example, where IO is defined as a > (generalized) algebraic datatype, the value of getChar is GetChar. > The value of 'getChar >>= \x -> getChar' is 'Bind GetChar (\x -> GetChar'. > 'x' is not used anywhere, but this doesn't change the fact that these are > totally different values, no sane compiler would prove them equal. Are you saying that using equations to add a level of indirection prevents optimization? I still don't see it - discarding x doesn't change the semantics, so a good compiler /should/ do this. How is this different from optimizing out application of a constant function? -g From wagner.andrew at gmail.com Thu Feb 5 12:12:44 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Feb 5 12:02:45 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> Message-ID: Are you saying that using equations to add a level of indirection > prevents optimization? I still don't see it - discarding x doesn't > change the semantics, so a good compiler /should/ do this. How is > this different from optimizing out application of a constant function? > No, no compiler should change "getChar >>= \x -> getChar" to just getChar, because it's just wrong. The first will try to read in two values of type Char, the second will only try to read one. Side effects aren't THAT hated! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/bfb5972d/attachment.htm From gleb.alexeev at gmail.com Thu Feb 5 12:22:24 2009 From: gleb.alexeev at gmail.com (Gleb Alexeyev) Date: Thu Feb 5 12:12:12 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> Message-ID: Gregg Reynolds wrote: > Are you saying that using equations to add a level of indirection > prevents optimization? I still don't see it - discarding x doesn't > change the semantics, so a good compiler /should/ do this. How is > this different from optimizing out application of a constant function? > Perhaps my example doesn't work, so I'll try another example. As you know, (>>=) is just an (overloaded) higher-order function. Let's consider another higher-order function, map. The expression > map (\x -> 42) [1..3] evaluates to [42, 42, 42]. As you can see, the function (\x -> 42) passed to map ignores its first argument. Would you expect the compiler to discard the call to map? Can you see the analogy? The shapes of the two expressions, map (\x -> 42) [1..3] and (>>=) getChar (\x -> getChar) are similar. (>>=) is a combinator just like map, you cannot optimize it away in general. From dev at mobileink.com Thu Feb 5 12:22:55 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 12:12:55 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> Message-ID: <75cc17ac0902050922w165e58f3ja7cc0e14435fefb5@mail.gmail.com> On Thu, Feb 5, 2009 at 11:12 AM, Andrew Wagner wrote: > > >> Are you saying that using equations to add a level of indirection >> prevents optimization? I still don't see it - discarding x doesn't >> change the semantics, so a good compiler /should/ do this. How is >> this different from optimizing out application of a constant function? > > No, no compiler should change "getChar >>= \x -> getChar" to just getChar, > because it's just wrong. The first will try to read in two values of type > Char, the second will only try to read one. Side effects aren't THAT hated! Right, but that's only because the compiler either somehow knows about side effects or there is some other mechanism - e.g. an implicit World token that gets passed around - that prevents optiimization. As far as the formal semantics of the language are concerned, there's no essential difference between "getChar >>= \x -> getChar" and " Foo 3 >>= \x -> Foo 7 " for some data constructor Foo. I should think the latter would be optimized; if so, why not the former? The presence of some hidden (from me, anyway) semantics is inescapable. -g From jeremy at n-heptane.com Thu Feb 5 12:35:10 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Feb 5 12:25:19 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> Message-ID: <87skmsokhd.wl%jeremy@n-heptane.com> At Thu, 5 Feb 2009 11:06:22 -0600, Gregg Reynolds wrote: > Are you saying that using equations to add a level of indirection > prevents optimization? I still don't see it - discarding x doesn't > change the semantics, so a good compiler /should/ do this. How is > this different from optimizing out application of a constant function? Let rewrite this: 'getChar >>= \x -> getChar' in a slightly different looking form, where bind = (>>=) so that we have: bind getChar (\x -> getChar) If I understand your argument, you think that the compiler should be able to look at that expression, and instead of calling 'bind' with the two arguments 'getChar' and '(\x -> getChar)' it should just optimize it to 'getChar'? By comparision, consider this function: op :: Maybe a -> (a -> Maybe b) -> Maybe b op x f = Nothing I believe that by your argument we should be able to rewrite this: (Just "foo") `op` \x -> (Just "bar") as: (Just "bar") because the 'x' is ignored? But, 'op' *always* returns Nothing, and clearly Nothing /= (Just "bar")? Maybe I misunderstanding what you mean when you say that 'discarding x does not change the semantics'. Thanks! - jeremy From jake at pikewerks.com Thu Feb 5 12:42:32 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 12:32:33 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> Message-ID: <498B2508.7070206@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gleb Alexeyev wrote: | Perhaps my example doesn't work, so I'll try another example. | As you know, (>>=) is just an (overloaded) higher-order function. | Let's consider another higher-order function, map. The expression | > map (\x -> 42) [1..3] | evaluates to [42, 42, 42]. | As you can see, the function (\x -> 42) passed to map ignores its first | argument. Would you expect the compiler to discard the call to map? In fact, this can even be rewritten with bind: ~ [1..3] >>= \x -> return 42 So if you wouldn't expect the map to be discarded, certainly the bind should not be either. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLJQgACgkQye5hVyvIUKlUNQCgp6T0BCs00rYS3ygprs5rs3VM mrgAoMo1AgLTTeosXV8dQa+1BljcpfQy =o3iZ -----END PGP SIGNATURE----- From jake at pikewerks.com Thu Feb 5 12:44:36 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 12:34:37 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <87y6wkg6es.fsf@justinbogner.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> Message-ID: <498B2584.108@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mail@justinbogner.com wrote: | Oops, sent this off list the first time, here it is again. | | Jake McArthur writes: |> mail@justinbogner.com wrote: |> | Bind is a sequencing operator rather than an application operator. |> |> In my opinion, this is a common misconception. I think that bind would |> be nicer if its arguments were reversed. | | If this is a misconception, why does thinking of it this way work so | well? This idea is reinforced by the do notation syntactic sugar: bind | can be represented by going into imperative land and "do"ing one thing | before another. An imperative-looking notation does not make something imperative. Thinking of bind as sequencing really *doesn't* work very well. What does bind have to do with sequencing at all in the list monad, for example? What about the reader monad? - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLJYQACgkQye5hVyvIUKlGmACeJTP/Oj7F0tuoN+CdrzJeZ/fU AXgAn3Z5E1X1GDs96BgmHeqqEVVh0FSW =Zt4V -----END PGP SIGNATURE----- From temp.tsun at gmail.com Thu Feb 5 12:57:42 2009 From: temp.tsun at gmail.com (Tsunkiet Man) Date: Thu Feb 5 12:47:45 2009 Subject: [Haskell-cafe] RE: Define variable types Message-ID: Hello, thank you guys for your responds. I got it working now =). Thanks a lot! Greetx JTKM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/3b62fb1d/attachment.htm From barsoap at web.de Thu Feb 5 12:59:11 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 5 12:49:19 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <20090205185911.09fd1089@solaris> Gregg Reynolds wrote: > getChar >>= \x -> getChar > > An optimizer can see that the result of the first getChar is discarded > It isn't discarded. The first getChar results in a value of type IO Char, always and ever. Whether or not the Char inside the IO Char gets evaluated or not is another question... >>= could not care less about what you do to the values that are _inside_ the monad. If you look at the type (>>=) :: (Monad m) => m a -> (a -> m b) -> m b , you will find it hard to do much of significance to "a" and/or "b"[1] Whether or not a monad behaves strictly or lazyily wrt. to "m" depends on the definition of the functions that come with it: IO happens to be strict, [] to be lazy. This is nothing that messes with semantics, though, it celebrates them. [1] Well, you can pass them to id, seq or par, and replace them with undefined... -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From mail at justinbogner.com Thu Feb 5 13:47:38 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Feb 5 13:37:49 2009 Subject: [Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind) References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> Message-ID: <87tz78g1px.fsf_-_@justinbogner.com> Jake McArthur writes: > mail@justinbogner.com wrote: > | Oops, sent this off list the first time, here it is again. > | > | Jake McArthur writes: > |> mail@justinbogner.com wrote: > |> | Bind is a sequencing operator rather than an application operator. > |> > |> In my opinion, this is a common misconception. I think that bind would > |> be nicer if its arguments were reversed. > | > | If this is a misconception, why does thinking of it this way work so > | well? This idea is reinforced by the do notation syntactic sugar: bind > | can be represented by going into imperative land and "do"ing one thing > | before another. > > An imperative-looking notation does not make something imperative. > > Thinking of bind as sequencing really *doesn't* work very well. What > does bind have to do with sequencing at all in the list monad, for > example? What about the reader monad? > > - Jake What doesn't bind have to do with sequencing in the list monad? Consider: [1..2] >>= From mail at justinbogner.com Thu Feb 5 13:47:38 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Feb 5 13:44:32 2009 Subject: [Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind) References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> Message-ID: <87r62cg1ew.fsf@justinbogner.com> Jake McArthur writes: > mail@justinbogner.com wrote: > | Oops, sent this off list the first time, here it is again. > | > | Jake McArthur writes: > |> mail@justinbogner.com wrote: > |> | Bind is a sequencing operator rather than an application operator. > |> > |> In my opinion, this is a common misconception. I think that bind would > |> be nicer if its arguments were reversed. > | > | If this is a misconception, why does thinking of it this way work so > | well? This idea is reinforced by the do notation syntactic sugar: bind > | can be represented by going into imperative land and "do"ing one thing > | before another. > > An imperative-looking notation does not make something imperative. > > Thinking of bind as sequencing really *doesn't* work very well. What > does bind have to do with sequencing at all in the list monad, for > example? What about the reader monad? > > - Jake What doesn't bind have to do with sequencing in the list monad? Consider: [1..2] >>= return . (^2) This says "generate the list [1..2] and then use it to generate a list of squares". It's more than just application, it's a description of a sequence of actions. The whole point of list comprehensions (which is the only reason to have a list monad, as far as I know) is to think of it this way rather than as an application of concatMap. As for Reader, I don't know enough about it to say anything. From g9ks157k at acme.softbase.org Thu Feb 5 13:57:29 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 5 13:47:34 2009 Subject: [Haskell-cafe] Re: build problems on Hackage In-Reply-To: <20090205151642.GD3405@soi.city.ac.uk> References: <200902051041.20937.g9ks157k@acme.softbase.org> <200902051503.35893.g9ks157k@acme.softbase.org> <20090205151642.GD3405@soi.city.ac.uk> Message-ID: <200902051957.29154.g9ks157k@acme.softbase.org> Am Donnerstag, 5. Februar 2009 16:16 schrieb Ross Paterson: > On Thu, Feb 05, 2009 at 03:03:35PM +0100, Wolfgang Jeltsch wrote: > > Anyway, can something be done so that not all packages depending > > (directly or indirectly) on type-level are without documentation? For > > example, type-level could be installed on the Hackage server without > > documentation instead of not being installed at all. > > OK, I've done that. parameterized-data-0.1.3 now fails for other reasons, > but the earlier ones are OK. Thank you very much. Best wishes, Wolfgang From haskell at list.mightyreason.com Thu Feb 5 13:59:12 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Feb 5 13:49:26 2009 Subject: [Haskell-cafe] Re: Fastest regex package? In-Reply-To: <5e0214850902050754i214a76f4j419c92f4ee518c1@mail.gmail.com> References: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> <5e0214850902050754i214a76f4j419c92f4ee518c1@mail.gmail.com> Message-ID: <498B3700.2090706@list.mightyreason.com> Eugene Kirpichov wrote: >> All in all, my question remains: what is the fastest way to do this >> kind of parsing on a lazy bytestring? >> Your example regular expression works the same in both Posix and Perl-ish semantics. Do you know the difference? Posix libraries look for the longest match of all possible matches. Perl-ish is left-bias and looks at the left branch first and only looks at the right branch when the left fails and it has to backtrack. So the "++" operator is a hack to try and control the backtracking of Perl regular expressions. Such a things has no meaning in Posix where the implementation details are totally different. You might try this variant of the example pattern: /foo.xml.*fooid=([0-9]+)[^0-9].*barid=([0-9]+) The [^0-9] can be used when you know that there is at least one junk character before the barid, which I suspect will always occur in a URL. I expect regex-posix to be slower than regex-pcre. I have not used the new pcre-light. I wrote regex-tdfa ? it is pure haskell and not a C library wrapper. There are patterns where regex-pcre will backtrack and take exponentially more time than regex-tdfa's automaton (which is not yet ideal and may get faster). So what is the lazy bytestring with its multiple buffers doing for you when using PCRE, PCRE-light, or regex-posix? Absolutely nothing. To run against these C libraries the target text is converted to a single buffer, i.e. a CStringLen in Haskell. Thus it is morally converted into a strict bytestring. This may involve copying the logfile into a NEW strict bytestring EVERY TIME you run a match. Please Please Please convert to a strict bytestring and then run regex-pcre or pcre-light (or any of the others). regex-tdfa does not convert it into a strict bytestring, but is otherwise much slower than pcre for your simple pattern. As for regex-pcre's interface....you should use the API in regex-base to get a pure interface. The RegexLike functions are the pure interface for this, and the RegexContext class offers a slew of instances with useful variants. But if you have been getting to the "low level IO API" in regex-pcre then you probably do not need or want the RegexContext transformations. And BoyerMoore (which I think I helped optimize): this may be faster because it does not copy your whole Lazy bytestring into a Strict ByteString for each search. But you may wish to test it with a Strict ByteString as input anyway. -- Chris From jonathanccast at fastmail.fm Thu Feb 5 14:08:00 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 14:00:25 2009 Subject: [Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind) In-Reply-To: <87r62cg1ew.fsf@justinbogner.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> <87r62cg1ew.fsf@justinbogner.com> Message-ID: <1233860880.19682.36.camel@jcchost> On Thu, 2009-02-05 at 11:47 -0700, mail@justinbogner.com wrote: > Jake McArthur writes: > > mail@justinbogner.com wrote: > > | Oops, sent this off list the first time, here it is again. > > | > > | Jake McArthur writes: > > |> mail@justinbogner.com wrote: > > |> | Bind is a sequencing operator rather than an application operator. > > |> > > |> In my opinion, this is a common misconception. I think that bind would > > |> be nicer if its arguments were reversed. > > | > > | If this is a misconception, why does thinking of it this way work so > > | well? This idea is reinforced by the do notation syntactic sugar: bind > > | can be represented by going into imperative land and "do"ing one thing > > | before another. > > > > An imperative-looking notation does not make something imperative. > > > > Thinking of bind as sequencing really *doesn't* work very well. What > > does bind have to do with sequencing at all in the list monad, for > > example? What about the reader monad? > > > > - Jake > > What doesn't bind have to do with sequencing in the list monad? > Consider: > > [1..2] >>= return . (^2) > > This says "generate the list [1..2] and then use it to generate a list > of squares". It's more than just application, it's a description of a > sequence of actions. But not a temporal sequence. (>>=) in IO is about temporal sequencing (modulo unsafeInterleaveIO, forkIO, etc.) > The whole point of list comprehensions (which is > the only reason to have a list monad, as far as I know) Huh? I thought newtype Parser s alpha = Parser { unParser :: StateT s [] alpha } deriving (Functor, Applicative, Alternative, Monad, MonadPlus) was an entirely sufficient reason to have a list monad. jcc From leimy2k at gmail.com Thu Feb 5 14:20:20 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Feb 5 14:10:22 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> Message-ID: <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> 2009/2/5 Gregg Reynolds > On Wed, Feb 4, 2009 at 8:18 PM, Richard O'Keefe wrote: > >> >> On 5 Feb 2009, at 10:20 am, Gregg Reynolds wrote: >> >>> That's a fairly common representation, seems to work for lots of people, >>> but it caused me no end of trouble. Values are mathematical objects; how, I >>> asked myself, can they possibly /be/ programs that do IO (or actions, or >>> computations, or )? It doesn't make sense, says I, >>> >> >> without reference to the rest of your message, of course values can /be/ >> programs. > > > Not "programs", but "programs that do IO". The point of the idiom is that > there's an external side effect involved. What sticks in my craw is that "a > mathematical value with a non-mathematical side effect" is, well, > non-mathematical and possibly nonsensical. I know it works for some (most?) > people, but for me it lacks Geometry and Theology. > > -g > > I think the point of the Monad is that it works as a container of stuff, that still allows mathematically pure things to happen, while possibly having some opaque "other stuff" going on. If you have a monadic add operation, and a Monad of some kind that "Contains an Integer", you can call the Monadic add operation on a pair of those monads, and some of the other monadic gluey-stuff that happens in between can combine the "other stuff" in specific ways, depending on how the Monad is defined. If it's the identity monad, it might not be that interesting, but if it's a writer monad, it might log things that are going on. m 1 + m 2 = m3, but what happened inside the "m" is entirely up to how that "m" is defined. Does that make it a little easier to understand? IO could have happened in the "m", but there's still a pure peace.... sometimes :-) (there's nothing stopping you reading an integer from the keyboard and returning it to totally break down that analogy I suppose). At least this is how I like to think of Monads. If you want more guarantees about operations, keep them pure, and then you only have to really scrutinize the monad-using bits to see where your program can get screwy. I realize that might not make the mathematician in you feel tons better, but *shrug*. Dave > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/cb29ed38/attachment.htm From haskell at list.mightyreason.com Thu Feb 5 14:20:39 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Feb 5 14:10:52 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <498B3C07.80708@list.mightyreason.com> Gregg Reynolds wrote: > getChar >>= \x -> getChar > > An optimizer can see that the result of the first getChar is discarded True, so 'x' is not used, and it can be garbage collected, and may not even be created. But that data dependency is simple not the data dependency that make IO sequential. Here is code from IOBase.lhs for GHC: > newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #)) The # are unboxed types and thus strict, but here we can erase them for clarity: newtype IO a = IO (State RealWorld -> (State RealWorld, a)) getChar is of type IO Char so that is constructor IO applied to a function from the "State RealWorld" to a strict pair of "State RealWorld" and Char. Since this is strict there is no laziness and the code must evaluate the input and output "State RealWorld" to ensure they are not bottom or error. Here is the rest of the plumbing in GHC: > unIO :: IO a -> (State# RealWorld -> (# State# RealWorld, a #)) > unIO (IO a) = a > > instance Functor IO where > fmap f x = x >>= (return . f) > > instance Monad IO where > {-# INLINE return #-} > {-# INLINE (>>) #-} > {-# INLINE (>>=) #-} > m >> k = m >>= \ _ -> k > return x = returnIO x > > m >>= k = bindIO m k > fail s = failIO s > > failIO :: String -> IO a > failIO s = ioError (userError s) > > liftIO :: IO a -> State# RealWorld -> STret RealWorld a > liftIO (IO m) = \s -> case m s of (# s', r #) -> STret s' r > > bindIO :: IO a -> (a -> IO b) -> IO b > bindIO (IO m) k = IO ( \ s -> > case m s of > (# new_s, a #) -> unIO (k a) new_s > ) > > thenIO :: IO a -> IO b -> IO b > thenIO (IO m) k = IO ( \ s -> > case m s of > (# new_s, _ #) -> unIO k new_s > ) > > returnIO :: a -> IO a > returnIO x = IO (\ s -> (# s, x #)) The "bind" operation's case statement forces the unboxed "new_s :: State# RealWorld" to be strictly evaluated, and this depends on the input strict "s :: State# RealWorld". This data dependency of new_s on s is what forces IO statements to evaluate sequentially. Cheers, Chris From jake at pikewerks.com Thu Feb 5 14:21:46 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 14:11:48 2009 Subject: [Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind) In-Reply-To: <87r62cg1ew.fsf@justinbogner.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> <87r62cg1ew.fsf@justinbogner.com> Message-ID: <498B3C4A.30408@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mail@justinbogner.com wrote: | [1..2] >>= return . (^2) | | This says "generate the list [1..2] and then use it to generate a list | of squares". It's more than just application, it's a description of a | sequence of actions. The whole point of list comprehensions (which is | the only reason to have a list monad, as far as I know) is to think | of it this way rather than as an application of concatMap. The problem with your description is that you said "and then." The result will be generated lazily. There is no sequencing here. Consider: ~ do x <- [0..] ~ y <- [0..9] ~ return (x, y) Which list is generated first? | As for Reader, I don't know enough about it to say anything. Reader provides an immutable value that can be retrieved at any point in the monad. There are no monadic side effects, so it doesn't really mean much to say that anything happens in any particular order. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLPEoACgkQye5hVyvIUKlaJACePGL6FdevDAmREsl/H9u7jjxS bKsAoMzEkpw6XjOVg4xql8d4NN47lg8d =jNtS -----END PGP SIGNATURE----- From wagner.andrew at gmail.com Thu Feb 5 14:25:29 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Feb 5 14:15:31 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> Message-ID: > > I think the point of the Monad is that it works as a container of stuff, >> that still allows mathematically pure things to happen, while possibly >> having some opaque "other stuff" going on. >> > This at least sounds, very wrong, even if it's not. Monads are not impure. IO is, but it's only _one_ instance of Monad. All others, as far as I know, are pure. It's just that the bind operation allows you to hide the stuff you don't want to have to worry about, that should happen every time you compose two monadic actions. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/66b0fd8d/attachment.htm From miguelimo38 at yandex.ru Thu Feb 5 14:34:04 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Feb 5 14:24:16 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> Message-ID: <8EB87D8B-4160-49BD-B8E7-103E0A3C5FA3@yandex.ru> Let's put it this way: suppose you have two data types, say, Int and String; a value s of type String and a function f :: String -> (Int -> String) -> String This could be anything - may be, a function which looks for the first character '#' in it's first argument and replaces it with the second argument applied to the position where it's found; so f "abc#" (\n -> replicate n 'q') = "abcqqq" It could be anything else, of course. Now, would you expect an optimizer to transform f s (\x -> s) to s? I don't think so. f s (\x -> s) and s are clearly distinct and there is no reason to transform one to the other. Now, let's change notation a bit. First of all, let's denote our string s by getChar. Well, it's our string and we can name it with what name we want - especially if we forget for a moment that getChar is already defined. So, for a moment we assume that getChar is defined like this: getChar = "abc#" Therefore, f getChar (\x -> getChar) is NOT equivalent to getChar. Right? Let's change notation even more. Let's denote our function by (>>=): (>>=) getChar (\x -> getChar) is NOT equal to getChar By Haskell rules we can use >>= as infix operator: getChar >>= (\x -> getChar) is NOT equal to getChar Now, in your example, instead of Int and String we have Char and IO Char. Does that matter? In all the above we didn't use the fact that our types are Int and String; the very same applies to Char and (IO Char) as well. On 5 Feb 2009, at 19:18, Gregg Reynolds wrote: > On Thu, Feb 5, 2009 at 9:53 AM, Gleb Alexeyev > wrote: > Let's imagine that IO datatype is defined thus: > > >{-# LANGUAGE GADTs #-} > >{-# LANGUAGE NoImplicitPrelude #-} > > >import Prelude(Monad, Char) > >data IO a where > > GetChar :: IO Char > > Bind :: IO a -> (a -> IO b) -> IO b > > >getChar = GetChar > >(>>=) = Bind > > It is perfectly possible to construct IO actions as values of this > data type and execute them by some function evalIO :: IO -> > Prelude.IO with the obvious definition. Now the question arises: do > you think > getChar >>= \x -> getChar would be optimized to getChar by compiler? > > I must be misunderstanding something. I don't know if it would be > optimized out, but I see no reason why it couldn't be. There's no > data dependency, right? > > -g > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From miguelimo38 at yandex.ru Thu Feb 5 14:41:10 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Feb 5 14:31:25 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> Message-ID: <82C4325C-2D8E-4079-88A9-22D636759CD3@yandex.ru> Ahem... WHAT??? IO monad is impure??? What do you mean? On 5 Feb 2009, at 22:25, Andrew Wagner wrote: > I think the point of the Monad is that it works as a container of > stuff, that still allows mathematically pure things to happen, while > possibly having some opaque "other stuff" going on. > > This at least sounds, very wrong, even if it's not. Monads are not > impure. IO is, but it's only _one_ instance of Monad. All others, as > far as I know, are pure. It's just that the bind operation allows > you to hide the stuff you don't want to have to worry about, that > should happen every time you compose two monadic actions. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From lennart at augustsson.net Thu Feb 5 14:46:58 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Feb 5 14:37:29 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> Message-ID: You are absolutely right. The statement "The values of the IO monad are programs that do IO. " is somewhat nonsensical. Values don't do anything, they just are. But values of the IO monad *describe* how to do IO; they can be seen as a recipe for doing IO. A recipe doesn't cook a dish, but when the recipe is executed by a cook they creates a dish. An IO values doesn't do IO, but when it is executed by the runtime system IO happens. This is one way of interpreting what the IO type means. (Another one is to say that Haskell is just an imperative programming language, but any imperative actions show up in the type.) -- Lennart 2009/2/4 Gregg Reynolds : > On Wed, Feb 4, 2009 at 11:41 AM, Tim Newsham wrote: >> >> I put up a small Monad explanation (I wouldn't quite call it >> a tutorial): >> http://www.thenewsh.com/~newsham/haskell/monad.html > > "The values of the IO monad are programs that do IO. " > > That's a fairly common representation, seems to work for lots of people, but > it caused me no end of trouble. Values are mathematical objects; how, I > asked myself, can they possibly /be/ programs that do IO (or actions, or > computations, or )? It doesn't make sense, says I, so I > must be misunderstanding something about "values"; better spend hours and > hours researching and trying to figure this out. But it turns out the > answer is simple: they can't. They're not actions, or IO procedures, or > anything else other than plain old mathematical values, no different than > '2' or Int -> Char. They happen to correspond in some way to the external > physical behavior of the program, but that correspondence is an > implementation detail beyond the scope of the formal (mathematical) > semantics of the language. You don't even need monads for this part; they > only enter the picture in order to provide ordered evaluation. In fact > there really aren't any "monadic values", since a monad is pure morphism; > the values at issue are "functoric values" if anything. It's (the > implementation of) getChar the does the IO, not IO Char. > > So you could say that the monad itself is a purely mathematical structure > that has the felicitous if accidental side effect of imposing temporal > sequence on the physical interpretation (events) associated with the > program. > > -g > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From lennart at augustsson.net Thu Feb 5 14:46:58 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Feb 5 14:40:24 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> Message-ID: You are absolutely right. The statement "The values of the IO monad are programs that do IO. " is somewhat nonsensical. Values don't do anything, they just are. But values of the IO monad *describe* how to do IO; they can be seen as a recipe for doing IO. A recipe doesn't cook a dish, but when the recipe is executed by a cook they creates a dish. An IO values doesn't do IO, but when it is executed by the runtime system IO happens. This is one way of interpreting what the IO type means. (Another one is to say that Haskell is just an imperative programming language, but any imperative actions show up in the type.) -- Lennart 2009/2/4 Gregg Reynolds : > On Wed, Feb 4, 2009 at 11:41 AM, Tim Newsham wrote: >> >> I put up a small Monad explanation (I wouldn't quite call it >> a tutorial): >> http://www.thenewsh.com/~newsham/haskell/monad.html > > "The values of the IO monad are programs that do IO. " > > That's a fairly common representation, seems to work for lots of people, but > it caused me no end of trouble. Values are mathematical objects; how, I > asked myself, can they possibly /be/ programs that do IO (or actions, or > computations, or )? It doesn't make sense, says I, so I > must be misunderstanding something about "values"; better spend hours and > hours researching and trying to figure this out. But it turns out the > answer is simple: they can't. They're not actions, or IO procedures, or > anything else other than plain old mathematical values, no different than > '2' or Int -> Char. They happen to correspond in some way to the external > physical behavior of the program, but that correspondence is an > implementation detail beyond the scope of the formal (mathematical) > semantics of the language. You don't even need monads for this part; they > only enter the picture in order to provide ordered evaluation. In fact > there really aren't any "monadic values", since a monad is pure morphism; > the values at issue are "functoric values" if anything. It's (the > implementation of) getChar the does the IO, not IO Char. > > So you could say that the monad itself is a purely mathematical structure > that has the felicitous if accidental side effect of imposing temporal > sequence on the physical interpretation (events) associated with the > program. > > -g > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dev at mobileink.com Thu Feb 5 14:55:25 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 14:45:26 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> Message-ID: <75cc17ac0902051155sbe73df1t2cd1ec28e5ec1edc@mail.gmail.com> On Thu, Feb 5, 2009 at 11:22 AM, Gleb Alexeyev wrote: > Gregg Reynolds wrote: > >> Are you saying that using equations to add a level of indirection >> prevents optimization? I still don't see it - discarding x doesn't >> change the semantics, so a good compiler /should/ do this. How is >> this different from optimizing out application of a constant function? >> > > Perhaps my example doesn't work, so I'll try another example. > As you know, (>>=) is just an (overloaded) higher-order function. > Let's consider another higher-order function, map. The expression >> map (\x -> 42) [1..3] > evaluates to [42, 42, 42]. > As you can see, the function (\x -> 42) passed to map ignores its first > argument. Would you expect the compiler to discard the call to map? No, but I might expect it to discard the function application and just replace each element of the list with 42. Which it may do at compile time. Plus, it will only be evaluated once, no matter how many times the expression occurs, since lazy evaluation memoizes results. > > Can you see the analogy? The shapes of the two expressions, map (\x -> 42) > [1..3] and (>>=) getChar (\x -> getChar) are similar. > > (>>=) is a combinator just like map, you cannot optimize it away in general. Ok, I see what you're getting at, but I have to think about it some more. Here's a restatement that might make my puzzlement more clear. Suppose we have f = \x -> 42 Then I would expect the compiler to replace each expression of the form f x with 42, for all x. Now suppose we write 7 >>= \x -> 42. It seems to me that a compiler could examine that expression, conclude that it is constant, and replace it with the expression 42. So far as I know, there's nothing in the semantics of Haskell to forbid this, so why not do it? There are no side effects, and an optimizer can always substitute equals for equals, no? (Let's disregard the fact that such optimizations may be hard or expensive.) This is different from map, because unlike map it doesn't need to perform a computation (i.e. execute the function) to arrive at the final value; it only has to analyze the function (which is computation but not computation of the function itself.) Now getChar is a value of type IO Char, by definition. That means mathematical value - "an action that does some IO" won't cut it in a formal semantics, since there is no way to express "does some IO" formally. Values is values; they don't "do" anything. So we should be able to replace 7 and 42 above by getChar, and do the same optimization. Do you see why this is problematic for me? In any case, you're responses (and the others) have been quite useful and have helped me work through some problems with a rather radical idea I have to address this that I hope to write up this weekend. Thanks, gregg From mail at justinbogner.com Thu Feb 5 14:56:58 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Feb 5 14:47:13 2009 Subject: [Haskell-cafe] Re: Bind as a sequencing operator References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> <87r62cg1ew.fsf@justinbogner.com> <498B3C4A.30408@pikewerks.com> Message-ID: <87myd0fyid.fsf@justinbogner.com> Jake McArthur writes: > The problem with your description is that you said "and then." The > result will be generated lazily. There is no sequencing here. Consider: > > ~ do x <- [0..] > ~ y <- [0..9] > ~ return (x, y) > > Which list is generated first? > This is an implementation detail, since y has no dependency on x the compiler's free to reorder instructions, as it would be an imperative language. Semantically this means do x and then y, since if y is changed to depend on x, this is still valid, but if x is changed to depend on y, this sequence is not valid. Just because the compiler is allowed (and even encouraged) to change the sequence where that won't change the results, considering this a sequence is still valid and meaningful. > | As for Reader, I don't know enough about it to say anything. > > Reader provides an immutable value that can be retrieved at any point in > the monad. There are no monadic side effects, so it doesn't really mean > much to say that anything happens in any particular order. > It still needs to be retrieved (logically, not necessarily temporally) before it's used, doesn't it? > - Jake From dev at mobileink.com Thu Feb 5 15:03:37 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 14:53:36 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> Message-ID: <75cc17ac0902051203l5a865ff5nfff6dba7abe06cd5@mail.gmail.com> On Thu, Feb 5, 2009 at 1:46 PM, Lennart Augustsson wrote: > You are absolutely right. The statement > "The values of the IO monad are programs that do IO. " > is somewhat nonsensical. Values don't do anything, they just are. Whew! So I'm not crazy. I was starting to wonder. > But values of the IO monad *describe* how to do IO; they can be seen > as a recipe for doing IO. > A recipe doesn't cook a dish, but when the recipe is executed by a > cook they creates a dish. > An IO values doesn't do IO, but when it is executed by the runtime > system IO happens. > > This is one way of interpreting what the IO type means. > (Another one is to say that Haskell is just an imperative programming > language, but any imperative actions show up in the type.) > Thanks very much to you and everybody who contributed on the thread. It's amazing how much one can learn on this list. -gregg From iliya.kuznetsov at gmail.com Thu Feb 5 15:13:56 2009 From: iliya.kuznetsov at gmail.com (Iliya Kuznetsov) Date: Thu Feb 5 15:03:58 2009 Subject: [Haskell-cafe] Success (was: cURL under Windows again) Message-ID: The problem has solved. Solution, given by http://awson.livejournal.com/, is: 1. Copy libcurl-4.dll to libcurl.dll beause of namescheme 2. Before building haskell curl-1.3.4 _under windows_ you have to change #define CURL_EXTERN __declspec(dllimport) to #define CURL_EXTERN. After that, curl-7.19.3 and curl-1.3.4 work fine. ---------- Forwarded message ---------- From: Iliya Kuznetsov Date: 2009/2/2 Subject: cURL under Windows again To: haskell-cafe@haskell.org Hello cafe-subscribers, I saw some issues about installing haskell bindings for cURL under Windows, and now I'm trapped too. So, here is actions' log for everything (very detail; you can PgDn to the end with questions): 1. Windows Vista without UAC 2. ghc-6.10.1-i386-windows.exe is installed to C:\Program Files\Haskell "C:\Program Files\Haskell\package.conf" wasn't touched after installation (Cabal nor manually) 3. MinGW-5.1.4 installed to C:\temp\MinGW 4. MSys-1.0 installed to C:\temp\msys\1.0\ 5. curl-7.19.3.tar.bz2 had taken from http://curl.haxx.se/download/curl-7.19.3.tar.bz2 6. Under msys, curl-7.19.3.tar.bz2 is untared into /home/Kuznetsov/curl-7.19.3 7. cURL is made as: cd curl-7.19.3 $ ./configure configure: Configured to build curl/libcurl: ... curl version: 7.19.3 Host setup: i686-pc-mingw32 Install prefix: /usr/local Compiler: gcc SSL support: no (--with-ssl / --with-gnutls) SSH support: no (--with-libssh2) zlib support: no (--with-zlib) krb4 support: no (--with-krb4*) GSSAPI support: no (--with-gssapi) SPNEGO support: no (--with-spnego) c-ares support: no (--enable-ares) ipv6 support: no (--enable-ipv6) IDN support: no (--with-libidn) Build libcurl: Shared=yes, Static=yes Built-in manual: no (--enable-manual) Verbose errors: enabled (--disable-verbose) SSPI support: no (--enable-sspi) ca cert bundle: no ca cert path: no LDAP support: enabled (winldap) LDAPS support: no (--enable-ldaps) $ make ... make[2]: Leaving directory `/home/Kuznetsov/curl-7.19.3/src' make[1]: Leaving directory `/home/Kuznetsov/curl-7.19.3/src' make[1]: Entering directory `/home/Kuznetsov/curl-7.19.3' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/home/Kuznetsov/curl-7.19.3' $ make install ... libtool: install: /bin/install -c .libs/libcurl.dll.a /usr/local/lib/libcurl.dll.a libtool: install: base_file=`basename libcurl.la` libtool: install: dlpath=`/bin/sh 2>&1 -c '. .libs/'libcurl.la'i; echo libcurl-4.dll'` libtool: install: dldir=/usr/local/lib/`dirname ../bin/libcurl-4.dll` libtool: install: test -d /usr/local/lib/../bin || mkdir -p /usr/local/lib/../bin libtool: install: /bin/install -c .libs/libcurl-4.dll /usr/local/lib/../bin/libcurl-4.dll libtool: install: chmod a+x /usr/local/lib/../bin/libcurl-4.dll libtool: install: if test -n '' && test -n 'strip --strip-unneeded'; then eval 'strip --strip-unneeded /usr/local/lib/../bin/libcurl-4.dll' || exit 0; fi libtool: install: /bin/install -c .libs/libcurl.lai /usr/local/lib/ libcurl.la libtool: install: /bin/install -c .libs/libcurl.a /usr/local/lib/libcurl.a libtool: install: chmod 644 /usr/local/lib/libcurl.a libtool: install: ranlib /usr/local/lib/libcurl.a ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-LLIBDIR' linker flag ... /bin/install -c -m 644 'curl.h' '/usr/local/include/curl/curl.h' /bin/install -c -m 644 'curlver.h' '/usr/local/include/curl/curlver.h' /bin/install -c -m 644 'easy.h' '/usr/local/include/curl/easy.h' /bin/install -c -m 644 'mprintf.h' '/usr/local/include/curl/mprintf.h' /bin/install -c -m 644 'stdcheaders.h' '/usr/local/include/curl/stdcheaders.h' /bin/install -c -m 644 'types.h' '/usr/local/include/curl/types.h' /bin/install -c -m 644 'multi.h' '/usr/local/include/curl/multi.h' /bin/install -c -m 644 'typecheck-gcc.h' '/usr/local/include/curl/typecheck-gcc.h' /bin/install -c -m 644 'curlbuild.h' '/usr/local/include/curl/curlbuild.h' /bin/install -c -m 644 'curlrules.h' '/usr/local/include/curl/curlrules.h' ... 8. $ which curl && curl /usr/local/bin/curl curl: try 'curl --help' for more information I have following files in C:\temp\msys\1.0\local\bin\ (/usr/local/bin in Unix-scheme): 02.02.2009 15:10 4 029 curl-config 02.02.2009 15:10 98 591 curl.exe 02.02.2009 15:09 262 934 libcurl-4.dll In /usr/local/include/curl ten includes: 02.02.2009 15:10 67 183 curl.h 02.02.2009 15:10 5 865 curlbuild.h 02.02.2009 15:10 7 478 curlrules.h 02.02.2009 15:10 2 799 curlver.h 02.02.2009 15:10 3 526 easy.h 02.02.2009 15:10 2 850 mprintf.h 02.02.2009 15:10 13 039 multi.h 02.02.2009 15:10 1 383 stdcheaders.h 02.02.2009 15:10 33 337 typecheck-gcc.h 02.02.2009 15:10 15 types.h ---- Sorry for many details, but now I can show the wrong behaviour of the haskell bindings for cURL under windows: 9. curl-1.3.4 is taken from hackage and unzipped to /home/Kuznetsov $ cd ~/curl-1.3.4 $ runhaskell Setup.hs configure --extra-include-dirs=/usr/local/include --extra-lib-dirs=/usr/local/lib Configuring curl-1.3.4... $ runhaskell Setup.hs build Preprocessing library curl-1.3.4... Building curl-1.3.4... [1 of 8] Compiling Network.Curl.Debug ( Network\Curl\Debug.hs, dist\build\Network\Curl\Debug.o ) [2 of 8] Compiling Network.Curl.Types ( Network\Curl\Types.hs, dist\build\Network\Curl\Types.o ) [3 of 8] Compiling Network.Curl.Post ( Network\Curl\Post.hs, dist\build\Network\Curl\Post.o ) [4 of 8] Compiling Network.Curl.Opts ( Network\Curl\Opts.hs, dist\build\Network\Curl\Opts.o ) [5 of 8] Compiling Network.Curl.Code ( Network\Curl\Code.hs, dist\build\Network\Curl\Code.o ) [6 of 8] Compiling Network.Curl.Info ( Network\Curl\Info.hs, dist\build\Network\Curl\Info.o ) Network\Curl\Info.hs:80:0: Warning: Defined but not used: `stringTag' Network\Curl\Info.hs:83:0: Warning: Defined but not used: `longTag' Network\Curl\Info.hs:86:0: Warning: Defined but not used: `doubleTag' Network\Curl\Info.hs:89:0: Warning: Defined but not used: `slistTag' [7 of 8] Compiling Network.Curl.Easy ( Network\Curl\Easy.hs, dist\build\Network\Curl\Easy.o ) [8 of 8] Compiling Network.Curl ( Network\Curl.hs, dist\build\Network\Curl.o ) C:\Program Files\Haskell\bin\ar.exe: creating dist\build\libHScurl-1.3.4.a $ runhaskell Setup.hs install Installing library in C:\Program Files\Haskell\curl-1.3.4\ghc-6.10.1 Registering curl-1.3.4... Reading package info from "dist\\installed-pkg-config" ... done. Writing new package config file... done. 10. In package.conf I have seen: InstalledPackageInfo {package = PackageIdentifier {pkgName = PackageName "curl", pkgVersion = Version {versionBranch = [1,3,4], versionTags = []}}, license = BSD3, copyright = "", maintainer = "Sigbjorn Finne < sigbjorn.finne@gmail.com>", author = "Sigbjorn Finne", stability = "", homepage = "", pkgUrl = "", description = "libcurl is a client-side URL transfer library, supporting FTP, FTPS, HTTP,\nHTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE.\nlibcurl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading,\nHTTP form based upload, proxies, cookies, user+password authentication\n(Basic, Digest, NTLM, Negotiate, Kerberos4), file transfer resume,\nhttp proxy tunneling and more!\n\nThis package provides a Haskell binding to libcurl.", category = "Network", exposed = True, exposedModules = ["Network.Curl","Network.Curl.Code"," Network.Curl.Info ","Network.Curl.Opts","Network.Curl.Post","Network.Curl.Types","Network.Curl.Easy","Network.Curl.Debug"], hiddenModules = [], importDirs = ["C:\\Program Files\\Haskell\\curl-1.3.4\\ghc-6.10.1"], libraryDirs = ["C:\\Program Files\\Haskell\\curl-1.3.4\\ghc-6.10.1","C:/temp/msys/1.0/local/lib"], hsLibraries = ["HScurl-1.3.4"], extraLibraries = ["curl"], extraGHCiLibraries = [], includeDirs = ["C:/temp/msys/1.0/local/include"], includes = [], depends = [PackageIdentifier {pkgName = PackageName "base", pkgVersion = Version {versionBranch = [3,0,3,0], versionTags = []}},PackageIdentifier {pkgName = PackageName "bytestring", pkgVersion = Version {versionBranch = [0,9,1,4], versionTags = []}},PackageIdentifier {pkgName = PackageName "containers", pkgVersion = Version {versionBranch = [0,2,0,0], versionTags = []}}], hugsOptions = [], ccOptions = [], ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces = ["C:\\Program Files\\Haskell\\doc\\curl-1.3.4\\html\\curl.haddock"], haddockHTMLs = ["C:\\Program Files\\Haskell\\doc\\curl-1.3.4\\html"]} In "C:\Program Files\Haskell\curl-1.3.4\ghc-6.10.1\" I have seen HScurl-1.3.4.o , libHScurl-1.3.4.a and other Curl files. 11. Final tests: under msys: $ ghci Prelude> :m Network.Curl module `Network.Curl' is not loaded Bad, but not a disaster. under windows: C:\> ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m Network.Curl Prelude Network.Curl> let a = curlGet Loading package syb ... linking ... done. Loading package base-3.0.3.0 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package curl-1.3.4 ... : curl: ?? ?????? ????????? ??????. (text in russian here because of localized Vista. The message is near "Can't load specified module") can't load .so/.DLL for: curl (addDLL: could not load DLL) Prelude Network.Curl> So, the question is why curl doesn't work? I tried to use Cabal but it failed with building too. How can I test the fact that C:\temp\msys\1.0\local\bin\libcurl-4.dll is used in curl-1.3.4 ? -- Iliya Kuznetsov +7-916-878-75-70 -- Iliya Kuznetsov +7-916-878-75-70 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/25caee52/attachment.htm From jonathanccast at fastmail.fm Thu Feb 5 15:14:39 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 15:08:55 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> Message-ID: <1233864879.19682.40.camel@jcchost> On Thu, 2009-02-05 at 20:46 +0100, Lennart Augustsson wrote: > You are absolutely right. The statement > "The values of the IO monad are programs that do IO. " > is somewhat nonsensical. Values don't do anything, they just are. Technically, programs don't do anything either. I think of values of type IO a as being --- conceptually --- arbitrary sequences of machine code instructions. Just like a sequence of machine code instructions can be stored away in /bin/cat, and not do anything, an IO value needn't do anything, either. Until it's stored in memory and the instruction pointer set to its first instruction. At which point, if you want to get really picky, it's still the CPU doing things. Which it is told to do by its fixed microcode. Which tells it to look at your program to see what to do. Which = looking at the `value' of your IO-typed expression to see what to do. jcc From leimy2k at gmail.com Thu Feb 5 15:21:31 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Feb 5 15:11:33 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> Message-ID: <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner wrote: > I think the point of the Monad is that it works as a container of stuff, >>> that still allows mathematically pure things to happen, while possibly >>> having some opaque "other stuff" going on. >>> >> > This at least sounds, very wrong, even if it's not. Monads are not impure. > IO is, but it's only _one_ instance of Monad. All others, as far as I know, > are pure. It's just that the bind operation allows you to hide the stuff you > don't want to have to worry about, that should happen every time you compose > two monadic actions. > Well all I can tell you is that I can have (IO Int) in a function as a return, and the function is not idempotent in terms of the "stuff" inside IO being the same. Sounds impure to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/7cc157f3/attachment.htm From newsham at lava.net Thu Feb 5 15:21:21 2009 From: newsham at lava.net (Tim Newsham) Date: Thu Feb 5 15:11:43 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> Message-ID: > You are absolutely right. The statement > "The values of the IO monad are programs that do IO. " > is somewhat nonsensical. Values don't do anything, they just are. > But values of the IO monad *describe* how to do IO; they can be seen > as a recipe for doing IO. > A recipe doesn't cook a dish, but when the recipe is executed by a > cook they creates a dish. > An IO values doesn't do IO, but when it is executed by the runtime > system IO happens. Just as a recipe describes how to cook something, a program describes how to accomplish something. The program doesnt "do" anything until it is executed. However, we often use the word "do" to describe what a program will do when executed (even though its really the cpu that is actually "doing"). > This is one way of interpreting what the IO type means. > (Another one is to say that Haskell is just an imperative programming > language, but any imperative actions show up in the type.) I don't see the difference between these two interpretations. Wether the program is made up of instructions for a cpu or for an interpreter seems irrelevant. > -- Lennart Tim Newsham http://www.thenewsh.com/~newsham/ From wagner.andrew at gmail.com Thu Feb 5 15:25:15 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Feb 5 15:15:15 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> Message-ID: On Thu, Feb 5, 2009 at 3:21 PM, David Leimbach wrote: > > Well all I can tell you is that I can have (IO Int) in a function as a > return, and the function is not idempotent in terms of the "stuff" inside IO > being the same. > > Sounds impure to me. > Right, thus IO is impure. but as long as the function that returns the IO Int returns the same IO Int every time you provide the same input, it's pure. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/7e5552d2/attachment.htm From leimy2k at gmail.com Thu Feb 5 15:27:23 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Feb 5 15:17:24 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> Message-ID: <3e1162e60902051227x19e89143rb2d276cd8ab04716@mail.gmail.com> On Thu, Feb 5, 2009 at 12:25 PM, Andrew Wagner wrote: > On Thu, Feb 5, 2009 at 3:21 PM, David Leimbach wrote: > >> >> Well all I can tell you is that I can have (IO Int) in a function as a >> return, and the function is not idempotent in terms of the "stuff" inside IO >> being the same. >> >> Sounds impure to me. >> > > Right, thus IO is impure. but as long as the function that returns the IO > Int returns the same IO Int every time you provide the same input, it's > pure. > Ah yes I see your point... that's true absolutely. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/ee4bba6e/attachment.htm From jonathanccast at fastmail.fm Thu Feb 5 15:27:01 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 15:19:17 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> Message-ID: <1233865621.19682.43.camel@jcchost> On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > wrote: > I think the point of the Monad is that it > works as a container of stuff, that still > allows mathematically pure things to happen, > while possibly having some opaque "other > stuff" going on. > This at least sounds, very wrong, even if it's not. Monads > are not impure. IO is, but it's only _one_ instance of Monad. > All others, as far as I know, are pure. It's just that the > bind operation allows you to hide the stuff you don't want to > have to worry about, that should happen every time you compose > two monadic actions. > Well all I can tell you is that I can have (IO Int) in a function as a > return, and the function is not idempotent in terms of the "stuff" > inside IO being the same. Sure it's the same. > cmp /bin/cat /bin/cat > cp /bin/cat ~ > cmp /bin/cat ~/cat > Pretty much the same, anyway. jcc From jake at pikewerks.com Thu Feb 5 15:32:49 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 15:22:49 2009 Subject: [Haskell-cafe] Re: Bind as a sequencing operator In-Reply-To: <87myd0fyid.fsf@justinbogner.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> <87r62cg1ew.fsf@justinbogner.com> <498B3C4A.30408@pikewerks.com> <87myd0fyid.fsf@justinbogner.com> Message-ID: <498B4CF1.4030300@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mail@justinbogner.com wrote: | Jake McArthur writes: |> The problem with your description is that you said "and then." The |> result will be generated lazily. There is no sequencing here. Consider: |> |> ~ do x <- [0..] |> ~ y <- [0..9] |> ~ return (x, y) |> |> Which list is generated first? |> | | This is an implementation detail, since y has no dependency on x the | compiler's free to reorder instructions, as it would be an imperative | language. Semantically this means do x and then y That the order does not matter is definitely not an implementation detail. Order not mattering is exactly what declarative programming is about. The semantics of the above expression are the same as this: ~ (<$> [0..9]) . (,) =<< [0..] There is no "do X and then do Y," only "this is what I want." Declarative semantics. As I said, just because do notation makes it look imperative doesn't mean it actually is. | Just because the compiler is allowed (and even encouraged) to change the | sequence where that won't change the results, considering this a | sequence is still valid and meaningful. It can be helpful sometimes, but I don't think it should be the standard way to think of bind. There are too many cases when it makes little sense as a sequencing operator. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLTPEACgkQye5hVyvIUKkoCACgz/IYvxa6PoEvuqgxljGAwZ8+ TXQAn30MyLDwhLyZV3+dRuJvttx93ZNh =P9em -----END PGP SIGNATURE----- From wagner.andrew at gmail.com Thu Feb 5 15:38:34 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Feb 5 15:28:38 2009 Subject: [Haskell-cafe] Re: Bind as a sequencing operator In-Reply-To: <498B4CF1.4030300@pikewerks.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> <87r62cg1ew.fsf@justinbogner.com> <498B3C4A.30408@pikewerks.com> <87myd0fyid.fsf@justinbogner.com> <498B4CF1.4030300@pikewerks.com> Message-ID: bind is no more a sequencing operator than function composition is. Just as the order in which you pass two functions (ignoring the type issue for the moment) matters, the order in which you pass things to bind matters. The sense in which the order _doesn't_ matter is that of the order in which what you pass gets evaluated. On Thu, Feb 5, 2009 at 3:32 PM, Jake McArthur wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > mail@justinbogner.com wrote: > | Jake McArthur writes: > |> The problem with your description is that you said "and then." The > |> result will be generated lazily. There is no sequencing here. Consider: > |> > |> ~ do x <- [0..] > |> ~ y <- [0..9] > |> ~ return (x, y) > |> > |> Which list is generated first? > |> > | > | This is an implementation detail, since y has no dependency on x the > | compiler's free to reorder instructions, as it would be an imperative > | language. Semantically this means do x and then y > > That the order does not matter is definitely not an implementation > detail. Order not mattering is exactly what declarative programming is > about. The semantics of the above expression are the same as this: > > ~ (<$> [0..9]) . (,) =<< [0..] > > There is no "do X and then do Y," only "this is what I want." > Declarative semantics. As I said, just because do notation makes it look > imperative doesn't mean it actually is. > > | Just because the compiler is allowed (and even encouraged) to change the > | sequence where that won't change the results, considering this a > | sequence is still valid and meaningful. > > It can be helpful sometimes, but I don't think it should be the standard > way to think of bind. There are too many cases when it makes little > sense as a sequencing operator. > > - - Jake > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmLTPEACgkQye5hVyvIUKkoCACgz/IYvxa6PoEvuqgxljGAwZ8+ > TXQAn30MyLDwhLyZV3+dRuJvttx93ZNh > =P9em > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/5eb4925d/attachment.htm From leimy2k at gmail.com Thu Feb 5 16:01:38 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Feb 5 15:51:42 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <1233865621.19682.43.camel@jcchost> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> <1233865621.19682.43.camel@jcchost> Message-ID: <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast wrote: > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > > wrote: > > I think the point of the Monad is that it > > works as a container of stuff, that still > > allows mathematically pure things to happen, > > while possibly having some opaque "other > > stuff" going on. > > > This at least sounds, very wrong, even if it's not. Monads > > are not impure. IO is, but it's only _one_ instance of Monad. > > All others, as far as I know, are pure. It's just that the > > bind operation allows you to hide the stuff you don't want to > > have to worry about, that should happen every time you compose > > two monadic actions. > > > > Well all I can tell you is that I can have (IO Int) in a function as a > > return, and the function is not idempotent in terms of the "stuff" > > inside IO being the same. > > Sure it's the same. > > > cmp /bin/cat /bin/cat > > cp /bin/cat ~ > > cmp /bin/cat ~/cat > > > > Pretty much the same, anyway. > > jcc > > So if IO represents a program that when executed interacts with the world's state, is it safe to say that when I return (State Int Int), that I'm returning a "State program"? That'd make sense as it really does look like we force the State to be evaluated with runState, evalState or execState. The only difference with IO then is that to get IO programs to run, you have to do it inside another IO program. I hope I'm not making this worse! :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/57c34e65/attachment-0001.htm From wagner.andrew at gmail.com Thu Feb 5 16:11:17 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Feb 5 16:01:19 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe Message-ID: So we all know the age-old rule of thumb, that unsafeXXX is simply evil and anybody that uses it should be shot (except when it's ok). I understand that unsafeXXX allows impurity, which defiles our ability to reason logically about haskell programs like we would like to. My question is, to what extent is this true? Suppose we had a module, UnsafeRandoms, which had a function that would allow you to generate a different random number every time you call it. The semantics are relatively well-defined, impurity is safely sectioned off in its own impure module, which is clearly labeled as such. How much damage does this do? Can we push the lines elsewhere? Is sectioning unsafeXXX into Unsafe modules a useful idiom that we can use for other things as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/e24438ba/attachment.htm From kkwweett at hotmail.fr Thu Feb 5 16:30:12 2009 From: kkwweett at hotmail.fr (Paul Langevin) Date: Thu Feb 5 16:20:13 2009 Subject: [Haskell-cafe] Re: OpenAL Message-ID: >Does the example code at >http://articles.bluishcoder.co.nz/Haskell/OpenAL work for anyone? sorry for the delay, Brian : I can hear the two sounds one after the other (I wish I knew how to hear them at the same time). However, I've got a strange error message from ALSA : " alsa_blitbuffer: Could not write audio data to sound device: File descriptor in bad state mixer: pcm.c:2644: snd_pcm_areas_copy: Assertion 'dst_areas' failed. " (mixer is the name of the executable (because I thought...)) OpenAL version : 1.3 ALC version : 1.0 AL version : 1.1 Ghc version : 6.6 _________________________________________________________________ T?l?phonez gratuitement ? tous vos proches avec Windows Live Messenger? !? T?l?chargez-le maintenant !? http://www.windowslive.fr/messenger/1.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/a285daba/attachment.htm From jonathanccast at fastmail.fm Thu Feb 5 16:33:13 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 16:25:31 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: References: Message-ID: <1233869593.19682.61.camel@jcchost> On Thu, 2009-02-05 at 16:11 -0500, Andrew Wagner wrote: > So we all know the age-old rule of thumb, that unsafeXXX is simply > evil and anybody that uses it should be shot (except when it's ok). > I understand that unsafeXXX allows impurity, which defiles our ability > to reason logically about haskell programs like we would like to. Not just that! Parametric polymorphism is unsound in combination with mutable values; but unsafePerformIO turns on exactly that combination. unsafeCoerce :: alpha -> beta unsafeCoerce x = unsafePerformIO $ do let r = unsafePerformIO $ newIORef undefined r `writeIORef` x readIORef r > My question is, to what extent is this true? unsafePerformIO is a true function --- in the absence of any fancy compiler trickery --- on a small subset of its domain. Outside of that subset, I would regard use of unsafePerformIO simply as a bug --- violation of an unchecked precondition. Period. > Suppose we had a module, UnsafeRandoms, which had a function that > would allow you to generate a different random number every time you > call it. unsafePerformIO does not allow you to guarantee this! If I defined myRandomNumber = unsafePerformIO $ randomNumber then the compiler is permitted to call randomNumber (at most) *once*, and use that number throughout the program. > The semantics are relatively well-defined, Leaving aside the issue above, I would think complete randomness was nearly the worst possible case, semantically. (The *worst* worst possible case would be non-statistical non-determinism --- which is what you actually get here). > impurity is safely sectioned off in its own impure module, which is > clearly labeled as such. How much damage does this do? Well, it forces me to chase your libraries import lists to decide whether I want to trust your code, for one thing. Haskell is all about making it easier to audit code, not harder. > Can we push the lines elsewhere? I'd rather not. > Is sectioning unsafeXXX into Unsafe modules a useful idiom that we can > use for other things as well? I'd rather not write other unsafe functions at all. Sectioning off things that need to be unsafe into pure solutions --- like, say, monads --- is a much better idea. (Go read the global variables thread from last year). jcc From jake at pikewerks.com Thu Feb 5 16:36:51 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 16:26:51 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: References: Message-ID: <498B5BF3.5060405@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Wagner wrote: | I understand that unsafeXXX allows impurity, which defiles our ability | to reason logically about haskell programs like we would like to. My | question is, to what extent is this true? My opinion is that unsafeXXX is acceptable only when its use is preserved behind an abstraction that is referentially transparent and type safe. Others may be able to help refine this statement. | Suppose we had a module, UnsafeRandoms, which had a function that would | allow you to generate a different random number every time you call it. | The semantics are relatively well-defined, impurity is safely sectioned | off in its own impure module, which is clearly labeled as such. How much | damage does this do? This does not preserve referential transparency, so by my criteria above this is an unacceptable use of an unsafe function. One reason it's a bad idea is that it removes determinism, which may be very important for testability. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLW/MACgkQye5hVyvIUKniOACfQGPLiY65+eiMfsv7BlbYLI++ Bd0An1N5wp6TDkJzhmdw831/Gj45Bv9S =TnQg -----END PGP SIGNATURE----- From lemming at henning-thielemann.de Thu Feb 5 17:19:35 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 5 17:02:36 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> Message-ID: <498B65F7.4010708@henning-thielemann.de> Yitzchak Gale schrieb: > Manlio Perillo wrote: >> However there is still a *big* problem: it is inefficient. >> >> Here is a Python version of the Chudnovsky algorithm [1] for computing Pi: >> http://paste.pocoo.org/show/102800/ >> On my system it takes 10 seconds. >> Here is an Haskell version: >> http://paste.pocoo.org/show/102801/ >> On my system it takes 30 seconds. > > Ah, OK. Thanks. Now we have a well-defined problem. :) You would not need to handle huge interim results, if you compute the factorials incrementally. E.g. (n+1)!^3 = n!^3 * (n+1)^3 etc. 'scanl' is your friend. This should also be faster. From bugfact at gmail.com Thu Feb 5 17:16:56 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 5 17:07:04 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: <498B5BF3.5060405@pikewerks.com> References: <498B5BF3.5060405@pikewerks.com> Message-ID: I do have asked myself the question whether a "really random generating" function could be regarded as "pure" somehow (actually would a true random function still be a mathematical function?) E.g. the function would return a true (not pseudo) random number, practically unpredictable (e.g. hardware assisted, using some physical phenomenon, e.g. using atmospheric noise or something). So you surely won't get referential transparency but since the function is really random, this would be correct behavior? Of course you could just put this random generator in the IO monad, but certain algorithms- like Monte Carlo - intuitively don't seem to operate in a IO monad to me. Okay, just some thoughts from someone who knows absolutely nothing about category theory or advanced computer science, so don't shoot me ;-) On Thu, Feb 5, 2009 at 10:36 PM, Jake McArthur wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Wagner wrote: > | I understand that unsafeXXX allows impurity, which defiles our ability > | to reason logically about haskell programs like we would like to. My > | question is, to what extent is this true? > > My opinion is that unsafeXXX is acceptable only when its use is > preserved behind an abstraction that is referentially transparent and > type safe. Others may be able to help refine this statement. > > | Suppose we had a module, UnsafeRandoms, which had a function that would > | allow you to generate a different random number every time you call it. > | The semantics are relatively well-defined, impurity is safely sectioned > | off in its own impure module, which is clearly labeled as such. How much > | damage does this do? > > This does not preserve referential transparency, so by my criteria above > this is an unacceptable use of an unsafe function. One reason it's a bad > idea is that it removes determinism, which may be very important for > testability. > > - - Jake > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmLW/MACgkQye5hVyvIUKniOACfQGPLiY65+eiMfsv7BlbYLI++ > Bd0An1N5wp6TDkJzhmdw831/Gj45Bv9S > =TnQg > -----END PGP SIGNATURE----- > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/7eb748bf/attachment.htm From max.rabkin at gmail.com Thu Feb 5 17:22:45 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Thu Feb 5 17:12:46 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: References: <498B5BF3.5060405@pikewerks.com> Message-ID: 2009/2/5 Peter Verswyvelen : > Of course you could just put this random generator in the IO monad, but > certain algorithms- like Monte Carlo - intuitively don't seem to operate in > a IO monad to me. For PRNGs, only State is needed, not IO. But you might find the `randoms' function useful: it returns in infinite list of pseudo-random values. --Max From lemming at henning-thielemann.de Thu Feb 5 17:34:53 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 5 17:17:36 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs In-Reply-To: References: Message-ID: <498B698D.6070005@henning-thielemann.de> Peter Verswyvelen schrieb: > 3) hg addrem > this adds new files and removes deleted files from local repos. > forgetting to add files is a common problem, and is really tricky since > no record is made of these files, so if after a couple of versions if a > developer finds out a file was missing, the history is useless since you > can't reconstruct the old content of that local file anymore, and often > it's impossible to give the local file to the other developers since it > might be changed. I actually would like to have an option that > automatically adds/deletes files on each commit, as it is easier to > delete a file after it is checked in, than it is to reconstruct an old > version from a local file you forgot to add. I'm also not glad with darcs behaviour about non-added files. You can try darcs whatsnew --look-for-adds David Roundy's philosophy is that you must add a test compilation with 'darcs setprefs' anyway and this one reveals forgotten files. > 4) hg commit -m "message" > this commits my changes locally. I always do this before pulling since > then I'm sure my changes are saved in the case a merge goes wrong. In old darcs its precisely the other way round. Since it is so slow on merging ready patches, you better merge uncrecorded changes. From temp.public at gmail.com Thu Feb 5 17:28:19 2009 From: temp.public at gmail.com (TKM) Date: Thu Feb 5 17:19:29 2009 Subject: [Haskell-cafe] Signatures in defining functions Message-ID: Hello, I'm kind of new with Haskell and I would like to know about the following: [some function]:: Int -> Int -> Int Now is my question, how should I interpret "Int -> Int -> Int"? Meaning what does "Int -> Int -> Int" mean? Thank you for answering my question. Kind Regards, JTKM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/c95aa730/attachment.htm From jake at pikewerks.com Thu Feb 5 17:31:10 2009 From: jake at pikewerks.com (Jake McArthur) Date: Thu Feb 5 17:21:11 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: References: <498B5BF3.5060405@pikewerks.com> Message-ID: <498B68AE.70106@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Verswyvelen wrote: | I do have asked myself the question whether a "really random generating" | function could be regarded as "pure" somehow (actually would a true | random function still be a mathematical function?) | | E.g. the function would return a true (not pseudo) random number, | practically unpredictable (e.g. hardware assisted, using some physical | phenomenon, e.g. using atmospheric noise or something). So you surely | won't get referential transparency but since the function is really | random, this would be correct behavior? An informal definition of a function might be something like a black box that takes and input and produces an output, and for each possible input, the output must be the same. Taking this to be a function, there is really no such thing as a random function, and if there was, it wouldn't even need to be a function. (What would the input to it be?) If you wanted to mathematically represent a random number, it would, in most cases I can think of, best be represented as a free variable. In a program, such a free variable could be filled in by the runtime. Conveniently, (and by no coincidence) this is something the IO monad can provide for us! :) | Of course you could just put this random generator in the IO monad, but | certain algorithms- like Monte Carlo - intuitively don't seem to operate | in a IO monad to me. Why not? A Random monad might be more appropriate in this case anyway. Such a monad is a State monad that hold a random seed. Every time a random number is needed, the seed is passed to a deterministic psuedo-random number generator, and a new seed is put as the next state. If a truly random number is ever needed, either IO or unsafeInterleaveIO will be needed. The use of unsafeInterleaveIO would be a (rightly) controversial choice though. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmLaK4ACgkQye5hVyvIUKk88QCfRksu7z80QmzgjUvmiyrzDDjl QnsAn1R5DHz2tJpWP3yb0+U+loyBdyCX =RIX9 -----END PGP SIGNATURE----- From marcot at holoscopio.com Thu Feb 5 17:38:31 2009 From: marcot at holoscopio.com (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Thu Feb 5 17:28:39 2009 Subject: [Haskell-cafe] Error in building profiling Message-ID: <1233873511.18688.143.camel@quindinho.domain.invalid> Hello, I'm trying to package ghc-paths for debian, and I got to this: $ ./setup configure --enable-library-profiling --disable-library-vanilla Configuring ghc-paths-0.1.0.5... $ ./setup build Preprocessing library ghc-paths-0.1.0.5... Building ghc-paths-0.1.0.5... /usr/bin/ar: creating dist/build/libHSghc-paths-0.1.0.5_p.a /usr/bin/ld: dist/build/GHC/Paths.o: No such file: No such file or directory I thought this could be a problem with this package, but I've tried with mtl, and I got the same result: /usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file or directory I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1. Greetings. -- marcot http://marcot.iaaeee.org/ From jonathanccast at fastmail.fm Thu Feb 5 17:38:07 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 17:30:26 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> <1233865621.19682.43.camel@jcchost> <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> Message-ID: <1233873487.19682.68.camel@jcchost> On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote: > > > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast > wrote: > > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > > wrote: > > I think the point of the Monad is > that it > > works as a container of stuff, that > still > > allows mathematically pure things to > happen, > > while possibly having some opaque > "other > > stuff" going on. > > > This at least sounds, very wrong, even if it's not. > Monads > > are not impure. IO is, but it's only _one_ instance > of Monad. > > All others, as far as I know, are pure. It's just > that the > > bind operation allows you to hide the stuff you > don't want to > > have to worry about, that should happen every time > you compose > > two monadic actions. > > Well all I can tell you is that I can have (IO Int) in a > function as a > > return, and the function is not idempotent in terms of the > "stuff" > > inside IO being the same. > > > Sure it's the same. > > > cmp /bin/cat /bin/cat > > cp /bin/cat ~ > > cmp /bin/cat ~/cat > > > > Pretty much the same, anyway. > So if IO represents a program that when executed interacts with the > world's state, is it safe to say that when I return (State Int Int), > that I'm returning a "State program"? I won't object to it. Othe people might, though. > That'd make sense as it really does look like we force the State to be > evaluated with runState, evalState or execState. > The only difference with IO then is that to get IO programs to run, > you have to do it inside another IO program. Meh. Combining IO sub-programs into larger programs doesn't really `get them to run'. Better to say that an IO value is meaningful only to the computer, and not mathematically (denotationally) useful. jcc From bugfact at gmail.com Thu Feb 5 17:47:28 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 5 17:37:30 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: <498B68AE.70106@pikewerks.com> References: <498B5BF3.5060405@pikewerks.com> <498B68AE.70106@pikewerks.com> Message-ID: Well, one could say that a truly random number function takes as input time and some constant unique identifier (serial number) of the TRND device and gives you the random value measured at that time by this device. Of course this would mean the random value is not really random, since "the potential creator of the universe" would have known the value already, but to all humble beings living in the bubble, it would be Truly Random :) Then the question is, is time a function? If so, is it discrete? Okay, this is not Haskell anymore, this would become philosophy, and since a good and smart friend of mine told me that nobody really knows what time is, this is off topic. Sorry! :) On Thu, Feb 5, 2009 at 11:31 PM, Jake McArthur wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Peter Verswyvelen wrote: > | I do have asked myself the question whether a "really random generating" > | function could be regarded as "pure" somehow (actually would a true > | random function still be a mathematical function?) > | > | E.g. the function would return a true (not pseudo) random number, > | practically unpredictable (e.g. hardware assisted, using some physical > | phenomenon, e.g. using atmospheric noise or something). So you surely > | won't get referential transparency but since the function is really > | random, this would be correct behavior? > > An informal definition of a function might be something like a black box > that takes and input and produces an output, and for each possible > input, the output must be the same. Taking this to be a function, there > is really no such thing as a random function, and if there was, it > wouldn't even need to be a function. (What would the input to it be?) > > If you wanted to mathematically represent a random number, it would, in > most cases I can think of, best be represented as a free variable. In a > program, such a free variable could be filled in by the runtime. > Conveniently, (and by no coincidence) this is something the IO monad can > provide for us! :) > > | Of course you could just put this random generator in the IO monad, but > | certain algorithms- like Monte Carlo - intuitively don't seem to operate > | in a IO monad to me. > > Why not? > > A Random monad might be more appropriate in this case anyway. Such a > monad is a State monad that hold a random seed. Every time a random > number is needed, the seed is passed to a deterministic psuedo-random > number generator, and a new seed is put as the next state. > > If a truly random number is ever needed, either IO or unsafeInterleaveIO > will be needed. The use of unsafeInterleaveIO would be a (rightly) > controversial choice though. > > - - Jake > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmLaK4ACgkQye5hVyvIUKk88QCfRksu7z80QmzgjUvmiyrzDDjl > QnsAn1R5DHz2tJpWP3yb0+U+loyBdyCX > =RIX9 > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/c98379ee/attachment.htm From martijn at van.steenbergen.nl Thu Feb 5 17:48:03 2009 From: martijn at van.steenbergen.nl (Martijn van Steenbergen) Date: Thu Feb 5 17:38:03 2009 Subject: [Haskell-cafe] Signatures in defining functions In-Reply-To: References: Message-ID: <498B6CA3.8030801@van.steenbergen.nl> Hi JTKM, TKM wrote: > Now is my question, how should I interpret "Int -> Int -> Int"? Meaning > what does "Int -> Int -> Int" mean? There are many good tutorials and books online. Here's a link that directly answers your question: http://book.realworldhaskell.org/read/types-and-functions.html#id581829 Section "The type of a function of more than one argument" Hope this helps, Martijn. From lennart at augustsson.net Thu Feb 5 17:58:57 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Feb 5 17:48:57 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902051155sbe73df1t2cd1ec28e5ec1edc@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> <75cc17ac0902051155sbe73df1t2cd1ec28e5ec1edc@mail.gmail.com> Message-ID: Perhaps you meant the type correct expression return 7 >>= \ x -> return 42 which the compiler will probably optimize to return 42, because by seeing the definition of return the compiler can see that it has no effects in the monad. This expression is very different from getChar >>= \ x -> return 42 Assuming getChar is some kind of primitive operation, the compiler does not know that it has no effects, so it has to remain. There's nothing special about IO in this respect. If IO is implemented as a state monad the compiler can just unfold the definitions of return and >>= and do its usual job. Some subexpressions (like return 7) do not touch the RealWord state and can be optimized away, some operations (like getChar) take and return a RealWorld, so they cannot be removed. -- Lennart On Thu, Feb 5, 2009 at 8:55 PM, Gregg Reynolds wrote: > On Thu, Feb 5, 2009 at 11:22 AM, Gleb Alexeyev wrote: >> Gregg Reynolds wrote: >> >>> Are you saying that using equations to add a level of indirection >>> prevents optimization? I still don't see it - discarding x doesn't >>> change the semantics, so a good compiler /should/ do this. How is >>> this different from optimizing out application of a constant function? >>> >> >> Perhaps my example doesn't work, so I'll try another example. >> As you know, (>>=) is just an (overloaded) higher-order function. >> Let's consider another higher-order function, map. The expression >>> map (\x -> 42) [1..3] >> evaluates to [42, 42, 42]. >> As you can see, the function (\x -> 42) passed to map ignores its first >> argument. Would you expect the compiler to discard the call to map? > > No, but I might expect it to discard the function application and just > replace each element of the list with 42. Which it may do at compile > time. Plus, it will only be evaluated once, no matter how many times > the expression occurs, since lazy evaluation memoizes results. >> >> Can you see the analogy? The shapes of the two expressions, map (\x -> 42) >> [1..3] and (>>=) getChar (\x -> getChar) are similar. >> >> (>>=) is a combinator just like map, you cannot optimize it away in general. > > Ok, I see what you're getting at, but I have to think about it some more. > > Here's a restatement that might make my puzzlement more clear. Suppose we have > > f = \x -> 42 > > Then I would expect the compiler to replace each expression of the > form f x with 42, for all x. > > Now suppose we write 7 >>= \x -> 42. It seems to me that a compiler > could examine that expression, conclude that it is constant, and > replace it with the expression 42. So far as I know, there's nothing > in the semantics of Haskell to forbid this, so why not do it? There > are no side effects, and an optimizer can always substitute equals for > equals, no? (Let's disregard the fact that such optimizations may be > hard or expensive.) > > This is different from map, because unlike map it doesn't need to > perform a computation (i.e. execute the function) to arrive at the > final value; it only has to analyze the function (which is computation > but not computation of the function itself.) > > Now getChar is a value of type IO Char, by definition. That means > mathematical value - "an action that does some IO" won't cut it in a > formal semantics, since there is no way to express "does some IO" > formally. Values is values; they don't "do" anything. So we should > be able to replace 7 and 42 above by getChar, and do the same > optimization. > > Do you see why this is problematic for me? In any case, you're > responses (and the others) have been quite useful and have helped me > work through some problems with a rather radical idea I have to > address this that I hope to write up this weekend. > > Thanks, > > gregg > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From miguelimo38 at yandex.ru Thu Feb 5 18:08:27 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Feb 5 17:58:48 2009 Subject: [Haskell-cafe] Signatures in defining functions In-Reply-To: References: Message-ID: It means Int -> (Int -> Int). -> is right associative. On 6 Feb 2009, at 01:28, TKM wrote: > Hello, > > I'm kind of new with Haskell and I would like to know about the > following: > > [some function]:: Int -> Int -> Int > > Now is my question, how should I interpret "Int -> Int -> Int"? > Meaning what does "Int -> Int -> Int" mean? > > Thank you for answering my question. > > Kind Regards, JTKM > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From bugfact at gmail.com Thu Feb 5 18:21:12 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 5 18:11:13 2009 Subject: [Haskell-cafe] Signatures in defining functions In-Reply-To: References: Message-ID: Maybe you mean that f :: Int -> Int -> Int does not say much about what the function does since the Int arguments have no "name" in Haskell? E.g. the following might "mean" more, but is not valid Haskell: f :: numerator:Int -> denominator:Int -> quotient:Int In Haskell you regularly see documentation that says: "the 4th argument of dpSwitch is ..., the 7th argument of dpSwitch is ..." That's okay, since it trains you at counting :-) Of course, I'm being sarcastic. But most of the time, this is not an issue, since functions usually only have a few arguments, or have argument types that tell more. 2009/2/5 TKM > Hello, > > I'm kind of new with Haskell and I would like to know about the following: > > [some function]:: Int -> Int -> Int > > Now is my question, how should I interpret "Int -> Int -> Int"? Meaning > what does "Int -> Int -> Int" mean? > > Thank you for answering my question. > > Kind Regards, JTKM > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/f721543c/attachment.htm From bugfact at gmail.com Thu Feb 5 18:51:43 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 5 18:41:44 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <498B3C07.80708@list.mightyreason.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <498B3C07.80708@list.mightyreason.com> Message-ID: On Thu, Feb 5, 2009 at 8:20 PM, ChrisK wrote: > Since this is strict there is no laziness and the code must evaluate the > input and output "State RealWorld" to ensure they are not bottom or error. > Interesting. I also thought it was the passing of the RealWorld that caused the sequencing, I never realized that the strictness played an important role here. So what would happen if it would be lazy instead of strict? What kind of craziness would occur? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/94dc338b/attachment.htm From leimy2k at gmail.com Thu Feb 5 18:52:40 2009 From: leimy2k at gmail.com (David Leimbach) Date: Thu Feb 5 18:42:42 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <1233873487.19682.68.camel@jcchost> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> <1233865621.19682.43.camel@jcchost> <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> <1233873487.19682.68.camel@jcchost> Message-ID: <3e1162e60902051552x14eb6ccy2eeb00c850972051@mail.gmail.com> On Thu, Feb 5, 2009 at 2:38 PM, Jonathan Cast wrote: > On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast > > wrote: > > > > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach wrote: > > > > > > > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > > > wrote: > > > I think the point of the Monad is > > that it > > > works as a container of stuff, that > > still > > > allows mathematically pure things to > > happen, > > > while possibly having some opaque > > "other > > > stuff" going on. > > > > > This at least sounds, very wrong, even if it's not. > > Monads > > > are not impure. IO is, but it's only _one_ instance > > of Monad. > > > All others, as far as I know, are pure. It's just > > that the > > > bind operation allows you to hide the stuff you > > don't want to > > > have to worry about, that should happen every time > > you compose > > > two monadic actions. > > > > Well all I can tell you is that I can have (IO Int) in a > > function as a > > > return, and the function is not idempotent in terms of the > > "stuff" > > > inside IO being the same. > > > > > > Sure it's the same. > > > > > cmp /bin/cat /bin/cat > > > cp /bin/cat ~ > > > cmp /bin/cat ~/cat > > > > > > > Pretty much the same, anyway. > > > So if IO represents a program that when executed interacts with the > > world's state, is it safe to say that when I return (State Int Int), > > that I'm returning a "State program"? > > I won't object to it. Othe people might, though. > > > That'd make sense as it really does look like we force the State to be > > evaluated with runState, evalState or execState. > > > The only difference with IO then is that to get IO programs to run, > > you have to do it inside another IO program. > > Meh. Combining IO sub-programs into larger programs doesn't really `get > them to run'. Better to say that an IO value is meaningful only to the > computer, and not mathematically (denotationally) useful. > > jcc > All Haskell programs start as main :: IO () though... so they all get evaluated in the context of another IO () don't they? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/22e1cdd7/attachment.htm From jonathanccast at fastmail.fm Thu Feb 5 19:11:26 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 19:03:45 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <3e1162e60902051552x14eb6ccy2eeb00c850972051@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> <1233865621.19682.43.camel@jcchost> <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> <1233873487.19682.68.camel@jcchost> <3e1162e60902051552x14eb6ccy2eeb00c850972051@mail.gmail.com> Message-ID: <1233879086.19682.79.camel@jcchost> On Thu, 2009-02-05 at 15:52 -0800, David Leimbach wrote: > > > On Thu, Feb 5, 2009 at 2:38 PM, Jonathan Cast > wrote: > > On Thu, 2009-02-05 at 13:01 -0800, David Leimbach wrote: > > > > > > On Thu, Feb 5, 2009 at 12:27 PM, Jonathan Cast > > wrote: > > > > On Thu, 2009-02-05 at 12:21 -0800, David Leimbach > wrote: > > > > > > > > > On Thu, Feb 5, 2009 at 11:25 AM, Andrew Wagner > > > wrote: > > > I think the point of the > Monad is > > that it > > > works as a container of > stuff, that > > still > > > allows mathematically pure > things to > > happen, > > > while possibly having some > opaque > > "other > > > stuff" going on. > > > > > This at least sounds, very wrong, even if > it's not. > > Monads > > > are not impure. IO is, but it's only _one_ > instance > > of Monad. > > > All others, as far as I know, are pure. > It's just > > that the > > > bind operation allows you to hide the > stuff you > > don't want to > > > have to worry about, that should happen > every time > > you compose > > > two monadic actions. > > > > Well all I can tell you is that I can have (IO > Int) in a > > function as a > > > return, and the function is not idempotent in > terms of the > > "stuff" > > > inside IO being the same. > > > > > > Sure it's the same. > > > > > cmp /bin/cat /bin/cat > > > cp /bin/cat ~ > > > cmp /bin/cat ~/cat > > > > > > > Pretty much the same, anyway. > > > > So if IO represents a program that when executed interacts > with the > > world's state, is it safe to say that when I return (State > Int Int), > > that I'm returning a "State program"? > > > I won't object to it. Othe people might, though. > > > That'd make sense as it really does look like we force the > State to be > > evaluated with runState, evalState or execState. > > > The only difference with IO then is that to get IO programs > to run, > > you have to do it inside another IO program. > > > Meh. Combining IO sub-programs into larger programs doesn't > really `get > them to run'. Better to say that an IO value is meaningful > only to the > computer, and not mathematically (denotationally) useful. > > All Haskell programs start as > main :: IO () > though... so they all get evaluated in the context of another IO () > don't they? Well... Haskell compilers and runhaskell-style interpreters (not regular Hugs/ghci!) take the value of Main.main as `the program'. But that feels (to me --- I could be wrong) like an aspect of a particular hosted environment. REPLs can handle programs that aren't wrapped up in IO at all; and there's no reason why IO has to be the type of IO-performning-things in REPLs, either. You could just as well write a REPL that took, say, tangible values [http://haskell.org/haskellwiki/TV] as input instead, and displayed them. So it's more a matter of Haskell implementations can be given an IO value to run than that combining IO values together somehow runs them. jcc From jonathanccast at fastmail.fm Thu Feb 5 19:16:09 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 19:08:31 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <498B3C07.80708@list.mightyreason.com> Message-ID: <1233879369.19682.85.camel@jcchost> On Fri, 2009-02-06 at 00:51 +0100, Peter Verswyvelen wrote: > On Thu, Feb 5, 2009 at 8:20 PM, ChrisK > wrote: > Since this is strict there is no laziness and the code must > evaluate the input and output "State RealWorld" to ensure they > are not bottom or error. > Interesting. I also thought it was the passing of the RealWorld that > caused the sequencing, I never realized that the strictness played an > important role here. > So what would happen if it would be lazy instead of strict? What kind > of craziness would occur? The order of side effects would be demand-driven, rather than order-of-statement driven. So if I said: do x <- getChar y <- getChar z <- getChar then in the sequel, the first character I evaluated would be the first character read. Of course, Haskell's order of evaluation is undefined, so whether the string read from STDIN was [x, y, z] or [y, x, z] or [z, x, y] or some other permutation would be undefined. And, of course, if I never evaluated y at all, y would never be read --- there would be only two characters of input. Essentially, the program would act as if every statement was wrapped up in an unsafeInterleaveIO. jcc From david.waern at gmail.com Thu Feb 5 19:25:33 2009 From: david.waern at gmail.com (David Waern) Date: Thu Feb 5 19:15:33 2009 Subject: [Haskell-cafe] Re: Haddock In-Reply-To: <1C6E59C47F062E42820BEE74FD3388E91E482D9A0F@EA-EXMSG-C333.europe.corp.microsoft.com> References: <1C6E59C47F062E42820BEE74FD3388E91E482D9A0F@EA-EXMSG-C333.europe.corp.microsoft.com> Message-ID: Hi everyone, I received this question from Lennart Augustsson (via Simon M) and thought I'd send out an inquiry to the Haskell community in general (Lennart, I hope you don't mind): Lennart writes: > We have some local patches for haddock that extends the <> > syntax so you can put TeX formulae in the documentation. > It looks like, <>, but I'd like to extend it so > you can process the string with any command. > > Are you interested in folding this into the main branch? So the question is about extending the Haddock markup language. When modifying the language we should think about the tension between familiarity, presentation features (pictures, math, whatever) and visual portability across different mediums (HTML, ghci, IDE tooltips, etc). And here I should say that Haddock already supports pictures using the << url >> syntax. IMHO, adding <> for TeX math is fine, because: - math in documentation is often useful - if you're going to write math, you need a format, even when the medium is plain text as in ghci. - TeX formulae seem to be relatively widely used and understood. As for running arbitrary commands, I think we are opening up to a lot of unfamiliar syntax. I'd like to hear what everyone thinks about that. There was also a thread about Haddock markup on haskell-cafe@ about a year ago, which originated with the interesting idea of using Markdown (or a Pandoc-extended version of it) instead of the current language: http://www.mail-archive.com/haskell-cafe@haskell.org/msg38054.html I think the original idea there is pretty nice, but let's first focus on the current markup language in order to answer Lennart's question. That thread contains some useful opinions on this matter, also. So, any comments? :) David From haskell at list.mightyreason.com Thu Feb 5 19:27:19 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Feb 5 19:17:38 2009 Subject: [Haskell-cafe] Re: Monad explanation In-Reply-To: <1233879086.19682.79.camel@jcchost> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> <1233865621.19682.43.camel@jcchost> <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> <1233873487.19682.68.camel@jcchost> <3e1162e60902051552x14eb6ccy2eeb00c850972051@mail.gmail.com> <1233879086.19682.79.camel@jcchost> Message-ID: >> All Haskell programs start as > >> main :: IO () > >> though... so they all get evaluated in the context of another IO () >> don't they? True for most cases now, but historically false. Haskell existed and people wrote programs for years before the Monad class and IO were created. A Haskell98 program can be taken to have a "main :: IO ()", but that is not essential. Which is the point jcc made: > > Well... Haskell compilers and runhaskell-style interpreters (not > regular Hugs/ghci!) take the value of Main.main as `the program'. But > that feels (to me --- I could be wrong) like an aspect of a particular > hosted environment. REPLs can handle programs that aren't wrapped up in > IO at all; and there's no reason why IO has to be the type of > IO-performning-things in REPLs, either. You could just as well write a > REPL that took, say, tangible values [http://haskell.org/haskellwiki/TV] > as input instead, and displayed them. So it's more a matter of Haskell > implementations can be given an IO value to run than that combining IO > values together somehow runs them. > > jcc From david.waern at gmail.com Thu Feb 5 19:35:13 2009 From: david.waern at gmail.com (David Waern) Date: Thu Feb 5 19:25:17 2009 Subject: [Haskell-cafe] Haddock Markup Message-ID: I got the subject line wrong, so I'm reposting this: ==== Hi everyone, I received this question from Lennart Augustsson (via Simon M) and thought I'd send out an inquiry to the Haskell community in general (Lennart, I hope you don't mind): Lennart writes: > We have some local patches for haddock that extends the <> > syntax so you can put TeX formulae in the documentation. > It looks like, <>, but I'd like to extend it so > you can process the string with any command. > > Are you interested in folding this into the main branch? So the question is about extending the Haddock markup language. When modifying the language we should think about the tension between familiarity, presentation features (pictures, math, whatever) and visual portability across different mediums (HTML, ghci, IDE tooltips, etc). And here I should say that Haddock already supports pictures using the << url >> syntax. IMHO, adding <> for TeX math is fine, because: - math in documentation is often useful - if you're going to write math, you need a format, even when the medium is plain text as in ghci. - TeX formulae seem to be relatively widely used and understood. As for running arbitrary commands, I think we are opening up to a lot of unfamiliar syntax. I'd like to hear what everyone thinks about that. There was also a thread about Haddock markup on haskell-cafe@ about a year ago, which originated with the interesting idea of using Markdown (or a Pandoc-extended version of it) instead of the current language: http://www.mail-archive.com/haskell-cafe@haskell.org/msg38054.html I think the original idea there is pretty nice, but let's first focus on the current markup language in order to answer Lennart's question. That thread contains some useful opinions on this matter, also. So, any comments? :) David From max.rabkin at gmail.com Thu Feb 5 19:46:09 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Thu Feb 5 19:36:11 2009 Subject: [Haskell-cafe] Re: Haddock In-Reply-To: References: <1C6E59C47F062E42820BEE74FD3388E91E482D9A0F@EA-EXMSG-C333.europe.corp.microsoft.com> Message-ID: On Thu, Feb 5, 2009 at 4:25 PM, David Waern wrote: > As for running arbitrary commands, I think we are opening up to a lot > of unfamiliar syntax. I'd like to hear what everyone thinks about > that. I personally find it useful to have Haddock comments readable in the source. And aren't there security issues, too? So we'd have to have an option to disable them, which would have to be on by default, and basically they would be disabled by everybody but the writers of the comments themselves. --Max From andrewcoppin at btinternet.com Mon Feb 2 15:55:20 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Feb 5 19:45:27 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> Message-ID: <49875DB8.8010602@btinternet.com> Deniz Dogan wrote: > Learn You a Haskell for Great Good (http://learnyouahaskell.com/) Mmm, interesting. Does anybody else think it would be neat if GHCi really did colourise your input like that? (Or at least display the prompt in a different colour to user input and program output?) From andrewcoppin at btinternet.com Tue Feb 3 14:25:46 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Feb 5 19:45:38 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <20090202225218.GE13113@whirlpool.galois.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> <20090202220344.GA13113@whirlpool.galois.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB86@ELON17P32001A.csfb.cs-group.com> <20090202225218.GE13113@whirlpool.galois.com> Message-ID: <49889A3A.2000200@btinternet.com> Don Stewart wrote: > The platform is a set of blessed libraries and tools. The distros will > still need to package that. > > To do that for Windows, we're still going to need a windows packaging > team, along side Debian, Arch, Gentoo, Mac etc. > Right, so, let me make sure I understand this... 1. We sit down and pick a set of libraries that cover a useful range of subject areas, that are mature and stable, and that work well with each other. This is the "Haskell Platform". 2. For each OS, a team decides how best to deploy this set of libraries on that specific OS. Is that the plan? From andrewcoppin at btinternet.com Thu Feb 5 03:10:42 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Feb 5 19:45:55 2009 Subject: [Haskell-cafe] (Off-topic) CUDA Message-ID: <498A9F02.8070305@btinternet.com> And so, inspired by the marketing litrature, I just spent ??? on a very expensive new GPU that supports CUDA. The only problem is... I can't seem to get any software to use it. Does anybody know how to make this stuff actually work? (Also... Haskell on the GPU. It's been talked about for years, but will it ever actually happen?) From andrewcoppin at btinternet.com Thu Feb 5 09:42:31 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Thu Feb 5 19:46:01 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! In-Reply-To: <498AF64E.2080902@functor.nl> References: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> <498AF64E.2080902@functor.nl> Message-ID: <498AFAD7.3020600@btinternet.com> Jochem Berndsen wrote: > The HAppS project has been abandoned, see > http://groups.google.com/group/HAppS/msg/d128331e213c1031 . > > The Happstack project is intended to continue development. For more > details, see http://happstack.com/faq.html . > > So we've got HAppS, Happstack, WASH, Turbinado, probably others... Does anybody know how all these relate to each other? Where their strengths and weaknesses lie? It's nice to have choice, but without knowing what you're choosing between, it's hard to use it well. From dons at galois.com Thu Feb 5 19:57:10 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 5 19:47:45 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: <49875DB8.8010602@btinternet.com> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49875DB8.8010602@btinternet.com> Message-ID: <20090206005710.GK21583@whirlpool.galois.com> andrewcoppin: > Deniz Dogan wrote: >> Learn You a Haskell for Great Good (http://learnyouahaskell.com/) > > Mmm, interesting. > > Does anybody else think it would be neat if GHCi really did colourise > your input like that? (Or at least display the prompt in a different > colour to user input and program output?) I wrote about this a while ago, http://haskell.org/haskellwiki/GHCi_in_colour Needs integration with ghc-api, and we're done. From dons at galois.com Thu Feb 5 19:58:28 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 5 19:49:04 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! In-Reply-To: <498AFAD7.3020600@btinternet.com> References: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> <498AF64E.2080902@functor.nl> <498AFAD7.3020600@btinternet.com> Message-ID: <20090206005828.GL21583@whirlpool.galois.com> andrewcoppin: > Jochem Berndsen wrote: >> The HAppS project has been abandoned, see >> http://groups.google.com/group/HAppS/msg/d128331e213c1031 . >> >> The Happstack project is intended to continue development. For more >> details, see http://happstack.com/faq.html . >> >> > So we've got HAppS, Happstack, WASH, Turbinado, probably others... Does > anybody know how all these relate to each other? Where their strengths > and weaknesses lie? > > It's nice to have choice, but without knowing what you're choosing > between, it's hard to use it well. > A comparative analysis of the 10+ Haskell web frameworks would be awesome. happstack, wash, fastcgi.., turbinado, perpubplat, riviera, salvia, kibro, ella, what was that one launched yesterday? *ah, yesod... From jonathanccast at fastmail.fm Thu Feb 5 20:03:21 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 5 19:55:40 2009 Subject: [Haskell-cafe] Haskell tutorial for pseudo users? In-Reply-To: <49875DB8.8010602@btinternet.com> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49875DB8.8010602@btinternet.com> Message-ID: <1233882201.19682.88.camel@jcchost> On Mon, 2009-02-02 at 20:55 +0000, Andrew Coppin wrote: > Deniz Dogan wrote: > > Learn You a Haskell for Great Good (http://learnyouahaskell.com/) > > Mmm, interesting. > > Does anybody else think it would be neat if GHCi really did colourise > your input like that? Bleah. More terminal hacking to break and/or slow Emacs to a crawl? No thanks. jcc From wren at freegeek.org Thu Feb 5 20:19:53 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Feb 5 20:09:54 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902050922w165e58f3ja7cc0e14435fefb5@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> <75cc17ac0902050922w165e58f3ja7cc0e14435fefb5@mail.gmail.com> Message-ID: <498B9039.90404@freegeek.org> Gregg Reynolds wrote: > Right, but that's only because the compiler either somehow knows about > side effects or there is some other mechanism - e.g. an implicit World > token that gets passed around - that prevents optiimization. As far > as the formal semantics of the language are concerned, there's no > essential difference between "getChar >>= \x -> getChar" and " Foo 3 >>> = \x -> Foo 7 " for some data constructor Foo. I should think the > latter would be optimized; if so, why not the former? The presence of > some hidden (from me, anyway) semantics is inescapable. There's no reason to assume the latter would be "optimized" either. Consider: > data NotIO a = NotIO String a > > instance Monad NotIO where > return x = NotIO "" x > (NotIO s x) >>= f = (\(NotIO z y) -> NotIO (s++z) y) (f x) > > notGetChar = NotIO "foo" 'a' Let's consider your example: notGetChar >>= \x -> notGetChar == (NotIO "foo" 'a') >>= (\x -> NotIO "foo" 'a') == (\(NotIO z y) -> NotIO ("foo"++z) y) ((\x -> NotIO "foo" 'a') 'a') == (\(NotIO z y) -> NotIO ("foo"++z) y) (NotIO "foo" 'a') == NotIO ("foo"++"foo") 'a' It's clear to see that this result is not equal to notGetChar. And the compiler needn't know anything special about NotIO to realize that. There's nothing special about IO. The only difference between NotIO and IO is that NotIO has a Chars for "side effects". IO is a perfectly fine mathematical object, the only difference is that it is appending sequences of an abstract type that we mere mortals like to think of as "actions" or "side effects" or "a program". The mathematics neither knows nor cares about any of that rubbish. The only relevant thing[1] is that this abstract type ---whatever it is, however it's implemented--- forms a monoid. The return function associates the identity of the monoid with some value (which is also irrelevant as far as the monad is concerned), and the bind operation uses the associative operation of the monoid to combine them. The latter is more obvious when it's phrased in terms of join :: Monad m => m(m a) -> m a, and the monad law: join . join == join . fmap join It so happens that a sequence of anything is the "free" monoid. Appending sequences of characters is no different than appending sequences of actions or program instructions. For lists or sets as monads, the monoid is a path through a decision tree aka a sequence of choices. These "choices" aren't stored in bits anywhere, just like IO's RealWorld[2], but people don't seem to get as flustered trying to figure out what exactly a "choice" is and what a "choice" means as a mathematical object. The point is, it doesn't matter. The choice, the side effect, the character, these are all just arbitrary sets of things. We can construct a free monoid over any set, and the monoid neither knows nor cares anything about the "values" in that set. The only way we can optimize away one of the calls to notGetChar (or any other monadic function) is if we can guarantee that no other computation will use either the monoidal values or the "contained" values associated with it. IO is defined with a bind operator that's strict in the monoidal value, which means we can never remove things (unless, perhaps, we can demonstrate that they only append the identity of the monoid, in which case evaluating the function has no side effects--- by definition). There's nothing particularly intriguing about a strict bind operator, State has one as do other monads. And there's nothing particularly intriguing about "stateful" monads either, there is the Lazy State monad too (and the ACIO monad is something like a lazy IO). [1] Okay, not the *only* relevant thing :) [2] This is just like the binary search algorithm. Effectively there's a tree that spans the set we're searching, and each iteration of search is walking down one ply of that tree. Only for binary search we usually don't bother constructing that tree, the tree is realized in the recursion pattern of the algorithm. Or dually, binary tree datastructures are a reification of the algorithm. You get this same duality with, frex, lazy lists vs for-loops. There's nothing special about being stored in bits vs being stored in invariants or actions. -- Live well, ~wren From haskell at list.mightyreason.com Thu Feb 5 20:20:33 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Thu Feb 5 20:10:51 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <1233879369.19682.85.camel@jcchost> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <498B3C07.80708@list.mightyreason.com> <1233879369.19682.85.camel@jcchost> Message-ID: Jonathan Cast wrote: > On Fri, 2009-02-06 at 00:51 +0100, Peter Verswyvelen wrote: >> On Thu, Feb 5, 2009 at 8:20 PM, ChrisK >> wrote: >> Since this is strict there is no laziness and the code must >> evaluate the input and output "State RealWorld" to ensure they >> are not bottom or error. > >> Interesting. I also thought it was the passing of the RealWorld that >> caused the sequencing, I never realized that the strictness played an >> important role here. > >> So what would happen if it would be lazy instead of strict? What kind >> of craziness would occur? > > The order of side effects would be demand-driven, rather than > order-of-statement driven. So if I said: [snip] > Essentially, the program would act as if every statement was wrapped up > in an unsafeInterleaveIO. > > jcc I do not think so. Consider http://darcs.haskell.org/packages/base/GHC/IOBase.lhs to see unsafeInterleaveIO: > unsafeInterleaveIO m = unsafeDupableInterleaveIO (noDuplicate >> m) > unsafeDupableInterleaveIO (IO m) > = IO ( \ s -> let > r = case m s of (# _, res #) -> res > in > (# s, r #)) And Control.Monad.State.Lazy which is the non-strict State monad: > newtype State s a = State { runState :: s -> (a, s) } > instance Monad (State s) where > return a = State $ \s -> (a, s) > m >>= k = State $ \s -> let > (a, s') = runState m s > in runState (k a) s' And you can see that the data dependence is broken in unsafeInterleaveIO by _, and not broken in State.Lazy. But neither s nor s' are not forced to WHNF. What you can do State.Lazy is put an bottom into the state. Or you can put an unevaluated thunk into the state, and if it gets replaced later then you never paid to evaluate it. But the sequencing is retained. One could make an unsafeInterleaveIO for state: > interleaveState :: State s a -> State s a > interleaveState (State m) = State ( \ s -> let (a,_) = runState m s > in (a,s) ) Now the dependency chain is broken in the above, due to the _ being ignored. Cheers, Chris From wren at freegeek.org Thu Feb 5 20:46:00 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Feb 5 20:35:59 2009 Subject: [Haskell-cafe] Purely funcional LU decomposition In-Reply-To: <351ff25e0902041331i746e426cl207a340800fe687c@mail.gmail.com> References: <351ff25e0902031337k1e85cd3fua6ef8dfb7664fd17@mail.gmail.com> <625b74080902041109o4a219c3aj87738e7f9b4896bc@mail.gmail.com> <351ff25e0902041257x72959e30l35a680076be94271@mail.gmail.com> <625b74080902041314l5f388276t184ecf092c5bcfde@mail.gmail.com> <351ff25e0902041331i746e426cl207a340800fe687c@mail.gmail.com> Message-ID: <498B9658.7010003@freegeek.org> Rafael Gustavo da Cunha Pereira Pinto wrote: > What I miss most is a data structure with O(1) (amortized) direct access. Finger trees get close, O(log(min(i,n-i))): http://hackage.haskell.org/packages/archive/containers/latest/doc/html/Data-Sequence.html (And Theta(1) amortized for all dequeue operations to boot.) > One of the changes I thought today was to remove the ++ operator and create > a list of lists that I would concat in the last call. Don't do it manually, let an abstract type do the optimization for you. This idea[1] is often known as "difference lists", which the estimable Don Stewart has already packaged up for us: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dlist :) [1] Actually, not quite that idea. The idea instead is to represent a list as a function [a]->[a] and then compose these functions (rather than concatenating the strings). At the very end once you're done, pass in [] and get back the whole list in O(n) time, rather than the O(n^2) that commonly arises from using (++). -- Live well, ~wren From mail at justinbogner.com Thu Feb 5 20:50:05 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Thu Feb 5 20:40:19 2009 Subject: [Haskell-cafe] Re: Bind as a sequencing operator References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> <87r62cg1ew.fsf@justinbogner.com> <498B3C4A.30408@pikewerks.com> <87myd0fyid.fsf@justinbogner.com> <498B4CF1.4030300@pikewerks.com> Message-ID: <87iqnofi5u.fsf@justinbogner.com> Jake McArthur writes: > | Just because the compiler is allowed (and even encouraged) to change the > | sequence where that won't change the results, considering this a > | sequence is still valid and meaningful. > > It can be helpful sometimes, but I don't think it should be the standard > way to think of bind. There are too many cases when it makes little > sense as a sequencing operator. > Fair enough, thanks for your thoughts! From wren at freegeek.org Thu Feb 5 20:58:09 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Feb 5 20:48:09 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs In-Reply-To: <20090205154728.GA27668@flit> References: <87vdrodhmb.fsf@malde.org> <20090205154728.GA27668@flit> Message-ID: <498B9931.908@freegeek.org> Roman Cheplyaka wrote: > * Peter Verswyvelen [2009-02-05 16:35:34+0100] >> On Thu, Feb 5, 2009 at 4:32 PM, Ketil Malde wrote: >> >>> Peter Verswyvelen writes: >>> >>>> 1) hg st >>> darcs cha -s >> >> That seems to list all changes in the history. >> >> hg st lists local changes only. Can be done using darcs? > > darcs whatsnew -s Or `darcs w -s` if you're really adverse to spelling things out ;) The changes command gives the whole history (to varying depth, verbosity,...), whereas the whatsnew command gives what things have been altered but not recorded yet. The -s flag to whatsnew says to give a summary (names of files and count of lines changed). If you leave -s off, then you'll get textual diffs of same. -- Live well, ~wren From wchogg at gmail.com Thu Feb 5 21:05:29 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Thu Feb 5 20:55:29 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! In-Reply-To: <20090206005828.GL21583@whirlpool.galois.com> References: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> <498AF64E.2080902@functor.nl> <498AFAD7.3020600@btinternet.com> <20090206005828.GL21583@whirlpool.galois.com> Message-ID: <814617240902051805h35c77deg844215cc1bd5af06@mail.gmail.com> On Thu, Feb 5, 2009 at 6:58 PM, Don Stewart wrote: > andrewcoppin: >> Jochem Berndsen wrote: >>> The HAppS project has been abandoned, see >>> http://groups.google.com/group/HAppS/msg/d128331e213c1031 . >>> >>> The Happstack project is intended to continue development. For more >>> details, see http://happstack.com/faq.html . >>> >>> >> So we've got HAppS, Happstack, WASH, Turbinado, probably others... Does >> anybody know how all these relate to each other? Where their strengths >> and weaknesses lie? >> >> It's nice to have choice, but without knowing what you're choosing >> between, it's hard to use it well. >> > > A comparative analysis of the 10+ Haskell web frameworks would be > awesome. > > happstack, wash, fastcgi.., turbinado, perpubplat, riviera, salvia, > kibro, ella, what was that one launched yesterday? *ah, yesod... That's a lot of frameworks to try & compare and I don't think any one person would have the time to do more than a couple, but perhaps we could all agree on some kind of non-trivial, but still simple, application that we could implement & deploy in the most natural way for each framework. It'd probably be easy to just point prospective framework users to the resulting series of blog posts elucidating the features of each. I'd vote for something like a trimmed down reddit clone, something that I'd expect everyone could do whether they deploy it via Apache or something that's part of the framework such as happstack-server. Cheers, C From dev at mobileink.com Thu Feb 5 21:38:34 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 21:28:34 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <498B9039.90404@freegeek.org> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> <75cc17ac0902050922w165e58f3ja7cc0e14435fefb5@mail.gmail.com> <498B9039.90404@freegeek.org> Message-ID: <75cc17ac0902051838x37b487c1r3ff704a2fdb05c13@mail.gmail.com> On Thu, Feb 5, 2009 at 7:19 PM, wren ng thornton wrote: > Gregg Reynolds wrote: >> as the formal semantics of the language are concerned, there's no >> essential difference between "getChar >>= \x -> getChar" and " Foo 3 >>>> >>>> = \x -> Foo 7 " for some data constructor Foo. I should think the >> >> latter would be optimized; if so, why not the former? The presence of >> some hidden (from me, anyway) semantics is inescapable. > > There's no reason to assume the latter would be "optimized" either. > Consider: > > > data NotIO a = NotIO String a > > > > instance Monad NotIO where > > return x = NotIO "" x > > (NotIO s x) >>= f = (\(NotIO z y) -> NotIO (s++z) y) (f x) > > > > notGetChar = NotIO "foo" 'a' > > Let's consider your example: > > notGetChar >>= \x -> notGetChar > == > (NotIO "foo" 'a') >>= (\x -> NotIO "foo" 'a') > == > (\(NotIO z y) -> NotIO ("foo"++z) y) ((\x -> NotIO "foo" 'a') 'a') > == > (\(NotIO z y) -> NotIO ("foo"++z) y) (NotIO "foo" 'a') > == > NotIO ("foo"++"foo") 'a' > You've defined >>= in such a way that it carries additional semantic weight. My example doesn't do that. Bind can be thought of as an "augmented application" operator: x >>= f applies f to x, but it may fiddle with x first. If it doesn't then it amounts to ordinary function application, which can be optimized out. That's the point of my example: data constructors don't munge their arguments, and getChar is essentially a data constructor. > NotIO has a Chars for "side effects". IO is a perfectly fine mathematical > object, the only difference is that it is appending sequences of an abstract Gotcha! "appending sequences" is not something mathematical values are inclined to do. They neither spin nor toil, let alone append. The dominant idiom - "IO values are actions" just doesn't work if you want formal semantics, no matter how useful it may be pedagogically. > > The only way we can optimize away one of the calls to notGetChar (or any > other monadic function) is if we can guarantee that no other computation > will use either the monoidal values or the "contained" values associated > with it. IO is defined with a bind operator that's strict in the monoidal > value, which means we can never remove things (unless, perhaps, we can Ok; but where does it say that in the language definition? I understand how it all works, but that comes from the many informal narrative expositions; my point is that if you tried to write a formal semantics for Haskell, a la ML, you couldn't do it without coming up with a different story for IO. -gregg From dev at mobileink.com Thu Feb 5 21:52:07 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 5 21:42:07 2009 Subject: [Haskell-cafe] morphisms in IO Message-ID: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> I'm working on a radically different way of looking at IO. Before I post it and make a fool of myself, I'd appreciate a reality check on the following points: a) Can IO be thought of as a category? I think the answer is yes. b) If it is a category, what are its morphisms? I think the answer is: it has no morphisms. The morphisms available are natural transformations or functors, and thus not /in/ the category. Alternatively: we have no means of directly naming its values, so the only way we can operate on its values is to use morphisms from the outside (operating on construction expressions qua morphisms.) c) All categories with no morphisms ("bereft categories"?) are isomorphic (to each other). I think yes. Thanks, gregg From wren at freegeek.org Thu Feb 5 23:28:23 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Feb 5 23:18:24 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902051838x37b487c1r3ff704a2fdb05c13@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> <75cc17ac0902050922w165e58f3ja7cc0e14435fefb5@mail.gmail.com> <498B9039.90404@freegeek.org> <75cc17ac0902051838x37b487c1r3ff704a2fdb05c13@mail.gmail.com> Message-ID: <498BBC67.9090300@freegeek.org> Gregg Reynolds wrote: > On Thu, Feb 5, 2009 at 7:19 PM, wren ng thornton wrote: >> Gregg Reynolds wrote: > >>> as the formal semantics of the language are concerned, there's no >>> essential difference between "getChar >>= \x -> getChar" and " Foo 3 >>>>> = \x -> Foo 7 " for some data constructor Foo. I should think the >>> latter would be optimized; if so, why not the former? The presence of >>> some hidden (from me, anyway) semantics is inescapable. >> There's no reason to assume the latter would be "optimized" either. >> Consider: >> >> > data NotIO a = NotIO String a >> > >> > instance Monad NotIO where >> > return x = NotIO "" x >> > (NotIO s x) >>= f = (\(NotIO z y) -> NotIO (s++z) y) (f x) >> > >> > notGetChar = NotIO "foo" 'a' >> >> Let's consider your example: >> >> notGetChar >>= \x -> notGetChar >> == >> (NotIO "foo" 'a') >>= (\x -> NotIO "foo" 'a') >> == >> (\(NotIO z y) -> NotIO ("foo"++z) y) ((\x -> NotIO "foo" 'a') 'a') >> == >> (\(NotIO z y) -> NotIO ("foo"++z) y) (NotIO "foo" 'a') >> == >> NotIO ("foo"++"foo") 'a' >> > > You've defined >>= in such a way that it carries additional semantic > weight. My example doesn't do that. Yes, is does. Every bind operator does so (trivially for the Identity monad). What else would bind be "augmented" with if it's "augmented application"? Augmentation means to add structure. Bind does not "apply f to x", x is a monadic value which carries additional structure. What bind does is map f over x's structure and then calls join to collapse the monadic layers from the result. > If it doesn't then it amounts to ordinary > function application, which can be optimized out. That's the point of > my example: data constructors don't munge their arguments, and getChar > is essentially a data constructor. Data constructors in general are not monads. To the extent that your Foo example is well typed it is isomorphic to the Identity monad. In which case your Foo x >>= f is exactly return x >>= f which the monad laws require to equal f x. Just because the Identity monad is trivial does not mean that bind is trivial. That's like saying that addition must do nothing because of it's behavior on 0. > > NotIO has a Chars for "side effects". IO is a perfectly fine mathematical > > object, the only difference is that it is appending sequences of an abstract > > Gotcha! "appending sequences" is not something mathematical values > are inclined to do. They neither spin nor toil, let alone append. Balderdash. > The dominant idiom - "IO values are actions" just doesn't work if you > want formal semantics, no matter how useful it may be pedagogically. IO values are absolutely not actions, that's the whole point. Actions, such as they exist at all, are merely a domain over which we've constructed a monoid. The semantics from this are minimal, but if you'd like to define the domain more precisely there are many people who would be grateful for your contribution to research on effect systems and the ontology of computational effects on reality. > > The only way we can optimize away one of the calls to notGetChar (or any > > other monadic function) is if we can guarantee that no other computation > > will use either the monoidal values or the "contained" values associated > > with it. IO is defined with a bind operator that's strict in the monoidal > > value, which means we can never remove things (unless, perhaps, we can > > Ok; but where does it say that in the language definition? I > understand how it all works, but that comes from the many informal > narrative expositions; my point is that if you tried to write a formal > semantics for Haskell, a la ML, you couldn't do it without coming up > with a different story for IO. It says that in the function definitions for bind and return on the IO type. In GHC the IO type is defined such that it's a specialized version of the State monad where RealWorld is the type of the state it carries. You can look in the source code that defines IO if you care. Other compilers may choose a different implementation for IO which has the same observational behavior in which case their "story" will be different. IO is an abstract type which is defined only by its observational behavior. One aspect of this behavior is that it is a monad and is not the Identity monad. Everything else follows. -- Live well, ~wren From westondan at imageworks.com Thu Feb 5 23:32:17 2009 From: westondan at imageworks.com (Dan Weston) Date: Thu Feb 5 23:22:21 2009 Subject: [Haskell-cafe] morphisms in IO In-Reply-To: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> References: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> Message-ID: <498BBD51.5040602@imageworks.com> I truly have no idea what you are saying (and probably not even what I am saying), but I suspect: a) You are calling IO the target category of applying the functor IO [taking a to IO a and (a->b) to (IO a -> IO b)] to Hask. b) This category is hardly bereft, nor discrete. Its morphisms are IO a -> IO b. Maybe you are thinking that it becomes an empty category after some fixed point process where you strip off the IO with repeated joins (or runIOs)? Remember there can be arbitrarily many nestings of IO, so that main :: IO (IO (IO Int)) is (a program that when run returns)^3 an Int. This is a stream with no finite least fixed point. c) What you are calling a "bereft" category is an empty category. Without (identity) morphisms, there can be no objects. There is only one such category (the empty category), so naturally any two such are isomorphic (for what it's worth, which I suspect is not much). Dan Gregg Reynolds wrote: > I'm working on a radically different way of looking at IO. Before I > post it and make a fool of myself, I'd appreciate a reality check on > the following points: > > a) Can IO be thought of as a category? I think the answer is yes. > > b) If it is a category, what are its morphisms? I think the answer > is: it has no morphisms. The morphisms available are natural > transformations or functors, and thus not /in/ the category. > Alternatively: we have no means of directly naming its values, so the > only way we can operate on its values is to use morphisms from the > outside (operating on construction expressions qua morphisms.) > > c) All categories with no morphisms ("bereft categories"?) are > isomorphic (to each other). I think yes. > > Thanks, > > gregg > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From michael at snoyman.com Fri Feb 6 00:09:37 2009 From: michael at snoyman.com (Michael Snoyman) Date: Thu Feb 5 23:59:38 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! In-Reply-To: <20090206005828.GL21583@whirlpool.galois.com> References: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> <498AF64E.2080902@functor.nl> <498AFAD7.3020600@btinternet.com> <20090206005828.GL21583@whirlpool.galois.com> Message-ID: <29bf512f0902052109k64e3d243o1e47ac41f4762131@mail.gmail.com> On Thu, Feb 5, 2009 at 4:58 PM, Don Stewart wrote: > > A comparative analysis of the 10+ Haskell web frameworks would be > awesome. > > happstack, wash, fastcgi.., turbinado, perpubplat, riviera, salvia, > kibro, ella, what was that one launched yesterday? *ah, yesod... > Wow, that's a lot more frameworks than I realized... Anyway, I'm the guy who just started that new one, yesod. I don't think it's a good thing that there are so many of these unfinished web frameworks out there, and starting more is probably not that helpful. I did so because, as far as I can tell, none of the other frameworks out there are even remotely interested in the same goals as me. Happs(tack) seems to have thrown all convention about web frameworks out the window, which is fine, but not exactly usable in many conventional scenarios. Wash, fastcgi, and kibro all seem very low-level to me. Wash and fastcgi seem to correlate pretty well to ASP and FCGI.pm to me, which frankly don't provide much more than basic help in creating web sites. Turbinado seems to be the closest to what I would imagine as a mainstream framework. However, it is ignoring some features currently that I consider vital (correct me if I'm wrong): * Can run on a shared host. This means something like FastCGI, not its own server. * It's not aiming for any high-level Javascript/AJAX integration. I frankly think the generating plain HTML on the backend style is a little outdated at this point, and think we need to start exploring more advanced web development techniques. That said, if there's an existing web framework that has any interest in those two goals, I'd be happy to contribute to that instead of fracturing the community any more. It would be great if we could get some serious support behind a single framework. Obviously, I have more opinions than the two I just listed (I previously linked to a 14-point blog entry on the subject), but the others I would be willing to forego to achieve unity. Anyway, that's my plea. Sorry if it hijacked this thread too much. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/e39e900d/attachment.htm From michael at snoyman.com Fri Feb 6 00:14:05 2009 From: michael at snoyman.com (Michael Snoyman) Date: Fri Feb 6 00:04:05 2009 Subject: [Haskell-cafe] Automation and COM In-Reply-To: References: Message-ID: <29bf512f0902052114m2e3ffa7fk6db9a454eee8886e@mail.gmail.com> On Wed, Feb 4, 2009 at 3:55 AM, G?nther Schmidt wrote: > Hi, > > has anyone yet been using Sigbjorns COM package? > > Sigbjorn hasn't had the time yet to gather some docs on how to use it, so I > wonder if someone else could post some examples on how to use it. I'm asking > because I need to do some COM stuff with excel, which I know how to do in > another language, but can't seem to get it even started with haskell. > > Any help appreciated. > I just used the package for a project at work. Unfortunately, due to the nature of the project I can't post the code here. I'll try to work up a contrived example to demonstrate how to use it a bit, but e-mail me if you have any direct questions. I won't claim to be an expert, but I was able to pass some SAFEARRAYs to methods and such. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090205/52e6b829/attachment.htm From miguelimo38 at yandex.ru Fri Feb 6 01:12:21 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Fri Feb 6 01:02:31 2009 Subject: [Haskell-cafe] morphisms in IO In-Reply-To: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> References: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> Message-ID: <9C717938-3944-4FAC-8F84-E183F92312BC@yandex.ru> On 6 Feb 2009, at 05:52, Gregg Reynolds wrote: > I'm working on a radically different way of looking at IO. Before I > post it and make a fool of myself, I'd appreciate a reality check on > the following points: > > a) Can IO be thought of as a category? I think the answer is yes. What couldn't? Everything could be thought of as category, linear space, graph or matroid - you'll need some intellectual efforts for that, but it certainly could be done. > b) If it is a category, what are its morphisms? I think the answer > is: it has no morphisms. Oops. Than it's empty. In a category, every object has at least an identity morphism. > c) All categories with no morphisms ("bereft categories"?) are > isomorphic (to each other). I think yes. Yes, all empty categories are isomorphic. No, categories with identity morphisms only are not isomorphic in general. Yes, all categories with no morphisms except identities are equivalent. No, such categories are not very useful and there is no need to apply categorical language to them - thinking in terms of set (class) of objects would be easier. From dev at mobileink.com Fri Feb 6 01:13:32 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Fri Feb 6 01:03:32 2009 Subject: [Haskell-cafe] morphisms in IO In-Reply-To: <498BBD51.5040602@imageworks.com> References: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> <498BBD51.5040602@imageworks.com> Message-ID: <75cc17ac0902052213r33c2544bnade2483b2f120dcb@mail.gmail.com> On Thu, Feb 5, 2009 at 10:32 PM, Dan Weston wrote: > I truly have no idea what you are saying (and probably not even what I am > saying), but I suspect: > > a) You are calling IO the target category of applying the functor IO [taking > a to IO a and (a->b) to (IO a -> IO b)] to Hask. > > b) This category is hardly bereft, nor discrete. Its morphisms are IO a -> > IO b. Well, that's a function in Haskell, yes; but does it represent a morphism /in/ the category? It looks more like a Functor morphism to me. > > c) What you are calling a "bereft" category is an empty category. Without > (identity) morphisms, there can be no objects. There is only one such Right, I meant other than Id morphisms. I guess "discrete" is the correct term. > category (the empty category), so naturally any two such are isomorphic (for > what it's worth, which I suspect is not much). Thanks, g From tom.davie at gmail.com Fri Feb 6 02:08:54 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Fri Feb 6 01:58:59 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: References: Message-ID: <5C7FA92D-43B3-4894-ACD4-BF7CDE8C0960@gmail.com> On 5 Feb 2009, at 22:11, Andrew Wagner wrote: > So we all know the age-old rule of thumb, that unsafeXXX is simply > evil and anybody that uses it should be shot (except when it's ok). > > I understand that unsafeXXX allows impurity, which defiles our > ability to reason logically about haskell programs like we would > like to. My question is, to what extent is this true? > > Suppose we had a module, UnsafeRandoms, which had a function that > would allow you to generate a different random number every time you > call it. The semantics are relatively well-defined, impurity is > safely sectioned off in its own impure module, which is clearly > labeled as such. How much damage does this do? The problem here is composability ? you have no idea how far your non referentially transparent code has spread, because you can compose functions together willy nilly, meaning your random numbers can get pushed through all sorts of things, and cause odd behaviors (e.g. if a constant happens to get evaluated twice rather than once, and return different values each time). > Can we push the lines elsewhere? Is sectioning unsafeXXX into Unsafe > modules a useful idiom that we can use for other things as well? Well not useful modules, but useful types instead. The point of IO for example is to deliberately construct an environment in which you can't get one of your unsafe values out into the referentially transparent world ? the IO type denotes the line on which one side contains unsafe values, and the other side does not. There are however some instances where unsafe functions *are* safe, Conal's unamb function for example, always returns the same value (as long as its precondition is met), even though it contains IO based code to race the values. There are also some instances where unsafe functions are safe purely through force of will. For example: type ResourcePath = FilePath loadImageResource :: ResourcePath -> Image loadImageResource = unsafePerformIO . loadImage =<< readFile This is safe iff you treat the resource as a part of your program, just like your program's code, if it changes, the world falls down, but as long as it's still there and still the same, you're entirely safe. Bob From barsoap at web.de Fri Feb 6 02:15:23 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Feb 6 02:05:34 2009 Subject: [Haskell-cafe] Re: Just how unsafe is unsafe References: <498B5BF3.5060405@pikewerks.com> Message-ID: <20090206081523.1eba94fe@solaris> Peter Verswyvelen wrote: > I do have asked myself the question whether a "really random > generating" function could be regarded as "pure" somehow (actually > would a true random function still be a mathematical function?) > Wasn't there some agreement some time ago on this list that the universe itself is pure and computers are just simulating impurity by being, essentially, state monads on steroids? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From barsoap at web.de Fri Feb 6 02:30:30 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Feb 6 02:20:43 2009 Subject: [Haskell-cafe] Re: Haskell tutorial for pseudo users? References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49875DB8.8010602@btinternet.com> <1233882201.19682.88.camel@jcchost> Message-ID: <20090206083030.56c3e6d4@solaris> Jonathan Cast wrote: > On Mon, 2009-02-02 at 20:55 +0000, Andrew Coppin wrote: > > Deniz Dogan wrote: > > > Learn You a Haskell for Great Good (http://learnyouahaskell.com/) > > > > Mmm, interesting. > > > > Does anybody else think it would be neat if GHCi really did > > colourise your input like that? > > Bleah. More terminal hacking to break and/or slow Emacs to a crawl? > No thanks. > A while ago, I'd say that emacs looks like a decent operating system, sadly lacking a decent editor. Now it seems that it's even lacking a decent terminal. I'm really not sure what to make of all that: Would you recommend using it? Eternal flamewars cast aside, what about integrating such a thing into yi? Yi has the advantage of working for both masochists _and_ efficient typists. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From jonathanccast at fastmail.fm Fri Feb 6 02:44:16 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 6 02:34:16 2009 Subject: [Haskell-cafe] Re: Haskell tutorial for pseudo users? In-Reply-To: <20090206083030.56c3e6d4@solaris> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49875DB8.8010602@btinternet.com> <1233882201.19682.88.camel@jcchost> <20090206083030.56c3e6d4@solaris> Message-ID: <1233906256.6199.7.camel@jonathans-macbook> On Fri, 2009-02-06 at 08:30 +0100, Achim Schneider wrote: > Jonathan Cast wrote: > > On Mon, 2009-02-02 at 20:55 +0000, Andrew Coppin wrote: > > > Deniz Dogan wrote: > > > > Learn You a Haskell for Great Good (http://learnyouahaskell.com/) > > > > > > Mmm, interesting. > > > > > > Does anybody else think it would be neat if GHCi really did > > > colourise your input like that? > > > > Bleah. More terminal hacking to break and/or slow Emacs to a crawl? > > No thanks. > > > A while ago, I'd say that emacs looks like a decent operating system, > sadly lacking a decent editor. I always wonder how many people who say that have actually *tried* Emacs' editor. > Now it seems that it's even lacking a > decent terminal. Actually, I think the issue is just that Emacs' ANSI color parsing code is effectively O(n^2); when I really, really need colored output I run the command in a separate window (with B&W output) and switch major modes. Emacs' terminal is also lacking all the modern conveniences, like addressable cursors and builtin line-editing designed for 1970s printing terminals and practically no searching capabilities. Alternatively, you could say it's incompatible with modern Unix's biggest mistakes and worst legacy issues. > I'm really not sure what to make of all that: Would > you recommend using it? Of course. It sucks the least of any solution I've tried. Barely. > Eternal flamewars cast aside, what about integrating such a thing into > yi? Yi has the advantage of working for both masochists _and_ efficient > typists. Yi has a terminal? Maybe I should try it again. jcc From barsoap at web.de Fri Feb 6 03:02:15 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Feb 6 02:52:22 2009 Subject: [Haskell-cafe] How to properly design a Haskell TK Message-ID: <20090206090215.2517b26b@solaris> I've been thinking a bit, and come to the conclusion that we should just do it as others did it before: Start off with application-specific tk's, figure out what's cool and what's compatible and then put them into libraries. In short: Stop building cathedrals. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From lrpalmer at gmail.com Fri Feb 6 03:09:45 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Fri Feb 6 02:59:43 2009 Subject: [Haskell-cafe] How to properly design a Haskell TK In-Reply-To: <20090206090215.2517b26b@solaris> References: <20090206090215.2517b26b@solaris> Message-ID: <7ca3f0160902060009p613b0383xefee4527281aeef9@mail.gmail.com> On Fri, Feb 6, 2009 at 1:02 AM, Achim Schneider wrote: > I've been thinking a bit, and come to the conclusion that we should > just do it as others did it before: Start off with application-specific > tk's, figure out what's cool and what's compatible and then put them > into libraries. In short: Stop building cathedrals. I don't know what you mean by "TK", but whatever it means, I wholeheartedly support this sentiment! Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/640994d5/attachment.htm From bulat.ziganshin at gmail.com Fri Feb 6 03:20:39 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 6 03:14:59 2009 Subject: [Haskell-cafe] (Off-topic) CUDA In-Reply-To: <498A9F02.8070305@btinternet.com> References: <498A9F02.8070305@btinternet.com> Message-ID: <157939287.20090206112039@gmail.com> Hello Andrew, Thursday, February 5, 2009, 11:10:42 AM, you wrote: > Does anybody know how to make this stuff actually work? nvidia has cuda site where you can download sdk. afair, dr dobbs journal has (online) series of arcticles which describes how to program it step-by-step > (Also... Haskell on the GPU. It's been talked about for years, but will > it ever actually happen?) gpu is just set of simd-like instructions. so the reason why you will never see haskell on gpu is the same as why you will never see it implemented via simd instructions :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Fri Feb 6 03:27:43 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 6 03:24:55 2009 Subject: [Haskell-cafe] How to properly design a Haskell TK In-Reply-To: <7ca3f0160902060009p613b0383xefee4527281aeef9@mail.gmail.com> References: <20090206090215.2517b26b@solaris> <7ca3f0160902060009p613b0383xefee4527281aeef9@mail.gmail.com> Message-ID: <31394304.20090206112743@gmail.com> Hello Luke, Friday, February 6, 2009, 11:09:45 AM, you wrote: > I've been thinking a bit, and come to the conclusion that we should > just do it as others did it before: Start off with application-specific > tk's, figure out what's cool and what's compatible and then put them > into libraries. In short: Stop building cathedrals. > I don't know what you mean by "TK", but whatever it means, I > wholeheartedly support this sentiment! he said "tk", and i think that his sentence quantified over any tk :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From david.waern at gmail.com Fri Feb 6 03:40:13 2009 From: david.waern at gmail.com (David Waern) Date: Fri Feb 6 03:30:14 2009 Subject: [Haskell-cafe] Re: Haddock In-Reply-To: References: <1C6E59C47F062E42820BEE74FD3388E91E482D9A0F@EA-EXMSG-C333.europe.corp.microsoft.com> Message-ID: 2009/2/6 Max Rabkin : > On Thu, Feb 5, 2009 at 4:25 PM, David Waern wrote: >> As for running arbitrary commands, I think we are opening up to a lot >> of unfamiliar syntax. I'd like to hear what everyone thinks about >> that. > > I personally find it useful to have Haddock comments readable in the source. > > And aren't there security issues, too? So we'd have to have an option > to disable them, which would have to be on by default, and basically > they would be disabled by everybody but the writers of the comments > themselves. I think you can invoke any command using Setup.hs and Cabal already. David From aneumann at inf.fu-berlin.de Fri Feb 6 03:40:01 2009 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Fri Feb 6 03:30:25 2009 Subject: [Haskell-cafe] (Off-topic) CUDA In-Reply-To: <498A9F02.8070305@btinternet.com> References: <498A9F02.8070305@btinternet.com> Message-ID: <509D9012-5685-4186-8FAA-5415E4586CC6@inf.fu-berlin.de> Am 05.02.2009 um 09:10 schrieb Andrew Coppin: > And so, inspired by the marketing litrature, I just spent ??? on a > very expensive new GPU that supports CUDA. The only problem is... I > can't seem to get any software to use it. > > Does anybody know how to make this stuff actually work? > > (Also... Haskell on the GPU. It's been talked about for years, but > will it ever actually happen?) Have a look at Obsidian > http://www.cse.chalmers.se/~joels/ and ask Mr Svenson if there is anything working. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: Signierter Teil der Nachricht Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/229bb870/PGP.bin From malcolm.wallace at cs.york.ac.uk Fri Feb 6 03:49:56 2009 From: malcolm.wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Feb 6 03:39:55 2009 Subject: [Haskell-cafe] (Off-topic) CUDA In-Reply-To: <157939287.20090206112039@gmail.com> References: <498A9F02.8070305@btinternet.com> <157939287.20090206112039@gmail.com> Message-ID: <2A15B738-0CBB-40B4-83FD-6BB17815A92E@cs.york.ac.uk> >> (Also... Haskell on the GPU. It's been talked about for years, but >> will >> it ever actually happen?) > > gpu is just set of simd-like instructions. so the reason why you will > never see haskell on gpu is the same as why you will never see it > implemented via simd instructions :D Because SIMD/GPU deals only with numbers, not pointers, you will not see much _symbolic_ computation being offloaded to these arithmetic units. But there are still great opportunities to improve Haskell's speed at numerics using them. And some symbolic problems can be encoded using integers. There are at least two current (but incomplete) projects in this area: Sean Lee at UNSW has targetted Data Parallel Haskell for an Nvidia GPGPU, and Joel Svensson at Chalmers is developing a Haskell-embedded language for GPU programming called Obsidian. Regards, Malcolm From bulat.ziganshin at gmail.com Fri Feb 6 04:05:36 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 6 03:56:02 2009 Subject: [Haskell-cafe] (Off-topic) CUDA In-Reply-To: <2A15B738-0CBB-40B4-83FD-6BB17815A92E@cs.york.ac.uk> References: <498A9F02.8070305@btinternet.com> <157939287.20090206112039@gmail.com> <2A15B738-0CBB-40B4-83FD-6BB17815A92E@cs.york.ac.uk> Message-ID: <1679824675.20090206120536@gmail.com> Hello Malcolm, Friday, February 6, 2009, 11:49:56 AM, you wrote: >> gpu is just set of simd-like instructions. so the reason why you will >> never see haskell on gpu is the same as why you will never see it >> implemented via simd instructions :D > Because SIMD/GPU deals only with numbers, not pointers, you will not > see much _symbolic_ computation being offloaded to these arithmetic > units. But there are still great opportunities to improve Haskell's > speed at numerics using them. And some symbolic problems can be > encoded using integers. are you learned gpu asm? the *only* type of problems it can effectively run is massive-parallel computations. you can run anything on it, but much slower that on cpu > There are at least two current (but incomplete) projects in this area: > Sean Lee at UNSW has targetted Data Parallel Haskell for an Nvidia > GPGPU, and Joel Svensson at Chalmers is developing a Haskell-embedded > language for GPU programming called Obsidian. key word here *parallel*, i.e. simd computations -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From paolo at hypersonic.it Fri Feb 6 04:12:42 2009 From: paolo at hypersonic.it (Paolo Losi) Date: Fri Feb 6 04:03:02 2009 Subject: [Haskell-cafe] Re: Switching from Mercurial to Darcs In-Reply-To: <498B698D.6070005@henning-thielemann.de> References: <498B698D.6070005@henning-thielemann.de> Message-ID: <498BFF0A.8030808@hypersonic.it> Henning Thielemann wrote: >> 4) hg commit -m "message" >> this commits my changes locally. I always do this before pulling since >> then I'm sure my changes are saved in the case a merge goes wrong. > > In old darcs its precisely the other way round. Since it is so slow on > merging ready patches, you better merge uncrecorded changes. IMO pulling & merging before commit is a good practise also for hg: it avoids a (very often useless) merge commit in the history. Pao From magnus at therning.org Fri Feb 6 04:14:47 2009 From: magnus at therning.org (Magnus Therning) Date: Fri Feb 6 04:04:48 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: References: Message-ID: On Fri, Feb 6, 2009 at 12:35 AM, David Waern wrote: [..] > As for running arbitrary commands, I think we are opening up to a lot > of unfamiliar syntax. I'd like to hear what everyone thinks about > that. How do I find out what I need to install in order to build documentation for a specific package on Hackage? (Will cabal be extended to introduce dependencies on tools?) There's also the distinct risk that someone's system gets completely hosed by running Haddock on a Haskell source file. I'm not necessarily saying it's a security problem (though that aspect is worth considering), I'm more worried about someone writing Haddock docs that rely on system layout. I'd say limiting it to a set of application, a set that grows as needed, where each tool satisfies the following: * readily available on all platforms that has a Haskell runtime that Haddock is happy with * traditionally used to process or generate text/images (somewhat vague but e.g. no cop-out by adding bash to the set) Adding LaTeX now, and other tools as needed/requested later would be my suggestion. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus?therning?org Jabber: magnus?therning?org http://therning.org/magnus identi.ca|twitter: magthe From alistair at abayley.org Fri Feb 6 04:24:07 2009 From: alistair at abayley.org (Alistair Bayley) Date: Fri Feb 6 04:14:10 2009 Subject: [Haskell-cafe] haddock-2.3.0 literate comments discarded from .lhs input Message-ID: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> I have this test case for Haddock (2.3.0): -------------------------------------------------- | Module : Test.Haddock Copyright : (c) 2009 Alistair Bayley License : BSD-style Maintainer : alistair@abayley.org Stability : stable Portability : portable Test case for Haddock. > module Test.Haddock > ( > -- $named_block > Fail(..) > ) > where > data Fail = Fail | Succeed $named_block This is some hadock documentation. -------------------------------------------------- This fails with: [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) Test\Fail.hs:11:26: Can't make a derived instance of `Typeable Fail' (You need -XDeriveDataTypeable to derive an instance for this class) In the data type declaration for `Fail' If I manually unlit, then Haddock is happy: -------------------------------------------------- -- | -- Module : Test.Haddock2 -- Copyright : (c) 2009 Alistair Bayley -- License : BSD-style -- Maintainer : alistair@abayley.org -- Stability : stable -- Portability : portable -- -- Test case for Haddock. module Test.Haddock2 ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed -- $named_block -- -- This is some hadock documentation. -------------------------------------------------- so it looks as though it's discarding the literate comments. Is this intended? I was under the impression that because it used the ghc parser, it could now properly handle .lhs input. Ona related note, we have a nice unlitter in cabal that would preserve these comments before invoking haddock. Is this still used with haddock2, or does it now assume haddock2 will do the right thing? Alistair From devriese at cs.tcd.ie Fri Feb 6 04:53:52 2009 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Fri Feb 6 04:43:53 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: <498B5BF3.5060405@pikewerks.com> References: <498B5BF3.5060405@pikewerks.com> Message-ID: <20090206095352.GA11560@netsoc.tcd.ie> Hi, > My opinion is that unsafeXXX is acceptable only when its use is > preserved behind an abstraction that is referentially transparent and > type safe. Others may be able to help refine this statement. I would agree with this. The problem is that impurity spreads easily. For example, suppose we have this truly random number generator, 'random'. As soon as we have this, then *almost every* function is potentially impure: f :: Integer -> Integer f x = random + x g :: [Integer] g = repeat random etc. etc. The compiler has no way of tracking impurity other than through the type system which is, of course, exactly what monads do. To echo the sentiment above, the only safe way to use unsafePerformIO is to hide it behind a function that *is* guaranteed to be pure (i.e., returns the same values for the same arguments, can be inlined, etc.). And even then, I would recommend against it. Let me give a *practical* reason why. For a long time, I would never even have considered unsafePerformIO, but I recently had an application that needed unique global identifiers in lots of places, and I was reluctant to pass state around everywhere; *but* I could hide it in a few functions, which were themselves pure. It looked something like: -- Replace (some) name by a number quote :: Integer -> Term -> Term -- Replace a number by (that) name unquote :: Name -> Term -> Term -- Typical usage foo t == let l = getUnsafeUniqueGlobalIdentifier () in unquote l . do some stuff . quote l Since "unquote l . quote l" is an identity operation, 'foo' itself is pure -- provided that nothing in 'do some stuff' relies on the exact identity of the identifier. --- A rule which I broke at some point, got some very strange behaviour, and took me ages to debug. This was mostly due to laziness, which made the point of execution of the unsafe operation to be very difficult to predict. For example, every call to getUnsafeUniqueGlobalIdentifier (it wasn't actually called that, don't worry :-) yielded a number one higher than the previous. However, in a list of terms [t1, t2, .., tn] all of which include some unique idnetifier, it is *not* the generation of the list that determines whether the identifiers in these terms are incrementing, but the *evaluation* of the list -- when are the terms forced to normal form. I was called 'sort' on this list, and sort depended on the values of these identifiers -- but since sort evaluated the terms in the list to normal form in a hard to predict order, the order of the list was anything but sorted! --- Moreover, you need all sorts of compiler options or nasty hacks (the unit argument to getUnsafeUniqueGlobalIdentifier above is no mistake) to avoid the compiler optimizing your code in ways that you did not expect. In the end, I ended up rewriting the entire application to avoid the use of this global unique identifiers, because it was simply too difficult to get right. I felt I was writing C code again and was chasing bugs due to dangling pointers and the wrong memory being used. Not a time I want to return to! Moral of the story: unless you really really need to and really really know what you are doing -- do not use unsafePerformIO. Uncontrolled side effects and lazines will cause extremely hard to track behaviour in your program, and things are almost guaranteed to go wrong. Edsko From kkwweett at hotmail.fr Fri Feb 6 05:01:30 2009 From: kkwweett at hotmail.fr (Paul Langevin) Date: Fri Feb 6 04:51:31 2009 Subject: [Haskell-cafe] Re : OpenAL Message-ID: by the way, a mean to get it done without error is to not use runALUTUsingCurrentContext : import Sound.ALUT playSound :: IO () playSound = withProgNameAndArgs runALUT $ \ _ _ -> do buffer1 <- createBuffer $ Sine 440 0 1 buffer2 <- createBuffer HelloWorld [source] <- genOjectNames 1 queueBuffers source [buffer1,buffer2] play [source] sleep 2 return () main = playSound I'm not sure if haskell-cafe will take spaces into account. If not, only 7 lines should be tabulated after do. Does anyone know how to mix buffers ? _________________________________________________________________ Vous voulez savoir ce que vous pouvez faire avec le nouveau Windows Live?? Lancez-vous ! http://www.microsoft.com/windows/windowslive/default.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/5b060e07/attachment.htm From david.waern at gmail.com Fri Feb 6 05:18:41 2009 From: david.waern at gmail.com (David Waern) Date: Fri Feb 6 05:08:46 2009 Subject: [Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> Message-ID: 2009/2/6 Alistair Bayley : > I have this test case for Haddock (2.3.0): > > -------------------------------------------------- > > | > Module : Test.Haddock > Copyright : (c) 2009 Alistair Bayley > License : BSD-style > Maintainer : alistair@abayley.org > Stability : stable > Portability : portable > > Test case for Haddock. > > >> module Test.Haddock >> ( >> -- $named_block >> Fail(..) >> ) >> where >> data Fail = Fail | Succeed > > $named_block > > This is some hadock documentation. > > -------------------------------------------------- > > This fails with: > > [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) > > Test\Fail.hs:11:26: > Can't make a derived instance of `Typeable Fail' > (You need -XDeriveDataTypeable to derive an instance for this class) > In the data type declaration for `Fail' Are you processing the above module but it is called Test.Fail in reality? Have you stripped out a deriving statement from the example above? I'm very confused by this message :) David From nad at Cs.Nott.AC.UK Fri Feb 6 05:11:29 2009 From: nad at Cs.Nott.AC.UK (Nils Anders Danielsson) Date: Fri Feb 6 05:10:01 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <498C0CD1.5090707@cs.nott.ac.uk> On 2009-02-05 15:20, Gregg Reynolds wrote: > I think I've just about got monads figured out, but [...] I don't think anyone has mentioned Simon's "Tackling the awkward squad" paper in this thread. This tutorial, which contains a semantics for a subset of IO, should answer some of the questions raised. http://research.microsoft.com/en-us/um/people/simonpj/Papers/marktoberdorf/ -- /NAD This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From marcot at holoscopio.com Fri Feb 6 05:28:43 2009 From: marcot at holoscopio.com (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Fri Feb 6 05:18:47 2009 Subject: [Haskell-cafe] Error in building profiling In-Reply-To: <1233873511.18688.143.camel@quindinho.domain.invalid> References: <1233873511.18688.143.camel@quindinho.domain.invalid> Message-ID: <1233916123.18688.186.camel@quindinho.domain.invalid> Hi, Em Qui, 2009-02-05 ?s 20:38 -0200, Marco T?lio Gontijo e Silva escreveu: > I'm trying to package ghc-paths for debian, and I got to this: > > $ ./setup configure --enable-library-profiling --disable-library-vanilla > Configuring ghc-paths-0.1.0.5... > $ ./setup build > Preprocessing library ghc-paths-0.1.0.5... > Building ghc-paths-0.1.0.5... > /usr/bin/ar: creating dist/build/libHSghc-paths-0.1.0.5_p.a > /usr/bin/ld: dist/build/GHC/Paths.o: No such file: No such file or > directory > > I thought this could be a problem with this package, but I've tried with > mtl, and I got the same result: > > /usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file > or directory > > I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1. I tried the same with ghc6 6.8.2dfsg1-1 and it worked. Greetings. -- marcot http://marcot.iaaeee.org/ From kkwweett at hotmail.fr Fri Feb 6 05:29:28 2009 From: kkwweett at hotmail.fr (Paul Langevin) Date: Fri Feb 6 05:19:28 2009 Subject: [Haskell-cafe] Re : OpenAL Message-ID: For those who follow, I finally find the way to mix (simpler than I thought) import Sound.ALUT playSound :: IO () playSound = withProgNameAndArgs runALUT $ \ _ _ -> do ? buffer1 <- createBuffer $ Sine 440 0 1 ? buffer2 <- createBuffer $ HelloWorld ? [source1,source2] <- genObjectNames 2 ? buffer source1 $= Just buffer1 ? buffer source2 $= Just buffer2 ? play [source1,source2] ? sleep 2 ? return () main = playSound (sorry if unicode if ugly, I don't know what to do with spaces) _________________________________________________________________ T?l?phonez gratuitement ? tous vos proches avec Windows Live Messenger? !? T?l?chargez-le maintenant !? http://www.windowslive.fr/messenger/1.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/300016a8/attachment.htm From porges at porg.es Fri Feb 6 05:31:34 2009 From: porges at porg.es (George Pollard) Date: Fri Feb 6 05:21:40 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: References: Message-ID: <1233916294.9411.15.camel@porges-laptop> On Fri, 2009-02-06 at 01:35 +0100, David Waern wrote: > I received this question from Lennart Augustsson (via Simon M) and > thought I'd send out an inquiry to the Haskell community in general > (Lennart, I hope you don't mind): > > Lennart writes: > > We have some local patches for haddock that extends the <> > > syntax so you can put TeX formulae in the documentation. > > It looks like, <>, but I'd like to extend it so > > you can process the string with any command. > > > > Are you interested in folding this into the main branch? > > So the question is about extending the Haddock markup language. > > When modifying the language we should think about the tension between > familiarity, presentation features (pictures, math, whatever) and > visual portability across different mediums (HTML, ghci, IDE tooltips, > etc). And here I should say that Haddock already supports pictures > using the << url >> syntax. > > IMHO, adding <> for TeX math is fine, because: > > - math in documentation is often useful > - if you're going to write math, you need a format, even when the > medium is plain text as in ghci. > - TeX formulae seem to be relatively widely used and understood. My comment isn't related to the wider implications of third-party hooks into Haddock, but just for the (La?)TeX stuff itself. I think that the TeX *language* is great for writing mathematics, but that we should be wary of blindly incorporating TeX *output* into Haddock. Most of Haddock's documentation is currently HTML-based, and if we add TeX mathematics in the usual way (i.e. embedding images) it is very ?inaccessible content? (no selection, scaling, and a myriad of other small niggles) compared to the rest of the HTML file. My thoughts would be to use the TeX engine itself for when generating high-quality PDF documentation, and have something else translate TeX to (e.g.) MathML for the HTML pages. There are various programs to do this (or it could be done in Haskell :D!) Thanks, - George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/053abf08/attachment.bin From alistair at abayley.org Fri Feb 6 05:35:18 2009 From: alistair at abayley.org (Alistair Bayley) Date: Fri Feb 6 05:25:26 2009 Subject: [Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> Message-ID: <79d7c4980902060235x5eb42955p196dfe68707daab0@mail.gmail.com> >> [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) >> >> Test\Fail.hs:11:26: >> Can't make a derived instance of `Typeable Fail' >> (You need -XDeriveDataTypeable to derive an instance for this class) >> In the data type declaration for `Fail' > > Are you processing the above module but it is called Test.Fail in > reality? Have you stripped out a deriving statement from the example > above? I'm very confused by this message :) Sorry, my mistake. I pasted the error message from a different problem. This is the error I get from haddock: C:\bayleya\eclipse\workspace\takusen\src>haddock -h --odir=doc Test/Haddock.lhs Cannot find documentation for: $named_block Alistair From roma at ro-che.info Fri Feb 6 05:43:06 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri Feb 6 05:33:09 2009 Subject: [Haskell-cafe] How to properly design a Haskell TK In-Reply-To: <7ca3f0160902060009p613b0383xefee4527281aeef9@mail.gmail.com> References: <20090206090215.2517b26b@solaris> <7ca3f0160902060009p613b0383xefee4527281aeef9@mail.gmail.com> Message-ID: <20090206104306.GA18635@flit> * Luke Palmer [2009-02-06 01:09:45-0700] > On Fri, Feb 6, 2009 at 1:02 AM, Achim Schneider wrote: > > > I've been thinking a bit, and come to the conclusion that we should > > just do it as others did it before: Start off with application-specific > > tk's, figure out what's cool and what's compatible and then put them > > into libraries. In short: Stop building cathedrals. > > > I don't know what you mean by "TK", but whatever it means, I wholeheartedly > support this sentiment! I guess TK stands for "toolkit" (probably a graphical one?), although I like Bulat's version :) -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From ketil at malde.org Fri Feb 6 05:46:50 2009 From: ketil at malde.org (Ketil Malde) Date: Fri Feb 6 05:35:45 2009 Subject: [Haskell-cafe] Re: evaluation semantics of bind In-Reply-To: <75cc17ac0902051838x37b487c1r3ff704a2fdb05c13@mail.gmail.com> (Gregg Reynolds's message of "Thu\, 5 Feb 2009 20\:38\:34 -0600") References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902050818j82de765j214897e9074f6c27@mail.gmail.com> <75cc17ac0902050906u47c4f190pb37ab467513f3d04@mail.gmail.com> <75cc17ac0902050922w165e58f3ja7cc0e14435fefb5@mail.gmail.com> <498B9039.90404@freegeek.org> <75cc17ac0902051838x37b487c1r3ff704a2fdb05c13@mail.gmail.com> Message-ID: <873aerdeqt.fsf@malde.org> Gregg Reynolds writes: > You've defined >>= in such a way that it carries additional semantic > weight. Would it be appropriate to sum up this discussion thusly: 1. What gets and gets not optimized away in a monad depends on the implementation of (>>=) 2. For IO, (>>=) is - must be - implemented in such a way that actions don't get optimized away. For instance as passing around RealWorld as state. 3. While the reason for this should be obvious, any formal specification for this requirement is missing. -k -- If I haven't seen further, it is by standing in the footprints of giants From david.waern at gmail.com Fri Feb 6 05:48:48 2009 From: david.waern at gmail.com (David Waern) Date: Fri Feb 6 05:39:03 2009 Subject: [Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <79d7c4980902060235x5eb42955p196dfe68707daab0@mail.gmail.com> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <79d7c4980902060235x5eb42955p196dfe68707daab0@mail.gmail.com> Message-ID: 2009/2/6 Alistair Bayley : >>> [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) >>> >>> Test\Fail.hs:11:26: >>> Can't make a derived instance of `Typeable Fail' >>> (You need -XDeriveDataTypeable to derive an instance for this class) >>> In the data type declaration for `Fail' >> >> Are you processing the above module but it is called Test.Fail in >> reality? Have you stripped out a deriving statement from the example >> above? I'm very confused by this message :) > > > Sorry, my mistake. I pasted the error message from a different > problem. This is the error I get from haddock: > > C:\bayleya\eclipse\workspace\takusen\src>haddock -h --odir=doc Test/Haddock.lhs > Cannot find documentation for: $named_block Okay, then I understand. My guess is (without looking at ghc code) that ghc just throws the literate comments away before lexing the file. This means that the Haddock comments won't be recognized. As you say, there is also an unlitter in Cabal. I don't remember if it is invoked when using Haddock 2, but if it is, it would solve this problem. David From aslatter at gmail.com Fri Feb 6 07:00:21 2009 From: aslatter at gmail.com (Antoine Latter) Date: Fri Feb 6 06:50:21 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: References: Message-ID: <694519c50902060400ma5b5834nb333157f90942e97@mail.gmail.com> On Thu, Feb 5, 2009 at 3:11 PM, Andrew Wagner wrote: > So we all know the age-old rule of thumb, that unsafeXXX is simply evil and > anybody that uses it should be shot (except when it's ok). > I understand that unsafeXXX allows impurity, which defiles our ability to > reason logically about haskell programs like we would like to. My question > is, to what extent is this true? Tangential to all of this - sometimes my unsafeXXX functions are pure, but partial. So I'll have: foo :: a -> b -> Maybe c and unsafeFoo :: a -> b -> c -Antoine From bugfact at gmail.com Fri Feb 6 08:45:27 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Fri Feb 6 08:35:26 2009 Subject: [Haskell-cafe] How to properly design a Haskell TK In-Reply-To: <20090206104306.GA18635@flit> References: <20090206090215.2517b26b@solaris> <7ca3f0160902060009p613b0383xefee4527281aeef9@mail.gmail.com> <20090206104306.GA18635@flit> Message-ID: I don't think we need one large GUI toolkit. We need orthogonal little pieces that could be combined together into a toolkit... Less is more... So first we need to identify what these pieces really are, what they "mean" and how they can be composed together to make a bigger thing... So what *is* a GUI anyway? Anyway, I'm afraid as soon as you start with that, you will end up with something like Reactive and Fieldtrip, which is still work in progress and not yet proven to work, but it does not mean we can't discuss about it :) On Fri, Feb 6, 2009 at 11:43 AM, Roman Cheplyaka wrote: > * Luke Palmer [2009-02-06 01:09:45-0700] > > On Fri, Feb 6, 2009 at 1:02 AM, Achim Schneider wrote: > > > > > I've been thinking a bit, and come to the conclusion that we should > > > just do it as others did it before: Start off with application-specific > > > tk's, figure out what's cool and what's compatible and then put them > > > into libraries. In short: Stop building cathedrals. > > > > > > I don't know what you mean by "TK", but whatever it means, I > wholeheartedly > > support this sentiment! > > I guess TK stands for "toolkit" (probably a graphical one?), although I > like Bulat's version :) > > -- > Roman I. Cheplyaka :: http://ro-che.info/ > "Don't let school get in the way of your education." - Mark Twain > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/bcb87a6f/attachment.htm From deniz.a.m.dogan at gmail.com Fri Feb 6 08:56:00 2009 From: deniz.a.m.dogan at gmail.com (Deniz Dogan) Date: Fri Feb 6 08:46:00 2009 Subject: [Haskell-cafe] Re: Haskell tutorial for pseudo users? In-Reply-To: <1233906256.6199.7.camel@jonathans-macbook> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49875DB8.8010602@btinternet.com> <1233882201.19682.88.camel@jcchost> <20090206083030.56c3e6d4@solaris> <1233906256.6199.7.camel@jonathans-macbook> Message-ID: <7b501d5c0902060556x2e96025avb82b6952cf5fc0f2@mail.gmail.com> 2009/2/6 Jonathan Cast : > Emacs' terminal is also lacking all the modern conveniences, like > addressable cursors and builtin line-editing designed for 1970s printing > terminals and practically no searching capabilities. Alternatively, you > could say it's incompatible with modern Unix's biggest mistakes and > worst legacy issues. With the risk of making this even more OT: Emacs has three different types of shells built-in, at least to my knowledge. These are M-x shell, eshell and term. I'm not sure which one you are referring to as "Emacs' terminal", if any of them, but inf-haskell.el uses "shell" afaics. And what do you mean with "no searching capabilites?" What kind of searching are we talking here? Deniz From vandijk.roel at gmail.com Fri Feb 6 09:40:47 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Fri Feb 6 09:30:49 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: <694519c50902060400ma5b5834nb333157f90942e97@mail.gmail.com> References: <694519c50902060400ma5b5834nb333157f90942e97@mail.gmail.com> Message-ID: On Fri, Feb 6, 2009 at 1:00 PM, Antoine Latter wrote: > Tangential to all of this - sometimes my unsafeXXX functions are pure, > but partial. ?So I'll have: > > foo :: a -> b -> Maybe c > > and > > unsafeFoo :: a -> b -> c I use the "unsafe" prefix in the same way. For me it means 'assume that preconditions hold'. If the preconditions do not hold and you evaluate an unsafe function anyway I would expect an error, as opposed to an exception. I have done that in my (tiny) roman numerals package. -- simplified toRoman :: Int -> Either String Int unsafeToRoman :: Int -> String The first function is very clear about the fact that something can go wrong. If you provide it with a value of (-3) it will (hopefully) produce something like 'Left "no negative numbers allowed"'. The second function hides this fact and will result in a (uncatchable) runtime error. It is still a pure function, but preventing errors is now the responsibility of whoever evaluates it. From lemming at henning-thielemann.de Fri Feb 6 09:55:04 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 6 09:45:04 2009 Subject: [Haskell-cafe] Mutually recursive modules Message-ID: I have written a small overview, how mutually recursive modules are currently supported and how they can be avoided: http://haskell.org/haskellwiki/Mutually_recursive_modules Please add information about other compilers and more ideas on breaking cycles. From g9ks157k at acme.softbase.org Fri Feb 6 10:03:29 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Fri Feb 6 09:53:33 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <1233916294.9411.15.camel@porges-laptop> References: <1233916294.9411.15.camel@porges-laptop> Message-ID: <200902061603.29609.g9ks157k@acme.softbase.org> Am Freitag, 6. Februar 2009 11:31 schrieb George Pollard: > I think that the TeX *language* is great for writing mathematics, > but that we should be wary of blindly incorporating TeX *output* > into Haddock. > > Most of Haddock's documentation is currently HTML-based, and > if we add TeX mathematics in the usual way (i.e. embedding images) > it is very ?inaccessible content? (no selection, scaling, and a myriad > of other small niggles) compared to the rest of the HTML file. > My thoughts would be to use the TeX engine itself for when generating > high-quality PDF documentation, and have something else translate TeX > to (e.g.) MathML for the HTML pages. There are various programs to do this > (or it could be done in Haskell :D!) TeX is not so great for mathematics and especially not for conversion into MathML (which would be needed for HTML output). The TeX math language provides rather little semantic information. As input language for the concrete software named TeX this is mostly okay since the concrete rendering algorithm of TeX doesn?t need certain information (for example, about implicit bracketing). However, even for rendering with TeX, you sometimes have to ressort to ugly tricks since TeX sometimes misinterprets what you wrote. Knuth gives some examples in chapter 18 of The TeXbook. For conversion into MathML, a TeX source generally doesn?t have enough information since even presentation MathML code contains much more structure than ordinary TeX source code does. So using TeX as a general language for math is a very bad idea, in my opinion. The problem is that there is no good language which provides enough structural information for conversion into MathML and is at the same time simple to write and read. Maybe, both requirements contradict. Best wishes, Wolfgang From colin at colina.demon.co.uk Fri Feb 6 10:10:11 2009 From: colin at colina.demon.co.uk (Colin Paul Adams) Date: Fri Feb 6 10:00:12 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: (Roel van Dijk's message of "Fri\, 6 Feb 2009 15\:40\:47 +0100") References: <694519c50902060400ma5b5834nb333157f90942e97@mail.gmail.com> Message-ID: >>>>> "Roel" == Roel van Dijk writes: Roel> On Fri, Feb 6, 2009 at 1:00 PM, Antoine Latter wrote: >> Tangential to all of this - sometimes my unsafeXXX functions >> are pure, but partial. ?So I'll have: >> >> foo :: a -> b -> Maybe c >> >> and >> >> unsafeFoo :: a -> b -> c Roel> I use the "unsafe" prefix in the same way. For me it means Roel> 'assume that preconditions hold'. If the preconditions do Roel> not hold and you evaluate an unsafe function anyway I would Roel> expect an error, as opposed to an exception. I have done Roel> that in my (tiny) roman numerals package. Roel> -- simplified toRoman :: Int -> Either String Int Roel> unsafeToRoman :: Int -> String Roel> The first function is very clear about the fact that Roel> something can go wrong. If you provide it with a value of Roel> (-3) it will (hopefully) produce something like 'Left "no Roel> negative numbers allowed"'. The second function hides this Roel> fact and will result in a (uncatchable) runtime error. It is Roel> still a pure function, but preventing errors is now the Roel> responsibility of whoever evaluates it. Do you document the preconditions? It seems to me that this is more useful than naming a function unsafeXXX. I was using comments to document the contracts on my functions, but I have just found about about ESC/Haskell, so I am now using the contract notation of that (not yet released) tool. See http://www.cl.cam.ac.uk/~nx200/ -- Colin Adams Preston Lancashire From simonpj at microsoft.com Fri Feb 6 10:12:57 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 6 10:02:58 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498AD041.1070200@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A0717.8040809@libero.it> <77D3BA5C-DBBE-45FC-B4A0-F06701D97FD2@z.odi.ac> <498A0AEA.4000104@libero.it> <00BB35D2-3DD3-44F6-8F68-8FF6F50E1F1C@cs.otago.ac.nz> <2608b8a80902050252q2bbdc192oe5668b5053634e8b@mail.gmail.com> <498AD041.1070200@libero.it> Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C3328CA04DDC@EA-EXMSG-C334.europe.corp.microsoft.com> | By the way: it is possible to use a private constructor (via some | special GHC flag?). | I would like to do a quick performance check using the existing | fromRational specialization by constructing a Rational directly. | | I know that Haskell allows declaration hiding for program safety, but | sometimes this can be a nuisance. I think you mean that if you have module M(f) where f = ... g = ... precompiled in a library, is it possible to call g? No, I'm afraid it isn't, at least in GHC. For example, 'g' may no longer exist... it may have been inlined into 'f'. Simon From jonathanccast at fastmail.fm Fri Feb 6 10:35:06 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 6 10:25:11 2009 Subject: [Haskell-cafe] Re: Haddock In-Reply-To: References: <1C6E59C47F062E42820BEE74FD3388E91E482D9A0F@EA-EXMSG-C333.europe.corp.microsoft.com> Message-ID: <1233934506.6545.2.camel@jonathans-macbook> On Fri, 2009-02-06 at 09:40 +0100, David Waern wrote: > 2009/2/6 Max Rabkin : > > On Thu, Feb 5, 2009 at 4:25 PM, David Waern wrote: > >> As for running arbitrary commands, I think we are opening up to a lot > >> of unfamiliar syntax. I'd like to hear what everyone thinks about > >> that. > > > > I personally find it useful to have Haddock comments readable in the source. > > > > And aren't there security issues, too? So we'd have to have an option > > to disable them, which would have to be on by default, and basically > > they would be disabled by everybody but the writers of the comments > > themselves. > I think you can invoke any command using Setup.hs and Cabal already. It's not a question of what's possible. It's a question of how hard it is to audit your code. Do I just have to read your build system (Setup.hs and its import tree, and maybe the Cabal file)? Or do I have to scan the source code for dubious constructs (unfortunately, we already have this issue with Template Haskell)? Most programs have source code that is much larger than their build systems. jcc From kkwweett at hotmail.fr Fri Feb 6 10:54:39 2009 From: kkwweett at hotmail.fr (Paul Langevin) Date: Fri Feb 6 10:44:37 2009 Subject: [Haskell-cafe] Re: OpenAL Message-ID: > AL lib: alSource.c:2291: alcDestroyContext(): 1 Source(s) NOT deleted Brian, have you tried currentContext $= Nothing before closing the device ? It works for me now : no message from ALSA (and still the sounds) _________________________________________________________________ T?l?phonez gratuitement ? tous vos proches avec Windows Live Messenger? !? T?l?chargez-le maintenant !? http://www.windowslive.fr/messenger/1.asp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/7cb5b84d/attachment.htm From lemming at henning-thielemann.de Fri Feb 6 11:32:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 6 11:23:49 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: <498A2E65.4040805@libero.it> References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> <498A2E65.4040805@libero.it> Message-ID: On Thu, 5 Feb 2009, Manlio Perillo wrote: > Yitzchak Gale ha scritto: >> >> Ah, OK. Thanks. Now we have a well-defined problem. :) > > Good :). I have used this example to describe how to avoid big integers at all: http://haskell.org/haskellwiki/Integers_too_big_for_floats From lemming at henning-thielemann.de Fri Feb 6 12:09:26 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 6 11:59:23 2009 Subject: [Haskell-cafe] about integer and float operations Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: Henning Thielemann Subject: Re: [Haskell-cafe] about integer and float operations Date: Fri, 06 Feb 2009 17:50:18 +0100 Size: 2921 Url: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/ed356ade/attachment.eml From lemming at henning-thielemann.de Fri Feb 6 12:09:53 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 6 11:59:51 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! Message-ID: -------------- next part -------------- An embedded message was scrubbed... From: Henning Thielemann Subject: Re: [Haskell-cafe] Happstack 0.1 Released! Date: Fri, 06 Feb 2009 18:05:48 +0100 Size: 2300 Url: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/f36b3681/attachment.eml From jonathanccast at fastmail.fm Fri Feb 6 12:20:44 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 6 12:13:03 2009 Subject: [Haskell-cafe] Re: Haskell tutorial for pseudo users? In-Reply-To: <7b501d5c0902060556x2e96025avb82b6952cf5fc0f2@mail.gmail.com> References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49875DB8.8010602@btinternet.com> <1233882201.19682.88.camel@jcchost> <20090206083030.56c3e6d4@solaris> <1233906256.6199.7.camel@jonathans-macbook> <7b501d5c0902060556x2e96025avb82b6952cf5fc0f2@mail.gmail.com> Message-ID: <1233940844.25917.8.camel@jcchost> On Fri, 2009-02-06 at 14:56 +0100, Deniz Dogan wrote: > 2009/2/6 Jonathan Cast : > > Emacs' terminal is also lacking all the modern conveniences, like > > addressable cursors and builtin line-editing designed for 1970s printing > > terminals and practically no searching capabilities. Alternatively, you > > could say it's incompatible with modern Unix's biggest mistakes and > > worst legacy issues. > > With the risk of making this even more OT: > > Emacs has three different types of shells built-in, at least to my > knowledge. These are M-x shell, eshell and term. I'm not sure which > one you are referring to as "Emacs' terminal", if any of them, but > inf-haskell.el uses "shell" afaics. I believe so. But the colorization support in shell-mode is supplied by comint; comint does fine with colorization normally, but I've had problems with large files in the past. (E.g., comint can't handle the colorized output from a full run of the test suite at work). > And what do you mean with "no > searching capabilites?" What kind of searching are we talking here? Emacs' incremental search (C-r, C-s). Remember that my list is a (sarcastic) list of advantages of M-x shell (and comint) over full-blown Unix terminal emulators --- I had mis-remembered that Konsole and GnomeTerm lacked builtin search capabilities. (Checking, I see that Konsole (KDE 3.5.10, which is what I have at work) does have poorish search support. But Emacs' search is still better!). jcc From lemming at henning-thielemann.de Fri Feb 6 12:30:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 6 12:20:57 2009 Subject: [Haskell-cafe] Happstack 0.1 Released! In-Reply-To: <20090206005828.GL21583@whirlpool.galois.com> References: <987d172d0902041037r186d522fgeca8120098f68e4a@mail.gmail.com> <404396ef0902050255v142c8a0cncbf25f8afa77092d@mail.gmail.com> <498AF64E.2080902@functor.nl> <498AFAD7.3020600@btinternet.com> <20090206005828.GL21583@whirlpool.galois.com> Message-ID: On Thu, 5 Feb 2009, Don Stewart wrote: > andrewcoppin: >> Jochem Berndsen wrote: >>> The HAppS project has been abandoned, see >>> http://groups.google.com/group/HAppS/msg/d128331e213c1031 . >>> >>> The Happstack project is intended to continue development. For more >>> details, see http://happstack.com/faq.html . >>> >>> >> So we've got HAppS, Happstack, WASH, Turbinado, probably others... Does >> anybody know how all these relate to each other? Where their strengths >> and weaknesses lie? >> >> It's nice to have choice, but without knowing what you're choosing >> between, it's hard to use it well. >> > > A comparative analysis of the 10+ Haskell web frameworks would be > awesome. > > happstack, wash, fastcgi.., turbinado, perpubplat, riviera, salvia, > kibro, ella, what was that one launched yesterday? *ah, yesod... I'm afraid that http://haskell.org/haskellwiki/Applications_and_libraries/Web_programming has become less important since all people upload their stuff to Hackage and get automatically indexed and visible this way. However this Wiki page could be used by Web framework authors to advertise their frameworks, read how other authors advertise their work and adapt the own advertising accordingly. This might work like: "My framework can do X, but I didn't mention it, because I thought it is trivial. However since the others find X important, I'll add that to my feature list, too." "I see others support Y. I never thought about that. I'll add it to my ToDo list." "I see others solve problem X the way Y, where I thought my way Z would be the only one. So I'll mention that I solve it by Z and why I did not choose Y.") From overdrigzed at gmail.com Fri Feb 6 12:58:52 2009 From: overdrigzed at gmail.com (Rodrigo Queiro) Date: Fri Feb 6 12:48:49 2009 Subject: [Haskell-cafe] HGL window update problem Message-ID: <2eb8984a0902060958m32109bbl98b7395e811bb10e@mail.gmail.com> In this program, the HGL window only updates when I mouseover it. Can someone tell me why this is / how I should avoid it? Thanks! Rodrigo module Main where import Graphics.HGL import Control.Concurrent import Control.Concurrent.MVar import Control.Monad main = do stringMVar <- newEmptyMVar forkIO . runGraphics $ do w <- openWindowEx "HGLTest" Nothing (300, 100) DoubleBuffered Nothing forever $ do string <- takeMVar stringMVar setGraphic w $ text (0, 0) string forever $ do string <- getLine putMVar stringMVar string From chaddai.fouche at gmail.com Fri Feb 6 13:13:29 2009 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Fri Feb 6 13:03:27 2009 Subject: [Haskell-cafe] Re: ANN: diagrams 0.2 In-Reply-To: References: <20090131223734.GA28526@seas.upenn.edu> <20090201063706.GC30336@berkeley.edu> Message-ID: On Wed, Feb 4, 2009 at 4:56 PM, Gwern Branwen wrote: > > Now, to implement it, I would probably say to myself, "well, we'll > create a temporary file, we'll write some basic imports into it, then > we'll write the user's expression into it as the definition of a > function 'foo', and main will be defined as 'main = renderFile foo'. > Then we use 'runhaskell' on the temporary file to create the picture, > delete the temp file, and bob's your uncle." > > Except of course there's nothing to prevent DoS attacks or other > exploits in the arbitrary code. So do we accept this and say that this > is a plugin one uses at one's own risk? Hackage contains some packages for that sandboxing, like mueval which is now used by lambdabot on #haskell I believe. -- Jeda? From andy.haskell at zambezi.org.uk Fri Feb 6 13:24:35 2009 From: andy.haskell at zambezi.org.uk (Andy Smith) Date: Fri Feb 6 13:14:34 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902061603.29609.g9ks157k@acme.softbase.org> References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> Message-ID: <5540a5470902061024hce004b6l48a99d3aa4e587e4@mail.gmail.com> 2009/2/6 Wolfgang Jeltsch : > So using TeX as a general language for math is a very bad idea, in my opinion. > The problem is that there is no good language which provides enough > structural information for conversion into MathML and is at the same time > simple to write and read. Maybe, both requirements contradict. ASCIIMathML [1] is designed to do this. It doesn't cover everything in Presentation MathML, and makes no attempt to handle Content MathML, but you can do quite a lot with it. The notation has a formally defined grammar and rules for conversion to MathML [2]. [1] http://www1.chapman.edu/~jipsen/asciimath.html [2] http://www1.chapman.edu/~jipsen/mathml/asciimathsyntax.html Andy From vandijk.roel at gmail.com Fri Feb 6 13:25:18 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Fri Feb 6 13:15:18 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: References: <694519c50902060400ma5b5834nb333157f90942e97@mail.gmail.com> Message-ID: > Do you document the preconditions? Yes. The 'safe' variants of those functions have all preconditions listed in the accompanying (haddock) comments. The 'unsafe' variants simply state that they promote exceptions to errors. > It seems to me that this is more useful than naming a function > unsafeXXX. Well, I do both :-) They are called unsafeXXX and they state why they are unsafe. > I was using comments to document the contracts on my functions, but I > have just found about about ESC/Haskell, so I am now using the > contract notation of that (not yet released) tool. > > See http://www.cl.cam.ac.uk/~nx200/ That is interesting. I like formal proofs and preconditions better than informal ones. From gwern0 at gmail.com Fri Feb 6 13:34:30 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Fri Feb 6 13:24:26 2009 Subject: [Haskell-cafe] Re: ANN: diagrams 0.2 In-Reply-To: References: <20090131223734.GA28526@seas.upenn.edu> <20090201063706.GC30336@berkeley.edu> Message-ID: On Fri, Feb 6, 2009 at 1:13 PM, Chadda? Fouch? wrote: > On Wed, Feb 4, 2009 at 4:56 PM, Gwern Branwen wrote: >> >> Now, to implement it, I would probably say to myself, "well, we'll >> create a temporary file, we'll write some basic imports into it, then >> we'll write the user's expression into it as the definition of a >> function 'foo', and main will be defined as 'main = renderFile foo'. >> Then we use 'runhaskell' on the temporary file to create the picture, >> delete the temp file, and bob's your uncle." >> >> Except of course there's nothing to prevent DoS attacks or other >> exploits in the arbitrary code. So do we accept this and say that this >> is a plugin one uses at one's own risk? > > Hackage contains some packages for that sandboxing, like mueval which > is now used by lambdabot on #haskell I believe. Yes, I'm familiar with mueval, but it may not be the right approach in this case (quite aside from the fact that a fair number of changes would be necessary). See my comment on the Pandoc issue: http://code.google.com/p/pandoc/issues/detail?id=102#c9 -- gwern From newsham at lava.net Fri Feb 6 13:34:17 2009 From: newsham at lava.net (Tim Newsham) Date: Fri Feb 6 13:24:42 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> <1233865621.19682.43.camel@jcchost> <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> Message-ID: > So if IO represents a program that when executed interacts with the world's > state, is it safe to say that when I return (State Int Int), that I'm > returning a "State program"? That'd make sense as it really does look like > we force the State to be evaluated with runState, evalState or execState. Yes, exactly. > The only difference with IO then is that to get IO programs to run, you have > to do it inside another IO program. Almost. Add to your mental model a "runIO" that is invoked when your program runs as: "runIO main". Your haskell compiler or interpretter arranges this for you as part of its contract with you. > I hope I'm not making this worse! :-) I dont think so. Tim Newsham http://www.thenewsh.com/~newsham/ From vandijk.roel at gmail.com Fri Feb 6 13:38:11 2009 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Fri Feb 6 13:28:09 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: References: <694519c50902060400ma5b5834nb333157f90942e97@mail.gmail.com> Message-ID: On Fri, Feb 6, 2009 at 5:22 PM, Alberto G. Corona wrote: > then Data.List.head ? Data.Maybe.fromMaybe etc are also unsafe?. Yes, I consider them unsafe. Whenever I see those functions I know that I have to look elsewhere to see if their preconditions hold. I would have preferred that listToMaybe was called head and the existing head called unsafeHead, partialHead or something else of that nature. > unsafe does > not mean "with possible errors". unsafeXXX convert something in the IO monad > into something that is not. So it can potentially contaminate your pure > code. > But Data.List.head applied to a empty list ?will interrupt the computation > abruptly, so your code using head will either run side effect free or not > run at all. I guess what unsafe should mean is a matter of taste. Personally I find correctness more important that pureness. An unsafe function will crash your program if evaluated when its preconditions do not hold. Whether that is because of impurity (segmentation fault?), a partial pattern match or a direct error "bla" is not that important. It might be important when determining why your program crashed, but the result is still the same. The ByteString library has a module called Data.ByteString.Unsafe with plenty of unsafeXXX functions. The comment for unsafeHead for example states: "A variety of head for non-empty ByteStrings. unsafeHead omits the check for the empty case, so there is an obligation on the programmer to provide a proof that the ByteString is non-empty." That perfectly reflects my own philosophy on this issue. From kirk.martinez at gmail.com Fri Feb 6 14:49:01 2009 From: kirk.martinez at gmail.com (Kirk Martinez) Date: Fri Feb 6 14:39:00 2009 Subject: [Haskell-cafe] Are you using Haskell on the job? Message-ID: Hello, fellow Haskell hackers! I am writing a term paper on Haskell in Business, and while I have gathered a lot of good information on the Internet, I would really like direct feedback from software professionals who have used Haskell in a business setting. I would really appreciate a few minutes of your time to provide insights gained from applying Haskell in the real world. Who knows, this could lead to a greater adoption of Haskell in the business community! Rather than a list of Haskell's technical strengths (purity, laziness, composition, etc.), I want to get a sense of the process leading up to the decision to use Haskell for a given project and the insights gained during and after completion. I am particularly interested in questions related to *business value*: - What were the pros and cons you considered when choosing a language? Why FP? Why Haskell? - What aspects of your problem domain were most critical to making that choice? - How has using Haskell given you a competitive advantage? - How is the software development lifecycle positively/negatively affected by using Haskell as opposed to a different language? - How did you convince management to go with a functional approach? - Was the relative scarcity of Haskell programmers a problem? If so, how was it managed? - Would you choose to use Haskell again for a similar project given what you know now? The best responses will not simply list answers, but also provide background and a bit of narrative on the project and insights gained. Feel free to reply to the list, or just to me personally if you prefer. My email is below. Thank you, Kirk Martinez (Kirk dot Martinez at gmail dot com) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/624c71db/attachment.htm From lennart at augustsson.net Fri Feb 6 15:17:19 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Fri Feb 6 15:07:17 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902061603.29609.g9ks157k@acme.softbase.org> References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> Message-ID: It doesn't really matter if TeX is a good or bad idea for writing maths. For our users, they might do a formula if it's TeX, they won't if it's something else. -- Lennart On Fri, Feb 6, 2009 at 4:03 PM, Wolfgang Jeltsch wrote: > Am Freitag, 6. Februar 2009 11:31 schrieb George Pollard: >> I think that the TeX *language* is great for writing mathematics, >> but that we should be wary of blindly incorporating TeX *output* >> into Haddock. >> >> Most of Haddock's documentation is currently HTML-based, and >> if we add TeX mathematics in the usual way (i.e. embedding images) >> it is very 'inaccessible content' (no selection, scaling, and a myriad >> of other small niggles) compared to the rest of the HTML file. >> My thoughts would be to use the TeX engine itself for when generating >> high-quality PDF documentation, and have something else translate TeX >> to (e.g.) MathML for the HTML pages. There are various programs to do this >> (or it could be done in Haskell :D!) > > TeX is not so great for mathematics and especially not for conversion into > MathML (which would be needed for HTML output). The TeX math language > provides rather little semantic information. As input language for the > concrete software named TeX this is mostly okay since the concrete rendering > algorithm of TeX doesn't need certain information (for example, about > implicit bracketing). > > However, even for rendering with TeX, you sometimes have to ressort to ugly > tricks since TeX sometimes misinterprets what you wrote. Knuth gives some > examples in chapter 18 of The TeXbook. For conversion into MathML, a TeX > source generally doesn't have enough information since even presentation > MathML code contains much more structure than ordinary TeX source code does. > > So using TeX as a general language for math is a very bad idea, in my opinion. > The problem is that there is no good language which provides enough > structural information for conversion into MathML and is at the same time > simple to write and read. Maybe, both requirements contradict. > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jgoerzen at complete.org Fri Feb 6 15:27:52 2009 From: jgoerzen at complete.org (John Goerzen) Date: Fri Feb 6 15:17:50 2009 Subject: [Haskell-cafe] Are you using Haskell on the job? In-Reply-To: References: Message-ID: <498C9D48.1090809@complete.org> Kirk Martinez wrote: > Hello, fellow Haskell hackers! I am writing a term paper on Haskell in > Business, and while I have gathered a lot of good information on the I do hope you will publish your results somewhere. > * What were the pros and cons you considered when choosing a > language? Why FP? Why Haskell? Haskell's static type checking plus type inference were a big win. Java is so heavy-handed with its type system (yet not actually achieving real safety; see NullPointerException and ClassCastException) that is is a significant hindrance to productivity. Python is an agile language to write in, but things can sometimes blow up in your face long after you thought they were stable. Type inference is a killer feature in my book. Killer feature #2 is purity. It is just a really... freeing experience. I worry less about my Haskell code than I did about my Python code. > * What aspects of your problem domain were most critical to making > that choice? The need for stability of code in production. > * How has using Haskell given you a competitive advantage? It has been, on more than one occasion, faster to write both an application and a library in Haskell that it would have been to write just the application in some other language. FFI also plays into that, thanks to some dinosaur proprietary software. But in the long run, our Haskell code is *solid*. OK, so there are occasional read-generated exceptions, but knowing to avoid that particular pitfall is easy and not burdensome. Bottom line: it is fast to write, and it works well. > * How is the software development lifecycle positively/negatively > affected by using Haskell as opposed to a different language? Compared to Python, my Haskell code is more likely to work when it manages to compile, and less likely to discover some weird type error after already going into production. Shorter development lifecycle there. Shorter testing cycle, and less hacking once it's in production. Back when we had AIX on-site, the benefit was not as clear. AIX was not well-supported by GHC, and I had to invest a non-trivial amount of time maintaining it there. OTOH, I had to invest a non-trivial amount of time just maintaining gcc and binutils there as well, so pick your poison I guess. Python worked pretty much out of the box on AIX. > * How did you convince management to go with a functional approach? I am management. It never came up :-) > * Was the relative scarcity of Haskell programmers a problem? If > so, how was it managed? Yes and no. I don't hire people because they know $LANGUAGE. I hire people that are adaptable and love to learn new things. Finding time for them to learn Haskell has been an issue, and we haven't done it yet. On the other hand, they already maintain their own GHC development environments, and when I've been at conferences, they've successfully done a small bit of Haskell hacking for urgent problems. I am not concerned about them being able to learn Haskell, or about finding people with that ability. I'm somewhat concerned about us finding the time to permit them to do so though. > * Would you choose to use Haskell again for a similar project given > what you know now? Absolutely. Though I would not use WASH or HSQL again. > The best responses will not simply list answers, but also provide > background and a bit of narrative on the project and insights gained. > Feel free to reply to the list, or just to me personally if you > prefer. I have used Haskell for quite a few integration projects: data from vendor X has to go into a database from an app by vendor Y, and vice-versa. There is a lot of parsing, a lot of formatting, and a lot of database interactions and data validation. It is "messy": sometimes we get data in a format it shouldn't be in, sometimes we get errors, and we have to deal with this. One of my coworkers instinctively reaches for Perl for this, and I instinctively reach for Haskell. They both seem to work pretty well for it -- I think Haskell with Parsec works better than Perl, actually, thanks to its helpful error messages. Haskell was also at the heart of a system that we (a lawn mower manufacturer) pushed out to our dealers, letting them register the warranty on units they've sold and request rebates on a private website. This project requires data validation in several disparate systems and complex business rules governing eligibility and penalties for late submission. This was initially written using WASH, but rewritten to FastCGI plus a custom utility module. It also initially used HSQL, but I wrote HDBC mainly due to bugs and deficiencies in HSQL for this particular project. One database involved is a dinosaur proprietary system that supports ODBC but not unixODBC and is about 7 years out of date. We maintain a private branch of HDBC-ODBC to get it to compile with this. No language binding worked with it out of the box. Haskell was also a small part of our Linux on the Desktop initiative, in which we pushed out Linux as our standard corporate desktop to a large part of the company: about 60 office machines, plus quite a few data collection terminals in our manufacturing areas. One of the issues we faced was dealing with existing essential proprietary software that requires Windows. We set up a Windows terminal server and use rdesktop with SeamlessRDP to connect to it. But the problem arises: if you are using some Windows app that generates a spreadsheet, we want it to open with the OpenOffice on your local Linux box, not something running on the terminal server. I wrote a client/server app that contains a Linux-based server that runs on the PCs and a Windows-base client. We associate certain extensions with the Windows-based client, so if you open, say, a CSV file on Windows, it executes my little app, which connects to the Linux PC, sends the data over the network, and causes OpenOffice to open it locally. Both pieces of this were written in Haskell, and developed mostly on my Linux workstation. I installed GHC in a virtual Windows box, compiled the Windows version there, and it worked well. The cross-platform capability was nice. Haskell has become my "go to" language for anything involving CSV files and databases, a situation which is sadly quite common. I have been known to whip up quick scripts for a few users that import well-formatted CSV files into database tables in certain ways. Since they all have GHC on their (Linux) machines, I can plonk it down with source and #!/usr/bin/runghc in ~/bin, put a .desktop file in ~/Desktop for them, and they can drag a file to it to get it imported. Quick and easy. Hope that helps. -- John From max.rabkin at gmail.com Fri Feb 6 15:30:29 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Fri Feb 6 15:20:27 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> Message-ID: On Fri, Feb 6, 2009 at 12:17 PM, Lennart Augustsson wrote: > It doesn't really matter if TeX is a good or bad idea for writing maths. > For our users, they might do a formula if it's TeX, they won't if it's > something else. Generally, I'd agree, but I just took a look at AsciiMathML, and it's pretty TeX-like. Personally, I'd consider using it, if it meant I could get decent-looking formulae in my HTML Haddocks. > -- Lennart --Max From dons at galois.com Fri Feb 6 15:51:19 2009 From: dons at galois.com (Don Stewart) Date: Fri Feb 6 15:41:49 2009 Subject: [Haskell-cafe] Are you using Haskell on the job? In-Reply-To: References: Message-ID: <20090206205119.GK24129@whirlpool.galois.com> kirk.martinez: > Hello, fellow Haskell hackers! I am writing a term paper on Haskell in > Business, and while I have gathered a lot of good information on the Internet, > I would really like direct feedback from software professionals who have used > Haskell in a business setting. I would really appreciate a few minutes of your > time to provide insights gained from applying Haskell in the real world. Who > knows, this could lead to a greater adoption of Haskell in the business > community! > > > > Rather than a list of Haskell's technical strengths (purity, laziness, > composition, etc.), I want to get a sense of the process leading up to the > decision to use Haskell for a given project and the insights gained during and > after completion. I am particularly interested in questions related to > business value: > > > > ? What were the pros and cons you considered when choosing a language? Why > FP? Why Haskell? > ? What aspects of your problem domain were most critical to making that > choice? > ? How has using Haskell given you a competitive advantage? > ? How is the software development lifecycle positively/negatively affected by > using Haskell as opposed to a different language? > ? How did you convince management to go with a functional approach? > ? Was the relative scarcity of Haskell programmers a problem? If so, how was > it managed? > ? Would you choose to use Haskell again for a similar project given what you > know now? > > > > The best responses will not simply list answers, but also provide background > and a bit of narrative on the project and insights gained. Feel free to reply > to the list, or just to me personally if you prefer. My email is below. > I would also suggest you contact speakers from past CUFP meetings, who've written all sorts of interesting summaries on the use of Haskell (and other FP langs) in industry. http://cufp.galois.com/ -- Don From agocorona at gmail.com Fri Feb 6 16:17:56 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri Feb 6 16:07:54 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: References: <694519c50902060400ma5b5834nb333157f90942e97@mail.gmail.com> Message-ID: Then you are talking about something very different from the subject that Andrew started.. He clearly ask about "unsafeXXX understood as impurity "which defiles our ability to reason logically about haskell programs like we would like to". I also want to discuss here that any signature of type IO a -> a defies also the ability to reason of the compiler evaluation algoritm. For example i sometimes find strange differences between using and not using unsafePerformIO. It seems that, when the result of a IO action is converted in pure, if the variable becomes out of scope, the garbage collection can drop some data that is needed for the next call to the IO function to work properly. this does not happens if the calls are executed inside the IO monad. Alternatively, it could be that the some necessary state is lost. This happens for example with the System.Mem.StableName.makeStableName method and some others that I do not remember now. I would like to know if this is due to some general cause or if it is library specific. 2009/2/6 Roel van Dijk > On Fri, Feb 6, 2009 at 5:22 PM, Alberto G. Corona > wrote: > > then Data.List.head Data.Maybe.fromMaybe etc are also unsafe?. > Yes, I consider them unsafe. Whenever I see those functions I know > that I have to look elsewhere to see if their preconditions hold. I > would have preferred that listToMaybe was called head and the existing > head called unsafeHead, partialHead or something else of that nature. > > > unsafe does > > not mean "with possible errors". unsafeXXX convert something in the IO > monad > > into something that is not. So it can potentially contaminate your pure > > code. > > But Data.List.head applied to a empty list will interrupt the > computation > > abruptly, so your code using head will either run side effect free or not > > run at all. > I guess what unsafe should mean is a matter of taste. Personally I > find correctness more important that pureness. An unsafe function will > crash your program if evaluated when its preconditions do not hold. > Whether that is because of impurity (segmentation fault?), a partial > pattern match or a direct error "bla" is not that important. It might > be important when determining why your program crashed, but the result > is still the same. > > The ByteString library has a module called Data.ByteString.Unsafe with > plenty of unsafeXXX functions. The comment for unsafeHead for example > states: "A variety of head for non-empty ByteStrings. unsafeHead omits > the check for the empty case, so there is an obligation on the > programmer to provide a proof that the ByteString is non-empty." That > perfectly reflects my own philosophy on this issue. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/2964a936/attachment-0001.htm From manlio_perillo at libero.it Fri Feb 6 17:06:28 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Fri Feb 6 16:57:26 2009 Subject: [Haskell-cafe] about integer and float operations In-Reply-To: References: <4989B74B.7090806@libero.it> <2608b8a80902041107s1d022e4fudb2079a005b000f8@mail.gmail.com> <498A040A.6030809@libero.it> <498A10A3.60700@libero.it> <2608b8a80902041531j3e5955a8i50b51681cbb257c1@mail.gmail.com> <498A2E65.4040805@libero.it> Message-ID: <498CB464.1030004@libero.it> Henning Thielemann ha scritto: > > On Thu, 5 Feb 2009, Manlio Perillo wrote: > >> Yitzchak Gale ha scritto: >>> >>> Ah, OK. Thanks. Now we have a well-defined problem. :) >> >> Good :). > > I have used this example to describe how to avoid big integers at all: > http://haskell.org/haskellwiki/Integers_too_big_for_floats > Thanks, I didn't know that Ratio constructor was available via GHC.FLoat. I have done a test using the :% operator, instead of the % operator, but, the program run slower! About 29 seconds, against 20 seconds of the previous version (and 10 seconds of the Python version). I was expecting to obtain an execution time of about 6 seconds... Manlio Perillo From duncan.coutts at worc.ox.ac.uk Fri Feb 6 17:27:05 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 6 17:16:48 2009 Subject: [Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <79d7c4980902060235x5eb42955p196dfe68707daab0@mail.gmail.com> Message-ID: <1233959225.26754.713.camel@localhost> On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote: > 2009/2/6 Alistair Bayley : > >>> [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) > >>> > >>> Test\Fail.hs:11:26: > >>> Can't make a derived instance of `Typeable Fail' > >>> (You need -XDeriveDataTypeable to derive an instance for this class) > >>> In the data type declaration for `Fail' > >> > >> Are you processing the above module but it is called Test.Fail in > >> reality? Have you stripped out a deriving statement from the example > >> above? I'm very confused by this message :) > > > > > > Sorry, my mistake. I pasted the error message from a different > > problem. This is the error I get from haddock: > > > > C:\bayleya\eclipse\workspace\takusen\src>haddock -h --odir=doc Test/Haddock.lhs > > Cannot find documentation for: $named_block > > Okay, then I understand. > > My guess is (without looking at ghc code) that ghc just throws the > literate comments away before lexing the file. This means that the > Haddock comments won't be recognized. > > As you say, there is also an unlitter in Cabal. I don't remember if it > is invoked when using Haddock 2, but if it is, it would solve this > problem. Yes, against my better judgement the code in Cabal for haddock-2.x does not run cpp or unliting like it does for haddock-0.x. Instead it assumes that haddock-2.x will do all the cpp and unliting itself. Obviously this mean the special unliting mode that Cabal provides is not usable with haddock-2.x. The solution is to do the pre-processing the same for haddock-0.x and 2.x. Generally the haddock code in Cabal is a horrible inconsistent mess. I believe Andrea Vezzosi has been looking at rewriting it, which is good news. Duncan From duncan.coutts at worc.ox.ac.uk Fri Feb 6 17:55:35 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 6 17:45:18 2009 Subject: [Haskell-cafe] Error in building profiling In-Reply-To: <1233916123.18688.186.camel@quindinho.domain.invalid> References: <1233873511.18688.143.camel@quindinho.domain.invalid> <1233916123.18688.186.camel@quindinho.domain.invalid> Message-ID: <1233960935.26754.719.camel@localhost> On Fri, 2009-02-06 at 08:28 -0200, Marco T?lio Gontijo e Silva wrote: > > $ ./setup configure --enable-library-profiling --disable-library-vanilla > > /usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file > > or directory > > > > I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1. > > I tried the same with ghc6 6.8.2dfsg1-1 and it worked. Turns out I broke it in Cabal-1.4. It used to be that --disable-library-vanilla implied --disable-library-for-ghci where as they're now independent. Try the Cabal head branch now. Let me know if that fixes it for you. If it does I'll push it to the Cabal-1.6 branch. Duncan From duncan.coutts at worc.ox.ac.uk Fri Feb 6 17:57:23 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 6 17:47:03 2009 Subject: [Haskell-cafe] Re: 1,000 packages, so let's build a few! In-Reply-To: <49889A3A.2000200@btinternet.com> References: <49848480.70106@btinternet.com> <20090131203528.GC24687@scytale.galois.com> <20090201005031.GK24687@scytale.galois.com> <1233500488.26754.352.camel@localhost> <1233568155.26754.489.camel@localhost> <404396ef0902020207j2553e65dt619dbfd85c0404ae@mail.gmail.com> <20090202220344.GA13113@whirlpool.galois.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCB86@ELON17P32001A.csfb.cs-group.com> <20090202225218.GE13113@whirlpool.galois.com> <49889A3A.2000200@btinternet.com> Message-ID: <1233961043.26754.721.camel@localhost> On Tue, 2009-02-03 at 19:25 +0000, Andrew Coppin wrote: > Don Stewart wrote: > > The platform is a set of blessed libraries and tools. The distros will > > still need to package that. > > > > To do that for Windows, we're still going to need a windows packaging > > team, along side Debian, Arch, Gentoo, Mac etc. > > > > Right, so, let me make sure I understand this... > > 1. We sit down and pick a set of libraries that cover a useful range of > subject areas, that are mature and stable, and that work well with each > other. This is the "Haskell Platform". > > 2. For each OS, a team decides how best to deploy this set of libraries > on that specific OS. > > Is that the plan? More or less, yes. In practise we expect there to be quite a bit of overlap and communication between the OS teams. Duncan From wren at freegeek.org Fri Feb 6 19:09:41 2009 From: wren at freegeek.org (wren ng thornton) Date: Fri Feb 6 18:59:38 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <3e1162e60902051120p11c6d654me24b21f547a32a36@mail.gmail.com> <3e1162e60902051221p4ec89a9aqcf8723107d9fff6e@mail.gmail.com> <1233865621.19682.43.camel@jcchost> <3e1162e60902051301g717f36eds4bfc9dbbe75622fd@mail.gmail.com> Message-ID: <498CD145.8010600@freegeek.org> Tim Newsham wrote: > > The only difference with IO then is that to get IO programs to run, > > you have > > to do it inside another IO program. > > Almost. Add to your mental model a "runIO" that is invoked when your > program runs as: "runIO main". Your haskell compiler or interpretter > arranges this for you as part of its contract with you. Also worth mentioning, the "to get IO to run you must do it from within IO" is not actually "running" ala unsafePerformIO, runState, runST, etc. Instead this transformation is called join :: M(M a) -> M a, which is different from run* :: M a -> ? For join, the monad structure says that more than one M layer can be collapsed into just one layer, but this is separate from being able to get rid of that last layer ("no escape"). For IO the join function can be thought of as inlining the other program or machine into the current one--- which is distinct from running that program/machine and using its results in the current one (that would be staged programming ala TH or MetaOCaml). The join and bind operators can be defined in terms of one another. Category theorists tend to prefer join, but Haskell programmers tend to prefer bind. Either one can be clearer depending on what is being explained, but it's helpful to think about them both. mx >>= f = join (fmap f mx) join mmx = mmx >>= id -- Live well, ~wren From allbery at ece.cmu.edu Fri Feb 6 19:46:07 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 6 19:36:19 2009 Subject: [Haskell-cafe] Fastest regex package? In-Reply-To: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> References: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> Message-ID: <3282F7B3-CF78-4C92-914A-2657535935E6@ece.cmu.edu> On 2009 Feb 5, at 10:26, Eugene Kirpichov wrote: > My benchmark (parsing a huge logfile with a regex like "GET > /foo.xml.*fooid=([0-9]++).*barid=([0-9]++)") shows that plain PCRE is > the fastest one (I tried PCRE, PCRE-light and TDFA; DFA can't do > capturing groups at all, TDFA was abysmally slow (about 20x slower > than PCRE), and it doesn't support ++), but maybe have I missed any > blazing-fast package? I think dons (copied) will want to hear about this; pcre-light is supposed to be a fast lightweight wrapper for the PCRE library, and if it's slower than PCRE then something is likely to be wrong somewhere. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090206/1cc08ff1/PGP.bin From dons at galois.com Fri Feb 6 20:40:03 2009 From: dons at galois.com (Don Stewart) Date: Fri Feb 6 20:30:37 2009 Subject: [Haskell-cafe] Fastest regex package? In-Reply-To: <3282F7B3-CF78-4C92-914A-2657535935E6@ece.cmu.edu> References: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> <3282F7B3-CF78-4C92-914A-2657535935E6@ece.cmu.edu> Message-ID: <20090207014003.GA24129@whirlpool.galois.com> allbery: > On 2009 Feb 5, at 10:26, Eugene Kirpichov wrote: >> My benchmark (parsing a huge logfile with a regex like "GET >> /foo.xml.*fooid=([0-9]++).*barid=([0-9]++)") shows that plain PCRE is >> the fastest one (I tried PCRE, PCRE-light and TDFA; DFA can't do >> capturing groups at all, TDFA was abysmally slow (about 20x slower >> than PCRE), and it doesn't support ++), but maybe have I missed any >> blazing-fast package? > > > I think dons (copied) will want to hear about this; pcre-light is > supposed to be a fast lightweight wrapper for the PCRE library, and if > it's slower than PCRE then something is likely to be wrong somewhere. Shouldn't be slower (assuming you're using bytestrings). -- Don From barsoap at web.de Fri Feb 6 21:12:36 2009 From: barsoap at web.de (Achim Schneider) Date: Fri Feb 6 21:04:54 2009 Subject: [Haskell-cafe] Re: Haskell tutorial for pseudo users? References: <49870495.3010305@chalmers.se> <7b501d5c0902020744r2c687c4eo5c9d7097c13f5f30@mail.gmail.com> <49875DB8.8010602@btinternet.com> <1233882201.19682.88.camel@jcchost> <20090206083030.56c3e6d4@solaris> <1233906256.6199.7.camel@jonathans-macbook> <7b501d5c0902060556x2e96025avb82b6952cf5fc0f2@mail.gmail.com> <1233940844.25917.8.camel@jcchost> Message-ID: <20090207031236.7ff59de0@solaris> Jonathan Cast wrote: > Konsole > ctrl+shift+f, incremental, all matches highlight, case (in)sensitive, regexen. Konsole 2.1 (KDE 4.1.2), that is. I'd use its tab support, but I have xmonad. In fact, it comes with a nice editor: I just have to type vi. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From allbery at ece.cmu.edu Sat Feb 7 00:18:19 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Sat Feb 7 00:08:29 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs In-Reply-To: References: Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090207/c1abe41b/PGP.bin From ekirpichov at gmail.com Sat Feb 7 03:44:38 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Sat Feb 7 03:34:34 2009 Subject: [Haskell-cafe] Re: Fastest regex package? In-Reply-To: <498B3700.2090706@list.mightyreason.com> References: <5e0214850902050726q73658049g41b6a3953f66722@mail.gmail.com> <5e0214850902050754i214a76f4j419c92f4ee518c1@mail.gmail.com> <498B3700.2090706@list.mightyreason.com> Message-ID: <5e0214850902070044h3d9dae8bu4245190f52c6ca9f@mail.gmail.com> 2009/2/5 ChrisK : > Eugene Kirpichov wrote: >>> >>> All in all, my question remains: what is the fastest way to do this >>> kind of parsing on a lazy bytestring? >>> > > Your example regular expression works the same in both Posix and Perl-ish > semantics. Do you know the difference? Posix libraries look for the > longest match of all possible matches. Perl-ish is left-bias and looks at > the left branch first and only looks at the right branch when the left fails > and it has to backtrack. Thanks, I didn't know that about posix. > > So the "++" operator is a hack to try and control the backtracking of Perl > regular expressions. Such a things has no meaning in Posix where the > implementation details are totally different. > That's precisely what I put it in for :) > You might try this variant of the example pattern: > /foo.xml.*fooid=([0-9]+)[^0-9].*barid=([0-9]+) > > The [^0-9] can be used when you know that there is at least one junk > character before the barid, which I suspect will always occur in a URL. > > I expect regex-posix to be slower than regex-pcre. I have not used the new > pcre-light. I wrote regex-tdfa ? it is pure haskell and not a C library > wrapper. There are patterns where regex-pcre will backtrack and take > exponentially more time than regex-tdfa's automaton (which is not yet ideal > and may get faster). You're right :) > > So what is the lazy bytestring with its multiple buffers doing for you when > using PCRE, PCRE-light, or regex-posix? Absolutely nothing. To run against > these C libraries the target text is converted to a single buffer, i.e. a > CStringLen in Haskell. Thus it is morally converted into a strict > bytestring. This may involve copying the logfile into a NEW strict > bytestring EVERY TIME you run a match. Please Please Please convert to a > strict bytestring and then run regex-pcre or pcre-light (or any of the > others). > I'm running the regex on lines of the logfile, not on the whole logfile itself; and I'm running it only once per line, so that doesn't matter much. Actually, that's what I did in the initial version of the program (strictify lines before matching), but then I experimentally got rid of the extra conversion function and performance didn't change at all (anyways, someone was converting that string exactly once, be it me or the package), so I left it that way. > regex-tdfa does not convert it into a strict bytestring, but is otherwise > much slower than pcre for your simple pattern. > > As for regex-pcre's interface....you should use the API in regex-base to get > a pure interface. The RegexLike functions are the pure interface for this, > and the RegexContext class offers a slew of instances with useful variants. Thanks, I didn't know that. > But if you have been getting to the "low level IO API" in regex-pcre then > you probably do not need or want the RegexContext transformations. Is that because of their performance? > > And BoyerMoore (which I think I helped optimize): this may be faster because > it does not copy your whole Lazy bytestring into a Strict ByteString for > each search. But you may wish to test it with a Strict ByteString as input > anyway. > > -- > Chris > From mithrandi at mithrandi.net Sat Feb 7 04:13:55 2009 From: mithrandi at mithrandi.net (Tristan Seligmann) Date: Sat Feb 7 04:03:54 2009 Subject: [Haskell-cafe] Switching from Mercurial to Darcs In-Reply-To: <498B698D.6070005@henning-thielemann.de> References: <498B698D.6070005@henning-thielemann.de> Message-ID: <20090207091355.GE29295@mithrandi.net> * Henning Thielemann [2009-02-05 23:34:53 +0100]: > Peter Verswyvelen schrieb: > > > 3) hg addrem > > this adds new files and removes deleted files from local repos. > > forgetting to add files is a common problem, and is really tricky since > > no record is made of these files, so if after a couple of versions if a > > developer finds out a file was missing, the history is useless since you > > can't reconstruct the old content of that local file anymore, and often > > it's impossible to give the local file to the other developers since it > > might be changed. I actually would like to have an option that > > automatically adds/deletes files on each commit, as it is easier to > > delete a file after it is checked in, than it is to reconstruct an old > > version from a local file you forgot to add. > > I'm also not glad with darcs behaviour about non-added files. You can try > > darcs whatsnew --look-for-adds You can also pass --look-for-adds (-l) to darcs record; if you want this to be the default behaviour, you could add "record look-for-adds" to ~/.darcs/defaults or similar. > > 4) hg commit -m "message" > > this commits my changes locally. I always do this before pulling since > > then I'm sure my changes are saved in the case a merge goes wrong. > > In old darcs its precisely the other way round. Since it is so slow on > merging ready patches, you better merge uncrecorded changes. This sounds like bad advice; merging changes with locally unrecorded changes shouldn't be any less expensive than merging them with a just-recorded patch (the algorithm is exactly the same, after all, unless there's something I've missed), and you have no way to roll things back if you don't record a patch before merging. Of course, you may want to unrecord your temporary patch after you've pulled, to keep your patch history neater. -- mithrandi, i Ainil en-Balandor, a faer Ambar -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090207/43073d8e/attachment.bin From tom.davie at gmail.com Sat Feb 7 05:41:22 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Sat Feb 7 05:31:50 2009 Subject: [Haskell-cafe] Re: Switching from Mercurial to Darcs In-Reply-To: <498BFF0A.8030808@hypersonic.it> References: <498B698D.6070005@henning-thielemann.de> <498BFF0A.8030808@hypersonic.it> Message-ID: On 6 Feb 2009, at 10:12, Paolo Losi wrote: > Henning Thielemann wrote: > >>> 4) hg commit -m "message" >>> this commits my changes locally. I always do this before pulling >>> since >>> then I'm sure my changes are saved in the case a merge goes wrong. >> In old darcs its precisely the other way round. Since it is so slow >> on >> merging ready patches, you better merge uncrecorded changes. > > IMO pulling & merging before commit is a good practise also for hg: > it avoids a (very often useless) merge commit in the history. I don't understand this view. Isn't the point of a commit that you flag working points. In each branch, before you merge (hopefully) you have a working repository, so flag it as such, and commit. When you merge, you may or may not have a working repository, fix it until it is, and merge. I would never do a merge without the two branches I was merging having a commit just before the merge. Bob From david.waern at gmail.com Sat Feb 7 05:54:12 2009 From: david.waern at gmail.com (David Waern) Date: Sat Feb 7 05:44:08 2009 Subject: [Haskell-cafe] 1,000 packages, so let's build a few! In-Reply-To: <49848480.70106@btinternet.com> References: <49848480.70106@btinternet.com> Message-ID: 2009/1/31 Andrew Coppin : > In celebration of Hackage reachin over 1,000 unique packages, I decided that > I would re-visit the problem of attempting to build them on Windows. > > I began by removing all existing Haskellness from my PC. I now have a > vanilla Windows XP (32-bit) system with Service Pack 3. So, let's see what > we can do here... > > - Install GHC 6.10.1. As you'd expect, no issues here. > > - Now, let's install stream-fusion. First let me ch... woah! What the hell? > > OK, it seems that Google is temporarily "broken". (All websites show up as > "this site may damange your computer".) Obviously this has nothing to do > with Haskell, but it makes navigating Hackage moderately more tedious. Oh > well, anyway, where was I? > > Ah yes, I already have the tarball for stream-fusion-0.1.1, but I see that > the latest release is 0.1.2.1. (Unfortunately, there doesn't appear to be > any way to determine what the difference is between the two versions...) > > - Right, I've got the tarball for stream-fusion. Now let's see if it will > install... > > J:\Haskell\unpack> runhaskell Setup configure > J:\Haskell\unpack> runhaskell Setup build > J:\Haskell\unpack> runhaskell Setup install > J:\Haskell\unpack> ghc-pkg list > ...stream-fusion-0.1.2.1... > > OK, nothing much wrong with that then. :-D > > - Hmm, doesn't GHC 6.10.1 now come with Haddock included? I wonder if > there's a way to ask Cabal to build the docs for me... > > [Grr! Google is still busted.] > > Ah, yes there is. OK, let's try this: > > J:\Haskell\unpack> runhaskell Setup haddock > ... > Data\Stream.hs:292:33: parse error on input `!' > haddock: Failed to check module: Data.Stream > > Uh... OK. So I guess I *won't* build the docs for that one then. :-/ Oh > well, maybe it's a one-off failure? Let's try some more packages... The problem there is that stream-fusion is trying to put documentation on individual data constructor arguments which is not supported by Haddock. David From g9ks157k at acme.softbase.org Sat Feb 7 08:18:16 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Sat Feb 7 08:08:18 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: References: <200902061603.29609.g9ks157k@acme.softbase.org> Message-ID: <200902071418.16832.g9ks157k@acme.softbase.org> Am Freitag, 6. Februar 2009 21:17 schrieben Sie: > It doesn't really matter if TeX is a good or bad idea for writing maths. > For our users, they might do a formula if it's TeX, they won't if it's > something else. Oh, what ignorant users! ;-) Well, if this discussion is about changing the real Haddock (not about making a fork) than the arguments about TeX not being good as a general math language should count, I?d say. Best wishes, Wolfgang From alexey.skladnoy at gmail.com Sat Feb 7 07:46:25 2009 From: alexey.skladnoy at gmail.com (Khudyakov Alexey) Date: Sat Feb 7 09:23:30 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <5540a5470902061024hce004b6l48a99d3aa4e587e4@mail.gmail.com> References: <200902061603.29609.g9ks157k@acme.softbase.org> <5540a5470902061024hce004b6l48a99d3aa4e587e4@mail.gmail.com> Message-ID: <200902071546.25957.alexey.skladnoy@gmail.com> On Friday 06 February 2009 21:24:35 Andy Smith wrote: > 2009/2/6 Wolfgang Jeltsch : > > So using TeX as a general language for math is a very bad idea, in my > > opinion. The problem is that there is no good language which provides > > enough structural information for conversion into MathML and is at the > > same time simple to write and read. Maybe, both requirements contradict. > > ASCIIMathML [1] is designed to do this. It doesn't cover everything in > Presentation MathML, and makes no attempt to handle Content MathML, > but you can do quite a lot with it. The notation has a formally > defined grammar and rules for conversion to MathML [2]. > > [1] http://www1.chapman.edu/~jipsen/asciimath.html > [2] http://www1.chapman.edu/~jipsen/mathml/asciimathsyntax.html > TeX aim is presentation quality not structural information. And it's rather good at it. If one want really good looking formulae TeX is the answer. ASCIIMathML is nice but its produce not so good looking formulae. I've tried it some time ago and found it clearly inferior to TeX. It gives too little control over presentation. I wasn't able even to place integration indices exactly over and under integral sign. P.S. Maybe I just to used to TeX. -- Khudyakov Alexey From alexey.skladnoy at gmail.com Sat Feb 7 07:46:00 2009 From: alexey.skladnoy at gmail.com (Khudyakov Alexey) Date: Sat Feb 7 09:23:40 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <1233916294.9411.15.camel@porges-laptop> References: <1233916294.9411.15.camel@porges-laptop> Message-ID: <200902071546.00718.alexey.skladnoy@gmail.com> On Friday 06 February 2009 13:31:34 George Pollard wrote: > My comment isn't related to the wider implications of third-party > hooks into Haddock, but just for the (La?)TeX stuff itself. > I think that the TeX *language* is great for writing mathematics, > but that we should be wary of blindly incorporating TeX *output* > into Haddock. > > Most of Haddock's documentation is currently HTML-based, and > if we add TeX mathematics in the usual way (i.e. embedding images) > it is very ?inaccessible content? (no selection, scaling, and a myriad > of other small niggles) compared to the rest of the HTML file. > My thoughts would be to use the TeX engine itself for when generating > high-quality PDF documentation, and have something else translate TeX > to (e.g.) MathML for the HTML pages. There are various programs to do this > (or it could be done in Haskell :D!) > > Thanks, > - George I think MathML is much less accessible than images. Yes, there are problems with them but any browser is able to display them save for text based ones. MathML on contrary doesn't have much support. According to wikipedia only recent versions of gecko based browsers and opera >=9.5 can do this. For IE special plugin is required (MathPlayer). I believe image are safest way at least for now. -- Khudyakov Alexey From alexey.skladnoy at gmail.com Sat Feb 7 08:01:57 2009 From: alexey.skladnoy at gmail.com (Khudyakov Alexey) Date: Sat Feb 7 09:23:43 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <49887404.4070504@gmail.com> References: <49887404.4070504@gmail.com> Message-ID: <200902071601.57671.alexey.skladnoy@gmail.com> On Tuesday 03 February 2009 19:42:44 Simon Marlow wrote: > I've been working on adding proper Unicode support to Handle I/O in GHC, > and I finally have something that's ready for testing. I've put a patchset > here: > > http://www.haskell.org/~simonmar/base-unicode.tar.gz > > ... skipped ... > > Comments/discussion please! > How do you plan to handle filenames? Currently FilePath is simply a string. Would it be decoded/encoded automatically? If so there is a nasty catch. Not all valid filenames have representation as strings. On linux (and I suspect all unices) file name is sequence of bytes. For example let consider file with name {0xff} on computer with UTF8 locale. It's valid and everything, but its name cannot be converted to string. 0xff byte cannot appear in UTF8 strings. -- Khudyakov Alexey From bulat.ziganshin at gmail.com Sat Feb 7 09:58:40 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Feb 7 09:48:51 2009 Subject: [Haskell-cafe] Ready for testing: Unicode support for Handle I/O In-Reply-To: <200902071601.57671.alexey.skladnoy@gmail.com> References: <49887404.4070504@gmail.com> <200902071601.57671.alexey.skladnoy@gmail.com> Message-ID: <1741226060.20090207175840@gmail.com> Hello Khudyakov, Saturday, February 7, 2009, 4:01:57 PM, you wrote: > How do you plan to handle filenames? Currently FilePath is simply a string. i think that this patch does nothing to unicode filenames support -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From noel.kalman at googlemail.com Sat Feb 7 11:56:32 2009 From: noel.kalman at googlemail.com (Kalman Noel) Date: Sat Feb 7 11:46:40 2009 Subject: [Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe In-Reply-To: References: Message-ID: <498DBD40.7040306@googlemail.com> As I didn't catch the whole thread, I hope I'm not just repeating everyone else: Roel van Dijk wrote: > I guess what unsafe should mean is a matter of taste. Personally I > find correctness more important that pureness. An unsafe function will > crash your program if evaluated when its preconditions do not hold. > Whether that is because of impurity (segmentation fault?), a partial > pattern match or a direct error "bla" is not that important. It might > be important when determining why your program crashed, but the result > is still the same. Maybe for the purposes of naming functions it's sufficient to argument that a crash is a crash whatsoever, but as for terminology in general, I think it's good to distinguish (1) partial functions from (2) functions that break purity, may lead to segmentation faults etc. I suppose (2) is the ?traditional? meaning of unsafe. The motivation for this distinction is that you can still reason to some extent about (1) if you consider _|_, and that there are many functions that, although useful and correct, aren't guaranteed to terminate on infinite input, thus are partial. On the other hand, functions from (2) should always be called unsafeFoo, and/or wrapped by safe functions. Kalman From dev at mobileink.com Sat Feb 7 12:11:29 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Sat Feb 7 12:01:25 2009 Subject: [Haskell-cafe] Moggi :: CT -> Hask Message-ID: <75cc17ac0902070911m5075d53bs952b615f0c1353cf@mail.gmail.com> Hi, I had a monadic revelation at about 3 am. The answer to the question "what is an IO value, really?" is "who cares?" I just posted a blog entry discussing how CT found it's way from Moggi into Haskell at http://syntax.wikidot.com/blog (hence the title; Moggi as functor). It addresses the question of what such things are and why Moggi's insight is so brilliant. Feedback welcome, but please remember this is coming from a non-mathematician who likes to write. If you find anything there that outrages your inner Russell, please correct me, but be gentle. Thanks, gregg From dev at mobileink.com Sat Feb 7 12:18:12 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Sat Feb 7 12:08:06 2009 Subject: [Haskell-cafe] Re: Moggi :: CT -> Hask In-Reply-To: <75cc17ac0902070911m5075d53bs952b615f0c1353cf@mail.gmail.com> References: <75cc17ac0902070911m5075d53bs952b615f0c1353cf@mail.gmail.com> Message-ID: <75cc17ac0902070918n16c805fi8f0eaaf36c8e4b84@mail.gmail.com> Correction: the correct response is: "Nothing." On Sat, Feb 7, 2009 at 11:11 AM, Gregg Reynolds wrote: > Hi, > > I had a monadic revelation at about 3 am. The answer to the question > "what is an IO value, really?" is "who cares?" I just posted a blog > entry discussing how CT found it's way from Moggi into Haskell at > http://syntax.wikidot.com/blog (hence the title; Moggi as functor). > It addresses the question of what such things are and why Moggi's > insight is so brilliant. Feedback welcome, but please remember this > is coming from a non-mathematician who likes to write. If you find > anything there that outrages your inner Russell, please correct me, > but be gentle. > > Thanks, > > gregg > From paul at cogito.org.uk Sat Feb 7 12:18:22 2009 From: paul at cogito.org.uk (Paul Johnson) Date: Sat Feb 7 12:08:21 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <494EA1EE.1010606@cogito.org.uk> References: <494EA1EE.1010606@cogito.org.uk> Message-ID: <498DC25E.8070808@cogito.org.uk> Paul Johnson wrote: > A call has gone out > > for a new logo for Haskell. Candidates (including a couple > > of mine > ) are > accumulating here > . > There has also been a long thread on the Haskell Cafe mailing list. > So what's happening about this? Paul. From dons at galois.com Sat Feb 7 12:20:23 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 12:10:52 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <498DC25E.8070808@cogito.org.uk> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> Message-ID: <20090207172023.GD27081@whirlpool.galois.com> paul: > Paul Johnson wrote: >> A call has gone out >> >> for a new logo for Haskell. Candidates (including a couple >> >> of mine >> ) are >> accumulating here >> . >> There has also been a long thread on the Haskell Cafe mailing list. >> > So what's happening about this? We need a voting site set up. There was some progress prior to the end of the year. Updates welcome! -- Don From dan.doel at gmail.com Sat Feb 7 13:00:08 2009 From: dan.doel at gmail.com (Dan Doel) Date: Sat Feb 7 12:50:06 2009 Subject: [Haskell-cafe] Moggi :: CT -> Hask In-Reply-To: <75cc17ac0902070911m5075d53bs952b615f0c1353cf@mail.gmail.com> References: <75cc17ac0902070911m5075d53bs952b615f0c1353cf@mail.gmail.com> Message-ID: <200902071300.08944.dan.doel@gmail.com> On Saturday 07 February 2009 12:11:29 pm Gregg Reynolds wrote: > I had a monadic revelation at about 3 am. The answer to the question > "what is an IO value, really?" is "who cares?" I just posted a blog > entry discussing how CT found it's way from Moggi into Haskell at > http://syntax.wikidot.com/blog (hence the title; Moggi as functor). > It addresses the question of what such things are and why Moggi's > insight is so brilliant. Feedback welcome, but please remember this > is coming from a non-mathematician who likes to write. If you find > anything there that outrages your inner Russell, please correct me, > but be gentle. As far as I know, Moggi didn't really have anything directly to do with Haskell. He pioneered the idea of monads being useful in denotational semantics. But it was Wadler that recognized that they'd be useful for actually writing functional programs (see his "The Essence of Functional Programming"). So one might say that it was his doing that brought monads to Haskell proper. -- Dan From wagner.andrew at gmail.com Sat Feb 7 13:08:52 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Sat Feb 7 12:58:48 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207172023.GD27081@whirlpool.galois.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> Message-ID: > We need a voting site set up. There was some progress prior to the end > of the year. Updates welcome! > > -- Don > > Can't we just use the haskell proposal reddit for this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090207/c4e7a857/attachment.htm From dons at galois.com Sat Feb 7 13:12:43 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 13:03:15 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> Message-ID: <20090207181243.GH27081@whirlpool.galois.com> wagner.andrew: > > We need a voting site set up. There was some progress prior to the end > of the year. Updates welcome! > > -- Don > > Can't we just use the haskell proposal reddit for this? Hmm... not ideal. Would make a backup should all else fail. From wagner.andrew at gmail.com Sat Feb 7 13:31:53 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Sat Feb 7 13:21:47 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207181243.GH27081@whirlpool.galois.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <20090207181243.GH27081@whirlpool.galois.com> Message-ID: Um, ok. Glad we could "discuss" it On Sat, Feb 7, 2009 at 1:12 PM, Don Stewart wrote: > wagner.andrew: > > > > We need a voting site set up. There was some progress prior to the > end > > of the year. Updates welcome! > > > > -- Don > > > > Can't we just use the haskell proposal reddit for this? > > Hmm... not ideal. Would make a backup should all else fail. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090207/b1265a83/attachment.htm From dons at galois.com Sat Feb 7 13:34:29 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 13:25:01 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <20090207181243.GH27081@whirlpool.galois.com> Message-ID: <20090207183429.GJ27081@whirlpool.galois.com> Oh, we had a long discussion about the need for condorcet voting, not a system like the reddit which is prone to abuse. Also, it would be good to have the images inline. wagner.andrew: > Um, ok. Glad we could "discuss" it > > On Sat, Feb 7, 2009 at 1:12 PM, Don Stewart wrote: > > wagner.andrew: > > > > We need a voting site set up. There was some progress prior to the > end > > of the year. Updates welcome! > > > > -- Don > > > > Can't we just use the haskell proposal reddit for this? > > Hmm... not ideal. Would make a backup should all else fail. > > > > From bulat.ziganshin at gmail.com Sat Feb 7 13:48:06 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Feb 7 13:39:18 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207172023.GD27081@whirlpool.galois.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> Message-ID: <1988130373.20090207214806@gmail.com> Hello Don, Saturday, February 7, 2009, 8:20:23 PM, you wrote: > We need a voting site set up. There was some progress prior to the end > of the year. Updates welcome! i think that there are a lot of free voting/survey services available. the last one i went through was LimeSurvey available for any SF project and on separate site too http://apps.sourceforge.net/trac/sitedocs/wiki/Hosted%20Apps https://www.limeservice.com/ -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From byorgey at seas.upenn.edu Sat Feb 7 14:11:49 2009 From: byorgey at seas.upenn.edu (Brent Yorgey) Date: Sat Feb 7 14:01:44 2009 Subject: [Haskell-cafe] Haskell Weekly News: Issue 104 - February 7, 2009 Message-ID: <20090207191149.GA25487@seas.upenn.edu> --------------------------------------------------------------------------- Haskell Weekly News http://sequence.complete.org/hwn/20090207 Issue 104 - February 07, 2009 --------------------------------------------------------------------------- Welcome to issue 104 of HWN, a newsletter covering developments in the [1]Haskell community. Community News Andre Pang (ozone) will be soon [2]moving to San Fransisco to begin work with [3]Pixar! Announcements Mutually recursive modules. Henning Thielemann [4]announced a [5]small writeup explaining how mutually recursive modules are currently supported, and how they can be avoided. Please add information about other compilers and more ideas on breaking cycles. UrlDisp, a friendly URL dispatching library. Artyom Shalkhakov [6]announced the first release of [7]UrlDisp, a small library for URL dispatching (aka routing). Right now it works with CGI, and should be compatible with FastCGI as well (not tested); Happstack compatibility is planned. [8]Documentation and usage examples are available. Purely functional LU decomposition. Rafael Gustavo da Cunha Pereira Pinto [9]released some code to perform purely functional LU decomposition. Ready for testing: Unicode support for Handle I/O. Simon Marlow [10]announced that proper Unicode support in Handle I/O is ready for testing in GHC. Just download the [11]set of patches, compile GHC with them, and test away! Comments and discussion welcome. HaskellWiki Accounts. Ashley Yakeley can [12]create a HaskellWiki account for anyone who wants one (account creation has been disabled as a spam-fighting measure). multiplicity 0.1.0 released. Dino Morelli [13]announced the release of [14]multiplicity 0.1.0, a configuration file driven wrapper around [15]duplicity. It allows you to easily define backup sets as config files and avoid long, repetitive command lines. Happstack 0.1 Released!. Matthew Elder [16]announced the [17]0.1 release of [18]Happstack, the successor for the HAppS project. #haskell-in-depth IRC channel. Philippa Cowderoy [19]announced the creation of a new IRC channel, #haskell-in-depth. The new channel is open to everyone, just like #haskell, but is intended for more in-depth conversations, to allow the #haskell channel to be a more newbie-friendly place. regex-posix-unittest-1.0 AND regex-posix-0.94.1 AND regex-tdfa-0.97.1. ChrisK [20]announced an update to the [21]regex-posix package which provides better semantics for multiple matches; an update to the [22]regex-tdfa package, which provides the same new multiple match semantics and fixes a bug; and finally, a new package, [23]regex-posix-unittest, along with an [24]accompanying wiki page; it runs a suite of unit tests which regex-tdfa passes, but reveals bugs in the standard glibc, OS X, FreeBSD, and NetBSD implementations! Jane Street Summer Project 2009. Yaron Minsky [25]announced the [26]Jane Street Summer Project for 2009, the goal of which is to make functional programming languages into better practical tools for programming in the real world. Students will be funded over the summer to work on open-source projects which aim at improving the practical utility of their favorite functional language. gitit 0.5.1. John MacFarlane [27]announced the release of [28]gitit 0.5.1, a wiki program that uses git or darcs as a filestore and HAppS as a server. Changes include major code reorganization, bug fixes, new debugging features, and more. regex-xmlschema. Uwe Schmidt [29]announced the [30]release of [31]regex-xmlschema, (yet another) package for processing text with regular expressions, containing a complete implementation of the W3C XML Schema specification language for regular expressions. diagrams 0.2. Brent Yorgey [32]announced version 0.2 of the [33]diagrams package, an embedded domain-specific language for creating simple graphics in a compositional style. New features include support for arbitrary paths, text, multiple output formats, and support for the [34]colour library. Discussion Haddock Markup. David Waern began a [35]discussion on Haddock markup syntax: should it support (La)TeX for embedded mathematics? Should it support other stuff? Elegant & powerful replacement for CSS. Conal Elliott began a [36]discussion on an elegant replacement for CSS that is consistent, composable, orthogonal, functional, and based on an elegantly compelling semantic model---what might such a thing look like? type metaphysics. Gregg Reynolds began a long and interesting [37]discussion on the type system, denotational semantics, and related matters. Jobs Postdoc Positions at the CLIP group, Spain. CFP [38]announced the availability of [39]postdoctoral research positions within the [40]CLIP (Computational Logic, Implementation and Parallelism) group in Madrid, Spain. The application deadlines are February 13th and 18th; see the original email for more details. Multiple funded Ph.D. positions available. Martin Erwig [41]announced the availability of multiple funded Ph.D. positions in the [42]school of EECS at Oregon State University, in the areas of programming languages (focusing on DSLs and language design), software engineering, and HCI. If you are interested, email Martin with a resume and contact information by February 15. Blog noise [43]Haskell news from the [44]blogosphere. * Erik de Castro Lopo: [45]libsndfile 1.0.18.. * >>> Gregg Reynolds: [46]Moggi :: CT -> Hask. An interesting perspective on Haskell and category theory. * Osfameron: [47]Functional Pe(a)rls v2 (now with Monads!) at the London Perl Workshop 2008. * ezekiel smithburg: [48]google code project, google group, and darcs repository for WikimediaParser. * ezekiel smithburg: [49]releasing WikimediaParser 0.1. * Andre Pang (ozone): [50]Change. * Lennart Augustsson: [51]Is Haskell fast?. * Lennart Augustsson: [52]Regression. A library for writing embedded BASIC programs in Haskell? What is the world coming to? * Galois, Inc: [53]Equivalence and Safety Checking in Cryptol. * GHC / OpenSPARC Project: [54]Just Testing. * Jeff Heard: [55]Hieroglyph: Interactively graph a spreadsheet in 99 lines of code.. * Jeff Heard: [56]Snippet: sorting the elements of a map. * LHC Team: [57]Grin a little.. * Alex Mason: [58]Other shootout news. * Xmonad: [59]contribs review: SpawnOn. * Jeff Heard: [60]Hieroglyph Haddock docs. * Alex Mason: [61]More n-bodies speedups. * Alex Mason: [62]N-bodies evolution. * Eric Kow (kowey): [63]practical quickcheck (wanted). Eric is seeking practical advice on how to effectively use QuickCheck. * Alex Mason: [64]TextMate haskell bundle improvements. * Haskell application server stack: [65]Happstack 0.1 Released (one day early!). * Haskell application server stack: [66]SOCALFP presentation: patch-tag as a startup using Happstack. * Neil Mitchell: [67]Monomorphism and Defaulting. * Jeff Heard: [68]Hieroglyph Part II, basic mouse/keyboard interactivity. * Jeff Heard: [69]Introducing Hieroglyph. Purely functional 2D visualization on top of Cairo.. The Hieroglyph library looks pretty cool! * Jeff Heard: [70]Hieroglyph HOWTO, part I: Sparklines. * Alex Mason: [71]N-bodies speedup (50%!). * >>> John Lato: [72]Build a better WAVE reader, pt 2. * GHC / OpenSPARC Project: [73]Join Points. * Luke Palmer: [74]Parallel Rewrite System. * >>> John Lato: [75]Build a better WAVE reader, pt 1. Notes on building an 'optimal audio I/O library in Haskell'. * Luke Palmer: [76]Dana update: System U-Box compiler is go. * Luke Palmer: [77]Dana needs a self-embedding of U-Box. * Beelsebob: [78]Simulating n-bodies and functional programming. A beautiful implementation of an n-bodies simulation using reactive. * Xmonad: [79]New layout: GridVariants.SplitGrid. * Lane: [80]Christopher Lane Hinson: MaybeArrow?. An arrow with possible failure, which still allows later effects to happen after failure. * Don Stewart (dons): [81]#haskell is a busy place. Some statistics on the #haskell IRC channel. * Alson Kemp: [82]Cabal-install is awesome. Enough said! * FP-Syd: [83]Sydney FP Group: FP-Syd #11.. * Brent Yorgey: [84]Diagrams 0.2 release. * Dan Piponi (sigfpe): [85]Beyond Regular Expressions: More Incremental String Matching. More incremental brain expansion courtesy of Dan. * Don Stewart (dons): [86]Reviving the Gofer Standard Prelude (circa. 1994). Haskell, retro-style! Quotes of the Week * sigfpe: If I took some Ritalin, maybe I could write an entire book on Haskell and algebra. * cjb: It's all fun and games until somebody loses an IOVar. * Gracenotes: You are likely to be eaten by a poset * Gracenotes: A public service announcement: if you find yourself overusing the Writer monad, tell (Sum 1) * Anonymous: Haskell, the world's leading purely fictional programming language * ehird: 2009: The Year of the Combinatorial Explosion of Haskell Web Frameworks. Also, the Linux Desktop. * ehird: [on the previous quote] Someone re-remember that quote when lambdabot's back so I don't have to and thereby look egotistical, thanks * luqui: Hmph! My program which uses unsafeCoerce everywhere is not working properly! Who'd have thought... About the Haskell Weekly News New editions are posted to [87]the Haskell mailing list as well as to [88]the Haskell Sequence and [89]Planet Haskell. [90]RSS is also available, and headlines appear on [91]haskell.org. To help create new editions of this newsletter, please see the information on [92]how to contribute. Send stories to byorgey at cis dot upenn dot edu. The darcs repository is available at darcs get [93]http://code.haskell.org/~byorgey/code/hwn/ . References 1. http://haskell.org/ 2. http://www.algorithm.com.au/blog/files/change.php#unique-entry-id-605 3. http://www.pixar.com/ 4. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52272 5. http://haskell.org/haskellwiki/Mutually_recursive_modules 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52045 7. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/UrlDisp 8. http://www.haskell.org/haskellwiki/UrlDisp 9. http://article.gmane.org/gmane.comp.lang.haskell.cafe/52012 10. http://article.gmane.org/gmane.comp.lang.haskell.cafe/51988 11. http://www.haskell.org/~simonmar/base-unicode.tar.gz 12. http://article.gmane.org/gmane.comp.lang.haskell.general/16846 13. http://article.gmane.org/gmane.comp.lang.haskell.general/16840 14. http://ui3.info/d/proj/multiplicity.html 15. http://duplicity.nongnu.org/index.html 16. http://article.gmane.org/gmane.comp.lang.haskell.general/16838 17. http://blog.happstack.com/2009/02/03/happstack-01-released 18. http://happstack.com/ 19. http://article.gmane.org/gmane.comp.lang.haskell.general/16833 20. http://article.gmane.org/gmane.comp.lang.haskell.general/16829 21. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex%2Dposix 22. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex%2Dtdfa 23. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex%2Dposix%2Dunittest 24. http://www.haskell.org/haskellwiki/Regex_Posix 25. http://article.gmane.org/gmane.comp.lang.haskell.general/16822 26. http://janestreetsummer.com/ 27. http://article.gmane.org/gmane.comp.lang.haskell.cafe/51783 28. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gitit 29. http://article.gmane.org/gmane.comp.lang.haskell.cafe/51764 30. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-xmlschema 31. http://www.haskell.org/haskellwiki/Regular_expressions_for_XML_Schema 32. http://article.gmane.org/gmane.comp.lang.haskell.cafe/51726 33. http://code.haskell.org/diagrams 34. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour 35. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/52219 36. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/51998 37. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/51858 38. http://article.gmane.org/gmane.comp.lang.haskell.general/16837 39. http://clip.dia.fi.upm.es/Job_Openings/RyC2009.html 40. http://clip.dia.fi.upm.es/ 41. http://article.gmane.org/gmane.comp.lang.haskell.general/16841 42. http://eecs.oregonstate.edu/ 43. http://planet.haskell.org/ 44. http://haskell.org/haskellwiki/Blog_articles 45. http://www.mega-nerd.com/erikd/Blog/CodeHacking/libsndfile/rel_18.html 46. http://syntax.wikidot.com/blog:1 47. http://greenokapi.net/blog/2008/12/01/functional-pearls-v2-now-with-monads-at-the-london-perl-workshop-2008/ 48. http://tehgeekmeister.wordpress.com/2009/02/06/google-code-project-google-group-and-darcs-repository-for-wikimediaparser/ 49. http://tehgeekmeister.wordpress.com/2009/02/05/releasing-wikimediaparser-01/ 50. http://www.algorithm.com.au/blog/files/change.php#unique-entry-id-605 51. http://augustss.blogspot.com/2009/02/is-haskell-fast-lets-do-simple.html 52. http://augustss.blogspot.com/2009/02/regression-they-say-that-as-you-get.html 53. http://www.galois.com/blog/2009/02/05/equivalence-and-safety-checking-in-cryptol/ 54. http://ghcsparc.blogspot.com/2009/02/just-testing.html 55. http://vis.renci.org/jeff/2009/02/05/heiroglyph-interactively-graph-a-spreadsheet-in-99-lines-of-code/ 56. http://vis.renci.org/jeff/2009/02/05/snippet-sorting-the-elements-of-a-map/ 57. http://lhc-compiler.blogspot.com/2009/02/grin-little.html 58. http://axman6.homeip.net/blog/2009/02/other-shootout-news.html 59. http://xmonad.wordpress.com/2009/02/04/contribs-review-spawnon/ 60. http://vis.renci.org/jeff/2009/02/04/hieroglyph-haddock-docs/ 61. http://axman6.homeip.net/blog/2009/02/more-n-bodies-speedups.html 62. http://axman6.homeip.net/blog/2009/02/n-bodies-evolution.html 63. http://koweycode.blogspot.com/2009/02/practical-quickcheck-wanted.html 64. http://axman6.homeip.net/blog/2009/02/textmate-haskell-bundle-improvments.html 65. http://blog.happstack.com/2009/02/03/happstack-01-released/ 66. http://blog.happstack.com/2009/02/03/socalfp-presentation-patch-tag-as-a-startup-using-happstack/ 67. http://neilmitchell.blogspot.com/2009/02/monomorphism-and-defaulting.html 68. http://vis.renci.org/jeff/2009/02/03/hieroglyph-part-ii-basic-mousekeyboard-interactivity/ 69. http://vis.renci.org/jeff/2009/02/03/introducing-hieroglyph-purely-functional-visualization-on-top-of-cairo/ 70. http://vis.renci.org/jeff/2009/02/03/hieroglyph-howto-part-i-sparklines/ 71. http://axman6.homeip.net/blog/2009/02/n-bodies-speedup-50.html 72. http://johnlato.blogspot.com/2009/02/build-better-wave-reader-pt-2.html 73. http://ghcsparc.blogspot.com/2009/02/join-points.html 74. http://lukepalmer.wordpress.com/2009/02/02/parallel-rewrite-system/ 75. http://johnlato.blogspot.com/2009/02/build-better-wave-reader.html 76. http://lukepalmer.wordpress.com/2009/02/02/dana-update-system-u-box-compiler-is-go/ 77. http://lukepalmer.wordpress.com/2009/02/02/dana-needs-a-self-embedding-of-u-box/ 78. http://noordering.wordpress.com/2009/02/01/simulating-n-bodies-and-functional-programmingre/ 79. http://xmonad.wordpress.com/2009/02/01/new-layout-gridvariantssplitgrid/ 80. http://blog.downstairspeople.org/2009/01/04/maybearrow/ 81. http://donsbot.wordpress.com/2009/02/01/haskell-is-a-busy-place/ 82. http://www.alsonkemp.com/haskell/cabal-install-is-awesome/ 83. http://www.mega-nerd.com/erikd/Blog/FP-Syd/fp-syd-11.html 84. http://byorgey.wordpress.com/2009/01/31/diagrams-02-release/ 85. http://sigfpe.blogspot.com/2009/01/beyond-regular-expressions-more.html 86. http://donsbot.wordpress.com/2009/01/31/reviving-the-gofer-standard-prelude-circa-1994/ 87. http://www.haskell.org/mailman/listinfo/haskell 88. http://sequence.complete.org/ 89. http://planet.haskell.org/ 90. http://sequence.complete.org/node/feed 91. http://haskell.org/ 92. http://haskell.org/haskellwiki/HWN 93. http://code.haskell.org/~byorgey/code/hwn/ From manlio_perillo at libero.it Sat Feb 7 14:12:51 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Feb 7 14:02:53 2009 Subject: [Haskell-cafe] HSGI: Haskell Server Gateway Interface Message-ID: <498DDD33.7030101@libero.it> Lately I have started to think about how I would like to implement a web application framework in Haskell. To keep my thoughts well defined, I have decided to write some documents. My ideas are heavily based on my experience with Python WSGI, and a Python WSGI framework I'm implementing (wsgix). Note that there is already another attempt to define an Haskell Gateway interface, and it may also have the same name! However I'm not trying to write a formal specification. The core of my idea is in the Haskell Web Application Framework, I just need a gateway interface as a building block. I apologize for my not very good experience at writing in english and Haskell. Also note that the document is in a very rough state. I'm announcing it here, to receive feedback, just to make sure that what I would like to do is possible/convenient to do in Haskell. The documents (only the first one - HSGI - available at the moment) are available here: http://mperillo.ath.cx/haskell/ Thanks and regards Manlio Perillo From dev at mobileink.com Sat Feb 7 14:36:39 2009 From: dev at mobileink.com (gregg reynolds) Date: Sat Feb 7 14:27:02 2009 Subject: [Haskell-cafe] Semantic web Message-ID: Anybody implementing rdf or owl stuff in haskell? Seems like a natural fit. G From dons at galois.com Sat Feb 7 14:40:41 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 14:31:10 2009 Subject: [Haskell-cafe] Semantic web In-Reply-To: References: Message-ID: <20090207194040.GK27081@whirlpool.galois.com> dev: > Anybody implementing rdf or owl stuff in haskell? Seems like a natural fit. http://www.ninebynine.org/RDFNotes/Swish/Intro.html Needs moving to Hackage. From gwern0 at gmail.com Sat Feb 7 15:02:53 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Feb 7 14:52:50 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <20090207181243.GH27081@whirlpool.galois.com> <20090207183429.GJ27081@whirlpool.galois.com> Message-ID: On Sat, Feb 7, 2009 at 1:34 PM, Don Stewart wrote: > Oh, we had a long discussion about the need for condorcet voting, > not a system like the reddit which is prone to abuse. > > Also, it would be good to have the images inline. Perfect, please meet better. Better, perfect. Now get along you two! Since January 1st, we could've had hundreds or thousands of votes and easily compensated for any abuse. -- gwern From dons at galois.com Sat Feb 7 15:04:01 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 14:54:31 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <20090207181243.GH27081@whirlpool.galois.com> <20090207183429.GJ27081@whirlpool.galois.com> Message-ID: <20090207200401.GM27081@whirlpool.galois.com> gwern0: > On Sat, Feb 7, 2009 at 1:34 PM, Don Stewart wrote: > > Oh, we had a long discussion about the need for condorcet voting, > > not a system like the reddit which is prone to abuse. > > > > Also, it would be good to have the images inline. > > Perfect, please meet better. Better, perfect. Now get along you two! > > Since January 1st, we could've had hundreds or thousands of votes and > easily compensated for any abuse. Unfortunately, reddit isn't a suitable voting site, as submissions decay over time, dissappearing off the page after a day or two. It does have up and down mods, but in no other way is a voting site. -- Don From gwern0 at gmail.com Sat Feb 7 15:20:38 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Feb 7 15:10:33 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207200401.GM27081@whirlpool.galois.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <20090207181243.GH27081@whirlpool.galois.com> <20090207183429.GJ27081@whirlpool.galois.com> <20090207200401.GM27081@whirlpool.galois.com> Message-ID: On Sat, Feb 7, 2009 at 3:04 PM, Don Stewart wrote: > gwern0: >> On Sat, Feb 7, 2009 at 1:34 PM, Don Stewart wrote: >> > Oh, we had a long discussion about the need for condorcet voting, >> > not a system like the reddit which is prone to abuse. >> > >> > Also, it would be good to have the images inline. >> >> Perfect, please meet better. Better, perfect. Now get along you two! >> >> Since January 1st, we could've had hundreds or thousands of votes and >> easily compensated for any abuse. > > Unfortunately, reddit isn't a suitable voting site, as submissions decay > over time, dissappearing off the page after a day or two. It does have > up and down mods, but in no other way is a voting site. > > -- Don That's how the what's hot works, I understand. But it seems to me that Top works just fine for vote tallying purposes eg. http://www.reddit.com/r/haskell/top/ lists quite a few posts posted months ago (4 months seems to be the oldest). -- gwern From dons at galois.com Sat Feb 7 15:29:58 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 15:20:27 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <20090207181243.GH27081@whirlpool.galois.com> <20090207183429.GJ27081@whirlpool.galois.com> <20090207200401.GM27081@whirlpool.galois.com> Message-ID: <20090207202958.GN27081@whirlpool.galois.com> gwern0: > On Sat, Feb 7, 2009 at 3:04 PM, Don Stewart wrote: > > gwern0: > >> On Sat, Feb 7, 2009 at 1:34 PM, Don Stewart wrote: > >> > Oh, we had a long discussion about the need for condorcet voting, > >> > not a system like the reddit which is prone to abuse. > >> > > >> > Also, it would be good to have the images inline. > >> > >> Perfect, please meet better. Better, perfect. Now get along you two! > >> > >> Since January 1st, we could've had hundreds or thousands of votes and > >> easily compensated for any abuse. > > > > Unfortunately, reddit isn't a suitable voting site, as submissions decay > > over time, dissappearing off the page after a day or two. It does have > > up and down mods, but in no other way is a voting site. > > > > -- Don > > That's how the what's hot works, I understand. But it seems to me that > Top works just fine for vote tallying purposes eg. > http://www.reddit.com/r/haskell/top/ lists quite a few posts posted > months ago (4 months seems to be the oldest). Quite so, biased by the fact that they dropped off the page. I'm not saying reddit is unsuitable for communal decision making -- I've thought hard about this -- just that isn't perfect, and this isn't really its purpose. It would make a good backup if we can't find a proper system. -- Don From fmartini at gmail.com Sat Feb 7 15:57:24 2009 From: fmartini at gmail.com (Felix Martini) Date: Sat Feb 7 15:47:19 2009 Subject: [Haskell-cafe] HSGI: Haskell Server Gateway Interface In-Reply-To: <498DDD33.7030101@libero.it> References: <498DDD33.7030101@libero.it> Message-ID: <6c0416190902071257j43384eeawf693b3f5ed13557a@mail.gmail.com> Hi Manlio, Have you looked at http://www.haskell.org/haskellwiki/WebApplicationInterface ? If you did is there something in that proposal that you think should be changed or is not clear? There is currently a lot of interest in writing web frameworks for Haskell and it would be great if the frameworks support a common interface like Python's WSGI and Ruby's Rack interface and all use the same frontends like Hyena and modules for Apache, Nginx etc. Felix From alistair at abayley.org Sat Feb 7 16:31:47 2009 From: alistair at abayley.org (Alistair Bayley) Date: Sat Feb 7 16:21:43 2009 Subject: [Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <1233959225.26754.713.camel@localhost> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <79d7c4980902060235x5eb42955p196dfe68707daab0@mail.gmail.com> <1233959225.26754.713.camel@localhost> Message-ID: <79d7c4980902071331w1546ca7dtbb363e3e5c994109@mail.gmail.com> 2009/2/6 Duncan Coutts : > > Yes, against my better judgement the code in Cabal for haddock-2.x does > not run cpp or unliting like it does for haddock-0.x. Instead it assumes > that haddock-2.x will do all the cpp and unliting itself. Obviously this > mean the special unliting mode that Cabal provides is not usable with > haddock-2.x. > > The solution is to do the pre-processing the same for haddock-0.x and > 2.x. Generally the haddock code in Cabal is a horrible inconsistent > mess. I believe Andrea Vezzosi has been looking at rewriting it, which > is good news. In Distribution.Simple.Haddock, in the haddock function we have: withLib pkg_descr () $ \lib -> do let bi = libBuildInfo lib modules = PD.exposedModules lib ++ otherModules bi inFiles <- getLibSourceFiles lbi lib unless isVersion2 $ mockAll bi inFiles So I guess the easiest thing to do right now is remove the "unless isVersion2 $" . I'm testing this at the moment, so when I get it working (or not) I'll let you know, and maybe send a patch. Alistair From gwern0 at gmail.com Sat Feb 7 16:31:57 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sat Feb 7 16:21:56 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207202958.GN27081@whirlpool.galois.com> References: <498DC25E.8070808@cogito.org.uk> <20090207181243.GH27081@whirlpool.galois.com> <20090207183429.GJ27081@whirlpool.galois.com> <20090207200401.GM27081@whirlpool.galois.com> <20090207202958.GN27081@whirlpool.galois.com> Message-ID: 2009/2/7 Don Stewart : > Quite so, biased by the fact that they dropped off the page. > > I'm not saying reddit is unsuitable for communal decision making -- I've > thought hard about this -- just that isn't perfect, and this isn't > really its purpose. It would make a good backup if we can't find a > proper system. > > -- Don And how long do we wait? Is a month long enough? 2 months? Do we just make a note on our calendars for February 2010 - 'get moving on that logo contest thing'? -- gwern From derek.a.elkins at gmail.com Sat Feb 7 16:32:20 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Feb 7 16:22:20 2009 Subject: [Haskell-cafe] Bind as a sequencing operator (Was: evaluation semantics of bind) In-Reply-To: <87r62cg1ew.fsf@justinbogner.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <878wokhmtz.fsf@justinbogner.com> <498B174A.202@pikewerks.com> <87y6wkg6es.fsf@justinbogner.com> <498B2584.108@pikewerks.com> <87r62cg1ew.fsf@justinbogner.com> Message-ID: <1234042340.27250.117.camel@derek-laptop> On Thu, 2009-02-05 at 11:47 -0700, mail@justinbogner.com wrote: > Jake McArthur writes: > > mail@justinbogner.com wrote: > > | Oops, sent this off list the first time, here it is again. > > | > > | Jake McArthur writes: > > |> mail@justinbogner.com wrote: > > |> | Bind is a sequencing operator rather than an application operator. > > |> > > |> In my opinion, this is a common misconception. I think that bind would > > |> be nicer if its arguments were reversed. > > | > > | If this is a misconception, why does thinking of it this way work so > > | well? This idea is reinforced by the do notation syntactic sugar: bind > > | can be represented by going into imperative land and "do"ing one thing > > | before another. > > > > An imperative-looking notation does not make something imperative. > > > > Thinking of bind as sequencing really *doesn't* work very well. What > > does bind have to do with sequencing at all in the list monad, for > > example? What about the reader monad? > > > > - Jake > > What doesn't bind have to do with sequencing in the list monad? > Consider: > > [1..2] >>= return . (^2) > > This says "generate the list [1..2] and then use it to generate a list > of squares". It's more than just application, it's a description of a > sequence of actions. The whole point of list comprehensions (which is > the only reason to have a list monad, as far as I know) is to think > of it this way rather than as an application of concatMap. > > As for Reader, I don't know enough about it to say anything. Jake is more or less right. The Monad interface does nothing to enforce any particular evaluation order. The interface is, however, too narrow for you to express "do these two things in an indeterminate order" so you are forced to choose a particular linearization. Commutative monads, such as Reader, could relax that constraint, not that it would really mean much in many of those cases. Now, if we wanted to give a semantics for a call-by-value programming language, which was exactly the sort of thing Moggi was thinking about when he was talking about monads, then application would indeed translate into exactly (flipped) (>>=). So the expression (f x) in, say, SML would be translated to (f =<< x) using some appropriate monad to model the side-effects that ML supports. Actually, a 'let' like notation is often preferred as it matches better with lists of statements more prettily than the equivalent of treating ; as const. This is the source of the name 'bind' as, e.g. the ML, (let a = M in let b = N in a+b) translates to (M >>= \a -> N >>= \b -> return (a+b)) and, of course, do-notation is just a syntactic variant of this 'let' notation. From derek.a.elkins at gmail.com Sat Feb 7 16:33:35 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Sat Feb 7 16:23:33 2009 Subject: [Haskell-cafe] morphisms in IO In-Reply-To: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> References: <75cc17ac0902051852t55bf412fg8bda17f23a86c6ec@mail.gmail.com> Message-ID: <1234042415.27250.119.camel@derek-laptop> On Thu, 2009-02-05 at 20:52 -0600, Gregg Reynolds wrote: > I'm working on a radically different way of looking at IO. Before I > post it and make a fool of myself, I'd appreciate a reality check on > the following points: > > a) Can IO be thought of as a category? I think the answer is yes. No. At least not in any reasonable way. > b) If it is a category, what are its morphisms? I think the answer > is: it has no morphisms. The morphisms available are natural > transformations or functors, and thus not /in/ the category. > Alternatively: we have no means of directly naming its values, so the > only way we can operate on its values is to use morphisms from the > outside (operating on construction expressions qua morphisms.) N/A > c) All categories with no morphisms ("bereft categories"?) are > isomorphic (to each other). I think yes. No. "Discrete" categories which you seem to be talking about are isomorphic to sets (namely their set of objects). Not all sets are isomorphic. From dons at galois.com Sat Feb 7 16:35:41 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 16:26:11 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <20090207181243.GH27081@whirlpool.galois.com> <20090207183429.GJ27081@whirlpool.galois.com> <20090207200401.GM27081@whirlpool.galois.com> <20090207202958.GN27081@whirlpool.galois.com> Message-ID: <20090207213541.GQ27081@whirlpool.galois.com> gwern0: > 2009/2/7 Don Stewart : > > Quite so, biased by the fact that they dropped off the page. > > > > I'm not saying reddit is unsuitable for communal decision making -- I've > > thought hard about this -- just that isn't perfect, and this isn't > > really its purpose. It would make a good backup if we can't find a > > proper system. > > > > -- Don > > And how long do we wait? Is a month long enough? 2 months? Do we just > make a note on our calendars for February 2010 - 'get moving on that > logo contest thing'? Help identifying and implementing a voting process is very welcome. Snarky comments are not. -- Don From dons at galois.com Sat Feb 7 16:40:50 2009 From: dons at galois.com (Don Stewart) Date: Sat Feb 7 16:31:20 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <1988130373.20090207214806@gmail.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> Message-ID: <20090207214050.GR27081@whirlpool.galois.com> bulat.ziganshin: > Hello Don, > > Saturday, February 7, 2009, 8:20:23 PM, you wrote: > > > We need a voting site set up. There was some progress prior to the end > > of the year. Updates welcome! > > i think that there are a lot of free voting/survey services available. > the last one i went through was LimeSurvey available for any SF > project and on separate site too > > http://apps.sourceforge.net/trac/sitedocs/wiki/Hosted%20Apps > https://www.limeservice.com/ > Before the new year's break, the progress we made towards deciding on a voting process was, http://groups.google.com/group/fa.haskell/msg/5d0ad1a681b044c7 Eelco implemented a demo condorcet voting system in HAppS. He then asked for help with some decisions: * Limit voting, if so how? Email confirmation, IP based, vote once, once per day? * Maybe don't show the results until the contest is over? Eelco, can we do simple email-based confirm to encourage people to vote only once, and can we keep the results closed until the vote process is over? -- Don From manlio_perillo at libero.it Sat Feb 7 16:52:21 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Feb 7 16:42:20 2009 Subject: [Haskell-cafe] HSGI: Haskell Server Gateway Interface In-Reply-To: <6c0416190902071257j43384eeawf693b3f5ed13557a@mail.gmail.com> References: <498DDD33.7030101@libero.it> <6c0416190902071257j43384eeawf693b3f5ed13557a@mail.gmail.com> Message-ID: <498E0295.9090700@libero.it> Felix Martini ha scritto: > Hi Manlio, > > Have you looked at > http://www.haskell.org/haskellwiki/WebApplicationInterface ? If you remember, I posted a few messages in the thread where WAI was announced. There is a separate channel where we can discuss in detail? Or should I just use this thread? > If you > did is there something in that proposal that you think should be > changed or is not clear? Here are the problems: 1) supported HTTP methods are fixed, since you use a custom data type 2) no support for other possible CGI variables (or simply custom variables: I use the environ dictionary to store application configuration, and I think it is a great thing). I think that we should simply have a dictionary Map ByteString ByteString 3) No support for optimized file serving, like with WSGI file_wrapper 4) No support for keeping "complex" state (like database connection) in the environ. I have read some examples with CGI package, where a custom monad transformer is used. I'm not sure if this solution is flexible and "scalable". 5) I can't find documentation about the type of the response. It is rather clear that it is (ByteString, [(ByteString, ByteString)], Enumerator) but this should be documented somewhere. There are also few typos: * Chapter 2: "A standardized interface is of no use of no..." should be "A standardized interface is of no use if no..." * Chapter 4.2 "However, if the the amount..." should be "However, if the amount..." As a last note: I have some doubts about the name, since gateway is not in it ;-). Regards Manlio Perillo From fmartini at gmail.com Sat Feb 7 17:01:26 2009 From: fmartini at gmail.com (Felix Martini) Date: Sat Feb 7 16:51:21 2009 Subject: [Haskell-cafe] HSGI: Haskell Server Gateway Interface In-Reply-To: <498E0295.9090700@libero.it> References: <498DDD33.7030101@libero.it> <6c0416190902071257j43384eeawf693b3f5ed13557a@mail.gmail.com> <498E0295.9090700@libero.it> Message-ID: <6c0416190902071401l5910c2bci5843846f1e777bfa@mail.gmail.com> > There is a separate channel where we can discuss in detail? > Or should I just use this thread? This is a good topic for the web-devel@haskell.org list. I'll post my reply there. Felix From manlio_perillo at libero.it Sat Feb 7 17:20:04 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Sat Feb 7 17:10:04 2009 Subject: [Haskell-cafe] HSGI: Haskell Server Gateway Interface In-Reply-To: <6c0416190902071257j43384eeawf693b3f5ed13557a@mail.gmail.com> References: <498DDD33.7030101@libero.it> <6c0416190902071257j43384eeawf693b3f5ed13557a@mail.gmail.com> Message-ID: <498E0914.2020901@libero.it> Felix Martini ha scritto: > Hi Manlio, > > Have you looked at > http://www.haskell.org/haskellwiki/WebApplicationInterface ? If you > did is there something in that proposal that you think should be > changed or is not clear? There is currently a lot of interest in > writing web frameworks for Haskell and it would be great if the > frameworks support a common interface like Python's WSGI and Ruby's > Rack interface and all use the same frontends like Hyena and modules > for Apache, Nginx etc. > Another typo at chapter 4.2 (the end): "The consumed likely wants..." should be "The consumer likely wants..." Another problem I have not discussed in previous reply is with the use of the custom Enumerator. There is nothing wrong in using it (it is the best choice, IMHO), however there is *little* support for enumerators in Haskell base packages, and little examples about how to use it. It is not a "know" pattern in the Haskell community. So, it may be the right choices, but it may be a bit premature, IMHO. > Felix > Manlio From temp.public at gmail.com Sat Feb 7 18:24:27 2009 From: temp.public at gmail.com (TKM) Date: Sat Feb 7 18:15:47 2009 Subject: [Haskell-cafe] Function const (Binding) Message-ID: <0FB842FB4C374B4881BD1FC92A55E44F@TOSHIBA> Hello, I've a small question about the function const. I'm a bit of confused about how it binds. Let me take the following expression as example: const id 1 2 If I execute this expression, I will get as answer 2 with Helium. Now is my question, why doesn't it give me 1 as the answer? Because the type of id would be: a -> a. So first it would execute id 1 in my opinion. That gives us 1. And after executing const 1 2 it should give us 1. Can somebody explain to me why it does not bind as I expect? (I know I can do: const (id 1) 2 to get what I want) Thank you for your answers. Greetz TKM -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090208/97df2761/attachment.htm From tmorris at tmorris.net Sat Feb 7 18:28:40 2009 From: tmorris at tmorris.net (Tony Morris) Date: Sat Feb 7 18:18:42 2009 Subject: [Haskell-cafe] Function const (Binding) In-Reply-To: <0FB842FB4C374B4881BD1FC92A55E44F@TOSHIBA> References: <0FB842FB4C374B4881BD1FC92A55E44F@TOSHIBA> Message-ID: <498E1928.5040005@tmorris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe it will help with parentheses: (const id 1) 2 (const id 1) ignores the second argument and yields the id function so then id 2 which is just 2. TKM wrote: > Hello, > > I've a small question about the function const. I'm a bit of > confused about how it binds. Let me take the following expression > as example: > > const id 1 2 > > If I execute this expression, I will get as answer 2 with Helium. > Now is my question, why doesn't it give me 1 as the answer? Because > the type of id would be: a -> a. So first it would execute id 1 in > my opinion. That gives us 1. And after executing const 1 2 it > should give us 1. > > Can somebody explain to me why it does not bind as I expect? (I > know I can do: const (id 1) 2 to get what I want) > > Thank you for your answers. > > Greetz TKM > > ---------------------------------------------------------------------- > > > _______________________________________________ Haskell-Cafe > mailing list Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe - -- Tony Morris http://tmorris.net/ ************************************ * Anteromedial Osseous Impingement * ************************************ http://www.ajronline.org/cgi/content/full/178/3/601 "can result in chronic ankle pain, especially in athletes and the younger population (15-40 years old)" http://radiographics.rsnajnls.org/cgi/content/figsonly/22/6/1457 "Soft-tissue and osseous impingement syndromes of the ankle can be an important cause of chronic pain, particularly in the professional athlete." 1. Take any person with soft tissue and osseous joint impingement from trauma 2. Surgically tighten the joint ligaments particularly those in the area of impingement. 3. When the patient complains of incredible and permanent pain, shrug your shoulders. Outcome You'll find the patient at the mental hospital bordering psychosis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJjhkomnpgrYe6r60RAmvtAKDBQxNAlc2tfN283vcvs5gkzXUEjwCgpw7s CcGAha7L6AgHESzwLSoD2XU= =szrP -----END PGP SIGNATURE----- From daniel.is.fischer at web.de Sat Feb 7 18:38:49 2009 From: daniel.is.fischer at web.de (Daniel Fischer) Date: Sat Feb 7 18:26:09 2009 Subject: [Haskell-cafe] Function const (Binding) In-Reply-To: <0FB842FB4C374B4881BD1FC92A55E44F@TOSHIBA> References: <0FB842FB4C374B4881BD1FC92A55E44F@TOSHIBA> Message-ID: <200902080038.51088.daniel.is.fischer@web.de> Am Sonntag, 8. Februar 2009 00:24 schrieb TKM: > Hello, > > I've a small question about the function const. I'm a bit of confused about > how it binds. Let me take the following expression as example: > > const id 1 2 > > If I execute this expression, I will get as answer 2 with Helium. Now is my > question, why doesn't it give me 1 as the answer? Because the type of id > would be: a -> a. So first it would execute id 1 in my opinion. That gives > us 1. And after executing const 1 2 it should give us 1. > > Can somebody explain to me why it does not bind as I expect? (I know I can > do: const (id 1) 2 to get what I want) > > Thank you for your answers. > > Greetz TKM Function application associates to the left, so f a b c d is the same as (((f a) b) c) d and in your example const id 1 2 === ((const id) 1) 2, so first (const id) is evaluated, that is then applied to 1 and finally the result of const id 1 is applied to 2. Now (const x) === \y -> x, so (const id) 1 is id and id 2 === 2. HTH, Daniel From lemming at henning-thielemann.de Sat Feb 7 19:25:31 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat Feb 7 19:15:31 2009 Subject: [Haskell-cafe] ANN: HLint 1.2 In-Reply-To: <1231770379.28590.77.camel@localhost> References: <404396ef0901111405g2b3f4ca2wa13f4c6408c33fee@mail.gmail.com> <1231768913.28590.66.camel@localhost> <1231770379.28590.77.camel@localhost> Message-ID: On Mon, 12 Jan 2009, Duncan Coutts wrote: > On Mon, 2009-01-12 at 15:06 +0100, Henning Thielemann wrote: > > >>> It has to be manually transformed into a version that is not recursive >>> at the top level: >>> >>> map :: (a -> b) -> [a] -> [b] >>> map f = go >>> where >>> go [] = [] >>> go (x:xs) = f x : go xs >>> >>> Then the map can be inlined at the call site and the 'f' inlined into >>> the body of 'go'. >> >> Maybe HLint can make such suggestions ... > > I think HLint's philosophy prefers elegant code to performance hacks. I encountered just another instance of 'jumping into the wrong loop' when experimenting with a function using top-level recursion. Thus I summarized the stylistic reasons pro local recursion: http://www.haskell.org/haskellwiki/Top-level_vs._local_recursion From wchogg at gmail.com Sat Feb 7 19:36:33 2009 From: wchogg at gmail.com (Creighton Hogg) Date: Sat Feb 7 19:26:27 2009 Subject: [Haskell-cafe] ANN : happs-tutorial 0.7 In-Reply-To: <814617240902071625o79c8e7des35f155cc7a4655f3@mail.gmail.com> References: <814617240902071625o79c8e7des35f155cc7a4655f3@mail.gmail.com> Message-ID: <814617240902071636i19cc30c2y49b77cd54c80449a@mail.gmail.com> Hello, I'm pleased to announce the release of happs-tutorial 0.7 on Hackage. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-tutorial This is the first release of happs-tutorial built against the new Happstack project. Not much has changed in content since the last release except a few minor cleanups & a little bit of reorganization. The 0.8 release will consist of more extensive additions, with the primary focus being a walk through of multimaster. I've taken over the development of the tutorial from Thomas Hartman, who has already put a rather massive effort into making HAppS/Happstack more accessible. Please feel free to e-mail me with any comments, errata, or threats of bodily harm. Cheers, Creighton Hogg From gale at sefer.org Sat Feb 7 20:24:11 2009 From: gale at sefer.org (Yitzchak Gale) Date: Sat Feb 7 20:14:06 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: References: <498B5BF3.5060405@pikewerks.com> Message-ID: <2608b8a80902071724w4634d174y5728c00547305db0@mail.gmail.com> Peter Verswyvelen wrote: > I do have asked myself the question whether a "really random generating" > function could be regarded as "pure" somehow Not really. Somewhere in your program you are likely to make the assumption that a value you obtained, however indirectly, from this function will be the same in two different places. But the sands will constantly be shifting. Furthermore, in real life physical RNGs also involve state, because they need to accumulate entropy. For example, in Unix (on many platforms), the physical RNG device /dev/random will block until there is enough entropy to provide a random number. The /dev/urandom device always returns a number immediately, but that is because it will return a pseudo-random number if there is not enough entropy available, again requiring state. -Yitz From dev at mobileink.com Sat Feb 7 21:31:52 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Sat Feb 7 21:21:51 2009 Subject: [Haskell-cafe] Moggi :: CT -> Hask In-Reply-To: <200902071300.08944.dan.doel@gmail.com> References: <75cc17ac0902070911m5075d53bs952b615f0c1353cf@mail.gmail.com> <200902071300.08944.dan.doel@gmail.com> Message-ID: <75cc17ac0902071831k283b40fche8050f49aa058ea3@mail.gmail.com> Hi Dan, On Sat, Feb 7, 2009 at 12:00 PM, Dan Doel wrote: > On Saturday 07 February 2009 12:11:29 pm Gregg Reynolds wrote: > > As far as I know, Moggi didn't really have anything directly to do with > Haskell. He pioneered the idea of monads being useful in denotational > semantics. But it was Wadler that recognized that they'd be useful for > actually writing functional programs (see his "The Essence of Functional > Programming"). So one might say that it was his doing that brought monads > to > Haskell proper. > >From what I've read Wadler was clearly the guy who thought of using monads in Haskell, but he explicitly credits Moggi for coming up with the general idea. Moggi just as clearly knew he was on to something powerful and useful (e.g. something " that could lead to the introduction of higher order modules in programming languages like ADA or ML"). What I would be interested in knowing is whether it was Wadler or Moggi who first realized monads (and CT) could be encoded directly in a target language, not just in a semantic metalanguage. Plus there were other people working in the same area; I just don't know the detailed history. Might be a good subject for a blog post for somebody who does. FYI I made a few corrections to my original post. -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090207/588fc4ba/attachment-0001.htm From redcom at fedoms.com Sat Feb 7 23:14:46 2009 From: redcom at fedoms.com (=?UTF-8?B?R8KfdWVudGhlciBTY2htaWR0?=) Date: Sat Feb 7 23:04:51 2009 Subject: [Haskell-cafe] Re: Haskell and Automation In-Reply-To: <29bf512f0902071912s4d20a631k72c3ae83a326f5b3@mail.gmail.com> References: <498CF871.4060801@fedoms.com> <29bf512f0902071912s4d20a631k72c3ae83a326f5b3@mail.gmail.com> Message-ID: <498E5C36.30901@fedoms.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: user-a4.ps Type: application/postscript Size: 403820 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090208/25b5284a/user-a4-0001.ps From noteed at gmail.com Sun Feb 8 07:50:42 2009 From: noteed at gmail.com (minh thu) Date: Sun Feb 8 07:40:34 2009 Subject: [Haskell-cafe] how to link statically with a c lib ? Message-ID: <40a414c20902080450i55bfec0aj7f6259edb99293ce@mail.gmail.com> Hi, I'm writing bindings for the Tiny C Compiler. It seems that tcc provide a libtcc.a but no libtcc.so. In my cabal file, I have extra-libraries: dl, tcc but when using the generated haskell module, I have the following message : ?thu@jones samples? ghc -e "main" Test.hs : : can't load .so/.DLL for: tcc (libtcc.so: cannot open shared object file: No such file or directory) How can I generate a module linked statically against libtcc ? Thanks, Thu From jianzhou at seas.upenn.edu Sun Feb 8 08:45:55 2009 From: jianzhou at seas.upenn.edu (Jianzhou Zhao) Date: Sun Feb 8 08:35:54 2009 Subject: [Haskell-cafe] any implementation of ACIO? Message-ID: <43D4C2DADE6143D68FC1FF8DB68EC917@zjzzjzPC> Hi, http://www.haskell.org/pipermail/haskell-cafe/2004-November/007715.html mentioned an interesting (A)ffine and (C)entral IO. Are there any packages or extensions to support ACIO in Haskell? Thanks JZ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090208/39f4f5d0/attachment.htm From gale at sefer.org Sun Feb 8 09:32:33 2009 From: gale at sefer.org (Yitzchak Gale) Date: Sun Feb 8 09:22:25 2009 Subject: [Haskell-cafe] Just how unsafe is unsafe In-Reply-To: References: <498B5BF3.5060405@pikewerks.com> <2608b8a80902071724w4634d174y5728c00547305db0@mail.gmail.com> Message-ID: <2608b8a80902080632s39da577gd4841dbadcefca61@mail.gmail.com> Peter Verswyvelen wrote: >>> I do have asked myself the question whether >>> a "really random generating" >>> function could be regarded as "pure" somehow I wrote: >> Not really... Alberto G. Corona wrote: > What is pure randomness? .When the algorithmic complexity of the list of > random number is equal to the lenght of the list, that is, is incompressible > by any means. But this can not be probed. the distribution of values gives a > hint of whether if the list obey any algorithm, but even so, many > compressible series have a random distribution. in practical terms, it is > random has a random distribution, the receiver does not know the algorithm > AND the initial value. In this case it can be pure. Perhaps philosophically you can consider it pure, but it is unsafe to treat it as pure in your program. If you write x = genRandomR (1, 100) then the compiler may or may not replace the variable x by the function application genRandomR (1, 100) anywhere in your program. That is probably not what you want. -Yitz From alexott at gmail.com Sun Feb 8 09:53:53 2009 From: alexott at gmail.com (Alex Ott) Date: Sun Feb 8 09:43:45 2009 Subject: [Haskell-cafe] [ANN] Working with HLint from Emacs In-Reply-To: References: Message-ID: <259495020902080653j64584683pc815f1adbc345dcb@mail.gmail.com> Hello On Wed, Jan 28, 2009 at 12:30 PM, Colin Paul Adams wrote: >>>>>> "Alex" == Alex Ott writes: > > Alex> Hello For Emacs users it could be interesting - I wrote > Alex> small module for more comfortable work with HLint from > Alex> Emacs. It has same functionality as compilation-mode - > Alex> navigation between errors, etc. .... > I've done that. > Now how do you get it to do anything? In your source file, opened in Emacs, just press C-c l, and it will run HLint and you'll able to navigate between suggestions with C-x ` combination. P.S. Today i released the second version of package, that allows to apply suggestions to source code - see more details at http://alexott.blogspot.com/2009/02/second-version-of-hs-lint-package.html -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://alexott-ru.blogspot.com/ http://xtalk.msk.su/~ott/ From dons at galois.com Sun Feb 8 11:48:24 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 8 11:38:54 2009 Subject: [Haskell-cafe] any implementation of ACIO? In-Reply-To: <43D4C2DADE6143D68FC1FF8DB68EC917@zjzzjzPC> References: <43D4C2DADE6143D68FC1FF8DB68EC917@zjzzjzPC> Message-ID: <20090208164824.GA29860@whirlpool.galois.com> jianzhou: > Hi, > > http://www.haskell.org/pipermail/haskell-cafe/2004-November/007715.html > mentioned an interesting (A)ffine and (C)entral IO. Are there any packages > or extensions to support ACIO in Haskell? Not that I know of. -- Don From dons at galois.com Sun Feb 8 11:49:21 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 8 11:39:47 2009 Subject: [Haskell-cafe] how to link statically with a c lib ? In-Reply-To: <40a414c20902080450i55bfec0aj7f6259edb99293ce@mail.gmail.com> References: <40a414c20902080450i55bfec0aj7f6259edb99293ce@mail.gmail.com> Message-ID: <20090208164921.GB29860@whirlpool.galois.com> noteed: > Hi, > > I'm writing bindings for the Tiny C Compiler. > It seems that tcc provide a libtcc.a but no libtcc.so. > > In my cabal file, I have > > extra-libraries: dl, tcc > > but when using the generated haskell module, > I have the following message : > > ?thu@jones samples? ghc -e "main" Test.hs > : : can't load .so/.DLL for: tcc > (libtcc.so: cannot open shared object file: No such file or directory) > > How can I generate a module linked statically against libtcc ? Without a .so you can't load it in ghci, but you can compile it with ghc. ghc --make Test.hs -- Don From gwern0 at gmail.com Sun Feb 8 11:57:29 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Feb 8 11:47:21 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207214050.GR27081@whirlpool.galois.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> Message-ID: On Sat, Feb 7, 2009 at 4:40 PM, Don Stewart wrote: > bulat.ziganshin: >> Hello Don, >> >> Saturday, February 7, 2009, 8:20:23 PM, you wrote: >> >> > We need a voting site set up. There was some progress prior to the end >> > of the year. Updates welcome! >> >> i think that there are a lot of free voting/survey services available. >> the last one i went through was LimeSurvey available for any SF >> project and on separate site too >> >> http://apps.sourceforge.net/trac/sitedocs/wiki/Hosted%20Apps >> https://www.limeservice.com/ >> > > Before the new year's break, the progress we made towards deciding on a > voting process was, > > http://groups.google.com/group/fa.haskell/msg/5d0ad1a681b044c7 > > Eelco implemented a demo condorcet voting system in HAppS. > > He then asked for help with some decisions: > > * Limit voting, if so how? Email confirmation, IP based, vote once, once per day? > * Maybe don't show the results until the contest is over? > > Eelco, can we do simple email-based confirm to encourage people to vote > only once, and can we keep the results closed until the vote process is > over? > > -- Don We should limit voting, and limit based on IP. If we go via email, then anyone wishing extra votes merely needs to use mailinator.com (and its dozens of alternate domain names, to say nothing of competitors providing similar services) to vote as many times as they want. If we care about fraud, then it would be a very troublesome task to filter out all those ways to fraudulently vote; if we don't care about fraud, then email confirms are just a burden on honest users. > Help identifying and implementing a voting process is very welcome. > Snarky comments are not. An open-ended search process is obviously hazardous to any schedule. A logo is something that is better decided on sooner than later, since the Haskell community (and uses of the logo) is growing. Setting a deadline, even for a long time from now like a month or two, has no downside: if we reach the deadline, then we have limited the amount of time wasted; if a better system turns up before the deadline, then the deadline was nugatory and of no harm. -- gwern From max.rabkin at gmail.com Sun Feb 8 12:03:46 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Sun Feb 8 11:53:38 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> Message-ID: On Sun, Feb 8, 2009 at 8:57 AM, Gwern Branwen wrote: > We should limit voting, and limit based on IP. If we go via email, > then anyone wishing extra votes merely needs to use mailinator.com > (and its dozens of alternate domain names, to say nothing of > competitors providing similar services) to vote as many times as they > want. If we care about fraud, then it would be a very troublesome task > to filter out all those ways to fraudulently vote; if we don't care > about fraud, then email confirms are just a burden on honest users. I don't know about other people, but for me it takes less time to change IP addresses than to sign up for a mail account. dhclient -r dsl0 && dhclient dsl0 vs. fill in a form on a webpage. --Max From gwern0 at gmail.com Sun Feb 8 12:10:35 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Feb 8 12:00:28 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> Message-ID: On Sun, Feb 8, 2009 at 12:03 PM, Max Rabkin wrote: > On Sun, Feb 8, 2009 at 8:57 AM, Gwern Branwen wrote: >> We should limit voting, and limit based on IP. If we go via email, >> then anyone wishing extra votes merely needs to use mailinator.com >> (and its dozens of alternate domain names, to say nothing of >> competitors providing similar services) to vote as many times as they >> want. If we care about fraud, then it would be a very troublesome task >> to filter out all those ways to fraudulently vote; if we don't care >> about fraud, then email confirms are just a burden on honest users. > > I don't know about other people, but for me it takes less time to > change IP addresses than to sign up for a mail account. > > dhclient -r dsl0 && dhclient dsl0 > > vs. fill in a form on a webpage. > > --Max You don't sign up for a Mailinator account. That's the whole point. Take a look at https://secure.wikimedia.org/wikipedia/en/wiki/Mailinator -- gwern From noteed at gmail.com Sun Feb 8 12:29:32 2009 From: noteed at gmail.com (minh thu) Date: Sun Feb 8 12:19:24 2009 Subject: [Haskell-cafe] how to link statically with a c lib ? In-Reply-To: <20090208164921.GB29860@whirlpool.galois.com> References: <40a414c20902080450i55bfec0aj7f6259edb99293ce@mail.gmail.com> <20090208164921.GB29860@whirlpool.galois.com> Message-ID: <40a414c20902080929x28d86be7j6d5c6759736b10f4@mail.gmail.com> 2009/2/8 Don Stewart : > noteed: >> Hi, >> >> I'm writing bindings for the Tiny C Compiler. >> It seems that tcc provide a libtcc.a but no libtcc.so. >> >> In my cabal file, I have >> >> extra-libraries: dl, tcc >> >> but when using the generated haskell module, >> I have the following message : >> >> ?thu@jones samples? ghc -e "main" Test.hs >> : : can't load .so/.DLL for: tcc >> (libtcc.so: cannot open shared object file: No such file or directory) >> >> How can I generate a module linked statically against libtcc ? > > Without a .so you can't load it in ghci, but you can compile it with ghc. > > ghc --make Test.hs Ok but what should be written in the cabal file ? I build a .so of libtcc so it works for now. Before I put it on hackage, maybe I can get a review of it, if anything is fundamentaly wrong ? It is located at http://github.com/noteed/tcc/tree/master Thanks ! Thu From dons at galois.com Sun Feb 8 12:29:33 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 8 12:20:04 2009 Subject: [Haskell-cafe] how to link statically with a c lib ? In-Reply-To: <40a414c20902080929x28d86be7j6d5c6759736b10f4@mail.gmail.com> References: <40a414c20902080450i55bfec0aj7f6259edb99293ce@mail.gmail.com> <20090208164921.GB29860@whirlpool.galois.com> <40a414c20902080929x28d86be7j6d5c6759736b10f4@mail.gmail.com> Message-ID: <20090208172933.GE29860@whirlpool.galois.com> noteed: > 2009/2/8 Don Stewart : > > noteed: > >> Hi, > >> > >> I'm writing bindings for the Tiny C Compiler. > >> It seems that tcc provide a libtcc.a but no libtcc.so. > >> > >> In my cabal file, I have > >> > >> extra-libraries: dl, tcc > >> > >> but when using the generated haskell module, > >> I have the following message : > >> > >> ?thu@jones samples? ghc -e "main" Test.hs > >> : : can't load .so/.DLL for: tcc > >> (libtcc.so: cannot open shared object file: No such file or directory) > >> > >> How can I generate a module linked statically against libtcc ? > > > > Without a .so you can't load it in ghci, but you can compile it with ghc. > > > > ghc --make Test.hs > > Ok but what should be written in the cabal file ? > > I build a .so of libtcc so it works for now. > > Before I put it on hackage, maybe I can get a review of it, if > anything is fundamentaly wrong ? > It is located at http://github.com/noteed/tcc/tree/master In the .cabal file should only be: extra-libraries: tcc I think. From noteed at gmail.com Sun Feb 8 12:42:55 2009 From: noteed at gmail.com (minh thu) Date: Sun Feb 8 12:32:46 2009 Subject: [Haskell-cafe] how to link statically with a c lib ? In-Reply-To: <20090208172933.GE29860@whirlpool.galois.com> References: <40a414c20902080450i55bfec0aj7f6259edb99293ce@mail.gmail.com> <20090208164921.GB29860@whirlpool.galois.com> <40a414c20902080929x28d86be7j6d5c6759736b10f4@mail.gmail.com> <20090208172933.GE29860@whirlpool.galois.com> Message-ID: <40a414c20902080942h59e9c5pedf9bd1d35d10088@mail.gmail.com> 2009/2/8 Don Stewart : > noteed: >> 2009/2/8 Don Stewart : >> > noteed: >> >> Hi, >> >> >> >> I'm writing bindings for the Tiny C Compiler. >> >> It seems that tcc provide a libtcc.a but no libtcc.so. >> >> >> >> In my cabal file, I have >> >> >> >> extra-libraries: dl, tcc >> >> >> >> but when using the generated haskell module, >> >> I have the following message : >> >> >> >> ?thu@jones samples? ghc -e "main" Test.hs >> >> : : can't load .so/.DLL for: tcc >> >> (libtcc.so: cannot open shared object file: No such file or directory) >> >> >> >> How can I generate a module linked statically against libtcc ? >> > >> > Without a .so you can't load it in ghci, but you can compile it with ghc. >> > >> > ghc --make Test.hs >> >> Ok but what should be written in the cabal file ? >> >> I build a .so of libtcc so it works for now. >> >> Before I put it on hackage, maybe I can get a review of it, if >> anything is fundamentaly wrong ? >> It is located at http://github.com/noteed/tcc/tree/master > > In the .cabal file should only be: > > extra-libraries: tcc > > I think. > Oh I misunderstood : I thought it was the build process which was flawed, not the way ghc or ghci would handle the library. Thank you, Thu From sanzhiyan at gmail.com Sun Feb 8 13:18:37 2009 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Sun Feb 8 13:08:30 2009 Subject: [Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <1233959225.26754.713.camel@localhost> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <79d7c4980902060235x5eb42955p196dfe68707daab0@mail.gmail.com> <1233959225.26754.713.camel@localhost> Message-ID: <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> I did work on this and i simplified the code a lot fixing inconsistencies and making more explicit what how each component contributes to the arguments to haddock. Aside from this, should we also do the unliting and cpp from Cabal on the sources passed to HsColour? On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts wrote: > On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote: >> 2009/2/6 Alistair Bayley : >> >>> [1 of 1] Compiling Test.Fail ( Test\Fail.hs, Test\Fail.o ) >> >>> >> >>> Test\Fail.hs:11:26: >> >>> Can't make a derived instance of `Typeable Fail' >> >>> (You need -XDeriveDataTypeable to derive an instance for this class) >> >>> In the data type declaration for `Fail' >> >> >> >> Are you processing the above module but it is called Test.Fail in >> >> reality? Have you stripped out a deriving statement from the example >> >> above? I'm very confused by this message :) >> > >> > >> > Sorry, my mistake. I pasted the error message from a different >> > problem. This is the error I get from haddock: >> > >> > C:\bayleya\eclipse\workspace\takusen\src>haddock -h --odir=doc Test/Haddock.lhs >> > Cannot find documentation for: $named_block >> >> Okay, then I understand. >> >> My guess is (without looking at ghc code) that ghc just throws the >> literate comments away before lexing the file. This means that the >> Haddock comments won't be recognized. >> >> As you say, there is also an unlitter in Cabal. I don't remember if it >> is invoked when using Haddock 2, but if it is, it would solve this >> problem. > > Yes, against my better judgement the code in Cabal for haddock-2.x does > not run cpp or unliting like it does for haddock-0.x. Instead it assumes > that haddock-2.x will do all the cpp and unliting itself. Obviously this > mean the special unliting mode that Cabal provides is not usable with > haddock-2.x. > > The solution is to do the pre-processing the same for haddock-0.x and > 2.x. Generally the haddock code in Cabal is a horrible inconsistent > mess. I believe Andrea Vezzosi has been looking at rewriting it, which > is good news. > > Duncan > > From aslatter at gmail.com Sun Feb 8 15:46:06 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 8 15:35:57 2009 Subject: [Haskell-cafe] ANNOUNCE: X Haskell Bindings 0.1 Message-ID: <694519c50902081246i5cb82191mf0ba2cf16ea4ceb0@mail.gmail.com> I'd like to announce a version bump for the X Haskell Bindings (XHB) library, to 0.1.* from 0.0.*. The goal of XHB is to provide a Haskell implementation of the X11 wire protocol, similar in spirit to the X protocol C-language Binding (XCB). On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb This release focuses on making the API a bit friendlier: + 'type BOOL = Word8' has been replaced in the API by Prelude.Bool + type synonyms BYTE, CARD8, CARD16 and CARD32 for the Data.Word types have been eliminated + type synonyms INT8, INT16 and INT32 for the Data.Int types have been eliminated + Previously, all protocol replies were represented by their own distinct data type. Now, if the reply to a request only includes a single field, the request returns that field directly. In more concrete terms: > internAtom :: Connection -> InternAtom -> IO (Receipt InternAtomReply) becomes: > internAtom :: Connection -> InternAtom -> IO (Receipt ATOM) Further work to make the API more "Haskelly" is ongoing. Related projects: X C Bindings: http://xcb.freedesktop.org/ -Antoine From dons at galois.com Sun Feb 8 15:47:10 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 8 15:37:39 2009 Subject: [Haskell-cafe] ANNOUNCE: X Haskell Bindings 0.1 In-Reply-To: <694519c50902081246i5cb82191mf0ba2cf16ea4ceb0@mail.gmail.com> References: <694519c50902081246i5cb82191mf0ba2cf16ea4ceb0@mail.gmail.com> Message-ID: <20090208204710.GV29860@whirlpool.galois.com> aslatter: > I'd like to announce a version bump for the X Haskell Bindings (XHB) > library, to 0.1.* from 0.0.*. > > The goal of XHB is to provide a Haskell implementation of the X11 wire > protocol, similar in spirit to the X protocol C-language Binding > (XCB). > > On Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xhb > > This release focuses on making the API a bit friendlier: > > + 'type BOOL = Word8' has been replaced in the API by Prelude.Bool > > + type synonyms BYTE, CARD8, CARD16 and CARD32 for the Data.Word > types have been eliminated > > + type synonyms INT8, INT16 and INT32 for the Data.Int types have > been eliminated > > + Previously, all protocol replies were represented by their own > distinct data type. Now, if the reply to a request only includes a > single field, the request returns that field directly. > > In more concrete terms: > > > internAtom :: Connection -> InternAtom -> IO (Receipt InternAtomReply) > > becomes: > > > internAtom :: Connection -> InternAtom -> IO (Receipt ATOM) > > Further work to make the API more "Haskelly" is ongoing. > > Related projects: > > X C Bindings: http://xcb.freedesktop.org/ Well done! Have a distro package, http://aur.archlinux.org/packages.php?ID=23765 -- Don From aslatter at gmail.com Sun Feb 8 15:57:39 2009 From: aslatter at gmail.com (Antoine Latter) Date: Sun Feb 8 15:47:30 2009 Subject: [Haskell-cafe] Re: ANNOUNCE: X Haskell Bindings 0.1 In-Reply-To: <694519c50902081246i5cb82191mf0ba2cf16ea4ceb0@mail.gmail.com> References: <694519c50902081246i5cb82191mf0ba2cf16ea4ceb0@mail.gmail.com> Message-ID: <694519c50902081257x4978c205o83b9d208687f02c0@mail.gmail.com> On Sun, Feb 8, 2009 at 2:46 PM, Antoine Latter wrote: > I'd like to announce a version bump for the X Haskell Bindings (XHB) > library, to 0.1.* from 0.0.*. > > The goal of XHB is to provide a Haskell implementation of the X11 wire > protocol, similar in spirit to the X protocol C-language Binding > (XCB). > On a related note, I don't think I've ever formally announce my xcb-types library: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xcb-types The goal of this project is to provide a parser for the X11 Protocol descriptions used by the XCB project. This is probably a bit specialized of a library, so I doubt I'll be announcing future releases as widely. The XML files that this is built to parse are available at: http://xcb.freedesktop.org/dist/ in the xcb-proto-X.X.tar.gz files. This library is among those required to build the source distribution for the XHB library. -Antoine From ok at cs.otago.ac.nz Sun Feb 8 19:25:30 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Sun Feb 8 19:15:26 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: On 6 Feb 2009, at 4:20 am, Gregg Reynolds wrote: > However, consider: > > getChar >>= \x -> getChar > > An optimizer can see that the result of the first getChar is > discarded and replace the entire expression with one getChar without > changing the formal semantics. But the result of the first getChar is *NOT* discarded. **As an analogy**, think of the type IO t as (World -> (t,World)) for some hidden type World, and getChar w = (c, w') -- get a character c out of world w somehow, -- changing w to w' as you go (f >>= g) w = let (v,w') = f w in (g v) w' In this analogy, you see that the result of getChar is a value of type IO Char (not of type Char), and that while the character part of the result of performing the result of getChar may be discarded, the "changed world" part is NOT. From duncan.coutts at worc.ox.ac.uk Sun Feb 8 19:33:44 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 8 19:23:55 2009 Subject: [Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input In-Reply-To: <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> References: <79d7c4980902060124o728967d1v149df465ac182b47@mail.gmail.com> <79d7c4980902060235x5eb42955p196dfe68707daab0@mail.gmail.com> <1233959225.26754.713.camel@localhost> <8625cd9c0902081018t7103283ctdf94f249db1b0860@mail.gmail.com> Message-ID: <1234139624.5238.128.camel@localhost> On Sun, 2009-02-08 at 19:18 +0100, Andrea Vezzosi wrote: > I did work on this and i simplified the code a lot fixing > inconsistencies and making more explicit what how each component > contributes to the arguments to haddock. Much appreciated. > Aside from this, should we also do the unliting and cpp from Cabal on > the sources passed to HsColour? Hmm. I thought it did already :-) Well, I know it runs happy, hsc2hs etc. Someone was complaining the other day that the hscolour output run on the result of happy is not really readable, but then it's not clear if running it on the happy input would be any better. For the particular case of .lhs and cpp, I hope we'd get better hscolour output by not running unlit or cpp first. Malcolm says it'll at least do something. So it seems worth checking which ends up looking more useful. Duncan > On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts > > Yes, against my better judgement the code in Cabal for haddock-2.x does > > not run cpp or unliting like it does for haddock-0.x. Instead it assumes > > that haddock-2.x will do all the cpp and unliting itself. Obviously this > > mean the special unliting mode that Cabal provides is not usable with > > haddock-2.x. > > > > The solution is to do the pre-processing the same for haddock-0.x and > > 2.x. Generally the haddock code in Cabal is a horrible inconsistent > > mess. I believe Andrea Vezzosi has been looking at rewriting it, which > > is good news. From ok at cs.otago.ac.nz Sun Feb 8 19:39:00 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Sun Feb 8 19:28:52 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> Message-ID: On 6 Feb 2009, at 5:08 am, Gregg Reynolds wrote: > Not "programs", but "programs that do IO". The point of the idiom > is that there's an external side effect involved. What sticks in my > craw is that "a mathematical value with a non-mathematical side > effect" is, well, non-mathematical and possibly nonsensical. I was introduced to group theory by being shown a real physical cube (a child's building block) and the real physical actions of turning a cube around in physical space that left it looking like the same cube in the same place. These physical actions are the elements of a group because the action "don't do anything" is the identity the combination rule "do X then do Y" is multiplication for every action there is an obvious "undo" (or inverse) action Take away the cube and the group remains: the elements of the group are (representable as) mathematical objects and you can operate on those mathematical objects to your heart's content. Of course nothing actually happens in the real world until you get a real cube and start following the instructions. The analogy: Members of the symmetry group on a cube : IO actions :: an actual real world : the IO state of a program :: someone following the turning orders : a Haskell system is a good one. If you want to say that "a mathematical value with a non-mathematical effect" is nonsensical, more power to you. I said I don't want to get far into White Knight territory. As long as you can agree "A mathematical value INTERPRETED BY a physical engine can have physical effects", we're home and dry. Let's face it, the idea of a Haskell program having physical effects (despite being a mathematical object) is no more (and no less) "non-mathematical and possibly nonsensical" than the idea of a C program (which is just a character string) having such effects, and no more (and no less) "non-mathematical and possibly nonsensical" than the idea of a machine code program (which is just a sequence of bits) having such effects. In all these cases, the program *is* a perfectly good mathematical value, just as good as the number 1, and arguably better than the number pi, and can be manipulated as an mathematical value, even computed as the result of a mathematical process. In all these cases, the program cannot and will not have any effects in the world whatsoever until it is combined with a physical program-interpreting device. Rem > I know it works for some (most?) people, but for me it lacks > Geometry and Theology. > > -g > From s.clover at gmail.com Sun Feb 8 19:41:21 2009 From: s.clover at gmail.com (Sterling Clover) Date: Sun Feb 8 19:31:18 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> Message-ID: <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> IP based limitations are a terrible idea. Multiple users can be and often are behind the same IP if they're in some sort of intranet, be it corporate, academic, or simply multiple home computers. Mail-based authentication can be screwed with, sure, but it's also very easy to notice this (as opposed to ip nonsense) through simply eyeballing the results. There's no general everywhere way to prevent vote fraud. However, if we make it even require a mild bit of thought, that should be sufficient in this case, as there won't be enough votes to prevent some sort of rough eyeball-based check of the results, and if there are, then that's a sign of fraud for sure! Furthermore, there's very little incentive for someone to go the extra mile here, as we're voting for a haskell logo, and not, e.g., giving away ten thousand dollars. Furthermore, since I assume we'll only be presenting reasonable logos, there's not even some room for pranksters to stage a "write-in" of some gag slogan. Cheers, Sterl. On Feb 8, 2009, at 12:10 PM, Gwern Branwen wrote: > On Sun, Feb 8, 2009 at 12:03 PM, Max Rabkin > wrote: >> On Sun, Feb 8, 2009 at 8:57 AM, Gwern Branwen >> wrote: >>> We should limit voting, and limit based on IP. If we go via email, >>> then anyone wishing extra votes merely needs to use mailinator.com >>> (and its dozens of alternate domain names, to say nothing of >>> competitors providing similar services) to vote as many times as >>> they >>> want. If we care about fraud, then it would be a very troublesome >>> task >>> to filter out all those ways to fraudulently vote; if we don't care >>> about fraud, then email confirms are just a burden on honest users. >> >> I don't know about other people, but for me it takes less time to >> change IP addresses than to sign up for a mail account. >> >> dhclient -r dsl0 && dhclient dsl0 >> >> vs. fill in a form on a webpage. >> >> --Max > > You don't sign up for a Mailinator account. That's the whole point. > Take a look at https://secure.wikimedia.org/wikipedia/en/wiki/ > Mailinator > > -- > gwern > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dons at galois.com Sun Feb 8 19:44:36 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 8 19:35:03 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> Message-ID: <20090209004436.GB29860@whirlpool.galois.com> s.clover: > IP based limitations are a terrible idea. Multiple users can be and > often are behind the same IP if they're in some sort of intranet, be it > corporate, academic, or simply multiple home computers. Mail-based > authentication can be screwed with, sure, but it's also very easy to > notice this (as opposed to ip nonsense) through simply eyeballing the > results. There's no general everywhere way to prevent vote fraud. > However, if we make it even require a mild bit of thought, that should be > sufficient in this case, as there won't be enough votes to prevent some > sort of rough eyeball-based check of the results, and if there are, then > that's a sign of fraud for sure! Furthermore, there's very little > incentive for someone to go the extra mile here, as we're voting for a > haskell logo, and not, e.g., giving away ten thousand dollars. Exactly. Let's not wander down to the bikeshed :) > Furthermore, since I assume we'll only be presenting reasonable logos, > there's not even some room for pranksters to stage a "write-in" of some > gag slogan. Right, only a subset of previously submitted ones. -- Don From gwern0 at gmail.com Sun Feb 8 20:11:51 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Sun Feb 8 20:01:42 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090209004436.GB29860@whirlpool.galois.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> <20090209004436.GB29860@whirlpool.galois.com> Message-ID: On Sun, Feb 8, 2009 at 7:44 PM, Don Stewart wrote: > s.clover: >> IP based limitations are a terrible idea. Multiple users can be and >> often are behind the same IP if they're in some sort of intranet, be it >> corporate, academic, or simply multiple home computers. Mail-based >> authentication can be screwed with, sure, but it's also very easy to >> notice this (as opposed to ip nonsense) through simply eyeballing the >> results. There's no general everywhere way to prevent vote fraud. >> However, if we make it even require a mild bit of thought, that should be >> sufficient in this case, as there won't be enough votes to prevent some >> sort of rough eyeball-based check of the results, and if there are, then >> that's a sign of fraud for sure! Furthermore, there's very little >> incentive for someone to go the extra mile here, as we're voting for a >> haskell logo, and not, e.g., giving away ten thousand dollars. > > Exactly. Let's not wander down to the bikeshed :) > >> Furthermore, since I assume we'll only be presenting reasonable logos, >> there's not even some room for pranksters to stage a "write-in" of some >> gag slogan. > > Right, only a subset of previously submitted ones. > > -- Don So.... does this mean no 'haskell YEEAAAAHH!'? -- gwern From dons at galois.com Sun Feb 8 20:13:55 2009 From: dons at galois.com (Don Stewart) Date: Sun Feb 8 20:04:21 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: References: <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> <20090209004436.GB29860@whirlpool.galois.com> Message-ID: <20090209011355.GC29860@whirlpool.galois.com> > >> Furthermore, since I assume we'll only be presenting reasonable logos, > >> there's not even some room for pranksters to stage a "write-in" of some > >> gag slogan. > > > > Right, only a subset of previously submitted ones. > > > > -- Don > > So.... does this mean no 'haskell YEEAAAAHH!'? Isn't that already the underground official logo? http://www.facebook.com/pages/Haskell/56088385002 -- Don From lists at qseep.net Sun Feb 8 20:21:39 2009 From: lists at qseep.net (Lyle Kopnicky) Date: Sun Feb 8 20:11:31 2009 Subject: [Haskell-cafe] GHC 6.11 missing time package? In-Reply-To: <220e47b40902010238y22d9d410wc047b20e4fdeedef@mail.gmail.com> References: <670e468e0901311954g554fb91eua74f1fcc44de367c@mail.gmail.com> <694519c50901312213i1dd09651m7955b711a061c7f1@mail.gmail.com> <670e468e0902010106ted207a9j7dd0f199ae639bbd@mail.gmail.com> <220e47b40902010238y22d9d410wc047b20e4fdeedef@mail.gmail.com> Message-ID: <670e468e0902081721ifa1f677k15ddc566b42cdad1@mail.gmail.com> OK, I was able to get it to build. I just had to install MinGW and put its bin directory in my path. Thanks for the help! (Actually, I ended up building time-1.1.2.3 for 6.10.1.20090110.) On Sun, Feb 1, 2009 at 2:38 AM, Krzysztof Skrz?tnicki wrote: > It looks that you need MSYS or Cygwin to complete this build. Here you can > find instructions regarding MSYS (and also GLUT, but you can ignore that > part): > http://www.haskell.org/pipermail/haskell-cafe/2007-September/031535.html > > All best > > Christopher Skrz?tnicki > > 2009/2/1 Lyle Kopnicky > >> I tried building it from hackage. I got an error: >> Setup.hs: sh: createProcess: does not exist (No such file or >> directory) >> >> ...which is very similar to the error I get if I try to build it using >> 6.10: >> >> Setup.hs: sh: runGenProcess: does not exist (No such file or >> directory) >> >> I don't know if there's something wrong with the package, or I don't have >> something set up right to build it on Windows. >> >> On Sat, Jan 31, 2009 at 10:13 PM, Antoine Latter wrote: >> >>> 2009/1/31 Lyle Kopnicky : >>> > Hi folks, >>> > I'm getting ready to release a piece of software. Unfortunately due to >>> a bug >>> > in GHC 6.10 on Windows it does not handle Ctrl+C properly. Since the >>> bug has >>> > been fixed (thank you Simon Marlow), I figured I'd download a 6.11 >>> build (I >>> > grabbed the 2009-01-29 version). >>> > Unfortunately, my project won't build with it because it's missing the >>> > time-1.1 package. This is sad because I had gone through the trouble to >>> > rewrite my use of oldtime to use time, thinking it was more >>> future-proof. Is >>> > this an oversight in the nightly build, or is this package going out of >>> GHC? >>> > Thanks, >>> > Lyle >>> >>> Hackage seems to have it: >>> >>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/time >>> >>> Does that work? >>> >>> -Antoine >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090208/b1d4aa7b/attachment.htm From haskell at datakids.org Mon Feb 9 00:21:15 2009 From: haskell at datakids.org (Jamie) Date: Mon Feb 9 00:11:06 2009 Subject: [Haskell-cafe] Video phone application Message-ID: Hello! I like to create H.323 (primarly) & SIP based video phone application that will run on Linux, Windows & Mac platforms and of course, written in Haskell. (Writing similar application in Haskell is not "reinventing the wheel" :) I did look/try various current H.323/SIP based video phone software that runs on Windows, Mac and Linux such as Ekiga, XMeeting, Linphone, Mirial and some others. Ekiga (despite version 3.x) is unstable, keeps crashing a lot on me. XMeeting (Mac) does not work good (choppy videos, dropped packets et al). So do Linphone. The best of the lot so far is Mirial Softphone, it has nice decent features to begin with, but there are lot more features I want to add. Please let me know if there is good H.323 based videophone software that I might miss (I think I have looked at all of them). Since my video phone application mainly focus more on deaf people thus strong emphasize on video part while all other (if not all) video softphone put stronger emphasize on audio part & traditional phone setup. Also it has to be primarly H.323 because I would say about over 95% or so of all deaf people (with high speed Internet access) use Sorenson VP-200 as their "main" videophone (Sorenson gives away VP-200 video phone device for free to all deaf people in USA in exchange for using Sorenson Video Relay Service which they make profit from). Sorenson VP-200 only supports H.323, H.263 video codec and G.711/G.723.1 audio codec. Being able to work with VP-200 well is this application's first step. Skype, ooVoo, SightSpeed, QuteCom, VZOchat, iChat AV and some others are excellent video phone/chat applications but they are not H.323 complaint so they are "out of question". It would take me a lot of time (more like forever) if I have to write my own H.323 protocol stack along with video/audio codecs as well the GUI in Haskell. So in order to write this application in timely manner (say one year from now or so) I will need external library/functions for H.323/SIP protocol stack, the audio/video codecs and the GUI. I have been contacting serveral companies that offer licensing of their H.323/SIP/codecs SDK/API/Libraries for my program to be able to access to those functions. Naturally all of them ues C/C++. Yes there are some free/open source ones such as h323plus.org, x264, ffmpeg and some others, but still all of them are written in C/C++. I think I am more likely to go for commercial libraries due to stability (least bugs), higher performance, better documentation and whole set of supported features. What do I ask to make sure those libraries/SDK would work well with Haskell? As for GUI, since I would like for this application to run on three popular platforms: Windows, Mac and Linux, so I think I would have to use Gtk+, wxWidgets or Qt which mean I would use Gtk2Hs, wxHaskell or qtHaskell. Even nicer is to use FRP GUI library such as Fruit, Grapefruit, wxFruit, et al. This application would need to support localization i.e. support different languages. What do you suggest for me to use one of middle level GUI library or even the higher level FRP GUI library (with localization support)? Fast and smooth video (i.e. 30 FPS) is the key for this application. As it stands now, looks like I'll write the "main program" entirely in Haskell, then use some kind of bindings to call to those C/C++ libraries for H.323, SIP, codecs, webcam/video camera I/O, video display, GUI et al. Any better ideas for doing this? I know it would be dream come true to see acclerated vector/raster based drawing primitives with FRP GUI on top written entirely in Haskell along with H.323, codecs et al being written in Haskell too (we may have to wait quite while for that), but we live in real world so I will have to learn to deal with what we have now and the workarounds. Thanks in advance! Jamie From jupdike at gmail.com Mon Feb 9 01:57:23 2009 From: jupdike at gmail.com (Jared Updike) Date: Mon Feb 9 01:47:17 2009 Subject: [Haskell-cafe] Data.Map: Enumerating ordered subset of keys Message-ID: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> I would like to enumerate a subset of keys in a Map satisfying \ key >= key1 && key <= key2 but in the expected, reasonable amount of time (e.g. < O(log(n)) + O(m) for n total keys and m keys in the subset). (Or key > key1 and/or key < key2 or some such combination). Is there an appropriate idiom or combination of library functions to accomplish this, short of digging into the code for Data.Map and writing such a function for a forked version of Data.Map? For example I could try something like a Set.split of a Set.split of Map.keysSet of my original map, but will laziness magically do what I really want? which is to walk down the tree to key1 (or the nearest key > key1) and enumerate keys in order until key2 is reached? Data.Map almost looks like what I need if I can do this. Jared. From jupdike at gmail.com Mon Feb 9 02:02:37 2009 From: jupdike at gmail.com (Jared Updike) Date: Mon Feb 9 01:52:27 2009 Subject: [Haskell-cafe] Re: Data.Map: Enumerating ordered subset of keys In-Reply-To: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> References: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> Message-ID: <8b108f950902082302o341c4376wca32c591aace7d1c@mail.gmail.com> It looks like two "Map.split"s will do what I need except for allowing more exact testing of <= vs. < (since == elements are left out of both maps...?) Jared. On 2/8/09, Jared Updike wrote: > I would like to enumerate a subset of keys in a Map satisfying \ key > >= key1 && key <= key2 but in the expected, reasonable amount of time > (e.g. < O(log(n)) + O(m) for n total keys and m keys in the subset). > (Or key > key1 and/or key < key2 or some such combination). > > Is there an appropriate idiom or combination of library functions to > accomplish this, short of digging into the code for Data.Map and > writing such a function for a forked version of Data.Map? > > For example I could try something like a Set.split of a Set.split of > Map.keysSet of my original map, but will laziness magically do what I > really want? which is to walk down the tree to key1 (or the nearest > key > key1) and enumerate keys in order until key2 is reached? > > Data.Map almost looks like what I need if I can do this. > > > Jared. > From haskell at datakids.org Mon Feb 9 02:06:31 2009 From: haskell at datakids.org (Jamie) Date: Mon Feb 9 01:56:47 2009 Subject: [Haskell-cafe] Video phone application In-Reply-To: References: Message-ID: About the GUI, since I would like to run this video phone application on set-top box (Linux based) in the future (i.e. do video chatting via on big screen TV using set-top box via HDMI interface) so the interface/GUI would look like "appliance-like" interface rather than standard windowing interface like Qt, wxWidgets & Gtk+. Good example is Mirial Softphone which seems to use OpenGL/Direct3D for user interface with it's own simple custom written widgets (i.e. contact list, call history) on top of OpenGL/Direct3D. The only part of Mirial Softphone that use standard Windows window and it's standard widgets is the "Configurations" window. In my case, I would use one of windowing library (Qt, wx, Gtk) for that window. So I think I should go this route by using OpenGL directly (nice that OpenGL is supported in all three platforms (using Mesa 3D library?) So it will be some extra work to write some custom GUI widgets on top of OpenGL (maybe someone has written some of them?) Any better way of doing this? Since I would want this video phone application to have "unlimited" (as much as network bandwidth, memory, CPU load allows) "lines" (like the two line phone with "A and "B" buttons), should this Haskell program run other copy of itself, or should it spwan/run other thread? For example, someone do video chat call and I answer it, then someone else also call and I answer that one and I would be talking with two (or more) people at the same time using shared webcam input and shared network connection. What is ideal way to deal with this in Haskell? Thanks! Jamie From anishmuttreja at gmail.com Mon Feb 9 02:07:22 2009 From: anishmuttreja at gmail.com (Anish Muttreja) Date: Mon Feb 9 01:57:15 2009 Subject: [Haskell-cafe] Re: Data.Map: Enumerating ordered subset of keys In-Reply-To: <8b108f950902082302o341c4376wca32c591aace7d1c@mail.gmail.com> References: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> <8b108f950902082302o341c4376wca32c591aace7d1c@mail.gmail.com> Message-ID: Maybe you want Data.Map.partition (\key -> key >= key1 && key <= key2) map HTH, Anish On Sun, 08 Feb 2009 23:02:37 -0800, Jared Updike wrote: > It looks like two "Map.split"s will do what I need except for allowing > more exact testing of <= vs. < (since == elements are left out of both > maps...?) > > Jared. > > On 2/8/09, Jared Updike wrote: >> I would like to enumerate a subset of keys in a Map satisfying \ key >> >= key1 && key <= key2 but in the expected, reasonable amount of time >> (e.g. < O(log(n)) + O(m) for n total keys and m keys in the subset). >> (Or key > key1 and/or key < key2 or some such combination). >> >> Is there an appropriate idiom or combination of library functions to >> accomplish this, short of digging into the code for Data.Map and >> writing such a function for a forked version of Data.Map? >> >> For example I could try something like a Set.split of a Set.split of >> Map.keysSet of my original map, but will laziness magically do what I >> really want? which is to walk down the tree to key1 (or the nearest >> key > key1) and enumerate keys in order until key2 is reached? >> >> Data.Map almost looks like what I need if I can do this. >> >> >> Jared. >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From svein.ove at aas.no Mon Feb 9 02:31:29 2009 From: svein.ove at aas.no (Svein Ove Aas) Date: Mon Feb 9 02:21:18 2009 Subject: [Haskell-cafe] Re: Data.Map: Enumerating ordered subset of keys In-Reply-To: <8b108f950902082302o341c4376wca32c591aace7d1c@mail.gmail.com> References: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> <8b108f950902082302o341c4376wca32c591aace7d1c@mail.gmail.com> Message-ID: <221b53ab0902082331xf2daad1r768782a65cb6e96a@mail.gmail.com> On Mon, Feb 9, 2009 at 8:02 AM, Jared Updike wrote: > It looks like two "Map.split"s will do what I need except for allowing > more exact testing of <= vs. < (since == elements are left out of both > maps...?) > If your key is an instance of Enum, you can use succ/pred to work around that little problem. From qdunkan at gmail.com Mon Feb 9 02:57:55 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Mon Feb 9 02:47:46 2009 Subject: [Haskell-cafe] Data.Map: Enumerating ordered subset of keys In-Reply-To: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> References: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> Message-ID: <2518b95d0902082357w1b32d770u4de4d20f571629f3@mail.gmail.com> On Mon, Feb 9, 2009 at 2:57 PM, Jared Updike wrote: > I would like to enumerate a subset of keys in a Map satisfying \ key >>= key1 && key <= key2 but in the expected, reasonable amount of time > (e.g. < O(log(n)) + O(m) for n total keys and m keys in the subset). > (Or key > key1 and/or key < key2 or some such combination). > > Is there an appropriate idiom or combination of library functions to > accomplish this, short of digging into the code for Data.Map and > writing such a function for a forked version of Data.Map? I have a little util library with various map functions. 'within' is almost what you want, except it's half-open. You can make an inclusive one by pulling the lowest element off the above map. I'm also curious if there's a better way to do this... -- | Like Map.split, except include a matched key in the above map. split_map :: (Ord k) => k -> Map.Map k a -> (Map.Map k a, Map.Map k a) split_map k fm = (pre, post') where (pre, at, post) = Map.splitLookup k fm post' = maybe post (\v -> Map.insert k v post) at -- | Split the map into the maps below, within, and above the given range. -- @low@ to @high@ is half-open, as usual. split3_map :: (Ord k) => k -> k -> Map.Map k a -> (Map.Map k a, Map.Map k a, Map.Map k a) split3_map low high fm = (below, within, way_above) where (below, above) = split_map low fm (within, way_above) = split_map high above within low high fm = let (_, m, _) = split3_map low high fm in m From dev at mobileink.com Mon Feb 9 03:56:50 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 03:46:40 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> Message-ID: <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> On Sun, Feb 8, 2009 at 6:39 PM, Richard O'Keefe wrote: > > is a good one. If you want to say that "a mathematical value with > a non-mathematical effect" is nonsensical, more power to you. I said > I don't want to get far into White Knight territory. As long as you > can agree "A mathematical value INTERPRETED BY a physical engine can > have physical effects", we're home and dry. > Here's an analogy that will make the logical contradiction clear. Forget computers and assume you have been asked to referee a paper containing a proof with the following passage: Let x = ___ (Please fill in the blank) I think you will agree that would be plainly nonsensical. It's logically equivalent to an input operation ("getInt"). Now back to computers. Given a program text containing the symbol '3', the computer will provide a physical representation: an electromagnetic pattern in a bit of silicon. That's a value; the pattern is to be interpreted as a datum; it is not to be executed. For "getChar", the computer will also provide such a pattern, but this pattern is to be interpreted as executable code, not as a datum. Now suppose we also have an ordinary function like "Add2"; it too will be represented as an electromagnetic pattern, to be interpreted as executable code. getChar and Add2 are not data, except in the trivial sense that all code is data. All three "have an effect" only in the trivial sense that they are physically represented. In all three cases, the symbolic representation is isomorphic to the physical representation. The 3 will not be executed. When Add2 is executed, the ensuing process is isomorphic to the mathematical function so defined. But when getChar is executed, the ensuing process is not isomorphic to a mathematical function. The process interacts with the non-mathematical world, which a mathematical function can never do. So it has a side effect along with its ordinary representational effect. The point being that the metalanguage commonly used to describe IO in Haskell contains a logical contradiction. A thing cannot be both a value and a function, but e,g, getChar behaves like a function and has the type signature of a value. I believe this is part of the reason the IO monad is troublesome for beginners (I speak from experience). -g -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/57353b3d/attachment.htm From tmorris at tmorris.net Mon Feb 9 04:26:52 2009 From: tmorris at tmorris.net (Tony Morris) Date: Mon Feb 9 04:16:48 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> Message-ID: <498FF6DC.9020909@tmorris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gregg Reynolds wrote: > The point being that the metalanguage commonly used to describe IO > in Haskell contains a logical contradiction. A thing cannot be both > a value and a function, but e,g, getChar behaves like a function and > has the type signature of a value. getChar has the signature RealWorld -> (RealWorld, Char) - -- Tony Morris http://tmorris.net/ ********************************************************* * Anteromedial Heterotopic Osseous Impingement Syndrome * ********************************************************* http://www.ajronline.org/cgi/content/full/178/3/601 "can result in chronic ankle pain, especially in athletes and the younger population (15-40 years old)" http://radiographics.rsnajnls.org/cgi/content/figsonly/22/6/1457 "Soft-tissue and osseous impingement syndromes of the ankle can be an important cause of chronic pain, particularly in the professional athlete." -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJj/bcmnpgrYe6r60RAicqAJ9z3f+aM/k+gDv8d5yAaNSCFf9NVQCfX3Qo ItFqQSWPDUE2h9WS+axAXV8= =c8Nw -----END PGP SIGNATURE----- From lennart at augustsson.net Mon Feb 9 05:10:43 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 9 05:00:34 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <498FF6DC.9020909@tmorris.net> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> Message-ID: Not it doesn't. getChar has the type signature IO Char. The IO type is abstract. GHC happens to implement it by a state monad. But in, e.g., hbc it is implemented in a totally different way, more like a continuation monad. Peeking inside an implementation of IO can be illuminating, but one must remember that IO is abstract. -- Lennart On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Gregg Reynolds wrote: >> The point being that the metalanguage commonly used to describe IO >> in Haskell contains a logical contradiction. A thing cannot be both >> a value and a function, but e,g, getChar behaves like a function and >> has the type signature of a value. > getChar has the signature RealWorld -> (RealWorld, Char) > > - -- > Tony Morris > http://tmorris.net/ > > ********************************************************* > * Anteromedial Heterotopic Osseous Impingement Syndrome * > ********************************************************* > > http://www.ajronline.org/cgi/content/full/178/3/601 > "can result in chronic ankle pain, especially in athletes and the > younger population (15-40 years old)" > > http://radiographics.rsnajnls.org/cgi/content/figsonly/22/6/1457 > "Soft-tissue and osseous impingement syndromes of the ankle can be an > important cause of chronic pain, particularly in the professional > athlete." > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJj/bcmnpgrYe6r60RAicqAJ9z3f+aM/k+gDv8d5yAaNSCFf9NVQCfX3Qo > ItFqQSWPDUE2h9WS+axAXV8= > =c8Nw > -----END PGP SIGNATURE----- > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From tmorris at tmorris.net Mon Feb 9 05:14:21 2009 From: tmorris at tmorris.net (Tony Morris) Date: Mon Feb 9 05:04:32 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> Message-ID: <499001FD.5010705@tmorris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You're right - my statement is inaccurate. Implementation details aside, I am referring specifically to the statement "getChar ... has the type signature of a value". It clearly does not. Lennart Augustsson wrote: > Not it doesn't. getChar has the type signature IO Char. The IO > type is abstract. GHC happens to implement it by a state monad. > But in, e.g., hbc it is implemented in a totally different way, > more like a continuation monad. > > Peeking inside an implementation of IO can be illuminating, but one > must remember that IO is abstract. > > -- Lennart > > On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris > wrote: Gregg Reynolds wrote: >>>> The point being that the metalanguage commonly used to >>>> describe IO in Haskell contains a logical contradiction. A >>>> thing cannot be both a value and a function, but e,g, getChar >>>> behaves like a function and has the type signature of a >>>> value. > getChar has the signature RealWorld -> (RealWorld, Char) > >> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe >> - -- Tony Morris http://tmorris.net/ S, K and I ought to be enough for anybody. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmQAfkACgkQmnpgrYe6r61tmQCcCx42Cz1iunkD7JGubla/z2Pg uhAAoLk5rkjeHnrfc936IhYoBQYO/+0r =6xWk -----END PGP SIGNATURE----- From paolo at hypersonic.it Mon Feb 9 05:27:30 2009 From: paolo at hypersonic.it (Paolo Losi) Date: Mon Feb 9 05:17:36 2009 Subject: [Haskell-cafe] Re: Switching from Mercurial to Darcs In-Reply-To: References: <498B698D.6070005@henning-thielemann.de> <498BFF0A.8030808@hypersonic.it> Message-ID: <49900512.607@hypersonic.it> Thomas Davie wrote: > > On 6 Feb 2009, at 10:12, Paolo Losi wrote: > >> Henning Thielemann wrote: >> >>>> 4) hg commit -m "message" >>>> this commits my changes locally. I always do this before pulling since >>>> then I'm sure my changes are saved in the case a merge goes wrong. >>> In old darcs its precisely the other way round. Since it is so slow on >>> merging ready patches, you better merge uncrecorded changes. >> >> IMO pulling & merging before commit is a good practise also for hg: >> it avoids a (very often useless) merge commit in the history. > > I don't understand this view. Isn't the point of a commit that you flag > working points. In each branch, before you merge (hopefully) you have a > working repository, so flag it as such, and commit. When you merge, you > may or may not have a working repository, fix it until it is, and merge. > > I would never do a merge without the two branches I was merging having a > commit just before the merge. > > Bob I think you're right. but: - if you synch with the central repo at every commit you usually have a sort of out of band protocol with your peers for avoiding conflicts and in case of conflicts the manual merge is easy (if you occasionally merge unrelated branches that is obviously a different story) - the problem with mercurial is that it doesn't allow to amend history (you cannot afford to "merge" the first commit with the "merge" commit) and the commit history becomes cluttered. That's the reason why I prefer (in the case of commit/sync/commit/sync... scenario) pulling and updating before committing. AFAIK darcs and git doesn't have this problem, so the approach your suggesting should be the best in any case. I'm an "old" user of mercurial but I'm starting seeing some shortcomings with respect to git (and probably darcs). I really hope there will be some sort of convergence on a de facto DVCS soon in the opensource community :-) Paolo From lennart at augustsson.net Mon Feb 9 05:32:22 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 9 05:22:12 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <499001FD.5010705@tmorris.net> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> Message-ID: But an (IO Char) is a value. You can do all the things with it that you can do with values, e.g., pass it as an argument, stick it in a list, etc. It is a special kind of value, since if it ever "gets in contact with" the top level it will be executed. But the fact that IO types also behave as values makes Haskell a very powerful imperative language. On Mon, Feb 9, 2009 at 11:14 AM, Tony Morris wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > You're right - my statement is inaccurate. > > Implementation details aside, I am referring specifically to the > statement "getChar ... has the type signature of a value". It clearly > does not. > > Lennart Augustsson wrote: >> Not it doesn't. getChar has the type signature IO Char. The IO >> type is abstract. GHC happens to implement it by a state monad. >> But in, e.g., hbc it is implemented in a totally different way, >> more like a continuation monad. >> >> Peeking inside an implementation of IO can be illuminating, but one >> must remember that IO is abstract. >> >> -- Lennart >> >> On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris >> wrote: Gregg Reynolds wrote: >>>>> The point being that the metalanguage commonly used to >>>>> describe IO in Haskell contains a logical contradiction. A >>>>> thing cannot be both a value and a function, but e,g, getChar >>>>> behaves like a function and has the type signature of a >>>>> value. >> getChar has the signature RealWorld -> (RealWorld, Char) >> >>> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > > - -- > Tony Morris > http://tmorris.net/ > > S, K and I ought to be enough for anybody. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmQAfkACgkQmnpgrYe6r61tmQCcCx42Cz1iunkD7JGubla/z2Pg > uhAAoLk5rkjeHnrfc936IhYoBQYO/+0r > =6xWk > -----END PGP SIGNATURE----- > From tmorris at tmorris.net Mon Feb 9 05:38:13 2009 From: tmorris at tmorris.net (Tony Morris) Date: Mon Feb 9 05:28:15 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> Message-ID: <49900795.5060802@tmorris.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I also agree it is a value. The original post was attempting to make a distinction that does not exist. I deliberately avoided that topic. "A thing cannot be both a value and a function, but e,g, getChar" My original intent was to hope the poster reconsidered the whole post. You've blown my cover :) Lennart Augustsson wrote: > But an (IO Char) is a value. You can do all the things with it > that you can do with values, e.g., pass it as an argument, stick it > in a list, etc. It is a special kind of value, since if it ever > "gets in contact with" the top level it will be executed. But the > fact that IO types also behave as values makes Haskell a very > powerful imperative language. > > On Mon, Feb 9, 2009 at 11:14 AM, Tony Morris > wrote: You're right - my statement is inaccurate. > > Implementation details aside, I am referring specifically to the > statement "getChar ... has the type signature of a value". It > clearly does not. > > Lennart Augustsson wrote: >>>> Not it doesn't. getChar has the type signature IO Char. The >>>> IO type is abstract. GHC happens to implement it by a state >>>> monad. But in, e.g., hbc it is implemented in a totally >>>> different way, more like a continuation monad. >>>> >>>> Peeking inside an implementation of IO can be illuminating, >>>> but one must remember that IO is abstract. >>>> >>>> -- Lennart >>>> >>>> On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris >>>> wrote: Gregg Reynolds wrote: >>>>>>> The point being that the metalanguage commonly used to >>>>>>> describe IO in Haskell contains a logical >>>>>>> contradiction. A thing cannot be both a value and a >>>>>>> function, but e,g, getChar behaves like a function and >>>>>>> has the type signature of a value. >>>> getChar has the signature RealWorld -> (RealWorld, Char) >>>> > _______________________________________________ Haskell-Cafe > mailing list Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >> - -- Tony Morris http://tmorris.net/ S, K and I ought to be enough for anybody. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmQB5EACgkQmnpgrYe6r60L5QCfffj1Vy2Yg25adZLsLBReOk/K ZAoAoISEpzQH/9D0AzQOZdxJoxmoKeBj =+ZZx -----END PGP SIGNATURE----- From lennart at augustsson.net Mon Feb 9 06:22:30 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 9 06:12:20 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <49900795.5060802@tmorris.net> References: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> Message-ID: Sorry, I should have come down on the original poster too. ;) Functions are values, after all. On Mon, Feb 9, 2009 at 10:38 AM, Tony Morris wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I also agree it is a value. > The original post was attempting to make a distinction that does not > exist. I deliberately avoided that topic. > > "A thing cannot be both a value and a function, but e,g, getChar" > > My original intent was to hope the poster reconsidered the whole post. > You've blown my cover :) > > > Lennart Augustsson wrote: >> But an (IO Char) is a value. You can do all the things with it >> that you can do with values, e.g., pass it as an argument, stick it >> in a list, etc. It is a special kind of value, since if it ever >> "gets in contact with" the top level it will be executed. But the >> fact that IO types also behave as values makes Haskell a very >> powerful imperative language. >> >> On Mon, Feb 9, 2009 at 11:14 AM, Tony Morris >> wrote: You're right - my statement is inaccurate. >> >> Implementation details aside, I am referring specifically to the >> statement "getChar ... has the type signature of a value". It >> clearly does not. >> >> Lennart Augustsson wrote: >>>>> Not it doesn't. getChar has the type signature IO Char. The >>>>> IO type is abstract. GHC happens to implement it by a state >>>>> monad. But in, e.g., hbc it is implemented in a totally >>>>> different way, more like a continuation monad. >>>>> >>>>> Peeking inside an implementation of IO can be illuminating, >>>>> but one must remember that IO is abstract. >>>>> >>>>> -- Lennart >>>>> >>>>> On Mon, Feb 9, 2009 at 10:26 AM, Tony Morris >>>>> wrote: Gregg Reynolds wrote: >>>>>>>> The point being that the metalanguage commonly used to >>>>>>>> describe IO in Haskell contains a logical >>>>>>>> contradiction. A thing cannot be both a value and a >>>>>>>> function, but e,g, getChar behaves like a function and >>>>>>>> has the type signature of a value. >>>>> getChar has the signature RealWorld -> (RealWorld, Char) >>>>> >> _______________________________________________ Haskell-Cafe >> mailing list Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > > - -- > Tony Morris > http://tmorris.net/ > > S, K and I ought to be enough for anybody. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkmQB5EACgkQmnpgrYe6r60L5QCfffj1Vy2Yg25adZLsLBReOk/K > ZAoAoISEpzQH/9D0AzQOZdxJoxmoKeBj > =+ZZx > -----END PGP SIGNATURE----- > From dev at mobileink.com Mon Feb 9 06:24:15 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 06:14:05 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <49900795.5060802@tmorris.net> References: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> Message-ID: <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> On Mon, Feb 9, 2009 at 4:38 AM, Tony Morris wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I also agree it is a value. > The original post was attempting to make a distinction that does not > exist. I deliberately avoided that topic. > > "A thing cannot be both a value and a function, but e,g, getChar" > > My original intent was to hope the poster reconsidered the whole post. > You've blown my cover :) > My bad, I restate: a value cannot be both static and dynamic. Or an object and a morphism. Or an element and a function. Sure, you can treat a morphism as an object, but only by moving to a higher (or different) level of abstraction. That doesn't erase the difference between object and morphism. If you do erase that difference you end up with mush. getChar /looks/ like an object, but semantically it must be a morphism. But it can't be a function, since it is non-deterministic. So actually the logical contradiction comes from the nature of the beast. Another reason it's confusing to newcomers: it's typed as "IO Char", which looks like a type constructor. One would expect getChar to yield a value of type IO Char, no? But it delivers a Char instead. This is way confusing. So I take "type IO foo" to mean "type foo, after a side effect". In a sense "getChar :: IO Char" isn't even a true type signature. In any case, many thanks to all who have contributed to the thread. It's sharpened my thinking revealed weaknesses in my terminology, and I expect I'll make my inevitable contribution to the infinite Haskell tutorial on the topic before too long. -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/a55ae1fb/attachment.htm From lennart at augustsson.net Mon Feb 9 06:39:44 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 9 06:29:35 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> References: <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> Message-ID: Huh? The getChar function does yield a value of type (IO Char), exactly as the type signature says. If you want access to the Char you must use a >>=, just like in any other monad. 2009/2/9 Gregg Reynolds : > On Mon, Feb 9, 2009 at 4:38 AM, Tony Morris wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I also agree it is a value. >> The original post was attempting to make a distinction that does not >> exist. I deliberately avoided that topic. >> >> "A thing cannot be both a value and a function, but e,g, getChar" >> >> My original intent was to hope the poster reconsidered the whole post. >> You've blown my cover :) > > My bad, I restate: a value cannot be both static and dynamic. Or an object > and a morphism. Or an element and a function. Sure, you can treat a > morphism as an object, but only by moving to a higher (or different) level > of abstraction. That doesn't erase the difference between object and > morphism. If you do erase that difference you end up with mush. getChar > /looks/ like an object, but semantically it must be a morphism. But it > can't be a function, since it is non-deterministic. So actually the > logical contradiction comes from the nature of the beast. > > Another reason it's confusing to newcomers: it's typed as "IO Char", which > looks like a type constructor. One would expect getChar to yield a value of > type IO Char, no? But it delivers a Char instead. This is way confusing. > So I take "type IO foo" to mean "type foo, after a side effect". In a sense > "getChar :: IO Char" isn't even a true type signature. > > In any case, many thanks to all who have contributed to the thread. It's > sharpened my thinking revealed weaknesses in my terminology, and I expect > I'll make my inevitable contribution to the infinite Haskell tutorial on the > topic before too long. > > -gregg > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From ganesh.sittampalam at credit-suisse.com Mon Feb 9 06:32:58 2009 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Mon Feb 9 06:32:48 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> References: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz><75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com><75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com><498FF6DC.9020909@tmorris.net><499001FD.5010705@tmorris.net><49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> Message-ID: <16442B752A06A74AB4D9F9A5FF076E4B4DCBBE@ELON17P32001A.csfb.cs-group.com> > My bad, I restate: a value cannot be both static and dynamic. Or an > object and a morphism. Or an element and a function. Sure, you can > treat a morphism as an object, but only by moving to a higher (or > different) level of abstraction. That doesn't erase the difference > between object and morphism. If you do erase that difference you end > up with mush. getChar /looks/ like an object, but semantically it > must be a morphism. But it can't be a function, since it is > non-deterministic. So actually the logical contradiction comes from > the nature of the beast. > > Another reason it's confusing to newcomers: it's typed as "IO Char", > which looks like a type constructor. One would expect getChar to > yield a value of type IO Char, no? But it delivers a Char instead. > This is way confusing. So I take "type IO foo" to mean "type foo, > after a side effect". In a sense "getChar :: IO Char" isn't even a > true type signature. It does yield a value of type IO Char, which it also happens that you can ask the Haskell runtime to interpret by combining it with other IO values using >>= and invoking it from the top-level. *When interpreted in this way* it delivers a Char, but that's precisely the point at which we move to the different level of abstraction you mention above. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ============================================================================== From ketil at malde.org Mon Feb 9 06:49:05 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Feb 9 06:37:52 2009 Subject: [Haskell-cafe] Efficient string output Message-ID: <87ljsf4yq6.fsf@malde.org> Hi, I'm currently working on a program that parses a large binary file and produces various textual outputs extracted from it. Simple enough. But: since we're talking large amounts of data, I'd like to have reasonable performance. Reading the binary file is very efficient thanks to Data.Binary. However, output is a different matter. Currently, my code looks something like: summarize :: Foo -> ByteString summarize f = let f1 = accessor f f2 = expression f : in B.concat [f1,pack "\t",pack (show f2),...] which isn't particularly elegant, and builds a temporary ByteString that usually only get passed to B.putStrLn. I can suffer the inelegance were it only fast - but this ends up taking the better part of the execution time. I tried to use lazy ByteStrings, the theory being that the components that already are (strict) ByteStrings could be recycled as chunks. I also tried to push the output down into the function (summarize :: Foo -> IO ()), but both of these were actuall slower. Since I surely can't be the first person that needs to output tab-separated text, I'd be grateful if somebody could point me in the right direction. -k -- If I haven't seen further, it is by standing in the footprints of giants From johan.tibell at gmail.com Mon Feb 9 06:55:36 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Feb 9 06:45:26 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <87ljsf4yq6.fsf@malde.org> References: <87ljsf4yq6.fsf@malde.org> Message-ID: <90889fe70902090355ida7bc0av58fb3ed0b78c1c01@mail.gmail.com> On Mon, Feb 9, 2009 at 12:49 PM, Ketil Malde wrote: > Reading the binary file is very efficient thanks to Data.Binary. > However, output is a different matter. Currently, my code looks > something like: > > summarize :: Foo -> ByteString > summarize f = let f1 = accessor f > f2 = expression f > : > in B.concat [f1,pack "\t",pack (show f2),...] > > which isn't particularly elegant, and builds a temporary ByteString > that usually only get passed to B.putStrLn. I can suffer the > inelegance were it only fast - but this ends up taking the better part > of the execution time. Is building the strict ByteString what takes the most time? If so, you might want to use `writev` to avoid extra copying. Does your data support incremental processing so that you could produce output before all input has been parsed? Cheers, Johan From g9ks157k at acme.softbase.org Mon Feb 9 07:19:42 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 9 07:09:37 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902071546.25957.alexey.skladnoy@gmail.com> References: <5540a5470902061024hce004b6l48a99d3aa4e587e4@mail.gmail.com> <200902071546.25957.alexey.skladnoy@gmail.com> Message-ID: <200902091319.42566.g9ks157k@acme.softbase.org> Am Samstag, 7. Februar 2009 13:46 schrieb Khudyakov Alexey: > On Friday 06 February 2009 21:24:35 Andy Smith wrote: > > 2009/2/6 Wolfgang Jeltsch : > > > So using TeX as a general language for math is a very bad idea, in my > > > opinion. The problem is that there is no good language which provides > > > enough structural information for conversion into MathML and is at the > > > same time simple to write and read. Maybe, both requirements > > > contradict. > > > > ASCIIMathML [1] is designed to do this. It doesn't cover everything in > > Presentation MathML, and makes no attempt to handle Content MathML, > > but you can do quite a lot with it. The notation has a formally > > defined grammar and rules for conversion to MathML [2]. > > > > [1] http://www1.chapman.edu/~jipsen/asciimath.html > > [2] http://www1.chapman.edu/~jipsen/mathml/asciimathsyntax.html > > TeX aim is presentation quality not structural information. And it's rather > good at it. If one want really good looking formulae TeX is the answer. This is only true if your destination format is PDF, DVI or PS. For a webpage, you?ll need MathML in the end and TeX is not so good in producing MathML, I suppose. > ASCIIMathML is nice but its produce not so good looking formulae. How can you say that in general? ASCIIMathML can be converted into several formats (in principal) and is usually converted into MathML. And the rendering of MathML depends very much on the browser, plugin or whatever. Are there general deficiencies in ASCIIMathML or its usual conversion into MathML that prevent any MathML renderer from doing a good job? Or is it just a problem with your concrete MathML renderer? > I've tried it some time ago and found it clearly inferior to TeX. It gives > too little control over presentation. If you want a format suitable for multiple output formats (including more strucuture-oriented ones like MathML) than control over presentation is probably not what you want. > I wasn't able even to place integration indices exactly over and under > integral sign. In my opinion, you should just say what the indices are and the renderer should place them correctly. If it doesn?t, it?s a failure of the renderer, not of ASCIIMathML. Best wishes, Wolfgang From bulat.ziganshin at gmail.com Mon Feb 9 07:21:12 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 9 07:11:26 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <87ljsf4yq6.fsf@malde.org> References: <87ljsf4yq6.fsf@malde.org> Message-ID: <489376423.20090209152112@gmail.com> Hello Ketil, Monday, February 9, 2009, 2:49:05 PM, you wrote: > in B.concat [f1,pack "\t",pack (show f2),...] > inelegance were it only fast - but this ends up taking the better part > of the execution time. i'm not a BS expert but it seems that you produce Strings using show and then convert them to BS. of course this is inefficient - you need to replace show with BS analog -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ketil at malde.org Mon Feb 9 07:22:57 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Feb 9 07:11:38 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <90889fe70902090355ida7bc0av58fb3ed0b78c1c01@mail.gmail.com> (Johan Tibell's message of "Mon\, 9 Feb 2009 12\:55\:36 +0100") References: <87ljsf4yq6.fsf@malde.org> <90889fe70902090355ida7bc0av58fb3ed0b78c1c01@mail.gmail.com> Message-ID: <87bptb240u.fsf@malde.org> Johan Tibell writes: > Is building the strict ByteString what takes the most time? Yes. > If so, you might want to use `writev` to avoid extra copying. Is there a Haskell binding somewhere, or do I need to FFI the system call? Googling 'writev haskell' didn't turn up anything useful. > Does your data support incremental processing so that you could > produce output before all input has been parsed? Typically, yes. -k -- If I haven't seen further, it is by standing in the footprints of giants From dev at mobileink.com Mon Feb 9 07:35:11 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 07:25:00 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> Message-ID: <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> On Sun, Feb 8, 2009 at 6:25 PM, Richard O'Keefe wrote: > > On 6 Feb 2009, at 4:20 am, Gregg Reynolds wrote: > >> However, consider: >> >> getChar >>= \x -> getChar >> >> An optimizer can see that the result of the first getChar is discarded and >> replace the entire expression with one getChar without changing the formal >> semantics. >> > > But the result of the first getChar is *NOT* discarded. > **As an analogy**, think of the type IO t as (World -> (t,World)) > for some hidden type World, and > getChar w = (c, w') > -- get a character c out of world w somehow, > -- changing w to w' as you go > (f >>= g) w = let (v,w') = f w in (g v) w' > > In this analogy, you see that the result of getChar is a value of > type IO Char (not of type Char), and that while the character > part of the result of performing the result of getChar may be > discarded, the "changed world" part is NOT. That's an implementation detail. It doesn't account for other possible IO implementations. My original question was motivated by the observation that a human reader of an expression of the form "e >>= f" , on seeing that f is constant, may pull the constant value out of f, disregard e and dispense with the application f e. So can a compiler, unless IO expressions are involved, in which case such optimizations are forbidden. I wondered if that was due to the semantics of >>= or the semantics of IO. To summarize what I've concluded thanks to the helpful people on haskell-cafe: The compiler can optimize e >>= f except for any IO expressions in e and f. IO expressions must be evaluated, due to the semantics of IO. The may not be disregarded, memoized, or substituted. IO semantics may be implemented in different ways by different compilers; these implementation techniques are not part of the formal semantics of the language, which may be expressed as above: IO expressions must be evaluated wherever and whenever they occur. The bind operator >>= enforces sequencing on arguments containing IO expressions, but does not force evaluation. Even bind expressions involving IO may be optimized. For example: getChar >>= \x -> ...... putChar 'c' The compiler may discard (assuming it contains no IO expressions), but it must evaluate getChar and putChar (due to IO semantics) in the correct order (due to bind semantics). Thanks all, gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/f72f89d8/attachment.htm From ekirpichov at gmail.com Mon Feb 9 07:37:59 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Mon Feb 9 07:27:48 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <489376423.20090209152112@gmail.com> References: <87ljsf4yq6.fsf@malde.org> <489376423.20090209152112@gmail.com> Message-ID: <5e0214850902090437ke3abf73k81ae3eb51705b6e6@mail.gmail.com> +1; it's obviously the packing that causes sloth. Memoize the "pack "\t"" etc. stuff , and write bytestring replacements for show for your data. I guess you can use the Put monad instead of B.concat for that, by the way. 2009/2/9 Bulat Ziganshin : > Hello Ketil, > > Monday, February 9, 2009, 2:49:05 PM, you wrote: > >> in B.concat [f1,pack "\t",pack (show f2),...] > >> inelegance were it only fast - but this ends up taking the better part >> of the execution time. > > i'm not a BS expert but it seems that you produce Strings using show > and then convert them to BS. of course this is inefficient - you need > to replace show with BS analog > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From duncan.coutts at worc.ox.ac.uk Mon Feb 9 07:38:21 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 9 07:28:38 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <87ljsf4yq6.fsf@malde.org> References: <87ljsf4yq6.fsf@malde.org> Message-ID: <1234183101.5238.150.camel@localhost> On Mon, 2009-02-09 at 12:49 +0100, Ketil Malde wrote: > Hi, > > I'm currently working on a program that parses a large binary file and > produces various textual outputs extracted from it. Simple enough. > > But: since we're talking large amounts of data, I'd like to have > reasonable performance. > > Reading the binary file is very efficient thanks to Data.Binary. > However, output is a different matter. Currently, my code looks > something like: Have you considered using Data.Binary to output the data too? It has a pretty efficient underlying monoid for accumulating output data in a buffer. You'd want some wrapper functions over the top to make it a bit nicer for your use case, but it should work and should be quick. It generates a lazy bytestring, but does so with a few large chunks so the IO will still be quick. Duncan From immanuel203 at gmail.com Mon Feb 9 07:42:24 2009 From: immanuel203 at gmail.com (Immanuel Litzroth) Date: Mon Feb 9 07:32:14 2009 Subject: [Haskell-cafe] threadDelay Message-ID: Am I correct in assuming this program should run 100 secs? >import Control.Concurrent >main = do > threadDelay 100000 Why do I get the folling result then? ghc -threaded Main.hs -o delay time ./delay real 0m0.104s user 0m0.001s sys 0m0.002s Thanks in advance for all your wonderful comments, Immanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/2727aec2/attachment.htm From ketil at malde.org Mon Feb 9 07:46:03 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Feb 9 07:34:44 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <489376423.20090209152112@gmail.com> (Bulat Ziganshin's message of "Mon\, 9 Feb 2009 15\:21\:12 +0300") References: <87ljsf4yq6.fsf@malde.org> <489376423.20090209152112@gmail.com> Message-ID: <87zlgvzsl0.fsf@malde.org> Bulat Ziganshin writes: >> in B.concat [f1,pack "\t",pack (show f2),...] > i'm not a BS expert but it seems that you produce Strings using show > and then convert them to BS. of course this is inefficient - you need > to replace show with BS analog Do these analogous functions exist, or must I roll my own. I've also looked a bit at Data.Binary.Builder, perhaps this is the way to go? Will look more closely. -k -- If I haven't seen further, it is by standing in the footprints of giants From svein.ove at aas.no Mon Feb 9 07:53:30 2009 From: svein.ove at aas.no (Svein Ove Aas) Date: Mon Feb 9 07:43:22 2009 Subject: [Haskell-cafe] threadDelay In-Reply-To: References: Message-ID: <221b53ab0902090453w1992ea64u4a500c0d5049ecb4@mail.gmail.com> 2009/2/9 Immanuel Litzroth : > Am I correct in assuming this program should run 100 secs? > No, you're off by a factor of a thousand. It's based on microseconds, not milliseconds. From bulat.ziganshin at gmail.com Mon Feb 9 07:54:27 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 9 07:44:35 2009 Subject: [Haskell-cafe] threadDelay In-Reply-To: References: Message-ID: <331796775.20090209155427@gmail.com> Hello Immanuel, Monday, February 9, 2009, 3:42:24 PM, you wrote: > Am I correct in assuming this program should run 100 secs? > real??? 0m0.104s may be, 100 msecs? :) -- | Suspends the current thread for a given number of microseconds -- (GHC only). -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dev at mobileink.com Mon Feb 9 07:57:37 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 07:47:26 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <16442B752A06A74AB4D9F9A5FF076E4B4DCBBE@ELON17P32001A.csfb.cs-group.com> References: <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCBBE@ELON17P32001A.csfb.cs-group.com> Message-ID: <75cc17ac0902090457i755d6e2em39f271215a52c0a9@mail.gmail.com> On Mon, Feb 9, 2009 at 5:32 AM, Sittampalam, Ganesh < ganesh.sittampalam@credit-suisse.com> wrote: > > > My bad, I restate: a value cannot be both static and dynamic. Or an > > object and a morphism. Or an element and a function. Sure, you can > > treat a morphism as an object, but only by moving to a higher (or > > different) level of abstraction. That doesn't erase the difference > > between object and morphism. If you do erase that difference you end > > up with mush. getChar /looks/ like an object, but semantically it > > must be a morphism. But it can't be a function, since it is > > non-deterministic. So actually the logical contradiction comes from > > the nature of the beast. > > > > Another reason it's confusing to newcomers: it's typed as "IO Char", > > which looks like a type constructor. One would expect getChar to > > yield a value of type IO Char, no? But it delivers a Char instead. > > This is way confusing. So I take "type IO foo" to mean "type foo, > > after a side effect". In a sense "getChar :: IO Char" isn't even a > > true type signature. > > It does yield a value of type IO Char, which it also happens that you > can ask the Haskell runtime to interpret by combining it with other > IO values using >>= and invoking it from the top-level. > *When interpreted in this way* it delivers a Char, but that's precisely > the point at which we move to the different level of abstraction you > mention above. Right; "implementation of IO" means also an implementation for >>=, not just the IO operators. I hadn't thought about that but it's hugely important for the exposition of monads and IO. "The IO Char indicates that getChar, when invoked, performs some action which returns a character." (Gentle Intro, typical of many expositions.) That, plus the form of \x -> putChar x used with >>=, plus the fact that one can do getChar at the ghci command line, plus all the other stuff - it all adds up to exasperation. Thanks, gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/097579f5/attachment.htm From johan.tibell at gmail.com Mon Feb 9 07:57:52 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon Feb 9 07:47:42 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <87bptb240u.fsf@malde.org> References: <87ljsf4yq6.fsf@malde.org> <90889fe70902090355ida7bc0av58fb3ed0b78c1c01@mail.gmail.com> <87bptb240u.fsf@malde.org> Message-ID: <90889fe70902090457yf772124x72e9930e6739b835@mail.gmail.com> On Mon, Feb 9, 2009 at 1:22 PM, Ketil Malde wrote: > Johan Tibell writes: >> If so, you might want to use `writev` to avoid extra copying. > > Is there a Haskell binding somewhere, or do I need to FFI the system > call? Googling 'writev haskell' didn't turn up anything useful. To my knowledge there's no binding out there. We will include one for sockets in the next release of network-bytestring. You might find the code here useful if you want to write your own: http://github.com/tibbe/network-bytestring/blob/c13d8fab5179e6afbcdebac95d4993ac57f04689/Network/Socket/ByteString/Internal.hs Cheers, Johan From r.kelsall at millstream.com Mon Feb 9 08:03:05 2009 From: r.kelsall at millstream.com (Richard Kelsall) Date: Mon Feb 9 07:53:03 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207213541.GQ27081@whirlpool.galois.com> References: <20090207181243.GH27081@whirlpool.galois.com> <20090207183429.GJ27081@whirlpool.galois.com> <20090207200401.GM27081@whirlpool.galois.com> <20090207202958.GN27081@whirlpool.galois.com> <20090207213541.GQ27081@whirlpool.galois.com> Message-ID: <49902989.4090001@millstream.com> Don Stewart wrote: > Help identifying and implementing a voting process is very welcome. Maybe we could have an administrator who receives the votes by email and we confirm our emailed vote by appending the MD5 of our email to a Haskell wiki page. The machine-readable email format might be: I vote for these three logos in order of preference: 23 5 78 Here is my random salt: kauhgfhgh Here is the MD5 of the above: e4d909c290d0fb1ca068ffaddf22cbd0 The administrator can check the MD5s he has received by email and mark them as good on the wiki page, count the votes and publish the result. Richard. From lennart at augustsson.net Mon Feb 9 08:17:07 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon Feb 9 08:06:57 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> Message-ID: Just to clarify a little. If you implement the IO monad in a sane way (as some kind of state monad or continuation monad) then the compiler can optimize e>>=f even for the IO monad. The implementation of >>= will ensure the sequencing of effects in e before effects in f. The IO monad is less magic than you seem to think it is. :) -- Lennart 2009/2/9 Gregg Reynolds : > On Sun, Feb 8, 2009 at 6:25 PM, Richard O'Keefe wrote: >> >> On 6 Feb 2009, at 4:20 am, Gregg Reynolds wrote: >>> >>> However, consider: >>> >>> getChar >>= \x -> getChar >>> >>> An optimizer can see that the result of the first getChar is discarded >>> and replace the entire expression with one getChar without changing the >>> formal semantics. >> >> But the result of the first getChar is *NOT* discarded. >> **As an analogy**, think of the type IO t as (World -> (t,World)) >> for some hidden type World, and >> getChar w = (c, w') >> -- get a character c out of world w somehow, >> -- changing w to w' as you go >> (f >>= g) w = let (v,w') = f w in (g v) w' >> >> In this analogy, you see that the result of getChar is a value of >> type IO Char (not of type Char), and that while the character >> part of the result of performing the result of getChar may be >> discarded, the "changed world" part is NOT. > > That's an implementation detail. It doesn't account for other possible IO > implementations. > > My original question was motivated by the observation that a human reader of > an expression of the form "e >>= f" , on seeing that f is constant, may pull > the constant value out of f, disregard e and dispense with the application f > e. So can a compiler, unless IO expressions are involved, in which case > such optimizations are forbidden. I wondered if that was due to the > semantics of >>= or the semantics of IO. > > To summarize what I've concluded thanks to the helpful people on > haskell-cafe: > > The compiler can optimize e >>= f except for any IO expressions in e and f. > IO expressions must be evaluated, due to the semantics of IO. The may not > be disregarded, memoized, or substituted. IO semantics may be implemented > in different ways by different compilers; these implementation techniques > are not part of the formal semantics of the language, which may be expressed > as above: IO expressions must be evaluated wherever and whenever they > occur. > > The bind operator >>= enforces sequencing on arguments containing IO > expressions, but does not force evaluation. Even bind expressions involving > IO may be optimized. For example: > > getChar >>= \x -> ...... putChar 'c' > > The compiler may discard (assuming it contains no IO > expressions), but it must evaluate getChar and putChar (due to IO semantics) > in the correct order (due to bind semantics). > > Thanks all, > > gregg > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From dev at mobileink.com Mon Feb 9 08:33:53 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 08:23:43 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> Message-ID: <75cc17ac0902090533m40f7f9dct7dce53533ab5831a@mail.gmail.com> On Mon, Feb 9, 2009 at 7:17 AM, Lennart Augustsson wrote: > Just to clarify a little. > If you implement the IO monad in a sane way (as some kind of state > monad or continuation monad) then the compiler can optimize e>>=f even > for the IO monad. The implementation of >>= will ensure the > sequencing of effects in e before effects in f. I think this answers one of my questions about the relation of category theory to Haskell. Bind is an implementation of the Kleisli star, but the latter, being abstract, may encode data dependency but not sequence. The IO implementation of >>= must ensure sequence, regardless of data dependency (e.g. even for putChar 'a' >>= \x -> putChar 'c'). So if we wanted to write a Haskell specification with more formality and detail than the Report, we could say that the IO monad must implement the Kleisli star operator, but that would not be enough, we would also have to require that the implementation ensure sequencing. IOW, Kleisli star implementation plus a constraint on the implementation. Does that sound right? > > The IO monad is less magic than you seem to think it is. :) > Any sufficiently advanced technology is isomorphic to magic. ;) (http://www.quotationspage.com/quote/776.html) -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/ce50e562/attachment.htm From marlowsd at gmail.com Mon Feb 9 08:34:27 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 9 08:24:22 2009 Subject: [Haskell-cafe] Re: The Haskell re-branding exercise In-Reply-To: <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> Message-ID: <499030E3.5000404@gmail.com> Sterling Clover wrote: > IP based limitations are a terrible idea. Multiple users can be and > often are behind the same IP if they're in some sort of intranet, be it > corporate, academic, or simply multiple home computers. Mail-based > authentication can be screwed with, sure, but it's also very easy to > notice this (as opposed to ip nonsense) through simply eyeballing the > results. There's no general everywhere way to prevent vote fraud. > However, if we make it even require a mild bit of thought, that should > be sufficient in this case, as there won't be enough votes to prevent > some sort of rough eyeball-based check of the results, and if there are, > then that's a sign of fraud for sure! Furthermore, there's very little > incentive for someone to go the extra mile here, as we're voting for a > haskell logo, and not, e.g., giving away ten thousand dollars. > Furthermore, since I assume we'll only be presenting reasonable logos, > there's not even some room for pranksters to stage a "write-in" of some > gag slogan. I suggest we do voting by email, and restrict voting to those who have ever posted on haskell-cafe before 1 Jan 2009. We could then have an auto-confirmation scheme similar to mailing list sign-up where the confirmation message is sent back to the originator to confirm their identity, containing a verification link to click on. I realise there are flaws in this, but it seems to be (a) cheap to implement and participate in, and (b) good enough. Cheers, Simon From marlowsd at gmail.com Mon Feb 9 08:39:06 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Feb 9 08:28:59 2009 Subject: [Haskell-cafe] Re: Does readFile "/proc/mounts" hang for you? In-Reply-To: References: Message-ID: <499031FA.3010500@gmail.com> David Fox wrote: > On Wed, Jan 21, 2009 at 9:20 AM, David Fox > wrote: > > I posted a bug about this > (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I > had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and > Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 > machine running Linux. Also, Data.ByteString.readFile > "/proc/mounts" returns the empty string. Is this behavior present > for others? On i386? > > > I can now confirm that this bug also affects the i386 architecture. There was a more serious underlying bug, which is now fixed. Thanks to those who reported and investigated it. Cheers, Simon From r.kelsall at millstream.com Mon Feb 9 08:48:32 2009 From: r.kelsall at millstream.com (Richard Kelsall) Date: Mon Feb 9 08:38:25 2009 Subject: [Haskell-cafe] Re: The Haskell re-branding exercise In-Reply-To: <499030E3.5000404@gmail.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> <499030E3.5000404@gmail.com> Message-ID: <49903430.1080906@millstream.com> Simon Marlow wrote: > I suggest we do voting by email, and restrict voting to those who have > ever posted on haskell-cafe before 1 Jan 2009. We could then have an > auto-confirmation scheme similar to mailing list sign-up where the > confirmation message is sent back to the originator to confirm their > identity, containing a verification link to click on. > > I realise there are flaws in this, but it seems to be (a) cheap to > implement and participate in, and (b) good enough. > That sounds better than my Haskell Wiki verification method. Richard. From peter.padawitz at udo.edu Mon Feb 9 09:10:22 2009 From: peter.padawitz at udo.edu (Peter Padawitz) Date: Mon Feb 9 09:00:13 2009 Subject: [Haskell-cafe] lazy evaluation is not complete Message-ID: <4990394E.8020409@udo.edu> A simplied version of Example 5-16 in Manna's classical book "Mathematical Theory of Computation": foo x = if x == 0 then 0 else foo (x-1)*foo (x+1) If run with ghci, foo 5 does not terminate, i.e., Haskell does not look for all outermost redices in parallel. Why? For efficiency reasons? It's a pity because a parallel-outermost strategy would be complete. From lemming at henning-thielemann.de Mon Feb 9 09:10:44 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 9 09:00:50 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902061603.29609.g9ks157k@acme.softbase.org> References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> Message-ID: <49903964.3070304@henning-thielemann.de> Wolfgang Jeltsch wrote: > TeX is not so great for mathematics and especially not for conversion into > MathML (which would be needed for HTML output). The TeX math language > provides rather little semantic information. As input language for the > concrete software named TeX this is mostly okay since the concrete rendering > algorithm of TeX doesn?t need certain information (for example, about > implicit bracketing). > > However, even for rendering with TeX, you sometimes have to ressort to ugly > tricks since TeX sometimes misinterprets what you wrote. Knuth gives some > examples in chapter 18 of The TeXbook. For conversion into MathML, a TeX > source generally doesn?t have enough information since even presentation > MathML code contains much more structure than ordinary TeX source code does. > > So using TeX as a general language for math is a very bad idea, in my opinion. > The problem is that there is no good language which provides enough > structural information for conversion into MathML and is at the same time > simple to write and read. Maybe, both requirements contradict. I want for long to write math formulas in a paper in Haskell. Actually, lhs2TeX can do such transformations but it is quite limited in handling of parentheses and does not support more complicated transformations (transforming prefix notation in infix notation or vice versa with minimal parentheses). I would like to write sumFor [0..n] (\i -> i^2) (with sumFor xs f = sum $ map f xs) which is rendered as \sum_{i=0}^{n} i^2 or integrate 1000 (a,b) (\t -> f t) to be rendered as \int_a^b f(t) \dif t I imagine some rule based configuration that is implemented using haskell-src, that handles all identifiers, say, with prefix "parameter" as wildcards: sumFor [parameterA..parameterB] (\parameterI -> parameterS) => \sum_{parameterI=parameterA}^{parameterB} parameterS Unfortunately a tool for this transformation still has to be written, but wouldn't that be really cool? The tool might be even relatively simple, but the configuration is certainly non-trivial and it would have to be hard-wired into cabal in order to provide identical rendering on all systems and output formats (TeX or MathML). From lemming at henning-thielemann.de Mon Feb 9 09:18:54 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon Feb 9 09:08:45 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902071546.00718.alexey.skladnoy@gmail.com> References: <1233916294.9411.15.camel@porges-laptop> <200902071546.00718.alexey.skladnoy@gmail.com> Message-ID: <49903B4E.4020100@henning-thielemann.de> Khudyakov Alexey wrote: > I think MathML is much less accessible than images. Yes, there are problems > with them but any browser is able to display them save for text based ones. > MathML on contrary doesn't have much support. According to wikipedia only > recent versions of gecko based browsers and opera >=9.5 can do this. For IE > special plugin is required (MathPlayer). I believe image are safest way at > least for now. As far as I know, Haddock is not bound to HTML output. (And if it is bound this way, I wished it wouldn't.) For PDF Haddock output TeX formula will be the best choice, whereas for HTML, MathML or embedded images are the best. I expect there will be no consensus and the Haddock user should decide how he wants the formulas to be rendered. That's best generated from a structure preserving notation of math formulas (like Haskell expressions). From devriese at cs.tcd.ie Mon Feb 9 09:18:18 2009 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Mon Feb 9 09:09:10 2009 Subject: [Haskell-cafe] Looking for pointfree version Message-ID: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> Hi, Is there a nice way to write down :: Focus -> [Focus] down p = concat [downPar p, downNew p, downTrans p] in point-free style? (In doesn't make much difference what these functions do; if it helps, their types are downPar, downNew, downTrans :: Focus -> [Focus]). Ideally, I would like to write something like down = downPar ... downNew ... downTrans but I'm not sure what should be on the dots. This works: down = concat . flip map [downPar, downNew, downTrans] . flip ($) but is extremely ugly and doesn't really explain what's going on :) (It seems to me I should be able to take advantage of the list monad, somehow). Pointers appreciated! Edsko From bulat.ziganshin at gmail.com Mon Feb 9 09:23:58 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 9 09:13:58 2009 Subject: [Haskell-cafe] lazy evaluation is not complete In-Reply-To: <4990394E.8020409@udo.edu> References: <4990394E.8020409@udo.edu> Message-ID: <1948659268.20090209172358@gmail.com> Hello Peter, Monday, February 9, 2009, 5:10:22 PM, you wrote: > If run with ghci, foo 5 does not terminate, i.e., Haskell does not look > for all outermost redices in parallel. Why? For efficiency reasons? of course. if you will create new thread for every cpu instruction executed, you will definitely never compute anything :D you need to use `par` -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From greenrd at greenrd.org Sun Feb 8 13:56:19 2009 From: greenrd at greenrd.org (Robin Green) Date: Mon Feb 9 09:15:55 2009 Subject: [Haskell-cafe] lazy evaluation is not complete In-Reply-To: <4990394E.8020409@udo.edu> References: <4990394E.8020409@udo.edu> Message-ID: <20090208185619.79fa1437@greenrd.org> On Mon, 09 Feb 2009 15:10:22 +0100 Peter Padawitz wrote: > A simplied version of Example 5-16 in Manna's classical book > "Mathematical Theory of Computation": > > foo x = if x == 0 then 0 else foo (x-1)*foo (x+1) > > If run with ghci, foo 5 does not terminate, i.e., Haskell does not > look for all outermost redices in parallel. Why? For efficiency > reasons? I believe * is implemented in the normal way and thus is always strict in both arguments. From bugfact at gmail.com Mon Feb 9 09:26:15 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Feb 9 09:16:09 2009 Subject: [Haskell-cafe] FFI binding to CGAL? Message-ID: I was wandering of someone already made a FFI binding to http://www.cgal.org or something similar that does computational geometry? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/8cd80e5e/attachment.htm From greenrd at greenrd.org Sun Feb 8 14:01:12 2009 From: greenrd at greenrd.org (Robin Green) Date: Mon Feb 9 09:20:49 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> Message-ID: <20090208190112.35ea32d0@greenrd.org> On Mon, 9 Feb 2009 14:18:18 +0000 Edsko de Vries wrote: > Hi, > > Is there a nice way to write > > down :: Focus -> [Focus] > down p = concat [downPar p, downNew p, downTrans p] > > in point-free style? I think this should work: down = concat . swing map [downPar, downNew, downTrans] swing is defined at http://www.haskell.org/haskellwiki/Pointfree#Swing -- Robin From wss at cs.nott.ac.uk Mon Feb 9 09:31:09 2009 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Mon Feb 9 09:21:04 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> Message-ID: > snip How about using Data.Monoid: down = downPar `mappend` downNew `mappend` downTrans Wouter From bradypus at xs4all.nl Mon Feb 9 09:42:29 2009 From: bradypus at xs4all.nl (Aai) Date: Mon Feb 9 09:26:03 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> Message-ID: <499040D5.6070907@xs4all.nl> Rewriting it to: concatMap ($ p)[downPar , downNew , downTrans ] gives: ($ p) =<< [downPar, downNew, downTrans] didn't check though! =@@i Edsko de Vries schreef: > Hi, > > Is there a nice way to write > > down :: Focus -> [Focus] > down p = concat [downPar p, downNew p, downTrans p] > > in point-free style? (In doesn't make much difference what these > functions do; if it helps, their types are downPar, downNew, downTrans > :: Focus -> [Focus]). > > Ideally, I would like to write something like > > down = downPar ... downNew ... downTrans > > but I'm not sure what should be on the dots. This works: > > down = concat . flip map [downPar, downNew, downTrans] . flip ($) > > but is extremely ugly and doesn't really explain what's going on :) > (It seems to me I should be able to take advantage of the list monad, > somehow). > > Pointers appreciated! > > Edsko > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From noteed at gmail.com Mon Feb 9 09:36:42 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 9 09:26:30 2009 Subject: [Haskell-cafe] FFI binding to CGAL? In-Reply-To: References: Message-ID: <40a414c20902090636t7dd5bc36l6d10336705c253fe@mail.gmail.com> 2009/2/9 Peter Verswyvelen : > I was wandering of someone already made a FFI binding to http://www.cgal.org > or something similar that does computational geometry? > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe CGAL is written in C++ and makes heavy use of templates to let user code parametrize efficiently the data structures. I'm not sure it would be a good pick to begin with if you not a lot of time. On the other hand, if you're happy with a few small choices of parametrization, you can do that in C++, then export some C functions then bind against that. It's overall quite straightforward. HTH, Thu From duncan.coutts at worc.ox.ac.uk Mon Feb 9 09:40:30 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 9 09:30:43 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <49903B4E.4020100@henning-thielemann.de> References: <1233916294.9411.15.camel@porges-laptop> <200902071546.00718.alexey.skladnoy@gmail.com> <49903B4E.4020100@henning-thielemann.de> Message-ID: <1234190430.5238.154.camel@localhost> On Mon, 2009-02-09 at 15:18 +0100, Henning Thielemann wrote: > Khudyakov Alexey wrote: > > > I think MathML is much less accessible than images. Yes, there are problems > > with them but any browser is able to display them save for text based ones. > > MathML on contrary doesn't have much support. According to wikipedia only > > recent versions of gecko based browsers and opera >=9.5 can do this. For IE > > special plugin is required (MathPlayer). I believe image are safest way at > > least for now. > > As far as I know, Haddock is not bound to HTML output. (And if it is > bound this way, I wished it wouldn't.) Right, it's not. Though there are not many other backends. Translating haddock markup into pandoc or docbook might be an easy way to get more. > For PDF Haddock output TeX formula will be the best choice, whereas > for HTML, MathML or embedded images are the best. I expect there will > be no consensus and the Haddock user should decide how he wants the > formulas to be rendered. That's best generated from a structure > preserving notation of math formulas (like Haskell expressions). Right, the problem is that since it is not bound to a specific output format then it cannot use embedded tex or whatever. The current haddock markup is deliberately very limited and simple so that it can be rendered in more or less any output format. Duncan From ketil at malde.org Mon Feb 9 09:47:08 2009 From: ketil at malde.org (Ketil Malde) Date: Mon Feb 9 09:35:48 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <1234183101.5238.150.camel@localhost> (Duncan Coutts's message of "Mon\, 09 Feb 2009 12\:38\:21 +0000") References: <87ljsf4yq6.fsf@malde.org> <1234183101.5238.150.camel@localhost> Message-ID: <87fxinzmz7.fsf@malde.org> Duncan Coutts writes: > Have you considered using Data.Binary to output the data too? It has a > pretty efficient underlying monoid for accumulating output data in a > buffer. You'd want some wrapper functions over the top to make it a bit > nicer for your use case, but it should work and should be quick. I've used Data.Binary.Builder to generate the output, which is quite nice as an interface. Currently, I've managed to shave off a few percent off the time - nothing radical yet, but there's a lot of room for tuning various convenience functions in there. -k -- If I haven't seen further, it is by standing in the footprints of giants From devriese at cs.tcd.ie Mon Feb 9 09:47:53 2009 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Mon Feb 9 09:38:44 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> Message-ID: <92D07DED-B162-45C6-895A-E8CFB00E2EEE@cs.tcd.ie> Perfect! Beautiful. I was hoping there'd be a simple solution like that. Thanks! On 9 Feb 2009, at 14:31, Wouter Swierstra wrote: > > snip > > How about using Data.Monoid: > > down = downPar `mappend` downNew `mappend` downTrans > > Wouter > From white at u.washington.edu Mon Feb 9 10:16:22 2009 From: white at u.washington.edu (drblanco) Date: Mon Feb 9 10:06:11 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902091319.42566.g9ks157k@acme.softbase.org> References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> <5540a5470902061024hce004b6l48a99d3aa4e587e4@mail.gmail.com> <200902071546.25957.alexey.skladnoy@gmail.com> <200902091319.42566.g9ks157k@acme.softbase.org> Message-ID: <21914911.post@talk.nabble.com> Wolfgang Jeltsch-2 wrote: > > This is only true if your destination format is PDF, DVI or PS. For a > webpage, > you?ll need MathML in the end and TeX is not so good in producing MathML, > I > suppose. > Has jsMath been considered as an alternative to images in HTML? (http://www.math.union.edu/~dpvc/jsMath/) It's supposed to work on most browsers, and the screen output is very nice. -- View this message in context: http://www.nabble.com/Haddock-Markup-tp21864389p21914911.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From jochem at functor.nl Mon Feb 9 10:19:29 2009 From: jochem at functor.nl (Jochem Berndsen) Date: Mon Feb 9 10:09:21 2009 Subject: [Haskell-cafe] lazy evaluation is not complete In-Reply-To: <4990394E.8020409@udo.edu> References: <4990394E.8020409@udo.edu> Message-ID: <49904981.4090202@functor.nl> Peter Padawitz wrote: > A simplied version of Example 5-16 in Manna's classical book > "Mathematical Theory of Computation": > > foo x = if x == 0 then 0 else foo (x-1)*foo (x+1) > > If run with ghci, foo 5 does not terminate, i.e., Haskell does not look > for all outermost redices in parallel. Why? For efficiency reasons? > > It's a pity because a parallel-outermost strategy would be complete. (*) is strict in both arguments for Int. If you want to avoid this, you could do newtype X = X Int and write your own implementation of (*) that is nonstrict. -- Jochem Berndsen | jochem@functor.nl GPG: 0xE6FABFAB From michael at snoyman.com Mon Feb 9 10:21:34 2009 From: michael at snoyman.com (Michael Snoyman) Date: Mon Feb 9 10:11:24 2009 Subject: [Haskell-cafe] Re: Haskell and Automation In-Reply-To: <498E5C36.30901@fedoms.com> References: <498CF871.4060801@fedoms.com> <29bf512f0902071912s4d20a631k72c3ae83a326f5b3@mail.gmail.com> <498E5C36.30901@fedoms.com> Message-ID: <29bf512f0902090721x69298904qe3883bf589cf483e@mail.gmail.com> Gunther, Thanks for the heads-up. I might need to interface with Excel in the future. Michael On Sat, Feb 7, 2009 at 8:14 PM, G?uenther Schmidt wrote: > Dear Michael, > > sorry too, for not telling you sooner that meanwhile I found out how to get > it working, I hope you did not spend too much time trying on your end. > > It had to do with the context in which these components are initialized. > > Once you switch to LocalProcess (as opposed to AnyProcess) in > coCreateInstance everything works fine and rather smoothly. The defaults in > createObject do not work for every kind of object that you do want to > instantiate, certainly not Excel. > > Of course having an old, but still fairly current manual also helps. > > Good luck with your projects. > > G?nther > > > > Michael Snoyman schrieb: > > Gunther, > > Sorry for not getting back to you on your previous e-mail, I've been > swamped. > > The reason I didn't put up an example was specifically because of the error > you mention. I was hoping to get a chance to use the COM bindings in Python > to see if I got the same thing. For the life of me I can't figure out how to > get started with Excel and Haskell. Sorry I can't be more useful at this > time. > > Michael > > On Fri, Feb 6, 2009 at 6:56 PM, G?uenther Schmidt wrote: > >> Hi Michael, >> >> for some reason createObject "Excel.Application" throws an "Interface not >> supported" error. >> >> Can you help me out here? >> >> G?nther >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/8e8ca948/attachment.htm From silviu.andrica at epfl.ch Mon Feb 9 10:56:40 2009 From: silviu.andrica at epfl.ch (Silviu ANDRICA) Date: Mon Feb 9 10:46:31 2009 Subject: [Haskell-cafe] Haskell and Java interaction Message-ID: <49905238.9050507@epfl.ch> Hello, I was wondering if there is a way to call Haskell code from Java. I tried using jvm-bridge(http://sourceforge.net/projects/jvm-bridge/), but I'm stuck on building it. Thank you very much, Silviu From cmb21 at kent.ac.uk Mon Feb 9 11:05:25 2009 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Mon Feb 9 10:55:15 2009 Subject: [Haskell-cafe] Haskell and Java interaction In-Reply-To: <49905238.9050507@epfl.ch> References: <49905238.9050507@epfl.ch> Message-ID: Hi Silviu, There's the GCJNI: http://www.haskell.org/gcjni/ Which is basically a greencard-ed JNI interface for Haskell. I'm not sure it's still suported but may be worth a shot. Regards, Chris. On Mon, 9 Feb 2009, Silviu ANDRICA wrote: > Hello, > I was wondering if there is a way to call Haskell code from Java. I > tried using jvm-bridge(http://sourceforge.net/projects/jvm-bridge/), but > I'm stuck on building it. > > Thank you very much, > Silviu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dev at mobileink.com Mon Feb 9 11:06:34 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 10:56:23 2009 Subject: [Haskell-cafe] Formal semantics for Haskell? Message-ID: <75cc17ac0902090806v377cbffare54bc0e851629fe@mail.gmail.com> ML has a formal definition[1]; why not Haskell? Would this be a Good Thing, or a Waste Of Time? The Report strikes me as a hybrid of formal and informal. I guess that's not a problem so far, but there aren't that many implementations; if we had dozens, how could we verify conformance? A formal semantics would be useful, but it would also be Fun to use Category Theory notation in a language definition. Such a task would be way beyond my abilities, but I have come up with an idea for a formal semantics of IO and other non-deterministic elements of the language that I think is kind of interesting. It's inspired by Category Theory and the Z specification language. See my (brief) blog article . Actually, I'm in a state of rather intense euphoria about it, so a bucket of cold water realism over my head might be a Good Thing. Then I could get some sleep instead of obsessing about category theory and Haskell. :) I propose any formal definition include the following warning, modeled on Knuth's warning about MetaFont: WARNING: Haskell can be hazardous to your other interests. Once you get hooked, you will develop intense feelings about language design; semantic models will intrude on the program texts you read. And you will perpetually be thinking of improvements to the programs that you see everywhere, including those of your own design. Thanks, gregg [1] The Definition of Standard ML (Revised); a preview is on Google Books -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/4a7a7097/attachment.htm From jupdike at gmail.com Mon Feb 9 11:18:33 2009 From: jupdike at gmail.com (Jared Updike) Date: Mon Feb 9 11:08:23 2009 Subject: [Haskell-cafe] Re: Data.Map: Enumerating ordered subset of keys In-Reply-To: <221b53ab0902082331xf2daad1r768782a65cb6e96a@mail.gmail.com> References: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> <8b108f950902082302o341c4376wca32c591aace7d1c@mail.gmail.com> <221b53ab0902082331xf2daad1r768782a65cb6e96a@mail.gmail.com> Message-ID: <8b108f950902090818m117763e9r2268f14103ed6ef6@mail.gmail.com> I had a similar thought. That will probably do the trick. Jared. On 2/8/09, Svein Ove Aas wrote: > On Mon, Feb 9, 2009 at 8:02 AM, Jared Updike wrote: > > It looks like two "Map.split"s will do what I need except for allowing > > more exact testing of <= vs. < (since == elements are left out of both > > maps...?) > > > > If your key is an instance of Enum, you can use succ/pred to work > around that little problem. > From jupdike at gmail.com Mon Feb 9 11:20:51 2009 From: jupdike at gmail.com (Jared Updike) Date: Mon Feb 9 11:10:41 2009 Subject: [Haskell-cafe] Re: Data.Map: Enumerating ordered subset of keys In-Reply-To: References: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> <8b108f950902082302o341c4376wca32c591aace7d1c@mail.gmail.com> Message-ID: <8b108f950902090820r749db4a3ra07bc4855208c723@mail.gmail.com> On 2/8/09, Anish Muttreja wrote: > Maybe you wantData.Map.partition (\key -> key >= key1 && key <= key2) map This will return what I want, but partition is O(n) and touches all the keys, so if I had a million keys and only 2 of them matched the key1..key2 range, it would still visit all of them before it enumerated the ones that satisify the predicate. I don't believe laziness would help here. > HTH, > Anish > > > On Sun, 08 Feb 2009 23:02:37 -0800, Jared Updike wrote: > > > > > > It looks like two "Map.split"s will do what I need except for allowing > > more exact testing of <= vs. < (since == elements are left out of both > > maps...?) > > > > Jared. > > > > On 2/8/09, Jared Updike wrote: > > > > > I would like to enumerate a subset of keys in a Map satisfying \ key > > > >= key1 && key <= key2 but in the expected, reasonable amount of time > > > (e.g. < O(log(n)) + O(m) for n total keys and m keys in the subset). > > > (Or key > key1 and/or key < key2 or some such combination). > > > > > > Is there an appropriate idiom or combination of library functions to > > > accomplish this, short of digging into the code for Data.Map and > > > writing such a function for a forked version of Data.Map? > > > > > > For example I could try something like a Set.split of a Set.split of > > > Map.keysSet of my original map, but will laziness magically do what I > > > really want? which is to walk down the tree to key1 (or the nearest > > > key > key1) and enumerate keys in order until key2 is reached? > > > > > > Data.Map almost looks like what I need if I can do this. > > > > > > > > > Jared. > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > > From jupdike at gmail.com Mon Feb 9 11:33:49 2009 From: jupdike at gmail.com (Jared Updike) Date: Mon Feb 9 11:23:37 2009 Subject: [Haskell-cafe] Data.Map: Enumerating ordered subset of keys In-Reply-To: <2518b95d0902082357w1b32d770u4de4d20f571629f3@mail.gmail.com> References: <8b108f950902082257o275a313dn4c2b19953c25abb@mail.gmail.com> <2518b95d0902082357w1b32d770u4de4d20f571629f3@mail.gmail.com> Message-ID: <8b108f950902090833s3ce2d3fbo41b02eb1658711f3@mail.gmail.com> On 2/8/09, Evan Laforge wrote: > I have a little util library with various map functions. 'within' is > almost what you want, except it's half-open. You can make an > inclusive one by pulling the lowest element off the above map. > > I'm also curious if there's a better way to do this... > > -- | Like Map.split, except include a matched key in the above map. > split_map :: (Ord k) => k -> Map.Map k a -> (Map.Map k a, Map.Map k a) > split_map k fm = (pre, post') > where > (pre, at, post) = Map.splitLookup k fm > post' = maybe post (\v -> Map.insert k v post) at > > -- | Split the map into the maps below, within, and above the given range. > -- @low@ to @high@ is half-open, as usual. > split3_map :: (Ord k) => k -> k -> Map.Map k a > -> (Map.Map k a, Map.Map k a, Map.Map k a) > split3_map low high fm = (below, within, way_above) > where > (below, above) = split_map low fm > (within, way_above) = split_map high above > > within low high fm = let (_, m, _) = split3_map low high fm in m This looks right to me (correct time complexity). It should do what I need. I will test it and see what I discover. Thanks, Jared. From marcot at holoscopio.com Mon Feb 9 11:36:24 2009 From: marcot at holoscopio.com (Marco =?ISO-8859-1?Q?T=FAlio?= Gontijo e Silva) Date: Mon Feb 9 11:26:11 2009 Subject: [Haskell-cafe] Error in building profiling In-Reply-To: <1233960935.26754.719.camel@localhost> References: <1233873511.18688.143.camel@quindinho.domain.invalid> <1233916123.18688.186.camel@quindinho.domain.invalid> <1233960935.26754.719.camel@localhost> Message-ID: <1234197384.10189.49.camel@quindinho.domain.invalid> Em Sex, 2009-02-06 ?s 22:55 +0000, Duncan Coutts escreveu: > On Fri, 2009-02-06 at 08:28 -0200, Marco T?lio Gontijo e Silva wrote: > > > > $ ./setup configure --enable-library-profiling --disable-library-vanilla > > > > /usr/bin/ld: dist/build/Control/Monad/Cont.o: No such file: No such file > > > or directory > > > > > > I'm using ghc6 6.10.1+dfsg1-5 and binutils 2.19-1~exp1. > > > > I tried the same with ghc6 6.8.2dfsg1-1 and it worked. > > Turns out I broke it in Cabal-1.4. It used to be that > --disable-library-vanilla implied --disable-library-for-ghci where as > they're now independent. > > Try the Cabal head branch now. Let me know if that fixes it for you. If > it does I'll push it to the Cabal-1.6 branch. I tried with the updated cabal and it's working. Thanks. -- marcot http://marcot.iaaeee.org/ From rendel at cs.au.dk Mon Feb 9 12:06:44 2009 From: rendel at cs.au.dk (Tillmann Rendel) Date: Mon Feb 9 11:56:53 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> Message-ID: <499062A4.7050306@cs.au.dk> Gregg Reynolds wrote:: > My original question was motivated by the observation that a human reader of > an expression of the form "e >>= f" , on seeing that f is constant, may pull > the constant value out of f, disregard e and dispense with the application f > e. While a human reader may well do that, but it would be correct or wrong depending on the definition of >>=. The same is of course true for compilers. By the way, there is no "application f e". An example where it would be wrong to ignore e: sum ([1, 2] >>= const [21]) This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21. There is nothing special with IO or >>=, so there is no need to introduce special cases for IO or >>= in a formal or informal semantics of Haskell. Tillmann From noteed at gmail.com Mon Feb 9 12:13:23 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 9 12:03:11 2009 Subject: [Haskell-cafe] how to use a literal string with bystring useAsCString Message-ID: <40a414c20902090913m163a81c7v621406300183a30f@mail.gmail.com> Hi, I have a Haskell source file encoded in utf-8. Inside that source, I have literal strings that I'd like to pass to a C function. withCString does the job well until I tried to use the double-quote character ". I get /usr/lib/ghc-6.10.1/ghc: `@: Bad font file format (even when using (chr 34) instead). I didn't understand the reason of this behavior (since the double quote is just ascii) but tried to use useAsCString but coudn't do it. I can ByteString.Char8.pack my string but the problem remains. I tried to use IConv but it uses UTF8.ByteString and I don't know how to make the conversion so I can use useAsCString or withCString. Any idea ? Thanks, Thu From dave at zednenem.com Mon Feb 9 12:23:19 2009 From: dave at zednenem.com (David Menendez) Date: Mon Feb 9 12:13:08 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> Message-ID: <49a77b7a0902090923o41a9330au1c97737b4840cb80@mail.gmail.com> 2009/2/9 Gregg Reynolds : > On Sun, Feb 8, 2009 at 6:25 PM, Richard O'Keefe wrote: >> >> On 6 Feb 2009, at 4:20 am, Gregg Reynolds wrote: >>> >>> However, consider: >>> >>> getChar >>= \x -> getChar >>> >>> An optimizer can see that the result of the first getChar is discarded >>> and replace the entire expression with one getChar without changing the >>> formal semantics. >> >> But the result of the first getChar is *NOT* discarded. >> **As an analogy**, think of the type IO t as (World -> (t,World)) >> for some hidden type World, and >> getChar w = (c, w') >> -- get a character c out of world w somehow, >> -- changing w to w' as you go >> (f >>= g) w = let (v,w') = f w in (g v) w' >> >> In this analogy, you see that the result of getChar is a value of >> type IO Char (not of type Char), and that while the character >> part of the result of performing the result of getChar may be >> discarded, the "changed world" part is NOT. > > That's an implementation detail. It doesn't account for other possible IO > implementations. > > My original question was motivated by the observation that a human reader of > an expression of the form "e >>= f" , on seeing that f is constant, may pull > the constant value out of f, disregard e and dispense with the application f > e. So can a compiler, unless IO expressions are involved, in which case > such optimizations are forbidden. I wondered if that was due to the > semantics of >>= or the semantics of IO. Neither. It's because the expression "e >>= f" is not "f e". As far as Haskell is concerned, >>= is just a higher-order function. You can't arbitrarily replace "foo bar (const baz)" with "baz", unless it turns out that foo = \x y -> y x. Perhaps you're thinking of the monad law, forall x f. return x >>= f = f x The presence of "return" is important. Among other things, there is no x such that getChar = return x. That's because getChar has (or, rather, causes when interpreted by the RTS) side-effects, whereas "return x" is pure. Here's some code you can try on your own: data IO a = Return a | Get (Char -> IO a) | Put Char (IO a) instance Monad IO where return = Return Return a >>= f = f a Get k >>= f = Get (\c -> k c >>= f) Put c k >>= f = Put c (k >>= f) getChar :: IO Char getChar = Get (\c -> Return c) putChar :: Char -> IO () putChar c = Put c (Return ()) Now, if the compiler sees "getChar >>= \_ -> getChar", it *can* optimize out the >>=. But the result would be "Get (\_ -> Get (\c -> Return c))", which is not equivalent to getChar. Neither IO semantics nor monad semantics are involved. -- Dave Menendez From g9ks157k at acme.softbase.org Mon Feb 9 12:32:46 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Mon Feb 9 12:22:42 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <49903964.3070304@henning-thielemann.de> References: <200902061603.29609.g9ks157k@acme.softbase.org> <49903964.3070304@henning-thielemann.de> Message-ID: <200902091832.47108.g9ks157k@acme.softbase.org> Am Montag, 9. Februar 2009 15:10 schrieben Sie: > I want for long to write math formulas in a paper in Haskell. Actually, > lhs2TeX can do such transformations but it is quite limited in handling > of parentheses and does not support more complicated transformations > (transforming prefix notation in infix notation or vice versa with > minimal parentheses). > > [?] > > I imagine some rule based configuration that is implemented using > haskell-src, that handles all identifiers, say, with prefix "parameter" > as wildcards: > > sumFor [parameterA..parameterB] (\parameterI -> parameterS) > => \sum_{parameterI=parameterA}^{parameterB} parameterS > > Unfortunately a tool for this transformation still has to be written, > but wouldn't that be really cool? The tool might be even relatively > simple, but the configuration is certainly non-trivial and it would have > to be hard-wired into cabal in order to provide identical rendering on > all systems and output formats (TeX or MathML). This reminds me of an idea which I had some time ago. The idea is to write all your documentation in Template Haskell, possibly using quasiquoting to support Haddock-like syntax. Then you could write math as ordinary Haskell expressions and embed these expressions into your documentation expressions. This would make the documentation language very extensible since you could always write your own extensions in the form of some Haskell code fragments or libraries. To build the documentation, one would run GHC with a special flag or whatever which makes the Template Haskell parts build HTML or whatever. Without the flag, the documentation code would do nothing. By using Template Haskell, one would have access to information about identifiers, types etc. A basic Haddock Haskell library could provide functions which use that information to build HTML or whatever from the actual documentation. These functions would then be used in the Template Haskell code. Does this make some sense? Best wishes, Wolfgang From newsham at lava.net Mon Feb 9 12:37:27 2009 From: newsham at lava.net (Tim Newsham) Date: Mon Feb 9 12:27:17 2009 Subject: [Haskell-cafe] Formal semantics for Haskell? In-Reply-To: <75cc17ac0902090806v377cbffare54bc0e851629fe@mail.gmail.com> References: <75cc17ac0902090806v377cbffare54bc0e851629fe@mail.gmail.com> Message-ID: > ML has a formal definition[1]; why not Haskell? Would this be a Good Thing, > or a Waste Of Time? Not exactly what you are asking for, but a start: http://www.cs.kent.ac.uk/pubs/1992/123/index.html > gregg Tim Newsham http://www.thenewsh.com/~newsham/ From dave at zednenem.com Mon Feb 9 12:41:38 2009 From: dave at zednenem.com (David Menendez) Date: Mon Feb 9 12:31:27 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902090457i755d6e2em39f271215a52c0a9@mail.gmail.com> References: <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCBBE@ELON17P32001A.csfb.cs-group.com> <75cc17ac0902090457i755d6e2em39f271215a52c0a9@mail.gmail.com> Message-ID: <49a77b7a0902090941g47be1b82x7ab3aecbc565b72c@mail.gmail.com> 2009/2/9 Gregg Reynolds : > > Right; "implementation of IO" means also an implementation for >>=, not just > the IO operators. I hadn't thought about that but it's hugely important for > the exposition of monads and IO. > > "The IO Char indicates that getChar, when invoked, performs some action > which returns a character." (Gentle Intro, typical of many expositions.) In this case, I think "invoked" is shorthand for "interpreted by the runtime system". > That, plus the form of \x -> putChar x used with >>=, plus the fact that one > can do getChar at the ghci command line, plus all the other stuff - it all > adds up to exasperation. It's worth noting that ghci, unlike Haskell itself, *does* treat IO specially. It checks the type of the expression you've entered, and behaves differently depending on whether it's equal to a, IO a, or IO (). interp[ e :: IO () ] = e interp[ e :: IO a ] = e >>= print interp[ e :: a ] = print e This is convenient for users, but it has nothing to do with the semantics of Haskell. -- Dave Menendez From dons at galois.com Mon Feb 9 12:44:49 2009 From: dons at galois.com (Don Stewart) Date: Mon Feb 9 12:35:12 2009 Subject: [Haskell-cafe] Efficient string output In-Reply-To: <87ljsf4yq6.fsf@malde.org> References: <87ljsf4yq6.fsf@malde.org> Message-ID: <20090209174449.GC936@whirlpool.galois.com> ketil: > > Hi, > > I'm currently working on a program that parses a large binary file and > produces various textual outputs extracted from it. Simple enough. > > But: since we're talking large amounts of data, I'd like to have > reasonable performance. > > Reading the binary file is very efficient thanks to Data.Binary. > However, output is a different matter. Currently, my code looks > something like: > > summarize :: Foo -> ByteString > summarize f = let f1 = accessor f > f2 = expression f > : > in B.concat [f1,pack "\t",pack (show f2),...] > > which isn't particularly elegant, and builds a temporary ByteString > that usually only get passed to B.putStrLn. I can suffer the > inelegance were it only fast - but this ends up taking the better part > of the execution time. Why not use Data.Binary for output too? It is rather efficient at output -- using a continuation-like system to fill buffers gradually. -- Don From rendel at cs.au.dk Mon Feb 9 12:45:31 2009 From: rendel at cs.au.dk (Tillmann Rendel) Date: Mon Feb 9 12:35:39 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902090457i755d6e2em39f271215a52c0a9@mail.gmail.com> References: <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCBBE@ELON17P32001A.csfb.cs-group.com> <75cc17ac0902090457i755d6e2em39f271215a52c0a9@mail.gmail.com> Message-ID: <49906BBB.7020106@cs.au.dk> Hi Gregg, Gregg Reynolds wrote: > Right; "implementation of IO" means also an implementation for >>=, not just > the IO operators. I hadn't thought about that but it's hugely important for > the exposition of monads and IO. Indeed, that's very important. Note that the topics "monads in Haskell" and "IO in Haskell" can (and in my opinion should) be understood independently of each other. IO in Haskell is just an abstract data type, with a bunch of functions return :: a -> IO a bind :: IO a -> (a -> IO b) -> IO b getChar :: IO Char putChar :: a -> IO () ... A Haskell runtime system is a somewhat vaguely specified interpreter for (IO a) values. While it would be nice to a have a better specification of that interpreter, it is not part of the semantics of the language Haskell. > "The IO Char indicates that getChar, when invoked, performs some action > which returns a character." (Gentle Intro, typical of many expositions.) I guess that "invoked" here means really "interpreted by your Haskell implementation during its interpretation of the (IO a) your main function constructed". Tillmann From dons at galois.com Mon Feb 9 12:46:34 2009 From: dons at galois.com (Don Stewart) Date: Mon Feb 9 12:37:01 2009 Subject: [Haskell-cafe] Re: The Haskell re-branding exercise In-Reply-To: <499030E3.5000404@gmail.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> <9C2ED3B7-041E-42B6-95B8-76A3845E7961@gmail.com> <499030E3.5000404@gmail.com> Message-ID: <20090209174634.GD936@whirlpool.galois.com> marlowsd: > Sterling Clover wrote: >> IP based limitations are a terrible idea. Multiple users can be and >> often are behind the same IP if they're in some sort of intranet, be it >> corporate, academic, or simply multiple home computers. Mail-based >> authentication can be screwed with, sure, but it's also very easy to >> notice this (as opposed to ip nonsense) through simply eyeballing the >> results. There's no general everywhere way to prevent vote fraud. >> However, if we make it even require a mild bit of thought, that should >> be sufficient in this case, as there won't be enough votes to prevent >> some sort of rough eyeball-based check of the results, and if there >> are, then that's a sign of fraud for sure! Furthermore, there's very >> little incentive for someone to go the extra mile here, as we're voting >> for a haskell logo, and not, e.g., giving away ten thousand dollars. >> Furthermore, since I assume we'll only be presenting reasonable logos, >> there's not even some room for pranksters to stage a "write-in" of some >> gag slogan. > > I suggest we do voting by email, and restrict voting to those who have > ever posted on haskell-cafe before 1 Jan 2009. We could then have an > auto-confirmation scheme similar to mailing list sign-up where the > confirmation message is sent back to the originator to confirm their > identity, containing a verification link to click on. > > I realise there are flaws in this, but it seems to be (a) cheap to > implement and participate in, and (b) good enough. Seems good enough. Who's going to tally the votes? From wasserman.louis at gmail.com Mon Feb 9 13:10:45 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Mon Feb 9 13:00:34 2009 Subject: [Haskell-cafe] Control.Arrow being icky Message-ID: In GHCi, I import Control.Arrow, and Kliesli doesn't appear: Prelude Control.Arrow> :t Kliesli :1:0: Not in scope: data constructor `Kliesli' Prelude Control.Arrow> :browse (<<^) :: (Arrow a) => a c d -> (b -> c) -> a b d (>>^) :: (Arrow a) => a b c -> (c -> d) -> a b d class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') class (Arrow a) => ArrowApply a where app :: a (a b c, b) c class (Arrow a) => ArrowChoice a where left :: a b c -> a (Either b d) (Either c d) right :: a b c -> a (Either d b) (Either d c) (+++) :: a b c -> a b' c' -> a (Either b b') (Either c c') (|||) :: a b d -> a c d -> a (Either b c) d class (Arrow a) => ArrowLoop a where loop :: a (b, d) (c, d) -> a b c newtype (ArrowApply a) => ArrowMonad a b = ArrowMonad (a () b) class (ArrowZero a) => ArrowPlus a where (<+>) :: a b c -> a b c -> a b c class (Arrow a) => ArrowZero a where zeroArrow :: a b c newtype Kleisli m a b = Kleisli {runKleisli :: a -> m b} (^<<) :: (Arrow a) => (c -> d) -> a b c -> a b d (^>>) :: (Arrow a) => (b -> c) -> a c d -> a b d leftApp :: (ArrowApply a) => a b c -> a (Either b d) (Either c d) returnA :: (Arrow a) => a b b (<<<) :: (Control.Category.Category cat) => cat b c -> cat a b -> cat a c (>>>) :: (Control.Category.Category cat) => cat a b -> cat b c -> cat a c Does anybody know what's going on? Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/07a83da6/attachment.htm From wagner.andrew at gmail.com Mon Feb 9 13:13:50 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Mon Feb 9 13:03:39 2009 Subject: [Haskell-cafe] Control.Arrow being icky In-Reply-To: References: Message-ID: It's spelled 'Kleisli'. You spelled it 'Kliesli' 2009/2/9 Louis Wasserman > In GHCi, I import Control.Arrow, and Kliesli doesn't appear: > Prelude Control.Arrow> :t Kliesli > > :1:0: Not in scope: data constructor `Kliesli' > Prelude Control.Arrow> :browse > (<<^) :: (Arrow a) => a c d -> (b -> c) -> a b d > (>>^) :: (Arrow a) => a b c -> (c -> d) -> a b d > class (Control.Category.Category a) => Arrow a where > arr :: (b -> c) -> a b c > first :: a b c -> a (b, d) (c, d) > second :: a b c -> a (d, b) (d, c) > (***) :: a b c -> a b' c' -> a (b, b') (c, c') > (&&&) :: a b c -> a b c' -> a b (c, c') > class (Arrow a) => ArrowApply a where app :: a (a b c, b) c > class (Arrow a) => ArrowChoice a where > left :: a b c -> a (Either b d) (Either c d) > right :: a b c -> a (Either d b) (Either d c) > (+++) :: a b c -> a b' c' -> a (Either b b') (Either c c') > (|||) :: a b d -> a c d -> a (Either b c) d > class (Arrow a) => ArrowLoop a where > loop :: a (b, d) (c, d) -> a b c > newtype (ArrowApply a) => ArrowMonad a b = ArrowMonad (a () b) > class (ArrowZero a) => ArrowPlus a where > (<+>) :: a b c -> a b c -> a b c > class (Arrow a) => ArrowZero a where zeroArrow :: a b c > newtype Kleisli m a b = Kleisli {runKleisli :: a -> m b} > (^<<) :: (Arrow a) => (c -> d) -> a b c -> a b d > (^>>) :: (Arrow a) => (b -> c) -> a c d -> a b d > leftApp :: (ArrowApply a) => a b c -> a (Either b d) (Either c d) > returnA :: (Arrow a) => a b b > (<<<) :: > (Control.Category.Category cat) => cat b c -> cat a b -> cat a c > (>>>) :: > (Control.Category.Category cat) => cat a b -> cat b c -> cat a c > > Does anybody know what's going on? > > Louis Wasserman > wasserman.louis@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/8bec92e5/attachment.htm From mail at justinbogner.com Mon Feb 9 13:16:25 2009 From: mail at justinbogner.com (mail@justinbogner.com) Date: Mon Feb 9 13:06:31 2009 Subject: [Haskell-cafe] Re: Control.Arrow being icky References: Message-ID: <87tz73cw7a.fsf@justinbogner.com> Louis Wasserman writes: > In GHCi, I import Control.Arrow, and Kliesli doesn't appear: > Prelude Control.Arrow> :t Kliesli > > :1:0: Not in scope: data constructor `Kliesli' It's spelled `Kleisli' From dev at mobileink.com Mon Feb 9 12:54:38 2009 From: dev at mobileink.com (gregg reynolds) Date: Mon Feb 9 13:07:06 2009 Subject: [Haskell-cafe] Formal semantics for Haskell? Message-ID: <427h7hp9y9t34enetqonq3g1.1234203424902@email.android.com> Is that () or _|_? ;) Tim Newsham wrote: >null From noteed at gmail.com Mon Feb 9 13:20:31 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 9 13:10:21 2009 Subject: [Haskell-cafe] Re: how to use a literal string with bystring useAsCString In-Reply-To: <40a414c20902090913m163a81c7v621406300183a30f@mail.gmail.com> References: <40a414c20902090913m163a81c7v621406300183a30f@mail.gmail.com> Message-ID: <40a414c20902091020u56aae918u9fe74711fa9046a8@mail.gmail.com> 2009/2/9 minh thu : > Hi, > > I have a Haskell source file encoded in utf-8. > Inside that source, I have literal strings that I'd > like to pass to a C function. > > withCString does the job well until I tried to use > the double-quote character ". I get > /usr/lib/ghc-6.10.1/ghc: `@: Bad font file format > (even when using (chr 34) instead). > > I didn't understand the reason of this behavior (since > the double quote is just ascii) but > tried to use useAsCString but coudn't do it. > I can ByteString.Char8.pack my string but the problem > remains. I tried to use IConv but it uses UTF8.ByteString > and I don't know how to make the conversion so I can > use useAsCString or withCString. Bulat asked me a minimal example. I cannot come with the same behavior with ghc --make and the attached code. Maybe it is showed inside ghci. Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1). How can do this ? -------------- next part -------------- A non-text attachment was scrubbed... Name: Literal.hs Type: text/x-haskell Size: 840 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/4055b698/Literal.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: literal.c Type: text/x-csrc Size: 69 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/4055b698/literal.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: literal.h Type: text/x-chdr Size: 25 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/4055b698/literal-0001.bin From colinpauladams at googlemail.com Mon Feb 9 13:28:09 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Mon Feb 9 13:17:58 2009 Subject: [Haskell-cafe] Re: how to use a literal string with bystring useAsCString In-Reply-To: <40a414c20902091020u56aae918u9fe74711fa9046a8@mail.gmail.com> References: <40a414c20902090913m163a81c7v621406300183a30f@mail.gmail.com> <40a414c20902091020u56aae918u9fe74711fa9046a8@mail.gmail.com> Message-ID: <1afdeaec0902091028s63dcc9a5sb10264dba6b03633@mail.gmail.com> 2009/2/9 minh thu : > > Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1). > > How can do this ? You can't (in general). If the data just happens to be ascii, then your utf-8 string will BE ascii (there is no way to tell the difference). If it just happens to be in the range of latin-1(all codepoints 0-255), then you have to convert it to latin-1. But otherwise, you are stuck. From apfelmus at quantentunnel.de Mon Feb 9 13:40:30 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Mon Feb 9 13:29:45 2009 Subject: [Haskell-cafe] Re: Haddock Markup In-Reply-To: <49903964.3070304@henning-thielemann.de> References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> <49903964.3070304@henning-thielemann.de> Message-ID: Henning Thielemann wrote: > > I want for long to write math formulas in a paper in Haskell. Actually, > lhs2TeX can do such transformations but it is quite limited in handling > of parentheses and does not support more complicated transformations > (transforming prefix notation in infix notation or vice versa with > minimal parentheses). > > I would like to write > sumFor [0..n] (\i -> i^2) > (with sumFor xs f = sum $ map f xs) > which is rendered as > \sum_{i=0}^{n} i^2 > or > integrate 1000 (a,b) (\t -> f t) > to be rendered as > \int_a^b f(t) \dif t Neat idea! Can't you do implement this as a DSL? sumFor x xs f = "\sum_{" ++ x ++ "=" ++ head xs ++ "}^{" ++ last xs ++ "} " ++ f x Regards, apfelmus -- http://apfelmus.nfshost.com From noteed at gmail.com Mon Feb 9 13:58:36 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 9 13:48:24 2009 Subject: [Haskell-cafe] Re: how to use a literal string with bystring useAsCString In-Reply-To: <1afdeaec0902091028s63dcc9a5sb10264dba6b03633@mail.gmail.com> References: <40a414c20902090913m163a81c7v621406300183a30f@mail.gmail.com> <40a414c20902091020u56aae918u9fe74711fa9046a8@mail.gmail.com> <1afdeaec0902091028s63dcc9a5sb10264dba6b03633@mail.gmail.com> Message-ID: <40a414c20902091058p5980302as93fbe9cd84d92593@mail.gmail.com> 2009/2/9 Colin Adams : > 2009/2/9 minh thu : > >> >> Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1). >> >> How can do this ? > > You can't (in general). > If the data just happens to be ascii, then your utf-8 string will BE > ascii (there is no way to tell the difference). If it just happens to > be in the range of latin-1(all codepoints 0-255), then you have to > convert it to latin-1. But otherwise, you are stuck. That's what I thought, but in the code attached before, the output of the program is not what is expected, i.e. I have : 0xb7d7e018 0xb7d7e040 Why ? Thu From noteed at gmail.com Mon Feb 9 14:52:52 2009 From: noteed at gmail.com (minh thu) Date: Mon Feb 9 14:42:41 2009 Subject: [Haskell-cafe] Re: how to use a literal string with bystring useAsCString In-Reply-To: <40a414c20902091058p5980302as93fbe9cd84d92593@mail.gmail.com> References: <40a414c20902090913m163a81c7v621406300183a30f@mail.gmail.com> <40a414c20902091020u56aae918u9fe74711fa9046a8@mail.gmail.com> <1afdeaec0902091028s63dcc9a5sb10264dba6b03633@mail.gmail.com> <40a414c20902091058p5980302as93fbe9cd84d92593@mail.gmail.com> Message-ID: <40a414c20902091152t7b59c852taf431dbddd26c739@mail.gmail.com> 2009/2/9 minh thu : > 2009/2/9 Colin Adams : >> 2009/2/9 minh thu : >> >>> >>> Anyway, I'd like to get my utf-8 string to C but in ascii (or latin1). >>> >>> How can do this ? >> >> You can't (in general). >> If the data just happens to be ascii, then your utf-8 string will BE >> ascii (there is no way to tell the difference). If it just happens to >> be in the range of latin-1(all codepoints 0-255), then you have to >> convert it to latin-1. But otherwise, you are stuck. > > That's what I thought, but in the code attached before, the output of > the program is not what is expected, i.e. I have : > 0xb7d7e018 > 0xb7d7e040 > Why ? > > Thu > Sorry, in both case, it's a mistake on my side. In particular, in the attached code, I call 'print' instead of 'c_print'. Thu From john at n-brain.net Mon Feb 9 16:31:29 2009 From: john at n-brain.net (John A. De Goes) Date: Mon Feb 9 16:21:22 2009 Subject: [Haskell-cafe] Re: Haskell and Java interaction References: <51C4C342-186D-4894-BF19-DC82122CA33D@n-brain.net> Message-ID: <9874FF0F-F05F-460B-8A0F-586BC79BC1A3@n-brain.net> The bridging projects are all dead and unsupported. You can still do it, but you'll have to write Haskell wrappers that use C types, then write C code that calls the wrapped Haskell code, then write JNI code to call the C code from Java. http://www.haskell.org/haskellwiki/Calling_Haskell_from_C There was a promising thesis project called LambdaVM that allowed you to compile Haskell to JVM byte codes, but it suffered the same fate as all thesis projects. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On Feb 9, 2009, at 8:56 AM, Silviu ANDRICA wrote: > Hello, > I was wondering if there is a way to call Haskell code from Java. I > tried using jvm-bridge(http://sourceforge.net/projects/jvm-bridge/), > but I'm stuck on building it. > > Thank you very much, > Silviu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/5cf839ea/attachment.htm From newhoggy at gmail.com Mon Feb 9 16:35:25 2009 From: newhoggy at gmail.com (John Ky) Date: Mon Feb 9 16:25:16 2009 Subject: [Haskell-cafe] Why does sleep not work? Message-ID: Hi Haskell Cafe, I wrote very short program to sleep for 5 seconds compiled with the -threaded option in ghc on the Mac OS X 1.5. I am finding that using the sleep function doesn't sleep at all, whereas using threadDelay does: main = do putStrLn "Waiting for 5 seconds." threadDelay 5000000 -- works putStrLn "Done." main = do putStrLn "Waiting for 5 seconds." sleep 5 -- doesn't sleep at all putStrLn "Done." Anybody know what's happening? Thanks -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/c8ae1aa7/attachment.htm From agocorona at gmail.com Mon Feb 9 16:53:35 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Mon Feb 9 16:43:25 2009 Subject: [Haskell-cafe] Formal semantics for Haskell? In-Reply-To: <427h7hp9y9t34enetqonq3g1.1234203424902@email.android.com> References: <427h7hp9y9t34enetqonq3g1.1234203424902@email.android.com> Message-ID: Gregg,Too late for me, but, anyway. I support the idea of the warning 2009/2/9 gregg reynolds > Is that () or _|_? ;) > > Tim Newsham wrote: > > >null > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/6f658df1/attachment.htm From bulat.ziganshin at gmail.com Mon Feb 9 16:54:52 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Mon Feb 9 16:45:02 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: <1334368195.20090210005452@gmail.com> Hello John, Tuesday, February 10, 2009, 12:35:25 AM, you wrote: > I am finding that using the sleep function doesn't sleep at all, whereas using threadDelay does: > Anybody know what's happening? 1) this depends on your sleep definition 2) read threadDelay docs -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From robgreayer at yahoo.com Mon Feb 9 16:58:50 2009 From: robgreayer at yahoo.com (Robert Greayer) Date: Mon Feb 9 16:48:38 2009 Subject: [Haskell-cafe] Haskell and Java interaction References: <49905238.9050507@epfl.ch> Message-ID: <866129.97508.qm@web65706.mail.ac4.yahoo.com> I'm sure this isn't the solution you are looking for, but when I had to do something similar (integrate an Eclipse plugin to Haskell code) the simplest approach I found was to simply invoke the Haskell in a separate process, binding the stdin/stdout of the Haskell process to Java output/input streams. Perhaps low-tech, but has worked well for me. ----- Original Message ---- From: Silviu ANDRICA To: "haskell-cafe@haskell.org" Sent: Monday, February 9, 2009 10:56:40 AM Subject: [Haskell-cafe] Haskell and Java interaction Hello, I was wondering if there is a way to call Haskell code from Java. I tried using jvm-bridge(http://sourceforge.net/projects/jvm-bridge/), but I'm stuck on building it. Thank you very much, Silviu _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe From bugfact at gmail.com Mon Feb 9 16:59:34 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Mon Feb 9 16:49:26 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: Hi John, Which sleep are you using? From which module? Can you show the full source with import statements? Cheers, Peter 2009/2/9 John Ky > Hi Haskell Cafe, > > I wrote very short program to sleep for 5 seconds compiled with the > -threaded option in ghc on the Mac OS X 1.5. > > I am finding that using the sleep function doesn't sleep at all, whereas > using threadDelay does: > > main = do > putStrLn "Waiting for 5 seconds." > threadDelay 5000000 -- works > putStrLn "Done." > > main = do > putStrLn "Waiting for 5 seconds." > sleep 5 -- doesn't sleep at all > putStrLn "Done." > > Anybody know what's happening? > > Thanks > > -John > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/e7f67bcb/attachment.htm From mail at joachim-breitner.de Mon Feb 9 17:55:29 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon Feb 9 17:44:22 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree Message-ID: <1234220129.5358.131.camel@localhost> Hi, I have a problem that, it seems, I can not solve cleanly without resorting to imperative programming (via ST): Assume you have a tree (and you can think of a real tree here), defined by something like this: data Tree a = Bud | Branch a Double Tree Tree -- | ` Lenght of this branch -- ` General storage field for additional information Now, I have a nice algorithm that calulates something for each branch, but it only works on lists of branches, so I have to cut them apart first, remembering their position in space, and then work on these, well, logs. data Point = Point Double Double data Log = Log Point Point type Info = ... noInfo :: Info cutTreeApart :: Tree a -> [(Log, a)] someAlgorithm :: [(Log,a)] -> [(a, Info)] Conveniently, the algorithm allows me to tag the logs with something, to be able to keep track at least somewhat of the logs. Unfortunately, I need this information in the storage field in my Tree, as the list of logs is not sufficient for later calculations. Idea: Using ST ============== annotateTree :: Tree a -> Tree Info annotateTree tree = runSt $ do -- Put an STRef in each node treeWithPointer <- mapM const (newSTRef noInfo) tree -- Cut this tree apart let logsWithPointers = cutTreeApart treeWithPointer -- Run the algorithm let informations = someAlgorithm logsWithPointers -- Put the information back, via the ST ref mapM (\(stRef, info) -> writeSTRef stRef info) informations -- Read the ST refs mapM readIORef tree Note that I assume a instance Traversable Tree here, and mapM is Data.Traversable.mapM. Now while this works, and while ST is still somewhat pure, I?m wondering if there is no better way of expressing "This piece of information came from the point in a data structure, so something else can be put here easily". Some ideas where numbering the Nodes and then using this number as the tag on the log, but this is not much different from using STRefs, it seems. Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/790d63f8/attachment.bin From newhoggy at gmail.com Mon Feb 9 18:39:03 2009 From: newhoggy at gmail.com (John Ky) Date: Mon Feb 9 18:28:57 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: Hi Peter, Source code: import System.IO import System.Posix main = do putStrLn "Waiting for 5 seconds." sleep 5 -- doesn't sleep at all putStrLn "Done." OS: Mac OS X 10.5 Compile command: ghc --threaded testsleep.hs If I remove --threaded, then it does sleep. Thanks, -John On Tue, Feb 10, 2009 at 8:59 AM, Peter Verswyvelen wrote: > Hi John, > Which sleep are you using? From which module? Can you show the full source > with import statements? > > Cheers, > Peter > > 2009/2/9 John Ky > >> Hi Haskell Cafe, >> >> I wrote very short program to sleep for 5 seconds compiled with the >> -threaded option in ghc on the Mac OS X 1.5. >> >> I am finding that using the sleep function doesn't sleep at all, whereas >> using threadDelay does: >> >> main = do >> putStrLn "Waiting for 5 seconds." >> threadDelay 5000000 -- works >> putStrLn "Done." >> >> main = do >> putStrLn "Waiting for 5 seconds." >> sleep 5 -- doesn't sleep at all >> putStrLn "Done." >> >> Anybody know what's happening? >> >> Thanks >> >> -John >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/2098a581/attachment.htm From lrpalmer at gmail.com Mon Feb 9 18:41:08 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Mon Feb 9 18:30:55 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <1234220129.5358.131.camel@localhost> References: <1234220129.5358.131.camel@localhost> Message-ID: <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> 2009/2/9 Joachim Breitner > Now while this works, and while ST is still somewhat pure, I'm wondering > if there is no better way of expressing "This piece of information came > from the point in a data structure, so something else can be put here > easily". You might want to look into zippers: http://haskell.org/haskellwiki/Zipper Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/04e68e81/attachment.htm From egallego at babel.ls.fi.upm.es Mon Feb 9 18:50:06 2009 From: egallego at babel.ls.fi.upm.es (Emilio =?utf-8?Q?Jes=C3=BAs?= Gallego Arias) Date: Mon Feb 9 18:40:19 2009 Subject: [Haskell-cafe] Re: Monad explanation References: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> Message-ID: <87ljsf9nm9.fsf@babel.ls.fi.upm.es> Gregg Reynolds writes: > But it can't be a function, since it is non-deterministic. IMHO, if you assume IO a = World -> (World, a), then getChar is indeed a function and deterministic. It is, there are not w :: World such that getChar w != getChar. The fact that World is too big to be represented in Haskell and we use IO to simulate it is a different matter. With regard to your original question, I like to keep in mind that arrow composition in the Kleisli category (>>= in Haskell) is defined in terms of the monad's join :: m (m a) -> m a. Then, the question is, how many ways can you map an IO (IO a) to an IO a? You will find that you cannot ignore the inner (first) IO in order to obey monad laws. Regards, Emilio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/b165595b/attachment.bin From egallego at babel.ls.fi.upm.es Mon Feb 9 19:07:00 2009 From: egallego at babel.ls.fi.upm.es (Emilio =?utf-8?Q?Jes=C3=BAs?= Gallego Arias) Date: Mon Feb 9 18:57:06 2009 Subject: [Haskell-cafe] Re: Monad explanation References: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> <87ljsf9nm9.fsf@babel.ls.fi.upm.es> Message-ID: <878wof9mu3.fsf@babel.ls.fi.upm.es> egallego@babel.ls.fi.upm.es (Emilio Jes?s Gallego Arias) writes: > IMHO, if you assume IO a = World -> (World, a), then getChar is indeed a > function and deterministic. It is, there are not w :: World such that > getChar w != getChar. Sorry I meant: There is not w :: World such that getChar w != getChar w. From lists at qseep.net Mon Feb 9 19:54:15 2009 From: lists at qseep.net (Lyle Kopnicky) Date: Mon Feb 9 19:44:05 2009 Subject: [Haskell-cafe] Haskell Fest Message-ID: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> Looks like a lot of fun! http://www.haskellchamber.com/page6.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/7d3ee2ce/attachment.htm From ok at cs.otago.ac.nz Mon Feb 9 20:19:21 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Feb 9 20:09:15 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> References: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> Message-ID: <3F7C027E-A274-4ACC-A04F-DACE0EE523FA@cs.otago.ac.nz> On 10 Feb 2009, at 12:24 am, Gregg Reynolds wrote: > My bad, I restate: a value cannot be both static and dynamic. It's not clear what you mean here, but in what sense are "static" values not a subset of "dynamic" ones? > Or an object and a morphism. Crack open any book on category theory and you will discover that an object CAN be a morphism. Not only can the morphisms of one category be objects of another, but you can build a category where the objects and the morphisms are the same things. > Or an element and a function. An element of _what_? Functions can be elements of sets. Mathematicians routinely deal with function spaces. If you mean that F : S -> S cannot be an element of S, then if you mean a set theoretic function, no, but a Scott domain *can* contain the continuous functions over itself. > Sure, you can treat a morphism as an object, but only by moving to > a higher (or different) level of abstraction. False as a generalisation about mathematics. False about functional programming languages, the very essence of which is treating functions ("morphisms") as values ("objects") exactly like any other values. > That doesn't erase the difference between object and morphism. There is no intrinsic difference between objects and morphisms. It's what you DO with something that makes it an object or a morphism (or both). > If you do erase that difference you end up with mush. getChar / > looks/ like an object, but semantically it must be a morphism. getChar is an element of an abstract data type in Haskell. PERIOD. Since a morphism is characterised by its source and target objects, and since getChar is not so characterised, in what sense is getChar a morphism? *Within Haskell*, getChar is just some value. For all you or I can tell to the contrary, it might be the letter 'G' or a JPEG image of the planet Mars. It's only as part of a whole system of IO primitives in the context of Haskell that the value is interpreted as a description of the "read a character from standard input" action. > But it can't be a function, since it is non-deterministic. No it isn't. getChar is perfectly deterministic. Whenever you ask for the value of getChar, you get the *same* value. Evaluating getChar does no input whatever. If you compute map (\_ -> getChar) [1..n] you get a list containing n copies of the value of getChar, and NO INPUT WHATSOEVER happens. > So actually the logical contradiction comes from the nature of the > beast. There is no logical contradiction because you have mistaken the nature of the beast. > > Another reason it's confusing to newcomers: it's typed as "IO > Char", which looks like a type constructor. Surely "IO" and "Char" are type constructors, and "Char" and "IO Char" are types. > One would expect getChar to yield a value of type IO Char, no? Yes, that's EXACTLY what it does. The only thing the expression (getChar) ever gives you is an (abstract) value of type IO Char. > But it delivers a Char instead. No it doesn't. getChar delivers, always and only, a value of type IO Char. Call that value Gamaliel. When Gamaliel is *performed* by the Haskell environment, *then* a character is read (the action) and returned. But it's Gamaliel that delivers a Char, not getChar. > This is way confusing. Composer (Haskell program) writes score (computes getChar). Performer (Haskell environment) sings score (performs Gamaliel). Sound happens (a character is read). > So I take "type IO foo" to mean "type foo, after a side effect". No. Mistake not: there COULD be a type system not unlike that. Look up "effect systems". Haskell's is not one of them. By the way, (return 'x') has type IO Char, but never has any side effects. Type "IO foo" can be usefully read as meaning "descriptions of actions that when carried out also yield a value of type foo". > In a sense "getChar :: IO Char" isn't even a true type signature. Yes it is. It is exactly and perfectly true. Have you actually read the classic paper "How to declare an imperative", P. Wadler, ACM Computing Surveys 29, 3 (1997). For me, this was more helpful than any tutorial on monads and monadic I/O that I ever read. > From vanenkj at gmail.com Mon Feb 9 20:35:50 2009 From: vanenkj at gmail.com (John Van Enk) Date: Mon Feb 9 20:25:45 2009 Subject: [Haskell-cafe] Haskell Fest In-Reply-To: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> References: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> Message-ID: Pie auction and contest? Count me in! /jve 2009/2/9 Lyle Kopnicky > Looks like a lot of fun! > > http://www.haskellchamber.com/page6.html > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/0d149442/attachment.htm From wagner.andrew at gmail.com Mon Feb 9 20:38:40 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Mon Feb 9 20:28:31 2009 Subject: [Haskell-cafe] Haskell Fest In-Reply-To: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> References: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> Message-ID: We believe in Haskell! 2009/2/9 Lyle Kopnicky > Looks like a lot of fun! > > http://www.haskellchamber.com/page6.html > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/a3e8ede8/attachment.htm From derek.a.elkins at gmail.com Mon Feb 9 20:44:33 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Mon Feb 9 20:34:29 2009 Subject: [Haskell-cafe] Haskell Fest In-Reply-To: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> References: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> Message-ID: <1234230273.21515.0.camel@derek-laptop> On Mon, 2009-02-09 at 16:54 -0800, Lyle Kopnicky wrote: > Looks like a lot of fun! > > http://www.haskellchamber.com/page6.html I could readily go there. Maybe I could pick up a beauty at the pageant. From ok at cs.otago.ac.nz Mon Feb 9 20:47:58 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Feb 9 20:37:49 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> References: <75cc17ac0902041320pa4b9b52rab866494ad746153@mail.gmail.com> <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> Message-ID: On 9 Feb 2009, at 9:56 pm, Gregg Reynolds wrote: > Here's an analogy that will make the logical contradiction clear. > Forget computers and assume you have been asked to referee a paper > containing a proof with the following passage: > > Let x = ___ (Please fill in the blank) > > I think you will agree that would be plainly nonsensical. It's > logically equivalent to an input operation ("getInt"). No, I do not agree that it would be nonsensical at all. Why shouldn't a paper describe a family of proofs? (paper :: Int -> Proof) > Now back to computers. Given a program text containing the symbol > '3', the computer will provide a physical representation: an > electromagnetic pattern in a bit of silicon. That's a value; the > pattern is to be interpreted as a datum; it is not to be executed. Who says? It is part of the essence of the stored program computer that the *same* bit pattern may be computed as numbers and executed as code. There have certainly been virtual machines where the bit pattern for the character '+' meant, when executed, ADD. > For "getChar", the computer will also provide such a pattern, but > this pattern is to be interpreted as executable code, not as a datum. "The computer" here must be understood as "The composite of a physical machine, HAL/BIOS/whatever-maybe, hypervisor-maybe, operating system- maybe, Haskell compiler, and Haskell libraries. (Yes, I know that I am oversimplifying.) The expression (getChar) may be represented by executable code, but then, Haskell being lazy, so may the expression (1+1) be represented by executable code. Your problem seems to be based on two fundamental assumptions: (1) there is an intrinsic difference between code and data, (2) evaluating getChar reads a character. Neither assumption is true. Code and data are interchangeable. Evaluating getChar yields (without any side effects) a value, let's call it Gamaliel, and it is the environment's performance of Gamaliel that reads a character. So you are seeing a difference when there is none, and not seeing one where there is one. > Now suppose we also have an ordinary function like "Add2"; it too > will be represented as an electromagnetic pattern, to be interpreted > as executable code. *AND* as data. Ever heard of genetic programming? Genetic programming is a form of evolutionary computing where members of the population are functions. Koza's original book used lisp-style trees to represent these functions (so something was at one and the same time a tree resulting from genetic operations and used as input to genetic operations) and executable code. There have been many variations of the idea since then. Nowadays some GP systems represent functions by native machine code. In such systems, native machine code is - the result of genetic operators - data that is input to genetic operators - native code to be executed all in the same program within a single "generation". > getChar and Add2 are not data, except in the trivial sense that > all code is data. The sense in which all code is data is far from trivial. It's what makes things like Windows *possible*. (Try to imagine booting Windows by plugging wires into a city-sized backplane!) It's certainly what makes Genetic Programming possible. The interesting thing here is that since getChar need not be a function, its representation inside a computer need not be machine code. > In all three cases, the symbolic representation is isomorphic to the > physical representation. Eh? This is a very strong and extremely dubious claim. > The 3 will not be executed. Who says? I once used (and still love) a computer which had Zero and One instructions. I don't see why you couldn't have a Three instruction. > When Add2 is executed, the ensuing process is isomorphic to the > mathematical function so defined. The *process* is isomorphic to the *function*? I think not. > But when getChar is executed, the ensuing process is not > isomorphic to a mathematical function. Yes it is. You are confusing two very different things here: Executing (getChar). Performing the result of (getChar). For what it's worth, the analogue of getChar in Clean and Mercury *is* a mathematical function. > The process interacts with the non-mathematical world, which a > mathematical function can never do. But a mathematical function can *describe* that process, and a computing engine can have its interactions governed by such a description. And that's what Haskell does. > So it has a side effect along with its ordinary representational > effect. No. [The result of] (getChar) is a pure mathematical value. (It might be or contain a function, but it need not. It could be the number 42 in drag.) When the Haskell environment does what that [result] says to do, then reading happens. But the computation of (getChar) and the reading are DIFFERENT events (notionally) carried out by DIFFERENT execution engines and happening at DIFFERENT times. > The point being that the metalanguage commonly used to describe IO > in Haskell contains a logical contradiction. No, you have read a contradiction into it, but the contradiction is not there. > A thing cannot be both a value and a function, Yes it can. ALL functions are values. > but e,g, getChar behaves like a function and has the type signature > of a value. getChar behaves like a value. You can evaluate getChar 500 million times and not one character will be read. > I believe this is part of the reason the IO monad is troublesome > for beginners (I speak from experience). When I read the "How to declare an imperative" paper, I fell about laughing. It was so *simple*, and yet, so astronomically far from anything I could have invented. When you have understood that there really isn't anything magical about getChar (and there most CERTAINLY isn't anything remotely resembling a contradiction or inconsistency or type incorrectness), you will have begun to understand monads. From ok at cs.otago.ac.nz Mon Feb 9 20:56:43 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Feb 9 20:47:08 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902091319.42566.g9ks157k@acme.softbase.org> References: <5540a5470902061024hce004b6l48a99d3aa4e587e4@mail.gmail.com> <200902071546.25957.alexey.skladnoy@gmail.com> <200902091319.42566.g9ks157k@acme.softbase.org> Message-ID: <609F806E-4EF2-4115-A54D-F3C88C640727@cs.otago.ac.nz> On 10 Feb 2009, at 1:19 am, Wolfgang Jeltsch wrote: > This is only true if your destination format is PDF, DVI or PS. For > a webpage, > you?ll need MathML in the end and TeX is not so good in producing > MathML, I > suppose. Hmm. I find designed-for-HTML documentation horrible. In many ways the current Haddock output is the worst of both worlds: it is inconvenient for on-screen viewing and doesn't exploit paper very well either. Amongst other things, people who are learning a library package need overviews, examples, conceptual models, all sorts of details, whereas people who already know them mainly need reminders, for which web pages are well suited. I would point out that you DON'T need MathML for a web page, because a PDF document can *be* a web page. You can link to one, you can display it in your browser, and it may contain links to other pages. Especially if one can download a tolerably full snapshot of the library and all its documentation, updating this at rare intervals, PDF-on-the-local-host suits me much better than HTML-on-the-Web. From ok at cs.otago.ac.nz Mon Feb 9 21:37:58 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Feb 9 21:27:49 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> Message-ID: <0C42DFC1-E530-42F4-9574-C10D730AD53D@cs.otago.ac.nz> On 10 Feb 2009, at 1:35 am, Gregg Reynolds wrote: > My original question was motivated by the observation that a human > reader of an expression of the form "e >>= f" , on seeing that f is > constant, may pull the constant value out of f, disregard e and > dispense with the application f e. There isn't any "application f e". Any human reader who does that is simply WRONG to do so. > So can a compiler, unless IO expressions are involved, in which > case such optimizations are forbidden. Remember that (e >>= f) means (>>=) e f. When/whether it is sound to replace (>>=) e f by (f undefined) depends on the semantics of >>=. But >>= is an operation of a type class (the Monad type class). If we come across g :: Monad m => m a -> b -> m b g e r = e >>= \x -> return r then the compiler doesn't know what m is, so it doesn't know which, if any, of its arguments >>= depends on. data Trivial x = Trivial x instance Monad Trivial where return = Trivial (>>=) (Trivial a) f = f a If we now try h :: Trivial a -> b -> Trivial b h e r = g e r then the compiler can inline the call to g h e r = e >>= \x -> return r and inline the calls to >>= and return h (Trivial a) r = (\x -> Trivial r) a then simplify to h (Trivial _) r = Trivial r You might have thought that the result doesn't depend on the first argument to h, but as written, it does. This version of h is strict in its first argument, so even though there are NO side effects whatever, the first argument will be evaluated to weak head normal form. Of course, since there is only one constructor for Trivial, it could be a newtype. If I change that declaration to newtype Trivial x = Trivial x then the pattern match is implicitly irrefutable, h ~(Trivial _) r = Trivial r and if the compiler doesn't simplify ~(NTC _) to _ when NTC is a newtype constructor, I'll be surprised, so it's like h _ r = Trivial r and the function will *NOT* be strict in its first argument. Here you see that the soundness or otherwise of eliminating the first argument of >>= when the second argument doesn't depend on the eventual result has nothing to do with IO as such and certainly nothing to do with side effects. It's really all about whether the version of >>= used is strict in its first argument or not. > I wondered if that was due to the semantics of >>= or the > semantics of IO. It's about the semantics of IO's implementation of >>=. > > > To summarize what I've concluded thanks to the helpful people on > haskell-cafe: > > The compiler can optimize e >>= f except for any IO expressions in e > and f. False. There is nothing unusual about IO here. > IO expressions must be evaluated, due to the semantics of IO. False. > The may not be disregarded, memoized, or substituted. False. In Haskell there is nothing whatever unusual about expressions of type IO something. They *MAY* be disregarded: let n = length [getChar, putChar 'f'] can be optimised to let n = 2. They MAY be memoised. They MAY be substituted. > IO semantics may be implemented in different ways by different > compilers; True. But then, so may Int semantics. > these implementation techniques are not part of the formal semantics > of the language, which may be expressed as above: IO expressions > must be evaluated wherever and whenever they occur. False. Utterly false. > > > The bind operator >>= enforces sequencing on arguments containing IO > expressions, but does not force evaluation. False. For the special case of IO (and for other similar monads) >>= enforced sequence BY forcing evaluation (more precisely, by being strict in its first argument). > Even bind expressions involving IO may be optimized. For example: > > getChar >>= \x -> ...... putChar 'c' > > The compiler may discard (assuming it contains > no IO expressions), but it must evaluate getChar and putChar (due to > IO semantics) in the correct order (due to bind semantics). You are conflating *evaluating* (by the Haskell evaluator) with *performance* (by the Haskell environment). IO *values* are determined by the Haskell evaluator exactly like any other values; IO *actions* are performed by the Haskell environment as part of the process of forcing the lazy evaluator to do some work. In your fragmentary example, may be discarded EVEN IF it contains IO expressions, it's only if they are linked into the IO chain using >> and/or >>= that the environment will perform their values. > > > Thanks all, > > gregg From DekuDekuplex at Yahoo.com Mon Feb 9 21:40:13 2009 From: DekuDekuplex at Yahoo.com (Benjamin L.Russell) Date: Mon Feb 9 21:30:04 2009 Subject: [Haskell-cafe] Re: Haskell Fest References: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> Message-ID: <62q1p4ljr399d4guus2g2heqhqalod88f9@4ax.com> On Mon, 9 Feb 2009 16:54:15 -0800, Lyle Kopnicky wrote: >Looks like a lot of fun! > >http://www.haskellchamber.com/page6.html They should extend this by adding the domain Virtualhaskellcounty (see http://whois.domaintools.com/virtualhaskellcounty.com) so we can all participate! -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^ From dev at mobileink.com Mon Feb 9 22:15:38 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 22:05:25 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <499062A4.7050306@cs.au.dk> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <499062A4.7050306@cs.au.dk> Message-ID: <75cc17ac0902091915w6d7c7813q79b638e7e6628694@mail.gmail.com> On Mon, Feb 9, 2009 at 11:06 AM, Tillmann Rendel wrote: > Gregg Reynolds wrote:: > >> My original question was motivated by the observation that a human reader >> of >> an expression of the form "e >>= f" , on seeing that f is constant, may >> pull >> the constant value out of f, disregard e and dispense with the application >> f >> e. >> > > While a human reader may well do that, but it would be correct or wrong > depending on the definition of >>=. The same is of course true for > compilers. By the way, there is no "application f e". > I guess it would help if I got the notation right. My intended meaning was f* e, where * is the Kleisli star. Sorry about that. > > > An example where it would be wrong to ignore e: > > sum ([1, 2] >>= const [21]) > > This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21. > Sigh. I hate it when this happens. Just when I thought I had it figured out, it turns out I'm clueless. This is very enlightening and should definitely be included in any monad tutorial. Actually you don't even need "sum" and "const" to demo the point, "[1,2] >>= \x -> [21]" evals to "[21, 21]" in ghci. And I have absolutely no idea why. Very mysterious, the Kleisli star. :( Back to the drawing board! -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/09bf09bc/attachment.htm From dev at mobileink.com Mon Feb 9 23:07:41 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Mon Feb 9 22:57:29 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <0C42DFC1-E530-42F4-9574-C10D730AD53D@cs.otago.ac.nz> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <0C42DFC1-E530-42F4-9574-C10D730AD53D@cs.otago.ac.nz> Message-ID: <75cc17ac0902092007vcff5edci8394c31c936d20d9@mail.gmail.com> On Mon, Feb 9, 2009 at 8:37 PM, Richard O'Keefe wrote: > > There isn't any "application f e". > Any human reader who does that is simply WRONG to do so. > Sorry, should have written f* > > In your fragmentary example, may be discarded > EVEN IF it contains IO expressions, it's only if they are linked into > the IO chain using >> and/or >>= that the environment will perform > their values. > Thanks. I see the error of my ways. So, IO expressions must be evaluated if they are in the chain leading to main. -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090209/419eb2d7/attachment.htm From ok at cs.otago.ac.nz Mon Feb 9 23:17:06 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Mon Feb 9 23:06:56 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902092007vcff5edci8394c31c936d20d9@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <0C42DFC1-E530-42F4-9574-C10D730AD53D@cs.otago.ac.nz> <75cc17ac0902092007vcff5edci8394c31c936d20d9@mail.gmail.com> Message-ID: On 10 Feb 2009, at 5:07 pm, Gregg Reynolds wrote: > Thanks. I see the error of my ways. So, IO expressions must be > evaluated if they are in the chain leading to main. We need some standard terminology to distinguish between *evaluating* an expression and *performing* the result of an expression of type IO something. An IO expression that is passed to a function at a strict position must be evaluated whether the result is performed or not. An IO expression whose result will be performed must be evaluated before that performance can take place. (Dash it, this really is getting us into White Knight land.) From dave at zednenem.com Mon Feb 9 23:30:01 2009 From: dave at zednenem.com (David Menendez) Date: Mon Feb 9 23:19:48 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902091915w6d7c7813q79b638e7e6628694@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <499062A4.7050306@cs.au.dk> <75cc17ac0902091915w6d7c7813q79b638e7e6628694@mail.gmail.com> Message-ID: <49a77b7a0902092030n565ba1d1k61a541c8829741bd@mail.gmail.com> 2009/2/9 Gregg Reynolds : > On Mon, Feb 9, 2009 at 11:06 AM, Tillmann Rendel wrote: >> >> Gregg Reynolds wrote:: >>> >>> My original question was motivated by the observation that a human reader >>> of >>> an expression of the form "e >>= f" , on seeing that f is constant, may >>> pull >>> the constant value out of f, disregard e and dispense with the >>> application f >>> e. >> >> While a human reader may well do that, but it would be correct or wrong >> depending on the definition of >>=. The same is of course true for >> compilers. By the way, there is no "application f e". > > I guess it would help if I got the notation right. My intended meaning was > f* e, where * is the Kleisli star. Sorry about that. You can't assume f* is a constant function just because f is. In fact, in most monads (excluding Identity and Reader) f* is never constant. >> An example where it would be wrong to ignore e: >> >> sum ([1, 2] >>= const [21]) >> >> This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21. > > Sigh. I hate it when this happens. Just when I thought I had it figured > out, it turns out I'm clueless. This is very enlightening and should > definitely be included in any monad tutorial. Actually you don't even need > "sum" and "const" to demo the point, "[1,2] >>= \x -> [21]" evals to "[21, > 21]" in ghci. And I have absolutely no idea why. Very mysterious, the > Kleisli star. :( Here are two ways to think about it. First, you can decompose the Kleisli star into two operations. That is, for a monad T with multiplication mu, f* = mu . T f Or in Haskell notation, (f =<<) = join . fmap f For the list monad, join is concat and fmap is map. So we have, [1,2] >>= \x -> [21] = concat (map (\x -> [21])) [1,2] = concat [[21],[21]] = [21,21] Second, in the list monad, we have a distributive law relating mplus and >>=. mplus x y >>= f = mplus (x >>= f) (y >>= f) We can rewrite [1,2] >>= \x -> [21] as mplus (return 1) (return 2) >>= \x -> return 21 then we can distribute >>=, mplus (return 1 >>= \x -> return 21) (return 2 >>= \x -> return 21) then by the monad laws, mplus (return 21) (return 21) -- Dave Menendez From wren at freegeek.org Mon Feb 9 23:52:31 2009 From: wren at freegeek.org (wren ng thornton) Date: Mon Feb 9 23:42:20 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902091915w6d7c7813q79b638e7e6628694@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <499062A4.7050306@cs.au.dk> <75cc17ac0902091915w6d7c7813q79b638e7e6628694@mail.gmail.com> Message-ID: <4991080F.4070403@freegeek.org> Gregg Reynolds wrote: > Tillmann Rendel wrote: > > An example where it would be wrong to ignore e: > > > > sum ([1, 2] >>= const [21]) > > > > This expression should evaluate to sum [21, 21] = 42, not sum [21] = 21. > > > > Sigh. I hate it when this happens. Just when I thought I had it figured > out, it turns out I'm clueless. This is very enlightening and should > definitely be included in any monad tutorial. Actually you don't even need > "sum" and "const" to demo the point, "[1,2] >>= \x -> [21]" evals to "[21, > 21]" in ghci. And I have absolutely no idea why. Very mysterious, the > Kleisli star. :( Just walk through the evaluation step by step, it's not so mysterious. [1,2] >>= \x -> [21] == {CT definition of bind} join . fmap (\x -> [21]) $ [1,2] == join [(\x -> [21]) 1, (\x -> [21]) 2] == join [[21],[21]] == [21,21] Or if you prefer to use the Haskell function definitions instead of the category theory definitions (it's all the same): [1,2] >>= \x -> [21] == concatMap (\x -> [21]) [1,2] == concat . map (\x -> [21]) $ [1,2] == concat [(\x -> [21]) 1, (\x -> [21]) 2] == concat [[21],[21]] == [21,21] This is exactly the point I was raising earlier. The "statefullness" of monads has nothing to do with IO, but every monad has some of it. In general it is wrong to throw it away just because the function passed to bind happens to ignore the value associated with it. There are some cases where that can be correct, but in general it is not. For lists, we can envision the statefullness as a path through a decision tree. To get the intuition right, it's easiest to pretend that we never call join (or that join does nothing). If we don't call join, eventually after a number of binds or maps we'll end up with some value of type [[...[a]...]]. We can draw that value out as a B-tree where each level has a branch of whatever arity it needs. In this B-tree, every leaf is associated with a unique path through the tree and therefore they can be distinguished. The reason the above example works the way it does is that the initial list has two leaves each associated with their unique paths through this tree of choices. The function passed into bind is a continuation of sorts. So, given that we can non-deterministically choose either of the paths in the original tree, for each choice we must then continue with (\x -> [21]) applied to the seed value for that choice (1 or 2, as appropriate). Because we had two choices initially, and from there we have only one choice, we will have 2*1 choices in the end: /\ / \ (1) (2) | | | | 21 21 If we imagine a finite state automaton, we might think that the two 21s could be collapsed together since they represent the same "state". But that is not so: the list monad is for *paths* through an FSA not for states in an FSA. (For states in an FSA we'd want the set monad instead.) Of course for the list monad we don't actually keep around the decision tree. In fact lists generalize over all possible decision trees which could yield the given distribution of path-endpoints, so it's not quite the way envisioned above. -- Live well, ~wren From bjpop at csse.unimelb.edu.au Tue Feb 10 00:53:56 2009 From: bjpop at csse.unimelb.edu.au (Bernie Pope) Date: Tue Feb 10 00:44:05 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <49906BBB.7020106@cs.au.dk> References: <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> <16442B752A06A74AB4D9F9A5FF076E4B4DCBBE@ELON17P32001A.csfb.cs-group.com> <75cc17ac0902090457i755d6e2em39f271215a52c0a9@mail.gmail.com> <49906BBB.7020106@cs.au.dk> Message-ID: On 10/02/2009, at 4:45 AM, Tillmann Rendel wrote: > > A Haskell runtime system is a somewhat vaguely specified interpreter > for (IO a) values. While it would be nice to a have a better > specification of that interpreter, it is not part of the semantics > of the language Haskell. While not "official", there is always "Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell" by Simon Peyton Jones. https://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/ Another nice aspect of that paper is that it discusses some of the difficulties in coming up with a denotation for values of type IO a, see particularly section 3.1. It suggests a set of event traces as a possible way forward: type IO a = (a, Set Trace) type Trace = [Event] data Event = PutChar Char | GetChar Char | ... (Incidentally, this view is quite useful in a declarative debugger, which emphasises the denotational semantics of a program.) In the end the paper goes for an operational semantics, on the grounds that the author finds it "simpler and easier to understand". Cheers, Bernie. From iavor.diatchki at gmail.com Tue Feb 10 01:50:42 2009 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue Feb 10 01:40:27 2009 Subject: [Haskell-cafe] lazy evaluation is not complete In-Reply-To: <49904981.4090202@functor.nl> References: <4990394E.8020409@udo.edu> <49904981.4090202@functor.nl> Message-ID: <5ab17e790902092250s20ab719by648ca3b554d45886@mail.gmail.com> Hi, Just for fun, here is the code that does this: newtype Int' = I Int deriving Eq instance Show Int' where show (I x) = show x instance Num Int' where I x + I y = I (x + y) I 0 * _ = I 0 I x * I y = I (x * y) I x - I y = I (x - y) abs (I x) = I (abs x) signum (I x) = I (signum x) negate (I x) = I (negate x) fromInteger n = I (fromInteger n) foo x = if x == 0 then 0 else foo (x - 1) * foo (x + 1) *Main> foo 5 :: Int' 0 -Iavor On Mon, Feb 9, 2009 at 7:19 AM, Jochem Berndsen wrote: > Peter Padawitz wrote: >> A simplied version of Example 5-16 in Manna's classical book >> "Mathematical Theory of Computation": >> >> foo x = if x == 0 then 0 else foo (x-1)*foo (x+1) >> >> If run with ghci, foo 5 does not terminate, i.e., Haskell does not look >> for all outermost redices in parallel. Why? For efficiency reasons? >> >> It's a pity because a parallel-outermost strategy would be complete. > > (*) is strict in both arguments for Int. If you want to avoid this, you > could do > newtype X = X Int > and write your own implementation of (*) that is nonstrict. > > -- > Jochem Berndsen | jochem@functor.nl > GPG: 0xE6FABFAB > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From max.rabkin at gmail.com Tue Feb 10 01:57:58 2009 From: max.rabkin at gmail.com (Max Rabkin) Date: Tue Feb 10 01:47:47 2009 Subject: [Haskell-cafe] lazy evaluation is not complete In-Reply-To: <5ab17e790902092250s20ab719by648ca3b554d45886@mail.gmail.com> References: <4990394E.8020409@udo.edu> <49904981.4090202@functor.nl> <5ab17e790902092250s20ab719by648ca3b554d45886@mail.gmail.com> Message-ID: On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki wrote: > I 0 * _ = I 0 > I x * I y = I (x * y) Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's what we need here, but it means that the "obviously correct" transformation of > foo x = if x == 0 then 0 else foo (x - 1) * foo (x + 1) into foo' x = if x == 0 then 0 else foo' (x + 1) * foo' (x - 1) is *not* in fact correct. --Max From tom.davie at gmail.com Tue Feb 10 02:03:51 2009 From: tom.davie at gmail.com (Thomas Davie) Date: Tue Feb 10 01:53:41 2009 Subject: [Haskell-cafe] lazy evaluation is not complete In-Reply-To: References: <4990394E.8020409@udo.edu> <49904981.4090202@functor.nl> <5ab17e790902092250s20ab719by648ca3b554d45886@mail.gmail.com> Message-ID: On 10 Feb 2009, at 07:57, Max Rabkin wrote: > On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki > wrote: >> I 0 * _ = I 0 >> I x * I y = I (x * y) > > Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's > what we need here, but it means that the "obviously correct" > transformation of just to improve slightly: I 0 |* _ = I 0 I x |* I y = I (x * y) _ *| I 0 = I 0 I x *| I y = I (x * y) I x * | y = (I x |* I y) `unamb` (I x *| I y) Now it is commutative :) Bob From anotheraddress at gmx.de Tue Feb 10 02:46:31 2009 From: anotheraddress at gmx.de (Daniel =?iso-8859-1?q?Sch=FCssler?=) Date: Tue Feb 10 02:36:33 2009 Subject: [Haskell-cafe] ANN: convertible (first release) Message-ID: <200902100846.31761.anotheraddress@gmx.de> Hi, On Wednesday 28 January 2009 04:30:07 John Goerzen wrote: > On Tue, Jan 27, 2009 at 09:41:30PM -0500, wren ng thornton wrote: > > I once again point out that realToFrac is *wrong* for converting from > > Float or Double. > > > > > realToFrac (1/0::Float) ::Double > > > > 3.402823669209385e38 > > Yes, I understand what you are saying and agree with you. But there > is nothing better in the standard library don't know whether you consider GHC as standard library, but if you do...: import GHC.Types import GHC.Prim -- | Double to Float d2f (D# d) = F# (double2Float# d) -- | Float to Double f2d (F# f) = D# (float2Double# f) ghci> f2d (1/0) Infinity it :: Double :) -- Daniel From porges at porg.es Tue Feb 10 02:52:11 2009 From: porges at porg.es (George Pollard) Date: Tue Feb 10 02:42:25 2009 Subject: [Haskell-cafe] lazy evaluation is not complete In-Reply-To: References: <4990394E.8020409@udo.edu> <49904981.4090202@functor.nl> <5ab17e790902092250s20ab719by648ca3b554d45886@mail.gmail.com> Message-ID: <1234252331.6758.1.camel@porges-laptop> On Tue, 2009-02-10 at 08:03 +0100, Thomas Davie wrote: > On 10 Feb 2009, at 07:57, Max Rabkin wrote: > > > On Mon, Feb 9, 2009 at 10:50 PM, Iavor Diatchki > > wrote: > >> I 0 * _ = I 0 > >> I x * I y = I (x * y) > > > > Note that (*) is now non-commutative (w.r.t. _|_). Of course, that's > > what we need here, but it means that the "obviously correct" > > transformation of > > just to improve slightly: > > I 0 |* _ = I 0 > I x |* I y = I (x * y) > > _ *| I 0 = I 0 > I x *| I y = I (x * y) > > I x * | y = (I x |* I y) `unamb` (I x *| I y) > > Now it is commutative :) > > Bob See `parCommute` from the 'lub' package :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/17ed7760/attachment.bin From porges at porg.es Tue Feb 10 03:02:47 2009 From: porges at porg.es (George Pollard) Date: Tue Feb 10 02:52:39 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: <1234252967.6758.5.camel@porges-laptop> I can confirm this behaviour, on: Linux 2.6.27-11-generic #1 SMP i686 GNU/Linux Difference in the RTS between non-working and working: ("RTS way", "rts_thr") ("RTS way", "rts") - George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/0918548a/attachment.bin From g9ks157k at acme.softbase.org Tue Feb 10 03:16:33 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 10 03:06:28 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <609F806E-4EF2-4115-A54D-F3C88C640727@cs.otago.ac.nz> References: <200902091319.42566.g9ks157k@acme.softbase.org> <609F806E-4EF2-4115-A54D-F3C88C640727@cs.otago.ac.nz> Message-ID: <200902100916.33357.g9ks157k@acme.softbase.org> Am Dienstag, 10. Februar 2009 02:56 schrieben Sie: > On 10 Feb 2009, at 1:19 am, Wolfgang Jeltsch wrote: > > This is only true if your destination format is PDF, DVI or PS. For > > a webpage, you?ll need MathML in the end and TeX is not so good in > > producing MathML, I suppose. > > Hmm. I find designed-for-HTML documentation horrible. I did *not* want to argue pro ?designed-for-HTML?. I wanted to argue contra ?designed-for-PDF? and pro ?designed-for-any-output-format?. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Tue Feb 10 03:21:48 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Tue Feb 10 03:11:46 2009 Subject: [Haskell-cafe] Haskell and Java interaction In-Reply-To: <866129.97508.qm@web65706.mail.ac4.yahoo.com> References: <49905238.9050507@epfl.ch> <866129.97508.qm@web65706.mail.ac4.yahoo.com> Message-ID: <200902100921.48245.g9ks157k@acme.softbase.org> Am Montag, 9. Februar 2009 22:58 schrieb Robert Greayer: > I'm sure this isn't the solution you are looking for, but when I had to do > something similar (integrate an Eclipse plugin to Haskell code) the > simplest approach I found was to simply invoke the Haskell in a separate > process, binding the stdin/stdout of the Haskell process to Java > output/input streams. Perhaps low-tech, but has worked well for me. For communication between Haskell software and Eclipse, there is also Cohatoe (). Interally, it works similar to what you described, as far as I know. Best wishes, Wolfgang From mail at joachim-breitner.de Tue Feb 10 03:55:29 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Feb 10 03:44:27 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> Message-ID: <1234256129.4115.7.camel@localhost> Hi, Am Montag, den 09.02.2009, 16:41 -0700 schrieb Luke Palmer: > 2009/2/9 Joachim Breitner > Now while this works, and while ST is still somewhat pure, I'm > wondering > if there is no better way of expressing "This piece of > information came > from the point in a data structure, so something else can be > put here > easily". > > You might want to look into zippers: > http://haskell.org/haskellwiki/Zipper I thought about Zippers, but I understand that they improve _navigating_ in a Tree-like structure, or to refrence _one_ position in a tree. But if I would deconstruct my tree to the list of _all_ locations, with > type Loc a = (Tree a, Cxt a) and then run my algorithm that returns [(Loc a, Info)], it?s still not clear to me how I can combine all of these locations to get back my original Tree, annotated with the Info returned. Thanks nevertheless, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/2d3d3c79/attachment.bin From noteed at gmail.com Tue Feb 10 04:02:56 2009 From: noteed at gmail.com (minh thu) Date: Tue Feb 10 03:52:43 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <1234256129.4115.7.camel@localhost> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> <1234256129.4115.7.camel@localhost> Message-ID: <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> 2009/2/10 Joachim Breitner : > Hi, > > Am Montag, den 09.02.2009, 16:41 -0700 schrieb Luke Palmer: >> 2009/2/9 Joachim Breitner >> Now while this works, and while ST is still somewhat pure, I'm >> wondering >> if there is no better way of expressing "This piece of >> information came >> from the point in a data structure, so something else can be >> put here >> easily". >> >> You might want to look into zippers: >> http://haskell.org/haskellwiki/Zipper > > I thought about Zippers, but I understand that they improve _navigating_ > in a Tree-like structure, or to refrence _one_ position in a tree. > > But if I would deconstruct my tree to the list of _all_ locations, with >> type Loc a = (Tree a, Cxt a) > and then run my algorithm that returns [(Loc a, Info)], it's still not > clear to me how I can combine all of these locations to get back my > original Tree, annotated with the Info returned. I guess I just repeat your last praragraph of your original mail but it seems to me you can mapAccump some 'names' on the tree, process an association list (or an IntMap) of the (name,log) then map the three again using the result. In spirits, it's the same thing than the STRef solution but it seems cleaner to me. Cheers, Thu From noteed at gmail.com Tue Feb 10 04:05:59 2009 From: noteed at gmail.com (minh thu) Date: Tue Feb 10 03:55:45 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> <1234256129.4115.7.camel@localhost> <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> Message-ID: <40a414c20902100105t2fb6ec82h4126cdcfbf4a542@mail.gmail.com> 2009/2/10 minh thu : > 2009/2/10 Joachim Breitner : >> Hi, >> >> Am Montag, den 09.02.2009, 16:41 -0700 schrieb Luke Palmer: >>> 2009/2/9 Joachim Breitner >>> Now while this works, and while ST is still somewhat pure, I'm >>> wondering >>> if there is no better way of expressing "This piece of >>> information came >>> from the point in a data structure, so something else can be >>> put here >>> easily". >>> >>> You might want to look into zippers: >>> http://haskell.org/haskellwiki/Zipper >> >> I thought about Zippers, but I understand that they improve _navigating_ >> in a Tree-like structure, or to refrence _one_ position in a tree. >> >> But if I would deconstruct my tree to the list of _all_ locations, with >>> type Loc a = (Tree a, Cxt a) >> and then run my algorithm that returns [(Loc a, Info)], it's still not >> clear to me how I can combine all of these locations to get back my >> original Tree, annotated with the Info returned. > > I guess I just repeat your last praragraph of your original mail but it seems > to me you can mapAccump some 'names' on the tree, process an > association list (or an IntMap) of the (name,log) then map the three > again using the result. > In spirits, it's the same thing than the STRef solution but it seems > cleaner to me. I forgot to mention you can try to tie the knot too, using the result of the processing in the first mapping (and then you don't need the second one)... From oleg at okmij.org Tue Feb 10 04:37:03 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Tue Feb 10 04:28:43 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree Message-ID: <20090210093703.870B3AB11@Adric.metnet.fnmoc.navy.mil> If I understand you correctly, the problem is to annotate an already constructed tree with arbitrary pieces of new data -- hopefully without reconstructing the tree. Perhaps the approach used in the FLOLAC type-checkers would be helpful. The `tree' was an expression in lambda-calculus to type check. The new annotations are the reconstructed types, of each node in the tree (of each sub-expression). I wanted to annotate each sub-expression with its reconstructed type -- without re-defining the data type of expressions or rebuilding the tree. The expression should stay as it was, I merely want to associate, after the fact, additional pieces of data with each node. I also wanted the code to be pure and avoid STRefs let alone StableNames and any IO. Here are the files in question: http://okmij.org/ftp/Computation/FLOLAC/TEvalNC.hs http://okmij.org/ftp/Computation/FLOLAC/TEvalNR.hs TEvalNC.hs is the ordinary type checker for the simply-typed lambda calculus with constants and the fix-point. The type reconstructor (aka, non-standard, abstract evaluator) has this type teval :: TEnv -> Term -> Typ Given the type environment and a term, it returns its inferred type (or reports an error). The file TEvalNR.hs returns not only the reconstructed type of the term but also the types of all the subterms. The latter data are returned in a `virtual' typed AST -- virtual because the original AST is not modified and the inferred types are attached to AST nodes, well, virtually. Generally speaking, after a simple modification teval could be made total: it would return reconstructed types of the subterms even if the entire term is ill-typed. That modification was one of the exercises. The intention was to model OCaml -- which, given a special flag, can dump the inferred types of all sub-expressions, even if the overall type checking failed. In Emacs and vi, one can highlight an expression or variable and see its inferred type. If the type checking failed, one can still explore what the type checker did manage to infer. From mail at joachim-breitner.de Tue Feb 10 04:59:59 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Feb 10 04:48:46 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <40a414c20902100105t2fb6ec82h4126cdcfbf4a542@mail.gmail.com> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> <1234256129.4115.7.camel@localhost> <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> <40a414c20902100105t2fb6ec82h4126cdcfbf4a542@mail.gmail.com> Message-ID: <1234259999.4115.23.camel@localhost> Hi, Am Dienstag, den 10.02.2009, 10:05 +0100 schrieb minh thu: > I forgot to mention you can try to tie the knot too, using the result > of the processing in the first mapping (and then you don't need the > second one)... could you elaborate who to tie that particular knot? I unfortunately, I don?t see it. Thanks, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/a6050496/attachment.bin From apfelmus at quantentunnel.de Tue Feb 10 05:59:22 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Tue Feb 10 05:48:29 2009 Subject: [Haskell-cafe] Re: Painting logs to get a coloured tree In-Reply-To: <1234220129.5358.131.camel@localhost> References: <1234220129.5358.131.camel@localhost> Message-ID: Joachim Breitner wrote: > > Assume you have a tree (and you can think of a real tree here), defined > by something like this: > > data Tree a = Bud | Branch a Double Tree Tree > -- | ` Lenght of this branch > -- ` General storage field for additional information > > Now, I have a nice algorithm that calulates something for each branch, > but it only works on lists of branches, so I have to cut them apart > first, remembering their position in space, and then work on these, > well, logs. > > data Point = Point Double Double > data Log = Log Point Point > type Info = ... > noInfo :: Info > > cutTreeApart :: Tree a -> [(Log, a)] > someAlgorithm :: [(Log,a)] -> [(a, Info)] > > Conveniently, the algorithm allows me to tag the logs with something, to > be able to keep track at least somewhat of the logs. > > [...] > > Some ideas where numbering the Nodes and then using this number as the > tag on the log, but this is not much different from using STRefs, it > seems. Yes, tagging the logs with their position in the tree isn't really different from using STRefs. There are many options for representing positions (depth/breath first numbers; paths like [L,R,L,...] etc.) but in the end, it boils down to the same thing. Here's an example with with numbers annotate tree = thread tree (\(x:xs) -> (x,xs)) . map snd . sort (comparing fst) . someAlgorithm . cutTreeApart . thread tree (\n -> (n, succ n)) $ (0 :: Int) where thread tree f x = evalState (mapM (const $ State f) tree) x However, I would be surprised if someAlgorithm could not be formulated directly on the tree or at least satisfies a few invariants like for example map fst . someAlgorithm = map snd Also, how does cutTreeApart arrange the list? The idea is that most of the tree structure survives in the list and can be reconstructed. Regards, apfelmus -- http://apfelmus.nfshost.com From lemming at henning-thielemann.de Tue Feb 10 06:35:27 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 10 06:18:11 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902091832.47108.g9ks157k@acme.softbase.org> References: <200902061603.29609.g9ks157k@acme.softbase.org> <49903964.3070304@henning-thielemann.de> <200902091832.47108.g9ks157k@acme.softbase.org> Message-ID: <4991667F.5010100@henning-thielemann.de> Wolfgang Jeltsch schrieb: > This reminds me of an idea which I had some time ago. The idea is to write all > your documentation in Template Haskell, possibly using quasiquoting to > support Haddock-like syntax. Then you could write math as ordinary Haskell > expressions and embed these expressions into your documentation expressions. > This would make the documentation language very extensible since you could > always write your own extensions in the form of some Haskell code fragments > or libraries. If Template Haskell is capable of such processing that we be great since we wouldn't need to develop a new tool, but can concentrate on writing the transformations to TeX, MathML and so on. And if someone wants to include chemical formulas he may write appropriate transformations himself, upload them to Hackage, and cabal will be able to install them when needed. Everything becomes scalable, extensible, flexible and everything becomes great. Even versioning conflicts will become possible for documentation generation. :-) From bugfact at gmail.com Tue Feb 10 06:28:43 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Tue Feb 10 06:18:35 2009 Subject: [Haskell-cafe] Darcs 2.2.0 diff on Windows Message-ID: When using this inside the Windows command prompt (CMD.EXE) I get darcs: diff: runInteractiveProcess: does not exist (No such file or directory) It works fine under MSYS. Also when using --diff-command to launch a GUI diff tool, Darcs does not seem to copy any changes the GUI tool did to the "new-program". Is this intended behavior? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/b6309ec6/attachment.htm From lemming at henning-thielemann.de Tue Feb 10 06:39:59 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue Feb 10 06:22:16 2009 Subject: [Haskell-cafe] Re: Haddock Markup In-Reply-To: References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> <49903964.3070304@henning-thielemann.de> Message-ID: <4991678F.6020401@henning-thielemann.de> Heinrich Apfelmus schrieb: > Henning Thielemann wrote: >> I want for long to write math formulas in a paper in Haskell. Actually, >> lhs2TeX can do such transformations but it is quite limited in handling >> of parentheses and does not support more complicated transformations >> (transforming prefix notation in infix notation or vice versa with >> minimal parentheses). >> >> I would like to write >> sumFor [0..n] (\i -> i^2) >> (with sumFor xs f = sum $ map f xs) >> which is rendered as >> \sum_{i=0}^{n} i^2 >> or >> integrate 1000 (a,b) (\t -> f t) >> to be rendered as >> \int_a^b f(t) \dif t > > Neat idea! Can't you do implement this as a DSL? > > sumFor x xs f = > "\sum_{" ++ x ++ "=" ++ head xs ++ "}^{" ++ last xs ++ "} " > ++ f x My original idea was to use the formulas in papers both for typesetting and for unit testing. Thus, when you state that a function fulfills a law, that it can be automatically tested by QuickCheck, that this at least true for some instances. The same would be useful for Haddock documentation. I remember that someone proposed to permit Haddock to expose the implementation of some functions as examples or as unit-tests/laws. Now we could extend this idea to allow Haddock not only to expose the implementation of functions, but also to tell Haddock how to render its implementation. From briqueabraque at yahoo.com Tue Feb 10 06:32:49 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Feb 10 06:22:49 2009 Subject: [Haskell-cafe] Additonal types for Foreign.C.Types Message-ID: Hi, After reading an ISO draft for standard C, I found a few types that could be usefull when binding to libraries (these are from ): int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t What about if they were included in the next version of GHC Foreign.C.Types module? For instance, as: CInt8, CUInt8, CInt16 etc. Some libraries (e.g. sqlite) define function parameters that are supposed to always have a given size (e.g., sqlite defines sqlite3_int64). In order to have a portable binding to those libraries, it would be nice to have types in Haskell that also offer that guarantee. There are also a few other nice types, although I'm not sure they belong to standard modules. If they did, however, they could make life easier for those people writing higher level Haskell modules after standard C functions: complex, float complex, double complex (from ) are used in functions like ccos, csin, cexp, csqrt etc. struct lconv (from ) struct tm (from ) From and : mbstate_t, wint_t, wctrans_t, wctype_t. Do you think I could open a ticket for GHC proposing that? Best, Maur?cio From dev at mobileink.com Tue Feb 10 06:38:30 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Tue Feb 10 06:28:18 2009 Subject: [Haskell-cafe] Haskell Fest In-Reply-To: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> References: <670e468e0902091654g3726eaacra9a8664890285b4d@mail.gmail.com> Message-ID: <75cc17ac0902100338l51069328pd733a865eac499b1@mail.gmail.com> Just be careful. The judge uses lazy evaluation, so if you get arrested you might spend 20 years in the holding pen. On the bright side, you can pay for stuff whenever you feel like it. 2009/2/9 Lyle Kopnicky > Looks like a lot of fun! > > http://www.haskellchamber.com/page6.html > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/aa50051b/attachment.htm From agocorona at gmail.com Tue Feb 10 08:16:08 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue Feb 10 08:05:56 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <3410468369.20090205182759@gmail.com> <75cc17ac0902050746i7eba3defj9b3ea70b7621223b@mail.gmail.com> Message-ID: forwarded: Yes! if no state is passed, the optimization makes sense and the term is not executed, like any lazy evaluation. For example, I used the debugger (that is, without optimizations) to verify it with the Maybe monad: op x= x+x print $ Just (op 1) >>= \y-> return (Just 2) does not evaluate op 1 but print $ Just (op 1) >>= \y-> return y does execute it. The trace of the first: [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> :set stop :list *Main> :step main Stopped at test.hs:4:6-43 _result :: IO () = _ 3 4 main= print $ Just (op 1) >>= \y-> return 2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 5 [test.hs:4:6-43] *Main> :step Stopped at test.hs:4:14-43 _result :: Maybe Integer = _ 3 4 main= print $ Just (op 1) >>= \y-> return 2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 5 [test.hs:4:14-43] *Main> :step Stopped at test.hs:4:14-24 _result :: Maybe Integer = _ 3 4 main= print $ Just (op 1) >>= \y-> return 2 ^^^^^^^^^^^ 5 [test.hs:4:14-24] *Main> :step Stopped at test.hs:4:35-43 _result :: Maybe Integer = _ 3 4 main= print $ Just (op 1) >>= \y-> return 2 ^^^^^^^^^ 5 [test.hs:4:35-43] *Main> :step Just 2 But in the second case op is executed: *Main> :step main Stopped at test.hs:4:6-43 _result :: IO () = _ 3 4 main= print $ Just (op 1) >>= \y-> return y ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 5 [test.hs:4:6-43] *Main> :step Stopped at test.hs:4:14-43 _result :: Maybe Integer = _ 3 4 main= print $ Just (op 1) >>= \y-> return y ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 5 [test.hs:4:14-43] *Main> :step Stopped at test.hs:4:14-24 _result :: Maybe Integer = _ 3 4 main= print $ Just (op 1) >>= \y-> return y ^^^^^^^^^^^ 5 [test.hs:4:14-24] *Main> :step Stopped at test.hs:4:35-43 _result :: Maybe Integer = _ y :: Integer = _ 3 4 main= print $ Just (op 1) >>= \y-> return y ^^^^^^^^^ 5 [test.hs:4:35-43] *Main> :step Just Stopped at test.hs:4:20-23 _result :: Integer = _ 3 4 main= print $ Just (op 1) >>= \y-> return y ^^^^ 5 [test.hs:4:20-23] *Main> :step Stopped at test.hs:6:0-8 _result :: Integer = _ 5 6 op x= x+x ^^^^^^^^^ 7 [test.hs:6:0-8] *Main> :step Stopped at test.hs:6:6-8 _result :: Integer = _ x :: Integer = _ 5 6 op x= x+x ^^^ 7 [test.hs:6:6-8] *Main> :step Just 2 2009/2/5 Gregg Reynolds - Ocultar texto citado - > > On Thu, Feb 5, 2009 at 9:27 AM, Bulat Ziganshin wrote: >> >> Hello Gregg, >> >> Thursday, February 5, 2009, 6:20:06 PM, you wrote: >> >> > An optimizer can see that the result of the first getChar is >> > discarded and replace the entire expression with one getChar without >> > changing the formal semantics. >> >> this is prohibited by using pseudo-value of type RealWorld which is >> passed through entire action stream. actually, order of execution is >> controlled by dependencies on this values >> >> http://haskell.org/haskellwiki/IO_inside >> > Thanks. I actually read that a few weeks ago and forgot all about it. So the gist is that type IO has special magic semantics. Formal, but hidden. Which means monad semantics are built in to the language, at least for that type. The Haskell Report doesn't seem to say anything about this, which seems odd. > > But then for non-IO monads, the optimization would be allowed, no? Of course; only the IO monad has external world behavior. > > Thanks, > > gregg > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/7b4cbb8f/attachment.htm From dev at mobileink.com Tue Feb 10 08:22:41 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Tue Feb 10 08:12:27 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <0C42DFC1-E530-42F4-9574-C10D730AD53D@cs.otago.ac.nz> <75cc17ac0902092007vcff5edci8394c31c936d20d9@mail.gmail.com> Message-ID: <75cc17ac0902100522u28a2c512o1c7aa79c9249a586@mail.gmail.com> On Mon, Feb 9, 2009 at 10:17 PM, Richard O'Keefe wrote: > > On 10 Feb 2009, at 5:07 pm, Gregg Reynolds wrote: > >> Thanks. I see the error of my ways. So, IO expressions must be evaluated >> if they are in the chain leading to main. >> > > > We need some standard terminology to distinguish > between *evaluating* an expression and *performing* > the result of an expression of type IO something. > Indeed. Wrote a blog article about this proposing a semiotic approach: http://syntax.wikidot.com/blog:4 > > An IO expression that is passed to a function at a > strict position must be evaluated whether the result > is performed or not. > > An IO expression whose result will be performed must > be evaluated before that performance can take place. > Is the result of evaluation a thunk/suspension/closer? > > (Dash it, this really is getting us into White Knight land.) > What's White Knight land? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/9c4151f7/attachment.htm From noteed at gmail.com Tue Feb 10 08:38:02 2009 From: noteed at gmail.com (minh thu) Date: Tue Feb 10 08:27:48 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <1234259999.4115.23.camel@localhost> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> <1234256129.4115.7.camel@localhost> <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> <40a414c20902100105t2fb6ec82h4126cdcfbf4a542@mail.gmail.com> <1234259999.4115.23.camel@localhost> Message-ID: <40a414c20902100538t33099992t1da0477f26c32d6c@mail.gmail.com> 2009/2/10 Joachim Breitner : > Hi, > > Am Dienstag, den 10.02.2009, 10:05 +0100 schrieb minh thu: >> I forgot to mention you can try to tie the knot too, using the result >> of the processing in the first mapping (and then you don't need the >> second one)... > > could you elaborate who to tie that particular knot? I unfortunately, I > don't see it. > > Thanks, > Joachim I can post some code later but here is the idea. You conceptually label the tree with Int's. If you go through the tree visiting the node in a specific order, you don't have to actually label it since the label of a node is just its position in the parcour. The goal is to map the tree with some data drawn from an association-list. Again, a straight-forward association is just a plain list indexed by Int's. Thus, when visiting the nodes of the tree, if you have the above-mentionned list, you can use that information when doing the mapping, replacing the data in the node by the data in the list (where the index used for the list is the 'label' of the node). The list is the result of going to the tree too, thus tying the knot. To construct it, you simply make some kind of mapAccum, using [] as the starting value and : (cons) to accumulate the data. To understand this intuitiveley, just note that a three can be flattened into a list. Thus if you want to process the 'association-list' which is represented by a plain list, just zipWith it [0..]. Cheers, Thu From lennart at augustsson.net Tue Feb 10 08:57:22 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Tue Feb 10 08:47:08 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902100522u28a2c512o1c7aa79c9249a586@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <0C42DFC1-E530-42F4-9574-C10D730AD53D@cs.otago.ac.nz> <75cc17ac0902092007vcff5edci8394c31c936d20d9@mail.gmail.com> <75cc17ac0902100522u28a2c512o1c7aa79c9249a586@mail.gmail.com> Message-ID: The result of an evaluation is always in WHNF (weak head normal form). So if it's a function, it's been evaluated to \ x -> ..., but no evaluation under lambda. Similarely, if it's a data type it has been evaluated so the outermost form is a constructor, but no evaluation inside the constructor. The terms thunk/suspension/closure usually refer to implementation rather than semantics. But in terms of an implementation, the answer is no. After evaluation you will have none of those as the outmost thing. -- Lennart 2009/2/10 Gregg Reynolds : > Is the result of evaluation a thunk/suspension/closer? From marlowsd at gmail.com Tue Feb 10 09:41:54 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Feb 10 09:31:46 2009 Subject: [Haskell-cafe] Re: How outdated is Hugs? In-Reply-To: <20090128034149.GA32419@jgoerzen-eee.lan.complete.org> References: <351ff25e0901270655n4d333016rdec504f4af402389@mail.gmail.com> <1233091135.8432.565.camel@localhost> <20090128034149.GA32419@jgoerzen-eee.lan.complete.org> Message-ID: <49919232.3040304@gmail.com> John Goerzen wrote: > Just to close -- I will point out that ghci doesn't work on many > platforms that Hugs does (though ghc does). Hugs is the only > interpreter on some of these platforms. I didn't see anyone follow up to this so I'll just mention that nowadays GHCi works wherever GHC works, since 6.10.1. Actually I think most platforms worked with 6.8.1, but 6.10.1 added libffi which meant that GHCi also gets working FFI support on any platform supported by libffi, which is most of them. Cheers, Simon From haskell at datakids.org Tue Feb 10 10:18:00 2009 From: haskell at datakids.org (Jamie) Date: Tue Feb 10 10:07:47 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is getting very popular nowadays and it would be great to have encoder and decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) as a base to start with. Jamie From noteed at gmail.com Tue Feb 10 10:36:34 2009 From: noteed at gmail.com (minh thu) Date: Tue Feb 10 10:26:21 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <40a414c20902100538t33099992t1da0477f26c32d6c@mail.gmail.com> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> <1234256129.4115.7.camel@localhost> <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> <40a414c20902100105t2fb6ec82h4126cdcfbf4a542@mail.gmail.com> <1234259999.4115.23.camel@localhost> <40a414c20902100538t33099992t1da0477f26c32d6c@mail.gmail.com> Message-ID: <40a414c20902100736l5ca9a2e3q64f0251f6994105b@mail.gmail.com> 2009/2/10 minh thu : > 2009/2/10 Joachim Breitner : >> Hi, >> >> Am Dienstag, den 10.02.2009, 10:05 +0100 schrieb minh thu: >>> I forgot to mention you can try to tie the knot too, using the result >>> of the processing in the first mapping (and then you don't need the >>> second one)... >> >> could you elaborate who to tie that particular knot? I unfortunately, I >> don't see it. >> >> Thanks, >> Joachim > > I can post some code later but here is the idea. > > You conceptually label the tree with Int's. If you go through the tree > visiting the node in a specific order, you don't have to actually > label it since the label of a node is just its position in the > parcour. > > The goal is to map the tree with some data drawn from an > association-list. Again, a straight-forward association is just a > plain list indexed by Int's. > > Thus, when visiting the nodes of the tree, if you have the > above-mentionned list, you can use that information when doing the > mapping, replacing the data in the node by the data in the list (where > the index used for the list is the 'label' of the node). > > The list is the result of going to the tree too, thus tying the knot. > To construct it, you simply make some kind of mapAccum, using [] as > the starting value and : (cons) to accumulate the data. > > To understand this intuitiveley, just note that a three can be > flattened into a list. Thus if you want to process the > 'association-list' which is represented by a plain list, just zipWith > it [0..]. So here some code, notice the process function which work on a list of data (drawn from the tree). As said above, it can make use of a [0..] list if the 'tags' or 'names' are needed for processing. Is it applicable to your problem ? -------------------------- module Log where data Tree a = Bud | Branch a (Tree a) (Tree a) -- no length here deriving Show mapAcc f acc Bud = (acc, Bud) mapAcc f acc (Branch a l r) = (acc2, Branch a' l' r') where (acc0,a') = f acc a (acc1,l') = mapAcc f acc0 l (acc2,r') = mapAcc f acc1 r tree0 = Bud tree1 = Branch "a" Bud Bud tree2 = Branch "r" (Branch "s" Bud Bud) Bud tree3 = Branch "x" (Branch "y" tree1 tree2) Bud process :: [String] -> [String] process l = zipWith (\a b -> a ++ show b) l [0..] tie tree = tree' where ((acc,q),tree') = mapAcc (\(acc,p) a -> ((acc + 1,a:p),r !! acc)) (0,[]) tree r = process (reverse q) From leimy2k at gmail.com Tue Feb 10 10:53:38 2009 From: leimy2k at gmail.com (David Leimbach) Date: Tue Feb 10 10:43:24 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <3e1162e60902100753n76031e04v190f167b5b750b9c@mail.gmail.com> SNMP would be really cool. So far the best implementation of SNMP I've had the pleasure to work with is part of the Erlang OTP distribution, and being able to compete with Erlang on that level would be really nice. On Tue, Feb 10, 2009 at 7:18 AM, Jamie wrote: > What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is > getting very popular nowadays and it would be great to have encoder and > decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) > as a base to start with. > > Jamie > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/e6ff3e46/attachment.htm From dons at galois.com Tue Feb 10 11:02:25 2009 From: dons at galois.com (Don Stewart) Date: Tue Feb 10 10:52:48 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20090210160225.GA3835@whirlpool.galois.com> Malcolm.Wallace: > Gentle Haskellers, > > The Google Summer of Code will be running again this year. Once again, > haskell.org has the opportunity to bid to become a mentoring > organisation. (Although, as always, there is no guarantee of > acceptance.) > > If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing > lists of your choice. We especially encourage students to communicate > with the wider community: if you keep your ideas private, you have a > much worse chance of acceptance than if you develop ideas in > collaboration with those who will be your "customers", end-users, or > fellow-developers. This is the open-source world! > And I'll just note that since December we've been running a proposal submission site here, where you can vote and comment on ideas, http://www.reddit.com/r/haskell_proposals/top/ A great place to suggest ideas! -- Don From rmm-haskell at z.odi.ac Tue Feb 10 11:32:49 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Tue Feb 10 11:22:40 2009 Subject: [Haskell-cafe] Additonal types for Foreign.C.Types In-Reply-To: References: Message-ID: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> I think you can use Data.Word and Data.Int types for this, that is. Data.Word.Word16 == uint16_t, Data.Word.Word32 == uint32_t, etc. Data.Int.Int16 = int16_t, Data.Int.Int32 = int32_t, etc. There are Foreign.Storable.Storable instances for those. -Ross On Feb 10, 2009, at 6:32 AM, Maur? cio wrote: > Hi, > > After reading an ISO draft for standard C, I found > a few types that could be usefull when binding to > libraries (these are from ): > > int8_t, uint8_t, int16_t, uint16_t, int32_t, > uint32_t, int64_t, uint64_t > > What about if they were included in the next version > of GHC Foreign.C.Types module? For instance, as: > > CInt8, CUInt8, CInt16 etc. > > Some libraries (e.g. sqlite) define function parameters > that are supposed to always have a given size (e.g., > sqlite defines sqlite3_int64). In order to have a > portable binding to those libraries, it would be nice > to have types in Haskell that also offer that guarantee. > > There are also a few other nice types, although I'm not > sure they belong to standard modules. If they did, > however, they could make life easier for those people > writing higher level Haskell modules after standard > C functions: > > complex, float complex, double complex (from ) > are used in functions like ccos, csin, cexp, csqrt etc. > > struct lconv (from ) > > struct tm (from ) > > From and : mbstate_t, wint_t, > wctrans_t, wctype_t. > > Do you think I could open a ticket for GHC proposing > that? > > Best, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From eelco at lempsink.nl Tue Feb 10 12:34:35 2009 From: eelco at lempsink.nl (Eelco Lempsink) Date: Tue Feb 10 12:24:27 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <20090207214050.GR27081@whirlpool.galois.com> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> <20090207172023.GD27081@whirlpool.galois.com> <1988130373.20090207214806@gmail.com> <20090207214050.GR27081@whirlpool.galois.com> Message-ID: On 7 feb 2009, at 22:40, Don Stewart wrote: > bulat.ziganshin: >> Hello Don, >> >> Saturday, February 7, 2009, 8:20:23 PM, you wrote: >> >>> We need a voting site set up. There was some progress prior to the >>> end >>> of the year. Updates welcome! >> >> i think that there are a lot of free voting/survey services >> available. >> the last one i went through was LimeSurvey available for any SF >> project and on separate site too >> >> http://apps.sourceforge.net/trac/sitedocs/wiki/Hosted%20Apps >> https://www.limeservice.com/ >> > > Before the new year's break, the progress we made towards deciding > on a > voting process was, > > http://groups.google.com/group/fa.haskell/msg/5d0ad1a681b044c7 > > Eelco implemented a demo condorcet voting system in HAppS. > > He then asked for help with some decisions: > > * Limit voting, if so how? Email confirmation, IP based, vote > once, once per day? > * Maybe don't show the results until the contest is over? > > Eelco, can we do simple email-based confirm to encourage people to > vote > only once, and can we keep the results closed until the vote process > is > over? Yes, sure. I'll try to make some time to finish the implementation, hopefully early next week. In the mean time, if somebody wants to go ahead and implement it (and maybe your own favorite feature as well), feel free to fork from http://github.com/eelco/voting The idea is that you only need to change the HTML to change the things that are voted upon. It might be nice(r) to use JavaScript to load those things. If you want to hack on it and have some questions please email me directly if you want a prompt response ;) -- Regards, Eelco Lempsink -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/a1d8ef11/PGP.bin From mads_lindstroem at yahoo.dk Tue Feb 10 12:41:59 2009 From: mads_lindstroem at yahoo.dk (Mads =?ISO-8859-1?Q?Lindstr=F8m?=) Date: Tue Feb 10 12:38:37 2009 Subject: [Haskell-cafe] Asking the GHC garbage collector to run Message-ID: <1234287719.5466.6.camel@localhost.localdomain> Hi all, Is it possible to ask the GHC garbage collector to run ? Something like a collectAllGarbage :: IO() call. Greetings, Mads Lindstr?m From dons at galois.com Tue Feb 10 12:49:34 2009 From: dons at galois.com (Don Stewart) Date: Tue Feb 10 12:39:57 2009 Subject: [Haskell-cafe] Asking the GHC garbage collector to run In-Reply-To: <1234287719.5466.6.camel@localhost.localdomain> References: <1234287719.5466.6.camel@localhost.localdomain> Message-ID: <20090210174934.GA4048@whirlpool.galois.com> mads_lindstroem: > Hi all, > > Is it possible to ask the GHC garbage collector to run ? Something like > a collectAllGarbage :: IO() call. System.Mem.performGC iirc, Don From coreyoconnor at gmail.com Tue Feb 10 12:57:19 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Tue Feb 10 12:47:04 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: The POSIX sleep function is defined as: sleep() makes the current process sleep until seconds seconds have elapsed or a signal arrives which is not ignored. Sounds like a signal is arriving that is interrupting the sleep. -Corey O'Connor 2009/2/9 John Ky : > Hi Peter, > > Source code: > import System.IO > import System.Posix > > main = do > putStrLn "Waiting for 5 seconds." > sleep 5 -- doesn't sleep at all > putStrLn "Done." > > OS: > Mac OS X 10.5 > > Compile command: > ghc --threaded testsleep.hs > > If I remove --threaded, then it does sleep. > > Thanks, > > -John > > On Tue, Feb 10, 2009 at 8:59 AM, Peter Verswyvelen > wrote: >> >> Hi John, >> Which sleep are you using? From which module? Can you show the full source >> with import statements? >> Cheers, >> Peter >> 2009/2/9 John Ky >>> >>> Hi Haskell Cafe, >>> >>> I wrote very short program to sleep for 5 seconds compiled with the >>> -threaded option in ghc on the Mac OS X 1.5. >>> >>> I am finding that using the sleep function doesn't sleep at all, whereas >>> using threadDelay does: >>> >>> main = do >>> putStrLn "Waiting for 5 seconds." >>> threadDelay 5000000 -- works >>> putStrLn "Done." >>> >>> main = do >>> putStrLn "Waiting for 5 seconds." >>> sleep 5 -- doesn't sleep at all >>> putStrLn "Done." >>> >>> Anybody know what's happening? >>> >>> Thanks >>> >>> -John >>> >>> >>> _______________________________________________ >>> 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 > > From mail at joachim-breitner.de Tue Feb 10 13:18:44 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Feb 10 13:07:32 2009 Subject: [Haskell-cafe] Re: Painting logs to get a coloured tree In-Reply-To: References: <1234220129.5358.131.camel@localhost> Message-ID: <1234289924.4115.50.camel@localhost> Hi, Am Dienstag, den 10.02.2009, 11:59 +0100 schrieb Heinrich Apfelmus: > However, I would be surprised if someAlgorithm could not be formulated > directly on the tree or at least satisfies a few invariants like for example > > map fst . someAlgorithm = map snd > > Also, how does cutTreeApart arrange the list? The idea is that most of > the tree structure survives in the list and can be reconstructed. Probably not. My algorithm calculates the amount of light that shines through the branches, and the amount of light cought by the branches (seeing branches as approximations for leaves here :-)). The algorithm works by taking the list of branches (represented by their start and end point), projects them along the direction of light, creates a list of start and endpoints, sorts them (to be able to sweep the line somewhat efficiently) and adds the projections of all intersections of branches. Then it iterates through the intervals on this line, gets the list of branches that are hit by this interval, sorts them by hights and adds, from top to bottom, the appropriate, decreasing portion of the light that comes in this interval. In this process, the branches are sorted around quite a bit, and I assume it would be hard to preserve the structure. If you want to see code (not sure though if you really want to see that code :-)), it?s in http://git.nomeata.de/?p=L-seed.git;a=blob;f=src/Lseed/Geometry.hs Lines 74-142. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/9c9889c7/attachment.bin From coreyoconnor at gmail.com Tue Feb 10 13:21:54 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Tue Feb 10 13:11:39 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? Message-ID: I released a new version of data-spacepart that resolved some of the issues with the previous release. One issue I had was the previous release used the version numbering scheme I use at work: [date].[release] Which does not appear to work as well as the traditional X.Y.Z release numbering scheme with Cabal. As part of the new release I changed the version numbering scheme. An *obviously* bad idea if I thought it through. Any [date].[release] style version number is greater than a X.Y.Z version number until X gets rather large. So what to do? Continue using the [date].[release] version numbering scheme? Or is there a way to coax HackageDB to ignore the old release? EG: The new release is: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-spacepart-0.1.1 The old release is: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-spacepart-20090126.0 The "latest" release according to HackageDB is: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-spacepart Which points to the old release. Cheers, -Corey O'Connor From mail at joachim-breitner.de Tue Feb 10 13:33:45 2009 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue Feb 10 13:22:32 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <40a414c20902100736l5ca9a2e3q64f0251f6994105b@mail.gmail.com> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> <1234256129.4115.7.camel@localhost> <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> <40a414c20902100105t2fb6ec82h4126cdcfbf4a542@mail.gmail.com> <1234259999.4115.23.camel@localhost> <40a414c20902100538t33099992t1da0477f26c32d6c@mail.gmail.com> <40a414c20902100736l5ca9a2e3q64f0251f6994105b@mail.gmail.com> Message-ID: <1234290825.4115.57.camel@localhost> Hi, Am Dienstag, den 10.02.2009, 16:36 +0100 schrieb minh thu: > So here some code, notice the process function which work on a list > of data (drawn from the tree). As said above, it can make use of a [0..] > list if the 'tags' or 'names' are needed for processing. > > Is it applicable to your problem ? > > -------------------------- > > module Log where > > data Tree a = Bud | Branch a (Tree a) (Tree a) -- no length here > deriving Show > > mapAcc f acc Bud = (acc, Bud) > mapAcc f acc (Branch a l r) = (acc2, Branch a' l' r') > where (acc0,a') = f acc a > (acc1,l') = mapAcc f acc0 l > (acc2,r') = mapAcc f acc1 r > > tree0 = Bud > tree1 = Branch "a" Bud Bud > tree2 = Branch "r" (Branch "s" Bud Bud) Bud > tree3 = Branch "x" (Branch "y" tree1 tree2) Bud > > process :: [String] -> [String] > process l = zipWith (\a b -> a ++ show b) l [0..] > > tie tree = tree' > where ((acc,q),tree') = mapAcc (\(acc,p) a -> ((acc + 1,a:p),r !! > acc)) (0,[]) tree > r = process (reverse q) thanks for your work. It doesn?t fit directly (if the process operation reorders the elements of the list, it fails). But if I first number them, and later sort them again, or use lookup instead of !!, it would work. But the knot-tying (and thus the single traversal of the tree) is a very neat idea. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/483434ea/attachment.bin From thomas.dubuisson at gmail.com Tue Feb 10 15:48:54 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Tue Feb 10 15:38:39 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: <4c44d90b0902101248n2e51ea54ufe8c640e8d437450@mail.gmail.com> Not to say the issue shouldn't be tracked down, but shouldn't a more portable function be used anyway? untested example: maxBoundMicroSecInSec =(maxBound `div` 10^6) threadDelaySec :: Int -> IO () threadDelaySec s | s > maxBoundMicroSecInSec = threadDelay (maxBoundMicroSecInSec * 10^6) >> threadDelaySec (s - maxBoundMicroSecInSec) | otherwise = threadDelay (s * 10^6) On Tue, Feb 10, 2009 at 5:57 PM, Corey O'Connor wrote: > The POSIX sleep function is defined as: > sleep() makes the current process sleep until seconds seconds have > elapsed or a signal arrives which is not ignored. > > Sounds like a signal is arriving that is interrupting the sleep. > > -Corey O'Connor > > > > 2009/2/9 John Ky : >> Hi Peter, >> >> Source code: >> import System.IO >> import System.Posix >> >> main = do >> putStrLn "Waiting for 5 seconds." >> sleep 5 -- doesn't sleep at all >> putStrLn "Done." >> >> OS: >> Mac OS X 10.5 >> >> Compile command: >> ghc --threaded testsleep.hs >> >> If I remove --threaded, then it does sleep. >> >> Thanks, >> >> -John >> >> On Tue, Feb 10, 2009 at 8:59 AM, Peter Verswyvelen >> wrote: >>> >>> Hi John, >>> Which sleep are you using? From which module? Can you show the full source >>> with import statements? >>> Cheers, >>> Peter >>> 2009/2/9 John Ky >>>> >>>> Hi Haskell Cafe, >>>> >>>> I wrote very short program to sleep for 5 seconds compiled with the >>>> -threaded option in ghc on the Mac OS X 1.5. >>>> >>>> I am finding that using the sleep function doesn't sleep at all, whereas >>>> using threadDelay does: >>>> >>>> main = do >>>> putStrLn "Waiting for 5 seconds." >>>> threadDelay 5000000 -- works >>>> putStrLn "Done." >>>> >>>> main = do >>>> putStrLn "Waiting for 5 seconds." >>>> sleep 5 -- doesn't sleep at all >>>> putStrLn "Done." >>>> >>>> Anybody know what's happening? >>>> >>>> Thanks >>>> >>>> -John >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From briqueabraque at yahoo.com Tue Feb 10 15:56:40 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Feb 10 15:46:39 2009 Subject: [Haskell-cafe] Re: Additonal types for Foreign.C.Types In-Reply-To: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> References: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> Message-ID: Yes, I can. Thanks. Just forget my idea, with this I can provide all those types in a library. I'm confused. When is it possible to use a type as a parameter to a foreign function call? My first guess was that I had to provide an instance for class Storable, but after I tried writing a complex-like type that way GHC told me my type was unaceptable. So I thought only types allowed by the compiler (including forall a. Ptr a) could be used that way. What is the rule? I've read all of FFI report and found nothing. Did I miss something? How can I make a type of mine acceptable? Why are Data.Int acceptable, and how could I know that? Thanks, Maur?cio > I think you can use Data.Word and Data.Int types for this, that is. > (...) >> After reading an ISO draft for standard C, I found >> a few types that could be usefull when binding to >> libraries (these are from ): >> >> int8_t, uint8_t, int16_t, uint16_t, int32_t, >> uint32_t, int64_t, uint64_t >> >> (...) From vanenkj at gmail.com Tue Feb 10 16:08:04 2009 From: vanenkj at gmail.com (John Van Enk) Date: Tue Feb 10 15:57:49 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: I'd like to see some good libgcrypt[1] bindings to complement our existing cryptography packages. /jve [1] http://www.gnupg.org/documentation/manuals/gcrypt/ On Tue, Feb 10, 2009 at 10:18 AM, Jamie wrote: > What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is > getting very popular nowadays and it would be great to have encoder and > decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) > as a base to start with. > > Jamie > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/0358733d/attachment.htm From rmm-haskell at z.odi.ac Tue Feb 10 16:13:41 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Tue Feb 10 16:04:51 2009 Subject: [Haskell-cafe] Re: Additonal types for Foreign.C.Types In-Reply-To: References: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> Message-ID: The FFI spec says (at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2) : The argument types at[i] produced by fatype must be marshallable foreign types; that is, each ati is either (1) a basic foreign type or (2) a type synonym or renamed datatype of a marshallable foreign type. Moreover, the result type rt produced by frtype must be a marshallable foreign result type; that is, it is either a marshallable foreign type, the type (), or a type matching Prelude.IO t, where t is a marshallable foreign type or (). Earlier it defines the basic foreign types: The following types constitute the set of basic foreign types: * Char, Int, Double, Float, and Bool as exported by the Haskell 98 Prelude as well as * Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64, Ptr a, FunPtr a, and StablePtr a, for any type a, as exported by Foreign (Section 5.1). So, that list of types, or any type synonym. -Ross On Feb 10, 2009, at 3:56 PM, Maur? cio wrote: > Yes, I can. Thanks. Just forget my idea, with > this I can provide all those types in a library. > > I'm confused. When is it possible to use a type > as a parameter to a foreign function call? My > first guess was that I had to provide an instance > for class Storable, but after I tried writing > a complex-like type that way GHC told me my type > was unaceptable. So I thought only types allowed > by the compiler (including forall a. Ptr a) could > be used that way. > > What is the rule? I've read all of FFI report > and found nothing. Did I miss something? How can > I make a type of mine acceptable? Why are > Data.Int acceptable, and how could I know that? > > Thanks, > Maur?cio > >> I think you can use Data.Word and Data.Int types for this, that is. >> (...) > >>> After reading an ISO draft for standard C, I found >>> a few types that could be usefull when binding to >>> libraries (these are from ): >>> >>> int8_t, uint8_t, int16_t, uint16_t, int32_t, >>> uint32_t, int64_t, uint64_t >>> >>> (...) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From bulat.ziganshin at gmail.com Tue Feb 10 16:18:35 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Tue Feb 10 16:09:19 2009 Subject: [Haskell-cafe] Re: Additonal types for Foreign.C.Types In-Reply-To: References: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> Message-ID: <1648705522.20090211001835@gmail.com> Hello Maur??cio, Tuesday, February 10, 2009, 11:56:40 PM, you wrote: 1. haskell compiler should check that your haskell imports match C function prototypes. ghc does it in -fvia-C mode if you declare .h file where the function prototype may be found: foreign import ccall unsafe "Environment.h UpdateCRC" c_UpdateCRC :: Ptr CChar -> CUInt -> CUInt -> IO CUInt but who now uses -fvia-C mode? 2. there is correspondence between C and Haskell types. haskell equivalents for C tpes are defined in FFI addendum. C equivalents for GHC haskell types are defined in ghc .h files, these are things like HsInt and so on if you use, for example, Int type on haskell side and int on C side, they may turn out to be the same or not. if you don't use -fvia-C and .h file, you will not get even a warning - program will just stop working i think that we may propose changing FFI addendum so that haskell compilers guarantees correspondence between Int16 and int16_t and so on disclaimer: i don't used ghc versions after 6.6, so things may be worse or better now :) > Yes, I can. Thanks. Just forget my idea, with > this I can provide all those types in a library. > I'm confused. When is it possible to use a type > as a parameter to a foreign function call? My > first guess was that I had to provide an instance > for class Storable, but after I tried writing > a complex-like type that way GHC told me my type > was unaceptable. So I thought only types allowed > by the compiler (including forall a. Ptr a) could > be used that way. > What is the rule? I've read all of FFI report > and found nothing. Did I miss something? How can > I make a type of mine acceptable? Why are > Data.Int acceptable, and how could I know that? > Thanks, > Maur?cio >> I think you can use Data.Word and Data.Int types for this, that is. >> (...) >>> After reading an ISO draft for standard C, I found >>> a few types that could be usefull when binding to >>> libraries (these are from ): >>> >>> int8_t, uint8_t, int16_t, uint16_t, int32_t, >>> uint32_t, int64_t, uint64_t >>> >>> (...) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From roma at ro-che.info Tue Feb 10 16:21:50 2009 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue Feb 10 16:11:56 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: References: Message-ID: <20090210212150.GB16231@flit> * Corey O'Connor [2009-02-10 10:21:54-0800] > I released a new version of data-spacepart that resolved some of the > issues with the previous release. One issue I had was the previous > release used the version numbering scheme I use at work: > [date].[release] Which does not appear to work as well as the > traditional X.Y.Z release numbering scheme with Cabal. As part of the > new release I changed the version numbering scheme. An *obviously* bad > idea if I thought it through. Any [date].[release] style version > number is greater than a X.Y.Z version number until X gets rather > large. > > So what to do? Continue using the [date].[release] version numbering > scheme? Or is there a way to coax HackageDB to ignore the old release? >From haxr changelog: Sun Feb 11 11:43:15 EET 2007 bjorn@bringert.net * Changed haxr version number to 3000.0.0 to avoid ordering problems with old date-based version numbers. -- Roman I. Cheplyaka :: http://ro-che.info/ "Don't let school get in the way of your education." - Mark Twain From konrad at tylerc.org Tue Feb 10 17:49:38 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Tue Feb 10 17:39:28 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <200902101449.38372.konrad@tylerc.org> On Tuesday 10 February 2009 07:18:00 am Jamie wrote: > What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is > getting very popular nowadays and it would be great to have encoder and > decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) > as a base to start with. > > Jamie GSoC is run out of the US, where software patents would prevent a student from taking this task. -- Conrad Meyer From konrad at tylerc.org Tue Feb 10 17:51:15 2009 From: konrad at tylerc.org (Conrad Meyer) Date: Tue Feb 10 17:41:02 2009 Subject: [Haskell-cafe] Re: How outdated is Hugs? In-Reply-To: <49919232.3040304@gmail.com> References: <351ff25e0901270655n4d333016rdec504f4af402389@mail.gmail.com> <20090128034149.GA32419@jgoerzen-eee.lan.complete.org> <49919232.3040304@gmail.com> Message-ID: <200902101451.15953.konrad@tylerc.org> On Tuesday 10 February 2009 06:41:54 am Simon Marlow wrote: > John Goerzen wrote: > > Just to close -- I will point out that ghci doesn't work on many > > platforms that Hugs does (though ghc does). Hugs is the only > > interpreter on some of these platforms. > > I didn't see anyone follow up to this so I'll just mention that nowadays > GHCi works wherever GHC works, since 6.10.1. Actually I think most > platforms worked with 6.8.1, but 6.10.1 added libffi which meant that GHCi > also gets working FFI support on any platform supported by libffi, which is > most of them. > > Cheers, > Simon Counterexample: GHC 6.10.1 works on linux/ppc, GHCi 6.10.1 does not. (6.8.3 worked, though.) Regards, -- Conrad Meyer From manlio_perillo at libero.it Tue Feb 10 18:05:25 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Feb 10 17:55:15 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: <49920835.7060507@libero.it> John Ky ha scritto: > Hi Haskell Cafe, > > I wrote very short program to sleep for 5 seconds compiled with the > -threaded option in ghc on the Mac OS X 1.5. > > I am finding that using the sleep function doesn't sleep at all, whereas > using threadDelay does: > > [...] > main = do > putStrLn "Waiting for 5 seconds." > sleep 5 -- doesn't sleep at all > putStrLn "Done." > > Anybody know what's happening? > Here is a syscal trace, on Linux: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1332#a1332 The interesting part: write(1, "Waiting for 5 seconds.\n"..., 23) = 23 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({5, 0}, 0xbf85f5cc) = ? ERESTART_RESTARTBLOCK (To be restarted) --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- sigreturn() = ? (mask now []) write(1, "5\n"..., 2) = 2 So, it seems nanosleep get interruped by a signal. Manlio Perillo From briqueabraque at yahoo.com Tue Feb 10 18:13:22 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Feb 10 18:03:18 2009 Subject: [Haskell-cafe] Re: Additonal types for Foreign.C.Types In-Reply-To: References: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> Message-ID: > The FFI spec says (at > http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2): > There I see: --- Foreign types are produced according to the following grammar: ftype --> frtype | fatype -> ftype frtype --> fatype | () fatype --> qtycon atype[1] ... atype[k] (k > 0) --- I can't understand the "qtycon atype[1]..." line. I did search haskell 98 report syntax reference, and saw how qtycon and tycon are defined, but I could not understand how they are used here. Thanks for your help, Maur?cio From porges at porg.es Tue Feb 10 18:22:04 2009 From: porges at porg.es (George Pollard) Date: Tue Feb 10 18:11:53 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: Message-ID: <1234308124.6786.10.camel@porges-laptop> On Tue, 2009-02-10 at 09:57 -0800, Corey O'Connor wrote: > The POSIX sleep function is defined as: > sleep() makes the current process sleep until seconds seconds have > elapsed or a signal arrives which is not ignored. > > Sounds like a signal is arriving that is interrupting the sleep. > > -Corey O'Connor I tested this when testing the original code; sleep reports that the signal received is 5 (SIGTRAP). However, the following code does not work: > import System.Posix > > main = do > putStrLn "Waiting for 5 seconds." > print sigTRAP > blockSignals $ addSignal sigTRAP emptySignalSet > signal <- sleep 5 > print signal > putStrLn "Done." This, on the other (strange) hand, does: > import System.Posix > > main = do > putStrLn "Waiting for 5 seconds." > blockSignals fullSignalSet > signal <- sleep 5 > print signal > putStrLn "Done." - George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/221ef498/attachment.bin From rmm-haskell at z.odi.ac Tue Feb 10 18:22:54 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Tue Feb 10 18:12:39 2009 Subject: [Haskell-cafe] Re: Additonal types for Foreign.C.Types In-Reply-To: References: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> Message-ID: <127ABCD5-FF85-4F80-A69F-916C5D1F6BC6@z.odi.ac> fatype is the function argument type. atype[i] are type arguments. qtycon is a qualified (e.g. possibly with module prefix) type constructor, e.g. Just So, for example if you have: foreign import ccall "string.h strlen" cstrlen :: Ptr CChar -> IO CSize fatype -> ftype :: ftype fatype :: fatype qtycon "Ptr" atype1 "CChar" fatype :: frtype qtycon "IO" atype1 "CSize" (I struggled a bit with finding a good way to communicate the productions chosen, so bear with me) Make sense? -Ross On Feb 10, 2009, at 6:13 PM, Maur? cio wrote: >> The FFI spec says (at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2) >> : > > There I see: > > --- > Foreign types are produced according to the following grammar: > > ftype --> frtype > | fatype -> ftype > frtype --> fatype > | () > fatype --> qtycon atype[1] ... atype[k] (k > 0) > --- > > I can't understand the "qtycon atype[1]..." line. I did > search haskell 98 report syntax reference, and saw how > qtycon and tycon are defined, but I could not understand > how they are used here. > > Thanks for your help, > Maur?cio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From porges at porg.es Tue Feb 10 18:36:49 2009 From: porges at porg.es (George Pollard) Date: Tue Feb 10 18:26:37 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: <49920835.7060507@libero.it> References: <49920835.7060507@libero.it> Message-ID: <1234309009.6786.12.camel@porges-laptop> On Wed, 2009-02-11 at 00:05 +0100, Manlio Perillo wrote: > John Ky ha scritto: > > Hi Haskell Cafe, > > > > I wrote very short program to sleep for 5 seconds compiled with the > > -threaded option in ghc on the Mac OS X 1.5. > > > > I am finding that using the sleep function doesn't sleep at all, whereas > > using threadDelay does: > > > > [...] > > main = do > > putStrLn "Waiting for 5 seconds." > > sleep 5 -- doesn't sleep at all > > putStrLn "Done." > > > > Anybody know what's happening? > > > > Here is a syscal trace, on Linux: > http://hpaste.org/fastcgi/hpaste.fcgi/view?id=1332#a1332 > > > The interesting part: > write(1, "Waiting for 5 seconds.\n"..., 23) = 23 > rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 > rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > nanosleep({5, 0}, 0xbf85f5cc) = ? ERESTART_RESTARTBLOCK (To be > restarted) > --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > sigreturn() = ? (mask now []) > write(1, "5\n"..., 2) = 2 > > > So, it seems nanosleep get interruped by a signal. This works: > import System.Posix > > main = do > putStrLn "Waiting for 5 seconds." > blockSignals $ addSignal sigVTALRM emptySignalSet > sleep 5 > putStrLn "Done." > So (see my earlier email) `sleep` is lying about what interrupts it :) - George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/fd631dae/attachment.bin From coreyoconnor at gmail.com Tue Feb 10 18:41:28 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Tue Feb 10 18:31:27 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: <1234309009.6786.12.camel@porges-laptop> References: <49920835.7060507@libero.it> <1234309009.6786.12.camel@porges-laptop> Message-ID: 2009/2/10 George Pollard : >> import System.Posix >> >> main = do >> putStrLn "Waiting for 5 seconds." >> blockSignals $ addSignal sigVTALRM emptySignalSet >> sleep 5 >> putStrLn "Done." >> Huh! Does the GHC runtime uses this signal? Perhaps for scheduling? Cheers, -Corey O'Connor From haskell at list.mightyreason.com Tue Feb 10 18:46:10 2009 From: haskell at list.mightyreason.com (ChrisK) Date: Tue Feb 10 18:36:09 2009 Subject: [Haskell-cafe] ANN: Bug fix to regex-tdfa, new version 0.97.3 Message-ID: <499211C2.4030605@list.mightyreason.com> To Haskell and Libraries and Haskell-Cafe, Whilst improving regex-tdfa I have run across new bugs. Some patterns were getting compiled wrong and others were affected by an execution bug. As this package has actual users, I wanted to make sure they get these fixes immediately. Three Cheers For QuickCheck! The new version is 0.97.3 at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-tdfa And this version passes all the unit tests I have, including coverage for the new bugs. This is no warranty that regex-tdfa is bug free, since I made that same claim last release. For instance: I suspect 0.97.3 may be buggy if used in the optional left-associative mode. The new improved version of regex-tdfa is still a long way off. Cheers, Chris Kuklewicz From ok at cs.otago.ac.nz Tue Feb 10 18:46:34 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Tue Feb 10 18:36:57 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902100916.33357.g9ks157k@acme.softbase.org> References: <200902091319.42566.g9ks157k@acme.softbase.org> <609F806E-4EF2-4115-A54D-F3C88C640727@cs.otago.ac.nz> <200902100916.33357.g9ks157k@acme.softbase.org> Message-ID: On 10 Feb 2009, at 9:16 pm, Wolfgang Jeltsch wrote: > I did *not* want to argue pro ?designed-for-HTML?. I wanted to argue > contra ?designed-for-PDF? and pro ?designed-for-any-output-format?. Fair enough. I suppose I should point out what seems obvious to me, which is that one could embed a substantial chunk of MathML (possibly all of it) in TeX. I mean, give it a TeX-parseable syntax. The reason I mention this is that I've found typing TeX versions of formulas to be noticeably easier and faster than using "equation editors" to generate MathML. From porges at porg.es Tue Feb 10 18:49:15 2009 From: porges at porg.es (George Pollard) Date: Tue Feb 10 18:39:07 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: <49920835.7060507@libero.it> <1234309009.6786.12.camel@porges-laptop> Message-ID: <1234309755.6786.13.camel@porges-laptop> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/c531a41f/attachment-0001.bin From manlio_perillo at libero.it Tue Feb 10 19:04:01 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Feb 10 18:53:52 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: References: <49920835.7060507@libero.it> <1234309009.6786.12.camel@porges-laptop> Message-ID: <499215F1.6090203@libero.it> Corey O'Connor ha scritto: > 2009/2/10 George Pollard : >>> import System.Posix >>> >>> main = do >>> putStrLn "Waiting for 5 seconds." >>> blockSignals $ addSignal sigVTALRM emptySignalSet >>> sleep 5 >>> putStrLn "Done." >>> > > Huh! Does the GHC runtime uses this signal? Perhaps for scheduling? > Right. It is used for scheduling, as far as I understand. So blocking it is a bad idea (unless you block it in a thread other than the main thread, IMO). > Cheers, > -Corey O'Connor > Regards Manlio From michael at schmong.org Tue Feb 10 19:19:23 2009 From: michael at schmong.org (Michael Litchard) Date: Tue Feb 10 19:09:08 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <3dc350d00902101619n6b96095dkaa62ad824be10443@mail.gmail.com> I would love a mentor to help me with a Haskell binding to libnova. This is part of a larger project I have in mind, but the libnova binding seems like the first step. I don't expect this to be picked as an official GSoC, but this seemed like a good time to look for a mentor for this project. Michael Litchard On Tue, Feb 10, 2009 at 6:26 AM, Malcolm Wallace wrote: > Gentle Haskellers, > > The Google Summer of Code will be running again this year. Once again, > haskell.org has the opportunity to bid to become a mentoring > organisation. (Although, as always, there is no guarantee of > acceptance.) > > If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing > lists of your choice. We especially encourage students to communicate > with the wider community: if you keep your ideas private, you have a > much worse chance of acceptance than if you develop ideas in > collaboration with those who will be your "customers", end-users, or > fellow-developers. This is the open-source world! > > The timeline is that Haskell.org will apply for GSoC membership between > 9-13 March, and if we are successful, students can submit applications > between 23 March - 3 April. > > If you wish to help publicise GSoC amongst students, there are official > posters/fliers available (not specific to haskell.org): > > http://code.google.com/p/google-summer-of-code/wiki/GsocFlyers > > Regards, > Malcolm > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From ok at cs.otago.ac.nz Tue Feb 10 19:44:10 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Tue Feb 10 19:33:57 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <75cc17ac0902100522u28a2c512o1c7aa79c9249a586@mail.gmail.com> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <75cc17ac0902090435w2f5675dao7ce5b021840e340e@mail.gmail.com> <0C42DFC1-E530-42F4-9574-C10D730AD53D@cs.otago.ac.nz> <75cc17ac0902092007vcff5edci8394c31c936d20d9@mail.gmail.com> <75cc17ac0902100522u28a2c512o1c7aa79c9249a586@mail.gmail.com> Message-ID: <0A7D6B02-9111-494A-9402-6B8155750934@cs.otago.ac.nz> On 11 Feb 2009, at 2:22 am, Gregg Reynolds wrote: > Is the result of evaluation a thunk/suspension/closer? As T. S. Eliot wrote, "Teach us to care and not to care Teach us to sit still." There are some things it is better not to care about and this is one of them. > > > > (Dash it, this really is getting us into White Knight land.) > > What's White Knight land? > From Alice in Wonderland. ``You are sad,'' the Knight said in an anxious tone: ``let me sing you a song to comfort you.'' ``Is it very long?'' Alice asked, for she had heard a good deal of poetry that day. ``It's long,'' said the Knight, ``but it's very, {\it very} beautiful. Everybody that hears me sing it---either it brings tears to their eyes, or else---'' ``Or else what?'' said Alice, for the Knight had made a sudden pause. ``Or else it doesn't, you know. The name of the song is called {\it `Haddocks' Eyes.'\/}{}'' ``Oh, that's the name of the song, is it?'' Alice said, trying to feel interested. ``No, you don't understand,'' the Knight said, looking a little vexed. ``That's what the name is {\it called}. The name really {\it is `The Aged Aged Man.'\/}{}'' ``Then I ought to have said, `That's what the {\it song} is called?'' Alice corrected herself. ``No, you oughtn't: that's quite another thing! The {\it song} is called {\it `Ways and Means'\/}: but that's only what it's {\it called}, you know.'' ``Well, what {\it is} the song, then?'' said Alice, who was by this time completely bewildered. ``I was coming to that,'' the Knight said. ``The song really {\it is `A-sitting On a Gate'\/}: and the tune's my own invention.'' From manlio_perillo at libero.it Tue Feb 10 19:50:05 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Tue Feb 10 19:39:56 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: <1234309009.6786.12.camel@porges-laptop> References: <49920835.7060507@libero.it> <1234309009.6786.12.camel@porges-laptop> Message-ID: <499220BD.1020108@libero.it> George Pollard ha scritto: > [...] > >> So, it seems nanosleep get interruped by a signal. > > This works: > >> import System.Posix >> >> main = do >> putStrLn "Waiting for 5 seconds." >> blockSignals $ addSignal sigVTALRM emptySignalSet >> sleep 5 >> putStrLn "Done." >> > So (see my earlier email) `sleep` is lying about what interrupts it :) > > - George A possibly better solution is: sleep' :: Int -> IO Int sleep' n = do n' <- sleep n if n' == 0 then return 0 else sleep' n' From the trace, I see that nanosleep is being called 17 times here. Another solution is to set RTS flag: ./bug_sleep +RTS -V0 -RTS What strange is that the timer is created in non threaded RTS, too, but sleep is interrupted only with the threaded RTS. This may be caused by an "incorrect" execution of a foreign function marked safe. Regards Manlio From wren at freegeek.org Tue Feb 10 20:01:16 2009 From: wren at freegeek.org (wren ng thornton) Date: Tue Feb 10 19:51:01 2009 Subject: [Haskell-cafe] Monad explanation In-Reply-To: <3F7C027E-A274-4ACC-A04F-DACE0EE523FA@cs.otago.ac.nz> References: <050B1F12-D445-491D-B5D4-DE5E837E6D9A@cs.otago.ac.nz> <75cc17ac0902050808y4e336493gbf79c0841b3ec55d@mail.gmail.com> <75cc17ac0902090056r3876db6cuecf75ed855efec00@mail.gmail.com> <498FF6DC.9020909@tmorris.net> <499001FD.5010705@tmorris.net> <49900795.5060802@tmorris.net> <75cc17ac0902090324v197fe335r1c0d4a8772ede19e@mail.gmail.com> <3F7C027E-A274-4ACC-A04F-DACE0EE523FA@cs.otago.ac.nz> Message-ID: <4992235C.80803@freegeek.org> Richard O'Keefe wrote: > Gregg Reynolds wrote: > > Sure, you can treat a morphism as an object, but only by moving to a > > higher (or different) level of abstraction. > > False as a generalisation about mathematics. > False about functional programming languages, the very essence > of which is treating functions ("morphisms") as values ("objects") > exactly like any other values. > > > That doesn't erase the difference between object and morphism. > > There is no intrinsic difference between objects and morphisms. > It's what you DO with something that makes it an object or a > morphism (or both). > > > This is way confusing. > > Composer (Haskell program) writes score (computes getChar). > Performer (Haskell environment) sings score (performs Gamaliel). > Sound happens (a character is read). +1. The only difference between objects and morphisms is in the decision by some supreme entity (human reader, Haskell runtime) to treat them differently. There is nothing different between them other than our decisions to treat them differently. As for the concrete example about "3", I define: > let 3 = \f x -> f(f(f x)) which is as valid as any other definition. Oh noes, you say, it's a function and therefore a morphism. And certainly it is. However, it's perfectly fine to treat that as a value and define a "real" function like addition: > let m + n = \f x -> m f (n f x) When people see something like "1 + 2 + 3" they choose to think of 1, 2, and 3 as "objects" and choose to think of (+) and (+) as "morphisms", but who cares? Any datum can be encoded as a function, the execution of which enacts the existence of the object the function denotes. And, in functional languages, functions can be passed around and clubbed over the head just like every other value. And therein lies the rub: "the execution of which enacts the existence of the object the function denotes." The only thing that distinguishes objects and morphisms is the decision by some supreme entity to treat them that way. Just as you once said that values don't concatenate, so neither do functions apply. The application of functions can only be observed by some evaluator for the structure generated by application. Application itself has no semantics, it just builds ASTs and uninterpreted terms; only our choice to evaluate ASTs and terms gives them meaning. -- Live well, ~wren From anotheraddress at gmx.de Tue Feb 10 20:04:20 2009 From: anotheraddress at gmx.de (Daniel =?iso-8859-1?q?Sch=FCssler?=) Date: Tue Feb 10 19:54:23 2009 Subject: [Haskell-cafe] ANN: convertible (first release) In-Reply-To: <33BC916C-BB4E-4F3D-A307-A621CA94E80F@geeky.net> References: <200902100846.31761.anotheraddress@gmx.de> <33BC916C-BB4E-4F3D-A307-A621CA94E80F@geeky.net> Message-ID: <200902110204.20437.anotheraddress@gmx.de> Hello, it is a real code snippet, but I failed to include the necessary pragma (which is: {-# OPTIONS_GHC -fglasgow-exts #-} or {-# OPTIONS_GHC -XMagicHash #-} at the beginning of the file). the "#" suffix is for unboxed types: http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#magic-hash Greetings, Daniel On Wednesday 11 February 2009 00:19:56 Dylan Tisdall wrote: > Maybe I'm just a noob falling for someone's joke here, but I can't > make that sample, or anything else I tried with "#" on the end of > names, to compile with ghci. In the example below, I get a parse error > at the line defining d2f. Is this a real code snippet? > > > Cheers, > Dylan > > On Feb 10, 2009, at 2:46 AM, Daniel Sch?ssler wrote: > > Hi, > > > > On Wednesday 28 January 2009 04:30:07 John Goerzen wrote: > >> On Tue, Jan 27, 2009 at 09:41:30PM -0500, wren ng thornton wrote: > >>> I once again point out that realToFrac is *wrong* for converting > >>> from > >>> Float or Double. > >>> > >>>> realToFrac (1/0::Float) ::Double > >>> > >>> 3.402823669209385e38 > >> > >> Yes, I understand what you are saying and agree with you. But there > >> is nothing better in the standard library > > > > don't know whether you consider GHC as standard library, but if you > > do...: > > > > import GHC.Types > > import GHC.Prim > > > > -- | Double to Float > > d2f (D# d) = F# (double2Float# d) > > > > -- | Float to Double > > f2d (F# f) = D# (float2Double# f) > > > > > > ghci> f2d (1/0) > > Infinity > > it :: Double > > > > :) > > > > -- > > Daniel > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe From briqueabraque at yahoo.com Tue Feb 10 20:31:15 2009 From: briqueabraque at yahoo.com (=?ISO-8859-1?Q?Maur=ED=ADcio?=) Date: Tue Feb 10 20:21:12 2009 Subject: [Haskell-cafe] Re: Additonal types for Foreign.C.Types In-Reply-To: <127ABCD5-FF85-4F80-A69F-916C5D1F6BC6@z.odi.ac> References: <4F824BEC-D473-499A-92C0-0CD098F59F93@z.odi.ac> <127ABCD5-FF85-4F80-A69F-916C5D1F6BC6@z.odi.ac> Message-ID: Sure it does! Thanks. > (...)So, for example if you have: > > foreign import ccall "string.h strlen" cstrlen :: Ptr CChar -> IO CSize > > fatype -> ftype :: ftype > fatype :: fatype > qtycon "Ptr" > atype1 "CChar" > fatype :: frtype > qtycon "IO" > atype1 "CSize" > > (I struggled a bit with finding a good way to communicate the > productions chosen, so bear with me) > > Make sense? >>> The FFI spec says (at >>> http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi/ffise3.html#x6-120003.2): >>> >> >> There I see: >> >> --- >> (...) >> I can't understand the "qtycon atype[1]..." line. (...) From wren at freegeek.org Tue Feb 10 20:32:49 2009 From: wren at freegeek.org (wren ng thornton) Date: Tue Feb 10 20:22:35 2009 Subject: [Haskell-cafe] Painting logs to get a coloured tree In-Reply-To: <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> References: <1234220129.5358.131.camel@localhost> <7ca3f0160902091541j6b6ff5e8qa0629a20985a84e1@mail.gmail.com> <1234256129.4115.7.camel@localhost> <40a414c20902100102h59b880fdof4f1249e865a10a9@mail.gmail.com> Message-ID: <49922AC1.2040607@freegeek.org> minh thu wrote: > Joachim Breitner: > > I thought about Zippers, but I understand that they improve _navigating_ > > in a Tree-like structure, or to refrence _one_ position in a tree. > > > > But if I would deconstruct my tree to the list of _all_ locations, with > > > type Loc a = (Tree a, Cxt a) > > and then run my algorithm that returns [(Loc a, Info)], it's still not > > clear to me how I can combine all of these locations to get back my > > original Tree, annotated with the Info returned. > > I guess I just repeat your last praragraph of your original mail but it seems > to me you can mapAccump some 'names' on the tree, process an > association list (or an IntMap) of the (name,log) then map the three > again using the result. > In spirits, it's the same thing than the STRef solution but it seems > cleaner to me. It might also be worth looking at Okasaki's algorithm for (breadth-first) numbering of nodes in a tree[1]. Assuming your tree doesn't have interesting invariants to maintain, a similar/inverse algorithm could be used to "unfold" a list of logs back into a tree. As minh thu says, the numbering seems like it only needs to be conceptual rather than actual. In which case you should be able to fuse the code that traverses the tree to produce logs and the code that traverses the logs to produce a tree (aka a hylomorphism, if you're familiar). The knot-tying step should only be necessary if constructing the tree from logs requires more information than whatever's local to the log itself. Of course, if global information is necessary then you probably _do_ need to actually label the tree. At least it's cleaner than STRefs since you don't need mutability. [1] http://www.eecs.usma.edu/webs/people/okasaki/pubs.html#icfp00 -- Live well, ~wren From wren at freegeek.org Tue Feb 10 20:59:16 2009 From: wren at freegeek.org (wren ng thornton) Date: Tue Feb 10 20:49:01 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <3410468369.20090205182759@gmail.com> <75cc17ac0902050746i7eba3defj9b3ea70b7621223b@mail.gmail.com> Message-ID: <499230F4.2020407@freegeek.org> Alberto G. Corona wrote: > forwarded: > > Yes! if no state is passed, the optimization makes sense and the term is > not executed, like any lazy evaluation. For example, I used the debugger > (that is, without optimizations) to verify it with the Maybe monad: > op x= x+x > > print $ Just (op 1) >>= \y-> return (Just 2) > > does not evaluate op 1 Presumably you mean?: print $ Just (op 1) >>= \y-> return 2 > but > > print $ Just (op 1) >>= \y-> return y > > does execute it. Dashing off towards the White Knight, we should be careful what is said here. If we take only the expression "Just (op 1) >>= \y-> return y" then evaluating it yields "Just (op 1)". That is, it only evaluates to WHNF and does not evaluate what's inside. It is only once this value is subsequently handed off to print or some other function, that it may become evaluated. Similarly with the first example as originally written. It so happens that bind is non-strict for the field in Just, so we can discard the "op 1". However, according to the semantics we do not evaluate "Just 2" either; we only need to evaluate the return which will produce Just and pass the operand down. (Regardless of the fact that the value yielded by applying Just to 2 is Just 2. Expressions and their denotations are different.) -- Live well, ~wren From haskell at datakids.org Tue Feb 10 21:54:09 2009 From: haskell at datakids.org (Jamie) Date: Tue Feb 10 21:43:53 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <200902101449.38372.konrad@tylerc.org> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> Message-ID: On Tue, 10 Feb 2009, Conrad Meyer wrote: > On Tuesday 10 February 2009 07:18:00 am Jamie wrote: >> What I would like to see is H.264 video codec in Haskell. H.264/MPEG-4 is >> getting very popular nowadays and it would be great to have encoder and >> decoder in haskell. Can use x264 (encoder) and ffmpeg (en/de coder) >> as a base to start with. >> >> Jamie > > GSoC is run out of the US, where software patents would prevent a > student from taking this task. via http://www.videolan.org/developers/x264.html "x264 is a free library for encoding H264/AVC video streams. The code is written from scratch by Laurent Aimar, Loren Merritt, Eric Petit (OS X), Min Chen (vfw/asm), Justin Clay (vfw), M?ns Rullg?rd, Radek Czyz, Christian Heine (asm), Alex Izvorski, and Alex Wright. It is released under the terms of the GPL license." Seems like it is ok to write H.264 in Haskell and released via GPL license? There is theora.org but H.264 would be ideal. Ditto for H.263. > Conrad Meyer > Jamie From gwern0 at gmail.com Tue Feb 10 22:01:45 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Feb 10 21:53:50 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: Message-ID: 2009/2/10 Jamie : > On Tue, 10 Feb 2009, Conrad Meyer wrote: > >> On Tuesday 10 February 2009 07:18:00 am Jamie wrote: >>> >>> What I would like to see is H.264 video codec in Haskell. ?H.264/MPEG-4 >>> is >>> getting very popular nowadays and it would be great to have encoder and >>> decoder in haskell. ?Can use x264 (encoder) and ffmpeg (en/de coder) >>> as a base to start with. >>> >>> ? ? ? ?Jamie >> >> GSoC is run out of the US, where software patents would prevent a student >> from taking this task. > > via http://www.videolan.org/developers/x264.html > > "x264 is a free library for encoding H264/AVC video streams. The code is > written from scratch by Laurent Aimar, Loren Merritt, Eric Petit (OS X), Min > Chen (vfw/asm), Justin Clay (vfw), M?ns Rullg?rd, Radek Czyz, Christian > Heine (asm), Alex Izvorski, and Alex Wright. It is released under the terms > of the GPL license." > > Seems like it is ok to write H.264 in Haskell and released via GPL license? > > There is theora.org but H.264 would be ideal. ?Ditto for H.263. > >> Conrad Meyer > > > ? ? ? ?Jamie Software patent issues are entirely orthogonal to the copyright issues of who wrote what under which license. That's why software patents suck so very hard. See https://secure.wikimedia.org/wikipedia/en/wiki/Software_patent#Free_and_open_source_software & https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_software -- gwern -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 270 bytes Desc: OpenPGP digital signature Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/ee8093c6/signature.bin From gwern0 at gmail.com Tue Feb 10 23:35:46 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Tue Feb 10 23:25:30 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: Message-ID: (The following is a quasi essay/list of past Summer of Code projects; my hope is to guide thinking about what Summer of Code projects would be good to pick, and more specifically what should be avoided. If you're in a hurry, my conclusions are at the bottom. The whole thing is written in Markdown; for best results pass it through Pandoc or view it via your friendly local Gitit wiki.) # Summer of Code As part of Google's [Summer of code](http://en.wikipedia.org/wiki/Google_Summer_of_Code)[](http://code.google.com/soc/) program, Google sponsors 5-10 [projects for Haskell](http://hackage.haskell.org/trac/summer-of-code/). The Haskell Summer of Codes have often produced excellent results, but how excellent is excellent? Are there any features or commonalities between successful projects or unsuccessful ones? (This questions are particularly important as SoC 2009 isn't too far away; yet we don't have even a general sense of where we are.) ## Example retrospective: Debian An energetic blogger & Debian developer has produced [a](http://www.milliways.fr/2009/01/20/debian-2008-where-now-1/) [three](http://www.milliways.fr/2009/01/28/debian-2008-where-now-2/) [part](http://www.milliways.fr/2009/02/02/debian-2008-where-now-3/) series on the many Debian-related Summer of Code projects. The results are interesting: some projects were a failure and the relevant student drifted away and had little to do with Debian again; and some were great successes. I don't discern any particular lessons there, except perhaps one against hubris or filling unclear needs. Let's see whether that holds true of Haskell. ### Haskell retrospective Haskell wasn't part of the first Summer of Code in 2005, but it was accepted for 2006. We start there. #### 2006 The 2006 [homepage](http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2006) lists the following projects: - "Fast Mutable Collection Types for Haskell" Caio Marcelo de Oliveira Filho, mentored by Audrey Tang This ultimately resulted in the [HsJudy](http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HsJudy) library ('fast mutable collection' here meaning 'array'; see the [application](http://darcs.haskell.org/judy/SOC_APP.txt)). HsJudy was apparently used in Pugs at one time, but no more. Thus, I judge this to have been **unsuccessful**. - "Port Haddock to use GHC" David Waern, mentored by Simon Marlow **Successful**. Haddock has used the GHC API ever since.[^complaints] - "A model for client-side scripts with HSP" Joel Bj?rnson, mentored by Niklas Broberg Was initially unsuccessful, but seems to've been picked up again. So I give this a tentative **successful** - "GHCi based debugger for Haskell" Jos? Iborra L?pez, mentored by David Himmelstrup **Successful**. The GHCi debugger was accepted into GHC HEAD, and by now is in production use, - "HaskellNet" Jun Mukai, mentored by Shae Erisson **Unsuccessful**. HaskellNet is dead, and nothing of it has propagated elsewhere. (I'm not entirely sure what happened with the HaskellNet code - I know of [two](http://darcs.haskell.org/SoC/haskellnet/) [repos](http://stuff.mit.edu/afs/sipb/project/suez/src/haskell/haskellnet/), but that's about it.) Shae tells me that this poor uptake is probably due to a lack of advertising, and not any actual defect in the HaskellNet code. - "Language.C - a C parser written in Haskell" Marc van Woerkom, mentored by Manuel Chakravarty **Failure**. According to [Don Stewart's outline](http://www.haskell.org/pipermail/haskell-cafe/2007-February/022509.html) of the 2006 SoC, this project was not completed. - "Implement a better type checker for Yhc" Leon P Smith, mentored by Malcolm Wallace **Failure**. See Language.C - "Thin out cabal-get and integrate in GHC" Paolo Martini, mentored by Isaac Jones **Successful**. Code is in Cabal, which we all know and love. - "Unicode ByteString, Data.Rope, Parsec for generic strings" Spencer Janssen, mentored by Don Stewart **Successful**. (Again, per Don.) 4 successful; 2 unsuccessful; and 2 failures. #### 2007 The [2007 homepage](http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2007) - "Darcs conflict handling" Jason Dagit, mentored by David Roundy **Successful**. The work was successful in almost completely getting rid of the exponential conflict bug, and has been in the regular releases of Darcs 2.x for some time now. - "Automated building of packages and generation of Haddock documentation" Sascha B?hme, mentored by Ross Paterson **Successful**. The auto build and doc generation are long-standing and very useful parts of Hackage. - "Rewrite the typechecker for YHC and nhc98" Mathieu Boespflug, mentored by Malcolm Wallace Unknown. - "Cabal Configurations" Thomas Schilling, mentored by Michael Isaac Jones **Successful**. Cabal configurations have been around for a while and are very useful for enabling/disabling things - Update the Hat tracer Kenn Knowles, mentored by Malcolm Wallace **Unsuccessful**. The update apparently happened, since the [Hat homepage](http://www.haskell.org/hat/) says "Version 2.06 released 2nd Oct 2008", but it is [described](http://www.haskell.org/hat/download.html) as unmaintained, and I can't seem to find any examples of people actually using Hat. - Generalizing Parsec to ParsecT and arbitrary input (ByteStrings) Paolo Martini, mentored by Philippa Jane Cowderoy **Success**. But a mixed one ? I understand the performance is terrible so few people use it. - Shared Libraries for GHC Clemens Fruhwirth, mentored by Simon Marlow **Unsuccessful**. The situation is unclear to me, but I know that for some period dynamic linking worked for some platforms. However, it's 2009 and I still have static linking; so I'm going to chalk this one up as existing but not in use. - "Libcurl" Mieczys?aw B?k, mentored by Bryan O'Sullivan **Success**. Libcurl does exist and has been used, and is maintained. I understand it has been used, even if I personally don't know of any examples. - "Extending GuiHaskell: An IDE for Haskell Hackers" Asumu Takikawa, mentored by Neil David Mitchell **Failure**. GuiHaskell does not exist in any usable form. (The homepage summarizes the situation thusly: ["**Warning**: This project is fragile, unfinished, and I do not recommend that anyone tries using it."](http://www-users.cs.york.ac.uk/~ndm/guihaskell/)) 4 successes; 2 unsuccessful; 1 failure, and 1 unknown. ##### See also - [The Monad.Reader's](http://haskell.org/haskellwiki/The_Monad_Reader) [issue 9](http://haskell.org/sitewiki/images/5/5d/TMR-Issue9.pdf) covers SoC projects - #### 2008 The [2008 homepage](http://hackage.haskell.org/trac/summer-of-code/wiki/SoC2008) isn't so kind enough as to list all the projects as before, but it does tell us that only 7 projects were accepted by Google. So we can work from the [code.google.com](http://code.google.com/p/google-summer-of-code-2008-haskell/downloads/list) page which lists 6: - "C99 Parser/Pretty-Printer" by Benedikt Huber, mentored by Iavor Diatchki **Success**. The first try failed, but the second won through, and now people are doing things like [parsing the Linux kernel](http://www.galois.com/blog/2008/09/17/parsing-the-linux-kernel-with-haskell-experience-with-languagec/) with it. - "GMap - Fast composable maps" by Jamie Brandon **Successful**. GMap is on [Hackage](http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gmap), and I believe I've seen it used. - "Haskell API Search" Neil Mitchell **Successful**. The improved performance and search capability have made it into Hoogle releases. - "Cabal 'make-like' dependency framework" Andrea Vezzosi **Successful**? (I don't actually know, but this probably made it into Cabal.) - "GHC plugins" Maximilian Conroy Bolingbroke **Successful**? - "Data parallel physics engine" Roman Cheplyaka **Unsuccessful**? It seems to be finished but no use made of the actual engine (that I can see mentioned on the [engine's blog](http://physics-dph.blogspot.com/)). - "GHC API". Thomas Schilling According to the [Haskell Weekly News](http://sequence.complete.org/hwn/20080702): > "Thomas Schilling (nominolo) is working on improvements to the GHC API. Officials at HWN headquarters have released a statement reversing their previous position regarding the existence of Thomas, citing regrettably faulty information to explain their previous misapprehensions. Expect to hear more from Thomas soon, now that he has finished graduating and moving." 5 successful, 1 unsuccessful, 1 unknown. (These assessments are the most untrustworthy of all, since relatively little time has passed; it's much easier to see whether 2006 projects have had a lasting effect than these 2008 projects.) ##### See also - The Monad.Reader's [Issue 12](http://haskell.org/sitewiki/images/f/f0/TMR-Issue12.pdf) #### 2009 Yet to come.. The student apps are due during 23 March ? 3 April. Look forward to it! #### Haskell roundup So, what lessons can we learn from the 3 SoCs? It seems to me like there are roughly 3 groups explanations of unsuccess or failure fall into. They are: 1) _Hubris_. GuiHaskell is probably a good example; it is essentially a bare-bones IDE, from its description. It is expecting a bit much of a single student in a single summer to write *that*! 2) _Unclear use_. HsJudy is my example here. There are already so many arrays and array types in Haskell! What does HsJudy bring to the table that justifies a FFI dependency? Who's going to use it? Pugs initially did apparently, but perhaps that's just because it was there - when I looked at Pugs/HsJudy in 2007, certainly Pugs had no need of it. (The data parallel physics engine is probably another good example. Is it just a benchmark for the GHC developers? Is it intended for actual games? If the former, why is it a SoC project, and if the latter, isn't that a little hubristic?) 3) _Lack of propaganda_. One of the reasons Don Stewart's bytestring library is so great is his relentless evangelizing of their benefits, which convinces people to actually take the effort to learn and use them, and eventually by network effects the whole Haskell community is affected & improved. Some of these SoC projects suffer from a distinct lack of community buy-in - who used HaskellNet? Who used Hat when it was updated? Indifference can be fatal, and can defeat the point of a project. What good is a library that no one uses? These aren't academic research projects which accomplish their task just by existing, after all. They're supposed to be useful to real Haskellers. [^complaints]: I can hear the wankers in the peanut gallery - "Yeah, and it's been buggy ever since!" Hush you. -- gwern From pgavin at gmail.com Tue Feb 10 23:40:57 2009 From: pgavin at gmail.com (Peter Gavin) Date: Tue Feb 10 23:30:49 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released Message-ID: <499256D9.7020102@gmail.com> Hi everyone, Oh, dear... it seems I've forgotten how to spell "cafe", and sent this message to haskell-caft@haskell.org the first time around. I resent it to all the lists again (just to make sure everyone interested receives it), so I apologize for any duplicated messages you might have received. In any case... I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new stuff has gone into this release, including: - Support for GHC 6.10 - Bindings to GIO and GtkSourceView-2.0 - Full switch to the new model-view implementation using a Haskell model - Support for many more model-based widgets such as IconView and an updated binding for ComboBox - Full Drag-and-Drop support - Better support for Attributes in Pango - Replaced Event for EventM monad, thereby improving efficiency and convenience - Functions for interaction between Cairo and Pixbuf drawing - Lots of bug fixes, code cleanups, and portability improvements With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have been deprecated. The TreeList modules have been deprecated from the Gtk+ bindings. Source and Win32 binaries are available at: https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 Thanks to everyone who submitted bug fixes and features this time around! Thanks, Peter Gavin Gtk2HS Release Manager From leimy2k at gmail.com Tue Feb 10 23:56:29 2009 From: leimy2k at gmail.com (David Leimbach) Date: Tue Feb 10 23:46:14 2009 Subject: [Haskell-cafe] GMP on Mac OS X linked statically by default Message-ID: <3e1162e60902102056k7960cb77l6db5e4665f0b4696@mail.gmail.com> Was there a reason for this? If so, it'd be nice if the package that was build explained why... otherwise it feels kind of arbitrary, and would be nice if there was documentation available to make it link dynamically in case someone didn't want to LGPL their program. Anyone know the steps to make it link dynamically? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090210/bd1cbaf1/attachment.htm From jefferson.r.heard at gmail.com Wed Feb 11 00:33:26 2009 From: jefferson.r.heard at gmail.com (Jeff Heard) Date: Wed Feb 11 00:23:10 2009 Subject: [Haskell-cafe] Re: [Gtk2hs-users] Gtk2HS 0.10.0 Released In-Reply-To: <499256D9.7020102@gmail.com> References: <499256D9.7020102@gmail.com> Message-ID: <4165d3a70902102133jc432096tfa4da6a3f2bfdddf@mail.gmail.com> Wonderful! Who maintains the mac-ports port of it? I'm itching to get hieroglyph working on the Mac. On Tue, Feb 10, 2009 at 11:40 PM, Peter Gavin wrote: > Hi everyone, > > Oh, dear... it seems I've forgotten how to spell "cafe", and sent this > message to haskell-caft@haskell.org the first time around. I resent it > to all the lists again (just to make sure everyone interested receives > it), so I apologize for any duplicated messages you might have received. > In any case... > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new > stuff has gone into this release, including: > > - Support for GHC 6.10 > - Bindings to GIO and GtkSourceView-2.0 > - Full switch to the new model-view implementation using a Haskell model > - Support for many more model-based widgets such as IconView and an > updated binding for ComboBox > - Full Drag-and-Drop support > - Better support for Attributes in Pango > - Replaced Event for EventM monad, thereby improving efficiency and > convenience > - Functions for interaction between Cairo and Pixbuf drawing > - Lots of bug fixes, code cleanups, and portability improvements > > With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have > been deprecated. The TreeList modules have been deprecated from the > Gtk+ bindings. > > Source and Win32 binaries are available at: > > > https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 > > Thanks to everyone who submitted bug fixes and features this time around! > > Thanks, > Peter Gavin > Gtk2HS Release Manager > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > _______________________________________________ > Gtk2hs-users mailing list > Gtk2hs-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > From tonal.promsoft at gmail.com Wed Feb 11 00:47:12 2009 From: tonal.promsoft at gmail.com (Alexandr N. Zamaraev) Date: Wed Feb 11 00:37:01 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <49926660.7040205@gmail.com> On Tue, Feb 10, 2009 at 6:26 AM, Malcolm Wallace wrote: >> Gentle Haskellers, >> >> The Google Summer of Code will be running again this year. Once again, >> haskell.org has the opportunity to bid to become a mentoring >> organisation. (Although, as always, there is no guarantee of >> acceptance.) >> >> If you have ideas for student projects that you think would benefit the >> Haskell community, now is the time to start discussing them on mailing >> lists of your choice. 1. Binding for FireBird RDBMS. 2. Library for manipulate ODF. 3. Binding to OOo UNO. From dons at galois.com Wed Feb 11 01:29:57 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 01:20:18 2009 Subject: [Haskell-cafe] GMP on Mac OS X linked statically by default In-Reply-To: <3e1162e60902102056k7960cb77l6db5e4665f0b4696@mail.gmail.com> References: <3e1162e60902102056k7960cb77l6db5e4665f0b4696@mail.gmail.com> Message-ID: <20090211062957.GA5482@whirlpool.galois.com> leimy2k: > Was there a reason for this? If so, it'd be nice if the package that was build > explained why... otherwise it feels kind of arbitrary, and would be nice if > there was documentation available to make it link dynamically in case someone > didn't want to LGPL their program. > > Anyone know the steps to make it link dynamically? > Here's how we do it on Windows. The Mac should be far easier, http://haskell.forkio.com/gmpwindows -- Don From dons at galois.com Wed Feb 11 01:33:06 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 01:23:25 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <499256D9.7020102@gmail.com> References: <499256D9.7020102@gmail.com> Message-ID: <20090211063306.GB5482@whirlpool.galois.com> Well done! Our flagship GUI bindings... Go team! -- Don pgavin: > Hi everyone, > > Oh, dear... it seems I've forgotten how to spell "cafe", and sent this > message to haskell-caft@haskell.org the first time around. I resent it > to all the lists again (just to make sure everyone interested receives > it), so I apologize for any duplicated messages you might have received. > In any case... > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new > stuff has gone into this release, including: > > - Support for GHC 6.10 > - Bindings to GIO and GtkSourceView-2.0 > - Full switch to the new model-view implementation using a Haskell model > - Support for many more model-based widgets such as IconView and an > updated binding for ComboBox > - Full Drag-and-Drop support > - Better support for Attributes in Pango > - Replaced Event for EventM monad, thereby improving efficiency and > convenience > - Functions for interaction between Cairo and Pixbuf drawing > - Lots of bug fixes, code cleanups, and portability improvements > > With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have > been deprecated. The TreeList modules have been deprecated from the > Gtk+ bindings. > > Source and Win32 binaries are available at: > > > https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 > > Thanks to everyone who submitted bug fixes and features this time around! > > Thanks, > Peter Gavin > Gtk2HS Release Manager > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From porges at porg.es Wed Feb 11 03:24:53 2009 From: porges at porg.es (George Pollard) Date: Wed Feb 11 03:14:44 2009 Subject: [Haskell-cafe] Why does sleep not work? In-Reply-To: <499220BD.1020108@libero.it> References: <49920835.7060507@libero.it> <1234309009.6786.12.camel@porges-laptop> <499220BD.1020108@libero.it> Message-ID: <1234340693.6778.1.camel@porges-laptop> On Wed, 2009-02-11 at 01:50 +0100, Manlio Perillo wrote: > George Pollard ha scritto: > > [...] > > > >> So, it seems nanosleep get interruped by a signal. > > > > This works: > > > >> import System.Posix > >> > >> main = do > >> putStrLn "Waiting for 5 seconds." > >> blockSignals $ addSignal sigVTALRM emptySignalSet > >> sleep 5 > >> putStrLn "Done." > >> > > So (see my earlier email) `sleep` is lying about what interrupts it :) > > > > - George > > > A possibly better solution is: > > sleep' :: Int -> IO Int > sleep' n = do > n' <- sleep n > if n' == 0 then return 0 else sleep' n' > > > From the trace, I see that nanosleep is being called 17 times here. > > Another solution is to set RTS flag: > ./bug_sleep +RTS -V0 -RTS > > > What strange is that the timer is created in non threaded RTS, too, but > sleep is interrupted only with the threaded RTS. > > This may be caused by an "incorrect" execution of a foreign function > marked safe. I just realized that for some reason I thought that `sleep` reported the signal that interrupted it... contrary to the documentation... as such, several of my replies to this thread may read as non-sequiturs :P -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/b010c2a1/attachment.bin From bulat.ziganshin at gmail.com Wed Feb 11 04:40:41 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 11 04:31:38 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> Message-ID: <1251338777.20090211124041@gmail.com> Hello Jamie, Wednesday, February 11, 2009, 5:54:09 AM, you wrote: > Seems like it is ok to write H.264 in Haskell and released via GPL > license? anyway it's impossible due to slow code generated by ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From d at domob.eu Wed Feb 11 05:12:13 2009 From: d at domob.eu (Daniel Kraft) Date: Wed Feb 11 04:57:56 2009 Subject: [Haskell-cafe] Haskell.org GSoC Message-ID: Hi, I noticed last year Haskell.org was a mentoring organization for Google's Summer of Code, and I barely noticed some discussion about it applying again this year :) I participated for GCC in 2008 and would like to try again this year; while I'm still active for GCC and will surely stay so, I'd like to see something new at least for GSoC. And Haskell.org would surely be a very, very nice organization. Since I discovered there's more than just a lot of imperative languages that are nearly all the same, I love to do some programming in Prolog, Scheme and of course Haskell. However, so far this was only some toy programs and nothing "really useful"; I'd like to change this (as well as learning more about Haskell during the projects). Here are some ideas for developing Haskell packages (that would hopefully be of general use to the community) as possible projects: - Numerics, like basic linear algebra routines, numeric integration and other basic algorithms of numeric mathematics. - A basic symbolic maths package; I've no idea how far one could do this as a single GSoC project, but it would surely be a very interesting task. Alternatively or in combination, one could try to use an existing free CAS package as engine. - Graphs. - Some simulation routines from physics, though I've not really an idea what exactly one should implement here best. - A logic programming framework. I know there's something like that for Scheme; in my experience, there are some problems best expressed logically with Prolog-style backtracking/predicates and unification. This could help use such formulations from inside a Haskell program. This is surely also a very interesting project. What do you think about these ideas? I'm pretty sure there are already some of those implemented, but I also hope some would be new and really of some use to the community. Do you think something would be especially nice to have and is currently missing? Thanks for your comments, Daniel From agocorona at gmail.com Wed Feb 11 05:31:16 2009 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed Feb 11 05:21:00 2009 Subject: [Haskell-cafe] evaluation semantics of bind In-Reply-To: <499230F4.2020407@freegeek.org> References: <75cc17ac0902050720hdd1d9cck82626b50928c369f@mail.gmail.com> <3410468369.20090205182759@gmail.com> <75cc17ac0902050746i7eba3defj9b3ea70b7621223b@mail.gmail.com> <499230F4.2020407@freegeek.org> Message-ID: Yes, Just must be executed because by the very definition of bind for the Maybe mondad, (>>=) Nothing f = Nothing (>>=) (Just x) f = f x He need to know if the value injected is Just or Nothing, but anyway, my point is : it is just plain lazy functional code!. No magic inside. everything depend on the definition of bind. 2009/2/11 wren ng thornton > > Alberto G. Corona wrote: >> >> forwarded: >> >> Yes! if no state is passed, the optimization makes sense and the term is >> not executed, like any lazy evaluation. For example, I used the debugger >> (that is, without optimizations) to verify it with the Maybe monad: >> op x= x+x >> >> print $ Just (op 1) >>= \y-> return (Just 2) >> >> does not evaluate op 1 > > Presumably you mean?: print $ Just (op 1) >>= \y-> return 2 > > >> but >> >> print $ Just (op 1) >>= \y-> return y >> >> does execute it. > > > Dashing off towards the White Knight, we should be careful what is said here. If we take only the expression "Just (op 1) >>= \y-> return y" then evaluating it yields "Just (op 1)". That is, it only evaluates to WHNF and does not evaluate what's inside. It is only once this value is subsequently handed off to print or some other function, that it may become evaluated. > > Similarly with the first example as originally written. It so happens that bind is non-strict for the field in Just, so we can discard the "op 1". However, according to the semantics we do not evaluate "Just 2" either; we only need to evaluate the return which will produce Just and pass the operand down. (Regardless of the fact that the value yielded by applying Just to 2 is Just 2. Expressions and their denotations are different.) > > -- > Live well, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/d8ae0eaf/attachment.htm From david.waern at gmail.com Wed Feb 11 05:40:44 2009 From: david.waern at gmail.com (David Waern) Date: Wed Feb 11 05:30:28 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: Message-ID: 2009/2/11 Gwern Branwen : > [^complaints]: I can hear the wankers in the peanut gallery - "Yeah, > and it's been buggy ever since!" Hush you. Those (aforementioned) people should keep in mind we tried to keep the scope of the project down to just making the new Haddock support the features of the old Haddock (no type inference, docs for GHC extensions, etc). Most of the bugs concerning the pre-GHC subset of Haddock have now been fixed (although there are a few left). Most other problems we're currently seeing is with GHC extensions, like for instance Template Haskell.You should not blame the SoC project so much for this (although it could have handled extensions more gracefully). The project was also run in a time when the GHC API was not so evolved and had a bug or two. David From duncan.coutts at worc.ox.ac.uk Wed Feb 11 05:48:52 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 11 05:38:51 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: References: Message-ID: <1234349332.5238.246.camel@localhost> On Tue, 2009-02-10 at 10:21 -0800, Corey O'Connor wrote: > I released a new version of data-spacepart that resolved some of the > issues with the previous release. One issue I had was the previous > release used the version numbering scheme I use at work: > [date].[release] Which does not appear to work as well as the > traditional X.Y.Z release numbering scheme with Cabal. I'm not sure I understand. Is there something in Cabal or Hackage that makes date-based numbering schemes not work well? > As part of the new release I changed the version numbering scheme. An > *obviously* bad idea if I thought it through. Any [date].[release] > style version number is greater than a X.Y.Z version number until X > gets rather large. > > So what to do? Continue using the [date].[release] version numbering > scheme? Or is there a way to coax HackageDB to ignore the old release? Yeah, there's not a lot you can do except make the number higher. The problem is not just hackage, it's all the previous releases in the wild. All the tools assume the normal ordering on version numbers. Not just the Cabal/Hackage tools but the native distro tools too. People have suggested "epochs", but it turns out this doesn't make the situation any better, as one can never get rid of having to specify the epoch (eg 1:0.1.1). Duncan From Christian.Maeder at dfki.de Wed Feb 11 05:49:14 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Feb 11 05:39:04 2009 Subject: [Haskell-cafe] Re: Gtk2HS 0.10.0 Released In-Reply-To: <499256D9.7020102@gmail.com> References: <499256D9.7020102@gmail.com> Message-ID: <4992AD2A.2060001@dfki.de> Peter Gavin wrote: > > https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 Maybe you could update your central page http://www.haskell.org/gtk2hs/ at least with a link to a new central page. You also did not care much about bug tracking via http://hackage.haskell.org/trac/gtk2hs/. Isn't this the recommend way to report bugs any longer? Cheers Christian From wss at cs.nott.ac.uk Wed Feb 11 06:40:54 2009 From: wss at cs.nott.ac.uk (Wouter Swierstra) Date: Wed Feb 11 06:30:37 2009 Subject: [Haskell-cafe] ANN: Data.Stream 0.3 Message-ID: <023F46D8-0EE9-483C-AF4C-9BFFFC8165BC@cs.nott.ac.uk> I've released a new version of the Data.Stream package, a modest library for manipulating infinite lists. Changes include: * Support for lazy SmallCheck; * Improved Show instance; * Stricter scans; * Various documentation fixes; * Several new functions from Data.List. Many of these features were based on patches by Bas van Dijk - thank you Bas! Haddock: http://www.cs.nott.ac.uk/~wss/repos/Stream/dist/doc/html/Stream/ Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream/ darcs: darcs get http://www.cs.nott.ac.uk/~wss/repos/Stream All the best, Wouter From bugfact at gmail.com Wed Feb 11 07:36:23 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Wed Feb 11 07:26:27 2009 Subject: [Haskell-cafe] Re: [Gtk2hs-users] Gtk2HS 0.10.0 Released In-Reply-To: <499254F8.7000009@gmail.com> References: <499254F8.7000009@gmail.com> Message-ID: Great job! I have been using the RC1 version for a while and it works well. - Full switch to the new model-view implementation using a Haskell model This is very interesting. Do demos exist to show this? On Wed, Feb 11, 2009 at 5:32 AM, Peter Gavin wrote: > Hi everyone, > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new > stuff has gone into this release, including: > > - Support for GHC 6.10 > - Bindings to GIO and GtkSourceView-2.0 > - Full switch to the new model-view implementation using a Haskell model > - Support for many more model-based widgets such as IconView and an > updated binding for ComboBox > - Full Drag-and-Drop support > - Better support for Attributes in Pango > - Replaced Event for EventM monad, thereby improving efficiency and > convenience > - Functions for interaction between Cairo and Pixbuf drawing > - Lots of bug fixes, code cleanups, and portability improvements > > With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have > been deprecated. The TreeList modules have been deprecated from the > Gtk+ bindings. > > Source and Win32 binaries are available at: > > > > https://sourceforge.net/project/showfiles.php?group_id=49207&package_id=42440&release_id=659598 > > Thanks to everyone who submitted bug fixes and features this time around! > > Thanks, > Peter Gavin > Gtk2HS Release Manager > > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code > to > build responsive, highly engaging applications that combine the power of > local > resources and data with the reach of the web. Download the Adobe AIR SDK > and > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > _______________________________________________ > Gtk2hs-users mailing list > Gtk2hs-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/46fb2143/attachment.htm From g9ks157k at acme.softbase.org Wed Feb 11 07:40:26 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Wed Feb 11 07:30:16 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: References: <200902100916.33357.g9ks157k@acme.softbase.org> Message-ID: <200902111340.27082.g9ks157k@acme.softbase.org> Am Mittwoch, 11. Februar 2009 00:46 schrieben Sie: > I suppose I should point out what seems obvious to me, which is that one > could embed a substantial chunk of MathML (possibly all of it) in TeX. I > mean, give it a TeX-parseable syntax. You can convert MathML into TeX but not the other way round. How would you translate $a \odot b \otimes c$? It depends on the precedence of the operators. Best wishes, Wolfgang From bugfact at gmail.com Wed Feb 11 07:54:52 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Wed Feb 11 07:44:36 2009 Subject: [Haskell-cafe] Re: [Gtk2hs-users] Gtk2HS 0.10.0 Released In-Reply-To: <1234356014.8184.1.camel@aconit> References: <499254F8.7000009@gmail.com> <1234356014.8184.1.camel@aconit> Message-ID: Nice. The demos are now included only in the source distri right? On Wed, Feb 11, 2009 at 1:40 PM, Axel Simon wrote: > On Wed, 2009-02-11 at 13:36 +0100, Peter Verswyvelen wrote: > > Great job! I have been using the RC1 version for a while and it works > > well. > > > > > > - Full switch to the new model-view implementation using a Haskell > > model > > > > > > This is very interesting. Do demos exist to show this? > > > > Yes, all the demos under demo/treeList have been converted to use the > new ModelView (the directory name is stale, it should probably be > renamed to modelView since TreeList was the old interface). > > There's also a combo box demo in demo/menu. > > Cheers, > Axel. > > > On Wed, Feb 11, 2009 at 5:32 AM, Peter Gavin wrote: > > Hi everyone, > > > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot > > of new > > stuff has gone into this release, including: > > > > - Support for GHC 6.10 > > - Bindings to GIO and GtkSourceView-2.0 > > - Full switch to the new model-view implementation using a > > Haskell model > > - Support for many more model-based widgets such as IconView > > and an > > updated binding for ComboBox > > - Full Drag-and-Drop support > > - Better support for Attributes in Pango > > - Replaced Event for EventM monad, thereby improving > > efficiency and > > convenience > > - Functions for interaction between Cairo and Pixbuf drawing > > - Lots of bug fixes, code cleanups, and portability > > improvements > > > > With this release, the bindings to GnomeVFS and > > GtkSourceView-1.0 have > > been deprecated. The TreeList modules have been deprecated > > from the > > Gtk+ bindings. > > > > Source and Win32 binaries are available at: > > > > > > > https://sourceforge.net/project/showfiles.php?group_id=49207&package_id=42440&release_id=659598 > > > > Thanks to everyone who submitted bug fixes and features this > > time around! > > > > Thanks, > > Peter Gavin > > Gtk2HS Release Manager > > > > > > > ------------------------------------------------------------------------------ > > Create and Deploy Rich Internet Apps outside the browser with > > Adobe(R)AIR(TM) > > software. With Adobe AIR, Ajax developers can use existing > > skills and code to > > build responsive, highly engaging applications that combine > > the power of local > > resources and data with the reach of the web. Download the > > Adobe AIR SDK and > > Ajax docs to start building applications > > today-http://p.sf.net/sfu/adobe-com > > _______________________________________________ > > Gtk2hs-users mailing list > > Gtk2hs-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > > > > > > ------------------------------------------------------------------------------ > > Create and Deploy Rich Internet Apps outside the browser with > Adobe(R)AIR(TM) > > software. With Adobe AIR, Ajax developers can use existing skills and > code to > > build responsive, highly engaging applications that combine the power of > local > > resources and data with the reach of the web. Download the Adobe AIR SDK > and > > Ajax docs to start building applications today- > http://p.sf.net/sfu/adobe-com > > _______________________________________________ Gtk2hs-users mailing list > Gtk2hs-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/ef54343d/attachment.htm From cristiano.paris at gmail.com Wed Feb 11 08:22:15 2009 From: cristiano.paris at gmail.com (Cristiano Paris) Date: Wed Feb 11 08:11:59 2009 Subject: [Haskell-cafe] Can this be done? Message-ID: I wonder whether this can be done in Haskell (see muleherd's comment): http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ Cristiano From bugfact at gmail.com Wed Feb 11 08:30:59 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Wed Feb 11 08:20:49 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: References: Message-ID: I haven't looked at the details, but I think this is what a library like Reactive from Conal Elliott could do, but as far as I understand it, it is still work in progress. On Wed, Feb 11, 2009 at 2:22 PM, Cristiano Paris wrote: > I wonder whether this can be done in Haskell (see muleherd's comment): > > > http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ > > Cristiano > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/4fa7fc22/attachment.htm From alistair at abayley.org Wed Feb 11 08:34:29 2009 From: alistair at abayley.org (Alistair Bayley) Date: Wed Feb 11 08:24:14 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: References: Message-ID: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> 2009/2/11 Cristiano Paris : > I wonder whether this can be done in Haskell (see muleherd's comment): > > http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ WASH did/does something similar. You can certainly write applications in a similar, workflow-ish style (rather than like a state machine). Alistair From cristiano.paris at gmail.com Wed Feb 11 08:41:30 2009 From: cristiano.paris at gmail.com (Cristiano Paris) Date: Wed Feb 11 08:31:13 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: References: Message-ID: On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen wrote: > I haven't looked at the details, but I think this is what a library like > Reactive from Conal Elliott could do, but as far as I understand it, it is > still work in progress. I'm interested in the possibility of stopping/pickling/unpickling/resuming a computation. Cristiano From qdunkan at gmail.com Wed Feb 11 08:43:34 2009 From: qdunkan at gmail.com (Evan Laforge) Date: Wed Feb 11 08:33:17 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> Message-ID: <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> On Wed, Feb 11, 2009 at 9:34 PM, Alistair Bayley wrote: > 2009/2/11 Cristiano Paris : >> I wonder whether this can be done in Haskell (see muleherd's comment): >> >> http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ > > WASH did/does something similar. You can certainly write applications > in a similar, workflow-ish style (rather than like a state machine). To hijack the subject, what happened to WASH? The paper seemed like it was full of interesting ideas, but the implementation seems to have failed to capture many hearts. Now it seems like a stagnant project. What were the fatal flaws? [ paris ] > I'm interested in the possibility of > stopping/pickling/unpickling/resuming a computation. >From what I recall, WASH stores the continuation in the URL, at least if you turn on that setting... From sylvan at student.chalmers.se Wed Feb 11 08:53:56 2009 From: sylvan at student.chalmers.se (Sebastian Sylvan) Date: Wed Feb 11 08:43:40 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: References: Message-ID: <3d96ac180902110553s4a982d55kac8a08104411d2af@mail.gmail.com> On Wed, Feb 11, 2009 at 1:41 PM, Cristiano Paris wrote: > On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen > wrote: > > I haven't looked at the details, but I think this is what a library like > > Reactive from Conal Elliott could do, but as far as I understand it, it > is > > still work in progress. > > I'm interested in the possibility of > stopping/pickling/unpickling/resuming a computation. > I think that would be difficult. You could probably store the continuation in a server-side cache if you aren't doing CGI but have a persistent server process, but eventually you'll need to discard unused continuations to avoid running out of memory. You may be able to use a WASH style continuation model in conjunction with this. So you store the session logs on disk, and if the continuation does not exist in memory you'd fetch the session log from disk, replay the whole session from that, and reproduce the continuation that way. That way most sessions would just work directly off of the cache and never touch disk, but if someone waits too long (or, say, bookmarks a page in the middle of the session!) there's still a fallback stored on disk. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/4eae922b/attachment.htm From haskell at datakids.org Wed Feb 11 09:06:26 2009 From: haskell at datakids.org (Jamie) Date: Wed Feb 11 08:56:09 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <1251338777.20090211124041@gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> Message-ID: Hi Bulat, On Wed, 11 Feb 2009, Bulat Ziganshin wrote: > Hello Jamie, > > Wednesday, February 11, 2009, 5:54:09 AM, you wrote: > >> Seems like it is ok to write H.264 in Haskell and released via GPL >> license? > > anyway it's impossible due to slow code generated by ghc I see, I guess I'll have to stuck with C version of H.264 in my Haskell programs. Maybe in future when ghc have better optimizations. At least one can write various subset of H.323 standard in Haskell as the only part of H.323 subset that is CPU intensive is video/audio codecs, the rest is just mainly network I/O code. http://www.h323plus.org/standards/ > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com Jamie From cristiano.paris at gmail.com Wed Feb 11 09:14:02 2009 From: cristiano.paris at gmail.com (Cristiano Paris) Date: Wed Feb 11 09:03:44 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: <3d96ac180902110553s4a982d55kac8a08104411d2af@mail.gmail.com> References: <3d96ac180902110553s4a982d55kac8a08104411d2af@mail.gmail.com> Message-ID: On Wed, Feb 11, 2009 at 2:53 PM, Sebastian Sylvan wrote: > I think that would be difficult. You could probably store the continuation > in a server-side cache if you aren't doing CGI but have a persistent server > process, but eventually you'll need to discard unused continuations to avoid > running out of memory. You may be able to use a WASH style continuation > model in conjunction with this. So you store the session logs on disk, and > if the continuation does not exist in memory you'd fetch the session log > from disk, replay the whole session from that, and reproduce the > continuation that way. That way most sessions would just work directly off > of the cache and never touch disk, but if someone waits too long (or, say, > bookmarks a page in the middle of the session!) there's still a fallback > stored on disk. I thought about something like that. In this regards, I narrowed the problem to a computation's internal binding to symbol names. With this respect, a point-free approach, like the one found in the factor language, would be simpler to handle as you'd have to serialize the state of stacks and those of any other monads used. Cristiano From gwern0 at gmail.com Wed Feb 11 09:43:01 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Feb 11 09:35:15 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <499256D9.7020102@gmail.com> Message-ID: Skipped content of type multipart/signed-------------- next part -------------- gwern@craft:40742~/gtk2hs-0.10.0>./configure && make [ 9:39AM] checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... none checking how to run the C preprocessor... gcc -E checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for ar... /usr/bin/ar checking for ld... /usr/bin/ld checking for basename... /usr/bin/basename checking for grep that handles long lines and -e... /bin/grep checking for gzip... /bin/gzip checking for a sed that does not truncate output... /bin/sed checking for cut... /usr/bin/cut checking for tar... /bin/tar checking for touch... /usr/bin/touch checking for ranlib... ranlib checking for xargs... /usr/bin/xargs checking for ghc... /home/gwern/bin/bin/ghc checking version of GHC... 6.10.1 checking for ghc-pkg... /home/gwern/bin/bin/ghc-pkg checking whether to build deprecated bindings... yes checking whether to build deprecated packages (gnomevfs, sourceview)... yes checking for the GHC package "base"... yes, version 4.0.0.0 checking for the GHC package "haskell98"... yes, version 1.0.1.0 checking for the GHC package "mtl"... yes, version 1.1.0.2 checking for the GHC package "bytestring"... yes, version 0.9.1.4 checking for the GHC package "containers"... yes, version 0.2.0.0 checking for the GHC package "array"... yes, version 0.2.0.0 checking for the GHC package "old-time"... yes, version 1.0.0.1 checking for the GHC package "pretty"... yes, version 1.0.1.0 checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GLIB... yes checking for GTK... yes checking whether to build gtk package... yes checking for GIO... yes checking whether to build gio package... yes checking for LIBGLADE... yes checking whether to build glade package... yes checking for GCONF... yes checking whether to build gconf package... yes checking for GTKSOURCEVIEW2... no checking whether to build gtksourceview2 package... no checking for SOURCEVIEW... yes checking whether to build sourceview package... yes checking for MOZILLA_MOZEMBED... yes checking whether to build mozembed package... yes checking for SEAMONKEY_MOZEMBED... no checking whether to build mozembed package... no checking for FIREFOX_MOZEMBED... no checking whether to build mozembed package... no checking for XULRUNNER_MOZEMBED... no checking whether to build mozembed package... no checking for CAIRO... yes checking whether to build cairo package... yes checking for SVGCAIRO... yes checking whether to build svgcairo package... yes checking for GTKGLEXT... yes checking whether to build gtkglext package... yes checking for GNOMEVFS... yes checking whether to build gnomevfs package... yes checking for GSTREAMER... yes checking whether to build gstreamer package... yes checking for hsc2hs... /home/gwern/bin/bin/hsc2hs checking for happy... /home/gwern/bin/bin/happy checking version of happy... 1.18.2 checking for alex... /home/gwern/bin/bin/alex configure: creating ./config.status config.status: creating Makefile config.status: creating gtk2hs.spec config.status: creating mk/chsDepend config.status: creating mk/link-splitobjs.sh config.status: creating mk/fix-package-conf.sh config.status: creating docs/prologue.txt config.status: creating glib/glib.package.conf config.status: creating glib/glib.cabal config.status: creating gtk/gtk.package.conf config.status: creating gtk/gtk.cabal config.status: creating gio/gio.package.conf config.status: creating gio/gio.cabal config.status: creating glade/glade.package.conf config.status: creating glade/glade.cabal config.status: creating gconf/gconf.package.conf config.status: creating gconf/gconf.cabal config.status: creating sourceview/sourceview.package.conf config.status: creating sourceview/sourceview.cabal config.status: creating gtksourceview2/gtksourceview2.package.conf config.status: creating gtksourceview2/gtksourceview2.cabal config.status: creating mozembed/mozembed.package.conf config.status: creating mozembed/mozembed.cabal config.status: creating cairo/cairo.package.conf config.status: creating cairo/cairo.cabal config.status: creating svgcairo/svgcairo.package.conf config.status: creating svgcairo/svgcairo.cabal config.status: creating gtkglext/gtkglext.package.conf config.status: creating gtkglext/gtkglext.cabal config.status: creating soegtk/soegtk.package.conf config.status: creating soegtk/soegtk.cabal config.status: creating gnomevfs/gnomevfs.package.conf config.status: creating gnomevfs/gnomevfs.cabal config.status: creating gstreamer/gstreamer.package.conf config.status: creating gstreamer/gstreamer.cabal config.status: creating gtk2hs-config.h config.status: gtk2hs-config.h is unchanged config.status: executing depfiles commands config.status: executing default commands ************************************************** * Configuration completed successfully. * * The following packages will be built: * * glib : yes * gtk : yes * gio : yes * glade : yes * cairo : yes * svgcairo : yes * gtkglext : yes * gconf : yes * sourceview : yes * gtksourceview2 : no * mozembed : yes * soegtk : yes * gnomevfs : yes * gstreamer : yes * documentation : no * * Now do "(g)make" followed by "(g)make install" ************************************************** echo "[]" > package.conf.inplace /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|System.Glib, System.Glib.Attributes, System.Glib.FFI, System.Glib.Flags, System.Glib.GDateTime, System.Glib.GError, System.Glib.GList, System.Glib.GObject, System.Glib.GParameter, System.Glib.GType, System.Glib.GTypeConstants, System.Glib.GValue, System.Glib.GValueTypes, System.Glib.MainLoop, System.Glib.Properties, System.Glib.Signals, System.Glib.StoreValue, System.Glib.Types, System.Glib.UTFString|' glib/glib.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.Rendering.Cairo, Graphics.Rendering.Cairo.Internal, Graphics.Rendering.Cairo.Internal.Drawing.Cairo, Graphics.Rendering.Cairo.Internal.Drawing.Paths, Graphics.Rendering.Cairo.Internal.Drawing.Patterns, Graphics.Rendering.Cairo.Internal.Drawing.Text, Graphics.Rendering.Cairo.Internal.Drawing.Transformations, Graphics.Rendering.Cairo.Internal.Fonts.FontOptions, Graphics.Rendering.Cairo.Internal.Surfaces.Image, Graphics.Rendering.Cairo.Internal.Surfaces.PDF, Graphics.Rendering.Cairo.Internal.Surfaces.PNG, Graphics.Rendering.Cairo.Internal.Surfaces.PS, Graphics.Rendering.Cairo.Internal.Surfaces.SVG, Graphics.Rendering.Cairo.Internal.Surfaces.Surface, Graphics.Rendering.Cairo.Internal.Utilities, Graphics.Rendering.Cairo.Matrix, Graphics.Rendering.Cairo.Types|' cairo/cairo.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.Rendering.Cairo.SVG|' svgcairo/svgcairo.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.UI.Gtk, Graphics.UI.Gtk.Abstract.Bin, Graphics.UI.Gtk.Abstract.Box, Graphics.UI.Gtk.Abstract.ButtonBox, Graphics.UI.Gtk.Abstract.Container, Graphics.UI.Gtk.Abstract.ContainerChildProperties, Graphics.UI.Gtk.Abstract.Misc, Graphics.UI.Gtk.Abstract.Object, Graphics.UI.Gtk.Abstract.Paned, Graphics.UI.Gtk.Abstract.Range, Graphics.UI.Gtk.Abstract.Scale, Graphics.UI.Gtk.Abstract.Scrollbar, Graphics.UI.Gtk.Abstract.Separator, Graphics.UI.Gtk.Abstract.Widget, Graphics.UI.Gtk.ActionMenuToolbar.Action, Graphics.UI.Gtk.ActionMenuToolbar.ActionGroup, Graphics.UI.Gtk.ActionMenuToolbar.RadioAction, Graphics.UI.Gtk.ActionMenuToolbar.ToggleAction, Graphics.UI.Gtk.ActionMenuToolbar.UIManager, Graphics.UI.Gtk.Buttons.Button, Graphics.UI.Gtk.Buttons.CheckButton, Graphics.UI.Gtk.Buttons.RadioButton, Graphics.UI.Gtk.Buttons.ToggleButton, Graphics.UI.Gtk.Cairo, Graphics.UI.Gtk.Display.AccelLabel, Graphics.UI.Gtk.Display.Image, Graphics.UI.Gtk.Display.Label, Graphics.UI.Gtk.Display.ProgressBar, Graphics.UI.Gtk.Display.StatusIcon, Graphics.UI.Gtk.Display.Statusbar, Graphics.UI.Gtk.Embedding.Embedding, Graphics.UI.Gtk.Embedding.Plug, Graphics.UI.Gtk.Embedding.Socket, Graphics.UI.Gtk.Entry.Editable, Graphics.UI.Gtk.Entry.Entry, Graphics.UI.Gtk.Entry.EntryCompletion, Graphics.UI.Gtk.Entry.HScale, Graphics.UI.Gtk.Entry.SpinButton, Graphics.UI.Gtk.Entry.VScale, Graphics.UI.Gtk.Gdk.Cursor, Graphics.UI.Gtk.Gdk.DrawWindow, Graphics.UI.Gtk.Gdk.Drawable, Graphics.UI.Gtk.Gdk.Enums, Graphics.UI.Gtk.Gdk.EventM, Graphics.UI.Gtk.Gdk.Events, Graphics.UI.Gtk.Gdk.GC, Graphics.UI.Gtk.Gdk.Gdk, Graphics.UI.Gtk.Gdk.Keys, Graphics.UI.Gtk.Gdk.Pixbuf, Graphics.UI.Gtk.Gdk.PixbufData, Graphics.UI.Gtk.Gdk.Pixmap, Graphics.UI.Gtk.Gdk.Region, Graphics.UI.Gtk.Gdk.Screen, Graphics.UI.Gtk.General.Clipboard, Graphics.UI.Gtk.General.DNDTypes, Graphics.UI.Gtk.General.Drag, Graphics.UI.Gtk.General.Enums, Graphics.UI.Gtk.General.General, Graphics.UI.Gtk.General.IconFactory, Graphics.UI.Gtk.General.Selection, Graphics.UI.Gtk.General.StockItems, Graphics.UI.Gtk.General.Structs, Graphics.UI.Gtk.General.Style, Graphics.UI.Gtk.Layout.Alignment, Graphics.UI.Gtk.Layout.AspectFrame, Graphics.UI.Gtk.Layout.Expander, Graphics.UI.Gtk.Layout.Fixed, Graphics.UI.Gtk.Layout.HBox, Graphics.UI.Gtk.Layout.HButtonBox, Graphics.UI.Gtk.Layout.HPaned, Graphics.UI.Gtk.Layout.Layout, Graphics.UI.Gtk.Layout.Notebook, Graphics.UI.Gtk.Layout.Table, Graphics.UI.Gtk.Layout.VBox, Graphics.UI.Gtk.Layout.VButtonBox, Graphics.UI.Gtk.Layout.VPaned, Graphics.UI.Gtk.MenuComboToolbar.CheckMenuItem, Graphics.UI.Gtk.MenuComboToolbar.Combo, Graphics.UI.Gtk.MenuComboToolbar.ComboBox, Graphics.UI.Gtk.MenuComboToolbar.ComboBoxEntry, Graphics.UI.Gtk.MenuComboToolbar.ImageMenuItem, Graphics.UI.Gtk.MenuComboToolbar.Menu, Graphics.UI.Gtk.MenuComboToolbar.MenuBar, Graphics.UI.Gtk.MenuComboToolbar.MenuItem, Graphics.UI.Gtk.MenuComboToolbar.MenuShell, Graphics.UI.Gtk.MenuComboToolbar.MenuToolButton, Graphics.UI.Gtk.MenuComboToolbar.OptionMenu, Graphics.UI.Gtk.MenuComboToolbar.RadioMenuItem, Graphics.UI.Gtk.MenuComboToolbar.RadioToolButton, Graphics.UI.Gtk.MenuComboToolbar.SeparatorMenuItem, Graphics.UI.Gtk.MenuComboToolbar.SeparatorToolItem, Graphics.UI.Gtk.MenuComboToolbar.TearoffMenuItem, Graphics.UI.Gtk.MenuComboToolbar.ToggleToolButton, Graphics.UI.Gtk.MenuComboToolbar.ToolButton, Graphics.UI.Gtk.MenuComboToolbar.ToolItem, Graphics.UI.Gtk.MenuComboToolbar.Toolbar, Graphics.UI.Gtk.Misc.Adjustment, Graphics.UI.Gtk.Misc.Arrow, Graphics.UI.Gtk.Misc.Calendar, Graphics.UI.Gtk.Misc.DrawingArea, Graphics.UI.Gtk.Misc.EventBox, Graphics.UI.Gtk.Misc.HandleBox, Graphics.UI.Gtk.Misc.SizeGroup, Graphics.UI.Gtk.Misc.Tooltips, Graphics.UI.Gtk.Misc.Viewport, Graphics.UI.Gtk.ModelView, Graphics.UI.Gtk.ModelView.CellLayout, Graphics.UI.Gtk.ModelView.CellRenderer, Graphics.UI.Gtk.ModelView.CellRendererCombo, Graphics.UI.Gtk.ModelView.CellRendererPixbuf, Graphics.UI.Gtk.ModelView.CellRendererProgress, Graphics.UI.Gtk.ModelView.CellRendererText, Graphics.UI.Gtk.ModelView.CellRendererToggle, Graphics.UI.Gtk.ModelView.CellView, Graphics.UI.Gtk.ModelView.CustomStore, Graphics.UI.Gtk.ModelView.IconView, Graphics.UI.Gtk.ModelView.ListStore, Graphics.UI.Gtk.ModelView.Sequence, Graphics.UI.Gtk.ModelView.TreeDrag, Graphics.UI.Gtk.ModelView.TreeModel, Graphics.UI.Gtk.ModelView.TreeModelSort, Graphics.UI.Gtk.ModelView.TreeRowReference, Graphics.UI.Gtk.ModelView.TreeSelection, Graphics.UI.Gtk.ModelView.TreeSortable, Graphics.UI.Gtk.ModelView.TreeStore, Graphics.UI.Gtk.ModelView.TreeView, Graphics.UI.Gtk.ModelView.TreeViewColumn, Graphics.UI.Gtk.ModelView.Types, Graphics.UI.Gtk.Multiline.TextBuffer, Graphics.UI.Gtk.Multiline.TextIter, Graphics.UI.Gtk.Multiline.TextMark, Graphics.UI.Gtk.Multiline.TextTag, Graphics.UI.Gtk.Multiline.TextTagTable, Graphics.UI.Gtk.Multiline.TextView, Graphics.UI.Gtk.Multiline.Types, Graphics.UI.Gtk.Ornaments.Frame, Graphics.UI.Gtk.Ornaments.HSeparator, Graphics.UI.Gtk.Ornaments.VSeparator, Graphics.UI.Gtk.Pango.Attributes, Graphics.UI.Gtk.Pango.Context, Graphics.UI.Gtk.Pango.Description, Graphics.UI.Gtk.Pango.Enums, Graphics.UI.Gtk.Pango.Font, Graphics.UI.Gtk.Pango.GlyphStorage, Graphics.UI.Gtk.Pango.Layout, Graphics.UI.Gtk.Pango.Markup, Graphics.UI.Gtk.Pango.Rendering, Graphics.UI.Gtk.Pango.Structs, Graphics.UI.Gtk.Pango.Types, Graphics.UI.Gtk.Scrolling.HScrollbar, Graphics.UI.Gtk.Scrolling.ScrolledWindow, Graphics.UI.Gtk.Scrolling.VScrollbar, Graphics.UI.Gtk.Selectors.ColorButton, Graphics.UI.Gtk.Selectors.ColorSelection, Graphics.UI.Gtk.Selectors.ColorSelectionDialog, Graphics.UI.Gtk.Selectors.FileChooser, Graphics.UI.Gtk.Selectors.FileChooserButton, Graphics.UI.Gtk.Selectors.FileChooserDialog, Graphics.UI.Gtk.Selectors.FileChooserWidget, Graphics.UI.Gtk.Selectors.FileFilter, Graphics.UI.Gtk.Selectors.FileSelection, Graphics.UI.Gtk.Selectors.FontButton, Graphics.UI.Gtk.Selectors.FontSelection, Graphics.UI.Gtk.Selectors.FontSelectionDialog, Graphics.UI.Gtk.Signals, Graphics.UI.Gtk.TreeList, Graphics.UI.Gtk.TreeList.CellRenderer, Graphics.UI.Gtk.TreeList.CellRendererPixbuf, Graphics.UI.Gtk.TreeList.CellRendererText, Graphics.UI.Gtk.TreeList.CellRendererToggle, Graphics.UI.Gtk.TreeList.CellView, Graphics.UI.Gtk.TreeList.IconView, Graphics.UI.Gtk.TreeList.ListStore, Graphics.UI.Gtk.TreeList.TreeIter, Graphics.UI.Gtk.TreeList.TreeModel, Graphics.UI.Gtk.TreeList.TreeModelSort, Graphics.UI.Gtk.TreeList.TreePath, Graphics.UI.Gtk.TreeList.TreeRowReference, Graphics.UI.Gtk.TreeList.TreeSelection, Graphics.UI.Gtk.TreeList.TreeStore, Graphics.UI.Gtk.TreeList.TreeView, Graphics.UI.Gtk.TreeList.TreeViewColumn, Graphics.UI.Gtk.Types, Graphics.UI.Gtk.Windows.AboutDialog, Graphics.UI.Gtk.Windows.Dialog, Graphics.UI.Gtk.Windows.MessageDialog, Graphics.UI.Gtk.Windows.Window, Graphics.UI.Gtk.Windows.WindowGroup|' gtk/gtk.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.SOE.Gtk|' soegtk/soegtk.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|System.GIO, System.GIO.AsyncResult, System.GIO.Base, System.GIO.Cancellable, System.GIO.File, System.GIO.FileAttribute, System.GIO.Signals, System.GIO.Types|' gio/gio.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.UI.Gtk.Glade, Graphics.UI.Gtk.Glade.Types|' glade/glade.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|System.Gnome.GConf, System.Gnome.GConf.GConfClient, System.Gnome.GConf.GConfValue, System.Gnome.GConf.Signals, System.Gnome.GConf.Types|' gconf/gconf.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.UI.Gtk.SourceView, Graphics.UI.Gtk.SourceView.SourceBuffer, Graphics.UI.Gtk.SourceView.SourceIter, Graphics.UI.Gtk.SourceView.SourceLanguage, Graphics.UI.Gtk.SourceView.SourceLanguagesManager, Graphics.UI.Gtk.SourceView.SourceMarker, Graphics.UI.Gtk.SourceView.SourceStyleScheme, Graphics.UI.Gtk.SourceView.SourceTag, Graphics.UI.Gtk.SourceView.SourceTagStyle, Graphics.UI.Gtk.SourceView.SourceTagTable, Graphics.UI.Gtk.SourceView.SourceView, Graphics.UI.Gtk.SourceView.Types|' sourceview/sourceview.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.UI.Gtk.MozEmbed, Graphics.UI.Gtk.MozEmbed.Types|' mozembed/mozembed.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Graphics.UI.Gtk.OpenGL, Graphics.UI.Gtk.OpenGL.Config, Graphics.UI.Gtk.OpenGL.Context, Graphics.UI.Gtk.OpenGL.Drawable, Graphics.UI.Gtk.OpenGL.DrawingArea, Graphics.UI.Gtk.OpenGL.General, Graphics.UI.Gtk.OpenGL.Pixmap, Graphics.UI.Gtk.OpenGL.Types, Graphics.UI.Gtk.OpenGL.Window|' gtkglext/gtkglext.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|System.Gnome.VFS, System.Gnome.VFS.Cancellation, System.Gnome.VFS.Constants, System.Gnome.VFS.Directory, System.Gnome.VFS.Drive, System.Gnome.VFS.Error, System.Gnome.VFS.FileInfo, System.Gnome.VFS.Hierarchy, System.Gnome.VFS.Init, System.Gnome.VFS.Marshal, System.Gnome.VFS.Monitor, System.Gnome.VFS.Ops, System.Gnome.VFS.Signals, System.Gnome.VFS.Types, System.Gnome.VFS.URI, System.Gnome.VFS.Util, System.Gnome.VFS.Volume, System.Gnome.VFS.VolumeMonitor, System.Gnome.VFS.Xfer|' gnomevfs/gnomevfs.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; /bin/sed -e 's|${pkglibdir}/imports|.|' -e 's|"${pkglibdir}/include"|.|' -e 's|${pkglibdir}|.|' -e 's|${modules}|Media.Streaming.GStreamer, Media.Streaming.GStreamer.Audio.Audio, Media.Streaming.GStreamer.Audio.AudioClock, Media.Streaming.GStreamer.Audio.Constants, Media.Streaming.GStreamer.Audio.Hierarchy, Media.Streaming.GStreamer.Audio.Types, Media.Streaming.GStreamer.Base, Media.Streaming.GStreamer.Base.Adapter, Media.Streaming.GStreamer.Base.BaseSink, Media.Streaming.GStreamer.Base.BaseSrc, Media.Streaming.GStreamer.Base.BaseTransform, Media.Streaming.GStreamer.Base.CollectPads, Media.Streaming.GStreamer.Base.Constants, Media.Streaming.GStreamer.Base.GObjectHierarchy, Media.Streaming.GStreamer.Base.Hierarchy, Media.Streaming.GStreamer.Base.PushSrc, Media.Streaming.GStreamer.Base.Types, Media.Streaming.GStreamer.Controller.Controller, Media.Streaming.GStreamer.Controller.GObjectHierarchy, Media.Streaming.GStreamer.Controller.Types, Media.Streaming.GStreamer.Core, Media.Streaming.GStreamer.Core.Bin, Media.Streaming.GStreamer.Core.Buffer, Media.Streaming.GStreamer.Core.Bus, Media.Streaming.GStreamer.Core.Caps, Media.Streaming.GStreamer.Core.Clock, Media.Streaming.GStreamer.Core.Constants, Media.Streaming.GStreamer.Core.Element, Media.Streaming.GStreamer.Core.ElementFactory, Media.Streaming.GStreamer.Core.Event, Media.Streaming.GStreamer.Core.Format, Media.Streaming.GStreamer.Core.GObjectHierarchy, Media.Streaming.GStreamer.Core.GhostPad, Media.Streaming.GStreamer.Core.Hierarchy, Media.Streaming.GStreamer.Core.HierarchyBase, Media.Streaming.GStreamer.Core.ImplementsInterface, Media.Streaming.GStreamer.Core.Index, Media.Streaming.GStreamer.Core.IndexFactory, Media.Streaming.GStreamer.Core.Init, Media.Streaming.GStreamer.Core.Iterator, Media.Streaming.GStreamer.Core.Message, Media.Streaming.GStreamer.Core.MiniHierarchy, Media.Streaming.GStreamer.Core.MiniHierarchyBase, Media.Streaming.GStreamer.Core.MiniObject, Media.Streaming.GStreamer.Core.Object, Media.Streaming.GStreamer.Core.Pad, Media.Streaming.GStreamer.Core.PadTemplate, Media.Streaming.GStreamer.Core.Parse, Media.Streaming.GStreamer.Core.Pipeline, Media.Streaming.GStreamer.Core.Plugin, Media.Streaming.GStreamer.Core.PluginFeature, Media.Streaming.GStreamer.Core.Query, Media.Streaming.GStreamer.Core.Registry, Media.Streaming.GStreamer.Core.Segment, Media.Streaming.GStreamer.Core.Signals, Media.Streaming.GStreamer.Core.Structure, Media.Streaming.GStreamer.Core.SystemClock, Media.Streaming.GStreamer.Core.TagList, Media.Streaming.GStreamer.Core.Types, Media.Streaming.GStreamer.DataProtocol.Constants, Media.Streaming.GStreamer.DataProtocol.DataProtocol, Media.Streaming.GStreamer.Net.Hierarchy, Media.Streaming.GStreamer.Net.NetClientClock, Media.Streaming.GStreamer.Net.Types|' gstreamer/gstreamer.package.conf | /home/gwern/bin/bin/ghc-pkg update - --force --package-conf=package.conf.inplace; Reading package info from stdin ... done. cannot find libHSglib.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHScairo.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSsvgcairo.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSgtk.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSsoegtk.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSgio.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSglade.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSgconf.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSsourceview.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSmozembed.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSgtkglext.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSgnomevfs.a on library path (ignoring) Writing new package config file... done. Reading package info from stdin ... done. cannot find libHSgstreamer.a on library path (ignoring) Writing new package config file... done. touch tools/c2hs/c2hsLocal.deps; /home/gwern/bin/bin/ghc -M -dep-makefile -optdeptools/c2hs/c2hsLocal.deps -fglasgow-exts -O -itools/c2hs/base/admin:tools/c2hs/base/errors:tools/c2hs/base/general:tools/c2hs/base/state:tools/c2hs/base/syms:tools/c2hs/base/syntax:tools/c2hs/c:tools/c2hs/chs:tools/c2hs/gen:tools/c2hs/state:tools/c2hs/toplevel -package-conf package.conf.inplace -hide-all-packages -package base-4.0.0.0 -package haskell98-1.0.1.0 -package pretty-1.0.1.0 -package containers-0.2.0.0 -package array-0.2.0.0 tools/c2hs/base/admin/BaseVersion.hs tools/c2hs/base/admin/Config.hs tools/c2hs/base/errors/Errors.hs tools/c2hs/base/general/DLists.hs tools/c2hs/base/general/FileOps.hs tools/c2hs/base/general/FNameOps.hs tools/c2hs/base/general/Map.hs tools/c2hs/base/general/Position.hs tools/c2hs/base/general/Set.hs tools/c2hs/base/general/UNames.hs tools/c2hs/base/general/Binary.hs tools/c2hs/base/general/FastMutInt.hs tools/c2hs/base/state/CIO.hs tools/c2hs/base/state/StateBase.hs tools/c2hs/base/state/State.hs tools/c2hs/base/state/StateTrans.hs tools/c2hs/base/syms/Attributes.hs tools/c2hs/base/syms/Idents.hs tools/c2hs/base/syms/NameSpaces.hs tools/c2hs/base/syntax/Lexers.hs tools/c2hs/c/CAST.hs tools/c2hs/c/CAttrs.hs tools/c2hs/c/CBuiltin.hs tools/c2hs/c/C.hs tools/c2hs/c/CLexer.hs tools/c2hs/c/CNames.hs tools/c2hs/c/CParser.hs tools/c2hs/c/CParserMonad.hs tools/c2hs/c/CPretty.hs tools/c2hs/c/CTokens.hs tools/c2hs/c/CTrav.hs tools/c2hs/chs/CHS.hs tools/c2hs/chs/CHSLexer.hs tools/c2hs/gen/CInfo.hs tools/c2hs/gen/GBMonad.hs tools/c2hs/gen/GenBind.hs tools/c2hs/gen/GenHeader.hs tools/c2hs/state/C2HSState.hs tools/c2hs/state/Switches.hs tools/c2hs/toplevel/Main.hs tools/c2hs/toplevel/Version.hs tools/c2hs/toplevel/C2HSConfig.hs; gcc -E -x c -traditional-cpp -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DGTK2HS_HS_PREPROC -include gtk2hs-config.h glib/System/Glib/GObject.chs.pp -o glib/System/Glib/GObject.chs glib/System/Glib/GObject.chs.pp:38: error: missing expression between '(' and ')' glib/System/Glib/GObject.chs.pp:91: error: missing expression between '(' and ')' make: *** [glib/System/Glib/GObject.chs] Error 1 From lennart at augustsson.net Wed Feb 11 09:49:57 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Feb 11 09:39:42 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <499256D9.7020102@gmail.com> References: <499256D9.7020102@gmail.com> Message-ID: Does this version work from ghci? -- Lennart On Wed, Feb 11, 2009 at 5:40 AM, Peter Gavin wrote: > Hi everyone, > > Oh, dear... it seems I've forgotten how to spell "cafe", and sent this > message to haskell-caft@haskell.org the first time around. I resent it to > all the lists again (just to make sure everyone interested receives it), so > I apologize for any duplicated messages you might have received. In any > case... > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new stuff > has gone into this release, including: > > - Support for GHC 6.10 > - Bindings to GIO and GtkSourceView-2.0 > - Full switch to the new model-view implementation using a Haskell model > - Support for many more model-based widgets such as IconView and an updated > binding for ComboBox > - Full Drag-and-Drop support > - Better support for Attributes in Pango > - Replaced Event for EventM monad, thereby improving efficiency and > convenience > - Functions for interaction between Cairo and Pixbuf drawing > - Lots of bug fixes, code cleanups, and portability improvements > > With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have been > deprecated. The TreeList modules have been deprecated from the Gtk+ > bindings. > > Source and Win32 binaries are available at: > > > https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 > > Thanks to everyone who submitted bug fixes and features this time around! > > Thanks, > Peter Gavin > Gtk2HS Release Manager > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From haskell at datakids.org Wed Feb 11 10:00:12 2009 From: haskell at datakids.org (Jamie) Date: Wed Feb 11 09:49:57 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: Message-ID: >> Seems like it is ok to write H.264 in Haskell and released via GPL license? >> >> There is theora.org but H.264 would be ideal. ?Ditto for H.263. > > Software patent issues are entirely orthogonal to the copyright issues of who > wrote what under which license. That's why software patents suck so very > hard. > > See > https://secure.wikimedia.org/wikipedia/en/wiki/Software_patent#Free_and_open_source_software > & > https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_software > > gwern Thanks for the links. What I understand is some standard body create the specs, the role, the purpose, the protocols (i.e. H.323 by ITU Telecommunication Standardization Sector) then one can create programs that follow those protocols and don't have to concern about patent license at all, is that correct? I just checked H.264 and yes JVT (the creator of H.264/MPEG 4/AVC specs/protocol) require patent licensing. Oh well... I guess JVT does not do something with x264/ffmpeg cause they are totally free, but let say if I include the H.264 code from x264/ffmpeg in my application and sell for some $$$ then JVT's lawyers could run after me, is that correct? I just checked H.263 and it looks like it does not require patent licensing at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can write H.263 in Haskell and release freely without patent licensing issues. So writing H.263 in Haskell could be a good GSoC project. One mentioned that GHC produce slow code, well H.263 could be a good test case to improve GHC optimization over time. In The Computer Language Benchmarks Game, Haskell has some catching up to do. :) Jamie From jgoerzen at complete.org Wed Feb 11 10:07:21 2009 From: jgoerzen at complete.org (John Goerzen) Date: Wed Feb 11 09:57:12 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> Message-ID: <20090211150721.GA1660@hustlerturf.com> On Wed, Feb 11, 2009 at 09:43:34PM +0800, Evan Laforge wrote: > On Wed, Feb 11, 2009 at 9:34 PM, Alistair Bayley wrote: > > 2009/2/11 Cristiano Paris : > >> I wonder whether this can be done in Haskell (see muleherd's comment): > >> > >> http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ > > > > WASH did/does something similar. You can certainly write applications > > in a similar, workflow-ish style (rather than like a state machine). > > To hijack the subject, what happened to WASH? The paper seemed like > it was full of interesting ideas, but the implementation seems to have > failed to capture many hearts. Now it seems like a stagnant project. > What were the fatal flaws? I actually used it in production for some time, and abandoned it in favor of a FastCGI-based app about 6 months ago. There were several issues. The biggest was maintainability. CPS was difficult to work with, especially when different paths through a web app branch and may later reunite. There was not enough control over how things worked, and the HTML and JavaScript generated did not always fit our needs. Field names were essentially random, and IIRC, so were page names, making integration with other web sites difficult. You can't just link from an external static HTML to a particular page or to the submission of a particular form. There were also issues with people using the back button. It reminded me a fair bit of the issues I ran into when using Python's Twisted framework, actually. -- John From sylvan at student.chalmers.se Wed Feb 11 10:05:52 2009 From: sylvan at student.chalmers.se (Sebastian Sylvan) Date: Wed Feb 11 09:57:23 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <1251338777.20090211124041@gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> Message-ID: <3d96ac180902110705l53fdc802x31bb335a1fe73d2f@mail.gmail.com> On Wed, Feb 11, 2009 at 9:40 AM, Bulat Ziganshin wrote: > Hello Jamie, > > Wednesday, February 11, 2009, 5:54:09 AM, you wrote: > > > Seems like it is ok to write H.264 in Haskell and released via GPL > > license? > > anyway it's impossible due to slow code generated by ghc > Impossible? Really? How does performance relate to it being possible to write? I would be surprised if it was indeed impossible to get something that runs fine one *some* machine. It may be difficult to beat C, but that doesn't mean it's impossible to write something useful. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/d131a449/attachment.htm From manlio_perillo at libero.it Wed Feb 11 10:08:10 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 11 09:57:59 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: References: Message-ID: <4992E9DA.6020703@libero.it> Cristiano Paris ha scritto: > On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen wrote: >> I haven't looked at the details, but I think this is what a library like >> Reactive from Conal Elliott could do, but as far as I understand it, it is >> still work in progress. > > I'm interested in the possibility of > stopping/pickling/unpickling/resuming a computation. > Not sure this is a good thing in a web application. Manlio From gwern0 at gmail.com Wed Feb 11 10:12:08 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Feb 11 10:01:59 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: Message-ID: On Wed, Feb 11, 2009 at 10:00 AM, Jamie wrote: > >>> Seems like it is ok to write H.264 in Haskell and released via GPL >>> license? >>> >>> There is theora.org but H.264 would be ideal. Ditto for H.263. >> >> Software patent issues are entirely orthogonal to the copyright issues of >> who wrote what under which license. That's why software patents suck so very >> hard. >> >> See >> https://secure.wikimedia.org/wikipedia/en/wiki/Software_patent#Free_and_open_source_software >> & >> https://secure.wikimedia.org/wikipedia/en/wiki/Software_patents_and_free_software >> >> gwern > > Thanks for the links. What I understand is some standard body create the > specs, the role, the purpose, the protocols (i.e. H.323 by ITU > Telecommunication Standardization Sector) then one can create programs that > follow those protocols and don't have to concern about patent license at > all, is that correct? In general, you can't say that just because it was generated by some standards body it will be usable. Standards bodies often only have to make their work available under 'reasonable and non discriminatory' terms, which should be read 'not ruinously high license fees' (see https://secure.wikimedia.org/wikipedia/en/wiki/Reasonable_and_Non_Discriminatory_Licensing ). RAND terms are, of course, hopelessly strict for any FLOSS purposes. > I just checked H.264 and yes JVT (the creator of H.264/MPEG 4/AVC > specs/protocol) require patent licensing. Oh well... I guess JVT does not > do something with x264/ffmpeg cause they are totally free, but let say if I > include the H.264 code from x264/ffmpeg in my application and sell for some > $$$ then JVT's lawyers could run after me, is that correct? If JVT has patented any of the techniques in the x264/ffmpeg codebase, then they can come after you if you distribute in *any* manner. An example: the RIAA is still allowed to sue file-sharers even though the sharers aren't seeing a penny in any way. > I just checked H.263 and it looks like it does not require patent licensing > at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can > write H.263 in Haskell and release freely without patent licensing issues. > > So writing H.263 in Haskell could be a good GSoC project. One mentioned > that GHC produce slow code, well H.263 could be a good test case to improve > GHC optimization over time. In The Computer Language Benchmarks Game, > Haskell has some catching up to do. :) > > Jamie It does sound like a reasonably discrete task, and it sounds like you have a use for it; but I wonder if it's doable in a single summer? -- gwern From marlowsd at gmail.com Wed Feb 11 10:33:56 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 11 10:23:48 2009 Subject: [Haskell-cafe] Re: How outdated is Hugs? In-Reply-To: <200902101451.15953.konrad@tylerc.org> References: <351ff25e0901270655n4d333016rdec504f4af402389@mail.gmail.com> <20090128034149.GA32419@jgoerzen-eee.lan.complete.org> <49919232.3040304@gmail.com> <200902101451.15953.konrad@tylerc.org> Message-ID: <4992EFE4.5050301@gmail.com> Conrad Meyer wrote: > On Tuesday 10 February 2009 06:41:54 am Simon Marlow wrote: >> John Goerzen wrote: >>> Just to close -- I will point out that ghci doesn't work on many >>> platforms that Hugs does (though ghc does). Hugs is the only >>> interpreter on some of these platforms. >> I didn't see anyone follow up to this so I'll just mention that nowadays >> GHCi works wherever GHC works, since 6.10.1. Actually I think most >> platforms worked with 6.8.1, but 6.10.1 added libffi which meant that GHCi >> also gets working FFI support on any platform supported by libffi, which is >> most of them. >> >> Cheers, >> Simon > > Counterexample: GHC 6.10.1 works on linux/ppc, GHCi 6.10.1 does not. (6.8.3 > worked, though.) I presume you're referring to this bug: http://hackage.haskell.org/trac/ghc/ticket/2972 So I should really say that /in theory/ there's no reason why GHCi shouldn't work if GHC works, platform-specific bugs notwithstanding. As Ian said in a comment on that bug, I expect that an unregisterised build would work fine. We could do with a Linux/PPC expert to help improve GHC support on that platform. Cheers, Simon From cmb21 at kent.ac.uk Wed Feb 11 10:34:37 2009 From: cmb21 at kent.ac.uk (C.M.Brown) Date: Wed Feb 11 10:24:21 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> Message-ID: Hi Jamie, As a side note - I'd be very interested to see a Haskell implementation of H264 decoding. I'm currently having to use the ffmpeg library in C, and it's notoriously buggy with memory leaks left right and centre. A haskell solution would be very much welcome! Regards, Chris. On Wed, 11 Feb 2009, Jamie wrote: > Hi Bulat, > > On Wed, 11 Feb 2009, Bulat Ziganshin wrote: > > > Hello Jamie, > > > > Wednesday, February 11, 2009, 5:54:09 AM, you wrote: > > > >> Seems like it is ok to write H.264 in Haskell and released via GPL > >> license? > > > > anyway it's impossible due to slow code generated by ghc > > I see, I guess I'll have to stuck with C version of H.264 in my Haskell > programs. Maybe in future when ghc have better optimizations. > > At least one can write various subset of H.323 standard in Haskell as the > only part of H.323 subset that is CPU intensive is video/audio codecs, the > rest is just mainly network I/O code. http://www.h323plus.org/standards/ > > > Best regards, > > Bulat mailto:Bulat.Ziganshin@gmail.com > > Jamie > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From cristiano.paris at gmail.com Wed Feb 11 10:36:42 2009 From: cristiano.paris at gmail.com (Cristiano Paris) Date: Wed Feb 11 10:26:24 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: <4992E9DA.6020703@libero.it> References: <4992E9DA.6020703@libero.it> Message-ID: On Wed, Feb 11, 2009 at 4:08 PM, Manlio Perillo wrote: > Cristiano Paris ha scritto: >> >> On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen >> wrote: >>> >>> I haven't looked at the details, but I think this is what a library like >>> Reactive from Conal Elliott could do, but as far as I understand it, it >>> is >>> still work in progress. >> >> I'm interested in the possibility of >> stopping/pickling/unpickling/resuming a computation. >> > > Not sure this is a good thing in a web application. I'm thinking of complex workflows and inversion of control. A computation may stop, return a response, wait for a new request to be passed by the HTTP server and return back a new response, stopping again. This goes on forever. All this can be achieved in Haskell but the serialization path, which is crucial for swapping out idle sessions (containing the stopped computation) or to get back to life after server stopped (for maintenance for instance). I guess this should be doable in Clean, which has mechanisms to do dynamic binding and serialization of closures. I once did something close to this using Stackless Python, which sports serializable iterators. I did funny things like moving all the sessions to a different server transparently. Nevertheless, the use of yield, specially in sub-computation, is tricky to handle. Notice that this is not a main concern in my daily work but the possibility fascinates me and it turns out to be not a simple problem to solve. During my explorations, I considered continuations, delimited continuations and zippers, and I learned a lot even if I can't still catch delimited continuations. Recently, I stumbled upon Factor and realized that most of the complications are simply cut out in that language as it is purely concatenative (no symbol bindings to mess around). Cristiano From marlowsd at gmail.com Wed Feb 11 10:40:38 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Feb 11 10:30:25 2009 Subject: [Haskell-cafe] Re: space leak with 'concat' ? In-Reply-To: <497F973D.20106@pikewerks.com> References: <1233091272.25364.19.camel@jcchost> <497F973D.20106@pikewerks.com> Message-ID: <4992F176.8030101@gmail.com> Jake McArthur wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Henning Thielemann wrote: > | in that module I defined the text to be printed as top-level > | variable which might have been the problem. But this can't be the > | problem of the compiled version of the program, where I encountered the > | leak. So I have to keep on searching that leak. > > You have created a constant applicative form (commonly abbreviated CAF). > GHC assumes that all top level declarations are constants, and simply > does not garbage collect them. FUD! CAFs are definitely garbage collected, in fact we have a big lump of code generator and runtime complexity (Static Reference Tables, SRTs) to ensure that they do. However, GHCi doesn't always GC CAFs, perhaps that's what you meant. Cheers, Simon From manlio_perillo at libero.it Wed Feb 11 11:05:54 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 11 10:55:56 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: <20090211150721.GA1660@hustlerturf.com> References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> <20090211150721.GA1660@hustlerturf.com> Message-ID: <4992F762.40207@libero.it> John Goerzen ha scritto: > [...] > There were also issues with people using the back button. > > It reminded me a fair bit of the issues I ran into when using Python's > Twisted framework, actually. > Same experience, with Twisted Web + Nevow. All solved after switching to WSGI and a simple WSGI framework (wrote by myself). Configuration and behaviour (middlewares) are all composable. The only thing I miss is a "little" higher level of abstraction. Right now I operate on "request bodies" (in a text format, usually text/html) but I would like to operate on generic "response entities", where an entity is a generic object/data that can be serialized to a request body. This will allow an even greater degree of composability, where each web "view" returns a generic entity, that can be later transformed to another object/data (filtered) or serialized (to JSON or HTML). I think that Haskell is one of the most suitable languages for this idea, but there is the need for the equivalent of WSGI. > -- John Manlio From bugfact at gmail.com Wed Feb 11 11:12:38 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Wed Feb 11 11:03:05 2009 Subject: [Haskell-cafe] Re: space leak with 'concat' ? In-Reply-To: <4992F176.8030101@gmail.com> References: <1233091272.25364.19.camel@jcchost> <497F973D.20106@pikewerks.com> <4992F176.8030101@gmail.com> Message-ID: Yes, I was really surprised that this was the case. I while ago I did a little FRP experiment. I made a top level binding to a list of timer event occurrences. The list was generated on another thread. To my surprise, I did not have space leak, which is amazingly cool, but it felt odd :) Is it documented when GHC will garbage collect CAFs? > FUD! CAFs are definitely garbage collected, in fact we have a big lump of > code generator and runtime complexity (Static Reference Tables, SRTs) to > ensure that they do. > > However, GHCi doesn't always GC CAFs, perhaps that's what you meant. > > Cheers, > Simon > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/00407495/attachment.htm From jake at pikewerks.com Wed Feb 11 11:40:06 2009 From: jake at pikewerks.com (Jake McArthur) Date: Wed Feb 11 11:29:40 2009 Subject: [Haskell-cafe] Re: space leak with 'concat' ? In-Reply-To: <4992F176.8030101@gmail.com> References: <1233091272.25364.19.camel@jcchost> <497F973D.20106@pikewerks.com> <4992F176.8030101@gmail.com> Message-ID: <4992FF66.4010505@pikewerks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simon Marlow wrote: | FUD! CAFs are definitely garbage collected, in fact we have a big lump | of code generator and runtime complexity (Static Reference Tables, SRTs) | to ensure that they do. | | However, GHCi doesn't always GC CAFs, perhaps that's what you meant. The FUD is probably due to my own misunderstanding. Perhaps I did get that impression from GHCi. Sorry about that. - - Jake -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmS/2YACgkQye5hVyvIUKkcEwCgtAfixwQL69lILm1lHFOk8Dj3 55kAnjBV8ZkkMSwRWZOCwKbPaH8VTHdq =DKgU -----END PGP SIGNATURE----- From jwlato at gmail.com Wed Feb 11 11:52:08 2009 From: jwlato at gmail.com (John Lato) Date: Wed Feb 11 11:41:50 2009 Subject: [Haskell-cafe] can't figure out a type Message-ID: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> Hello, I'm working on some code like the following: > class Chunkable c el | c -> el where > cLength :: c -> Int > cHead :: c -> Maybe el I want to be able to map over this type, like this: > cMap :: Chunkable c' el' => (el -> el') -> c -> c' but this isn't quite right. c' shouldn't be any instance of Chunkable, it should be the same instance except parameterized over a different type. Another approach would be something like: class (Functor c) => Chunkable c el ... except that's not right either. I think c has the wrong kind to be a Functor instance. I expect there's something very basic I'm missing. Could anyone point in the proper direction of how to do this? Can this be expressed with associated types, perhaps? Thanks, John Lato From jvranish at gmail.com Wed Feb 11 12:12:39 2009 From: jvranish at gmail.com (Job Vranish) Date: Wed Feb 11 12:02:23 2009 Subject: [Haskell-cafe] can't figure out a type In-Reply-To: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> References: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> Message-ID: What do you mean by parameterized over a different type? will c have a kind of * -> * ? I don't think it has to be for what you want to work, but the idea of "same instance" will go out the window. Do you have a small usage example? On Wed, Feb 11, 2009 at 11:52 AM, John Lato wrote: > Hello, > > I'm working on some code like the following: > >> class Chunkable c el | c -> el where >> cLength :: c -> Int >> cHead :: c -> Maybe el > > I want to be able to map over this type, like this: > >> cMap :: Chunkable c' el' => (el -> el') -> c -> c' > > but this isn't quite right. c' shouldn't be any instance of > Chunkable, it should be the same instance except parameterized over a > different type. Another approach would be something like: > > class (Functor c) => Chunkable c el > ... > > except that's not right either. I think c has the wrong kind to be a > Functor instance. > > I expect there's something very basic I'm missing. Could anyone point > in the proper direction of how to do this? Can this be expressed with > associated types, perhaps? > > Thanks, > > John Lato > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From dons at galois.com Wed Feb 11 12:27:30 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 12:17:50 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: Message-ID: <20090211172730.GA6911@whirlpool.galois.com> gwern0: > (The following is a quasi essay/list of past Summer of Code projects; > my hope is to guide thinking about what Summer of Code projects would > be good to pick, and more specifically what should be avoided. > If you're in a hurry, my conclusions are at the bottom. > The whole thing is written in Markdown; for best results pass it > through Pandoc or view it via your friendly local Gitit wiki.) > Thanks for the write up! We explicitly pushed harder in 2008 to clarify and simplify the goals of the projects, ensure adequate *prior Haskell experience* and to focus on libraries and tools that directly benefit the communtity. And our success rate was much higher. So: look for things that benefit the largest number of Haskell developers and users, and from students with proven Haskell development experience. You can't learn Haskell from zero on the job, during SoC. -- Don From dons at galois.com Wed Feb 11 12:28:33 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 12:18:55 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <1251338777.20090211124041@gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> Message-ID: <20090211172833.GB6911@whirlpool.galois.com> bulat.ziganshin: > Hello Jamie, > > Wednesday, February 11, 2009, 5:54:09 AM, you wrote: > > > Seems like it is ok to write H.264 in Haskell and released via GPL > > license? > > anyway it's impossible due to slow code generated by ghc > Been a long time since you did high perf code -- we routinely now write code that previously was considered not feasible. However, I would say it needs an optimisation expert, yes, in any language. -- Don From jwlato at gmail.com Wed Feb 11 12:34:50 2009 From: jwlato at gmail.com (John Lato) Date: Wed Feb 11 12:24:33 2009 Subject: [Haskell-cafe] can't figure out a type In-Reply-To: References: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> Message-ID: <9979e72e0902110934o4ec4f55cn97c81c28143806e0@mail.gmail.com> Hi Job, Thanks for answering. What I'm trying to do is probably very simple, and I think the biggest problem is that I don't fully understand kinds yet. Here's an example instance: instance Chunkable [a] a where cmap = map --etc. In the class I wrote, c has kind * (e.g. [a]), but then I don't see how to write a suitable map function. For that, I would want c to have kind * -> *. Unfortunately then I don't know to write the others. Would I have to do something with c having kind (* -> *) ? class Chunkable2 c el where cLength :: c el -> Int cHead :: c el -> Maybe el cMap :: (el -> el') -> c el -> c el' Sincerely, John On Wed, Feb 11, 2009 at 5:12 PM, Job Vranish wrote: > What do you mean by parameterized over a different type? > will c have a kind of * -> * ? I don't think it has to be for what you > want to work, but the idea of "same instance" will go out the window. > > Do you have a small usage example? > > > On Wed, Feb 11, 2009 at 11:52 AM, John Lato wrote: >> Hello, >> >> I'm working on some code like the following: >> >>> class Chunkable c el | c -> el where >>> cLength :: c -> Int >>> cHead :: c -> Maybe el >> >> I want to be able to map over this type, like this: >> >>> cMap :: Chunkable c' el' => (el -> el') -> c -> c' >> >> but this isn't quite right. c' shouldn't be any instance of >> Chunkable, it should be the same instance except parameterized over a >> different type. Another approach would be something like: >> >> class (Functor c) => Chunkable c el >> ... >> >> except that's not right either. I think c has the wrong kind to be a >> Functor instance. >> >> I expect there's something very basic I'm missing. Could anyone point >> in the proper direction of how to do this? Can this be expressed with >> associated types, perhaps? >> >> Thanks, >> >> John Lato >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > From barsoap at web.de Wed Feb 11 12:41:28 2009 From: barsoap at web.de (Achim Schneider) Date: Wed Feb 11 12:31:32 2009 Subject: [Haskell-cafe] Re: Can this be done? References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> Message-ID: <20090211184128.7bb8014b@solaris> Evan Laforge wrote: > On Wed, Feb 11, 2009 at 9:34 PM, Alistair Bayley > wrote: > > 2009/2/11 Cristiano Paris : > >> I wonder whether this can be done in Haskell (see muleherd's > >> comment): > >> > >> http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ > > > > WASH did/does something similar. You can certainly write > > applications in a similar, workflow-ish style (rather than like a > > state machine). > > To hijack the subject, what happened to WASH? The paper seemed like > it was full of interesting ideas, but the implementation seems to have > failed to capture many hearts. Now it seems like a stagnant project. > What were the fatal flaws? > I got curious and made two pages point to each other, resulting in as many stale continuations as your left mouse button would permit. While the model certainly is cool, I'm not aware of any implementation that even comes close to having production-safe (that is, non-abusable) semantics. Continuations might also be overkill: For things like server-side checked[1] POST hurdle races, specifying a list of form/predicate/action triples seems to be the nicer way to go. Generalising, fgl should be able to take care of any control flow imaginable. [1] Am I the only one who can't stand those buggy js-forms, especially if the client side has a different notion of valid input than the server? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From gwern0 at gmail.com Wed Feb 11 12:49:01 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Feb 11 12:38:44 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090211172730.GA6911@whirlpool.galois.com> References: <20090211172730.GA6911@whirlpool.galois.com> Message-ID: On Wed, Feb 11, 2009 at 12:27 PM, Don Stewart wrote: > gwern0: >> (The following is a quasi essay/list of past Summer of Code projects; >> my hope is to guide thinking about what Summer of Code projects would >> be good to pick, and more specifically what should be avoided. >> If you're in a hurry, my conclusions are at the bottom. >> The whole thing is written in Markdown; for best results pass it >> through Pandoc or view it via your friendly local Gitit wiki.) >> > > Thanks for the write up! > > We explicitly pushed harder in 2008 to clarify and simplify the goals of > the projects, ensure adequate *prior Haskell experience* and to > focus on libraries and tools that directly benefit the communtity. Oh, I didn't know that about prior experience. (I was tired enough when I finished it that I decided to not look at the students involved - how much prior experience they had, and how involved they were in the Haskell community afterwards.) > And our success rate was much higher. That certainly does seem to be true. Looking over the 2008 projects, I see 0 outright failures (compared to 2 in 2006), and only 1 or 2 which might turn out to be unsuccessful (the physics engine, and perhaps GMap or the GHC API improvements). > So: look for things that benefit the largest number of Haskell > developers and users, and from students with proven Haskell development > experience. You can't learn Haskell from zero on the job, during SoC. > > -- Don Inexperience is a good criterion to add to the 3 I had in my conclusion, certainly. -- gwern From dons at galois.com Wed Feb 11 12:51:26 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 12:42:01 2009 Subject: [Haskell-cafe] Haskell.org GSoC In-Reply-To: References: Message-ID: <20090211175126.GF6911@whirlpool.galois.com> d: > Hi, > > I noticed last year Haskell.org was a mentoring organization for > Google's Summer of Code, and I barely noticed some discussion about it > applying again this year :) > > I participated for GCC in 2008 and would like to try again this year; > while I'm still active for GCC and will surely stay so, I'd like to see > something new at least for GSoC. And Haskell.org would surely be a > very, very nice organization. > > Since I discovered there's more than just a lot of imperative languages > that are nearly all the same, I love to do some programming in Prolog, > Scheme and of course Haskell. However, so far this was only some toy > programs and nothing "really useful"; I'd like to change this (as well > as learning more about Haskell during the projects). > > Here are some ideas for developing Haskell packages (that would > hopefully be of general use to the community) as possible projects: > > - Numerics, like basic linear algebra routines, numeric integration and > other basic algorithms of numeric mathematics. I think a lot of the numerics stuff is now covered by libraries (see e.g. haskell-blas, haskell-lapack, haskell-fftw) > - A basic symbolic maths package; I've no idea how far one could do this > as a single GSoC project, but it would surely be a very interesting > task. Alternatively or in combination, one could try to use an existing > free CAS package as engine. Interesting, but niche, imo. > - Graphs. > > - Some simulation routines from physics, though I've not really an idea > what exactly one should implement here best. True graphs (the data structure) are still a weak point! There's no canonical graph library for Haskell. > - A logic programming framework. I know there's something like that for > Scheme; in my experience, there are some problems best expressed > logically with Prolog-style backtracking/predicates and unification. > This could help use such formulations from inside a Haskell program. > This is surely also a very interesting project. Interesting, lots of related work, hard to state the benefits to the community though. > What do you think about these ideas? I'm pretty sure there are already > some of those implemented, but I also hope some would be new and really > of some use to the community. Do you think something would be > especially nice to have and is currently missing? Think about how many people would benefit. For example, if all the haddocks on hackage.org were a wiki, and interlinked, every single package author would benefit, as would all users. -- Don From jwlato at gmail.com Wed Feb 11 12:54:35 2009 From: jwlato at gmail.com (John Lato) Date: Wed Feb 11 12:44:19 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code Message-ID: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> Hi Bulat, I know you've talked about performance in the past, and I don't want to start a huge argument, but do you have recent data to back this up? IIRC you're using ghc 6.6, yes? I haven't looked at H.264 (and I realize it's compressed, so the situation is different from my work), however ghc can generate very fast code for binary I/O. Check out (shameless self-promotion) http://johnlato.blogspot.com for my recent writeup on creating a high-performance, pure-Haskell, Iteratee-based WAVE file reader. Sincerely, John Lato > > anyway it's impossible due to slow code generated by ghc > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > From manlio_perillo at libero.it Wed Feb 11 13:01:32 2009 From: manlio_perillo at libero.it (Manlio Perillo) Date: Wed Feb 11 12:51:50 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: <4992F762.40207@libero.it> References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> <20090211150721.GA1660@hustlerturf.com> <4992F762.40207@libero.it> Message-ID: <4993127C.1000809@libero.it> Manlio Perillo ha scritto: > > The only thing I miss is a "little" higher level of abstraction. > Right now I operate on "request bodies" (in a text format, usually "request body" should be replaced with "response body" Manlio From barsoap at web.de Wed Feb 11 13:25:29 2009 From: barsoap at web.de (Achim Schneider) Date: Wed Feb 11 13:15:22 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> Message-ID: <20090211192529.6d7886b3@solaris> Bulat Ziganshin wrote: > impossible > impossible, adj: 1) admittance of loosing an argument 2) tease to make someone do something -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From andrewcoppin at btinternet.com Fri Feb 6 08:08:54 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Feb 11 13:34:47 2009 Subject: [Haskell-cafe] (Off-topic) CUDA In-Reply-To: <157939287.20090206112039@gmail.com> References: <498A9F02.8070305@btinternet.com> <157939287.20090206112039@gmail.com> Message-ID: <498C3666.1050409@btinternet.com> Bulat Ziganshin wrote: > Hello Andrew, > > Thursday, February 5, 2009, 11:10:42 AM, you wrote: > > >> Does anybody know how to make this stuff actually work? >> > > nvidia has cuda site where you can download sdk. afair, dr dobbs > journal has (online) series of arcticles which describes how to > program it step-by-step > OK. It's just that I downloaded a CUDA-enabled program, and it's not using CUDA, and I can't figure out why. :-( >> (Also... Haskell on the GPU. It's been talked about for years, but will >> it ever actually happen?) >> > > gpu is just set of simd-like instructions. so the reason why you will > never see haskell on gpu is the same as why you will never see it > implemented via simd instructions :D > Heh, fair enough. From andrewcoppin at btinternet.com Wed Feb 11 13:43:25 2009 From: andrewcoppin at btinternet.com (Andrew Coppin) Date: Wed Feb 11 13:35:21 2009 Subject: [Haskell-cafe] GHC development Message-ID: <49931C4D.1070804@btinternet.com> OK, so I have a small question. I was just wondering what the current state of development with GHC is. So, I had a look at the developer wiki. Unfortunately, as best as I can tell, most of the status pages haven't been updated in many months. (Most of them still talk about what will or won't be in 6.10.1, which has been *released* for a while now.) What's the best way to find out what the "real" state of affairs is? What are the developers really working on? What's on hold? How far have people got with things? Etc. (Yes, I know. I'm nosey...) From dons at galois.com Wed Feb 11 13:47:36 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 13:37:57 2009 Subject: [Haskell-cafe] GHC development In-Reply-To: <49931C4D.1070804@btinternet.com> References: <49931C4D.1070804@btinternet.com> Message-ID: <20090211184736.GO6911@whirlpool.galois.com> andrewcoppin: > OK, so I have a small question. > > I was just wondering what the current state of development with GHC is. > So, I had a look at the developer wiki. Unfortunately, as best as I can > tell, most of the status pages haven't been updated in many months. > (Most of them still talk about what will or won't be in 6.10.1, which > has been *released* for a while now.) What's the best way to find out > what the "real" state of affairs is? What are the developers really > working on? What's on hold? How far have people got with things? Etc. > > (Yes, I know. I'm nosey...) > GHC questions should go to glasgow-haskell-users, http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/thread.html To really see what is going on, look at the commit list and the bug tracker, http://www.haskell.org/pipermail/cvs-ghc/2009-February/thread.html Bug tracker, http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status=reopened&group=priority&type=bug&order=id&desc=1 These links are trivial to find from the GHC home page. -- Don From sylvan at student.chalmers.se Wed Feb 11 14:13:54 2009 From: sylvan at student.chalmers.se (Sebastian Sylvan) Date: Wed Feb 11 14:03:38 2009 Subject: [Haskell-cafe] Re: Can this be done? In-Reply-To: <20090211184128.7bb8014b@solaris> References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> <20090211184128.7bb8014b@solaris> Message-ID: <3d96ac180902111113h105c9b17ye1e3476dedd07f6d@mail.gmail.com> On Wed, Feb 11, 2009 at 5:41 PM, Achim Schneider wrote: > Evan Laforge wrote: > > > On Wed, Feb 11, 2009 at 9:34 PM, Alistair Bayley > > wrote: > > > 2009/2/11 Cristiano Paris : > > >> I wonder whether this can be done in Haskell (see muleherd's > > >> comment): > > >> > > >> > http://www.reddit.com/r/programming/comments/7wi7s/how_continuationbased_web_frameworks_work/ > > > > > > WASH did/does something similar. You can certainly write > > > applications in a similar, workflow-ish style (rather than like a > > > state machine). > > > > To hijack the subject, what happened to WASH? The paper seemed like > > it was full of interesting ideas, but the implementation seems to have > > failed to capture many hearts. Now it seems like a stagnant project. > > What were the fatal flaws? > > > I got curious and made two pages point to each other, resulting in as > many stale continuations as your left mouse button would permit. While > the model certainly is cool, I'm not aware of any implementation that > even comes close to having production-safe (that is, non-abusable) > semantics. Shouldn't the following WASH function help? once :: (Read a, Show a) => CGI a -> CGI a -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/9dd1370e/attachment.htm From vanenkj at gmail.com Wed Feb 11 14:43:07 2009 From: vanenkj at gmail.com (John Van Enk) Date: Wed Feb 11 14:32:49 2009 Subject: [Haskell-cafe] Haskell Users in the West Michigan Area? Message-ID: I'm wondering if there are people in the West Michigan, USA area who'd be interested in forming WMHUG (West Michigan Haskell Users Group). Any one on here from that area? /jve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/f808cdcc/attachment.htm From gwern0 at gmail.com Wed Feb 11 14:45:33 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Wed Feb 11 14:35:21 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: 2009/2/10 John Van Enk : > I'd like to see some good libgcrypt[1] bindings to complement our existing > cryptography packages. > /jve Here are the projects I favor (in no particular order): * I'd like to see the X-saiga parser library finished: http://hackage.haskell.org/trac/summer-of-code/ticket/1558 * A GUI interface to Darcs (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/. Perhaps the specific project could be making TortoiseDarcs not Windows specific? * Graphical reduction http://hackage.haskell.org/trac/summer-of-code/ticket/83 We already have some of it done in Lambdabot, but a full implementation would be very nice. * Optimization of containers (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would benefit every Haskell user very quickly. * XMonad compositing support (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). XMonad is one of the flagship applications of Haskell, and there are quite a few would-be users of compositing support who either go without or limp by with xcompmgr. * Haddock in general could use work (http://hackage.haskell.org/trac/summer-of-code/ticket/45). Everyone uses Haddock, sooner or later... * Sandboxed Haskell (http://hackage.haskell.org/trac/summer-of-code/ticket/1114). This is a personal wish of mine; safe code would certainly let me simplify mueval! -- gwern From james.swaine at gmail.com Wed Feb 11 14:42:19 2009 From: james.swaine at gmail.com (James Swaine) Date: Wed Feb 11 14:36:02 2009 Subject: [Haskell-cafe] DPH Prelude Message-ID: <5195fdde0902111142h44fc56e3p3a353d065a604cec@mail.gmail.com> I was wondering if anyone could point me to a more in-depth explanation of why we are (currently) restricted to using a special-purpose standard Prelude when writing vectorised code with DPH. We're prototyping using several data-parallel languages for a research project here at Northwestern University, and wanted to get a better idea how we might go about adding vectorisation support for addtional types/operations. There are certain simple operations which don't appear to be supported for primitive types yet (e.g. the ^ and ** operators for an Int type). These are the kinds of things we'd like to look into as a first step. Much thanks, James Swaine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/3ab4688e/attachment.htm From inforichland at gmail.com Wed Feb 11 14:46:22 2009 From: inforichland at gmail.com (Tim Wawrzynczak) Date: Wed Feb 11 14:36:23 2009 Subject: [Haskell-cafe] Haskell Users in the West Michigan Area? In-Reply-To: References: Message-ID: <4335a3260902111146y43c25f9fv2c31758e3d428f9f@mail.gmail.com> You should have mentioned this a year ago! I must moved out of that area middle of last year... 2009/2/11 John Van Enk > I'm wondering if there are people in the West Michigan, USA area who'd be > interested in forming WMHUG (West Michigan Haskell Users Group). > Any one on here from that area? > > /jve > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/0d0b8e45/attachment.htm From vanenkj at gmail.com Wed Feb 11 14:47:28 2009 From: vanenkj at gmail.com (John Van Enk) Date: Wed Feb 11 14:37:23 2009 Subject: [Haskell-cafe] Haskell Users in the West Michigan Area? In-Reply-To: <4335a3260902111146y43c25f9fv2c31758e3d428f9f@mail.gmail.com> References: <4335a3260902111146y43c25f9fv2c31758e3d428f9f@mail.gmail.com> Message-ID: D: Tragedy! /jve On Wed, Feb 11, 2009 at 2:46 PM, Tim Wawrzynczak wrote: > You should have mentioned this a year ago! I must moved out of that area > middle of last year... > > 2009/2/11 John Van Enk > >> I'm wondering if there are people in the West Michigan, USA area who'd be >> interested in forming WMHUG (West Michigan Haskell Users Group). >> Any one on here from that area? >> >> /jve >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/27c9b4b4/attachment.htm From haskell at datakids.org Wed Feb 11 15:00:26 2009 From: haskell at datakids.org (Jamie) Date: Wed Feb 11 14:50:09 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: Message-ID: Hi Gwern, On Wed, 11 Feb 2009, Gwern Branwen wrote: >> I just checked H.263 and it looks like it does not require patent licensing >> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can >> write H.263 in Haskell and release freely without patent licensing issues. >> >> So writing H.263 in Haskell could be a good GSoC project. One mentioned >> that GHC produce slow code, well H.263 could be a good test case to improve >> GHC optimization over time. In The Computer Language Benchmarks Game, >> Haskell has some catching up to do. :) > > It does sound like a reasonably discrete task, and it sounds like you > have a use for it; but I wonder if it's doable in a single summer? I have no idea, I have not dig deeper into H.263 C source code but I guess it should be quite trivial as it is a black box with video frame input and output with several parameters for encoding and just frame in/out for decoding. That could be a seed to create Haskell library of video/audio codecs. One mentioned that C based ffmpeg library is buggy with memory leaks left and center (and probably right too :) Ouch! > gwern Jamie From bulat.ziganshin at gmail.com Wed Feb 11 14:53:48 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 11 14:55:25 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090211172833.GB6911@whirlpool.galois.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> <20090211172833.GB6911@whirlpool.galois.com> Message-ID: <1078917771.20090211225348@gmail.com> Hello Don, Wednesday, February 11, 2009, 8:28:33 PM, you wrote: >> anyway it's impossible due to slow code generated by ghc > Been a long time since you did high perf code -- we routinely now write > code that previously was considered not feasible. which is still slower than C and need more time to write > However, I would say it needs an optimisation expert, yes, in any > language. there are experts, includingyou, in making haskell specific code as fast as possible, but i don't know anyone using haskell to write high-performance code. so you ask for non-existing specialists -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From james.swaine at gmail.com Wed Feb 11 15:12:25 2009 From: james.swaine at gmail.com (James Swaine) Date: Wed Feb 11 15:02:45 2009 Subject: [Haskell-cafe] More DPH Questions Message-ID: <5195fdde0902111212l6fd25a2fvfb61b1490ef3b0da@mail.gmail.com> I apologize - I forgot to include this in my previous posting. I also couldn't seem to find an implementation of the foldP function, which is included in several of Roman's papers on DPH and ndp in general. Is this not implemented yet? Thanks, James Swaine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/9d3e4f03/attachment.htm From bulat.ziganshin at gmail.com Wed Feb 11 15:05:38 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 11 15:02:58 2009 Subject: [Haskell-cafe] Re[2]: [Haskell] Google Summer of Code In-Reply-To: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> Message-ID: <20178446.20090211230538@gmail.com> Hello John, Wednesday, February 11, 2009, 8:54:35 PM, you wrote: > I know you've talked about performance in the past, and I don't want > to start a huge argument, but do you have recent data to back this up? > IIRC you're using ghc 6.6, yes? i don't seen examples of high-performance code written by anyone else which would be as simple and as fast as C analogue. afaik ghc now can generate good code for tight loops, but gcc optimizations goes far beyond this. if you know specialists writing HP code in haskell and results of their work - please point us to these code > I haven't looked at H.264 (and I realize it's compressed, so the > situation is different from my work), however ghc can generate very > fast code for binary I/O it's exactly example of tight loop. and let's compare HP code written for this task with analogous code written in C. i expect that haskell code is much more complex > . Check out (shameless self-promotion) > http://johnlato.blogspot.com for my recent writeup on creating a > high-performance, pure-Haskell, Iteratee-based WAVE file reader. afaiu, it's 20-line equivalent of 2-line C code: for (i=...) a[i] = b[i] does this need any more comments? unfortunately, your post doesn't contain equivalent C code and its performance measurements, so i can't consider this as argument for ghc/gcc comparison. all that i see there is large complex code that proves that HP haskell programming is much more complex than C one > Sincerely, > John Lato >> >> anyway it's impossible due to slow code generated by ghc >> >> >> -- >> Best regards, >> Bulat mailto:Bulat.Ziganshin@gmail.com >> -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From ryani.spam at gmail.com Wed Feb 11 15:16:52 2009 From: ryani.spam at gmail.com (Ryan Ingram) Date: Wed Feb 11 15:06:35 2009 Subject: [Haskell-cafe] can't figure out a type In-Reply-To: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> References: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> Message-ID: <2f9b2d30902111216n467e553fid35f7788e9d131b0@mail.gmail.com> You can do this with another type class. class (Chunkable c1 el1, Chunkable c2 el2) => ChunkMap c1 el1 c2 el2 where cMap :: (el1 -> el2) -> c1 -> c2 instance ChunkMap [a] a [b] b where cMap = map If you want to assert that c1 and c2 are really related, you can add functional dependencies to specify the relation: class ... | c1 el2 -> c2, c2 el1 -> c1 where ... Combined with the dependencies in the superclass, this says that if we have c1 and el2 we can determine c2 and el1, and vice versa. Also, if "chunkable" has a notion of "cons", "empty", and "fold", you can write a generic map between any two chunkable instances: genericCMap :: (Chunkable c1 el1, Chunkable c2 el2) => (el1 -> el2) -> c1 -> c2 genericCMap f = cFold (\x xs -> cCons (f x) xs) cEmpty -- ryan P.S. Check out Data.Traversable. On Wed, Feb 11, 2009 at 8:52 AM, John Lato wrote: > Hello, > > I'm working on some code like the following: > >> class Chunkable c el | c -> el where >> cLength :: c -> Int >> cHead :: c -> Maybe el > > I want to be able to map over this type, like this: > >> cMap :: Chunkable c' el' => (el -> el') -> c -> c' > > but this isn't quite right. c' shouldn't be any instance of > Chunkable, it should be the same instance except parameterized over a > different type. Another approach would be something like: > > class (Functor c) => Chunkable c el > ... > > except that's not right either. I think c has the wrong kind to be a > Functor instance. > > I expect there's something very basic I'm missing. Could anyone point > in the proper direction of how to do this? Can this be expressed with > associated types, perhaps? > > Thanks, > > John Lato > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From phunge0 at hotmail.com Wed Feb 11 15:22:24 2009 From: phunge0 at hotmail.com (Brian Bloniarz) Date: Wed Feb 11 15:12:07 2009 Subject: [Haskell-cafe] RE: can't figure out a type In-Reply-To: <20090211193553.8F3873247C4@www.haskell.org> References: <20090211193553.8F3873247C4@www.haskell.org> Message-ID: Hi John, > In the class I wrote, c has kind * (e.g. [a]), but then I don't see > how to write a suitable map function. For that, I would want c to > have kind * -> *. Unfortunately then I don't know to write the > others. > > Would I have to do something with c having kind (* -> *) ? > > class Chunkable2 c el where > cLength :: c el -> Int > cHead :: c el -> Maybe el > cMap :: (el -> el') -> c el -> c el' When c is (* -> *), why do you need el to be a parameter of the typeclass at all? I.e., would this work for your purposes: > class Chunkable3 c where > cLength :: c el -> Int > cHead :: c el -> Maybe el > cMap :: (a -> b) -> c a -> c b > instance Chunkable3 [] where > cLength = length > cMap = map > cHead = ... Using Functor as a superclass of Chunkable3 works too. Thanks, -Brian _________________________________________________________________ More than messages?check out the rest of the Windows Live?. http://www.microsoft.com/windows/windowslive/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/059ce740/attachment.htm From jvranish at gmail.com Wed Feb 11 15:28:41 2009 From: jvranish at gmail.com (Job Vranish) Date: Wed Feb 11 15:18:25 2009 Subject: [Haskell-cafe] can't figure out a type In-Reply-To: <9979e72e0902110934o4ec4f55cn97c81c28143806e0@mail.gmail.com> References: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> <9979e72e0902110934o4ec4f55cn97c81c28143806e0@mail.gmail.com> Message-ID: I think what you probably want is something like this: class Chunckable c where cLength :: c el -> Int cHead :: c el -> Maybe el cMap :: (a -> b) -> c a -> c b instance Chunckable [] where cLength [] = 0 cLength (x:xs) = 1 + cLength xs cHead [] = Nothing cHead (x:xs) = Just x cMap = map a = [4, 7, 3, 8] test1 = cLength a test2 = cHead a test3 = cMap (Just) a The class does not actually need the second type parameter. You can actually use all sorts of extra type variables in the type signatures in class declarations as long as all your instances are polymorphic across those types (not sure if that's the precise terminology). Basically, as long as cLength, cHead and cMap do the same thing regardless of what el is, then you don't need to have el as a type parameter to the class. Now if you _do_ want to have cLength, etc do something else depending el, then things get more complicated. Maybe something like this: class Chunckable2 c el where cLength2 :: c el -> Int cHead2 :: c el -> Maybe el cMap2 :: (Chunckable2 c el') => (el -> el') -> c el -> c el' instance Chunckable2 [] Int where cLength2 [] = 0 cLength2 (x:xs) = 1 + cLength xs cHead2 [] = Nothing cHead2 (x:xs) = Just x cMap2 = map instance Chunckable2 [] Float where cLength2 [] = 0 cLength2 (x:xs) = 1 + cLength xs cHead2 [] = Nothing cHead2 (x:xs) = Just x cMap2 f xs = [] test4 = cMap2 (fromIntegral) (a::[Int]) :: [Float] test5 = cMap2 (id) ([3.0, 4.0, 1.0]::[Float]) :: [Float] Note that if you want things to work like this, functional dependencies wont help you out (as they don't make sense in this case) On Wed, Feb 11, 2009 at 12:34 PM, John Lato wrote: > Hi Job, > > Thanks for answering. What I'm trying to do is probably very simple, > and I think the biggest problem is that I don't fully understand kinds > yet. > > Here's an example instance: > > instance Chunkable [a] a where > cmap = map > --etc. > > In the class I wrote, c has kind * (e.g. [a]), but then I don't see > how to write a suitable map function. For that, I would want c to > have kind * -> *. Unfortunately then I don't know to write the > others. > > Would I have to do something with c having kind (* -> *) ? > > class Chunkable2 c el where > cLength :: c el -> Int > cHead :: c el -> Maybe el > cMap :: (el -> el') -> c el -> c el' > > Sincerely, > John > > On Wed, Feb 11, 2009 at 5:12 PM, Job Vranish wrote: >> What do you mean by parameterized over a different type? >> will c have a kind of * -> * ? I don't think it has to be for what you >> want to work, but the idea of "same instance" will go out the window. >> >> Do you have a small usage example? >> >> >> On Wed, Feb 11, 2009 at 11:52 AM, John Lato wrote: >>> Hello, >>> >>> I'm working on some code like the following: >>> >>>> class Chunkable c el | c -> el where >>>> cLength :: c -> Int >>>> cHead :: c -> Maybe el >>> >>> I want to be able to map over this type, like this: >>> >>>> cMap :: Chunkable c' el' => (el -> el') -> c -> c' >>> >>> but this isn't quite right. c' shouldn't be any instance of >>> Chunkable, it should be the same instance except parameterized over a >>> different type. Another approach would be something like: >>> >>> class (Functor c) => Chunkable c el >>> ... >>> >>> except that's not right either. I think c has the wrong kind to be a >>> Functor instance. >>> >>> I expect there's something very basic I'm missing. Could anyone point >>> in the proper direction of how to do this? Can this be expressed with >>> associated types, perhaps? >>> >>> Thanks, >>> >>> John Lato >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > From leimy2k at gmail.com Wed Feb 11 15:42:00 2009 From: leimy2k at gmail.com (David Leimbach) Date: Wed Feb 11 15:31:42 2009 Subject: [Haskell-cafe] GMP on Mac OS X linked statically by default In-Reply-To: <20090211062957.GA5482@whirlpool.galois.com> References: <3e1162e60902102056k7960cb77l6db5e4665f0b4696@mail.gmail.com> <20090211062957.GA5482@whirlpool.galois.com> Message-ID: <3e1162e60902111242q1fefb4d0w8a44fae6f46c540c@mail.gmail.com> Thanks Don! On Tue, Feb 10, 2009 at 10:29 PM, Don Stewart wrote: > leimy2k: > > Was there a reason for this? If so, it'd be nice if the package that was > build > > explained why... otherwise it feels kind of arbitrary, and would be nice > if > > there was documentation available to make it link dynamically in case > someone > > didn't want to LGPL their program. > > > > Anyone know the steps to make it link dynamically? > > > > Here's how we do it on Windows. The Mac should be far easier, > > http://haskell.forkio.com/gmpwindows > > -- Don > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/4670d1ae/attachment.htm From jwlato at gmail.com Wed Feb 11 15:55:47 2009 From: jwlato at gmail.com (John Lato) Date: Wed Feb 11 15:45:30 2009 Subject: [Haskell-cafe] Re: Re[2]: [Haskell] Google Summer of Code In-Reply-To: <20178446.20090211230538@gmail.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> Message-ID: <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> On Wed, Feb 11, 2009 at 8:05 PM, Bulat Ziganshin wrote: > Hello John, > > Wednesday, February 11, 2009, 8:54:35 PM, you wrote: > >> I know you've talked about performance in the past, and I don't want >> to start a huge argument, but do you have recent data to back this up? >> IIRC you're using ghc 6.6, yes? > > i don't seen examples of high-performance code written by anyone else > which would be as simple and as fast as C analogue. afaik ghc now can > generate good code for tight loops, but gcc optimizations goes far > beyond this. if you know specialists writing HP code in haskell and > results of their work - please point us to these code > >> I haven't looked at H.264 (and I realize it's compressed, so the >> situation is different from my work), however ghc can generate very >> fast code for binary I/O > > it's exactly example of tight loop. and let's compare HP code written > for this task with analogous code written in C. i expect that haskell > code is much more complex I think it's fair to point out that tight loops are nearly always the biggest bottlenecks of code, so generating good code for tight loops is pretty important. And ghc is still making large improvements with each release, whereas gcc isn't likely to get significantly better. > >> . Check out (shameless self-promotion) >> http://johnlato.blogspot.com for my recent writeup on creating a >> high-performance, pure-Haskell, Iteratee-based WAVE file reader. > > afaiu, it's 20-line equivalent of 2-line C code: > > for (i=...) > a[i] = b[i] > > does this need any more comments? I think you've misunderstood my code. Look at Oleg's IterateeM and see if you think that's really all it's doing. > > unfortunately, your post doesn't contain equivalent C code and its > performance measurements, so i can't consider this as argument for > ghc/gcc comparison. all that i see there is large complex code that > proves that HP haskell programming is much more complex than C one Use libsndfile for comparison. http://www.mega-nerd.com/libsndfile/. I actually haven't looked at the code, although it's very highly regarded in the audio community (and I've seen the author post on this list on occasion). Using libsndfile-1.0.18: wc wav.c 1786 7833 57922 wav.c compared to my source: wc Wave.hs 412 2215 15472 Wave.hs And there you are. I will admit that I have implemented the entire wave spec, but only because of lack of time. Cheers, John From dons at galois.com Wed Feb 11 15:58:13 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 15:48:39 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <1078917771.20090211225348@gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> <20090211172833.GB6911@whirlpool.galois.com> <1078917771.20090211225348@gmail.com> Message-ID: <20090211205813.GS6911@whirlpool.galois.com> bulat.ziganshin: > Hello Don, > > Wednesday, February 11, 2009, 8:28:33 PM, you wrote: > > >> anyway it's impossible due to slow code generated by ghc > > > Been a long time since you did high perf code -- we routinely now write > > code that previously was considered not feasible. > > which is still slower than C and need more time to write > > > However, I would say it needs an optimisation expert, yes, in any > > language. > > there are experts, includingyou, in making haskell specific code as > fast as possible, but i don't know anyone using haskell to write > high-performance code. so you ask for non-existing specialists We're doing it at Galois regularly. Check out the blog. -- Don From bulat.ziganshin at gmail.com Wed Feb 11 16:11:39 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 11 16:02:29 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> Message-ID: <1954145479.20090212001139@gmail.com> Hello John, Wednesday, February 11, 2009, 11:55:47 PM, you wrote: >> it's exactly example of tight loop. and let's compare HP code written >> for this task with analogous code written in C. i expect that haskell >> code is much more complex > I think it's fair to point out that tight loops are nearly always the > biggest bottlenecks of code, so generating good code for tight loops > is pretty important. it's important, but doesnt't make whole game. and while i said that ghc improved tight loops compilation, this doesn't mean that it becomes the same as in gcc. it just started to put loop variables into register > And ghc is still making large improvements with > each release, whereas gcc isn't likely to get significantly better. yes, it's close to perfect >> afaiu, it's 20-line equivalent of 2-line C code: >> >> for (i=...) >> a[i] = b[i] >> >> does this need any more comments? > I think you've misunderstood my code. Look at Oleg's IterateeM and > see if you think that's really all it's doing. what else does the code that you've citated? you are wrote that it just copies 16-bit words into doubles > Use libsndfile for comparison. http://www.mega-nerd.com/libsndfile/. it's one method of miscomparing haskell to C - compare hand-tuned haskell code with some C code which may be just not optimal. ig you want to make fair comparison, you should write best code in both languages > I actually haven't looked at the code, although it's very highly > regarded in the audio community (and I've seen the author post on this > list on occasion). Using libsndfile-1.0.18: > wc wav.c > 1786 7833 57922 wav.c > compared to my source: > wc Wave.hs > 412 2215 15472 Wave.hs > And there you are. I will admit that I have implemented the entire > wave spec, but only because of lack of time. when you don't need speed, you may write more compact code in haskell than in C. so the best way is to split your task into speed-critical part and the rest and use C++ for the first and Haskell for the second -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Wed Feb 11 16:21:27 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 11 16:11:53 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090211205813.GS6911@whirlpool.galois.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902101449.38372.konrad@tylerc.org> <1251338777.20090211124041@gmail.com> <20090211172833.GB6911@whirlpool.galois.com> <1078917771.20090211225348@gmail.com> <20090211205813.GS6911@whirlpool.galois.com> Message-ID: <182312096.20090212002127@gmail.com> Hello Don, Wednesday, February 11, 2009, 11:58:13 PM, you wrote: >> fast as possible, but i don't know anyone using haskell to write >> high-performance code. so you ask for non-existing specialists > We're doing it at Galois regularly. Check out the blog. i scanned through http://www.galois.com/blog/category/haskell/ and don't found anything about this. probably we mean different things - i'm saying about implementation of cpu-intensive algorithms like deflate, md5 or mpeg for crypto-algos we have haskell library and afair it was 3-10 times slower than C equivalents and probably harder to write too? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Wed Feb 11 16:23:16 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 16:13:37 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: <1954145479.20090212001139@gmail.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> <1954145479.20090212001139@gmail.com> Message-ID: <20090211212316.GV6911@whirlpool.galois.com> bulat.ziganshin: > Hello John, > > Wednesday, February 11, 2009, 11:55:47 PM, you wrote: > > >> it's exactly example of tight loop. and let's compare HP code written > >> for this task with analogous code written in C. i expect that haskell > >> code is much more complex > > > I think it's fair to point out that tight loops are nearly always the > > biggest bottlenecks of code, so generating good code for tight loops > > is pretty important. > > it's important, but doesnt't make whole game. and while i said that > ghc improved tight loops compilation, this doesn't mean that it > becomes the same as in gcc. it just started to put loop variables into > register > > > And ghc is still making large improvements with > > each release, whereas gcc isn't likely to get significantly better. > > yes, it's close to perfect > > >> afaiu, it's 20-line equivalent of 2-line C code: > >> > >> for (i=...) > >> a[i] = b[i] > >> > >> does this need any more comments? > > > I think you've misunderstood my code. Look at Oleg's IterateeM and > > see if you think that's really all it's doing. > > what else does the code that you've citated? you are wrote that it > just copies 16-bit words into doubles > > > Use libsndfile for comparison. http://www.mega-nerd.com/libsndfile/. > > it's one method of miscomparing haskell to C - compare hand-tuned > haskell code with some C code which may be just not optimal. ig you > want to make fair comparison, you should write best code in both > languages > > > I actually haven't looked at the code, although it's very highly > > regarded in the audio community (and I've seen the author post on this > > list on occasion). Using libsndfile-1.0.18: > > wc wav.c > > 1786 7833 57922 wav.c > > > compared to my source: > > wc Wave.hs > > 412 2215 15472 Wave.hs > > > And there you are. I will admit that I have implemented the entire > > wave spec, but only because of lack of time. > > when you don't need speed, you may write more compact code in haskell > than in C. so the best way is to split your task into > speed-critical part and the rest and use C++ for the first and Haskell > for the second I think what's frustrating about this continued dialogue with Bulat re. performance is that , a) the experience he bases his remarks upon was several year ago b) he's making blanket generic statements, using that old data d) a lot of people have written a lot of fast code without trouble c) he's not acknowledging the great improvements over this time So its very difficult to have these conversations. They're stuck in the same old pattern. Meanwhile, GHC keeps getting smarter and smarter. Bulat: time to update your results! Check out what GHC is doing these days, and come back with an analysis of what still needs to be improved. We can't wait to hear! -- Don From mwotton at gmail.com Wed Feb 11 16:28:26 2009 From: mwotton at gmail.com (Mark Wotton) Date: Wed Feb 11 16:18:06 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: References: Message-ID: <9ea53ad50902111328l5306b33etaa17dc224cea4e0f@mail.gmail.com> On Thu, Feb 12, 2009 at 12:41 AM, Cristiano Paris wrote: > On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen wrote: >> I haven't looked at the details, but I think this is what a library like >> Reactive from Conal Elliott could do, but as far as I understand it, it is >> still work in progress. > > I'm interested in the possibility of > stopping/pickling/unpickling/resuming a computation. I've been looking into something similar... currently, my best option is looking like deliberately causing a core dump and editing the core file to run as a binary (or even more hackishly, just using gdb.) If there's a less filthy way to do it, I'd love to hear about it. (I know about Data.Binary, but it seems inelegant to have to write out instances for something that exists already in memory - you should be able to just blat it back in.) Mark From dmehrtash at gmail.com Wed Feb 11 16:31:38 2009 From: dmehrtash at gmail.com (Daryoush Mehrtash) Date: Wed Feb 11 16:21:19 2009 Subject: Fwd: [Haskell-cafe] ANN : happs-tutorial 0.7 In-Reply-To: <814617240902071636i19cc30c2y49b77cd54c80449a@mail.gmail.com> References: <814617240902071625o79c8e7des35f155cc7a4655f3@mail.gmail.com> <814617240902071636i19cc30c2y49b77cd54c80449a@mail.gmail.com> Message-ID: When i try to cabal install happs-tutorial I get the following error: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: Crypto-4.1.0 failed during the building phase. The exception was: exit: ExitFailure 1 PBKDF2-0.3 depends on Crypto-4.1.0 which failed to install. happs-tutorial-0.7.1 depends on Crypto-4.1.0 which failed to install. happstack-helpers-0.11 depends on Crypto-4.1.0 which failed to install. Did I do anything wrong? Daryoush On Sat, Feb 7, 2009 at 4:36 PM, Creighton Hogg wrote: > Hello, > > I'm pleased to announce the release of happs-tutorial 0.7 on Hackage. > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-tutorial > > This is the first release of happs-tutorial built against the new > Happstack project. Not much has changed in content since the last > release except a few minor cleanups & a little bit of reorganization. > The 0.8 release will consist of more extensive additions, with the > primary focus being a walk through of multimaster. > > I've taken over the development of the tutorial from Thomas Hartman, > who has already put a rather massive effort into making > HAppS/Happstack more accessible. Please feel free to e-mail me with > any comments, errata, or threats of bodily harm. > > Cheers, > Creighton Hogg > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Daryoush Weblog: http://perlustration.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/1c3bcdae/attachment.htm From rmm-haskell at z.odi.ac Wed Feb 11 16:34:43 2009 From: rmm-haskell at z.odi.ac (Ross Mellgren) Date: Wed Feb 11 16:24:29 2009 Subject: [Haskell-cafe] ANN : happs-tutorial 0.7 In-Reply-To: References: <814617240902071625o79c8e7des35f155cc7a4655f3@mail.gmail.com> <814617240902071636i19cc30c2y49b77cd54c80449a@mail.gmail.com> Message-ID: <73D1DBF6-BCE1-4864-94C7-0061E5E96F72@z.odi.ac> This is a known issue: http://hackage.haskell.org/trac/ghc/ticket/1993 Try: cabal install --ghc-options="-fregs-graph" Crypto and then try installing happs-tutorial again. -Ross On Feb 11, 2009, at 4:31 PM, Daryoush Mehrtash wrote: > When i try to cabal install happs-tutorial I get the following error: > > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- > graph > > Please report this as a GHC bug: http://www.haskell.org/ghc/ > reportabug > > cabal: Error: some packages failed to install: > Crypto-4.1.0 failed during the building phase. The exception was: > exit: ExitFailure 1 > PBKDF2-0.3 depends on Crypto-4.1.0 which failed to install. > happs-tutorial-0.7.1 depends on Crypto-4.1.0 which failed to install. > happstack-helpers-0.11 depends on Crypto-4.1.0 which failed to > install. > > Did I do anything wrong? > > Daryoush > > On Sat, Feb 7, 2009 at 4:36 PM, Creighton Hogg > wrote: > Hello, > > I'm pleased to announce the release of happs-tutorial 0.7 on Hackage. > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/happs-tutorial > > This is the first release of happs-tutorial built against the new > Happstack project. Not much has changed in content since the last > release except a few minor cleanups & a little bit of reorganization. > The 0.8 release will consist of more extensive additions, with the > primary focus being a walk through of multimaster. > > I've taken over the development of the tutorial from Thomas Hartman, > who has already put a rather massive effort into making > HAppS/Happstack more accessible. Please feel free to e-mail me with > any comments, errata, or threats of bodily harm. > > Cheers, > Creighton Hogg > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > Daryoush > > Weblog: http://perlustration.blogspot.com/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/062ce808/attachment.htm From ok at cs.otago.ac.nz Wed Feb 11 16:38:02 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Wed Feb 11 16:28:21 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902111340.27082.g9ks157k@acme.softbase.org> References: <200902100916.33357.g9ks157k@acme.softbase.org> <200902111340.27082.g9ks157k@acme.softbase.org> Message-ID: <801FE99D-FE1C-4B19-9D85-D2B10C85F447@cs.otago.ac.nz> On 12 Feb 2009, at 1:40 am, Wolfgang Jeltsch wrote: > Am Mittwoch, 11. Februar 2009 00:46 schrieben Sie: >> I suppose I should point out what seems obvious to me, which is >> that one >> could embed a substantial chunk of MathML (possibly all of it) in >> TeX. I >> mean, give it a TeX-parseable syntax. > > You can convert MathML into TeX but not the other way round. How > would you > translate $a \odot b \otimes c$? It depends on the precedence of the > operators. And the point of that is? What I suggested is the way around that works. And the point of my suggestion was that one could have something that could be embedded directly in a (La)TeX document *or* processed by Haddock: no changes when copying from one document to another means fewer new mistakes. From coreyoconnor at gmail.com Wed Feb 11 17:02:38 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Wed Feb 11 16:52:19 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: <1234349332.5238.246.camel@localhost> References: <1234349332.5238.246.camel@localhost> Message-ID: On Wed, Feb 11, 2009 at 2:48 AM, Duncan Coutts wrote: > On Tue, 2009-02-10 at 10:21 -0800, Corey O'Connor wrote: >> I released a new version of data-spacepart that resolved some of the >> issues with the previous release. One issue I had was the previous >> release used the version numbering scheme I use at work: >> [date].[release] Which does not appear to work as well as the >> traditional X.Y.Z release numbering scheme with Cabal. > > I'm not sure I understand. Is there something in Cabal or Hackage that > makes date-based numbering schemes not work well? I think version number schemes of the X.Y.Z form are easier to work with when defining cabal depends constraints. A user of the library can use the constrain "data-spacepart == 0.1.*" to specifying a dependency on any 0.1 release. For date-based version numbers what would the constraint be? "data-spacepart == 20090211.*" maybe? Or constrain to a range of dates? Both seem awkward to me. Part of the reason they seem awkward to me is that I expect the difference between version numbers to indicate something about what has changed between the two versions. This only ends up being a heuristic but a useful one. Date based version numbers don't communicate much beyond, well, the date the release was built on unless annotations are added in addition to the date. Still, they don't read as nicely as X.Y.Z scheme version numbers. The way I read changes in version numbers for a scheme using the format X.Y.Z is: * A change in Z indicates bug fixes only * A change in Y indicates the interface has changed but not in an incompatible way. For instance, maybe a new method was added. * A change in X indicates the interface has changed in a way that could be incompatible with software that depended on a previous version of the library. I don't know of a mapping that can be applied to date based version numbers that is as rigorous. > Yeah, there's not a lot you can do except make the number higher. The > problem is not just hackage, it's all the previous releases in the wild. > All the tools assume the normal ordering on version numbers. Not just > the Cabal/Hackage tools but the native distro tools too. Hm aye. I guess this explains all the packages with 3000.X (and so on) version numbers. Cheers, Corey O'Connor From gtener at gmail.com Wed Feb 11 17:44:53 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Wed Feb 11 17:34:35 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: References: <499256D9.7020102@gmail.com> Message-ID: <220e47b40902111444k407295ear90d35c8cda755073@mail.gmail.com> 2009/2/11 Gwern Branwen : > touch tools/c2hs/c2hsLocal.deps; /home/gwern/bin/bin/ghc -M -dep-makefile > -optdeptools/c2hs/c2hsLocal.deps -fglasgow-exts -O > -itools/c2hs/base/admin:tools/c2hs/base/errors:tools/c2hs/base/general:tools/c2hs/base/state:tools/c2hs/base/syms:tools/c2hs/base/syntax:tools/c2hs/c:tools/c2hs/chs:tools/c2hs/gen:tools/c2hs/state:tools/c2hs/toplevel > -package-conf package.conf.inplace -hide-all-packages -package base-4.0.0.0 > -package haskell98-1.0.1.0 -package pretty-1.0.1.0 -package > containers-0.2.0.0 -package array-0.2.0.0 > tools/c2hs/base/admin/BaseVersion.hs tools/c2hs/base/admin/Config.hs > tools/c2hs/base/errors/Errors.hs tools/c2hs/base/general/DLists.hs > tools/c2hs/base/general/FileOps.hs tools/c2hs/base/general/FNameOps.hs > tools/c2hs/base/general/Map.hs tools/c2hs/base/general/Position.hs > tools/c2hs/base/general/Set.hs tools/c2hs/base/general/UNames.hs > tools/c2hs/base/general/Binary.hs tools/c2hs/base/general/FastMutInt.hs > tools/c2hs/base/state/CIO.hs tools/c2hs/base/state/StateBase.hs > tools/c2hs/base/state/State.hs tools/c2hs/base/state/StateTrans.hs > tools/c2hs/base/syms/Attributes.hs tools/c2hs/base/syms/Idents.hs > tools/c2hs/base/syms/NameSpaces.hs tools/c2hs/base/syntax/Lexers.hs > tools/c2hs/c/CAST.hs tools/c2hs/c/CAttrs.hs tools/c2hs/c/CBuiltin.hs > tools/c2hs/c/C.hs tools/c2hs/c/CLexer.hs tools/c2hs/c/CNames.hs > tools/c2hs/c/CParser.hs tools/c2hs/c/CParserMonad.hs tools/c2hs/c/CPretty.hs > tools/c2hs/c/CTokens.hs tools/c2hs/c/CTrav.hs tools/c2hs/chs/CHS.hs > tools/c2hs/chs/CHSLexer.hs tools/c2hs/gen/CInfo.hs tools/c2hs/gen/GBMonad.hs > tools/c2hs/gen/GenBind.hs tools/c2hs/gen/GenHeader.hs > tools/c2hs/state/C2HSState.hs tools/c2hs/state/Switches.hs > tools/c2hs/toplevel/Main.hs tools/c2hs/toplevel/Version.hs > tools/c2hs/toplevel/C2HSConfig.hs; > gcc -E -x c -traditional-cpp -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -DGTK2HS_HS_PREPROC -include gtk2hs-config.h > glib/System/Glib/GObject.chs.pp -o glib/System/Glib/GObject.chs > glib/System/Glib/GObject.chs.pp:38: error: missing expression between '(' > and ')' > glib/System/Glib/GObject.chs.pp:91: error: missing expression between '(' > and ')' > make: *** [glib/System/Glib/GObject.chs] Error 1 > Ah, It feels familiar. I'm didn't get this error, but I do recall a recent thread with similar error. However AFAIR that thread was about building on Windows, not Ubuntu. It turned out that configure script was somewhat broken and specific symbols needed for CPP where declared to be empty strings. This might be happening in your case too. I think. All best Christopher Skrz?tnicki From toby.hutton at gmail.com Wed Feb 11 17:47:52 2009 From: toby.hutton at gmail.com (Toby Hutton) Date: Wed Feb 11 17:37:34 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: <1954145479.20090212001139@gmail.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> <1954145479.20090212001139@gmail.com> Message-ID: <711894390902111447o53d941earc8d11a594b07967e@mail.gmail.com> On Thu, Feb 12, 2009 at 8:11 AM, Bulat Ziganshin wrote: > Wednesday, February 11, 2009, 11:55:47 PM, you wrote: > >> And ghc is still making large improvements with >> each release, whereas gcc isn't likely to get significantly better. > > yes, it's close to perfect LOL! From newhoggy at gmail.com Wed Feb 11 18:17:41 2009 From: newhoggy at gmail.com (John Ky) Date: Wed Feb 11 18:07:24 2009 Subject: [Haskell-cafe] Writing a generic event handler Message-ID: Hi Haskell Cafe, I'm interested in writing some events and event handlers in Haskell. I already have a Loop data structure, and I intend to use it for this purpose: -- Create event tEvent <- newLoop (return ()) -- Register event handlers tHandler1 <- newLoop (putStrLn "Handler1") tHandler2 <- newLoop (putStrLn "Handler2") splice tEvent tHandler1 splice tEvent tHandler2 -- Fire event action <- doLoop tEvent action doLoop :: Monad m => TVar (Loop (m ())) -> STM (m ()) doLoop tLoop = do aLoop <- readAsList tLoop return $ sequence_ aLoop My question is: Is it possible to write a generic doLoop that works over arbitrary functions? For instance the following code wouldn't work because the event provides one argument and the handler takes one argument: -- Create event tEvent <- newLoop (\x -> return ()) -- Register event handlers tHandler1 <- newLoop (\x -> putStrLn ("Handler1" ++ show x)) tHandler2 <- newLoop (\x -> putStrLn ("Handler2" ++ show x)) splice tEvent tHandler1 splice tEvent tHandler2 -- Fire event action <- doLoop tEvent action 123 Thanks, -John Full source code for Loop type: module Fx.STM.Loop where import Control.Monad import Fx.STM.Util import GHC.Conc import System.IO.Unsafe -- Transactional loop. A loop is a circular link list. data Loop a = ItemLink { item :: a , prev :: TVar (Loop a) , next :: TVar (Loop a) } -- Create a new empty transactional loop. newLoop :: a -> STM (TVar (Loop a)) newLoop item = do tLoop <- newTVar undefined writeTVar tLoop (ItemLink item tLoop tLoop) return tLoop -- Splice two transactional loops. This will join two loops if they were -- originally separate, or split a single loop if the links were originally -- part of the same loop. No change occurs if the two links are identical. splice :: TVar (Loop a) -> TVar (Loop a) -> STM () splice tLink0 tLink1 = do aLink0 <- readTVar tLink0 aLink1 <- readTVar tLink1 let tLink0Prev = prev aLink0 let tLink1Prev = prev aLink1 writeTVar tLink0 aLink0 { prev = tLink1Prev } writeTVar tLink1 aLink1 { prev = tLink0Prev } aLink0Prev <- readTVar tLink0Prev aLink1Prev <- readTVar tLink1Prev writeTVar tLink0Prev aLink0Prev { next = tLink1 } writeTVar tLink1Prev aLink1Prev { next = tLink0 } return () -- Unlink a single link from a transactional loop. unlink :: TVar (Loop a) -> STM () unlink tLink = do (ItemLink item tLinkPrev tLinkNext) <- readTVar tLink aLinkPrev <- readTVar tLinkPrev writeTVar tLinkPrev aLinkPrev { next = tLinkNext } aLinkNext <- readTVar tLinkNext writeTVar tLinkNext aLinkNext { prev = tLinkPrev } writeTVar tLink (ItemLink item tLink tLink) return () -- Read the length of the loop. readLength :: TVar (Loop a) -> STM Int readLength tLink = do list <- readAsList tLink return $ length list readLinks :: TVar (Loop a) -> STM [TVar (Loop a)] readLinks tLink = readLinksUntil tLink tLink readLinksUntil :: TVar (Loop a) -> TVar (Loop a) -> STM [TVar (Loop a)] readLinksUntil tLink tLinkEnd = do (ItemLink _ tLinkPrev tLinkNext) <- readTVar tLink return [] if tLinkNext == tLinkEnd then return [tLink] else do tail <- readLinksUntil tLinkNext tLinkEnd return $ tLink:tail -- Read the elements of the loop as a list starting from tLink. readAsList :: TVar (Loop a) -> STM [a] readAsList tLink = readAsListUntil tLink tLink -- Read the elements of the loop as a list starting from tLink -- and terminating non-inclusively at tLinkEnd. readAsListUntil :: TVar (Loop a) -> TVar (Loop a) -> STM [a] readAsListUntil tLink tLinkEnd = do (ItemLink item tLinkPrev tLinkNext) <- readTVar tLink if tLinkNext == tLinkEnd then return [item] else do tail <- readAsListUntil tLinkNext tLinkEnd return $ item:tail -- Create a new loop from a list. newFromList :: [a] -> STM (TVar (Loop a)) newFromList [item] = newLoop item newFromList (item:items) = do tLink <- newLoop item tLinkRest <- newFromList items splice tLink tLinkRest return tLink doLoop :: Monad m => TVar (Loop (m ())) -> STM (m ()) doLoop tLoop = do aLoop <- readAsList tLoop return $ sequence_ aLoop -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/9e772326/attachment.htm From gtener at gmail.com Wed Feb 11 18:19:41 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Wed Feb 11 18:09:42 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: Message-ID: <220e47b40902111519q158009a5r473ca34f40466d60@mail.gmail.com> On Wed, Feb 11, 2009 at 21:00, Jamie wrote: > Hi Gwern, > > On Wed, 11 Feb 2009, Gwern Branwen wrote: > >>> I just checked H.263 and it looks like it does not require patent >>> licensing >>> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one >>> can >>> write H.263 in Haskell and release freely without patent licensing >>> issues. >>> >>> So writing H.263 in Haskell could be a good GSoC project. One mentioned >>> that GHC produce slow code, well H.263 could be a good test case to >>> improve >>> GHC optimization over time. In The Computer Language Benchmarks Game, >>> Haskell has some catching up to do. :) >> >> It does sound like a reasonably discrete task, and it sounds like you have >> a use for it; but I wonder if it's doable in a single summer? > > I have no idea, I have not dig deeper into H.263 C source code but I guess > it should be quite trivial as it is a black box with video frame input and > output with several parameters for encoding and just frame in/out for > decoding. I didn't dig into the source code either, but I've just skimmed through Wikipedia page on that codec: http://en.wikipedia.org/wiki/H.263 and in seems far from trivial. Anything that has 23 annexes is likely to be quite complex :-) Therefore I seriously doubt chances for success of such project. I did some checks: in libavcodec at least following files consist of implementation of H.263: h263.c h263data.h h263dec.c h263.h h263_parser.c h263_parser.h How many lines are there? [Tener@laptener libavcodec]$ wc h263* 6295 19280 218932 h263.c 314 2117 10423 h263data.h 816 2171 26675 h263dec.c 46 217 2032 h263.h 91 282 2361 h263_parser.c 29 165 1047 h263_parser.h 7591 24232 261470 razem In Haskell project one would also need to provide some additional utility code which is part of libavcodec. Fast grep shows the tip of an iceberg: [Tener@laptener libavcodec]$ grep include h263* | grep -v "<" h263.c:#include "dsputil.h" h263.c:#include "avcodec.h" h263.c:#include "mpegvideo.h" h263.c:#include "h263data.h" h263.c:#include "mpeg4data.h" h263.c:#include "mathops.h" h263data.h:#include "mpegvideo.h" h263dec.c:#include "avcodec.h" h263dec.c:#include "dsputil.h" h263dec.c:#include "mpegvideo.h" h263dec.c:#include "h263_parser.h" h263dec.c:#include "mpeg4video_parser.h" h263dec.c:#include "msmpeg4.h" h263.h:#include "config.h" h263.h:#include "msmpeg4.h" h263_parser.c:#include "parser.h" h263_parser.h:#include "parser.h" Bottom line: I don't think it is reasonable to assume anyone without previous knowledge of H.263 is able to fit that project into one summer. But! It's Haskell community, and people here see the impossible happen from time to time ;-) All best Christopher Skrz?tnicki From dons at galois.com Wed Feb 11 18:31:51 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 18:22:18 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <220e47b40902111519q158009a5r473ca34f40466d60@mail.gmail.com> References: <220e47b40902111519q158009a5r473ca34f40466d60@mail.gmail.com> Message-ID: <20090211233151.GI5978@whirlpool.galois.com> Thanks for the analysis, this clarifies things greatly. Feasibility and scope is a big part of how we determine what projects to work on. gtener: > On Wed, Feb 11, 2009 at 21:00, Jamie wrote: > > Hi Gwern, > > > > On Wed, 11 Feb 2009, Gwern Branwen wrote: > > > >>> I just checked H.263 and it looks like it does not require patent > >>> licensing > >>> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one > >>> can > >>> write H.263 in Haskell and release freely without patent licensing > >>> issues. > >>> > >>> So writing H.263 in Haskell could be a good GSoC project. One mentioned > >>> that GHC produce slow code, well H.263 could be a good test case to > >>> improve > >>> GHC optimization over time. In The Computer Language Benchmarks Game, > >>> Haskell has some catching up to do. :) > >> > >> It does sound like a reasonably discrete task, and it sounds like you have > >> a use for it; but I wonder if it's doable in a single summer? > > > > I have no idea, I have not dig deeper into H.263 C source code but I guess > > it should be quite trivial as it is a black box with video frame input and > > output with several parameters for encoding and just frame in/out for > > decoding. > > I didn't dig into the source code either, but I've just skimmed > through Wikipedia page on that codec: > http://en.wikipedia.org/wiki/H.263 > and in seems far from trivial. Anything that has 23 annexes is likely > to be quite complex :-) > Therefore I seriously doubt chances for success of such project. I did > some checks: in libavcodec at least following files consist of > implementation of H.263: > > h263.c h263data.h h263dec.c h263.h > h263_parser.c h263_parser.h > > How many lines are there? > > [Tener@laptener libavcodec]$ wc h263* > 6295 19280 218932 h263.c > 314 2117 10423 h263data.h > 816 2171 26675 h263dec.c > 46 217 2032 h263.h > 91 282 2361 h263_parser.c > 29 165 1047 h263_parser.h > 7591 24232 261470 razem > > In Haskell project one would also need to provide some additional > utility code which is part of libavcodec. > Fast grep shows the tip of an iceberg: > > [Tener@laptener libavcodec]$ grep include h263* | grep -v "<" > h263.c:#include "dsputil.h" > h263.c:#include "avcodec.h" > h263.c:#include "mpegvideo.h" > h263.c:#include "h263data.h" > h263.c:#include "mpeg4data.h" > h263.c:#include "mathops.h" > h263data.h:#include "mpegvideo.h" > h263dec.c:#include "avcodec.h" > h263dec.c:#include "dsputil.h" > h263dec.c:#include "mpegvideo.h" > h263dec.c:#include "h263_parser.h" > h263dec.c:#include "mpeg4video_parser.h" > h263dec.c:#include "msmpeg4.h" > h263.h:#include "config.h" > h263.h:#include "msmpeg4.h" > h263_parser.c:#include "parser.h" > h263_parser.h:#include "parser.h" > > > > Bottom line: I don't think it is reasonable to assume anyone without > previous knowledge of H.263 is able to fit that project into one > summer. But! It's Haskell community, and people here see the > impossible happen from time to time ;-) > > All best > > Christopher Skrz?tnicki > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From duncan.coutts at worc.ox.ac.uk Wed Feb 11 19:11:37 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Feb 11 19:01:34 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: References: <499256D9.7020102@gmail.com> Message-ID: <1234397497.4025.6.camel@localhost> On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: > Does this version work from ghci? > > -- Lennart Specifically I believe Lennart is asking about Windows. It's worked in ghci in Linux for ages and it worked in ghci in Windows prior to the 0.9.13 release. In the 0.9.13 release on Windows there was something funky with linking (possibly due to using a newer mingw) and ghci's linker could not understand was was going on and could not load the packages. Duncan > On Wed, Feb 11, 2009 at 5:40 AM, Peter Gavin wrote: > > Hi everyone, > > > > Oh, dear... it seems I've forgotten how to spell "cafe", and sent this > > message to haskell-caft@haskell.org the first time around. I resent it to > > all the lists again (just to make sure everyone interested receives it), so > > I apologize for any duplicated messages you might have received. In any > > case... > > > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new stuff > > has gone into this release, including: > > > > - Support for GHC 6.10 > > - Bindings to GIO and GtkSourceView-2.0 > > - Full switch to the new model-view implementation using a Haskell model > > - Support for many more model-based widgets such as IconView and an updated > > binding for ComboBox > > - Full Drag-and-Drop support > > - Better support for Attributes in Pango > > - Replaced Event for EventM monad, thereby improving efficiency and > > convenience > > - Functions for interaction between Cairo and Pixbuf drawing > > - Lots of bug fixes, code cleanups, and portability improvements > > > > With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have been > > deprecated. The TreeList modules have been deprecated from the Gtk+ > > bindings. > > > > Source and Win32 binaries are available at: > > > > > > https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 > > > > Thanks to everyone who submitted bug fixes and features this time around! > > > > Thanks, > > Peter Gavin > > Gtk2HS Release Manager > > > > _______________________________________________ > > 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 From bulat.ziganshin at gmail.com Wed Feb 11 19:34:29 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 11 19:31:32 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: <20090211212316.GV6911@whirlpool.galois.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> <1954145479.20090212001139@gmail.com> <20090211212316.GV6911@whirlpool.galois.com> Message-ID: <1163866693.20090212033429@gmail.com> Hello Don, Thursday, February 12, 2009, 12:23:16 AM, you wrote: > Check out what GHC is doing these days, and come back with an analysis > of what still needs to be improved. We can't wait to hear! can you point me to any haskell code that is as fast as it's C equivalent? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From dons at galois.com Wed Feb 11 19:45:36 2009 From: dons at galois.com (Don Stewart) Date: Wed Feb 11 19:35:56 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: <1163866693.20090212033429@gmail.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> <1954145479.20090212001139@gmail.com> <20090211212316.GV6911@whirlpool.galois.com> <1163866693.20090212033429@gmail.com> Message-ID: <20090212004536.GT5978@whirlpool.galois.com> bulat.ziganshin: > Hello Don, > > Thursday, February 12, 2009, 12:23:16 AM, you wrote: > > > Check out what GHC is doing these days, and come back with an analysis > > of what still needs to be improved. We can't wait to hear! > > can you point me to any haskell code that is as fast as it's C > equivalent? You should do your own benchmarking! -- Don From benja.fallenstein at gmail.com Wed Feb 11 20:07:16 2009 From: benja.fallenstein at gmail.com (Benja Fallenstein) Date: Wed Feb 11 19:56:57 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: Hi all, On Tue, Feb 10, 2009 at 3:26 PM, Malcolm Wallace wrote: > If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing > lists of your choice. We especially encourage students to communicate > with the wider community (...) I have a project that I've tinkered with doing for a while, but have never actually gotten around to, and I'm wondering whether there would be interest from the community in using it. Actually, two related projects: (1) A library for working with hashable data structures, including a hashable finger tree with sequence, map and set types based on it. Surprisingly, there does not seem to be much library support for working with hashes in Haskell beyond the bare-bones, imperative Data.HashTable, even though pure functional programming and hashes Go Well Together. I'm pulling these bounds out of my intuition, but hashable collections should give amortized O(1) comparison for equality and amortized O(log n) comparison for order, and you could use them as set values and map keys without efficiency blowing up in your face. The library should probably also include support for hashtables based on the various kinds of pure and monad-encapsulated arrays we have in Haskell, and maybe include support for interning values; unsafePerformIO, weak references and friends were originally introduced with the intention to support interned values in a way that programmers can tailor to their own needs, but it would be nice to have some default library support. (2) Based on this, a serialization library that would recognize if it has already written a particular value from memory to the same file, and write a pointer to the first occurrence of that value instead of serializing the actual value again, making it efficient to serialize versioned data structures. The idea is to make something similar to HAppS' MACID, but where MACID serializes the different kinds of updates that you can do for your data, this library would simply do the update in memory, then serialize the whole updated value to disk, but actually *writing* only the *new* parts of the data structure. (I think this could be simpler to use, and would be in a sense more elegant and 'haskelly' than the MACID approach. On the other hand, we already *have* MACID.) So, anybody out there who looks at these things and thinks "this could be useful"? :-) Thanks, - Benja From felipe.lessa at gmail.com Wed Feb 11 20:12:38 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Wed Feb 11 20:02:19 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: Do we already have enough information to turn http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized package? I think Iteratees may prove themselves as useful as ByteStrings. -- Felipe. From bulat.ziganshin at gmail.com Wed Feb 11 20:15:57 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed Feb 11 20:11:41 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: <20090212004536.GT5978@whirlpool.galois.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> <1954145479.20090212001139@gmail.com> <20090211212316.GV6911@whirlpool.galois.com> <1163866693.20090212033429@gmail.com> <20090212004536.GT5978@whirlpool.galois.com> Message-ID: <834339889.20090212041557@gmail.com> Hello Don, Thursday, February 12, 2009, 3:45:36 AM, you wrote: > You should do your own benchmarking! well, when you say that ghc can generate code that is fast as gcc, i expect that you can supply some arguments. is the your only argument that ghc was improved in last years? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From johan.tibell at gmail.com Wed Feb 11 20:29:36 2009 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed Feb 11 20:19:18 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <90889fe70902111729g4672d322p28df0054f4aee698@mail.gmail.com> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa wrote: > Do we already have enough information to turn > http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized > package? I think Iteratees may prove themselves as useful as > ByteStrings. I still haven't figured out what the "correct" definition of Iteratee would look like. The Iteratee code that Oleg wrote seems to have the structure of some kind of "two level" monad. I think that's the reason for the frequent occurrences of >>== and liftI in the code. There seems to be some things we yet have to discover about Iteratees. Cheers, Johan From chak at cse.unsw.edu.au Wed Feb 11 20:38:46 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Wed Feb 11 20:28:41 2009 Subject: [Haskell-cafe] (Off-topic) CUDA In-Reply-To: <2A15B738-0CBB-40B4-83FD-6BB17815A92E@cs.york.ac.uk> References: <498A9F02.8070305@btinternet.com> <157939287.20090206112039@gmail.com> <2A15B738-0CBB-40B4-83FD-6BB17815A92E@cs.york.ac.uk> Message-ID: <22BF062C-6281-4154-8261-8C36E77CC522@cse.unsw.edu.au> Malcolm Wallace: >>> (Also... Haskell on the GPU. It's been talked about for years, but >>> will >>> it ever actually happen?) >> >> gpu is just set of simd-like instructions. so the reason why you will >> never see haskell on gpu is the same as why you will never see it >> implemented via simd instructions :D > > Because SIMD/GPU deals only with numbers, not pointers, you will not > see much _symbolic_ computation being offloaded to these arithmetic > units. But there are still great opportunities to improve Haskell's > speed at numerics using them. And some symbolic problems can be > encoded using integers. > > There are at least two current (but incomplete) projects in this > area: Sean Lee at UNSW has targetted Data Parallel Haskell for an > Nvidia GPGPU, and Joel Svensson at Chalmers is developing a Haskell- > embedded language for GPU programming called Obsidian. We have a paper about the UNSW project now. It is rather high-level, but has some performance figures of preliminary benchmarks: http://www.cse.unsw.edu.au/~chak/papers/LCGK09.html BTW, this is currently independent of Data Parallel Haskell. It is a flat data-parallel array language embedded in Haskell. The language is restricted in a manner that we can generate GPU code (CUDA to be precise) from it. In the longer run, we want to turn this into a backend of Data Parallel Haskell, but that will require quite a bit more work. Manuel From conrad at metadecks.org Wed Feb 11 21:06:16 2009 From: conrad at metadecks.org (Conrad Parker) Date: Wed Feb 11 20:55:58 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090211233151.GI5978@whirlpool.galois.com> References: <220e47b40902111519q158009a5r473ca34f40466d60@mail.gmail.com> <20090211233151.GI5978@whirlpool.galois.com> Message-ID: 2009/2/12 Don Stewart : > Thanks for the analysis, this clarifies things greatly. > Feasibility and scope is a big part of how we determine what projects to > work on. I agree that it's beyond the scope of a SoC project. Rather than H.263 or H.264 I was going to suggest implementation of Theora or OMS, both of which avoid the patent issues and have publicly available specs: http://theora.org/doc/Theora.pdf http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf Scanning those documents should give anyone a fair idea of the amount of work involved. My understanding is that OMS is of a similar complexity to H.263, and H.264 is more complex than any of these. For Theora playback we've found that the largest CPU load comes from colorspace conversion, where the YUV output of the codec needs to be converted to RGB for some targets (like Firefox). That is some fairly straightforward array processing, and would be a good place to start for anyone trying to implement video codecs in Haskell. Conrad. > > gtener: >> On Wed, Feb 11, 2009 at 21:00, Jamie wrote: >> > Hi Gwern, >> > >> > On Wed, 11 Feb 2009, Gwern Branwen wrote: >> > >> >>> I just checked H.263 and it looks like it does not require patent >> >>> licensing >> >>> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one >> >>> can >> >>> write H.263 in Haskell and release freely without patent licensing >> >>> issues. >> >>> >> >>> So writing H.263 in Haskell could be a good GSoC project. One mentioned >> >>> that GHC produce slow code, well H.263 could be a good test case to >> >>> improve >> >>> GHC optimization over time. In The Computer Language Benchmarks Game, >> >>> Haskell has some catching up to do. :) >> >> >> >> It does sound like a reasonably discrete task, and it sounds like you have >> >> a use for it; but I wonder if it's doable in a single summer? >> > >> > I have no idea, I have not dig deeper into H.263 C source code but I guess >> > it should be quite trivial as it is a black box with video frame input and >> > output with several parameters for encoding and just frame in/out for >> > decoding. >> >> I didn't dig into the source code either, but I've just skimmed >> through Wikipedia page on that codec: >> http://en.wikipedia.org/wiki/H.263 >> and in seems far from trivial. Anything that has 23 annexes is likely >> to be quite complex :-) >> Therefore I seriously doubt chances for success of such project. I did >> some checks: in libavcodec at least following files consist of >> implementation of H.263: >> >> h263.c h263data.h h263dec.c h263.h >> h263_parser.c h263_parser.h >> >> How many lines are there? >> >> [Tener@laptener libavcodec]$ wc h263* >> 6295 19280 218932 h263.c >> 314 2117 10423 h263data.h >> 816 2171 26675 h263dec.c >> 46 217 2032 h263.h >> 91 282 2361 h263_parser.c >> 29 165 1047 h263_parser.h >> 7591 24232 261470 razem >> >> In Haskell project one would also need to provide some additional >> utility code which is part of libavcodec. >> Fast grep shows the tip of an iceberg: >> >> [Tener@laptener libavcodec]$ grep include h263* | grep -v "<" >> h263.c:#include "dsputil.h" >> h263.c:#include "avcodec.h" >> h263.c:#include "mpegvideo.h" >> h263.c:#include "h263data.h" >> h263.c:#include "mpeg4data.h" >> h263.c:#include "mathops.h" >> h263data.h:#include "mpegvideo.h" >> h263dec.c:#include "avcodec.h" >> h263dec.c:#include "dsputil.h" >> h263dec.c:#include "mpegvideo.h" >> h263dec.c:#include "h263_parser.h" >> h263dec.c:#include "mpeg4video_parser.h" >> h263dec.c:#include "msmpeg4.h" >> h263.h:#include "config.h" >> h263.h:#include "msmpeg4.h" >> h263_parser.c:#include "parser.h" >> h263_parser.h:#include "parser.h" >> >> >> >> Bottom line: I don't think it is reasonable to assume anyone without >> previous knowledge of H.263 is able to fit that project into one >> summer. But! It's Haskell community, and people here see the >> impossible happen from time to time ;-) >> >> All best >> >> Christopher Skrz?tnicki >> _______________________________________________ >> 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 > > From wren at freegeek.org Wed Feb 11 23:20:48 2009 From: wren at freegeek.org (wren ng thornton) Date: Wed Feb 11 23:10:30 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: References: <1234349332.5238.246.camel@localhost> Message-ID: <4993A3A0.1000308@freegeek.org> Corey O'Connor wrote: > Part of the reason they seem awkward to me is that I expect the > difference between version numbers to indicate something about what > has changed between the two versions. This only ends up being a > heuristic but a useful one. Date based version numbers don't > communicate much beyond, well, the date the release was built on > unless annotations are added in addition to the date. Still, they > don't read as nicely as X.Y.Z scheme version numbers. Delimited date-based versions (YYYY.MM.DD[.X.Y.Z]) work better for specifying ranges. Though there is still the problem of correlating "version" into "feature set" or "api", which is true of any versioning scheme to varying degrees. For projects which are released very frequently (i.e. on the order of daily) or very infrequently (e.g. semiannually, annually) then date-based releases can make sense. However, the releases do need to be quite regular on either of those time scales. This style is also appropriate for projects which exist in-time with our non-code world. Often though, projects see sporadic flurries of improvements and so something that's been languishing for months can quickly make a couple bugfix releases followed by a backwards-incompatible rewrite in the same week, only to languish for a while afterwards. With this sort of release pattern, date-based versions make no sense whatsoever since the calendar makes rather arbitrary cliffs in the topology. For most projects the Major.Minor.Bug style seems to work better, but I have seen projects where the YYYY.MM.DD style is more appropriate. -- Live well, ~wren From aslatter at gmail.com Wed Feb 11 23:55:41 2009 From: aslatter at gmail.com (Antoine Latter) Date: Wed Feb 11 23:45:22 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: <4993A3A0.1000308@freegeek.org> References: <1234349332.5238.246.camel@localhost> <4993A3A0.1000308@freegeek.org> Message-ID: <694519c50902112055o183645f4pd7f5879a0850f3a5@mail.gmail.com> On Wed, Feb 11, 2009 at 10:20 PM, wren ng thornton wrote: > > For projects which are released very frequently (i.e. on the order of daily) > or very infrequently (e.g. semiannually, annually) then date-based releases > can make sense. However, the releases do need to be quite regular on either > of those time scales. This style is also appropriate for projects which > exist in-time with our non-code world. > > Often though, projects see sporadic flurries of improvements and so > something that's been languishing for months can quickly make a couple > bugfix releases followed by a backwards-incompatible rewrite in the same > week, only to languish for a while afterwards. With this sort of release > pattern, date-based versions make no sense whatsoever since the calendar > makes rather arbitrary cliffs in the topology. > > For most projects the Major.Minor.Bug style seems to work better, but I have > seen projects where the YYYY.MM.DD style is more appropriate. > I went with the Major.Minor.YYYY.MM.DD because I'm too lazy to increment bug-fix version numbers, and the code I have building the .cabal file already knows today's date. I guess that approach doesn't work too well if you're not machine generating your .cabal file, or if you expect more than one bug-fix release per day. -Antoine From vigalchin at gmail.com Thu Feb 12 00:46:18 2009 From: vigalchin at gmail.com (Galchin, Vasili) Date: Thu Feb 12 00:35:58 2009 Subject: [Haskell-cafe] Haskell users in the Houston area?? Message-ID: <5ae4f2ba0902112146q5d26931fx186c371a60bc755d@mail.gmail.com> Hello, Are there Haskell users in the Houston area? Regards, Vasili -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090211/58d20c5b/attachment.htm From wren at freegeek.org Thu Feb 12 01:04:30 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Feb 12 00:54:12 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: References: <4992E9DA.6020703@libero.it> Message-ID: <4993BBEE.9070603@freegeek.org> Cristiano Paris wrote: > Manlio Perillo wrote: > > Cristiano Paris ha scritto: > > > I'm interested in the possibility of > > > stopping/pickling/unpickling/resuming a computation. > > > > Not sure this is a good thing in a web application. > > I'm thinking of complex workflows and inversion of control. > > A computation may stop, return a response, wait for a new request to > be passed by the HTTP server and return back a new response, stopping > again. This goes on forever. All this can be achieved in Haskell but > the serialization path, which is crucial for swapping out idle > sessions (containing the stopped computation) or to get back to life > after server stopped (for maintenance for instance). I guess this > should be doable in Clean, which has mechanisms to do dynamic binding > and serialization of closures. It's ugly, but one option is to just reify your continuations as an ADT, where there are constructors for each function and fields for each variable that needs closing over. Serializing that ADT should be simple (unless some of those functions are higher-order in which case you run into the same problem of how to serialize the function arguments). In GHC's STG machine this representation shouldn't have much overhead, though it does require the developer to do the compiler's job. -- Live well, ~wren From allbery at ece.cmu.edu Thu Feb 12 01:11:56 2009 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Thu Feb 12 01:01:54 2009 Subject: [Haskell-cafe] Can this be done? In-Reply-To: <4993BBEE.9070603@freegeek.org> References: <4992E9DA.6020703@libero.it> <4993BBEE.9070603@freegeek.org> Message-ID: On 2009 Feb 12, at 1:04, wren ng thornton wrote: > It's ugly, but one option is to just reify your continuations as an > ADT, where there are constructors for each function and fields for > each variable that needs closing over. Serializing that ADT should > be simple (unless some of those functions are higher-order in which > case you run into the same problem of how to serialize the function > arguments). In GHC's STG machine this representation shouldn't have > much overhead, though it does require the developer to do the > compiler's job. Hmmm... Template Haskell useful here? Feed it the continuation, extract the AST and rewrite as an ADT? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/25116638/PGP.bin From pumpkingod at gmail.com Thu Feb 12 01:26:22 2009 From: pumpkingod at gmail.com (Daniel Peebles) Date: Thu Feb 12 01:16:02 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: <834339889.20090212041557@gmail.com> References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> <1954145479.20090212001139@gmail.com> <20090211212316.GV6911@whirlpool.galois.com> <1163866693.20090212033429@gmail.com> <20090212004536.GT5978@whirlpool.galois.com> <834339889.20090212041557@gmail.com> Message-ID: These seem to be good starting points: http://donsbot.wordpress.com/2008/05/06/write-haskell-as-fast-as-c-exploiting-strictness-laziness-and-recursion/ http://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c-working-at-a-high-altitude-for-low-level-performance/ http://haskell.org/haskellwiki/Wc On Wed, Feb 11, 2009 at 8:15 PM, Bulat Ziganshin wrote: > Hello Don, > > Thursday, February 12, 2009, 3:45:36 AM, you wrote: >> You should do your own benchmarking! > > well, when you say that ghc can generate code that is fast as gcc, i > expect that you can supply some arguments. is the your only argument > that ghc was improved in last years? :) > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From Ben.Lippmeier at anu.edu.au Thu Feb 12 02:02:53 2009 From: Ben.Lippmeier at anu.edu.au (Ben Lippmeier) Date: Thu Feb 12 01:52:39 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code In-Reply-To: References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com> <20178446.20090211230538@gmail.com> <9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com> <1954145479.20090212001139@gmail.com> <20090211212316.GV6911@whirlpool.galois.com> <1163866693.20090212033429@gmail.com> <20090212004536.GT5978@whirlpool.galois.com> <834339889.20090212041557@gmail.com> Message-ID: A: "X has some problems with runtime performance." B: "My work solves all your problems. There is no problem." "Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy" - Alan Perlis. can /= can be bothered. :) Ben. On 12/02/2009, at 5:26 PM, Daniel Peebles wrote: > These seem to be good starting points: > > http://donsbot.wordpress.com/2008/05/06/write-haskell-as-fast-as-c-exploiting-strictness-laziness-and-recursion/ > http://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-c-working-at-a-high-altitude-for-low-level-performance/ > http://haskell.org/haskellwiki/Wc > > > On Wed, Feb 11, 2009 at 8:15 PM, Bulat Ziganshin > wrote: >> Hello Don, >> >> Thursday, February 12, 2009, 3:45:36 AM, you wrote: >>> You should do your own benchmarking! >> >> well, when you say that ghc can generate code that is fast as gcc, i >> expect that you can supply some arguments. is the your only argument >> that ghc was improved in last years? :) >> From barsoap at web.de Thu Feb 12 02:43:32 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 12 02:33:28 2009 Subject: [Haskell-cafe] Re: Can this be done? References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> <20090211184128.7bb8014b@solaris> <3d96ac180902111113h105c9b17ye1e3476dedd07f6d@mail.gmail.com> Message-ID: <20090212084332.08afad45@solaris> Sebastian Sylvan wrote: > On Wed, Feb 11, 2009 at 5:41 PM, Achim Schneider > wrote: > > > I got curious and made two pages point to each other, resulting in > > as many stale continuations as your left mouse button would permit. > > While the model certainly is cool, I'm not aware of any > > implementation that even comes close to having production-safe > > (that is, non-abusable) semantics. > > > Shouldn't the following WASH function help? > > once :: (Read a, Show a) => CGI a -> CGI a > Possibly, I don't know. It was in my early days of Haskell, and I quickly gave up on using anything and prototyped my own web server instead. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From a.biurvOir4 at asuhan.com Thu Feb 12 02:46:30 2009 From: a.biurvOir4 at asuhan.com (Kim-Ee Yeoh) Date: Thu Feb 12 02:36:11 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: <92D07DED-B162-45C6-895A-E8CFB00E2EEE@cs.tcd.ie> References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> <92D07DED-B162-45C6-895A-E8CFB00E2EEE@cs.tcd.ie> Message-ID: <21971304.post@talk.nabble.com> On the same note, does anyone have ideas for the following snippet? Tried the pointfree package but the output was useless. pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) Edsko de Vries wrote: > > Perfect! Beautiful. I was hoping there'd be a simple solution like that. > > Thanks! > > On 9 Feb 2009, at 14:31, Wouter Swierstra wrote: > >> How about using Data.Monoid: >> >> down = downPar `mappend` downNew `mappend` downTrans > > -- View this message in context: http://www.nabble.com/Looking-for-pointfree-version-tp21913653p21971304.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From g9ks157k at acme.softbase.org Thu Feb 12 02:48:14 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 02:38:00 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <801FE99D-FE1C-4B19-9D85-D2B10C85F447@cs.otago.ac.nz> References: <200902111340.27082.g9ks157k@acme.softbase.org> <801FE99D-FE1C-4B19-9D85-D2B10C85F447@cs.otago.ac.nz> Message-ID: <200902120848.14765.g9ks157k@acme.softbase.org> Am Mittwoch, 11. Februar 2009 22:38 schrieben Sie: > On 12 Feb 2009, at 1:40 am, Wolfgang Jeltsch wrote: > > Am Mittwoch, 11. Februar 2009 00:46 schrieben Sie: > >> I suppose I should point out what seems obvious to me, which is > >> that one > >> could embed a substantial chunk of MathML (possibly all of it) in > >> TeX. I > >> mean, give it a TeX-parseable syntax. > > > > You can convert MathML into TeX but not the other way round. How > > would you > > translate $a \odot b \otimes c$? It depends on the precedence of the > > operators. > > And the point of that is? What I suggested is the way around that > works. And the point of my suggestion was that one could have > something that could be embedded directly in a (La)TeX document > *or* processed by Haddock: no changes when copying from one > document to another means fewer new mistakes. I don?t understand this. The way which works is conversion from MathML to TeX. So your suggestion would be to use MathML as the source language. But this is obviously not what you suggest. I?m confused. If you want to use a subset of TeX in Haddock comments, how would you render them on a webpage? Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Feb 12 02:52:04 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 02:41:50 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <200902120852.04699.g9ks157k@acme.softbase.org> Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: > Here are the projects I favor (in no particular order): > [?] > * A GUI interface to Darcs > (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could > possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/. > Perhaps the specific project could be making TortoiseDarcs not Windows > specific? I plan to start writing a GUI interface to darcs together with some of our students. (However, we don?t want to base it on TortoiseDarcs.) So if you have ideas of what features such an interface should have, please write me quickly. > [?] Best wishes, Wolfgang From dev at mobileink.com Thu Feb 12 03:00:12 2009 From: dev at mobileink.com (Gregg Reynolds) Date: Thu Feb 12 02:49:54 2009 Subject: [Haskell-cafe] The Haskell re-branding exercise In-Reply-To: <498DC25E.8070808@cogito.org.uk> References: <494EA1EE.1010606@cogito.org.uk> <498DC25E.8070808@cogito.org.uk> Message-ID: <75cc17ac0902120000m23e601bfy237cb26c8f772f4b@mail.gmail.com> On Sat, Feb 7, 2009 at 11:18 AM, Paul Johnson wrote: > Paul Johnson wrote: > >> A call has gone out < >> http://www.haskell.org/pipermail/haskell-cafe/2008-December/051836.html> >> for a new logo for Haskell. Candidates (including a couple < >> http://www.haskell.org/haskellwiki/Image:Haskell-logo-revolution.png> of >> mine ) >> are accumulating here < >> http://www.haskell.org/haskellwiki/Haskell_logos/New_logo_ideas>. There >> has also been a long thread on the Haskell Cafe mailing list. >> >> So what's happening about this? > I know I'm late to the party, but here's an observation anyway. It might be better to settle on an emblem first, and then a logo. Lambda is popular for functional languages, but it's not a distinctive feature of Haskell. What is distinctive of Haskell is category theory in general and the monad in particular. Both of which are strongly reminiscent of Alchemy. Believe it or not, it's possible to see the operations of the monad as the exact analog of certain aspects of Alchemy (I'm working on a detailed exposition.) Monad as Philosopher's Stone? Galleries of Alchemical emblems and symbols are easily found on the web; see for example the symbol for composition at http://www.iridius.info/current/info/ -gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/fed127cd/attachment-0001.htm From g9ks157k at acme.softbase.org Thu Feb 12 03:04:54 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 02:54:39 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: References: <1234349332.5238.246.camel@localhost> Message-ID: <200902120904.54100.g9ks157k@acme.softbase.org> Am Mittwoch, 11. Februar 2009 23:02 schrieb Corey O'Connor: > The way I read changes in version numbers for a scheme using the > format X.Y.Z is: > * A change in Z indicates bug fixes only > * A change in Y indicates the interface has changed but not in an > incompatible way. For instance, maybe a new method was added. > * A change in X indicates the interface has changed in a way that > could be incompatible with software that depended on a previous > version of the library. Note that Haskell?s package versioning policy [1] assigns your meaning of Z to the 4th component of the version, your meaning of Y to the 3rd and your meaning of X to the pair of the 1st and the 2nd component. Best wishes, Wolfgang [1] From g9ks157k at acme.softbase.org Thu Feb 12 03:12:49 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 03:02:35 2009 Subject: [Haskell-cafe] Haskell.org GSoC In-Reply-To: <20090211175126.GF6911@whirlpool.galois.com> References: <20090211175126.GF6911@whirlpool.galois.com> Message-ID: <200902120912.49554.g9ks157k@acme.softbase.org> Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: > For example, if all the haddocks on hackage.org were a wiki, and > interlinked, every single package author would benefit, as would all > users. You mean, everyone should be able to mess about with my documentation? This would be similar to give everyone commit rights to my repositories or allow everyone to edit the code of my published libraries. What is the good thing about that? Best wishes, Wolfgang From barsoap at web.de Thu Feb 12 03:14:39 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 12 03:04:36 2009 Subject: [Haskell-cafe] Re: Writing a generic event handler References: Message-ID: <20090212091439.03d4302d@solaris> John Ky wrote: > My question is: Is it possible to write a generic doLoop that works > over arbitrary functions? > Yes and no, that is, you can overcome the no. The following code typechecks, and would run nicely if there was a fixed version of reactive, by now[1]. Event handlers can take one arbitrary argument and return anything (as long as it's the same as other handlers), and may be curried before registration, of course. As you can stuff anything you please into one argument, I doubt you'll hit a wall there. Note the usage of Maybe to dispatch, you should be able to do something similar with a plain Maybe monad, without all that Event stuff. Either might also be a good idea. [1] It would also feature splices that can be spliced further and other things quite similar to pattern-matching. TBH, I got tired of not running the code and intimidated by fixpoints of Event streams. module Main where -- current darcs XHB -- hack it to export Graphics.XHB.Connection.Types -- get rid of the Show constraint in Reactive's filterE (or was it justE?) import Graphics.XHB as X import FRP.Reactive as R import FRP.Reactive.LegacyAdapters import Control.Concurrent import Control.Monad import Control.Applicative import Data.Maybe import Data.Monoid createSimpleWindow :: Connection -> Int -> Int -> Int -> Int -> IO WINDOW createSimpleWindow c x y w h = let s = getScreen c black = black_pixel_SCREEN s root = root_SCREEN s depth = root_depth_SCREEN s visual = root_visual_SCREEN s in do id <- newResource c createWindow c (MkCreateWindow depth id root (fromIntegral x) (fromIntegral y) (fromIntegral w) (fromIntegral h) 0 0 visual (toValueParam [(CWBackPixel,black) ,(CWEventMask,toMask [ EventMaskExposure , EventMaskKeyPress --, EventMaskFocusChange ])])) return id createSimpleGC :: Connection -> IO GCONTEXT createSimpleGC c = let s = getScreen c root = root_SCREEN s white = white_pixel_SCREEN s in do g <- newResource c createGC c (MkCreateGC g (castXid root) (toValueParam [(GCForeground,white) ,(GCGraphicsExposures,0) ])) return g printErrors c = (forkIO . forever) $ waitForError c >>= print getScreen = head . roots_Setup . conf_setup . conn_conf castXid = fromXid . toXid main = do (Just c) <- connect printErrors c print $ displayInfo c gc <- createSimpleGC c w <- createSimpleWindow c 0 0 640 480 lock <- newEmptyMVar let quit = putMVar lock () mapWindow c w sync <- makeSync evs <- eventsX sync c forkIO $ adaptE $ braidE (const $ putStrLn "Unhandled Event") [ xEventSplice expose , xEventSplice (keyPress quit) ] evs readMVar lock type Splice a b = (R.Event a, R.Event b) -> (R.Event a, R.Event b) xEventSplice :: X.Event c => (c -> b) -> Splice SomeEvent b xEventSplice = mkSplice fromEvent mkSplice :: (a -> Maybe c) -> (c -> b) -> Splice a b mkSplice f g (a,b) = ( filterE (isNothing . f) a , (fmap g . justE . fmap f) a `mappend` b ) braidE :: (a -> b) -> [Splice a b] -> R.Event a -> R.Event b braidE f ss i = b `mappend` fmap f a where (a, b) = (foldr (.) id ss) (i, mzero) expose :: Expose -> Action expose = const $ putStrLn "expose" keyPress :: Action -> KeyPress -> Action keyPress quit = const $ putStrLn "keyPress" >> quit type Sync = Clock TimeT makeSync = makeClock eventsX cl c = do (sink, res) <- makeEvent cl (forkIO . forever) $ {-putStrLn "tick " >>-} waitForEvent c >>= sink return res -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From dons at galois.com Thu Feb 12 03:15:15 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 12 03:06:07 2009 Subject: [Haskell-cafe] Haskell.org GSoC In-Reply-To: <200902120912.49554.g9ks157k@acme.softbase.org> References: <20090211175126.GF6911@whirlpool.galois.com> <200902120912.49554.g9ks157k@acme.softbase.org> Message-ID: <20090212081515.GA8010@whirlpool.galois.com> g9ks157k: > Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: > > For example, if all the haddocks on hackage.org were a wiki, and > > interlinked, every single package author would benefit, as would all > > users. > > You mean, everyone should be able to mess about with my documentation? This > would be similar to give everyone commit rights to my repositories or allow > everyone to edit the code of my published libraries. What is the good thing > about that? No one said anything about unrestricted commit rights ... we're not crazy ... what if it were more like, say, RWH's wiki .. where comments go to editors to encorporate ... -- Don From matt at mattelder.org Thu Feb 12 03:16:47 2009 From: matt at mattelder.org (Matthew Elder) Date: Thu Feb 12 03:06:28 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <200902120852.04699.g9ks157k@acme.softbase.org> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902120852.04699.g9ks157k@acme.softbase.org> Message-ID: <987d172d0902120016i725dcb2bgc0ed2d18abeb9029@mail.gmail.com> would love to see this. basic features first i suppose. here are some of my ideas: 1. browseable change history with preview pane (preview pane shows diff and patch message) 2. darcs send which goes through the usual interactive console but then prompts with a file save pane where you will save the .dpatch (easy contribution). 3. graphical dependency chart for patches (also shows conflict patches as merges). On Wed, Feb 11, 2009 at 11:52 PM, Wolfgang Jeltsch < g9ks157k@acme.softbase.org> wrote: > Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: > > Here are the projects I favor (in no particular order): > > > [?] > > > * A GUI interface to Darcs > > (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this could > > possibly be based on TortoiseDarcs http://tortoisedarcs.sourceforge.net/ > . > > Perhaps the specific project could be making TortoiseDarcs not Windows > > specific? > > I plan to start writing a GUI interface to darcs together with some of our > students. (However, we don't want to base it on TortoiseDarcs.) So if you > have ideas of what features such an interface should have, please write me > quickly. > > > [?] > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/f788f57c/attachment.htm From benja.fallenstein at gmail.com Thu Feb 12 03:19:44 2009 From: benja.fallenstein at gmail.com (Benja Fallenstein) Date: Thu Feb 12 03:09:24 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: <21971304.post@talk.nabble.com> References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> <92D07DED-B162-45C6-895A-E8CFB00E2EEE@cs.tcd.ie> <21971304.post@talk.nabble.com> Message-ID: On Thu, Feb 12, 2009 at 8:46 AM, Kim-Ee Yeoh wrote: > > On the same note, does anyone have ideas for the following snippet? Tried the > pointfree package but the output was useless. > > pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) import Control.Monad.Reader -- for the (Monad (a ->)) instance import Control.Bifunctor -- package category-extras dup = join (,) mapPair = uncurry bimap pointfree = (mapPair .) . mapPair . dup Or if you're not afraid of *some* points, and want to avoid the imports: dup x = (x,x) mapPair (f,g) (x,y) = (f x, g y) pointfree op = mapPair . mapPair (dup op) That what you're looking for? :-) - Benja From barsoap at web.de Thu Feb 12 03:20:36 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 12 03:10:33 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC References: <20090211175126.GF6911@whirlpool.galois.com> <200902120912.49554.g9ks157k@acme.softbase.org> Message-ID: <20090212092036.0d09805e@solaris> Wolfgang Jeltsch wrote: > Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: > > For example, if all the haddocks on hackage.org were a wiki, and > > interlinked, every single package author would benefit, as would all > > users. > > You mean, everyone should be able to mess about with my > documentation? This would be similar to give everyone commit rights > to my repositories or allow everyone to edit the code of my published > libraries. What is the good thing about that? > The fact that you can mark a revision to be the official one and, in case you e.g. have a wiki yourself, disable the hackage wiki? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From toby.hutton at gmail.com Thu Feb 12 04:00:46 2009 From: toby.hutton at gmail.com (Toby Hutton) Date: Thu Feb 12 03:50:28 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: <21971304.post@talk.nabble.com> References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> <92D07DED-B162-45C6-895A-E8CFB00E2EEE@cs.tcd.ie> <21971304.post@talk.nabble.com> Message-ID: <711894390902120100s1dec1caay43808f43fa9c2799@mail.gmail.com> On Thu, Feb 12, 2009 at 6:46 PM, Kim-Ee Yeoh wrote: > > On the same note, does anyone have ideas for the following snippet? Tried the > pointfree package but the output was useless. > > pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) $ pointfree '(\op (a, b) (c, d) -> (a `op` c, b `op` d))' (`ap` snd) . (. fst) . flip flip snd . ((flip . (ap .)) .) . flip flip fst . ((flip . ((.) .)) .) . (flip =<< (((.) . flip . (((.) . (,)) .)) .)) 'Useless' is a bit understated , IMO. From Christian.Maeder at dfki.de Thu Feb 12 04:11:24 2009 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Thu Feb 12 04:01:05 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <1234397497.4025.6.camel@localhost> References: <499256D9.7020102@gmail.com> <1234397497.4025.6.camel@localhost> Message-ID: <4993E7BC.3030507@dfki.de> Duncan Coutts wrote: > On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: >> Does this version work from ghci? >> >> -- Lennart > > Specifically I believe Lennart is asking about Windows. It's worked in > ghci in Linux for ages and it worked in ghci in Windows prior to the > 0.9.13 release. > > In the 0.9.13 release on Windows there was something funky with linking > (possibly due to using a newer mingw) and ghci's linker could not > understand was was going on and could not load the packages. I'm having trouble http://hackage.haskell.org/trac/ghc/ticket/2615 (cairo depends on pthread, which has a linker script) Is there an easy workaround? Maybe that ticket can be considered in "Plans for GHC 6.10.2" Cheers Christian From felipe.lessa at gmail.com Thu Feb 12 04:30:22 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu Feb 12 04:20:03 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <987d172d0902120016i725dcb2bgc0ed2d18abeb9029@mail.gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902120852.04699.g9ks157k@acme.softbase.org> <987d172d0902120016i725dcb2bgc0ed2d18abeb9029@mail.gmail.com> Message-ID: 2009/2/12 Matthew Elder : > would love to see this. > > basic features first i suppose. here are some of my ideas: meld-like diff view would be great too. http://meld.sourceforge.net/ -- Felipe. From marlowsd at gmail.com Thu Feb 12 04:36:55 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Thu Feb 12 04:26:42 2009 Subject: [Haskell-cafe] Re: space leak with 'concat' ? In-Reply-To: References: <1233091272.25364.19.camel@jcchost> <497F973D.20106@pikewerks.com> <4992F176.8030101@gmail.com> Message-ID: <4993EDB7.6060806@gmail.com> Peter Verswyvelen wrote: > Yes, I was really surprised that this was the case. I while ago I did a > little FRP experiment. I made a top level binding to a list of timer > event occurrences. The list was generated on another thread. To my > surprise, I did not have space leak, which is amazingly cool, but it > felt odd :) Is it documented when GHC will garbage collect CAFs? CAFs are garbage collected when they are unreachable by traversing the code that is reachable from the currently running program. In practice we don't actually traverse the code, instead we have these "static reference tables" that list the top-level closures referenced by each code block, and traverse those instead. Unfortunately we didn't get around to documenting the details of how this works... Cheers, Simon From simonpj at microsoft.com Thu Feb 12 04:41:49 2009 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Feb 12 04:31:35 2009 Subject: [Haskell-cafe] Take a break: write an essay for Onward! Essays Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C33399201B74@EA-EXMSG-C334.europe.corp.microsoft.com> Friends Writing papers is fun, we mostly only get to write one *kind* of paper. Here is an opportunity to write something in a totally different style: Submit an essay to Onward! Essays Deadline: 20 April 2009 http://onward-conference.org/calls/foressays An Onward! essay is a thoughtful reflection upon software-related technology. Its goal is to help the reader to share a new insight, engage with an argument, or wrestle with a dilemma. A successful essay is a clear and compelling piece of writing that explores a topic important to the software community. The subject area should be interpreted broadly, including the relationship of software to human endeavours, or its philosophical, sociological, psychological, historical, or anthropological underpinnings. An essay can be an exploration of its topic, its impact, or the circumstances of its creation; it can present a personal view of what is, explore a terrain, or lead the reader in an act of discovery; it can be a philosophical digression or a deep analysis. It can describe a personal journey, perhaps that by which the author reached an understanding of such a topic. I'm the program chair, and I'd love to get submissions from the POPL/ICFP/types community. Reflections on programming languages, types, testing, verification, software engineering, compilers, society, ... you name it. Anything to do with software. NB: Onward! is co-located with OOPSLA, but they are otherwise unrelated. OO is fine, but not required. Don't forget: 20th April. Simon PS: To get your imagination going, here are a couple of (strongly-contrasting) past essays: * Dan Grossman "The transactional memory / garbage collection analogy" http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla07.pdf * Dick Gabriel "Designed as designer" http://dreamsongs.org/DesignedAsDesigner.html From apfelmus at quantentunnel.de Thu Feb 12 04:42:57 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu Feb 12 04:32:06 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC In-Reply-To: <200902120912.49554.g9ks157k@acme.softbase.org> References: <20090211175126.GF6911@whirlpool.galois.com> <200902120912.49554.g9ks157k@acme.softbase.org> Message-ID: Wolfgang Jeltsch wrote: > Don Stewart wrote: >> For example, if all the haddocks on hackage.org were a wiki, and >> interlinked, every single package author would benefit, as would all >> users. > > You mean, everyone should be able to mess about with my documentation? This > would be similar to give everyone commit rights to my repositories or allow > everyone to edit the code of my published libraries. What is the good thing > about that? Well, it's excellent if you haven't written said documentation yet. ;) But yes, the package author should have the last word about what goes in and what does not. The goal is simply to drastically lower the bar of participation. Regards, apfelmus -- http://apfelmus.nfshost.com From svein.ove at aas.no Thu Feb 12 04:48:22 2009 From: svein.ove at aas.no (Svein Ove Aas) Date: Thu Feb 12 04:38:02 2009 Subject: [Haskell-cafe] Re: space leak with 'concat' ? In-Reply-To: <4993EDB7.6060806@gmail.com> References: <1233091272.25364.19.camel@jcchost> <497F973D.20106@pikewerks.com> <4992F176.8030101@gmail.com> <4993EDB7.6060806@gmail.com> Message-ID: <221b53ab0902120148o625c1a73rc8acb5244d51b83f@mail.gmail.com> On Thu, Feb 12, 2009 at 10:36 AM, Simon Marlow wrote: > Peter Verswyvelen wrote: >> >> Yes, I was really surprised that this was the case. I while ago I did a >> little FRP experiment. I made a top level binding to a list of timer event >> occurrences. The list was generated on another thread. To my surprise, I did >> not have space leak, which is amazingly cool, but it felt odd :) Is it >> documented when GHC will garbage collect CAFs? > > CAFs are garbage collected when they are unreachable by traversing the code > that is reachable from the currently running program. In practice we don't > actually traverse the code, instead we have these "static reference tables" > that list the top-level closures referenced by each code block, and traverse > those instead. > > Unfortunately we didn't get around to documenting the details of how this > works... > Using this as a guide, I tested these two programs: ==== str = concat $ repeat "foo " main1 = print foo main2 = print foo >> print foo ===== As I'm sure you realize, the first ran in constant memory; the second, not so much. Very interesting. From lrpalmer at gmail.com Thu Feb 12 04:49:38 2009 From: lrpalmer at gmail.com (Luke Palmer) Date: Thu Feb 12 04:39:20 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC In-Reply-To: References: <20090211175126.GF6911@whirlpool.galois.com> <200902120912.49554.g9ks157k@acme.softbase.org> Message-ID: <7ca3f0160902120149y9eccbcfn3630c04923f71448@mail.gmail.com> On Thu, Feb 12, 2009 at 2:42 AM, Heinrich Apfelmus < apfelmus@quantentunnel.de> wrote: > Wolfgang Jeltsch wrote: > > Don Stewart wrote: > >> For example, if all the haddocks on hackage.org were a wiki, and > >> interlinked, every single package author would benefit, as would all > >> users. > > > > You mean, everyone should be able to mess about with my documentation? > This > > would be similar to give everyone commit rights to my repositories or > allow > > everyone to edit the code of my published libraries. What is the good > thing > > about that? > > Well, it's excellent if you haven't written said documentation yet. ;) > > But yes, the package author should have the last word about what goes in > and what does not. The goal is simply to drastically lower the bar of > participation. Something like AnnoCPAN would be a good middle-ground here; i.e. differentiate between "official" package documentation and user annotations, but make them both visible. Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/9a19c69e/attachment.htm From Alistair.Bayley at invesco.com Thu Feb 12 04:50:36 2009 From: Alistair.Bayley at invesco.com (Bayley, Alistair) Date: Thu Feb 12 04:40:18 2009 Subject: [Haskell-cafe] Haskell.org GSoC In-Reply-To: <20090212081515.GA8010@whirlpool.galois.com> References: <20090211175126.GF6911@whirlpool.galois.com><200902120912.49554.g9ks157k@acme.softbase.org> <20090212081515.GA8010@whirlpool.galois.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA911025E6A@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Don Stewart > > > > You mean, everyone should be able to mess about with my > documentation? This > > would be similar to give everyone commit rights to my > repositories or allow > > everyone to edit the code of my published libraries. What > is the good thing > > about that? > > No one said anything about unrestricted commit rights ... we're not > crazy ... what if it were more like, say, RWH's wiki .. where comments > go to editors to incorporate ... Yes. PostgreSQL online docs have a similar feature, although their implementation isn't perhaps as nice as RWH's (I like RWH's inline comments feature). See e.g. http://www.postgresql.org/docs/8.3/interactive/tutorial-createdb.html http://www.postgresql.org/docs/8.3/interactive/functions-string.html http://www.postgresql.org/docs/8.3/interactive/indexes-multicolumn.html http://www.postgresql.org/docs/8.3/interactive/textsearch-tables.html Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. ***************************************************************** From apfelmus at quantentunnel.de Thu Feb 12 04:51:41 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu Feb 12 04:40:46 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC In-Reply-To: <20090212081515.GA8010@whirlpool.galois.com> References: <20090211175126.GF6911@whirlpool.galois.com> <200902120912.49554.g9ks157k@acme.softbase.org> <20090212081515.GA8010@whirlpool.galois.com> Message-ID: Don Stewart wrote: > > No one said anything about unrestricted commit rights ... we're not > crazy ... what if it were more like, say, RWH's wiki .. where comments > go to editors to encorporate ... By the way, the PHP documentation has such a comment feature, see for example http://www.php.net/manual/en/function.preg-match.php But I'm not sure whether this form of commenting is the best way to write/improve documentation. (The many proposed regular expressions for validating e-mail addresses sure have a certain hilarity to them...) Regards, apfelmus -- http://apfelmus.nfshost.com From apfelmus at quantentunnel.de Thu Feb 12 05:08:08 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu Feb 12 04:57:14 2009 Subject: [Haskell-cafe] Re: Looking for pointfree version In-Reply-To: References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> <92D07DED-B162-45C6-895A-E8CFB00E2EEE@cs.tcd.ie> <21971304.post@talk.nabble.com> Message-ID: Benja Fallenstein wrote: > Kim-Ee Yeoh wrote: >> >> On the same note, does anyone have ideas for the following snippet? Tried the >> pointfree package but the output was useless. >> >> pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) > > import Control.Monad.Reader -- for the (Monad (a ->)) instance > import Control.Bifunctor -- package category-extras > > dup = join (,) > mapPair = uncurry bimap > pointfree = (mapPair .) . mapPair . dup > > Or if you're not afraid of *some* points, and want to avoid the imports: > > dup x = (x,x) > mapPair (f,g) (x,y) = (f x, g y) > pointfree op = mapPair . mapPair (dup op) > > That what you're looking for? :-) The pairs are of course an applicative functor (<*>) = uncurry (***) -- from Control.Arrow pure x = (x,x) pointwise op x y = pure op <*> x <*> y Regards, apfelmus -- http://apfelmus.nfshost.com From bugfact at gmail.com Thu Feb 12 05:22:35 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 12 05:15:55 2009 Subject: [Haskell-cafe] Re: space leak with 'concat' ? In-Reply-To: <221b53ab0902120148o625c1a73rc8acb5244d51b83f@mail.gmail.com> References: <1233091272.25364.19.camel@jcchost> <497F973D.20106@pikewerks.com> <4992F176.8030101@gmail.com> <4993EDB7.6060806@gmail.com> <221b53ab0902120148o625c1a73rc8acb5244d51b83f@mail.gmail.com> Message-ID: On Thu, Feb 12, 2009 at 10:48 AM, Svein Ove Aas wrote: > Using this as a guide, I tested these two programs: > > ==== > str = concat $ repeat "foo " > > main1 = print foo > main2 = print foo >> print foo > ===== > > As I'm sure you realize, the first ran in constant memory; the second, > not so much. Very interesting. > That seems logical to me. The first one prints the str once, and str is never needed anymore. The second one prints str, and after it is printed, it prints it again, so the full str is needed again. So the "life data" analyzer is not clever enough to realize that the second print will never occur. Solving the latter might require solving the halting problem? I don't know It is funny that recently I had a strange problem in C# (I tried to write parts of Reactive in C#) where the garbage collector freed data that was actually needed by my program! I had to fix that by putting a local variable on the stack, passing the constructed data to a function did not work. I think .NET and Java the garbage collector traverses from data (the stack, globals, etc). If I understood Simon correctly, GHC traverse the code blocks instead, which feels correct as it would have fixed the bug I had in C#. So yet again an extreme difference between Haskell and .NET/Java even when it comes to garbage collection, Haskell wins :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/438b2377/attachment.htm From g9ks157k at acme.softbase.org Thu Feb 12 05:31:37 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 05:21:22 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC In-Reply-To: <20090212092036.0d09805e@solaris> References: <200902120912.49554.g9ks157k@acme.softbase.org> <20090212092036.0d09805e@solaris> Message-ID: <200902121131.37469.g9ks157k@acme.softbase.org> Am Donnerstag, 12. Februar 2009 09:20 schrieb Achim Schneider: > Wolfgang Jeltsch wrote: > > Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: > > > For example, if all the haddocks on hackage.org were a wiki, and > > > interlinked, every single package author would benefit, as would all > > > users. > > > > You mean, everyone should be able to mess about with my > > documentation? This would be similar to give everyone commit rights > > to my repositories or allow everyone to edit the code of my published > > libraries. What is the good thing about that? > > The fact that you can mark a revision to be the official one and, in > case you e.g. have a wiki yourself, disable the hackage wiki? What do you mean by ?disabling the Hackage wiki?? Best wishes, Wolfgang From Malcolm.Wallace at cs.york.ac.uk Thu Feb 12 05:36:29 2009 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Feb 12 05:30:02 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20090212103629.58f12bc3.Malcolm.Wallace@cs.york.ac.uk> Gwern Branwen wrote: > * A GUI interface to Darcs > (http://hackage.haskell.org/trac/summer-of-code/ticket/17); I wonder whether darcs ought to apply to be a GSoC mentoring organisation in its own right this year? It would be good to attempt to get a couple of dedicated slots for darcs only (in addition to any that haskell.org may get). > * Optimization of containers > (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would > benefit every Haskell user very quickly. This was Jamie Brandon's GSoC project last year, and although that is not yet in wide use, I suspect there is very little extra effort needed to get it out there into the average Haskell user's hands. > * XMonad compositing support > (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). Maybe XMonad should also think about whether to apply to GSoC in their own right as a mentoring org? As a project, it seems to have a lot of life independent of the Haskell community. Regards, Malcolm From frodo at theshire.org Thu Feb 12 05:41:40 2009 From: frodo at theshire.org (Cristiano Paris) Date: Thu Feb 12 05:31:19 2009 Subject: [Haskell-cafe] Re: Can this be done? In-Reply-To: <20090211184128.7bb8014b@solaris> References: <79d7c4980902110534n490aef7av6816e231ffe9f014@mail.gmail.com> <2518b95d0902110543w7e2cb8b3gcb595e380c0eac9b@mail.gmail.com> <20090211184128.7bb8014b@solaris> Message-ID: On Wed, Feb 11, 2009 at 6:41 PM, Achim Schneider wrote: > ... > I got curious and made two pages point to each other, resulting in as > many stale continuations as your left mouse button would permit. While > the model certainly is cool, I'm not aware of any implementation that > even comes close to having production-safe (that is, non-abusable) > semantics. Stale continuations are an issue (think of anonymous accesses), even if my personal feeling is that it may be mitigated using continuations wisely (i.e. only when they're actually relevant). Cristiano From felipe.lessa at gmail.com Thu Feb 12 05:52:26 2009 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu Feb 12 05:42:06 2009 Subject: [Haskell-cafe] Re: space leak with 'concat' ? In-Reply-To: References: <1233091272.25364.19.camel@jcchost> <497F973D.20106@pikewerks.com> <4992F176.8030101@gmail.com> <4993EDB7.6060806@gmail.com> <221b53ab0902120148o625c1a73rc8acb5244d51b83f@mail.gmail.com> Message-ID: 2009/2/12 Peter Verswyvelen : > It is funny that recently I had a strange problem in C# (I tried to write > parts of Reactive in C#) where the garbage collector freed data that was > actually needed by my program! I had to fix that by putting a local variable > on the stack, passing the constructed data to a function did not work. I > think .NET and Java the garbage collector traverses from data (the stack, > globals, etc). If I understood Simon correctly, GHC traverse the code blocks > instead, which feels correct as it would have fixed the bug I had in C#. So > yet again an extreme difference between Haskell and .NET/Java even when it > comes to garbage collection, Haskell wins :) I'm curious, a GC that removes live data is a buggy GC. What was holding the pointer to the data, if it was not the stack? Were you with MS .NET or with Mono? -- Felipe. From barsoap at web.de Thu Feb 12 05:56:10 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 12 05:46:23 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC References: <200902120912.49554.g9ks157k@acme.softbase.org> <20090212092036.0d09805e@solaris> <200902121131.37469.g9ks157k@acme.softbase.org> Message-ID: <20090212115610.77d151b3@solaris> Wolfgang Jeltsch wrote: > Am Donnerstag, 12. Februar 2009 09:20 schrieb Achim Schneider: > > Wolfgang Jeltsch wrote: > > > Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: > > > > For example, if all the haddocks on hackage.org were a wiki, and > > > > interlinked, every single package author would benefit, as > > > > would all users. > > > > > > You mean, everyone should be able to mess about with my > > > documentation? This would be similar to give everyone commit > > > rights to my repositories or allow everyone to edit the code of > > > my published libraries. What is the good thing about that? > > > > The fact that you can mark a revision to be the official one and, in > > case you e.g. have a wiki yourself, disable the hackage wiki? > > What do you mean by ___disabling the Hackage wiki___? > Well, disabling the wiki function of the documentation on hackage and redirect to somewhere else, instead. The point is that it's certainly possible to have some maintainer-guaranteed integrity and the possibility of low-barrier contributions at the same time. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From porges at porg.es Thu Feb 12 06:05:13 2009 From: porges at porg.es (George Pollard) Date: Thu Feb 12 05:54:57 2009 Subject: [Haskell-cafe] Re: Looking for pointfree version In-Reply-To: References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> <92D07DED-B162-45C6-895A-E8CFB00E2EEE@cs.tcd.ie> <21971304.post@talk.nabble.com> Message-ID: <1234436713.17816.1.camel@porges-laptop> On Thu, 2009-02-12 at 11:08 +0100, Heinrich Apfelmus wrote: > Benja Fallenstein wrote: > > Kim-Ee Yeoh wrote: > >> > >> On the same note, does anyone have ideas for the following snippet? Tried the > >> pointfree package but the output was useless. > >> > >> pointwise op (x0,y0) (x1,y1) = (x0 `op` x1, y0 `op` y1) > > > > import Control.Monad.Reader -- for the (Monad (a ->)) instance > > import Control.Bifunctor -- package category-extras > > > > dup = join (,) > > mapPair = uncurry bimap > > pointfree = (mapPair .) . mapPair . dup > > > > Or if you're not afraid of *some* points, and want to avoid the imports: > > > > dup x = (x,x) > > mapPair (f,g) (x,y) = (f x, g y) > > pointfree op = mapPair . mapPair (dup op) > > > > That what you're looking for? :-) > > The pairs are of course an applicative functor > > (<*>) = uncurry (***) -- from Control.Arrow > pure x = (x,x) > > pointwise op x y = pure op <*> x <*> y > > > Regards, > apfelmus Concretely (this might do with a few laziness notations): > import Control.Applicative > > data Pair a = a :*: a > > instance Functor Pair where > f `fmap` (x :*: y) = f x :*: f y > > instance Applicative Pair where > (f :*: g) <*> (x :*: y) = f x :*: f y > pure x = x :*: x > > pointfree :: (a -> b -> c) -> Pair a -> Pair b -> Pair c > --pointfree o x y = pure o <*> x <*> y > pointfree = ((<*>) .) . (<*>) . pure > -- in the applicative paper notation: > --pointfree o x y = [| o x y |] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/441adb32/attachment.bin From bugfact at gmail.com Thu Feb 12 06:09:34 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 12 05:59:19 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <1234397497.4025.6.camel@localhost> References: <499256D9.7020102@gmail.com> <1234397497.4025.6.camel@localhost> Message-ID: 0.10.0 works on Windows for me even when using GHCi. Great work, I love it. On Thu, Feb 12, 2009 at 1:11 AM, Duncan Coutts wrote: > On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: > > Does this version work from ghci? > > > > -- Lennart > > Specifically I believe Lennart is asking about Windows. It's worked in > ghci in Linux for ages and it worked in ghci in Windows prior to the > 0.9.13 release. > > In the 0.9.13 release on Windows there was something funky with linking > (possibly due to using a newer mingw) and ghci's linker could not > understand was was going on and could not load the packages. > > Duncan > > > On Wed, Feb 11, 2009 at 5:40 AM, Peter Gavin wrote: > > > Hi everyone, > > > > > > Oh, dear... it seems I've forgotten how to spell "cafe", and sent this > > > message to haskell-caft@haskell.org the first time around. I resent > it to > > > all the lists again (just to make sure everyone interested receives > it), so > > > I apologize for any duplicated messages you might have received. In > any > > > case... > > > > > > I'd like to release the announcement of Gtk2HS 0.10.0. A lot of new > stuff > > > has gone into this release, including: > > > > > > - Support for GHC 6.10 > > > - Bindings to GIO and GtkSourceView-2.0 > > > - Full switch to the new model-view implementation using a Haskell > model > > > - Support for many more model-based widgets such as IconView and an > updated > > > binding for ComboBox > > > - Full Drag-and-Drop support > > > - Better support for Attributes in Pango > > > - Replaced Event for EventM monad, thereby improving efficiency and > > > convenience > > > - Functions for interaction between Cairo and Pixbuf drawing > > > - Lots of bug fixes, code cleanups, and portability improvements > > > > > > With this release, the bindings to GnomeVFS and GtkSourceView-1.0 have > been > > > deprecated. The TreeList modules have been deprecated from the Gtk+ > > > bindings. > > > > > > Source and Win32 binaries are available at: > > > > > > > > > > https://sourceforge.net/project/showfiles.php?group_id=49207package_id=42440&release_id=659598 > > > > > > Thanks to everyone who submitted bug fixes and features this time > around! > > > > > > Thanks, > > > Peter Gavin > > > Gtk2HS Release Manager > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe@haskell.org > > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/5f7054db/attachment-0001.htm From duncan.coutts at worc.ox.ac.uk Thu Feb 12 07:04:25 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 12 06:54:41 2009 Subject: [Haskell-cafe] Gtk2HS 0.10.0 Released In-Reply-To: <4993E7BC.3030507@dfki.de> References: <499256D9.7020102@gmail.com> <1234397497.4025.6.camel@localhost> <4993E7BC.3030507@dfki.de> Message-ID: <1234440265.4025.18.camel@localhost> On Thu, 2009-02-12 at 10:11 +0100, Christian Maeder wrote: > Duncan Coutts wrote: > > On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote: > >> Does this version work from ghci? > >> > >> -- Lennart > > > > Specifically I believe Lennart is asking about Windows. It's worked in > > ghci in Linux for ages and it worked in ghci in Windows prior to the > > 0.9.13 release. > > > > In the 0.9.13 release on Windows there was something funky with linking > > (possibly due to using a newer mingw) and ghci's linker could not > > understand was was going on and could not load the packages. > > I'm having trouble > http://hackage.haskell.org/trac/ghc/ticket/2615 > (cairo depends on pthread, which has a linker script) > Is there an easy workaround? The way it used to work was that the Gtk2Hs ./configure script just filtered out pthread on linux systems. Of course that's just a hack. > Maybe that ticket can be considered in "Plans for GHC 6.10.2" Maybe. Dealing with linker scripts properly is probably rather tricky and we get it for free when we switch to shared libraries. Duncan From gtener at gmail.com Thu Feb 12 07:12:04 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Thu Feb 12 07:01:45 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090212103629.58f12bc3.Malcolm.Wallace@cs.york.ac.uk> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <20090212103629.58f12bc3.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <220e47b40902120412n20b09a08va14d7dced3cc9e3f@mail.gmail.com> On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace wrote: > Gwern Branwen wrote: > >> * A GUI interface to Darcs >> (http://hackage.haskell.org/trac/summer-of-code/ticket/17); > > I wonder whether darcs ought to apply to be a GSoC mentoring > organisation in its own right this year? ?It would be good to attempt to > get a couple of dedicated slots for darcs only (in addition to any that > haskell.org may get). > >> * Optimization of containers >> (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would >> benefit every Haskell user very quickly. > > This was Jamie Brandon's GSoC project last year, and although that is > not yet in wide use, I suspect there is very little extra effort needed > to get it out there into the average Haskell user's hands. > >> * XMonad compositing support >> (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). > > Maybe XMonad should also think about whether to apply to GSoC in their > own right as a mentoring org? ?As a project, it seems to have a lot of > life independent of the Haskell community. > By the way: I think it may be worthwile to contact Google to point out the recent growth of Haskell community. I don't know on what basis they assign the slots, but it may be beneficial to do so. All best Christopher Skrz?tnicki From duncan.coutts at worc.ox.ac.uk Thu Feb 12 07:12:45 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 12 07:02:40 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: References: <1234349332.5238.246.camel@localhost> Message-ID: <1234440765.4025.25.camel@localhost> On Wed, 2009-02-11 at 14:02 -0800, Corey O'Connor wrote: > On Wed, Feb 11, 2009 at 2:48 AM, Duncan Coutts > wrote: > > On Tue, 2009-02-10 at 10:21 -0800, Corey O'Connor wrote: > >> I released a new version of data-spacepart that resolved some of the > >> issues with the previous release. One issue I had was the previous > >> release used the version numbering scheme I use at work: > >> [date].[release] Which does not appear to work as well as the > >> traditional X.Y.Z release numbering scheme with Cabal. > > > > I'm not sure I understand. Is there something in Cabal or Hackage that > > makes date-based numbering schemes not work well? > > I think version number schemes of the X.Y.Z form are easier to work > with when defining cabal depends constraints. A user of the library > can use the constrain "data-spacepart == 0.1.*" to specifying a > dependency on any 0.1 release. For date-based version numbers what > would the constraint be? "data-spacepart == 20090211.*" maybe? Or > constrain to a range of dates? Both seem awkward to me. > > Part of the reason they seem awkward to me is that I expect the > difference between version numbers to indicate something about what > has changed between the two versions. This only ends up being a > heuristic but a useful one. Date based version numbers don't > communicate much beyond, well, the date the release was built on > unless annotations are added in addition to the date. Still, they > don't read as nicely as X.Y.Z scheme version numbers. > > The way I read changes in version numbers for a scheme using the > format X.Y.Z is: > * A change in Z indicates bug fixes only > * A change in Y indicates the interface has changed but not in an > incompatible way. For instance, maybe a new method was added. > * A change in X indicates the interface has changed in a way that > could be incompatible with software that depended on a previous > version of the library. > > I don't know of a mapping that can be applied to date based version > numbers that is as rigorous. Right yes. Using a versioning scheme that relates to the API is a good idea for libraries. As Wolfgang mentioned, you may choose to follow the common package versioning policy. http://haskell.org/haskellwiki/Package_versioning_policy We are planning to develop tool support for this. To let packages explicitly opt-in and then we can hold such packages to their promise. We can also advise authors about what form of version constraints they should use for dependencies on packages that follow the PVP. That said, there are still areas where date-based is fine. For example the platform meta-package will be date based but also follow the PVP. Duncan From duncan.coutts at worc.ox.ac.uk Thu Feb 12 07:18:28 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu Feb 12 07:08:24 2009 Subject: [Haskell-cafe] Re: Haddock Markup In-Reply-To: <4991678F.6020401@henning-thielemann.de> References: <1233916294.9411.15.camel@porges-laptop> <200902061603.29609.g9ks157k@acme.softbase.org> <49903964.3070304@henning-thielemann.de> <4991678F.6020401@henning-thielemann.de> Message-ID: <1234441108.4025.30.camel@localhost> On Tue, 2009-02-10 at 12:39 +0100, Henning Thielemann wrote: > Heinrich Apfelmus schrieb: > > Henning Thielemann wrote: > >> I want for long to write math formulas in a paper in Haskell. Actually, > >> lhs2TeX can do such transformations but it is quite limited in handling > >> of parentheses and does not support more complicated transformations > >> (transforming prefix notation in infix notation or vice versa with > >> minimal parentheses). > >> > >> I would like to write > >> sumFor [0..n] (\i -> i^2) > >> (with sumFor xs f = sum $ map f xs) > >> which is rendered as > >> \sum_{i=0}^{n} i^2 > >> or > >> integrate 1000 (a,b) (\t -> f t) > >> to be rendered as > >> \int_a^b f(t) \dif t > > > > Neat idea! Can't you do implement this as a DSL? > > > > sumFor x xs f = > > "\sum_{" ++ x ++ "=" ++ head xs ++ "}^{" ++ last xs ++ "} " > > ++ f x > > > My original idea was to use the formulas in papers both for typesetting > and for unit testing. Thus, when you state that a function fulfills a > law, that it can be automatically tested by QuickCheck, that this at > least true for some instances. > The same would be useful for Haddock documentation. I remember that > someone proposed to permit Haddock to expose the implementation of some > functions as examples or as unit-tests/laws. Now we could extend this > idea to allow Haddock not only to expose the implementation of > functions, but also to tell Haddock how to render its implementation. If we want to tell haddock how to render an implementation, surely we use a derivative of lhs2tex. It requires minimal markup in the standard case (just spacing for alignment) and has a nice set of standard presentation rules and allows extending that with formatting directives. It would not let you write complex display mode maths like \sum_{i=0}^{n} i^2 but for code, and laws and proofs that look mostly like code it's really nice. Duncan From haskell at datakids.org Thu Feb 12 07:45:59 2009 From: haskell at datakids.org (Jamie) Date: Thu Feb 12 07:35:40 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <220e47b40902111519q158009a5r473ca34f40466d60@mail.gmail.com> <20090211233151.GI5978@whirlpool.galois.com> Message-ID: On Thu, 12 Feb 2009, Conrad Parker wrote: > 2009/2/12 Don Stewart : >> Thanks for the analysis, this clarifies things greatly. >> Feasibility and scope is a big part of how we determine what projects to >> work on. > > I agree that it's beyond the scope of a SoC project. > > Rather than H.263 or H.264 I was going to suggest implementation of > Theora or OMS, both of which avoid the patent issues and have publicly > available specs: > > http://theora.org/doc/Theora.pdf > http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf > > Scanning those documents should give anyone a fair idea of the amount > of work involved. My understanding is that OMS is of a similar > complexity to H.263, and H.264 is more complex than any of these. > > For Theora playback we've found that the largest CPU load comes from > colorspace conversion, where the YUV output of the codec needs to be > converted to RGB for some targets (like Firefox). That is some fairly > straightforward array processing, and would be a good place to start > for anyone trying to implement video codecs in Haskell. That is great idea and a great seed to plant. Wonder if Theora is as good as H.264 in terms of video quality and bandwidth usage? Theora codec is being used in Ekiga (popular SIP/H.323 video softphone but that thing keeps crashing on me :( ) Jamie > Conrad. > >> >> gtener: >>> On Wed, Feb 11, 2009 at 21:00, Jamie wrote: >>>> Hi Gwern, >>>> >>>> On Wed, 11 Feb 2009, Gwern Branwen wrote: >>>> >>>>>> I just checked H.263 and it looks like it does not require patent >>>>>> licensing >>>>>> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one >>>>>> can >>>>>> write H.263 in Haskell and release freely without patent licensing >>>>>> issues. >>>>>> >>>>>> So writing H.263 in Haskell could be a good GSoC project. One mentioned >>>>>> that GHC produce slow code, well H.263 could be a good test case to >>>>>> improve >>>>>> GHC optimization over time. In The Computer Language Benchmarks Game, >>>>>> Haskell has some catching up to do. :) >>>>> >>>>> It does sound like a reasonably discrete task, and it sounds like you have >>>>> a use for it; but I wonder if it's doable in a single summer? >>>> >>>> I have no idea, I have not dig deeper into H.263 C source code but I guess >>>> it should be quite trivial as it is a black box with video frame input and >>>> output with several parameters for encoding and just frame in/out for >>>> decoding. >>> >>> I didn't dig into the source code either, but I've just skimmed >>> through Wikipedia page on that codec: >>> http://en.wikipedia.org/wiki/H.263 >>> and in seems far from trivial. Anything that has 23 annexes is likely >>> to be quite complex :-) >>> Therefore I seriously doubt chances for success of such project. I did >>> some checks: in libavcodec at least following files consist of >>> implementation of H.263: >>> >>> h263.c h263data.h h263dec.c h263.h >>> h263_parser.c h263_parser.h >>> >>> How many lines are there? >>> >>> [Tener@laptener libavcodec]$ wc h263* >>> 6295 19280 218932 h263.c >>> 314 2117 10423 h263data.h >>> 816 2171 26675 h263dec.c >>> 46 217 2032 h263.h >>> 91 282 2361 h263_parser.c >>> 29 165 1047 h263_parser.h >>> 7591 24232 261470 razem >>> >>> In Haskell project one would also need to provide some additional >>> utility code which is part of libavcodec. >>> Fast grep shows the tip of an iceberg: >>> >>> [Tener@laptener libavcodec]$ grep include h263* | grep -v "<" >>> h263.c:#include "dsputil.h" >>> h263.c:#include "avcodec.h" >>> h263.c:#include "mpegvideo.h" >>> h263.c:#include "h263data.h" >>> h263.c:#include "mpeg4data.h" >>> h263.c:#include "mathops.h" >>> h263data.h:#include "mpegvideo.h" >>> h263dec.c:#include "avcodec.h" >>> h263dec.c:#include "dsputil.h" >>> h263dec.c:#include "mpegvideo.h" >>> h263dec.c:#include "h263_parser.h" >>> h263dec.c:#include "mpeg4video_parser.h" >>> h263dec.c:#include "msmpeg4.h" >>> h263.h:#include "config.h" >>> h263.h:#include "msmpeg4.h" >>> h263_parser.c:#include "parser.h" >>> h263_parser.h:#include "parser.h" >>> >>> >>> >>> Bottom line: I don't think it is reasonable to assume anyone without >>> previous knowledge of H.263 is able to fit that project into one >>> summer. But! It's Haskell community, and people here see the >>> impossible happen from time to time ;-) >>> >>> All best >>> >>> Christopher Skrz?tnicki >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From claus.reinke at talk21.com Thu Feb 12 07:56:57 2009 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Feb 12 07:46:42 2009 Subject: [Haskell-cafe] Re[4]: [Haskell] Google Summer of Code References: <9979e72e0902110954m7cb383f9laf351ca82c1fee16@mail.gmail.com><20178446.20090211230538@gmail.com><9979e72e0902111255q229cdda7o95e6503916253d63@mail.gmail.com><1954145479.20090212001139@gmail.com><20090211212316.GV6911@whirlpool.galois.com><1163866693.20090212033429@gmail.com> <20090212004536.GT5978@whirlpool.galois.com> Message-ID: <5482B140BC4E4A7CA87318A6F055F901@cr3lt> >> > Check out what GHC is doing these days, and come back with an analysis >> > of what still needs to be improved. We can't wait to hear! >> can you point me to any haskell code that is as fast as it's C >> equivalent? > You should do your own benchmarking! Please, folks! This is hardly helpful. It isn't difficult to find examples of fast Haskell code by Don, nor is it difficult to find benchmarking and analyses of slow GHC-generated code by Bulat. But expecting "your" readers to search for such fragments instead of providing direct references weakens your cases. In fact, I'm not aware of any documents that would make a coherent argument either way: - most of Don's examples focus on small bits of code where (a) it is still possible to associate core output with parts of the input (making the dire state of tool support less of an issue) and (b) few real-life awkwardnesses interfere with the optimization of pure algorithms (by which I mean code artifacts such as error handling etc confusing GHC's optimization phases). - most of Bulat's analyses refer to the via-C path, which used to be the fastest path, but appears to have an uncertain future (not that I'm aware of any claims, let alone documentation showing that the now standard compilation path in GHC is at least as good as via-C used to be). That summary is of course only based on the fragments I have chosen to find - if you want a fairer summary, you need to provide concrete and uptodate references!-) And if you don't want to be asked to repeat your argument every time this thread comes up, you need to present it in easily referenced form outside this mailing list. In particular, I would suggest that 1. performance issues are recorded as GHC trac tickets, with test cases, (there is an explicit ticket type for this) so that we could check easily whether any general GHC improvements have had any effect on which known bad cases. Note that performance isn't a high-priority issue per se at GHC HQ (due to manpower), unless it is a show-stopper or many users report it as important to them. Nevertheless, the issues should be recorded, so that we know where we stand. 2. performance wisdom is recorded on the Haskell/GHC wikis, or in tutorials/papers. There is a lot of information on small tricks already, but very little on what to do when those small tricks no longer suffice (eg, after one has found out that profiling lies, that core isn't easy to link back to source, when the code in question is not just pure and simple algorithm but riddled with error handling imported from libraries). Personally, I find the situation wrt performance of GHC-generated code very unsatisfactory, not because it isn't good (more often than not, it is), but because there is very little help when it isn't. And the first step towards improving that situation (eg, with tools helping to analyse core, or better understood profiling tools, or support for by-hand application of optimization transformation/undo/modify/retarget/replay..) is to acknowledge that there is a problem. Pointing out that some experienced hackers have been through this, and are now able to make do for themselves, is a non-solution (unless you want to secure consulting fees;-). Just as declarative languages allow us to ignore operational details until/unless they really are needed, offering a clear path on how to specify declarative aspects of our code, so there should be a clear path on how to specify operational details if that becomes necessary. A path that any mildly experienced Haskeller should be able to follow through good documentation, examples, and tools. Claus PS. Talking about "high-performance computing" seems slightly misleading in this context, if the only goal is to have code as fast as typical C. From what I've heard from HPC folks, generic compilers or generic C code are not tough benchmarks from their point of view, platform vendor compilers and platform-tuned Fortran code are. Of course, that info is second-hand, and somewhat dated, but I think it would help to state our goals explicitly, to avoid confusion or unreasonable expectations. From marco-oweber at gmx.de Thu Feb 12 08:47:01 2009 From: marco-oweber at gmx.de (Marc Weber) Date: Thu Feb 12 08:36:45 2009 Subject: [Haskell-cafe] attempt creating alternative logging lib which is actually much slower (?) In-Reply-To: <49885F99.8000305@complete.org> References: <20090201012818.GA11418@gmx.de> <49885F99.8000305@complete.org> Message-ID: <20090212134701.GA3719@gmx.de> > > without removing all all setLevel calls to subloggers? > > Is this desirable? > > I don't understand the problem. If you told hslogger that you didn't > want to hear about stuff about "A", why do you not like that it is > following your instructions? Because taht >>don't want to hear abuot "A"<< could have been set without my knowledge. When trouble shooting a problem it could be handy to just get all messages. But when such a use case arrives I can still patch hslogger. mlog (attempt to create a minimal alternative) ==== I've tried writing another minimal logging system. The idea was driven by adding the possibility to add a handler logging everything not matter what levels are set to different loggers or handlers. The design is simple: keep a list of log handlers and a list of filters. you can add a filter telling that a log message of "A.B" should not be logged. The actual handler function then looks like this log shouldbeLogged logmessage loggername prio = .... So you can still ignore shouldbeLogged easily. However I couldn't even come close to the speed of hslogger even when caching the list of handlers which are supposed to log the message. [some code snippets see end of mail] without any attached handlers: hslogger*[1] : 4ms mlog[2]: 12ms with one default stderr logger (./test 2> /dev/null) hslogger*[1] : 109ms mlog[2]: 150ms [1]: my modified version of hslogger (git://mawercer.de/hslogger) [2]: (git://mawercer.de/mlog) I've tried doing some investigation figuring out why my lib is that much slower but I failed. I noticed that -O2 had an impact on how often the list of generated test cases is run. But that has been all. I don't even use existential types! So I'll shut up and keep using hslogger. Thanks to you John Goerzen for your support. I've learned that I'm very bad at troubleshooting performance. I really thought I could make mlog faster than hslogger*. Using profiling (-P) didn't reveal the source wasting CPU cycles to me. Sincerly Marc Weber [ some code snippets of mlog] the global logger data looks like this: data GlobalLoggerData = GlobalLoggerData { handlers :: M.Map Int LogHandler -- assign a key so that this logger can be removed easily again ,filters :: M.Map Int GlobalFilter -- allow to add global filters -- cache information about which logger accepts what logging data -- String = Priority : loggername , cached :: M.Map String (Bool, [ LogMessageAction ]) } {-# NOINLINE globalLoggerData #-} globalLoggerData :: MVar GlobalLoggerData globalLoggerData = unsafePerformIO $ newMVar $ GlobalLoggerData M.empty M.empty M.empty -- add default handler: addHandler $ LogHandler { accept = \ln p -> True -- which logging events does this log handler accept? ,logAction = \ln p msg doLog -> hPutStrLn stderr msg ,close = return () } From rodrigo.bonifacio at uol.com.br Thu Feb 12 09:03:04 2009 From: rodrigo.bonifacio at uol.com.br (rodrigo.bonifacio) Date: Thu Feb 12 08:52:46 2009 Subject: [Haskell-cafe] HXT + Segmentation Fault Message-ID: <49942c18c8603_59d11555555879b486d@weasel17.tmail> Hi all, I'm trying to parse some XML files using HXT. However, even the examples available on the twiki fail. I guess that the problem is related to some library version, but I'm not sure. The error reported is: "Segmentation fault". Thanks in advance. Compiling with GHC-6.8.3 running on MAC/OS Tiger Packages: Cabal-1.2.4.0, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.2.0, bitset-0.6, bytestring-0.9.0.1.1, cgi-3001.1.6.0, containers-0.1.0.2, curl-1.3.3, directory-1.0.0.1, fgl-5.4.2.0, filepath-1.1.0.0, funsat-0.5.1, ghc-6.8.3, haskell-src-1.0.1.2, haskell98-1.0.1.0, hpc-0.5.0.1, html-1.0.1.1, hxt-8.1.0, (mtl-1.1.0.1), mtl-1.1.0.2, (network-2.2.0.0), network-2.2.0.1, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.1, parse-dimacs-1.2, parsec-2.1.0.1, parsec-3.0.0, pcre-light-0.3.1, pretty-1.0.0.0, process-1.0.0.1, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.1, tagsoup-0.6, template-haskell-2.2.0.0, time-1.1.2.1, unix-2.3.0.1, xhtml-3000.2.0.0 From d at domob.eu Thu Feb 12 09:12:17 2009 From: d at domob.eu (Daniel Kraft) Date: Thu Feb 12 08:57:57 2009 Subject: [Haskell-cafe] Graph library, was: Haskell.org GSoC In-Reply-To: <20090211175126.GF6911@whirlpool.galois.com> References: <20090211175126.GF6911@whirlpool.galois.com> Message-ID: <49942E41.1030408@domob.eu> Don Stewart wrote: >> - Graphs. >> > True graphs (the data structure) are still a weak point! There's no > canonical graph library for Haskell. That sounds interesting... What do you mean by "no canonical" library? Are there already ones but just no "standard" one? But in this case, I don't think adding yet another one will help :D Or isn't there a "real" general graph library? If so, this would be a nice thing to do :) I could look at existing ones (like Boost's graphs) to get a feeling for how an interface might look like and what functionality to implement. BTW, is there some sort of "project hosting" specifically for such Haskell projects? Or should I go with sourceforge (for instance) for developing this, if I gave it a try? Thanks, Daniel From florin.craciun at durham.ac.uk Thu Feb 12 09:22:30 2009 From: florin.craciun at durham.ac.uk (CRACIUN F.) Date: Thu Feb 12 09:12:28 2009 Subject: [Haskell-cafe] TASE 2009 - CALL FOR PAPERS Message-ID: <1C7F51B7A4A4F54389A69794AD79A24D0199C651@EXDUR3.mds.ad.dur.ac.uk> TASE 2009 - Final CALL FOR PAPERS ****************************************** * 3rd IEEE International Symposium on * Theoretical Aspects of Software Engineering * (TASE 2009) * 29-31 July 2009, Tianjin, China * http://www.dur.ac.uk/ieee.tase2009 * * For more information email: IEEE.TASE2009@durham.ac.uk ********************************************************** Large scale software systems and the Internet are of growing concern to academia and industry. This poses new challenges to the various aspects of software engineering, for instance, the reliability of software development, web-oriented software architecture and aspect and object-orientation techniques. As a result, new concepts and methodologies are required to enhance the development of software engineering from theoretical aspects. TASE 2009 is a forum for researchers from academia, industry and government to present ideas, results, and ongoing research on theoretical advances in software engineering. TASE 2009 is the third in a series of conference, sponsored by IEEE CS and IFIP. The first TASE conference was held in Shanghai, China, in June 2007. The second TASE conference was held in Nanjing, China, in June 2008. Topics of Interest: Authors are invited to submit high quality technical papers describing original and unpublished work in all theoretical aspects of software engineering. Topics of interest include, but are not limited to: * Requirements Engineering * Specification and Verification * Program Analysis * Software Testing * Model-Driven Engineering * Software Architectures and Design * Aspect and Object Orientation * Embedded and Real-Time Systems * Software Processes and Workflows * Component-Based Software Engineering * Software Safety, Security and Reliability * Reverse Engineering and Software Maintenance * Service-Oriented Computing * Semantic Web and Web Services * Type System and Theory * Program Logics and Calculus * Dependable Concurrency * Software Model Checking Program Co-Chairs ----------------- Wei-Ngan Chin (National Univ. of Singapore, Singapore) Shengchao Qin (Durham University, UK) Program Committee ----------------- Bernhard Aichernig (Graz University of Technology, Austria) Stefan Andrei (Lamar University, USA) Keijiro Araki (Kyushu University, Japan) Farhad Arbab (CWI and Leiden University, Netherlands) Jonathan Bowen (King's College London, UK) Michael Butler (University of Southampton, UK) Juan Chen (Microsoft Research, USA) Tyng-Ruey Chuang (Academica Sinica, Taiwan) Jim Davies (University of Oxford, UK) Zhenhua Duan (Xidian University, China) Xinyu Feng (Toyota Technological Inst. at Chicago, USA) Dieter Gollmann (Hamburg University of Technology, Germany) Tetsuo Ida (University of Tsukuba, Japan) Radu Iosif (Verimag, CNRS, France) Xuandong Li (Nanjing University, China) Kung-Kiu Lau (University of Manchester, UK) Shaoying Liu (Hosei University, Japan) Dorel Lucanu (University of Iasi, Romania) Tom Maibaum (McMaster University, Canada) Darko Marinov (Univ. of Illinois at Urbana-Champaign, USA) Hong Mei (Peking University, China) Huaikou Miao (Shanghai University, China) Peter Mueller (ETH Zurich, Switzerland) Viet Ha Nguyen (Vietnam National University, Vietnam) Sungwoo Park (Pohang Univ. of Science and Technology, Korea) Corneliu Popeea (MPI-SWS, Germany) Geguang Pu (East China Normal University, China) Zongyan Qiu (Peking University, China) Volker Stolz (UNU/IIST, Macau) Jing Sun (University of Auckland, New Zealand) Jun Sun (National Univ. of Singapore, Singapore) Kenji Taguchi (National Institute of Informatics, Japan) Yih-Kuen Tsay (National Taiwan University, Taiwan) Elizabeth Vidal (San Agustin National University, Peru) Ji Wang (National University of Defense Technology, China) Linzhang Wang (Nanjing University, China) Xianbing Wang (Wuhan University, China) Wang Yi (Uppsala University, Sweden) Jim Woodcock (University of York, UK) Hongyu Zhang (Tsinghua University, China) Jian Zhang (Chinese Academy of Sciences, China) Jianjun Zhao (Shanghai Jiao Tong University, China) Hong Zhu (Oxford Brookes University, UK) Huibiao Zhu (East China Normal University, China) Important Dates: February 20, 2009: Title and abstract submission deadline February 27, 2009: Paper submission deadline April 20, 2009: Acceptance/rejection notification May 11, 2009: Camera-ready version due July 29 - 31, 2009: TASE 2009 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/46c860c5/attachment.htm From barsoap at web.de Thu Feb 12 09:23:19 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 12 09:13:53 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 References: <220e47b40902111519q158009a5r473ca34f40466d60@mail.gmail.com> <20090211233151.GI5978@whirlpool.galois.com> Message-ID: <20090212152319.46533e9f@solaris> Jamie wrote: > > On Thu, 12 Feb 2009, Conrad Parker wrote: > > > 2009/2/12 Don Stewart : > >> Thanks for the analysis, this clarifies things greatly. > >> Feasibility and scope is a big part of how we determine what > >> projects to work on. > > > > I agree that it's beyond the scope of a SoC project. > > > > Rather than H.263 or H.264 I was going to suggest implementation of > > Theora or OMS, both of which avoid the patent issues and have > > publicly available specs: > > > > http://theora.org/doc/Theora.pdf > > http://www.openmediacommons.org/collateral/OMS-video-v0.9.pdf > > > > Scanning those documents should give anyone a fair idea of the > > amount of work involved. My understanding is that OMS is of a > > similar complexity to H.263, and H.264 is more complex than any of > > these. > > > > For Theora playback we've found that the largest CPU load comes from > > colorspace conversion, where the YUV output of the codec needs to be > > converted to RGB for some targets (like Firefox). That is some > > fairly straightforward array processing, and would be a good place > > to start for anyone trying to implement video codecs in Haskell. > > That is great idea and a great seed to plant. Wonder if Theora is as > good as H.264 in terms of video quality and bandwidth usage? > Theora isn't meant to be a H.264 competitor, but a replacement for flash, wmv and the ilk. I dare to guess that it works decent for low bitrates, especially if you're more interested in detecting shapes than skin pores. I guess you just have to do field tests: encoding video on the fly just isn't what general-purpose CPUs are made for, it's the playing field of processors that take SIMD seriously, i.e. GPUs. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From thomas.dubuisson at gmail.com Thu Feb 12 09:34:39 2009 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Thu Feb 12 09:24:19 2009 Subject: [Haskell-cafe] Graph library, was: Haskell.org GSoC In-Reply-To: <49942E41.1030408@domob.eu> References: <20090211175126.GF6911@whirlpool.galois.com> <49942E41.1030408@domob.eu> Message-ID: <4c44d90b0902120634s2da4edah8cef24fab2b47b9@mail.gmail.com> Daniel Kraft asked: > That sounds interesting... What do you mean by "no canonical" library? Are > there already ones but just no "standard" one? But in this case, I don't > think adding yet another one will help :D Or isn't there a "real" general > graph library? My impression is that there is now standard one, but then again I've only used Haskell + a graph library once. > BTW, is there some sort of "project hosting" specifically for such Haskell > projects? Or should I go with sourceforge (for instance) for developing > this, if I gave it a try? Get a community.haskell.org account once you are ready to start a repo, it can not only host your repo (ex: http://community.haskell.org/~tommd/pureMD5) but also allows you to upload packages to hackage.haskell.org. Thomas From barsoap at web.de Thu Feb 12 09:36:08 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 12 09:26:34 2009 Subject: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC References: <20090211175126.GF6911@whirlpool.galois.com> <49942E41.1030408@domob.eu> Message-ID: <20090212153608.0dbb5734@solaris> Daniel Kraft wrote: > Don Stewart wrote: > >> - Graphs. > >> > > True graphs (the data structure) are still a weak point! There's no > > canonical graph library for Haskell. > > That sounds interesting... What do you mean by "no canonical" > library? Are there already ones but just no "standard" one? But in > this case, I don't think adding yet another one will help :D Or > isn't there a "real" general graph library? > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl ? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From benjovi at gmx.net Thu Feb 12 09:42:16 2009 From: benjovi at gmx.net (Benedikt Huber) Date: Thu Feb 12 09:32:04 2009 Subject: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC In-Reply-To: <49942E41.1030408@domob.eu> References: <20090211175126.GF6911@whirlpool.galois.com> <49942E41.1030408@domob.eu> Message-ID: <49943548.3070501@gmx.net> Daniel Kraft schrieb: > Don Stewart wrote: >>> - Graphs. >>> >> True graphs (the data structure) are still a weak point! There's no >> canonical graph library for Haskell. > > That sounds interesting... What do you mean by "no canonical" library? > Are there already ones but just no "standard" one? But in this case, I > don't think adding yet another one will help :D Or isn't there a "real" > general graph library? I would also like to see a project working on a new graph library. Currently, there is at least Data.Graph (just one Module, package containers), based on Array - adjacency lists, and the functional graph library (package fgl). I think a good general purpose graph library is tricky though: - There are lot of variants of graphs (trees, bipartite, acyclic, undirected, simple, edge labeled etc.), hard to find adequate and easy to use abstraction. - There is no single 'best' implementation (mutable vs. unmutable etc.). - Its hard to find good traversal and zipper abstractions, though fgl has some nice ones. - The complexity of algorithms varies greatly depending on the particular kind of graph. Anyway, that's why it is challenging and interesting. > If so, this would be a nice thing to do :) I could look at existing > ones (like Boost's graphs) to get a feeling for how an interface might > look like and what functionality to implement. > > BTW, is there some sort of "project hosting" specifically for such > Haskell projects? Or should I go with sourceforge (for instance) for > developing this, if I gave it a try? code.haskell.org / community.haskell.org provides webspace, trac, mailing-list, darcs. benedikt From leather at cs.uu.nl Thu Feb 12 09:57:31 2009 From: leather at cs.uu.nl (Sean Leather) Date: Thu Feb 12 09:47:11 2009 Subject: [Haskell-cafe] CFP: 5th Haskell Hackathon, April 17-19, Utrecht Message-ID: <3c6288ab0902120657v4b23f18duc8663d365c0e3223@mail.gmail.com> Call for participation: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 5th Haskell Hackathon April 17 - 19, 2009 Utrecht, The Netherlands ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Haskell Hackathon is a collaborative coding festival with a simple focus: build and improve Haskell libraries, tools, and infrastructure. Of course, we have fun doing it, too! All hackers are welcome to visit and work on various Haskell-related projects. You decide what you want to work on! Lists of projects and concerted efforts are collected on the Hac5 website. == General Information == Information about the projects as well as practicalities such as traveling, accommodation, etc. is available from the Hac5 website: http://haskell.org/haskellwiki/Hac5 == Registration == Please register by following the instructions on the registration page: http://haskell.org/haskellwiki/Hac5/Register Once you've registered, please add your info to the attendees self-organizing page: http://haskell.org/haskellwiki/Hac5/Attendees If you are looking to share costs or want to meet up prior to the Hackathon with other attendees, feel free to organize via the Attendees wiki page or join the Hackathon IRC channel on freenode: #haskell-hac5 == Organizers == Andres L?h, Utrecht University (UU) Jos? Pedro Magalh?es, UU Sean Leather, UU Eelco Lempsink, UU + Tupil Chris Eidhof, UU + Tupil ... and more ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/ab3e0364/attachment.htm From ketil at malde.org Thu Feb 12 09:57:52 2009 From: ketil at malde.org (Ketil Malde) Date: Thu Feb 12 09:47:35 2009 Subject: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC In-Reply-To: <49943548.3070501@gmx.net> (Benedikt Huber's message of "Thu\, 12 Feb 2009 15\:42\:16 +0100") References: <20090211175126.GF6911@whirlpool.galois.com> <49942E41.1030408@domob.eu> <49943548.3070501@gmx.net> Message-ID: <871vu3snwv.fsf@malde.org> Benedikt Huber writes: > I would also like to see a project working on a new graph library. [...] > I think a good general purpose graph library is tricky though: And please, let us have a library that is scalable! This means there should be one (or several) benchmark application(s) that do non-trivial work on graphs of non-trivial sizes. -k -- If I haven't seen further, it is by standing in the footprints of giants From g9ks157k at acme.softbase.org Thu Feb 12 10:04:25 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 09:54:11 2009 Subject: [Haskell-cafe] Haskell.org GSoC In-Reply-To: <20090212081515.GA8010@whirlpool.galois.com> References: <200902120912.49554.g9ks157k@acme.softbase.org> <20090212081515.GA8010@whirlpool.galois.com> Message-ID: <200902121604.25717.g9ks157k@acme.softbase.org> Am Donnerstag, 12. Februar 2009 09:15 schrieben Sie: > g9ks157k: > > Am Mittwoch, 11. Februar 2009 18:51 schrieb Don Stewart: > > > For example, if all the haddocks on hackage.org were a wiki, and > > > interlinked, every single package author would benefit, as would all > > > users. > > > > You mean, everyone should be able to mess about with my documentation? > > This would be similar to give everyone commit rights to my repositories > > or allow everyone to edit the code of my published libraries. What is the > > good thing about that? > > No one said anything about unrestricted commit rights ... we're not > crazy ... what if it were more like, say, RWH's wiki .. where comments > go to editors to encorporate ... ?Wiki? sounds like you could edit the documentation of the package. This wouldn?t necessarily mean that these modifications are written back to the repository. However, it would men that Hackage is not longer showing the real documentation of the repository but what others made of it by wiki editing. I would dislike this. However, a commenting system like that of RWH is a very different thing. People would not edit the actual documentation (so the documentation is not a wiki). People would just add comments. This might be a good idea. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Feb 12 10:07:06 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 09:56:50 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC In-Reply-To: <7ca3f0160902120149y9eccbcfn3630c04923f71448@mail.gmail.com> References: <7ca3f0160902120149y9eccbcfn3630c04923f71448@mail.gmail.com> Message-ID: <200902121607.07016.g9ks157k@acme.softbase.org> Am Donnerstag, 12. Februar 2009 10:49 schrieb Luke Palmer: > Something like AnnoCPAN would be a good middle-ground here; i.e. > differentiate between "official" package documentation and user > annotations, but make them both visible. And give visitors of the Hackage website the choice to not see the comments at all. Best wishes, Wolfgang From g9ks157k at acme.softbase.org Thu Feb 12 10:10:21 2009 From: g9ks157k at acme.softbase.org (Wolfgang Jeltsch) Date: Thu Feb 12 10:00:05 2009 Subject: [Haskell-cafe] Graph library, was: Haskell.org GSoC In-Reply-To: <4c44d90b0902120634s2da4edah8cef24fab2b47b9@mail.gmail.com> References: <49942E41.1030408@domob.eu> <4c44d90b0902120634s2da4edah8cef24fab2b47b9@mail.gmail.com> Message-ID: <200902121610.21966.g9ks157k@acme.softbase.org> Am Donnerstag, 12. Februar 2009 15:34 schrieb Thomas DuBuisson: > Daniel Kraft asked: > > That sounds interesting... What do you mean by "no canonical" library? > > Are there already ones but just no "standard" one? But in this case, I > > don't think adding yet another one will help :D Or isn't there a "real" > > general graph library? > > My impression is that there is now standard one, but then again I've > only used Haskell + a graph library once. > > > BTW, is there some sort of "project hosting" specifically for such > > Haskell projects? Or should I go with sourceforge (for instance) for > > developing this, if I gave it a try? > > Get a community.haskell.org account once you are ready to start a > repo, it can not only host your repo (ex: > http://community.haskell.org/~tommd/pureMD5) but also allows you to > upload packages to hackage.haskell.org. I already have a Hackage account. Can this be readily used as a community.haskell.org account? If not, what if I get a community account. Do I have two accounts for Hackage access then? Best wishes, Wolfgang From tracy.wadleigh at gmail.com Thu Feb 12 10:19:31 2009 From: tracy.wadleigh at gmail.com (Tracy Wadleigh) Date: Thu Feb 12 10:11:14 2009 Subject: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC In-Reply-To: <49943548.3070501@gmx.net> References: <20090211175126.GF6911@whirlpool.galois.com> <49942E41.1030408@domob.eu> <49943548.3070501@gmx.net> Message-ID: Benedikt writes: > I think a good general purpose graph library is tricky though: > - There are lot of variants of graphs (trees, bipartite, acyclic, > undirected, simple, edge labeled etc.), hard to find adequate and easy to > use abstraction. > - There is no single 'best' implementation (mutable vs. unmutable etc.). > - Its hard to find good traversal and zipper abstractions, though fgl has > some nice ones. > - The complexity of algorithms varies greatly depending on the particular > kind of graph. > Anyway, that's why it is challenging and interesting. Hear, hear! >From what I can tell, fgl is the closest thing I've seen to a usable remotely-general-purpose graph library in any language. With all apologies to Siek, et al., the boost graph library is exceedingly complex, to the point of being unusable (one man's opinion) to all but the most ardent lovers of C++ template metaprogramming. That's no knock on its designers, it's just that the graph problem provides an exceptionally challenging tension between managing complexity and providing acceptable performance--on top of trying to achieve respectable generality. It seems to me that anyone who aspires to author a Haskell graph library that can be regarded as canonical really ought to first know fgl inside and out, and probably ought to consider extending that library, vs. starting from scratch. In fact, it was my current work with non-trivial graph problems that ultimately led me to justify switching to using Haskell for my day job a couple of months ago (after having investigated and abandoned other possible solutions in other languages that would have been a much easier sell to my higher-ups). So I have a pressing professional interest on hearing others weigh in on this topic, and particularly on the benefits/shortcomings of fgl. I'd especially like to hear from Martin Erwig on this topic. Martin? You listening? --Tracy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/25205331/attachment.htm From d at domob.eu Thu Feb 12 10:27:06 2009 From: d at domob.eu (Daniel Kraft) Date: Thu Feb 12 10:12:44 2009 Subject: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC In-Reply-To: <49943548.3070501@gmx.net> References: <20090211175126.GF6911@whirlpool.galois.com> <49942E41.1030408@domob.eu> <49943548.3070501@gmx.net> Message-ID: <49943FCA.4050507@domob.eu> Benedikt Huber wrote: > I would also like to see a project working on a new graph library. > Currently, there is at least Data.Graph (just one Module, package > containers), based on Array - adjacency lists, and the functional graph > library (package fgl). I don't know those, but "functional graph library" suggests it is meant to be something like what we're discussing here (and this is also what Google returns for Haskell + graph library). What's the problem with it or in which way is it different? > I think a good general purpose graph library is tricky though: > - There are lot of variants of graphs (trees, bipartite, acyclic, > undirected, simple, edge labeled etc.), hard to find adequate and easy > to use abstraction. Well, while an undirected tree / acyclic graph can obviously be represented as a "tree structure", all the others would resolve around having nodes and for each node a list of edges to neighbouring nodes; at least concept-wise, wouldn't they? Then one could build an abstraction on top of this with a node class able to name neighbouring nodes or something like that to get rid of a fixed representation (and allow working on graphs constructed on the fly as opposed to being stored in memory), but I think this would be the basic way to go. Everything else (whatever could benefit from a substantial different representation) could go in a seperate library or specialisation. Or do I miss something here? (No expert with regards to graphs and their use-cases yet.) > code.haskell.org / community.haskell.org > provides webspace, trac, mailing-list, darcs. Thanks for the pointer! Yours, Daniel From dons at galois.com Thu Feb 12 10:34:56 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 12 10:25:25 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090212103629.58f12bc3.Malcolm.Wallace@cs.york.ac.uk> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <20090212103629.58f12bc3.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20090212153456.GC9850@whirlpool.galois.com> Malcolm.Wallace: > Gwern Branwen wrote: > > > * A GUI interface to Darcs > > (http://hackage.haskell.org/trac/summer-of-code/ticket/17); > > I wonder whether darcs ought to apply to be a GSoC mentoring > organisation in its own right this year? It would be good to attempt to > get a couple of dedicated slots for darcs only (in addition to any that > haskell.org may get). > > > * Optimization of containers > > (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would > > benefit every Haskell user very quickly. > > This was Jamie Brandon's GSoC project last year, and although that is > not yet in wide use, I suspect there is very little extra effort needed > to get it out there into the average Haskell user's hands. > > > * XMonad compositing support > > (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). > > Maybe XMonad should also think about whether to apply to GSoC in their > own right as a mentoring org? As a project, it seems to have a lot of > life independent of the Haskell community. I agree: the big projects can stand on their own. -- Don From dons at galois.com Thu Feb 12 10:48:34 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 12 10:39:03 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <220e47b40902120412n20b09a08va14d7dced3cc9e3f@mail.gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <20090212103629.58f12bc3.Malcolm.Wallace@cs.york.ac.uk> <220e47b40902120412n20b09a08va14d7dced3cc9e3f@mail.gmail.com> Message-ID: <20090212154834.GE9850@whirlpool.galois.com> gtener: > On Thu, Feb 12, 2009 at 11:36, Malcolm Wallace > wrote: > > Gwern Branwen wrote: > > > >> * A GUI interface to Darcs > >> (http://hackage.haskell.org/trac/summer-of-code/ticket/17); > > > > I wonder whether darcs ought to apply to be a GSoC mentoring > > organisation in its own right this year? ?It would be good to attempt to > > get a couple of dedicated slots for darcs only (in addition to any that > > haskell.org may get). > > > >> * Optimization of containers > >> (http://hackage.haskell.org/trac/summer-of-code/ticket/1549). Would > >> benefit every Haskell user very quickly. > > > > This was Jamie Brandon's GSoC project last year, and although that is > > not yet in wide use, I suspect there is very little extra effort needed > > to get it out there into the average Haskell user's hands. > > > >> * XMonad compositing support > >> (http://hackage.haskell.org/trac/summer-of-code/ticket/1548). > > > > Maybe XMonad should also think about whether to apply to GSoC in their > > own right as a mentoring org? ?As a project, it seems to have a lot of > > life independent of the Haskell community. > > > > By the way: I think it may be worthwile to contact Google to point out > the recent growth of Haskell community. I don't know on what basis > they assign the slots, but it may be beneficial to do so. In the past it has been based on scale of mentors, proposals and students. If we're under-allocated, that can sometimes be addressed, however. -- Don From benjovi at gmx.net Thu Feb 12 11:20:33 2009 From: benjovi at gmx.net (Benedikt Huber) Date: Thu Feb 12 11:10:16 2009 Subject: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC In-Reply-To: <49943FCA.4050507@domob.eu> References: <20090211175126.GF6911@whirlpool.galois.com> <49942E41.1030408@domob.eu> <49943548.3070501@gmx.net> <49943FCA.4050507@domob.eu> Message-ID: <49944C51.4060501@gmx.net> Daniel Kraft schrieb: > Benedikt Huber wrote: >> I would also like to see a project working on a new graph library. >> Currently, there is at least Data.Graph (just one Module, package >> containers), based on Array - adjacency lists, and the functional >> graph library (package fgl). > > I don't know those, but "functional graph library" suggests it is meant > to be something like what we're discussing here (and this is also what > Google returns for Haskell + graph library). What's the problem with it > or in which way is it different? (I hope the following explanation is correct, apologies otherwise) The fgl is build upon the concept of Inductive Graphs, described in Martin Erwig's "Inductive Graphs and Functional Graph Algorithms" (http://web.engr.oregonstate.edu/~erwig/papers/InductiveGraphs_JFP01.pdf). The basic idea is that for traversals, you don't mark visited notes, but decompose the graph like that: > (nodeContext,restGraph) = matchAny graph > {- or -} > (nodeContext,restGraph) = match nodeId graph This is in some sense 'more functional' than relying on tables for marking visited nodes. DFS e.g. is implemented as (comments for clarification) > xdfsWith :: Graph gr => (Context a b -> [Node]) -> -- neighbours > (Context a b -> c) -> -- compute result > [Node] -> -- start > gr a b -> -- the graph > [c] -- result list > xdfsWith _ _ [] _ = [] -- no more nodes to visit > xdfsWith _ _ _ g | isEmpty g = [] -- empty graph > xdfsWith d f (v:vs) g = > case match v g of -- decompose graph > -- compute result, add neighbours to todo list, recursive dfs > (Just c,g') -> f c:xdfsWith d f (d c++vs) g' > -- Couldn't find node, continue > (Nothing,g') -> xdfsWith d f vs g' There's certainly more to say about the fgl, just read the paper. Now for many applications this is fine, and the fgl is indeed a fine library. But obviously there is some overhead in matching, and the API is sometimes a little difficult to understand. And it's not the only way to do graph algorithms in haskell. >> I think a good general purpose graph library is tricky though: >> - There are lot of variants of graphs (trees, bipartite, acyclic, >> undirected, simple, edge labeled etc.), hard to find adequate and easy >> to use abstraction. > > Well, while an undirected tree / acyclic graph can obviously be > represented as a "tree structure" Acyclic graphs are not tree-like. The point about trees is that sometimes it is useful to view them as general purpose graphs, so they should also be represented in a graph library. However, in my opionion the library should also have a specialized representation of trees, as most algorithms are much simpler (Like containers' Data.Tree). > all the others would resolve around > having nodes and for each node a list of edges to neighbouring nodes; at > least concept-wise, wouldn't they? From an implementation point of view, yes, adjacency lists, as arrays or trees, and matrices. But there is a wide range of possibilities for algorithms, from monadic implementations (using ST/UArray) to inductive graphs. For efficient algorithms, somethink like Array's freeze/thaw seems to be a good idea, too. benedikt From jwlato at gmail.com Thu Feb 12 11:49:50 2009 From: jwlato at gmail.com (John Lato) Date: Thu Feb 12 11:39:32 2009 Subject: [Haskell-cafe] Re: Google Summer of Code 2009 Message-ID: <9979e72e0902120849t7a3c9083n5f958f0ce23e1a3d@mail.gmail.com> Johan Tibell wrote: > On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa wrote: >> Do we already have enough information to turn >> http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized >> package? I think Iteratees may prove themselves as useful as >> ByteStrings. > > I still haven't figured out what the "correct" definition of Iteratee > would look like. The Iteratee code that Oleg wrote seems to have the > structure of some kind of "two level" monad. I think that's the reason > for the frequent occurrences of >>== and liftI in the code. There > seems to be some things we yet have to discover about Iteratees. > I concur. I've recently been involved with several discussions on this topic, and there are some issues that remain. The "two level monad" part doesn't bother me, but I think the type should be slightly more abstract and I'm not sure of the best way to do so. IMO liftI is used more because of Oleg's particular style of coding than anything else. I don't think it need be common in user code, although it may be more efficient. I think that, if a GSOC project were to focus on Iteratees, it would need to look at issues like these. I can't judge as to whether this is an appropriate amount of work for GSOC, however simply packaging and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely of too small a scope. John Lato From coreyoconnor at gmail.com Thu Feb 12 11:55:26 2009 From: coreyoconnor at gmail.com (Corey O'Connor) Date: Thu Feb 12 11:45:05 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: <1234440765.4025.25.camel@localhost> References: <1234349332.5238.246.camel@localhost> <1234440765.4025.25.camel@localhost> Message-ID: On Thu, Feb 12, 2009 at 4:12 AM, Duncan Coutts wrote: > As Wolfgang mentioned, you may choose to follow the common package > versioning policy. > > http://haskell.org/haskellwiki/Package_versioning_policy > > We are planning to develop tool support for this. To let packages > explicitly opt-in and then we can hold such packages to their promise. > We can also advise authors about what form of version constraints they > should use for dependencies on packages that follow the PVP. Thanks for the documentation! That's helpful. I'll change the libraries I maintain to follow this policy. None of them would work well for a date-based scheme. Thanks again, Corey O'Connor From cristiano.paris at gmail.com Thu Feb 12 11:55:49 2009 From: cristiano.paris at gmail.com (Cristiano Paris) Date: Thu Feb 12 11:45:30 2009 Subject: [Haskell-cafe] Delimited continuations: please comment Message-ID: Hi, I'm experimenting with delimited continuations in the effort to understand how they work and when it's convenient to use them. Consider this piece of code (install the CC-delcont before running it): ---- {-# LANGUAGE NoMonomorphismRestriction #-} import Control.Monad.CC import Control.Monad.Trans -- why do I have to import this? data Monad m => Susp m a b = Stop | Susp (a -> m (Susp m a b)) job = reset $ \p -> let askMsg = shift p $ \k -> return $ Susp $ k . return in do x <- askMsg liftIO $ putStrLn $ "x was " ++ show x y <- askMsg liftIO $ putStrLn $ "y was " ++ show y return Stop scheduler j = do Susp nj <- j Susp nj <- nj "Hello!" nj "World!" return undefined main = runCCT $ scheduler job ---- which produces the output: ---- [paris@bagend haskell]$ runhaskell dc.hs x was "Hello!" y was "World!" [paris@bagend haskell]$ ---- The goal of this is to have a test-case implementation of the system call mechanism found in operating systems, like the one described by Oleg in (see page 3): http://okmij.org/ftp/papers/context-OS.pdf In effect, this is a bit different from the syscall service routine described by Oleg, as the scheduler function reacts in different ways for subsequent calls (the first time feeds "Hello!", the second one "World!", in a nice monad style). Yet, I liked the separation between the scheduler and the job, which are two completely different values and which I tried to keep. As this is (almost) my first time using delconts, could you provide feedback, comments, opinions about my piece of code and the topic in general (convenience, performances, alternatives and so on)? Thank you, Cristiano From gwern0 at gmail.com Thu Feb 12 12:00:27 2009 From: gwern0 at gmail.com (Gwern Branwen) Date: Thu Feb 12 11:50:08 2009 Subject: [Haskell-cafe] Re: Google Summer of Code 2009 In-Reply-To: <9979e72e0902120849t7a3c9083n5f958f0ce23e1a3d@mail.gmail.com> References: <9979e72e0902120849t7a3c9083n5f958f0ce23e1a3d@mail.gmail.com> Message-ID: On Thu, Feb 12, 2009 at 11:49 AM, John Lato wrote: > Johan Tibell wrote: >> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa wrote: >>> Do we already have enough information to turn >>> http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized >>> package? I think Iteratees may prove themselves as useful as >>> ByteStrings. >> >> I still haven't figured out what the "correct" definition of Iteratee >> would look like. The Iteratee code that Oleg wrote seems to have the >> structure of some kind of "two level" monad. I think that's the reason >> for the frequent occurrences of >>== and liftI in the code. There >> seems to be some things we yet have to discover about Iteratees. >> > > I concur. I've recently been involved with several discussions on > this topic, and there are some issues that remain. The "two level > monad" part doesn't bother me, but I think the type should be slightly > more abstract and I'm not sure of the best way to do so. IMO liftI is > used more because of Oleg's particular style of coding than anything > else. I don't think it need be common in user code, although it may > be more efficient. > > I think that, if a GSOC project were to focus on Iteratees, it would > need to look at issues like these. I can't judge as to whether this > is an appropriate amount of work for GSOC, however simply packaging > and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely > of too small a scope. > > John Lato I agree. Just packaging and cabalizing something is likely not a SoC-worthy project. (This is why the 'cabalize Wash' suggestion will never make it, for example.) In general, cabalizing seems to be either pretty easy (most everything I've cabalized) or next to impossible (gtk2hs, ghc). The former are too trivial for SoC, and the latter likely are impossible without more development of Cabal - at which point it'd be more correct to call it a Cabal SoC and not a cabalizing SoC. -- gwern From dons at galois.com Thu Feb 12 12:12:53 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 12 12:03:13 2009 Subject: [Haskell-cafe] Re: Google Summer of Code 2009 In-Reply-To: References: <9979e72e0902120849t7a3c9083n5f958f0ce23e1a3d@mail.gmail.com> Message-ID: <20090212171253.GA10195@whirlpool.galois.com> gwern0: > On Thu, Feb 12, 2009 at 11:49 AM, John Lato wrote: > > Johan Tibell wrote: > >> On Thu, Feb 12, 2009 at 2:12 AM, Felipe Lessa wrote: > >>> Do we already have enough information to turn > >>> http://okmij.org/ftp/Haskell/Iteratee/ into a nice, generic, cabalized > >>> package? I think Iteratees may prove themselves as useful as > >>> ByteStrings. > >> > >> I still haven't figured out what the "correct" definition of Iteratee > >> would look like. The Iteratee code that Oleg wrote seems to have the > >> structure of some kind of "two level" monad. I think that's the reason > >> for the frequent occurrences of >>== and liftI in the code. There > >> seems to be some things we yet have to discover about Iteratees. > >> > > > > I concur. I've recently been involved with several discussions on > > this topic, and there are some issues that remain. The "two level > > monad" part doesn't bother me, but I think the type should be slightly > > more abstract and I'm not sure of the best way to do so. IMO liftI is > > used more because of Oleg's particular style of coding than anything > > else. I don't think it need be common in user code, although it may > > be more efficient. > > > > I think that, if a GSOC project were to focus on Iteratees, it would > > need to look at issues like these. I can't judge as to whether this > > is an appropriate amount of work for GSOC, however simply packaging > > and cabal-izing Oleg's Iteratee work (or Johan's, or my own) is likely > > of too small a scope. > > > > John Lato > > I agree. Just packaging and cabalizing something is likely not a > SoC-worthy project. (This is why the 'cabalize Wash' suggestion will > never make it, for example.) In general, cabalizing seems to be either > pretty easy (most everything I've cabalized) or next to impossible > (gtk2hs, ghc). The former are too trivial for SoC, and the latter > likely are impossible without more development of Cabal - at which > point it'd be more correct to call it a Cabal SoC and not a cabalizing > SoC. Yes, "cabalising" was more of a priority when we only had 10 libraries :) So in general, think hard about missing capabilities in Haskell: * tools * libraries * infrastructure that benefit the broadest number of Haskell users or developers. Another route is to identify a clear niche where Haskell could leap ahead of the competition, with a small investment. -- Don From bugfact at gmail.com Thu Feb 12 12:43:45 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 12 12:35:48 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? Message-ID: Haskell seems to have pretty strong support for dynamic casting using Data.Typeable and Data.Dynamic. All kinds of funky dynamic programming seems to be possible with these "hacks". Is this considered as being as bad as - say - unsafePerformIO? What kind of evil is lurking here? Cheers, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/776c1fec/attachment.htm From dons at galois.com Thu Feb 12 12:49:45 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 12 12:40:02 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? In-Reply-To: References: Message-ID: <20090212174945.GB10195@whirlpool.galois.com> bugfact: > Haskell seems to have pretty strong support for dynamic casting using > Data.Typeable and Data.Dynamic. > > All kinds of funky dynamic programming seems to be possible with these > "hacks". > > Is this considered as being as bad as - say - unsafePerformIO? What kind of > evil is lurking here? Inefficiencies and runtime errors? -- Don From barsoap at web.de Thu Feb 12 12:58:18 2009 From: barsoap at web.de (Achim Schneider) Date: Thu Feb 12 12:49:04 2009 Subject: [Haskell-cafe] Re: Is using Data.Dynamic considered a no-go? References: Message-ID: <20090212185818.320bf563@solaris> Peter Verswyvelen wrote: > Haskell seems to have pretty strong support for dynamic casting using > Data.Typeable and Data.Dynamic. > All kinds of funky dynamic programming seems to be possible with these > "hacks". > > Is this considered as being as bad as - say - unsafePerformIO? What > kind of evil is lurking here? > Uncertainty. Noone on #haskell seems to know how Typeable-dispatches compare to pattern matching wrt. performance, and I was either too lazy or too uninterested to measure it myself. Combined with a custom type class and existentials, they safe you from writing catch-all ADTs and thus give code flexibility (and conciseness), while retaining static typing, modulo unexhaustive pattern warnings. This is how XHB uses Typeable, and, IMHO, it's a Good Thing. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. From lennart at augustsson.net Thu Feb 12 13:04:58 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Feb 12 12:54:39 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? In-Reply-To: References: Message-ID: They are not unsafe in the way unsafePerformIO is, but I regard them as a last resort in certain situations. Still, in those situations they are very useful. -- Lennart 2009/2/12 Peter Verswyvelen : > Haskell seems to have pretty strong support for dynamic casting using > Data.Typeable and Data.Dynamic. > All kinds of funky dynamic programming seems to be possible with these > "hacks". > Is this considered as being as bad as - say - unsafePerformIO? What kind of > evil is lurking here? > Cheers, > Peter > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > From wasserman.louis at gmail.com Thu Feb 12 13:18:27 2009 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Thu Feb 12 13:08:08 2009 Subject: [Haskell-cafe] Re: Graph library, was: Haskell.org GSoC Message-ID: fgl uses pretty much the most beautiful way of abstracting graphs I've seen; a brief review: type Context a b -- a collected representation of a vertex's number, label, and all information on edges going into and out of that vertex match :: Graph gr => Node -> gr a b -> (Maybe (Context a b), gr a b) -- if a vertex is in the graph, extracts its adjacency information in a Context and returns the graph without that vertex (&) :: DynGraph gr => Context a b -> gr a b -> gr a b -- melds a vertex and its adjacency information into the graph I've been doing a huge amount of messing around with graph algorithms recently, and this inductive style of graph querying and modification make several algorithms far more intuitive than most imperative implementations I've seen. In addition, both of these lend themselves well to use in a State monad. Take the following code to extract the connected component of a vertex in an undirected graph: extractComponentM :: DynGraph gr => gr a b -> Node -> State (gr a b) (gr a b) extractComponentM partialComponent v = State (match v) >>= maybe (return partialComponent) expandContext where expandContext cxt = liftM (cxt &) (foldM extractComponentM partialComponent (neighbors' cxt)) extractComponent :: DynGraph gr => gr a b -- the initial graph -> Node -- the node whose component to find -> (gr a b, gr a b) -- the original graph without the component, and the component extractComponent g v = runState (extractComponentM empty v) g That's far more compact -- and intuitive to someone familiar with both fgl and the State monad -- than a standard connected-component finder in an imperative language, speaking as someone who wrote code along these lines imperatively for several years. (Fun fact: I've been working on a nice encapsulation of priority queues as monad transformers to make other common graph algorithms both efficient and make them this pretty to read, too. Any thoughts on that would be appreciated.) I strongly feel that fgl, though it could be improved in some areas, makes a better truly general graph abstraction than anything else I've seen. Areas that could specifically be improved include the stuff that uses LRTrees, and other stuff that isn't especially intuitive, elegant, or even efficient in fgl's implementation. Louis Wasserman wasserman.louis@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/8461f111/attachment.htm From haskell at datakids.org Thu Feb 12 13:19:39 2009 From: haskell at datakids.org (Jamie) Date: Thu Feb 12 13:09:21 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <20090212152319.46533e9f@solaris> References: <220e47b40902111519q158009a5r473ca34f40466d60@mail.gmail.com> <20090211233151.GI5978@whirlpool.galois.com> <20090212152319.46533e9f@solaris> Message-ID: On Thu, 12 Feb 2009, Achim Schneider wrote: > Jamie wrote: > >>> For Theora playback we've found that the largest CPU load comes from >>> colorspace conversion, where the YUV output of the codec needs to be >>> converted to RGB for some targets (like Firefox). That is some >>> fairly straightforward array processing, and would be a good place >>> to start for anyone trying to implement video codecs in Haskell. >> >> That is great idea and a great seed to plant. Wonder if Theora is as >> good as H.264 in terms of video quality and bandwidth usage? >> > Theora isn't meant to be a H.264 competitor, but a replacement for > flash, wmv and the ilk. I dare to guess that it works decent for low > bitrates, especially if you're more interested in detecting shapes than > skin pores. I guess you just have to do field tests: encoding video on > the fly just isn't what general-purpose CPUs are made for, it's the > playing field of processors that take SIMD seriously, i.e. GPUs. Signers (deaf people or "hearing" people who know sign language) naturally put strong emphasize on smooth video quality (i.e. at least 25 fps with no blurries/fuzzy). I use Mirial Softphone (to me, a best H.323/SIP video softphone so far, run on Windows) and it runs very nicely and perfectly on my Dell 1 GHz Centrind Duo laptop in both H.263 and H.264 (I even tried H.264 at 704x576 at 30 FPS and it works real nice). However Mirial sure did display "CPU overload" message time to time on my Samsung NC10 netbook especially using H.264 and result in pixelization of video frames. So no problem at all with my Dell laptop but kind of borderline on Atom 1.6Ghz netbook. I agree it would surely help offload the CPU work when there is hardware encoder/decoder present in GPU. I see more and more GPU now support H.264 decoder which is nice. Jamie From jonathanccast at fastmail.fm Thu Feb 12 13:24:21 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 12 13:16:52 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? In-Reply-To: References: Message-ID: <1234463061.22830.4.camel@jcchost> On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote: > They are not unsafe in the way unsafePerformIO is, I beg permission to demur: newtype Unsafe alpha = Unsafe { unUnsafe :: alpha } instance Typeable (Unsafe alpha) where typeOf _ = typeOf () pseudoSafeCoerce :: alpha -> Maybe beta pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe Note that pseudoSafeCoerce = Just . unsafeCoerce > but I regard them > as a last resort in certain situations. > Still, in those situations they are very useful. But I would agree with both of these. As long as you *derive* Typeable. jcc From lennart at augustsson.net Thu Feb 12 13:53:01 2009 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Feb 12 13:45:21 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? In-Reply-To: <1234463061.22830.4.camel@jcchost> References: <1234463061.22830.4.camel@jcchost> Message-ID: You're quite right. You should only be allowed to derive Typeable. (Which could be arranged by hiding the methods of typeable.) On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast wrote: > On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote: >> They are not unsafe in the way unsafePerformIO is, > > I beg permission to demur: > > newtype Unsafe alpha = Unsafe { unUnsafe :: alpha } > instance Typeable (Unsafe alpha) where > typeOf _ = typeOf () > > pseudoSafeCoerce :: alpha -> Maybe beta > pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe > > Note that > > pseudoSafeCoerce = Just . unsafeCoerce > >> but I regard them >> as a last resort in certain situations. >> Still, in those situations they are very useful. > > But I would agree with both of these. As long as you *derive* Typeable. > > jcc > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From wren at freegeek.org Thu Feb 12 14:22:26 2009 From: wren at freegeek.org (wren ng thornton) Date: Thu Feb 12 14:12:06 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902120852.04699.g9ks157k@acme.softbase.org> <987d172d0902120016i725dcb2bgc0ed2d18abeb9029@mail.gmail.com> Message-ID: <499476F2.6040907@freegeek.org> Matthew Elder wrote: > would love to see this. > > basic features first i suppose. here are some of my ideas: > > 1. browseable change history with preview pane (preview pane shows > diff and patch message) Extending this idea, I'd like to see some "3D" visualization of the file hierarchy and the partial hierarchy for the patch/diff being considered. That is: not just per-file diff views, but also per-project views. It'd also be nice to see this with more than one layer of diff at a time so you can get an idea about potential conflicts and what parts of the project are getting heavily changed. Felipe Lessa wrote: > 2009/2/12 Matthew Elder : > > would love to see this. > > > > basic features first i suppose. here are some of my ideas: > > meld-like diff view would be great too. > http://meld.sourceforge.net/ I especially like the highlighting of what has changed within the line, rather than diff's usual answer of "durr, it's different". -- Live well, ~wren From bugfact at gmail.com Thu Feb 12 14:55:35 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 12 14:45:15 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? In-Reply-To: References: <1234463061.22830.4.camel@jcchost> Message-ID: It would be interesting to see when you HAVE to use dynamics, e.g. when no other solution is possible in Haskell... Right now if I use it, it feels that I'm doing so because I'm too new to Haskell. On Thu, Feb 12, 2009 at 7:53 PM, Lennart Augustsson wrote: > You're quite right. You should only be allowed to derive Typeable. > (Which could be arranged by hiding the methods of typeable.) > > On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast > wrote: > > On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote: > >> They are not unsafe in the way unsafePerformIO is, > > > > I beg permission to demur: > > > > newtype Unsafe alpha = Unsafe { unUnsafe :: alpha } > > instance Typeable (Unsafe alpha) where > > typeOf _ = typeOf () > > > > pseudoSafeCoerce :: alpha -> Maybe beta > > pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe > > > > Note that > > > > pseudoSafeCoerce = Just . unsafeCoerce > > > >> but I regard them > >> as a last resort in certain situations. > >> Still, in those situations they are very useful. > > > > But I would agree with both of these. As long as you *derive* Typeable. > > > > jcc > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/feefc285/attachment.htm From dons at galois.com Thu Feb 12 15:40:43 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 12 15:31:16 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? In-Reply-To: References: <1234463061.22830.4.camel@jcchost> Message-ID: <20090212204043.GB10706@whirlpool.galois.com> Notably, extensible exceptions use dynamics, in conjunction with type classes and existentials. A number of solutions to the 'expression problem' involve dynamics. bugfact: > It would be interesting to see when you HAVE to use dynamics, e.g. when no > other solution is possible in Haskell... > > Right now if I use it, it feels that I'm doing so because I'm too new to > Haskell. > > > On Thu, Feb 12, 2009 at 7:53 PM, Lennart Augustsson > wrote: > > You're quite right. You should only be allowed to derive Typeable. > (Which could be arranged by hiding the methods of typeable.) > > On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast > wrote: > > On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote: > >> They are not unsafe in the way unsafePerformIO is, > > > > I beg permission to demur: > > > > newtype Unsafe alpha = Unsafe { unUnsafe :: alpha } > > instance Typeable (Unsafe alpha) where > > typeOf _ = typeOf () > > > > pseudoSafeCoerce :: alpha -> Maybe beta > > pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe > > > > Note that > > > > pseudoSafeCoerce = Just . unsafeCoerce > > > >> but I regard them > >> as a last resort in certain situations. > >> Still, in those situations they are very useful. > > > > But I would agree with both of these. As long as you *derive* Typeable. > > > > jcc > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe@haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jwlato at gmail.com Thu Feb 12 18:08:02 2009 From: jwlato at gmail.com (John Lato) Date: Thu Feb 12 17:57:42 2009 Subject: [Haskell-cafe] can't figure out a type In-Reply-To: References: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> <9979e72e0902110934o4ec4f55cn97c81c28143806e0@mail.gmail.com> Message-ID: <9979e72e0902121508t21797981yd2216aa82b56f5af@mail.gmail.com> Hi Job, thanks for replying. Thanks for explaining this. I never really thought about the implications of kinds on type classes, and it's all much more clear now. The first version, with only one parameter, almost works, except that some instances (e.g. uvector, storablevector) have further class restrictions on the element types. I believe these are impossible to express without the element parameter included in the Chunkable class. This was a big disappointment, because otherwise it would be possible in Haskell98. This is also a problem with the map implementation. Since the typeclass restriction exists for both el and el', I don't see how it's possible to type cMap without including el' in the class. I don't want to do that, so I guess the map function will just need to be provided outside the class instance. It does turn out that I don't need either fundeps or type families at least. Thanks to everyone who replied; it really helped me clarify my thoughts on this implementation. Cheers, John Lato On Wed, Feb 11, 2009 at 8:28 PM, Job Vranish wrote: > I think what you probably want is something like this: > > class Chunckable c where > cLength :: c el -> Int > cHead :: c el -> Maybe el > cMap :: (a -> b) -> c a -> c b > > instance Chunckable [] where > cLength [] = 0 > cLength (x:xs) = 1 + cLength xs > > cHead [] = Nothing > cHead (x:xs) = Just x > > cMap = map > > a = [4, 7, 3, 8] > test1 = cLength a > test2 = cHead a > test3 = cMap (Just) a > > > The class does not actually need the second type parameter. > You can actually use all sorts of extra type variables in the type > signatures in class declarations as long as all your instances are > polymorphic across those types (not sure if that's the precise > terminology). Basically, as long as cLength, cHead and cMap do the > same thing regardless of what el is, then you don't need to have el as > a type parameter to the class. > > Now if you _do_ want to have cLength, etc do something else depending > el, then things get more complicated. Maybe something like this: > > class Chunckable2 c el where > cLength2 :: c el -> Int > cHead2 :: c el -> Maybe el > cMap2 :: (Chunckable2 c el') => (el -> el') -> c el -> c el' > > instance Chunckable2 [] Int where > cLength2 [] = 0 > cLength2 (x:xs) = 1 + cLength xs > > cHead2 [] = Nothing > cHead2 (x:xs) = Just x > > cMap2 = map > > instance Chunckable2 [] Float where > cLength2 [] = 0 > cLength2 (x:xs) = 1 + cLength xs > > cHead2 [] = Nothing > cHead2 (x:xs) = Just x > > cMap2 f xs = [] > > test4 = cMap2 (fromIntegral) (a::[Int]) :: [Float] > test5 = cMap2 (id) ([3.0, 4.0, 1.0]::[Float]) :: [Float] > > Note that if you want things to work like this, functional > dependencies wont help you out (as they don't make sense in this case) > > > > On Wed, Feb 11, 2009 at 12:34 PM, John Lato wrote: >> Hi Job, >> >> Thanks for answering. What I'm trying to do is probably very simple, >> and I think the biggest problem is that I don't fully understand kinds >> yet. >> >> Here's an example instance: >> >> instance Chunkable [a] a where >> cmap = map >> --etc. >> >> In the class I wrote, c has kind * (e.g. [a]), but then I don't see >> how to write a suitable map function. For that, I would want c to >> have kind * -> *. Unfortunately then I don't know to write the >> others. >> >> Would I have to do something with c having kind (* -> *) ? >> >> class Chunkable2 c el where >> cLength :: c el -> Int >> cHead :: c el -> Maybe el >> cMap :: (el -> el') -> c el -> c el' >> >> Sincerely, >> John >> >> On Wed, Feb 11, 2009 at 5:12 PM, Job Vranish wrote: >>> What do you mean by parameterized over a different type? >>> will c have a kind of * -> * ? I don't think it has to be for what you >>> want to work, but the idea of "same instance" will go out the window. >>> >>> Do you have a small usage example? >>> >>> >>> On Wed, Feb 11, 2009 at 11:52 AM, John Lato wrote: >>>> Hello, >>>> >>>> I'm working on some code like the following: >>>> >>>>> class Chunkable c el | c -> el where >>>>> cLength :: c -> Int >>>>> cHead :: c -> Maybe el >>>> >>>> I want to be able to map over this type, like this: >>>> >>>>> cMap :: Chunkable c' el' => (el -> el') -> c -> c' >>>> >>>> but this isn't quite right. c' shouldn't be any instance of >>>> Chunkable, it should be the same instance except parameterized over a >>>> different type. Another approach would be something like: >>>> >>>> class (Functor c) => Chunkable c el >>>> ... >>>> >>>> except that's not right either. I think c has the wrong kind to be a >>>> Functor instance. >>>> >>>> I expect there's something very basic I'm missing. Could anyone point >>>> in the proper direction of how to do this? Can this be expressed with >>>> associated types, perhaps? >>>> >>>> Thanks, >>>> >>>> John Lato >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe@haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >> > From bugfact at gmail.com Thu Feb 12 18:17:52 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Thu Feb 12 18:07:32 2009 Subject: [Haskell-cafe] Race condition possible? Message-ID: Consider the following code stamp v x = do t <- getCurrentTime putMVar v (x,t) Is it possible - with GHC - that a thread switch happens after the t <- getCurrentTime and the putMVar v (x,t)? If so, how would it be possible to make sure that the operation of reading the current time and writing the pair to the MVar is an "atomic" operation, in the sense that no thread switch can happen between the two? Would this require STM? Thanks again for sharing your wisdom with me :) Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/3d599d37/attachment.htm From jwlato at gmail.com Thu Feb 12 18:22:03 2009 From: jwlato at gmail.com (John Lato) Date: Thu Feb 12 18:11:43 2009 Subject: [Haskell-cafe] can't figure out a type In-Reply-To: <9979e72e0902121508t21797981yd2216aa82b56f5af@mail.gmail.com> References: <9979e72e0902110852k541f81d3y1d550a162cc17751@mail.gmail.com> <9979e72e0902110934o4ec4f55cn97c81c28143806e0@mail.gmail.com> <9979e72e0902121508t21797981yd2216aa82b56f5af@mail.gmail.com> Message-ID: <9979e72e0902121522v26b05460gd6e6c2bcf23db755@mail.gmail.com> One clarification. That is, I could write map with the cNull/cCons implementation already suggested, but I couldn't do: instance Chunkable Data.StorableVector.Vector el where ... cMap = Data.StorableVector.map which is what I really want. However, I just realized that I should be able to use the cNull cCons implementation with a rewrite rule for this case, so I think I'm happy now. John On Thu, Feb 12, 2009 at 11:08 PM, John Lato wrote: > Hi Job, thanks for replying. > > Thanks for explaining this. I never really thought about the > implications of kinds on type classes, and it's all much more clear > now. > > The first version, with only one parameter, almost works, except that > some instances (e.g. uvector, storablevector) have further class > restrictions on the element types. I believe these are impossible to > express without the element parameter included in the Chunkable class. > This was a big disappointment, because otherwise it would be > possible in Haskell98. > > This is also a problem with the map implementation. Since the > typeclass restriction exists for both el and el', I don't see how it's > possible to type cMap without including el' in the class. I don't > want to do that, so I guess the map function will just need to be > provided outside the class instance. It does turn out that I don't > need either fundeps or type families at least. > > Thanks to everyone who replied; it really helped me clarify my > thoughts on this implementation. > > Cheers, > John Lato > > On Wed, Feb 11, 2009 at 8:28 PM, Job Vranish wrote: >> I think what you probably want is something like this: >> >> class Chunckable c where >> cLength :: c el -> Int >> cHead :: c el -> Maybe el >> cMap :: (a -> b) -> c a -> c b >> >> instance Chunckable [] where >> cLength [] = 0 >> cLength (x:xs) = 1 + cLength xs >> >> cHead [] = Nothing >> cHead (x:xs) = Just x >> >> cMap = map >> >> a = [4, 7, 3, 8] >> test1 = cLength a >> test2 = cHead a >> test3 = cMap (Just) a >> >> >> The class does not actually need the second type parameter. >> You can actually use all sorts of extra type variables in the type >> signatures in class declarations as long as all your instances are >> polymorphic across those types (not sure if that's the precise >> terminology). Basically, as long as cLength, cHead and cMap do the >> same thing regardless of what el is, then you don't need to have el as >> a type parameter to the class. >> >> Now if you _do_ want to have cLength, etc do something else depending >> el, then things get more complicated. Maybe something like this: >> >> class Chunckable2 c el where >> cLength2 :: c el -> Int >> cHead2 :: c el -> Maybe el >> cMap2 :: (Chunckable2 c el') => (el -> el') -> c el -> c el' >> >> instance Chunckable2 [] Int where >> cLength2 [] = 0 >> cLength2 (x:xs) = 1 + cLength xs >> >> cHead2 [] = Nothing >> cHead2 (x:xs) = Just x >> >> cMap2 = map >> >> instance Chunckable2 [] Float where >> cLength2 [] = 0 >> cLength2 (x:xs) = 1 + cLength xs >> >> cHead2 [] = Nothing >> cHead2 (x:xs) = Just x >> >> cMap2 f xs = [] >> >> test4 = cMap2 (fromIntegral) (a::[Int]) :: [Float] >> test5 = cMap2 (id) ([3.0, 4.0, 1.0]::[Float]) :: [Float] >> >> Note that if you want things to work like this, functional >> dependencies wont help you out (as they don't make sense in this case) >> >> >> >> On Wed, Feb 11, 2009 at 12:34 PM, John Lato wrote: >>> Hi Job, >>> >>> Thanks for answering. What I'm trying to do is probably very simple, >>> and I think the biggest problem is that I don't fully understand kinds >>> yet. >>> >>> Here's an example instance: >>> >>> instance Chunkable [a] a where >>> cmap = map >>> --etc. >>> >>> In the class I wrote, c has kind * (e.g. [a]), but then I don't see >>> how to write a suitable map function. For that, I would want c to >>> have kind * -> *. Unfortunately then I don't know to write the >>> others. >>> >>> Would I have to do something with c having kind (* -> *) ? >>> >>> class Chunkable2 c el where >>> cLength :: c el -> Int >>> cHead :: c el -> Maybe el >>> cMap :: (el -> el') -> c el -> c el' >>> >>> Sincerely, >>> John >>> >>> On Wed, Feb 11, 2009 at 5:12 PM, Job Vranish wrote: >>>> What do you mean by parameterized over a different type? >>>> will c have a kind of * -> * ? I don't think it has to be for what you >>>> want to work, but the idea of "same instance" will go out the window. >>>> >>>> Do you have a small usage example? >>>> >>>> >>>> On Wed, Feb 11, 2009 at 11:52 AM, John Lato wrote: >>>>> Hello, >>>>> >>>>> I'm working on some code like the following: >>>>> >>>>>> class Chunkable c el | c -> el where >>>>>> cLength :: c -> Int >>>>>> cHead :: c -> Maybe el >>>>> >>>>> I want to be able to map over this type, like this: >>>>> >>>>>> cMap :: Chunkable c' el' => (el -> el') -> c -> c' >>>>> >>>>> but this isn't quite right. c' shouldn't be any instance of >>>>> Chunkable, it should be the same instance except parameterized over a >>>>> different type. Another approach would be something like: >>>>> >>>>> class (Functor c) => Chunkable c el >>>>> ... >>>>> >>>>> except that's not right either. I think c has the wrong kind to be a >>>>> Functor instance. >>>>> >>>>> I expect there's something very basic I'm missing. Could anyone point >>>>> in the proper direction of how to do this? Can this be expressed with >>>>> associated types, perhaps? >>>>> >>>>> Thanks, >>>>> >>>>> John Lato >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe@haskell.org >>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> >>>> >>> >> > From lemming at henning-thielemann.de Thu Feb 12 18:25:50 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu Feb 12 18:15:32 2009 Subject: [Haskell-cafe] Looking for pointfree version In-Reply-To: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> References: <40B04645-DA4E-4B9C-9FD2-6BEC2241E1C4@cs.tcd.ie> Message-ID: On Mon, 9 Feb 2009, Edsko de Vries wrote: > Hi, > > Is there a nice way to write > > down :: Focus -> [Focus] > down p = concat [downPar p, downNew p, downTrans p] down = concat . sequence [downPar, downNew, downTrans] given the Reader like Monad instance of ((->) a). From dons at galois.com Thu Feb 12 18:26:25 2009 From: dons at galois.com (Don Stewart) Date: Thu Feb 12 18:16:41 2009 Subject: [Haskell-cafe] Race condition possible? In-Reply-To: References: Message-ID: <20090212232625.GL10706@whirlpool.galois.com> bugfact: > Consider the following code > > stamp v x = do > t <- getCurrentTime > putMVar v (x,t) > > Is it possible - with GHC - that a thread switch happens after the t <- > getCurrentTime and the putMVar v (x,t)? Yes. if 't' is heap allocated, there could be a context switch. > If so, how would it be possible to make sure that the operation of reading the > current time and writing the pair to the MVar is an "atomic" operation, in the > sense that no thread switch can happen between the two? Would this require STM? > Using 'atomically' and TVars in STM, perhaps? Else, use withMVar? Or a modifyMVar in IO? -- Don From newhoggy at gmail.com Thu Feb 12 18:34:42 2009 From: newhoggy at gmail.com (John Ky) Date: Thu Feb 12 18:24:22 2009 Subject: [Haskell-cafe] Type families not as useful over functions Message-ID: Hi Haskell Cafe, I tried using type families over functions, but when I try it complains that the two lines marked conflict with each other. class Broadcast a where type Return a broadcast :: a -> Return a instance Broadcast [a -> r] where type Return [a -> r] = a -> [r] -- Conflict! broadcast fs a = [] instance Broadcast [a -> b -> r] where type Return [a -> b -> r] = a -> b -> [r] -- Conflict! broadcast fs a b = [] Given that in Haskell, every function of n+1 arguments is also a function of n arguments, this is likely the cause of the conflict. In this case, currying is not my friend. Unfortunately this means I'm stuck with numbered function names: bc0 :: [r] -> [r] bc0 rs = rs bc1 :: [a -> r] -> a -> [r] bc1 [] a = [] bc1 (r:rs) a = (r a):bc1 rs a bc2 rs a b = rs `bc1` a `bc1` b bc3 rs a b c = rs `bc1` a `bc1` b `bc1` c -- etc Cheers, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/fa43a6c1/attachment-0001.htm From devriese at cs.tcd.ie Thu Feb 12 18:36:19 2009 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Thu Feb 12 18:26:00 2009 Subject: [Haskell-cafe] Another point-free question (>>=, join, ap) Message-ID: <20090212233619.GA4781@netsoc.tcd.ie> Hi, I can desugar do x' <- x f x' as x >>= \x -> f x' which is clearly the same as x >>= f However, now consider do x' <- x y' <- y f x' y' desugared, this is x >>= \x -> y >>= \y' -> f x' y' I can simplify the second half to x >>= \x -> y >>= f x' but now we are stuck. I feel it should be possible to write something like x ... y ... f or perhaps f ... x ... y the best I could come up with was join $ return f `ap` x `ap` y which is not terrible but quite as easy as I feel this should be. Any hints? Edsko From wagner.andrew at gmail.com Thu Feb 12 18:39:33 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Feb 12 18:29:12 2009 Subject: [Haskell-cafe] Another point-free question (>>=, join, ap) In-Reply-To: <20090212233619.GA4781@netsoc.tcd.ie> References: <20090212233619.GA4781@netsoc.tcd.ie> Message-ID: Check out liftM2. It's almost what you want. On Thu, Feb 12, 2009 at 6:36 PM, Edsko de Vries wrote: > Hi, > > I can desugar > > do x' <- x > f x' > > as > > x >>= \x -> f x' > > which is clearly the same as > > x >>= f > > However, now consider > > do x' <- x > y' <- y > f x' y' > > desugared, this is > > x >>= \x -> y >>= \y' -> f x' y' > > I can simplify the second half to > > x >>= \x -> y >>= f x' > > but now we are stuck. I feel it should be possible to write something like > > x ... y ... f > > or perhaps > > f ... x ... y > > the best I could come up with was > > join $ return f `ap` x `ap` y > > which is not terrible but quite as easy as I feel this should be. Any > hints? > > Edsko > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/a8bbf213/attachment.htm From miguelimo38 at yandex.ru Thu Feb 12 18:42:43 2009 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Thu Feb 12 18:32:31 2009 Subject: [Haskell-cafe] Type families not as useful over functions In-Reply-To: References: Message-ID: <98BF7C39-508C-4AB4-90E5-4E49CAB0E858@yandex.ru> What do you need that for? Can you live with infixl |$| (|$|) :: [a -> r] -> a -> [r] fs |$| x = map ($ x) fs and, instead of "broadcast fs a b" use fs |$| a |$| b ? On 13 Feb 2009, at 02:34, John Ky wrote: > Hi Haskell Cafe, > > I tried using type families over functions, but when I try it > complains that the two lines marked conflict with each other. > > class Broadcast a where > type Return a > broadcast :: a -> Return a > > instance Broadcast [a -> r] where > type Return [a -> r] = a -> [r] -- Conflict! > broadcast fs a = [] > > instance Broadcast [a -> b -> r] where > type Return [a -> b -> r] = a -> b -> [r] -- Conflict! > broadcast fs a b = [] > > Given that in Haskell, every function of n+1 arguments is also a > function of n arguments, this is likely the cause of the conflict. > > In this case, currying is not my friend. > > Unfortunately this means I'm stuck with numbered function names: > > bc0 :: [r] -> [r] > bc0 rs = rs > > bc1 :: [a -> r] -> a -> [r] > bc1 [] a = [] > bc1 (r:rs) a = (r a):bc1 rs a > > bc2 rs a b = rs `bc1` a `bc1` b > > bc3 rs a b c = rs `bc1` a `bc1` b `bc1` c > > -- etc > > Cheers, > > -John > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jonathanccast at fastmail.fm Thu Feb 12 18:44:35 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 12 18:37:05 2009 Subject: [Haskell-cafe] Type families not as useful over functions In-Reply-To: References: Message-ID: <1234482275.22830.44.camel@jcchost> On Fri, 2009-02-13 at 10:34 +1100, John Ky wrote: > Hi Haskell Cafe, > > I tried using type families over functions, but when I try it > complains that the two lines marked conflict with each other. > > class Broadcast a where > type Return a > broadcast :: a -> Return a > instance Broadcast [a -> r] where > type Return [a -> r] = a -> [r] -- Conflict! > broadcast fs a = [] > > instance Broadcast [a -> b -> r] where > type Return [a -> b -> r] = a -> b -> [r] -- Conflict! > broadcast fs a b = [] > > Given that in Haskell, every function of n+1 arguments is also a > function of n arguments, this is likely the cause of the conflict. This solution is somewhat in-extensible in the ultimate result type (r, in your code); if the number of types r can take on is limited, it should work well, though. For expository purposes, I assume that r is always Int: -- | Conal Elliot's semantic editor combinator argument argument :: (a -> a') -> (a -> b) -> (a' -> b) argument f g = g . f class Broadcast a where type Return a broadcast :: [a] -> Return a instance Broadcast Int where type Return Int = [Int] broadcast ns = ns instance Broadcast r => Broadcast (a -> r) where type Return (a -> r) = a -> Return r broadcast fs x = (map.argument) (const x) fs jcc From newhoggy at gmail.com Thu Feb 12 18:49:19 2009 From: newhoggy at gmail.com (John Ky) Date: Thu Feb 12 18:38:58 2009 Subject: [Haskell-cafe] Type families not as useful over functions In-Reply-To: <98BF7C39-508C-4AB4-90E5-4E49CAB0E858@yandex.ru> References: <98BF7C39-508C-4AB4-90E5-4E49CAB0E858@yandex.ru> Message-ID: Hi Miguel, That's a nice way of writing it. Thanks, -John On Fri, Feb 13, 2009 at 10:42 AM, Miguel Mitrofanov wrote: > What do you need that for? > > Can you live with > > infixl |$| > (|$|) :: [a -> r] -> a -> [r] > fs |$| x = map ($ x) fs > > and, instead of "broadcast fs a b" use > > fs |$| a |$| b > > ? > > > On 13 Feb 2009, at 02:34, John Ky wrote: > > Hi Haskell Cafe, >> >> I tried using type families over functions, but when I try it complains >> that the two lines marked conflict with each other. >> >> class Broadcast a where >> type Return a >> broadcast :: a -> Return a >> >> instance Broadcast [a -> r] where >> type Return [a -> r] = a -> [r] -- Conflict! >> broadcast fs a = [] >> >> instance Broadcast [a -> b -> r] where >> type Return [a -> b -> r] = a -> b -> [r] -- Conflict! >> broadcast fs a b = [] >> >> Given that in Haskell, every function of n+1 arguments is also a function >> of n arguments, this is likely the cause of the conflict. >> >> In this case, currying is not my friend. >> >> Unfortunately this means I'm stuck with numbered function names: >> >> bc0 :: [r] -> [r] >> bc0 rs = rs >> >> bc1 :: [a -> r] -> a -> [r] >> bc1 [] a = [] >> bc1 (r:rs) a = (r a):bc1 rs a >> >> bc2 rs a b = rs `bc1` a `bc1` b >> >> bc3 rs a b c = rs `bc1` a `bc1` b `bc1` c >> >> -- etc >> >> Cheers, >> >> -John >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/4e1bfcf5/attachment.htm From jeremy at n-heptane.com Thu Feb 12 19:04:45 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Feb 12 18:54:27 2009 Subject: [Haskell-cafe] Another point-free question (>>=, join, ap) In-Reply-To: <20090212233619.GA4781@netsoc.tcd.ie> References: <20090212233619.GA4781@netsoc.tcd.ie> Message-ID: <87prhn9p7m.wl%jeremy@n-heptane.com> Hello, You could do: (f =<< x) =<< y ? - jeremy At Thu, 12 Feb 2009 23:36:19 +0000, Edsko de Vries wrote: > > Hi, > > I can desugar > > do x' <- x > f x' > > as > > x >>= \x -> f x' > > which is clearly the same as > > x >>= f > > However, now consider > > do x' <- x > y' <- y > f x' y' > > desugared, this is > > x >>= \x -> y >>= \y' -> f x' y' > > I can simplify the second half to > > x >>= \x -> y >>= f x' > > but now we are stuck. I feel it should be possible to write something like > > x ... y ... f > > or perhaps > > f ... x ... y > > the best I could come up with was > > join $ return f `ap` x `ap` y > > which is not terrible but quite as easy as I feel this should be. Any hints? > > Edsko > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From jonathanccast at fastmail.fm Thu Feb 12 18:59:06 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 12 18:57:16 2009 Subject: [Haskell-cafe] Another point-free question (>>=, join, ap) In-Reply-To: <20090212233619.GA4781@netsoc.tcd.ie> References: <20090212233619.GA4781@netsoc.tcd.ie> Message-ID: <1234483146.22830.51.camel@jcchost> On Thu, 2009-02-12 at 23:36 +0000, Edsko de Vries wrote: > Hi, > > I can desugar > > do x' <- x > f x' > > as > > x >>= \x -> f x' > > which is clearly the same as > > x >>= f > > However, now consider > > do x' <- x > y' <- y > f x' y' > > desugared, this is > > x >>= \x -> y >>= \y' -> f x' y' > > I can simplify the second half to > > x >>= \x -> y >>= f x' > > but now we are stuck. I feel it should be possible to write something like > > x ... y ... f > > or perhaps > > f ... x ... y > > the best I could come up with was > > join $ return f `ap` x `ap` y > > which is not terrible but quite as easy as I feel this should be. Any hints? Copying a bit of Applicative style, you could say join $ f `liftM` x `ap` y I've thought it would be nice to have something like app :: Monad m => m (a -> m b) -> m a -> m b app af ax = join $ af `ap` ax in the standard library. Then you could simplify to f `liftM` x `app` y I think that's as simple as you're going to get. For more arguments, say f `liftM` x `ap` y `app` z The rule is: first application operator is `liftM` (or <$> --- I always define Applicative instances for my monads); last application operator is `app`; the operators in-between are all `ap`. I think that's a pretty straight-forward rule to follow. jcc From newhoggy at gmail.com Thu Feb 12 19:15:32 2009 From: newhoggy at gmail.com (John Ky) Date: Thu Feb 12 19:05:10 2009 Subject: [Haskell-cafe] Type families not as useful over functions In-Reply-To: <1234482275.22830.44.camel@jcchost> References: <1234482275.22830.44.camel@jcchost> Message-ID: Hi Johnaton, Ah yes. That makes sense. Is there a way to define type r to be all types except functions? -John On Fri, Feb 13, 2009 at 10:44 AM, Jonathan Cast wrote: > On Fri, 2009-02-13 at 10:34 +1100, John Ky wrote: > > Hi Haskell Cafe, > > > > I tried using type families over functions, but when I try it > > complains that the two lines marked conflict with each other. > > > > class Broadcast a where > > type Return a > > broadcast :: a -> Return a > > > instance Broadcast [a -> r] where > > type Return [a -> r] = a -> [r] -- Conflict! > > broadcast fs a = [] > > > > instance Broadcast [a -> b -> r] where > > type Return [a -> b -> r] = a -> b -> [r] -- Conflict! > > broadcast fs a b = [] > > > > Given that in Haskell, every function of n+1 arguments is also a > > function of n arguments, this is likely the cause of the conflict. > > This solution is somewhat in-extensible in the ultimate result type (r, > in your code); if the number of types r can take on is limited, it > should work well, though. For expository purposes, I assume that r is > always Int: > > -- | Conal Elliot's semantic editor combinator argument > argument :: (a -> a') -> (a -> b) -> (a' -> b) > argument f g = g . f > > class Broadcast a where > type Return a > broadcast :: [a] -> Return a > instance Broadcast Int where > type Return Int = [Int] > broadcast ns = ns > instance Broadcast r => Broadcast (a -> r) where > type Return (a -> r) = a -> Return r > broadcast fs x = (map.argument) (const x) fs > > jcc > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/23be026d/attachment.htm From jeremy at n-heptane.com Thu Feb 12 19:27:15 2009 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Thu Feb 12 19:16:58 2009 Subject: [Haskell-cafe] Another point-free question (>>=, join, ap) In-Reply-To: <87prhn9p7m.wl%jeremy@n-heptane.com> References: <20090212233619.GA4781@netsoc.tcd.ie> <87prhn9p7m.wl%jeremy@n-heptane.com> Message-ID: <87ocx79o64.wl%jeremy@n-heptane.com> oops, I take that back. It only appears to work if you are sloppy: x :: (Monad m) => m a x = undefined y :: (Monad m) => m b y = undefined g :: (Monad m) => a -> b -> m c g = undefined ex1 :: (Monad m) :: m c ex1 = (g =<< x) =<< y But, if you try to pin down the types you find it only works because they are not all the same Monad m. a :: (Int -> Int) a = return 1 b :: Maybe Int b = Just 2 h :: Int -> Int -> Maybe Int h a b = return (a + b) ex5 :: Maybe Int ex5 = (h =<< a) =<< b :) j. At Thu, 12 Feb 2009 18:04:45 -0600, Jeremy Shaw wrote: > > Hello, > > You could do: > > (f =<< x) =<< y > > ? > > - jeremy > > > > At Thu, 12 Feb 2009 23:36:19 +0000, > Edsko de Vries wrote: > > > > Hi, > > > > I can desugar > > > > do x' <- x > > f x' > > > > as > > > > x >>= \x -> f x' > > > > which is clearly the same as > > > > x >>= f > > > > However, now consider > > > > do x' <- x > > y' <- y > > f x' y' > > > > desugared, this is > > > > x >>= \x -> y >>= \y' -> f x' y' > > > > I can simplify the second half to > > > > x >>= \x -> y >>= f x' > > > > but now we are stuck. I feel it should be possible to write something like > > > > x ... y ... f > > > > or perhaps > > > > f ... x ... y > > > > the best I could come up with was > > > > join $ return f `ap` x `ap` y > > > > which is not terrible but quite as easy as I feel this should be. Any hints? > > > > Edsko > > _______________________________________________ > > 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 From ok at cs.otago.ac.nz Thu Feb 12 19:30:04 2009 From: ok at cs.otago.ac.nz (Richard O'Keefe) Date: Thu Feb 12 19:20:23 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <200902120848.14765.g9ks157k@acme.softbase.org> References: <200902111340.27082.g9ks157k@acme.softbase.org> <801FE99D-FE1C-4B19-9D85-D2B10C85F447@cs.otago.ac.nz> <200902120848.14765.g9ks157k@acme.softbase.org> Message-ID: <7B91BE81-6099-42F7-BF50-568CA748AC1B@cs.otago.ac.nz> On 12 Feb 2009, at 8:48 pm, Wolfgang Jeltsch wrote: > > I don?t understand this. The way which works is conversion from > MathML to TeX. > So your suggestion would be to use MathML as the source language. > But this is > obviously not what you suggest. I?m confused. It's explicit enough in the original message: Use "a substantial chunk of MathML" in "a TeX-parseable syntax". > > If you want to use a subset of TeX in Haddock comments, how would > you render them on a webpage? I didn't say "a subset of TeX" but a subset of >>MathML<<. MathML is two things: a set of labelled trees with some sort of semantics, and a representation of those trees as XML. Anything that can be written as ... can also be written as \X[b]{...} with a reasonable amount of care. (Not necessarily the same X and b, of course, and ... would be recursively transformed.) Let's take this example from the web. x2 + 4⁢x + 4 Step 1. Rule that letters c stand for \mi{c} unless otherwise quoted. Rule that digit sequences d stand for \mn{d} unless otherwise quoted. Rule that normal operators x stand for \mo{x} unless otherwise quoted. Rule that x^y stands for \msup{x}{y}. Rule that x_y stands for \msub{x}{y}. Step 2. Introduce names for (some) things MathML has, like ⁢ and TeX does not. Step 3. Write a checker that enforces the conventions. By step 3, we have the ability to write \mathml{\mrow{x^2 + \mrow{4\itimes x} + 4}} and have LaTeX process it directly. The advantage of this stuff is that you can put it in your technical papers. Why bother? Because of the checker. (I do not have such a program. This is a design sketch on a tablecloth, not to be taken any more seriously than that.) Why not use MathML? (La)TeX macros spring to mind as a good reason... Not having to use XML as another. Step 4. Based on the checker, write a program to convert this notation to MathML. MathML was, after all, designed for machines to write and read; it is not practical for people to write and it couldn't be called even remotely readable by its best friend. That makes it a pretty appalling choice for something to write in Haddock comments in source files. By step 4, you have something you can check better than standard TeX, something you can cut and paste between TeX papers and Haddock documentation without making the source code unreadable, and at the same time something that can be converted to MathML any time you want. By the way, I wonder very much how much semantics people _are_ putting into their MathML? The INEX consortium of people doing XML-based information retrieval have run into the problem that there is very little semantic markup out there, so for getting semantics out XML is *in practice as yet* little or no advance on plain text. Even with an equation editor, writing formulas on a computer is enough work that I'd expect people to do the minimum they need for the immediate taste, even using MathML. I don't have a body of MathML to examine, so I make no empirical claim here, I just raise the question. From jonathanccast at fastmail.fm Thu Feb 12 19:33:23 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 12 19:25:54 2009 Subject: [Haskell-cafe] Haddock Markup In-Reply-To: <7B91BE81-6099-42F7-BF50-568CA748AC1B@cs.otago.ac.nz> References: <200902111340.27082.g9ks157k@acme.softbase.org> <801FE99D-FE1C-4B19-9D85-D2B10C85F447@cs.otago.ac.nz> <200902120848.14765.g9ks157k@acme.softbase.org> <7B91BE81-6099-42F7-BF50-568CA748AC1B@cs.otago.ac.nz> Message-ID: <1234485203.22830.63.camel@jcchost> On Fri, 2009-02-13 at 13:30 +1300, Richard O'Keefe wrote: > Let's take this example from the web. > x2 + > 4⁢x + > 4 NB: This example is *precisely* why I will never adopt MathML as an authoring format. Bowing and scraping at the alter of W3C is not worth using such a terrible syntax, not ever. (Indented, that's x 2 + 4 ⁢ x + 4 Which is still unforgivably horrible. I *think* it's trying to say $x^2 + 4x + 4$, but I'm not confident even of that. I'm also unconvinced it's actually easier to parse than $x^2 + 4x + 4$.) jcc From himself at poczta.nom.pl Thu Feb 12 19:42:01 2009 From: himself at poczta.nom.pl (Andrzej Jaworski) Date: Thu Feb 12 19:32:23 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <91945673619847EF9424CA81804B8DFE@bzdryk> > If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing Here is an idea that if done right might bootstrap Haskell real world applications with the help of greed and adrenaline:-) The ignition: (0) Bind Haskell to an automatic trading platform [API] (1) write real-time streamer and stock scanner. [PType] should offer more than was demonstrated in [F#] (2) Join [apps] from any angle (3) Consider a [DSL] for data analysis or write an [EasyLanguage] [API] http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc [F#] http://channel9.msdn.com/pdc2008/TL11/ [PType] http://research.nii.ac.jp/~hu/pub/aplas04-xu.pdf [apps] http://www.interactivebrokers.com/en/general/poll/ibconsultants.php?accept_disclaimer=T&ib_entity=llc [DSL] http://www.cc.gatech.edu/~saswat/research/one.pdf [EasyLanguage] https://www.tradestation.com/support/books/pdf/EL_Essentials.pdf https://www.tradestation.com/support/books/pdf/EL_FunctionsAndReservedWords_Ref.pdf From himself at poczta.nom.pl Thu Feb 12 19:42:13 2009 From: himself at poczta.nom.pl (Andrzej Jaworski) Date: Thu Feb 12 19:32:37 2009 Subject: [Haskell-cafe] Google Summer of Code 2009 References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> Message-ID: > If you have ideas for student projects that you think would benefit the > Haskell community, now is the time to start discussing them on mailing Here is an idea that if done right might bootstrap Haskell real world applications with the help of greed and adrenaline:-) The ignition: (0) Bind Haskell to an automatic trading platform [API] (1) write real-time streamer and stock scanner. [PType] should offer more than was demonstrated in [F#] (2) Join [apps] from any angle (3) Consider a [DSL] for data analysis or write an [EasyLanguage] [API] http://www.interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc [F#] http://channel9.msdn.com/pdc2008/TL11/ [PType] http://research.nii.ac.jp/~hu/pub/aplas04-xu.pdf [apps] http://www.interactivebrokers.com/en/general/poll/ibconsultants.php?accept_disclaimer=T&ib_entity=llc [DSL] http://www.cc.gatech.edu/~saswat/research/one.pdf [EasyLanguage] https://www.tradestation.com/support/books/pdf/EL_Essentials.pdf https://www.tradestation.com/support/books/pdf/EL_FunctionsAndReservedWords_Ref.pdf From jonathanccast at fastmail.fm Thu Feb 12 19:40:49 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Thu Feb 12 19:33:19 2009 Subject: [Haskell-cafe] Type families not as useful over functions In-Reply-To: References: <1234482275.22830.44.camel@jcchost> Message-ID: <1234485649.22830.75.camel@jcchost> On Fri, 2009-02-13 at 11:15 +1100, John Ky wrote: > Hi Johnaton, > > Ah yes. That makes sense. Is there a way to define type r to be all > types except functions? Not without overlapping instances. I *think* if you turn on {-# LANGUAGE OverlappingInstances #-} then instance Broadcast r where type Result = [r] broadcast xn = xn should do what you want (instance resolution delayed until r has a type constructor at top level; this instance selected if no other instance is in scope --- should be equivalent to r not a function type unless someone else defines an instance!); but I know that's not a pretty way of doing things. jcc From ccshan at post.harvard.edu Thu Feb 12 19:55:20 2009 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Thu Feb 12 19:50:10 2009 Subject: [Haskell-cafe] Re: Can this be done? References: <4992E9DA.6020703@libero.it> <4993BBEE.9070603@freegeek.org> Message-ID: wren ng thornton wrote in article <4993BBEE.9070603@freegeek.org> in gmane.comp.lang.haskell.cafe: > It's ugly, but one option is to just reify your continuations as an ADT, > where there are constructors for each function and fields for each > variable that needs closing over. Serializing that ADT should be simple > (unless some of those functions are higher-order in which case you run > into the same problem of how to serialize the function arguments). In > GHC's STG machine this representation shouldn't have much overhead, > though it does require the developer to do the compiler's job. FWIW, this idea is called defunctionalization (due to Reynolds), and it works for higher-order functions as well (because you can defunctionalize those function arguments in the same way). People in many fields put a lot of effort into turning their programs into state machines... -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig "Attending a mathematics lecture is like walking through a thunderstorm at night. Most of the time you are lost, wet and miserable but at rare intervals there is a flash of lightening and the whole countryside is lit up." - Tom Koerner From matt at mattelder.org Thu Feb 12 20:06:07 2009 From: matt at mattelder.org (Matthew Elder) Date: Thu Feb 12 19:55:45 2009 Subject: [Haskell-cafe] Re: Google Summer of Code 2009 In-Reply-To: <987d172d0902121705g7ec26a41hf3929d6805fd9d03@mail.gmail.com> References: <9979e72e0902120849t7a3c9083n5f958f0ce23e1a3d@mail.gmail.com> <20090212171253.GA10195@whirlpool.galois.com> <987d172d0902121705g7ec26a41hf3929d6805fd9d03@mail.gmail.com> Message-ID: <987d172d0902121706h3111b6f0g5592a7b5bcb59265@mail.gmail.com> > So in general, think hard about missing capabilities in Haskell: > > * tools > * libraries > * infrastructure > > that benefit the broadest number of Haskell users or developers. > > Another route is to identify a clear niche where Haskell could leap > ahead of the competition, with a small investment. > > -- Don > One capability I would love to see as a SoC project is the ability to generate javascript (a small subset) as an additional output target from ghc. Something like this was already done with yhc herebut if it could be ported to GHC and cabalized, this would really be a boon to the web dev community; javascript is quickly becoming one of the most predominant languages used for GUI creation (mainly via the web). -- Need somewhere to put your code? http://patch-tag.com Want to build a webapp? http://happstack.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/4d746dae/attachment.htm From kyagrd at gmail.com Thu Feb 12 20:49:28 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Thu Feb 12 20:39:20 2009 Subject: [Haskell-cafe] Re: Type families not as useful over functions In-Reply-To: References: Message-ID: My thoughts on type families: 1) Type families are often too open. I causes "rigid variable" type error messages because when I start writing open type functions, I often realize that what I really intend is not truly open type functions. It happens a lot that I had some assumptions on the arguments or the range of the type function. Then, we need help of type classes to constrain the result of open type functions. For example, try to define HList library using type families instead of type classes with functional dependencies. One will soon need some class constraints. Sometimes, we can use associated type families, but many times it may become tedious when there are multiple arguments and result have certain constraints so that we might end up associating/splitting them over multiple type classes. In such cases, it may be more simple working with functional dependencies alone, rather than using both type classes and type families. I wish we had closed kinds so that we can define closed type functions as well as open type functions. 2) Type families are not good when we need to match types back and forth (e.g. bijective functions), or even multiple ways. We need the help of functional dependencies for these relational definitions. I know that several people are working on the unified implementation for both type families and functional dependencies. Once GHC have common background implementation, type families will truly be syntactic sugar of type classes with functional dependencies, as Mark Jones advocates, or maybe the other way around too. From ccshan at post.harvard.edu Thu Feb 12 20:05:07 2009 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Thu Feb 12 20:50:03 2009 Subject: [Haskell-cafe] Re: Delimited continuations: please comment References: Message-ID: <3jte66-a2v.ln1@mantle.rutgers.edu> Cristiano Paris wrote in article in gmane.comp.lang.haskell.cafe: > In effect, this is a bit different from the syscall service routine > described by Oleg, as the scheduler function reacts in different ways > for subsequent calls (the first time feeds "Hello!", the second one > "World!", in a nice monad style). Yet, I liked the separation between > the scheduler and the job, which are two completely different values > and which I tried to keep. It's not unheard of for the scheduler to react in different ways to the same system call -- I'm thinking of reading from a file, for example. > As this is (almost) my first time using delconts, could you provide > feedback, comments, opinions about my piece of code and the topic in > general (convenience, performances, alternatives and so on)? You clearly understand the whole idea, and your code demonstrates it in a nice way. Oleg and I have found this programming style particularly convenient when we need to - fork processes (i.e., backtrack in the monad), - run the same processes under different schedulers (e.g., a debugger), - nest the applications of schedulers (i.e., provide virtualization). -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig "Attending a mathematics lecture is like walking through a thunderstorm at night. Most of the time you are lost, wet and miserable but at rare intervals there is a flash of lightening and the whole countryside is lit up." - Tom Koerner From derek.a.elkins at gmail.com Thu Feb 12 21:11:27 2009 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Thu Feb 12 21:01:12 2009 Subject: [Haskell-cafe] Re: Can this be done? In-Reply-To: References: <4992E9DA.6020703@libero.it> <4993BBEE.9070603@freegeek.org> Message-ID: <1234491087.6099.4.camel@derek-laptop> On Thu, 2009-02-12 at 19:55 -0500, Chung-chieh Shan wrote: > wren ng thornton wrote in article <4993BBEE.9070603@freegeek.org> in gmane.comp.lang.haskell.cafe: > > It's ugly, but one option is to just reify your continuations as an ADT, > > where there are constructors for each function and fields for each > > variable that needs closing over. Serializing that ADT should be simple > > (unless some of those functions are higher-order in which case you run > > into the same problem of how to serialize the function arguments). In > > GHC's STG machine this representation shouldn't have much overhead, > > though it does require the developer to do the compiler's job. > > FWIW, this idea is called defunctionalization (due to Reynolds), > and it works for higher-order functions as well (because you can > defunctionalize those function arguments in the same way). > > People in many fields put a lot of effort into turning their programs > into state machines... > This paper by Ezra Cooper and Phil Wadler is an interesting recent development in the theory of defunctionalization and very relevant to this particular topic as well: http://homepages.inf.ed.ac.uk/wadler/topics/links.html#located-lambda From wagner.andrew at gmail.com Thu Feb 12 21:34:34 2009 From: wagner.andrew at gmail.com (Andrew Wagner) Date: Thu Feb 12 21:24:12 2009 Subject: [Haskell-cafe] Is this related to continuations somehow? Message-ID: So, I was reading a bit about continuations the other day, and, since I've been thinking about good ways of expressing chess strategies in Haskell, I thought that I'd play around a bit with something like continuations for game-playing strategies. The idea is that you have combinators that allow you full access to the strategies which remain to be applied. In this way, strategies can "activate" and "de-activate" other strategies. Here's a simple little toy app for Tic-Tac-Toe (Naughts and Crosses): http://codepad.org/nN9JsxFK You can run main on 'example', and see that it searches every line and fails. And, as you can see, it aborts after finding a win in example2. This would be easily extensible to say things like "if you've seen a blocking move, and you don't have a win, then play the blocking move", and of course the other deep intricacies of the game. My question is, is this, in fact, related to continuations somehow? Could continuations simplify it? Or am I doing something completely different? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090212/d6824646/attachment.htm From dave at zednenem.com Thu Feb 12 22:58:46 2009 From: dave at zednenem.com (David Menendez) Date: Thu Feb 12 22:48:24 2009 Subject: [Haskell-cafe] Race condition possible? In-Reply-To: <20090212232625.GL10706@whirlpool.galois.com> References: <20090212232625.GL10706@whirlpool.galois.com> Message-ID: <49a77b7a0902121958w7c431cf3q251874066c4f07cc@mail.gmail.com> On Thu, Feb 12, 2009 at 6:26 PM, Don Stewart wrote: > bugfact: >> Consider the following code >> >> stamp v x = do >> t <- getCurrentTime >> putMVar v (x,t) >> >> Is it possible - with GHC - that a thread switch happens after the t <- >> getCurrentTime and the putMVar v (x,t)? > > Yes. if 't' is heap allocated, there could be a context switch. > >> If so, how would it be possible to make sure that the operation of reading the >> current time and writing the pair to the MVar is an "atomic" operation, in the >> sense that no thread switch can happen between the two? Would this require STM? >> > > Using 'atomically' and TVars in STM, perhaps? Else, use withMVar? Or a > modifyMVar in IO? As I understand it, withMVar or modifyMVar will protect you from extraneous exceptions, but they won't prevent another thread from writing to the MVar between the take and the put. -- Dave Menendez From oleg at okmij.org Thu Feb 12 23:36:27 2009 From: oleg at okmij.org (oleg@okmij.org) Date: Thu Feb 12 23:28:00 2009 Subject: [Haskell-cafe] Re: Type families not as useful over functions Message-ID: <20090213043627.D92A2AB11@Adric.metnet.fnmoc.navy.mil> John Ky wrote: > Is there a way to define type r to be all types except functions? Perhaps the following article How to write an instance for not-a-function http://okmij.org/ftp/Haskell/typecast.html#is-function-type answers your question. It shows several complete examples. From s.clover at gmail.com Thu Feb 12 23:56:07 2009 From: s.clover at gmail.com (Sterling Clover) Date: Thu Feb 12 23:45:50 2009 Subject: [Haskell-cafe] Re: [Haskell] Google Summer of Code 2009 In-Reply-To: <987d172d0902120016i725dcb2bgc0ed2d18abeb9029@mail.gmail.com> References: <20090210142644.361a1d9e.Malcolm.Wallace@cs.york.ac.uk> <200902120852.04699.g9ks157k@acme.softbase.org> <987d172d0902120016i725dcb2bgc0ed2d18abeb9029@mail.gmail.com> Message-ID: +1 for some graphical tools for darcs, especially even a graphical merge tool (and a console/curses based version as well, to be sure). And +1 for darcs and xmonad applying as mentoring organizations in their own right. For that matter, it might be worthwhile for GHC to apply as well! That would ensure some dedicated compiler slots, and more could be contributed from the main haskell.org pool as appropriate. As well, I know that there's quite a nice new hackage2 almost rolled out, but I'm sure that there's at least an SoC project or two worth of feature additions to that as well. Off the top of my head, and bearing in mind that some might be further along than I think: a generalized way to search the package database, slicing and dicing by upload time, authors/maintainers, popularity, limiting views to packages that build on certain platforms, etc; some thought into security measures; a ratings system and associated reviews (thread/ wikibased); ways to mark packages as depreciated/for historic purposes. And there's bound to be more. As for numerics, I recall that Greg Wright, who knows whereof he speaks, had some particular issues that he thought no existing library addressed. I can't recall the details or do them justice, but perhaps he might care to enlighten us? Cheers, Sterl. On Feb 12, 2009, at 3:16 AM, Matthew Elder wrote: > would love to see this. > > basic features first i suppose. here are some of my ideas: > > 1. browseable change history with preview pane (preview pane shows > diff and patch message) > 2. darcs send which goes through the usual interactive console but > then prompts with a file save pane where you will save the .dpatch > (easy contribution). > 3. graphical dependency chart for patches (also shows conflict > patches as merges). > > On Wed, Feb 11, 2009 at 11:52 PM, Wolfgang Jeltsch > wrote: > Am Mittwoch, 11. Februar 2009 20:45 schrieb Gwern Branwen: > > Here are the projects I favor (in no particular order): > > > [?] > > > * A GUI interface to Darcs > > (http://hackage.haskell.org/trac/summer-of-code/ticket/17); this > could > > possibly be based on TortoiseDarcs http:// > tortoisedarcs.sourceforge.net/. > > Perhaps the specific project could be making TortoiseDarcs not > Windows > > specific? > > I plan to start writing a GUI interface to darcs together with some > of our > students. (However, we don't want to base it on TortoiseDarcs.) So > if you > have ideas of what features such an interface should have, please > write me > quickly. > > > [?] > > Best wishes, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > Need somewhere to put your code? http://patch-tag.com > Want to build a webapp? http://happstack.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From s.clover at gmail.com Fri Feb 13 00:20:05 2009 From: s.clover at gmail.com (Sterling Clover) Date: Fri Feb 13 00:09:45 2009 Subject: [Haskell-cafe] Is using Data.Dynamic considered a no-go? In-Reply-To: <20090212204043.GB10706@whirlpool.galois.com> References: <1234463061.22830.4.camel@jcchost> <20090212204043.GB10706@whirlpool.galois.com> Message-ID: SYB makes very heavy use of Typeable as well, although not, as I recall dynamics as such. Cheers, Sterl. On Feb 12, 2009, at 3:40 PM, Don Stewart wrote: > Notably, extensible exceptions use dynamics, in conjunction with type > classes and existentials. > > A number of solutions to the 'expression problem' involve dynamics. > > bugfact: >> It would be interesting to see when you HAVE to use dynamics, e.g. >> when no >> other solution is possible in Haskell... >> >> Right now if I use it, it feels that I'm doing so because I'm too >> new to >> Haskell. >> >> >> On Thu, Feb 12, 2009 at 7:53 PM, Lennart Augustsson >> >> wrote: >> >> You're quite right. You should only be allowed to derive >> Typeable. >> (Which could be arranged by hiding the methods of typeable.) >> >> On Thu, Feb 12, 2009 at 6:24 PM, Jonathan Cast >> wrote: >>> On Thu, 2009-02-12 at 19:04 +0100, Lennart Augustsson wrote: >>>> They are not unsafe in the way unsafePerformIO is, >>> >>> I beg permission to demur: >>> >>> newtype Unsafe alpha = Unsafe { unUnsafe :: alpha } >>> instance Typeable (Unsafe alpha) where >>> typeOf _ = typeOf () >>> >>> pseudoSafeCoerce :: alpha -> Maybe beta >>> pseudoSafeCoerce = fmap unUnsafe . cast . Unsafe >>> >>> Note that >>> >>> pseudoSafeCoerce = Just . unsafeCoerce >>> >>>> but I regard them >>>> as a last resort in certain situations. >>>> Still, in those situations they are very useful. >>> >>> But I would agree with both of these. As long as you *derive* >>> Typeable. >>> >>> jcc >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > >> _______________________________________________ >> Haskell-Cafe 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 From porges at porg.es Fri Feb 13 00:50:28 2009 From: porges at porg.es (George Pollard) Date: Fri Feb 13 00:40:09 2009 Subject: [Haskell-cafe] Type families not as useful over functions In-Reply-To: References: <98BF7C39-508C-4AB4-90E5-4E49CAB0E858@yandex.ru> Message-ID: <1234504228.6845.7.camel@porges-laptop> > Can you live with > infixl |$| > (|$|) :: [a -> r] -> a -> [r] > fs |$| x = map ($ x) fs > and, instead of "broadcast fs a b" use > fs |$| a |$| b > ? map ($ x) fs = { Applicative Functors satisfy... } pure ($ x) <*> fs = { 'interchange' rule from Control.Applicative } fs <*> pure x Thus; fs |$| x === fs <*> pure x fs |$| x |$| y === fs <*> pure x <*> pure y - George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/30b0c864/attachment.bin From magicloud.magiclouds at gmail.com Fri Feb 13 02:06:00 2009 From: magicloud.magiclouds at gmail.com (Magicloud) Date: Fri Feb 13 01:55:42 2009 Subject: [Haskell-cafe] How to deal with utf-8? Message-ID: <49951BD8.4080805@gmail.com> Hi, I am using Text.CSV to read and using gtk2hs to display csv files using utf-8 encode. Well, it displays broken strings, seems like it cannot deal with utf-8. What should I do? Thanks. From gtener at gmail.com Fri Feb 13 02:33:09 2009 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Fri Feb 13 02:22:48 2009 Subject: [Haskell-cafe] How to deal with utf-8? In-Reply-To: <49951BD8.4080805@gmail.com> References: <49951BD8.4080805@gmail.com> Message-ID: <220e47b40902122333m49ab25f6lcb1785e9d0e8ded7@mail.gmail.com> On Fri, Feb 13, 2009 at 08:06, Magicloud wrote: > Hi, > I am using Text.CSV to read and using gtk2hs to display csv files using > utf-8 encode. Well, it displays broken strings, seems like it cannot deal > with utf-8. > What should I do? You should try using functions from utf8-string package (find it on Hackage) to read UTF-8 encoded data. That's about reading data in. I'm not so sure however about the gtk2hs part. Experts should tell you if it is possible or not. (I think it is.) All best Christopher Skrz?tnicki P.S. I think beginners@haskell.org is a better place to ask such questions. From bulat.ziganshin at gmail.com Fri Feb 13 03:24:00 2009 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri Feb 13 03:14:16 2009 Subject: [Haskell-cafe] Race condition possible? In-Reply-To: References: Message-ID: <1542363862.20090213112400@gmail.com> Hello Peter, Friday, February 13, 2009, 2:17:52 AM, you wrote: > If so, how would it be possible to make sure that the operation of > reading the current time and writing the pair to the MVar is an > "atomic" operation, in the sense that no thread switch can happen > between the two? Would this require STM? it may be better to change architecture so that you no more need atomic operations - these are "unnatural" for mvar/chan approach -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From frodo at theshire.org Fri Feb 13 04:11:02 2009 From: frodo at theshire.org (Cristiano Paris) Date: Fri Feb 13 04:00:39 2009 Subject: [Haskell-cafe] Re: Delimited continuations: please comment In-Reply-To: <3jte66-a2v.ln1@mantle.rutgers.edu> References: <3jte66-a2v.ln1@mantle.rutgers.edu> Message-ID: On Fri, Feb 13, 2009 at 2:05 AM, Chung-chieh Shan wrote: > ... > It's not unheard of for the scheduler to react in different ways to the > same system call -- I'm thinking of reading from a file, for example. Sure, I went implementing something slitghtly different to double check my understanding of delconts. > You clearly understand the whole idea, and your code demonstrates it in > a nice way. Oleg and I have found this programming style particularly > convenient when we need to > - fork processes (i.e., backtrack in the monad), > - run the same processes under different schedulers (e.g., a debugger), > - nest the applications of schedulers (i.e., provide virtualization). Thanks for your feedback. Cristiano From devriese at cs.tcd.ie Fri Feb 13 04:14:48 2009 From: devriese at cs.tcd.ie (Edsko de Vries) Date: Fri Feb 13 04:04:26 2009 Subject: [Haskell-cafe] Another point-free question (>>=, join, ap) In-Reply-To: <20090212233619.GA4781@netsoc.tcd.ie> References: <20090212233619.GA4781@netsoc.tcd.ie> Message-ID: <20090213091447.GB16112@netsoc.tcd.ie> Hey, Thanks for all the suggestions. I was hoping that there was some uniform pattern that would extend to n arguments (rather than having to use liftM2, litM3, etc. or have different 'application' operators in between the different arguments); perhaps not. Oh well :) Thanks again! Edsko From duncan.coutts at worc.ox.ac.uk Fri Feb 13 04:54:21 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 13 04:44:13 2009 Subject: [Haskell-cafe] How to deal with utf-8? In-Reply-To: <220e47b40902122333m49ab25f6lcb1785e9d0e8ded7@mail.gmail.com> References: <49951BD8.4080805@gmail.com> <220e47b40902122333m49ab25f6lcb1785e9d0e8ded7@mail.gmail.com> Message-ID: <1234518861.4025.131.camel@localhost> On Fri, 2009-02-13 at 08:33 +0100, Krzysztof Skrz?tnicki wrote: > On Fri, Feb 13, 2009 at 08:06, Magicloud wrote: > > Hi, > > I am using Text.CSV to read and using gtk2hs to display csv files using > > utf-8 encode. Well, it displays broken strings, seems like it cannot deal > > with utf-8. > > What should I do? > > You should try using functions from utf8-string package (find it on > Hackage) to read UTF-8 encoded data. > That's about reading data in. I'm not so sure however about the gtk2hs > part. Experts should tell you if it is possible or not. (I think it > is.) Gtk2Hs displays Haskell Strings correctly. Haskell Strings are Unicode. So all you need to do is decode utf8 into a proper Haskell String. Duncan From duncan.coutts at worc.ox.ac.uk Fri Feb 13 05:01:44 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 13 04:51:37 2009 Subject: [Haskell-cafe] Race condition possible? In-Reply-To: <49a77b7a0902121958w7c431cf3q251874066c4f07cc@mail.gmail.com> References: <20090212232625.GL10706@whirlpool.galois.com> <49a77b7a0902121958w7c431cf3q251874066c4f07cc@mail.gmail.com> Message-ID: <1234519304.4025.138.camel@localhost> On Thu, 2009-02-12 at 22:58 -0500, David Menendez wrote: > On Thu, Feb 12, 2009 at 6:26 PM, Don Stewart wrote: > > bugfact: > >> Consider the following code > >> > >> stamp v x = do > >> t <- getCurrentTime > >> putMVar v (x,t) > >> > >> Is it possible - with GHC - that a thread switch happens after the t <- > >> getCurrentTime and the putMVar v (x,t)? > > > > Yes. if 't' is heap allocated, there could be a context switch. > > > >> If so, how would it be possible to make sure that the operation of reading the > >> current time and writing the pair to the MVar is an "atomic" operation, in the > >> sense that no thread switch can happen between the two? Would this require STM? > >> > > > > Using 'atomically' and TVars in STM, perhaps? Else, use withMVar? Or a > > modifyMVar in IO? > > As I understand it, withMVar or modifyMVar will protect you from > extraneous exceptions, but they won't prevent another thread from > writing to the MVar between the take and the put. You have to cooperate with the other users of the MVar. If each thread is using readMVar, withMVar or modifyMVar then it's fine. The read/with/modify actions do a takeMVar followed by a putMVar. If one thread is using withMVar and another is doing putMVar directly then the exclusion scheme does not work. Duncan From apfelmus at quantentunnel.de Fri Feb 13 05:08:55 2009 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri Feb 13 04:57:48 2009 Subject: [Haskell-cafe] Re: Haddock Markup In-Reply-To: <1234485203.22830.63.camel@jcchost> References: <200902111340.27082.g9ks157k@acme.softbase.org> <801FE99D-FE1C-4B19-9D85-D2B10C85F447@cs.otago.ac.nz> <200902120848.14765.g9ks157k@acme.softbase.org> <7B91BE81-6099-42F7-BF50-568CA748AC1B@cs.otago.ac.nz> <1234485203.22830.63.camel@jcchost> Message-ID: Jonathan Cast wrote: > > NB: This example is *precisely* why I will never adopt MathML as an > authoring format. Bowing and scraping at the alter of W3C is not worth > using such a terrible syntax, not ever. > > (Indented, that's > > > > > x > 2 > > + > > 4 > ⁢ > x > > + > 4 > > > > Which is still unforgivably horrible. I *think* it's trying to say $x^2 > + 4x + 4$, but I'm not confident even of that. Yeah, MathML looks like a machine-only format to me, begging the question why they don't use a more compact format. > I'm also unconvinced > it's actually easier to parse than $x^2 + 4x + 4$.) While parsing is a solved problem in theory, a lot of people use some regular expression kludges or similar atrocities in practice. Writing a proper parser is too complicated if your language doesn't have parser combinators. :) Regards, apfelmus -- http://apfelmus.nfshost.com From paolo.veronelli at gmail.com Fri Feb 13 05:09:35 2009 From: paolo.veronelli at gmail.com (Paolino) Date: Fri Feb 13 04:59:13 2009 Subject: [Haskell-cafe] parallelism or concurrency ? if they are different Message-ID: When I came to haskell, I arrived with a small and only evolutionary background in programming. First monad I met was MonadState StdGen m. Everything was in someway acceptable, I had no problem in explicitating the need for the generator. The lesson was referential transparency. To me referential tranparency is still obscure as a feature. Not using the monad , my functions pass around a generator, then they are repeatable, same generator , same computation. Years pass by, now evolutionary algorithms need to scale multicores. But multicore can be used with threads or par, the difference is that par is pure, because it respects referential transparency. But threads not. They are always unrespectful ? Or it's an implementation issue of preemptive choice? Can I have a baton to pass around like I had for random generator, so that the computation ends without IO (unsafe performed) , without breaking tranparency, something like (runIOThreads :: ThreadsIO a -> ThreadsBaton -> a) ? >From Real World Haskell my algorithm have to be parallelized as they don't do some kind of IO, they don't deal with the world, but where is it stated that it is possible to write them with par (I couldn't) ? More , I'm not caring that my computation is unrepeatable, for me it's fine that the runtime system gives me the cached results for same arguments computation. The fact that it doesn't ,and recompute the function giving out something fuzzily different from before, is enough to coerce me to spit out IO values ? Finally, why and where the optimizer will substitute a value with its definition, so that it possibly get computed twice ? Thanks paolino From d at domob.eu Fri Feb 13 05:27:01 2009 From: d at domob.eu (Daniel Kraft) Date: Fri Feb 13 05:12:38 2009 Subject: [Haskell-cafe] Overloading functions based on arguments? Message-ID: Hi, I just came across a problem like this: Suppose I've got two related functions that do similar things, and I want to call them the same... Like in: foobar :: String -> Int -> Int foobar :: Int -> String -> Int (Bad example, but I hope you got the point.) Is this kind of overloading (instead of the polymorphism based overloading) possible in Haskell? Namely to have two functions with the same name but different signatures so they could be distinguished by a call's parameters? I fear not... So I guess I have to name the functions differently, right? Thanks, Daniel From ekirpichov at gmail.com Fri Feb 13 05:25:27 2009 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Fri Feb 13 05:15:06 2009 Subject: [Haskell-cafe] Overloading functions based on arguments? In-Reply-To: References: Message-ID: <5e0214850902130225q67a546edt9461f279c3a50f29@mail.gmail.com> class Foobar a b where foobar :: a -> b -> Int instance Foobar String Int where ... instance Foobar Int String where ... 2009/2/13 Daniel Kraft : > Hi, > > I just came across a problem like this: Suppose I've got two related > functions that do similar things, and I want to call them the same... Like > in: > > foobar :: String -> Int -> Int > foobar :: Int -> String -> Int > > (Bad example, but I hope you got the point.) > > Is this kind of overloading (instead of the polymorphism based overloading) > possible in Haskell? Namely to have two functions with the same name but > different signatures so they could be distinguished by a call's parameters? > I fear not... So I guess I have to name the functions differently, right? > > Thanks, > Daniel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From colinpauladams at googlemail.com Fri Feb 13 05:28:59 2009 From: colinpauladams at googlemail.com (Colin Adams) Date: Fri Feb 13 05:18:37 2009 Subject: [Haskell-cafe] Overloading functions based on arguments? In-Reply-To: References: Message-ID: <1afdeaec0902130228x7996e5b8q4798f548ef7f222e@mail.gmail.com> If you have two functions that do two different things, then they certainly OUGHT to have different names. You can of course put the two functions in different modules. Then they do have different (qualified) names. 2009/2/13 Daniel Kraft : > Hi, > > I just came across a problem like this: Suppose I've got two related > functions that do similar things, and I want to call them the same... Like > in: > > foobar :: String -> Int -> Int > foobar :: Int -> String -> Int > > (Bad example, but I hope you got the point.) > > Is this kind of overloading (instead of the polymorphism based overloading) > possible in Haskell? Namely to have two functions with the same name but > different signatures so they could be distinguished by a call's parameters? > I fear not... So I guess I have to name the functions differently, right? > > Thanks, > Daniel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From d at domob.eu Fri Feb 13 05:40:43 2009 From: d at domob.eu (Daniel Kraft) Date: Fri Feb 13 05:26:14 2009 Subject: [Haskell-cafe] Re: Overloading functions based on arguments? In-Reply-To: <1afdeaec0902130228x7996e5b8q4798f548ef7f222e@mail.gmail.com> References: <1afdeaec0902130228x7996e5b8q4798f548ef7f222e@mail.gmail.com> Message-ID: <49954E2B.8070209@domob.eu> Colin Adams wrote: > If you have two functions that do two different things, then they > certainly OUGHT to have different names. Well, they do "the same thing" but for different arguments; it's like this: Table is a table of name-value pairs I want to substitute in a tree-like structure using: substitute :: Table -> Tree -> Tree For substituting a single name-value pair I want to define this utitlity routine so I don't have to construct a Table all the time in the user code: substitute :: String -> Value -> Tree -> Tree In the case I believe it would certainly be good to be able to name both functions the same, but I fear I can not do so? There are languages where this is explicitelly allowed (e.g. C++ or Java), so I don't think it is such an unuseful or evil thing. Daniel From duncan.coutts at worc.ox.ac.uk Fri Feb 13 05:39:33 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 13 05:29:26 2009 Subject: [Haskell-cafe] Overloading functions based on arguments? In-Reply-To: <5e0214850902130225q67a546edt9461f279c3a50f29@mail.gmail.com> References: <5e0214850902130225q67a546edt9461f279c3a50f29@mail.gmail.com> Message-ID: <1234521573.4025.144.camel@localhost> On Fri, 2009-02-13 at 13:25 +0300, Eugene Kirpichov wrote: > class Foobar a b where > foobar :: a -> b -> Int > > instance Foobar String Int where ... > instance Foobar Int String where ... But we typically do not to this. It's ugly. Classes work nicely when there is some kind of parametrisation going on, where a function can work with any instance of some interface. Ad-hoc overloading in the style of Java/C++ just isn't done, even though it can be encoded by the above trick. In the simple case just us a different name. If you would have lots of variations then consider other approaches like passing a data type containing some of the arguments (since that can encode alternatives). Duncan > 2009/2/13 Daniel Kraft : > > Hi, > > > > I just came across a problem like this: Suppose I've got two related > > functions that do similar things, and I want to call them the same... Like > > in: > > > > foobar :: String -> Int -> Int > > foobar :: Int -> String -> Int > > > > (Bad example, but I hope you got the point.) > > > > Is this kind of overloading (instead of the polymorphism based overloading) > > possible in Haskell? Namely to have two functions with the same name but > > different signatures so they could be distinguished by a call's parameters? > > I fear not... So I guess I have to name the functions differently, right? > > > > Thanks, > > Daniel From noteed at gmail.com Fri Feb 13 05:41:33 2009 From: noteed at gmail.com (minh thu) Date: Fri Feb 13 05:31:11 2009 Subject: [Haskell-cafe] Re: Overloading functions based on arguments? In-Reply-To: <49954E2B.8070209@domob.eu> References: <1afdeaec0902130228x7996e5b8q4798f548ef7f222e@mail.gmail.com> <49954E2B.8070209@domob.eu> Message-ID: <40a414c20902130241j25b66f06o48d5120d766ee685@mail.gmail.com> 2009/2/13 Daniel Kraft : > Colin Adams wrote: >> >> If you have two functions that do two different things, then they >> certainly OUGHT to have different names. > > Well, they do "the same thing" but for different arguments; it's like this: > > Table is a table of name-value pairs I want to substitute in a tree-like > structure using: > > substitute :: Table -> Tree -> Tree > > For substituting a single name-value pair I want to define this utitlity > routine so I don't have to construct a Table all the time in the user code: > > substitute :: String -> Value -> Tree -> Tree > > In the case I believe it would certainly be good to be able to name both > functions the same, but I fear I can not do so? There are languages where > this is explicitelly allowed (e.g. C++ or Java), so I don't think it is such > an unuseful or evil thing. That's probably not Evil, but it's much clearer to know what something is by looking at its name (or the name of the function used on). So, substituteOne and substituteMany are much clearer... Thu From ndmitchell at gmail.com Fri Feb 13 05:43:06 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 13 05:32:44 2009 Subject: [Haskell-cafe] Re: Overloading functions based on arguments? In-Reply-To: <49954E2B.8070209@domob.eu> References: <1afdeaec0902130228x7996e5b8q4798f548ef7f222e@mail.gmail.com> <49954E2B.8070209@domob.eu> Message-ID: <404396ef0902130243s121e6cc3t37488fd4b0566603@mail.gmail.com> Hi > Table is a table of name-value pairs I want to substitute in a tree-like > structure using: > > substitute :: Table -> Tree -> Tree > > For substituting a single name-value pair I want to define this utitlity > routine so I don't have to construct a Table all the time in the user code: > > substitute :: String -> Value -> Tree -> Tree Why not: substituteValue :: String -> Value -> Tree -> Tree substituteValue x y = substitute (table1 x y) > In the case I believe it would certainly be good to be able to name both > functions the same, but I fear I can not do so? ?There are languages where > this is explicitelly allowed (e.g. C++ or Java), so I don't think it is such > an unuseful or evil thing. Languages like C++ and Java allow mutable state, object-orientated programming and require massively verbose code - all of which are unuseful and evil :-) I think this is a case of trying to apply C++/Java thoughts on to Haskell, you can map the concepts directly, but you really shouldn't. Try writing multiple methods with many names, or simple utility functions to convert between the cases, and it will go much nicer. Thanks Neil From bugfact at gmail.com Fri Feb 13 05:44:27 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Fri Feb 13 05:34:05 2009 Subject: [Haskell-cafe] Race condition possible? In-Reply-To: <1234519304.4025.138.camel@localhost> References: <20090212232625.GL10706@whirlpool.galois.com> <49a77b7a0902121958w7c431cf3q251874066c4f07cc@mail.gmail.com> <1234519304.4025.138.camel@localhost> Message-ID: Ah yes, then you're doing a double handshaking in a sense, of course. Not ideal if you just want to put something in the MVar and resume as quick as possible. However, in that case one could fork a dummy thread that only does readMVar I guess. But does it also work when you want multiple threads that are waiting for the same MVar, and a single thread that writes to the MVar? It think is does, when you use readMVar one thread will get the value and the others will get it sequentially since readMVar puts the value back... Again you guys gave a solution, an amazing brain thank this cafe is... Usually one gets drunk in a cafe, destroying braincells. Here it's the opposite :) On Fri, Feb 13, 2009 at 11:01 AM, Duncan Coutts wrote: > On Thu, 2009-02-12 at 22:58 -0500, David Menendez wrote: > > On Thu, Feb 12, 2009 at 6:26 PM, Don Stewart wrote: > > > bugfact: > > >> Consider the following code > > >> > > >> stamp v x = do > > >> t <- getCurrentTime > > >> putMVar v (x,t) > > >> > > >> Is it possible - with GHC - that a thread switch happens after the t > <- > > >> getCurrentTime and the putMVar v (x,t)? > > > > > > Yes. if 't' is heap allocated, there could be a context switch. > > > > > >> If so, how would it be possible to make sure that the operation of > reading the > > >> current time and writing the pair to the MVar is an "atomic" > operation, in the > > >> sense that no thread switch can happen between the two? Would this > require STM? > > >> > > > > > > Using 'atomically' and TVars in STM, perhaps? Else, use withMVar? Or > a > > > modifyMVar in IO? > > > > As I understand it, withMVar or modifyMVar will protect you from > > extraneous exceptions, but they won't prevent another thread from > > writing to the MVar between the take and the put. > > You have to cooperate with the other users of the MVar. > > If each thread is using readMVar, withMVar or modifyMVar then it's fine. > The read/with/modify actions do a takeMVar followed by a putMVar. If one > thread is using withMVar and another is doing putMVar directly then the > exclusion scheme does not work. > > Duncan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/946ef6f7/attachment.htm From porges at porg.es Fri Feb 13 05:48:44 2009 From: porges at porg.es (George Pollard) Date: Fri Feb 13 05:38:27 2009 Subject: [Haskell-cafe] Re: Overloading functions based on arguments? In-Reply-To: <49954E2B.8070209@domob.eu> References: <1afdeaec0902130228x7996e5b8q4798f548ef7f222e@mail.gmail.com> <49954E2B.8070209@domob.eu> Message-ID: <1234522124.9587.2.camel@porges-laptop> On Fri, 2009-02-13 at 11:40 +0100, Daniel Kraft wrote: > Colin Adams wrote: > > If you have two functions that do two different things, then they > > certainly OUGHT to have different names. > > Well, they do "the same thing" but for different arguments; it's like this: > > Table is a table of name-value pairs I want to substitute in a tree-like > structure using: > > substitute :: Table -> Tree -> Tree > > For substituting a single name-value pair I want to define this utitlity > routine so I don't have to construct a Table all the time in the user code: > > substitute :: String -> Value -> Tree -> Tree You can write it like this: class Substitutable a where substitute :: a -> Tree -> Tree instance Substitutable Table where ... instance Substitutable (String, Value) where ... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/c72aa156/attachment.bin From d at domob.eu Fri Feb 13 06:00:51 2009 From: d at domob.eu (Daniel Kraft) Date: Fri Feb 13 05:46:26 2009 Subject: [Haskell-cafe] Re: Overloading functions based on arguments? In-Reply-To: References: Message-ID: Daniel Kraft wrote: > Is this kind of overloading (instead of the polymorphism based > overloading) possible in Haskell? Namely to have two functions with the > same name but different signatures so they could be distinguished by a > call's parameters? I fear not... So I guess I have to name the > functions differently, right? Thanks for all the quick replies, I think I'm really going for different names :) But there were some nice ideas I will remember for the future, maybe they can be of some use for something else! Daniel From duncan.coutts at worc.ox.ac.uk Fri Feb 13 05:58:19 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 13 05:48:17 2009 Subject: [Haskell-cafe] Help needed with apache config for hackage Message-ID: <1234522699.4025.150.camel@localhost> Hi folks, Does anyone have any experience with apache configuration, particularly mime types and handling browser quirks and would like to help us with an issue we have on hackage? http://hackage.haskell.org/trac/hackage/ticket/498 The problem is described in the ticket but basically IE6 gets confused by the Content-Type and Content-Encoding and ends up saving ".tar.gz" files with the wrong name ".tar.tar". We need help working out how to configure apache to use a workaround and with testing that the solution actually works. Thanks! Duncan From porges at porg.es Fri Feb 13 06:39:23 2009 From: porges at porg.es (George Pollard) Date: Fri Feb 13 06:29:04 2009 Subject: [Haskell-cafe] Help needed with apache config for hackage In-Reply-To: <1234522699.4025.150.camel@localhost> References: <1234522699.4025.150.camel@localhost> Message-ID: <1234525163.9587.25.camel@porges-laptop> On Fri, 2009-02-13 at 10:58 +0000, Duncan Coutts wrote: > Hi folks, > > Does anyone have any experience with apache configuration, particularly > mime types and handling browser quirks and would like to help us with an > issue we have on hackage? > > http://hackage.haskell.org/trac/hackage/ticket/498 > > The problem is described in the ticket but basically IE6 gets confused > by the Content-Type and Content-Encoding and ends up saving ".tar.gz" > files with the wrong name ".tar.tar". > > We need help working out how to configure apache to use a workaround and > with testing that the solution actually works. > > Thanks! > > Duncan Currently the browser receives: > HTTP/1.1 200 OK > Date: Fri, 13 Feb 2009 11:15:22 GMT > Server: Apache/2.2.3 (Debian) > Last-Modified: Mon, 09 Feb 2009 07:55:57 GMT > ETag: "38c010-46d-b361bd40" > Accept-Ranges: bytes > Content-Length: 1133 > Content-Type: application/x-tar > Content-Encoding: x-gzip You could try adding a Content-Disposition header to specify a file name: Content-Disposition: attachment; filename=APackage.tar.gz In Apache you can (apparently [1],[2]) do it like this: RewriteRule "^packages/archive/[^/]+/[^/]+/(.+)$" - [env=pkgname:$1] Header set Content-Disposition "attachment; filename=\"%{pkgname}e\"" env=pkgname [1]: http://httpd.apache.org/docs/2.0/mod/core.html#files [2]: http://www.experts-exchange.com/Software/Server_Software/Web_Servers/Apache/Q_23054616.html - George -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090213/599e50e2/attachment.bin From duncan.coutts at worc.ox.ac.uk Fri Feb 13 07:19:29 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Fri Feb 13 07:09:24 2009 Subject: [Haskell-cafe] Help needed with apache config for hackage In-Reply-To: <1234525163.9587.25.camel@porges-laptop> References: <1234522699.4025.150.camel@localhost> <1234525163.9587.25.camel@porges-laptop> Message-ID: <1234527569.4025.154.camel@localhost> On Fri, 2009-02-13 at 22:39 +1100, George Pollard wrote: > On Fri, 2009-02-13 at 10:58 +0000, Duncan Coutts wrote: > > Hi folks, > > > > Does anyone have any experience with apache configuration, particularly > > mime types and handling browser quirks and would like to help us with an > > issue we have on hackage? > > > > http://hackage.haskell.org/trac/hackage/ticket/498 > > > > The problem is described in the ticket but basically IE6 gets confused > > by the Content-Type and Content-Encoding and ends up saving ".tar.gz" > > files with the wrong name ".tar.tar". > > > > We need help working out how to configure apache to use a workaround and > > with testing that the solution actually works. > > > > Thanks! > > > > Duncan > > Currently the browser receives: > > > HTTP/1.1 200 OK > > Date: Fri, 13 Feb 2009 11:15:22 GMT > > Server: Apache/2.2.3 (Debian) > > Last-Modified: Mon, 09 Feb 2009 07:55:57 GMT > > ETag: "38c010-46d-b361bd40" > > Accept-Ranges: bytes > > Content-Length: 1133 > > Content-Type: application/x-tar > > Content-Encoding: x-gzip > > You could try adding a Content-Disposition header to specify a file name: > > Content-Disposition: attachment; filename=APackage.tar.gz > > In Apache you can (apparently [1],[2]) do it like this: > > RewriteRule "^packages/archive/[^/]+/[^/]+/(.+)$" - [env=pkgname:$1] > Header set Content-Disposition "attachment; filename=\"%{pkgname}e\"" env=pkgname > > [1]: http://httpd.apache.org/docs/2.0/mod/core.html#files > [2]: http://www.experts-exchange.com/Software/Server_Software/Web_Servers/Apache/Q_23054616.html Can we do that just for one user agent? I don't think we want to use non-standard stuff in general. Apparently Content-Disposition is not in the official HTTP spec, but IE is known to follow it. Duncan From hjgtuyl at chello.nl Fri Feb 13 09:52:48 2009 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri Feb 13 09:42:27 2009 Subject: [Haskell-cafe] Language popularity Message-ID: Yesterday I saw Haskell mentioned for the first time in a magazine, Bits & Chips. It is a magazine for professionals, about hardware and software; the article was about the domain specific language Cryptol from Galois. In the same issue of the magazine, there was an article saying that the company Tiobe has proclamed C the language of the year 2008, because of it's growth in popularity of almost two percent. The current statistics can befoud at [1]. The most popular functional language at the moment is LOGO [2], at the 15th place in the top 50 (from 22nd place a year ago). Haskell is at the 35th place (no indication of the score last year). A quick search in the Web Archive [3] reveals that Haskell was at the 41st place in the index in June 2007. My own research, using Google: Search Hits ------------------------------- Java programming 20.400.000 LOGO programming 14.600.000 Haskell programming 250.000 [1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [2] http://en.wikipedia.org/wiki/Logo_(programming_language) [3] http://web.archive.org/web/20070606231519/www.tiobe.com/?tiobe_index -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- From greenrd at greenrd.org Fri Feb 13 10:07:04 2009 From: greenrd at greenrd.org (Robin Green) Date: Fri Feb 13 09:56:00 2009 Subject: [Haskell-cafe] Language popularity In-Reply-To: References: Message-ID: <20090213150704.3a1e5bc2@greenrd.org> On Fri, 13 Feb 2009 15:52:48 +0100 "Henk-Jan van Tuyl" wrote: > > Yesterday I saw Haskell mentioned for the first time in a magazine, > Bits & Chips. It is a magazine for professionals, about hardware and > software; the article was about the domain specific language Cryptol > from Galois. > > In the same issue of the magazine, there was an article saying that > the company Tiobe has proclamed C the language of the year 2008, > because of it's growth in popularity of almost two percent. The > current statistics can befoud at [1]. The most popular functional > language at the moment is LOGO [2], at the 15th place in the top 50 > (from 22nd place a year ago). I think we can fairly safely discount the commercial relevance of any language ranking which places LOGO so highly. It may be that a lot of people *know* LOGO (or claim to know it), but that does not mean that is used a lot for commercial programming. -- Robin From lemming at henning-thielemann.de Fri Feb 13 10:07:04 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 13 09:56:43 2009 Subject: [Haskell-cafe] Changing version numbering schemes for HackageDB packages? In-Reply-To: References: Message-ID: <49958C98.8010101@henning-thielemann.de> Corey O'Connor wrote: > I released a new version of data-spacepart that resolved some of the > issues with the previous release. One issue I had was the previous > release used the version numbering scheme I use at work: > [date].[release] Which does not appear to work as well as the > traditional X.Y.Z release numbering scheme with Cabal. As part of the > new release I changed the version numbering scheme. An *obviously* bad > idea if I thought it through. Any [date].[release] style version > number is greater than a X.Y.Z version number until X gets rather > large. > > So what to do? Continue using the [date].[release] version numbering > scheme? Or is there a way to coax HackageDB to ignore the old release? Use a (slightly) different package name? From lemming at henning-thielemann.de Fri Feb 13 10:19:45 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 13 10:09:20 2009 Subject: [Haskell-cafe] Haskell.org GSoC In-Reply-To: References: Message-ID: <49958F91.7010500@henning-thielemann.de> Daniel Kraft wrote: > Hi, > > I noticed last year Haskell.org was a mentoring organization for > Google's Summer of Code, and I barely noticed some discussion about it > applying again this year :) > > I participated for GCC in 2008 and would like to try again this year; > while I'm still active for GCC and will surely stay so, I'd like to see > something new at least for GSoC. And Haskell.org would surely be a > very, very nice organization. > > Since I discovered there's more than just a lot of imperative languages > that are nearly all the same, I love to do some programming in Prolog, > Scheme and of course Haskell. However, so far this was only some toy > programs and nothing "really useful"; I'd like to change this (as well > as learning more about Haskell during the projects). > > Here are some ideas for developing Haskell packages (that would > hopefully be of general use to the community) as possible projects: > > - Numerics, like basic linear algebra routines, numeric integration and > other basic algorithms of numeric mathematics. I have some unsorted routines for that: http://darcs.haskell.org/htam/src/Numerics/ > - A basic symbolic maths package; I've no idea how far one could do this > as a single GSoC project, but it would surely be a very interesting > task. Alternatively or in combination, one could try to use an existing > free CAS package as engine. DoCon? > - Graphs. There was some discussion here about improved API of fgl: http://haskell.org/pipermail/libraries/2008-February/009241.html > - A logic programming framework. I know there's something like that for > Scheme; in my experience, there are some problems best expressed > logically with Prolog-style backtracking/predicates and unification. > This could help use such formulations from inside a Haskell program. > This is surely also a very interesting project. LogicT ? From conor at strictlypositive.org Fri Feb 13 10:25:47 2009 From: conor at strictlypositive.org (Conor McBride) Date: Fri Feb 13 10:16:19 2009 Subject: [Haskell-cafe] Another point-free question (>>=, join, ap) In-Reply-To: <20090213091447.GB16112@netsoc.tcd.ie> References: <20090212233619.GA4781@netsoc.tcd.ie> <20090213091447.GB16112@netsoc.tcd.ie> Message-ID: <4921873F-FAE0-4AEA-88EF-BDFE11A524CA@strictlypositive.org> Hi Edsko On 13 Feb 2009, at 09:14, Edsko de Vries wrote: > Hey, > > Thanks for all the suggestions. I was hoping that there was some > uniform > pattern that would extend to n arguments (rather than having to use > liftM2, litM3, etc. or have different 'application' operators in > between > the different arguments); perhaps not. Oh well :) Will this do? http://www.haskell.org/haskellwiki/Idiom_brackets You get to write iI f a1 a2 a3 Ji for do x1 <- a1 x2 <- a2 x3 <- a3 f a1 a2 a3 amongst other things... Cheers Conor This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From lemming at henning-thielemann.de Fri Feb 13 10:30:56 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 13 10:20:33 2009 Subject: [Haskell-cafe] Haskell.org GSoC -> Haskell for Math type setting In-Reply-To: References: Message-ID: I think the recent discussion about advanced markup for Haddock documentation could yield a Summer of code project. I still like my suggestion to use Haskell code as description for math formulas and I like Wolfgang's idea to use an existing tool like Template Haskell for conversion from Haskell code to an output format (TeX, MathML, or whatever): http://haskell.org/pipermail/haskell-cafe/2009-February/055358.html From lemming at henning-thielemann.de Fri Feb 13 10:34:38 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 13 10:24:13 2009 Subject: [Haskell-cafe] Overloading functions based on arguments? In-Reply-To: References: Message-ID: <4995930E.9050708@henning-thielemann.de> Daniel Kraft wrote: > Hi, > > I just came across a problem like this: Suppose I've got two related > functions that do similar things, and I want to call them the same... > Like in: > > foobar :: String -> Int -> Int > foobar :: Int -> String -> Int > > (Bad example, but I hope you got the point.) http://www.haskell.org/haskellwiki/Type_classes_are_for_reusability From jonathanccast at fastmail.fm Fri Feb 13 10:37:13 2009 From: jonathanccast at fastmail.fm (Jonathan Cast) Date: Fri Feb 13 10:26:51 2009 Subject: [Haskell-cafe] Re: Haddock Markup In-Reply-To: References: <200902111340.27082.g9ks157k@acme.softbase.org> <801FE99D-FE1C-4B19-9D85-D2B10C85F447@cs.otago.ac.nz> <200902120848.14765.g9ks157k@acme.softbase.org> <7B91BE81-6099-42F7-BF50-568CA748AC1B@cs.otago.ac.nz> <1234485203.22830.63.camel@jcchost> Message-ID: <1234539433.6422.3.camel@jonathans-macbook> On Fri, 2009-02-13 at 11:08 +0100, Heinrich Apfelmus wrote: > Jonathan Cast wrote: > > > > NB: This example is *precisely* why I will never adopt MathML as an > > authoring format. Bowing and scraping at the alter of W3C is not worth > > using such a terrible syntax, not ever. > > > > (Indented, that's > > > > > > > > > > x > > 2 > > > > + > > > > 4 > > ⁢ > > x > > > > + > > 4 > > > > > > > > Which is still unforgivably horrible. I *think* it's trying to say $x^2 > > + 4x + 4$, but I'm not confident even of that. > > Yeah, MathML looks like a machine-only format to me, begging the > question why they don't use a more compact format. > > > I'm also unconvinced > > it's actually easier to parse than $x^2 + 4x + 4$.) > > While parsing is a solved problem in theory, a lot of people use some > regular expression kludges or similar atrocities in practice. Yeah, we even seem to have adopted one of their syntaxen [markdown]. > Writing a > proper parser is too complicated if your language doesn't have parser > combinators. :) Haddock, I believe, is written in a language that does. If MathML output is desired at some point (e.g., if browsers start doing better at rendering it than at rendering images with TeX source-code alt-texts :) the I think Haddock will still be capable of handling a reasonable input language. jcc From ndmitchell at gmail.com Fri Feb 13 10:38:32 2009 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 13 10:28:41 2009 Subject: [Haskell-cafe] createProcess shutting file handles Message-ID: <404396ef0902130738h7c20ba29ve319c7a312c9320d@mail.gmail.com> Hi, I want to run multiple programs and dump the stdout/stderr to a file, I've tried doing: h <- openFile file WriteMode let c = CreateProcess (RawCommand file []) Nothing Nothing Inherit (UseHandle h) (UseHandle h) False (_,_,_,pid) <- createProcess c waitForProcess pid hPutStrLn h "Test" But by the time I get to the hPutStrLn line it says: Main: test.log: hPutStr: illegal operation (handle is closed) What have I done wrong? Did createProcess close the handle, and is there a way round this? This is using GHC 6.10 on Windows with the new process-1.0.1.1 Thanks Neil From lemming at henning-thielemann.de Fri Feb 13 10:45:34 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 13 10:35:38 2009 Subject: [Haskell-cafe] Language popularity In-Reply-To: <20090213150704.3a1e5bc2@greenrd.org> References: <20090213150704.3a1e5bc2@greenrd.org> Message-ID: <4995959E.1060405@henning-thielemann.de> Robin Green wrote: > > I think we can fairly safely discount the commercial relevance of any > language ranking which places LOGO so highly. > > It may be that a lot of people *know* LOGO (or claim to know it), but > that does not mean that is used a lot for commercial programming. If we discuss here about a new Haskell LOGO - does this also count as a hit for LOGO programming language? From d at domob.eu Fri Feb 13 11:11:52 2009 From: d at domob.eu (Daniel Kraft) Date: Fri Feb 13 10:57:25 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC In-Reply-To: <49958F91.7010500@henning-thielemann.de> References: <49958F91.7010500@henning-thielemann.de> Message-ID: <49959BC8.9060601@domob.eu> Hi, Henning Thielemann wrote: > Daniel Kraft wrote: >> I noticed last year Haskell.org was a mentoring organization for >> Google's Summer of Code, and I barely noticed some discussion about it >> applying again this year :) >> >> I participated for GCC in 2008 and would like to try again this year; >> while I'm still active for GCC and will surely stay so, I'd like to >> see something new at least for GSoC. And Haskell.org would surely be >> a very, very nice organization. >> >> Since I discovered there's more than just a lot of imperative >> languages that are nearly all the same, I love to do some programming >> in Prolog, Scheme and of course Haskell. However, so far this was >> only some toy programs and nothing "really useful"; I'd like to change >> this (as well as learning more about Haskell during the projects). >> >> - A basic symbolic maths package; I've no idea how far one could do >> this as a single GSoC project, but it would surely be a very >> interesting task. Alternatively or in combination, one could try to >> use an existing free CAS package as engine. > > DoCon? hm, I've only read a little on their webpage; what I was thinking of was to implement a very basic package just to do some symbolic integration or equation solving to be embedded in some other calculation, and DoCon sounds like a more abstract, mathematical system. So maybe there could still be some interest in a basic symbolic expression package that could be backed by a CAS library like GiNaC or some other one (better yet, pluggable) instead of imlementing a full CAS itself. Daniel From lemming at henning-thielemann.de Fri Feb 13 11:14:28 2009 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri Feb 13 11:04:07 2009 Subject: [Haskell-cafe] Re: Haskell.org GSoC In-Reply-To: <49959BC8.9060601@domob.eu> References: <49958F91.7010500@henning-thielemann.de> <49959BC8.9060601@domob.eu> Message-ID: On Fri, 13 Feb 2009, Daniel Kraft wrote: > Henning Thielemann wrote: >> DoCon? > > hm, I've only read a little on their webpage; what I was thinking of was to > implement a very basic package just to do some symbolic integration or > equation solving to be embedded in some other calculation, and DoCon sounds > like a more abstract, mathematical system. > > So maybe there could still be some interest in a basic symbolic expression > package that could be backed by a CAS library like GiNaC or some other one > (better yet, pluggable) instead of imlementing a full CAS itself. So it seems to be useful to make the distinction: * Computer algebra is doing advanced arithmetic on advanced mathematical objects like polynomials, Galois groups, function compositions (for integration). This is what DoCon is about (integration excluded). * Symbolic manipulation is what you are after, where symbolic manipulation often involves computer algebra behind the scenes (i.e. translating symbolic expressions to polynomials, function compositions) From bugfact at gmail.com Fri Feb 13 11:16:23 2009 From: bugfact at gmail.com (Peter Verswyvelen) Date: Fri Feb 13 11:07:18 2009 Subject: [Haskell-cafe] Possible bug? Message-ID: Could it be considered a