From dedgrant at gmail.com Sun Feb 1 07:15:19 2015 From: dedgrant at gmail.com (Darren Grant) Date: Sat, 31 Jan 2015 23:15:19 -0800 Subject: [Haskell-cafe] Template Haskell attempts to load mingw32.dll during build Message-ID: Hi all, Windows GHC 7.8.4 build issue here: I've noticed that GHC will attempt to link mingw32 if a related dependency (in my case sdl2) is required in a TH pass. Unsurprisingly, the OS fails to find the imaginary mingw32.dll file. Are there any known resolutions to this quirk? Cheers, Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sun Feb 1 08:46:01 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun, 01 Feb 2015 09:46:01 +0100 Subject: [Haskell-cafe] Template Haskell attempts to load mingw32.dll during build In-Reply-To: References: Message-ID: On Sun, 01 Feb 2015 08:15:19 +0100, Darren Grant wrote: > Hi all, > > Windows GHC 7.8.4 build issue here: > > I've noticed that GHC will attempt to link mingw32 if a related > dependency > (in my case sdl2) is required in a TH pass. Unsurprisingly, the OS fails > to > find the imaginary mingw32.dll file. > > Are there any known resolutions to this quirk? It seems that Stack Overflow has the answer: http://stackoverflow.com/questions/15996796/haskell-sdl-cant-find-mingw32-dll Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From dedgrant at gmail.com Sun Feb 1 14:47:53 2015 From: dedgrant at gmail.com (Darren Grant) Date: Sun, 1 Feb 2015 06:47:53 -0800 Subject: [Haskell-cafe] Template Haskell attempts to load mingw32.dll during build In-Reply-To: References: Message-ID: Hi, This is a bit different. The SDL dependencies are configured correctly and I can link against standard Haskell programs, but a TH build phase fails. Cheers, Darren On Feb 1, 2015 3:46 AM, "Henk-Jan van Tuyl" wrote: > On Sun, 01 Feb 2015 08:15:19 +0100, Darren Grant > wrote: > > Hi all, >> >> Windows GHC 7.8.4 build issue here: >> >> I've noticed that GHC will attempt to link mingw32 if a related dependency >> (in my case sdl2) is required in a TH pass. Unsurprisingly, the OS fails >> to >> find the imaginary mingw32.dll file. >> >> Are there any known resolutions to this quirk? >> > > It seems that Stack Overflow has the answer: > http://stackoverflow.com/questions/15996796/haskell- > sdl-cant-find-mingw32-dll > > Regards, > Henk-Jan van Tuyl > > > -- > Folding at home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://folding.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doaitse at swierstra.net Sun Feb 1 21:42:14 2015 From: doaitse at swierstra.net (S. Doaitse Swierstra) Date: Sun, 1 Feb 2015 22:42:14 +0100 Subject: [Haskell-cafe] cpp question Message-ID: <19EE3E8A-05F2-410E-A34E-03B8CC61C140@swierstra.net> With the new version of GHC (7.8.3) I am running into problems with cpp. The header of one of the files of my uu-parsinglib library reads as follows: {-# LANGUAGE NoMonomorphismRestriction, RankNTypes, FlexibleContexts, CPP #-} #define DEMO(p,i) demo "p" i p #define DEMOG(p,i) demo "p" i (mkP (p)) module Text.ParserCombinators.UU.Demo.MergeAndPermute where ... However when I try to compile this file I get error messages like: Text/ParserCombinators/UU/Demo/Demo.hs:88:17: Not in scope: data constructor ?DEMOG? So it seems that the cpp is no longer called at all. Any hints? I am running: MacBook-Doaitse:src doaitse$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 MacBook-Doaitse:src doaitse$ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix MacBook-Doaitse:src doaitse$ Any help is appreciated, Doaitse Swierstra From allbery.b at gmail.com Sun Feb 1 21:51:34 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 1 Feb 2015 16:51:34 -0500 Subject: [Haskell-cafe] cpp question In-Reply-To: <19EE3E8A-05F2-410E-A34E-03B8CC61C140@swierstra.net> References: <19EE3E8A-05F2-410E-A34E-03B8CC61C140@swierstra.net> Message-ID: On Sun, Feb 1, 2015 at 4:42 PM, S. Doaitse Swierstra wrote: > With the new version of GHC (7.8.3) I am running into problems with cpp. > > The header of one of the files of my uu-parsinglib library reads as > follows: > > {-# LANGUAGE NoMonomorphismRestriction, > RankNTypes, > FlexibleContexts, > CPP #-} > #define DEMO(p,i) demo "p" i p > #define DEMOG(p,i) demo "p" i (mkP (p)) > module Text.ParserCombinators.UU.Demo.MergeAndPermute where > > ... > > However when I try to compile this file I get error messages like: > > Text/ParserCombinators/UU/Demo/Demo.hs:88:17: > Not in scope: data constructor ?DEMOG? > (1) ghc is at 7.8.4. I *think* 7.8.4 does slightly better here, but only slightly: (2) May I guess that Demo.hs line 88 starts with an identifier with a prime in it? GHC 7.8.3 on OS X tries to make clang's cpp behave like gcc's, but does not completely succeed; clang's cpp will ignore macros in what it thinks are quoted strings/chars, so fails when faced with things like foo' = ... something using a cpp macro here ... One workaround is to install ghc from MacPorts (forces gcc's cpp) or the github ghcformacosx repo (which I think is Homebrew-based? so it depends on how much you like code with no error checking to speak of and curl-pipe-sh "hack me please" installation). 7.8.4 may also provide some way to point cpp to "gcc --traditional -E". Long term, we need to move away from using a C preprocessor for Haskell code; there are no guarantees that it won't try to enforce C syntax on you, like clang's does. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Sun Feb 1 22:00:42 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Sun, 01 Feb 2015 22:00:42 +0000 Subject: [Haskell-cafe] cpp question In-Reply-To: References: <19EE3E8A-05F2-410E-A34E-03B8CC61C140@swierstra.net> Message-ID: If cpp is troublesome, another workaround might be to persuade ghc to use cpphs, which at least is aware of Haskell syntax. Regards, Malcolm (iPhone) On 1 Feb 2015, at 21:51, Brandon Allbery wrote: On Sun, Feb 1, 2015 at 4:42 PM, S. Doaitse Swierstra wrote: > With the new version of GHC (7.8.3) I am running into problems with cpp. > > The header of one of the files of my uu-parsinglib library reads as follows: > > {-# LANGUAGE NoMonomorphismRestriction, > RankNTypes, > FlexibleContexts, > CPP #-} > #define DEMO(p,i) demo "p" i p > #define DEMOG(p,i) demo "p" i (mkP (p)) > module Text.ParserCombinators.UU.Demo.MergeAndPermute where > > ... > > However when I try to compile this file I get error messages like: > > Text/ParserCombinators/UU/Demo/Demo.hs:88:17: > Not in scope: data constructor ?DEMOG? (1) ghc is at 7.8.4. I *think* 7.8.4 does slightly better here, but only slightly: (2) May I guess that Demo.hs line 88 starts with an identifier with a prime in it? GHC 7.8.3 on OS X tries to make clang's cpp behave like gcc's, but does not completely succeed; clang's cpp will ignore macros in what it thinks are quoted strings/chars, so fails when faced with things like foo' = ... something using a cpp macro here ... One workaround is to install ghc from MacPorts (forces gcc's cpp) or the github ghcformacosx repo (which I think is Homebrew-based? so it depends on how much you like code with no error checking to speak of and curl-pipe-sh "hack me please" installation). 7.8.4 may also provide some way to point cpp to "gcc --traditional -E". Long term, we need to move away from using a C preprocessor for Haskell code; there are no guarantees that it won't try to enforce C syntax on you, like clang's does. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Mon Feb 2 01:38:26 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Mon, 02 Feb 2015 10:38:26 +0900 (JST) Subject: [Haskell-cafe] parallelism and purity Message-ID: <20150202.103826.261727257665812021.kazu@iij.ad.jp> Hi cafe, I received questions about parallelism in Haskell. I'm familiar with concurrency but not with parallelism. So, let me ask: Q1) Are there any *applications* using Haskell parallelism? Q2) What kind of parallelism is used in the application? - Task parallel - Data parallel - Data-flow paralle? - etc Q3) Does Haskell purity contribute for the application in the parallelism point of view? I'm one of the translators of "Parallel and Concurrent Programming in Haskell" into Japanese. So, please don't say read the book. :-) --Kazu From ivan.miljenovic at gmail.com Mon Feb 2 05:22:10 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 2 Feb 2015 16:22:10 +1100 Subject: [Haskell-cafe] ANNOUNCE: monad-levels Message-ID: I'm pleased to announce the first release of my new monad-levels library (aka Yet Another Monad Transformer Library ;-) http://hackage.haskell.org/package/monad-levels I've written more about the motivations of the library here: https://ivanmiljenovic.wordpress.com/2015/02/02/monadic-yak-shaving/ -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From magicloud.magiclouds at gmail.com Mon Feb 2 09:27:27 2015 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Mon, 2 Feb 2015 17:27:27 +0800 Subject: [Haskell-cafe] What could be the possible reason of linking errors on "_info" and "_closure"? Message-ID: Hi, I am making a cabal project including a library and a executable using the library. Building the library is fine. But when linking src/main, I got "undefined reference to someFunction1_info" and "someFunction1_closure". -- ??????? ??????? And for G+, please use magiclouds#gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Mon Feb 2 09:28:39 2015 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Mon, 2 Feb 2015 17:28:39 +0800 Subject: [Haskell-cafe] What could be the possible reason of linking errors on "_info" and "_closure"? In-Reply-To: References: Message-ID: Sorry, my mistake. I had a misunderstanding of cabal file that I did not expose enough modules. On Mon, Feb 2, 2015 at 5:27 PM, Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Hi, > > I am making a cabal project including a library and a executable using > the library. > > Building the library is fine. But when linking src/main, I got > "undefined reference to someFunction1_info" and "someFunction1_closure". > > -- > ??????? > ??????? > > And for G+, please use magiclouds#gmail.com. > -- ??????? ??????? And for G+, please use magiclouds#gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.keil at gmail.com Mon Feb 2 11:21:43 2015 From: jochen.keil at gmail.com (Jochen Keil) Date: Mon, 02 Feb 2015 12:21:43 +0100 Subject: [Haskell-cafe] GHC API - list all exports of a module Message-ID: <54CF5DC7.4080507@gmail.com> Dear Cafe, currently I'm working on a small program for which I need a list of all *exported* function and data types. In order to achieve this I've been toying around with the GHC API. My observations so far: * Using the pure `parser` function yields a `HsModule` object, which gives me a list of all exports and all declarations (internal & exported). I cannot or don't know how to use the list of exports (just `RdrName`s) to filter the declarations. * Using `parseModule` (which is essentially the same as the `parser` function) and `typecheckModule` on a `ModuleGraph` yields a `TypecheckedModule` object which contains a list of exported `Name`s which in turn can be used to get additional information about them. So, the second approach seems more promising, but I'm not too happy with it. The reason is that calling `typecheckModule` results in a compilation of the module and all of its dependencies, which I think is not necessary for what I want to achieve. This is especially cumbersome for large modules like `GHC.hs` where I'm struggling to figure out all of the dependencies without the build system. My main goal would be to have a program which takes two modules of different versions, compare them and highlight the differences between them. I think that'd be helpful for upgrading dependant packages or for writing compatibility layers. Thank you and all the best, Jochen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From simons at cryp.to Mon Feb 2 11:31:32 2015 From: simons at cryp.to (Peter Simons) Date: Mon, 02 Feb 2015 12:31:32 +0100 Subject: [Haskell-cafe] GHC API - list all exports of a module References: <54CF5DC7.4080507@gmail.com> Message-ID: <877fw0lfcb.fsf@write-only.cryp.to> Hi Jochen, > My main goal would be to have a program which takes two modules of > different versions, compare them and highlight the differences > between them. maybe http://hackage.haskell.org/package/hackage-diff would work for your purposes? Best regards, Peter From jochen.keil at gmail.com Mon Feb 2 11:46:46 2015 From: jochen.keil at gmail.com (Jochen Keil) Date: Mon, 02 Feb 2015 12:46:46 +0100 Subject: [Haskell-cafe] GHC API - list all exports of a module In-Reply-To: <877fw0lfcb.fsf@write-only.cryp.to> References: <54CF5DC7.4080507@gmail.com> <877fw0lfcb.fsf@write-only.cryp.to> Message-ID: <54CF63A6.6080109@gmail.com> Hello Peter, On 02.02.2015 12:31, Peter Simons wrote: > Hi Jochen, > > > My main goal would be to have a program which takes two modules of > > different versions, compare them and highlight the differences > > between them. > > maybe http://hackage.haskell.org/package/hackage-diff would work for > your purposes? Thanks for the hint, this looks pretty good. One thing though: hackage-diff uses haskell-src-exts for parsing modules. Does haskell-src-exts re-use the GHC API or does it run its own parser? (from a quick glance I'd say the latter case) Cheers, Jochen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From hesselink at gmail.com Mon Feb 2 11:55:41 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 2 Feb 2015 12:55:41 +0100 Subject: [Haskell-cafe] GHC API - list all exports of a module In-Reply-To: <54CF63A6.6080109@gmail.com> References: <54CF5DC7.4080507@gmail.com> <877fw0lfcb.fsf@write-only.cryp.to> <54CF63A6.6080109@gmail.com> Message-ID: On Mon, Feb 2, 2015 at 12:46 PM, Jochen Keil wrote: > Hello Peter, > > On 02.02.2015 12:31, Peter Simons wrote: >> Hi Jochen, >> >> > My main goal would be to have a program which takes two modules of >> > different versions, compare them and highlight the differences >> > between them. >> >> maybe http://hackage.haskell.org/package/hackage-diff would work for >> your purposes? > > Thanks for the hint, this looks pretty good. > > One thing though: hackage-diff uses haskell-src-exts for parsing > modules. Does haskell-src-exts re-use the GHC API or does it run its own > parser? (from a quick glance I'd say the latter case) There are basically two routes to choose from with such a tool (of which a few already exist, I think): you can use GHC and its API, like you're doing, or you can use haskell-src-exts, which is a separate parser, and use haskell-names for name resolution (and haskell-packages for dependency information). Sadly there's no haskell-type-exts for typechecking (yet). The GHC route is probably more powerful, the haskell-suite route is simpler and doesn't depend on GHC. Regards, Erik From alan.zimm at gmail.com Mon Feb 2 12:30:52 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 2 Feb 2015 14:30:52 +0200 Subject: [Haskell-cafe] GHC API - list all exports of a module In-Reply-To: References: <54CF5DC7.4080507@gmail.com> <877fw0lfcb.fsf@write-only.cryp.to> <54CF63A6.6080109@gmail.com> Message-ID: Also, prior to GHC 7.10, there are serious gotchas to processing the GHC API Parsed Source, as certain fields are initialised to a `panic "xxx"` value, and should never be accessed. Alan On Mon, Feb 2, 2015 at 1:55 PM, Erik Hesselink wrote: > On Mon, Feb 2, 2015 at 12:46 PM, Jochen Keil > wrote: > > Hello Peter, > > > > On 02.02.2015 12:31, Peter Simons wrote: > >> Hi Jochen, > >> > >> > My main goal would be to have a program which takes two modules of > >> > different versions, compare them and highlight the differences > >> > between them. > >> > >> maybe http://hackage.haskell.org/package/hackage-diff would work for > >> your purposes? > > > > Thanks for the hint, this looks pretty good. > > > > One thing though: hackage-diff uses haskell-src-exts for parsing > > modules. Does haskell-src-exts re-use the GHC API or does it run its own > > parser? (from a quick glance I'd say the latter case) > > There are basically two routes to choose from with such a tool (of > which a few already exist, I think): you can use GHC and its API, like > you're doing, or you can use haskell-src-exts, which is a separate > parser, and use haskell-names for name resolution (and > haskell-packages for dependency information). Sadly there's no > haskell-type-exts for typechecking (yet). The GHC route is probably > more powerful, the haskell-suite route is simpler and doesn't depend > on GHC. > > Regards, > > Erik > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dedgrant at gmail.com Mon Feb 2 16:48:04 2015 From: dedgrant at gmail.com (Darren Grant) Date: Mon, 2 Feb 2015 08:48:04 -0800 Subject: [Haskell-cafe] Template Haskell attempts to load mingw32.dll during build In-Reply-To: References: Message-ID: As a followup, this is an old GHCi bug: https://ghc.haskell.org/trac/ghc/ticket/3242?cversion=0&cnum_hist=29 I'm not sure if anyone else has made headway here, but I'll see if I can patch the GHC loader for mingw. Cheers, Darren Hi, This is a bit different. The SDL dependencies are configured correctly and I can link against standard Haskell programs, but a TH build phase fails. Cheers, Darren On Feb 1, 2015 3:46 AM, "Henk-Jan van Tuyl" wrote: > On Sun, 01 Feb 2015 08:15:19 +0100, Darren Grant > wrote: > > Hi all, >> >> Windows GHC 7.8.4 build issue here: >> >> I've noticed that GHC will attempt to link mingw32 if a related dependency >> (in my case sdl2) is required in a TH pass. Unsurprisingly, the OS fails >> to >> find the imaginary mingw32.dll file. >> >> Are there any known resolutions to this quirk? >> > > It seems that Stack Overflow has the answer: > http://stackoverflow.com/questions/15996796/haskell- > sdl-cant-find-mingw32-dll > > Regards, > Henk-Jan van Tuyl > > > -- > Folding at home > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://folding.stanford.edu/ > > > http://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.keil at gmail.com Mon Feb 2 16:58:29 2015 From: jochen.keil at gmail.com (Jochen Keil) Date: Mon, 02 Feb 2015 17:58:29 +0100 Subject: [Haskell-cafe] GHC API - list all exports of a module In-Reply-To: References: <54CF5DC7.4080507@gmail.com> <877fw0lfcb.fsf@write-only.cryp.to> <54CF63A6.6080109@gmail.com> Message-ID: <54CFACB5.5020505@gmail.com> Hi Erik, On 02.02.2015 12:55, Erik Hesselink wrote: > On Mon, Feb 2, 2015 at 12:46 PM, Jochen Keil wrote: >> Hello Peter, >> >> On 02.02.2015 12:31, Peter Simons wrote: >>> Hi Jochen, >>> >>> > My main goal would be to have a program which takes two modules of >>> > different versions, compare them and highlight the differences >>> > between them. >>> >>> maybe http://hackage.haskell.org/package/hackage-diff would work for >>> your purposes? >> >> Thanks for the hint, this looks pretty good. >> >> One thing though: hackage-diff uses haskell-src-exts for parsing >> modules. Does haskell-src-exts re-use the GHC API or does it run its own >> parser? (from a quick glance I'd say the latter case) > > There are basically two routes to choose from with such a tool (of > which a few already exist, I think): you can use GHC and its API, like > you're doing, or you can use haskell-src-exts, which is a separate > parser, and use haskell-names for name resolution (and > haskell-packages for dependency information). Sadly there's no > haskell-type-exts for typechecking (yet). The GHC route is probably > more powerful, the haskell-suite route is simpler and doesn't depend > on GHC. thanks for the clarification! Indeed it seems to me that the GHC approach is more powerful, because after running the typechecker I would have the AST available for comparing modules (did I get this right?). Drawback would obviously be the need for running the typechecker. :) So, just for the sake of my curiosity: Is there a way to get the exported declarations (and not just the RdrNames) from GHC without running the typechecker? I don't understand why it's necessary to run the typechecker in order to get this list. The parser already returns a list with all declarations, so shouldn't it be possible to filter this list for only the exported ones? Thanks, Jochen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From alan.zimm at gmail.com Mon Feb 2 17:36:03 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 2 Feb 2015 19:36:03 +0200 Subject: [Haskell-cafe] GHC API - list all exports of a module In-Reply-To: <54CFACB5.5020505@gmail.com> References: <54CF5DC7.4080507@gmail.com> <877fw0lfcb.fsf@write-only.cryp.to> <54CF63A6.6080109@gmail.com> <54CFACB5.5020505@gmail.com> Message-ID: Have you looked at ModuleInfo [1] ? This is accesible from a TypecheckedModule. And what do you mean by the exported declarations? If you are prepared to use the HaRe API (ony up to GHC 7.6.3) you can use definingDeclsNames [2] [1] https://downloads.haskell.org/~ghc/7.8.3/docs/html/libraries/ghc-7.8.3/GHC.html#t:ModuleInfo [2] http://hackage.haskell.org/package/HaRe-0.7.2.8/docs/Language-Haskell-Refact-API.html#v:definingDeclsNames On Mon, Feb 2, 2015 at 6:58 PM, Jochen Keil wrote: > Hi Erik, > > On 02.02.2015 12:55, Erik Hesselink wrote: > > On Mon, Feb 2, 2015 at 12:46 PM, Jochen Keil > wrote: > >> Hello Peter, > >> > >> On 02.02.2015 12:31, Peter Simons wrote: > >>> Hi Jochen, > >>> > >>> > My main goal would be to have a program which takes two modules of > >>> > different versions, compare them and highlight the differences > >>> > between them. > >>> > >>> maybe http://hackage.haskell.org/package/hackage-diff would work for > >>> your purposes? > >> > >> Thanks for the hint, this looks pretty good. > >> > >> One thing though: hackage-diff uses haskell-src-exts for parsing > >> modules. Does haskell-src-exts re-use the GHC API or does it run its own > >> parser? (from a quick glance I'd say the latter case) > > > > There are basically two routes to choose from with such a tool (of > > which a few already exist, I think): you can use GHC and its API, like > > you're doing, or you can use haskell-src-exts, which is a separate > > parser, and use haskell-names for name resolution (and > > haskell-packages for dependency information). Sadly there's no > > haskell-type-exts for typechecking (yet). The GHC route is probably > > more powerful, the haskell-suite route is simpler and doesn't depend > > on GHC. > > thanks for the clarification! > Indeed it seems to me that the GHC approach is more powerful, because > after running the typechecker I would have the AST available for > comparing modules (did I get this right?). Drawback would obviously be > the need for running the typechecker. :) > > So, just for the sake of my curiosity: > Is there a way to get the exported declarations (and not just the > RdrNames) from GHC without running the typechecker? > I don't understand why it's necessary to run the typechecker in order to > get this list. The parser already returns a list with all declarations, > so shouldn't it be possible to filter this list for only the exported ones? > > Thanks, > Jochen > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reilithion at gmail.com Mon Feb 2 17:48:53 2015 From: reilithion at gmail.com (Lucas Paul) Date: Mon, 2 Feb 2015 10:48:53 -0700 Subject: [Haskell-cafe] Cabal config file - default install flags? In-Reply-To: References: Message-ID: That seems to have done the trick. Thanks! On Sat, Jan 31, 2015 at 3:15 PM, Konstantine Rybnikov wrote: > Hi Lucas. > > Just put `jobs: $ncpus` into your ~/.cabal/config wile. I believe > documentation is somewhere inside cabal manual, please take a look there. > > Hope this helps. > > On Sat, Jan 31, 2015 at 11:02 PM, Lucas Paul wrote: >> >> I'd like to have cabal automatically use -j8 when I cabal install >> something. Is there something I can put into the .cabal/config file >> that will accomplish this? >> >> More generally, where can I find documentation on that config file? >> >> - Lucas Paul >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > From jochen.keil at gmail.com Mon Feb 2 19:05:54 2015 From: jochen.keil at gmail.com (Jochen Keil) Date: Mon, 02 Feb 2015 20:05:54 +0100 Subject: [Haskell-cafe] GHC API - list all exports of a module In-Reply-To: References: <54CF5DC7.4080507@gmail.com> <877fw0lfcb.fsf@write-only.cryp.to> <54CF63A6.6080109@gmail.com> <54CFACB5.5020505@gmail.com> Message-ID: <54CFCA92.2080208@gmail.com> Hi, On 02.02.2015 18:36, Alan & Kim Zimmerman wrote: > Have you looked at ModuleInfo [1] ? Yes, that's the path I went after type checking the module. There's also ModIface which could be suitable for my purpose. > And what do you mean by the exported declarations? I'm sorry if I didn't make my intent clear enough. There's the pure parser [1], which (at least I think so) is also used for parseModule [2]. This results in a HsModule object [3]. HsModule provides amongst others a field for exports [4] and *all* declarations [5]. I am explicitly only interested in *exported declarations*. But I don't see how I could combine [4] and [5] to achieve that, while avoiding to run the type checker. Sorry again if I was or still am unclear, but I hope it's better now. :) Cheers, Jochen [1] https://downloads.haskell.org/~ghc/7.8.3/docs/html/libraries/ghc-7.8.3/GHC.html#v:parser [2] https://downloads.haskell.org/~ghc/7.8.3/docs/html/libraries/ghc-7.8.3/GHC.html#v:parseModule [3] https://downloads.haskell.org/~ghc/7.8.3/docs/html/libraries/ghc-7.8.3/HsSyn.html#t:HsModule [4] https://downloads.haskell.org/~ghc/7.8.3/docs/html/libraries/ghc-7.8.3/HsSyn.html#v:hsmodExports [5] https://downloads.haskell.org/~ghc/7.8.3/docs/html/libraries/ghc-7.8.3/HsSyn.html#v:hsmodDecls > If you are prepared to use the HaRe API (ony up to GHC 7.6.3) you can use > definingDeclsNames [2] > > [1] > https://downloads.haskell.org/~ghc/7.8.3/docs/html/libraries/ghc-7.8.3/GHC.html#t:ModuleInfo > [2] > http://hackage.haskell.org/package/HaRe-0.7.2.8/docs/Language-Haskell-Refact-API.html#v:definingDeclsNames > > > > > On Mon, Feb 2, 2015 at 6:58 PM, Jochen Keil wrote: > >> Hi Erik, >> >> On 02.02.2015 12:55, Erik Hesselink wrote: >>> On Mon, Feb 2, 2015 at 12:46 PM, Jochen Keil >> wrote: >>>> Hello Peter, >>>> >>>> On 02.02.2015 12:31, Peter Simons wrote: >>>>> Hi Jochen, >>>>> >>>>> > My main goal would be to have a program which takes two modules of >>>>> > different versions, compare them and highlight the differences >>>>> > between them. >>>>> >>>>> maybe http://hackage.haskell.org/package/hackage-diff would work for >>>>> your purposes? >>>> >>>> Thanks for the hint, this looks pretty good. >>>> >>>> One thing though: hackage-diff uses haskell-src-exts for parsing >>>> modules. Does haskell-src-exts re-use the GHC API or does it run its own >>>> parser? (from a quick glance I'd say the latter case) >>> >>> There are basically two routes to choose from with such a tool (of >>> which a few already exist, I think): you can use GHC and its API, like >>> you're doing, or you can use haskell-src-exts, which is a separate >>> parser, and use haskell-names for name resolution (and >>> haskell-packages for dependency information). Sadly there's no >>> haskell-type-exts for typechecking (yet). The GHC route is probably >>> more powerful, the haskell-suite route is simpler and doesn't depend >>> on GHC. >> >> thanks for the clarification! >> Indeed it seems to me that the GHC approach is more powerful, because >> after running the typechecker I would have the AST available for >> comparing modules (did I get this right?). Drawback would obviously be >> the need for running the typechecker. :) >> >> So, just for the sake of my curiosity: >> Is there a way to get the exported declarations (and not just the >> RdrNames) from GHC without running the typechecker? >> I don't understand why it's necessary to run the typechecker in order to >> get this list. The parser already returns a list with all declarations, >> so shouldn't it be possible to filter this list for only the exported ones? >> >> Thanks, >> Jochen >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From madhub.bits at gmail.com Wed Feb 4 03:23:42 2015 From: madhub.bits at gmail.com (Madhu Babu) Date: Tue, 3 Feb 2015 22:23:42 -0500 Subject: [Haskell-cafe] ghc --make Vs runhaskell Message-ID: Hi !, I have the following program from ?Learn You a Haskell? ( http://learnyouahaskell.com/input-and-output#randomness ). When i run this using runhaskell, code works perfectly fine. However, when i compile and run the binary file, code behaves differently. Basically, in the following code, we print a line first and the read the line from stdin. This behavior works perfectly fine when using ?runhaskell guess.hs?. But when i say ?./guess?, i had to type in a number directly ( i.e. first prompt is skipped ). btw.. i am using mac yosomite command terminal. Any help greatly appreciated.. Thanks a lot in advance.. import System.Random import Control.Monad(when) main = do ranGen <- getStdGen let (rand,_) = randomR (1,10) ranGen :: (Int,StdGen) putStr "Guess a number between 1 and 10 : " numStr <- getLine when(not $ null numStr) $ do let num = read numStr if rand == num then putStrLn "Yuhaa!! you are right baby!" else putStrLn $ "Sorry dude!! it was " ++ show rand newStdGen main -------------- next part -------------- An HTML attachment was scrubbed... URL: From mithrandi at mithrandi.net Wed Feb 4 03:35:45 2015 From: mithrandi at mithrandi.net (Tristan Seligmann) Date: Wed, 4 Feb 2015 05:35:45 +0200 Subject: [Haskell-cafe] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: On 4 February 2015 at 05:23, Madhu Babu wrote: > Basically, in the following code, we print a line first and the read the > line from stdin. This behavior works perfectly fine when using ?runhaskell > guess.hs?. But when i say ?./guess?, i had to type in a number directly ( > i.e. first prompt is skipped ). This is most likely due to stdio buffering; usually stdin/stdout are line buffered, so data you write with putStr may not actually be written until a newline is written. This post / thread details some ways to handle this problem: https://www.haskell.org/pipermail/beginners/2010-March/003692.html -- mithrandi, i Ainil en-Balandor, a faer Ambar From allbery.b at gmail.com Wed Feb 4 03:35:59 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 3 Feb 2015 22:35:59 -0500 Subject: [Haskell-cafe] [Haskell-beginners] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: On Tue, Feb 3, 2015 at 10:23 PM, Madhu Babu wrote: > Basically, in the following code, we print a line first and the read the > line from stdin. This behavior works perfectly fine when using ?runhaskell > guess.hs?. But when i say ?./guess?, i had to type in a number directly ( > i.e. first prompt is skipped ). > runhaskell is presumably using unbuffered I/O for some reason, so outputting directly to the terminal. The compiled program follows standard Unix buffering conventions: line buffering on output to a terminal, so the putStr is sitting in a buffer waiting to see a newline output. C / C++ programs also do buffering, but there's a heinous hack which detects reads on stdin and flushes stdout beforehand. (Heinous because there is no guarantee that they are actually related --- but na?ve programmers invariably do not learn about line buffering and expect all output to be unbuffered(*), and C standard library programmers eventually gave up and catered to them after years of trying to get them to pay attention. I have a nasty suspicion we're going to end up with a similar horrible hack in Haskell eventually.) You can use hFlush from System.IO to flush the prompt out to the terminal, or disable output buffering with hSetBuffering in the same module. (*) At some point someone will pop up and say that on modern computers, buffering is obsolete because it's fast enough that horribly inefficient character-at-a-time I/O is good enough. Yet, I can *still* see visible hesitations when character-at-a-time I/O is used on a modern Intel core i5/i7. And your disk benchmarks will *tank* even with server-class disk subsystems. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Wed Feb 4 03:45:07 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 4 Feb 2015 10:45:07 +0700 Subject: [Haskell-cafe] [Haskell-beginners] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: Hey Madhu, Right, this is another gotcha -- haskell has a bunch of them. As Tristan and Brandon have remarked, the runhaskell interpreter and compiled programs handle output buffering differently. Here are changes to make your game work: On Wed, Feb 4, 2015 at 10:23 AM, Madhu Babu wrote: > import System.Random > import Control.Monad(when) > import System.IO > main = do > ranGen <- getStdGen > let (rand,_) = randomR (1,10) ranGen :: (Int,StdGen) > hSetBuffering stdout NoBuffering > putStr "Guess a number between 1 and 10 : " > You might want to take a look at the "Summing Two Numbers" section here: https://www.haskell.org/onlinereport/io.html -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhub.bits at gmail.com Wed Feb 4 04:57:16 2015 From: madhub.bits at gmail.com (Madhu Babu) Date: Tue, 3 Feb 2015 23:57:16 -0500 Subject: [Haskell-cafe] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: Thanks a lot. .this really helps.. On Feb 3, 2015 10:35 PM, "Tristan Seligmann" wrote: > On 4 February 2015 at 05:23, Madhu Babu wrote: > > Basically, in the following code, we print a line first and the read the > > line from stdin. This behavior works perfectly fine when using > ?runhaskell > > guess.hs?. But when i say ?./guess?, i had to type in a number directly ( > > i.e. first prompt is skipped ). > > This is most likely due to stdio buffering; usually stdin/stdout are > line buffered, so data you write with putStr may not actually be > written until a newline is written. This post / thread details some > ways to handle this problem: > > https://www.haskell.org/pipermail/beginners/2010-March/003692.html > -- > mithrandi, i Ainil en-Balandor, a faer Ambar > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holmisen at gmail.com Wed Feb 4 08:11:10 2015 From: holmisen at gmail.com (Johan Holmquist) Date: Wed, 4 Feb 2015 09:11:10 +0100 Subject: [Haskell-cafe] [Haskell-beginners] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: I just want to pop up and say that on modern computers... Seriously though, wouldn't it be reasonable if putStr flushed? Often in Haskell one constructs a long string to be output and there could still be buffering. On Feb 4, 2015 4:36 AM, "Brandon Allbery" wrote: > On Tue, Feb 3, 2015 at 10:23 PM, Madhu Babu wrote: > >> Basically, in the following code, we print a line first and the read the >> line from stdin. This behavior works perfectly fine when using ?runhaskell >> guess.hs?. But when i say ?./guess?, i had to type in a number directly ( >> i.e. first prompt is skipped ). >> > > runhaskell is presumably using unbuffered I/O for some reason, so > outputting directly to the terminal. The compiled program follows standard > Unix buffering conventions: line buffering on output to a terminal, so the > putStr is sitting in a buffer waiting to see a newline output. > > C / C++ programs also do buffering, but there's a heinous hack which > detects reads on stdin and flushes stdout beforehand. (Heinous because > there is no guarantee that they are actually related --- but na?ve > programmers invariably do not learn about line buffering and expect all > output to be unbuffered(*), and C standard library programmers eventually > gave up and catered to them after years of trying to get them to pay > attention. I have a nasty suspicion we're going to end up with a similar > horrible hack in Haskell eventually.) > > You can use hFlush from System.IO to flush the prompt out to the terminal, > or disable output buffering with hSetBuffering in the same module. > > (*) At some point someone will pop up and say that on modern computers, > buffering is obsolete because it's fast enough that horribly inefficient > character-at-a-time I/O is good enough. Yet, I can *still* see visible > hesitations when character-at-a-time I/O is used on a modern Intel core > i5/i7. And your disk benchmarks will *tank* even with server-class disk > subsystems. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khushil.dep at gmail.com Wed Feb 4 09:04:52 2015 From: khushil.dep at gmail.com (Khushil Dep) Date: Wed, 4 Feb 2015 01:04:52 -0800 (PST) Subject: [Haskell-cafe] hiring fp engineers for information security systems Message-ID: <440e5759-c80a-483a-b4da-f129ad71424c@googlegroups.com> About Guardtime We are team of US and Estonian scientists, network architects, software developers and security specialists who have decades of experience building cyber security solutions in our nations' military, supporting national objectives for mission and information assurance. In 2007 we invented Keyless Signature Infrastructure (KSI), a block-chain security technology designed for real-time detection and mitigation of cyber attack. About The Role We're looking for experienced functional software engineers to work on real-time backend systems dealing with high volume events. We need people who want to build systems to apply the power of workflow processing to security events to build deep intelligence platforms. We want people who understand the benefits of converged understanding over imperative understanding. About You - You should have an appetite for tackling complex and interesting software challenges. - Want to build systems that handle data on a global scale in a timely manner. - Have a strong understanding of Linux/UNIX kernel operations - Understand the value of documentation. - Be able to disseminate complex ideas to a wider audience. - Prepared to work in an agile but structured manner. - Prepared to travel in the E.U. - Prepared to travel to the U.S.A. on a quarterly basis. Minimum Qualifications - BS in Computer Science, Mathematics or Physics or equivalent work and life experience. - Clojure, Scala, Java, C/C++ Programming experience. - Large systems software design and development experience, with knowledge of Unix/Linux. Preferred Qualifications - MS or PhD in Computer Science, Mathematics or Physics. - Strong FP skills. - Strong competencies in data structures, algorithms, and software design. - Haskell, Clojure, Scala, Java, C/C++, NodeJS, Python programming experience, database design, knowledge of TCP/IP and network programming. Application Process In the first instance please send your C.V. and GitHub username (if you have one) to khushil.dep at guardtime.com. We have a two stage interview process and we hire quickly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Wed Feb 4 12:59:57 2015 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Wed, 4 Feb 2015 20:59:57 +0800 Subject: [Haskell-cafe] How does RTS judge that a STM transaction is blocked? Message-ID: Hi, I met an issue while I was using xhb. When a certain property of root window being changed, it was supposed to give me an AccessError. But actually I got "thread blocked indefinitely in an STM transaction" when I waitForEvent. AFAIK, in xhb, it forks a thread to read what X server sends. Then parse and put it into a TChan. waitForEvent reads from the TChan. It is reasonable to me that if X server did not send anything, then waitForEvent would be blocked. But apparently there are some other policies in RTS. So what is that? And how should I debug it? -- ??????? ??????? And for G+, please use magiclouds#gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From palotai.robin at gmail.com Wed Feb 4 13:42:32 2015 From: palotai.robin at gmail.com (Robin Palotai) Date: Wed, 4 Feb 2015 14:42:32 +0100 Subject: [Haskell-cafe] How does RTS judge that a STM transaction is blocked? In-Reply-To: References: Message-ID: More detail would be helpful, but sounds like an infinite (Async?) thread. Try bracket (newStablePtr a) freeStablePtr (const $ wait a) +google to find out why. 2015-02-04 13:59 GMT+01:00 Magicloud Magiclouds < magicloud.magiclouds at gmail.com>: > Hi, > > I met an issue while I was using xhb. When a certain property of root > window being changed, it was supposed to give me an AccessError. But > actually I got "thread blocked indefinitely in an STM transaction" when I > waitForEvent. > > AFAIK, in xhb, it forks a thread to read what X server sends. Then parse > and put it into a TChan. waitForEvent reads from the TChan. > > It is reasonable to me that if X server did not send anything, then > waitForEvent would be blocked. But apparently there are some other policies > in RTS. > > So what is that? And how should I debug it? > > -- > ??????? > ??????? > > And for G+, please use magiclouds#gmail.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Wed Feb 4 19:57:43 2015 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed, 4 Feb 2015 11:57:43 -0800 Subject: [Haskell-cafe] Haskell opportunities at Facebook Message-ID: Hi, friends ? I have a number of very interesting openings at Facebook HQ in Menlo Park, California. There are two different teams hiring. The first set of positions are for an entirely new team. This project involves distributed systems, data mining, and machine learning. There may be roles on this team for less experienced candidates in a few months, but right now we are looking for people who have written a reasonable amount of Haskell, have built real production systems in some language or other (and have the scars to prove it), and can contribute in major ways to the design and construction of a demanding new system that we're building from scratch. The second set of positions are for a cousin team, which is building on the success of our Haxl project to extend our capability to fight spam and malware. For these roles, we're open to a broader range of experience levels. If you're interested, please drop me an email with a current CV. Cheers, Bryan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpmoresmau at gmail.com Wed Feb 4 20:11:08 2015 From: jpmoresmau at gmail.com (JP Moresmau) Date: Wed, 4 Feb 2015 21:11:08 +0100 Subject: [Haskell-cafe] Haskell opportunities at Facebook In-Reply-To: References: Message-ID: "Facebook HQ in Menlo Park, California". So I take it, no remote workers accepted? Otherwise, looks like a great opportunity! JP On Wed, Feb 4, 2015 at 8:57 PM, Bryan O'Sullivan wrote: > Hi, friends ? > > I have a number of very interesting openings at Facebook HQ in Menlo Park, > California. There are two different teams hiring. > > The first set of positions are for an entirely new team. This project > involves distributed systems, data mining, and machine learning. There may > be roles on this team for less experienced candidates in a few months, but > right now we are looking for people who have written a reasonable amount of > Haskell, have built real production systems in some language or other (and > have the scars to prove it), and can contribute in major ways to the design > and construction of a demanding new system that we're building from scratch. > > The second set of positions are for a cousin team, which is building on > the success of our Haxl project to extend our capability to fight spam and > malware. For these roles, we're open to a broader range of experience > levels. > > If you're interested, please drop me an email with a current CV. > > Cheers, > Bryan. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- JP Moresmau http://jpmoresmau.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 4 21:07:13 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 04 Feb 2015 22:07:13 +0100 Subject: [Haskell-cafe] learn you a good haskell exercises Message-ID: <54D28A01.5040008@home.nl> Hello, If I want to look if I understand the contents of the book , are these good exercises : https://github.com/noelmarkham/learn-you-a-haskell-exercises Roelof From bob at redivi.com Wed Feb 4 21:13:52 2015 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 Feb 2015 13:13:52 -0800 Subject: [Haskell-cafe] learn you a good haskell exercises In-Reply-To: <54D28A01.5040008@home.nl> References: <54D28A01.5040008@home.nl> Message-ID: There's a much more comprehensive set of resources and exercises listed here: https://github.com/bitemyapp/learnhaskell - you're probably much better off with the CIS 194 lectures and assignments if you want exercises. On Wed, Feb 4, 2015 at 1:07 PM, Roelof Wobben wrote: > Hello, > > If I want to look if I understand the contents of the book , are these > good exercises : https://github.com/noelmarkham/learn-you-a- > haskell-exercises > > Roelof > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre_ at fastmail.com Wed Feb 4 21:23:59 2015 From: alexandre_ at fastmail.com (Alexandre Souza) Date: Wed, 04 Feb 2015 19:23:59 -0200 Subject: [Haskell-cafe] learn you a good haskell exercises In-Reply-To: <54D28A01.5040008@home.nl> References: <54D28A01.5040008@home.nl> Message-ID: <1423085039.156363.223202065.6F1F05AE@webmail.messagingengine.com> Roelof, Thank you, it is really useful. =] [ ]'s (hugs) -- [...]o sentido disso tudo ? que n?o h? sentido em tentar enlouquecer para impedir-se de ficar louco...guarde sua sanidade para mais tarde[...] - Douglas Adams On Wed, Feb 4, 2015, at 19:07, Roelof Wobben wrote: > Hello, > > If I want to look if I understand the contents of the book , are these > good exercises : > https://github.com/noelmarkham/learn-you-a-haskell-exercises > > Roelof > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From r.wobben at home.nl Wed Feb 4 21:25:00 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 04 Feb 2015 22:25:00 +0100 Subject: [Haskell-cafe] learn you a good haskell exercises In-Reply-To: References: <54D28A01.5040008@home.nl> Message-ID: <54D28E2C.4070302@home.nl> An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Wed Feb 4 21:26:49 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 4 Feb 2015 15:26:49 -0600 Subject: [Haskell-cafe] learn you a good haskell exercises In-Reply-To: <54D28E2C.4070302@home.nl> References: <54D28A01.5040008@home.nl> <54D28E2C.4070302@home.nl> Message-ID: Bob linked to my guide for learning Haskell which not Learn You A Haskell, it's a guide that recommends the use of cis194 and then the NICTA course for learning Haskell. Both of which are exercise driven. I'm also working on an exercise-driven book for learning Haskell http://haskellbook.com On Wed, Feb 4, 2015 at 3:25 PM, Roelof Wobben wrote: > Thanks, I have looked at learn yoiu a haskell for the greater but I > miss exercises there. > > Maybe I can better start with the realworld book. > > Roelof > > > Bob Ippolito schreef op 4-2-2015 om 22:13: > > There's a much more comprehensive set of resources and exercises listed > here: https://github.com/bitemyapp/learnhaskell - you're probably much > better off with the CIS 194 lectures and assignments if you want exercises. > > On Wed, Feb 4, 2015 at 1:07 PM, Roelof Wobben wrote: > >> Hello, >> >> If I want to look if I understand the contents of the book , are these >> good exercises : >> https://github.com/noelmarkham/learn-you-a-haskell-exercises >> >> Roelof >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Wed Feb 4 21:34:45 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Wed, 04 Feb 2015 22:34:45 +0100 Subject: [Haskell-cafe] learn you a good haskell exercises In-Reply-To: References: <54D28A01.5040008@home.nl> <54D28E2C.4070302@home.nl> <54D28FD3.3000808@home.nl> Message-ID: <54D29075.5050406@home.nl> An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Wed Feb 4 23:40:46 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 4 Feb 2015 15:40:46 -0800 Subject: [Haskell-cafe] RFC: rewrite-with-location proposal In-Reply-To: <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> References: <20131202220625.GA6022@x200> <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: I noticed a recent commit https://phabricator.haskell.org/D578 implements this. This is exciting! But I suppose it's too late for 7.10? Any chance of it making it in? I should note that to me the most interesting part of this has nothing to do with debugging. If you have a logging system, or tests, you need to have file name and line numbers. I've always done it via a custom preprocessor, but this extension would allow me to get rid of the preprocessor, which is very nice. It also seems simpler than the whole call stack thing because I only care about the first entry of the stack. On Thu, Dec 5, 2013 at 4:13 AM, Simon Peyton-Jones wrote: > Simon > > Interesting! > > There's been lot of work on this kind of thing, mostly collected here: > https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack > > I didn't know about your work, so I've added it. > > I'd be happy to see progress on this front. Tristan's "Finding the needle" stuff was close to "ready" but there were some awkward points (described in his paper) that meant he didn't feel it was done. > > To progress this, it'd be helpful to look at his work, articulate what the differences are, perhaps take the best of both, identify weak spots, and figure out what (if anything) should be done about them. > > We don't want the best to be the enemy of the good, but it's also worth ensuring that we take advantage of all the land-mine-discovery that earlier work has done. > > Simon > > | -----Original Message----- > | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf > | Of Simon Hengel > | Sent: 02 December 2013 22:06 > | To: Evan Laforge > | Cc: Haskell Cafe > | Subject: Re: [Haskell-cafe] RFC: rewrite-with-location proposal > | > | Hi Evan! > | > | On Mon, Dec 02, 2013 at 01:43:31PM -0800, Evan Laforge wrote: > | > Hey, whatever happened with this? > | > | My code for this is here: > | > | https://github.com/sol/ghc/commits/rewrite-with-location > | > | Revision 03e63f0a70ec8c0fece4049c2d714ea533494ec2 was fully functional, > | but it needs to be rebased on current master. The missing feature here > | is that type checking only happens on rewrite. I just added a wip > | commit with local modifications that do the type checking earlier, when > | the module with the rewrite pragma is compiled. > | > | > Is there anything in the way of getting this merged? Is there some > | > way I could help? > | > | This needs rebasing + I'm not sure if the wip commit currently compiles. > | I'm somewhat swamped, so I'm not sure when I'll have time to work on > | this. If you want to help, that would be awesome! I'm happy to help > | with any questions (solirc on freenode, feel free to say hello in #hspec > | ;). > | > | Cheers, > | Simon > | _______________________________________________ > | Haskell-Cafe mailing list > | Haskell-Cafe at haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-cafe From eric at seidel.io Wed Feb 4 23:51:24 2015 From: eric at seidel.io (Eric Seidel) Date: Wed, 04 Feb 2015 15:51:24 -0800 Subject: [Haskell-cafe] RFC: rewrite-with-location proposal In-Reply-To: (Evan Laforge's message of "Wed, 4 Feb 2015 15:40:46 -0800") References: <20131202220625.GA6022@x200> <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Evan Laforge writes: > I noticed a recent commit https://phabricator.haskell.org/D578 > implements this. This is exciting! But I suppose it's too late for > 7.10? Any chance of it making it in? Heh, I probably should have made some noise about it... But there are still some questions about to what extent to use it (if at all) in the standard libraries, so I doubt it would be a good candidate for a last minute merge to 7.10. I've actually been meaning to start a discussion about where/whether we should use this feature in base, but it slipped by the wayside. Thanks for the reminder! > I should note that to me the most interesting part of this has nothing > to do with debugging. If you have a logging system, or tests, you > need to have file name and line numbers. I've always done it via a > custom preprocessor, but this extension would allow me to get rid of > the preprocessor, which is very nice. It also seems simpler than the > whole call stack thing because I only care about the first entry of > the stack. Yep, my original motivation was getting access to source locations within embedded DSLs. The call-stack is a nice and easy extension, but I'm not sure how useful it will be in practice, as the first function that doesn't request a CallStack parameter will cut off the stack. This means that the generated stacks will often be quite short, I imagine. Eric From qdunkan at gmail.com Thu Feb 5 00:10:56 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 4 Feb 2015 16:10:56 -0800 Subject: [Haskell-cafe] RFC: rewrite-with-location proposal In-Reply-To: References: <20131202220625.GA6022@x200> <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: On Wed, Feb 4, 2015 at 3:51 PM, Eric Seidel wrote: > Yep, my original motivation was getting access to source locations > within embedded DSLs. The call-stack is a nice and easy extension, but > I'm not sure how useful it will be in practice, as the first function > that doesn't request a CallStack parameter will cut off the stack. This > means that the generated stacks will often be quite short, I imagine. Well, as I said, all I really care about is the direct caller. From the example in the commit, it looks like the function with the (?x :: Location) annotation can get its immediate caller, even if that caller doesn't have the annotation. If that's true, that's all that is needed! And from my point of view, it's not just "maybe useful in practice", but absolutely required, to the point where I wrote a custom preprocessor for it. I've been using it for 6 or 7 years and I sort of forgot that other people don't have it. I actually have no idea how other people do logging... just hope the message is unique and grep -n all the time? And for tests, manually give every single assertion a unique name and grep -n again? Enable TH globally? Those all seem impractical if you have or are expecting thousands of modules. I don't think it needs to be used at all in the standard libraries, since logging and testing are not part of base. I can understand if the merge window for 7.10 is closed, but trying to come up with a use in base shouldn't hold it up! From eric at seidel.io Thu Feb 5 00:39:32 2015 From: eric at seidel.io (Eric Seidel) Date: Wed, 04 Feb 2015 16:39:32 -0800 Subject: [Haskell-cafe] RFC: rewrite-with-location proposal In-Reply-To: (Evan Laforge's message of "Wed, 4 Feb 2015 16:10:56 -0800") References: <20131202220625.GA6022@x200> <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: Evan Laforge writes: > On Wed, Feb 4, 2015 at 3:51 PM, Eric Seidel wrote: >> Yep, my original motivation was getting access to source locations >> within embedded DSLs. The call-stack is a nice and easy extension, but >> I'm not sure how useful it will be in practice, as the first function >> that doesn't request a CallStack parameter will cut off the stack. This >> means that the generated stacks will often be quite short, I imagine. > > Well, as I said, all I really care about is the direct caller. From > the example in the commit, it looks like the function with the (?x :: > Location) annotation can get its immediate caller, even if that caller > doesn't have the annotation. If that's true, that's all that is > needed! That's correct, though I regrettably forgot to update the Phabricator summary with the rename from Location to CallStack (the actual docs do properly talk about CallStacks). A constraint (?x :: CallStack) will always be solved for the source location that gave rise to it, when it comes from a function signature (as opposed to a use of the implicit param) you'll get the immediate call-site. Furthermore, if that call-site has a CallStack implicit param in scope, the stacks will be appended (this appending of call-stacks is the bit that I'm not sure will see much use). Does that make sense? > And from my point of view, it's not just "maybe useful in practice", > but absolutely required, to the point where I wrote a custom > preprocessor for it. I've been using it for 6 or 7 years and I sort > of forgot that other people don't have it. I actually have no idea > how other people do logging... just hope the message is unique and > grep -n all the time? And for tests, manually give every single > assertion a unique name and grep -n again? Enable TH globally? Those > all seem impractical if you have or are expecting thousands of > modules. > > I don't think it needs to be used at all in the standard libraries, > since logging and testing are not part of base. I can understand if > the merge window for 7.10 is closed, but trying to come up with a use > in base shouldn't hold it up! You're quite right, there are plenty of reasons to want this functionality beyond error reporting, though I'd personally like to use this for `error`, `undefined`, and `assert` as well! From qdunkan at gmail.com Thu Feb 5 00:52:41 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 4 Feb 2015 16:52:41 -0800 Subject: [Haskell-cafe] RFC: rewrite-with-location proposal In-Reply-To: References: <20131202220625.GA6022@x200> <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: On Wed, Feb 4, 2015 at 4:39 PM, Eric Seidel wrote: > A constraint (?x :: CallStack) will always be solved for the source > location that gave rise to it, when it comes from a function signature > (as opposed to a use of the implicit param) you'll get the immediate > call-site. Furthermore, if that call-site has a CallStack implicit param > in scope, the stacks will be appended (this appending of call-stacks is > the bit that I'm not sure will see much use). Does that make sense? Sure. One place I can think of where the chaining would be useful is you can put it on a helper function that then calls the logging function, so the output can skip that intermediate function. This makes it better than python or C++ logging, which often provides no way to do that. > You're quite right, there are plenty of reasons to want this > functionality beyond error reporting, though I'd personally like to use > this for `error`, `undefined`, and `assert` as well! True enough, though assert kind of already has the feature. In fact, you could remove the assert special case hack, though there are probably people relying on it to get source info. In any case it's up to the GHC people to say what they think. In case it's not already obvious, big +1 for "merge as soon as possible" from me. From eric at seidel.io Thu Feb 5 01:02:48 2015 From: eric at seidel.io (Eric Seidel) Date: Wed, 4 Feb 2015 17:02:48 -0800 Subject: [Haskell-cafe] RFC: rewrite-with-location proposal In-Reply-To: References: <20131202220625.GA6022@x200> <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> Message-ID: <8ABFFF15-A6EF-47E6-962C-FE15C415C787@seidel.io> > On Feb 4, 2015, at 16:52, Evan Laforge wrote: > >> On Wed, Feb 4, 2015 at 4:39 PM, Eric Seidel wrote: >> A constraint (?x :: CallStack) will always be solved for the source >> location that gave rise to it, when it comes from a function signature >> (as opposed to a use of the implicit param) you'll get the immediate >> call-site. Furthermore, if that call-site has a CallStack implicit param >> in scope, the stacks will be appended (this appending of call-stacks is >> the bit that I'm not sure will see much use). Does that make sense? > > Sure. One place I can think of where the chaining would be useful is > you can put it on a helper function that then calls the logging > function, so the output can skip that intermediate function. This > makes it better than python or C++ logging, which often provides no > way to do that. Right, it would also be useful for partial functions like head, so error has access to head's call-site when it produces a stack trace. The thing is, this feature is not free, as it adds an argument to each function that participates. So the question is, to what extent would you want to annotate library code with these CallStack parameters? From qdunkan at gmail.com Thu Feb 5 01:18:51 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 4 Feb 2015 17:18:51 -0800 Subject: [Haskell-cafe] RFC: rewrite-with-location proposal In-Reply-To: <8ABFFF15-A6EF-47E6-962C-FE15C415C787@seidel.io> References: <20131202220625.GA6022@x200> <59543203684B2244980D7E4057D5FBC1486E0A24@DB3EX14MBXC308.europe.corp.microsoft.com> <8ABFFF15-A6EF-47E6-962C-FE15C415C787@seidel.io> Message-ID: On Wed, Feb 4, 2015 at 5:02 PM, Eric Seidel wrote: > Right, it would also be useful for partial functions like head, so error has access to head's call-site when it produces a stack trace. The thing is, this feature is not free, as it adds an argument to each function that participates. So the question is, to what extent would you want to annotate library code with these CallStack parameters? I don't actually care, since I never use those functions. I suppose one way to argue would be to say go ahead and add, since the only people using them are either a quick hack where crashing is ok, and thus probably don't care about micro-optimizing performance, or people who don't know any better, who are also not in the micro-optimization business. Or maybe people use them as a micro-optimization like e.g. unsafeIndex. But I don't know if it actually is a micro-optimization over e.g. 'case xs of [] -> error "..."', since 'head' probably compiles to just that. In any case, I have no horse in the race, but I'd say "put it on everything partial." From omari at smileystation.com Thu Feb 5 01:23:20 2015 From: omari at smileystation.com (Omari Norman) Date: Wed, 4 Feb 2015 20:23:20 -0500 Subject: [Haskell-cafe] SmallCheck Depth Message-ID: The original SmallCheck paper [0] gives a type data Name = P | Q | R and states that all values of type Name have depth 0. To me this suggests that all values of type Bool would have depth 0 as well, seeing as Bool would simply be data Bool = True | False Sure enough, if I load up ghci with SmallCheck 0.2.1, I get > series 0 :: [Bool] [True, False] But in QuickCheck 1.1.1 I get > list 0 series :: [Bool] [] Very puzzling to me is that it seems the definition of series for Bool has not changed in the new version. Both versions have something like series = cons0 True \/ cons0 False So what explains the different behavior? Thanks. --Omari [0] http://www.cs.york.ac.uk/fp/smallcheck/smallcheck.pdf From ok at cs.otago.ac.nz Thu Feb 5 03:10:50 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 5 Feb 2015 16:10:50 +1300 Subject: [Haskell-cafe] [Haskell-beginners] ghc --make Vs runhaskell In-Reply-To: References: Message-ID: <2DB2EE12-5811-4FAC-9938-D237A23ACF7D@cs.otago.ac.nz> On 4/02/2015, at 4:35 pm, Brandon Allbery wrote: > C / C++ programs also do buffering, but there's a heinous hack which detects reads on stdin and flushes stdout beforehand. (Heinous because there is no guarantee that they are actually related --- but na?ve programmers invariably do not learn about line buffering and expect all output to be unbuffered(*), and C standard library programmers eventually gave up and catered to them after years of trying to get them to pay attention. I have a nasty suspicion we're going to end up with a similar horrible hack in Haskell eventually.) Looking in the last public draft of C99, section 7.19.3 has this: When a stream is line buffered, characters are intended to be transmitted to or from the host environment as a block when a new-line character is encountered. >>> Furthermore, characters are intended to be transmitted as a block to the host >>> environment when a buffer is filled, when input is requested on an unbuffered >>> stream, or when input is requested on a line buffered stream that requires the >>> transmission of characters from the host environment. So the "heinous hack" is not about stdin or stdout specifically; the standard requirement is that getting input from ANY line-buffered stream forces EVERY line-buffered output stream to be flushed. And it's this way precisely *because* the C runtime doesn't know whether two such streams are "related" or not, so it plays safe. Given things like sockets, STREAMS, and ptys, I am not sure that it is _possible_ for a Unix system to determine whether two streams are or are not "related" reliably. Solaris and OpenBSD do what the standard requires. A local copy of the Linux manual pages says (in setbuf(3)): When an output stream ... is line buffered characters are saved up until a newline is output or input is read from any stream attached to a terminal device (typically stdin). I hope that's wrong. There's other GNU documentation that disagrees, saying that every output stream is flushed whenever any input stream "actually reads data from its file" and not mentioning line buffering at all. I suspect that Linux is doing the right thing, but digging through the glibc-2.20 sources left me even more confused than the Linux documenters. From fryguybob at gmail.com Thu Feb 5 03:42:38 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Wed, 4 Feb 2015 22:42:38 -0500 Subject: [Haskell-cafe] How does RTS judge that a STM transaction is blocked? In-Reply-To: References: Message-ID: When you get the "thread blocked indefinitely in an STM transaction" it is the result of the garbage collector finding no references to the TVars that a 'retry'ing or blocked transaction. If there are no references to those TVars then there is no way for that transaction to ever succeed. I don't know if that helps. On Wed, Feb 4, 2015 at 7:59 AM, Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Hi, > > I met an issue while I was using xhb. When a certain property of root > window being changed, it was supposed to give me an AccessError. But > actually I got "thread blocked indefinitely in an STM transaction" when I > waitForEvent. > > AFAIK, in xhb, it forks a thread to read what X server sends. Then parse > and put it into a TChan. waitForEvent reads from the TChan. > > It is reasonable to me that if X server did not send anything, then > waitForEvent would be blocked. But apparently there are some other policies > in RTS. > > So what is that? And how should I debug it? > > -- > ??????? > ??????? > > And for G+, please use magiclouds#gmail.com. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Thu Feb 5 03:45:14 2015 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Thu, 5 Feb 2015 11:45:14 +0800 Subject: [Haskell-cafe] How does RTS judge that a STM transaction is blocked? In-Reply-To: References: Message-ID: Sorry, where should I put your code? On Wed, Feb 4, 2015 at 9:42 PM, Robin Palotai wrote: > More detail would be helpful, but sounds like an infinite (Async?) thread. > Try > > bracket (newStablePtr a) freeStablePtr (const $ wait a) > > +google to find out why. > > 2015-02-04 13:59 GMT+01:00 Magicloud Magiclouds < > magicloud.magiclouds at gmail.com>: > >> Hi, >> >> I met an issue while I was using xhb. When a certain property of root >> window being changed, it was supposed to give me an AccessError. But >> actually I got "thread blocked indefinitely in an STM transaction" when >> I waitForEvent. >> >> AFAIK, in xhb, it forks a thread to read what X server sends. Then >> parse and put it into a TChan. waitForEvent reads from the TChan. >> >> It is reasonable to me that if X server did not send anything, then >> waitForEvent would be blocked. But apparently there are some other policies >> in RTS. >> >> So what is that? And how should I debug it? >> >> -- >> ??????? >> ??????? >> >> And for G+, please use magiclouds#gmail.com. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -- ??????? ??????? And for G+, please use magiclouds#gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Feb 5 03:45:30 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 4 Feb 2015 22:45:30 -0500 Subject: [Haskell-cafe] [Haskell-beginners] ghc --make Vs runhaskell In-Reply-To: <2DB2EE12-5811-4FAC-9938-D237A23ACF7D@cs.otago.ac.nz> References: <2DB2EE12-5811-4FAC-9938-D237A23ACF7D@cs.otago.ac.nz> Message-ID: On Wed, Feb 4, 2015 at 10:10 PM, Richard A. O'Keefe wrote: > Given things like sockets, STREAMS, and ptys, I am not > sure that it is _possible_ for a Unix system to determine whether two > streams > are or are not "related" reliably. > It's not. I was not implying that it was, or that it was even a good idea to try to do so. On the other hand, flushing *every* line-buffered FILE is rather overkill but less heinous than highly dubious and untestable assumptions about relationships. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicloud.magiclouds at gmail.com Thu Feb 5 03:46:22 2015 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Thu, 5 Feb 2015 11:46:22 +0800 Subject: [Haskell-cafe] How does RTS judge that a STM transaction is blocked? In-Reply-To: References: Message-ID: Thank you. That is why I am confused. Does it mean the read thread is dead before waitForEvent? On Thu, Feb 5, 2015 at 11:42 AM, Ryan Yates wrote: > When you get the "thread blocked indefinitely in an STM transaction" it is > the result of the garbage collector finding no references to the TVars that > a 'retry'ing or blocked transaction. If there are no references to those > TVars then there is no way for that transaction to ever succeed. I don't > know if that helps. > > On Wed, Feb 4, 2015 at 7:59 AM, Magicloud Magiclouds < > magicloud.magiclouds at gmail.com> wrote: > >> Hi, >> >> I met an issue while I was using xhb. When a certain property of root >> window being changed, it was supposed to give me an AccessError. But >> actually I got "thread blocked indefinitely in an STM transaction" when >> I waitForEvent. >> >> AFAIK, in xhb, it forks a thread to read what X server sends. Then >> parse and put it into a TChan. waitForEvent reads from the TChan. >> >> It is reasonable to me that if X server did not send anything, then >> waitForEvent would be blocked. But apparently there are some other policies >> in RTS. >> >> So what is that? And how should I debug it? >> >> -- >> ??????? >> ??????? >> >> And for G+, please use magiclouds#gmail.com. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -- ??????? ??????? And for G+, please use magiclouds#gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstcruz at gmail.com Thu Feb 5 04:21:49 2015 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Wed, 4 Feb 2015 21:21:49 -0700 Subject: [Haskell-cafe] Haskell Weekly News: Issue 316 Message-ID: Welcome to issue 316 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from January 18 to 31, 2015 After doing more than 150 of these, I have come to the conclusion that it is time for me to take a permanent break from HWN. I realize that "we could do better", and have something a bit more edited than a collection of links, and some quotes. I wish I had more time to devote to such endeavor, but my time is currently being taken up by trying to help my 1 year old explore her little world. If you'd like to be the one to continue the long tradition of HWN, drop me a line. Thanks for following along for the last 3 years! Quotes of the Week * johnw: "Sir, what weapon did the assailant use against you?" "All I know is that it was done in IO, officer." * monochrom: $ can't buy you love, but it can buy you function application * hiptobecubic: benzrf, well sure. I'm not suggesting that lens has actually left any operators available for anything Top Reddit Stories * I think I've nailed it! I've solved the records problem! Domain: nikita-volkov.github.io, Score: 348, Comments: 193 Original: [1] http://goo.gl/PhJo6K On Reddit: [2] http://goo.gl/vWPeOj * Use Haskell for shell scripting Domain: haskellforall.com, Score: 121, Comments: 62 Original: [3] http://goo.gl/Fx4HeT On Reddit: [4] http://goo.gl/2g83KR * Major Prelude changes proposed Domain: haskell.org, Score: 119, Comments: 252 Original: [5] http://goo.gl/wtFWt3 On Reddit: [6] http://goo.gl/kaegj2 * Slides from Don Stewart's Google tech talk Domain: code.haskell.org, Score: 104, Comments: 75 Original: [7] http://goo.gl/ejfoFp On Reddit: [8] http://goo.gl/9cK9dB * Haskell Design Patterns: .Extended Modules Domain: jaspervdj.be, Score: 86, Comments: 29 Original: [9] http://goo.gl/TvwGCF On Reddit: [10] http://goo.gl/wkNx38 * IO Monad Considered Harmful Domain: blog.jle.im, Score: 86, Comments: 157 Original: [11] http://goo.gl/z9Elq7 On Reddit: [12] http://goo.gl/uehgF9 * We are making great efforts to spread Haskell around our local programming groups. Today, I finally saw a Haskell post, so I'm glad it is kinda working. Kinda. Domain: i.imgur.com, Score: 86, Comments: 41 Original: [13] http://goo.gl/0SsbT7 On Reddit: [14] http://goo.gl/gyBJ1o * My Haskell tooling wishlist by Chris Done Domain: chrisdone.com, Score: 77, Comments: 27 Original: [15] http://goo.gl/VIRJgM On Reddit: [16] http://goo.gl/ChmItY * Categories for Programmers: Functors Domain: bartoszmilewski.com, Score: 70, Comments: 14 Original: [17] http://goo.gl/6M64jC On Reddit: [18] http://goo.gl/tW6ubH * I wrote another monad tutorial. Sorry. Domain: kevinmahoney.co.uk, Score: 63, Comments: 22 Original: [19] http://goo.gl/zEQIgS On Reddit: [20] http://goo.gl/XXeZN3 * Introducing SJS, a type inferer and checker for JavaScript (written in Haskell) Domain: noamlewis.wordpress.com, Score: 61, Comments: 33 Original: [21] http://goo.gl/oQRSNo On Reddit: [22] http://goo.gl/1LfY1u * Solving the expression problem with Object Algebras and Tagless Interpreters Domain: oleksandrmanzyuk.wordpress.com, Score: 59, Comments: 30 Original: [23] http://goo.gl/daJWGy On Reddit: [24] http://goo.gl/fKy9zV Top StackOverflow Questions * Why do we need monads? votes: 142, answers: 5 Read on SO: [25] http://goo.gl/Ioviv9 * Why compiling this Haskell program with -fllvm produces a different result? votes: 19, answers: 0 Read on SO: [26] http://goo.gl/twid2N * What is the difference between traits in Rust and typeclasses in Haskell? votes: 18, answers: 0 Read on SO: [27] http://goo.gl/KJdBqh * Motivation behind Phantom Types? votes: 17, answers: 3 Read on SO: [28] http://goo.gl/q7IQQC * What is the precedence of ~, and why? votes: 17, answers: 1 Read on SO: [29] http://goo.gl/iZHxLy * Using GHC API to compile Haskell sources to CORE and CORE to binary votes: 13, answers: 2 Read on SO: [30] http://goo.gl/Qto29m * How to ship an executable with Language.Haskell.Interpreter? votes: 13, answers: 0 Read on SO: [31] http://goo.gl/JptPyG Until next time, [32]+Daniel Santa Cruz References 1. http://nikita-volkov.github.io/record/ 2. http://www.reddit.com/r/haskell/comments/2svayz/i_think_ive_nailed_it_ive_solved_the_records/ 3. http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html 4. http://www.reddit.com/r/haskell/comments/2u6b8m/use_haskell_for_shell_scripting/ 5. https://www.haskell.org/pipermail/libraries/2015-January/024777.html 6. http://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/ 7. http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf 8. http://www.reddit.com/r/haskell/comments/2u0380/slides_from_don_stewarts_google_tech_talk/ 9. http://jaspervdj.be/posts/2015-01-20-haskell-design-patterns-extended-modules.html 10. http://www.reddit.com/r/haskell/comments/2t4lba/haskell_design_patterns_extended_modules/ 11. http://blog.jle.im/entry/io-monad-considered-harmful 12. http://www.reddit.com/r/haskell/comments/2tbbxh/io_monad_considered_harmful/ 13. http://i.imgur.com/Rw8mmad.jpg 14. http://www.reddit.com/r/haskell/comments/2tg9gs/we_are_making_great_efforts_to_spread_haskell/ 15. http://chrisdone.com/posts/haskell-wishlist 16. http://www.reddit.com/r/haskell/comments/2tpwim/my_haskell_tooling_wishlist_by_chris_done/ 17. http://bartoszmilewski.com/2015/01/20/functors/ 18. http://www.reddit.com/r/haskell/comments/2t2g5a/categories_for_programmers_functors/ 19. http://kevinmahoney.co.uk/articles/haskell-io/ 20. http://www.reddit.com/r/haskell/comments/2trmyx/i_wrote_another_monad_tutorial_sorry/ 21. https://noamlewis.wordpress.com/2015/01/20/introducing-sjs-a-type-inferer-and-checker-for-javascript/ 22. http://www.reddit.com/r/haskell/comments/2szt1u/introducing_sjs_a_type_inferer_and_checker_for/ 23. https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ 24. http://www.reddit.com/r/haskell/comments/2stmt6/solving_the_expression_problem_with_object/ 25. http://stackoverflow.com/questions/28139259/why-do-we-need-monads 26. http://stackoverflow.com/questions/28053448/why-compiling-this-haskell-program-with-fllvm-produces-a-different-result 27. http://stackoverflow.com/questions/28123453/what-is-the-difference-between-traits-in-rust-and-typeclasses-in-haskell 28. http://stackoverflow.com/questions/28247543/motivation-behind-phantom-types 29. http://stackoverflow.com/questions/28257511/what-is-the-precedence-of-and-why 30. http://stackoverflow.com/questions/28059669/using-ghc-api-to-compile-haskell-sources-to-core-and-core-to-binary 31. http://stackoverflow.com/questions/28204973/how-to-ship-an-executable-with-language-haskell-interpreter 32. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu Feb 5 05:11:33 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 5 Feb 2015 06:11:33 +0100 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 In-Reply-To: References: Message-ID: <20150205051133.GA28929@x60s.casa> On Wed, Feb 04, 2015 at 09:21:49PM -0700, Daniel Santa Cruz wrote: > After doing more than 150 of these, I have come to the conclusion that > it is time for me to take a permanent break from HWN. I realize that > "we could do better", and have something a bit more edited than a > collection of links, and some quotes. I wish I had more time to devote > to such endeavor, but my time is currently being taken up by trying to > help my 1 year old explore her little world. Thanks so much for doing these! Always useful, great way to keep up to date with other places than the ML. Good luck with the 1 year old, may her steps be functional! -F From r.wobben at home.nl Thu Feb 5 07:48:32 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 08:48:32 +0100 Subject: [Haskell-cafe] stuck at the first part of chapter 1 of the CIS course Message-ID: <54D32050.9070901@home.nl> An HTML attachment was scrubbed... URL: From brendan.g.hay at gmail.com Thu Feb 5 08:39:54 2015 From: brendan.g.hay at gmail.com (Brendan Hay) Date: Thu, 5 Feb 2015 09:39:54 +0100 Subject: [Haskell-cafe] stuck at the first part of chapter 1 of the CIS course In-Reply-To: <54D32050.9070901@home.nl> References: <54D32050.9070901@home.nl> Message-ID: Hi Roelof, The parse error is due to the colon ':' in the guards, where instead an equals '=' should be used: toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | otherwise = n/10 : [] You can see some more examples of the guard syntax under the heading 'Guards, guards!' in LYAH: http://learnyouahaskell.com/syntax-in-functions#guards-guards Hope that helps, Brendan On 5 February 2015 at 08:48, Roelof Wobben wrote: > Hello, > > I have to do this : > > Exercise 1 We need to first find the digits of a number. Define the > functions > toDigits :: Integer -> [Integer] > toDigitsRev :: Integer -> [Integer] > toDigits should convert positive Integers to a list of digits. (For 0 or > negative inputs, toDigits should return the empty list.) toDigitsRev > should do the same, but with the digits reversed. > Example: toDigits 1234 == [1,2,3,4] > Example: toDigitsRev 1234 == [4,3,2,1] > Example: toDigits 0 == [] > Example: toDigits (-17) == [] > > > I have this so far : > > -- | convert a number to a array in pieces where a negative number will be > a empty array. > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 : [] > | otherwise : n/10 : [] > > -- | Main entry point to the application. > module Main where > > -- | The main entry point. > main :: IO () > main = do > toDigits 123 > > but now I see this error message : > > src/Main.hs at 5:3-5:4 > parse error on input | > > This is not homework because I do this as a self-study. > > Roelof > > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Feb 5 09:07:07 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 5 Feb 2015 09:07:07 +0000 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF562BF720@DB3PRD3001MB020.064d.mgd.msft.net> After doing more than 150 of these, I have come to the conclusion that it is time for me to take a permanent break from HWN. I realize that "we could do better", and have something a bit more edited than a collection of links, and some quotes. I wish I had more time to devote to such endeavour, but my time is currently being taken up by trying to help my 1 year old explore her little world. We owe Daniel a huge debt of thanks. HWN is a huge service to the community. I have read many interesting blog posts that I would have never otherwise found. Thank you! We really need a successor! Please, please. Simon From: Haskell [mailto:haskell-bounces at haskell.org] On Behalf Of Daniel Santa Cruz Sent: 05 February 2015 04:22 To: haskell at haskell.org; haskell-cafe at haskell.org Subject: [Haskell] Haskell Weekly News: Issue 316 Welcome to issue 316 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers from January 18 to 31, 2015 After doing more than 150 of these, I have come to the conclusion that it is time for me to take a permanent break from HWN. I realize that "we could do better", and have something a bit more edited than a collection of links, and some quotes. I wish I had more time to devote to such endeavor, but my time is currently being taken up by trying to help my 1 year old explore her little world. If you'd like to be the one to continue the long tradition of HWN, drop me a line. Thanks for following along for the last 3 years! Quotes of the Week * johnw: "Sir, what weapon did the assailant use against you?" "All I know is that it was done in IO, officer." * monochrom: $ can't buy you love, but it can buy you function application * hiptobecubic: benzrf, well sure. I'm not suggesting that lens has actually left any operators available for anything Top Reddit Stories * I think I've nailed it! I've solved the records problem! Domain: nikita-volkov.github.io, Score: 348, Comments: 193 Original: [1] http://goo.gl/PhJo6K On Reddit: [2] http://goo.gl/vWPeOj * Use Haskell for shell scripting Domain: haskellforall.com, Score: 121, Comments: 62 Original: [3] http://goo.gl/Fx4HeT On Reddit: [4] http://goo.gl/2g83KR * Major Prelude changes proposed Domain: haskell.org, Score: 119, Comments: 252 Original: [5] http://goo.gl/wtFWt3 On Reddit: [6] http://goo.gl/kaegj2 * Slides from Don Stewart's Google tech talk Domain: code.haskell.org, Score: 104, Comments: 75 Original: [7] http://goo.gl/ejfoFp On Reddit: [8] http://goo.gl/9cK9dB * Haskell Design Patterns: .Extended Modules Domain: jaspervdj.be, Score: 86, Comments: 29 Original: [9] http://goo.gl/TvwGCF On Reddit: [10] http://goo.gl/wkNx38 * IO Monad Considered Harmful Domain: blog.jle.im, Score: 86, Comments: 157 Original: [11] http://goo.gl/z9Elq7 On Reddit: [12] http://goo.gl/uehgF9 * We are making great efforts to spread Haskell around our local programming groups. Today, I finally saw a Haskell post, so I'm glad it is kinda working. Kinda. Domain: i.imgur.com, Score: 86, Comments: 41 Original: [13] http://goo.gl/0SsbT7 On Reddit: [14] http://goo.gl/gyBJ1o * My Haskell tooling wishlist by Chris Done Domain: chrisdone.com, Score: 77, Comments: 27 Original: [15] http://goo.gl/VIRJgM On Reddit: [16] http://goo.gl/ChmItY * Categories for Programmers: Functors Domain: bartoszmilewski.com, Score: 70, Comments: 14 Original: [17] http://goo.gl/6M64jC On Reddit: [18] http://goo.gl/tW6ubH * I wrote another monad tutorial. Sorry. Domain: kevinmahoney.co.uk, Score: 63, Comments: 22 Original: [19] http://goo.gl/zEQIgS On Reddit: [20] http://goo.gl/XXeZN3 * Introducing SJS, a type inferer and checker for JavaScript (written in Haskell) Domain: noamlewis.wordpress.com, Score: 61, Comments: 33 Original: [21] http://goo.gl/oQRSNo On Reddit: [22] http://goo.gl/1LfY1u * Solving the expression problem with Object Algebras and Tagless Interpreters Domain: oleksandrmanzyuk.wordpress.com, Score: 59, Comments: 30 Original: [23] http://goo.gl/daJWGy On Reddit: [24] http://goo.gl/fKy9zV Top StackOverflow Questions * Why do we need monads? votes: 142, answers: 5 Read on SO: [25] http://goo.gl/Ioviv9 * Why compiling this Haskell program with -fllvm produces a different result? votes: 19, answers: 0 Read on SO: [26] http://goo.gl/twid2N * What is the difference between traits in Rust and typeclasses in Haskell? votes: 18, answers: 0 Read on SO: [27] http://goo.gl/KJdBqh * Motivation behind Phantom Types? votes: 17, answers: 3 Read on SO: [28] http://goo.gl/q7IQQC * What is the precedence of ~, and why? votes: 17, answers: 1 Read on SO: [29] http://goo.gl/iZHxLy * Using GHC API to compile Haskell sources to CORE and CORE to binary votes: 13, answers: 2 Read on SO: [30] http://goo.gl/Qto29m * How to ship an executable with Language.Haskell.Interpreter? votes: 13, answers: 0 Read on SO: [31] http://goo.gl/JptPyG Until next time, [32]+Daniel Santa Cruz References 1. http://nikita-volkov.github.io/record/ 2. http://www.reddit.com/r/haskell/comments/2svayz/i_think_ive_nailed_it_ive_solved_the_records/ 3. http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html 4. http://www.reddit.com/r/haskell/comments/2u6b8m/use_haskell_for_shell_scripting/ 5. https://www.haskell.org/pipermail/libraries/2015-January/024777.html 6. http://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_proposed/ 7. http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf 8. http://www.reddit.com/r/haskell/comments/2u0380/slides_from_don_stewarts_google_tech_talk/ 9. http://jaspervdj.be/posts/2015-01-20-haskell-design-patterns-extended-modules.html 10. http://www.reddit.com/r/haskell/comments/2t4lba/haskell_design_patterns_extended_modules/ 11. http://blog.jle.im/entry/io-monad-considered-harmful 12. http://www.reddit.com/r/haskell/comments/2tbbxh/io_monad_considered_harmful/ 13. http://i.imgur.com/Rw8mmad.jpg 14. http://www.reddit.com/r/haskell/comments/2tg9gs/we_are_making_great_efforts_to_spread_haskell/ 15. http://chrisdone.com/posts/haskell-wishlist 16. http://www.reddit.com/r/haskell/comments/2tpwim/my_haskell_tooling_wishlist_by_chris_done/ 17. http://bartoszmilewski.com/2015/01/20/functors/ 18. http://www.reddit.com/r/haskell/comments/2t2g5a/categories_for_programmers_functors/ 19. http://kevinmahoney.co.uk/articles/haskell-io/ 20. http://www.reddit.com/r/haskell/comments/2trmyx/i_wrote_another_monad_tutorial_sorry/ 21. https://noamlewis.wordpress.com/2015/01/20/introducing-sjs-a-type-inferer-and-checker-for-javascript/ 22. http://www.reddit.com/r/haskell/comments/2szt1u/introducing_sjs_a_type_inferer_and_checker_for/ 23. https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ 24. http://www.reddit.com/r/haskell/comments/2stmt6/solving_the_expression_problem_with_object/ 25. http://stackoverflow.com/questions/28139259/why-do-we-need-monads 26. http://stackoverflow.com/questions/28053448/why-compiling-this-haskell-program-with-fllvm-produces-a-different-result 27. http://stackoverflow.com/questions/28123453/what-is-the-difference-between-traits-in-rust-and-typeclasses-in-haskell 28. http://stackoverflow.com/questions/28247543/motivation-behind-phantom-types 29. http://stackoverflow.com/questions/28257511/what-is-the-precedence-of-and-why 30. http://stackoverflow.com/questions/28059669/using-ghc-api-to-compile-haskell-sources-to-core-and-core-to-binary 31. http://stackoverflow.com/questions/28204973/how-to-ship-an-executable-with-language-haskell-interpreter 32. https://plus.google.com/105107667630152149014/about -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Thu Feb 5 09:54:21 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Thu, 5 Feb 2015 10:54:21 +0100 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> Message-ID: Hi all, I have been very interested by this discussion when Alberto started it. As there been any progress? The problem is very acute in the Nomyx game I'm developing (www.nomyx.com). The game is based on a DSL, it's working well, but at the moment only expert Haskell developers can play... I think cryptic error messages is part of the problem. How to improve that? For example, a common error message is the following: Won't Compile :5:28: Couldn't match type ?'NoEffect? with ?'Effect? Expected type: Exp Effect () Actual type: Exp NoEffect () In the expression: e_1 In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect () It's not so helpful and exposing Nomyx internals. A better error message would be to hint that the player forgot a "liftEffect" instruction. The only quick-and-dirty solution I see is to pattern-match for it and display an additional hint line... On Mon, Nov 24, 2014 at 10:47 PM, Alberto G. Corona wrote: > That is fantastic news. Very nice to know that the project is alive and > with aims to produce tangible results. > > As Felipe said, please ping your advances there. To add some estimated > dates would be fantastic. > > 2014-11-24 17:37 GMT+01:00 Felipe Lessa : > >> On 24-11-2014 06:27, Alejandro Serrano Mena wrote: >> > At Utrecht University we are currently tackling this problem, in the >> > form of the DOMain Specific Type Error Diagnosis (DOMSTED) Project [1]. >> > So at least we have one person (me) working full-time on it, plus my >> > supervisor Jurriaan Hage, which had already worked in a similar project >> > for Haskell 98 which produced the Helium [2] compiler. >> > We are slowly building step towards a nice way to create domain specific >> > error messages, and we expect to have some nice results soon :) >> > Of course, if you have any ideas on how to improve error messages, feel >> > free to contact me :) >> >> It would be nice if you could ping relevant issues (such as [1]) stating >> that you're researching on this topic. >> >> Cheers, >> >> [1] https://ghc.haskell.org/trac/ghc/ticket/7870 >> >> -- >> Felipe. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > > -- > Alberto. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Feb 5 11:06:40 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 05 Feb 2015 13:06:40 +0200 Subject: [Haskell-cafe] SmallCheck Depth In-Reply-To: References: Message-ID: <54D34EC0.2070903@ro-che.info> The choice of what belongs to what depth is rather arbitrary. You say you'd expect all three constructors to be of depth 0. What about data A = A1 .. A50 ? What about Char or Int? See the problem? On 05/02/15 03:23, Omari Norman wrote: > The original SmallCheck paper [0] gives a type > > data Name = P | Q | R > > and states that all values of type Name have depth 0. To me this > suggests that all values of type Bool would have depth 0 as well, > seeing as Bool would simply be > > data Bool = True | False > > Sure enough, if I load up ghci with SmallCheck 0.2.1, I get > >> series 0 :: [Bool] > [True, False] > > But in QuickCheck 1.1.1 I get > >> list 0 series :: [Bool] > [] > > Very puzzling to me is that it seems the definition of series for Bool > has not changed in the new version. Both versions have something like > > series = cons0 True \/ cons0 False > > So what explains the different behavior? Thanks. --Omari > > [0] http://www.cs.york.ac.uk/fp/smallcheck/smallcheck.pdf > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From r.wobben at home.nl Thu Feb 5 11:19:29 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 12:19:29 +0100 Subject: [Haskell-cafe] stuck at the first part of chapter 1 of the CIS course In-Reply-To: References: <54D32050.9070901@home.nl> Message-ID: <54D351C1.1040508@home.nl> An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Feb 5 11:27:45 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 5 Feb 2015 11:27:45 +0000 Subject: [Haskell-cafe] stuck at the first part of chapter 1 of the CIS course In-Reply-To: <54D351C1.1040508@home.nl> References: <54D32050.9070901@home.nl> <54D351C1.1040508@home.nl> Message-ID: <20150205112745.GG10648@weber> 'module Main where' has to go at the top of the file. You could also omit it. I would suggest you direct these kinds of questions to the haskell-beginners mailing list https://www.haskell.org/mailman/listinfo/beginners or the #haskell-beginners IRC channel on Freenode. Tom From ky3 at atamo.com Thu Feb 5 12:28:18 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 5 Feb 2015 19:28:18 +0700 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562BF720@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF562BF720@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Thu, Feb 5, 2015 at 4:07 PM, Simon Peyton Jones wrote: > We really need a successor! Please, please. I have offered to continue HWN. If picked, I intend to bring it back to the informed news source that it was circa early 2000s. I'm cognizant of the diversification of online hangouts. Whereas it was plenty enough to curate haskell-cafe way back when, it's no longer enough to sort through Haskell Reddit and Stack Overflow. Haskell professionals already know to watch the ghc mailing lists, especially libraries, ghc-devs, and tickets. There's Google+, which holds its share of haskellers. But there's a slew of non-haskell.org mailing lists around real world applications, e.g. purescript/elm, pipes, and commercial-haskell, that command sizeable sections of the community. And last but not least, can anyone afford to ignore the Twitter grapevine? I make no promises to comprehensive coverage. But I endeavor to build bridges across special interest tectonics. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Thu Feb 5 14:12:44 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Thu, 05 Feb 2015 15:12:44 +0100 Subject: [Haskell-cafe] stuck at the first part of chapter 1 of the CIS course In-Reply-To: References: <54D32050.9070901@home.nl> Message-ID: <54D37A5C.7080209@home.nl> An HTML attachment was scrubbed... URL: From omari at smileystation.com Thu Feb 5 14:29:38 2015 From: omari at smileystation.com (Omari Norman) Date: Thu, 5 Feb 2015 09:29:38 -0500 Subject: [Haskell-cafe] SmallCheck Depth In-Reply-To: <54D34EC0.2070903@ro-che.info> References: <54D34EC0.2070903@ro-che.info> Message-ID: On Thu, Feb 5, 2015 at 6:06 AM, Roman Cheplyaka wrote: > The choice of what belongs to what depth is rather arbitrary. > > You say you'd expect all three constructors to be of depth 0. What about > > data A = A1 .. A50 > > ? > > What about Char or Int? > > See the problem? I see the issue, but I think the current SmallCheck documentation does not acknowledge this issue and the documentation in fact obstructs understanding of the way the library currently works. First, Runciman 2008 does not say that the choice of what belongs to what depth is arbitrary. Rather, it states that "the depth of a zero-arity construction is zero, and the depth of a positive-arity construction is one greater than the maximum depth of a component argument." Thus the depth of True would be zero. In data A = A1 .. A50 the depth of each value would be zero. The Runciman 2008 theory holds perfectly for Int if one conceptualizes Int to be built as follows: data Sign = Pos | Neg data Nat = One | Succ Nat data Int = Zero | NonZero Sign Nat In that case, the depth of Zero is 0. The depth of 1 (that is, NonZero Pos One)) is one greater than the maximum depth of a component argument; since the maximum depth of a component is zero, that gives us depth 1. Similarly, the depth of NonZero Pos (Succ One) is 2. I acknowledge that Runciman 2008 did not explain this as well as it might have. I have puzzled over it off and on for months, though the fact that the current SmallCheck is not consistent with this explanation did not help me. Further, my explanation of Int is not the one Runciman 2008 gave, as it ignores that an Int might be negative. In addition, since Int is bounded, you could indeed argue that every member of Int should indeed have depth 0 because then your @data A = A1 .. A50@ conceptualization is more appropriate. However, the conceptualization given above is the only one that holds for Integer. I also acknowledge that the Runciman 2008 theory was not used for all types in the original SmallCheck; for instance, Char would have been treated differently. Even so, the Runciman 2008 theory certainly holds for types with only a few possible values (such as (), Bool, Maybe, etc.) and the original SmallCheck was faithful to the Runciman 2008 theory in those cases. Upon further examination of the current SmallCheck source, I see that 'cons0' decreases the depth, while its counterpart in the original SmallCheck did not. What I was wondering is whether this change was made for any particular reason. Perhaps the explanation given in Runciman 2008 is not, in fact, a useful one in practice because of the existence of bounded types with large numbers of values, such as Char and Int. In that case, though, it would be useful if the current SmallCheck documentation abandoned the Runciman 2008 explanation. "Test.SmallCheck.Series" still states that "For data values, [depth] is the depth of nested constructor applications." After puzzling over what on earth "nested constructor applications" means, and then consulting Runciman 2008, I was only more confused after seeing that the current SmallCheck behaves in a way that is inconsistent with its own documentation, with Runciman 2008, and with the original SmallCheck. Perhaps, then, if the current theory underlying SmallCheck is that depth is just some size-limiting thing, the documentation should say something like "Depth is a non-negative integer. You use depth to make progressively 'larger' values. What 'larger' means is up to you. Runciman 2008 said it means the depth of nested constructor applications, but that is not always practically sensible. You should, however, ensure that all the values included at @depth n@ are also included in @depth n + 1 at . " Even with an explanation like that, though, I don't see why @list 0@ should sometimes return values (as it does for () and Int) and sometimes not (as it does with Bool). That's a puzzling behavior that did not exist in the original SmallCheck. I bring all this up because the implementation of SmallCheck is in some ways quite subtle. In the past I have considered using it but found the depth concept to be bewildering. In contrast, QuickCheck's Arbitrary makes no claims as to theoretical consistency--Gen Int might give a huge range of Int, or it might return 5 every time. Indeed, that is why there is a whole batch of bindings in Test.QuickCheck for Gen Int of different ranges. I doubt I am the only one who found the inconsistency between the SmallCheck docs and its behavior to be confusing. Now that I finally understand the idea of depth, I might actually use SmallCheck. Thanks. --Omari From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Feb 5 18:11:35 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 5 Feb 2015 18:11:35 +0000 Subject: [Haskell-cafe] Complex Event Processing in Haskell Message-ID: <20150205181135.GB29558@weber> I'm looking for examples of production-capable Complex Event Processing systems in Haskell along the lines of Esper: http://esper.codehaus.org/ I know of Nettle (and McNettle and Procera) from Yale, and it claims to have excellent performance. http://haskell.cs.yale.edu/nettle/ Is there anything else? Is there anything in another functional language I should look at? I know FRP systems in general deal with processing events, but I am looking specifically for things similar to Esper. Tom From roma at ro-che.info Thu Feb 5 18:29:38 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 05 Feb 2015 20:29:38 +0200 Subject: [Haskell-cafe] SmallCheck Depth In-Reply-To: References: <54D34EC0.2070903@ro-che.info> Message-ID: <54D3B692.7070806@ro-che.info> On 05/02/15 16:29, Omari Norman wrote: > On Thu, Feb 5, 2015 at 6:06 AM, Roman Cheplyaka wrote: >> The choice of what belongs to what depth is rather arbitrary. >> >> You say you'd expect all three constructors to be of depth 0. What about >> >> data A = A1 .. A50 >> >> ? >> >> What about Char or Int? >> >> See the problem? > > I see the issue, but I think the current SmallCheck documentation does > not acknowledge this issue and the documentation in fact obstructs > understanding of the way the library currently works. I simply didn't think it was important for the end users. Granted, having a nice, principled answer to the question "what is depth" would be nice. I spent a fair bit of time trying to figure it out, but hadn't found it. But practically speaking, you can just look at the generated values (using 'list') and see which depth you need (or whether you need to redefine the instance, as I often do for Char). > First, Runciman 2008 does not say that the choice of what belongs to > what depth is arbitrary. Rather, it states that "the depth of a > zero-arity construction is zero, and the depth of a positive-arity > construction is one greater than the maximum depth of a component > argument." Thus the depth of True would be zero. In > > data A = A1 .. A50 > > the depth of each value would be zero. > > The Runciman 2008 theory holds perfectly for Int if one conceptualizes > Int to be built as follows: > > data Sign = Pos | Neg > data Nat = One | Succ Nat > data Int = Zero | NonZero Sign Nat Except that's not what Int is. I'm sure one can find a mapping that justifies almost any instance. > Upon further examination of the current SmallCheck source, I see that > 'cons0' decreases the depth, while its counterpart in the original > SmallCheck did not. What I was wondering is whether this change was > made for any particular reason. IIRC, it was mostly for consistency. cons1, cons2 etc. all decrement the depth; why shouldn't cons0? If depth(Just x) = 1 + depth x, it sounds fair that depth(Nothing) = 1 + depth() = 1 > "Test.SmallCheck.Series" still states > that "For data values, [depth] is the depth of nested constructor > applications." True is a single constructor, so its depth is 1. Just True is a constructor application of depth 2. And so on. So this still mostly holds (ignoring cases like Int). That said, the docs could definitely be improved; patches are welcome. > Perhaps, then, if the current theory underlying SmallCheck is that > depth is just some size-limiting thing, the documentation should say > something like "Depth is a non-negative integer. You use depth to > make progressively 'larger' values. What 'larger' means is up to you. > Runciman 2008 said it means the depth of nested constructor > applications, but that is not always practically sensible. You > should, however, ensure that all the values included at @depth n@ are > also included in @depth n + 1 at . " Sounds sensible. > Even with an explanation like that, > though, I don't see why @list 0@ should sometimes return values (as it > does for () and Int) and sometimes not (as it does with Bool). That's > a puzzling behavior that did not exist in the original SmallCheck. *Test.SmallCheck> series 0 :: [Bool] [True,False] *Test.SmallCheck> series 0 :: [Either Bool Bool] [] - Roman From agocorona at gmail.com Thu Feb 5 19:12:08 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 5 Feb 2015 20:12:08 +0100 Subject: [Haskell-cafe] Complex Event Processing in Haskell In-Reply-To: <20150205181135.GB29558@weber> References: <20150205181135.GB29558@weber> Message-ID: I?m creating something around this 2015-02-05 19:11 GMT+01:00 Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: > I'm looking for examples of production-capable Complex Event Processing > systems in Haskell along the lines of Esper: > > http://esper.codehaus.org/ > > I know of Nettle (and McNettle and Procera) from Yale, and it claims to > have > excellent performance. > > http://haskell.cs.yale.edu/nettle/ > > Is there anything else? Is there anything in another functional language I > should look at? I know FRP systems in general deal with processing events, > but I am looking specifically for things similar to Esper. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Thu Feb 5 19:20:08 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 5 Feb 2015 20:20:08 +0100 Subject: [Haskell-cafe] Complex Event Processing in Haskell In-Reply-To: References: <20150205181135.GB29558@weber> Message-ID: Sorry. My cat passed over the keyboard. I was just creating a draft message just in case nobody answered you. I said that I'm developing something around this article: https://www.fpcomplete.com/user/agocorona/monad-reactive-programming-2 Of course it is not production ready .not even a package in Hackage is yet available. That is the reason why I doubted to send this response. but the cat has decided for me. I will publish an article soon more elaborated with the last things that I have done. 2015-02-05 20:12 GMT+01:00 Alberto G. Corona : > I?m creating something around this > > > 2015-02-05 19:11 GMT+01:00 Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: > >> I'm looking for examples of production-capable Complex Event Processing >> systems in Haskell along the lines of Esper: >> >> http://esper.codehaus.org/ >> >> I know of Nettle (and McNettle and Procera) from Yale, and it claims to >> have >> excellent performance. >> >> http://haskell.cs.yale.edu/nettle/ >> >> Is there anything else? Is there anything in another functional language >> I >> should look at? I know FRP systems in general deal with processing >> events, >> but I am looking specifically for things similar to Esper. >> >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Alberto. > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Feb 5 19:22:36 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 05 Feb 2015 19:22:36 +0000 Subject: [Haskell-cafe] Complex Event Processing in Haskell References: <20150205181135.GB29558@weber> Message-ID: The cat made a good decision IMO :) On Thu Feb 05 2015 at 9:20:37 PM Alberto G. Corona wrote: > Sorry. > > My cat passed over the keyboard. > > I was just creating a draft message just in case nobody answered you. > > I said that I'm developing something around this article: > > https://www.fpcomplete.com/user/agocorona/monad-reactive-programming-2 > > Of course it is not production ready .not even a package in Hackage is yet > available. That is the reason why I doubted to send this response. but the > cat has decided for me. > > I will publish an article soon more elaborated with the last things that I > have done. > > 2015-02-05 20:12 GMT+01:00 Alberto G. Corona : > >> I?m creating something around this >> >> >> 2015-02-05 19:11 GMT+01:00 Tom Ellis < >> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: >> >>> I'm looking for examples of production-capable Complex Event Processing >>> systems in Haskell along the lines of Esper: >>> >>> http://esper.codehaus.org/ >>> >>> I know of Nettle (and McNettle and Procera) from Yale, and it claims to >>> have >>> excellent performance. >>> >>> http://haskell.cs.yale.edu/nettle/ >>> >>> Is there anything else? Is there anything in another functional >>> language I >>> should look at? I know FRP systems in general deal with processing >>> events, >>> but I am looking specifically for things similar to Esper. >>> >>> Tom >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> >> -- >> Alberto. >> > > > > -- > Alberto. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Thu Feb 5 20:55:57 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 5 Feb 2015 21:55:57 +0100 Subject: [Haskell-cafe] Complex Event Processing in Haskell In-Reply-To: References: <20150205181135.GB29558@weber> Message-ID: He want me to work harder ;) 2015-02-05 20:22 GMT+01:00 Michael Snoyman : > The cat made a good decision IMO :) > > > On Thu Feb 05 2015 at 9:20:37 PM Alberto G. Corona > wrote: > >> Sorry. >> >> My cat passed over the keyboard. >> >> I was just creating a draft message just in case nobody answered you. >> >> I said that I'm developing something around this article: >> >> https://www.fpcomplete.com/user/agocorona/monad-reactive-programming-2 >> >> Of course it is not production ready .not even a package in Hackage is >> yet available. That is the reason why I doubted to send this response. but >> the cat has decided for me. >> >> I will publish an article soon more elaborated with the last things that >> I have done. >> >> 2015-02-05 20:12 GMT+01:00 Alberto G. Corona : >> >>> I?m creating something around this >>> >>> >>> 2015-02-05 19:11 GMT+01:00 Tom Ellis < >>> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: >>> >>>> I'm looking for examples of production-capable Complex Event Processing >>>> systems in Haskell along the lines of Esper: >>>> >>>> http://esper.codehaus.org/ >>>> >>>> I know of Nettle (and McNettle and Procera) from Yale, and it claims to >>>> have >>>> excellent performance. >>>> >>>> http://haskell.cs.yale.edu/nettle/ >>>> >>>> Is there anything else? Is there anything in another functional >>>> language I >>>> should look at? I know FRP systems in general deal with processing >>>> events, >>>> but I am looking specifically for things similar to Esper. >>>> >>>> Tom >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >>> >>> >>> -- >>> Alberto. >>> >> >> >> >> -- >> Alberto. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.crayne at gmail.com Thu Feb 5 23:07:48 2015 From: jim.crayne at gmail.com (James Crayne) Date: Thu, 5 Feb 2015 18:07:48 -0500 Subject: [Haskell-cafe] ANNOUNCE: bash script for haskell Message-ID: I'm sure variations of this exist, but for some reason I didn't find any while searching, so I made my own. The idea is for using haskell on the command line instead of perl or awk etc. https://github.com/jimcrayne/hk -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwc at cs.yale.edu Thu Feb 5 23:12:26 2015 From: dwc at cs.yale.edu (Daniel Winograd-Cort) Date: Thu, 5 Feb 2015 18:12:26 -0500 Subject: [Haskell-cafe] ANNOUNCE: UISF Release Message-ID: I'm happy to announce the release of UISF on Hackage! http://hackage.haskell.org/package/UISF UISF provides an arrowized FRP library for graphical user interfaces. It stems from work done on Euterpea (http://haskell.cs.yale.edu/euterpea/), and is built atop GLFW. One of the neat things about UISF is how it behaves with ArrowChoice. Specifically, one can create dynamic arrows so long as they are *predictably* dynamic. This means that it is possible to have widgets activate, deactivate, and even replicate without resorting to switch. If you're interested in playing around with it, feel free to take a look at the example files, some of which are pretty well documented (note that there are more than just the two displayed on the hackage page). Do let us know about comments you have and bugs you find. -Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From simons at cryp.to Thu Feb 5 23:42:14 2015 From: simons at cryp.to (Peter Simons) Date: Fri, 06 Feb 2015 00:42:14 +0100 Subject: [Haskell-cafe] ANNOUNCE: bash script for haskell References: Message-ID: <87k2zwylgp.fsf@write-only.cryp.to> This announcement left me totally amazed at the realization that neither "runhaskell" nor "ghci" seem to have a command-line option equivalent to "-c" in Bourne shell. Am I missing something terribly obvious? Best regards, Peter From allbery.b at gmail.com Thu Feb 5 23:44:59 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 5 Feb 2015 18:44:59 -0500 Subject: [Haskell-cafe] ANNOUNCE: bash script for haskell In-Reply-To: <87k2zwylgp.fsf@write-only.cryp.to> References: <87k2zwylgp.fsf@write-only.cryp.to> Message-ID: On Thu, Feb 5, 2015 at 6:42 PM, Peter Simons wrote: > This announcement left me totally amazed at the realization that neither > "runhaskell" nor "ghci" seem to have a command-line option equivalent to > "-c" in Bourne shell. > ghc -e. (Similarly ghci and runghc are really custom invocations of ghc.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Feb 5 23:46:38 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 5 Feb 2015 23:46:38 +0000 Subject: [Haskell-cafe] ANNOUNCE: bash script for haskell In-Reply-To: <87k2zwylgp.fsf@write-only.cryp.to> References: <87k2zwylgp.fsf@write-only.cryp.to> Message-ID: <20150205234638.GL10648@weber> On Fri, Feb 06, 2015 at 12:42:14AM +0100, Peter Simons wrote: > This announcement left me totally amazed at the realization that neither > "runhaskell" nor "ghci" seem to have a command-line option equivalent to > "-c" in Bourne shell. > > Am I missing something terribly obvious? How about ghc -e 'do { putStrLn "What is your name?"; name <- getLine; putStrLn $ "Hello " ++ name }' From jim.crayne at gmail.com Fri Feb 6 00:35:44 2015 From: jim.crayne at gmail.com (James Crayne) Date: Thu, 5 Feb 2015 19:35:44 -0500 Subject: [Haskell-cafe] ANNOUNCE: bash script for haskell In-Reply-To: <20150205234638.GL10648@weber> References: <87k2zwylgp.fsf@write-only.cryp.to> <20150205234638.GL10648@weber> Message-ID: Note the hk script gives you a richer default environment, including System.Environment and a bunch of other commonly used modules. Also, some magic to sort of detect what you want, in the case of whether you give it a pure function vs an IO etc. For one offs on the command line, a slightly less picky type check seems to make sense in my opinion. In the case that it doesn't work, it lets you edit the script in a text editor, there by showing you what the real haskell looks like. Not that I am especially proud, the implementation could be cleaned up a lot I am sure, but the user interface is failry nice I think. One caveat I probably should mention in the README but didn't, is that your script is copied to a file stored under /tmp, so you don't want to put passwords or anything of that matter in it. On Thu, Feb 5, 2015 at 6:46 PM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Fri, Feb 06, 2015 at 12:42:14AM +0100, Peter Simons wrote: > > This announcement left me totally amazed at the realization that neither > > "runhaskell" nor "ghci" seem to have a command-line option equivalent to > > "-c" in Bourne shell. > > > > Am I missing something terribly obvious? > > How about > > ghc -e 'do { putStrLn "What is your name?"; name <- getLine; putStrLn $ > "Hello " ++ name }' > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.crayne at gmail.com Fri Feb 6 01:00:50 2015 From: jim.crayne at gmail.com (James Crayne) Date: Thu, 5 Feb 2015 20:00:50 -0500 Subject: [Haskell-cafe] ANNOUNCE: bash script for haskell In-Reply-To: References: <87k2zwylgp.fsf@write-only.cryp.to> <20150205234638.GL10648@weber> Message-ID: Sorry to reply to myself, but actually passwords on the command line are never secure. The secure thing is to use a file descripter to input that information such as STDIN. Thus this is not really a failing of hk. On Thu, Feb 5, 2015 at 7:35 PM, James Crayne wrote: > Note the hk script gives you a richer default environment, including > System.Environment and a bunch of other commonly used modules. > > Also, some magic to sort of detect what you want, in the case of whether > you give it a pure function vs an IO etc. For one offs on the command line, > a slightly less picky type check seems to make sense in my opinion. In the > case that it doesn't work, it lets you edit the script in a text editor, > there by showing you what the real haskell looks like. > > Not that I am especially proud, the implementation could be cleaned up a > lot I am sure, but the user interface is failry nice I think. > > One caveat I probably should mention in the README but didn't, is that > your script is copied to a file stored under /tmp, so you don't want to put > passwords or anything of that matter in it. > > > > On Thu, Feb 5, 2015 at 6:46 PM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > >> On Fri, Feb 06, 2015 at 12:42:14AM +0100, Peter Simons wrote: >> > This announcement left me totally amazed at the realization that neither >> > "runhaskell" nor "ghci" seem to have a command-line option equivalent to >> > "-c" in Bourne shell. >> > >> > Am I missing something terribly obvious? >> >> How about >> >> ghc -e 'do { putStrLn "What is your name?"; name <- getLine; putStrLn $ >> "Hello " ++ name }' >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Fri Feb 6 01:01:49 2015 From: mwm at mired.org (Mike Meyer) Date: Thu, 5 Feb 2015 19:01:49 -0600 Subject: [Haskell-cafe] ANNOUNCE: bash script for haskell In-Reply-To: References: <87k2zwylgp.fsf@write-only.cryp.to> <20150205234638.GL10648@weber> Message-ID: On Thu, Feb 5, 2015 at 6:35 PM, James Crayne wrote: > Note the hk script gives you a richer default environment, including > System.Environment and a bunch of other commonly used modules. > Been there, done that :-). My eddie program "cabal install eddie" is specifically designed for using haskell in shell scripts, so has a slew of options for pre & post-processing the input and handling files as arguments. It got some traction for windows users, but not on systems that have the unix tools set. The unix tools already cover most common use cases, with languages designed for it. On those systems, it's more popular for testing expressions before putting them in a program. Looks like hk will be better for that. Not that I am especially proud, the implementation could be cleaned up a > lot I am sure, but the user interface is failry nice I think. > Ditto for eddie. My first real program, now four years old. it's desperately in need of a rewrite, but I've failed to find time for it for a year or so now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Fri Feb 6 02:18:43 2015 From: mwm at mired.org (Mike Meyer) Date: Thu, 5 Feb 2015 20:18:43 -0600 Subject: [Haskell-cafe] ghci on ARM m3? Message-ID: Lately, I've not been doing much Haskell because I've buried in embedded systems work. The code is all C, with only a smidgen of C++ (for which I am grateful). One of the things I've been toying with is turning part of the on-chip configuration information a haskel functions. They'd even be pure code, and would be a lot more expressive than what's there now. The target platforms are running Cortex M3 CPUs. I know that jhc/ajhc will generate code for those CPUs, but I really need at least a subset of the compiler running on the target processor with no pre-installed RTOS. Has that been done? Is it likely to even be possible? As part of the project, I'll need to install both a cross-compiler on my Unix box, and the the compiler (or parts of it) on the M3. Can someone provide pointers to tutorials on that? My google-foo wasn't powerful enough to find any. I'm thinking about using either an Aruino Due (as it has the M3 CPU on it) as a testbed platform. So tutorials targeted for that platform would be particularly appreciated. Since I hopefully have the eyes of people experienced with these things, should I be considering a raspberry pi or something similar instead of the Due? Basically, will I be able to run code built for the M3 CPU on the pi CPUs? thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstcruz at gmail.com Fri Feb 6 04:50:57 2015 From: dstcruz at gmail.com (Daniel Santa Cruz) Date: Fri, 06 Feb 2015 04:50:57 +0000 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 References: <20150205051133.GA28929@x60s.casa> Message-ID: On Wed Feb 04 2015 at 10:14:08 PM Francesco Ariis wrote: > Thanks so much for doing these! Always useful, great way to keep > up to date with other places than the ML. > > Good luck with the 1 year old, may her steps be functional! > Thanks! I hope her first steps are not lazy :-) Cheers, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrz.vtl at gmail.com Fri Feb 6 06:26:37 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Fri, 6 Feb 2015 01:26:37 -0500 Subject: [Haskell-cafe] hflags Message-ID: with ghc 7.8.4 and hflags 0.4 the following program: {-# LANGUAGE TemplateHaskell #-} module Main where import HFlags defineFlag "f" True "A flag." --defineFlag "g" True "Another flag." main = do _ <- $initHFlags "flags demo" print Main.flags_f gives me a runtime error about the flag f not being found, unless I add the declaration of a second flag. It seems like the last flag definition is not seen. Any idea/suggestion? Thanks, Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Fri Feb 6 07:53:06 2015 From: adam at well-typed.com (Adam Gundry) Date: Fri, 06 Feb 2015 07:53:06 +0000 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> Message-ID: <54D472E2.50707@well-typed.com> [Re-sending to haskell-cafe since I used the wrong From address...] This is something that has been on my mind for a while, particularly following discussions at the last ICFP and prompted by the work on typechecker plugins in GHC [1]. I think I see a way to proceed, though I don't know whether I will have time to implement it for a while. I'd be interested to hear about other approaches. Suppose we define an ADT representation of all the typechecker error messages, e.g. something roughly like data TcError = CustomError String | CouldNotUnify Type Type | NoClassInstance ... In GHC all the relevant messages are generated in the typechecker/TcErrors module, so this shouldn't be too hard to arrange. Now we can extend plugins with the ability to supply a function tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError] and run the plugged-in function between generating and reporting the errors. Thus a library defining a DSL could also provide a plugin to supply more informative error messages. This is a fairly quick-and-dirty approach, because the plugin would be quite tightly coupled to GHC, even though it could be written and distributed separately. But it might be one way of making progress. (It also occurs to me that such an ADT might allow GHC to define a machine-readable serialisable format for its error messages, to allow post-processing by external programs.) Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker On 05/02/15 09:54, Corentin Dupont wrote: > Hi all, > I have been very interested by this discussion when Alberto started it. > As there been any progress? > The problem is very acute in the Nomyx game I'm developing > (www.nomyx.com ). > The game is based on a DSL, it's working well, but at the moment only > expert Haskell developers can play... > I think cryptic error messages is part of the problem. > How to improve that? > For example, a common error message is the following: > > Won't Compile > :5:28: > Couldn't match type ?'NoEffect? with ?'Effect? > Expected type: Exp Effect () > Actual type: Exp NoEffect () > In the expression: e_1 > In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect () > > It's not so helpful and exposing Nomyx internals. > A better error message would be to hint that the player forgot a "liftEffect" instruction. > > The only quick-and-dirty solution I see is to pattern-match for it and display an additional hint line... -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From trupill at gmail.com Fri Feb 6 08:23:44 2015 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 6 Feb 2015 09:23:44 +0100 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: <54D472E2.50707@well-typed.com> References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> Message-ID: I think this is very similar to what Idris supports for reflecting on errors: http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf 2015-02-06 8:53 GMT+01:00 Adam Gundry : > [Re-sending to haskell-cafe since I used the wrong From address...] > > This is something that has been on my mind for a while, particularly > following discussions at the last ICFP and prompted by the work on > typechecker plugins in GHC [1]. I think I see a way to proceed, though I > don't know whether I will have time to implement it for a while. I'd be > interested to hear about other approaches. > > Suppose we define an ADT representation of all the typechecker error > messages, e.g. something roughly like > > data TcError = CustomError String > | CouldNotUnify Type Type > | NoClassInstance ... > > In GHC all the relevant messages are generated in the > typechecker/TcErrors module, so this shouldn't be too hard to arrange. > Now we can extend plugins with the ability to supply a function > > tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError] > > and run the plugged-in function between generating and reporting the > errors. Thus a library defining a DSL could also provide a plugin to > supply more informative error messages. > > This is a fairly quick-and-dirty approach, because the plugin would be > quite tightly coupled to GHC, even though it could be written and > distributed separately. But it might be one way of making progress. (It > also occurs to me that such an ADT might allow GHC to define a > machine-readable serialisable format for its error messages, to allow > post-processing by external programs.) > > Adam > > [1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker > > > On 05/02/15 09:54, Corentin Dupont wrote: > > Hi all, > > I have been very interested by this discussion when Alberto started it. > > As there been any progress? > > The problem is very acute in the Nomyx game I'm developing > > (www.nomyx.com ). > > The game is based on a DSL, it's working well, but at the moment only > > expert Haskell developers can play... > > I think cryptic error messages is part of the problem. > > How to improve that? > > For example, a common error message is the following: > > > > Won't Compile > > :5:28: > > Couldn't match type ?'NoEffect? with ?'Effect? > > Expected type: Exp Effect () > > Actual type: Exp NoEffect () > > In the expression: e_1 > > In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect () > > > > It's not so helpful and exposing Nomyx internals. > > A better error message would be to hint that the player forgot a > "liftEffect" instruction. > > > > The only quick-and-dirty solution I see is to pattern-match for it and > display an additional hint line... > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claude at mathr.co.uk Fri Feb 6 09:28:43 2015 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Fri, 06 Feb 2015 09:28:43 +0000 Subject: [Haskell-cafe] hflags In-Reply-To: References: Message-ID: <54D4894B.1090707@mathr.co.uk> On 06/02/15 06:26, Maurizio Vitale wrote: > with ghc 7.8.4 and hflags 0.4 the following program: > > {-# LANGUAGE TemplateHaskell #-} > > module Main where > > import HFlags > > defineFlag "f" True "A flag." > --defineFlag "g" True "Another flag." return [] -- see http://hackage.haskell.org/package/QuickCheck-2.7.6/docs/Test-QuickCheck-All.html#v:quickCheckAll - I haven't tested with hflags but it looks like the same issue from first glance > > main = do > _ <- $initHFlags "flags demo" > print Main.flags_f > > gives me a runtime error about the flag f not being found, unless I add the > declaration of a second flag. It seems like the last flag definition is not > seen. > > Any idea/suggestion? > > Thanks, > > Maurizio Claude -- http://mathr.co.uk From rasen.dubi at gmail.com Fri Feb 6 09:42:24 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Fri, 6 Feb 2015 11:42:24 +0200 Subject: [Haskell-cafe] ghci on ARM m3? In-Reply-To: References: Message-ID: I'm not aware of state of Haskell compilers for ARM platform, but I'm an embedded developer. As far as I know, you can't run Cortex-M3 code on Raspberry Pi, because latest is Cortex-A8 and I believe M3 and A8 are binary incompatible. Regards, Alexey 2015-02-06 4:18 GMT+02:00 Mike Meyer : > Lately, I've not been doing much Haskell because I've buried in embedded > systems work. The code is all C, with only a smidgen of C++ (for which I am > grateful). > > One of the things I've been toying with is turning part of the on-chip > configuration information a haskel functions. They'd even be pure code, and > would be a lot more expressive than what's there now. > > The target platforms are running Cortex M3 CPUs. I know that jhc/ajhc will > generate code for those CPUs, but I really need at least a subset of the > compiler running on the target processor with no pre-installed RTOS. Has > that been done? Is it likely to even be possible? > > As part of the project, I'll need to install both a cross-compiler on my > Unix box, and the the compiler (or parts of it) on the M3. Can someone > provide pointers to tutorials on that? My google-foo wasn't powerful enough > to find any. > > I'm thinking about using either an Aruino Due (as it has the M3 CPU on it) > as a testbed platform. So tutorials targeted for that platform would be > particularly appreciated. > > Since I hopefully have the eyes of people experienced with these things, > should I be considering a raspberry pi or something similar instead of the > Due? Basically, will I be able to run code built for the M3 CPU on the pi > CPUs? > > thanks, > Mike > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Fri Feb 6 09:53:37 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Fri, 6 Feb 2015 10:53:37 +0100 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: <54D472E2.50707@well-typed.com> References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> Message-ID: Interesting, in fact I'm surprised error reporting is not already done with some sort of ADT. How it is done currently? With string manipulation? On Fri, Feb 6, 2015 at 8:53 AM, Adam Gundry wrote: > [Re-sending to haskell-cafe since I used the wrong From address...] > > This is something that has been on my mind for a while, particularly > following discussions at the last ICFP and prompted by the work on > typechecker plugins in GHC [1]. I think I see a way to proceed, though I > don't know whether I will have time to implement it for a while. I'd be > interested to hear about other approaches. > > Suppose we define an ADT representation of all the typechecker error > messages, e.g. something roughly like > > data TcError = CustomError String > | CouldNotUnify Type Type > | NoClassInstance ... > > In GHC all the relevant messages are generated in the > typechecker/TcErrors module, so this shouldn't be too hard to arrange. > Now we can extend plugins with the ability to supply a function > > tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError] > > and run the plugged-in function between generating and reporting the > errors. Thus a library defining a DSL could also provide a plugin to > supply more informative error messages. > > This is a fairly quick-and-dirty approach, because the plugin would be > quite tightly coupled to GHC, even though it could be written and > distributed separately. But it might be one way of making progress. (It > also occurs to me that such an ADT might allow GHC to define a > machine-readable serialisable format for its error messages, to allow > post-processing by external programs.) > > Adam > > [1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker > > > On 05/02/15 09:54, Corentin Dupont wrote: > > Hi all, > > I have been very interested by this discussion when Alberto started it. > > As there been any progress? > > The problem is very acute in the Nomyx game I'm developing > > (www.nomyx.com ). > > The game is based on a DSL, it's working well, but at the moment only > > expert Haskell developers can play... > > I think cryptic error messages is part of the problem. > > How to improve that? > > For example, a common error message is the following: > > > > Won't Compile > > :5:28: > > Couldn't match type ?'NoEffect? with ?'Effect? > > Expected type: Exp Effect () > > Actual type: Exp NoEffect () > > In the expression: e_1 > > In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect () > > > > It's not so helpful and exposing Nomyx internals. > > A better error message would be to hint that the player forgot a > "liftEffect" instruction. > > > > The only quick-and-dirty solution I see is to pattern-match for it and > display an additional hint line... > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Fri Feb 6 09:56:19 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Fri, 06 Feb 2015 10:56:19 +0100 Subject: [Haskell-cafe] ghci on ARM m3? In-Reply-To: References: Message-ID: <54D48FC3.4020306@centrum.cz> I would say no way to run ghci on M3, but this should be possible on RPi especially if you consider v2 which provides quad-core ARMv7 CPU. ARMv6 on the v1 should also be possible if the support has not bit-roted that much. Anyway, GHC for ARM requires LLVM and the situation with GHC/LLVM is not currently stable as it's kind of in transition period from old LLVM support to new LLVM support. Ben Gamari (cced to this) knows more about it. Cheers, Karel On 02/ 6/15 03:18 AM, Mike Meyer wrote: > Lately, I've not been doing much Haskell because I've buried in embedded > systems work. The code is all C, with only a smidgen of C++ (for which I > am grateful). > > One of the things I've been toying with is turning part of the on-chip > configuration information a haskel functions. They'd even be pure code, > and would be a lot more expressive than what's there now. > > The target platforms are running Cortex M3 CPUs. I know that jhc/ajhc > will generate code for those CPUs, but I really need at least a subset > of the compiler running on the target processor with no pre-installed > RTOS. Has that been done? Is it likely to even be possible? > > As part of the project, I'll need to install both a cross-compiler on my > Unix box, and the the compiler (or parts of it) on the M3. Can someone > provide pointers to tutorials on that? My google-foo wasn't powerful > enough to find any. > > I'm thinking about using either an Aruino Due (as it has the M3 CPU on > it) as a testbed platform. So tutorials targeted for that platform would > be particularly appreciated. > > Since I hopefully have the eyes of people experienced with these things, > should I be considering a raspberry pi or something similar instead of > the Due? Basically, will I be able to run code built for the M3 CPU on > the pi CPUs? > > thanks, > Mike > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From komendantsky at gmail.com Fri Feb 6 10:06:41 2015 From: komendantsky at gmail.com (Vladimir Komendantskiy) Date: Fri, 6 Feb 2015 10:06:41 +0000 Subject: [Haskell-cafe] ghci on ARM m3? In-Reply-To: References: Message-ID: Try this demo on Cortex-M3: https://github.com/ajhc/demo-cortex-m3/tree/master/stm32f3-discovery I only have Cortex-M0+ and Cortex-M4 in my disposition but I think the above should run on your hardware. You would likely need to modify the linker script stm32f3.ld for your memory layout. BTW, Raspberry Pi is ARM11 (ARM architecture v6) and not Cortex-M3 (arm architecture v7). On Raspberry Pi you can run bare metal binaries on as little as 32KiB RAM in a similar way to the above demo, with a GCC cross-compiler rather than in Linux under LLVM. I understand your question was about bare metal support for Haskell and not LLVM. --Vladimir On 6 February 2015 at 02:18, Mike Meyer wrote: > Lately, I've not been doing much Haskell because I've buried in embedded > systems work. The code is all C, with only a smidgen of C++ (for which I am > grateful). > > One of the things I've been toying with is turning part of the on-chip > configuration information a haskel functions. They'd even be pure code, and > would be a lot more expressive than what's there now. > > The target platforms are running Cortex M3 CPUs. I know that jhc/ajhc will > generate code for those CPUs, but I really need at least a subset of the > compiler running on the target processor with no pre-installed RTOS. Has > that been done? Is it likely to even be possible? > > As part of the project, I'll need to install both a cross-compiler on my > Unix box, and the the compiler (or parts of it) on the M3. Can someone > provide pointers to tutorials on that? My google-foo wasn't powerful enough > to find any. > > I'm thinking about using either an Aruino Due (as it has the M3 CPU on it) > as a testbed platform. So tutorials targeted for that platform would be > particularly appreciated. > > Since I hopefully have the eyes of people experienced with these things, > should I be considering a raspberry pi or something similar instead of the > Due? Basically, will I be able to run code built for the M3 CPU on the pi > CPUs? > > thanks, > Mike > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From simonpj at microsoft.com Fri Feb 6 10:10:06 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Feb 2015 10:10:06 +0000 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: <54D472E2.50707@well-typed.com> References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C07E7@DB3PRD3001MB020.064d.mgd.msft.net> Yes, the centralisation of many type errors to TcErrors is a huge win. It would be massive task to turn *all* of GHC's errors into a data type, but the ones in TcErrors ought not to be too hard. Simon | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf | Of Adam Gundry | Sent: 06 February 2015 07:53 | To: Haskell Cafe | Subject: Re: [Haskell-cafe] Domain specific error messages | | [Re-sending to haskell-cafe since I used the wrong From address...] | | This is something that has been on my mind for a while, particularly | following discussions at the last ICFP and prompted by the work on | typechecker plugins in GHC [1]. I think I see a way to proceed, though | I don't know whether I will have time to implement it for a while. I'd | be interested to hear about other approaches. | | Suppose we define an ADT representation of all the typechecker error | messages, e.g. something roughly like | | data TcError = CustomError String | | CouldNotUnify Type Type | | NoClassInstance ... | | In GHC all the relevant messages are generated in the | typechecker/TcErrors module, so this shouldn't be too hard to arrange. | Now we can extend plugins with the ability to supply a function | | tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError] | | and run the plugged-in function between generating and reporting the | errors. Thus a library defining a DSL could also provide a plugin to | supply more informative error messages. | | This is a fairly quick-and-dirty approach, because the plugin would be | quite tightly coupled to GHC, even though it could be written and | distributed separately. But it might be one way of making progress. | (It also occurs to me that such an ADT might allow GHC to define a | machine-readable serialisable format for its error messages, to allow | post-processing by external programs.) | | Adam | | [1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker | | | On 05/02/15 09:54, Corentin Dupont wrote: | > Hi all, | > I have been very interested by this discussion when Alberto started | it. | > As there been any progress? | > The problem is very acute in the Nomyx game I'm developing | > (www.nomyx.com ). | > The game is based on a DSL, it's working well, but at the moment | only | > expert Haskell developers can play... | > I think cryptic error messages is part of the problem. | > How to improve that? | > For example, a common error message is the following: | > | > Won't Compile | > :5:28: | > Couldn't match type ''NoEffect' with ''Effect' | > Expected type: Exp Effect () | > Actual type: Exp NoEffect () | > In the expression: e_1 | > In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect | () | > | > It's not so helpful and exposing Nomyx internals. | > A better error message would be to hint that the player forgot a | "liftEffect" instruction. | > | > The only quick-and-dirty solution I see is to pattern-match for it | and display an additional hint line... | | | | -- | Adam Gundry, Haskell Consultant | Well-Typed LLP, http://www.well-typed.com/ | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe at haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From simonpj at microsoft.com Fri Feb 6 10:17:44 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 6 Feb 2015 10:17:44 +0000 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> I think this is very similar to what Idris supports for reflecting on errors: http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf Aha! Yes, thank you for jogging my memory. I had a good conversation with David Christiansen about this at ICFP, about this very topic, and whether we could steal Idris?s clever ideas and put them in GHC. ? He subsequently wrote a blog post ? Incidentally, in case it?s not clear this thread on Haskell Caf? goes back to Nov 14. The first message in the series had more useful links David?s idea is would have much broader scope than just TcErrors. Much of the infrastructure is in place already, since error message are SDocs (an abstract type, private to GHC), not strings. Design work needed. Start a wiki page. Articulate a vision. Discuss alternatives. Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Alejandro Serrano Mena Sent: 06 February 2015 08:24 To: Adam Gundry Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Domain specific error messages I think this is very similar to what Idris supports for reflecting on errors: http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf 2015-02-06 8:53 GMT+01:00 Adam Gundry >: [Re-sending to haskell-cafe since I used the wrong From address...] This is something that has been on my mind for a while, particularly following discussions at the last ICFP and prompted by the work on typechecker plugins in GHC [1]. I think I see a way to proceed, though I don't know whether I will have time to implement it for a while. I'd be interested to hear about other approaches. Suppose we define an ADT representation of all the typechecker error messages, e.g. something roughly like data TcError = CustomError String | CouldNotUnify Type Type | NoClassInstance ... In GHC all the relevant messages are generated in the typechecker/TcErrors module, so this shouldn't be too hard to arrange. Now we can extend plugins with the ability to supply a function tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError] and run the plugged-in function between generating and reporting the errors. Thus a library defining a DSL could also provide a plugin to supply more informative error messages. This is a fairly quick-and-dirty approach, because the plugin would be quite tightly coupled to GHC, even though it could be written and distributed separately. But it might be one way of making progress. (It also occurs to me that such an ADT might allow GHC to define a machine-readable serialisable format for its error messages, to allow post-processing by external programs.) Adam [1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker On 05/02/15 09:54, Corentin Dupont wrote: > Hi all, > I have been very interested by this discussion when Alberto started it. > As there been any progress? > The problem is very acute in the Nomyx game I'm developing > (www.nomyx.com ). > The game is based on a DSL, it's working well, but at the moment only > expert Haskell developers can play... > I think cryptic error messages is part of the problem. > How to improve that? > For example, a common error message is the following: > > Won't Compile > :5:28: > Couldn't match type ?'NoEffect? with ?'Effect? > Expected type: Exp Effect () > Actual type: Exp NoEffect () > In the expression: e_1 > In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect () > > It's not so helpful and exposing Nomyx internals. > A better error message would be to hint that the player forgot a "liftEffect" instruction. > > The only quick-and-dirty solution I see is to pattern-match for it and display an additional hint line... -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Feb 6 11:08:45 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 6 Feb 2015 06:08:45 -0500 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Two scattered thoughts on this issue: - I don't think snagging all of the errors from TcErrors is quite enough. For example, the errors generated in TcHsType might also be relevant, and maybe those in TcTyClsDecls. But, getting TcErrors would be 80% of the way, I think. - It has been suggested (I forget by whom, sorry) that sometimes this approach grabs info at the wrong level of abstraction, even for a plugin. As a case in point, I'll think about my `units` package, which implements a domain-specific type system for dimensional analysis. (I know this will be close to Adam's heart!) The errors generated by tiny misuses of this package are disastrous. But, figuring out what went wrong from an error message would still be hard, even as a plugin. Instead, it would be much better if extra checks were put in place during typechecking; if these checks fail, then the errors are easier to diagnose. I'm thinking, in particular of what's done in Helium, as presented at Haskell Implementors' Workshop 2014: http://foswiki.cs.uu.nl/foswiki/pub/Hage/ResearchTalks/hiw-helium.pdf I'm not familiar at all with Idris's approach here, but it would be interesting to compare and contrast the two to see what we can learn from others' experience. In any case, I would very excited for forward progress to be made here! Richard On Feb 6, 2015, at 5:17 AM, Simon Peyton Jones wrote: > I think this is very similar to what Idris supports for reflecting on errors: http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf > > > Aha! Yes, thank you for jogging my memory. I had a good conversation with David Christiansen about this at ICFP, about this very topic, and whether we could steal Idris?s clever ideas and put them in GHC. > > ? He subsequently wrote a blog post > ? Incidentally, in case it?s not clear this thread on Haskell Caf? goes back to Nov 14. The first message in the series had more useful links > > David?s idea is would have much broader scope than just TcErrors. Much of the infrastructure is in place already, since error message are SDocs (an abstract type, private to GHC), not strings. > > Design work needed. Start a wiki page. Articulate a vision. Discuss alternatives. > > Simon > > From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Alejandro Serrano Mena > Sent: 06 February 2015 08:24 > To: Adam Gundry > Cc: Haskell Cafe > Subject: Re: [Haskell-cafe] Domain specific error messages > > I think this is very similar to what Idris supports for reflecting on errors: http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf > > > > 2015-02-06 8:53 GMT+01:00 Adam Gundry : > > [Re-sending to haskell-cafe since I used the wrong From address...] > > This is something that has been on my mind for a while, particularly > following discussions at the last ICFP and prompted by the work on > typechecker plugins in GHC [1]. I think I see a way to proceed, though I > don't know whether I will have time to implement it for a while. I'd be > interested to hear about other approaches. > > Suppose we define an ADT representation of all the typechecker error > messages, e.g. something roughly like > > data TcError = CustomError String > | CouldNotUnify Type Type > | NoClassInstance ... > > In GHC all the relevant messages are generated in the > typechecker/TcErrors module, so this shouldn't be too hard to arrange. > Now we can extend plugins with the ability to supply a function > > tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError] > > and run the plugged-in function between generating and reporting the > errors. Thus a library defining a DSL could also provide a plugin to > supply more informative error messages. > > This is a fairly quick-and-dirty approach, because the plugin would be > quite tightly coupled to GHC, even though it could be written and > distributed separately. But it might be one way of making progress. (It > also occurs to me that such an ADT might allow GHC to define a > machine-readable serialisable format for its error messages, to allow > post-processing by external programs.) > > Adam > > [1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker > > > On 05/02/15 09:54, Corentin Dupont wrote: > > Hi all, > > I have been very interested by this discussion when Alberto started it. > > As there been any progress? > > The problem is very acute in the Nomyx game I'm developing > > (www.nomyx.com ). > > The game is based on a DSL, it's working well, but at the moment only > > expert Haskell developers can play... > > I think cryptic error messages is part of the problem. > > How to improve that? > > For example, a common error message is the following: > > > > Won't Compile > > :5:28: > > Couldn't match type ?'NoEffect? with ?'Effect? > > Expected type: Exp Effect () > > Actual type: Exp NoEffect () > > In the expression: e_1 > > In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect () > > > > It's not so helpful and exposing Nomyx internals. > > A better error message would be to hint that the player forgot a "liftEffect" instruction. > > > > The only quick-and-dirty solution I see is to pattern-match for it and display an additional hint line... > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Fri Feb 6 11:21:56 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Fri, 6 Feb 2015 12:21:56 +0100 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I think it would be a great improvement. However I'm wondering about the initial goal, that was making DSLs: the creator of a DSL is an Haskell expert (more or less), but not a GHC expert. So I'm wondering if the knowledge of TcError and all should be required... How would that work in general? I suppose the creator of a library would: - provide a nice DSL to interface with, - also provide instructions to the compiler for how to handle errors. Should this be done through a language pragma? Then the user of the DSL would simply create his program, compile and get the nice error messages. How to be sure that the modified error messages remain local to the DSL or to the library, and does not pollute all the rest of the compilation? On Fri, Feb 6, 2015 at 11:17 AM, Simon Peyton Jones wrote: > I think this is very similar to what Idris supports for reflecting on > errors: > http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf > > > > Aha! Yes, thank you for jogging my memory. I had a good conversation > with David Christiansen about this at ICFP, about this very topic, and > whether we could steal Idris?s clever ideas and put them in GHC. > > > > ? He subsequently wrote a blog post > > > ? Incidentally, in case it?s not clear this thread on Haskell > Caf? > > goes back to Nov 14. The first message in the series had more useful links > > > > David?s idea is would have much broader scope than just TcErrors. Much of > the infrastructure is in place already, since error message are SDocs (an > abstract type, private to GHC), not strings. > > > > Design work needed. Start a wiki page. Articulate a vision. Discuss > alternatives. > > > > Simon > > > > *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On Behalf > Of *Alejandro Serrano Mena > *Sent:* 06 February 2015 08:24 > *To:* Adam Gundry > *Cc:* Haskell Cafe > *Subject:* Re: [Haskell-cafe] Domain specific error messages > > > > I think this is very similar to what Idris supports for reflecting on > errors: > http://www.itu.dk/people/drc/drafts/error-reflection-submission.pdf > > > > 2015-02-06 8:53 GMT+01:00 Adam Gundry : > > [Re-sending to haskell-cafe since I used the wrong From address...] > > This is something that has been on my mind for a while, particularly > following discussions at the last ICFP and prompted by the work on > typechecker plugins in GHC [1]. I think I see a way to proceed, though I > don't know whether I will have time to implement it for a while. I'd be > interested to hear about other approaches. > > Suppose we define an ADT representation of all the typechecker error > messages, e.g. something roughly like > > data TcError = CustomError String > | CouldNotUnify Type Type > | NoClassInstance ... > > In GHC all the relevant messages are generated in the > typechecker/TcErrors module, so this shouldn't be too hard to arrange. > Now we can extend plugins with the ability to supply a function > > tcPluginAdjustErrors :: [TcError] -> TcPluginM [TcError] > > and run the plugged-in function between generating and reporting the > errors. Thus a library defining a DSL could also provide a plugin to > supply more informative error messages. > > This is a fairly quick-and-dirty approach, because the plugin would be > quite tightly coupled to GHC, even though it could be written and > distributed separately. But it might be one way of making progress. (It > also occurs to me that such an ADT might allow GHC to define a > machine-readable serialisable format for its error messages, to allow > post-processing by external programs.) > > Adam > > [1] https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker > > > On 05/02/15 09:54, Corentin Dupont wrote: > > Hi all, > > I have been very interested by this discussion when Alberto started it. > > As there been any progress? > > The problem is very acute in the Nomyx game I'm developing > > (www.nomyx.com ). > > The game is based on a DSL, it's working well, but at the moment only > > expert Haskell developers can play... > > I think cryptic error messages is part of the problem. > > How to improve that? > > For example, a common error message is the following: > > > > Won't Compile > > :5:28: > > Couldn't match type ?'NoEffect? with ?'Effect? > > Expected type: Exp Effect () > > Actual type: Exp NoEffect () > > In the expression: e_1 > > In the expression: (let e_1 = do { ... } in e_1) :: Exp Effect () > > > > It's not so helpful and exposing Nomyx internals. > > A better error message would be to hint that the player forgot a > "liftEffect" instruction. > > > > The only quick-and-dirty solution I see is to pattern-match for it and > display an additional hint line... > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Fri Feb 6 11:22:42 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 6 Feb 2015 12:22:42 +0100 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20150206112241.GA14688@machine> Hi Richard, > The errors generated by tiny misuses of this package are disastrous. > But, figuring out what went wrong from an error message would still be hard, > even as a plugin. Yes, it also feels a bit too heuristically and if GHC changes, extensions get added or just activated, then the type errors might change and the heuristics break. > Instead, it would be much better if extra checks were put in place > during typechecking; if these checks fail, then the errors are easier > to diagnose. Yes, this seems like a more stable approach. Greetings, Daniel From corentin.dupont at gmail.com Fri Feb 6 11:26:39 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Fri, 6 Feb 2015 12:26:39 +0100 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: <20150206112241.GA14688@machine> References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> <20150206112241.GA14688@machine> Message-ID: On Fri, Feb 6, 2015 at 12:22 PM, Daniel Trstenjak < daniel.trstenjak at gmail.com> wrote: > > Hi Richard, > > > The errors generated by tiny misuses of this package are disastrous. > > But, figuring out what went wrong from an error message would still be > hard, > > even as a plugin. > > Yes, it also feels a bit too heuristically and if GHC changes, > extensions get added or just activated, then the type errors might > change and the heuristics break. > > > Instead, it would be much better if extra checks were put in place > > during typechecking; if these checks fail, then the errors are easier > > to diagnose. > > Yes, this seems like a more stable approach. > Maybe a sort pre-compilation of the DSL, to catch the most common errors? > > > Greetings, > Daniel > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Fri Feb 6 12:36:49 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 6 Feb 2015 13:36:49 +0100 Subject: [Haskell-cafe] Are conditional changes in library interfaces problematic? Message-ID: transformers 0.4 deprecated ErrorT in favor of ExceptT. I've noticed that several packages use CPP to conditionally add ExceptT instances, like this: ``` #if MIN_VERSION_transformers(0,4,0) instance C m => C (ExceptT e m) where #endif ``` The problem I've found with this is that I will get a different interface depending on which transformers version is picked. There is a transformers-compat[1] library that provides ExceptT when using older versions of transformers, when combining these I end up with a compilation failure since the ExceptT instances are no longer included due to CPP. The alternatives I see are: 1. Use transformers-compat (and as of today mtl-compat[2]) 2. Drop support of older versions of dependencies 3. Advise against compat packages The first alternative seems preferable from a user's standpoint. For transformers and mtl I argue it's the most pragmatic option. I think the compat packages are a good thing, especially for core packages, since they let us maintain backwards compatibility. Do you agree with this line of thought? I started working on pull requests to "fix" this but I'd appreciate feedback on the issue first. Along these lines, does conditionally altering the interface of a package like this violate the PVP? Cheers, Adam [1] http://hackage.haskell.org/package/transformers-compat [2] http://hackage.haskell.org/package/mtl-compat -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Fri Feb 6 12:59:08 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 6 Feb 2015 21:59:08 +0900 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 In-Reply-To: References: <20150205051133.GA28929@x60s.casa> Message-ID: Hi Daniel, Thank you for your efforts. I've got a lot of gifts from you. I wish you and your family will be happy:-) and, to haskell-cafe, "Haskell Weekly News: Issue 316" original message[1] had sent only to haskell at haskell.org? (not to haskell-cafe? or my mailer trouble?) [1] https://groups.google.com/forum/#!topic/haskell-cafe/ORq2AymJJgs Thank you, Takenobu 2015-02-06 13:50 GMT+09:00 Daniel Santa Cruz : > On Wed Feb 04 2015 at 10:14:08 PM Francesco Ariis wrote: > >> Thanks so much for doing these! Always useful, great way to keep >> up to date with other places than the ML. >> >> Good luck with the 1 year old, may her steps be functional! >> > > Thanks! I hope her first steps are not lazy :-) > > Cheers, > Daniel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From h-o-k-u-m at yandex.ru Fri Feb 6 12:47:04 2015 From: h-o-k-u-m at yandex.ru (hokum) Date: Fri, 06 Feb 2015 16:47:04 +0400 Subject: [Haskell-cafe] error compiling 24 Days of Hackage: heist Message-ID: <54D4B7C8.5010808@yandex.ru> Hello, I was trying to compile an example of heist (a template engine) usage from 24 Days of Hackage: heist, but ended up with an error message: src/Main.hs:60:7: `hcTemplateLocations' is not a record selector In the first argument of `initHeist', namely `mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}' In a stmt of a 'do' block: heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}) In the second argument of `($)', namely `do { heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}); Just (output, _) <- renderTemplate heist "billy"; liftIO . BS.putStrLn . toByteString $ output }' src/Main.hs:61:7: `hcInterpretedSplices' is not a record selector In the first argument of `initHeist', namely `mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}' In a stmt of a 'do' block: heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}) In the second argument of `($)', namely `do { heist <- initHeist (mempty {hcTemplateLocations = [loadTemplates "templates"], hcInterpretedSplices = defaultInterpretedSplices}); Just (output, _) <- renderTemplate heist "billy"; liftIO . BS.putStrLn . toByteString $ output }' It's probably something to do with lenses, but I'm not very familiar with it. Four hours of googling didn't give me anything on the subject, so any help? Here is the code(in the state I left it): module Main ( main ) where import Blaze.ByteString.Builder (toByteString) import qualified Data.ByteString.Char8 as BS import Control.Monad.IO.Class (MonadIO(..)) import Control.Monad.Trans.Either import Data.Monoid (mempty) import Data.Foldable (forM_) import Heist import Heist.Interpreted import Text.XmlHtml (Node(TextNode), renderHtmlFragment, Encoding(UTF8)) billy :: IO () billy = eitherT (putStrLn . unlines) return $ do heist <- initHeist mempty { hcTemplateLocations = [ loadTemplates "templates" ] , hcInterpretedSplices = defaultInterpretedSplices } Just (output, _) <- renderTemplate heist "billy" liftIO . BS.putStrLn . toByteString $ output main = do putStrLn "---" From adam at well-typed.com Fri Feb 6 14:08:43 2015 From: adam at well-typed.com (Adam Gundry) Date: Fri, 06 Feb 2015 14:08:43 +0000 Subject: [Haskell-cafe] Domain specific error messages In-Reply-To: References: <5472389A.8030503@artyom.me> <54735EC9.1020902@gmail.com> <54D472E2.50707@well-typed.com> <618BE556AADD624C9C918AA5D5911BEF562C081D@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <54D4CAEB.20205@well-typed.com> On 06/02/15 11:08, Richard Eisenberg wrote: > Two scattered thoughts on this issue: > > - I don't think snagging all of the errors from TcErrors is quite > enough. For example, the errors generated in TcHsType might also be > relevant, and maybe those in TcTyClsDecls. But, getting TcErrors would > be 80% of the way, I think. Good point. Ultimately it might be nice if plugins could manipulate any error messages at all, but unsolved constraints (in TcErrors) seem like a good starting point. > - It has been suggested (I forget by whom, sorry) that sometimes this > approach grabs info at the wrong level of abstraction, even for a > plugin. As a case in point, I'll think about my `units` package, which > implements a domain-specific type system for dimensional analysis. (I > know this will be close to Adam's heart!) The errors generated by tiny > misuses of this package are disastrous. But, figuring out what went > wrong from an error message would still be hard, even as a plugin. > Instead, it would be much better if extra checks were put in place > during typechecking; if these checks fail, then the errors are easier to > diagnose. I'm thinking, in particular of what's done in Helium, as > presented at Haskell Implementors' Workshop > 2014: http://foswiki.cs.uu.nl/foswiki/pub/Hage/ResearchTalks/hiw-helium.pdf > I'm not familiar at all with Idris's approach here, but it would be > interesting to compare and contrast the two to see what we can learn > from others' experience. I agree that working backwards from error messages is not necessarily the best approach, but at least it's one that we can see how to implement easily and will allow us to make some progress. Idris is a great example here - I should have credited it for the inspiration in my earlier message. Doing something Helium-like might well be useful, but it's something of a research project (Alejandro's, to be precise!) and would require rather substantial changes to the typechecker in order to control the order in which constraints are solved. For units, I would argue that the right approach is to use a typechecker plugin to implement custom constraint solving behaviour for the equational theory you want... but then I am doing exactly that, so I'm biased. ;-) Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From allbery.b at gmail.com Fri Feb 6 14:12:17 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 6 Feb 2015 09:12:17 -0500 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 In-Reply-To: References: <20150205051133.GA28929@x60s.casa> Message-ID: On Fri, Feb 6, 2015 at 7:59 AM, Takenobu Tani wrote: > and, to haskell-cafe, > "Haskell Weekly News: Issue 316" original message[1] had sent only to > haskell at haskell.org? > (not to haskell-cafe? or my mailer trouble?) > gmail suppresses duplicate messages, so if you are subscribed to both lists you will receive it only once. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.dijk.bas at gmail.com Fri Feb 6 14:12:17 2015 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Fri, 6 Feb 2015 15:12:17 +0100 Subject: [Haskell-cafe] error compiling 24 Days of Hackage: heist In-Reply-To: <54D4B7C8.5010808@yandex.ru> References: <54D4B7C8.5010808@yandex.ru> Message-ID: On 6 February 2015 at 13:47, hokum wrote: > It's probably something to do with lenses, but I'm not very familiar with it. Four hours of googling didn't give me anything on the subject, so any help? Indeed, hcTemplateLocations is not a record field. Try using lenses instead: initHeist $ mempty & hcTemplateLocations .~ [ loadTemplates "templates" ] & hcInterpretedSplices .~ defaultInterpretedSplices From mrz.vtl at gmail.com Fri Feb 6 14:28:16 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Fri, 6 Feb 2015 09:28:16 -0500 Subject: [Haskell-cafe] hflags In-Reply-To: <54D4894B.1090707@mathr.co.uk> References: <54D4894B.1090707@mathr.co.uk> Message-ID: That was it, thanks. I would have never figured it out on my own. I've reported this issue in the hflags bugtracker (to get the workaround in the docs). Hope it will be propagated to ghc if it is not already known. On Fri, Feb 6, 2015 at 4:28 AM, Claude Heiland-Allen wrote: > On 06/02/15 06:26, Maurizio Vitale wrote: > >> with ghc 7.8.4 and hflags 0.4 the following program: >> >> {-# LANGUAGE TemplateHaskell #-} >> >> module Main where >> >> import HFlags >> >> defineFlag "f" True "A flag." >> --defineFlag "g" True "Another flag." >> > > return [] > > -- see http://hackage.haskell.org/package/QuickCheck-2.7.6/docs/ > Test-QuickCheck-All.html#v:quickCheckAll - I haven't tested with hflags > but it looks like the same issue from first glance > > > >> main = do >> _ <- $initHFlags "flags demo" >> print Main.flags_f >> >> gives me a runtime error about the flag f not being found, unless I add >> the >> declaration of a second flag. It seems like the last flag definition is >> not >> seen. >> >> Any idea/suggestion? >> >> Thanks, >> >> Maurizio >> > > > Claude > -- > http://mathr.co.uk > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 6 15:18:36 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 16:18:36 +0100 Subject: [Haskell-cafe] recursion problem part 2 Message-ID: <54D4DB4C.7090202@home.nl> Hello, I partly solved the problem of cis194 of turning 123 into [1,2,3] But I ran into a problem I cannot solve . When I have this : toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | n == 0 = [] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] toDigits 123 gives [ 1,2,3] but toDigits 0 gives [] where I expect to be [0] So I change the code to this : toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | n == 0 = [0] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] Now toDigits 0 gives [ 0] but toDigits 123 gives now [ 0, 1 ,2, 3] where I expect to be [1,2,3] Can someone give me a tip how to solve this I have asked this on the beginners ML but the only answer I get was someone who was using some if -then statement and I think I can be solved without. Roelof From allbery.b at gmail.com Fri Feb 6 15:24:16 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 6 Feb 2015 10:24:16 -0500 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: <54D4DB4C.7090202@home.nl> References: <54D4DB4C.7090202@home.nl> Message-ID: On Fri, Feb 6, 2015 at 10:18 AM, Roelof Wobben wrote: > Can someone give me a tip how to solve this > I have asked this on the beginners ML but the only answer I get was > someone who was using some if -then statement and I think I can be solved > without. > You need to distinguish three "zero" cases: - the value is itself zero - leading zero (i.e. you hit the end of available digits) - interior zero The middle one is your end case --- but this will give you no output if the value you put in initially is zero, since you're already at the end case. So you need to treat an initial value of 0 specially somehow to get output for it. So, either an explicit conditional or a setup where the public function handles an explicit zero and otherwise defers to what you have, which becomes an internal/hidden function (via where or let). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 6 15:40:01 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 16:40:01 +0100 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: References: <54D4DB4C.7090202@home.nl> Message-ID: <54D4E051.8090903@home.nl> Dmitry Olshansky schreef op 6-2-2015 om 16:25: > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | n < 10 = [n] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > Thanks that worked, I have now to figure out why I see [0] on 0 and no zero when it reaches it end-point. isDigits 0 n< 10 so [0] IsDigits 1 n < 0 not true n < 10 not true. toDigits 1 ++ [0] toDigits 1 + [0] n< 0 not true n < 10 true so [1] ++ [0] [1] ++ [0] is [1.0] where the output is [1] So somehow I do not understand fully how this works . Roelof From r.wobben at home.nl Fri Feb 6 15:48:20 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 16:48:20 +0100 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: <54D4E155.6040204@unicaen.fr> References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> Message-ID: <54D4E244.1070502@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Fri Feb 6 16:07:41 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 06 Feb 2015 17:07:41 +0100 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: <54D4E452.10905@unicaen.fr> References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> <54D4E244.1070502@home.nl> <54D4E452.10905@unicaen.fr> Message-ID: <54D4E6CD.2070006@home.nl> Jerzy Karczmarczuk schreef op 6-2-2015 om 16:57: > > Le 06/02/2015 16:48, Roelof Wobben a ?crit : >> Im only sure that somehow I take the wrong turn somewhere because I >> cannot figure out why I do not get the right answer. >> >> I think I have the value of n wrong. > Did you read my answer entirely? Do so, find the red fat line > > You take n=1, and you write: n<10 not True. > You don't need to be a specialist on recursion, to see the error. > > Jerzy > oke, Another try : toDigits :: Integer -> [Integer] toDigits n | n < 0 = [] | n < 10 = [n] | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] isDigits 1 n < 0 not true. n < 10 true so [1] IsDigits 12 n < 0 not true n < 10 not true toDigits 1 + [2] toDigits 1 + [2] n < 0 not true n < 10 true [1] ++ [2] 1 ++2 = [1,2] I think I understand it finnaly. Roelof From jeffbrown.the at gmail.com Fri Feb 6 20:41:13 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Fri, 6 Feb 2015 12:41:13 -0800 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: <54D4E6CD.2070006@home.nl> References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> <54D4E244.1070502@home.nl> <54D4E452.10905@unicaen.fr> <54D4E6CD.2070006@home.nl> Message-ID: Here's a solution: lastDigit x = mod x 10 remainingDigits x = (x - lastDigit x) `div` 10 listDigits x | x < 10 = [x] | otherwise = (listDigits $ remainingDigits x) ++ [lastDigit x] Here's a faster one: listDigits2 x | x < 10 = [x] | otherwise = (listDigits $ remainingDigits) ++ [lastDigit] where lastDigit = mod x 10 remainingDigits = (x - lastDigit) `div` 10 On Fri, Feb 6, 2015 at 8:07 AM, Roelof Wobben wrote: > Jerzy Karczmarczuk schreef op 6-2-2015 om 16:57: > >> >> Le 06/02/2015 16:48, Roelof Wobben a ?crit : >> >>> Im only sure that somehow I take the wrong turn somewhere because I >>> cannot figure out why I do not get the right answer. >>> >>> I think I have the value of n wrong. >>> >> Did you read my answer entirely? Do so, find the red fat line >> >> You take n=1, and you write: n<10 not True. >> You don't need to be a specialist on recursion, to see the error. >> >> Jerzy >> >> > oke, > > Another try : > > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | n < 10 = [n] > | otherwise = toDigits (n `div` 10) ++ [n `mod` 10] > > isDigits 1 > > n < 0 not true. > n < 10 true so [1] > > IsDigits 12 > > n < 0 not true > n < 10 not true > toDigits 1 + [2] > > toDigits 1 + [2] > > n < 0 not true > n < 10 true [1] ++ [2] > > 1 ++2 = [1,2] > > I think I understand it finnaly. > > > Roelof > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Fri Feb 6 22:41:52 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Sat, 7 Feb 2015 02:41:52 +0400 Subject: [Haskell-cafe] hflags In-Reply-To: References: <54D4894B.1090707@mathr.co.uk> Message-ID: This issue was known in hflags: https://github.com/errge/hflags/issues/8 (Opened Jun 30, 2014) and in ghc: https://ghc.haskell.org/trac/ghc/ticket/9768 And it's not a bug, as you can see from discussion in both tickets and reference to ghc-7.8 documentation. On 6 February 2015 at 17:28, Maurizio Vitale wrote: > That was it, thanks. > I would have never figured it out on my own. > > I've reported this issue in the hflags bugtracker (to get the workaround in > the docs). Hope it will be propagated to ghc if it is not already known. > > > On Fri, Feb 6, 2015 at 4:28 AM, Claude Heiland-Allen > wrote: >> >> On 06/02/15 06:26, Maurizio Vitale wrote: >>> >>> with ghc 7.8.4 and hflags 0.4 the following program: >>> >>> {-# LANGUAGE TemplateHaskell #-} >>> >>> module Main where >>> >>> import HFlags >>> >>> defineFlag "f" True "A flag." >>> --defineFlag "g" True "Another flag." >> >> >> return [] >> >> -- see >> http://hackage.haskell.org/package/QuickCheck-2.7.6/docs/Test-QuickCheck-All.html#v:quickCheckAll >> - I haven't tested with hflags but it looks like the same issue from first >> glance >> >> >>> >>> main = do >>> _ <- $initHFlags "flags demo" >>> print Main.flags_f >>> >>> gives me a runtime error about the flag f not being found, unless I add >>> the >>> declaration of a second flag. It seems like the last flag definition is >>> not >>> seen. >>> >>> Any idea/suggestion? >>> >>> Thanks, >>> >>> Maurizio >> >> >> >> Claude >> -- >> http://mathr.co.uk >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Alexander From david.feuer at gmail.com Fri Feb 6 22:42:46 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 6 Feb 2015 17:42:46 -0500 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> <54D4E244.1070502@home.nl> <54D4E452.10905@unicaen.fr> <54D4E6CD.2070006@home.nl> Message-ID: On Feb 6, 2015 3:41 PM, "Jeffrey Brown" wrote: > > Here's a solution: > lastDigit x = mod x 10 > remainingDigits x = (x - lastDigit x) `div` 10 > listDigits x > | x < 10 = [x] > | otherwise = (listDigits $ remainingDigits x) ++ [lastDigit x] > > Here's a faster one: > listDigits2 x > | x < 10 = [x] > | otherwise = (listDigits $ remainingDigits) ++ [lastDigit] > where lastDigit = mod x 10 > remainingDigits = (x - lastDigit) `div` 10 These give somewhat peculiar results when the argument is negative. That can be rectified, of course. Unfortunately, all of these proposed solutions have a serious performance problem: successively appending single elements to build a list of length n is O(n^2). There's an easy fix, which I'll let you come up with. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From aditya.siram at gmail.com Fri Feb 6 23:50:02 2015 From: aditya.siram at gmail.com (aditya siram) Date: Fri, 6 Feb 2015 17:50:02 -0600 Subject: [Haskell-cafe] Installing Package Candidates With Cabal ... Message-ID: Hi all, Is there a way to 'cabal install' a package candidate? The description at https://hackage.haskell.org/upload says it "let others install it before publishing it to the main index" which seems to indicate it can. Am I missing something? Thanks! -deech -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Sat Feb 7 01:01:34 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Fri, 6 Feb 2015 17:01:34 -0800 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> <54D4E244.1070502@home.nl> <54D4E452.10905@unicaen.fr> <54D4E6CD.2070006@home.nl> Message-ID: Is it successively appending? My intention was to prepend. If it's appending, Is that because the ++ operator always evaluates its left argument first, then its right one? On Fri, Feb 6, 2015 at 2:42 PM, David Feuer wrote: > > On Feb 6, 2015 3:41 PM, "Jeffrey Brown" wrote: > > > > Here's a solution: > > lastDigit x = mod x 10 > > remainingDigits x = (x - lastDigit x) `div` 10 > > listDigits x > > | x < 10 = [x] > > | otherwise = (listDigits $ remainingDigits x) ++ [lastDigit x] > > > > Here's a faster one: > > listDigits2 x > > | x < 10 = [x] > > | otherwise = (listDigits $ remainingDigits) ++ [lastDigit] > > where lastDigit = mod x 10 > > remainingDigits = (x - lastDigit) `div` 10 > > These give somewhat peculiar results when the argument is negative. That > can be rectified, of course. Unfortunately, all of these proposed solutions > have a serious performance problem: successively appending single elements > to build a list of length n is O(n^2). There's an easy fix, which I'll let > you come up with. > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sat Feb 7 01:32:53 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 7 Feb 2015 10:32:53 +0900 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 In-Reply-To: References: <20150205051133.GA28929@x60s.casa> Message-ID: Hi Brandon, Thank you for your help. I think my environmental problems. It's OK, if everyone could read it in cafe:-) Thank you, Takenobu 2015-02-06 23:12 GMT+09:00 Brandon Allbery : > On Fri, Feb 6, 2015 at 7:59 AM, Takenobu Tani > wrote: > >> and, to haskell-cafe, >> "Haskell Weekly News: Issue 316" original message[1] had sent only to >> haskell at haskell.org? >> (not to haskell-cafe? or my mailer trouble?) >> > > gmail suppresses duplicate messages, so if you are subscribed to both > lists you will receive it only once. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nrujac at gmail.com Sat Feb 7 01:38:14 2015 From: nrujac at gmail.com (Arjun Comar) Date: Fri, 6 Feb 2015 20:38:14 -0500 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> <54D4E244.1070502@home.nl> <54D4E452.10905@unicaen.fr> <54D4E6CD.2070006@home.nl> Message-ID: Jeff, An expression of the form xs ++ [x] appends the element to the end of the list. In order to evaluate the result, the ++ function iterates through the elements of the first list to find the end of the list then sets the tail of the last element of the first list to the second list. This means that on each recursive call (once per digit), your algorithm must traverse the list of digits already produced to attach the newest element. You can avoid this problem by instead consing the new digit onto the front of the list, and then reverse the list at the end to produce the digits in the correct order. Alternatively, you could try and compute the digits in the reverse order. Here's another solution, though it also will only work on positive integers and will fail on negative inputs: import Data.Char (digitToInt) lastDigit :: Int -> [Int] lastDigit x = map digitToInt (show x) You can fix the issues with this implementation by replacing digitToInt with a wrapper that checks if the character being analyzed is in fact a digit and then providing something if it is not. What you should provide in the failure case is up to the requirements of the problem. Thanks, Arjun On Fri, Feb 6, 2015 at 8:01 PM, Jeffrey Brown wrote: > Is it successively appending? My intention was to prepend. If it's > appending, Is that because the ++ operator always evaluates its left > argument first, then its right one? > > On Fri, Feb 6, 2015 at 2:42 PM, David Feuer wrote: > >> >> On Feb 6, 2015 3:41 PM, "Jeffrey Brown" wrote: >> > >> > Here's a solution: >> > lastDigit x = mod x 10 >> > remainingDigits x = (x - lastDigit x) `div` 10 >> > listDigits x >> > | x < 10 = [x] >> > | otherwise = (listDigits $ remainingDigits x) ++ [lastDigit x] >> > >> > Here's a faster one: >> > listDigits2 x >> > | x < 10 = [x] >> > | otherwise = (listDigits $ remainingDigits) ++ [lastDigit] >> > where lastDigit = mod x 10 >> > remainingDigits = (x - lastDigit) `div` 10 >> >> These give somewhat peculiar results when the argument is negative. That >> can be rectified, of course. Unfortunately, all of these proposed solutions >> have a serious performance problem: successively appending single elements >> to build a list of length n is O(n^2). There's an easy fix, which I'll let >> you come up with. >> >> David >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Sat Feb 7 01:48:06 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Fri, 6 Feb 2015 17:48:06 -0800 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> <54D4E244.1070502@home.nl> <54D4E452.10905@unicaen.fr> <54D4E6CD.2070006@home.nl> Message-ID: I see: what matters is that ++ has to traverse to the end of the first list. The order in which its two arguments are evaluated is irrelevant. Thank you, David and Arjun! On Fri, Feb 6, 2015 at 5:38 PM, Arjun Comar wrote: > Jeff, > An expression of the form xs ++ [x] appends the element to the end of the > list. In order to evaluate the result, the ++ function iterates through the > elements of the first list to find the end of the list then sets the tail > of the last element of the first list to the second list. This means that > on each recursive call (once per digit), your algorithm must traverse the > list of digits already produced to attach the newest element. You can avoid > this problem by instead consing the new digit onto the front of the list, > and then reverse the list at the end to produce the digits in the correct > order. Alternatively, you could try and compute the digits in the reverse > order. > > Here's another solution, though it also will only work on positive > integers and will fail on negative inputs: > > import Data.Char (digitToInt) > > lastDigit :: Int -> [Int] > lastDigit x = map digitToInt (show x) > > You can fix the issues with this implementation by replacing digitToInt > with a wrapper that checks if the character being analyzed is in fact a > digit and then providing something if it is not. What you should provide in > the failure case is up to the requirements of the problem. > > Thanks, > Arjun > > On Fri, Feb 6, 2015 at 8:01 PM, Jeffrey Brown > wrote: > >> Is it successively appending? My intention was to prepend. If it's >> appending, Is that because the ++ operator always evaluates its left >> argument first, then its right one? >> >> On Fri, Feb 6, 2015 at 2:42 PM, David Feuer >> wrote: >> >>> >>> On Feb 6, 2015 3:41 PM, "Jeffrey Brown" wrote: >>> > >>> > Here's a solution: >>> > lastDigit x = mod x 10 >>> > remainingDigits x = (x - lastDigit x) `div` 10 >>> > listDigits x >>> > | x < 10 = [x] >>> > | otherwise = (listDigits $ remainingDigits x) ++ [lastDigit x] >>> > >>> > Here's a faster one: >>> > listDigits2 x >>> > | x < 10 = [x] >>> > | otherwise = (listDigits $ remainingDigits) ++ [lastDigit] >>> > where lastDigit = mod x 10 >>> > remainingDigits = (x - lastDigit) `div` 10 >>> >>> These give somewhat peculiar results when the argument is negative. That >>> can be rectified, of course. Unfortunately, all of these proposed solutions >>> have a serious performance problem: successively appending single elements >>> to build a list of length n is O(n^2). There's an easy fix, which I'll let >>> you come up with. >>> >>> David >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerzy.karczmarczuk at unicaen.fr Sat Feb 7 02:15:37 2015 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Sat, 07 Feb 2015 03:15:37 +0100 Subject: [Haskell-cafe] recursion problem part 2 In-Reply-To: References: <54D4DB4C.7090202@home.nl> <54D4E051.8090903@home.nl> <54D4E155.6040204@unicaen.fr> <54D4E244.1070502@home.nl> <54D4E452.10905@unicaen.fr> <54D4E6CD.2070006@home.nl> Message-ID: <54D57549.9090603@unicaen.fr> Le 07/02/2015 02:48, Jeffrey Brown a ?crit : > I see: what matters is that ++ has to traverse to the end of the first > list. The order in which its two arguments are evaluated is irrelevant. > > Thank you, David and Arjun! > > On Fri, Feb 6, 2015 at 5:38 PM, Arjun Comar > wrote: > > Jeff, > An expression of the form xs ++ [x] appends the element to the end > of the list. In order to evaluate the result, the ++ function > iterates through the elements of the first list to find the end of > the list then sets the tail of the last element of the first list > to the second list. > Gentlemen, don't forget that Haskell is lazy, and this traversal takes place only when the list is effectively traversed by a consumer, which stores everything (and doesn't get rid of elements read). This might be the case here if somebody wants to keep and use the "digit representation" of a number, but please do not consider this phenomenon as inherent to the list creation algorithm. Jerzy Karczmarczuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sat Feb 7 02:31:01 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 7 Feb 2015 11:31:01 +0900 Subject: [Haskell-cafe] [Haskell] Haskell Weekly News: Issue 316 In-Reply-To: References: <20150205051133.GA28929@x60s.casa> Message-ID: sorry, frequent mail in important thread. I understood why I did not receive initial mail. Daniel's initial mail was determined that the spam mail in Gmail. I found it in Gmail spam folder. Cheers, Takenobu 2015-02-07 10:32 GMT+09:00 Takenobu Tani : > Hi Brandon, > > Thank you for your help. > I think my environmental problems. > > It's OK, if everyone could read it in cafe:-) > > Thank you, > Takenobu > > > > 2015-02-06 23:12 GMT+09:00 Brandon Allbery : > >> On Fri, Feb 6, 2015 at 7:59 AM, Takenobu Tani >> wrote: >> >>> and, to haskell-cafe, >>> "Haskell Weekly News: Issue 316" original message[1] had sent only to >>> haskell at haskell.org? >>> (not to haskell-cafe? or my mailer trouble?) >>> >> >> gmail suppresses duplicate messages, so if you are subscribed to both >> lists you will receive it only once. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hasufell at posteo.de Sat Feb 7 16:21:25 2015 From: hasufell at posteo.de (Julian Ospald) Date: Sat, 07 Feb 2015 16:21:25 +0000 Subject: [Haskell-cafe] cryptography in haskell Message-ID: <54D63B85.3020403@posteo.de> Hi, I've been wondering about the state of cryptography in haskell. Not so much in the sense of "what libraries are out there?", but rather about the question what crpyto and IT security people think about ideas like rewriting something as OpenSSL in haskell. I know it can be technically done, but are there any remarks in this area that are important for practical security? For example, some people think that it can be dangerous to implement something like this in high-level languages (e.g. java which was vulnerable to timing attacks). Of course I think haskell can do a lot for us to make things safer: * type safety * referential transparency * explicit knowledge about side-effects and which kind ... But that doesn't tell me if it introduces new pitfalls/attack-vectors for practical cryptography implementations. -- Regards, Julian Ospald From haskell at patrickmylund.com Sat Feb 7 16:53:42 2015 From: haskell at patrickmylund.com (Patrick Mylund Nielsen) Date: Sat, 7 Feb 2015 11:53:42 -0500 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: <54D63B85.3020403@posteo.de> References: <54D63B85.3020403@posteo.de> Message-ID: On Sat, Feb 7, 2015 at 11:21 AM, Julian Ospald wrote: > I've been wondering about the state of cryptography in haskell. Not so > much in the sense of "what libraries are out there?", but rather about > the question what crpyto and IT security people think about ideas like > rewriting something as OpenSSL in haskell. > I know it can be technically done, but are there any remarks in this > area that are important for practical security? > It's an interesting exercise (at least implementing TLSv1.2+) One thing to remember, though, is that a lot of the issues with OpenSSL aren't solved by having memory safety or isolation of effects: downgrade attacks, mac-then-encrypt instead of encrypt-then-mac, Heartbleed, etc. In other words, Haskell eliminates several classes of errors, but doesn't prevent logic errors, and can do nothing about poor standards. Aside from this, I think the main issues would be: - Timing resistance: This is not as simple as sprinkling some bitwise operations on your crypto code. It took a long time to figure out even the basics in OpenSSL, and for better and worse it's more difficult to intuit what your Haskell code will be compiled to than it is with C (though C compilers have been known to optimize away constant-time code.) - Usability: C is easy to embed in any program written in any language. Haskell, not so much. If nobody is using your library, it doesn't matter if it's the safest TLS implementation in the world! (Another small issue is that it's not easy to erase something, e.g. a private key, from memory in Haskell, so they may stick around for some time. This isn't a big deal as long as your application's memory isn't swapped to disk.) >From a high-level security perspective, libressl offers the most hope in the short-term, and it's possible that e.g. a Rust (which at least is a lot like Haskell, but without a runtime!) TLS implementation could replace OpenSSL in a lot of existing applications in the longer-term. But because of the complexity of TLS and the possibility of logic errors, it's not a sure thing that implementations in Rust, Haskell, or what have you, would be more, or even equally as safe as something like libressl. That being said, if you're thinking about doing something like this, go for it! Implementing TLS is fun (as long as you don't try to reach compatibility with anything but recent clients,) and it might be useful for other Haskellers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khushil.dep at gmail.com Sat Feb 7 18:25:48 2015 From: khushil.dep at gmail.com (Khushil Dep) Date: Sat, 7 Feb 2015 10:25:48 -0800 (PST) Subject: [Haskell-cafe] Functional Programmers Sought Message-ID: I'm looking for experienced functional programmers who are happy to work with Haskell, Scala or Clojure. Please see https://hackerjobs.co.uk/jobs/2015/2/4/guardtime-experienced-functional-software-engineer I'm afraid I can't hire outside the UK or EU areas for this role. Very competitive salaries for the right person, occasional EU/US travel, working from home. Direct hire - I'm not an agency. You'll be working for me. Please ping me on here or privately at the e-mail address on the HackerJobs advert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaki at manian.org Sat Feb 7 20:50:19 2015 From: zaki at manian.org (zaki at manian.org) Date: Sat, 7 Feb 2015 12:50:19 -0800 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: References: <54D63B85.3020403@posteo.de> Message-ID: On Sat, Feb 7, 2015 at 8:53 AM, Patrick Mylund Nielsen < haskell at patrickmylund.com> wrote: > On Sat, Feb 7, 2015 at 11:21 AM, Julian Ospald wrote: > >> I've been wondering about the state of cryptography in haskell. Not so >> much in the sense of "what libraries are out there?", but rather about >> the question what crpyto and IT security people think about ideas like >> rewriting something as OpenSSL in haskell. > > >> > I know it can be technically done, but are there any remarks in this >> area that are important for practical security? >> > > It's an interesting exercise (at least implementing TLSv1.2+) One thing to > remember, though, is that a lot of the issues with OpenSSL aren't solved by > having memory safety or isolation of effects: downgrade attacks, > mac-then-encrypt instead of encrypt-then-mac, Heartbleed, etc. > > In other words, Haskell eliminates several classes of errors, but doesn't > prevent logic errors, and can do nothing about poor standards. > > Aside from this, I think the main issues would be: > > - Timing resistance: This is not as simple as sprinkling some bitwise > operations on your crypto code. It took a long time to figure out even the > basics in OpenSSL, and for better and worse it's more difficult to intuit > what your Haskell code will be compiled to than it is with C (though C > compilers have been known to optimize away constant-time code.) > > - Usability: C is easy to embed in any program written in any language. > Haskell, not so much. If nobody is using your library, it doesn't matter if > it's the safest TLS implementation in the world! > > TLS contains numerous design errors that we all have to live with like "mac then encrypt" which we have to deal with through incredibly "careful" implementation. It would be an interesting research project to try to understand if laziness is a benefit or a challenge when working with flawed protocol designs that known to vulnerable to timing oracle attacks. The Open Mirage project which uses an OCAML unikernel architecture makes a strong case for putting security critical parts of an applications stack in a virtualized type safe container. Haskell seems like it offers the strongest properties when demonstrating a good design is implemented as intended. It isn't likely to have any magic properties for protect against poor design. > (Another small issue is that it's not easy to erase something, e.g. a > private key, from memory in Haskell, so they may stick around for some > time. This isn't a big deal as long as your application's memory isn't > swapped to disk.) > > From a high-level security perspective, libressl offers the most hope in > the short-term, and it's possible that e.g. a Rust (which at least is a lot > like Haskell, but without a runtime!) TLS implementation could replace > OpenSSL in a lot of existing applications in the longer-term. But because > of the complexity of TLS and the possibility of logic errors, it's not a > sure thing that implementations in Rust, Haskell, or what have you, would > be more, or even equally as safe as something like libressl. > > That being said, if you're thinking about doing something like this, go > for it! Implementing TLS is fun (as long as you don't try to reach > compatibility with anything but recent clients,) and it might be useful for > other Haskellers. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Sat Feb 7 20:57:49 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Sat, 07 Feb 2015 21:57:49 +0100 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: <54D63B85.3020403@posteo.de> References: <54D63B85.3020403@posteo.de> Message-ID: <54D67C4D.8020503@centrum.cz> I'm not sure if you have already read it, but at least for the reference in this thread, this is also discussed here: https://news.ycombinator.com/item?id=7557089 Karel On 02/ 7/15 05:21 PM, Julian Ospald wrote: > Hi, > > I've been wondering about the state of cryptography in haskell. Not so > much in the sense of "what libraries are out there?", but rather about > the question what crpyto and IT security people think about ideas like > rewriting something as OpenSSL in haskell. > > I know it can be technically done, but are there any remarks in this > area that are important for practical security? > > For example, some people think that it can be dangerous to implement > something like this in high-level languages (e.g. java which was > vulnerable to timing attacks). > > Of course I think haskell can do a lot for us to make things safer: > * type safety > * referential transparency > * explicit knowledge about side-effects and which kind > ... > > But that doesn't tell me if it introduces new pitfalls/attack-vectors > for practical cryptography implementations. > > > -- > Regards, > Julian Ospald > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From darthdeus at gmail.com Sat Feb 7 22:28:30 2015 From: darthdeus at gmail.com (Jakub Arnold) Date: Sat, 07 Feb 2015 22:28:30 +0000 Subject: [Haskell-cafe] MySQL + Windows + Haskell = ??? Message-ID: Hey guys, I've been trying to get my Yesod app working on Windows 8.1 using the Haskell Platform 2014.2.0.0, and everything seemes to work well, except for MySQL. The `mysql` package doesn't build with the following error setup.exe: The program mysql_config is required but it could not be found I've found a related GitHub issue (https://github.com/bos/mysql/issues/3), but there doesn't seem to be any solution. Is there anyone who's successfully running using Haskell and MySQL on Windows? I've also tried `hdbc-mysql` and `mysql-simple`, but they both depend on the `mysql` package, so that didn't really help. I can't really use a different database, or Linux. Thanks for any tips, Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Feb 7 22:53:24 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 7 Feb 2015 17:53:24 -0500 Subject: [Haskell-cafe] MySQL + Windows + Haskell = ??? In-Reply-To: References: Message-ID: On Sat, Feb 7, 2015 at 5:28 PM, Jakub Arnold wrote: > setup.exe: The program mysql_config is required but it could not be > found > You need to get a mysql development package for Windows from somewhere. Unfortunately I can't help with that. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Sat Feb 7 23:54:45 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 08 Feb 2015 01:54:45 +0200 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: References: <54D63B85.3020403@posteo.de> Message-ID: <54D6A5C5.805@ro-che.info> On 07/02/15 18:53, Patrick Mylund Nielsen wrote: > (Another small issue is that it's not easy to erase something, e.g. a > private key, from memory in Haskell, so they may stick around for some > time. This isn't a big deal as long as your application's memory isn't > swapped to disk.) https://hackage.haskell.org/package/securemem > That being said, if you're thinking about doing something like this, go > for it! Implementing TLS is fun (as long as you don't try to reach > compatibility with anything but recent clients,) and it might be useful > for other Haskellers. https://hackage.haskell.org/package/tls From haskell at patrickmylund.com Sun Feb 8 01:01:29 2015 From: haskell at patrickmylund.com (Patrick Mylund Nielsen) Date: Sat, 7 Feb 2015 20:01:29 -0500 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: <54D6A5C5.805@ro-che.info> References: <54D63B85.3020403@posteo.de> <54D6A5C5.805@ro-che.info> Message-ID: On Sat, Feb 7, 2015 at 6:54 PM, Roman Cheplyaka wrote: > On 07/02/15 18:53, Patrick Mylund Nielsen wrote: > > (Another small issue is that it's not easy to erase something, e.g. a > > private key, from memory in Haskell, so they may stick around for some > > time. This isn't a big deal as long as your application's memory isn't > > swapped to disk.) > > https://hackage.haskell.org/package/securemem Now consider how you'd construct and use a SecureMem without copying your secret all over memory. Again, not a big issue, but it's trickier in garbage-collected languages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From darthdeus at gmail.com Sun Feb 8 02:33:27 2015 From: darthdeus at gmail.com (Jakub Arnold) Date: Sun, 08 Feb 2015 02:33:27 +0000 Subject: [Haskell-cafe] Building with some dependencies pre-installed in a sandbox Message-ID: Hey guys, sorry for re-posting, but I feel that my original question is largely different from this one. I've managed to get my broken dependency to build (the mysql package), but unfortunately I had to manually change its source code to make this happen, (original post https://www.haskell.org/pipermail/haskell-cafe/2015-February/118064.html), but I do have the package installed locally (or in the sandbox of my app). The problem is that when I try to `cabal install` the whole application, it will re-download the `mysql` package from Hackage and try to build it again, instead of using the version I custom built and installed myself. Is it normal that cabal won't re-use the already existing packages, or did I somehow change it so that it won't recognize it? Also, is it possible to explicitly say where should cabal resolve some of its dependencies? Such as this case when one package is in a local path, and other should be built from hackage. I'm not really sure what the best approach is here. again sorry for posting twice in a row, but I just can't seem to find this information anywhere in the docs Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mietek at bak.io Sun Feb 8 02:50:08 2015 From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=) Date: Sun, 8 Feb 2015 02:50:08 +0000 Subject: [Haskell-cafe] Building with some dependencies pre-installed in a sandbox In-Reply-To: References: Message-ID: <6AEE7490-C10F-428B-876A-2D744E706458@bak.io> It sounds like you?re looking for `cabal sandbox add-source`: https://www.haskell.org/cabal/users-guide/installing-packages.html#developing-with-sandboxes -- Mi?tek On 2015-02-08, at 02:33, Jakub Arnold wrote: > Hey guys, sorry for re-posting, but I feel that my original question is largely different from this one. > > I've managed to get my broken dependency to build (the mysql package), but unfortunately I had to manually change its source code to make this happen, (original post https://www.haskell.org/pipermail/haskell-cafe/2015-February/118064.html), but I do have the package installed locally (or in the sandbox of my app). > > The problem is that when I try to `cabal install` the whole application, it will re-download the `mysql` package from Hackage and try to build it again, instead of using the version I custom built and installed myself. Is it normal that cabal won't re-use the already existing packages, or did I somehow change it so that it won't recognize it? > > Also, is it possible to explicitly say where should cabal resolve some of its dependencies? Such as this case when one package is in a local path, and other should be built from hackage. I'm not really sure what the best approach is here. > > again sorry for posting twice in a row, but I just can't seem to find this information anywhere in the docs > > Thanks! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4203 bytes Desc: not available URL: From ivan.perez at keera.co.uk Mon Feb 9 07:56:56 2015 From: ivan.perez at keera.co.uk (Ivan Perez) Date: Mon, 09 Feb 2015 07:56:56 +0000 Subject: [Haskell-cafe] Officially supported Android backend, GSoC? Message-ID: <54D86848.7060903@keera.co.uk> Hi Caf? For the past few years I have done quite a lot of work in functional languages targeting mobile platforms. I've tried every functional language I could find. GHC targets Android via Neurocyte's (and JoeyH's) backend [1], although, afaik, this is not officially supported. There have been recent discussions on strategies to improve the current state, especially wrt. TH. Nevertheless, the progress is amazing and the backend works very well. I haven't found any major bugs. We've successfully used this at Keera Studios to write multiple games [2,3,4], and I've also written small applications for Google Glass (yes, Haskell works on Glass!). Users are running the games on different Android devices (with different hardware and OS version), and none of them has reported any (ghc-related) bugs so far. Haskell's ability to 'write once, run anywhere' could be a major selling point. Soon Haskell might become one of the very few functional languages that can target any platform, be it web, desktop or mobile, with minimal changes to the codebase (F# can do all of this; but, apart from language differences, developing and deploying software for Android is not free as in beer). So, I'd like to ask: 1) Does officially supporting the Android backend sound like a (strategically) reasonable and viable idea? 2) What would it take? Could a Google Summer of Code project help get things up to speed? (The project proposal deadline is probably very soon.) Cheers Ivan [1] https://github.com/neurocyte/ghc-android [2] http://tiny.cc/w53rtx (Link to Facebook photo, visible without a FB account). [3] http://tiny.cc/l73rtx (Link to Facebook photo, visible without a FB account). [4] http://tiny.cc/e83rtx (Link to Facebook photo, visible without a FB account). From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Feb 9 11:19:37 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 9 Feb 2015 11:19:37 +0000 Subject: [Haskell-cafe] Use of STM in business? Message-ID: <20150209111937.GF10648@weber> >From associate of mine: "I am quite curious if anyone actually uses Haskell (esp STM) successfully in business." Of course I can anwser the general question about usage of Haskell in business, but I don't know much about STM specifically. Can anyone provide me with any references to where STM has been used in production in a business setting? Thanks, Tom From alois.cochard at gmail.com Mon Feb 9 11:24:12 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Mon, 9 Feb 2015 12:24:12 +0100 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: <20150209111937.GF10648@weber> References: <20150209111937.GF10648@weber> Message-ID: Hi Tom, I can't share much code yet, but I have build a small service that run in production which tail the mongodb log and convert this to rabbitmq event, it's built entirely on the STM and give pretty performance. FWIW, it works very well, stable and stuff. Cheers On 9 February 2015 at 12:19, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > From associate of mine: "I am quite curious if anyone actually uses Haskell > (esp STM) successfully in business." > > Of course I can anwser the general question about usage of Haskell in > business, but I don't know much about STM specifically. Can anyone provide > me with any references to where STM has been used in production in a > business setting? > > Thanks, > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozgurakgun at gmail.com Mon Feb 9 11:36:05 2015 From: ozgurakgun at gmail.com (Ozgur Akgun) Date: Mon, 9 Feb 2015 11:36:05 +0000 Subject: [Haskell-cafe] GHC-7.8.4 for Mac OS X Message-ID: Hi, Does anyone plan to put a binary release of GHC-7.8.4 for OS X? There isn't one here: https://www.haskell.org/ghc/download_ghc_7_8_4 Cheers! Ozgur -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Mon Feb 9 11:46:27 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Mon, 9 Feb 2015 13:46:27 +0200 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: <20150209111937.GF10648@weber> References: <20150209111937.GF10648@weber> Message-ID: Hi Tom. Pretty much anywhere in your program where you have a state, shared by multiple threads, and which's consistency gets more complex than the one that's operated by few atomic operations, you might get benefit from using STM. For example, I have a web app that needs to operate fast (e.g. from memory), that's why it has few HashMaps used as a cache. Those HashMaps need to be consistent with each other, e.g. you need to modify them both simultaneously to keep data "synced" between them. STM solves this great, as each of HashMaps is wrapped by TMVar, so update just uses an STM transaction to update both of them. While reads often need to read only one of these HashMaps, that's why putting all of them under single MVar would be a worse idea. Hope this clarifies use-case a bit. Thanks. On Mon, Feb 9, 2015 at 1:19 PM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > From associate of mine: "I am quite curious if anyone actually uses Haskell > (esp STM) successfully in business." > > Of course I can anwser the general question about usage of Haskell in > business, but I don't know much about STM specifically. Can anyone provide > me with any references to where STM has been used in production in a > business setting? > > Thanks, > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Mon Feb 9 11:51:01 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 9 Feb 2015 12:51:01 +0100 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: <20150209111937.GF10648@weber> References: <20150209111937.GF10648@weber> Message-ID: We use STM for various things, one of which is our in memory graph database. It's not open source, but it's a core part of our business. We also use it in other places for small bits of shared state, both in public facing (web) applications and development tools. Let me know if you want any further details. Erik On Mon, Feb 9, 2015 at 12:19 PM, Tom Ellis wrote: > From associate of mine: "I am quite curious if anyone actually uses Haskell > (esp STM) successfully in business." > > Of course I can anwser the general question about usage of Haskell in > business, but I don't know much about STM specifically. Can anyone provide > me with any references to where STM has been used in production in a > business setting? > > Thanks, > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From dct25-561bs at mythic-beasts.com Mon Feb 9 12:19:00 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Mon, 9 Feb 2015 12:19:00 +0000 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: <20150209111937.GF10648@weber> References: <20150209111937.GF10648@weber> Message-ID: Yes, we use it in a commercial product. As the other replies, I can't give too much detail, but amongst other uses it enormously simplifies the implementation of passing events over HTTP using long-polling: http://stackoverflow.com/questions/17022625/long-polling-in-yesod/27481455#27481455 On 9 February 2015 at 11:19, Tom Ellis wrote: > From associate of mine: "I am quite curious if anyone actually uses Haskell > (esp STM) successfully in business." > > Of course I can anwser the general question about usage of Haskell in > business, but I don't know much about STM specifically. Can anyone provide > me with any references to where STM has been used in production in a > business setting? > > Thanks, > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From f at mazzo.li Mon Feb 9 12:20:23 2015 From: f at mazzo.li (Francesco Mazzoli) Date: Mon, 9 Feb 2015 13:20:23 +0100 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: References: <20150209111937.GF10648@weber> Message-ID: Hi Tom, I used STM in an Haskell web application that was in production (it is now defunct). We used it in the implementation of a custom document store. Francesco On 9 February 2015 at 12:51, Erik Hesselink wrote: > We use STM for various things, one of which is our in memory graph > database. It's not open source, but it's a core part of our business. > We also use it in other places for small bits of shared state, both in > public facing (web) applications and development tools. Let me know if > you want any further details. > > Erik > > On Mon, Feb 9, 2015 at 12:19 PM, Tom Ellis > wrote: >> From associate of mine: "I am quite curious if anyone actually uses Haskell >> (esp STM) successfully in business." >> >> Of course I can anwser the general question about usage of Haskell in >> business, but I don't know much about STM specifically. Can anyone provide >> me with any references to where STM has been used in production in a >> business setting? >> >> Thanks, >> >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From hjgtuyl at chello.nl Mon Feb 9 13:00:08 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Mon, 09 Feb 2015 14:00:08 +0100 Subject: [Haskell-cafe] Cabal: Missing field in record construction configProf Message-ID: L.S., I am trying to install a package with the new GHC 7.10 RC 2 (I recompiled cabal.exe with it, and now "cabal update" finally works again). The install fails, even after renaming the cabal config file: > cabal install Config file path source is default config file. Config file C:\Users\X\AppData\Roaming\cabal\config not found. Writing default configuration to C:\Users\X\AppData\Roaming\cabal\config Resolving dependencies... Configuring random-1.1... cabal: Distribution\Client\Config.hs:(246,37)-(299,9): Missing field in record construction configProf What does this message mean? How can I correct this? Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From bjp at informatik.uni-kiel.de Mon Feb 9 13:09:37 2015 From: bjp at informatik.uni-kiel.de (=?windows-1252?Q?Bj=F6rn_Peem=F6ller?=) Date: Mon, 09 Feb 2015 14:09:37 +0100 Subject: [Haskell-cafe] Cabal: Missing field in record construction configProf In-Reply-To: References: Message-ID: <54D8B191.3060102@informatik.uni-kiel.de> Am 09.02.2015 um 14:00 schrieb Henk-Jan van Tuyl: > > L.S., > > I am trying to install a package with the new GHC 7.10 RC 2 (I > recompiled cabal.exe with it, and now "cabal update" finally works > again). The install fails, even after renaming the cabal config file: This is a problem in the version of Cabal that ships with the GHC RC2, see https://github.com/haskell/cabal/issues/2389 . I could fix it manually by reinstalling Cabal-1.22.0.0 taken from Hackage, but as the issue is now fixed reinstalling Cabal-1.22.1.0 from the GitHub repository should also work, I think. Regards, Bj?rn From semanticphilosopher at gmail.com Mon Feb 9 13:45:32 2015 From: semanticphilosopher at gmail.com (Neil Davies) Date: Mon, 9 Feb 2015 13:45:32 +0000 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: References: <20150209111937.GF10648@weber> Message-ID: Hi Tom We make extensive use of it in ?realtime? network performance analysis. As has been said, the ability to both share state and co-ordinate serial/parallel flow of control is key. Neil On 9 Feb 2015, at 12:20, Francesco Mazzoli wrote: > Hi Tom, > > I used STM in an Haskell web application that was in production (it is > now defunct). We used it in the implementation of a custom document > store. > > Francesco > > On 9 February 2015 at 12:51, Erik Hesselink wrote: >> We use STM for various things, one of which is our in memory graph >> database. It's not open source, but it's a core part of our business. >> We also use it in other places for small bits of shared state, both in >> public facing (web) applications and development tools. Let me know if >> you want any further details. >> >> Erik >> >> On Mon, Feb 9, 2015 at 12:19 PM, Tom Ellis >> wrote: >>> From associate of mine: "I am quite curious if anyone actually uses Haskell >>> (esp STM) successfully in business." >>> >>> Of course I can anwser the general question about usage of Haskell in >>> business, but I don't know much about STM specifically. Can anyone provide >>> me with any references to where STM has been used in production in a >>> business setting? >>> >>> Thanks, >>> >>> Tom >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From gbwey9 at gmail.com Mon Feb 9 13:46:06 2015 From: gbwey9 at gmail.com (grant) Date: Mon, 9 Feb 2015 08:46:06 -0500 Subject: [Haskell-cafe] MySQL + Windows + Haskell = ??? In-Reply-To: References: Message-ID: Hi Jakub, You could try persistent-odbc. This should give you access to mysql on windows via odbc.. Grant On Sat, Feb 7, 2015 at 5:28 PM, Jakub Arnold wrote: > Hey guys, > > I've been trying to get my Yesod app working on Windows 8.1 using the > Haskell Platform 2014.2.0.0, and everything seemes to work well, except for > MySQL. The `mysql` package doesn't build with the following error > > setup.exe: The program mysql_config is required but it could not be > found > > I've found a related GitHub issue (https://github.com/bos/mysql/issues/3), > but there doesn't seem to be any solution. > > Is there anyone who's successfully running using Haskell and MySQL on > Windows? I've also tried `hdbc-mysql` and `mysql-simple`, but they both > depend on the `mysql` package, so that didn't really help. I can't really > use a different database, or Linux. > > Thanks for any tips, > Jakub > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Mon Feb 9 14:12:10 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Mon, 9 Feb 2015 09:12:10 -0500 (EST) Subject: [Haskell-cafe] Building with some dependencies pre-installed in a sandbox In-Reply-To: <6AEE7490-C10F-428B-876A-2D744E706458@bak.io> Message-ID: <120447305.5806220.1423491130039.JavaMail.root@covenanteyes.com> Jakub, It's certainly a hack, but one thing you can do is the following: In your main package (the one which depends on your customization), simply set up a sandbox like this: $ cd /home/me/my-package $ cabal sandbox init Then, in your custom mysql package, tell it to *share* a sandbox with "my-package" and then install it, like this: $ cd /home/me/mysql-custom $ cabal sandbox init --sandbox /home/me/my-package/.cabal-sandbox $ cabal install Now, back in "my-package", "cabal install --dependencies-only" will not re-download mysql. Make sure that your cabal config depends on the same package name and version that you have customized. Hope this helps: Elliot ----- Original Message ----- From: "Mi?tek Bak" To: "Jakub Arnold" Cc: haskell-cafe at haskell.org Sent: Saturday, February 7, 2015 9:50:08 PM Subject: Re: [Haskell-cafe] Building with some dependencies pre-installed in a sandbox It sounds like you?re looking for `cabal sandbox add-source`: https://www.haskell.org/cabal/users-guide/installing-packages.html#developing-with-sandboxes -- Mi?tek On 2015-02-08, at 02:33, Jakub Arnold wrote: > Hey guys, sorry for re-posting, but I feel that my original question is largely different from this one. > > I've managed to get my broken dependency to build (the mysql package), but unfortunately I had to manually change its source code to make this happen, (original post https://www.haskell.org/pipermail/haskell-cafe/2015-February/118064.html), but I do have the package installed locally (or in the sandbox of my app). > > The problem is that when I try to `cabal install` the whole application, it will re-download the `mysql` package from Hackage and try to build it again, instead of using the version I custom built and installed myself. Is it normal that cabal won't re-use the already existing packages, or did I somehow change it so that it won't recognize it? > > Also, is it possible to explicitly say where should cabal resolve some of its dependencies? Such as this case when one package is in a local path, and other should be built from hackage. I'm not really sure what the best approach is here. > > again sorry for posting twice in a row, but I just can't seem to find this information anywhere in the docs > > Thanks! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Mon Feb 9 15:58:04 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 9 Feb 2015 16:58:04 +0100 Subject: [Haskell-cafe] Injective type families for GHC Message-ID: <201502091658.04383.jan.stolarek@p.lodz.pl> Haskellers, I am finishing work on adding injective type families to GHC. I know that in the past many people have asked for this feature. If you have use cases for injective type families I would appreciate if you could show them to me. My implementation has some restrictions and I want to see how severe these restrictions are from a practical point of view. Janek --- Politechnika ??dzka Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. From bob at redivi.com Mon Feb 9 16:46:31 2015 From: bob at redivi.com (Bob Ippolito) Date: Mon, 9 Feb 2015 08:46:31 -0800 Subject: [Haskell-cafe] GHC-7.8.4 for Mac OS X In-Reply-To: References: Message-ID: I've been waiting for that as well, I haven't published a new version of http://ghcformacosx.github.io/ because there hasn't been a new official binary to build it with. On Mon, Feb 9, 2015 at 3:36 AM, Ozgur Akgun wrote: > Hi, > > Does anyone plan to put a binary release of GHC-7.8.4 for OS X? > > There isn't one here: https://www.haskell.org/ghc/download_ghc_7_8_4 > > Cheers! > Ozgur > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Mon Feb 9 17:06:26 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Mon, 09 Feb 2015 18:06:26 +0100 Subject: [Haskell-cafe] Installing Package Candidates With Cabal ... In-Reply-To: References: Message-ID: On Sat, 07 Feb 2015 00:50:02 +0100, aditya siram wrote: > Is there a way to 'cabal install' a package candidate? You can install with a URL instead of a package name, like this: cabal install http://hackage.haskell.org/package/clock-0.4.1.3/clock-0.4.1.3.tar.gz (HTTPS is not supported) Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From roma at ro-che.info Mon Feb 9 19:10:58 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 09 Feb 2015 21:10:58 +0200 Subject: [Haskell-cafe] Injective type families for GHC In-Reply-To: <201502091658.04383.jan.stolarek@p.lodz.pl> References: <201502091658.04383.jan.stolarek@p.lodz.pl> Message-ID: <54D90642.2060806@ro-che.info> Huh, that's a tough question! I've certainly run into the non-injectivity issue quite a few times, but it's hard to remember a single specific case. You may want to look at the uses of data families. In my experience, a programmer would often (almost always?) prefer a type family, but has to resort to a data family when s/he runs into non-injectivity. Is your design described anywhere? On 09/02/15 17:58, Jan Stolarek wrote: > Haskellers, > > I am finishing work on adding injective type families to GHC. I know that in the past many people > have asked for this feature. If you have use cases for injective type families I would appreciate > if you could show them to me. My implementation has some restrictions and I want to see how > severe these restrictions are from a practical point of view. > > Janek > > --- > Politechnika ??dzka > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From jan.stolarek at p.lodz.pl Mon Feb 9 19:14:53 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Mon, 9 Feb 2015 20:14:53 +0100 Subject: [Haskell-cafe] Injective type families for GHC In-Reply-To: <54D90642.2060806@ro-che.info> References: <201502091658.04383.jan.stolarek@p.lodz.pl> <54D90642.2060806@ro-che.info> Message-ID: <201502092014.53770.jan.stolarek@p.lodz.pl> > Is your design described anywhere? https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies At the moment some sections of this page are slightly out of date. I have an update prepared but it will go online after the merge. Janek --- Politechnika ??dzka Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. From carter.schonwald at gmail.com Mon Feb 9 20:34:58 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 9 Feb 2015 15:34:58 -0500 Subject: [Haskell-cafe] GHC-7.8.4 for Mac OS X In-Reply-To: References: Message-ID: theres been my unofficial build, but i guess thats not official enough :) On Mon, Feb 9, 2015 at 11:46 AM, Bob Ippolito wrote: > I've been waiting for that as well, I haven't published a new version of > http://ghcformacosx.github.io/ because there hasn't been a new official > binary to build it with. > > On Mon, Feb 9, 2015 at 3:36 AM, Ozgur Akgun wrote: > >> Hi, >> >> Does anyone plan to put a binary release of GHC-7.8.4 for OS X? >> >> There isn't one here: https://www.haskell.org/ghc/download_ghc_7_8_4 >> >> Cheers! >> Ozgur >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Mon Feb 9 20:35:52 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 9 Feb 2015 12:35:52 -0800 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: <20150209111937.GF10648@weber> References: <20150209111937.GF10648@weber> Message-ID: <20150209123552.58f6b11c184bafff7a4903d6@mega-nerd.com> Tom Ellis wrote: > From associate of mine: "I am quite curious if anyone actually uses Haskell > (esp STM) successfully in business." > > Of course I can anwser the general question about usage of Haskell in > business, but I don't know much about STM specifically. Can anyone provide > me with any references to where STM has been used in production in a > business setting? I used STM in a helper application for an internal web app in my current job. The helper polls a database for jobs once an hour and places jobs in an work queue and mulltiple workers pull from the work queue and exectue the jobs. The work queue is built out of STM elements. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From vogt.adam at gmail.com Tue Feb 10 00:29:21 2015 From: vogt.adam at gmail.com (adam vogt) Date: Mon, 9 Feb 2015 19:29:21 -0500 Subject: [Haskell-cafe] Injective type families for GHC In-Reply-To: <201502091658.04383.jan.stolarek@p.lodz.pl> References: <201502091658.04383.jan.stolarek@p.lodz.pl> Message-ID: Hi Jan, One example is https://github.com/haskell/vector/issues/34 I see lots of potential uses in HList. For example in HZip.hs there's a Zip using type families: type family HZipR (x::[*]) (y::[*]) :: [*] type instance HZipR '[] '[] = '[] type instance HZipR (x ': xs) (y ': ys) = (x,y) ': HZipR xs ys If there was no need to write some additional type families that tell ghc how to find x and y given HZipR x y, then the version using TFs might be as good as the version using FDs (defined in HList.hs) I don't know how realistic this is but a constraint (HLength x ~ HLength y) would ideally have the same result as SameLength x y. Copy-paste into ghci: :set +t -XDataKinds -XFlexibleContexts -XTypeFamilies import Data.HList let desired = Proxy :: SameLength x '[(),()] => Proxy x let current = Proxy :: (HLength y ~ HLength '[(),()]) => Proxy y Prints desired :: Proxy '[y, y1] current :: HLength y ~ 'HSucc ('HSucc 'HZero) => Proxy y Regards, Adam On Mon, Feb 9, 2015 at 10:58 AM, Jan Stolarek wrote: > Haskellers, > > I am finishing work on adding injective type families to GHC. I know that in the past many people > have asked for this feature. If you have use cases for injective type families I would appreciate > if you could show them to me. My implementation has some restrictions and I want to see how > severe these restrictions are from a practical point of view. > > Janek > > --- > Politechnika ??dzka > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From magicloud.magiclouds at gmail.com Tue Feb 10 06:59:48 2015 From: magicloud.magiclouds at gmail.com (Magicloud Magiclouds) Date: Tue, 10 Feb 2015 14:59:48 +0800 Subject: [Haskell-cafe] How does RTS judge that a STM transaction is blocked? In-Reply-To: References: Message-ID: Just found out that, the two functions of waitForEvent and waitForError cannot be run in "main" thread. I just forked them and used a getChar to block the program, and everything just went smooth. No idea what to proceed.... On Wed, Feb 4, 2015 at 8:59 PM, Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Hi, > > I met an issue while I was using xhb. When a certain property of root > window being changed, it was supposed to give me an AccessError. But > actually I got "thread blocked indefinitely in an STM transaction" when I > waitForEvent. > > AFAIK, in xhb, it forks a thread to read what X server sends. Then parse > and put it into a TChan. waitForEvent reads from the TChan. > > It is reasonable to me that if X server did not send anything, then > waitForEvent would be blocked. But apparently there are some other policies > in RTS. > > So what is that? And how should I debug it? > > -- > ??????? > ??????? > > And for G+, please use magiclouds#gmail.com. > -- ??????? ??????? And for G+, please use magiclouds#gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.stolarek at p.lodz.pl Tue Feb 10 11:38:10 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Tue, 10 Feb 2015 12:38:10 +0100 Subject: [Haskell-cafe] Injective type families for GHC In-Reply-To: References: <201502091658.04383.jan.stolarek@p.lodz.pl> Message-ID: <201502101238.10719.jan.stolarek@p.lodz.pl> Thank you Adam. > One example is https://github.com/haskell/vector/issues/34 Yes, this looks like an example where injectivity will work. One question here: how does one build vector with GHC HEAD? I tried but failed because of dependencies. > I see lots of potential uses in HList. For example in HZip.hs there's > a Zip using type families: > > type family HZipR (x::[*]) (y::[*]) :: [*] > type instance HZipR '[] '[] = '[] > type instance HZipR (x ': xs) (y ': ys) = (x,y) ': HZipR xs ys Bad news: my current implementation won't allow to declare HZipR as injective. That's because my implementation is conservative and does not permit calling type families by injective type family. > I don't know how realistic this is but a constraint (HLength x ~ > HLength y) would ideally have the same result as SameLength x y. I'm not sure if I understand that part. HLength is not injective. How would injectivity help here? Janek --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From nikita at karetnikov.org Tue Feb 10 14:29:55 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Tue, 10 Feb 2015 17:29:55 +0300 Subject: [Haskell-cafe] Using Haskell types in a database Message-ID: <87lhk54z6k.fsf@karetnikov.org> Suppose I need to represent a user in a database. I could make a table like this one (using Yesod's config/models syntax): User name Text email Text Maybe is_verified Bool default=false last_login UTCTime default=now() Instead, it would be better to do the following, so I couldn't swap name and email by accident or feed a wrong value to is_verified and last_login: User name UserName email UserEmail v Maybe last_login UserLastLogin where newtype UserName = UserName Text deriving (Show, Read) derivePersistField "UserName" newtype UserLastLogin = UserLastLogin UTCTime deriving (Show, Read) derivePersistField "UserLastLogin" data Verified data Unverified newtype UserEmail v = UserEmail Text deriving (Show, Read) derivePersistField "UserEmail" (So I could define functions like sendAnnouncement :: UserEmail Verified -> IO () sendVerification :: UserEmail Unverified -> IO ()) The Haskell part is not new and has been successfully used in the large (see http://code.haskell.org/~dons/talks/dons-google-2015-01-27.pdf, pp. 17--21), but I wonder whether it's reasonable in the database layer. The first table will be mapped to this in PostgreSQL: User name character varying not null email character varying is_verified boolean not null default false last_login timestamp with time zone not null default now() while the second will use character varying for everything. The only downsides of the latter approach I can think of: 1. You can no longer rely on the database to ensure (basic) type safety, so everything needs to be done in the Haskell layer. Otherwise, you will get runtime errors. 2. I haven't benchmarked this, but I assume that comparing, say, booleans should be faster than comparing varchars. So, is it worth it in practice? Do I need to worry about these issues? And are there any other problems? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Feb 10 15:32:21 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 10 Feb 2015 15:32:21 +0000 Subject: [Haskell-cafe] Using Haskell types in a database In-Reply-To: <87lhk54z6k.fsf@karetnikov.org> References: <87lhk54z6k.fsf@karetnikov.org> Message-ID: <20150210153221.GJ6273@weber> On Tue, Feb 10, 2015 at 05:29:55PM +0300, Nikita Karetnikov wrote: > User > name UserName > email UserEmail v Maybe > last_login UserLastLogin > > where > > data Verified > data Unverified > newtype UserEmail v = UserEmail Text deriving (Show, Read) > derivePersistField "UserEmail" I think you want the verification status to exist at the value level as well as the type level. What you currently have is essentially the same as defining your table to be [(UserName, Maybe (UserEmail v), UserLastLogin)] where I guess you're assuming the `v` will be existentially quantified. Presumably this isn't actually what you want. You could however have (the database version of) [(UserName, Maybe UserEmail, UserLastLogin)] and something like (the database version of) UserEmail -> Maybe UserEmailVerified UserEmail -> Maybe UserEmailUnverified which would give you the type safety you're looking for, I think. Opaleye supports user-created types for this kind of purpose, and I've found it invaluable. Tom From simonpj at microsoft.com Tue Feb 10 15:50:02 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Feb 2015 15:50:02 +0000 Subject: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C4A1C@DB3PRD3001MB020.064d.mgd.msft.net> Haskell Friends This email asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10. Please read on, but all the info is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX. Deadline is 21 Feb. The ?Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on. For over a year the CLC has been working on integrating the Foldable and Traversable classes (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration. Then we had a failure of communication. As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process. However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail). This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. We need to decide what to do now. A small group of us met by Skype and we've decided to do this: ? Push back GHC 7.10's release by at least a month, to late March. This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858. ? Invite input from the Haskell community on which of two approaches to adopt (this survey). The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it. ? Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10. Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details: ? Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710 ? Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List ? Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP This survey invites your input on which plan we should follow. Would you please ? Read the details of the alternative plans on the three wiki pages above ? Add your response to the survey Please do read the background. Well-informed responses will help. Thank you! DEADLINE: 21 February 2015 Simon PJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Tue Feb 10 15:59:18 2015 From: miguelimo38 at yandex.ru (Miguel Mitrofanov) Date: Tue, 10 Feb 2015 18:59:18 +0300 Subject: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C4A1C@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF562C4A1C@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <4445561423583958@web8j.yandex.ru> What were the objections? Especially the principle ones? 10.02.2015, 18:51, "Simon Peyton Jones" : > Haskell Friends > > This email asks for your help in deciding how to proceed with some Prelude changes in GHC 7.10.? Please read on, but all the info is also at the survey link, here: http://goo.gl/forms/XP1W2JdfpX.?? Deadline is 21 Feb. > > The ?Core Libraries Committee (CLC) is responsible for developing the core libraries that ship with GHC. This is an important but painstaking task, and we owe the CLC a big vote of thanks for taking it on. > > For over a year the CLC has been working on integrating the Foldable and Traversable classes (shipped in base in GHC 7.8) into the core libraries, and into the Prelude in particular. Detailed planning for GHC 7.10 started in the autumn of 2014, and the CLC went ahead with this integration. > > Then we had a failure of communication.? As these changes affect the Prelude, which is in scope for all users of Haskell, these changes should be held to a higher bar than the regular libraries@ review process.? However, the Foldable/Traversable changes were not particularly well signposted. Many people have only recently woken up to them, and some have objected (both in principle and detail). > > This is an extremely unfortunate situation. On the one hand we are at RC2 for GHC 7.10, so library authors have invested effort in updating their libraries to the new Prelude. On the other, altering the Prelude is in effect altering the language, something we take pretty seriously. We should have had this debate back in 2014, but here we are, and it is unproductive to argue about whose fault it is. We all share responsibility. > > We need to decide what to do now. A small group of us met by Skype and we've decided to do this: > > ????????? Push back GHC 7.10's release by at least a month, to late March.? This delay also gives us breathing space to address an unrelated show-stopping bug, Trac #9858. > > ????????? Invite input from the Haskell community on which of two approaches to adopt (this survey).? The main questions revolve around impact on the Haskell ecosystem (commercial applications, teaching, libraries, etc etc), so we want to ask your opinion rather than guess it. > > ????????? Ask Simon Marlow and Simon Peyton Jones to decide which approach to follow for GHC 7.10. > > Wiki pages have been created summarizing these two primary alternatives, including many more points and counter-points and technical details: > > ????????? Overall summary: https://ghc.haskell.org/trac/ghc/wiki/Prelude710 > > ????????? Details of Plan List: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List > > ????????? Details of Plan FTP: https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP > > This survey invites your input on which plan we should follow. Would you please > > ????????? Read the details of the alternative plans on the three wiki pages above > > ????????? Add your response to the survey > > Please do read the background.? Well-informed responses will help.? Thank you! > > DEADLINE: 21 February 2015 > > Simon PJ > > , > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From simonpj at microsoft.com Tue Feb 10 16:05:21 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Feb 2015 16:05:21 +0000 Subject: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion In-Reply-To: <4445561423583958@web8j.yandex.ru> References: <618BE556AADD624C9C918AA5D5911BEF562C4A1C@DB3PRD3001MB020.064d.mgd.msft.net> <4445561423583958@web8j.yandex.ru> Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C4AE6@DB3PRD3001MB020.064d.mgd.msft.net> | What were the objections? Especially the principle ones? Please read the info pages, which set out the arguments quite carefully. Also, I spammed several email lists to ensure broad coverage, but it'd be best to debate on the libraries at haskell.org, rather than reply-to-all; that's what it's for. (Which I failed to send the announcement to! I'll fix that.) Simon | -----Original Message----- | From: Miguel Mitrofanov [mailto:miguelimo38 at yandex.ru] | Sent: 10 February 2015 15:59 | To: Simon Peyton Jones; haskell at haskell.org; Haskell Cafe (haskell- | cafe at haskell.org); GHC users; ghc-devs at haskell.org | Subject: Re: [Haskell-cafe] GHC 7.10 Prelude: we need your opinion | | What were the objections? Especially the principle ones? | | 10.02.2015, 18:51, "Simon Peyton Jones" : | > Haskell Friends | > | > This email asks for your help in deciding how to proceed with some | Prelude changes in GHC 7.10.? Please read on, but all the info is also | at the survey link, here: http://goo.gl/forms/XP1W2JdfpX.?? Deadline | is 21 Feb. | > | > The ?Core Libraries Committee (CLC) is responsible for developing the | core libraries that ship with GHC. This is an important but | painstaking task, and we owe the CLC a big vote of thanks for taking | it on. | > | > For over a year the CLC has been working on integrating the Foldable | and Traversable classes (shipped in base in GHC 7.8) into the core | libraries, and into the Prelude in particular. Detailed planning for | GHC 7.10 started in the autumn of 2014, and the CLC went ahead with | this integration. | > | > Then we had a failure of communication.? As these changes affect the | Prelude, which is in scope for all users of Haskell, these changes | should be held to a higher bar than the regular libraries@ review | process.? However, the Foldable/Traversable changes were not | particularly well signposted. Many people have only recently woken up | to them, and some have objected (both in principle and detail). | > | > This is an extremely unfortunate situation. On the one hand we are | at RC2 for GHC 7.10, so library authors have invested effort in | updating their libraries to the new Prelude. On the other, altering | the Prelude is in effect altering the language, something we take | pretty seriously. We should have had this debate back in 2014, but | here we are, and it is unproductive to argue about whose fault it is. | We all share responsibility. | > | > We need to decide what to do now. A small group of us met by Skype | and we've decided to do this: | > | > ????????? Push back GHC 7.10's release by at least a month, to late | March.? This delay also gives us breathing space to address an | unrelated show-stopping bug, Trac #9858. | > | > ????????? Invite input from the Haskell community on which of two | approaches to adopt (this survey).? The main questions revolve around | impact on the Haskell ecosystem (commercial applications, teaching, | libraries, etc etc), so we want to ask your opinion rather than guess | it. | > | > ????????? Ask Simon Marlow and Simon Peyton Jones to decide which | approach to follow for GHC 7.10. | > | > Wiki pages have been created summarizing these two primary | alternatives, including many more points and counter-points and | technical details: | > | > ????????? Overall summary: | https://ghc.haskell.org/trac/ghc/wiki/Prelude710 | > | > ????????? Details of Plan List: | https://ghc.haskell.org/trac/ghc/wiki/Prelude710/List | > | > ????????? Details of Plan FTP: | https://ghc.haskell.org/trac/ghc/wiki/Prelude710/FTP | > | > This survey invites your input on which plan we should follow. Would | you please | > | > ????????? Read the details of the alternative plans on the three | wiki pages above | > | > ????????? Add your response to the survey | > | > Please do read the background.? Well-informed responses will | help.? Thank you! | > | > DEADLINE: 21 February 2015 | > | > Simon PJ | > | > , | > | > _______________________________________________ | > Haskell-Cafe mailing list | > Haskell-Cafe at haskell.org | > http://www.haskell.org/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Feb 10 16:32:27 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 10 Feb 2015 16:32:27 +0000 Subject: [Haskell-cafe] Use of STM in business? In-Reply-To: <20150209111937.GF10648@weber> References: <20150209111937.GF10648@weber> Message-ID: <20150210163227.GN6273@weber> On Mon, Feb 09, 2015 at 11:19:37AM +0000, Tom Ellis wrote: > From associate of mine: "I am quite curious if anyone actually uses Haskell > (esp STM) successfully in business." > > Can anyone provide me with any references to where STM has been used in > production [...] Thanks to everyone who helped with my query. From nikita at karetnikov.org Tue Feb 10 16:33:12 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Tue, 10 Feb 2015 19:33:12 +0300 Subject: [Haskell-cafe] Using Haskell types in a database In-Reply-To: <20150210153221.GJ6273@weber> (Tom Ellis's message of "Tue, 10 Feb 2015 15:32:21 +0000") References: <87lhk54z6k.fsf@karetnikov.org> <20150210153221.GJ6273@weber> Message-ID: <87oap17mlz.fsf@karetnikov.org> But does it (that is, having varchars everywhere) significantly affect performance in practice? If it depends, then when is it a reasonable price to pay? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Feb 10 16:35:50 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 10 Feb 2015 16:35:50 +0000 Subject: [Haskell-cafe] Using Haskell types in a database In-Reply-To: <87oap17mlz.fsf@karetnikov.org> References: <87lhk54z6k.fsf@karetnikov.org> <20150210153221.GJ6273@weber> <87oap17mlz.fsf@karetnikov.org> Message-ID: <20150210163550.GO6273@weber> On Tue, Feb 10, 2015 at 07:33:12PM +0300, Nikita Karetnikov wrote: > But does it (that is, having varchars everywhere) significantly affect > performance in practice? If it depends, then when is it a reasonable > price to pay? That part I don't understand. Why does your proposal require varchars everywhere? From nikita at karetnikov.org Tue Feb 10 18:02:58 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Tue, 10 Feb 2015 21:02:58 +0300 Subject: [Haskell-cafe] Using Haskell types in a database In-Reply-To: <20150210163550.GO6273@weber> (Tom Ellis's message of "Tue, 10 Feb 2015 16:35:50 +0000") References: <87lhk54z6k.fsf@karetnikov.org> <20150210153221.GJ6273@weber> <87oap17mlz.fsf@karetnikov.org> <20150210163550.GO6273@weber> Message-ID: <87k2zp7igd.fsf@karetnikov.org> > That part I don't understand. Why does your proposal require varchars > everywhere? That's what Persistent generates (using derivePersistField) for the second table. For example, the Haskell value MyText "foo" where MyText is newtype MyText = MyText Text deriving (Show, Read) derivePersistField "MyText" will be stored in PostgreSQL as a varchar 'MyText "foo"' I assume that Persistent (or its PostgreSQL backend) has a predefined mapping from a commonly used Haskell types to the database types. And everything else is represented as a varchar. So there are two choices, corresponding to the two tables shown in the original message: 1. Design tables with the (basic) database types in mind (integer, boolean, timestamp, varchar, etc.) then wrap and unwrap values each time you interact with the database. 2. Use Haskell types like MyText or something more complex directly and end up with varchar everywhere. I wonder how bad is the second option in practice because wrapping/unwrapping is error-prone. Of course, the varchar thing makes the alarm bells ring in my head, but when does it significantly affect performance? For example, maybe it's okay for a small shop, or is it a no go for everyone? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From bob at redivi.com Tue Feb 10 18:11:08 2015 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 Feb 2015 10:11:08 -0800 Subject: [Haskell-cafe] Using Haskell types in a database In-Reply-To: <87k2zp7igd.fsf@karetnikov.org> References: <87lhk54z6k.fsf@karetnikov.org> <20150210153221.GJ6273@weber> <87oap17mlz.fsf@karetnikov.org> <20150210163550.GO6273@weber> <87k2zp7igd.fsf@karetnikov.org> Message-ID: If you're using Postgres you can use types in the database http://www.postgresql.org/docs/9.2/static/sql-createtype.html I don't know what these look like from the Haskell drivers but you can have typed SQL if you want it. On Tuesday, February 10, 2015, Nikita Karetnikov wrote: > > That part I don't understand. Why does your proposal require varchars > > everywhere? > > That's what Persistent generates (using derivePersistField) for the > second table. For example, the Haskell value > > MyText "foo" > > where MyText is > > newtype MyText = MyText Text deriving (Show, Read) > derivePersistField "MyText" > > will be stored in PostgreSQL as a varchar > > 'MyText "foo"' > > I assume that Persistent (or its PostgreSQL backend) has a predefined > mapping from a commonly used Haskell types to the database types. > And everything else is represented as a varchar. > > So there are two choices, corresponding to the two tables shown in the > original message: > > 1. Design tables with the (basic) database types in mind (integer, > boolean, timestamp, varchar, etc.) then wrap and unwrap values each > time you interact with the database. > > 2. Use Haskell types like MyText or something more complex directly > and end up with varchar everywhere. > > I wonder how bad is the second option in practice because > wrapping/unwrapping is error-prone. Of course, the varchar thing makes > the alarm bells ring in my head, but when does it significantly affect > performance? For example, maybe it's okay for a small shop, or is it a > no go for everyone? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Tue Feb 10 18:53:36 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 10 Feb 2015 19:53:36 +0100 Subject: [Haskell-cafe] Using Haskell types in a database In-Reply-To: References: <87lhk54z6k.fsf@karetnikov.org> <20150210153221.GJ6273@weber> <87oap17mlz.fsf@karetnikov.org> <20150210163550.GO6273@weber> <87k2zp7igd.fsf@karetnikov.org> Message-ID: You shouldn't be using derivePersistField here if you want another db type. As you say there is a predefined mapping but you can override this by defining custom instances for your newtype. On Tue, Feb 10, 2015 at 7:11 PM, Bob Ippolito wrote: > If you're using Postgres you can use types in the database > http://www.postgresql.org/docs/9.2/static/sql-createtype.html > > I don't know what these look like from the Haskell drivers but you can > have typed SQL if you want it. > > > On Tuesday, February 10, 2015, Nikita Karetnikov > wrote: > >> > That part I don't understand. Why does your proposal require varchars >> > everywhere? >> >> That's what Persistent generates (using derivePersistField) for the >> second table. For example, the Haskell value >> >> MyText "foo" >> >> where MyText is >> >> newtype MyText = MyText Text deriving (Show, Read) >> derivePersistField "MyText" >> >> will be stored in PostgreSQL as a varchar >> >> 'MyText "foo"' >> >> I assume that Persistent (or its PostgreSQL backend) has a predefined >> mapping from a commonly used Haskell types to the database types. >> And everything else is represented as a varchar. >> >> So there are two choices, corresponding to the two tables shown in the >> original message: >> >> 1. Design tables with the (basic) database types in mind (integer, >> boolean, timestamp, varchar, etc.) then wrap and unwrap values each >> time you interact with the database. >> >> 2. Use Haskell types like MyText or something more complex directly >> and end up with varchar everywhere. >> >> I wonder how bad is the second option in practice because >> wrapping/unwrapping is error-prone. Of course, the varchar thing makes >> the alarm bells ring in my head, but when does it significantly affect >> performance? For example, maybe it's okay for a small shop, or is it a >> no go for everyone? >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Tue Feb 10 22:13:57 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 10 Feb 2015 17:13:57 -0500 Subject: [Haskell-cafe] Injective type families for GHC In-Reply-To: <201502101238.10719.jan.stolarek@p.lodz.pl> References: <201502091658.04383.jan.stolarek@p.lodz.pl> <201502101238.10719.jan.stolarek@p.lodz.pl> Message-ID: On Tue, Feb 10, 2015 at 6:38 AM, Jan Stolarek wrote: >> I don't know how realistic this is but a constraint (HLength x ~ >> HLength y) would ideally have the same result as SameLength x y. > I'm not sure if I understand that part. HLength is not injective. How would injectivity help here? I agree it's not injective. But my impression is that injective TFs pretty much allow ghc to replace a constraint TF a b ~ result with (TF_getResult a b ~ result, TF_getB result a ~ b) Where instances of: type family TF a b | result a -> b, a b -> result -- or whatever the notation actually is define instances of ordinary type families TF_getB and TF_getResult. So it's a move in the same direction to replace (HLength x ~ HLength y) with SameLength x y. While I don't know how the code for SameLength might be derived from the definition of HLength, that substitution seems safe so long as (HLength x ~ HLength y) is still checked. I can see that substitution happening in a type checker plugin, but it would be nice if it was part of the language. Regards, Adam From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Feb 11 00:00:12 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 11 Feb 2015 00:00:12 +0000 Subject: [Haskell-cafe] Using Haskell types in a database In-Reply-To: <87k2zp7igd.fsf@karetnikov.org> References: <87lhk54z6k.fsf@karetnikov.org> <20150210153221.GJ6273@weber> <87oap17mlz.fsf@karetnikov.org> <20150210163550.GO6273@weber> <87k2zp7igd.fsf@karetnikov.org> Message-ID: <20150211000010.GP6273@weber> On Tue, Feb 10, 2015 at 09:02:58PM +0300, Nikita Karetnikov wrote: > > That part I don't understand. Why does your proposal require varchars > > everywhere? > > I assume that Persistent (or its PostgreSQL backend) has a predefined > mapping from a commonly used Haskell types to the database types. > And everything else is represented as a varchar. OK, well that's surprising. Opaleye by contrast does not force everything into a varchar. Tom From ok at cs.otago.ac.nz Wed Feb 11 01:11:27 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 11 Feb 2015 14:11:27 +1300 Subject: [Haskell-cafe] stuck at the first part of chapter 1 of the CIS course In-Reply-To: <54D351C1.1040508@home.nl> References: <54D32050.9070901@home.nl> <54D351C1.1040508@home.nl> Message-ID: <257DEB24-EF28-4136-8E9F-95A7AC62B065@cs.otago.ac.nz> On 6/02/2015, at 12:19 am, Roelof Wobben wrote: > it's now looking like this : > > -- | convert a number to a array in pieces where a negative number will be a empty array. > toDigits :: Integer -> [Integer] > toDigits n > | n < 0 = [] > | otherwise = n/10 : [] I've seen you thinking the same way in the Erlang mailing list. Since this can only return a list of one element, it *must* be wrong. Also, n / 10 cannot be an integer, but the result is supposed to be a list of integers. You need `div` and `mod`, not / . You need to think recursively. Q How can toDigits n ==> [] arise? A When n is less than or equal to zero. Q How can toDigits n ==> [d1,d2,...,dm] arise? A When n is greater than zero, dm is n `mod` 10, and [d1,d2,...] without dm at the end is toDigits (n `div` 10). toDigits n | n <= 0 = [] toDigits n | n > 0 = toDigits (n `div` 10) ++ [n `mod` 10] There is another solution that builds up the answer from right to left using a helper function. In this case, I based an induction on the output I wanted to generate. Another way to think about it is to *pretend* that the integers are defined by a data type like --data Integer -- = Positive Integer Digit {- div 10, mod 10 -} -- | NonPositive (note the comment signs; this is NOT how integers are defined, but by using x > 0 -vs- x <= 0 we can tell which case applies and by using x `div` 10 and x `mod` 10 we can extract the "components" of an integer. We are PRETENDING that integers are a back-to-front list.) This (pretended) data type is just like a list except that it branches left 1234 = Positive (Positive (Positive (Positive NonPositive 1) 2) 3) 4) instead of right. Given this view of integers, we can process them using code that is structurally very much like the recursive code we would use to process lists. Just as we would write f (Positive higher least) = g (f higher) least f (NonPositive) = e so we can write f n | n > 0 = g (f (n `div` 10)) (n `mod` 10) f n | n <= 0 = e GIVEN a schema like that, you just have to ask yourself "what should e be? what should g be?" > -- | Main entry point to the application. > module Main where > > -- | The main entry point. > main :: IO () > main = do > toDigits 123 This makes has to be wrong because toDigits returns a list of integers, but a list of integers is not an IO action, which is what main needs. To put it another way, there is nothing in the expression (toDigits 123) that causes any output to occur. You probably want something like main = print (toDigits 1234) From ok at cs.otago.ac.nz Wed Feb 11 01:24:16 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 11 Feb 2015 14:24:16 +1300 Subject: [Haskell-cafe] SmallCheck Depth In-Reply-To: <54D3B692.7070806@ro-che.info> References: <54D34EC0.2070903@ro-che.info> <54D3B692.7070806@ro-che.info> Message-ID: <213E6D26-27EF-4145-A731-3DC6139DC1CC@cs.otago.ac.nz> On 6/02/2015, at 7:29 am, Roman Cheplyaka wrote: >> "Test.SmallCheck.Series" still states >> that "For data values, [depth] is the depth of nested constructor >> applications." > > True is a single constructor, so its depth is 1. > Just True is a constructor application of depth 2. Arguably, while True *is* a constructor, it is not a *nested* constructor. To me it obviously isn't, while to you it obviously is. This kind of problem with natural language is why we need more formal specifications. In the same way, to me (Just True) *obviously* has depth (actually height) 1. It is the tree +--------+ | Just | +--------+ | v +--------+ | True | +--------+ in which the longest path from the root to a leaf contains 1 edge. Where is the second edge? For example, http://www.cs.cmu.edu/~adamchik/15-121/lectures/Trees/trees.html says - The depth of a node is the number of edges from the root to the node. - The height of a node is the number of edges from the node to the deepest leaf. - The height of a tree is [the] height of the root. These are essentially the same definitions found in http://en.wikipedia.org/wiki/Tree_(data_structure) So we don't just have a potential ambiguity (what is "nested"?) but an actual clash with standard terminology; you are defining depth tree = height tree + 1 From ky3 at atamo.com Wed Feb 11 03:53:57 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 11 Feb 2015 10:53:57 +0700 Subject: [Haskell-cafe] SmallCheck Depth In-Reply-To: <213E6D26-27EF-4145-A731-3DC6139DC1CC@cs.otago.ac.nz> References: <54D34EC0.2070903@ro-che.info> <54D3B692.7070806@ro-che.info> <213E6D26-27EF-4145-A731-3DC6139DC1CC@cs.otago.ac.nz> Message-ID: On Wed, Feb 11, 2015 at 8:24 AM, Richard A. O'Keefe wrote: > So we don't just have a potential ambiguity (what is "nested"?) but an > actual > clash with standard terminology; you are defining > > depth tree = height tree + 1 > I think Roman defines "depth" that way because it counts the total number of constructors (i.e. tree nodes) in the path. The advantage is that it corresponds to the number of words in the syntax: Just (Just True) would have a "depth" of 3, etc. And you're right that it does clash with standard terminology. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhub.bits at gmail.com Wed Feb 11 03:57:53 2015 From: madhub.bits at gmail.com (madhub) Date: Tue, 10 Feb 2015 22:57:53 -0500 Subject: [Haskell-cafe] svgcairo/ghc vis cabal install error.. Message-ID: Hi !, I tried installing svgcairo ( for installing ghc vis ). I am getting following error. Could you please help me out install ghc vis. Thanks in advance Madhu ? environment details. I am on mac yosomite with gcc provided by OS X. Following is the gcc ?version 22:54:34:~$ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/pkgconfig export LDFLAGS=-L/usr/local/lib export CFLAGS=-I/usr/local/include export LIBS=-L/usr/local/lib svgcairo error =============== Configuring svgcairo-0.13.0.1... Building svgcairo-0.13.0.1... Preprocessing library svgcairo-0.13.0.1... gtk2hsC2hs: Error in C header file. /usr/include/sys/qos.h:124: (column 34) [FATAL] >>> Syntax error! The symbol `__attribute__' does not fit here. cabal: Error: some packages failed to install: svgcairo-0.13.0.1 failed during the building phase. The exception was: ExitFailure 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Wed Feb 11 04:28:37 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 11 Feb 2015 17:28:37 +1300 Subject: [Haskell-cafe] SmallCheck Depth In-Reply-To: References: <54D34EC0.2070903@ro-che.info> <54D3B692.7070806@ro-che.info> <213E6D26-27EF-4145-A731-3DC6139DC1CC@cs.otago.ac.nz> Message-ID: <987212E4-AD88-4A5F-B336-DE0F9C0814A4@cs.otago.ac.nz> On 11/02/2015, at 4:53 pm, Kim-Ee Yeoh wrote: > I think Roman defines "depth" that way because it counts the total number of constructors (i.e. tree nodes) in the path. That is a perfectly reasonable thing to count, but "depth" is not a good name for it. From lemming at henning-thielemann.de Wed Feb 11 08:25:35 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 11 Feb 2015 09:25:35 +0100 (CET) Subject: [Haskell-cafe] [Haskell] Rank-N types with (.) composition In-Reply-To: <1557238.IhA1og8xmu@whitehead.beowulf.uwo.ca> References: <1557238.IhA1og8xmu@whitehead.beowulf.uwo.ca> Message-ID: On Tue, 10 Feb 2015, Tyson Whitehead wrote: > I came across something that seems a bit strange to me. Here is a > simplified version (the original was trying to move from a lens > ReifiedFold to a lens-action ReifiedMonadicFold) You are on Haskell at haskell.org here. Could you please move to haskell-cafe? From lemming at henning-thielemann.de Wed Feb 11 09:53:08 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 11 Feb 2015 10:53:08 +0100 (CET) Subject: [Haskell-cafe] [Haskell] Rank-N types with (.) composition In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C5871@DB3PRD3001MB020.064d.mgd.msft.net> References: <1557238.IhA1og8xmu@whitehead.beowulf.uwo.ca> <1637612.9k5Y53Y3NQ@whitehead.beowulf.uwo.ca> <618BE556AADD624C9C918AA5D5911BEF562C5871@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Wed, 11 Feb 2015, Simon Peyton Jones wrote: > ($) has its own *typing rule*; it does not have a special type. It's > very ad hoc, but ($) is used so much to decrease parens that (e1 $ e2) > is almost special syntax! I already wondered why runST $ do foo bar worked in some versions of GHC and not in others. I guess it is better to tell the programmer the truth, i.e. remove the special treatment of ($). If you save a programmer from wondering about why "runST $ do ... " does not work with the special typing rule for ($), the programmer will later wonder why (.) does not work or why his privately defined function application operator (e.g. for reversed order of argument and function) will not work. I think that I stay with "runST (do ...)" in order to be compatible with several GHC versions. From ky3 at atamo.com Wed Feb 11 10:15:56 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 11 Feb 2015 17:15:56 +0700 Subject: [Haskell-cafe] SmallCheck Depth In-Reply-To: <987212E4-AD88-4A5F-B336-DE0F9C0814A4@cs.otago.ac.nz> References: <54D34EC0.2070903@ro-che.info> <54D3B692.7070806@ro-che.info> <213E6D26-27EF-4145-A731-3DC6139DC1CC@cs.otago.ac.nz> <987212E4-AD88-4A5F-B336-DE0F9C0814A4@cs.otago.ac.nz> Message-ID: On Wed, Feb 11, 2015 at 11:28 AM, Richard A. O'Keefe wrote: > > On 11/02/2015, at 4:53 pm, Kim-Ee Yeoh wrote: > > I think Roman defines "depth" that way because it counts the total > number of constructors (i.e. tree nodes) in the path. > > That is a perfectly reasonable thing to count, but "depth" is not a good > name for it. Agreed. How about "weight"? As Pacman eats pellets traversing the tree he gains weight. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From f at mazzo.li Wed Feb 11 10:26:17 2015 From: f at mazzo.li (Francesco Mazzoli) Date: Wed, 11 Feb 2015 11:26:17 +0100 Subject: [Haskell-cafe] Anonymous FFI calls Message-ID: Hi, I am in a situation where it would be very useful to call C functions without an explicit FFI import. For example, I'd like to be able to do (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 instead of declaring the foreign import explicitely at the top level. Is there a way to do this or to achieve similar results in some other way? If not, I imagine it would be easy to implement such a facility in GHC, given that the code implementing calling to C functions must already be present to implement "proper" FFI imports. I think such an addition would be useful in many cases. Thanks, Francesco From simonpj at microsoft.com Wed Feb 11 10:40:19 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 11 Feb 2015 10:40:19 +0000 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> This may be relevant. http://www.cse.unsw.edu.au/~chak/papers/CMCK14.html Manuel gave a talk about something like this at the Haskell Symposium. Simon | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf | Of Francesco Mazzoli | Sent: 11 February 2015 10:26 | To: haskell; ghc-devs at haskell.org | Subject: [Haskell-cafe] Anonymous FFI calls | | Hi, | | I am in a situation where it would be very useful to call C functions | without an explicit FFI import. For example, I'd like to be able to | do | | (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 | | instead of declaring the foreign import explicitely at the top level. | | Is there a way to do this or to achieve similar results in some other | way? | | If not, I imagine it would be easy to implement such a facility in | GHC, given that the code implementing calling to C functions must | already be present to implement "proper" FFI imports. I think such an | addition would be useful in many cases. | | Thanks, | Francesco | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe at haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From k-bx at k-bx.com Wed Feb 11 11:07:40 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Wed, 11 Feb 2015 13:07:40 +0200 Subject: [Haskell-cafe] Regex-applicative and Data.Text Message-ID: I just tried some regex-applicative and it's amazing! Very nice library, thanks Roman! However, I can't figure out the best way to work with Data.Text.Text instead of String. The token would be Text, I guess, but then it breaks in composition, since type of `few anySym` would now return `[Text]`, not `Text`. Am I understanding this correctly that intention is to in issue #8? [0] Or is there a clever way to work with them today? Example code: {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import Data.Text (Text) import Text.Regex.Applicative main = do let input = "foo:\n--- blablabla\ttheend" let r1 = sym "foo:\n" *> sym "--- " *> few anySym <* sym "\t" <* few anySym :: RE Text Text putStrLn (show (input =~ r1)) Error is something like (this is an error for a bit different code, but should be very similar): Main.hs:14:40: Couldn't match type ?[Text]? with ?Text? Expected type: RE Text Text Actual type: RE Text [Text] In the second argument of ?(*>)?, namely ?few anySym? In the first argument of ?(<*)?, namely ?few anySym *> sym "Actual stderr output differs from expected:" *> sym "--- " *> few anySym? Thanks! [0]: https://github.com/feuerbach/regex-applicative/issues/8 -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Feb 11 12:12:43 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 11 Feb 2015 14:12:43 +0200 Subject: [Haskell-cafe] Regex-applicative and Data.Text In-Reply-To: References: Message-ID: <54DB473B.7050507@ro-che.info> No, the token will still be Char. You'll need to unpack Text into [Char] beforehand, and pack the result back if appropriate. On 11/02/15 13:07, Konstantine Rybnikov wrote: > I just tried some regex-applicative and it's amazing! Very nice library, > thanks Roman! > > However, I can't figure out the best way to work with Data.Text.Text > instead of String. The token would be Text, I guess, but then it breaks > in composition, since type of `few anySym` would now return `[Text]`, > not `Text`. > > Am I understanding this correctly that intention is to in issue #8? [0] > Or is there a clever way to work with them today? > > Example code: > > {-# LANGUAGE OverloadedStrings #-} > > import qualified Data.Text as T > import Data.Text (Text) > import Text.Regex.Applicative > > main = do > let input = "foo:\n--- blablabla\ttheend" > let r1 = sym "foo:\n" > *> sym "--- " *> few anySym <* sym "\t" <* few anySym > :: RE Text Text > > putStrLn (show (input =~ r1)) > > Error is something like (this is an error for a bit different code, but > should be very similar): > > Main.hs:14:40: > Couldn't match type ?[Text]? with ?Text? > Expected type: RE Text Text > Actual type: RE Text [Text] > In the second argument of ?(*>)?, namely ?few anySym? > In the first argument of ?(<*)?, namely > ?few anySym *> sym "Actual stderr output differs from expected:" > *> sym "--- " > *> few anySym? > > Thanks! > > [0]: https://github.com/feuerbach/regex-applicative/issues/8 > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From k-bx at k-bx.com Wed Feb 11 12:18:12 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Wed, 11 Feb 2015 14:18:12 +0200 Subject: [Haskell-cafe] Regex-applicative and Data.Text In-Reply-To: <54DB473B.7050507@ro-che.info> References: <54DB473B.7050507@ro-che.info> Message-ID: I see. That's what I did exactly, thanks for the help. On Wed, Feb 11, 2015 at 2:12 PM, Roman Cheplyaka wrote: > No, the token will still be Char. You'll need to unpack Text into [Char] > beforehand, and pack the result back if appropriate. > > On 11/02/15 13:07, Konstantine Rybnikov wrote: > > I just tried some regex-applicative and it's amazing! Very nice library, > > thanks Roman! > > > > However, I can't figure out the best way to work with Data.Text.Text > > instead of String. The token would be Text, I guess, but then it breaks > > in composition, since type of `few anySym` would now return `[Text]`, > > not `Text`. > > > > Am I understanding this correctly that intention is to in issue #8? [0] > > Or is there a clever way to work with them today? > > > > Example code: > > > > {-# LANGUAGE OverloadedStrings #-} > > > > import qualified Data.Text as T > > import Data.Text (Text) > > import Text.Regex.Applicative > > > > main = do > > let input = "foo:\n--- blablabla\ttheend" > > let r1 = sym "foo:\n" > > *> sym "--- " *> few anySym <* sym "\t" <* few > anySym > > :: RE Text Text > > > > putStrLn (show (input =~ r1)) > > > > Error is something like (this is an error for a bit different code, but > > should be very similar): > > > > Main.hs:14:40: > > Couldn't match type ?[Text]? with ?Text? > > Expected type: RE Text Text > > Actual type: RE Text [Text] > > In the second argument of ?(*>)?, namely ?few anySym? > > In the first argument of ?(<*)?, namely > > ?few anySym *> sym "Actual stderr output differs from expected:" > > *> sym "--- " > > *> few anySym? > > > > Thanks! > > > > [0]: https://github.com/feuerbach/regex-applicative/issues/8 > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From twhitehead at gmail.com Wed Feb 11 15:06:35 2015 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed, 11 Feb 2015 10:06:35 -0500 Subject: [Haskell-cafe] [Haskell] Rank-N types with (.) composition In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C5871@DB3PRD3001MB020.064d.mgd.msft.net> References: <1557238.IhA1og8xmu@whitehead.beowulf.uwo.ca> <1637612.9k5Y53Y3NQ@whitehead.beowulf.uwo.ca> <618BE556AADD624C9C918AA5D5911BEF562C5871@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <54DB6FFB.4060907@gmail.com> On 11/02/15 04:39 AM, Simon Peyton Jones wrote: > ($) has its own *typing rule*; it does not have a special type. It's very ad hoc, but ($) is used so much to decrease parens that (e1 $ e2) is almost special syntax! I do like the idea of being able to end a function application with a lambda, let, if, case, or do without having to use $ though. Would something like the following grammar rules be problematic for parsing? infixexp? lexp qop infixexp | - infixexp | [fexp] lexp (*) | aexp (*) lexp ? \ apat1 ? apatn -> exp | let decls in exp | if exp [;] then exp [;] else exp | case exp of { alts } | do { stmts } (*) fexp ? [fexp] aexp aexp ? qvar | gcon | literal | ( exp ) | ( exp1 , ? , expk ) | [ exp1 , ? , expk ] | [ exp1 [, exp2] .. [exp3] ] | [ exp | qual1 , ? , qualn ] | ( infixexp qop ) | ( qop?-? infixexp ) | qcon { fbind1 , ? , fbindn } | aexp?qcon? { fbind1 , ? , fbindn } https://www.haskell.org/onlinereport/haskell2010/haskellch3.html were I've added (*) to where I have added or removed lines (basically I've moved function application from lexp to infixexp in order to allow the last exp in a function application to be an lexp). > At the moment the *only* robust way to pass a polymorphic function to a polymorphic function (here, you are passing Wrap to (.)) is to wrap it in a newtype, much as Wrap does. Good to know. Thanks! -Tyson From f at mazzo.li Wed Feb 11 15:18:43 2015 From: f at mazzo.li (Francesco Mazzoli) Date: Wed, 11 Feb 2015 16:18:43 +0100 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hi Simon, Thanks for the reply. The work on accelerated is indeed relevant: in accelerate-cuda, CUDA kernels (which are composed of C code) get compiled to a binary file invoking an external compiler, and then (this is the relevant part) the compiled binary is executed used the CUDA library. The problem is that while CUDA kernels are executable through a libraries, compiled functions using the C calling convention aren't. So I can't really call compiled C functions like accelerate-cuda invokes CUDA kernels. Relatedly, if I have some function pointer known at runtime that addresses a C function that takes some arguments, I have no way to invoke it from Haskell, since all FFI imports must be declared at compile-time, and I don't know the address of the symbol I want to execute at compile time. I am exploring the possibility of adding such capabilities to GHC, since as I mentioned I don't see any particular roadblock. Francesco On 11 February 2015 at 11:40, Simon Peyton Jones wrote: > This may be relevant. http://www.cse.unsw.edu.au/~chak/papers/CMCK14.html > Manuel gave a talk about something like this at the Haskell Symposium. > > Simon > > | -----Original Message----- > | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf > | Of Francesco Mazzoli > | Sent: 11 February 2015 10:26 > | To: haskell; ghc-devs at haskell.org > | Subject: [Haskell-cafe] Anonymous FFI calls > | > | Hi, > | > | I am in a situation where it would be very useful to call C functions > | without an explicit FFI import. For example, I'd like to be able to > | do > | > | (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 > | > | instead of declaring the foreign import explicitely at the top level. > | > | Is there a way to do this or to achieve similar results in some other > | way? > | > | If not, I imagine it would be easy to implement such a facility in > | GHC, given that the code implementing calling to C functions must > | already be present to implement "proper" FFI imports. I think such an > | addition would be useful in many cases. > | > | Thanks, > | Francesco > | _______________________________________________ > | Haskell-Cafe mailing list > | Haskell-Cafe at haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-cafe From mail at joachim-breitner.de Wed Feb 11 15:33:02 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 11 Feb 2015 16:33:02 +0100 Subject: [Haskell-cafe] svgcairo/ghc vis cabal install error.. In-Reply-To: References: Message-ID: <1423668782.1961.2.camel@joachim-breitner.de> Hi, Am Dienstag, den 10.02.2015, 22:57 -0500 schrieb madhub: > I tried installing svgcairo ( for installing ghc vis ). I am getting > following error. Could you please help me out install ghc vis. > just a guess, but you might have the wrong versoin of gtk2hs-buildtools installed. Make sure it matches the version of svgcairo that you are trying to install. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From allbery.b at gmail.com Wed Feb 11 16:57:13 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 11 Feb 2015 11:57:13 -0500 Subject: [Haskell-cafe] [Haskell-beginners] svgcairo/ghc vis cabal install error.. In-Reply-To: References: Message-ID: On Tue, Feb 10, 2015 at 10:57 PM, madhub wrote: > Preprocessing library svgcairo-0.13.0.1... > gtk2hsC2hs: Error in C header file. > > /usr/include/sys/qos.h:124: (column 34) [FATAL] > >>> Syntax error! > The symbol `__attribute__' does not fit here. > What version of gtk2hs-buildtools / gtk2hsc2hs? They had to be upgraded recently (past several months) to deal with changes in Apple header files related to Yosemite and to Apple's migration from gcc to clang. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsyl20 at gmail.com Wed Feb 11 17:26:10 2015 From: hsyl20 at gmail.com (Sylvain Henry) Date: Wed, 11 Feb 2015 18:26:10 +0100 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: 2015-02-11 16:18 GMT+01:00 Francesco Mazzoli : > > Relatedly, if I have some function pointer known at runtime that > addresses a C function that takes some arguments, I have no way to > invoke it from Haskell, since all FFI imports must be declared at > compile-time, and I don't know the address of the symbol I want to > execute at compile time. > You can use FunPtr and wrapper imports to convert a FunPtr into a Haskell function. https://hackage.haskell.org/package/base-4.7.0.2/docs/Foreign-Ptr.html#g:2 You may be interested in my dynamic-linker-template package [1] to avoid having to write boilerplate wrappers. For now it only works with dynamic linking from System.Posix.DynamicLinker, but it could be easily extended to support other platforms. It automatically generates wrappers for all the functions in a record as well as the code to load symbol addresses and to convert them into Haskell functions (examples [2,3]). Sylvain [1] https://hackage.haskell.org/package/dynamic-linker-template [2] https://github.com/hsyl20/dynamic-linker-template/blob/master/Tests/Test.hs [3] https://github.com/hsyl20/ViperVM/blob/master/src/lib/ViperVM/Arch/OpenCL/Library.hs -------------- next part -------------- An HTML attachment was scrubbed... URL: From donn at avvanta.com Wed Feb 11 17:41:39 2015 From: donn at avvanta.com (Donn Cave) Date: Wed, 11 Feb 2015 09:41:39 -0800 (PST) Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <20150211174139.CCA1E93C40@mail.avvanta.com> Quoth Sylvain Henry , > 2015-02-11 16:18 GMT+01:00 Francesco Mazzoli : > >> Relatedly, if I have some function pointer known at runtime that >> addresses a C function that takes some arguments, I have no way to >> invoke it from Haskell, since all FFI imports must be declared at >> compile-time, and I don't know the address of the symbol I want to >> execute at compile time. > > You can use FunPtr and wrapper imports to convert a FunPtr into a Haskell > function. For example, foreign import ccall "get_type1_fn" get_type1_fn :: IO (FunPtr (CInt -> IO CInt)) foreign import ccall "dynamic" type1FunPtrToFun :: FunPtr (CInt -> IO CInt) -> (CInt -> IO CInt) main = do fp <- get_type1_fn let f = type1FunPtrToFun fp f 5 >>= print I guess the key point in this demo is that a C function is able to return a FunPtr. Donn From clintonmead at gmail.com Wed Feb 11 19:00:59 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Thu, 12 Feb 2015 06:00:59 +1100 Subject: [Haskell-cafe] Rationale for two separate map functions in ClassyPrelude Message-ID: ClassyPrelude has two map functions, namely: 1. "map" 2. "omap" "map" works on any Functor. However, things like "Text" are not functors as they aren't generic containers. As can be seen in the following code: module Main where import Prelude () import ClassyPrelude import qualified Data.Text as T import Data.Char as C main = do let l = [1,2,3] :: [Int] let t = (T.pack "Hello") let m = Just 5 print $ map (*2) l print $ map (*2) m print $ omap C.toUpper t return () Notice one has to use "omap" to deal with the Text. The thing is, I found it trivially easy to get "map" to work for both calls. Here's the code: {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} module Main where import Prelude hiding (map) import qualified Data.Text as T import Data.Char as C import Control.Monad (Functor) class CanMap a b where type Element a :: * type Container a b :: * map :: (Element a -> b) -> a -> Container a b instance (Functor f) => CanMap (f a) b where type Element (f a) = a type Container (f a) b = f b map = fmap instance CanMap T.Text Char where type Element T.Text = Char type Container T.Text Char = T.Text map = T.map main = do let l = [1,2,3] :: [Int] let m = Just 5 let t = (T.pack "Hello") print $ map (*2) l print $ map (*2) m print $ map C.toUpper t return () All that's required is to add instances to CanMap for any monomorphic containers. ClassyPrelude already does this anyway with "omap" in the Data.MonoTraversable module. I suspect however there's a good reason I'm missing about why there should be two separate map functions to deal with these alternate situations, but I'm wondering what that is. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Wed Feb 11 19:32:03 2015 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 11 Feb 2015 14:32:03 -0500 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On Wed, Feb 11, 2015 at 12:26 PM, Sylvain Henry wrote: > 2015-02-11 16:18 GMT+01:00 Francesco Mazzoli : >> >> >> Relatedly, if I have some function pointer known at runtime that >> addresses a C function that takes some arguments, I have no way to >> invoke it from Haskell, since all FFI imports must be declared at >> compile-time, and I don't know the address of the symbol I want to >> execute at compile time. > > > You can use FunPtr and wrapper imports to convert a FunPtr into a Haskell > function. > https://hackage.haskell.org/package/base-4.7.0.2/docs/Foreign-Ptr.html#g:2 > > You may be interested in my dynamic-linker-template package [1] to avoid > having to write boilerplate wrappers. Code using http://hackage.haskell.org/package/libffi looks pretty similar, though the specification needs terms (such as argCInt) instead of a mandatory type signature. GHC itself includes libffi so maybe the foreign import "dynamic" calls end up doing exactly the same thing as the hackage libffi does. From f at mazzo.li Wed Feb 11 20:01:41 2015 From: f at mazzo.li (Francesco Mazzoli) Date: Wed, 11 Feb 2015 21:01:41 +0100 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On 11 February 2015 at 18:26, Sylvain Henry wrote: > You can use FunPtr and wrapper imports to convert a FunPtr into a Haskell > function. > https://hackage.haskell.org/package/base-4.7.0.2/docs/Foreign-Ptr.html#g:2 The problem with that scheme is that you have to define a FFI import per type. TH solutions are not viable (and cumbersome) for our use case -- the biggest problem being related to the TH staging restriction. > Code using http://hackage.haskell.org/package/libffi looks pretty > similar, though the specification needs terms (such as argCInt) > instead of a mandatory type signature. GHC itself includes libffi so > maybe the foreign import "dynamic" calls end up doing exactly the same > thing as the hackage libffi does. Thanks! That seems like a good workaround for the time being -- we had actually considered for a split second re-implementing the C calling convention, I should have suspected that such a library existed already. However, while that library works for pointers, it does not (and can't) have the facilities to refer to symbols. In any case, there still is the need for such a facility built-in GHC, since such solutions are always going to incur in some overhead, compared to calling C functions directly. For example in the linked bindings to `libffi' the arguments are passed as a list, which is certainly a big difference from storing them into registers. And again, it seems like 95% of the work is already done, since `foreign import's are already desugared to Haskell functions with a primitive call to the C function. Francesco From psyzy3 at nottingham.ac.uk Wed Feb 11 20:15:02 2015 From: psyzy3 at nottingham.ac.uk (Zongzhe Yuan) Date: Wed, 11 Feb 2015 20:15:02 +0000 Subject: [Haskell-cafe] Applying for Haskell opportunities at Facebook Message-ID: Hi I am a student in the University of Nottingham in year 2 and I am quite interested in Haskell. May I apply for the summer internship in this summer in London? I have learnt Haskell during the module Introduction to Functional Programming last Year and have the highest mark among the student from Ningbo campus. I could solve countdown problem and sudoku right now. I know Monad and know the basic idea about that. This semester I take the module Advanced Functional Programming taught by professor Graham Hutton. By the end of this semester, i will be good at monad using and learn more about the efficiency about the programming. Apart from Haskell, I also good at algorithm and Java programming. I deal the entire image processing procedure algorithm with a candy detect application. https://github.com/ZongzheYuan/ImageProcessing.git Here is my code and i am improving it continuously. I really looking forward to working at FaceBook and especially with Haskell. If i could have this opportunity, it will become my pleasure. Greeting Zongzhe Yuan 11/2/2015 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CV.pdf Type: application/pdf Size: 59773 bytes Desc: CV.pdf URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From psyzy3 at nottingham.ac.uk Wed Feb 11 20:15:02 2015 From: psyzy3 at nottingham.ac.uk (Zongzhe Yuan) Date: Wed, 11 Feb 2015 20:15:02 +0000 Subject: [Haskell-cafe] Applying for Haskell opportunities at Facebook Message-ID: <7B849B38-7771-4521-9C42-007402C02B94@exmail.nottingham.ac.uk> Hi I am a student in the University of Nottingham in year 2 and I am quite interested in Haskell. May I apply for the summer internship in this summer in London? I have learnt Haskell during the module Introduction to Functional Programming last Year and have the highest mark among the student from Ningbo campus. I could solve countdown problem and sudoku right now. I know Monad and know the basic idea about that. This semester I take the module Advanced Functional Programming taught by professor Graham Hutton. By the end of this semester, i will be good at monad using and learn more about the efficiency about the programming. Apart from Haskell, I also good at algorithm and Java programming. I deal the entire image processing procedure algorithm with a candy detect application. https://github.com/ZongzheYuan/ImageProcessing.git Here is my code and i am improving it continuously. I really looking forward to working at FaceBook and especially with Haskell. If i could have this opportunity, it will become my pleasure. Greeting Zongzhe Yuan 11/2/2015 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CV.pdf Type: application/pdf Size: 59773 bytes Desc: CV.pdf URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From psyzy3 at nottingham.ac.uk Wed Feb 11 20:24:15 2015 From: psyzy3 at nottingham.ac.uk (Zongzhe Yuan) Date: Wed, 11 Feb 2015 20:24:15 +0000 Subject: [Haskell-cafe] Applying for Haskell opportunities at Facebook Message-ID: <35DAD467-ABE2-4D29-AA85-195AE2C88332@exmail.nottingham.ac.uk> Hi I am a student in the University of Nottingham in year 2 and I am quite interested in Haskell. May I apply for the summer internship in this summer in London? I have learnt Haskell during the module Introduction to Functional Programming last Year and have the highest mark among the student from Ningbo campus. I could solve countdown problem and sudoku right now. I know Monad and know the basic idea about that. This semester I take the module Advanced Functional Programming taught by professor Graham Hutton. By the end of this semester, i will be good at monad using and learn more about the efficiency about the programming. Apart from Haskell, I also good at algorithm and Java programming. I deal the entire image processing procedure algorithm with a candy detect application. https://github.com/ZongzheYuan/ImageProcessing.git Here is my code and i am improving it continuously. I really looking forward to working at FaceBook and especially with Haskell. If i could have this opportunity, it will become my pleasure. Greeting Zongzhe Yuan 11/2/2015 This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CV.pdf Type: application/pdf Size: 59773 bytes Desc: CV.pdf URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrz.vtl at gmail.com Wed Feb 11 20:55:05 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Wed, 11 Feb 2015 15:55:05 -0500 Subject: [Haskell-cafe] GHC Hackaton (GHC internals) slides Message-ID: Anybody knows if the slides (or higher quality video) for the GHC Hackaton are available? I'm not sure which year, this video has been posted in 2012: https://www.youtube.com/watch?v=lw7kbUvAmK4&list=PLBkRCigjPwyeCSD_DFxpd246YIF7_RDDI Thanks! Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Wed Feb 11 23:18:31 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Wed, 11 Feb 2015 15:18:31 -0800 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: Message-ID: It seems like addTopDecls[1] will able to help here. Unfortunately, the function is not well documented and not very discoverable because it's only exported by Language.Haskell.TH. The documentation doesn't mention that it can only be used to create new top level functions and FFI imports[2]. I think that adding FFI imports was the main motivation for implementing it. In the past I've wanted to generate instances via this function, but unfortunately it's not implemented.. Hope that helps! -Michael [1] http://hackage.haskell.org/package/template-haskell-2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls [2] https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/compiler/typecheck/TcSplice.hs#L818 On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: > Hi, > > I am in a situation where it would be very useful to call C functions > without an explicit FFI import. For example, I'd like to be able to do > > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 > > instead of declaring the foreign import explicitely at the top level. > > Is there a way to do this or to achieve similar results in some other > way? > > If not, I imagine it would be easy to implement such a facility in GHC, > given that the code implementing calling to C functions must already be > present to implement "proper" FFI imports. I think such an addition > would be useful in many cases. > > Thanks, > Francesco > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From simonpj at microsoft.com Wed Feb 11 23:25:49 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 11 Feb 2015 23:25:49 +0000 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C740B@DB3PRD3001MB020.064d.mgd.msft.net> I would LOVE someone to improve the documentation for addTopDecls. Manuel Chakravarty and Geoff Mainland were responsible for the implementation. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michael | Sloan | Sent: 11 February 2015 23:19 | To: Francesco Mazzoli | Cc: ghc-devs at haskell.org; haskell | Subject: Re: [Haskell-cafe] Anonymous FFI calls | | It seems like addTopDecls[1] will able to help here. Unfortunately, | the function is not well documented and not very discoverable because | it's only exported by Language.Haskell.TH. | | The documentation doesn't mention that it can only be used to create | new top level functions and FFI imports[2]. I think that adding FFI | imports was the main motivation for implementing it. In the past | I've wanted to generate instances via this function, but unfortunately | it's not implemented.. | | Hope that helps! | -Michael | | [1] http://hackage.haskell.org/package/template-haskell- | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls | | [2] | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ | compiler/typecheck/TcSplice.hs#L818 | | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: | > Hi, | > | > I am in a situation where it would be very useful to call C functions | > without an explicit FFI import. For example, I'd like to be able to do | > | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 | > | > instead of declaring the foreign import explicitely at the top level. | > | > Is there a way to do this or to achieve similar results in some other | > way? | > | > If not, I imagine it would be easy to implement such a facility in GHC, | > given that the code implementing calling to C functions must already be | > present to implement "proper" FFI imports. I think such an addition | > would be useful in many cases. | > | > Thanks, | > Francesco | > _______________________________________________ | > Haskell-Cafe mailing list | > Haskell-Cafe at haskell.org | > http://www.haskell.org/mailman/listinfo/haskell-cafe | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs From mgsloan at gmail.com Wed Feb 11 23:32:35 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Wed, 11 Feb 2015 15:32:35 -0800 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C740B@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF562C740B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I'd love for the implementation to be as powerful as the documentation suggests it is :D However, yes, in the meantime, fixing the documentation would be great! Also, I meant to say that addTopDecls is only exported by "Language.Haskell.TH.Syntax". While this is a digression, there are a few other handy functions that are oddly left out of "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly more. -Michael On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones wrote: > I would LOVE someone to improve the documentation for addTopDecls. Manuel Chakravarty and Geoff Mainland were responsible for the implementation. > > Simon > > | -----Original Message----- > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michael > | Sloan > | Sent: 11 February 2015 23:19 > | To: Francesco Mazzoli > | Cc: ghc-devs at haskell.org; haskell > | Subject: Re: [Haskell-cafe] Anonymous FFI calls > | > | It seems like addTopDecls[1] will able to help here. Unfortunately, > | the function is not well documented and not very discoverable because > | it's only exported by Language.Haskell.TH. > | > | The documentation doesn't mention that it can only be used to create > | new top level functions and FFI imports[2]. I think that adding FFI > | imports was the main motivation for implementing it. In the past > | I've wanted to generate instances via this function, but unfortunately > | it's not implemented.. > | > | Hope that helps! > | -Michael > | > | [1] http://hackage.haskell.org/package/template-haskell- > | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls > | > | [2] > | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ > | compiler/typecheck/TcSplice.hs#L818 > | > | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: > | > Hi, > | > > | > I am in a situation where it would be very useful to call C functions > | > without an explicit FFI import. For example, I'd like to be able to do > | > > | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 > | > > | > instead of declaring the foreign import explicitely at the top level. > | > > | > Is there a way to do this or to achieve similar results in some other > | > way? > | > > | > If not, I imagine it would be easy to implement such a facility in GHC, > | > given that the code implementing calling to C functions must already be > | > present to implement "proper" FFI imports. I think such an addition > | > would be useful in many cases. > | > > | > Thanks, > | > Francesco > | > _______________________________________________ > | > Haskell-Cafe mailing list > | > Haskell-Cafe at haskell.org > | > http://www.haskell.org/mailman/listinfo/haskell-cafe > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | http://www.haskell.org/mailman/listinfo/ghc-devs From mgsloan at gmail.com Thu Feb 12 00:41:28 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Wed, 11 Feb 2015 16:41:28 -0800 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: <54DBEAF8.2060501@cs.drexel.edu> References: <618BE556AADD624C9C918AA5D5911BEF562C740B@DB3PRD3001MB020.064d.mgd.msft.net> <54DBEAF8.2060501@cs.drexel.edu> Message-ID: Hi! I don't mean to be accusatory with the whole documentation thing - I totally understand that most folks have a lot going on! In this particular case, I got very excited when I initially saw addTopDecls, because it says it allows you to "Add additional top-level declarations". After implementing something to use it, I got rather disappointed as it couldn't add instances. So, when I say "not implemented", it's just that the docs say it allows you to add additional top-level decls, when you can really only add functions, variable bindings, and foreign import decls. I didn't realize that not re-exporting these functions is due to their experimental status. That makes sense! I'm glad it was a conscious decision. I just tried writing a demo of addTopDecls, but unfortunately using it to add a function and referencing this function causes a GHC internal error: https://gist.github.com/mgsloan/53d7fa50338c696e5c80 . I haven't tried it with a foreign import yet. -Michael On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland wrote: > Typed Template Haskell happened at the end of my tenure at MSR, and > there was a mad rush to get it in to the compiler in time for 7.8.3 at > the same time I was starting a new job. I'm afraid the documentation is > indeed wanting, but the alternative was no typed Template Haskell. > > One side-effect was that the functions you note as present only in > Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't > re-export them from Language.Haskell.TH. > > I am willing to help with documentation if people want to use this > functionality. Has anyone attempted to use addTopDecls? Michael, when > you say "it's not implemented," what do you mean? What, exactly, is not > implemented? > > Cheers, > Geoff > > On 2/11/15 6:32 PM, Michael Sloan wrote: >> I'd love for the implementation to be as powerful as the documentation >> suggests it is :D >> >> However, yes, in the meantime, fixing the documentation would be great! >> >> Also, I meant to say that addTopDecls is only exported by >> "Language.Haskell.TH.Syntax". While this is a digression, there are a >> few other handy functions that are oddly left out of >> "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly >> more. >> >> -Michael >> >> On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones >> wrote: >>> I would LOVE someone to improve the documentation for addTopDecls. Manuel Chakravarty and Geoff Mainland were responsible for the implementation. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michael >>> | Sloan >>> | Sent: 11 February 2015 23:19 >>> | To: Francesco Mazzoli >>> | Cc: ghc-devs at haskell.org; haskell >>> | Subject: Re: [Haskell-cafe] Anonymous FFI calls >>> | >>> | It seems like addTopDecls[1] will able to help here. Unfortunately, >>> | the function is not well documented and not very discoverable because >>> | it's only exported by Language.Haskell.TH. >>> | >>> | The documentation doesn't mention that it can only be used to create >>> | new top level functions and FFI imports[2]. I think that adding FFI >>> | imports was the main motivation for implementing it. In the past >>> | I've wanted to generate instances via this function, but unfortunately >>> | it's not implemented.. >>> | >>> | Hope that helps! >>> | -Michael >>> | >>> | [1] http://hackage.haskell.org/package/template-haskell- >>> | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls >>> | >>> | [2] >>> | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ >>> | compiler/typecheck/TcSplice.hs#L818 >>> | >>> | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: >>> | > Hi, >>> | > >>> | > I am in a situation where it would be very useful to call C functions >>> | > without an explicit FFI import. For example, I'd like to be able to do >>> | > >>> | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 >>> | > >>> | > instead of declaring the foreign import explicitely at the top level. >>> | > >>> | > Is there a way to do this or to achieve similar results in some other >>> | > way? >>> | > >>> | > If not, I imagine it would be easy to implement such a facility in GHC, >>> | > given that the code implementing calling to C functions must already be >>> | > present to implement "proper" FFI imports. I think such an addition >>> | > would be useful in many cases. >>> | > >>> | > Thanks, >>> | > Francesco >>> | > _______________________________________________ >>> | > Haskell-Cafe mailing list >>> | > Haskell-Cafe at haskell.org >>> | > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | http://www.haskell.org/mailman/listinfo/ghc-devs > From stegeman at gmail.com Thu Feb 12 02:22:01 2015 From: stegeman at gmail.com (Luite Stegeman) Date: Thu, 12 Feb 2015 15:22:01 +1300 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF562C59A4@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Another example, similar to Manuel's work but for GHCJS JavaScriptFFI is ghcjs-ffiqq: https://github.com/ghcjs/ghcjs-ffiqq . There is some automatic marshalling of arguments and results using the ToJSRef / FromJSRef typeclasses. I'm working on integrating the improvements in these typeclasses back into ghcjs-base. The quasiquoter might be moved there too, but I'm not sure yet. The (ugly) implementation is here: https://github.com/ghcjs/ghcjs-ffiqq/blob/master/src/GHCJS/Foreign/QQ.hs Adapting to ccall imports should be straightforward, but implementing the full functionality would require a bit more stub code generation, since this code depends on GHCJS' native support for inline foreign import argument placeholders ($1, $2, $3 etc) placeholders. luite On Wed, Feb 11, 2015 at 11:40 PM, Simon Peyton Jones wrote: > This may be relevant. http://www.cse.unsw.edu.au/~chak/papers/CMCK14.html > Manuel gave a talk about something like this at the Haskell Symposium. > > Simon > > | -----Original Message----- > | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf > | Of Francesco Mazzoli > | Sent: 11 February 2015 10:26 > | To: haskell; ghc-devs at haskell.org > | Subject: [Haskell-cafe] Anonymous FFI calls > | > | Hi, > | > | I am in a situation where it would be very useful to call C functions > | without an explicit FFI import. For example, I'd like to be able to > | do > | > | (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 > | > | instead of declaring the foreign import explicitely at the top level. > | > | Is there a way to do this or to achieve similar results in some other > | way? > | > | If not, I imagine it would be easy to implement such a facility in > | GHC, given that the code implementing calling to C functions must > | already be present to implement "proper" FFI imports. I think such an > | addition would be useful in many cases. > | > | Thanks, > | Francesco > | _______________________________________________ > | Haskell-Cafe mailing list > | Haskell-Cafe at haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs From mgsloan at gmail.com Thu Feb 12 03:13:21 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Wed, 11 Feb 2015 19:13:21 -0800 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: <54DC1518.80609@cs.drexel.edu> References: <618BE556AADD624C9C918AA5D5911BEF562C740B@DB3PRD3001MB020.064d.mgd.msft.net> <54DBEAF8.2060501@cs.drexel.edu> <54DC1518.80609@cs.drexel.edu> Message-ID: It works, cool! So at least this ought to address Francesco's use-case. Is there anything wrong with my code? It definitely looks like a GHC bug. Yes, I've successfully generated instance declarations from the top-level. I may as well describe the usecase: pretty printing a value of any type in GHCI. While this feature list isn't the main point here, it'd be very cool to do things like: * Look up the value of mutable references such as IORefs * Print out functions as just their type * Be able to evaluate particular subtrees of the pretty print output (like present [1]) * Select a subportion of the output and get a variable out of it Usage would look like "$(pretty 'x)". This would reify the type of x and transitively generate `Pretty` instances for things, by using my th-reify-many package [2]. It then generates an expression which invokes `pretty` on `x`, using these new instances. This instance generation can do clever things like check if a type has a "Data" instance, and use it if available. In this way, we can construct a pretty printer for ghci which will work for any type. Certainly, this is still possible without instance generation, but it'd be quite clever to not need to re-generate the pretty printing code for every invocation. -Michael [1] https://github.com/chrisdone/present [2] https://github.com/mgsloan/th-reify-many On Wed, Feb 11, 2015 at 6:51 PM, Geoffrey Mainland wrote: > Hi Michael, > > Try this out: > > https://gist.github.com/mainland/f18cf3827c4b0b64b835 > > Have you had success generating instance declarations from top-level > splices? > > Geoff > > On 02/11/2015 07:41 PM, Michael Sloan wrote: >> Hi! >> >> I don't mean to be accusatory with the whole documentation thing - I >> totally understand that most folks have a lot going on! In this >> particular case, I got very excited when I initially saw addTopDecls, >> because it says it allows you to "Add additional top-level >> declarations". After implementing something to use it, I got rather >> disappointed as it couldn't add instances. >> >> So, when I say "not implemented", it's just that the docs say it >> allows you to add additional top-level decls, when you can really only >> add functions, variable bindings, and foreign import decls. >> >> I didn't realize that not re-exporting these functions is due to their >> experimental status. That makes sense! I'm glad it was a conscious >> decision. I just tried writing a demo of addTopDecls, but >> unfortunately using it to add a function and referencing this function >> causes a GHC internal error: >> https://gist.github.com/mgsloan/53d7fa50338c696e5c80 . I haven't >> tried it with a foreign import yet. >> >> -Michael >> >> On Wed, Feb 11, 2015 at 3:51 PM, Geoffrey Mainland >> wrote: >>> Typed Template Haskell happened at the end of my tenure at MSR, and >>> there was a mad rush to get it in to the compiler in time for 7.8.3 at >>> the same time I was starting a new job. I'm afraid the documentation is >>> indeed wanting, but the alternative was no typed Template Haskell. >>> >>> One side-effect was that the functions you note as present only in >>> Language.Haskell.TH.Syntax were not thoroughly vetted, so we didn't >>> re-export them from Language.Haskell.TH. >>> >>> I am willing to help with documentation if people want to use this >>> functionality. Has anyone attempted to use addTopDecls? Michael, when >>> you say "it's not implemented," what do you mean? What, exactly, is not >>> implemented? >>> >>> Cheers, >>> Geoff >>> >>> On 2/11/15 6:32 PM, Michael Sloan wrote: >>>> I'd love for the implementation to be as powerful as the documentation >>>> suggests it is :D >>>> >>>> However, yes, in the meantime, fixing the documentation would be great! >>>> >>>> Also, I meant to say that addTopDecls is only exported by >>>> "Language.Haskell.TH.Syntax". While this is a digression, there are a >>>> few other handy functions that are oddly left out of >>>> "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly >>>> more. >>>> >>>> -Michael >>>> >>>> On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones >>>> wrote: >>>>> I would LOVE someone to improve the documentation for addTopDecls. Manuel Chakravarty and Geoff Mainland were responsible for the implementation. >>>>> >>>>> Simon >>>>> >>>>> | -----Original Message----- >>>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Michael >>>>> | Sloan >>>>> | Sent: 11 February 2015 23:19 >>>>> | To: Francesco Mazzoli >>>>> | Cc: ghc-devs at haskell.org; haskell >>>>> | Subject: Re: [Haskell-cafe] Anonymous FFI calls >>>>> | >>>>> | It seems like addTopDecls[1] will able to help here. Unfortunately, >>>>> | the function is not well documented and not very discoverable because >>>>> | it's only exported by Language.Haskell.TH. >>>>> | >>>>> | The documentation doesn't mention that it can only be used to create >>>>> | new top level functions and FFI imports[2]. I think that adding FFI >>>>> | imports was the main motivation for implementing it. In the past >>>>> | I've wanted to generate instances via this function, but unfortunately >>>>> | it's not implemented.. >>>>> | >>>>> | Hope that helps! >>>>> | -Michael >>>>> | >>>>> | [1] http://hackage.haskell.org/package/template-haskell- >>>>> | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls >>>>> | >>>>> | [2] >>>>> | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33f78a/ >>>>> | compiler/typecheck/TcSplice.hs#L818 >>>>> | >>>>> | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli wrote: >>>>> | > Hi, >>>>> | > >>>>> | > I am in a situation where it would be very useful to call C functions >>>>> | > without an explicit FFI import. For example, I'd like to be able to do >>>>> | > >>>>> | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 >>>>> | > >>>>> | > instead of declaring the foreign import explicitely at the top level. >>>>> | > >>>>> | > Is there a way to do this or to achieve similar results in some other >>>>> | > way? >>>>> | > >>>>> | > If not, I imagine it would be easy to implement such a facility in GHC, >>>>> | > given that the code implementing calling to C functions must already be >>>>> | > present to implement "proper" FFI imports. I think such an addition >>>>> | > would be useful in many cases. >>>>> | > >>>>> | > Thanks, >>>>> | > Francesco >>>>> | > _______________________________________________ >>>>> | > Haskell-Cafe mailing list >>>>> | > Haskell-Cafe at haskell.org >>>>> | > http://www.haskell.org/mailman/listinfo/haskell-cafe >>>>> | _______________________________________________ >>>>> | ghc-devs mailing list >>>>> | ghc-devs at haskell.org >>>>> | http://www.haskell.org/mailman/listinfo/ghc-devs > From ky3 at atamo.com Thu Feb 12 04:26:04 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Thu, 12 Feb 2015 11:26:04 +0700 Subject: [Haskell-cafe] GHC Hackaton (GHC internals) slides In-Reply-To: References: Message-ID: Hi Maurizio, The only GHC hackathon I know of is the one in Portland in 2006, which is what your video links to apparently. While it certainly helps to have the slides while watching the video -- kudos to Malcolm for doing them -- some of the information contained in them has bitrotted. Your best bet for up-to-date info on the inner workings of GHC is to look up the wiki: https://ghc.haskell.org/trac/ghc/ The hackathon jump-started the wiki, iirc. And over time, careful curation has only added to it. -- Kim-Ee On Thu, Feb 12, 2015 at 3:55 AM, Maurizio Vitale wrote: > Anybody knows if the slides (or higher quality video) for the GHC Hackaton > are available? > I'm not sure which year, this video has been posted in 2012: > > > https://www.youtube.com/watch?v=lw7kbUvAmK4&list=PLBkRCigjPwyeCSD_DFxpd246YIF7_RDDI > > Thanks! > > Maurizio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrz.vtl at gmail.com Thu Feb 12 06:20:14 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Thu, 12 Feb 2015 01:20:14 -0500 Subject: [Haskell-cafe] GHC Hackaton (GHC internals) slides In-Reply-To: References: Message-ID: Thanks. The Haskell Commentary seems to cover the same material used in the videos. On Wed, Feb 11, 2015 at 11:26 PM, Kim-Ee Yeoh wrote: > Hi Maurizio, > > The only GHC hackathon I know of is the one in Portland in 2006, which is > what your video links to apparently. > > While it certainly helps to have the slides while watching the video -- > kudos to Malcolm for doing them -- some of the information contained in > them has bitrotted. > > Your best bet for up-to-date info on the inner workings of GHC is to look > up the wiki: > > https://ghc.haskell.org/trac/ghc/ > > The hackathon jump-started the wiki, iirc. And over time, careful curation > has only added to it. > > -- Kim-Ee > > On Thu, Feb 12, 2015 at 3:55 AM, Maurizio Vitale > wrote: > >> Anybody knows if the slides (or higher quality video) for the GHC >> Hackaton are available? >> I'm not sure which year, this video has been posted in 2012: >> >> >> https://www.youtube.com/watch?v=lw7kbUvAmK4&list=PLBkRCigjPwyeCSD_DFxpd246YIF7_RDDI >> >> Thanks! >> >> Maurizio >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Feb 12 08:29:29 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 12 Feb 2015 08:29:29 +0000 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF562C740B@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C75BE@DB3PRD3001MB020.064d.mgd.msft.net> | Also, I meant to say that addTopDecls is only exported by | "Language.Haskell.TH.Syntax". While this is a digression, there are a | few other handy functions that are oddly left out of | "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly | more. That does seem wrong. Do make a patch! SIMon | | -Michael | | On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones | wrote: | > I would LOVE someone to improve the documentation for addTopDecls. | Manuel Chakravarty and Geoff Mainland were responsible for the | implementation. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of | > | Michael Sloan | > | Sent: 11 February 2015 23:19 | > | To: Francesco Mazzoli | > | Cc: ghc-devs at haskell.org; haskell | > | Subject: Re: [Haskell-cafe] Anonymous FFI calls | > | | > | It seems like addTopDecls[1] will able to help here. | Unfortunately, | > | the function is not well documented and not very discoverable | > | because it's only exported by Language.Haskell.TH. | > | | > | The documentation doesn't mention that it can only be used to | create | > | new top level functions and FFI imports[2]. I think that adding | FFI | > | imports was the main motivation for implementing it. In the past | > | I've wanted to generate instances via this function, but | > | unfortunately it's not implemented.. | > | | > | Hope that helps! | > | -Michael | > | | > | [1] http://hackage.haskell.org/package/template-haskell- | > | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls | > | | > | [2] | > | | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33 | > | f78a/ | > | compiler/typecheck/TcSplice.hs#L818 | > | | > | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli | wrote: | > | > Hi, | > | > | > | > I am in a situation where it would be very useful to call C | > | > functions without an explicit FFI import. For example, I'd like | > | > to be able to do | > | > | > | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 | > | > | > | > instead of declaring the foreign import explicitely at the top | level. | > | > | > | > Is there a way to do this or to achieve similar results in some | > | > other way? | > | > | > | > If not, I imagine it would be easy to implement such a facility | in | > | > GHC, given that the code implementing calling to C functions | must | > | > already be present to implement "proper" FFI imports. I think | > | > such an addition would be useful in many cases. | > | > | > | > Thanks, | > | > Francesco | > | > _______________________________________________ | > | > Haskell-Cafe mailing list | > | > Haskell-Cafe at haskell.org | > | > http://www.haskell.org/mailman/listinfo/haskell-cafe | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs at haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs From k-bx at k-bx.com Thu Feb 12 08:50:29 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Thu, 12 Feb 2015 10:50:29 +0200 Subject: [Haskell-cafe] Rationale for two separate map functions in ClassyPrelude In-Reply-To: References: Message-ID: Hi Clinton. I find this to be a fantastic idea. I really enjoyed how "type-level functions" (TypeFamilies) being able to "un-apply" a type-function (code like `type Element (f a) = a`) is a central piece of implementation here. One thing I would add from myself is that names like Element and Container were highly misleading for me, since they're rather "type from which map function maps" and "end-result type". Not sure on new best names, just shared my thoughts on these. Thanks. On Wed, Feb 11, 2015 at 9:00 PM, Clinton Mead wrote: > ClassyPrelude has two map functions, namely: > > 1. "map" > 2. "omap" > > "map" works on any Functor. However, things like "Text" are not functors > as they aren't generic containers. As can be seen in the following code: > > module Main where > import Prelude () > import ClassyPrelude > import qualified Data.Text as T > import Data.Char as C > > main = do > let l = [1,2,3] :: [Int] > let t = (T.pack "Hello") > let m = Just 5 > print $ map (*2) l > print $ map (*2) m > print $ omap C.toUpper t > return () > > > Notice one has to use "omap" to deal with the Text. The thing is, I found > it trivially easy to get "map" to work for both calls. Here's the code: > > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies #-} > > module Main where > import Prelude hiding (map) > import qualified Data.Text as T > import Data.Char as C > import Control.Monad (Functor) > > class CanMap a b where > type Element a :: * > type Container a b :: * > map :: (Element a -> b) -> a -> Container a b > > instance (Functor f) => CanMap (f a) b where > type Element (f a) = a > type Container (f a) b = f b > map = fmap > > instance CanMap T.Text Char where > type Element T.Text = Char > type Container T.Text Char = T.Text > map = T.map > > main = do > let l = [1,2,3] :: [Int] > let m = Just 5 > let t = (T.pack "Hello") > print $ map (*2) l > print $ map (*2) m > print $ map C.toUpper t > return () > > > All that's required is to add instances to CanMap for any monomorphic > containers. ClassyPrelude already does this anyway with "omap" in the > Data.MonoTraversable module. I suspect however there's a good reason I'm > missing about why there should be two separate map functions to deal with > these alternate situations, but I'm wondering what that is. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f at mazzo.li Thu Feb 12 08:59:53 2015 From: f at mazzo.li (Francesco Mazzoli) Date: Thu, 12 Feb 2015 09:59:53 +0100 Subject: [Haskell-cafe] Anonymous FFI calls In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C75BE@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF562C740B@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF562C75BE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Thanks to everyone who replied! It seems like that through a combination of facilities like `libffi' and `addTopDecls' I can do everything that I wanted to do. I still want to take a shot at implementing anonymous FFI calls, since IMHO I think they are a very small but useful addition to the language. Francesco On 12 February 2015 at 09:29, Simon Peyton Jones wrote: > | Also, I meant to say that addTopDecls is only exported by > | "Language.Haskell.TH.Syntax". While this is a digression, there are a > | few other handy functions that are oddly left out of > | "Language.Haskell.TH": addDependentFile, addModFinalizer, and possibly > | more. > > That does seem wrong. Do make a patch! > > SIMon > > | > | -Michael > | > | On Wed, Feb 11, 2015 at 3:25 PM, Simon Peyton Jones > | wrote: > | > I would LOVE someone to improve the documentation for addTopDecls. > | Manuel Chakravarty and Geoff Mainland were responsible for the > | implementation. > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of > | > | Michael Sloan > | > | Sent: 11 February 2015 23:19 > | > | To: Francesco Mazzoli > | > | Cc: ghc-devs at haskell.org; haskell > | > | Subject: Re: [Haskell-cafe] Anonymous FFI calls > | > | > | > | It seems like addTopDecls[1] will able to help here. > | Unfortunately, > | > | the function is not well documented and not very discoverable > | > | because it's only exported by Language.Haskell.TH. > | > | > | > | The documentation doesn't mention that it can only be used to > | create > | > | new top level functions and FFI imports[2]. I think that adding > | FFI > | > | imports was the main motivation for implementing it. In the past > | > | I've wanted to generate instances via this function, but > | > | unfortunately it's not implemented.. > | > | > | > | Hope that helps! > | > | -Michael > | > | > | > | [1] http://hackage.haskell.org/package/template-haskell- > | > | 2.9.0.0/docs/Language-Haskell-TH-Syntax.html#v:addTopDecls > | > | > | > | [2] > | > | > | https://github.com/ghc/ghc/blob/1d982ba10f590828b78eba992e73315dee33 > | > | f78a/ > | > | compiler/typecheck/TcSplice.hs#L818 > | > | > | > | On Wed, Feb 11, 2015 at 2:26 AM, Francesco Mazzoli > | wrote: > | > | > Hi, > | > | > > | > | > I am in a situation where it would be very useful to call C > | > | > functions without an explicit FFI import. For example, I'd like > | > | > to be able to do > | > | > > | > | > (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 > | > | > > | > | > instead of declaring the foreign import explicitely at the top > | level. > | > | > > | > | > Is there a way to do this or to achieve similar results in some > | > | > other way? > | > | > > | > | > If not, I imagine it would be easy to implement such a facility > | in > | > | > GHC, given that the code implementing calling to C functions > | must > | > | > already be present to implement "proper" FFI imports. I think > | > | > such an addition would be useful in many cases. > | > | > > | > | > Thanks, > | > | > Francesco > | > | > _______________________________________________ > | > | > Haskell-Cafe mailing list > | > | > Haskell-Cafe at haskell.org > | > | > http://www.haskell.org/mailman/listinfo/haskell-cafe > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs at haskell.org > | > | http://www.haskell.org/mailman/listinfo/ghc-devs From marat61 at gmail.com Thu Feb 12 13:24:12 2015 From: marat61 at gmail.com (=?UTF-8?B?0JfQsNC60LjRgNC+0LIg0JzQsNGA0LDRgg==?=) Date: Thu, 12 Feb 2015 17:24:12 +0400 Subject: [Haskell-cafe] example Message-ID: Hi all, Algorithms on graphs in my opinion is something bad for parallel execution (especially such of them which have O(n) comlexity). So if I haskell give me an advantage in some graph application it will be great benchmark. Recently I tried to think about well-known by compiler people - so called "topologic-sort" or reverse post order numeration, but I gave up... There are just nothing to execute in parallel. Currently I am searching for graph (compiler) algorithm example written in haskell with persistent data structures which can be executed in parallel. And in the same time this example written in imperative style must not have good parallel execution form. Summarizing: I want to find example of data_persistence&functional style killer graph (compiler) application. Do you know such an example? -- *Regards, Marat.* *? ????????? ?????.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Thu Feb 12 15:13:08 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Thu, 12 Feb 2015 19:13:08 +0400 Subject: [Haskell-cafe] example In-Reply-To: References: Message-ID: Hello, Marat. There are a bunch of algorithms on a graph that can be be parallelized. For example you may want to take a look at big graph analisys tool Stinger [1], or to haskell implementation [2]. Both libraries heavily expose parallelism. [1] http://www.stingergraph.com/ [2] https://hackage.haskell.org/package/GraphHammer On 12 February 2015 at 16:24, ??????? ????? wrote: > Hi all, > > Algorithms on graphs in my opinion is something bad for parallel execution > (especially such of them which have O(n) comlexity). So if I haskell give > me an advantage in some graph application it will be great benchmark. > Recently I tried to think about well-known by compiler people - so called > "topologic-sort" or reverse post order numeration, but I gave up... There > are just nothing to execute in parallel. Currently I am searching for graph > (compiler) algorithm example written in haskell with persistent data > structures which can be executed in parallel. And in the same time this > example written in imperative style must not have good parallel execution > form. > > Summarizing: I want to find example of data_persistence&functional style > killer graph (compiler) application. > > Do you know such an example? > > -- > Regards, Marat. > ? ????????? ?????. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Alexander From gershomb at gmail.com Thu Feb 12 19:47:16 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 12 Feb 2015 14:47:16 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? Message-ID: For a long time, many people, including me, have said that "Foldable has no laws" (or Foldable only has free laws) -- this is true, as it stands, with the exception that Foldable has a non-free law in interaction with Traversable (namely that it act as a proper specialization of Traversable methods). However, I believe that there is a good law we can give for Foldable. I earlier explored this in a paper presented at IFL 2014 but (rightfully) rejected from the IFL post-proceedings. ( http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of the way there, but I believe now have a better approach on the question of a Foldable law -- as sketched below. I think I now (unlike in the paper) can state a succinct law for Foldable that has desired properties: 1) It is not "free" -- it can be violated, and thus stating it adds semantic content. 2) We typically expect it to be true. 3) There are no places where I can see an argument for violating it. If it pans out, I intend to pursue this and write it up more formally, but given the current FTP discussion I thought it was worth documenting this earlier rather than later. For simplicity, I will state this property in terms of `toList` although that does not properly capture the infinite cases. Apologies for what may be nonstandard notation. Here is the law I think we should discuss requiring: * * * Given Foldable f, then forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a --> a `elem` toList x * * * Since we do not require `a` to be of type `Eq`, note that the `elem` function given here is not internal to Haskell, but in the metalogic. Furthermore, note that the use of parametricity here lets us make an "end run" around the usual problem of giving laws to Foldable -- rather than providing an interaction with another class, we provide a claim about _all_ functions of a particular type. Also note that the functions `g` we intend to quantify over are functions that _can be written_ -- so we can respect the property of data structures to abstract over information. Consider data Funny a = Funny {hidden :: a, public :: [a]} instance Foldable Funny where foldMap f x = foldMap f (public x) Now, if it is truly impossible to ever "see" hidden (i.e. it is not exported, or only exported through a semantics-breaking "Internal" module), then the Foldable instance is legitimate. Otherwise, the Foldable instance is illegitimate by the law given above. I would suggest the law given is "morally" the right thing for Foldable -- a Foldable instance for `f` should suggest that it gives us "all the as in any `f a`", and so it is, in some particular restricted sense, initial among functions that extract as. I do not suggest we add this law right away. However, I would like to suggest considering it, and I believe it (or a cleaned-up variant) would help us to see Foldable as a more legitimately lawful class that not only provides conveniences but can be used to aid reasoning. Relating this to adjointness, as I do in the IFL preprint, remains future work. Cheers, Gershom -------------- next part -------------- An HTML attachment was scrubbed... URL: From atzeus at gmail.com Thu Feb 12 19:59:20 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Thu, 12 Feb 2015 20:59:20 +0100 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: Hi Gershom! Do you have an example where this law allows us to conclude something interesting we otherwise would not have been able to conclude? Cheers, Atze On Feb 12, 2015 8:47 PM, "Gershom B" wrote: > For a long time, many people, including me, have said that "Foldable has > no laws" (or Foldable only has free laws) -- this is true, as it stands, > with the exception that Foldable has a non-free law in interaction with > Traversable (namely that it act as a proper specialization of Traversable > methods). However, I believe that there is a good law we can give for > Foldable. > > I earlier explored this in a paper presented at IFL 2014 but (rightfully) > rejected from the IFL post-proceedings. ( > http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of > the way there, but I believe now have a better approach on the question of > a Foldable law -- as sketched below. > > I think I now (unlike in the paper) can state a succinct law for Foldable > that has desired properties: 1) It is not "free" -- it can be violated, and > thus stating it adds semantic content. 2) We typically expect it to be > true. 3) There are no places where I can see an argument for violating it. > > If it pans out, I intend to pursue this and write it up more formally, but > given the current FTP discussion I thought it was worth documenting this > earlier rather than later. For simplicity, I will state this property in > terms of `toList` although that does not properly capture the infinite > cases. Apologies for what may be nonstandard notation. > > Here is the law I think we should discuss requiring: > > * * * > Given Foldable f, then > forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a --> > a `elem` toList x > * * * > > Since we do not require `a` to be of type `Eq`, note that the `elem` > function given here is not internal to Haskell, but in the metalogic. > > Furthermore, note that the use of parametricity here lets us make an "end > run" around the usual problem of giving laws to Foldable -- rather than > providing an interaction with another class, we provide a claim about _all_ > functions of a particular type. > > Also note that the functions `g` we intend to quantify over are functions > that _can be written_ -- so we can respect the property of data structures > to abstract over information. Consider > > data Funny a = Funny {hidden :: a, public :: [a]} > > instance Foldable Funny where > foldMap f x = foldMap f (public x) > > Now, if it is truly impossible to ever "see" hidden (i.e. it is not > exported, or only exported through a semantics-breaking "Internal" module), > then the Foldable instance is legitimate. Otherwise, the Foldable instance > is illegitimate by the law given above. > > I would suggest the law given is "morally" the right thing for Foldable -- > a Foldable instance for `f` should suggest that it gives us "all the as in > any `f a`", and so it is, in some particular restricted sense, initial > among functions that extract as. > > I do not suggest we add this law right away. However, I would like to > suggest considering it, and I believe it (or a cleaned-up variant) would > help us to see Foldable as a more legitimately lawful class that not only > provides conveniences but can be used to aid reasoning. > > Relating this to adjointness, as I do in the IFL preprint, remains future > work. > > Cheers, > Gershom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Feb 12 20:36:16 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 12 Feb 2015 15:36:16 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: There are 3 cases ruled out by this law. Two of them I'd have no trouble seeing go, the third one I think damages it beyond repair. First, `foldMap = mempty` is currently an admissable definition of foldMap for anything that is not Traversable. The law effectively talks backwards and ensures that you have to give back info on every 'a' in the container, so this is ruled out for any container that actually 'contains' an a. I'm pretty much okay with that case being ruled out. Second, There are instances such as the Foldable instance for `Machine` in the machines package. Here it starves the machine for input and takes the output and folds over it. However, these are not 'all of the 'a's it is possible to generate with such a machine, as you can construct a function (Machine ((->) b) a -> Maybe a) that feeds the machine a 'b' and then gets out an 'a' that would not occur in toList. One could argue that this Foldable violates the spirit of Foldable. I'm somewhat less okay with that case being ruled out as folks have found it useful, but I could accept it. Third, In the presence of GADTs, the fact that Foldable only accepts 'f' in negative position means that 'f' might be a GADT, telling us more about `a`, despite your function being parametric. e.g. it could carry around a Num constraint on its argument. Extracting this dictionary from the GADT would enable sum :: Num a => f a -> a to be used in your function (forall a. f a -> Maybe a), preventing parametricity from providing the insurance you seek. This means that your law would rule out any `Foldable` that exploits GADT-like properties. A version of `Set` where the data type carries around the `Ord` instance internally, could for instance instantiate `elem` in log time. That example becomes only marginally safe under your law because of `min` and `max` being in Ord and producing "new" a's, but it also rules out similar O(1) optimizations for sum or product in other potential containers, which could carry Num. These I'm much more reluctant to let go. You might be able to repair your law by also quantifying over `f` with a Foldable constraint or some such, but that re-admits the former 2 laws and seems to make it vacuous. -Edward On Thu, Feb 12, 2015 at 2:59 PM, Atze van der Ploeg wrote: > Hi Gershom! > > Do you have an example where this law allows us to conclude something > interesting we otherwise would not have been able to conclude? > > Cheers, > > Atze > On Feb 12, 2015 8:47 PM, "Gershom B" wrote: > >> For a long time, many people, including me, have said that "Foldable has >> no laws" (or Foldable only has free laws) -- this is true, as it stands, >> with the exception that Foldable has a non-free law in interaction with >> Traversable (namely that it act as a proper specialization of Traversable >> methods). However, I believe that there is a good law we can give for >> Foldable. >> >> I earlier explored this in a paper presented at IFL 2014 but (rightfully) >> rejected from the IFL post-proceedings. ( >> http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of >> the way there, but I believe now have a better approach on the question of >> a Foldable law -- as sketched below. >> >> I think I now (unlike in the paper) can state a succinct law for Foldable >> that has desired properties: 1) It is not "free" -- it can be violated, and >> thus stating it adds semantic content. 2) We typically expect it to be >> true. 3) There are no places where I can see an argument for violating it. >> >> If it pans out, I intend to pursue this and write it up more formally, >> but given the current FTP discussion I thought it was worth documenting >> this earlier rather than later. For simplicity, I will state this property >> in terms of `toList` although that does not properly capture the infinite >> cases. Apologies for what may be nonstandard notation. >> >> Here is the law I think we should discuss requiring: >> >> * * * >> Given Foldable f, then >> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a >> --> a `elem` toList x >> * * * >> >> Since we do not require `a` to be of type `Eq`, note that the `elem` >> function given here is not internal to Haskell, but in the metalogic. >> >> Furthermore, note that the use of parametricity here lets us make an "end >> run" around the usual problem of giving laws to Foldable -- rather than >> providing an interaction with another class, we provide a claim about _all_ >> functions of a particular type. >> >> Also note that the functions `g` we intend to quantify over are functions >> that _can be written_ -- so we can respect the property of data structures >> to abstract over information. Consider >> >> data Funny a = Funny {hidden :: a, public :: [a]} >> >> instance Foldable Funny where >> foldMap f x = foldMap f (public x) >> >> Now, if it is truly impossible to ever "see" hidden (i.e. it is not >> exported, or only exported through a semantics-breaking "Internal" module), >> then the Foldable instance is legitimate. Otherwise, the Foldable instance >> is illegitimate by the law given above. >> >> I would suggest the law given is "morally" the right thing for Foldable >> -- a Foldable instance for `f` should suggest that it gives us "all the as >> in any `f a`", and so it is, in some particular restricted sense, initial >> among functions that extract as. >> >> I do not suggest we add this law right away. However, I would like to >> suggest considering it, and I believe it (or a cleaned-up variant) would >> help us to see Foldable as a more legitimately lawful class that not only >> provides conveniences but can be used to aid reasoning. >> >> Relating this to adjointness, as I do in the IFL preprint, remains future >> work. >> >> Cheers, >> Gershom >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu Feb 12 20:49:07 2015 From: gershomb at gmail.com (Gershom B) Date: Thu, 12 Feb 2015 15:49:07 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: I agree the third issue raised is a pretty tricky one. GADTs can effectively pack in a "secret a" that is nonetheless accessible, or a "secret a -> a" for that matter... A quick and dirty repair is to just say that the law only applies to data types that do not quantify over dictionaries (and passes no judgement on data types which do). In such a case I think it is still useful, but unfortunately specialized. I absolutely think a more general law could be possible, but it could be rather tricky to state... Perhaps it could be stated by, instead of quantifying over _all_ a, quantifying over a specific "generic a" which promises it has no dictionaries with a positive occurrence of `a`. This maintains the spirit properly, but makes the statement more complex. With regards to Atze's question, the fact that such a law could rule out giving an arbitrary type an instance where "foldMap = mempty" is exactly the sort of thing we would like to see. --gershom On Thu, Feb 12, 2015 at 3:36 PM, Edward Kmett wrote: > There are 3 cases ruled out by this law. Two of them I'd have no trouble > seeing go, the third one I think damages it beyond repair. > > First, > > `foldMap = mempty` > > is currently an admissable definition of foldMap for anything that is not > Traversable. > > The law effectively talks backwards and ensures that you have to give back > info on every 'a' in the container, so this is ruled out for any container > that actually 'contains' an a. > > I'm pretty much okay with that case being ruled out. > > Second, > > There are instances such as the Foldable instance for `Machine` in the > machines package. Here it starves the machine for input and takes the > output and folds over it. > > However, these are not 'all of the 'a's it is possible to generate with > such a machine, as you can construct a function (Machine ((->) b) a -> > Maybe a) that feeds the machine a 'b' and then gets out an 'a' that would > not occur in toList. > > One could argue that this Foldable violates the spirit of Foldable. > > I'm somewhat less okay with that case being ruled out as folks have found > it useful, but I could accept it. > > Third, > > In the presence of GADTs, the fact that Foldable only accepts 'f' in > negative position means that 'f' might be a GADT, telling us more about > `a`, despite your function being parametric. > > e.g. it could carry around a Num constraint on its argument. Extracting > this dictionary from the GADT would enable sum :: Num a => f a -> a to be > used in your function (forall a. f a -> Maybe a), preventing parametricity > from providing the insurance you seek. > > This means that your law would rule out any `Foldable` that exploits > GADT-like properties. > > A version of `Set` where the data type carries around the `Ord` instance > internally, could for instance instantiate `elem` in log time. That example > becomes only marginally safe under your law because of `min` and `max` > being in Ord and producing "new" a's, but it also rules out similar O(1) > optimizations for sum or product in other potential containers, which could > carry Num. > > These I'm much more reluctant to let go. > > You might be able to repair your law by also quantifying over `f` with a > Foldable constraint or some such, but that re-admits the former 2 laws and > seems to make it vacuous. > > -Edward > > > On Thu, Feb 12, 2015 at 2:59 PM, Atze van der Ploeg > wrote: > >> Hi Gershom! >> >> Do you have an example where this law allows us to conclude something >> interesting we otherwise would not have been able to conclude? >> >> Cheers, >> >> Atze >> On Feb 12, 2015 8:47 PM, "Gershom B" wrote: >> >>> For a long time, many people, including me, have said that "Foldable has >>> no laws" (or Foldable only has free laws) -- this is true, as it stands, >>> with the exception that Foldable has a non-free law in interaction with >>> Traversable (namely that it act as a proper specialization of Traversable >>> methods). However, I believe that there is a good law we can give for >>> Foldable. >>> >>> I earlier explored this in a paper presented at IFL 2014 but >>> (rightfully) rejected from the IFL post-proceedings. ( >>> http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of >>> the way there, but I believe now have a better approach on the question of >>> a Foldable law -- as sketched below. >>> >>> I think I now (unlike in the paper) can state a succinct law for >>> Foldable that has desired properties: 1) It is not "free" -- it can be >>> violated, and thus stating it adds semantic content. 2) We typically expect >>> it to be true. 3) There are no places where I can see an argument for >>> violating it. >>> >>> If it pans out, I intend to pursue this and write it up more formally, >>> but given the current FTP discussion I thought it was worth documenting >>> this earlier rather than later. For simplicity, I will state this property >>> in terms of `toList` although that does not properly capture the infinite >>> cases. Apologies for what may be nonstandard notation. >>> >>> Here is the law I think we should discuss requiring: >>> >>> * * * >>> Given Foldable f, then >>> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a >>> --> a `elem` toList x >>> * * * >>> >>> Since we do not require `a` to be of type `Eq`, note that the `elem` >>> function given here is not internal to Haskell, but in the metalogic. >>> >>> Furthermore, note that the use of parametricity here lets us make an >>> "end run" around the usual problem of giving laws to Foldable -- rather >>> than providing an interaction with another class, we provide a claim about >>> _all_ functions of a particular type. >>> >>> Also note that the functions `g` we intend to quantify over are >>> functions that _can be written_ -- so we can respect the property of data >>> structures to abstract over information. Consider >>> >>> data Funny a = Funny {hidden :: a, public :: [a]} >>> >>> instance Foldable Funny where >>> foldMap f x = foldMap f (public x) >>> >>> Now, if it is truly impossible to ever "see" hidden (i.e. it is not >>> exported, or only exported through a semantics-breaking "Internal" module), >>> then the Foldable instance is legitimate. Otherwise, the Foldable instance >>> is illegitimate by the law given above. >>> >>> I would suggest the law given is "morally" the right thing for Foldable >>> -- a Foldable instance for `f` should suggest that it gives us "all the as >>> in any `f a`", and so it is, in some particular restricted sense, initial >>> among functions that extract as. >>> >>> I do not suggest we add this law right away. However, I would like to >>> suggest considering it, and I believe it (or a cleaned-up variant) would >>> help us to see Foldable as a more legitimately lawful class that not only >>> provides conveniences but can be used to aid reasoning. >>> >>> Relating this to adjointness, as I do in the IFL preprint, remains >>> future work. >>> >>> Cheers, >>> Gershom >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Feb 12 21:31:45 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Feb 2015 16:31:45 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: What I kind of like about this proposal is that it makes it illegal for potentially-infinite snoc-lists to be Foldable, since toList will produce _|_ on an infinite snoc-list. On the other hand, this is reason enough to make a lot of people hate it. The GADT problem Edward Kmett points out seems like a more serious issue. The solution is to make Functor f => Foldable f, which will probably eliminate another four fifths of the supporters of your idea. On Thu, Feb 12, 2015 at 3:49 PM, Gershom B wrote: > I agree the third issue raised is a pretty tricky one. GADTs can effectively > pack in a "secret a" that is nonetheless accessible, or a "secret a -> a" > for that matter... > > A quick and dirty repair is to just say that the law only applies to data > types that do not quantify over dictionaries (and passes no judgement on > data types which do). In such a case I think it is still useful, but > unfortunately specialized. > > I absolutely think a more general law could be possible, but it could be > rather tricky to state... Perhaps it could be stated by, instead of > quantifying over _all_ a, quantifying over a specific "generic a" which > promises it has no dictionaries with a positive occurrence of `a`. This > maintains the spirit properly, but makes the statement more complex. > > With regards to Atze's question, the fact that such a law could rule out > giving an arbitrary type an instance where "foldMap = mempty" is exactly the > sort of thing we would like to see. > > --gershom > > > On Thu, Feb 12, 2015 at 3:36 PM, Edward Kmett wrote: >> >> There are 3 cases ruled out by this law. Two of them I'd have no trouble >> seeing go, the third one I think damages it beyond repair. >> >> First, >> >> `foldMap = mempty` >> >> is currently an admissable definition of foldMap for anything that is not >> Traversable. >> >> The law effectively talks backwards and ensures that you have to give back >> info on every 'a' in the container, so this is ruled out for any container >> that actually 'contains' an a. >> >> I'm pretty much okay with that case being ruled out. >> >> Second, >> >> There are instances such as the Foldable instance for `Machine` in the >> machines package. Here it starves the machine for input and takes the output >> and folds over it. >> >> However, these are not 'all of the 'a's it is possible to generate with >> such a machine, as you can construct a function (Machine ((->) b) a -> Maybe >> a) that feeds the machine a 'b' and then gets out an 'a' that would not >> occur in toList. >> >> One could argue that this Foldable violates the spirit of Foldable. >> >> I'm somewhat less okay with that case being ruled out as folks have found >> it useful, but I could accept it. >> >> Third, >> >> In the presence of GADTs, the fact that Foldable only accepts 'f' in >> negative position means that 'f' might be a GADT, telling us more about `a`, >> despite your function being parametric. >> >> e.g. it could carry around a Num constraint on its argument. Extracting >> this dictionary from the GADT would enable sum :: Num a => f a -> a to be >> used in your function (forall a. f a -> Maybe a), preventing parametricity >> from providing the insurance you seek. >> >> This means that your law would rule out any `Foldable` that exploits >> GADT-like properties. >> >> A version of `Set` where the data type carries around the `Ord` instance >> internally, could for instance instantiate `elem` in log time. That example >> becomes only marginally safe under your law because of `min` and `max` being >> in Ord and producing "new" a's, but it also rules out similar O(1) >> optimizations for sum or product in other potential containers, which could >> carry Num. >> >> These I'm much more reluctant to let go. >> >> You might be able to repair your law by also quantifying over `f` with a >> Foldable constraint or some such, but that re-admits the former 2 laws and >> seems to make it vacuous. >> >> -Edward >> >> >> On Thu, Feb 12, 2015 at 2:59 PM, Atze van der Ploeg >> wrote: >>> >>> Hi Gershom! >>> >>> Do you have an example where this law allows us to conclude something >>> interesting we otherwise would not have been able to conclude? >>> >>> Cheers, >>> >>> Atze >>> >>> On Feb 12, 2015 8:47 PM, "Gershom B" wrote: >>>> >>>> For a long time, many people, including me, have said that "Foldable has >>>> no laws" (or Foldable only has free laws) -- this is true, as it stands, >>>> with the exception that Foldable has a non-free law in interaction with >>>> Traversable (namely that it act as a proper specialization of Traversable >>>> methods). However, I believe that there is a good law we can give for >>>> Foldable. >>>> >>>> I earlier explored this in a paper presented at IFL 2014 but >>>> (rightfully) rejected from the IFL post-proceedings. >>>> (http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of the >>>> way there, but I believe now have a better approach on the question of a >>>> Foldable law -- as sketched below. >>>> >>>> I think I now (unlike in the paper) can state a succinct law for >>>> Foldable that has desired properties: 1) It is not "free" -- it can be >>>> violated, and thus stating it adds semantic content. 2) We typically expect >>>> it to be true. 3) There are no places where I can see an argument for >>>> violating it. >>>> >>>> If it pans out, I intend to pursue this and write it up more formally, >>>> but given the current FTP discussion I thought it was worth documenting this >>>> earlier rather than later. For simplicity, I will state this property in >>>> terms of `toList` although that does not properly capture the infinite >>>> cases. Apologies for what may be nonstandard notation. >>>> >>>> Here is the law I think we should discuss requiring: >>>> >>>> * * * >>>> Given Foldable f, then >>>> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a >>>> --> a `elem` toList x >>>> * * * >>>> >>>> Since we do not require `a` to be of type `Eq`, note that the `elem` >>>> function given here is not internal to Haskell, but in the metalogic. >>>> >>>> Furthermore, note that the use of parametricity here lets us make an >>>> "end run" around the usual problem of giving laws to Foldable -- rather than >>>> providing an interaction with another class, we provide a claim about _all_ >>>> functions of a particular type. >>>> >>>> Also note that the functions `g` we intend to quantify over are >>>> functions that _can be written_ -- so we can respect the property of data >>>> structures to abstract over information. Consider >>>> >>>> data Funny a = Funny {hidden :: a, public :: [a]} >>>> >>>> instance Foldable Funny where >>>> foldMap f x = foldMap f (public x) >>>> >>>> Now, if it is truly impossible to ever "see" hidden (i.e. it is not >>>> exported, or only exported through a semantics-breaking "Internal" module), >>>> then the Foldable instance is legitimate. Otherwise, the Foldable instance >>>> is illegitimate by the law given above. >>>> >>>> I would suggest the law given is "morally" the right thing for Foldable >>>> -- a Foldable instance for `f` should suggest that it gives us "all the as >>>> in any `f a`", and so it is, in some particular restricted sense, initial >>>> among functions that extract as. >>>> >>>> I do not suggest we add this law right away. However, I would like to >>>> suggest considering it, and I believe it (or a cleaned-up variant) would >>>> help us to see Foldable as a more legitimately lawful class that not only >>>> provides conveniences but can be used to aid reasoning. >>>> >>>> Relating this to adjointness, as I do in the IFL preprint, remains >>>> future work. >>>> >>>> Cheers, >>>> Gershom >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ekmett at gmail.com Thu Feb 12 21:39:02 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 12 Feb 2015 16:39:02 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: The argument could be rephrased in terms of something other than toList, toList was more convenient short-hand than intending to rule out entire classes of recursion patterns. If we had a way to talk about roles you could likely recover this law for representational arguments, but dragging in a bunch of talk about (forall a b. Coercion a b -> Coercion (f a) (f b)) in order to claim that f is representational is a great way to make the law completely inaccessible and GHC specific, it also renders it useless for talking about things like Set, which aren't representational in their argument. And as been worked through to death in the past, Functor cannot be a superclass of Foldable. ;) -Edward On Thu, Feb 12, 2015 at 4:31 PM, David Feuer wrote: > What I kind of like about this proposal is that it makes it illegal > for potentially-infinite snoc-lists to be Foldable, since toList will > produce _|_ on an infinite snoc-list. On the other hand, this is > reason enough to make a lot of people hate it. The GADT problem Edward > Kmett points out seems like a more serious issue. The solution is to > make Functor f => Foldable f, which will probably eliminate another > four fifths of the supporters of your idea. > > On Thu, Feb 12, 2015 at 3:49 PM, Gershom B wrote: > > I agree the third issue raised is a pretty tricky one. GADTs can > effectively > > pack in a "secret a" that is nonetheless accessible, or a "secret a -> a" > > for that matter... > > > > A quick and dirty repair is to just say that the law only applies to data > > types that do not quantify over dictionaries (and passes no judgement on > > data types which do). In such a case I think it is still useful, but > > unfortunately specialized. > > > > I absolutely think a more general law could be possible, but it could be > > rather tricky to state... Perhaps it could be stated by, instead of > > quantifying over _all_ a, quantifying over a specific "generic a" which > > promises it has no dictionaries with a positive occurrence of `a`. This > > maintains the spirit properly, but makes the statement more complex. > > > > With regards to Atze's question, the fact that such a law could rule out > > giving an arbitrary type an instance where "foldMap = mempty" is exactly > the > > sort of thing we would like to see. > > > > --gershom > > > > > > On Thu, Feb 12, 2015 at 3:36 PM, Edward Kmett wrote: > >> > >> There are 3 cases ruled out by this law. Two of them I'd have no trouble > >> seeing go, the third one I think damages it beyond repair. > >> > >> First, > >> > >> `foldMap = mempty` > >> > >> is currently an admissable definition of foldMap for anything that is > not > >> Traversable. > >> > >> The law effectively talks backwards and ensures that you have to give > back > >> info on every 'a' in the container, so this is ruled out for any > container > >> that actually 'contains' an a. > >> > >> I'm pretty much okay with that case being ruled out. > >> > >> Second, > >> > >> There are instances such as the Foldable instance for `Machine` in the > >> machines package. Here it starves the machine for input and takes the > output > >> and folds over it. > >> > >> However, these are not 'all of the 'a's it is possible to generate with > >> such a machine, as you can construct a function (Machine ((->) b) a -> > Maybe > >> a) that feeds the machine a 'b' and then gets out an 'a' that would not > >> occur in toList. > >> > >> One could argue that this Foldable violates the spirit of Foldable. > >> > >> I'm somewhat less okay with that case being ruled out as folks have > found > >> it useful, but I could accept it. > >> > >> Third, > >> > >> In the presence of GADTs, the fact that Foldable only accepts 'f' in > >> negative position means that 'f' might be a GADT, telling us more about > `a`, > >> despite your function being parametric. > >> > >> e.g. it could carry around a Num constraint on its argument. Extracting > >> this dictionary from the GADT would enable sum :: Num a => f a -> a to > be > >> used in your function (forall a. f a -> Maybe a), preventing > parametricity > >> from providing the insurance you seek. > >> > >> This means that your law would rule out any `Foldable` that exploits > >> GADT-like properties. > >> > >> A version of `Set` where the data type carries around the `Ord` instance > >> internally, could for instance instantiate `elem` in log time. That > example > >> becomes only marginally safe under your law because of `min` and `max` > being > >> in Ord and producing "new" a's, but it also rules out similar O(1) > >> optimizations for sum or product in other potential containers, which > could > >> carry Num. > >> > >> These I'm much more reluctant to let go. > >> > >> You might be able to repair your law by also quantifying over `f` with a > >> Foldable constraint or some such, but that re-admits the former 2 laws > and > >> seems to make it vacuous. > >> > >> -Edward > >> > >> > >> On Thu, Feb 12, 2015 at 2:59 PM, Atze van der Ploeg > >> wrote: > >>> > >>> Hi Gershom! > >>> > >>> Do you have an example where this law allows us to conclude something > >>> interesting we otherwise would not have been able to conclude? > >>> > >>> Cheers, > >>> > >>> Atze > >>> > >>> On Feb 12, 2015 8:47 PM, "Gershom B" wrote: > >>>> > >>>> For a long time, many people, including me, have said that "Foldable > has > >>>> no laws" (or Foldable only has free laws) -- this is true, as it > stands, > >>>> with the exception that Foldable has a non-free law in interaction > with > >>>> Traversable (namely that it act as a proper specialization of > Traversable > >>>> methods). However, I believe that there is a good law we can give for > >>>> Foldable. > >>>> > >>>> I earlier explored this in a paper presented at IFL 2014 but > >>>> (rightfully) rejected from the IFL post-proceedings. > >>>> (http://gbaz.github.io/slides/buildable2014.pdf). That paper got > part of the > >>>> way there, but I believe now have a better approach on the question > of a > >>>> Foldable law -- as sketched below. > >>>> > >>>> I think I now (unlike in the paper) can state a succinct law for > >>>> Foldable that has desired properties: 1) It is not "free" -- it can be > >>>> violated, and thus stating it adds semantic content. 2) We typically > expect > >>>> it to be true. 3) There are no places where I can see an argument for > >>>> violating it. > >>>> > >>>> If it pans out, I intend to pursue this and write it up more formally, > >>>> but given the current FTP discussion I thought it was worth > documenting this > >>>> earlier rather than later. For simplicity, I will state this property > in > >>>> terms of `toList` although that does not properly capture the infinite > >>>> cases. Apologies for what may be nonstandard notation. > >>>> > >>>> Here is the law I think we should discuss requiring: > >>>> > >>>> * * * > >>>> Given Foldable f, then > >>>> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a > >>>> --> a `elem` toList x > >>>> * * * > >>>> > >>>> Since we do not require `a` to be of type `Eq`, note that the `elem` > >>>> function given here is not internal to Haskell, but in the metalogic. > >>>> > >>>> Furthermore, note that the use of parametricity here lets us make an > >>>> "end run" around the usual problem of giving laws to Foldable -- > rather than > >>>> providing an interaction with another class, we provide a claim about > _all_ > >>>> functions of a particular type. > >>>> > >>>> Also note that the functions `g` we intend to quantify over are > >>>> functions that _can be written_ -- so we can respect the property of > data > >>>> structures to abstract over information. Consider > >>>> > >>>> data Funny a = Funny {hidden :: a, public :: [a]} > >>>> > >>>> instance Foldable Funny where > >>>> foldMap f x = foldMap f (public x) > >>>> > >>>> Now, if it is truly impossible to ever "see" hidden (i.e. it is not > >>>> exported, or only exported through a semantics-breaking "Internal" > module), > >>>> then the Foldable instance is legitimate. Otherwise, the Foldable > instance > >>>> is illegitimate by the law given above. > >>>> > >>>> I would suggest the law given is "morally" the right thing for > Foldable > >>>> -- a Foldable instance for `f` should suggest that it gives us "all > the as > >>>> in any `f a`", and so it is, in some particular restricted sense, > initial > >>>> among functions that extract as. > >>>> > >>>> I do not suggest we add this law right away. However, I would like to > >>>> suggest considering it, and I believe it (or a cleaned-up variant) > would > >>>> help us to see Foldable as a more legitimately lawful class that not > only > >>>> provides conveniences but can be used to aid reasoning. > >>>> > >>>> Relating this to adjointness, as I do in the IFL preprint, remains > >>>> future work. > >>>> > >>>> Cheers, > >>>> Gershom > >>>> > >>>> _______________________________________________ > >>>> Haskell-Cafe mailing list > >>>> Haskell-Cafe at haskell.org > >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>>> > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Thu Feb 12 22:22:28 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 13 Feb 2015 05:22:28 +0700 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: (removing Libraries, since not everyone on HC is on that list) I do not know all of the context of Foldable, but one I do know that's not been mentioned is the implicit rule-of-thumb that every type class should have a law. So the undercurrent is that if Foldable doesn't have a law, should it even be a type class? This has led to efforts to uncover laws for Foldable. Worth discussing in a separate thread is the criterion itself of "if it doesn't have a law, it's not a type class". Useful sometimes, but that's not the sine qua non of type classes. -- Kim-Ee On Fri, Feb 13, 2015 at 2:47 AM, Gershom B wrote: > For a long time, many people, including me, have said that "Foldable has > no laws" (or Foldable only has free laws) -- this is true, as it stands, > with the exception that Foldable has a non-free law in interaction with > Traversable (namely that it act as a proper specialization of Traversable > methods). However, I believe that there is a good law we can give for > Foldable. > > I earlier explored this in a paper presented at IFL 2014 but (rightfully) > rejected from the IFL post-proceedings. ( > http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of > the way there, but I believe now have a better approach on the question of > a Foldable law -- as sketched below. > > I think I now (unlike in the paper) can state a succinct law for Foldable > that has desired properties: 1) It is not "free" -- it can be violated, and > thus stating it adds semantic content. 2) We typically expect it to be > true. 3) There are no places where I can see an argument for violating it. > > If it pans out, I intend to pursue this and write it up more formally, but > given the current FTP discussion I thought it was worth documenting this > earlier rather than later. For simplicity, I will state this property in > terms of `toList` although that does not properly capture the infinite > cases. Apologies for what may be nonstandard notation. > > Here is the law I think we should discuss requiring: > > * * * > Given Foldable f, then > forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a --> > a `elem` toList x > * * * > > Since we do not require `a` to be of type `Eq`, note that the `elem` > function given here is not internal to Haskell, but in the metalogic. > > Furthermore, note that the use of parametricity here lets us make an "end > run" around the usual problem of giving laws to Foldable -- rather than > providing an interaction with another class, we provide a claim about _all_ > functions of a particular type. > > Also note that the functions `g` we intend to quantify over are functions > that _can be written_ -- so we can respect the property of data structures > to abstract over information. Consider > > data Funny a = Funny {hidden :: a, public :: [a]} > > instance Foldable Funny where > foldMap f x = foldMap f (public x) > > Now, if it is truly impossible to ever "see" hidden (i.e. it is not > exported, or only exported through a semantics-breaking "Internal" module), > then the Foldable instance is legitimate. Otherwise, the Foldable instance > is illegitimate by the law given above. > > I would suggest the law given is "morally" the right thing for Foldable -- > a Foldable instance for `f` should suggest that it gives us "all the as in > any `f a`", and so it is, in some particular restricted sense, initial > among functions that extract as. > > I do not suggest we add this law right away. However, I would like to > suggest considering it, and I believe it (or a cleaned-up variant) would > help us to see Foldable as a more legitimately lawful class that not only > provides conveniences but can be used to aid reasoning. > > Relating this to adjointness, as I do in the IFL preprint, remains future > work. > > Cheers, > Gershom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Feb 12 23:33:32 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 12 Feb 2015 18:33:32 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: With Foldable we *do* have a very nice law around foldMap. A monoid homomorphism g is a combinator such that g mempty = mempty g (mappend a b) = mappend (g a) (mappend (g b) For any monoid homomorphism g, foldMap (g . f) = g . foldMap f We can use that to construct proofs of an analogue to "the banana split theorem" for foldr, but rephrased in terms of foldMap: foldMap f &&& foldMap g = foldMap (f &&& g) Getting there uses the fact that fst and snd are both monoid homomorphisms. There are also laws relating the behavior of all of the other combinators in Foldable to foldMap. Ultimately the reasons for the other members of the class are a sop to efficiency concerns: asymptotic factors in terms of time or stack usage matter. -Edward On Thu, Feb 12, 2015 at 5:22 PM, Kim-Ee Yeoh wrote: > (removing Libraries, since not everyone on HC is on that list) > > I do not know all of the context of Foldable, but one I do know that's not > been mentioned is the implicit rule-of-thumb that every type class should > have a law. > > So the undercurrent is that if Foldable doesn't have a law, should it even > be a type class? This has led to efforts to uncover laws for Foldable. > > Worth discussing in a separate thread is the criterion itself of "if it > doesn't have a law, it's not a type class". Useful sometimes, but that's > not the sine qua non of type classes. > > > > -- Kim-Ee > > On Fri, Feb 13, 2015 at 2:47 AM, Gershom B wrote: > >> For a long time, many people, including me, have said that "Foldable has >> no laws" (or Foldable only has free laws) -- this is true, as it stands, >> with the exception that Foldable has a non-free law in interaction with >> Traversable (namely that it act as a proper specialization of Traversable >> methods). However, I believe that there is a good law we can give for >> Foldable. >> >> I earlier explored this in a paper presented at IFL 2014 but (rightfully) >> rejected from the IFL post-proceedings. ( >> http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of >> the way there, but I believe now have a better approach on the question of >> a Foldable law -- as sketched below. >> >> I think I now (unlike in the paper) can state a succinct law for Foldable >> that has desired properties: 1) It is not "free" -- it can be violated, and >> thus stating it adds semantic content. 2) We typically expect it to be >> true. 3) There are no places where I can see an argument for violating it. >> >> If it pans out, I intend to pursue this and write it up more formally, >> but given the current FTP discussion I thought it was worth documenting >> this earlier rather than later. For simplicity, I will state this property >> in terms of `toList` although that does not properly capture the infinite >> cases. Apologies for what may be nonstandard notation. >> >> Here is the law I think we should discuss requiring: >> >> * * * >> Given Foldable f, then >> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a >> --> a `elem` toList x >> * * * >> >> Since we do not require `a` to be of type `Eq`, note that the `elem` >> function given here is not internal to Haskell, but in the metalogic. >> >> Furthermore, note that the use of parametricity here lets us make an "end >> run" around the usual problem of giving laws to Foldable -- rather than >> providing an interaction with another class, we provide a claim about _all_ >> functions of a particular type. >> >> Also note that the functions `g` we intend to quantify over are functions >> that _can be written_ -- so we can respect the property of data structures >> to abstract over information. Consider >> >> data Funny a = Funny {hidden :: a, public :: [a]} >> >> instance Foldable Funny where >> foldMap f x = foldMap f (public x) >> >> Now, if it is truly impossible to ever "see" hidden (i.e. it is not >> exported, or only exported through a semantics-breaking "Internal" module), >> then the Foldable instance is legitimate. Otherwise, the Foldable instance >> is illegitimate by the law given above. >> >> I would suggest the law given is "morally" the right thing for Foldable >> -- a Foldable instance for `f` should suggest that it gives us "all the as >> in any `f a`", and so it is, in some particular restricted sense, initial >> among functions that extract as. >> >> I do not suggest we add this law right away. However, I would like to >> suggest considering it, and I believe it (or a cleaned-up variant) would >> help us to see Foldable as a more legitimately lawful class that not only >> provides conveniences but can be used to aid reasoning. >> >> Relating this to adjointness, as I do in the IFL preprint, remains future >> work. >> >> Cheers, >> Gershom >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Feb 13 00:19:03 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 13 Feb 2015 00:19:03 +0000 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: <20150213001903.GE13621@weber> On Thu, Feb 12, 2015 at 04:39:02PM -0500, Edward Kmett wrote: > And as been worked through to death in the past, Functor cannot be a > superclass of Foldable. ;) Because, for example, that wouldn't allow a Set to be Foldable. From david.feuer at gmail.com Fri Feb 13 02:29:52 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 12 Feb 2015 21:29:52 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: <20150213001903.GE13621@weber> References: <20150213001903.GE13621@weber> Message-ID: Someone must not have noticed the bit where I mentioned that proposing Functor f => Foldable f in order to avoid the GADT stuff would make everyone reject the idea. But to the extent that Gershom's law is a good idea (I'm very far from convinced, because no one's explained in a way that I can understand what makes it useful), it could by made a conditional law: only Functor instances would have to obey it, in much the same way that (of course) only Functor instances must obey foldMap f = fold . fmap f. On Thu, Feb 12, 2015 at 7:19 PM, Tom Ellis wrote: > On Thu, Feb 12, 2015 at 04:39:02PM -0500, Edward Kmett wrote: >> And as been worked through to death in the past, Functor cannot be a >> superclass of Foldable. ;) > > Because, for example, that wouldn't allow a Set to be Foldable. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries From ekmett at gmail.com Fri Feb 13 05:12:10 2015 From: ekmett at gmail.com (Edward Kmett) Date: Fri, 13 Feb 2015 00:12:10 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: <20150213001903.GE13621@weber> Message-ID: Gershom's law is an attempt to make rigorous and capture the notion that a Foldable should touch all of the a's in 'f a'. This is a property that Functor and Traversable both share, but which Foldable doesn't. The others are able to attain this property through parametricity. This would rule out the un-extendable `foldMap = mempty` cases, and capture the intuitive definition of what Foldable "does". -Edward On Thu, Feb 12, 2015 at 9:29 PM, David Feuer wrote: > Someone must not have noticed the bit where I mentioned that proposing > Functor f => Foldable f in order to avoid the GADT stuff would make > everyone reject the idea. But to the extent that Gershom's law is a > good idea (I'm very far from convinced, because no one's explained in > a way that I can understand what makes it useful), it could by made a > conditional law: only Functor instances would have to obey it, in much > the same way that (of course) only Functor instances must obey foldMap > f = fold . fmap f. > > On Thu, Feb 12, 2015 at 7:19 PM, Tom Ellis > wrote: > > On Thu, Feb 12, 2015 at 04:39:02PM -0500, Edward Kmett wrote: > >> And as been worked through to death in the past, Functor cannot be a > >> superclass of Foldable. ;) > > > > Because, for example, that wouldn't allow a Set to be Foldable. > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://www.haskell.org/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Feb 13 05:34:06 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 13 Feb 2015 00:34:06 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: <20150213001903.GE13621@weber> Message-ID: I can see how it captures a certain sort of intuition; what I can't see is how that helps you prove anything useful. I'm not saying it *doesn't*; I'm just saying I don't see how it does. On Fri, Feb 13, 2015 at 12:12 AM, Edward Kmett wrote: > Gershom's law is an attempt to make rigorous and capture the notion that a > Foldable should touch all of the a's in 'f a'. > > This is a property that Functor and Traversable both share, but which > Foldable doesn't. The others are able to attain this property through > parametricity. > > This would rule out the un-extendable `foldMap = mempty` cases, and capture > the intuitive definition of what Foldable "does". > > -Edward > > On Thu, Feb 12, 2015 at 9:29 PM, David Feuer wrote: >> >> Someone must not have noticed the bit where I mentioned that proposing >> Functor f => Foldable f in order to avoid the GADT stuff would make >> everyone reject the idea. But to the extent that Gershom's law is a >> good idea (I'm very far from convinced, because no one's explained in >> a way that I can understand what makes it useful), it could by made a >> conditional law: only Functor instances would have to obey it, in much >> the same way that (of course) only Functor instances must obey foldMap >> f = fold . fmap f. >> >> On Thu, Feb 12, 2015 at 7:19 PM, Tom Ellis >> wrote: >> > On Thu, Feb 12, 2015 at 04:39:02PM -0500, Edward Kmett wrote: >> >> And as been worked through to death in the past, Functor cannot be a >> >> superclass of Foldable. ;) >> > >> > Because, for example, that wouldn't allow a Set to be Foldable. >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://www.haskell.org/mailman/listinfo/libraries >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > > From psyzy3 at nottingham.ac.uk Fri Feb 13 12:00:39 2015 From: psyzy3 at nottingham.ac.uk (Zongzhe Yuan) Date: Fri, 13 Feb 2015 12:00:39 +0000 Subject: [Haskell-cafe] A Question about the IO type detection Message-ID: <79ED4F7F-1D3C-4978-B7EA-CE15582D7DB1@exmail.nottingham.ac.uk> Hi i meet a problem when i was using readLn to read a int from user my function is like that do (some thing else that is working) n <- readLn (some thing else) f n x1 x2 x3 ?? f has the type of Int -> something else because the type in this function is fixed, if the type of n is not Int, it will have exception However i want to detect whether the user input is valid or not and i have this function import Data.Typeable isInteger :: Typeable a => a -> Bool isInteger n = (typeOf n) == (typeOf (1::Int)) and add to do (some thing else that is working) n <- readLn if isInteger n then (some thing else) f n x1 x2 x3 ?? else (something else) but it doesn?t work because of the reason ?type has been inferred and fixed? How could i solve this problem? Zongzhe Yuan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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 raabe at froglogic.com Fri Feb 13 12:09:02 2015 From: raabe at froglogic.com (Frerich Raabe) Date: Fri, 13 Feb 2015 13:09:02 +0100 Subject: [Haskell-cafe] A Question about the IO type detection In-Reply-To: <79ED4F7F-1D3C-4978-B7EA-CE15582D7DB1@exmail.nottingham.ac.uk> References: <79ED4F7F-1D3C-4978-B7EA-CE15582D7DB1@exmail.nottingham.ac.uk> Message-ID: <92d6a61b315a77c1af7e235109d70c02@roundcube.froglogic.com> On 2015-02-13 13:00, Zongzhe Yuan wrote: > i meet a problem when i was using readLn to read a int from user > > my function is like that > > do (some thing else that is working) > n <- readLn > (some thing else) > f n x1 x2 x3 ?? > > f has the type of Int -> something else > because the type in this function is fixed, if the type of n is not Int, it > will have exception > However i want to detect whether the user input is valid or not [..] > How could i solve this problem? readLn is a bit harsh when it comes to error reporting. You could use getLine to read a string and then use readMaybe (in Text.Read) to see whether it's a valid integer. Like: main = do s <- getLine case readMaybe s :: Maybe Int of Just i -> f i Nothing -> putStrLn "Ouch!" -- Frerich Raabe - raabe at froglogic.com www.froglogic.com - Multi-Platform GUI Testing From fvillanustre at gmail.com Fri Feb 13 12:48:12 2015 From: fvillanustre at gmail.com (Flavio Villanustre) Date: Fri, 13 Feb 2015 07:48:12 -0500 Subject: [Haskell-cafe] example In-Reply-To: References: Message-ID: Marat, There are many ways to truly parallelize (and distribute) the execution of graph algorithms, but it largely depends on what you are trying to do with that graph. For example, if you are interested in graph traversal (find the shortest path from point A to point B in a DAG), and you want to reduce the runtime complexity of that path traversal algorithm to a simple O(log n) lookup (n being the number of nodes) so that you can efficiently perform many of these lookups in parallel in a graph that doesn't necessarily fit in RAM, you could: 1. represent the graph as an adjacency matrix; 2. multiply that square matrix by itself to obtain the matrix representing the next degree of separation (this can be done in parallel using Strassen, for example); 3. materialize those matrices as b-trees. Each b-tree will represent an association at x degrees of separation between nodes. If your graph adheres to a small world, you only need 4 of these matrices to traverse any path up to 8 degrees of separation Of course, this is for unlabeled associations. If your associations are typed, you'll need a tensor structure rather. Another option would be to use an adjacency list and just use relational join operations (also parallelizable) to perform the same task. Keep in mind that graphs are isomorphic to adjacency matrices and adjacency lists. The lookups themselves could also be performed in parallel. This is just an example, you could also calculate things like centrality and connectedness in parallel with a little ingenuity. I hope this helps, even though it's not Haskell specific, Flavio Flavio Villanustre On Thu, Feb 12, 2015 at 8:24 AM, ??????? ????? wrote: > Hi all, > > Algorithms on graphs in my opinion is something bad for parallel execution > (especially such of them which have O(n) comlexity). So if I haskell give > me an advantage in some graph application it will be great benchmark. > Recently I tried to think about well-known by compiler people - so called > "topologic-sort" or reverse post order numeration, but I gave up... There > are just nothing to execute in parallel. Currently I am searching for graph > (compiler) algorithm example written in haskell with persistent data > structures which can be executed in parallel. And in the same time this > example written in imperative style must not have good parallel execution > form. > > Summarizing: I want to find example of data_persistence&functional style > killer graph (compiler) application. > > Do you know such an example? > > -- > > *Regards, Marat.* > *? ????????? ?????.* > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Fri Feb 13 13:42:34 2015 From: P.Achten at cs.ru.nl (Peter Achten) Date: Fri, 13 Feb 2015 14:42:34 +0100 Subject: [Haskell-cafe] [TFP 2015] 2nd call for papers Message-ID: <54DDFF4A.3070406@cs.ru.nl> ----------------------------- S E C O N D C A L L F O R P A P E R S ----------------------------- ======== TFP 2015 =========== 16th Symposium on Trends in Functional Programming June 3-5, 2015 Inria Sophia Antipolis, France http://tfp2015.inria.fr/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. The selected revised papers will be published as a Springer Lecture Notes in Computer Science (www.springer.com/lncs) volume. TFP 2015 will be the main event of a pair of functional programming events. TFP 2015 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 2nd. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * and in Soesterberg (The Netherlands) in 2014. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/). == INVITED SPEAKER == TFP is pleased to announce a talk by the following invited speaker: * Laurence Rideau is a researcher at INRIA and is interested in the semantics of programming languages , the formal methods, and the verification tools for programs and mathematical proofs. She participated in the beginnings of the Compcert project (certified compiler), and is part of the Component Mathematical team in the MSR-INRIA joint laboratory, who performed the formalization of the Feit-Thompson theorem successfully. Thirty years ago, computers barged in mathematics with the famous proof of the Four Color Theorem. Initially limited to simple calculation, their role is now expanding to the reasoning whose complexity is beyond the capabilities of most humans, as the proof of the classification of finite simple groups. We present our large collaborative adventure around the formalization of the Feit-Thompson theorem (http://en.wikipedia.org/wiki/Feit%E2%80%93Thompson_theorem) that is a first step to the classification of finite groups and that uses a palette of methods and techniques that range from formal logic to software (and mathematics) engineering. == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2015 program chair, Manuel Serrano. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == SPONSORS == TFP is financially supported by == PAPER SUBMISSIONS == Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which ALL authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. Papers must be submitted at: https://easychair.org/conferences/?conf=tfp2015 Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site: http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0 == IMPORTANT DATES == Submission of draft papers: March 17, 2015 Notification: March 24, 2015 Registration: April 7, 2015 TFP Symposium: June 3-5, 2015 Student papers feedback: June 9, 2015 Submission for formal review: July 1, 2015 Notification of acceptance: September 8, 2015 Camera ready paper: October 8, 2015 == PROGRAM COMMITTEE == Janis Voigtl?nder University of Bonn, DE Scott Owens University of Kent, UK Neil Sculthorpe Swansea University, UK Colin Runciman University of York, UK Manuel Serrano Inria (PC chair), FR Rinus Plasmeijer University of Nijmegen, NL Tomas Petricek University of Cambridge, UK Marco T. Morazan Seton Hall University, USA Wolfgang De Meuter Vrije Universiteit Brussel, BE Michel Mauny Ensta ParisTech, FR Sam Lindley The University of Edinburgh, UK Daan Leijen Microsoft, USA Jurriaan Hage Utrecht University, NL Andy Gill University of Kansas, USA Thomas Gazagnaire University of Cambrige, UK Lars-Ake Fredlund Universidad Polit?cnica de Madrid, ES Jean-Christophe Filliatre Universit? Paris Sud Orsay, FR Marc Feeley Universit? de Montr?al, CA Olaf Chitil University of Kent, UK Edwin Brady University of St Andrews, UK From icfp.publicity at googlemail.com Fri Feb 13 16:28:24 2015 From: icfp.publicity at googlemail.com (David Van Horn) Date: Fri, 13 Feb 2015 11:28:24 -0500 Subject: [Haskell-cafe] ICFP 2015: Final Call for Papers Message-ID: ===================================================================== 20th ACM SIGPLAN International Conference on Functional Programming ICFP 2015 Vancouver, Canada, August 31 - September 2, 2015 http://www.icfpconference.org/icfp2015 ===================================================================== Important Dates ~~~~~~~~~~~~~~~ Submissions due: Friday, February 27 2015, 23:59 UTC-11 https://icfp15.hotcrp.com/ Author response: Tuesday, April 21, 2015 through Thursday, 23 April, 2015 Notification: Friday, May 1, 2015 Final copy due: Friday, June 12, 2015 Scope ~~~~~ ICFP 2015 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, and 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, concurrency, or parallelism. Topics of interest include (but are not limited to): * Language Design: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. * Implementation: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. * Analysis and Transformation: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. * Applications: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. * Education: teaching introductory programming; parallel programming; mathematical proof; algebra. * Functional Pearls: elegant, instructive, and fun essays on functional programming. * Experience Reports: short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working. If you are concerned about the appropriateness of some topic, do not hesitate to contact the program chair. Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * By Friday, 27 February 2015, 23:59 UTC-11, submit a full paper of at most 12 pages (6 pages for an Experience Report) in standard ACM conference format, including bibliography, figures, and appendices. The deadlines will be strictly enforced and papers exceeding the page limits will be summarily rejected. * Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. * Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication * Authors of resubmitted (but previously rejected) papers have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the program chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Overall, a submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Proceedings will be published by ACM Press. Authors of accepted submissions will have a choice of one of three ways to manage their publication rights. These choices are described at http://authors.acm.org/main.html Presentations will be videotaped and released online if the presenter consents. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LaTeX is available at http://www.sigplan.org/Resources/Author/ Submission: Submissions will be accepted on the web using a link that will be posted at https://icfp15.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 72-hour period, starting at 0:00 UTC on Tuesday, 21 April 2015, to read reviews and respond to them. ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking the definitive version of ACM article should reduce user confusion over article versioning. After your article has been published and assigned to your ACM Author Profile page, please visit http://www.acm.org/publications/acm-author-izer-service to learn how to create your links for free downloads from the ACM DL. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. General Chair: Kathleen Fisher Tufts University (USA) Program Chair: John Reppy University of Chicago (USA) Program Committee: Amal Ahmed Northeastern University (USA) Jean-Philippe Bernardy Chalmers University of Technology (Sweden) Matthias Blume Google (USA) William Byrd University of Utah (USA) Andy Gill University of Kansas (USA) Neal Glew Google (USA) Fritz Henglein University of Copenhagen (Denmark) Gabriele Keller University of New South Wales and NICTA (Australia) Andrew Kennedy Microsoft Research Cambridge (UK) Neelakantan Krishnaswami Birmingham University (UK) Daan Leijen Microsoft Research Redmond (USA) Keiko Nakata FireEye Dresden (Germany) Mike Rainey INRIA Rocquencourt (France) Andreas Rossberg Google (Germany) Manuel Serrano INRIA Sophia Antipolis (France) Simon Thompson University of Kent (UK) David Van Horn University of Maryland (USA) Stephanie Weirich University of Pennsylvania (USA) From agocorona at gmail.com Fri Feb 13 20:16:32 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri, 13 Feb 2015 21:16:32 +0100 Subject: [Haskell-cafe] Complex Event Processing in Haskell In-Reply-To: References: <20150205181135.GB29558@weber> Message-ID: Tom, This may be relevant for you: https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers#wait-for-events 2015-02-05 20:20 GMT+01:00 Alberto G. Corona : > Sorry. > > My cat passed over the keyboard. > > I was just creating a draft message just in case nobody answered you. > > I said that I'm developing something around this article: > > https://www.fpcomplete.com/user/agocorona/monad-reactive-programming-2 > > Of course it is not production ready .not even a package in Hackage is yet > available. That is the reason why I doubted to send this response. but the > cat has decided for me. > > I will publish an article soon more elaborated with the last things that I > have done. > > 2015-02-05 20:12 GMT+01:00 Alberto G. Corona : > >> I?m creating something around this >> >> >> 2015-02-05 19:11 GMT+01:00 Tom Ellis < >> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: >> >>> I'm looking for examples of production-capable Complex Event Processing >>> systems in Haskell along the lines of Esper: >>> >>> http://esper.codehaus.org/ >>> >>> I know of Nettle (and McNettle and Procera) from Yale, and it claims to >>> have >>> excellent performance. >>> >>> http://haskell.cs.yale.edu/nettle/ >>> >>> Is there anything else? Is there anything in another functional >>> language I >>> should look at? I know FRP systems in general deal with processing >>> events, >>> but I am looking specifically for things similar to Esper. >>> >>> Tom >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> >> >> -- >> Alberto. >> > > > > -- > Alberto. > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Fri Feb 13 21:32:27 2015 From: chrisdone at gmail.com (Christopher Done) Date: Fri, 13 Feb 2015 22:32:27 +0100 Subject: [Haskell-cafe] Why doesn't TH expose its parser? Message-ID: What's the reason that there isn't a parseExp :: String -> Q Exp, parseDecl, etc.? It's a pretty common use case to write some syntactic extension that merely extends regular Haskell. We end up with the haskell-src-meta package which doesn't support full GHC Haskell and doesn't know how to parse infix applications. It doesn't give a strong story for quasi-quotes to be useful for extensions to Haskell's syntax itself, as opposed to just mini-DSLs. Here's a case in point: idiom brackets. You'd like to implement them like this: [i|foo bar mu|] ? foo <$> bar <*> mu You want it to be full Haskell inside, so foo could easilly be a case or a let, etc., so a trivial way to do that would be to just parse the string "foo bar mu" with parseExp and then do the above simple transformation. Job done. In practice, we can't do this. Our best option is HSE, but it's not ideal. Another way to do this is: $(idiom [|foo bar mu|]) And because [|?|] produces a Q Exp, you can just go ahead and do the rewrite on the resulting Exp. Yay, we now have full GHC Haskell inside the idiom bracket, but we've lost the syntactic convenience. Given that [|?|] already does the String ? Q Exp step, why not allow us to re-use this functionality in quasi quotes? Ciao! From simonpj at microsoft.com Fri Feb 13 22:36:32 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 13 Feb 2015 22:36:32 +0000 Subject: [Haskell-cafe] Why doesn't TH expose its parser? In-Reply-To: References: Message-ID: <618BE556AADD624C9C918AA5D5911BEF562C9B06@DB3PRD3001MB020.064d.mgd.msft.net> | What's the reason that there isn't a parseExp :: String -> Q Exp, | parseDecl, etc.? Good idea! I don't think it'd be too hard. The parser (in parser/Parser.y) already exposes parseExpression, parseDeclaration etc. But they generate HsSyn and we need TH syntax. We don?t currently have a way to do that. It's (B) in https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Conversions So there's some refactoring work to do here. Fiddly but not hard. Simon | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of | Christopher Done | Sent: 13 February 2015 21:32 | To: Haskell Cafe | Subject: [Haskell-cafe] Why doesn't TH expose its parser? | | What's the reason that there isn't a parseExp :: String -> Q Exp, | parseDecl, etc.? | | It's a pretty common use case to write some syntactic extension that | merely extends regular Haskell. We end up with the haskell-src-meta | package which doesn't support full GHC Haskell and doesn't know how to | parse infix applications. It doesn't give a strong story for | quasi-quotes to be useful for extensions to Haskell's syntax itself, | as opposed to just mini-DSLs. | | Here's a case in point: idiom brackets. You'd like to implement them like | this: | | [i|foo bar mu|] ? foo <$> bar <*> mu | | You want it to be full Haskell inside, so foo could easilly be a case | or a let, etc., so a trivial way to do that would be to just parse the | string "foo bar mu" with parseExp and then do the above simple | transformation. Job done. | | In practice, we can't do this. Our best option is HSE, but it's not | ideal. Another way to do this is: | | $(idiom [|foo bar mu|]) | | And because [|?|] produces a Q Exp, you can just go ahead and do the | rewrite on the resulting Exp. Yay, we now have full GHC Haskell inside | the idiom bracket, but we've lost the syntactic convenience. Given | that [|?|] already does the String ? Q Exp step, why not allow us to | re-use this functionality in quasi quotes? | | Ciao! | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe at haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe From chrisdone at gmail.com Fri Feb 13 23:18:34 2015 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 14 Feb 2015 00:18:34 +0100 Subject: [Haskell-cafe] Why doesn't TH expose its parser? In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF562C9B06@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF562C9B06@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: On 13 February 2015 at 23:36, Simon Peyton Jones wrote: > | What's the reason that there isn't a parseExp :: String -> Q Exp, > | parseDecl, etc.? > > Good idea! I don't think it'd be too hard. The parser (in parser/Parser.y) already exposes parseExpression, parseDeclaration etc. But they generate HsSyn and we need TH syntax. We don?t currently have a way to do that. It's (B) in https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Conversions > > So there's some refactoring work to do here. Fiddly but not hard. Awesome! I wasn't sure whether I wasn't taking into account a subtle stage restriction problem somehow. Nice diagram. :-) I'm looking at the TH implementation to see whether this is something I can reasonably tackle. Cheers! From chrisdone at gmail.com Fri Feb 13 23:31:32 2015 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 14 Feb 2015 00:31:32 +0100 Subject: [Haskell-cafe] Why doesn't TH expose its parser? In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF562C9B06@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: It appears my information is out of date on at least haskell-src-meta and would be misleading to others if I didn't correct it: since GHC 7.4 haskell-src-meta can now leave infix applications ambiguous and allow GHC to resolve them: http://hackage.haskell.org/package/haskell-src-meta-0.6.0.8/docs/Language-Haskell-Meta-Parse-Careful.html The problem of dealing with infix applications remains in your quasi quoter remains, of course. But that's a handy improvement. From redneb8888 at gmail.com Sat Feb 14 00:31:40 2015 From: redneb8888 at gmail.com (Marios Titas) Date: Sat, 14 Feb 2015 00:31:40 +0000 Subject: [Haskell-cafe] Is there a cross platform CA certificate bundle solution for HsOpenSSL? Message-ID: If I want to use HsOpenSSL for a tls client application that verifies the server certificate I have to manually specify a CA certificate bundle containing the trusted roots. For example, in a linux system, I would do the following mkTlsContext :: IO Context mkTlsContext = do ctx <- context contextSetVerificationMode ctx (VerifyPeer True False Nothing) contextSetCADirectory ctx "/etc/ssl/certs" return ctx The problem is that the above solution only works for linux. Is there a cross-platform way to find a reasonable CA bundle and use it with HsOpenSSL? Note that the tls package has x509-system [1] that does exactly that. So I am basically asking if anybody has written something similar for HsOpenSSL. [1] https://hackage.haskell.org/package/x509-system From hasufell at posteo.de Sat Feb 14 02:20:39 2015 From: hasufell at posteo.de (Julian Ospald) Date: Sat, 14 Feb 2015 02:20:39 +0000 Subject: [Haskell-cafe] Is there a cross platform CA certificate bundle solution for HsOpenSSL? In-Reply-To: References: Message-ID: <54DEB0F7.9060903@posteo.de> Marios Titas: > If I want to use HsOpenSSL for a tls client application that verifies > the server certificate I have to manually specify a CA certificate > bundle containing the trusted roots. For example, in a linux system, I > would do the following > > mkTlsContext :: IO Context > mkTlsContext = do > ctx <- context > contextSetVerificationMode ctx (VerifyPeer True False Nothing) > contextSetCADirectory ctx "/etc/ssl/certs" > return ctx > > The problem is that the above solution only works for linux. Is there > a cross-platform way to find a reasonable CA bundle and use it with > HsOpenSSL? > > Note that the tls package has x509-system [1] that does exactly that. > So I am basically asking if anybody has written something similar for > HsOpenSSL. > > [1] https://hackage.haskell.org/package/x509-system You shouldn't have to manually specify it. There is the function SSL_CTX_set_default_verify_paths() which sets default directories for the CAfile and CApath which are configured during compile-time of openssl. Unfortunately, some distributions don't really follow these standard paths, but that's your first bet. You might find this link interesting too: https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ But from what I see... HsOpenSSL lacks this function. Unless I missed something, I'd call that a bug. From vogt.adam at gmail.com Sat Feb 14 04:44:50 2015 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 13 Feb 2015 23:44:50 -0500 Subject: [Haskell-cafe] Rationale for two separate map functions in ClassyPrelude In-Reply-To: References: Message-ID: Hi Clinton, I think the problem is that the instance: > instance (Functor f) => CanMap (f a) b is overlapped by instances for containers that take a parameter but are not instances of Functor. For example: > instance (Unbox a, Unbox b) => CanMap (Data.Vector.Unboxed.Vector a) b Using {-# LANGUAGE OverlappingInstances #-} is a big deal for some people. Regards, Adam On Wed, Feb 11, 2015 at 2:00 PM, Clinton Mead wrote: > ClassyPrelude has two map functions, namely: > > 1. "map" > 2. "omap" > > "map" works on any Functor. However, things like "Text" are not functors as > they aren't generic containers. As can be seen in the following code: > > module Main where > import Prelude () > import ClassyPrelude > import qualified Data.Text as T > import Data.Char as C > > main = do > let l = [1,2,3] :: [Int] > let t = (T.pack "Hello") > let m = Just 5 > print $ map (*2) l > print $ map (*2) m > print $ omap C.toUpper t > return () > > > Notice one has to use "omap" to deal with the Text. The thing is, I found it > trivially easy to get "map" to work for both calls. Here's the code: > > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies #-} > > module Main where > import Prelude hiding (map) > import qualified Data.Text as T > import Data.Char as C > import Control.Monad (Functor) > > class CanMap a b where > type Element a :: * > type Container a b :: * > map :: (Element a -> b) -> a -> Container a b > > instance (Functor f) => CanMap (f a) b where > type Element (f a) = a > type Container (f a) b = f b > map = fmap > > instance CanMap T.Text Char where > type Element T.Text = Char > type Container T.Text Char = T.Text > map = T.map > > main = do > let l = [1,2,3] :: [Int] > let m = Just 5 > let t = (T.pack "Hello") > print $ map (*2) l > print $ map (*2) m > print $ map C.toUpper t > return () > > > All that's required is to add instances to CanMap for any monomorphic > containers. ClassyPrelude already does this anyway with "omap" in the > Data.MonoTraversable module. I suspect however there's a good reason I'm > missing about why there should be two separate map functions to deal with > these alternate situations, but I'm wondering what that is. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From amos.robinson at gmail.com Sat Feb 14 04:52:14 2015 From: amos.robinson at gmail.com (Amos Robinson) Date: Sat, 14 Feb 2015 04:52:14 +0000 Subject: [Haskell-cafe] Rationale for two separate map functions in ClassyPrelude References: Message-ID: I feel a bit silly, but could you explain to me where the overlap is here? On Sat Feb 14 2015 at 3:45:30 PM adam vogt wrote: > Hi Clinton, > > I think the problem is that the instance: > > > instance (Functor f) => CanMap (f a) b > > is overlapped by instances for containers that take a parameter but > are not instances of Functor. For example: > > > instance (Unbox a, Unbox b) => CanMap (Data.Vector.Unboxed.Vector a) b > > Using {-# LANGUAGE OverlappingInstances #-} is a big deal for some people. > > Regards, > Adam > > On Wed, Feb 11, 2015 at 2:00 PM, Clinton Mead > wrote: > > ClassyPrelude has two map functions, namely: > > > > 1. "map" > > 2. "omap" > > > > "map" works on any Functor. However, things like "Text" are not functors > as > > they aren't generic containers. As can be seen in the following code: > > > > module Main where > > import Prelude () > > import ClassyPrelude > > import qualified Data.Text as T > > import Data.Char as C > > > > main = do > > let l = [1,2,3] :: [Int] > > let t = (T.pack "Hello") > > let m = Just 5 > > print $ map (*2) l > > print $ map (*2) m > > print $ omap C.toUpper t > > return () > > > > > > Notice one has to use "omap" to deal with the Text. The thing is, I > found it > > trivially easy to get "map" to work for both calls. Here's the code: > > > > {-# LANGUAGE MultiParamTypeClasses #-} > > {-# LANGUAGE TypeFamilies #-} > > > > module Main where > > import Prelude hiding (map) > > import qualified Data.Text as T > > import Data.Char as C > > import Control.Monad (Functor) > > > > class CanMap a b where > > type Element a :: * > > type Container a b :: * > > map :: (Element a -> b) -> a -> Container a b > > > > instance (Functor f) => CanMap (f a) b where > > type Element (f a) = a > > type Container (f a) b = f b > > map = fmap > > > > instance CanMap T.Text Char where > > type Element T.Text = Char > > type Container T.Text Char = T.Text > > map = T.map > > > > main = do > > let l = [1,2,3] :: [Int] > > let m = Just 5 > > let t = (T.pack "Hello") > > print $ map (*2) l > > print $ map (*2) m > > print $ map C.toUpper t > > return () > > > > > > All that's required is to add instances to CanMap for any monomorphic > > containers. ClassyPrelude already does this anyway with "omap" in the > > Data.MonoTraversable module. I suspect however there's a good reason I'm > > missing about why there should be two separate map functions to deal with > > these alternate situations, but I'm wondering what that is. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Sat Feb 14 04:55:30 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 13 Feb 2015 22:55:30 -0600 Subject: [Haskell-cafe] HaskBoard? Message-ID: I asked about running GHCI on something like the Arduino due, and was told that there wasn't enough CPU on it for that. How about getting it running on something like a PyBoard? http://www.adafruit.com/products/2390 -------------- next part -------------- An HTML attachment was scrubbed... URL: From amos.robinson at gmail.com Sat Feb 14 05:07:10 2015 From: amos.robinson at gmail.com (Amos Robinson) Date: Sat, 14 Feb 2015 05:07:10 +0000 Subject: [Haskell-cafe] Rationale for two separate map functions in ClassyPrelude References: Message-ID: Sorry, I just reread the user guide and it makes sense. That's a shame - this had me excited. On Sat Feb 14 2015 at 3:52:12 PM Amos Robinson wrote: > I feel a bit silly, but could you explain to me where the overlap is here? > > On Sat Feb 14 2015 at 3:45:30 PM adam vogt wrote: > >> Hi Clinton, >> >> I think the problem is that the instance: >> >> > instance (Functor f) => CanMap (f a) b >> >> is overlapped by instances for containers that take a parameter but >> are not instances of Functor. For example: >> >> > instance (Unbox a, Unbox b) => CanMap (Data.Vector.Unboxed.Vector a) b >> >> Using {-# LANGUAGE OverlappingInstances #-} is a big deal for some people. >> >> Regards, >> Adam >> >> On Wed, Feb 11, 2015 at 2:00 PM, Clinton Mead >> wrote: >> > ClassyPrelude has two map functions, namely: >> > >> > 1. "map" >> > 2. "omap" >> > >> > "map" works on any Functor. However, things like "Text" are not >> functors as >> > they aren't generic containers. As can be seen in the following code: >> > >> > module Main where >> > import Prelude () >> > import ClassyPrelude >> > import qualified Data.Text as T >> > import Data.Char as C >> > >> > main = do >> > let l = [1,2,3] :: [Int] >> > let t = (T.pack "Hello") >> > let m = Just 5 >> > print $ map (*2) l >> > print $ map (*2) m >> > print $ omap C.toUpper t >> > return () >> > >> > >> > Notice one has to use "omap" to deal with the Text. The thing is, I >> found it >> > trivially easy to get "map" to work for both calls. Here's the code: >> > >> > {-# LANGUAGE MultiParamTypeClasses #-} >> > {-# LANGUAGE TypeFamilies #-} >> > >> > module Main where >> > import Prelude hiding (map) >> > import qualified Data.Text as T >> > import Data.Char as C >> > import Control.Monad (Functor) >> > >> > class CanMap a b where >> > type Element a :: * >> > type Container a b :: * >> > map :: (Element a -> b) -> a -> Container a b >> > >> > instance (Functor f) => CanMap (f a) b where >> > type Element (f a) = a >> > type Container (f a) b = f b >> > map = fmap >> > >> > instance CanMap T.Text Char where >> > type Element T.Text = Char >> > type Container T.Text Char = T.Text >> > map = T.map >> > >> > main = do >> > let l = [1,2,3] :: [Int] >> > let m = Just 5 >> > let t = (T.pack "Hello") >> > print $ map (*2) l >> > print $ map (*2) m >> > print $ map C.toUpper t >> > return () >> > >> > >> > All that's required is to add instances to CanMap for any monomorphic >> > containers. ClassyPrelude already does this anyway with "omap" in the >> > Data.MonoTraversable module. I suspect however there's a good reason I'm >> > missing about why there should be two separate map functions to deal >> with >> > these alternate situations, but I'm wondering what that is. >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Sat Feb 14 07:10:59 2015 From: vogt.adam at gmail.com (adam vogt) Date: Sat, 14 Feb 2015 02:10:59 -0500 Subject: [Haskell-cafe] Rationale for two separate map functions in ClassyPrelude In-Reply-To: References: Message-ID: Well Unboxed.Vector can have an instance of CanMap if we use -XOverlappingInstances, (see https://gist.github.com/aavogt/f64db5678181307bebb9). Unfortunately I had to use functional dependencies, since associated type families can't overlap. On Sat, Feb 14, 2015 at 12:07 AM, Amos Robinson wrote: > Sorry, I just reread the user guide and it makes sense. That's a shame - > this had me excited. > > On Sat Feb 14 2015 at 3:52:12 PM Amos Robinson > wrote: >> >> I feel a bit silly, but could you explain to me where the overlap is here? >> >> On Sat Feb 14 2015 at 3:45:30 PM adam vogt wrote: >>> >>> Hi Clinton, >>> >>> I think the problem is that the instance: >>> >>> > instance (Functor f) => CanMap (f a) b >>> >>> is overlapped by instances for containers that take a parameter but >>> are not instances of Functor. For example: >>> >>> > instance (Unbox a, Unbox b) => CanMap (Data.Vector.Unboxed.Vector a) b >>> >>> Using {-# LANGUAGE OverlappingInstances #-} is a big deal for some >>> people. >>> >>> Regards, >>> Adam >>> >>> On Wed, Feb 11, 2015 at 2:00 PM, Clinton Mead >>> wrote: >>> > ClassyPrelude has two map functions, namely: >>> > >>> > 1. "map" >>> > 2. "omap" >>> > >>> > "map" works on any Functor. However, things like "Text" are not >>> > functors as >>> > they aren't generic containers. As can be seen in the following code: >>> > >>> > module Main where >>> > import Prelude () >>> > import ClassyPrelude >>> > import qualified Data.Text as T >>> > import Data.Char as C >>> > >>> > main = do >>> > let l = [1,2,3] :: [Int] >>> > let t = (T.pack "Hello") >>> > let m = Just 5 >>> > print $ map (*2) l >>> > print $ map (*2) m >>> > print $ omap C.toUpper t >>> > return () >>> > >>> > >>> > Notice one has to use "omap" to deal with the Text. The thing is, I >>> > found it >>> > trivially easy to get "map" to work for both calls. Here's the code: >>> > >>> > {-# LANGUAGE MultiParamTypeClasses #-} >>> > {-# LANGUAGE TypeFamilies #-} >>> > >>> > module Main where >>> > import Prelude hiding (map) >>> > import qualified Data.Text as T >>> > import Data.Char as C >>> > import Control.Monad (Functor) >>> > >>> > class CanMap a b where >>> > type Element a :: * >>> > type Container a b :: * >>> > map :: (Element a -> b) -> a -> Container a b >>> > >>> > instance (Functor f) => CanMap (f a) b where >>> > type Element (f a) = a >>> > type Container (f a) b = f b >>> > map = fmap >>> > >>> > instance CanMap T.Text Char where >>> > type Element T.Text = Char >>> > type Container T.Text Char = T.Text >>> > map = T.map >>> > >>> > main = do >>> > let l = [1,2,3] :: [Int] >>> > let m = Just 5 >>> > let t = (T.pack "Hello") >>> > print $ map (*2) l >>> > print $ map (*2) m >>> > print $ map C.toUpper t >>> > return () >>> > >>> > >>> > All that's required is to add instances to CanMap for any monomorphic >>> > containers. ClassyPrelude already does this anyway with "omap" in the >>> > Data.MonoTraversable module. I suspect however there's a good reason >>> > I'm >>> > missing about why there should be two separate map functions to deal >>> > with >>> > these alternate situations, but I'm wondering what that is. >>> > >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > Haskell-Cafe at haskell.org >>> > http://www.haskell.org/mailman/listinfo/haskell-cafe >>> > >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe From stephen.tetley at gmail.com Sat Feb 14 08:45:56 2015 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat, 14 Feb 2015 08:45:56 +0000 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: References: Message-ID: The spec sheet says MicroPython runs on bare metal on the PyBoard. It would be a lot of effort to make GHCi or even Hugs/Gofer do the same. As the price point for the PyBoard is the same as Raspberry PI, such an effort would perhaps be headstrong rather than sensible. On 14 February 2015 at 04:55, Mike Meyer wrote: > I asked about running GHCI on something like the Arduino due, and was told > that there wasn't enough CPU on it for that. > > How about getting it running on something like a PyBoard? > http://www.adafruit.com/products/2390 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From ky3 at atamo.com Sat Feb 14 13:56:57 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sat, 14 Feb 2015 20:56:57 +0700 Subject: [Haskell-cafe] Changes to Haskell Weekly News: In with the Old, In with the New Message-ID: Dear Reader, A few days ago Daniel Santa Cruz stepped down from the helm of Haskell Weekly News. With others that read HWN regularly, I thank him for his long service and wish him and his family godspeed. Did you know John Goerzen started HWN in August 2, 2005? Now a week from today, February 21, 2015, Simon and Simon shall close your window of opportunity to opine on drastic changes to the prelude. By sheer coincidence, the very first issue of HWN links to a thread on Updating the Haskell Standard. John himself started the thread. Today the talk is about the Foldable and Traversable type classes. Back then it was about Overlapping and Undecidable instances, the FFI, and a Hierarchical namespace. But these are all features we take for granted today. What sweeping changes took hold over the last ten years. There was no hackage. Only in September 2005 did Isaac Jones and David Himmelstrup announce beta-testing of a cabal prototype. Imagine life without hackage. Today there are 7664 packages all ready to go. So it is with this ladened awareness that I have volunteered and been accepted to the open vacancy at HWN. I seek to alleviate a sorely felt void in the Haskell diaspora by elucidating the newsworthy. The first decision I made might catch you by surprise, so let me explain. You see, Semen Trygubenko has also stepped up to contribute to HWN by continuing the leaderboard format pioneered by Daniel. I proposed and he agreed to alternate weeks between HWN Leaderboard and HWN Light. I'm excited by this dual format. Lower frequency means longer wavelength, which also means looking at events from a wider angle. At the same time the dual format affords continuity from past editions that a readership has grown accustomed to. Even though some readers will be mortified by the loss in uniformity, I trust you won't be among them. I take full responsibility for any untowardness caused by this to-ing and fro-ing, including innocent kittens mysteriously vanishing into the night. The Light edition will come out this Tuesday; the Leaderboard edition next. Thank you for reading Haskell Weekly News. >From the desk of Poobah of HWN, Kim-Ee Yeoh -------------- next part -------------- An HTML attachment was scrubbed... URL: From redneb8888 at gmail.com Sat Feb 14 14:23:57 2015 From: redneb8888 at gmail.com (Marios Titas) Date: Sat, 14 Feb 2015 14:23:57 +0000 Subject: [Haskell-cafe] Is there a cross platform CA certificate bundle solution for HsOpenSSL? In-Reply-To: <54DEB0F7.9060903@posteo.de> References: <54DEB0F7.9060903@posteo.de> Message-ID: Hi Thanks for the response. My problem is that this would probably not work under windows as there is no CA bundle in PEM format somewhere in the file system if I am not mistaken. Instead, I think you have to call CertOpenSystemStore to get the certificates and then parse them and add them one by one to the openssl context (see [1]). This is also what x509-system does for the tls package. So I was hoping that someone had done that already. Another solution is to have package that provides its own certificate bundle. For example, in perl they have Mozilla::CA [2] which provides a copy of the certificate bundle from firefox. Or maybe there is some other cross-platform solution that I am missing. [1] https://stackoverflow.com/a/19612161 [2] http://search.cpan.org/perldoc?Mozilla%3A%3ACA On Sat, Feb 14, 2015 at 2:20 AM, Julian Ospald wrote: > Marios Titas: >> If I want to use HsOpenSSL for a tls client application that verifies >> the server certificate I have to manually specify a CA certificate >> bundle containing the trusted roots. For example, in a linux system, I >> would do the following >> >> mkTlsContext :: IO Context >> mkTlsContext = do >> ctx <- context >> contextSetVerificationMode ctx (VerifyPeer True False Nothing) >> contextSetCADirectory ctx "/etc/ssl/certs" >> return ctx >> >> The problem is that the above solution only works for linux. Is there >> a cross-platform way to find a reasonable CA bundle and use it with >> HsOpenSSL? >> >> Note that the tls package has x509-system [1] that does exactly that. >> So I am basically asking if anybody has written something similar for >> HsOpenSSL. >> >> [1] https://hackage.haskell.org/package/x509-system > > > You shouldn't have to manually specify it. > > There is the function SSL_CTX_set_default_verify_paths() which sets > default directories for the CAfile and CApath which are configured > during compile-time of openssl. > > Unfortunately, some distributions don't really follow these standard > paths, but that's your first bet. > > You might find this link interesting too: > https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ > > But from what I see... HsOpenSSL lacks this function. Unless I missed > something, I'd call that a bug. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From gleber.p at gmail.com Sat Feb 14 20:15:58 2015 From: gleber.p at gmail.com (Gleb Peregud) Date: Sat, 14 Feb 2015 21:15:58 +0100 Subject: [Haskell-cafe] ANN: ZuriHac 2015 Message-ID: We am glad to announce ZuriHac 2015, a annual three-day Haskell hackathon in Zurich. This year it's sponsored by Google. When: May 29th - May 31st Where: Google office, Zurich, Switzerland ZuriHac is an international Haskell hackathon: a grassroots, collaborative coding festival with a simple focus, to build and improve Haskell libraries, tools, and infrastructure. This is a great opportunity to meet your fellow Haskellers in real life, find new contributors for your project, improve existing libraries and tools, or even start new ones! I am happy to announce that Edward Kmett will give a talk. We are still in progress of nailing down the details, they will be available at the wiki page: http://www.haskell.org/haskellwiki/ZuriHac2015 Registration is not yet open, we will send an additional announcement email when it's open. We look forward to seeing you there! -- The organisers of ZuriHac 2015 Gleb Peregud Simon Meier Johan Tibell Alexander Bernauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Sat Feb 14 21:36:09 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sun, 15 Feb 2015 00:36:09 +0300 Subject: [Haskell-cafe] Exception safe resource management with dynamic regions, call for review Message-ID: <1423949769.2918.33.camel@gmail.com> Hello, I'm asking for code and design review for `io-region` library. It is already on Hackage for convenience and easy access to haddock: https://hackage.haskell.org/package/io-region Manual exception handling in Haskell almost never is a good idea, except probably trivial cases where `bracket` is enough. A number of special libraries where created to help with exception handling. `io-regions` is one of them. Initially it was an attempt to solve the double-throw issue, but I found it unsolvable in library without changes in language itself. So now it is an attempt to design easy to use API with a bit different set of trade-offs. The library is based on idea of regions that own resources. The resources are released when the region is closed. Early releasing and ownership transferring are supported. Types are *not* used to prevent use-after-free errors. The API is not monadic, and it is the biggest difference from other libraries. Regions are first-class citizens, so you can manipulate them, pass as arguments to functions, send to other thread, store in data types. Such flexibility has its cost -- a bit more manual management. The implementation is based on STM and is thread safe, that allows e.g. atomic ownership transferring between threads. The nearest competitor I think is `resourset` package, and I still recommend it by default. Though I convinced myself that `io-region` is good enough, and I'm using it in productions (for two weeks already :) ) Thanks, Yuras From sumit.sahrawat.apm13 at iitbhu.ac.in Sun Feb 15 01:54:28 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Sun, 15 Feb 2015 07:24:28 +0530 Subject: [Haskell-cafe] Code review. API Guidance. Message-ID: Hello everyone. I have an application (a calculator repl [1]) and I'm looking to convert it into an package that provides both library and executable. I'm looking for suggestions for what might be a good API for such a library. I'm not looking for an extended code review, just the placement of functions in modules, and which functions to export. The current source tree looks like this. src/ $ tree . . ??? Calculator ? ??? Color.hs -- Colored output ? ??? Evaluator ? ? ??? Base.hs -- Common evaluation functions ? ? ??? Cmd.hs -- Evaluate special commands ? ? ??? Expr.hs -- Expression evaluation ? ? ??? Func.hs -- Convert specification for a function into a mathematical function ? ? ??? Statement.hs -- Evaluate either expression or command ? ??? Help.hs -- Help message ? ??? Parser ? ? ??? Base.hs -- Common parsers, number, id etc. ? ? ??? Cmd.hs ? ? ??? Expr.hs ? ? ??? Statement.hs ? ??? Prim -- Primitives ? ??? Bindings.hs -- Variable and Function Bindings ? ??? Cmd.hs ? ??? Definitions.hs -- Basic definitions, pre-defined variables and functions etc. ? ??? Expr.hs ? ??? Function.hs -- Tried to formalize the notion of a function of multiple arguments without currying. ? ??? Statement.hs ??? Main.hs ??? Model ??? Arithmetic.hs -- A calculator model built using Text.ParserCombinators.Parsec.Expr (for model testing) I'm trying to have a library because I want to use a lot of the functionality provided by calculator in plot-lab [2], which is a plotting application. I want to have a stable API, because I don't want to irresponsibly keep changing it according to my personal needs. [1] : https://github.com/sumitsahrawat/calculator [2] : https://github.com/sumitsahrawat/plot-lab -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sun Feb 15 07:50:07 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 15 Feb 2015 02:50:07 -0500 Subject: [Haskell-cafe] ANN: New Haskell.org Homepage Now Live Message-ID: I?m pleased to announce that http://www.haskell.org has received its first significant design update since 2010! More significantly, for the first time since 2006 it is not a wiki, but an actual language homepage. More significantly still, for the first time ever, the Haskell homepage now runs on a fully Haskell-powered stack. I suppose some people might also be interested in the fact that it looks quite nice, and has significantly cleaned up the information it presents, so as to provide a more focused experience for newcomers looking to explore the language. The page is now includes the collective work of over 230 commits by 17 contributors. First and foremost among those is Chris Done, who conceived the vision, wrote the bulk of the code, and executed the design. Also thanks to our many admins, including Austin Seipp, Ricky Elrod, et al., who managed the deployment, and have been working behind the scenes to continue to modernize and update our creaking infrastructure. Onto a few key things to remember: ? * The wiki is still around at https://wiki.haskell.org and it is still a fantastic resource. It is now speedy again, and we have an account creation process. By all means, jump in, and help curate and cultivate its wealth of knowledge. ? * The new site is all on github:?https://github.com/haskell-infra/hl ? there you will also find an issue tracker as well. We are sure there are many gaffes, gaps, and oddities that remain to be patched up in the site, especially with regards to its content. Tickets, pull requests, and comments are encouraged. ? * The official home for our mailinglists is now http://mail.haskell.org ? hopefully this will cause no problems or confusion, and the redirects should be in place properly. Please let us know if there are any issues. ? * We think we covered everything, but there is the possibility that some item, service, or redirect broke in the course of this transition. Please let us know if this is the case. ? * If you have been responsible for some subdirectory under the www.haskell.org banner, then you will find that you do not yet have an account on the new server. Please contact us and we?ll get you set up to continue to maintain that portion of the site. ? * As always, you can reach the haskell ops and admin team at admin at haskell.org, or on freenode irc at #haskell-infrastructure. Regards, Gershom (and also the Haskell.org Committee and Haskell.org Admin Team) From lemming at henning-thielemann.de Sun Feb 15 09:28:06 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 15 Feb 2015 10:28:06 +0100 (CET) Subject: [Haskell-cafe] [Haskell] ANN: New Haskell.org Homepage Now Live In-Reply-To: References: Message-ID: On Sun, 15 Feb 2015, Gershom B wrote: > Onto a few key things to remember: > > ? * The wiki is still around at https://wiki.haskell.org and it is still > a fantastic resource. It is now speedy again, and we have an account > creation process. By all means, jump in, and help curate and cultivate > its wealth of knowledge. I like the new wiki subdomain which is much more handy than the HaskellWiki subdirectory. How can I add events to the table in the future? Unfortunately, in my browser the Twitter headlines on the left overlap with the Events on the right: https://www.haskell.org/news > ? * The official home for our mailinglists is now > http://mail.haskell.org ? hopefully this will cause no problems or > confusion, and the redirects should be in place properly. Please let us > know if there are any issues. I would prefer if the links in the Haskell News go to haskell.org/pipermail (or mail.haskell.org) and not to googlegroups. The latter one requires JavaScript. I would also prefer if the "click to expand" links on the front page were links to separate articles. We preach stateless programming to the rest of the programming world and then the homepage content should be preferably stateless as well, shouldn't it? Practically I want to send people URLs and not explain them a sequence of clicks to tell them what text I am talking about. From lemming at henning-thielemann.de Sun Feb 15 09:29:51 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 15 Feb 2015 10:29:51 +0100 (CET) Subject: [Haskell-cafe] [Haskell] ANN: New Haskell.org Homepage Now Live In-Reply-To: References: Message-ID: On Sun, 15 Feb 2015, Henning Thielemann wrote: > I would also prefer if the "click to expand" links on the front page were > links to separate articles. We preach stateless programming to the rest of > the programming world and then the homepage content should be preferably > stateless as well, shouldn't it? Practically I want to send people URLs and > not explain them a sequence of clicks to tell them what text I am talking > about. Btw. what does the single "Try It" line mean? From difrumin at gmail.com Sun Feb 15 13:56:10 2015 From: difrumin at gmail.com (Daniil Frumin) Date: Sun, 15 Feb 2015 14:56:10 +0100 Subject: [Haskell-cafe] [Haskell] ANN: New Haskell.org Homepage Now Live In-Reply-To: <54E09192.50909@ki.informatik.uni-frankfurt.de> References: <54E09192.50909@ki.informatik.uni-frankfurt.de> Message-ID: Dear Haskell.org team thank you for your great work! But I was wondering this as well, why there is no mention of the Haskell platform in the Downloads section? I am also a little bit concerned about the "News" section: arguably, the news about GHC and Haskell platform releases are more important than newest stackoverflow questions or reddit posts. The newsfeed on Python.org, for example, is almost exclusively dedicated to releases and real-life events (which is also located on the front page). On Sun, Feb 15, 2015 at 1:31 PM, David Sabel wrote: > I wonder why the downloads section doesn't link to the Haskell platform. > What's the reason for it? > > David > > Am 15.02.2015 um 08:50 schrieb Gershom B: >> >> I?m pleased to announce that http://www.haskell.org has received its first >> significant design update since 2010! More significantly, for the first time >> since 2006 it is not a wiki, but an actual language homepage. More >> significantly still, for the first time ever, the Haskell homepage now runs >> on a fully Haskell-powered stack. I suppose some people might also be >> interested in the fact that it looks quite nice, and has significantly >> cleaned up the information it presents, so as to provide a more focused >> experience for newcomers looking to explore the language. >> >> The page is now includes the collective work of over 230 commits by 17 >> contributors. First and foremost among those is Chris Done, who conceived >> the vision, wrote the bulk of the code, and executed the design. Also thanks >> to our many admins, including Austin Seipp, Ricky Elrod, et al., who managed >> the deployment, and have been working behind the scenes to continue to >> modernize and update our creaking infrastructure. >> >> Onto a few key things to remember: >> >> * The wiki is still around at https://wiki.haskell.org and it is still >> a fantastic resource. It is now speedy again, and we have an account >> creation process. By all means, jump in, and help curate and cultivate its >> wealth of knowledge. >> * The new site is all on github: https://github.com/haskell-infra/hl ? >> there you will also find an issue tracker as well. We are sure there are >> many gaffes, gaps, and oddities that remain to be patched up in the site, >> especially with regards to its content. Tickets, pull requests, and comments >> are encouraged. >> * The official home for our mailinglists is now http://mail.haskell.org >> ? hopefully this will cause no problems or confusion, and the redirects >> should be in place properly. Please let us know if there are any issues. >> * We think we covered everything, but there is the possibility that >> some item, service, or redirect broke in the course of this transition. >> Please let us know if this is the case. >> * If you have been responsible for some subdirectory under the >> www.haskell.org banner, then you will find that you do not yet have an >> account on the new server. Please contact us and we?ll get you set up to >> continue to maintain that portion of the site. >> * As always, you can reach the haskell ops and admin team at >> admin at haskell.org, or on freenode irc at #haskell-infrastructure. >> >> Regards, >> Gershom >> (and also the Haskell.org Committee and Haskell.org Admin Team) >> >> _______________________________________________ >> Haskell mailing list >> Haskell at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell -- Sincerely yours, -- Daniil From chrisdone at gmail.com Sun Feb 15 15:30:13 2015 From: chrisdone at gmail.com (Christopher Done) Date: Sun, 15 Feb 2015 16:30:13 +0100 Subject: [Haskell-cafe] [Haskell] ANN: New Haskell.org Homepage Now Live In-Reply-To: References: Message-ID: On 15 February 2015 at 10:28, Henning Thielemann wrote: > I like the new wiki subdomain which is much more handy than the HaskellWiki > subdirectory. How can I add events to the table in the future? > Unfortunately, in my browser the Twitter headlines on the left overlap with > the Events on the right: > https://www.haskell.org/news That page is generated by: http://haskellnews.org/ But was added mostly as just something to put there. In the original mockup I intended to put events on the home page: http://chrisdone.com/comp.png I was thinking we can continue using the Wiki page that you're used to editing for events and just accessing that via the MediaWiki API (which someone happily contributed today). > I would prefer if the links in the Haskell News go to haskell.org/pipermail > (or mail.haskell.org) and not to googlegroups. The latter one requires > JavaScript. Looks like someone might be contributing that. > I would also prefer if the "click to expand" links on the front page were > links to separate articles. We preach stateless programming to the rest of > the programming world and then the homepage content should be preferably > stateless as well, shouldn't it? Practically I want to send people URLs and > not explain them a sequence of clicks to tell them what text I am talking > about. That was also in my original plan: to have expanded full page versions of each of the sections, but time is needed. From jeffbrown.the at gmail.com Sun Feb 15 19:55:02 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sun, 15 Feb 2015 11:55:02 -0800 Subject: [Haskell-cafe] Refactor unqualified imports to qualified ones automatically? Message-ID: Hi, In a previous post regarding overlapping images in wx [1], Stephen Tetley suggested I study Blobs [2]. I want to find its wx logic, but as it stands I can't distinguish the wx commands from the others, because wx is too large a library for me to know all the names in it, and Blobs imports most of its modules unqualified. Is there some automatic way of changing an unqualified import to a qualified import, so that every function from the module of interest would be prefixed to indicate where it comes from? If not, is there some other way around the problem? Thanks, Jeff [1] https://mail.haskell.org/pipermail/haskell-cafe/2015-January/117669.html [2] https://hackage.haskell.org/package/Blobs-0.3/src/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Sun Feb 15 20:39:04 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 15 Feb 2015 15:39:04 -0500 Subject: [Haskell-cafe] Exception safe resource management with dynamic regions, call for review In-Reply-To: <1423949769.2918.33.camel@gmail.com> References: <1423949769.2918.33.camel@gmail.com> Message-ID: huh, this is a pretty neat little api for resource pools, i'll have to take some time to dig into it when i get the chance! thanks for sharing. On Sat, Feb 14, 2015 at 4:36 PM, Yuras Shumovich wrote: > > Hello, > > I'm asking for code and design review for `io-region` library. It is > already on Hackage for convenience and easy access to haddock: > https://hackage.haskell.org/package/io-region > > Manual exception handling in Haskell almost never is a good idea, except > probably trivial cases where `bracket` is enough. A number of special > libraries where created to help with exception handling. `io-regions` is > one of them. > > Initially it was an attempt to solve the double-throw issue, but I found > it unsolvable in library without changes in language itself. So now it > is an attempt to design easy to use API with a bit different set of > trade-offs. > > The library is based on idea of regions that own resources. The > resources are released when the region is closed. Early releasing and > ownership transferring are supported. Types are *not* used to prevent > use-after-free errors. > > The API is not monadic, and it is the biggest difference from other > libraries. Regions are first-class citizens, so you can manipulate them, > pass as arguments to functions, send to other thread, store in data > types. Such flexibility has its cost -- a bit more manual management. > > The implementation is based on STM and is thread safe, that allows e.g. > atomic ownership transferring between threads. > > The nearest competitor I think is `resourset` package, and I still > recommend it by default. Though I convinced myself that `io-region` is > good enough, and I'm using it in productions (for two weeks already :) ) > > Thanks, > Yuras > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guthrie at mum.edu Sun Feb 15 22:28:07 2015 From: guthrie at mum.edu (Gregory Guthrie) Date: Sun, 15 Feb 2015 16:28:07 -0600 Subject: [Haskell-cafe] gloss-examples install fails Message-ID: <08EF9DA445C4B5439C4733E1F35705BA04C0DAC5E67E@MAIL.cs.mum.edu> I installed gloss, and then the binary for llvm (http://llvm.org/builds/ ) But still gloss-examples fail, because it requires gloss-raster, which fails (below). I see some discussion of this from last year (https://mail.haskell.org/pipermail/haskell-cafe/2014-March/113001.html), Do I need to do some path manipulations to get this to work? I see llc & opt as mentioned in that note installed under mingw, but not under the llvm installed site. ------------------------------------------------------------------------ cabal install gloss-raster Resolving dependencies... Configuring gloss-raster-1.9.2.1... Building gloss-raster-1.9.2.1... Failed to install gloss-raster-1.9.2.1 Build log ( C:\Users\guthrie\AppData\Roaming\cabal\logs\gloss-raster-1.9.2.1.log ): Building gloss-raster-1.9.2.1... Preprocessing library gloss-raster-1.9.2.1... [1 of 2] Compiling Graphics.Gloss.Raster.Array ( Graphics\Gloss\Raster\Array.hs, dist\build\Graphics\Gloss\Raster\Array.o ) : Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM cabal: Error: some packages failed to install: gloss-raster-1.9.2.1 failed during the building phase. The exception was: ExitFailure 1 Running with -v, it adds: : Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM 8.3 found on system at: e:\Plang\Haskell Platform\bin\ghc.exe Using ghc-pkg version 7.8.3 found on system at: e:\Plang\Haskell Platform\bin\ghc-pkg.exe No ghcjs found No ghcjs-pkg found No greencard found ------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Sun Feb 15 22:57:55 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sun, 15 Feb 2015 14:57:55 -0800 Subject: [Haskell-cafe] Refactor unqualified imports to qualified ones automatically? In-Reply-To: References: Message-ID: Thank you, Henning. I found a description [1] of what the -ddump-minimal-imports flag you suggest does ("Dump a minimal set of imports"), and I don't know what that means. I tried running it anyway, but I can't get the code to compile via GHC (or make, or cabal install, though it seems to want to be built via at least one of those). It was abandoned long ago, and I'm not convinced its network of dependencies is something I can disentangle. [1] https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flag-reference.html On Sun, Feb 15, 2015 at 1:20 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > Maybe the GHC flag > > -ddump-minimal-imports > > helps? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Mon Feb 16 00:42:57 2015 From: mike at proclivis.com (Michael Jones) Date: Sun, 15 Feb 2015 17:42:57 -0700 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: References: Message-ID: <0BDE71F6-CDA4-489E-B700-52916E148B90@proclivis.com> I have used GHC on a 32 bit NUC running Ubuntu, and it is a bit slow compiling. Run time performance was ok for my app IO app. I prefer a MinnowBoardMax running Ubuntu. The 64 bit dual core performs well much better, reasonable compile times. Just don?t expect it to run like an I5/7 Quad core. It is more like $150 + a Drive, so about $200. But it it works well. On Feb 14, 2015, at 1:45 AM, Stephen Tetley wrote: > The spec sheet says MicroPython runs on bare metal on the PyBoard. It > would be a lot of effort to make GHCi or even Hugs/Gofer do the same. > > As the price point for the PyBoard is the same as Raspberry PI, such > an effort would perhaps be headstrong rather than sensible. > > On 14 February 2015 at 04:55, Mike Meyer wrote: >> I asked about running GHCI on something like the Arduino due, and was told >> that there wasn't enough CPU on it for that. >> >> How about getting it running on something like a PyBoard? >> http://www.adafruit.com/products/2390 >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From ben.franksen at online.de Mon Feb 16 01:03:07 2015 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 16 Feb 2015 02:03:07 +0100 Subject: [Haskell-cafe] Typed TH References: <20141218174313.GC7757@weber> <549385D9.3090203@informatik.uni-tuebingen.de> Message-ID: Lagging far behind as usual with reading the cafe... Tillmann Rendel wrote: > Edward Amsden wrote: >> Relevant paper to typed quotation: >> http://repository.cmu.edu/cgi/viewcontent.cgi?article=2969&context=compsci >> >> I'm very interested in metaprogramming in typed languages, and this >> paper seems to suggest that it is a Hard Problem?. > > You mention Pfenning and Lee (1989) above. If you want to read more > about this, there has been some progress in the tradition of that paper > in recent years, including: > > Carette, Kiselyov, and Shan (2009). > Finally tagless, partially evaluated: > Tagless staged interpreters for simpler typed languages. > Journal of Functional Programming 19(4): 509-543. > (Extended version of a 2007 conference paper). I don't remember all the details but the trick that Carette, Kiselyov, and Shan use to achieve partial evaluation is certainly ingenious, given that staging in MetaML is purely generative: there are no primitives to inspect code pieces once they have been constructed. > Rendel, Ostermann, and Hofer (2009). > Typed self-representation. > In Proc. of PLDI. > > Jay and Palsberg (2011). > Typed self-interpretation by pattern matching. > In Proc. of ICFP. > > Brown and Palsberg (2015). > Self-representation in Girard's System U. > To appear in Proc. of POPL. > > These papers explore various tricks to avoid the fundamental hardness of > expressing the rules of a sane type system in the same type system > itself. For our own work on typed self-representation, we always hoped > that it would lead to better macro systems for statically typed > languages, but so far, we never figured out how to make it practical > enough. I fear the situation is similar for the other papers. I recently read this one and found it quite promising in that regard: Steve Ganz, Amr Sabry, Walid Taha Macros as Multi-Stage Computations: Type-Safe, Generative, Binding Macros in MacroML http://www.cs.indiana.edu/~sabry/papers/macroml.pdf They use translation to MetaML to show that their language is well-behaved. Cheers Ben -- "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." ? C.A.R. Hoare From gautier.difolco at gmail.com Mon Feb 16 05:20:45 2015 From: gautier.difolco at gmail.com (Gautier DI FOLCO) Date: Mon, 16 Feb 2015 05:20:45 +0000 Subject: [Haskell-cafe] =?iso-8859-1?q?Invitation=3A_Re=3A__Typed_TH_-_Lun?= =?iso-8859-1?q?=2E_16_F=E9vr=2E_2015_09=3A00_-_10=3A00_=28Gautier_?= =?iso-8859-1?q?DI_FOLCO=29?= Message-ID: <089e0160ba4c937d85050f2dbf69@google.com> Vous avez ?t? invit? ? l'?v?nement suivant. Titre : Re: [Haskell-cafe] Typed TH Date : Lun. 16 F?vr. 2015 09:00 - 10:00 Paris Agenda : Gautier DI FOLCO Participants : * Gautier DI FOLCO- organisateur * haskell-cafe * ben.franksen at online.de D?tails de l'?v?nement : https://www.google.com/calendar/event?action=VIEW&eid=XzcxaTNhZTFtY2RqM2diYjI2a3NtNGI5aDY1aWo4YjlvY29wbTZiYjVjaGhqMnA5bmNoajNjZWI2Y2cgaGFza2VsbC1jYWZlQGhhc2tlbGwub3Jn&tok=MjUjZ2F1dGllci5kaWZvbGNvQGdtYWlsLmNvbWZmNjMxZmZmZjdjNDAwNDc2NDRmMjE3NDRkZGIzNGY0ZTEyNTFjNmE&ctz=Europe/Paris&hl=fr Invitation de Google Agenda : https://www.google.com/calendar/ Vous recevez ce message ? l'adresse haskell-cafe at haskell.org, car vous participez ? cet ?v?nement. Pour ne plus recevoir de notifications pour cet ?v?nement ? l'avenir, refusez cet ?v?nement. Vous avez ?galement la possibilit? de cr?er un compte Google sur la page https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de notification pour l'int?gralit? de votre agenda. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 1247 bytes Desc: not available URL: From gautier.difolco at gmail.com Mon Feb 16 05:21:27 2015 From: gautier.difolco at gmail.com (gautier.difolco at gmail.com) Date: Mon, 16 Feb 2015 05:21:27 +0000 Subject: [Haskell-cafe] =?iso-8859-1?q?=C9v=E9nement_annul=E9=3A_Re=3A__Ty?= =?iso-8859-1?q?ped_TH_-_Lun=2E_16_F=E9vr=2E_2015_09=3A00_-_10=3A00?= =?iso-8859-1?q?_=28gautier=2Edifolco=40gmail=2Ecom=29?= Message-ID: Cet ?v?nement a ?t? annul? et supprim? de votre agenda. Titre : Re: [Haskell-cafe] Typed TH Date : Lun. 16 F?vr. 2015 09:00 - 10:00 Paris Agenda : gautier.difolco at gmail.com Participants : * Gautier DI FOLCO- organisateur * haskell-cafe * ben.franksen at online.de Invitation de Google Agenda : https://www.google.com/calendar/ Vous recevez ce message ? l'adresse haskell-cafe at haskell.org, car vous participez ? cet ?v?nement. Pour ne plus recevoir de notifications pour cet ?v?nement ? l'avenir, refusez cet ?v?nement. Vous avez ?galement la possibilit? de cr?er un compte Google sur la page https://www.google.com/calendar/ et de d?finir vous-m?me les param?tres de notification pour l'int?gralit? de votre agenda. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 889 bytes Desc: not available URL: From gautier.difolco at gmail.com Mon Feb 16 05:24:04 2015 From: gautier.difolco at gmail.com (Gautier DI FOLCO) Date: 16 Feb 2015 05:24:04 +0000 Subject: [Haskell-cafe] Cancelled: Re: Typed TH Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 5853 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 5853 bytes Desc: not available URL: From redneb8888 at gmail.com Mon Feb 16 08:14:12 2015 From: redneb8888 at gmail.com (Marios Titas) Date: Mon, 16 Feb 2015 08:14:12 +0000 Subject: [Haskell-cafe] Is there a cross platform CA certificate bundle solution for HsOpenSSL? In-Reply-To: References: <54DEB0F7.9060903@posteo.de> Message-ID: So I decided to write my own solution for that: https://hackage.haskell.org/package/HsOpenSSL-x509-system It works similarly to x509-system. Depending on the operating system, it tries to find a reasonable CA certificate store and use that. It should work on most OSs. I tested it on a couple linux distros, Mac OS X 10.9, Windows XP & 8.1. On Sat, Feb 14, 2015 at 2:23 PM, Marios Titas wrote: > Hi > > Thanks for the response. My problem is that this would probably not > work under windows as there is no CA bundle in PEM format somewhere in > the file system if I am not mistaken. Instead, I think you have to > call CertOpenSystemStore to get the certificates and then parse them > and add them one by one to the openssl context (see [1]). This is also > what x509-system does for the tls package. So I was hoping that > someone had done that already. > > Another solution is to have package that provides its own certificate > bundle. For example, in perl they have Mozilla::CA [2] which provides > a copy of the certificate bundle from firefox. > > Or maybe there is some other cross-platform solution that I am missing. > > [1] https://stackoverflow.com/a/19612161 > [2] http://search.cpan.org/perldoc?Mozilla%3A%3ACA > > On Sat, Feb 14, 2015 at 2:20 AM, Julian Ospald wrote: >> Marios Titas: >>> If I want to use HsOpenSSL for a tls client application that verifies >>> the server certificate I have to manually specify a CA certificate >>> bundle containing the trusted roots. For example, in a linux system, I >>> would do the following >>> >>> mkTlsContext :: IO Context >>> mkTlsContext = do >>> ctx <- context >>> contextSetVerificationMode ctx (VerifyPeer True False Nothing) >>> contextSetCADirectory ctx "/etc/ssl/certs" >>> return ctx >>> >>> The problem is that the above solution only works for linux. Is there >>> a cross-platform way to find a reasonable CA bundle and use it with >>> HsOpenSSL? >>> >>> Note that the tls package has x509-system [1] that does exactly that. >>> So I am basically asking if anybody has written something similar for >>> HsOpenSSL. >>> >>> [1] https://hackage.haskell.org/package/x509-system >> >> >> You shouldn't have to manually specify it. >> >> There is the function SSL_CTX_set_default_verify_paths() which sets >> default directories for the CAfile and CApath which are configured >> during compile-time of openssl. >> >> Unfortunately, some distributions don't really follow these standard >> paths, but that's your first bet. >> >> You might find this link interesting too: >> https://www.happyassassin.net/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/ >> >> But from what I see... HsOpenSSL lacks this function. Unless I missed >> something, I'd call that a bug. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe From lemming at henning-thielemann.de Mon Feb 16 08:20:33 2015 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 16 Feb 2015 09:20:33 +0100 (CET) Subject: [Haskell-cafe] Refactor unqualified imports to qualified ones automatically? In-Reply-To: References: Message-ID: On Sun, 15 Feb 2015, Jeffrey Brown wrote: > Thank you, Henning. I found a description [1] of what the -ddump-minimal-imports flag you suggest does ("Dump > a minimal set of imports"), and I don't know what that means. I tried running it anyway, but I can't get the > code to compile via GHC (or make, or cabal install, though it seems to want to be built via at least one of > those). It was abandoned long ago, and I'm not convinced its network of dependencies is something I can > disentangle. Then you have a problem. That's also the reason why I promote qualified and explicit imports again and again. If code can no longer be compiled, the compiler cannot help anymore. Btw. there is another nice flag -fwarn-missing-import-lists that warns about unqualified implicit imports. It should be enabled in the Cabal.GHC-Options field. From mle+hs at mega-nerd.com Mon Feb 16 09:14:15 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 16 Feb 2015 01:14:15 -0800 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: References: Message-ID: <20150216011415.17cfa31bf8a740ac3fccc05c@mega-nerd.com> Mike Meyer wrote: > I asked about running GHCI on something like the Arduino due, and was told > that there wasn't enough CPU on it for that. > > How about getting it running on something like a PyBoard? > http://www.adafruit.com/products/2390 For a very similar price (but yes much large physical size) you can get a Beagle Bone Black which is capable of running a full Linux OS. I run Debian on mine and have successfully cross-compiled from my linux-amd64 machine to linux-armhf binaries that run on the BBB. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From mwm at mired.org Mon Feb 16 09:19:56 2015 From: mwm at mired.org (Mike Meyer) Date: Mon, 16 Feb 2015 03:19:56 -0600 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: <20150216011415.17cfa31bf8a740ac3fccc05c@mega-nerd.com> References: <20150216011415.17cfa31bf8a740ac3fccc05c@mega-nerd.com> Message-ID: On Mon, Feb 16, 2015 at 3:14 AM, Erik de Castro Lopo wrote: > Mike Meyer wrote: > > How about getting it running on something like a PyBoard? > > http://www.adafruit.com/products/2390 > For a very similar price (but yes much large physical size) you can get > a Beagle Bone Black which is capable of running a full Linux OS. I run > Debian on mine and have successfully cross-compiled from my linux-amd64 > machine to linux-armhf binaries that run on the BBB. And presumably, weight. I work with rc aircraft - and like the small scale ones. I won't say every gram counts, but every ounce certainly does. So while I appreciate such pointers (though if I get something like that, I'll probably go wit the new Raspberry Pi 2, as I'm already using the older one for some projects), they don't help that much for my higher - literally - goals. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karel.gardas at centrum.cz Mon Feb 16 09:39:23 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 16 Feb 2015 10:39:23 +0100 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: References: Message-ID: <54E1BACB.5040608@centrum.cz> On 02/14/15 05:55 AM, Mike Meyer wrote: > I asked about running GHCI on something like the Arduino due, and was > told that there wasn't enough CPU on it for that. > > How about getting it running on something like a PyBoard? > http://www.adafruit.com/products/2390 That's Cortex-M4. Size and weight is really nice but just 1MB of ROM and 192KiB of RAM is not enough to run GHCi. Perhaps you may attempt to try Hugs but I still think it's more prepared to be run on top of Linux/Unix than on RTOS -- at least yet. For such devices really the only option for now is to compile haskell to bare metal which means Ajhc. If you insist on GHCi, then search for Cortex-Ax which is able to run Linux and which fulfill your weight reqs. For example Gumstick or Variscite makes a lot of nice SOMs, perhaps some of them is applicable for your app? Karel From karel.gardas at centrum.cz Mon Feb 16 09:46:32 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Mon, 16 Feb 2015 10:46:32 +0100 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: <54E1BACB.5040608@centrum.cz> References: <54E1BACB.5040608@centrum.cz> Message-ID: <54E1BC78.5090407@centrum.cz> On 02/16/15 10:39 AM, Karel Gardas wrote: > If you insist on GHCi, then search for Cortex-Ax which is able to run > Linux and which fulfill your weight reqs. For example Gumstick or > Variscite makes a lot of nice SOMs, perhaps some of them is applicable > for your app? Also have a look at http://www.friendlyarm.net/ -- their TinyXXXX modules are really close to what you proposed in PyBoard and still able to run Linux + GHCi. Karel From gale at sefer.org Mon Feb 16 11:33:58 2015 From: gale at sefer.org (Yitzchak Gale) Date: Mon, 16 Feb 2015 13:33:58 +0200 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: <54D63B85.3020403@posteo.de> References: <54D63B85.3020403@posteo.de> Message-ID: Julian Ospald wrote: > I've been wondering about the state of cryptography in haskell. Not so > much in the sense of "what libraries are out there?", but rather about > the question what crpyto and IT security people think about ideas like > rewriting something as OpenSSL in haskell. At Galois they have done a lot of work on this during the past few years. Of course, the good points brought up by Patrick have been prominent in their thinking. I'm not sure how much of that work is available publicly. But they did open-source Cryptol, their Haskell-based DSL for designing and testing crypto algorithms. http://galois.com/ http://cryptol.net/ Regards, Yitz From komendantsky at gmail.com Mon Feb 16 16:50:43 2015 From: komendantsky at gmail.com (Vladimir Komendantskiy) Date: Mon, 16 Feb 2015 16:50:43 +0000 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: <54E1BC78.5090407@centrum.cz> References: <54E1BACB.5040608@centrum.cz> <54E1BC78.5090407@centrum.cz> Message-ID: FriendlyARM modules look very good. If you are interested in compute performance on a pocket budget, e.g. for computer vision on this RC plane, you could try 8-core Merrii A80 (http://linux-sunxi.org/Merrii_A80_Optimus_Board) or Pcduino8 (http://www.pcduino.com/pcduino8-beta-available-application/) or Cubieboard A80. There is some preliminary Linux support. You could even test-drive Parallel Haskell on those :) These A80 boards draw 3 Amps of current at 5 Volts which is doable for a standard LiPo battery. This current draw is considerably less than that required by the motor anyway. Boards should work from a battery source regulated by a 5V voltage regulator. Yet I wonder why do you have a requirement to run code in the interpreter on an automnomous vehicle? Wouldn't compiled code run more efficiently and require less resources? --Vladimir On 16 February 2015 at 09:46, Karel Gardas wrote: > On 02/16/15 10:39 AM, Karel Gardas wrote: >> >> If you insist on GHCi, then search for Cortex-Ax which is able to run >> Linux and which fulfill your weight reqs. For example Gumstick or >> Variscite makes a lot of nice SOMs, perhaps some of them is applicable >> for your app? > > > Also have a look at http://www.friendlyarm.net/ -- their TinyXXXX modules > are really close to what you proposed in PyBoard and still able to run Linux > + GHCi. > > > Karel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mrz.vtl at gmail.com Mon Feb 16 16:53:25 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Mon, 16 Feb 2015 11:53:25 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing Message-ID: I'm starting to work on my first real haskell program (I've only RWH exercises under my belt) and wondering whether people use quickcheck at all for compiler testing. I've seen uses of quickcheck for testing parsers, but I'm interested in generating well-formed programs (e.g. random programs with all declarations in reasonable random places). This could be used to test passes other than parsing (or even parsing, for languages that needs to distinguish identifiers, like the 'typedef' problem in C/C++). The only thing I can think of, is to use quickcheck for randomly generating statements, go over them and figure out free variables (incl. functions) and generate declarations in random places for them. But I'm not sure how this would play with test size reduction and doesn't look like a nice solution anyhow. Any idea or pointers to examples? or should I give up on quickcheck for this and just do direct testing? Thanks, Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at functionaljobs.com Mon Feb 16 17:00:01 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 16 Feb 2015 12:00:01 -0500 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <54e222144765e@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Senior Developer (Big Data Tech Stack) at Recruit IT Group Ltd http://functionaljobs.com/jobs/8783-senior-developer-big-data-tech-stack-at-recruit-it-group-ltd Senior Development Engineer at Lookingglass Cyber Solutions http://functionaljobs.com/jobs/8782-senior-development-engineer-at-lookingglass-cyber-solutions Cheers, Sean Murphy FunctionalJobs.com From achudnov at gmail.com Mon Feb 16 17:02:32 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Mon, 16 Feb 2015 12:02:32 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing In-Reply-To: References: Message-ID: <54E222A8.6020004@gmail.com> I use QuichCheck for compiler testing where I generate random, but well-formed programs and check some high-level syntactic properties on results. The QuickCheck instance is open-source (see language-ecmascript), but the compiler-test code is closed-source at this time. Still, I found that it's not the ultimate answer: many properties are hard to formalize, so I have to resort to unit tests. I'm not sure what you mean by "how this would play with test size reduction". I think it's worth giving a try, but keep in mind that you might still need to use unit tests. Let me know if you have any questions. /Andrey On 02/16/2015 11:53 AM, Maurizio Vitale wrote: > I'm starting to work on my first real haskell program (I've only RWH > exercises under my belt) and wondering whether people use quickcheck > at all for compiler testing. > > I've seen uses of quickcheck for testing parsers, but I'm interested > in generating well-formed programs (e.g. random programs with all > declarations in reasonable random places). This could be used to test > passes other than parsing (or even parsing, for languages that needs > to distinguish identifiers, like the 'typedef' problem in C/C++). > > The only thing I can think of, is to use quickcheck for randomly > generating statements, go over them and figure out free variables > (incl. functions) and generate declarations in random places for them. > But I'm not sure how this would play with test size reduction and > doesn't look like a nice solution anyhow. > > Any idea or pointers to examples? or should I give up on quickcheck > for this and just do direct testing? > > Thanks, > > Maurizio > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Mon Feb 16 17:19:09 2015 From: mwm at mired.org (Mike Meyer) Date: Mon, 16 Feb 2015 11:19:09 -0600 Subject: [Haskell-cafe] HaskBoard? In-Reply-To: References: <54E1BACB.5040608@centrum.cz> <54E1BC78.5090407@centrum.cz> Message-ID: On Mon, Feb 16, 2015 at 10:50 AM, Vladimir Komendantskiy < komendantsky at gmail.com> wrote: > Yet I wonder why do you have a requirement to run code in the > interpreter on an automnomous vehicle? Wouldn't compiled code run more > efficiently and require less resources? > Because the ability to change the programming in the field is important. A lot of the configuration is pure functions that get iterated over the state to produce new state, and expressing those in Haskell is where I think this can win. Ok, there'd be an advantage to writing it in Haskell in the first place, but that's a hard sell. On the other hand, replacing a text file in INI or XML or YAML or some ad-hoc format that specifies what is, when all is said and done, a pure function that takes the state of the hardware as input with an actual Haskell function, that I think I can sell. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrz.vtl at gmail.com Mon Feb 16 17:33:10 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Mon, 16 Feb 2015 12:33:10 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing In-Reply-To: <54E222A8.6020004@gmail.com> References: <54E222A8.6020004@gmail.com> Message-ID: By 'test size reduction' I mean the 'shrink' function. It seems to me (as I said, first Haskell program and no experience with quickcheck) that it works nicely with a topdown generation of the test, but I don't see how to easily generate correct programs that way. Even if you cannot release your tests, maybe you can help me with a very simple case. Consider a trivial AST. A program is a possibly nested block. Each block is a bunch of declarations of variables and some use of them data Block = Block [Declaration] [Statement] data Declaration = Var String String data Statement = Statement Block | Use String How one would generate things like: Block [Var "a" "int"] [Use "a"] -- here a is declared in the same block Block [] [Statement Block [Var "s" "int"] [Statement Block [] [Use "s"]]] -- here s is declared in some other visible scope etc. Or am I trying to approach the problem from the wrong angle? On Mon, Feb 16, 2015 at 12:02 PM, Andrey Chudnov wrote: > I use QuichCheck for compiler testing where I generate random, but > well-formed programs and check some high-level syntactic properties on > results. The QuickCheck instance is open-source (see language-ecmascript), > but the compiler-test code is closed-source at this time. Still, I found > that it's not the ultimate answer: many properties are hard to formalize, > so I have to resort to unit tests. I'm not sure what you mean by "how this > would play with test size reduction". I think it's worth giving a try, but > keep in mind that you might still need to use unit tests. > > Let me know if you have any questions. > > /Andrey > > > On 02/16/2015 11:53 AM, Maurizio Vitale wrote: > > I'm starting to work on my first real haskell program (I've only RWH > exercises under my belt) and wondering whether people use quickcheck at all > for compiler testing. > > I've seen uses of quickcheck for testing parsers, but I'm interested in > generating well-formed programs (e.g. random programs with all declarations > in reasonable random places). This could be used to test passes other than > parsing (or even parsing, for languages that needs to distinguish > identifiers, like the 'typedef' problem in C/C++). > > The only thing I can think of, is to use quickcheck for randomly > generating statements, go over them and figure out free variables (incl. > functions) and generate declarations in random places for them. But I'm not > sure how this would play with test size reduction and doesn't look like a > nice solution anyhow. > > Any idea or pointers to examples? or should I give up on quickcheck for > this and just do direct testing? > > Thanks, > > Maurizio > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diaa6510 at gmail.com Mon Feb 16 18:08:03 2015 From: diaa6510 at gmail.com (Deyaaeldeen) Date: Mon, 16 Feb 2015 13:08:03 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing In-Reply-To: References: <54E222A8.6020004@gmail.com> Message-ID: Hi, You will need to create instances of type Gen for your data types to specify how you can build expressions of your language. I have a simple interpreter for gradually-typed lambda calculus (still in development) and I am using quickcheck to verify it, here is the quickcheck code: https://github.com/deyaaeldeen/GTLC/blob/master/interps/Testing.hs Deyaa On Mon, Feb 16, 2015 at 12:33 PM, Maurizio Vitale wrote: > By 'test size reduction' I mean the 'shrink' function. It seems to me (as > I said, first Haskell program and no experience with quickcheck) that it > works nicely with a topdown generation of the test, but I don't see how to > easily generate correct programs that way. > > Even if you cannot release your tests, maybe you can help me with a very > simple case. Consider a trivial AST. A program is a possibly nested block. > Each block is a bunch of declarations of variables and some use of them > > data Block = Block [Declaration] [Statement] > > data Declaration = Var String String > > data Statement = Statement Block | Use String > > > How one would generate things like: > > Block [Var "a" "int"] [Use "a"] -- here a is declared in the same block > > Block [] [Statement Block [Var "s" "int"] [Statement Block [] [Use "s"]]] > -- here s is declared in some other visible scope > > > etc. > > Or am I trying to approach the problem from the wrong angle? > > > > On Mon, Feb 16, 2015 at 12:02 PM, Andrey Chudnov > wrote: > >> I use QuichCheck for compiler testing where I generate random, but >> well-formed programs and check some high-level syntactic properties on >> results. The QuickCheck instance is open-source (see language-ecmascript), >> but the compiler-test code is closed-source at this time. Still, I found >> that it's not the ultimate answer: many properties are hard to formalize, >> so I have to resort to unit tests. I'm not sure what you mean by "how this >> would play with test size reduction". I think it's worth giving a try, but >> keep in mind that you might still need to use unit tests. >> >> Let me know if you have any questions. >> >> /Andrey >> >> >> On 02/16/2015 11:53 AM, Maurizio Vitale wrote: >> >> I'm starting to work on my first real haskell program (I've only RWH >> exercises under my belt) and wondering whether people use quickcheck at all >> for compiler testing. >> >> I've seen uses of quickcheck for testing parsers, but I'm interested in >> generating well-formed programs (e.g. random programs with all declarations >> in reasonable random places). This could be used to test passes other than >> parsing (or even parsing, for languages that needs to distinguish >> identifiers, like the 'typedef' problem in C/C++). >> >> The only thing I can think of, is to use quickcheck for randomly >> generating statements, go over them and figure out free variables (incl. >> functions) and generate declarations in random places for them. But I'm not >> sure how this would play with test size reduction and doesn't look like a >> nice solution anyhow. >> >> Any idea or pointers to examples? or should I give up on quickcheck for >> this and just do direct testing? >> >> Thanks, >> >> Maurizio >> >> >> _______________________________________________ >> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Feb 16 18:33:57 2015 From: david.feuer at gmail.com (David Feuer) Date: Mon, 16 Feb 2015 13:33:57 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing In-Reply-To: References: Message-ID: I was wondering the same thing about testing GHC itself. In particular, the test case for Trac #9964 (a subtle code generator crash) seems like it could conceivably be small enough for QuickCheck to have come up with. Although I can see why good properties would be hard to formulate (and some/many/most important ones are impossible to check in general), "does not quickly trigger a GHC panic" should be a very easy one. On Feb 16, 2015 11:53 AM, "Maurizio Vitale" wrote: > I'm starting to work on my first real haskell program (I've only RWH > exercises under my belt) and wondering whether people use quickcheck at all > for compiler testing. > > I've seen uses of quickcheck for testing parsers, but I'm interested in > generating well-formed programs (e.g. random programs with all declarations > in reasonable random places). This could be used to test passes other than > parsing (or even parsing, for languages that needs to distinguish > identifiers, like the 'typedef' problem in C/C++). > > The only thing I can think of, is to use quickcheck for randomly > generating statements, go over them and figure out free variables (incl. > functions) and generate declarations in random places for them. But I'm not > sure how this would play with test size reduction and doesn't look like a > nice solution anyhow. > > Any idea or pointers to examples? or should I give up on quickcheck for > this and just do direct testing? > > Thanks, > > Maurizio > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Mon Feb 16 18:44:14 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Mon, 16 Feb 2015 13:44:14 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing In-Reply-To: References: <54E222A8.6020004@gmail.com> Message-ID: <54E23A7E.30506@gmail.com> If you just need an example for generating and shrinking arbitrary ASTs, you can have a look here: https://github.com/jswebtools/language-ecmascript/blob/master/src/Language/ECMAScript3/Syntax/Arbitrary.hs . Note that I use the testing-feat package to generate Gen instances --- it tends to do better (explore interesting cases earlier) than handwritten code --- and then fix-up incorrect ASTs (another option is to simply discard them). On 02/16/2015 12:33 PM, Maurizio Vitale wrote: > By 'test size reduction' I mean the 'shrink' function. It seems to me > (as I said, first Haskell program and no experience with quickcheck) > that it works nicely with a topdown generation of the test, but I > don't see how to easily generate correct programs that way. > > Even if you cannot release your tests, maybe you can help me with a > very simple case. Consider a trivial AST. A program is a possibly > nested block. Each block is a bunch of declarations of variables and > some use of them > > data Block = Block [Declaration] [Statement] > > data Declaration = Var String String > > data Statement = Statement Block | Use String > > > How one would generate things like: > > Block [Var "a" "int"] [Use "a"] -- here a is declared in the same > block > > Block [] [Statement Block [Var "s" "int"] [Statement Block [] [Use > "s"]]] -- here s is declared in some other visible scope > > > etc. > > Or am I trying to approach the problem from the wrong angle? > > > On Mon, Feb 16, 2015 at 12:02 PM, Andrey Chudnov > wrote: > > I use QuichCheck for compiler testing where I generate random, but > well-formed programs and check some high-level syntactic > properties on results. The QuickCheck instance is open-source (see > language-ecmascript), but the compiler-test code is closed-source > at this time. Still, I found that it's not the ultimate answer: > many properties are hard to formalize, so I have to resort to unit > tests. I'm not sure what you mean by "how this would play with > test size reduction". I think it's worth giving a try, but keep in > mind that you might still need to use unit tests. > > Let me know if you have any questions. > > /Andrey > > > On 02/16/2015 11:53 AM, Maurizio Vitale wrote: >> I'm starting to work on my first real haskell program (I've only >> RWH exercises under my belt) and wondering whether people use >> quickcheck at all for compiler testing. >> >> I've seen uses of quickcheck for testing parsers, but I'm >> interested in generating well-formed programs (e.g. random >> programs with all declarations in reasonable random places). This >> could be used to test passes other than parsing (or even parsing, >> for languages that needs to distinguish identifiers, like the >> 'typedef' problem in C/C++). >> >> The only thing I can think of, is to use quickcheck for randomly >> generating statements, go over them and figure out free variables >> (incl. functions) and generate declarations in random places for >> them. But I'm not sure how this would play with test size >> reduction and doesn't look like a nice solution anyhow. >> >> Any idea or pointers to examples? or should I give up on >> quickcheck for this and just do direct testing? >> >> Thanks, >> >> Maurizio >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdammers at gmail.com Tue Feb 17 06:52:49 2015 From: tdammers at gmail.com (Tobias Dammers) Date: Tue, 17 Feb 2015 07:52:49 +0100 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: References: <54D63B85.3020403@posteo.de> Message-ID: Another path worth investigating would be to construct a Haskell (e)DSL which produces C code, but adds better constraints and guarantees through Haskell's type system, a bit like what people are already doing for embedded systems On Feb 16, 2015 12:34 PM, "Yitzchak Gale" wrote: > Julian Ospald wrote: > > I've been wondering about the state of cryptography in haskell. Not so > > much in the sense of "what libraries are out there?", but rather about > > the question what crpyto and IT security people think about ideas like > > rewriting something as OpenSSL in haskell. > > At Galois they have done a lot of work on this during the past > few years. Of course, the good points brought up by Patrick > have been prominent in their thinking. > > I'm not sure how much of that work is available publicly. > But they did open-source Cryptol, their Haskell-based > DSL for designing and testing crypto algorithms. > > http://galois.com/ > http://cryptol.net/ > > Regards, > Yitz > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polux2001 at gmail.com Tue Feb 17 08:15:10 2015 From: polux2001 at gmail.com (Paul Brauner) Date: Tue, 17 Feb 2015 08:15:10 +0000 Subject: [Haskell-cafe] quickcheck for compiler testing References: <54E222A8.6020004@gmail.com> <54E23A7E.30506@gmail.com> Message-ID: There's a recent paper by Jonas Dureg?rd et al where they introduce a variant of feat that allows for efficient discarding of unwanted values, ? la lazy Smallcheck. The motivating example of the paper is exactly what you're looking for: discarding ill-formed programs. On Mon, Feb 16, 2015, 19:44 Andrey Chudnov wrote: > If you just need an example for generating and shrinking arbitrary ASTs, > you can have a look here: > https://github.com/jswebtools/language-ecmascript/blob/master/src/Language/ECMAScript3/Syntax/Arbitrary.hs > . Note that I use the testing-feat package to generate Gen instances --- it > tends to do better (explore interesting cases earlier) than handwritten > code --- and then fix-up incorrect ASTs (another option is to simply > discard them). > > > On 02/16/2015 12:33 PM, Maurizio Vitale wrote: > > By 'test size reduction' I mean the 'shrink' function. It seems to me (as > I said, first Haskell program and no experience with quickcheck) that it > works nicely with a topdown generation of the test, but I don't see how to > easily generate correct programs that way. > > Even if you cannot release your tests, maybe you can help me with a very > simple case. Consider a trivial AST. A program is a possibly nested block. > Each block is a bunch of declarations of variables and some use of them > > data Block = Block [Declaration] [Statement] > > data Declaration = Var String String > > data Statement = Statement Block | Use String > > > How one would generate things like: > > Block [Var "a" "int"] [Use "a"] -- here a is declared in the same block > > Block [] [Statement Block [Var "s" "int"] [Statement Block [] [Use > "s"]]] -- here s is declared in some other visible scope > > > etc. > > Or am I trying to approach the problem from the wrong angle? > > > > On Mon, Feb 16, 2015 at 12:02 PM, Andrey Chudnov > wrote: > >> I use QuichCheck for compiler testing where I generate random, but >> well-formed programs and check some high-level syntactic properties on >> results. The QuickCheck instance is open-source (see language-ecmascript), >> but the compiler-test code is closed-source at this time. Still, I found >> that it's not the ultimate answer: many properties are hard to formalize, >> so I have to resort to unit tests. I'm not sure what you mean by "how this >> would play with test size reduction". I think it's worth giving a try, but >> keep in mind that you might still need to use unit tests. >> >> Let me know if you have any questions. >> >> /Andrey >> >> >> On 02/16/2015 11:53 AM, Maurizio Vitale wrote: >> >> I'm starting to work on my first real haskell program (I've only RWH >> exercises under my belt) and wondering whether people use quickcheck at all >> for compiler testing. >> >> I've seen uses of quickcheck for testing parsers, but I'm interested in >> generating well-formed programs (e.g. random programs with all declarations >> in reasonable random places). This could be used to test passes other than >> parsing (or even parsing, for languages that needs to distinguish >> identifiers, like the 'typedef' problem in C/C++). >> >> The only thing I can think of, is to use quickcheck for randomly >> generating statements, go over them and figure out free variables (incl. >> functions) and generate declarations in random places for them. But I'm not >> sure how this would play with test size reduction and doesn't look like a >> nice solution anyhow. >> >> Any idea or pointers to examples? or should I give up on quickcheck for >> this and just do direct testing? >> >> Thanks, >> >> Maurizio >> >> >> _______________________________________________ >> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Tue Feb 17 08:20:17 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Tue, 17 Feb 2015 00:20:17 -0800 Subject: [Haskell-cafe] Refactor unqualified imports to qualified ones automatically? In-Reply-To: References: Message-ID: wxPython is well documented and tutorialed. Today I began learning that. It has already clarified a lot of what was opaque in Blobs, such as the distinction between a frame and a window (windows are smaller!), and what a DC is for. When I turned to wxPython I thought I was giving up on Haskell. It will be poetic if that having given up is what allows me to persist. (It's lucky that didn't switch to pyQt!) On Mon, Feb 16, 2015 at 12:20 AM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > > On Sun, 15 Feb 2015, Jeffrey Brown wrote: > > Thank you, Henning. I found a description [1] of what the >> -ddump-minimal-imports flag you suggest does ("Dump >> a minimal set of imports"), and I don't know what that means. I tried >> running it anyway, but I can't get the >> code to compile via GHC (or make, or cabal install, though it seems to >> want to be built via at least one of >> those). It was abandoned long ago, and I'm not convinced its network of >> dependencies is something I can >> disentangle. >> > > Then you have a problem. That's also the reason why I promote qualified > and explicit imports again and again. If code can no longer be compiled, > the compiler cannot help anymore. > > Btw. there is another nice flag -fwarn-missing-import-lists that warns > about unqualified implicit imports. It should be enabled in the > Cabal.GHC-Options field. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at marcelfourne.de Tue Feb 17 09:43:12 2015 From: haskell at marcelfourne.de (Marcel =?UTF-8?B?Rm91cm7DqQ==?=) Date: Tue, 17 Feb 2015 10:43:12 +0100 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: References: <54D63B85.3020403@posteo.de> Message-ID: <20150217104312.0940bbd3@rechner> Am Sat, 7 Feb 2015 11:53:42 -0500 schrieb Patrick Mylund Nielsen: >In other words, Haskell eliminates several classes of errors, but >doesn't prevent logic errors, and can do nothing about poor standards. > >Aside from this, I think the main issues would be: > > - Timing resistance: This is not as simple as sprinkling some bitwise >operations on your crypto code. It took a long time to figure out even >the basics in OpenSSL, and for better and worse it's more difficult to >intuit what your Haskell code will be compiled to than it is with C >(though C compilers have been known to optimize away constant-time >code.) I feel prompted to add something in here, since I'm working on this as the author of hecc[0]. My published basic implementation of elliptic curve cryptography contains the basic math for the so-called NIST-curves[1] in a best-effort timing-attack resistant way, which I will try to explain here. I will try to make my own experiences into simple guidelines this way, so it might be a bit long-ish. There are numerous ways to see different execution times depending on the bits of the secret key, each of which has to be fixed. First of all, if there is a branch in your code, a construct like if secretkeybit == True then do_something else do_nothing is way too easy to attack. (1) All your branches need to have exactly the same execution times. If you implement RSA or ECC, there will at some point be a square-and-multiply or double-and-add equivalent. A good fix for this is the Montgomery's Ladder, which has the property of juggling both branches in its parameters. In theory, this will leave no timing channel since both branch-parameters will be executed (I learned: {-# LANGUAGE BangPatterns #-} is very helpful here). (2) All branches need to be really executed. Sadly, this is not sufficient in a lazy evaluation environment like Haskell - or any other language which permits the compiler to optimize computations away (I agree: There be dragons if you really want to be compiler-safe in C! ;-)). I found out that special patterns in a secret key can lead a lazy Montgomery Ladder to faster execution times in Haskell, which I will try to explain in a proper paper in detail, time permitting. There are malicious little things in modern CPUs called "caches", which make some executed code quite a bit faster. In company with the branch prediction unit, branches based on bits of the secret key become very volatile, so the best defense is (3) No branches based on the content of bits of the secret key. This point is very hard to do when implementing the NIST-curves for TLS, my own code is not yet made in this fashion. Also currently, most people use Integer-gmp, which is of course based on gmp, which got timing-attack resistant (slower) implementations of methods in its version 6 release, so every one before that may be insecure when regarding timing attacks. This is not a deal-breaker, since other libraries in other languages also depend on gmp, like nocrypto[2] for Mirage OS and GNUTLS. I am currently fixing my new Ed25519/EdDSA implementation in pure Haskell (please don't confuse it with the fully functioning and fast C-wrapper one [3]), which is branch-free per point (3) and should be an example of code under such a rule. Right now I am not sure when the code will be ready for public scrutiny, but it should at least be implementation-secure and correct, being fast can follow later. This release will also feature a rework of hecc and a name-change, since the possible confusion with Hyper-Elliptic Curve Cryptography. Please note: I am currently searching a (paid) position as (preferably) phd student. I like working on functional programming, provabilty and cryptography. If you or anyone you know has interest in having me working for them, please contact me! Best of wishes, Marcel Fourn? [0]:https://hackage.haskell.org/package/hecc [1]:http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf [2]:https://github.com/mirleft/ocaml-nocrypto [3]:https://hackage.haskell.org/package/ed25519 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From o.klinke at dkfz-heidelberg.de Tue Feb 17 10:05:45 2015 From: o.klinke at dkfz-heidelberg.de (Dr. Olaf Klinke) Date: Tue, 17 Feb 2015 11:05:45 +0100 (CET) Subject: [Haskell-cafe] Very large data structures in the heap Message-ID: I have a function that builds a (cyclic) data structure for searching text. The resulting object can be serialized and re-built. Real-world problems would, however, result in a tree with about 10^9 nodes. I take it that standard data type declarations are not very memory-efficient, so my (fully evaluated) search tree would not fit into memory as a heap object. Its serialised form should be of tractable size, e.g. by storing an array of labels and the tree structure as a bit array of parentheses. I'd like to separate serialization (IO) from traversal of the stucture (pure), but how can one avoid the entire heap object from being built? Can lazyness be exploited? Olaf From ky3 at atamo.com Tue Feb 17 12:14:13 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 17 Feb 2015 19:14:13 +0700 Subject: [Haskell-cafe] Very large data structures in the heap In-Reply-To: References: Message-ID: On Tue, Feb 17, 2015 at 5:05 PM, Dr. Olaf Klinke < o.klinke at dkfz-heidelberg.de> wrote: > I'd like to separate serialization (IO) from traversal of the stucture > (pure), but how can one avoid the entire heap object from being built? Can > lazyness be exploited? Something I didn't quite understand from your email is whether 1. the data structure is being constructed and you'd like it simultaneously serialized to disk or 2. it's already serialized and you'd like to perform pure traversals on it. Problem 1 is one of compute then write, problem 2 is one of read then compute. Lazy I/O, as in unsafeInterleaveIO, excels at 2. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Tue Feb 17 12:54:39 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Tue, 17 Feb 2015 07:54:39 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing In-Reply-To: References: <54E222A8.6020004@gmail.com> <54E23A7E.30506@gmail.com> Message-ID: <54E33A0F.3060307@gmail.com> Do you know if there is an implementation? On 02/17/2015 03:15 AM, Paul Brauner wrote: > > There's a recent paper by Jonas Dureg?rd et al where they introduce a > variant of feat that allows for efficient discarding of unwanted > values, ? la lazy Smallcheck. The motivating example of the paper is > exactly what you're looking for: discarding ill-formed programs. > > > On Mon, Feb 16, 2015, 19:44 Andrey Chudnov > wrote: > > If you just need an example for generating and shrinking arbitrary > ASTs, you can have a look here: > https://github.com/jswebtools/language-ecmascript/blob/master/src/Language/ECMAScript3/Syntax/Arbitrary.hs > . Note that I use the testing-feat package to generate Gen > instances --- it tends to do better (explore interesting cases > earlier) than handwritten code --- and then fix-up incorrect ASTs > (another option is to simply discard them). > > > On 02/16/2015 12:33 PM, Maurizio Vitale wrote: >> By 'test size reduction' I mean the 'shrink' function. It seems >> to me (as I said, first Haskell program and no experience with >> quickcheck) that it works nicely with a topdown generation of the >> test, but I don't see how to easily generate correct programs >> that way. >> >> Even if you cannot release your tests, maybe you can help me with >> a very simple case. Consider a trivial AST. A program is a >> possibly nested block. Each block is a bunch of declarations of >> variables and some use of them >> >> data Block = Block [Declaration] [Statement] >> >> data Declaration = Var String String >> >> data Statement = Statement Block | Use String >> >> >> How one would generate things like: >> >> Block [Var "a" "int"] [Use "a"] -- here a is declared in the >> same block >> >> Block [] [Statement Block [Var "s" "int"] [Statement Block [] >> [Use "s"]]] -- here s is declared in some other visible scope >> >> >> etc. >> >> Or am I trying to approach the problem from the wrong angle? >> >> >> On Mon, Feb 16, 2015 at 12:02 PM, Andrey Chudnov >> > wrote: >> >> I use QuichCheck for compiler testing where I generate >> random, but well-formed programs and check some high-level >> syntactic properties on results. The QuickCheck instance is >> open-source (see language-ecmascript), but the compiler-test >> code is closed-source at this time. Still, I found that it's >> not the ultimate answer: many properties are hard to >> formalize, so I have to resort to unit tests. I'm not sure >> what you mean by "how this would play with test size >> reduction". I think it's worth giving a try, but keep in mind >> that you might still need to use unit tests. >> >> Let me know if you have any questions. >> >> /Andrey >> >> >> On 02/16/2015 11:53 AM, Maurizio Vitale wrote: >>> I'm starting to work on my first real haskell program (I've >>> only RWH exercises under my belt) and wondering whether >>> people use quickcheck at all for compiler testing. >>> >>> I've seen uses of quickcheck for testing parsers, but I'm >>> interested in generating well-formed programs (e.g. random >>> programs with all declarations in reasonable random places). >>> This could be used to test passes other than parsing (or >>> even parsing, for languages that needs to distinguish >>> identifiers, like the 'typedef' problem in C/C++). >>> >>> The only thing I can think of, is to use quickcheck for >>> randomly generating statements, go over them and figure out >>> free variables (incl. functions) and generate declarations >>> in random places for them. But I'm not sure how this would >>> play with test size reduction and doesn't look like a nice >>> solution anyhow. >>> >>> Any idea or pointers to examples? or should I give up on >>> quickcheck for this and just do direct testing? >>> >>> Thanks, >>> >>> Maurizio >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Feb 17 13:45:08 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 17 Feb 2015 14:45:08 +0100 Subject: [Haskell-cafe] Very large data structures in the heap In-Reply-To: References: Message-ID: <1424180708.1981.21.camel@joachim-breitner.de> Hallo Olaf, Am Dienstag, den 17.02.2015, 11:05 +0100 schrieb Dr. Olaf Klinke: > I have a function that builds a (cyclic) data structure for searching > text. The resulting object can be serialized and re-built. Real-world > problems would, however, result in a tree with about 10^9 nodes. I take it > that standard data type declarations are not very memory-efficient, so my > (fully evaluated) search tree would not fit into memory as a heap object. > Its serialised form should be of tractable size, e.g. by storing an array > of labels and the tree structure as a bit array of parentheses. you say cyclic, but you also say it is a tree. Do you mean that it locally looks like a tree, but is in fact a graph, due to self-references? > I'd like to separate serialization (IO) from traversal of the stucture > (pure), but how can one avoid the entire heap object from being built? > Can lazyness be exploited? I would say ?yes?, but need more information for a more concrete answer :-) Gr??e aus Karlsruhe, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From polux2001 at gmail.com Tue Feb 17 13:53:08 2015 From: polux2001 at gmail.com (Paul Brauner) Date: Tue, 17 Feb 2015 13:53:08 +0000 Subject: [Haskell-cafe] quickcheck for compiler testing References: <54E222A8.6020004@gmail.com> <54E23A7E.30506@gmail.com> <54E33A0F.3060307@gmail.com> Message-ID: According to the paper there is, but it's not on Hackage as far as I know. If you ever ping the authors about the implementation I'd be interested in their answer too. Paul On Tue Feb 17 2015 at 1:54:52 PM Andrey Chudnov wrote: > Do you know if there is an implementation? > > > On 02/17/2015 03:15 AM, Paul Brauner wrote: > > There's a recent paper by Jonas Dureg?rd et al where they introduce a > variant of feat that allows for efficient discarding of unwanted values, ? > la lazy Smallcheck. The motivating example of the paper is exactly what > you're looking for: discarding ill-formed programs. > > On Mon, Feb 16, 2015, 19:44 Andrey Chudnov wrote: > >> If you just need an example for generating and shrinking arbitrary ASTs, >> you can have a look here: >> https://github.com/jswebtools/language-ecmascript/blob/master/src/Language/ECMAScript3/Syntax/Arbitrary.hs >> . Note that I use the testing-feat package to generate Gen instances --- it >> tends to do better (explore interesting cases earlier) than handwritten >> code --- and then fix-up incorrect ASTs (another option is to simply >> discard them). >> >> >> On 02/16/2015 12:33 PM, Maurizio Vitale wrote: >> >> By 'test size reduction' I mean the 'shrink' function. It seems to me (as >> I said, first Haskell program and no experience with quickcheck) that it >> works nicely with a topdown generation of the test, but I don't see how to >> easily generate correct programs that way. >> >> Even if you cannot release your tests, maybe you can help me with a >> very simple case. Consider a trivial AST. A program is a possibly nested >> block. Each block is a bunch of declarations of variables and some use of >> them >> >> data Block = Block [Declaration] [Statement] >> >> data Declaration = Var String String >> >> data Statement = Statement Block | Use String >> >> >> How one would generate things like: >> >> Block [Var "a" "int"] [Use "a"] -- here a is declared in the same block >> >> Block [] [Statement Block [Var "s" "int"] [Statement Block [] [Use >> "s"]]] -- here s is declared in some other visible scope >> >> >> etc. >> >> Or am I trying to approach the problem from the wrong angle? >> >> >> >> On Mon, Feb 16, 2015 at 12:02 PM, Andrey Chudnov >> wrote: >> >>> I use QuichCheck for compiler testing where I generate random, but >>> well-formed programs and check some high-level syntactic properties on >>> results. The QuickCheck instance is open-source (see language-ecmascript), >>> but the compiler-test code is closed-source at this time. Still, I found >>> that it's not the ultimate answer: many properties are hard to formalize, >>> so I have to resort to unit tests. I'm not sure what you mean by "how this >>> would play with test size reduction". I think it's worth giving a try, but >>> keep in mind that you might still need to use unit tests. >>> >>> Let me know if you have any questions. >>> >>> /Andrey >>> >>> >>> On 02/16/2015 11:53 AM, Maurizio Vitale wrote: >>> >>> I'm starting to work on my first real haskell program (I've only RWH >>> exercises under my belt) and wondering whether people use quickcheck at all >>> for compiler testing. >>> >>> I've seen uses of quickcheck for testing parsers, but I'm interested >>> in generating well-formed programs (e.g. random programs with all >>> declarations in reasonable random places). This could be used to test >>> passes other than parsing (or even parsing, for languages that needs to >>> distinguish identifiers, like the 'typedef' problem in C/C++). >>> >>> The only thing I can think of, is to use quickcheck for randomly >>> generating statements, go over them and figure out free variables (incl. >>> functions) and generate declarations in random places for them. But I'm not >>> sure how this would play with test size reduction and doesn't look like a >>> nice solution anyhow. >>> >>> Any idea or pointers to examples? or should I give up on quickcheck >>> for this and just do direct testing? >>> >>> Thanks, >>> >>> Maurizio >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Feb 17 14:56:10 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 17 Feb 2015 21:56:10 +0700 Subject: [Haskell-cafe] Very large data structures in the heap In-Reply-To: References: Message-ID: On Tue, Feb 17, 2015 at 8:26 PM, Dr. Olaf Klinke < o.klinke at dkfz-heidelberg.de> wrote: > On Tue, 17 Feb 2015, Kim-Ee Yeoh wrote: > > >> On Tue, Feb 17, 2015 at 5:05 PM, Dr. Olaf Klinke < >> o.klinke at dkfz-heidelberg.de> wrote: >> I'd like to separate serialization (IO) from traversal of the >> stucture (pure), but how can one avoid the entire heap object from being >> built? Can lazyness be exploited? >> >> >> Something I didn't quite understand from your email is whether >> >> 1. the data structure is being constructed and you'd like it >> simultaneously serialized to disk >> >> or >> >> 2. it's already serialized and you'd like to perform pure traversals on >> it. >> >> Problem 1 is one of compute then write, problem 2 is one of read then >> compute. >> >> Lazy I/O, as in unsafeInterleaveIO, excels at 2. >> >> -- Kim-Ee >> >> >> > Both. > > The data structure is a search tree, which is intended to be used multiple > times, so 1. applies. I guess that the only way to circumvent the memory > bottleneck would be to serialize the part of the structure already > constructed and use the already serialized part for constructing the rest, > somehow without de-serializing it again. > To an extent, the virtual memory of a modern operating system solves the memory bottleneck. I'm curious what you were hoping for when thinking of exploiting laziness. If the search tree is truly huge, you'd probably resort to fancy (or fuzzy or both) algorithms to break up the work. > > 2. also applies. Queries to the search tree traverse different paths of > it, but one can not rule out that multiple queries will eventually have > traversed the entire tree. Thus lazily de-serializing it may not be enough > unless the garbage collector disposes of parts of the tree after each > query. Which it won't, if we say something like this: > > search :: FilePath -> IO (Query -> Result) > search treeOnDisk = do > searchtree <- decodeFile treeOnDisk > return (\query -> searchFor query searchtree) > No, gc _will_ reclaim memory if decodeFile uses unsafeInterleaveIO. Take a look at the lazy bytestrings package. p.s. Your search function looks odd. Surely you mean something with the type signature: FilePath -> Query -> IO Result ? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Feb 17 18:55:05 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 18 Feb 2015 01:55:05 +0700 Subject: [Haskell-cafe] Haskell Weekly News Message-ID: Welcome. Here are this week's picks: - Scott Turner proffered a solution in getting exponentiation of complex numbers right, which includes an at-a-glance table to see if everything's sane. - GHC is unsound! It has a type safety leak. Iavor Diatchki is hard at work plugging the hole. - Richard Eisenberg discovered that Debug.Trace.traceStack does a better job debugging GHC than pprTrace. - The curtain is pulled back on the new face of www.haskell.org. Chris Done designed it, Gershom Bazerman announced it, and unsung heroes migrated it and kept it running under the flash crowd onslaught. The raves include: - This is far more welcoming and user-friendly, especially to those who might be curious about Haskell. [link] - The website redesign is great from a new programmer's perspective. I just started learning Haskell a week ago, and I wish this was the first thing I saw. Looks wonderful. Cheers! [link] - This new, awesome site is using the framework Yesod, which is kinda like the Rails of the Haskell world, only it can do rad stuff like prevent XSS and 404s at *compile *time. Yes, you read that right. [link] - Repo of the week: Samuel G?lineau's hawk , a haskell command-line text-processor similar to unix awk. Quotes of the week: - "I have made several forays into the impredicative swamp, and barely made it back to the shore alive." - Simon Peyton Jones - "Web programming is like a mature RPG: everything's extremely complicated and everyone's overpowered." - Max Goldstein Tweets: - In Buenos Aires, Marcote Torres tweets about the first ever Haskell meetup. - And "In Soviet Russia, #haskell learns a you" as @aberls reminds us. Got a letter to the editor? Hit reply. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrz.vtl at gmail.com Tue Feb 17 22:33:02 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Tue, 17 Feb 2015 17:33:02 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing In-Reply-To: References: <54E222A8.6020004@gmail.com> <54E23A7E.30506@gmail.com> Message-ID: also a longer thesis (which I believe is the backtracking optimization they refer to in the paper) is at http://publications.lib.chalmers.se/records/fulltext/157525.pdf I'll have to play with a very small language and see where I get. Thanks to everybody, and if there're other examples around I'll be glad to know about them. On Tue, Feb 17, 2015 at 3:15 AM, Paul Brauner wrote: > There's a recent paper by Jonas Dureg?rd et al where they introduce a > variant of feat that allows for efficient discarding of unwanted values, ? > la lazy Smallcheck. The motivating example of the paper is exactly what > you're looking for: discarding ill-formed programs. > > On Mon, Feb 16, 2015, 19:44 Andrey Chudnov wrote: > >> If you just need an example for generating and shrinking arbitrary ASTs, >> you can have a look here: >> https://github.com/jswebtools/language-ecmascript/blob/master/src/Language/ECMAScript3/Syntax/Arbitrary.hs >> . Note that I use the testing-feat package to generate Gen instances --- it >> tends to do better (explore interesting cases earlier) than handwritten >> code --- and then fix-up incorrect ASTs (another option is to simply >> discard them). >> >> >> On 02/16/2015 12:33 PM, Maurizio Vitale wrote: >> >> By 'test size reduction' I mean the 'shrink' function. It seems to me (as >> I said, first Haskell program and no experience with quickcheck) that it >> works nicely with a topdown generation of the test, but I don't see how to >> easily generate correct programs that way. >> >> Even if you cannot release your tests, maybe you can help me with a >> very simple case. Consider a trivial AST. A program is a possibly nested >> block. Each block is a bunch of declarations of variables and some use of >> them >> >> data Block = Block [Declaration] [Statement] >> >> data Declaration = Var String String >> >> data Statement = Statement Block | Use String >> >> >> How one would generate things like: >> >> Block [Var "a" "int"] [Use "a"] -- here a is declared in the same block >> >> Block [] [Statement Block [Var "s" "int"] [Statement Block [] [Use >> "s"]]] -- here s is declared in some other visible scope >> >> >> etc. >> >> Or am I trying to approach the problem from the wrong angle? >> >> >> >> On Mon, Feb 16, 2015 at 12:02 PM, Andrey Chudnov >> wrote: >> >>> I use QuichCheck for compiler testing where I generate random, but >>> well-formed programs and check some high-level syntactic properties on >>> results. The QuickCheck instance is open-source (see language-ecmascript), >>> but the compiler-test code is closed-source at this time. Still, I found >>> that it's not the ultimate answer: many properties are hard to formalize, >>> so I have to resort to unit tests. I'm not sure what you mean by "how this >>> would play with test size reduction". I think it's worth giving a try, but >>> keep in mind that you might still need to use unit tests. >>> >>> Let me know if you have any questions. >>> >>> /Andrey >>> >>> >>> On 02/16/2015 11:53 AM, Maurizio Vitale wrote: >>> >>> I'm starting to work on my first real haskell program (I've only RWH >>> exercises under my belt) and wondering whether people use quickcheck at all >>> for compiler testing. >>> >>> I've seen uses of quickcheck for testing parsers, but I'm interested >>> in generating well-formed programs (e.g. random programs with all >>> declarations in reasonable random places). This could be used to test >>> passes other than parsing (or even parsing, for languages that needs to >>> distinguish identifiers, like the 'typedef' problem in C/C++). >>> >>> The only thing I can think of, is to use quickcheck for randomly >>> generating statements, go over them and figure out free variables (incl. >>> functions) and generate declarations in random places for them. But I'm not >>> sure how this would play with test size reduction and doesn't look like a >>> nice solution anyhow. >>> >>> Any idea or pointers to examples? or should I give up on quickcheck >>> for this and just do direct testing? >>> >>> Thanks, >>> >>> Maurizio >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekirpichov at gmail.com Wed Feb 18 05:04:40 2015 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Wed, 18 Feb 2015 05:04:40 +0000 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? Message-ID: Hello haskell-cafe, Let me repost here a question I posted to cstheory stackexchange - in hopes that there are more type theory experts here. http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks Perhaps the main source of performance problems in Haskell is when a program inadvertently builds up a thunk of unbounded depth - this causes both a memory leak and a potential stack overflow when evaluating. The classic example is defining sum = foldr (+) 0 in Haskell. Are there any type systems which statically enforce lack of such thunks in a program using a lazy language? Seems like this should be on the same order of difficulty as proving other static program properties using type system extensions, e.g. some flavors of thread safety or memory safety. -------------- next part -------------- An HTML attachment was scrubbed... URL: From atzeus at gmail.com Wed Feb 18 06:24:47 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Wed, 18 Feb 2015 07:24:47 +0100 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: References: Message-ID: See the paper "copatterns" by andreas abel. Cheers! Atze On Feb 18, 2015 6:04 AM, "Eugene Kirpichov" wrote: > Hello haskell-cafe, > > Let me repost here a question I posted to cstheory stackexchange - in > hopes that there are more type theory experts here. > > > http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks > > Perhaps the main source of performance problems in Haskell is when a > program inadvertently builds up a thunk of unbounded depth - this causes > both a memory leak and a potential stack overflow when evaluating. The > classic example is defining sum = foldr (+) 0 in Haskell. > > Are there any type systems which statically enforce lack of such thunks in > a program using a lazy language? > > Seems like this should be on the same order of difficulty as proving other > static program properties using type system extensions, e.g. some flavors > of thread safety or memory safety. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atzeus at gmail.com Wed Feb 18 06:32:39 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Wed, 18 Feb 2015 07:32:39 +0100 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: References: Message-ID: I'm not awake yet. That paper is not what you asked at all. I'm not aware of any paper that presents a type system statically ruling out thunks of unbounded depth, but it seems to me like this indeed should be possible. On Feb 18, 2015 7:24 AM, "Atze van der Ploeg" wrote: > See the paper "copatterns" by andreas abel. > > Cheers! > > Atze > On Feb 18, 2015 6:04 AM, "Eugene Kirpichov" wrote: > >> Hello haskell-cafe, >> >> Let me repost here a question I posted to cstheory stackexchange - in >> hopes that there are more type theory experts here. >> >> >> http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks >> >> Perhaps the main source of performance problems in Haskell is when a >> program inadvertently builds up a thunk of unbounded depth - this causes >> both a memory leak and a potential stack overflow when evaluating. The >> classic example is defining sum = foldr (+) 0 in Haskell. >> >> Are there any type systems which statically enforce lack of such thunks >> in a program using a lazy language? >> >> Seems like this should be on the same order of difficulty as proving >> other static program properties using type system extensions, e.g. some >> flavors of thread safety or memory safety. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Feb 18 07:50:17 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 18 Feb 2015 09:50:17 +0200 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: References: Message-ID: <54E44439.5070304@ro-che.info> Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its problem is that it's not tail-recursive. foldl (+) 0 would be an example of a laziness issue. If you want to specify which functions should or shouldn't be used in a lazy context, take a look at polarity (see Harper's Practical Foundations for Programming Languages). So you could say, for instance, that it doesn't make sense to use + in a lazy context; that'd eliminate half the cases of laziness-induced memory leaks in practice. If instead you want to impose some upper bound on the memory consumption without caring about specific cases, then see this ICFP'12 paper: http://www.dcc.fc.up.pt/~pbv/AALazyExtended.pdf On 18/02/15 07:04, Eugene Kirpichov wrote: > Hello haskell-cafe, > > Let me repost here a question I posted to cstheory stackexchange - in > hopes that there are more type theory experts here. > > http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks > > Perhaps the main source of performance problems in Haskell is when a > program inadvertently builds up a thunk of unbounded depth - this causes > both a memory leak and a potential stack overflow when evaluating. The > classic example is defining sum = foldr (+) 0 in Haskell. > > Are there any type systems which statically enforce lack of such thunks > in a program using a lazy language? > > Seems like this should be on the same order of difficulty as proving > other static program properties using type system extensions, e.g. some > flavors of thread safety or memory safety. From haskell at marcelfourne.de Wed Feb 18 13:47:30 2015 From: haskell at marcelfourne.de (Marcel =?UTF-8?B?Rm91cm7DqQ==?=) Date: Wed, 18 Feb 2015 14:47:30 +0100 Subject: [Haskell-cafe] cryptography in haskell In-Reply-To: <20150217104312.0940bbd3@rechner> References: <54D63B85.3020403@posteo.de> <20150217104312.0940bbd3@rechner> Message-ID: <20150218144730.496ef698@rechner> Am Tue, 17 Feb 2015 10:43:12 +0100 schrieb Marcel Fourn?: >Am Sat, 7 Feb 2015 11:53:42 -0500 schrieb Patrick Mylund Nielsen: >>In other words, Haskell eliminates several classes of errors, but >>doesn't prevent logic errors, and can do nothing about poor standards. >> >>Aside from this, I think the main issues would be: >> >> - Timing resistance: This is not as simple as sprinkling some >> bitwise >>operations on your crypto code. It took a long time to figure out even >>the basics in OpenSSL, and for better and worse it's more difficult to >>intuit what your Haskell code will be compiled to than it is with C >>(though C compilers have been known to optimize away constant-time >>code.) >[...] >(3) No branches based on the content of bits of the secret key. Basically, an encoding of the advice[0] Peter Schwabe gave at ShmooCon 2015 for C-like languages translate well to Haskell, but having typecheckable timing attack resistance would be nicer. Cheers, Marcel Fourn? [0]:https://cryptojedi.org/peter/data/shmoocon-20150118.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From joehillen at gmail.com Wed Feb 18 15:40:11 2015 From: joehillen at gmail.com (Joe Hillenbrand) Date: Wed, 18 Feb 2015 07:40:11 -0800 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: <54E44439.5070304@ro-che.info> References: <54E44439.5070304@ro-che.info> Message-ID: Is foldl = foldl' ever going to happen? On Tue, Feb 17, 2015 at 11:50 PM, Roman Cheplyaka wrote: > Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its > problem is that it's not tail-recursive. > > foldl (+) 0 would be an example of a laziness issue. > > If you want to specify which functions should or shouldn't be used in a > lazy context, take a look at polarity (see Harper's Practical > Foundations for Programming Languages). So you could say, for instance, > that it doesn't make sense to use + in a lazy context; that'd eliminate > half the cases of laziness-induced memory leaks in practice. > > If instead you want to impose some upper bound on the memory consumption > without caring about specific cases, then see this ICFP'12 paper: > http://www.dcc.fc.up.pt/~pbv/AALazyExtended.pdf > > On 18/02/15 07:04, Eugene Kirpichov wrote: > > Hello haskell-cafe, > > > > Let me repost here a question I posted to cstheory stackexchange - in > > hopes that there are more type theory experts here. > > > > > http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks > > > > Perhaps the main source of performance problems in Haskell is when a > > program inadvertently builds up a thunk of unbounded depth - this causes > > both a memory leak and a potential stack overflow when evaluating. The > > classic example is defining sum = foldr (+) 0 in Haskell. > > > > Are there any type systems which statically enforce lack of such thunks > > in a program using a lazy language? > > > > Seems like this should be on the same order of difficulty as proving > > other static program properties using type system extensions, e.g. some > > flavors of thread safety or memory safety. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Feb 18 19:46:16 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 18 Feb 2015 19:46:16 +0000 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! Message-ID: Hi friends, Last night I was having a good natter with Chris Done, and the topic of idiom brackets came up. Specifically, Chris' hindent and structured-haskell-mode tools have both recently become aware of the quasiquoter in applicative-quoters - allowing one to write ordinary Haskell code but have it formatted/edited as if it wasn't even inside a quasiquoter. However, it's a shame that Chris has to now be aware of this specific quasiquoter just to get his tools to work properly. Furthermore, it's a shame that *everyone* has to do the same whenever they want to manipulate Haskell code. That said, idiom brackets - at least to me - appears to be a very desirable syntax extension. A recent desire for this came to me while working with reactive-banana. As almost everything "interesting" is even an Event or a Behavior, there tends to be a lot of assembling programs with applicative syntax. Another obvious example is when using parser combinators. Therefore, I'd like to propose that we teach GHC about this desugaring, properly. Now, how we do that, and in fact, what I'm even proposing... that's all up for discussion! I spoke briefly with David Christiansen and a few others in the Idris IRC channel last night about their particular variation of idiom brackets, and it seems people are generally happy with that. Copying that almost verbatim is probably the first proposal I'd put forward. This is the first time I've proposed an extension to GHC, so I'll need some guidance to make this happen - both in terms of guiding the discussion through to a proposal, but ultimately implementing it. Perhaps the proposal will be ready for ZuriHac, and some GHC devs could help me work on it there. Anyway, that's enough rambling from me. I would love to hear your thoughts - do you think idiom brackets are a good idea? Do you have a particular tricky case that you think they need to support? I'm all ears. -- Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliot.cameron at covenanteyes.com Wed Feb 18 20:20:32 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Wed, 18 Feb 2015 15:20:32 -0500 (EST) Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: Message-ID: <677447498.6868167.1424290832048.JavaMail.root@covenanteyes.com> As a beginner Haskeller, I think my perspective might be surprising: I actually think idiom brackets would make learning and understanding Haskell *easier* for new-comers. Applicative code is intimidating to read for beginners and I have often been afraid to use it because it all seems so magical (lots of strange operators between everything!). But when I read the papers and saw idiom brackets, I suddenly realized that the whole idea was actually pretty simple! I've been pushing for them ever since. ----- Original Message ----- From: "Oliver Charles" To: "Haskell Cafe" Sent: Wednesday, February 18, 2015 2:46:16 PM Subject: [Haskell-cafe] Let's teach GHC idiom brackets! Hi friends, Last night I was having a good natter with Chris Done, and the topic of idiom brackets came up. Specifically, Chris' hindent and structured-haskell-mode tools have both recently become aware of the quasiquoter in applicative-quoters - allowing one to write ordinary Haskell code but have it formatted/edited as if it wasn't even inside a quasiquoter. However, it's a shame that Chris has to now be aware of this specific quasiquoter just to get his tools to work properly. Furthermore, it's a shame that everyone has to do the same whenever they want to manipulate Haskell code. That said, idiom brackets - at least to me - appears to be a very desirable syntax extension. A recent desire for this came to me while working with reactive-banana. As almost everything "interesting" is even an Event or a Behavior, there tends to be a lot of assembling programs with applicative syntax. Another obvious example is when using parser combinators. Therefore, I'd like to propose that we teach GHC about this desugaring, properly. Now, how we do that, and in fact, what I'm even proposing... that's all up for discussion! I spoke briefly with David Christiansen and a few others in the Idris IRC channel last night about their particular variation of idiom brackets, and it seems people are generally happy with that. Copying that almost verbatim is probably the first proposal I'd put forward. This is the first time I've proposed an extension to GHC, so I'll need some guidance to make this happen - both in terms of guiding the discussion through to a proposal, but ultimately implementing it. Perhaps the proposal will be ready for ZuriHac, and some GHC devs could help me work on it there. Anyway, that's enough rambling from me. I would love to hear your thoughts - do you think idiom brackets are a good idea? Do you have a particular tricky case that you think they need to support? I'm all ears. -- Ollie _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Feb 18 20:30:17 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 18 Feb 2015 15:30:17 -0500 Subject: [Haskell-cafe] quickcheck for compiler testing Message-ID: <201502182030.t1IKUHhS001473@coolidge.cs.dartmouth.edu> >> I'm ... wondering whether people use quickcheck at all for >> compiler testing. > it's worth giving a try, but keep in mind that you might still > need to use unit tests If your compiler is for a widely used language, you might consider a hybrid approach due to Bill McKeeman: generate random code and check it by automated crowd-sourcing. The crowd is a jury of other compilers, not necessarily even for the same hardware. The check is to compare compilability, compile time, run time and run results against those of the jury. McKeeman used a generative grammar whose productions were adjustably weighted to influence the characteristics of the generated code. Over the course of several months of overnight runs torturing a production C compiler, he turned up something like one anomaly per day, excluding jury errors and extra reports from a common root cause. (One amusing find was that the compiler took Omega(INT_MAX) time to evaluate the constant expression 1< Hi, I'd like to use QuickCheck to test polymorphic properties and I'm wondering if there's any community consenus on how to do this while avoiding creating large amounts of boilerplate test code. As an example, suppose I have this simple simplistic Monoid typeclass: class Monoid a where zero :: a (|+|) :: a -> a -> a And suppose I make these types Monoid instances: instance Monoid Integer where zero = 0 (|+|) = (+) instance Monoid Rational where zero = 0 (|+|) = (+) instance (Monoid a, Monoid b) => Monoid (a, b) where zero = (zero, zero) (|+|) (x, y) (u, v) = (x |+| u, y |+| v) Using QuickCheck and the Tasty test framework I'd like to test the Monoid laws across the relevant types (I'm only showing one part of one law here) as QuickCheck properties: prop_left_add_id :: (Eq a, Monoid a) => a -> Bool prop_left_add_id x = zero |+| x == x monoid_suite :: TestTree monoid_suite = testGroup "monoid" [ testProperty "left additive identity (Integer)" (prop_left_add_id :: Integer -> Bool), testProperty "left additive identity (Rational)" (prop_left_add_id :: Rational -> Bool), testProperty "left additive identity ((Integer, Integer))" (prop_left_add_id :: (Integer, Integer) -> Bool), -- ...] And this is where I start creating a lot of essentially boilerplate code. I'm wondering if there's any consensus on the way to go about this kind of testing? Researching this issue I've found ways of combining various GHC extensions and the type system to (I think) write the properties more at the type level. There are QuickCheck and Tasty modules that aim to find all properties in a module and test them, but polymorphic properties are automatically defaulted to Integer arguments. I'm also tempted by Template Haskell to write what's essentially code generation templates. Is there a better way to go about this? Thanks, Stu From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Feb 18 20:50:01 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 18 Feb 2015 20:50:01 +0000 Subject: [Haskell-cafe] Testing polymorphic properties with QuickCheck In-Reply-To: References: Message-ID: <20150218205001.GS22249@weber> On Thu, Feb 19, 2015 at 07:41:25AM +1100, Stuart Hungerford wrote: > prop_left_add_id :: (Eq a, Monoid a) => a -> Bool > prop_left_add_id x = zero |+| x == x > > monoid_suite :: TestTree > monoid_suite = testGroup "monoid" [ > testProperty "left additive identity (Integer)" > (prop_left_add_id :: Integer -> Bool), > > testProperty "left additive identity (Rational)" > (prop_left_add_id :: Rational -> Bool), > > testProperty "left additive identity ((Integer, Integer))" > (prop_left_add_id :: (Integer, Integer) -> Bool), > -- ...] I'm not quite sure what you're asking specifically, but maybe this will help: {-# LANGUAGE ScopedTypeVariables #-} monoid_suite :: forall m. (Eq m, Monoid m) => String -> Proxy m -> TestTree monoid_suite typename _ = testGroup "monoid" [ testProperty ("left additive identity (" ++ typename ++ ")") (prop_left_add_id :: m -> Bool), ... ] monoid_suite_integer :: TestTree monoid_suite_integer = monoid_suite "Integer" (Proxy :: Integer) monoid_suite_rational :: TestTree monoid_suite_rational = monoid_suite "Rational" (Proxy :: Rational) monoid_suite_pair :: TestTree monoid_suite_pair = monoid_suite "(Integer, Integer)" (Proxy :: (Integer, Integer)) From mike at izbicki.me Wed Feb 18 21:04:54 2015 From: mike at izbicki.me (Mike Izbicki) Date: Wed, 18 Feb 2015 13:04:54 -0800 Subject: [Haskell-cafe] Testing polymorphic properties with QuickCheck In-Reply-To: References: Message-ID: I agree that this is a huge pain. I've been working on an alternative numeric hierarchy, and as part of that I've wanted a completely automated test suite. What I've done is use template haskell to write boilerplate code for me. Currently, I am verifying around 1000 quickcheck properties, all of which are automatically generated. I suspect that by the time I finish the final number of properties will be between 10000-100000, so full automation for this is a must! Here's a file-by-file breakdown of how it works: ---- https://github.com/mikeizbicki/subhask/blob/master/test/TestSuite.hs This file defines the actual tests. You specify a type to test, and then the template haskell figures out all of the classes it's an instance of and runs the appropriate tests on that type. Eventually, I'd like to automate this a bit more so that you don't have to manually specify types to test, and the template haskell will determine that as well. ---- https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/Algebra.hs Here's the code for the classes. Notice that for each class I've created functions beginning with law_, defn_ or theorem_ that define the required properties of the class. These are the tests that will get automatically run on an instance of that class to verify it obeys the laws. The prefix differences don't mean anything special to my generating code yet. Eventually, I'd like to create a "fast" test suite for quick development and a "thorough" test suite to run before releases, in which case there would be a difference between these prefixes. ---- https://github.com/mikeizbicki/subhask/blob/master/src/SubHask/TemplateHaskell/Test.hs Then I have a bunch of template haskell code to generate test cases automatically from the law_/defn_/theorem_ functions. The `testmap` variable contains all the tests that apply to each class. In theory, this can be generated automatically, however, template haskell isn't yet powerful enough to do this (https://ghc.haskell.org/trac/ghc/ticket/9699). On Wed, Feb 18, 2015 at 12:41 PM, Stuart Hungerford wrote: > Hi, > > I'd like to use QuickCheck to test polymorphic properties and I'm > wondering if there's any community consenus on how to do this while > avoiding creating large amounts of boilerplate test code. > > As an example, suppose I have this simple simplistic Monoid typeclass: > > class Monoid a where > zero :: a > (|+|) :: a -> a -> a > > And suppose I make these types Monoid instances: > > > instance Monoid Integer where > zero = 0 > (|+|) = (+) > > instance Monoid Rational where > zero = 0 > (|+|) = (+) > > instance (Monoid a, Monoid b) => Monoid (a, b) where > zero = (zero, zero) > (|+|) (x, y) (u, v) = (x |+| u, y |+| v) > > > Using QuickCheck and the Tasty test framework I'd like to test the > Monoid laws across the relevant types (I'm only showing one part of > one law here) as QuickCheck properties: > > > prop_left_add_id :: (Eq a, Monoid a) => a -> Bool > prop_left_add_id x = zero |+| x == x > > monoid_suite :: TestTree > monoid_suite = testGroup "monoid" [ > testProperty "left additive identity (Integer)" > (prop_left_add_id :: Integer -> Bool), > > testProperty "left additive identity (Rational)" > (prop_left_add_id :: Rational -> Bool), > > testProperty "left additive identity ((Integer, Integer))" > (prop_left_add_id :: (Integer, Integer) -> Bool), > -- ...] > > > And this is where I start creating a lot of essentially boilerplate > code. I'm wondering if there's any consensus on the way to go about > this kind of testing? > > Researching this issue I've found ways of combining various GHC > extensions and the type system to (I think) write the properties more > at the type level. There are QuickCheck and Tasty modules that aim to > find all properties in a module and test them, but polymorphic > properties are automatically defaulted to Integer arguments. I'm also > tempted by Template Haskell to write what's essentially code > generation templates. > > Is there a better way to go about this? > > Thanks, > > Stu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From tikhon at jelv.is Wed Feb 18 21:15:00 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Wed, 18 Feb 2015 13:15:00 -0800 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: <677447498.6868167.1424290832048.JavaMail.root@covenanteyes.com> References: <677447498.6868167.1424290832048.JavaMail.root@covenanteyes.com> Message-ID: You can play around with idiom brackets now using the Strathclyde Haskell Enhancement (SHE)[1]. It's pretty easy to configure and will give you a good feel for how the feature behaves in practice. I haven't used Idris, and the syntax looks a bit different[2], but I suspect they're pretty similar in capability. If not, I'd love to see how they differ in detail. Personally, I'm definitely in favor of idiom brackets or similar syntax abstractly. That said, I tried using SHE's idiom brackets in some of my own existing code and was a bit underwhelmed. They're certainly an improvement for simpler cases, especially ones using operators, but fall apart quickly for more complex expressions. Now, I might have been using them incorrectly, but I found it awkward to express code that used both normal *and* Applicative application at the same time... which proved to be about half of all my code using Applicative operators. Common cases like `f <$> g x <*> h y` are a bit tricky, and they completely hose the $ operator. Now, I didn't spend much time or effort trying to make idiom brackets work, so I'm certainly not saying that they're unworkable. A good start for the proposal would be to examine more complex cases and idioms present in real code and how idiom brackets would?or wouldn't?improve them. Idris likely has some more interesting examples to start from, but there are probably enough differences in both the language and common idioms to make specific Haskell examples necessary. Adding idiom brackets to some of your own code, or code from some open source projects, would be a good way to both find relevant examples and refine the whole proposal. -tikhon On Wed, Feb 18, 2015 at 12:20 PM, Elliot Cameron < elliot.cameron at covenanteyes.com> wrote: > As a beginner Haskeller, I think my perspective might be surprising: I > actually think idiom brackets would make learning and understanding Haskell > *easier* for new-comers. Applicative code is intimidating to read for > beginners and I have often been afraid to use it because it all seems so > magical (lots of strange operators between everything!). But when I read > the papers and saw idiom brackets, I suddenly realized that the whole idea > was actually pretty simple! I've been pushing for them ever since. > > ------------------------------ > *From: *"Oliver Charles" > *To: *"Haskell Cafe" > *Sent: *Wednesday, February 18, 2015 2:46:16 PM > *Subject: *[Haskell-cafe] Let's teach GHC idiom brackets! > > > Hi friends, > > Last night I was having a good natter with Chris Done, and the topic of > idiom brackets came up. Specifically, Chris' hindent and > structured-haskell-mode tools have both recently become aware of the > quasiquoter in applicative-quoters > - allowing one > to write ordinary Haskell code but have it formatted/edited as if it wasn't > even inside a quasiquoter. However, it's a shame that Chris has to now be > aware of this specific quasiquoter just to get his tools to work properly. > Furthermore, it's a shame that *everyone* has to do the same whenever > they want to manipulate Haskell code. > > That said, idiom brackets - at least to me - appears to be a very > desirable syntax extension. A recent desire for this came to me while > working with reactive-banana. As almost everything "interesting" is even an > Event or a Behavior, there tends to be a lot of assembling programs with > applicative syntax. Another obvious example is when using parser > combinators. > > Therefore, I'd like to propose that we teach GHC about this desugaring, > properly. > > Now, how we do that, and in fact, what I'm even proposing... that's all up > for discussion! I spoke briefly with David Christiansen and a few others in > the Idris IRC channel last night about their particular variation of idiom > brackets, and it seems people are generally happy with that. Copying that > almost verbatim is probably the first proposal I'd put forward. > > This is the first time I've proposed an extension to GHC, so I'll need > some guidance to make this happen - both in terms of guiding the discussion > through to a proposal, but ultimately implementing it. Perhaps the proposal > will be ready for ZuriHac, and some GHC devs could help me work on it there. > > Anyway, that's enough rambling from me. I would love to hear your thoughts > - do you think idiom brackets are a good idea? Do you have a particular > tricky case that you think they need to support? I'm all ears. > > -- Ollie > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Wed Feb 18 21:32:04 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 18 Feb 2015 16:32:04 -0500 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: <677447498.6868167.1424290832048.JavaMail.root@covenanteyes.com> Message-ID: On Wed, Feb 18, 2015 at 4:15 PM, Tikhon Jelvis wrote: > > That said, I tried using SHE's idiom brackets in some of my own existing > code and was a bit underwhelmed. They're certainly an improvement for > simpler cases, especially ones using operators, but fall apart quickly for > more complex expressions. > My experience with them is pretty close to Tikhon's here, so I'm pretty much neutral on whether we go ahead and do this. Idiom brackets seem to have some strident supporters, I just have never personally had a case where I worked through what the idiom bracket version was and found the result appreciably clearer. When you need to mix in joins and regular application it gets quite messy. -Edward -tikhon > > On Wed, Feb 18, 2015 at 12:20 PM, Elliot Cameron < > elliot.cameron at covenanteyes.com> wrote: > >> As a beginner Haskeller, I think my perspective might be surprising: I >> actually think idiom brackets would make learning and understanding Haskell >> *easier* for new-comers. Applicative code is intimidating to read for >> beginners and I have often been afraid to use it because it all seems so >> magical (lots of strange operators between everything!). But when I read >> the papers and saw idiom brackets, I suddenly realized that the whole idea >> was actually pretty simple! I've been pushing for them ever since. >> >> ------------------------------ >> *From: *"Oliver Charles" >> *To: *"Haskell Cafe" >> *Sent: *Wednesday, February 18, 2015 2:46:16 PM >> *Subject: *[Haskell-cafe] Let's teach GHC idiom brackets! >> >> >> Hi friends, >> >> Last night I was having a good natter with Chris Done, and the topic of >> idiom brackets came up. Specifically, Chris' hindent and >> structured-haskell-mode tools have both recently become aware of the >> quasiquoter in applicative-quoters >> - allowing one >> to write ordinary Haskell code but have it formatted/edited as if it wasn't >> even inside a quasiquoter. However, it's a shame that Chris has to now be >> aware of this specific quasiquoter just to get his tools to work properly. >> Furthermore, it's a shame that *everyone* has to do the same whenever >> they want to manipulate Haskell code. >> >> That said, idiom brackets - at least to me - appears to be a very >> desirable syntax extension. A recent desire for this came to me while >> working with reactive-banana. As almost everything "interesting" is even an >> Event or a Behavior, there tends to be a lot of assembling programs with >> applicative syntax. Another obvious example is when using parser >> combinators. >> >> Therefore, I'd like to propose that we teach GHC about this desugaring, >> properly. >> >> Now, how we do that, and in fact, what I'm even proposing... that's all >> up for discussion! I spoke briefly with David Christiansen and a few others >> in the Idris IRC channel last night about their particular variation of >> idiom brackets, and it seems people are generally happy with that. Copying >> that almost verbatim is probably the first proposal I'd put forward. >> >> This is the first time I've proposed an extension to GHC, so I'll need >> some guidance to make this happen - both in terms of guiding the discussion >> through to a proposal, but ultimately implementing it. Perhaps the proposal >> will be ready for ZuriHac, and some GHC devs could help me work on it there. >> >> Anyway, that's enough rambling from me. I would love to hear your >> thoughts - do you think idiom brackets are a good idea? Do you have a >> particular tricky case that you think they need to support? I'm all ears. >> >> -- Ollie >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.dijk.bas at gmail.com Wed Feb 18 21:41:50 2015 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed, 18 Feb 2015 22:41:50 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: Message-ID: Do we still need idiom brackets if we have ApplicativeDo? https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo Cheers, Bas On 18 February 2015 at 20:46, Oliver Charles wrote: > Hi friends, > > Last night I was having a good natter with Chris Done, and the topic of > idiom brackets came up. Specifically, Chris' hindent and > structured-haskell-mode tools have both recently become aware of the > quasiquoter in applicative-quoters - allowing one to write ordinary Haskell > code but have it formatted/edited as if it wasn't even inside a quasiquoter. > However, it's a shame that Chris has to now be aware of this specific > quasiquoter just to get his tools to work properly. Furthermore, it's a > shame that everyone has to do the same whenever they want to manipulate > Haskell code. > > That said, idiom brackets - at least to me - appears to be a very desirable > syntax extension. A recent desire for this came to me while working with > reactive-banana. As almost everything "interesting" is even an Event or a > Behavior, there tends to be a lot of assembling programs with applicative > syntax. Another obvious example is when using parser combinators. > > Therefore, I'd like to propose that we teach GHC about this desugaring, > properly. > > Now, how we do that, and in fact, what I'm even proposing... that's all up > for discussion! I spoke briefly with David Christiansen and a few others in > the Idris IRC channel last night about their particular variation of idiom > brackets, and it seems people are generally happy with that. Copying that > almost verbatim is probably the first proposal I'd put forward. > > This is the first time I've proposed an extension to GHC, so I'll need some > guidance to make this happen - both in terms of guiding the discussion > through to a proposal, but ultimately implementing it. Perhaps the proposal > will be ready for ZuriHac, and some GHC devs could help me work on it there. > > Anyway, that's enough rambling from me. I would love to hear your thoughts - > do you think idiom brackets are a good idea? Do you have a particular tricky > case that you think they need to support? I'm all ears. > > -- Ollie > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From stuart.hungerford at gmail.com Wed Feb 18 21:50:18 2015 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Thu, 19 Feb 2015 08:50:18 +1100 Subject: [Haskell-cafe] Testing polymorphic properties with QuickCheck In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 8:04 AM, Mike Izbicki wrote: > I agree that this is a huge pain. I've been working on an alternative > numeric hierarchy, and as part of that I've wanted a completely > automated test suite. What I've done is use template haskell to write > boilerplate code for me. Currently, I am verifying around 1000 > quickcheck properties, all of which are automatically generated. I > suspect that by the time I finish the final number of properties will > be between 10000-100000, so full automation for this is a must! > > Here's a file-by-file breakdown of how it works: Many thanks for this excellent introduction--I'll check this approach (and the heirarchy) out. Stu From mokus at deepbondi.net Wed Feb 18 22:08:37 2015 From: mokus at deepbondi.net (James Cook) Date: Wed, 18 Feb 2015 14:08:37 -0800 Subject: [Haskell-cafe] How to force James Cook (author of dependent-map) evaluation? In-Reply-To: References: Message-ID: <2E7EA7C3-B08B-45B2-A156-734C21E505DB@deepbondi.net> Sorry, as Dominic mentioned I have been quite busy in recent years and it's hard to keep up with e-mail sometimes. I'm happy to get this particular issue fixed, but I don't have a whole lot of time to chase down the details. In particular, I'd like to make sure the patch doesn't break building on older versions of GHC (or, depending on the versions it breaks, at least make sure the cabal file doesn't claim to work when it doesn't). I can take a look at this sometime soon, but if you happen to be able to track down info on which versions of GHC support the syntax you changed to, I can make the needed changes a bit sooner (or merge as-is, whichever is appropriate). -- James > On Jan 27, 2015, at 2:01 AM, Alexey Uimanov wrote: > > Hello people. There is a pull request https://github.com/mokus0/dependent-map/pull/2 which I need to be on hackage. I have sent a email to mokus at deepbondi.net but nothing happened. > > Does anyone can contact with James and tell him about my problem? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From Henrik.Nilsson at nottingham.ac.uk Wed Feb 18 22:13:26 2015 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Wed, 18 Feb 2015 22:13:26 +0000 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: <677447498.6868167.1424290832048.JavaMail.root@covenanteyes.com> Message-ID: <54E50E86.7030002@nottingham.ac.uk> Edward Kmett wrote: > My experience with them is pretty close to Tikhon's here, so I'm > pretty much neutral on whether we go ahead and do this. Idiom > brackets seem to have some strident supporters, I just have never > personally had a case where I worked through what the idiom bracket > version was and found the result appreciably clearer. When you need > to mix in joins and regular application it gets quite messy. I agree. I've written quite a lot of applicative code (very) long before it was even called applicative, and I never found it particularly burdensome to be explicit. On the other hand, I'd say being able to easily mix regular application and join is essential. > Do we still need idiom brackets if we have ApplicativeDo? Wasn't aware of this proposal, but I must say it does look rather verbose compared to the explicit version, so nothing gained in that sense, and, more importantly, it obscures the key point of applicative: that arguments *cannot* depend on each other. So from that perspective, if yet more special syntax must be introduced, idiom brackets would seem preferable. But personally, I'd rather there was no more special syntax unless it truly makes a difference, like for monads and (even more so) arrows. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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 chrisdone at gmail.com Thu Feb 19 00:24:26 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 01:24:26 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: Message-ID: Adding context from what brought me to start thinking about using idioms: * I'm tired of writing (and reading) the awkward f <$> z <*> y <*> z pattern. * It's a pain with editor support and pretty printing (which is a solvable problem, but not the kind of problem I'd like to solve). * It feels like using >> and >>= for monads instead of do-notation. * The [i|?|] idiom quasi-quoter seems like it can solve these issues for me. So I've started trying it out on future codebases. Naturally I added support in SHM and hindent which reduces this pattern down to basic function application, which is great for editing and reading. The more function arguments, the more of a saving this is. Here's a fair comparison of before/after on my ace package's parser: https://github.com/chrisdone/ace/commit/36767780ca356db75468f803b0c91388186c0441 I say it's fair because this example involves mostly a low number of arguments, but a couple larger ones with obvious savings. (But I'm the kinda guy who writes do x; y instead of x >> y.) The more pathological examples come from e.g. writing JSON/Binary instances or formlets or optparse-applicative things, which regularly have >5 arguments. Pros for the template-haskell-based quasi-quoter: * It doesn't seem to add any noticeable compiling overhead to this large module (see commit message for timings). Cons: * Nesting is not supported by quasi-quoters. * Currently it lacks the Alternative support as proposed by Conor. That would look like this: [i|TopicalizedSentenceExistential existentialTopic (optional (try sentenceCoord)) |TopicalizedSentenceUniversal universalTopic sentenceCoord |TopicalizedSentenceComposite compositeSentence|] Given that nobody is maintaining the applicative-quoter, I might go and add support for this extension too. That would also substantially improve the Parser.hs example above. It's quite similar to the parallel list comprehension notation. One nice thing is how trivial it is to move to and from pure to monadic/applicative code with this. Comparatively, I've never used arrows ever and yet GHC has built-in support for it. Meanwhile Applicatives have wide application (hehe) and we're stuck writing this clunky stuff. But I figured I'd play with the quasi-quoter and see how it feels, and see if other people get onboard with it. Ciao! From carter.schonwald at gmail.com Thu Feb 19 00:37:08 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 18 Feb 2015 19:37:08 -0500 Subject: [Haskell-cafe] How to force James Cook (author of dependent-map) evaluation? In-Reply-To: <2E7EA7C3-B08B-45B2-A156-734C21E505DB@deepbondi.net> References: <2E7EA7C3-B08B-45B2-A156-734C21E505DB@deepbondi.net> Message-ID: Hey James, if you want some help setting up travis ci on your projects to test across different ghc versions, please feel to holler. Hvr has setup a lovely default that's easy to add to new projects, his multi - ghc - travis repo lays out some nice steps. Like wise most core libraries use it if you want some nice examples. On Feb 18, 2015 5:08 PM, "James Cook" wrote: > Sorry, as Dominic mentioned I have been quite busy in recent years and > it's hard to keep up with e-mail sometimes. > > I'm happy to get this particular issue fixed, but I don't have a whole lot > of time to chase down the details. In particular, I'd like to make sure > the patch doesn't break building on older versions of GHC (or, depending on > the versions it breaks, at least make sure the cabal file doesn't claim to > work when it doesn't). I can take a look at this sometime soon, but if you > happen to be able to track down info on which versions of GHC support the > syntax you changed to, I can make the needed changes a bit sooner (or merge > as-is, whichever is appropriate). > > -- James > > > On Jan 27, 2015, at 2:01 AM, Alexey Uimanov wrote: > > > > Hello people. There is a pull request > https://github.com/mokus0/dependent-map/pull/2 which I need to be on > hackage. I have sent a email to mokus at deepbondi.net but nothing happened. > > > > Does anyone can contact with James and tell him about my problem? > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mokus at deepbondi.net Thu Feb 19 01:15:41 2015 From: mokus at deepbondi.net (James Cook) Date: Wed, 18 Feb 2015 17:15:41 -0800 Subject: [Haskell-cafe] How to force James Cook (author of dependent-map) evaluation? In-Reply-To: References: <2E7EA7C3-B08B-45B2-A156-734C21E505DB@deepbondi.net> Message-ID: That would be very nice. I'll take a look at it tonight, thanks for the pointers. > On Feb 18, 2015, at 4:37 PM, Carter Schonwald wrote: > > Hey James, if you want some help setting up travis ci on your projects to test across different ghc versions, please feel to holler. Hvr has setup a lovely default that's easy to add to new projects, his multi - ghc - travis repo lays out some nice steps. Like wise most core libraries use it if you want some nice examples. > > On Feb 18, 2015 5:08 PM, "James Cook" wrote: > Sorry, as Dominic mentioned I have been quite busy in recent years and it's hard to keep up with e-mail sometimes. > > I'm happy to get this particular issue fixed, but I don't have a whole lot of time to chase down the details. In particular, I'd like to make sure the patch doesn't break building on older versions of GHC (or, depending on the versions it breaks, at least make sure the cabal file doesn't claim to work when it doesn't). I can take a look at this sometime soon, but if you happen to be able to track down info on which versions of GHC support the syntax you changed to, I can make the needed changes a bit sooner (or merge as-is, whichever is appropriate). > > -- James > > > On Jan 27, 2015, at 2:01 AM, Alexey Uimanov wrote: > > > > Hello people. There is a pull request https://github.com/mokus0/dependent-map/pull/2 which I need to be on hackage. I have sent a email to mokus at deepbondi.net but nothing happened. > > > > Does anyone can contact with James and tell him about my problem? > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From stuart.hungerford at gmail.com Thu Feb 19 03:00:10 2015 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Thu, 19 Feb 2015 14:00:10 +1100 Subject: [Haskell-cafe] Haskell-Cafe Digest, Vol 138, Issue 30 In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 12:13 PM, wrote: > From: Tom Ellis > To: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Testing polymorphic properties with > QuickCheck > I'm not quite sure what you're asking specifically, but maybe this will > help: > > {-# LANGUAGE ScopedTypeVariables #-} > > monoid_suite :: forall m. (Eq m, Monoid m) => String -> Proxy m -> TestTree > monoid_suite typename _ = testGroup "monoid" [ > testProperty ("left additive identity (" ++ typename ++ ")") > (prop_left_add_id :: m -> Bool), > > ... > ] > > monoid_suite_integer :: TestTree > monoid_suite_integer = monoid_suite "Integer" (Proxy :: Integer) Please excuse my ignorance as a relatively new Haskell user but is there anything special about that "Proxy m" type? Thanks, Stu From ivan.miljenovic at gmail.com Thu Feb 19 03:08:58 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 19 Feb 2015 14:08:58 +1100 Subject: [Haskell-cafe] Haskell-Cafe Digest, Vol 138, Issue 30 In-Reply-To: References: Message-ID: On 19 February 2015 at 14:00, Stuart Hungerford wrote: > On Thu, Feb 19, 2015 at 12:13 PM, wrote: > >> From: Tom Ellis >> To: haskell-cafe at haskell.org >> Subject: Re: [Haskell-cafe] Testing polymorphic properties with >> QuickCheck > >> I'm not quite sure what you're asking specifically, but maybe this will >> help: >> >> {-# LANGUAGE ScopedTypeVariables #-} >> >> monoid_suite :: forall m. (Eq m, Monoid m) => String -> Proxy m -> TestTree >> monoid_suite typename _ = testGroup "monoid" [ >> testProperty ("left additive identity (" ++ typename ++ ")") >> (prop_left_add_id :: m -> Bool), >> >> ... >> ] >> >> monoid_suite_integer :: TestTree >> monoid_suite_integer = monoid_suite "Integer" (Proxy :: Integer) > > Please excuse my ignorance as a relatively new Haskell user but is > there anything special about that "Proxy m" type? No: Proxy is used when you need/want to pass a type around but don't have a value of that type to use. See http://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Proxy.html > > Thanks, > > Stu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From vogt.adam at gmail.com Thu Feb 19 04:23:49 2015 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 18 Feb 2015 23:23:49 -0500 Subject: [Haskell-cafe] Testing polymorphic properties with QuickCheck In-Reply-To: References: Message-ID: Hi Stuart, If you're testing stand-alone functions, defaulting all type variables to Integer can probably find a counterexample, provided it's not something that depends on properties of an instance of Integer like: prop_assoc a b c = (a + b) + c == a + (b + c) -- fails for Double But another type might find the counterexample faster. See this paper (called Testing Polymorphic Properties): http://publications.lib.chalmers.se/records/fulltext/local_99387.pdf Unfortunately, I don't know of an implementation of the method they describe. Regards, Adam On Wed, Feb 18, 2015 at 3:41 PM, Stuart Hungerford wrote: > Hi, > > I'd like to use QuickCheck to test polymorphic properties and I'm > wondering if there's any community consenus on how to do this while > avoiding creating large amounts of boilerplate test code. > > As an example, suppose I have this simple simplistic Monoid typeclass: > > class Monoid a where > zero :: a > (|+|) :: a -> a -> a > > And suppose I make these types Monoid instances: > > > instance Monoid Integer where > zero = 0 > (|+|) = (+) > > instance Monoid Rational where > zero = 0 > (|+|) = (+) > > instance (Monoid a, Monoid b) => Monoid (a, b) where > zero = (zero, zero) > (|+|) (x, y) (u, v) = (x |+| u, y |+| v) > > > Using QuickCheck and the Tasty test framework I'd like to test the > Monoid laws across the relevant types (I'm only showing one part of > one law here) as QuickCheck properties: > > > prop_left_add_id :: (Eq a, Monoid a) => a -> Bool > prop_left_add_id x = zero |+| x == x > > monoid_suite :: TestTree > monoid_suite = testGroup "monoid" [ > testProperty "left additive identity (Integer)" > (prop_left_add_id :: Integer -> Bool), > > testProperty "left additive identity (Rational)" > (prop_left_add_id :: Rational -> Bool), > > testProperty "left additive identity ((Integer, Integer))" > (prop_left_add_id :: (Integer, Integer) -> Bool), > -- ...] > > > And this is where I start creating a lot of essentially boilerplate > code. I'm wondering if there's any consensus on the way to go about > this kind of testing? > > Researching this issue I've found ways of combining various GHC > extensions and the type system to (I think) write the properties more > at the type level. There are QuickCheck and Tasty modules that aim to > find all properties in a module and test them, but polymorphic > properties are automatically defaulted to Integer arguments. I'm also > tempted by Template Haskell to write what's essentially code > generation templates. > > Is there a better way to go about this? > > Thanks, > > Stu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From briand at aracnet.com Thu Feb 19 05:48:57 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Wed, 18 Feb 2015 21:48:57 -0800 Subject: [Haskell-cafe] ghc and libgmp compiled separately Message-ID: <20150218214857.34a7eb41@cedar.deldotd.com> i downloaded the centos65 binary of ghc only to find there was some sort of problem with libgmp on the system i am using. No problem i think, I'll just go grab the latest 4.x gmp compile it and use the --with-gmp flags to point ghc to my compiled version. didn't work. Don't have access to the machine from home, so i can't relay the precise error message (forgot to email it to myself), but it seems that the --with-gmp flags should have solved my problem (gmp compiled cleanly without any problems and put all the files in the right place). any obvious trickery involved when attempting something like this ? Thanks, Brian From apfelmus at quantentunnel.de Thu Feb 19 09:21:04 2015 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu, 19 Feb 2015 10:21:04 +0100 Subject: [Haskell-cafe] Very large data structures in the heap In-Reply-To: References: Message-ID: Dr. Olaf Klinke wrote: > I have a function that builds a (cyclic) data structure for searching > text. The resulting object can be serialized and re-built. Real-world > problems would, however, result in a tree with about 10^9 nodes. I take > it that standard data type declarations are not very memory-efficient, > so my (fully evaluated) search tree would not fit into memory as a heap > object. Its serialised form should be of tractable size, e.g. by storing > an array of labels and the tree structure as a bit array of parentheses. > > I'd like to separate serialization (IO) from traversal of the stucture > (pure), but how can one avoid the entire heap object from being built? > Can lazyness be exploited? As a rule of thumb, if you want tight control over memory usage, then you need to stick to an execution model that gives you that control -- so not lazy evaluation. It certainly is possible to reason about memory usage with lazy evaluation, but it's not straightforward. Here's an idea that could work for you: The problem as you described it is that you want to use an algebraic data type data Tree a = Bin (Tree a) (Tree a) | Leaf a but for reasons for space usage, you have to represent it as a compressed byte array, for instance like this type Tree = ByteString The drawback of the latter representation is that you lose pattern matching, but there is actually a way to sort of avoid that. In particular, consider the following function for the algebraic data type: caseof :: (Tree a -> Tree a -> b) -> (a -> b) -> (Tree a -> b) caseof f g tree = case tree of Bin x y -> f x y Leaf a -> g a This is essentially a case-of expression, written as a function with two argument (the two cases). If you implement a function like this for your byte array `Tree`, then you can formulate your traversal in terms of this case-of expression/function, which handles all the decoding issues. Essentially, your `Tree` data type has to be a pointer to the tip of a subtree. You can also augment the `caseof` function to be in the IO monad if you want. This way, you can avoid loading the tree in memory altogether. Again, the `caseof` function takes care of decoding the data format, while the traversal uses `caseof` to make decisions of which parts of the tree to inspect. This trick is also known as "Scott encoding", or "Mogensen-Scott encoding". It is very similar to the more well-known "Church encoding", but they differ in the case of recursive data types. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com From ollie at ocharles.org.uk Thu Feb 19 09:36:17 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 19 Feb 2015 09:36:17 +0000 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: Message-ID: <87lhjub5v2.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Bas van Dijk writes: > Do we still need idiom brackets if we have ApplicativeDo? > > https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo I think they solve different things. ApplicativeDo is a nice extension when I need to run n different effectful computations, but either use m < n results (that is, emulating the <* and *> operators), and/or if I need to return the results in a different order. For example: do a <- x b <- y c <- z (b, a) That's going to be a pain to write using idiom brackets: (| (\a b _ -> (b, a)) x y z |) However, for the common case where you do want to apply a function to the result of all effectful computations, then ApplicativeDo just forces you to introduce new symbol names: do x' <- x y' <- y z' <- z f x' y' z' I'm against this not just due to the extra amount of typing, but choosing names is often an unnecessary cognitive burden - I've often already used up the "obvious" name, and now I'm forced to come up with another set of names, unless I want to live with shadowing warnings (not an option, I use -Werror). - Ollie From ollie at ocharles.org.uk Thu Feb 19 09:56:08 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 19 Feb 2015 09:56:08 +0000 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: Message-ID: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Christopher Done writes: Hey Chris, thanks for chiming in! > Here's a fair comparison of before/after on my ace package's parser: > https://github.com/chrisdone/ace/commit/36767780ca356db75468f803b0c91388186c0441 In my opinion, this is exactly why I want this extension - these changes are easier for me to parse after the changes, and would be even nicer if we could drop the 'i' (so the brackets are symmetric). Interestingly, I think some of these changes could be even nicer assuming we had ApplicativeDo as well: (|SentenceCoord_2 sentenceCoord_3 (optional (try (do string "or" sentenceCoord_2)))|) As you can see, it allows us to do away with infix operators entirely. > Cons: > > * Nesting is not supported by quasi-quoters. This is something I think is very important - I often nest applicative syntax in my own code, and it's essential to me that I would be able to nest idiom brackets too. > * Currently it lacks the Alternative support as proposed by Conor. > That would look like this: > > [i|TopicalizedSentenceExistential existentialTopic (optional (try > sentenceCoord)) > |TopicalizedSentenceUniversal universalTopic sentenceCoord > |TopicalizedSentenceComposite compositeSentence|] I'm actually somewhat against this - my personal preference is that we keep this extension very minimal. Essentially, all we're doing is overloading what whitespace means within the idiom brackets. Introducing new symbols now complicates that, and introduces yet more syntax. My current solution for dealing with sums is to use asum: asum [[i|TopicalizedSentenceExistential existentialTopic (optional (try sentenceCoord)) ,[i|TopicalizedSentenceUniversal universalTopic sentenceCoord |] ,[i|TopicalizedSentenceComposite compositeSentence|]] Though it is a little noisy, I think it gives you want you want - machine-predictable indentation and consistency. > Comparatively, I've never used arrows ever and yet GHC has built-in > support for it. Meanwhile Applicatives have wide application (hehe) > and we're stuck writing this clunky stuff. But I figured I'd play with > the quasi-quoter and see how it feels, and see if other people get > onboard with it. Interestingly there is more interaction there. It's somewhat widely known now that Arrow <=> Applicative + Category. Thus in my current codebase using Opaleye, I actually work entirely *without* arrow notation. I find the notation alien-enough that it's not providing a huge win for my productivity, but in return I end up paying a cost in a little more typing. personBirthdayProduct = proc () -> do personRow <- personQuery -< () birthdayRow <- birthdayQuery -< () returnA -< (personRow, birthdayRow) right now becomes (,) <$> personQuery <*> birthdayQuery or liftA2 (,) personQuery birthdayQuery but with idiom brackets becomes (| (personQuery, birthdayRow) |) A slightly more complicated example is youngPeople = proc () -> do row@(_, age, _) <- personQuery -< () restrict -< age .<= 18 returnA -< row could become (| fst (second (lmap age restrict) . (| dup personQuery |)) |) where dup a = (a,a) Arguably not considerably better as you have to tuple things up only to immediately unpack them, but hopefully provides some insight how the use of ArrowNotation could be replaced with idiom brackets. - Ollie From mboes at tweag.net Thu Feb 19 10:37:44 2015 From: mboes at tweag.net (Mathieu Boespflug) Date: Thu, 19 Feb 2015 11:37:44 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: Hi Ollie, Chris, nice idea. This is something I've always thought would be nice to have since the original paper on applicatives. However, Tikhon, Ed and Henrik raise an important point: how would I write the following using idiom brackets? (,) <$> g x y <*> h (g x y) or f <*> g x y <*> h ((,) <$> g x y) Does g x y need to be written (| g x y |) for the Identity Applicative? FWIW, the original paper, http://strictlypositive.org/Idiom.pdf, defines a neat trick to encode idiom brackets with no need for any extensions as a solution to exercise 3 in the paper. Best, Mathieu On 19 February 2015 at 10:56, Oliver Charles wrote: > Christopher Done writes: > > Hey Chris, thanks for chiming in! > >> Here's a fair comparison of before/after on my ace package's parser: >> https://github.com/chrisdone/ace/commit/36767780ca356db75468f803b0c91388186c0441 > > In my opinion, this is exactly why I want this extension - these changes > are easier for me to parse after the changes, and would be even nicer if > we could drop the 'i' (so the brackets are symmetric). > > Interestingly, I think some of these changes could be even nicer > assuming we had ApplicativeDo as well: > > (|SentenceCoord_2 > sentenceCoord_3 > (optional (try (do string "or" > sentenceCoord_2)))|) > > As you can see, it allows us to do away with infix operators entirely. > >> Cons: >> >> * Nesting is not supported by quasi-quoters. > > This is something I think is very important - I often nest applicative > syntax in my own code, and it's essential to me that I would be able to > nest idiom brackets too. > >> * Currently it lacks the Alternative support as proposed by Conor. >> That would look like this: >> >> [i|TopicalizedSentenceExistential existentialTopic (optional (try >> sentenceCoord)) >> |TopicalizedSentenceUniversal universalTopic sentenceCoord >> |TopicalizedSentenceComposite compositeSentence|] > > I'm actually somewhat against this - my personal preference is that we > keep this extension very minimal. Essentially, all we're doing is > overloading what whitespace means within the idiom brackets. Introducing > new symbols now complicates that, and introduces yet more syntax. > > My current solution for dealing with sums is to use asum: > > asum [[i|TopicalizedSentenceExistential existentialTopic > (optional (try sentenceCoord)) > ,[i|TopicalizedSentenceUniversal universalTopic sentenceCoord |] > ,[i|TopicalizedSentenceComposite compositeSentence|]] > > Though it is a little noisy, I think it gives you want you want - > machine-predictable indentation and consistency. > >> Comparatively, I've never used arrows ever and yet GHC has built-in >> support for it. Meanwhile Applicatives have wide application (hehe) >> and we're stuck writing this clunky stuff. But I figured I'd play with >> the quasi-quoter and see how it feels, and see if other people get >> onboard with it. > > Interestingly there is more interaction there. It's somewhat widely > known now that Arrow <=> Applicative + Category. Thus in my current > codebase using Opaleye, I actually work entirely *without* arrow > notation. I find the notation alien-enough that it's not providing a > huge win for my productivity, but in return I end up paying a cost in a > little more typing. > > personBirthdayProduct = proc () -> do > personRow <- personQuery -< () > birthdayRow <- birthdayQuery -< () > returnA -< (personRow, birthdayRow) > > right now becomes > > (,) <$> personQuery <*> birthdayQuery > or liftA2 (,) personQuery birthdayQuery > > but with idiom brackets becomes > > (| (personQuery, birthdayRow) |) > > > A slightly more complicated example is > > youngPeople = proc () -> do > row@(_, age, _) <- personQuery -< () > restrict -< age .<= 18 > returnA -< row > > could become > > (| fst (second (lmap age restrict) . (| dup personQuery |)) |) > where dup a = (a,a) > > Arguably not considerably better as you have to tuple things up only to > immediately unpack them, but hopefully provides some insight how the use > of ArrowNotation could be replaced with idiom brackets. > > - Ollie > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From hesselink at gmail.com Thu Feb 19 10:37:30 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 19 Feb 2015 11:37:30 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: On Thu, Feb 19, 2015 at 10:56 AM, Oliver Charles wrote: > A slightly more complicated example is > > youngPeople = proc () -> do > row@(_, age, _) <- personQuery -< () > restrict -< age .<= 18 > returnA -< row > > could become > > (| fst (second (lmap age restrict) . (| dup personQuery |)) |) > where dup a = (a,a) OT: you might be able to make this clearer with `where_` [1] which we defined in our opaleye utility package [2]. It feels much more natural to me than restrict, and works much better with composition outside of arrow notation. Erik [1] https://github.com/silkapp/silk-opaleye/blob/c3a324e277d730eafa9c455e1a33e67b15283cb3/src/Silk/Opaleye.hs#L170 [2] https://github.com/silkapp/silk-opaleye From chrisdone at gmail.com Thu Feb 19 10:54:53 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 11:54:53 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: On 19 February 2015 at 10:56, Oliver Charles wrote: > This is something I think is very important - I often nest applicative > syntax in my own code, and it's essential to me that I would be able to > nest idiom brackets too. Indeed, it definitely adds to the handiness to nest them. > My current solution for dealing with sums is to use asum: > asum [[i|TopicalizedSentenceExistential existentialTopic > (optional (try sentenceCoord)) > ,[i|TopicalizedSentenceUniversal universalTopic sentenceCoord |] > ,[i|TopicalizedSentenceComposite compositeSentence|]] > Though it is a little noisy, I think it gives you want you want - > machine-predictable indentation and consistency. As mentioned via IRC, this is tricky due to the unclear semantic differences between x <|> y and asum [x,y] (i.e. the implicit ?empty? in asum). asum1 is a solution, but partial functions like that trouble me. Generally I'd prefer to just use asum or asum1, though. > personBirthdayProduct = proc () -> do > personRow <- personQuery -< () > birthdayRow <- birthdayQuery -< () > returnA -< (personRow, birthdayRow) > right now becomes > (,) <$> personQuery <*> birthdayQuery > or liftA2 (,) personQuery birthdayQuery > but with idiom brackets becomes > (| (personQuery, birthdayRow) |) Right, in the case that you don't want to name anything the idiom is much cleaner. From chrisdone at gmail.com Thu Feb 19 11:08:50 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 12:08:50 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: On 19 February 2015 at 11:37, Mathieu Boespflug wrote: > how would I write the following using idiom brackets? > > (,) <$> g x y <*> h (g x y) (| (g x y,h (g x y)) |) With applicative-quoters: [i|(,) (g x y) (h (g x y))|] > or > > f <*> g x y <*> h ((,) <$> g x y) (|id f (g x y) (h (| (g x y,)) |) |) With applicative-quoters: [i|id f (g x y) (h [i|(,) (g x y)|])|] (nesting permitting) From chrisdone at gmail.com Thu Feb 19 11:20:38 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 12:20:38 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: Although, I'm pretty sure this use of tuples is inconsistent with what's in the Applicatives paper. It'd be: [| (,) (g x y) (h (g x y))) |] [| id f (g x y) (h [| (,) (g x y)) |] |] I think that's the legit way to write it. The transformation is pretty trivial. From ollie at ocharles.org.uk Thu Feb 19 12:43:57 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 19 Feb 2015 12:43:57 +0000 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <87egpmgjg2.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Christopher Done writes: > Although, I'm pretty sure this use of tuples is inconsistent with > what's in the Applicatives paper. It'd be: > > [| (,) (g x y) (h (g x y))) |] > > [| id f (g x y) (h [| (,) (g x y)) |] |] > > I think that's the legit way to write it. The transformation is pretty trivial. This has actually reminded me of another point. Tuples are one form of construction in Haskell that is somewhat special - but another is using record syntax. I wonder if it would be possible to use idiom brackets there to lift the record constructor too: (| T { a = x, b = y } |) This would desugar into (something like) (\a b -> T {..}) <$> x <*> y In this case, we've "lifted" the original syntax into the idiom brackets, so I think it's only natural that we're able to lift tuple construction into these brackets too. My preference would be that (| (g x y, h (g x y) |) Does the expected thing, where my expectation is (following on from my point about record syntax) would be: (\a b -> (a, b)) <$> g x y <*> h (g x y) -- Ollie From chrisdone at gmail.com Thu Feb 19 13:08:39 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 14:08:39 +0100 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: <87egpmgjg2.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> <87egpmgjg2.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: On 19 February 2015 at 13:43, Oliver Charles wrote: > This has actually reminded me of another point. Tuples are one form of > construction in Haskell that is somewhat special - but another is using > record syntax. I wonder if it would be possible to use idiom brackets > there to lift the record constructor too: > > (| T { a = x, b = y } |) > > This would desugar into (something like) > > (\a b -> T {..}) <$> x <*> y Yeah, this would nicely handle: (1) being explicit about naming when you want to be, (2) order of effects. > In this case, we've "lifted" the original syntax into the idiom > brackets, so I think it's only natural that we're able to lift tuple > construction into these brackets too. My preference would be that > > (| (g x y, h (g x y) |) There's a wee bit of contention with (| foo |) which is supposed to be "pure foo", AIUI. I saw elsewhere someone suggest: (| g x y, h x y |) But that doesn't help with a way to involve records. -- On an unrelated note but the same topic, "applicative comprehensions" could be fun: (| f a b |) and (| f a b | a <- x, b <- y |) and (| T{..} | a <- x, b <- y |) From chrisdone at gmail.com Thu Feb 19 14:51:31 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 15:51:31 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions Message-ID: Ahoy, The idiom discussion brought back to mind a general problem (well, for me) in Haskell syntax which is there is no syntactic sugar for interspersing operators to many arguments. Regarding a solution for this, I wrote up a wee proposal here: https://gist.github.com/chrisdone/d9d33e4770a2fef19ad1 If I go ahead and implement this in GHC as -XInfixExpressions or something (better names welcome), would it be likely to be accepted? I could first do an implementation in haskell-src-exts to demonstrate the concept. Ciao! From noteed at gmail.com Thu Feb 19 15:07:26 2015 From: noteed at gmail.com (Vo Minh Thu) Date: Thu, 19 Feb 2015 16:07:26 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: This example infix a b c d ? a b c d makes me thing to the Lisp (+ a b c d) s-expression... And indeed your infix keyword could be replaced by something like ? a b c d? ? a b c d Voil?, s-expressions part of Haskell syntax ! 2015-02-19 15:51 GMT+01:00 Christopher Done : > Ahoy, > > The idiom discussion brought back to mind a general problem (well, for > me) in Haskell syntax which is there is no syntactic sugar for > interspersing operators to many arguments. > > Regarding a solution for this, I wrote up a wee proposal here: > https://gist.github.com/chrisdone/d9d33e4770a2fef19ad1 > > If I go ahead and implement this in GHC as -XInfixExpressions or > something (better names welcome), would it be likely to be accepted? I > could first do an implementation in haskell-src-exts to demonstrate > the concept. > > Ciao! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From clintonmead at gmail.com Thu Feb 19 15:15:36 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Fri, 20 Feb 2015 02:15:36 +1100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: "infix" for two or more arguments is pretty much just "foldl1". On Fri, Feb 20, 2015 at 1:51 AM, Christopher Done wrote: > Ahoy, > > The idiom discussion brought back to mind a general problem (well, for > me) in Haskell syntax which is there is no syntactic sugar for > interspersing operators to many arguments. > > Regarding a solution for this, I wrote up a wee proposal here: > https://gist.github.com/chrisdone/d9d33e4770a2fef19ad1 > > If I go ahead and implement this in GHC as -XInfixExpressions or > something (better names welcome), would it be likely to be accepted? I > could first do an implementation in haskell-src-exts to demonstrate > the concept. > > Ciao! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Thu Feb 19 15:22:30 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 16:22:30 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On 19 February 2015 at 16:15, Clinton Mead wrote: > "infix" for two or more arguments is pretty much just "foldl1". Please see the proposal. From chrisdone at gmail.com Thu Feb 19 15:28:30 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 16:28:30 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On 19 February 2015 at 16:07, Vo Minh Thu wrote: > And indeed your infix keyword could be replaced by something like > > ? a b c d? ? a b c d > > Voil?, s-expressions part of Haskell syntax ! This is how it worked in Lisk. :-) But I don't know how on my keyboard to type those characters. ;-) From hesselink at gmail.com Thu Feb 19 15:29:20 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 19 Feb 2015 16:29:20 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: If I'm reading it correctly, the only example where a fold wouldn't work is <*>, right? And probably conduits, I don't know the types there. Erik On Thu, Feb 19, 2015 at 4:22 PM, Christopher Done wrote: > On 19 February 2015 at 16:15, Clinton Mead wrote: >> "infix" for two or more arguments is pretty much just "foldl1". > > Please see the proposal. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From chrisdone at gmail.com Thu Feb 19 15:42:17 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 16:42:17 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On 19 February 2015 at 16:29, Erik Hesselink wrote: > If I'm reading it correctly, the only example where a fold wouldn't > work is <*>, right? And probably conduits, I don't know the types > there. Right, I see three use-cases: * Some things are foldable cleanly like monoids, so you can just mconcat [x,y,z] and that'll be inlined (I think). * Other things like x <|> y is not the same as asum [x,y] due to the additional mempty being introduced. You can also use foldl1 kind of functions, but they are partial and therefore not desirable. * Finally, things like <*>, $=, $, ., #/:& (e.g. in HList/vinyl) can't be folded at all, because the types are different. The third use-case doesn't have a solution that I'm aware of. So this solves that. It also solves the second use-case, which has only a partial (he he) solution. The first use-case is just a bonus. Should I add this clarification to the proposal? From hesselink at gmail.com Thu Feb 19 16:26:48 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 19 Feb 2015 17:26:48 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 4:42 PM, Christopher Done wrote: > On 19 February 2015 at 16:29, Erik Hesselink wrote: >> If I'm reading it correctly, the only example where a fold wouldn't >> work is <*>, right? And probably conduits, I don't know the types >> there. > > Right, I see three use-cases: > > * Some things are foldable cleanly like monoids, so you can just > mconcat [x,y,z] and that'll be inlined (I think). > * Other things like x <|> y is not the same as asum [x,y] due to the > additional mempty being introduced. You can also use foldl1 kind of > functions, but they are partial and therefore not desirable. Do you mean execution-wise? Because semantically there should be no difference, I think. Although now that I think of it, there might be for things that carry information in the mempty case, like ErrorT, when they are right biased. It could be argued that this is a bug, and ExceptT fixes it. You could write monoids that do the same thing, e.g. instance Monoid b => Monoid (Either String b) where mempty = Left "" mappend (Right x) _ = Right x mappend _ y = y I have a feeling that `Alternative (f a)` should satisfy the Monoid laws for `Monoid (f a)`, but that doesn't seem to be documented. It does say 'a monoid on applicative functors', so perhaps it's implied. > * Finally, things like <*>, $=, $, ., #/:& (e.g. in HList/vinyl) can't > be folded at all, because the types are different. > > The third use-case doesn't have a solution that I'm aware of. So this > solves that. It also solves the second use-case, which has only a > partial (he he) solution. The first use-case is just a bonus. Should I > add this clarification to the proposal? Yes, that sounds good. It wasn't immediately obvious to me in the first paragraph why you would want this, and after the examples, I thought "meh". This list is very clarifying, and the third bullet is much more convincing to me. Erik From matthewtpickering at gmail.com Thu Feb 19 16:33:42 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 19 Feb 2015 16:33:42 +0000 Subject: [Haskell-cafe] Let's teach GHC idiom brackets! In-Reply-To: References: <87ioeyb4xz.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: > FWIW, the original paper, http://strictlypositive.org/Idiom.pdf, > defines a neat trick to encode idiom brackets with no need for any > extensions as a solution to exercise 3 in the paper. Here's the trick explicitly for anyone who was wondering (like me) https://gist.github.com/mpickering/99d62ccdb73f49840220 On Thu, Feb 19, 2015 at 10:37 AM, Mathieu Boespflug wrote: > Hi Ollie, Chris, > > nice idea. This is something I've always thought would be nice to have > since the original paper on applicatives. However, Tikhon, Ed and > Henrik raise an important point: how would I write the following using > idiom brackets? > > (,) <$> g x y <*> h (g x y) > > or > > f <*> g x y <*> h ((,) <$> g x y) > > Does g x y need to be written (| g x y |) for the Identity Applicative? > > FWIW, the original paper, http://strictlypositive.org/Idiom.pdf, > defines a neat trick to encode idiom brackets with no need for any > extensions as a solution to exercise 3 in the paper. > > Best, > > Mathieu > > On 19 February 2015 at 10:56, Oliver Charles wrote: >> Christopher Done writes: >> >> Hey Chris, thanks for chiming in! >> >>> Here's a fair comparison of before/after on my ace package's parser: >>> https://github.com/chrisdone/ace/commit/36767780ca356db75468f803b0c91388186c0441 >> >> In my opinion, this is exactly why I want this extension - these changes >> are easier for me to parse after the changes, and would be even nicer if >> we could drop the 'i' (so the brackets are symmetric). >> >> Interestingly, I think some of these changes could be even nicer >> assuming we had ApplicativeDo as well: >> >> (|SentenceCoord_2 >> sentenceCoord_3 >> (optional (try (do string "or" >> sentenceCoord_2)))|) >> >> As you can see, it allows us to do away with infix operators entirely. >> >>> Cons: >>> >>> * Nesting is not supported by quasi-quoters. >> >> This is something I think is very important - I often nest applicative >> syntax in my own code, and it's essential to me that I would be able to >> nest idiom brackets too. >> >>> * Currently it lacks the Alternative support as proposed by Conor. >>> That would look like this: >>> >>> [i|TopicalizedSentenceExistential existentialTopic (optional (try >>> sentenceCoord)) >>> |TopicalizedSentenceUniversal universalTopic sentenceCoord >>> |TopicalizedSentenceComposite compositeSentence|] >> >> I'm actually somewhat against this - my personal preference is that we >> keep this extension very minimal. Essentially, all we're doing is >> overloading what whitespace means within the idiom brackets. Introducing >> new symbols now complicates that, and introduces yet more syntax. >> >> My current solution for dealing with sums is to use asum: >> >> asum [[i|TopicalizedSentenceExistential existentialTopic >> (optional (try sentenceCoord)) >> ,[i|TopicalizedSentenceUniversal universalTopic sentenceCoord |] >> ,[i|TopicalizedSentenceComposite compositeSentence|]] >> >> Though it is a little noisy, I think it gives you want you want - >> machine-predictable indentation and consistency. >> >>> Comparatively, I've never used arrows ever and yet GHC has built-in >>> support for it. Meanwhile Applicatives have wide application (hehe) >>> and we're stuck writing this clunky stuff. But I figured I'd play with >>> the quasi-quoter and see how it feels, and see if other people get >>> onboard with it. >> >> Interestingly there is more interaction there. It's somewhat widely >> known now that Arrow <=> Applicative + Category. Thus in my current >> codebase using Opaleye, I actually work entirely *without* arrow >> notation. I find the notation alien-enough that it's not providing a >> huge win for my productivity, but in return I end up paying a cost in a >> little more typing. >> >> personBirthdayProduct = proc () -> do >> personRow <- personQuery -< () >> birthdayRow <- birthdayQuery -< () >> returnA -< (personRow, birthdayRow) >> >> right now becomes >> >> (,) <$> personQuery <*> birthdayQuery >> or liftA2 (,) personQuery birthdayQuery >> >> but with idiom brackets becomes >> >> (| (personQuery, birthdayRow) |) >> >> >> A slightly more complicated example is >> >> youngPeople = proc () -> do >> row@(_, age, _) <- personQuery -< () >> restrict -< age .<= 18 >> returnA -< row >> >> could become >> >> (| fst (second (lmap age restrict) . (| dup personQuery |)) |) >> where dup a = (a,a) >> >> Arguably not considerably better as you have to tuple things up only to >> immediately unpack them, but hopefully provides some insight how the use >> of ArrowNotation could be replaced with idiom brackets. >> >> - Ollie >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Feb 19 17:02:15 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 19 Feb 2015 17:02:15 +0000 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: <20150219170215.GA29710@weber> On Thu, Feb 19, 2015 at 03:51:31PM +0100, Christopher Done wrote: > The idiom discussion brought back to mind a general problem (well, for > me) in Haskell syntax which is there is no syntactic sugar for > interspersing operators to many arguments. The goal of reducing duplication like this is a worthy one. I don't like the idea of using what essentially amounts to a macro as it is not first class. However, if a first class way can be found to make such a thing type check (perhaps some cunning use of dependent types) then I will be all for it! Tom From simonpj at microsoft.com Thu Feb 19 17:37:55 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Feb 2015 17:37:55 +0000 Subject: [Haskell-cafe] Pattern match checking for GADTs Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> Friends George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are working on finally cracking the problem of accurately reporting pattern-match overlap and redundancy warnings, in the presence of GADTs. You know the problem; consider vzip :: Vect n a -> Vect n b -> Vect n (a,b) vzip VN VN = VN vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) data Vect :: Nat -> * -> * where VN :: Vect Zero a VC :: a -> Vect n a -> Vect (Succ n) a Are there any missing equations in vzip? No! But GHC complains anyway. We have lots of Trac tickets about this; e.g. https://ghc.haskell.org/trac/ghc/ticket/3927. We now have a draft paper (wait a week) and a prototype implementation, that fixes the problem. But we need your help. We'd like to try our prototype on real code, not just toy examples. So, could you send George a pointer to any packages you have, or know of, that * use GADTS (or other fancy type features) and * would benefit from accurate pattern-match overlap/redundancy warnings? Specifically: * Where you have had to add a catch-all f _ _ = error "impossible" to silence GHC from saying "missing patterns" * Or where you have added {-# OPTIONS_GHC -fno-warn-missing-patterns #-} to silence the warnings. * Or something else like that. George's email is in cc. Time is short - the ICFP deadline is on 27 Feb. So sooner is better than later for us. But later is better than never. Thank you! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Thu Feb 19 17:50:53 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 19 Feb 2015 17:50:53 +0000 Subject: [Haskell-cafe] Pattern match checking for GADTs In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I have some code that I could provide, but I don't seem to see George's email address in the CC (only Tom's). Perhaps GMail ate it for some reason - but either way, I don't know where to send my code :) -- Ollie On Thu, Feb 19, 2015 at 5:37 PM, Simon Peyton Jones wrote: > Friends > > George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are working > on finally cracking the problem of accurately reporting pattern-match > overlap and redundancy warnings, in the presence of GADTs. You know the > problem; consider > > vzip :: Vect n a -> Vect n b -> Vect n (a,b) > > vzip VN VN = VN > > vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) > > > > data Vect :: Nat -> * -> * where > > VN :: Vect Zero a > > VC :: a -> Vect n a -> Vect (Succ n) a > > Are there any missing equations in vzip? No! But GHC complains anyway. > We have lots of Trac tickets about this; e.g. > https://ghc.haskell.org/trac/ghc/ticket/3927. > > We now have a draft paper (wait a week) and a prototype implementation, > that fixes the problem. But we need your help. We?d like to try our > prototype on real code, not just toy examples. > > *So, could you send George a pointer to any packages you have, or know of, > that* > > ? *use GADTS (or other fancy type features) and * > > ? *would benefit from accurate pattern-match overlap/redundancy > warnings?* > > Specifically: > > ? Where you have had to add a catch-all > > f _ _ = error ?impossible? > > to silence GHC from saying ?missing patterns? > > ? Or where you have added {-# OPTIONS_GHC > ?fno-warn-missing-patterns #-} to silence the warnings. > > ? Or something else like that. > > George?s email is in cc. > > Time is short ? the ICFP deadline is on 27 Feb. So sooner is better than > later for us. But later is better than never. > > Thank you! > > Simon > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Thu Feb 19 17:54:16 2015 From: ben.franksen at online.de (Ben Franksen) Date: Thu, 19 Feb 2015 18:54:16 +0100 Subject: [Haskell-cafe] FLTK bindings near completion. Need community assistance ... References: Message-ID: aditya siram wrote: > I've been working on bindings [1] to the FLTK GUI toolkit [2] and I've > come to the point where it's mostly complete but I could use some help > from the community before I put it up on Hackage. > > My hope is to eventually fill the need in the Haskell ecosystem for a > native GUI library that: > - runs on all platforms > - is easily installable > - is small and fast > - has a minimum of dependencies. Currently this library uses only base, > stm, bytestring and c2hs. > - is conservative with extensions. Currently the most recent extension > required is GADTs. I very much welcome the effort and are willing to help. My system is ubuntu trusty (14.04.1 LTS). I am using ghc-7.6.3 from the distribution and have almost all the existing packages for haskell libraries installed. I usually try to get new stuff to compile with them and only cabal install dependencies if that fails (but always in a sandbox, except for cabal and cabal-install of which i have the latest versions). I first tried to build your library with my distro's libfltk1.3-dev package. This gave me errors early on: ==Compiling C bindings== *** Compiling Fl_Menu_ButtonC.cpp... *** Compiling Fl_PositionerC.cpp... Fl_PositionerC.cpp: In function ?void* Fl_Positioner_top_window(fl_Positioner)?: Fl_PositionerC.cpp:268:67: error: ?class Fl_Positioner? has no member named ?top_window? return (fl_Window) (static_cast(positioner))- >top_window(); ^ Fl_PositionerC.cpp: In function ?void* Fl_Positioner_top_window_offset(fl_Positioner, int*, int*)?: Fl_PositionerC.cpp:271:67: error: ?class Fl_Positioner? has no member named ?top_window_offset? return (fl_Window) (static_cast(positioner))- >top_window_offset(*xoff,*yoff); ^ Fl_PositionerC.cpp: In function ?void* Fl_Positioner_top_window(fl_Positioner)?: Fl_PositionerC.cpp:269:3: warning: control reaches end of non-void function [-Wreturn-type] } ^ Fl_PositionerC.cpp: In function ?void* Fl_Positioner_top_window_offset(fl_Positioner, int*, int*)?: Fl_PositionerC.cpp:272:3: warning: control reaches end of non-void function [-Wreturn-type] } ^ make[1]: *** [Fl_PositionerC.o] Fehler 1 make: *** [src] Fehler 2 Then I looked at the exact version of the libfltk package and saw it is based on version 1.3.2. I then downloaded the 1.3.3 version and installed manually. But this failed, too, though much later in the process: src/Graphics/UI/FLTK/LowLevel/FL.chs:279:3: Ambiguous occurrence `unsafePerformIO' It could refer to either `Graphics.UI.FLTK.LowLevel.FL.unsafePerformIO', defined at src/Graphics/UI/FLTK/LowLevel/FL.chs:276:1 or `C2HS.unsafePerformIO', imported from `C2HS' at src/Graphics/UI/FLTK/LowLevel/FL.chs:150:1-47 (and originally defined in `Foreign') If I remove the unsafePerformIO work-around (thanks for the comment in the code), I get a few warnings but the build completes. Compiling the examples takes ages. I wonder why. The examples seems to work basically, though not without some rough corners. The first two I tried: hello-world: the window is too small, it cuts off the button on the right edge. Note that I am running xmonad as my window manager i.e. no window decorations. table-spreadsheet-with-keyboard-nav: I tuned the sliders to max and found that the scollbars behave strangely (the handles do not scale properly, clicking inside the empty area works only once). You can contact me off-list if you want more detailed feedback. Cheers Ben -- "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." ? C.A.R. Hoare From mail at nils.cc Thu Feb 19 17:53:22 2015 From: mail at nils.cc (Nils Schweinsberg) Date: Thu, 19 Feb 2015 18:53:22 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: What would be the typing rules for this? What would be the types of e.g. pointfree written function definitions (`f` in `let f = infix + 5 in f 2 + f 2 3 4`)? Haskell does support variable umber of argument functions like for instance the `printf` by using type class instances for arguments, but I don't think that approach would be flexible enough to ensure type safety in all cases? On Thu, Feb 19, 2015 at 3:51 PM, Christopher Done wrote: > Ahoy, > > The idiom discussion brought back to mind a general problem (well, for > me) in Haskell syntax which is there is no syntactic sugar for > interspersing operators to many arguments. > > Regarding a solution for this, I wrote up a wee proposal here: > https://gist.github.com/chrisdone/d9d33e4770a2fef19ad1 > > If I go ahead and implement this in GHC as -XInfixExpressions or > something (better names welcome), would it be likely to be accepted? I > could first do an implementation in haskell-src-exts to demonstrate > the concept. > > Ciao! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From chrisdone at gmail.com Thu Feb 19 18:11:26 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 19:11:26 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On 19 February 2015 at 18:53, Nils Schweinsberg wrote: > What would be the typing rules for this? What would be the types of > e.g. pointfree written function definitions (`f` in `let f = infix + 5 > in f 2 + f 2 3 4`)? Purely syntactical, the translation I gave was literal: let f = infix + 5 is the same as let f = (5 +). But to avoid confusion it's also possible to disallow unary arguments and mandate at least two arguments. From vilevin at gmail.com Thu Feb 19 18:17:31 2015 From: vilevin at gmail.com (Aaron Levin) Date: Thu, 19 Feb 2015 18:17:31 +0000 Subject: [Haskell-cafe] Pattern match checking for GADTs References: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Same with Oliver (can't see email and would like to contribute). On Thu, Feb 19, 2015 at 12:51 PM Oliver Charles wrote: > I have some code that I could provide, but I don't seem to see George's > email address in the CC (only Tom's). Perhaps GMail ate it for some reason > - but either way, I don't know where to send my code :) > > -- Ollie > > On Thu, Feb 19, 2015 at 5:37 PM, Simon Peyton Jones > wrote: > >> Friends >> >> George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are >> working on finally cracking the problem of accurately reporting >> pattern-match overlap and redundancy warnings, in the presence of GADTs. >> You know the problem; consider >> >> vzip :: Vect n a -> Vect n b -> Vect n (a,b) >> >> vzip VN VN = VN >> >> vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) >> >> >> >> data Vect :: Nat -> * -> * where >> >> VN :: Vect Zero a >> >> VC :: a -> Vect n a -> Vect (Succ n) a >> >> Are there any missing equations in vzip? No! But GHC complains anyway. >> We have lots of Trac tickets about this; e.g. >> https://ghc.haskell.org/trac/ghc/ticket/3927. >> >> We now have a draft paper (wait a week) and a prototype implementation, >> that fixes the problem. But we need your help. We?d like to try our >> prototype on real code, not just toy examples. >> >> *So, could you send George a pointer to any packages you have, or know >> of, that* >> >> ? *use GADTS (or other fancy type features) and * >> >> ? *would benefit from accurate pattern-match overlap/redundancy >> warnings?* >> >> Specifically: >> >> ? Where you have had to add a catch-all >> >> f _ _ = error ?impossible? >> >> to silence GHC from saying ?missing patterns? >> >> ? Or where you have added {-# OPTIONS_GHC >> ?fno-warn-missing-patterns #-} to silence the warnings. >> >> ? Or something else like that. >> >> George?s email is in cc. >> >> Time is short ? the ICFP deadline is on 27 Feb. So sooner is better than >> later for us. But later is better than never. >> >> Thank you! >> >> Simon >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at jonmsterling.com Thu Feb 19 18:20:18 2015 From: jon at jonmsterling.com (Jon Sterling) Date: Thu, 19 Feb 2015 10:20:18 -0800 Subject: [Haskell-cafe] Pattern match checking for GADTs In-Reply-To: References: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <1424370018.3843602.229804453.6AE27E6F@webmail.messagingengine.com> At PivotCloud, we have some internal code that would benefit from this being fixed; it's internal for aesthetic reasons, rather than IP, so we would be happy to share it with anyone who is trying to work on this problem. Kind regards, Jon On Thu, Feb 19, 2015, at 10:17 AM, Aaron Levin wrote: > Same with Oliver (can't see email and would like to contribute). > On Thu, Feb 19, 2015 at 12:51 PM Oliver Charles > wrote: > > > I have some code that I could provide, but I don't seem to see George's > > email address in the CC (only Tom's). Perhaps GMail ate it for some reason > > - but either way, I don't know where to send my code :) > > > > -- Ollie > > > > On Thu, Feb 19, 2015 at 5:37 PM, Simon Peyton Jones > > wrote: > > > >> Friends > >> > >> George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are > >> working on finally cracking the problem of accurately reporting > >> pattern-match overlap and redundancy warnings, in the presence of GADTs. > >> You know the problem; consider > >> > >> vzip :: Vect n a -> Vect n b -> Vect n (a,b) > >> > >> vzip VN VN = VN > >> > >> vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) > >> > >> > >> > >> data Vect :: Nat -> * -> * where > >> > >> VN :: Vect Zero a > >> > >> VC :: a -> Vect n a -> Vect (Succ n) a > >> > >> Are there any missing equations in vzip? No! But GHC complains anyway. > >> We have lots of Trac tickets about this; e.g. > >> https://ghc.haskell.org/trac/ghc/ticket/3927. > >> > >> We now have a draft paper (wait a week) and a prototype implementation, > >> that fixes the problem. But we need your help. We?d like to try our > >> prototype on real code, not just toy examples. > >> > >> *So, could you send George a pointer to any packages you have, or know > >> of, that* > >> > >> ? *use GADTS (or other fancy type features) and * > >> > >> ? *would benefit from accurate pattern-match overlap/redundancy > >> warnings?* > >> > >> Specifically: > >> > >> ? Where you have had to add a catch-all > >> > >> f _ _ = error ?impossible? > >> > >> to silence GHC from saying ?missing patterns? > >> > >> ? Or where you have added {-# OPTIONS_GHC > >> ?fno-warn-missing-patterns #-} to silence the warnings. > >> > >> ? Or something else like that. > >> > >> George?s email is in cc. > >> > >> Time is short ? the ICFP deadline is on 27 Feb. So sooner is better than > >> later for us. But later is better than never. > >> > >> Thank you! > >> > >> Simon > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > >> > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From simonpj at microsoft.com Thu Feb 19 18:21:15 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 19 Feb 2015 18:21:15 +0000 Subject: [Haskell-cafe] Pattern match checking for GADTs In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEAA504@DB3PRD3001MB020.064d.mgd.msft.net> I have some code that I could provide, but I don't seem to see George's email address in the CC (only Tom's). Perhaps GMail ate it for some reason - but either way, I don't know where to send my code :) Second attempt, to try to include George's email. If it's not in cc, it is: george.karachalias at gmail.com Strange. My "sent items" folder definitely shows him in cc. Sorry for the spam. Simon From: Simon Peyton Jones Sent: 19 February 2015 17:38 To: Haskell Libraries (libraries at haskell.org); Haskell Cafe (haskell-cafe at haskell.org) Cc: George Karachalias; Tom Schrijvers; Dimitrios Vytiniotis (dimitris at microsoft.com); Simon Peyton-Jones Subject: Pattern match checking for GADTs Friends George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are working on finally cracking the problem of accurately reporting pattern-match overlap and redundancy warnings, in the presence of GADTs. You know the problem; consider vzip :: Vect n a -> Vect n b -> Vect n (a,b) vzip VN VN = VN vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) data Vect :: Nat -> * -> * where VN :: Vect Zero a VC :: a -> Vect n a -> Vect (Succ n) a Are there any missing equations in vzip? No! But GHC complains anyway. We have lots of Trac tickets about this; e.g. https://ghc.haskell.org/trac/ghc/ticket/3927. We now have a draft paper (wait a week) and a prototype implementation, that fixes the problem. But we need your help. We'd like to try our prototype on real code, not just toy examples. So, could you send George a pointer to any packages you have, or know of, that * use GADTS (or other fancy type features) and * would benefit from accurate pattern-match overlap/redundancy warnings? Specifically: * Where you have had to add a catch-all f _ _ = error "impossible" to silence GHC from saying "missing patterns" * Or where you have added {-# OPTIONS_GHC -fno-warn-missing-patterns #-} to silence the warnings. * Or something else like that. George's email is in cc. Time is short - the ICFP deadline is on 27 Feb. So sooner is better than later for us. But later is better than never. Thank you! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at andres-loeh.de Thu Feb 19 19:18:58 2015 From: mail at andres-loeh.de (Andres Loeh) Date: Thu, 19 Feb 2015 20:18:58 +0100 Subject: [Haskell-cafe] Pattern match checking for GADTs In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEAA504@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> <618BE556AADD624C9C918AA5D5911BEF7BEAA504@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: Hi Simon and George. All of generics-sop, basic-sop, pretty-sop, lens-sop, json-sop (all on Hackage) have instances of such pattern matches. You can grep for 'error "inaccessible"' to find the places in question. Cheers, Andres On Thu, Feb 19, 2015 at 7:21 PM, Simon Peyton Jones wrote: > I have some code that I could provide, but I don't seem to see George's > email address in the CC (only Tom's). Perhaps GMail ate it for some reason - > but either way, I don't know where to send my code :) > > Second attempt, to try to include George?s email. If it?s not in cc, it > is: george.karachalias at gmail.com > > Strange. My ?sent items? folder definitely shows him in cc. > > Sorry for the spam. > > Simon > > > > From: Simon Peyton Jones > Sent: 19 February 2015 17:38 > To: Haskell Libraries (libraries at haskell.org); Haskell Cafe > (haskell-cafe at haskell.org) > Cc: George Karachalias; Tom Schrijvers; Dimitrios Vytiniotis > (dimitris at microsoft.com); Simon Peyton-Jones > Subject: Pattern match checking for GADTs > > > > Friends > > George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are working > on finally cracking the problem of accurately reporting pattern-match > overlap and redundancy warnings, in the presence of GADTs. You know the > problem; consider > > vzip :: Vect n a -> Vect n b -> Vect n (a,b) > > vzip VN VN = VN > > vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) > > > > data Vect :: Nat -> * -> * where > > VN :: Vect Zero a > > VC :: a -> Vect n a -> Vect (Succ n) a > > Are there any missing equations in vzip? No! But GHC complains anyway. We > have lots of Trac tickets about this; e.g. > https://ghc.haskell.org/trac/ghc/ticket/3927. > > We now have a draft paper (wait a week) and a prototype implementation, that > fixes the problem. But we need your help. We?d like to try our prototype on > real code, not just toy examples. > > So, could you send George a pointer to any packages you have, or know of, > that > > ? use GADTS (or other fancy type features) and > > ? would benefit from accurate pattern-match overlap/redundancy > warnings? > > Specifically: > > ? Where you have had to add a catch-all > > f _ _ = error ?impossible? > > to silence GHC from saying ?missing patterns? > > ? Or where you have added {-# OPTIONS_GHC ?fno-warn-missing-patterns > #-} to silence the warnings. > > ? Or something else like that. > > George?s email is in cc. > > Time is short ? the ICFP deadline is on 27 Feb. So sooner is better than > later for us. But later is better than never. > > Thank you! > > Simon > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From briand at aracnet.com Thu Feb 19 19:29:03 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Thu, 19 Feb 2015 11:29:03 -0800 Subject: [Haskell-cafe] build troubles with ghc binary Message-ID: <28f43afefe71af294e36ec1e1922545e@aracnet.com> (i hope this is not a repost - sent it to haskell-cafe-bounces the first time) new thread because i have the details i should have provided in the first place. development system is centos 6.6 but i suspect something's broken because... i built and installed gmp-4.3.2 only to find that it's being build as a 32-bit library and will only build as 32-bits. which is really weird, because 64-bit system: 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17 01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux however- no problem- i'll simply download the 32-bit version of the ghc binary, which was built on centos no less, and install that instead of the 64-bit version. so i do that, point configure at my gmp thusly ./configure --prefix=/home/denheyer/local --with-gmp-includes=/home/denheyer/local/include --with-gmp-libraries=/home/denheyer/local/lib and get this checking for path to top of build tree... utils/ghc-pwd/dist-install/build/tmp/ghc-pwd: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory configure: error: cannot determine current directory ok- i haven't seen it do that before, but it's probably because i'm pointing it away from it's internal libgmp. that's fine, i'll set LD_LIBRARY_PATH. I do that and make install starts to work. yay! and then i get THIS ghc-cabal: Bad interface file: dist-install/build/GHC/CString.hi magic number mismatch: old/corrupt interface file? (wanted 33214052, got 129742) somebody really hates me. so originally i had downloaded the xz file, and even though i figure it's pretty much impossible that the archive was actually corrupted, i decide to download the bzip version just in case. yeah- not surprisingly, the build still breaks. any ideas ?? Thanks, Brian From rf at rufflewind.com Thu Feb 19 19:30:17 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Thu, 19 Feb 2015 14:30:17 -0500 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: That's an interesting idea! A few remarks: 1. For consistency it's probably a good idea to either backtick non-operators such as: infix `mappend` x y z or parenthesize operators such as: infix (+) x y z I tend to prefer the latter because my eyes are very accustomed to reading `infix + x y z` as `(infix) + (x y z)`. 2. I think it might be useful to have a multiline version: infix (+) in x y w z * d which the lexer desugars to: infix (+) in { x ; y w ; z * d } and is semantically equivalent to: infix (+) x (y w) (z * d) This provides the additional benefit of not having to parenthesize non-atomic arguments, which can be a source of typos. From goodingm at gmail.com Thu Feb 19 20:00:59 2015 From: goodingm at gmail.com (htebalaka) Date: Thu, 19 Feb 2015 13:00:59 -0700 (MST) Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: <1424376059613-5765684.post@n5.nabble.com> If this was used, you could probably also extend it to patterns where the function is a data constructor. Might be handy for vectors too, where OverloadedLists doesn't work. I could see myself using this to make arrow-y types easier to work with; being able to treat sums and products like lists would be much nicer than the type operator route, though that would require (,) not to be handled specially. Christopher Done-2 wrote > On 19 February 2015 at 18:53, Nils Schweinsberg < > mail@ > > wrote: >> What would be the typing rules for this? What would be the types of >> e.g. pointfree written function definitions (`f` in `let f = infix + 5 >> in f 2 + f 2 3 4`)? > > Purely syntactical, the translation I gave was literal: let f = infix > + 5 is the same as let f = (5 +). But to avoid confusion it's also > possible to disallow unary arguments and mandate at least two > arguments. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Infix-expression-keyword-XInfixExpressions-tp5765656p5765684.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From danburton.email at gmail.com Thu Feb 19 20:25:05 2015 From: danburton.email at gmail.com (Dan Burton) Date: Thu, 19 Feb 2015 12:25:05 -0800 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: I feel the same about this as I do about idiom brackets. I think QuasiQuotes need more love. They are a little heavier syntactically, but are flexible enough to accomplish the same thing. blah = [ infixQ | (+) foo bar baz quux ] blarg = [ idiomQ | pureFunc fa fb fc ] Perhaps the extension that we should be proposing is to make QuasiQuotes syntactically lighter. {-# LANGUAGE QQLite #-} blah = infixQ (+) foo bar baz quux blarg = idiomQ pureFunc fa fb fc Obviously some thought needs to be put into multiline/precedence/etc; I don't think all QuasiQuoters would be suitable for usage in this way, but Chris's existing ideas for his proposal seems to apply just as well to this one. (Also a bikeshedding comment: I think the keyword "infix" is not adequately descriptive for this particular proposal. I'd prefer "vararg" or something of the sort.) -- Dan Burton On Thu, Feb 19, 2015 at 6:51 AM, Christopher Done wrote: > Ahoy, > > The idiom discussion brought back to mind a general problem (well, for > me) in Haskell syntax which is there is no syntactic sugar for > interspersing operators to many arguments. > > Regarding a solution for this, I wrote up a wee proposal here: > https://gist.github.com/chrisdone/d9d33e4770a2fef19ad1 > > If I go ahead and implement this in GHC as -XInfixExpressions or > something (better names welcome), would it be likely to be accepted? I > could first do an implementation in haskell-src-exts to demonstrate > the concept. > > Ciao! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Thu Feb 19 20:53:21 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 21:53:21 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On 19 February 2015 at 21:25, Dan Burton wrote: > I feel the same about this as I do about idiom brackets. I think QuasiQuotes need more love. They are a little heavier syntactically, but are flexible enough to accomplish the same thing. Yeah, if quasi quotes were more like Lisp macros that'd make a bunch of these cases easier. It's a general complaint I have with TH, it makes simple rewrites like this too not-worth-it. If I had such macros I would've written an 'idiom' and 'infix' macro ages ago and wouldn't have had to ask for approval from anyone. But true macros seems much harder to slip by Haskellers. $(idiom [|f x y z|]) is too heavy, but idiom f x y z is too implicit. From mail at nils.cc Thu Feb 19 21:58:53 2015 From: mail at nils.cc (Nils Schweinsberg) Date: Thu, 19 Feb 2015 22:58:53 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: If so, I feel like this would break consistency with the current syntax since e.g. all these definitions of `f` would be valid but have completely different type/meaning (even though in "classical" Haskell they would be identical): f x y = infix (+) 1 2 x y -- f :: Int -> Int -> Int f x = infix (+) 1 2 x -- f :: Int -> Int f = infix (+) 1 2 -- f :: Int I like the general idea to represent variable argument functions as infix function applications, but I wouldn't like a purely syntactical solution that adds no real new functionality and is biased towards non-function values like strings, integeres, etc. On Thu, Feb 19, 2015 at 7:11 PM, Christopher Done wrote: > On 19 February 2015 at 18:53, Nils Schweinsberg wrote: > > What would be the typing rules for this? What would be the types of > > e.g. pointfree written function definitions (`f` in `let f = infix + 5 > > in f 2 + f 2 3 4`)? > > Purely syntactical, the translation I gave was literal: let f = infix > + 5 is the same as let f = (5 +). But to avoid confusion it's also > possible to disallow unary arguments and mandate at least two > arguments. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Thu Feb 19 22:05:50 2015 From: chrisdone at gmail.com (Christopher Done) Date: Thu, 19 Feb 2015 23:05:50 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On 19 February 2015 at 22:58, Nils Schweinsberg wrote: > I like the general idea to represent variable argument functions as infix > function applications, but I wouldn't like a purely syntactical solution > that adds no real new functionality Well, it adds the functionality that it adds. Do notation, if/then/else, "where" syntax, bang patterns, etc. are "purely syntactical solutions that add no real new functionality" by this measure. Some of the best language features are made by a simple transformation. From david.feuer at gmail.com Thu Feb 19 23:42:02 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 19 Feb 2015 18:42:02 -0500 Subject: [Haskell-cafe] Pattern match checking for GADTs In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> References: <618BE556AADD624C9C918AA5D5911BEF7BEAA3CE@DB3PRD3001MB020.064d.mgd.msft.net> Message-ID: I just want to thank you folks for doing this. David On Thu, Feb 19, 2015 at 12:37 PM, Simon Peyton Jones wrote: > Friends > > George Karachalas, Tom Schrijvers, Dimitrios Vytiniotis, and I are working > on finally cracking the problem of accurately reporting pattern-match > overlap and redundancy warnings, in the presence of GADTs. You know the > problem; consider > > vzip :: Vect n a -> Vect n b -> Vect n (a,b) > > vzip VN VN = VN > > vzip (VC x xs) (VC y ys) = VC (x,y) (vzip xs ys) > > > > data Vect :: Nat -> * -> * where > > VN :: Vect Zero a > > VC :: a -> Vect n a -> Vect (Succ n) a > > Are there any missing equations in vzip? No! But GHC complains anyway. We > have lots of Trac tickets about this; e.g. > https://ghc.haskell.org/trac/ghc/ticket/3927. > > We now have a draft paper (wait a week) and a prototype implementation, that > fixes the problem. But we need your help. We?d like to try our prototype on > real code, not just toy examples. > > So, could you send George a pointer to any packages you have, or know of, > that > > ? use GADTS (or other fancy type features) and > > ? would benefit from accurate pattern-match overlap/redundancy > warnings? > > Specifically: > > ? Where you have had to add a catch-all > > f _ _ = error ?impossible? > > to silence GHC from saying ?missing patterns? > > ? Or where you have added {-# OPTIONS_GHC ?fno-warn-missing-patterns > #-} to silence the warnings. > > ? Or something else like that. > > George?s email is in cc. > > Time is short ? the ICFP deadline is on 27 Feb. So sooner is better than > later for us. But later is better than never. > > Thank you! > > Simon > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From goodingm at gmail.com Fri Feb 20 00:44:07 2015 From: goodingm at gmail.com (htebalaka) Date: Thu, 19 Feb 2015 17:44:07 -0700 (MST) Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: <1424393047355-5765701.post@n5.nabble.com> You could always follow the lead of BangPatterns and reserve a character to make the syntax less ambiguous if you're using a function or macro. I think (`idiom f a b) would be much nicer than quasi quoters are currently (with the parentheses optional if the 'idiom' is being called on all the arguments to the end of line). I don't think there are any valid uses of back ticks when the token isn't immediately followed by another back tick. The only real issue is making sure they nest properly. Nils Schweinsberg-2 wrote > If so, I feel like this would break consistency with the current syntax > since e.g. all these definitions of `f` would be valid but have completely > different type/meaning (even though in "classical" Haskell they would be > identical): > > f x y = infix (+) 1 2 x y -- f :: Int -> Int -> Int > f x = infix (+) 1 2 x -- f :: Int -> Int > f = infix (+) 1 2 -- f :: Int > > I like the general idea to represent variable argument functions as infix > function applications, but I wouldn't like a purely syntactical solution > that adds no real new functionality and is biased towards non-function > values like strings, integeres, etc. > > On Thu, Feb 19, 2015 at 7:11 PM, Christopher Done < > chrisdone@ > > > wrote: > >> On 19 February 2015 at 18:53, Nils Schweinsberg < > mail@ > > wrote: >> > What would be the typing rules for this? What would be the types of >> > e.g. pointfree written function definitions (`f` in `let f = infix + 5 >> > in f 2 + f 2 3 4`)? >> >> Purely syntactical, the translation I gave was literal: let f = infix >> + 5 is the same as let f = (5 +). But to avoid confusion it's also >> possible to disallow unary arguments and mandate at least two >> arguments. >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@ > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Infix-expression-keyword-XInfixExpressions-tp5765656p5765701.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From ekirpichov at gmail.com Fri Feb 20 05:26:37 2015 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Fri, 20 Feb 2015 05:26:37 +0000 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? References: <54E44439.5070304@ro-che.info> Message-ID: On Tue Feb 17 2015 at 11:50:20 PM Roman Cheplyaka wrote: > Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its > problem is that it's not tail-recursive. > The problem is that when you say foldr (+) 0 [1, 2, 3, 4, 5] you build a thunk "1 + (2 + (3 + (4 + (5 + 0))))", which has - let's call it "whnf evaluation depth" of 4 (you need a stack of size 4 to evaluate it to whnf). I would like a type system that would disallow building thunks with *unbounded* whnf evaluation depth. I'm thinking we could annotate every type in every type signature with this depth. Let us use a special kind "@" for these annotations, allow polymorphism on them, and use "t at d" to denote "a value of type t requiring whnf evaluation depth d". (+) :: forall (a:@) (b:@) . Int at a -> Int at b -> Int@(1+max(a,b)); ($) :: forall (a:@) (b:@->@) . (forall (a:@) (b:@->@) . x at a -> y@(b a)) -> x at a -> y@(b a) The type signature for (.) quickly gets unwieldy and I wasn't able to even write down the signature for foldr :) but perhaps you get the idea. Some informal properties this would have: * whnf depth of calling a function in a tailcall position is max(whnf depth of the function itself, whnf depth of its argument). * whnf depth of "case x of { ... }" is 1. * In the context of "case x of { ...(primitive pattern)... }", whnf depth of x is 0. Does this make any sense? > foldl (+) 0 would be an example of a laziness issue. > > If you want to specify which functions should or shouldn't be used in a > lazy context, take a look at polarity (see Harper's Practical > Foundations for Programming Languages). So you could say, for instance, > that it doesn't make sense to use + in a lazy context; that'd eliminate > half the cases of laziness-induced memory leaks in practice. > > If instead you want to impose some upper bound on the memory consumption > without caring about specific cases, then see this ICFP'12 paper: > http://www.dcc.fc.up.pt/~pbv/AALazyExtended.pdf > > On 18/02/15 07:04, Eugene Kirpichov wrote: > > Hello haskell-cafe, > > > > Let me repost here a question I posted to cstheory stackexchange - in > > hopes that there are more type theory experts here. > > > > http://cstheory.stackexchange.com/questions/29518/type- > systems-preventing-laziness-related-memory-leaks > > > > Perhaps the main source of performance problems in Haskell is when a > > program inadvertently builds up a thunk of unbounded depth - this causes > > both a memory leak and a potential stack overflow when evaluating. The > > classic example is defining sum = foldr (+) 0 in Haskell. > > > > Are there any type systems which statically enforce lack of such thunks > > in a program using a lazy language? > > > > Seems like this should be on the same order of difficulty as proving > > other static program properties using type system extensions, e.g. some > > flavors of thread safety or memory safety. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Feb 20 07:05:50 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 20 Feb 2015 02:05:50 -0500 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: References: <54E44439.5070304@ro-che.info> Message-ID: Probably not. There's real code that depends on the current foldl semantics. On Wed, Feb 18, 2015 at 10:40 AM, Joe Hillenbrand wrote: > Is foldl = foldl' ever going to happen? > > On Tue, Feb 17, 2015 at 11:50 PM, Roman Cheplyaka wrote: >> >> Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its >> problem is that it's not tail-recursive. >> >> foldl (+) 0 would be an example of a laziness issue. >> >> If you want to specify which functions should or shouldn't be used in a >> lazy context, take a look at polarity (see Harper's Practical >> Foundations for Programming Languages). So you could say, for instance, >> that it doesn't make sense to use + in a lazy context; that'd eliminate >> half the cases of laziness-induced memory leaks in practice. >> >> If instead you want to impose some upper bound on the memory consumption >> without caring about specific cases, then see this ICFP'12 paper: >> http://www.dcc.fc.up.pt/~pbv/AALazyExtended.pdf >> >> On 18/02/15 07:04, Eugene Kirpichov wrote: >> > Hello haskell-cafe, >> > >> > Let me repost here a question I posted to cstheory stackexchange - in >> > hopes that there are more type theory experts here. >> > >> > >> > http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks >> > >> > Perhaps the main source of performance problems in Haskell is when a >> > program inadvertently builds up a thunk of unbounded depth - this causes >> > both a memory leak and a potential stack overflow when evaluating. The >> > classic example is defining sum = foldr (+) 0 in Haskell. >> > >> > Are there any type systems which statically enforce lack of such thunks >> > in a program using a lazy language? >> > >> > Seems like this should be on the same order of difficulty as proving >> > other static program properties using type system extensions, e.g. some >> > flavors of thread safety or memory safety. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From roma at ro-che.info Fri Feb 20 09:13:17 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 20 Feb 2015 11:13:17 +0200 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: References: <54E44439.5070304@ro-che.info> Message-ID: <54E6FAAD.5060907@ro-che.info> I'd be curious to see a (non-contrived) example. On 20/02/15 09:05, David Feuer wrote: > Probably not. There's real code that depends on the current foldl semantics. > > On Wed, Feb 18, 2015 at 10:40 AM, Joe Hillenbrand wrote: >> Is foldl = foldl' ever going to happen? >> >> On Tue, Feb 17, 2015 at 11:50 PM, Roman Cheplyaka wrote: >>> >>> Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its >>> problem is that it's not tail-recursive. >>> >>> foldl (+) 0 would be an example of a laziness issue. >>> >>> If you want to specify which functions should or shouldn't be used in a >>> lazy context, take a look at polarity (see Harper's Practical >>> Foundations for Programming Languages). So you could say, for instance, >>> that it doesn't make sense to use + in a lazy context; that'd eliminate >>> half the cases of laziness-induced memory leaks in practice. >>> >>> If instead you want to impose some upper bound on the memory consumption >>> without caring about specific cases, then see this ICFP'12 paper: >>> http://www.dcc.fc.up.pt/~pbv/AALazyExtended.pdf >>> >>> On 18/02/15 07:04, Eugene Kirpichov wrote: >>>> Hello haskell-cafe, >>>> >>>> Let me repost here a question I posted to cstheory stackexchange - in >>>> hopes that there are more type theory experts here. >>>> >>>> >>>> http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks >>>> >>>> Perhaps the main source of performance problems in Haskell is when a >>>> program inadvertently builds up a thunk of unbounded depth - this causes >>>> both a memory leak and a potential stack overflow when evaluating. The >>>> classic example is defining sum = foldr (+) 0 in Haskell. >>>> >>>> Are there any type systems which statically enforce lack of such thunks >>>> in a program using a lazy language? >>>> >>>> Seems like this should be on the same order of difficulty as proving >>>> other static program properties using type system extensions, e.g. some >>>> flavors of thread safety or memory safety. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From roma at ro-che.info Fri Feb 20 09:23:22 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 20 Feb 2015 11:23:22 +0200 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: References: <54E44439.5070304@ro-che.info> Message-ID: <54E6FD0A.5030003@ro-che.info> On 20/02/15 07:26, Eugene Kirpichov wrote: > > > On Tue Feb 17 2015 at 11:50:20 PM Roman Cheplyaka > wrote: > > Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its > problem is that it's not tail-recursive. > > The problem is that when you say foldr (+) 0 [1, 2, 3, 4, 5] you build a > thunk "1 + (2 + (3 + (4 + (5 + 0))))", which has - let's call it "whnf > evaluation depth" of 4 (you need a stack of size 4 to evaluate it to whnf). This is not a thunk. These values would be pushed to the stack, but no thunks will be created. Just so that you have no doubts left, here's the STG code for foldr (+) 0: $wgo = \r srt:SRT:[] [w] case w of _ { [] -> 0; : y ys -> case y of _ { I# x -> case $wgo ys of ww { __DEFAULT -> +# [x ww]; }; }; }; As you can see, there are no lets here, only cases. Roman From k-bx at k-bx.com Fri Feb 20 12:34:49 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Fri, 20 Feb 2015 14:34:49 +0200 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: References: <54E44439.5070304@ro-che.info> Message-ID: Eugene, I find your idea quite interesting. One thing that I'd say is that since you don't know how many recursive calls will foldr do at runtime, you can't say at compile-time it's thunk depth. Thus, I think, if you would be able to express something that is similar to type-level `Nat`, which could also be `Infinity` (e.g., either it's a known nat or an infinity), you could do something like that. Here's my code (which I suggest as something that's more concrete than notation you ovided): ``` {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Main where import GHC.TypeLits newtype Nf (n::Nat) a = Nf a -- TODO: add deepseq to ensure? toNf :: a -> Nf 0 a toNf = Nf unNf :: Nf n a -> a unNf (Nf x) = x type family Max (n :: Nat) (m :: Nat) :: Nat -- Implement properly later somehow type instance Max 0 0 = 0 type instance Max 0 m = m type instance Max n 0 = n type instance Max 1 1 = 1 -- addition creates a thunk of `(max n m) + 1` depth nfAdd :: (Num a) => Nf n a -> Nf m a -> Nf ((Max n m) + 1) a nfAdd x y = Nf ((unNf x) + (unNf y)) -- TODO: think on this. Need infinity? nfFold :: (Nf n1 a -> Nf n2 b -> Nf n3 b) -> Nf n4 b -> Nf n5 [a] -> Nf n6 b nfFold _ acc (Nf []) = Nf (unNf acc) nfFold f acc xs = undefined main :: IO () main = do let nfZero = (toNf 0) nfTwo = (toNf 2) printNf (nfAdd nfZero nfTwo :: Nf 1 Int) putStrLn "Hi!" where printNf = print . unNf ``` Is this is kind of thing you were talking about? Thanks! On Fri, Feb 20, 2015 at 7:26 AM, Eugene Kirpichov wrote: > > > On Tue Feb 17 2015 at 11:50:20 PM Roman Cheplyaka > wrote: > >> Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its >> problem is that it's not tail-recursive. >> > The problem is that when you say foldr (+) 0 [1, 2, 3, 4, 5] you build a > thunk "1 + (2 + (3 + (4 + (5 + 0))))", which has - let's call it "whnf > evaluation depth" of 4 (you need a stack of size 4 to evaluate it to whnf). > > I would like a type system that would disallow building thunks with > *unbounded* whnf evaluation depth. > > I'm thinking we could annotate every type in every type signature with > this depth. Let us use a special kind "@" for these annotations, allow > polymorphism on them, and use "t at d" to denote "a value of type t > requiring whnf evaluation depth d". > > (+) :: forall (a:@) (b:@) . Int at a -> Int at b -> Int@(1+max(a,b)); > > ($) :: forall (a:@) (b:@->@) . (forall (a:@) (b:@->@) . x at a -> y@(b a)) > -> x at a -> y@(b a) > > The type signature for (.) quickly gets unwieldy and I wasn't able to even > write down the signature for foldr :) but perhaps you get the idea. > > Some informal properties this would have: > * whnf depth of calling a function in a tailcall position is max(whnf > depth of the function itself, whnf depth of its argument). > * whnf depth of "case x of { ... }" is 1. > * In the context of "case x of { ...(primitive pattern)... }", whnf depth > of x is 0. > > Does this make any sense? > > >> foldl (+) 0 would be an example of a laziness issue. >> >> If you want to specify which functions should or shouldn't be used in a >> lazy context, take a look at polarity (see Harper's Practical >> Foundations for Programming Languages). So you could say, for instance, >> that it doesn't make sense to use + in a lazy context; that'd eliminate >> half the cases of laziness-induced memory leaks in practice. >> >> If instead you want to impose some upper bound on the memory consumption >> without caring about specific cases, then see this ICFP'12 paper: >> http://www.dcc.fc.up.pt/~pbv/AALazyExtended.pdf >> >> On 18/02/15 07:04, Eugene Kirpichov wrote: >> > Hello haskell-cafe, >> > >> > Let me repost here a question I posted to cstheory stackexchange - in >> > hopes that there are more type theory experts here. >> > >> > http://cstheory.stackexchange.com/questions/29518/type- >> systems-preventing-laziness-related-memory-leaks >> > >> > Perhaps the main source of performance problems in Haskell is when a >> > program inadvertently builds up a thunk of unbounded depth - this causes >> > both a memory leak and a potential stack overflow when evaluating. The >> > classic example is defining sum = foldr (+) 0 in Haskell. >> > >> > Are there any type systems which statically enforce lack of such thunks >> > in a program using a lazy language? >> > >> > Seems like this should be on the same order of difficulty as proving >> > other static program properties using type system extensions, e.g. some >> > flavors of thread safety or memory safety. >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Feb 20 13:02:34 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 20 Feb 2015 14:02:34 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: <1424437354.1986.18.camel@joachim-breitner.de> Hi, Am Donnerstag, den 19.02.2015, 16:42 +0100 schrieb Christopher Done: > * Some things are foldable cleanly like monoids, so you can just > mconcat [x,y,z] and that'll be inlined (I think). the sufficiently smart compiler might do that, but not this one (GHC 7.8.4). Neither in the generic case of foo :: Monoid a => a -> a -> a -> a -> a -> a foo a b c d e = mconcat [a,b,c,d,e] nor the monomophic case of foo :: String -> String -> String -> String -> String -> String foo a b c d e = mconcat [a,b,c,d,e] BTW, would your proposal extend to types? i.e. foo :: infix (->) String String String String String foo a b c d e = mconcat [a,b,c,d,e] Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From chrisdone at gmail.com Fri Feb 20 13:06:08 2015 From: chrisdone at gmail.com (Christopher Done) Date: Fri, 20 Feb 2015 14:06:08 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: <1424437354.1986.18.camel@joachim-breitner.de> References: <1424437354.1986.18.camel@joachim-breitner.de> Message-ID: On 20 February 2015 at 14:02, Joachim Breitner wrote: > the sufficiently smart compiler might do that, but not this one (GHC > 7.8.4). Neither in the generic case of > > foo :: Monoid a => a -> a -> a -> a -> a -> a > foo a b c d e = mconcat [a,b,c,d,e] > > nor the monomophic case of > > foo :: String -> String -> String -> String -> String -> String > foo a b c d e = mconcat [a,b,c,d,e] Huh, really? Good to know. I'll update the doc. :-) > BTW, would your proposal extend to types? i.e. > > foo :: infix (->) String String String String String > foo a b c d e = mconcat [a,b,c,d,e] Could do, that would come in handy for HList kind of constructions too. From o.klinke at dkfz-heidelberg.de Fri Feb 20 16:58:42 2015 From: o.klinke at dkfz-heidelberg.de (Dr. Olaf Klinke) Date: Fri, 20 Feb 2015 17:58:42 +0100 (CET) Subject: [Haskell-cafe] Very large data structures in the heap In-Reply-To: References: Message-ID: > To an extent, the virtual memory of a modern operating system solves the memory bottleneck. > > I'm curious what you were hoping for when thinking of exploiting laziness. If the search tree is truly huge, you'd probably resort to fancy (or fuzzy or both) algorithms to break up the work. > -- Kim-Ee Here is an update: I considered comments made by Kim-Ee and Jachim Breitner and decided to represent my search tree as an unboxed IOVector that stores indices in its elements. The code now looks very imperative. It is a bit simpler though as the pure tying-the-knot code that builds the cyclic structure. I tried several approaches for lookups: (i) Reconstruct the search tree (lazily) from the vector each time a query is made. A relatively small part should actually be constructed and garbage-collected. This turned out to be not overwhelmingly fast. (ii) Keep the search tree structure implicit. Instead, descend the tree by doing reads on the vector and follow the included pointers around. This was faster. (iii) Combine both: After a pre-specified number of lookup/insert cycles, reconstruct a part of the search tree in the heap and traverse this, keeping the same tree for subsequent lookups. When reaching a leaf in the heap, continue hopping around the IOVector. Since the size of the vector is not known beforehand, inserts use Data.Vector.Unboxed.Mutable.grow from time to time. As I read here (https://github.com/haskell/vector/issues/36) and tested on my machine, growing the IOVector makes a copy of it. So after my IOVector has grown to considerable size, additional inserts slow down considerably. However, when constructing a tree of final size 1.2 million nodes, the approach (iii) already outperforms my pure algorithm. A tree with 18 million nodes is no problem to construct. -- Olaf From ekirpichov at gmail.com Fri Feb 20 17:40:59 2015 From: ekirpichov at gmail.com (Eugene Kirpichov) Date: Fri, 20 Feb 2015 17:40:59 +0000 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? References: <54E44439.5070304@ro-che.info> <54E6FD0A.5030003@ro-che.info> Message-ID: On Fri Feb 20 2015 at 1:23:25 AM Roman Cheplyaka wrote: > On 20/02/15 07:26, Eugene Kirpichov wrote: > > > > > > On Tue Feb 17 2015 at 11:50:20 PM Roman Cheplyaka > > wrote: > > > > Note that foldr (+) 0 has nothing to do with laziness ? it's eager. > Its > > problem is that it's not tail-recursive. > > > > The problem is that when you say foldr (+) 0 [1, 2, 3, 4, 5] you build a > > thunk "1 + (2 + (3 + (4 + (5 + 0))))", which has - let's call it "whnf > > evaluation depth" of 4 (you need a stack of size 4 to evaluate it to > whnf). > > This is not a thunk. These values would be pushed to the stack, but no > thunks will be created. > > Just so that you have no doubts left, here's the STG code for foldr (+) 0: > > $wgo = \r srt:SRT:[] [w] > case w of _ { > [] -> 0; > : y ys -> > case y of _ { > I# x -> case $wgo ys of ww { > __DEFAULT -> +# [x ww]; > }; > }; > }; > > As you can see, there are no lets here, only cases. > Indeed - I guess the strictness analyzer did its job. Nevertheless, the expression foldr (+) 0 [1..n] requires an evaluation stack depth of n and I would like it to be uncompilable - I would like the type of foldr (+) 0 to be "[Int] -> Int@\infty" > > Roman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Fri Feb 20 19:12:29 2015 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 20 Feb 2015 14:12:29 -0500 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On Thu, Feb 19, 2015 at 10:42 AM, Christopher Done wrote: > Right, I see three use-cases: > > * Some things are foldable cleanly like monoids, so you can just > mconcat [x,y,z] and that'll be inlined (I think). > * Other things like x <|> y is not the same as asum [x,y] due to the > additional mempty being introduced. You can also use foldl1 kind of > functions, but they are partial and therefore not desirable. > * Finally, things like <*>, $=, $, ., #/:& (e.g. in HList/vinyl) can't > be folded at all, because the types are different. > > The third use-case doesn't have a solution that I'm aware of. So this > solves that. It also solves the second use-case, which has only a > partial (he he) solution. The first use-case is just a bonus. Should I > add this clarification to the proposal? I think this is a half-solution to the third option: https://gist.github.com/aavogt/433969cc83548e1f59ea Rather than adding more syntax, maybe it's better to make polymorphic functions/values easier to create. Writing instances of ApplyAB is a pain, but ghc could help, as it does with this quasiquoter http://lpaste.net/114788. Regards, Adam From chrisdone at gmail.com Fri Feb 20 19:25:30 2015 From: chrisdone at gmail.com (Christopher Done) Date: Fri, 20 Feb 2015 20:25:30 +0100 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: On 20 February 2015 at 20:12, adam vogt wrote: > I think this is a half-solution to the third option Because? From vogt.adam at gmail.com Fri Feb 20 19:57:59 2015 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 20 Feb 2015 14:57:59 -0500 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: Because: 1. It's hard to write an ApplyAB instance 2. using AllowAmbiguousTypes means you can't partially apply the iI / iIwith without giving a type signature (which ghci is quite able to infer for you). When we get -XDysfunctionalDependencies (https://phabricator.haskell.org/D69) I think we'll be able to stop using AllowAmbiguousTypes. those might not be big problems, but the current solution (use an infix operator) is a much smaller problem for me. On Fri, Feb 20, 2015 at 2:25 PM, Christopher Done wrote: > On 20 February 2015 at 20:12, adam vogt wrote: >> I think this is a half-solution to the third option > > Because? From joehillen at gmail.com Fri Feb 20 19:58:30 2015 From: joehillen at gmail.com (Joe Hillenbrand) Date: Fri, 20 Feb 2015 11:58:30 -0800 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: <54E6FAAD.5060907@ro-che.info> References: <54E44439.5070304@ro-che.info> <54E6FAAD.5060907@ro-che.info> Message-ID: Me too. Last I heard, there wasn't any code that depended on foldl being lazy, and it doesn't really seem possible. http://www.well-typed.com/blog/90/ On Fri, Feb 20, 2015 at 1:13 AM, Roman Cheplyaka wrote: > I'd be curious to see a (non-contrived) example. > > On 20/02/15 09:05, David Feuer wrote: > > Probably not. There's real code that depends on the current foldl > semantics. > > > > On Wed, Feb 18, 2015 at 10:40 AM, Joe Hillenbrand > wrote: > >> Is foldl = foldl' ever going to happen? > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Feb 20 20:41:36 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 20 Feb 2015 21:41:36 +0100 Subject: [Haskell-cafe] Type systems preventing laziness-related memory leaks? In-Reply-To: <54E6FAAD.5060907@ro-che.info> References: <54E44439.5070304@ro-che.info> <54E6FAAD.5060907@ro-che.info> Message-ID: <1424464896.15376.23.camel@joachim-breitner.de> Hi, last = foldl (\_ x -> x) (errorEmptyList "last") (see http://git.haskell.org/ghc.git/blob/f44bbc83bab62f9a2d25e69d87c2b4af25318d52:/libraries/base/GHC/List.hs#l88) not sure how contrived that is, but at least it?s real code in GHC-7.10. Greetings, Joachim Am Freitag, den 20.02.2015, 11:13 +0200 schrieb Roman Cheplyaka: > I'd be curious to see a (non-contrived) example. > > On 20/02/15 09:05, David Feuer wrote: > > Probably not. There's real code that depends on the current foldl semantics. > > > > On Wed, Feb 18, 2015 at 10:40 AM, Joe Hillenbrand wrote: > >> Is foldl = foldl' ever going to happen? > >> > >> On Tue, Feb 17, 2015 at 11:50 PM, Roman Cheplyaka wrote: > >>> > >>> Note that foldr (+) 0 has nothing to do with laziness ? it's eager. Its > >>> problem is that it's not tail-recursive. > >>> > >>> foldl (+) 0 would be an example of a laziness issue. > >>> > >>> If you want to specify which functions should or shouldn't be used in a > >>> lazy context, take a look at polarity (see Harper's Practical > >>> Foundations for Programming Languages). So you could say, for instance, > >>> that it doesn't make sense to use + in a lazy context; that'd eliminate > >>> half the cases of laziness-induced memory leaks in practice. > >>> > >>> If instead you want to impose some upper bound on the memory consumption > >>> without caring about specific cases, then see this ICFP'12 paper: > >>> http://www.dcc.fc.up.pt/~pbv/AALazyExtended.pdf > >>> > >>> On 18/02/15 07:04, Eugene Kirpichov wrote: > >>>> Hello haskell-cafe, > >>>> > >>>> Let me repost here a question I posted to cstheory stackexchange - in > >>>> hopes that there are more type theory experts here. > >>>> > >>>> > >>>> http://cstheory.stackexchange.com/questions/29518/type-systems-preventing-laziness-related-memory-leaks > >>>> > >>>> Perhaps the main source of performance problems in Haskell is when a > >>>> program inadvertently builds up a thunk of unbounded depth - this causes > >>>> both a memory leak and a potential stack overflow when evaluating. The > >>>> classic example is defining sum = foldr (+) 0 in Haskell. > >>>> > >>>> Are there any type systems which statically enforce lack of such thunks > >>>> in a program using a lazy language? > >>>> > >>>> Seems like this should be on the same order of difficulty as proving > >>>> other static program properties using type system extensions, e.g. some > >>>> flavors of thread safety or memory safety. > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From rob at mars.org Sat Feb 21 00:58:59 2015 From: rob at mars.org (Rob Leslie) Date: Fri, 20 Feb 2015 16:58:59 -0800 Subject: [Haskell-cafe] Trouble with forkProcess Message-ID: <551292E7-498B-483F-8CDF-618F1FFC74F8@mars.org> Hi folks, I?d love to get a sense of the prevailing wisdom with respect to forkProcess from System.Posix.Process. I?m building a multithreaded (STM) application with potentially many threads simultaneously reading and writing to pieces of (an otherwise rather large) shared state. Occasionally I would like to record a whole snapshot of that state, and it seems to me a natural way to accomplish this is to fork a process (eliminating all the other threads) and perform a read-only dump of the state. This dump can be time-consuming, which is why I?d rather not have contention with other threads that may be trying to modify the state while I?m dumping. My experience with forkProcess so far is that sometimes it works brilliantly, and other times it just deadlocks. I?m at a loss to understand what the problem is, but the deadlock seems to occur before the new process gets any control -- certainly before it has started to access any of the shared state. I?m aware of the giant warning in the forkProcess documentation, but I?m not sure if or how it could explain the behavior I?m seeing. Has anyone else used forkProcess successfully? It?s possible too that I?m running into something related to the way I?m setting up a pipe to receive messages from the forked process. Here is what I?m doing: > runInForkedProcess :: ((Text -> IO ()) -> IO ()) -> > Consumer Text IO () -> IO Bool > runInForkedProcess iof consumer = do > process <- newEmptyMVar > result <- newEmptyMVar > > let handler = Catch $ do > status <- getProcessStatus False False =<< readMVar process > case status of > Just (Exited code) -> void $ tryPutMVar result (code == ExitSuccess) > Just Terminated{} -> void $ tryPutMVar result False > _ -> return () > > bracket (installHandler processStatusChanged handler Nothing) > (\former -> installHandler processStatusChanged former Nothing) $ \_ -> do > > (input, output) <- createPipe > > processId <- forkProcess $ do > closeFd input > bracket (fdToHandle output) hClose $ \outHandle -> do > hSetBuffering outHandle NoBuffering > iof (hPutStrLn outHandle) > putMVar process processId > > closeFd output > > bracket (fdToHandle input) hClose $ \inHandle -> do > hSetBuffering inHandle NoBuffering > runEffect $ fromHandle inHandle >-> for cat (yield . T.pack) >-> consumer > > takeMVar result Does anyone have any advice? Many thanks, -- Rob Leslie rob at mars.org From allbery.b at gmail.com Sat Feb 21 01:11:16 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 20 Feb 2015 20:11:16 -0500 Subject: [Haskell-cafe] Trouble with forkProcess In-Reply-To: <551292E7-498B-483F-8CDF-618F1FFC74F8@mars.org> References: <551292E7-498B-483F-8CDF-618F1FFC74F8@mars.org> Message-ID: On Fri, Feb 20, 2015 at 7:58 PM, Rob Leslie wrote: > My experience with forkProcess so far is that sometimes it works > brilliantly, and other times it just deadlocks. I?m at a loss to understand > what the problem is, but the deadlock seems to occur before the new process > gets any control -- certainly before it has started to access any of the > shared state. > I'd be using strace / truss / dtruss / platform equivalent to see what's going on in that case. > I?m aware of the giant warning in the forkProcess documentation, but I?m > not sure if or how it could explain the behavior I?m seeing. Has anyone > else used forkProcess successfully? > xmonad uses it extensively with no problems except an oddity on FreeBSD that appears to be some nonportable behavior inside GHC's I/O manager. (The person who ran into that was asked to submit a GHC bug report.) That said, it doesn't do any significant processing in the child process; the most common use is a double-fork with the grandchild doing executeFile. It is conceivable that the I/O manager is not handling some use cases other than that one properly; since most uses of forkProcess are followed by executeFile, it's entirely possible that some bug has crept in that only shows up in the few cases where that isn't done. It?s possible too that I?m running into something related to the way I?m > setting up a pipe to receive messages from the forked process. Here is what > I?m doing: > The basic pipe handling looks correct to me, for what it's worth. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From aditya.siram at gmail.com Sat Feb 21 02:32:47 2015 From: aditya.siram at gmail.com (aditya siram) Date: Fri, 20 Feb 2015 20:32:47 -0600 Subject: [Haskell-cafe] FLTK GUI Bindings - Alpha Release Message-ID: I'm pleased to announce the alpha release of Haskell bindings [1] to the FLTK [2] GUI library. On Linux and Mac this package and FLTK 1.3.3 [3] should install pretty smoothly. The library covers about 80+% of API and has 60+ widgets that can be used transparently from Haskell. You can read more about the motivation behind the library, installation instructions and quick start documentation here [4]. The package also comes with 14 demos to show you how to get started. There still isn't any support for Windows because I don't have access to a Windows machine, and don't have any experience with the Windows C/C++ build tools. The code itself should be fully portable. I could use some help here. Please report any issues on the Github page [5]. Hope you enjoy and I'd love any feedback on the install and development process. Thanks! -deech [1] http://hackage.haskell.org/package/fltkhs-0.1.0.0 [2] http://fltk.org [3] http://www.fltk.org/software.php?VERSION=1.3.3&FILE=fltk/1.3.3/fltk-1.3.3-source.tar.gz [4] http://hackage.haskell.org/package/fltkhs-0.1.0.0/docs/Graphics-UI-FLTK-LowLevel-FLTKHS.html [5] https://github.com/deech/fltkhs -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Sat Feb 21 07:11:37 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Sat, 21 Feb 2015 11:11:37 +0400 Subject: [Haskell-cafe] Trouble with forkProcess In-Reply-To: <551292E7-498B-483F-8CDF-618F1FFC74F8@mars.org> References: <551292E7-498B-483F-8CDF-618F1FFC74F8@mars.org> Message-ID: Hello, Rob. We are using forkProcess for similar reason: "share" complex immutable state, that takes much time to be created, and process isolation. I wrote "share" because big part of the structure is not in pinned memory, thus it would be shared up to GC, that will relocate this structures. But in our case its OK, because we can allow multiplying of structure, and reduced initialization time outterweights other problems. However in case if we need real sharing then we'd had to use other structures based on the storage pinned memory. We never experienced deadlocks in our case. However there are known problems with forkProcess like: https://ghc.haskell.org/trac/ghc/ticket/9347 and there were few topics in this mailing list, so you could get in a problematic case. -- Alexander On Feb 21, 2015 3:59 AM, "Rob Leslie" wrote: > Hi folks, > > I?d love to get a sense of the prevailing wisdom with respect to > forkProcess from System.Posix.Process. > > I?m building a multithreaded (STM) application with potentially many > threads simultaneously reading and writing to pieces of (an otherwise > rather large) shared state. Occasionally I would like to record a whole > snapshot of that state, and it seems to me a natural way to accomplish this > is to fork a process (eliminating all the other threads) and perform a > read-only dump of the state. This dump can be time-consuming, which is why > I?d rather not have contention with other threads that may be trying to > modify the state while I?m dumping. > > My experience with forkProcess so far is that sometimes it works > brilliantly, and other times it just deadlocks. I?m at a loss to understand > what the problem is, but the deadlock seems to occur before the new process > gets any control -- certainly before it has started to access any of the > shared state. > > I?m aware of the giant warning in the forkProcess documentation, but I?m > not sure if or how it could explain the behavior I?m seeing. Has anyone > else used forkProcess successfully? > > It?s possible too that I?m running into something related to the way I?m > setting up a pipe to receive messages from the forked process. Here is what > I?m doing: > > > runInForkedProcess :: ((Text -> IO ()) -> IO ()) -> > > Consumer Text IO () -> IO Bool > > runInForkedProcess iof consumer = do > > process <- newEmptyMVar > > result <- newEmptyMVar > > > > let handler = Catch $ do > > status <- getProcessStatus False False =<< readMVar process > > case status of > > Just (Exited code) -> void $ tryPutMVar result (code == > ExitSuccess) > > Just Terminated{} -> void $ tryPutMVar result False > > _ -> return () > > > > bracket (installHandler processStatusChanged handler Nothing) > > (\former -> installHandler processStatusChanged former Nothing) $ \_ > -> do > > > > (input, output) <- createPipe > > > > processId <- forkProcess $ do > > closeFd input > > bracket (fdToHandle output) hClose $ \outHandle -> do > > hSetBuffering outHandle NoBuffering > > iof (hPutStrLn outHandle) > > putMVar process processId > > > > closeFd output > > > > bracket (fdToHandle input) hClose $ \inHandle -> do > > hSetBuffering inHandle NoBuffering > > runEffect $ fromHandle inHandle >-> for cat (yield . T.pack) >-> > consumer > > > > takeMVar result > > Does anyone have any advice? > > Many thanks, > > -- > Rob Leslie > rob at mars.org > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 21 08:03:50 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 21 Feb 2015 09:03:50 +0100 Subject: [Haskell-cafe] how can I do this the best Message-ID: <54E83BE6.9080900@home.nl> Hello, Im busy with a programm which translates log files to another format. I also have to look if the lines in the old one have the rigtht format. Schould I check the format and also if another field contains a I, E or W. Or schould I do the checking in one clause and make another case on the rest ? Roelof From david.feuer at gmail.com Sat Feb 21 14:23:05 2015 From: david.feuer at gmail.com (David Feuer) Date: Sat, 21 Feb 2015 09:23:05 -0500 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54E83BE6.9080900@home.nl> References: <54E83BE6.9080900@home.nl> Message-ID: You should probably ask on the haskell-beginners list instead. And you should explain in much more detail what you are trying to do. David On Feb 21, 2015 3:03 AM, "Roelof Wobben" wrote: > Hello, > > > Im busy with a programm which translates log files to another format. > I also have to look if the lines in the old one have the rigtht format. > > Schould I check the format and also if another field contains a I, E or > W. > Or schould I do the checking in one clause and make another case on the > rest ? > > Roelof > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chneukirchen at gmail.com Sat Feb 21 14:43:42 2015 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sat, 21 Feb 2015 15:43:42 +0100 Subject: [Haskell-cafe] Munich Haskell Meeting, 2015-02-24 @ 19:30 Message-ID: <87vbivxr35.fsf@gmail.com> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, February 24 at Cafe Puck at 19h30. For details see here: http://www.haskell-munich.de/dates If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-feb-2015/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From voldermort at hotmail.com Sun Feb 22 09:34:23 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 22 Feb 2015 02:34:23 -0700 (MST) Subject: [Haskell-cafe] Haskell implementation of longest path algorithm Message-ID: <1424597663005-5765786.post@n5.nabble.com> Compared to the Nim code [https://github.com/logicchains/LPATHBench/blob/master/nim.nim] for a longest path algorithm, Haskell [https://github.com/logicchains/LPATHBench/blob/master/hs.hs] looks horrendously verbose and ugly, even if you ignore the pragmas and imports. Is this idiomatic Haskell style? Could it be clearer, but has to be written that way for performance - although it still takes 3.7x as long as the Nim version [https://github.com/logicchains/LPATHBench/blob/master/writeup.md]? I posted this to the beginners group last week, but no reply, so trying again here. -- View this message in context: http://haskell.1045720.n5.nabble.com/Haskell-implementation-of-longest-path-algorithm-tp5765786.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From atzeus at gmail.com Sun Feb 22 10:00:31 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Sun, 22 Feb 2015 11:00:31 +0100 Subject: [Haskell-cafe] Haskell implementation of longest path algorithm In-Reply-To: <1424597663005-5765786.post@n5.nabble.com> References: <1424597663005-5765786.post@n5.nabble.com> Message-ID: Well... I don't think anyone would consider this horrendous thing, idiomatic haskell... 2015-02-22 10:34 GMT+01:00 Jeremy : > Compared to the Nim code > [https://github.com/logicchains/LPATHBench/blob/master/nim.nim] for a > longest path algorithm, Haskell > [https://github.com/logicchains/LPATHBench/blob/master/hs.hs] looks > horrendously verbose and ugly, even if you ignore the pragmas and imports. > > Is this idiomatic Haskell style? Could it be clearer, but has to be written > that way for performance - although it still takes 3.7x as long as the Nim > version [https://github.com/logicchains/LPATHBench/blob/master/writeup.md > ]? > > I posted this to the beginners group last week, but no reply, so trying > again here. > > > > -- > View this message in context: > http://haskell.1045720.n5.nabble.com/Haskell-implementation-of-longest-path-algorithm-tp5765786.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sun Feb 22 13:01:26 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun, 22 Feb 2015 14:01:26 +0100 Subject: [Haskell-cafe] Looking for a new release manager for cabal Message-ID: (bcc: haskell-cafe) Hi, After about 3 years of cabal releases I'm looking for someone else to take over the responsibility as cabal release manager. As a release manager I try to keep on top of pull requests, make releases, and make sure bugs get triaged and bugfixes get release. Anyone interested? -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sun Feb 22 15:01:05 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun, 22 Feb 2015 16:01:05 +0100 Subject: [Haskell-cafe] Haskell implementation of longest path algorithm In-Reply-To: <1424597663005-5765786.post@n5.nabble.com> References: <1424597663005-5765786.post@n5.nabble.com> Message-ID: On Sun, 22 Feb 2015 10:34:23 +0100, Jeremy wrote: > Compared to the Nim code > [https://github.com/logicchains/LPATHBench/blob/master/nim.nim] for a > longest path algorithm, Haskell > [https://github.com/logicchains/LPATHBench/blob/master/hs.hs] looks > horrendously verbose and ugly, even if you ignore the pragmas and > imports. > > Is this idiomatic Haskell style? Could it be clearer, but has to be > written > that way for performance - although it still takes 3.7x as long as the > Nim version You can replace case isVisited of True -> return () False -> do with unless isVisited $ do in several places. ("unless" is from Control.Monad) Other options for simplification: 76 if dist > maxVal then writeIORef max dist else return ()) -> 76 when (dist > maxVal) $ writeIORef max dist ("when" is also from Control.Monad) if dist > maxDist then dist else maxDist -> max dist maxDist in several places. Note, the you cannot use the function max, if you used max as a variable name, like in max <- GV.foldM' acc (0::Int32) (nodes V.! (fromIntegral nodeID)) (If you use -Wall when compiling, you probably get a warning when you use max as a variable name) Replace: newMax <- case isVisited of True -> return maxDist False -> do -> newMax <- if isVisited then return maxDist else do You used fromIntegral quite a lot, could you change some type(s) to prevent this? Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From k-bx at k-bx.com Sun Feb 22 15:17:16 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Sun, 22 Feb 2015 17:17:16 +0200 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54E83BE6.9080900@home.nl> References: <54E83BE6.9080900@home.nl> Message-ID: Hi Roelof, You forgot to explain what are those fields you are talking about, and what are I/E/W . Also what are those clauses you are talking about? Cheers. 21 ???. 2015 09:03, ?????????? "Roelof Wobben" ???????: > Hello, > > > Im busy with a programm which translates log files to another format. > I also have to look if the lines in the old one have the rigtht format. > > Schould I check the format and also if another field contains a I, E or > W. > Or schould I do the checking in one clause and make another case on the > rest ? > > Roelof > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sun Feb 22 16:24:19 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sun, 22 Feb 2015 17:24:19 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> Message-ID: <54EA02B3.4060700@home.nl> An HTML attachment was scrubbed... URL: From jyotirmoy at jyotirmoy.net Sun Feb 22 18:06:24 2015 From: jyotirmoy at jyotirmoy.net (Jyotirmoy Bhattacharya) Date: Sun, 22 Feb 2015 23:36:24 +0530 Subject: [Haskell-cafe] Haskell implementation of longest path algorithm In-Reply-To: <1424597663005-5765786.post@n5.nabble.com> References: <1424597663005-5765786.post@n5.nabble.com> Message-ID: On Sun, Feb 22, 2015 at 3:04 PM, Jeremy wrote: > Compared to the Nim code > [https://github.com/logicchains/LPATHBench/blob/master/nim.nim] for a > longest path algorithm, Haskell > [https://github.com/logicchains/LPATHBench/blob/master/hs.hs] looks > horrendously verbose and ugly, even if you ignore the pragmas and imports. > > Is this idiomatic Haskell style? Could it be clearer, but has to be written > that way for performance - although it still takes 3.7x as long as the Nim > version [https://github.com/logicchains/LPATHBench/blob/master/writeup.md > ]? > > A clearer version http://lpaste.net/120981 though this is 2x-3x slower than the Haskell version above. Regards, Jyotirmoy Bhattacharya http://www.jyotirmoy.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertram.felgenhauer at googlemail.com Sun Feb 22 19:36:11 2015 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun, 22 Feb 2015 20:36:11 +0100 Subject: [Haskell-cafe] ANN: Lambdabot 5.0 Message-ID: <20150222193611.GB5885@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Dear Haskell users, after a long hiatus, I'm pleased to announce that we have just released Lambdabot 5.0 on hackage. Lambdabot is an IRC bot that can also be used offline; it provides tools for querying information about and even for producing Haskell code. To install it, use the following command: cabal install lambdabot-haskell-plugins lambdabot (cabal install lambdabot *should* work, but instead seems to send cabal's dependency solver onto a wild goose chase from which it fails to return.) * What's new Lambdabot is now maintained by a team, currently consisting of James Cook and me. The repository and bugtracker have moved to https://github.com/lambdabot/lambdabot The most significant change compared to lambdabot 4.3 is that lambdabot has been refactored and split into multiple packages. As a result, lambdabot has become easier to customize: simply edit the source files (Main.hs and Modules.hs) in the lambdabot package, and optionally add your own plugins. Other notable changes include - The code snippets provided by @src have been updated. (thanks to Artyom) - Support for IRC server authentication. - Pinging the IRC server regularly in order to detect one-sided disconnects. There have also been many minor tweaks and bug fixes. * What's next There are still a number of open issues on the bugtracker, so you can expect another release soon. Have fun with lambdabot, Bertram and James From k-bx at k-bx.com Sun Feb 22 22:35:13 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Mon, 23 Feb 2015 00:35:13 +0200 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EA02B3.4060700@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> Message-ID: So, as the simplest solution -- you need to read file, split it by lines (convert it to list of lines), for each line check it for validity and return some result, which would have type, for example Either String LogMsg , where Left String indicates error, and other one is Right LogMsg, with this type: data LogLevel = LevelW | LevelE | LevelI data LogMsg = LogMsg LogLevel Int String Then you would filter all rights to output to new logfile, and filter all lefts to do whatever you wanted to do with them (you didn't specify this, I think). Does this look clear? Ask if you have more questions! 22 ???. 2015 18:24, ?????????? "Roelof Wobben" ???????: > Sorry, > > I stand for Info > E stands for Error > W stands for Warning. > > The clause Im talking about is that the log message must be the format > char Int [char] so like this: W 10 this is a warning > All the sentences that are not of this format , like for example this one: > W this is a false warning , must have another output. > That's is also true when the first Char is not a W, E or I. > > When it's a W , E, or I then the char must be converted to the word > Warning, Error or Info. > > I hope it's clear now what I want. > > Roelof > > > > Konstantine Rybnikov schreef op 22-2-2015 om 16:17: > > Hi Roelof, > > You forgot to explain what are those fields you are talking about, and > what are I/E/W . Also what are those clauses you are talking about? > > Cheers. > 21 ???. 2015 09:03, ?????????? "Roelof Wobben" ???????: > >> Hello, >> >> >> Im busy with a programm which translates log files to another format. >> I also have to look if the lines in the old one have the rigtht format. >> >> Schould I check the format and also if another field contains a I, E or >> W. >> Or schould I do the checking in one clause and make another case on the >> rest ? >> >> Roelof >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jyotirmoy at jyotirmoy.net Mon Feb 23 05:27:38 2015 From: jyotirmoy at jyotirmoy.net (Jyotirmoy Bhattacharya) Date: Mon, 23 Feb 2015 10:57:38 +0530 Subject: [Haskell-cafe] Haskell implementation of longest path algorithm In-Reply-To: References: <1424597663005-5765786.post@n5.nabble.com> Message-ID: On Sun, Feb 22, 2015 at 11:36 PM, Jyotirmoy Bhattacharya < jyotirmoy at jyotirmoy.net> wrote: > On Sun, Feb 22, 2015 at 3:04 PM, Jeremy wrote: > >> Compared to the Nim code >> [https://github.com/logicchains/LPATHBench/blob/master/nim.nim] for a >> longest path algorithm, Haskell >> [https://github.com/logicchains/LPATHBench/blob/master/hs.hs] looks >> horrendously verbose and ugly, even if you ignore the pragmas and imports. >> >> Is this idiomatic Haskell style? Could it be clearer, but has to be >> written >> that way for performance - although it still takes 3.7x as long as the Nim >> version [https://github.com/logicchains/LPATHBench/blob/master/writeup.md >> ]? >> >> A clearer version > http://lpaste.net/120981 > though this is 2x-3x slower than the Haskell version above. > > > Another version that uses mutable vectors to track the visited nodes and has almost the same run time as the Haskell version in the LPATHBench repository: http://lpaste.net/121012 Regards, Jyotirmoy Bhattacharya -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozgurakgun at gmail.com Mon Feb 23 10:36:59 2015 From: ozgurakgun at gmail.com (Ozgur Akgun) Date: Mon, 23 Feb 2015 10:36:59 +0000 Subject: [Haskell-cafe] hpc - ignore some expressions Message-ID: Hi, I am generating code coverage reports using hpc, it works great. The reports would be much more helpful if I could somehow tell hpc to treat certain expressions as "covered" though. As an example, let's think of "impossible" cases of a function. f x | check x = result x | otherwise = error "impossible" I know there are techniques to get rid of (or minimise the number of) the impossible cases. I also can see how this information can be relevant, i.e. seeing whether `check` always holds or not in the report. However, at least for one version of the report, I want the error call like the above example to be treated as covered. Or maybe a different colour could be used to annotate "ignored"? Did anyone need/want anything like this? Is it possible? My guess is that this is somewhat possible using manually generated .tix files and merging them with the .tix file that is generated in the usual way. However this feels too adhoc, fragile and seems to be too much effort to reach a simple goal. Best, Ozgur -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaddai.fouche at gmail.com Mon Feb 23 12:20:46 2015 From: chaddai.fouche at gmail.com (=?UTF-8?B?Q2hhZGRhw68gRm91Y2jDqQ==?=) Date: Mon, 23 Feb 2015 13:20:46 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> Message-ID: Note that Roelof is doing the CIS 194 Homework http://www.seas.upenn.edu/~cis194/fall14/hw/03-ADTs.pdf (the older version of fall2014, not the one currently running). This is much clearer than Roelof's description, and gives among other information an algebraic datatype to represent log messages. -- Jeda? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Mon Feb 23 14:13:06 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 23 Feb 2015 14:13:06 +0000 (UTC) Subject: [Haskell-cafe] hpc - ignore some expressions References: Message-ID: Ozgur Akgun gmail.com> writes: > > Hi, > I am generating code coverage reports using hpc, it works great. > Hi Ozgur, Is this what you want? https://wiki.haskell.org/Haskell_program_coverage#Example. Dominic From r.wobben at home.nl Mon Feb 23 14:50:52 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 15:50:52 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> Message-ID: <54EB3E4C.4030309@home.nl> An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Mon Feb 23 15:03:29 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Mon, 23 Feb 2015 17:03:29 +0200 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB3E4C.4030309@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> Message-ID: Roelof, You defined isValid function in the upper-scope first, and then you defined a symbol (variable) that re-wrote that name to something different (string "Geldige string"). That's why you get an error saying it doesn't expect arguments. My suggestion is to rename second isValid. Good luck. On Mon, Feb 23, 2015 at 4:50 PM, Roelof Wobben wrote: > Chadda? Fouch? schreef op 23-2-2015 om 13:20: > > Note that Roelof is doing the CIS 194 Homework > http://www.seas.upenn.edu/~cis194/fall14/hw/03-ADTs.pdf (the older > version of fall2014, not the one currently running). This is much clearer > than Roelof's description, and gives among other information an algebraic > datatype to represent log messages. > > > -- > Jeda? > > > Correct and Im trying to do exercise 1 of Week 2, > > I have tried this solution : > > -- | Main entry point to the application. > {-# OPTIONS_GHC -Wall #-} > > module LogAnalysis where > > import Log; > import Data.Char (isLetter, isDigit) > > isValid :: [Char] -> Bool > isValid s = go (words s) > where > go ([a]:b:_) = isLetter a && all isDigit b > go _ = False > > parseMessage :: [Char] -> [Char] > parseMessage s = isValid s > where > isValid = "Geldige string" > _ = "Ongeldige string" > > -- | The main entry point. > main :: IO () > main = do > putStrLn $ parseMessage "I 4764 He trusts to you to set them free," > > > but I see this error message : > > src/LogAnalysis.hs at 16:18-16:27 > Couldn't match expected type ?[Char] -> [Char]? with actual type > [Char] > The function > isValid > is applied to one argument, but its type > [Char] > has none ? In the expression: isValid s In an equation for > ?parseMessage?: parseMessage s = isValid s where isValid = "Geldige string" > _ = "Ongeldige string" > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 15:10:19 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 16:10:19 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> Message-ID: <54EB42DB.6020509@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 16:19:18 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 17:19:18 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB42DB.6020509@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> Message-ID: <54EB5306.2050501@home.nl> An HTML attachment was scrubbed... URL: From ozgurakgun at gmail.com Mon Feb 23 16:46:45 2015 From: ozgurakgun at gmail.com (Ozgur Akgun) Date: Mon, 23 Feb 2015 16:46:45 +0000 Subject: [Haskell-cafe] hpc - ignore some expressions In-Reply-To: References: Message-ID: On 23 February 2015 at 14:13, Dominic Steinitz wrote: > Ozgur Akgun gmail.com> writes: > > > > > Hi, > > I am generating code coverage reports using hpc, it works great. > > > > Hi Ozgur, > > Is this what you want? > https://wiki.haskell.org/Haskell_program_coverage#Example. > That is sort of what I was getting at towards the end of my email: > My guess is that this is somewhat possible using manually generated .tix files and merging them with the .tix file that is generated in the usual way. However this feels too adhoc, fragile and seems to be too much effort to reach a simple goal. Maybe I am not fully understanding how it works. Ozgur -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 17:19:19 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 18:19:19 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB5306.2050501@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> Message-ID: <54EB6117.9070003@home.nl> An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Mon Feb 23 17:28:22 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Mon, 23 Feb 2015 09:28:22 -0800 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB6117.9070003@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> Message-ID: The type of `putStrLn` is String -> IO (). `isValid` returns a Bool. You're probably looking for `print`. On Mon, Feb 23, 2015 at 9:19 AM, Roelof Wobben wrote: > And when Im trying this: > > {-# OPTIONS_GHC -Wall #-} > > module LogAnalysis where > > import Log; > import Data.Char (isLetter, isDigit) > > isValid :: String -> Bool > isValid s = go (words s) > where > go ([a]:b:_) = isLetter a && all isDigit b > go _ = False > > > -- | The main entry point. > main :: IO () > main = do > putStrLn $ isValid "I 4764 He trusts to you to set them free," > > > I see this error message : > > src/LogAnalysis.hs at 19:16-19:67 > Couldn't match type > Bool > with > [Char] > Expected type: String Actual type: Bool ? In the second argument of > ?($)?, namely ?isValid "I 4764 He trusts to you to set them free,"? In a > stmt of a 'do' block: putStrLn $ isValid "I 4764 He trusts to you to set > them free," > > Roelof > > > > > > Roelof Wobben schreef op 23-2-2015 om 17:19: > > I tried it another way more like explained on this page : > http://www.seas.upenn.edu/~cis194/spring13/lectures/02-ADTs.html > > so I tried this : > > parseMessage :: [Char] -> [Char] > parseMessage s > case Errornumber of > IsDigit Errornumber -> "Geldige string" > otherwise -> "Ongeldige string" > where > Error = s words > Errornumber = Error(ErrorNumber _ _ ) > Errorcode = Error(_ Errorcode _ ) > > but now I cannot use where :( > > Roelof > > > > > Roelof Wobben schreef op 23-2-2015 om 16:10: > > Oke, > > Then I make there a mistake, > > What I try to do is to send the file to parseMessage and let IsValid check > if it?s have the right format. > > Then after the where I try to check if the function isValid returns true > or false. > > Roelof > > > Konstantine Rybnikov schreef op 23-2-2015 om 16:03: > > Roelof, > > You defined isValid function in the upper-scope first, and then you > defined a symbol (variable) that re-wrote that name to something different > (string "Geldige string"). That's why you get an error saying it doesn't > expect arguments. > > My suggestion is to rename second isValid. > > Good luck. > > On Mon, Feb 23, 2015 at 4:50 PM, Roelof Wobben wrote: > >> Chadda? Fouch? schreef op 23-2-2015 om 13:20: >> >> Note that Roelof is doing the CIS 194 Homework >> http://www.seas.upenn.edu/~cis194/fall14/hw/03-ADTs.pdf (the older >> version of fall2014, not the one currently running). This is much clearer >> than Roelof's description, and gives among other information an algebraic >> datatype to represent log messages. >> >> >> -- >> Jeda? >> >> >> Correct and Im trying to do exercise 1 of Week 2, >> >> I have tried this solution : >> >> -- | Main entry point to the application. >> {-# OPTIONS_GHC -Wall #-} >> >> module LogAnalysis where >> >> import Log; >> import Data.Char (isLetter, isDigit) >> >> isValid :: [Char] -> Bool >> isValid s = go (words s) >> where >> go ([a]:b:_) = isLetter a && all isDigit b >> go _ = False >> >> parseMessage :: [Char] -> [Char] >> parseMessage s = isValid s >> where >> isValid = "Geldige string" >> _ = "Ongeldige string" >> >> -- | The main entry point. >> main :: IO () >> main = do >> putStrLn $ parseMessage "I 4764 He trusts to you to set them free," >> >> >> but I see this error message : >> >> src/LogAnalysis.hs at 16:18-16:27 >> Couldn't match expected type ?[Char] -> [Char]? with actual type >> [Char] >> The function >> isValid >> is applied to one argument, but its type >> [Char] >> has none ? In the expression: isValid s In an equation for >> ?parseMessage?: parseMessage s = isValid s where isValid = "Geldige string" >> _ = "Ongeldige string" >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Mon Feb 23 17:49:18 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Mon, 23 Feb 2015 19:49:18 +0200 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB6117.9070003@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> Message-ID: As Alex mentioned, isValid returns Bool, while type for putStrLn is `String -> IO ()`. So, in order to print something of type Bool, you need to first convert it to String. For example, via a function `show`: putStrLn (show True) As Alex mentioned, there's a `print` function, which does exactly this: print x = putStrLn (show x) You can use it. On Mon, Feb 23, 2015 at 7:19 PM, Roelof Wobben wrote: > And when Im trying this: > > {-# OPTIONS_GHC -Wall #-} > > module LogAnalysis where > > import Log; > import Data.Char (isLetter, isDigit) > > isValid :: String -> Bool > isValid s = go (words s) > where > go ([a]:b:_) = isLetter a && all isDigit b > go _ = False > > > -- | The main entry point. > main :: IO () > main = do > putStrLn $ isValid "I 4764 He trusts to you to set them free," > > > I see this error message : > > src/LogAnalysis.hs at 19:16-19:67 > Couldn't match type > Bool > with > [Char] > Expected type: String Actual type: Bool ? In the second argument of > ?($)?, namely ?isValid "I 4764 He trusts to you to set them free,"? In a > stmt of a 'do' block: putStrLn $ isValid "I 4764 He trusts to you to set > them free," > > Roelof > > > > > > Roelof Wobben schreef op 23-2-2015 om 17:19: > > I tried it another way more like explained on this page : > http://www.seas.upenn.edu/~cis194/spring13/lectures/02-ADTs.html > > so I tried this : > > parseMessage :: [Char] -> [Char] > parseMessage s > case Errornumber of > IsDigit Errornumber -> "Geldige string" > otherwise -> "Ongeldige string" > where > Error = s words > Errornumber = Error(ErrorNumber _ _ ) > Errorcode = Error(_ Errorcode _ ) > > but now I cannot use where :( > > Roelof > > > > > Roelof Wobben schreef op 23-2-2015 om 16:10: > > Oke, > > Then I make there a mistake, > > What I try to do is to send the file to parseMessage and let IsValid check > if it?s have the right format. > > Then after the where I try to check if the function isValid returns true > or false. > > Roelof > > > Konstantine Rybnikov schreef op 23-2-2015 om 16:03: > > Roelof, > > You defined isValid function in the upper-scope first, and then you > defined a symbol (variable) that re-wrote that name to something different > (string "Geldige string"). That's why you get an error saying it doesn't > expect arguments. > > My suggestion is to rename second isValid. > > Good luck. > > On Mon, Feb 23, 2015 at 4:50 PM, Roelof Wobben wrote: > >> Chadda? Fouch? schreef op 23-2-2015 om 13:20: >> >> Note that Roelof is doing the CIS 194 Homework >> http://www.seas.upenn.edu/~cis194/fall14/hw/03-ADTs.pdf (the older >> version of fall2014, not the one currently running). This is much clearer >> than Roelof's description, and gives among other information an algebraic >> datatype to represent log messages. >> >> >> -- >> Jeda? >> >> >> Correct and Im trying to do exercise 1 of Week 2, >> >> I have tried this solution : >> >> -- | Main entry point to the application. >> {-# OPTIONS_GHC -Wall #-} >> >> module LogAnalysis where >> >> import Log; >> import Data.Char (isLetter, isDigit) >> >> isValid :: [Char] -> Bool >> isValid s = go (words s) >> where >> go ([a]:b:_) = isLetter a && all isDigit b >> go _ = False >> >> parseMessage :: [Char] -> [Char] >> parseMessage s = isValid s >> where >> isValid = "Geldige string" >> _ = "Ongeldige string" >> >> -- | The main entry point. >> main :: IO () >> main = do >> putStrLn $ parseMessage "I 4764 He trusts to you to set them free," >> >> >> but I see this error message : >> >> src/LogAnalysis.hs at 16:18-16:27 >> Couldn't match expected type ?[Char] -> [Char]? with actual type >> [Char] >> The function >> isValid >> is applied to one argument, but its type >> [Char] >> has none ? In the expression: isValid s In an equation for >> ?parseMessage?: parseMessage s = isValid s where isValid = "Geldige string" >> _ = "Ongeldige string" >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 18:14:45 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 19:14:45 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> Message-ID: <54EB6E15.7010503@home.nl> An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Mon Feb 23 20:01:39 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Mon, 23 Feb 2015 12:01:39 -0800 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB6E15.7010503@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> <54EB6E15.7010503@home.nl> Message-ID: Constructors with names like 'Unknown' are a code smell, IMO. I'd just define the data type like this: data LogMessage = LogMessage MessageType TimeStamp String and use `Either String LogMessage` in contexts where parsing can fail: parseLogEntry :: String -> Either String LogMesage parseLogEntry str | isValid str = Right $ mkLogMessage str | otherwise = Left $ "Poorly-formatted log entry: " ++ str As for implementing mkLogMessage: you already know how to unpack the parts of a log message with `words` and pattern matching. After that it's just a matter of type-casting everything correctly and passing it to the `LogMessage` constructor. On Mon, Feb 23, 2015 at 10:14 AM, Roelof Wobben wrote: > Thanks, > > This works : > > -- | Main entry point to the application. > {-# OPTIONS_GHC -Wall #-} > > module LogAnalysis where > > import Data.Char (isLetter, isDigit) > > isValid :: String -> Bool > isValid s = go (words s) > where > go ([a]:b:_) = isLetter a && all isDigit b > go _ = False > > > -- | The main entry point. > main :: IO () > main = do > putStrLn $ ( show (isValid "I 656 He trusts to you to set them free,")) > > > Now I have to ty to find out how I can check if a has the contents of > I/W/E and how to make the right output (Error/Warning/Info 22) " Text" > ) > and then make it work with this datatype : > > data LogMessage = LogMessage MessageType TimeStamp String > | Unknown String > deriving (Show, Eq) > > Roelof > > Konstantine Rybnikov schreef op 23-2-2015 om 18:49: > > As Alex mentioned, isValid returns Bool, while type for putStrLn is > `String -> IO ()`. So, in order to print something of type Bool, you need > to first convert it to String. For example, via a function `show`: > > putStrLn (show True) > > As Alex mentioned, there's a `print` function, which does exactly this: > > print x = putStrLn (show x) > > You can use it. > > On Mon, Feb 23, 2015 at 7:19 PM, Roelof Wobben wrote: > >> And when Im trying this: >> >> {-# OPTIONS_GHC -Wall #-} >> >> module LogAnalysis where >> >> import Log; >> import Data.Char (isLetter, isDigit) >> >> isValid :: String -> Bool >> isValid s = go (words s) >> where >> go ([a]:b:_) = isLetter a && all isDigit b >> go _ = False >> >> >> -- | The main entry point. >> main :: IO () >> main = do >> putStrLn $ isValid "I 4764 He trusts to you to set them free," >> >> >> I see this error message : >> >> src/LogAnalysis.hs at 19:16-19:67 >> Couldn't match type >> Bool >> with >> [Char] >> Expected type: String Actual type: Bool ? In the second argument of >> ?($)?, namely ?isValid "I 4764 He trusts to you to set them free,"? In a >> stmt of a 'do' block: putStrLn $ isValid "I 4764 He trusts to you to set >> them free," >> >> Roelof >> >> >> >> >> >> Roelof Wobben schreef op 23-2-2015 om 17:19: >> >> I tried it another way more like explained on this page : >> http://www.seas.upenn.edu/~cis194/spring13/lectures/02-ADTs.html >> >> so I tried this : >> >> parseMessage :: [Char] -> [Char] >> parseMessage s >> case Errornumber of >> IsDigit Errornumber -> "Geldige string" >> otherwise -> "Ongeldige string" >> where >> Error = s words >> Errornumber = Error(ErrorNumber _ _ ) >> Errorcode = Error(_ Errorcode _ ) >> >> but now I cannot use where :( >> >> Roelof >> >> >> >> >> Roelof Wobben schreef op 23-2-2015 om 16:10: >> >> Oke, >> >> Then I make there a mistake, >> >> What I try to do is to send the file to parseMessage and let IsValid >> check if it?s have the right format. >> >> Then after the where I try to check if the function isValid returns true >> or false. >> >> Roelof >> >> >> Konstantine Rybnikov schreef op 23-2-2015 om 16:03: >> >> Roelof, >> >> You defined isValid function in the upper-scope first, and then you >> defined a symbol (variable) that re-wrote that name to something different >> (string "Geldige string"). That's why you get an error saying it doesn't >> expect arguments. >> >> My suggestion is to rename second isValid. >> >> Good luck. >> >> On Mon, Feb 23, 2015 at 4:50 PM, Roelof Wobben wrote: >> >>> Chadda? Fouch? schreef op 23-2-2015 om 13:20: >>> >>> Note that Roelof is doing the CIS 194 Homework >>> http://www.seas.upenn.edu/~cis194/fall14/hw/03-ADTs.pdf (the older >>> version of fall2014, not the one currently running). This is much clearer >>> than Roelof's description, and gives among other information an algebraic >>> datatype to represent log messages. >>> >>> >>> -- >>> Jeda? >>> >>> >>> Correct and Im trying to do exercise 1 of Week 2, >>> >>> I have tried this solution : >>> >>> -- | Main entry point to the application. >>> {-# OPTIONS_GHC -Wall #-} >>> >>> module LogAnalysis where >>> >>> import Log; >>> import Data.Char (isLetter, isDigit) >>> >>> isValid :: [Char] -> Bool >>> isValid s = go (words s) >>> where >>> go ([a]:b:_) = isLetter a && all isDigit b >>> go _ = False >>> >>> parseMessage :: [Char] -> [Char] >>> parseMessage s = isValid s >>> where >>> isValid = "Geldige string" >>> _ = "Ongeldige string" >>> >>> -- | The main entry point. >>> main :: IO () >>> main = do >>> putStrLn $ parseMessage "I 4764 He trusts to you to set them free," >>> >>> >>> but I see this error message : >>> >>> src/LogAnalysis.hs at 16:18-16:27 >>> Couldn't match expected type ?[Char] -> [Char]? with actual type >>> [Char] >>> The function >>> isValid >>> is applied to one argument, but its type >>> [Char] >>> has none ? In the expression: isValid s In an equation for >>> ?parseMessage?: parseMessage s = isValid s where isValid = "Geldige string" >>> _ = "Ongeldige string" >>> >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Mon Feb 23 20:02:06 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 23 Feb 2015 20:02:06 +0000 Subject: [Haskell-cafe] hpc - ignore some expressions In-Reply-To: References: Message-ID: <5362AA65-5F23-4EAE-8D87-1A08C9AFDF00@steinitz.org> > > > > > Hi, > > I am generating code coverage reports using hpc, it works great. > > > > Hi Ozgur, > > Is this what you want? https://wiki.haskell.org/Haskell_program_coverage#Example. > > That is sort of what I was getting at towards the end of my email: > > > My guess is that this is somewhat possible using manually generated .tix files and merging them with the .tix file that is generated in the usual way. However this feels too adhoc, fragile and seems to be too much effort to reach a simple goal. > > Maybe I am not fully understanding how it works. > > Ozgur I think you are right about it being fragile and becoming a big overhead in maintenance. Maybe one could add some sort of annotation to the sources for which you wish to check coverage and also modify HPC to handle these? -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 20:15:24 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 21:15:24 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> <54EB6E15.7010503@home.nl> Message-ID: <54EB8A5C.3040804@home.nl> An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Mon Feb 23 20:23:12 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Mon, 23 Feb 2015 12:23:12 -0800 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB8A5C.3040804@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> <54EB6E15.7010503@home.nl> <54EB8A5C.3040804@home.nl> Message-ID: You can pattern match on string literals: parseMessage :: String -> String parseMessage s = go (words s) where go ("I":_:_) = "Info" go _ = "false" You don't need to call it "go2", btw. Functions in where-blocks don't leak into the global scope, so there's no conflict with the `go` in your other function. On Mon, Feb 23, 2015 at 12:15 PM, Roelof Wobben wrote: > Sorry , > > I cannot change that function. I have to use it, > > But I think I found a solution for a step earlier, > > To parse a line and change it to another line which will be a member of > LogMessage : > > -- | Main entry point to the application. > {-# OPTIONS_GHC -Wall #-} > > module LogAnalysis where > > import Data.Char (isLetter, isDigit) > > isValid :: String -> Bool > isValid s = go (words s) > where > go ([a]:b:_) = isLetter a && all isDigit b > go _ = False > > parseMessage :: String -> String > parseMessage s = go2 (words s) > where > go2 (a:_:_) = case a of > "I" -> "Info " > _ -> "False" > > go2 _ = "false" > > > -- | The main entry point. > main :: IO () > main = do > putStrLn $ parseMessage "I 656 He trusts to you to set them free," > > > > But I feels wierd, to use first a pattern matching and later do a case of. > Is this a good way or are there better ways, > > Roelfo > > > > Alex Hammel schreef op 23-2-2015 om 21:01: > > Constructors with names like 'Unknown' are a code smell, IMO. I'd just > define the data type like this: > > data LogMessage = LogMessage MessageType TimeStamp String > > and use `Either String LogMessage` in contexts where parsing can fail: > > parseLogEntry :: String -> Either String LogMesage > parseLogEntry str > | isValid str = Right $ mkLogMessage str > | otherwise = Left $ "Poorly-formatted log entry: " ++ str > > As for implementing mkLogMessage: you already know how to unpack the parts > of a log message with `words` and pattern matching. After that it's just a > matter of type-casting everything correctly and passing it to the > `LogMessage` constructor. > > On Mon, Feb 23, 2015 at 10:14 AM, Roelof Wobben wrote: > >> Thanks, >> >> This works : >> >> -- | Main entry point to the application. >> {-# OPTIONS_GHC -Wall #-} >> >> module LogAnalysis where >> >> import Data.Char (isLetter, isDigit) >> >> isValid :: String -> Bool >> isValid s = go (words s) >> where >> go ([a]:b:_) = isLetter a && all isDigit b >> go _ = False >> >> >> -- | The main entry point. >> main :: IO () >> main = do >> putStrLn $ ( show (isValid "I 656 He trusts to you to set them >> free,")) >> >> >> Now I have to ty to find out how I can check if a has the contents of >> I/W/E and how to make the right output (Error/Warning/Info 22) " Text" >> ) >> and then make it work with this datatype : >> >> data LogMessage = LogMessage MessageType TimeStamp String >> | Unknown String >> deriving (Show, Eq) >> >> Roelof >> >> Konstantine Rybnikov schreef op 23-2-2015 om 18:49: >> >> As Alex mentioned, isValid returns Bool, while type for putStrLn is >> `String -> IO ()`. So, in order to print something of type Bool, you need >> to first convert it to String. For example, via a function `show`: >> >> putStrLn (show True) >> >> As Alex mentioned, there's a `print` function, which does exactly this: >> >> print x = putStrLn (show x) >> >> You can use it. >> >> On Mon, Feb 23, 2015 at 7:19 PM, Roelof Wobben wrote: >> >>> And when Im trying this: >>> >>> {-# OPTIONS_GHC -Wall #-} >>> >>> module LogAnalysis where >>> >>> import Log; >>> import Data.Char (isLetter, isDigit) >>> >>> isValid :: String -> Bool >>> isValid s = go (words s) >>> where >>> go ([a]:b:_) = isLetter a && all isDigit b >>> go _ = False >>> >>> >>> -- | The main entry point. >>> main :: IO () >>> main = do >>> putStrLn $ isValid "I 4764 He trusts to you to set them free," >>> >>> >>> I see this error message : >>> >>> src/LogAnalysis.hs at 19:16-19:67 >>> Couldn't match type >>> Bool >>> with >>> [Char] >>> Expected type: String Actual type: Bool ? In the second argument of >>> ?($)?, namely ?isValid "I 4764 He trusts to you to set them free,"? In a >>> stmt of a 'do' block: putStrLn $ isValid "I 4764 He trusts to you to set >>> them free," >>> >>> Roelof >>> >>> >>> >>> >>> >>> Roelof Wobben schreef op 23-2-2015 om 17:19: >>> >>> I tried it another way more like explained on this page : >>> http://www.seas.upenn.edu/~cis194/spring13/lectures/02-ADTs.html >>> >>> so I tried this : >>> >>> parseMessage :: [Char] -> [Char] >>> parseMessage s >>> case Errornumber of >>> IsDigit Errornumber -> "Geldige string" >>> otherwise -> "Ongeldige string" >>> where >>> Error = s words >>> Errornumber = Error(ErrorNumber _ _ ) >>> Errorcode = Error(_ Errorcode _ ) >>> >>> but now I cannot use where :( >>> >>> Roelof >>> >>> >>> >>> >>> Roelof Wobben schreef op 23-2-2015 om 16:10: >>> >>> Oke, >>> >>> Then I make there a mistake, >>> >>> What I try to do is to send the file to parseMessage and let IsValid >>> check if it?s have the right format. >>> >>> Then after the where I try to check if the function isValid returns true >>> or false. >>> >>> Roelof >>> >>> >>> Konstantine Rybnikov schreef op 23-2-2015 om 16:03: >>> >>> Roelof, >>> >>> You defined isValid function in the upper-scope first, and then you >>> defined a symbol (variable) that re-wrote that name to something different >>> (string "Geldige string"). That's why you get an error saying it doesn't >>> expect arguments. >>> >>> My suggestion is to rename second isValid. >>> >>> Good luck. >>> >>> On Mon, Feb 23, 2015 at 4:50 PM, Roelof Wobben wrote: >>> >>>> Chadda? Fouch? schreef op 23-2-2015 om 13:20: >>>> >>>> Note that Roelof is doing the CIS 194 Homework >>>> http://www.seas.upenn.edu/~cis194/fall14/hw/03-ADTs.pdf (the older >>>> version of fall2014, not the one currently running). This is much clearer >>>> than Roelof's description, and gives among other information an algebraic >>>> datatype to represent log messages. >>>> >>>> >>>> -- >>>> Jeda? >>>> >>>> >>>> Correct and Im trying to do exercise 1 of Week 2, >>>> >>>> I have tried this solution : >>>> >>>> -- | Main entry point to the application. >>>> {-# OPTIONS_GHC -Wall #-} >>>> >>>> module LogAnalysis where >>>> >>>> import Log; >>>> import Data.Char (isLetter, isDigit) >>>> >>>> isValid :: [Char] -> Bool >>>> isValid s = go (words s) >>>> where >>>> go ([a]:b:_) = isLetter a && all isDigit b >>>> go _ = False >>>> >>>> parseMessage :: [Char] -> [Char] >>>> parseMessage s = isValid s >>>> where >>>> isValid = "Geldige string" >>>> _ = "Ongeldige string" >>>> >>>> -- | The main entry point. >>>> main :: IO () >>>> main = do >>>> putStrLn $ parseMessage "I 4764 He trusts to you to set them free," >>>> >>>> >>>> but I see this error message : >>>> >>>> src/LogAnalysis.hs at 16:18-16:27 >>>> Couldn't match expected type ?[Char] -> [Char]? with actual type >>>> [Char] >>>> The function >>>> isValid >>>> is applied to one argument, but its type >>>> [Char] >>>> has none ? In the expression: isValid s In an equation for >>>> ?parseMessage?: parseMessage s = isValid s where isValid = "Geldige string" >>>> _ = "Ongeldige string" >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 20:30:44 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 21:30:44 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> <54EB6E15.7010503@home.nl> <54EB8A5C.3040804@home.nl> Message-ID: <54EB8DF4.1080205@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 20:39:06 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 21:39:06 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> <54EB6E15.7010503@home.nl> <54EB8A5C.3040804@home.nl> <54EB8DF4.1080205@home.nl> Message-ID: <54EB8FEA.3060403@home.nl> An HTML attachment was scrubbed... URL: From r.wobben at home.nl Mon Feb 23 21:04:58 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Mon, 23 Feb 2015 22:04:58 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <54EB6117.9070003@home.nl> <54EB6E15.7010503@home.nl> <54EB8A5C.3040804@home.nl> <54EB8DF4.1080205@home.nl> <54EB8FEA.3060403@home.nl> Message-ID: <54EB95FA.10607@home.nl> An HTML attachment was scrubbed... URL: From ozgurakgun at gmail.com Mon Feb 23 21:19:25 2015 From: ozgurakgun at gmail.com (Ozgur Akgun) Date: Mon, 23 Feb 2015 21:19:25 +0000 Subject: [Haskell-cafe] hpc - ignore some expressions In-Reply-To: <5362AA65-5F23-4EAE-8D87-1A08C9AFDF00@steinitz.org> References: <5362AA65-5F23-4EAE-8D87-1A08C9AFDF00@steinitz.org> Message-ID: On 23 February 2015 at 20:02, Dominic Steinitz wrote: > > I think you are right about it being fragile and becoming a big overhead > in maintenance. Maybe one could add some sort of annotation to the sources > for which you wish to check coverage and also modify HPC to handle these? > A simple interface where the user provides a list of function names to be ignored would be a good start. Something like: hpc markup prog.tix --destdir=report --ignore=fail,error,impossible,undefined It _could_ also be a good idea to have a way of ignoring literals. Flags like --ignore-num-literals and --ignore-string-literals could treat all such literals as covered or ignored. Maybe I should put this as a feature request to the hpc maintainers. I am wondering if they maintain an issue tracker or not. The wiki pages for hpc aren't very helpful... (Starting from: https://wiki.haskell.org/GHC/HPC) Ozgur -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Feb 23 22:20:10 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 23 Feb 2015 22:20:10 +0000 Subject: [Haskell-cafe] GHC 7.10 will use Plan FTP Message-ID: <618BE556AADD624C9C918AA5D5911BEF7BEB3523@DB3PRD3001MB020.064d.mgd.msft.net> Colleagues You will remember (see this email) that the Haskell community has been engaged in a debate about proposed changes to the Haskell Prelude, the Plan-List or Plan-FTP debate. We decided to hold an open survey to get feedback from the community. Simon Marlow and Simon PJ were asked to make a decision in the light of that feedback. The survey closed on 21 Feb, so it's time to decide. Bottom line: we recommend Plan FTP. There are strong arguments in both directions. For the record, our own personal instincts were both in the conservative, Plan List direction. But the survey gave some pretty compelling feedback, and was far more unequivocal than we expected. Some details * Over 800 people participated in the survey. That's a lot for an 11-day window. Many wrote several paragraphs of supporting information. Thank you for participating so actively! * Overall, 82% of respondents were in favour of FTP, a 4:1 majority. Simon and I found this level of unanimity quite surprising - and it made our task much easier. We clearly under-estimated the Haskell community's appetite for absorbing change when they approve of the direction of travel. * Herbert helped us by doing a rough categorisation into hobbyist/non-hobbyist responses. o The first interesting fact is that there were a lot of non-hobbyist responses: in fact a majority (58%) of the responses were from non-hobbyists. So increasingly people are using Haskell for real work. o The support for Plan FTP among hobbyists was overwhelming (over 87%). But it was still very strong indeed among non-hobbyists (over 79%). Caveat: time was short, so the hobby/non-hobby categorisation is extremely approximate. But since the results are so unambiguous, even the crude results are helpful. * We tried filtering out responses that were blank in the name field and both text boxes. The 82% majority did not budge. What happens now * GHC 7.10 will embody Plan FTP. * The Core Libraries committee, freshly energised and informed by this episode, is drafting new guidelines to clarify what it does, and how it works; and to help avoid a repetition of the recent drama. * The responses. In the survey we said "We won't publish either textual responses or personally-identifying information without your consent. The full responses will be made available only to a limited few." However, the English-language comments are a remarkable snapshot of the Haskell community, and it would be a shame to discard them without deeper study. We propose to make them available to the Core Libraries Committee, to inform their future choices. If anyone else wants to digest the comments into a summary report, we think that would be a service to the community, and (in our view, provided they are a reputable person etc) would fall under the "available to a limited few" rubric. If that appeals to you, write to us. If you object even to such limited sharing, write to us too. This wasn't an entirely easy process, especially because it happened so late in the release cycle. But although many people felt quite strongly about List vs FTP, the whole debate has involved light rather than heat; people have concentrated on the technical issues, rather than yelling. Overall, it's been very encouraging to see the resilience, transparency, and constructive tone of the community. We really appreciate that - thank you. Simon Marlow and Simon Peyton Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Mon Feb 23 22:55:06 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 23 Feb 2015 17:55:06 -0500 Subject: [Haskell-cafe] The Future of Community.Haskell.Org Message-ID: This message is intended to kick off a discussion on the state of the Community.Haskell.Org server and possible future plans. Included below is the text of a blog post on the infra blog ( https://blog.haskell.org/post/the_future_of_community_haskell_org/) We would especially like input and feedback from those who use or rely on any community.haskell.org services or accounts. We don't want to leave you in the lurch, and want to make sure that you feel your needs can be taken care of smoothly, even as we look to wind things down. Feedback is welcome via email (to admin at h.o) as a post on the blog, or via the reddit discussion ( http://www.reddit.com/r/haskell/comments/2wwc42/the_future_of_communityhaskellorg_request_for/ ) - - - Community.haskell.org is a server in our ecosystem that comparatively few know about these days. It actually was, to my knowledge, a key part of how the whole haskell.org community infrastructure got set up way back when. The sparse homepage still even says: "This server is run by a mysterious group of Haskell hackers who do not wish to be known as a Cabal, and is funded from money earned by haskell.org mentors in the Google Summer-of-Code programme." At a certain point after this server was created, it ceased to be run by a "mysterious group of Haskell hackers" and instead became managed officially by the haskell.org Committee that we know today. You can see the original announcement email in the archives . The community server, first set up in 2007 played a key role back before the current set of cloud-based services we know today was around. It provided a shared host which could provide many of the services a software project needs -- VCS hosting, public webspace for documentation, issue trackers, mailing lists, and soforth. Today, the server is somewhat of a relic of another time. People prefer to host projects in places like github, bitbucket, or darcs hub . Issue trackers likewise tend to be associated with these hosts, and there are other free, hosted issue trackers around as well. When folks want a mailing list, they tend to reach for google groups. Meanwhile, managing a big box full of shell account has become a much more difficult, riskier proposition. Every shell account is a security vulnerability waiting to happen, and there are more adversarial "scriptkiddie" hackers than ever looking to claim new boxes to spam and otherwise operate from. Managing a mailman installation is likewise more difficult. There are more spammers out there, with better methods, and unmaintained lists quickly can turn into ghost towns filled with pages of linkspam and nothing but. The same sad fate falls on unmaintained tracs. As a whole, the internet is a more adversarial world for small, self-hosted services, especially those whose domain names have some "google juice". We think it would be good to, to the extent possible, get out of the business of doing this sort of hosting. And indeed, very few individuals tend to request accounts, since there are now so many nicer, better ways of getting the benefits that community.haskell.org once was rare in providing. So what next? Well, we want to "end of life" most of community.haskell.org, but in as painless a way as possible. This means finding what few tracs, if any, are still active, and helping their owners migrate. Similarly for mailing lists. Of course we will find a way to continue to host their archives for historical purposes. Similarly, we will attempt to keep source repositories accessible for historical purposes, but would very much like to encourage owners to move to more well supported code hosting. One purpose that, until recently, was hard to serve elsewhere was in hosting of private darcs repositories with shared access -- such as academics might use to collaborate on a work in project. However, that capability is now also provided on http://hub.darcs.net. At this point, we can't think of anything in this regard that is not better provided elsewhere -- but if you can, please let us know. On webspace, it may be the case that a little more leniency is in order. For one, it is possible to provide restricted accounts that are able to control web-accessible files but have no other rights. For another, while many open source projects now host documentation through github pages or similar, and there are likewise many services for personal home pages, nonetheless it seems a nice thing to allow projects to host their resources on a system that is not under the control of a for-profit third party that, ultimately is responsible to its bottom line and not its users. But all this is open for discussion! Community.haskell.org was put together to serve the open source community of Haskell developers, and its direction needs to be determined based on feedback regarding current needs. What do you think? What would you like to see continued to be provided? What do you feel is less important? Are there other good hosted services that should be mentioned as alternatives? And, of course, are you interested in rolling up your sleeves to help with any of the changes discussed? This could mean simply helping out with sorting out the mailman and trac situation, inventorying the active elements and collaborating with their owners. Or, it could mean a more sustained technical involvement. Whatever you have to offer, we will likely have a use for it. As always, you can emailadmin at h.o or hop on the #haskell-infrastructure freenode channel to get involved directly. Cheers, Gershom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Tue Feb 24 01:01:26 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 24 Feb 2015 14:01:26 +1300 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB3E4C.4030309@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> Message-ID: <0D8EF14A-0F84-4577-BE7B-7ABBFBFB32BF@cs.otago.ac.nz> On 24/02/2015, at 3:50 am, Roelof Wobben wrote: > > isValid :: [Char] -> Bool > isValid s = go (words s) > where > go ([a]:b:_) = isLetter a && all isDigit b > go _ = False My attention was caught by the remarkably unhelpful name "go". What goes? Where does it go? What does going mean? This is a good time to use a 'case': isValid s = case words s of [a]:b:_ -> isLetter a && all isDigit b _ -> False >parseMessage :: [Char] -> [Char] > > parseMessage s = isValid s > where > isValid = "Geldige string" > _ = "Ongeldige string" In the first line of this function, you are calling isValid with an argument. But you are defining isValid to be a string! parseMessage s = if isValid s then "Geldige string" else "Ongeldige string" "parseMessage: is a bad name because the purpose of the function is *NOT* to break the message into parts and deliver those parts but to CHECK or VALIDATE or CLASSIFY the message. The code import Data.Char isValid s = case words s of [a]:b:_ -> isLetter a && all isDigit b _ -> False parseMessage s = if isValid s then "Geldige string" else "Ongeldige string" main = putStrLn $ parseMessage "I 4764 He trusts to you to set them free," compiles without warnings and produces the result I think you want. From ok at cs.otago.ac.nz Tue Feb 24 01:07:56 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 24 Feb 2015 14:07:56 +1300 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EB5306.2050501@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> Message-ID: <1783991C-8292-4932-9C50-DDC284967049@cs.otago.ac.nz> On 24/02/2015, at 5:19 am, Roelof Wobben wrote: > I tried it another way more like explained on this page : http://www.seas.upenn.edu/~cis194/spring13/lectures/02-ADTs.html > > so I tried this : > > parseMessage :: [Char] -> [Char] > parseMessage s > case Errornumber of > IsDigit Errornumber -> "Geldige string" > otherwise -> "Ongeldige string" > where > Error = s words > Errornumber = Error(ErrorNumber _ _ ) > Errorcode = Error(_ Errorcode _ ) > > but now I cannot use where :( That's not your problem. IsDigit ErrorNumber is not a pattern. parseMessage s = if isDigit errorNumber then "Geldige string" else "Ongelidige string" where errorNumber = ??? is OK. Now I cannot make sense of Error = s words identifiers beginning with capital letters are used for - module names - type constructors - data constructors You want a variable here, so it must begin with a lower case letter. s words treats a string s as a function and applies it to the function words as argument: s(words). But that does not type check. You mean words s. The result of words s, whatever else it may be, is not an error. Errornumber = Error(ErrorNumber _ _) In the form "expr where pattern = expr", the thing after the equal sign must be an expression. But Error(ErrorNumber _ _) is not an expression. "_" is a PATTERN (= I do not care what goes here) but never an EXPRESSION (because what value would it have?). From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 24 03:11:50 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 24 Feb 2015 08:41:50 +0530 Subject: [Haskell-cafe] Composition and type magic Message-ID: Hi everyone, I defined a function for discrete convolution, i.e conv xs = sum . zipWith (*) xs . reverse And I was wondering, can it be done without explicitly passing in the xs (eta-reduction)? I've seen people play with (.).(.) and foldl foldl foldl and was thinking that maybe something similar might be used here. -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 24 03:26:18 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 24 Feb 2015 08:56:18 +0530 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <1783991C-8292-4932-9C50-DDC284967049@cs.otago.ac.nz> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <1783991C-8292-4932-9C50-DDC284967049@cs.otago.ac.nz> Message-ID: >From the homework: data MessageType = Info | Warning | Error Int deriving (Show, Eq) data LogMessage = LogMessage MessageType TimeStamp String deriving (Eq, Show) data MaybeLogMessage = ValidM LogMessage -- A valid msg | InvalidLM String -- Invalid msg parseMessage :: String -> MaybeLogMessage parseMessage = undefined To implement parseMessage, we consume the string from left to right word-by-word. If the first word is E, then we read the second word as in integer indicating severity and proceed further. Info and Warning don't require more information, so the next word will be the timestamp in those cases. If the pattern fails anywhere, we return the whole string as an InvalidLM. Hope this helps. On 24 February 2015 at 06:37, Richard A. O'Keefe wrote: > > On 24/02/2015, at 5:19 am, Roelof Wobben wrote: > > > I tried it another way more like explained on this page : > http://www.seas.upenn.edu/~cis194/spring13/lectures/02-ADTs.html > > > > so I tried this : > > > > parseMessage :: [Char] -> [Char] > > parseMessage s > > case Errornumber of > > IsDigit Errornumber -> "Geldige string" > > otherwise -> "Ongeldige string" > > where > > Error = s words > > Errornumber = Error(ErrorNumber _ _ ) > > Errorcode = Error(_ Errorcode _ ) > > > > but now I cannot use where :( > > That's not your problem. > > IsDigit ErrorNumber is not a pattern. > > parseMessage s = > if isDigit errorNumber then "Geldige string" > else "Ongelidige string" > where > errorNumber = ??? > > is OK. > > Now I cannot make sense of > Error = s words > > identifiers beginning with capital letters are used for > - module names > - type constructors > - data constructors > You want a variable here, so it must begin with a > lower case letter. > > s words treats a string s as a function and applies it > to the function words as argument: s(words). But that > does not type check. You mean words s. > > The result of words s, whatever else it may be, is not > an error. > > Errornumber = Error(ErrorNumber _ _) > > In the form "expr where pattern = expr", the thing after > the equal sign must be an expression. But > Error(ErrorNumber _ _) is not an expression. "_" is a > PATTERN (= I do not care what goes here) but never an > EXPRESSION (because what value would it have?). > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Tue Feb 24 03:27:33 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Mon, 23 Feb 2015 22:27:33 -0500 Subject: [Haskell-cafe] Composition and type magic In-Reply-To: References: Message-ID: <54EBEFA5.3070006@orlitzky.com> On 02/23/2015 10:11 PM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > Hi everyone, > > I defined a function for discrete convolution, i.e > > conv xs = sum . zipWith (*) xs . reverse > > And I was wondering, can it be done without explicitly passing in the xs > (eta-reduction)? Ehhhhhhhhhh this will work: conv = (sum .) . (. reverse) . zipWith (*) But it's so much easier to understand without all the boobies operators: conv xs ys = sum $ zipWith (*) xs (reverse ys) From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 24 05:57:40 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 24 Feb 2015 11:27:40 +0530 Subject: [Haskell-cafe] Composition and type magic In-Reply-To: <54EBEFA5.3070006@orlitzky.com> References: <54EBEFA5.3070006@orlitzky.com> Message-ID: Thanks. You've given me a good exercise in equational reasoning. I'm studying such things because I might start studying combinatory logic (Smullyan's mockingbird book) soon. It's a good exercise for the mind, and is very enjoyable with pencil & paper. Can you give me some more patterns like transducers (foldl foldl) and the dot-dot-dot ( boobies, in your words :) ) example? Thanks once again. On 24 February 2015 at 08:57, Michael Orlitzky wrote: > On 02/23/2015 10:11 PM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > > Hi everyone, > > > > I defined a function for discrete convolution, i.e > > > > conv xs = sum . zipWith (*) xs . reverse > > > > And I was wondering, can it be done without explicitly passing in the xs > > (eta-reduction)? > > Ehhhhhhhhhh this will work: > > conv = (sum .) . (. reverse) . zipWith (*) > > But it's so much easier to understand without all the boobies operators: > > conv xs ys = sum $ zipWith (*) xs (reverse ys) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Tue Feb 24 07:52:24 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 24 Feb 2015 08:52:24 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <0D8EF14A-0F84-4577-BE7B-7ABBFBFB32BF@cs.otago.ac.nz> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <0D8EF14A-0F84-4577-BE7B-7ABBFBFB32BF@cs.otago.ac.nz> Message-ID: <54EC2DB8.7050208@home.nl> Thanks, I rewrote it like this : parseMessage :: String -> LogMessage parseMessage s = case words s of ("I":time:text) -> LogMessage Info (read time) (unwords text) ("W":time:text) -> LogMessage Warning (read time) (unwords text) ("E":errorcode:time:text) -> LogMessage Error (read errorcode) (read time) (unwords text) _ -> Unknown "This is not in the right format" The only thing Im facing now It the Error part. Messagetype has this signature : data MessageType = Info | Warning | Error Int deriving (Show, Eq) So Error has a Messagatype which contains 2 things. but because of the use of words I looks like this I think [ "E", 46, 23456 , "This", "is", "a", "error". ] Can I somehow use unwords here to to make the Messagetype work. Roelof Richard A. O'Keefe schreef op 24-2-2015 om 2:01: > On 24/02/2015, at 3:50 am, Roelof Wobben wrote: >> isValid :: [Char] -> Bool >> isValid s = go (words s) >> where >> go ([a]:b:_) = isLetter a && all isDigit b >> go _ = False > My attention was caught by the remarkably unhelpful name "go". > What goes? Where does it go? What does going mean? > > This is a good time to use a 'case': > > isValid s = > case words s of > [a]:b:_ -> isLetter a && all isDigit b > _ -> False > >> parseMessage :: [Char] -> [Char] >> >> parseMessage s = isValid s >> where >> isValid = "Geldige string" >> _ = "Ongeldige string" > In the first line of this function, you are calling > isValid with an argument. But you are defining > isValid to be a string! > > parseMessage s = > if isValid s then "Geldige string" else "Ongeldige string" > > "parseMessage: is a bad name because the purpose of the > function is *NOT* to break the message into parts and > deliver those parts but to CHECK or VALIDATE or CLASSIFY > the message. > > The code > > import Data.Char > > isValid s = > case words s of > [a]:b:_ -> isLetter a && all isDigit b > _ -> False > > parseMessage s = > if isValid s then "Geldige string" else "Ongeldige string" > > main = > putStrLn $ parseMessage "I 4764 He trusts to you to set them free," > > compiles without warnings and produces the result I think you want. > > > From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 24 08:14:25 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 24 Feb 2015 13:44:25 +0530 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: <54EC2DB8.7050208@home.nl> References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <0D8EF14A-0F84-4577-BE7B-7ABBFBFB32BF@cs.otago.ac.nz> <54EC2DB8.7050208@home.nl> Message-ID: On 24 February 2015 at 13:22, Roelof Wobben wrote: > Thanks, > > I rewrote it like this : > > parseMessage :: String -> LogMessage > parseMessage s = > case words s of > ("I":time:text) -> LogMessage Info (read time) (unwords > text) > ("W":time:text) -> LogMessage Warning (read time) > (unwords text) > ("E":errorcode:time:text) -> LogMessage Error (read errorcode) > (read time) (unwords text) > _ -> Unknown "This is not in the right > format" > The code looks just fine. Great work. The trouble is with the third case. The error message is fairly instructive. log.hs:19:36: Couldn't match expected type ?String -> LogMessage? with actual type ?LogMessage? The function ?LogMessage? is applied to four arguments, but its type ?MessageType -> TimeStamp -> String -> LogMessage? has only three In the expression: LogMessage Error (read errorcode) (read time) (unwords text) In a case alternative: ("E" : errorcode : time : text) -> LogMessage Error (read errorcode) (read time) (unwords text) log.hs:19:47: Couldn't match expected type ?MessageType? with actual type ?Int -> MessageType? Probable cause: ?Error? is applied to too few arguments In the first argument of ?LogMessage?, namely ?Error? In the expression: LogMessage Error (read errorcode) (read time) (unwords text) Long story short, you meant to write LogMessage (Error (read errorcode)) ... instead of LogMessage Error (read errorcode) ... -- Too many arguments to LogMessage (error message 1) -- Too few arguments to Error (error message 2) which is a very common error. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stereoid at zankapfel.org Tue Feb 24 08:15:13 2015 From: stereoid at zankapfel.org (Stere0id) Date: Tue, 24 Feb 2015 09:15:13 +0100 Subject: [Haskell-cafe] Composition and type magic In-Reply-To: References: <54EBEFA5.3070006@orlitzky.com> Message-ID: <54EC3311.3090204@zankapfel.org> On 24.02.2015 06:57, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > Thanks. > You've given me a good exercise in equational reasoning. > > I'm studying such things because I might start studying combinatory logic > (Smullyan's mockingbird book) soon. > It's a good exercise for the mind, and is very enjoyable with pencil & > paper. > Can you give me some more patterns like transducers (foldl foldl) and the > dot-dot-dot ( boobies, in your words :) ) example? > > Thanks once again. > > On 24 February 2015 at 08:57, Michael Orlitzky wrote: > >> On 02/23/2015 10:11 PM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: >>> Hi everyone, >>> >>> I defined a function for discrete convolution, i.e >>> >>> conv xs = sum . zipWith (*) xs . reverse >>> >>> And I was wondering, can it be done without explicitly passing in the xs >>> (eta-reduction)? >> >> Ehhhhhhhhhh this will work: >> >> conv = (sum .) . (. reverse) . zipWith (*) >> >> But it's so much easier to understand without all the boobies operators: >> >> conv xs ys = sum $ zipWith (*) xs (reverse ys) >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > You might be interested in the pointfree [1] tool, which can convert lambda expressions to pointfree versions automatically. Allthough I also find the more complex ones, as in this case, rather obscure. I like you initial version best: conv xs = sum . zipWith (*) xs . reverse [1] http://hackage.haskell.org/package/pointfree From r.wobben at home.nl Tue Feb 24 08:17:27 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Tue, 24 Feb 2015 09:17:27 +0100 Subject: [Haskell-cafe] how can I do this the best In-Reply-To: References: <54E83BE6.9080900@home.nl> <54EA02B3.4060700@home.nl> <54EB3E4C.4030309@home.nl> <54EB42DB.6020509@home.nl> <54EB5306.2050501@home.nl> <1783991C-8292-4932-9C50-DDC284967049@cs.otago.ac.nz> Message-ID: <54EC3397.80806@home.nl> An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Tue Feb 24 09:07:02 2015 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 24 Feb 2015 09:07:02 +0000 Subject: [Haskell-cafe] 7 PhD studentships in Nottingham Message-ID: Dear all, The School of Computer Science in Nottingham is advertising 7 fully-funded PhD studentships for "home" students (or EU students who have been ordinarily resident in the UK for 3 years prior to the start of the programme). Applicants in the area of the Functional Programming lab (fp.cs.nott.ac.uk) are encouraged! If you are interested in applying, please contact a potential supervisor in the FP lab prior to submitting your application: Venanzio Capretta - type theory, mathematical logic, corecursive structures, proof assistants, dependently-typed programming. Henrik Nilsson - functional reactive programming, modelling and simulation, domain-specific languages, probabilistic languages. Thorsten Altenkirch and Graham Hutton - not planning to take on any further new PhD students this year. Best wishes, Graham +-----------------------------------------------------------+ 7 Fully-Funded PhD Studentships School of Computer Science University of Nottingham, UK http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI1433 Applications are invited for up to 7 fully-funded PhD studentships for "home" students (or EU students who have been ordinarily resident in the UK for 3 years prior to the start of the programme) in the School of Computer Science at the University of Nottingham, starting on 1st October 2015. The topics for the studentships are open, but should relate to the interests of one of the School's research groups: Agents Lab; Automated Scheduling, Optimisation and Planning; Computer Vision Lab; Functional Programming Lab; Intelligent Modelling and Analysis; Mixed Reality Lab; Networked Systems. The studentships are for three years, include a stipend of ??13,863 per year and tuition fees, and are available to students who qualify as "home" applicants in terms of their fee status. Applicants are normally expected to have a first-class Masters or Bachelors degree in Computer Science or a related discipline, and must obtain the support of a potential supervisor in the School prior to submitting their application. Initial contact with supervisors should be made at least two weeks prior to the closing date for applications. Applications should be submitted via the postgraduate applications website: http://www.nottingham.ac.uk/pgstudy/apply/apply-online.aspx. As part of your personal statement, please include an outline research proposal (max 1 page). Informal enquiries may be addressed to Christine.Fletcher at nottingham.ac.uk. Closing date for applications: Tuesday 31st March 2015 +-----------------------------------------------------------+ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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 michael at orlitzky.com Tue Feb 24 13:28:03 2015 From: michael at orlitzky.com (Michael Orlitzky) Date: Tue, 24 Feb 2015 08:28:03 -0500 Subject: [Haskell-cafe] Composition and type magic In-Reply-To: References: <54EBEFA5.3070006@orlitzky.com> Message-ID: <54EC7C63.8030406@orlitzky.com> On 02/24/2015 12:57 AM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > Thanks. > You've given me a good exercise in equational reasoning. > > I'm studying such things because I might start studying combinatory logic > (Smullyan's mockingbird book) soon. > It's a good exercise for the mind, and is very enjoyable with pencil & > paper. > Can you give me some more patterns like transducers (foldl foldl) and the > dot-dot-dot ( boobies, in your words :) ) example? > I cheated with the pointfree tool, but you can do it by hand, too. The only trick you need to know in this case is how to get the extra argument on the end. You start with, conv xs = sum . zipWith (*) xs . reverse and obviously, you want the 'xs' on the end. So you want to switch the 'zipWith (*) xs' and 'reverse' somehow. Well, you can always flip the composition operator! Unfortunately it's no longer infix at that point, so it has to be written like, conv xs = sum . (flip (.)) reverse (zipWith (*) xs) Now the secret is that putting an extra dot around the chain of functions takes it from a one-argument chain to a two-argument chain (where the first function in the chain eats the second argument). You can sort of see this in the type of 'sum' and '(sum .)': ghci> :t sum sum :: Num a => [a] -> a ghci> :t (sum .) (sum .) :: Num c => (a -> [c]) -> a -> c The second one essentially eats an argument by taking "something that will give me a list" instead of a list itself. You have to do the same thing with the '(flip (.)) reverse' part of the chain: conv = (sum .) . (((flip (.)) reverse) .) zipWith (*) Now, since you've got '((flip (.)) reverse' in parentheses anyway, you can change it from a normal function application to a "section," i.e. these two are the same: (flip (.)) reverse == (. reverse). So you wind up with, conv = (sum .) . (((. reverse) .) zipWith (*) Drop the useless parentheses, conv = (sum .) . (. reverse) . zipWith (*) and now all that's left to do is pray that you aren't hanged for witchcraft. From matthewtpickering at gmail.com Tue Feb 24 13:44:30 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 24 Feb 2015 13:44:30 +0000 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: I've been playing around with various implementations like this. Interestingly, this more general version allows nested "idiom brackets" whilst a more specific implementation (such as the one on the haskell wiki) doesn't. Any ideas why? The two implementations I have been testing this with are https://gist.github.com/mpickering/e19f6a5590a74fc36752 On Fri, Feb 20, 2015 at 7:12 PM, adam vogt wrote: > On Thu, Feb 19, 2015 at 10:42 AM, Christopher Done > wrote: > > Right, I see three use-cases: > > > > * Some things are foldable cleanly like monoids, so you can just > > mconcat [x,y,z] and that'll be inlined (I think). > > * Other things like x <|> y is not the same as asum [x,y] due to the > > additional mempty being introduced. You can also use foldl1 kind of > > functions, but they are partial and therefore not desirable. > > * Finally, things like <*>, $=, $, ., #/:& (e.g. in HList/vinyl) can't > > be folded at all, because the types are different. > > > > The third use-case doesn't have a solution that I'm aware of. So this > > solves that. It also solves the second use-case, which has only a > > partial (he he) solution. The first use-case is just a bonus. Should I > > add this clarification to the proposal? > > I think this is a half-solution to the third option: > > https://gist.github.com/aavogt/433969cc83548e1f59ea > > Rather than adding more syntax, maybe it's better to make polymorphic > functions/values easier to create. Writing instances of ApplyAB is a > pain, but ghc could help, as it does with this quasiquoter > http://lpaste.net/114788. > > Regards, > Adam > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Tue Feb 24 17:28:46 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Tue, 24 Feb 2015 22:58:46 +0530 Subject: [Haskell-cafe] Composition and type magic In-Reply-To: <54EC7C63.8030406@orlitzky.com> References: <54EBEFA5.3070006@orlitzky.com> <54EC7C63.8030406@orlitzky.com> Message-ID: I didn't think of forcing xs to the end. I thought that I might be able to convert the dot to something with type (a -> b -> c) -> (b -> b) -> a -> b -> c I tried flipping ((.).(.)) but got (a -> b -> c) -> (c -> d) -> a -> b -> d which is not what I wanted. Thanks for the mini-tutorial. [?] On 24 February 2015 at 18:58, Michael Orlitzky wrote: > On 02/24/2015 12:57 AM, Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote: > > Thanks. > > You've given me a good exercise in equational reasoning. > > > > I'm studying such things because I might start studying combinatory logic > > (Smullyan's mockingbird book) soon. > > It's a good exercise for the mind, and is very enjoyable with pencil & > > paper. > > Can you give me some more patterns like transducers (foldl foldl) and the > > dot-dot-dot ( boobies, in your words :) ) example? > > > > I cheated with the pointfree tool, but you can do it by hand, too. The > only trick you need to know in this case is how to get the extra > argument on the end. You start with, > > conv xs = sum . zipWith (*) xs . reverse > > and obviously, you want the 'xs' on the end. So you want to switch the > 'zipWith (*) xs' and 'reverse' somehow. Well, you can always flip the > composition operator! Unfortunately it's no longer infix at that point, > so it has to be written like, > > conv xs = sum . (flip (.)) reverse (zipWith (*) xs) > > Now the secret is that putting an extra dot around the chain of > functions takes it from a one-argument chain to a two-argument chain > (where the first function in the chain eats the second argument). You > can sort of see this in the type of 'sum' and '(sum .)': > > ghci> :t sum > sum :: Num a => [a] -> a > > ghci> :t (sum .) > (sum .) :: Num c => (a -> [c]) -> a -> c > > The second one essentially eats an argument by taking "something that > will give me a list" instead of a list itself. You have to do the same > thing with the '(flip (.)) reverse' part of the chain: > > conv = (sum .) . (((flip (.)) reverse) .) zipWith (*) > > Now, since you've got '((flip (.)) reverse' in parentheses anyway, you > can change it from a normal function application to a "section," i.e. > these two are the same: (flip (.)) reverse == (. reverse). So you wind > up with, > > conv = (sum .) . (((. reverse) .) zipWith (*) > > Drop the useless parentheses, > > conv = (sum .) . (. reverse) . zipWith (*) > > and now all that's left to do is pray that you aren't hanged for > witchcraft. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: B97.gif Type: image/gif Size: 181 bytes Desc: not available URL: From vogt.adam at gmail.com Tue Feb 24 19:36:30 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 24 Feb 2015 14:36:30 -0500 Subject: [Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions In-Reply-To: References: Message-ID: Hi Matthew, Looks like you can nest your version, if you add type annotations specifying the result type of each bracket. > runIdentity $ iI (+) f (iI (+) (Identity 1) (Identity 1) Ii :: Identity Int) Ii :: Int Changing "i x" to ix in the instance head lets ghc pick the instance when an Ii shows up, and then decide the result of the bracket is "i x": instance (Applicative i, ix ~ i x) => Idiomatic (Ii -> ix) where type I (Ii -> ix) = GetI ix type F (Ii -> ix) = GetX ix idiomatic xi Ii = xi type family GetI xi :: * -> * type family GetX xi :: * type instance GetI (i x) = i type instance GetX (i x) = x It seems cleaner to avoid type families for this problem: https://gist.github.com/aavogt/433969cc83548e1f59ea#file-ii-hs Regards, Adam On Tue, Feb 24, 2015 at 8:44 AM, Matthew Pickering wrote: > I've been playing around with various implementations like this. > Interestingly, this more general version allows nested "idiom brackets" > whilst a more specific implementation (such as the one on the haskell wiki) > doesn't. Any ideas why? > > The two implementations I have been testing this with are > https://gist.github.com/mpickering/e19f6a5590a74fc36752 > > On Fri, Feb 20, 2015 at 7:12 PM, adam vogt wrote: >> >> On Thu, Feb 19, 2015 at 10:42 AM, Christopher Done >> wrote: >> > Right, I see three use-cases: >> > >> > * Some things are foldable cleanly like monoids, so you can just >> > mconcat [x,y,z] and that'll be inlined (I think). >> > * Other things like x <|> y is not the same as asum [x,y] due to the >> > additional mempty being introduced. You can also use foldl1 kind of >> > functions, but they are partial and therefore not desirable. >> > * Finally, things like <*>, $=, $, ., #/:& (e.g. in HList/vinyl) can't >> > be folded at all, because the types are different. >> > >> > The third use-case doesn't have a solution that I'm aware of. So this >> > solves that. It also solves the second use-case, which has only a >> > partial (he he) solution. The first use-case is just a bonus. Should I >> > add this clarification to the proposal? >> >> I think this is a half-solution to the third option: >> >> https://gist.github.com/aavogt/433969cc83548e1f59ea >> >> Rather than adding more syntax, maybe it's better to make polymorphic >> functions/values easier to create. Writing instances of ApplyAB is a >> pain, but ghc could help, as it does with this quasiquoter >> http://lpaste.net/114788. >> >> Regards, >> Adam >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > From bob at redivi.com Tue Feb 24 20:24:51 2015 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 Feb 2015 12:24:51 -0800 Subject: [Haskell-cafe] Should foldl' be added to the post-"Plan FTP" Prelude? Message-ID: I would love to have foldl' as part of the Prelude. I use it quite frequently and it seems like a beginner trap to have foldl but not foldl' (which is almost always the better choice). I see that foldMap has been added (in addition to all of Monoid and Traversable), why was foldl' left out? It might be good measure to add foldr' as well, although I use that much less frequently. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue Feb 24 20:38:14 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 24 Feb 2015 22:38:14 +0200 Subject: [Haskell-cafe] Should foldl' be added to the post-"Plan FTP" Prelude? In-Reply-To: References: Message-ID: <54ECE136.7060605@ro-che.info> I'd agree that foldl' should be in Prelude. foldr', on the other hand, is another trap. It only makes sense for left-associated data structures like snoc lists, but some may think that foldr' is an "improved" version of foldr and use it for lists as well, which would be a mistake. On 24/02/15 22:24, Bob Ippolito wrote: > I would love to have foldl' as part of the Prelude. I use it quite > frequently and it seems like a beginner trap to have foldl but not > foldl' (which is almost always the better choice). I see that foldMap > has been added (in addition to all of Monoid and Traversable), why was > foldl' left out? > > It might be good measure to add foldr' as well, although I use that much > less frequently. > > -bob > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From carter.schonwald at gmail.com Tue Feb 24 20:38:45 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 24 Feb 2015 15:38:45 -0500 Subject: [Haskell-cafe] Should foldl' be added to the post-"Plan FTP" Prelude? In-Reply-To: References: Message-ID: I think that should be raised on the libraries list, but subject to that, a strong +1 from me once you do :) On Tue, Feb 24, 2015 at 3:24 PM, Bob Ippolito wrote: > I would love to have foldl' as part of the Prelude. I use it quite > frequently and it seems like a beginner trap to have foldl but not foldl' > (which is almost always the better choice). I see that foldMap has been > added (in addition to all of Monoid and Traversable), why was foldl' left > out? > > It might be good measure to add foldr' as well, although I use that much > less frequently. > > -bob > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Wed Feb 25 01:46:36 2015 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Wed, 25 Feb 2015 02:46:36 +0100 Subject: [Haskell-cafe] Trouble with forkProcess In-Reply-To: <551292E7-498B-483F-8CDF-618F1FFC74F8@mars.org> References: <551292E7-498B-483F-8CDF-618F1FFC74F8@mars.org> Message-ID: <54ED297C.1060809@nh2.me> On 21/02/15 01:58, Rob Leslie wrote: > My experience with forkProcess so far is that sometimes it works brilliantly, and other times it just deadlocks. Here's a bug about forkProcess deadlocking with GHC < 7.8.4: https://ghc.haskell.org/trac/ghc/ticket/9295 And here some other problems I found: https://ghc.haskell.org/trac/ghc/ticket/9470 From haskell at jschneider.net Wed Feb 25 12:11:50 2015 From: haskell at jschneider.net (Jon Schneider) Date: Wed, 25 Feb 2015 12:11:50 -0000 Subject: [Haskell-cafe] PowerPC variants (GHC 7.8.3) Message-ID: <95d7f378e2a3c0bb237f2f14f4f86b95.squirrel@mail.jschneider.net> Good morning, We have a product with an MPC8544E we might want to target. Also known as PowerQUICC and e500v2. The ABI is gnuspe rather than gnueabi. I have built a powerpc---ghc cross compiler but the thing stopping "hello world" is a SIGILL happening in StgCRun.c where the stfd and lfd instructions are used to stash registers. The e500 has different instructions but that cannot be dropped in trivially because of offset encoding Commenting these out fixes "hello world" though this surely only scratches the surface of what would need doing. I notice that whereas ARMv5, v6 and v7 appear to be catered for along with various knobs and whistles there appears to be no such thing for PowerPC. Is anybody else out there working on this area ? Jon From k-bx at k-bx.com Wed Feb 25 13:12:07 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Wed, 25 Feb 2015 15:12:07 +0200 Subject: [Haskell-cafe] Typed label Message-ID: Hi! I have a problem that seems very basic and fundamental, but at the same time I keep somehow skipping "the right way" to solve it. So I decided to give a try and describe it here. The task itself is very common. You have some data, which has some property inside of it. Often, you want to write a function that works only on an object with specific property being equal to something, but you can't move it out to type-parameter, because then you get all sorts of problems like you can't use regular lists/vectors anymore and other similar things. Let's take a look at real-world example to get a better understanding of a problem: Given a `Vegetable` type with a type that describes it's "type" (saying which concretely veg is it), you need to write a function `embraceOnion`, which would only work on onions (because it doesn't make sense to embrace any other veg). https://gist.github.com/k-bx/32b3f6a770ad81330f51 ``` {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module Main where main :: IO () main = putStrLn "Hi!" data Vegetable = Vegetable { vegName :: String , vetType :: VegType } deriving (Show, Eq) data VegType = Potato | Tomato | Cucumber | Onion deriving (Show, Eq) newtype TypedVegetable (t::VegType) = TypedVegetable Vegetable unType :: TypedVegetable (t::VegType) -> Vegetable unType (TypedVegetable v) = v -- | bad embraceOnion :: Vegetable -> IO () embraceOnion veg = putStrLn ("Yay for onion! It's name is: " ++ vegName veg) -- | good, but little ugly because of boilerplate embraceOnion2 :: TypedVegetable Onion -> IO () embraceOnion2 onion = putStrLn ("Yay for onion! It's name is: " ++ vegName (unType onion)) -- | doesn't work, need to specify kind of `t` newtype TypedLabel1 t a = TypedLabel1 a unTyped1 :: TypedLabel1 t a -> a unTyped1 (TypedLabel1 a) = a embraceOnion3 :: TypedLabel1 Onion Vegetable -> IO () embraceOnion3 = undefined ``` Currently, I'm sticking to solution `embraceOnion2` in my code. `embraceOnion3` doesn't work because of: ``` /Users/kb/workspace/typelabels/typelabels.hs The first argument of ?Main.TypedLabel1? should have kind ?*?, but ?Main.Onion? has kind ?Main.VegType? In the type signature for ?Main.embraceOnion3?: Main.embraceOnion3 :: Main.TypedLabel1 Main.Onion Main.Vegetable -> GHC.Types.IO () ``` What are the other options and "state of the art"? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nickolay.kudasov at gmail.com Wed Feb 25 13:19:47 2015 From: nickolay.kudasov at gmail.com (Nickolay Kudasov) Date: Wed, 25 Feb 2015 17:19:47 +0400 Subject: [Haskell-cafe] Typed label In-Reply-To: References: Message-ID: Hi! You can use -XPolyKinds two have GHC figure out the kinds for you. Your code compiles with that extra option. Is that what you were looking for? Nick 2015-02-25 16:12 GMT+03:00 Konstantine Rybnikov : > Hi! > > I have a problem that seems very basic and fundamental, but at the same > time I keep somehow skipping "the right way" to solve it. So I decided to > give a try and describe it here. > > The task itself is very common. You have some data, which has some > property inside of it. Often, you want to write a function that works only > on an object with specific property being equal to something, but you can't > move it out to type-parameter, because then you get all sorts of problems > like you can't use regular lists/vectors anymore and other similar things. > > Let's take a look at real-world example to get a better understanding of a > problem: > > Given a `Vegetable` type with a type that describes it's "type" (saying > which concretely veg is it), you need to write a function `embraceOnion`, > which would only work on onions (because it doesn't make sense to embrace > any other veg). > > https://gist.github.com/k-bx/32b3f6a770ad81330f51 > > ``` > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > > module Main where > > main :: IO () > main = putStrLn "Hi!" > > data Vegetable = Vegetable { vegName :: String > , vetType :: VegType } > deriving (Show, Eq) > data VegType = Potato > | Tomato > | Cucumber > | Onion > deriving (Show, Eq) > newtype TypedVegetable (t::VegType) = TypedVegetable Vegetable > > unType :: TypedVegetable (t::VegType) -> Vegetable > unType (TypedVegetable v) = v > > -- | bad > embraceOnion :: Vegetable -> IO () > embraceOnion veg = putStrLn ("Yay for onion! It's name is: " ++ vegName > veg) > > -- | good, but little ugly because of boilerplate > embraceOnion2 :: TypedVegetable Onion -> IO () > embraceOnion2 onion = putStrLn ("Yay for onion! It's name is: " ++ vegName > (unType onion)) > > -- | doesn't work, need to specify kind of `t` > newtype TypedLabel1 t a = TypedLabel1 a > unTyped1 :: TypedLabel1 t a -> a > unTyped1 (TypedLabel1 a) = a > embraceOnion3 :: TypedLabel1 Onion Vegetable -> IO () > embraceOnion3 = undefined > ``` > > Currently, I'm sticking to solution `embraceOnion2` in my code. > `embraceOnion3` doesn't work because of: > > ``` > /Users/kb/workspace/typelabels/typelabels.hs > > The first argument of ?Main.TypedLabel1? should have kind ?*?, > but ?Main.Onion? has kind ?Main.VegType? > In the type signature for ?Main.embraceOnion3?: > Main.embraceOnion3 :: Main.TypedLabel1 Main.Onion Main.Vegetable > -> GHC.Types.IO () > ``` > > What are the other options and "state of the art"? > > Thank you! > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Wed Feb 25 13:21:36 2015 From: k-bx at k-bx.com (Konstantine Rybnikov) Date: Wed, 25 Feb 2015 15:21:36 +0200 Subject: [Haskell-cafe] Typed label In-Reply-To: References: Message-ID: Hi Nickolay! Yes, this looks like exactly what I was looking for to continue playing. Thank you! On Wed, Feb 25, 2015 at 3:19 PM, Nickolay Kudasov < nickolay.kudasov at gmail.com> wrote: > Hi! > > You can use -XPolyKinds two have GHC figure out the kinds for you. Your > code compiles with that extra option. > > Is that what you were looking for? > > Nick > > 2015-02-25 16:12 GMT+03:00 Konstantine Rybnikov : > >> Hi! >> >> I have a problem that seems very basic and fundamental, but at the same >> time I keep somehow skipping "the right way" to solve it. So I decided to >> give a try and describe it here. >> >> The task itself is very common. You have some data, which has some >> property inside of it. Often, you want to write a function that works only >> on an object with specific property being equal to something, but you can't >> move it out to type-parameter, because then you get all sorts of problems >> like you can't use regular lists/vectors anymore and other similar things. >> >> Let's take a look at real-world example to get a better understanding of >> a problem: >> >> Given a `Vegetable` type with a type that describes it's "type" (saying >> which concretely veg is it), you need to write a function `embraceOnion`, >> which would only work on onions (because it doesn't make sense to embrace >> any other veg). >> >> https://gist.github.com/k-bx/32b3f6a770ad81330f51 >> >> ``` >> {-# LANGUAGE DataKinds #-} >> {-# LANGUAGE KindSignatures #-} >> >> module Main where >> >> main :: IO () >> main = putStrLn "Hi!" >> >> data Vegetable = Vegetable { vegName :: String >> , vetType :: VegType } >> deriving (Show, Eq) >> data VegType = Potato >> | Tomato >> | Cucumber >> | Onion >> deriving (Show, Eq) >> newtype TypedVegetable (t::VegType) = TypedVegetable Vegetable >> >> unType :: TypedVegetable (t::VegType) -> Vegetable >> unType (TypedVegetable v) = v >> >> -- | bad >> embraceOnion :: Vegetable -> IO () >> embraceOnion veg = putStrLn ("Yay for onion! It's name is: " ++ vegName >> veg) >> >> -- | good, but little ugly because of boilerplate >> embraceOnion2 :: TypedVegetable Onion -> IO () >> embraceOnion2 onion = putStrLn ("Yay for onion! It's name is: " ++ >> vegName (unType onion)) >> >> -- | doesn't work, need to specify kind of `t` >> newtype TypedLabel1 t a = TypedLabel1 a >> unTyped1 :: TypedLabel1 t a -> a >> unTyped1 (TypedLabel1 a) = a >> embraceOnion3 :: TypedLabel1 Onion Vegetable -> IO () >> embraceOnion3 = undefined >> ``` >> >> Currently, I'm sticking to solution `embraceOnion2` in my code. >> `embraceOnion3` doesn't work because of: >> >> ``` >> /Users/kb/workspace/typelabels/typelabels.hs >> >> The first argument of ?Main.TypedLabel1? should have kind ?*?, >> but ?Main.Onion? has kind ?Main.VegType? >> In the type signature for ?Main.embraceOnion3?: >> Main.embraceOnion3 :: Main.TypedLabel1 Main.Onion Main.Vegetable >> -> GHC.Types.IO () >> ``` >> >> What are the other options and "state of the art"? >> >> Thank you! >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed Feb 25 22:40:34 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 25 Feb 2015 17:40:34 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: I think I can now float an amended law that is a further step in the right direction. First I will give the law, and then I will attempt to both motivate why the amended treatment is needed, and why the weakening of the initial proposal is a legitimate approach. Finally, I will discuss some remaining issues that it would be nice to examine, including some sketches of related but alternate approaches. So, the new law: === for a lawful Foldable f, and given a fresh newtype GenericSet = GenericSet Integer deriving (Eq, Ord), and mkGenericSet = GenericSet, where GenericSet is otherwise fully abstract then forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet). maybe True (`Foldable.elem` x) (g x) === True == You may recall that the prior formulation asked that this condition hold for all a., (x :: f a), and so required an external notion of equality. Here, we ask that it only hold at a _specified type_ -- i.e. "GenericSet". So, in what sense was the older formulation "too strong"? Here is a minimal case. data TBox a where TAny :: a -> TBox a TString :: String -> TBox String TBox is just a box with some optional type information, and it should be able to be equipped with the obvious Foldable instance. However, we can now write a function such as discrim :: forall a. TBox a -> Maybe a discrim (TAny x) = Just x discrim (TString _) = "zoinks" This is to say that if we _know_ that TBox contains a string, we can now take _any_ string out of it. Clearly, the existence of such functions means that the obvious Foldable instance cannot satisfy the stronger law. By contrast, the straightforward Foldable instance for TBox still satisfies the weaker law, as we only test the action on "GenericSet" -- and since we have defined GenericSet as a fresh newtype, we know that it cannot have a tag to be matched on within a GADT we have already defined. Hence, our law, though it gives a universal property, does not give this property itself "universally" _at every type a_ but rather at a "generic type". This is by analogy with the technique of using "generic points" in algebraic geometry [1] to give properties that are not "everywhere true" but instead are true "almost everywhere", with a precise meaning given to "almost" -- i.e. that the space for which they do not hold _vanishes_. This is to say, a Foldable satisfying the proposed law will not have the property hold "at all types," but rather at "almost all types" for an analogously precise meaning of "almost". I believe that a statement of why GenericSet is indeed "generic" in some topological sense is possible, although I have not fully fleshed this out. To my knowledge, the introduction of this sort of approach in an FP context is new, but I would welcome any references showing prior art. Aside from dealing with GADTs in some fashion, the new approach has a few other useful features. First, by formulating things directly in terms of "Foldable.elem" we omit the need for some sort of notion of equality in the metalogic -- instead we can use the "Eq" typeclass directly. Furthermore, this happens to sidestep the "toList" problem in the initial approach -- it directly allows search of potentially infinite structures. There are still a few things that could potentially be better. 1) The "fully internal" approach means that we are now subject to the "bias" of "||" -- that is to say that _|_ || True -> _|_, but True || _|_ -> True. So we do not fully capture the searchability of infinite structures. This may indicate that a retreat to a metalogical description of "elem" with unbiased "or" is in order. 2) While we can generically characterize a Foldable instance on some f "almost everywhere" this is at the cost of giving it _no_ characterization at the points where our generic characterization fails. It would be nice to establish some sort of relation between the generic characterization and the action at specified points. However, I am not quite sure how to present this. An alternate approach could be to specify a Foldable law for any `f` that first takes `f` (which may be a GADT) to a related type `f1` (which must be an ordinary ADT) that squashes or omits dictionaries and equality constraints, and likewise takes the Foldable instance to a related instance on f1, and then provides a condition on f1. So rather that retreating from universal to generic properties, we instead take hold of the machinery of logical relations directly to establish a law. I would be interested in being pointed to related work along these lines as well. 3) An additional drawback of the "Generic Point" approach as given is that we chose to derive only two particular typeclasses -- Eq and Ord. An alternate approach would be to quantify over all a, but then give the property in terms of say "newtype Generify a = Generify a deriving (...)" which derives all classes on "a" that do not feature "a" in a positive position. Doing this would also mean a retreat from a fully internal notion of equality, of course... Anyway, this is clearly still work in progress, but I would appreciate any feedback on the direction this is going, or references that may seem useful. Cheers, Gershom [1] https://en.wikipedia.org/wiki/Generic_point On Thu, Feb 12, 2015 at 6:33 PM, Edward Kmett wrote: > With Foldable we *do* have a very nice law around foldMap. > > A monoid homomorphism g is a combinator such that > > g mempty = mempty > g (mappend a b) = mappend (g a) (mappend (g b) > > For any monoid homomorphism g, > > foldMap (g . f) = g . foldMap f > > We can use that to construct proofs of an analogue to "the banana split > theorem" for foldr, but rephrased in terms of foldMap: > > foldMap f &&& foldMap g = foldMap (f &&& g) > > Getting there uses the fact that fst and snd are both monoid homomorphisms. > > There are also laws relating the behavior of all of the other combinators > in Foldable to foldMap. > > Ultimately the reasons for the other members of the class are a sop to > efficiency concerns: asymptotic factors in terms of time or stack usage > matter. > > -Edward > > > On Thu, Feb 12, 2015 at 5:22 PM, Kim-Ee Yeoh wrote: > >> (removing Libraries, since not everyone on HC is on that list) >> >> I do not know all of the context of Foldable, but one I do know that's >> not been mentioned is the implicit rule-of-thumb that every type class >> should have a law. >> >> So the undercurrent is that if Foldable doesn't have a law, should it >> even be a type class? This has led to efforts to uncover laws for Foldable. >> >> Worth discussing in a separate thread is the criterion itself of "if it >> doesn't have a law, it's not a type class". Useful sometimes, but that's >> not the sine qua non of type classes. >> >> >> >> -- Kim-Ee >> >> On Fri, Feb 13, 2015 at 2:47 AM, Gershom B wrote: >> >>> For a long time, many people, including me, have said that "Foldable has >>> no laws" (or Foldable only has free laws) -- this is true, as it stands, >>> with the exception that Foldable has a non-free law in interaction with >>> Traversable (namely that it act as a proper specialization of Traversable >>> methods). However, I believe that there is a good law we can give for >>> Foldable. >>> >>> I earlier explored this in a paper presented at IFL 2014 but >>> (rightfully) rejected from the IFL post-proceedings. ( >>> http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of >>> the way there, but I believe now have a better approach on the question of >>> a Foldable law -- as sketched below. >>> >>> I think I now (unlike in the paper) can state a succinct law for >>> Foldable that has desired properties: 1) It is not "free" -- it can be >>> violated, and thus stating it adds semantic content. 2) We typically expect >>> it to be true. 3) There are no places where I can see an argument for >>> violating it. >>> >>> If it pans out, I intend to pursue this and write it up more formally, >>> but given the current FTP discussion I thought it was worth documenting >>> this earlier rather than later. For simplicity, I will state this property >>> in terms of `toList` although that does not properly capture the infinite >>> cases. Apologies for what may be nonstandard notation. >>> >>> Here is the law I think we should discuss requiring: >>> >>> * * * >>> Given Foldable f, then >>> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a >>> --> a `elem` toList x >>> * * * >>> >>> Since we do not require `a` to be of type `Eq`, note that the `elem` >>> function given here is not internal to Haskell, but in the metalogic. >>> >>> Furthermore, note that the use of parametricity here lets us make an >>> "end run" around the usual problem of giving laws to Foldable -- rather >>> than providing an interaction with another class, we provide a claim about >>> _all_ functions of a particular type. >>> >>> Also note that the functions `g` we intend to quantify over are >>> functions that _can be written_ -- so we can respect the property of data >>> structures to abstract over information. Consider >>> >>> data Funny a = Funny {hidden :: a, public :: [a]} >>> >>> instance Foldable Funny where >>> foldMap f x = foldMap f (public x) >>> >>> Now, if it is truly impossible to ever "see" hidden (i.e. it is not >>> exported, or only exported through a semantics-breaking "Internal" module), >>> then the Foldable instance is legitimate. Otherwise, the Foldable instance >>> is illegitimate by the law given above. >>> >>> I would suggest the law given is "morally" the right thing for Foldable >>> -- a Foldable instance for `f` should suggest that it gives us "all the as >>> in any `f a`", and so it is, in some particular restricted sense, initial >>> among functions that extract as. >>> >>> I do not suggest we add this law right away. However, I would like to >>> suggest considering it, and I believe it (or a cleaned-up variant) would >>> help us to see Foldable as a more legitimately lawful class that not only >>> provides conveniences but can be used to aid reasoning. >>> >>> Relating this to adjointness, as I do in the IFL preprint, remains >>> future work. >>> >>> Cheers, >>> Gershom >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semen at trygub.com Thu Feb 26 00:59:15 2015 From: semen at trygub.com (Semen Trygubenko / =?utf-8?B?0KHQtdC80LXQvSDQotGA0LjQs9GD0LHQtdC9?= =?utf-8?B?0LrQvg==?=) Date: Thu, 26 Feb 2015 00:59:15 +0000 Subject: [Haskell-cafe] Haskell Weekly News: Issue 318 Message-ID: <20150226005915.GB48811@inanna.trygub.com> New Releases A very fast BufferBuilder-based JSON encoder for Aeson. Encode JSON 2-5x faster than Aeson. https://hackage.haskell.org/package/buffer-builder-0.2.0.3 https://hackage.haskell.org/package/buffer-builder-aeson-0.2.0.3 http://www.reddit.com/r/haskell/comments/2wwbuj/announcing_bufferbuilder_encode_json_25x_faster/ FLTK GUI bindings - Alpha release This library aims to make it easy for users to build native apps that work portably across platforms. http://hackage.haskell.org/package/fltkhs-0.1.0.0/docs/Graphics-UI-FLTK-LowLevel-FLTKHS.html Calls for Participation Primitive Haskell Originally this is a chapter in Mezzo Haskell, covering primitive operations, evaluation order and mutation. Michael Snoyman wants feedback on style and teaching approach. https://www.fpcomplete.com/blog/2015/02/primitive-haskell https://github.com/fpco/mezzohaskell Intermediate Haskell documentation proposal Michael Snoyman points out that Haskell community lacks middle-weight documentation beyond the levels of RWH and LYaH, or it is redundant, of varying quality and hard to find. He proposes to create conditions that will help Haskell community to write this documentation collectively. Part of Commercial Haskell effort. https://github.com/commercialhaskell/commercialhaskell/blob/master/proposal/intermediate-haskell-documentation.md https://github.com/commercialhaskell/commercialhaskell https://groups.google.com/forum/#!topic/commercialhaskell/Ou00AvRdDTU Discussion GHC 7.10 will embody Plan FTP In the 11 day window ~800 people participated in the survey and 82% were in favour of Foldable/Traversable Proposal. https://mail.haskell.org/pipermail/libraries/2015-February/025009.html http://www.reddit.com/r/haskell/comments/2wx64g/ghc_710_will_use_plan_ftp/ Web development using Haskell A discussion of (micro)frameworks, active and (seemingly) dormant, and the ultimate minimalism. http://www.reddit.com/r/haskell/comments/2wfap0/web_development_using_haskell/ Free Monoids in Haskell Lists aren't! http://comonad.com/reader/2015/free-monoids-in-haskell/ https://www.reddit.com/r/haskell/comments/2wqxqv/the_comonadreader_dan_doel_free_monoids_in_haskell/ Let's teach GHC idiom brackets! (| pureFunction (fetchWith some params) (fetchMore withOthers) |) vs pureFunction <$> fetchWith some params <*> fetchMore withOthers https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118228.html http://www.reddit.com/r/haskell/comments/2wclln/haskellcafe_lets_teach_ghc_idiom_brackets/ Is working with numeric formulas on Haskell a pain for anyone else? (/) and quot have different semantics, and this makes it hard to implement formulas. http://www.reddit.com/r/haskell/comments/2ws786/is_working_with_numeric_formulas_on_haskell_a/ Monads in a non Functional Programming language X Haskell Fluid interfaces and Monads have little in common, although it might look like a lot. http://www.reddit.com/r/haskell/comments/2wefft/monads_in_a_non_functional_programming_language_x/ Quotes of the Week "would require parens" in haskell world is like saying "would require taking lives" (chrisdone) "Functional programming beats all GOF Gang of Four patterns." (eniacsparc2xyz) http://www.reddit.com/r/haskell/comments/2wjtq5/haskell_actually_does_change_the_way_you_think/ "? pure functional programming and HTTP are a match made in heaven (type Application = Request -> Response - it doesn't get any more sensible than that ;)) ?" (tdammers) http://www.reddit.com/r/haskell/comments/2wfap0/web_development_using_haskell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From s.j.thompson at kent.ac.uk Thu Feb 26 07:12:59 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Thu, 26 Feb 2015 07:12:59 +0000 Subject: [Haskell-cafe] SBLP 2015: 19th Brazilian Symposium on Programming Languages References: <201502260253.t1Q2rqKS031432@easychair.org> Message-ID: <54C5AFE8-626D-4C9C-8DCB-4E197534E367@kent.ac.uk> +++++++++++++++++++++++++++++++++++++++++++++++++++ CALL FOR PAPERS - SBLP 2015 19th Brazilian Symposium on Programming Languages 21-26 September 2015 Belo Horizonte, Brazil http://cbsoft.org/sblp2015 +++++++++++++++++++++++++++++++++++++++++++++++++++ IMPORTANT DATES Abstract submission: 20 April, 2015 Paper submission: 27 April, 2015 Author notification: 18 June, 2015 Camera ready deadline: 2 July 2015 INTRODUCTION The Brazilian Symposium on Programming Languages is a well-established symposium which provides a venue for researchers and practitioners interested in the fundamental principles and innovations in the design and implementation of programming languages and systems. SBLP 2015 is part of 6th Brazilian Conference on Software: Theory and Practice, CBSoft 2015, that will be held in Belo Horizonte, Minas Gerais, Brazil, from September 21st to September 26th, 2015. Authors are invited to submit original research on any relevant topic which can be either in the form of regular or short papers. TOPICS Topics of interest include, but are not limited to: * Program generation and transformation, including domain-specific languages and model-driven development in the context of programming languages. * Programming paradigms and styles, including functional, object-oriented, aspect-oriented, scripting languages, real-time, service-oriented, multithreaded, parallel, and distributed programming. * Formal semantics and theoretical foundations, including denotational, operational, algebraic and categorical. * Program analysis and verification, including type systems, static analysis and abstract interpretation. * Programming language design and implementation, including new programming models, programming language environments, compilation and interpretation techniques. INVITED SPEAKERS * Doaitse Swierstra, Utrecht University * TBA SUBMISSION AND PUBLICATION All submissions will be peer-reviewed and judged on the basis of its originality, contribution to the field, technical and presentation quality, and relevance to the symposium. Contributions should be written in Portuguese or English. Papers should fall into one of two different categories: regular papers, which can be up to 15 pages long in LNCS format, or short papers, with up to 5 pages in LNCS format. Short papers can discuss new ideas which are at an early stage of development and which have not yet been thoroughly evaluated. We encourage the submission of short papers reporting partial results of on-going master dissertations or doctoral theses. Accepted papers written in English will be published in a volume of Lecture Notes in Computer Science (LNCS), by Springer. Both regular and short papers must be prepared using the LNCS format, available at http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0. Papers must be submitted electronically (in PDF format) via the Easychair System: http://www.easychair.org/conferences/?conf=sblp2015. As in previous editions, after the conference, authors of selected papers will be invited to submit an extended version of their work to be considered for publication in a journal special issue. Since 2009, selected papers of each SBPL edition are being published in a special issue of Science of Computer Programming, by Elsevier. PROGRAM CHAIRS Alberto Pardo, Universidad de la Rep?blica, Uruguay Doaitse Swierstra, Utrecht University, The Netherlands PROGRAM COMMITTEE Alberto Pardo, Universidad de la Rep?blica (co-chair) Alex Garcia, IME Alvaro Moreira, Federal University of Rio Grande do Sul Andre Rauber Du Bois, Federal University of Pelotas Carlos Camar?o, Federal University of Minas Gerais Christiano Braga, Fluminense Federal University Doaitse Swierstra, Utrecht University (co-chair) Fabio Mascarenhas, Federal University of Rio de Janeiro Fernando Pereira, Federal University of Minas Gerais Fernando Castor, Federal University of Pernambuco Francisco Carvalho-Junior, Federal University of Ceara Hans-Wolfgang Loidl, Heriot-Watt University Jo?o Saraiva, University of Minho Jo?o F. Ferreira, Teesside University Louis-Noel Pouchet, University of California, Los Angeles Lucilia Figueiredo, Federal University of Ouro Preto Luis Barbosa, University of Minho Manuel A. Martins, University of Aveiro Marcelo Maia, Federal University of Uberl?ndia Marcelo D'Amorim, Federal University of Pernambuco Mariza Bigonha, Federal University of Minas Gerais Martin Musicante, Federal University of Rio Grande do Norte Noemi Rodriguez, PUC-Rio Peter Mosses, Swansea University Rafael Lins, Federal University of Pernambuco Renato Cerqueira, PUC-Rio Roberto Bigonha, Federal University of Minas Gerais Roberto Ierusalimschy PUC-Rio Rodrigo Geraldo, Federal University of Ouro Preto Sandro Rigo, State University of Campinas S?rgio Medeiros, Federal University of Rio Grande do Norte Simon Thompson, University of Kent Varmo Vene, University of Tartu Zongyan Qiu Peking University Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From mail at joachim-breitner.de Thu Feb 26 13:36:11 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 26 Feb 2015 14:36:11 +0100 Subject: [Haskell-cafe] Would you use frozen-base Message-ID: <1424957771.1948.49.camel@joachim-breitner.de> Hi, = Introduction (can be skipped) = Recently, I find myself often worried about stability of our ecosystem ? may it be the FTP discussion, or the proposed? removal of functions you shouldn?t use, like fromJust. While all that makes our language and base libraries nicer, it also means that my chances that code from 3 or 4 years ago will compile without adjustment on newer compilers are quite low. Then I remember that a perl based webpage that I wrote 12 years ago just keeps working, even as I upgrade perl with every Debian stable release, and I?m happy about that. It makes me wonder if I am ever going to regret using Haskell because there, I?d have to decide whether I want to invest time to upgrade my code or simply stop using it. I definitely do not want to stop Haskell from evolving. Maybe we can make a more stable Haskell experience opt-in? This is one step in that direction, solving (as always) only parts of the problem. = The problem = One problem is that our central library "base" is both an implementation and an interface. As the implementation is tied to the compiler, and the interface comes with the implementation, you cannot upgrade one without the other. = My solution: frozen-base = My solution would be to provide a new library, let?s call it frozen-base, which decouples the interface (frozen-base) from the implementation (still base). We would start with one particular version of base, say, 4.6. With GHC-7.6 (which comes with base 4.6), frozen-base would simply re-export its modules?. On newer compilers and newer versions of base, it would re-create the old interface using CPP. So if your program depends on frozen-base only, you can expect it to compile with newer versions of GHC ? achievement unlocked. = How to get new features, then? = But does that mean that you do not get to use great new functionality in later versions of base, such as Data.Bool.bool? No: When a new version of base gets released, and a module gets changed, than frozen-base will ship a _new_ module, named Data.Bool1 that matches that interface. The next change in base causes yet another module to be created, i.e. Data.Bool2 So if you need to use Data.Bool.bool, in one of your modules, you simply change the import from "import Data.Bool" to "import Data.Bool2", adjust your code to the new interface, and are ready to go. Note that you only had to adjust to the changes in Data.Bool, nothing else. Note that you also had to touch only a single module in your program, the others still use whatever interface they were using. Your dependency on frozen-base would have to indicate a lower version bound, i.e. specify the lowest version that has all the Data.Bool variants that you desire, but ? by design ? never an upper version.? = When does it not work? = Of course, the promises by froze-base are not absolute: There are changes in base that frozen-base cannot protect you against: Data type changes, some type class changes, type class instances. I don?t have any great ideas here, but maybe they are rare enough so that frozen-base is still useful. = What about the Prelude? = I did not talk about the Prelude. There probably is not a good solution, and I?d simply leave the Prelude frozen. Maybe later GHC has a nice way to specifying which Prelude to use in a certain module, then you could use "Prelude1", "Prelude2" etc. in the same manner. = How does it related to base-compat? = The idea is similar to what base-compat provides, but the other way around: base-compat allows you to use the latest features of base on older compilers, while frozen-base would allow you to use the API of old base versions on newer systems. Frozen-base might subsume base-compat by providing, say Data.Bool2 with the API from base-4.8 also on systems with base-4.6. = How does it related to the split base proposal = Depending on how exactly base is being reconstructed, it might become a pure interface package on its own, or at least independent from compiler-specific bits. Then it might be feasible that, say, after the release of ghc-7.10 there is a new upload of base-4.6.0.n that provides the 4.6 API, but compiles on ghc-7.10. This way, if you depend on base == 4.6.* you could still expect your program to work. If that happens, and also cabal would learn that a plan with different versions of a interface only library like base are not a problem, frozen-base might be obsoleted. See https://ghc.haskell.org/trac/ghc/wiki/SplitBase for more on that. = No Conclusion and lots of future work = So what do you think? Would you be interested in using this? Do you have reasons to believe that this will not work as nicely as I think i could? Greetings, Joachim ? but rejected, it seems ? or a sensible subset; I could imagine not exporting certain .Internal modules and things like OldTypeable that are about compatibility themselves. ? or just one on the very major version number (frozen-base < 2), which to allow for exceptional breaking changes ? a redesign of the module naming scheme for example. -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From ianwookim at gmail.com Thu Feb 26 14:04:02 2015 From: ianwookim at gmail.com (Ian-Woo Kim) Date: Thu, 26 Feb 2015 15:04:02 +0100 Subject: [Haskell-cafe] [ANN] hoodle 0.4 Message-ID: Hi, Haskellers! I am happy to announce a new version of hoodle that I uploaded to hackage right now. The newest version is 0.4. Hoodle is a pen notetaking program developed in haskell using gtk2hs. You can find relevant information here: http://ianwookim.org/hoodle If all the dependencies are correctly installed (hoodle has rather big dependencies though), the installation of hoodle should be easily doable by cabal install hoodle. I am managing hoodle in nix package repository, so nix users can also easily install hoodle by nix command once after nix expression in nixpkgs is updated. The major change in this update is *tabbed* interface! Like modern web browsers, you can open multiple hoodle files in one hoodle window and navigate them using tabs. Internally, I improved its rendering engine quite much. Now it has a fully asynchronous renderer, which enables a faster change of zoom ratio using cached image and then update rendering later more precisely. This improves display performance from user's point of view a lot. I also made a support for synchronisation and shared documents in association with a web service which I am now preparing for. By default, it is turned off, so all network-related dependencies for that will not be required unless turned on by -fhub flag. In addition, I also made dyre (dynamic reloading as xmonad and yi) opt-in, so you need to use -fdyre if you want to have the feature. Now hoodle is being migrated to gtk3 though this version will not support gtk3 fully yet. I plan to migrate hoodle to gtk3 fully and use gtk3 exclusively in the next version, so this version will be the last gtk2 version. Once this is done, a multi-touch support will be enabled. (and also hoodle will be able to live in wayland, too!) Enjoy hoodle and please bug me if you have any issues. Thank you! best, Ian-Woo Kim From roma at ro-che.info Thu Feb 26 14:14:00 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 26 Feb 2015 16:14:00 +0200 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: <1424957771.1948.49.camel@joachim-breitner.de> References: <1424957771.1948.49.camel@joachim-breitner.de> Message-ID: <54EF2A28.6070009@ro-che.info> I don't think frozen-base by itself is enough to achieve the goal of compiling n-year-old code without modifications. Just a couple of examples that jump to mind: - the recent change to require extensions for inferred types - AMP (e.g. your code had a monad defined without an applicative instance) Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From david.feuer at gmail.com Thu Feb 26 14:17:43 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 26 Feb 2015 09:17:43 -0500 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: <1424957771.1948.49.camel@joachim-breitner.de> References: <1424957771.1948.49.camel@joachim-breitner.de> Message-ID: This sounds like a dependency nightmare to me. On Feb 26, 2015 8:36 AM, "Joachim Breitner" wrote: > Hi, > > = Introduction (can be skipped) = > > Recently, I find myself often worried about stability of our ecosystem ? > may it be the FTP discussion, or the proposed? removal of functions you > shouldn?t use, like fromJust. While all that makes our language and base > libraries nicer, it also means that my chances that code from 3 or 4 > years ago will compile without adjustment on newer compilers are quite > low. > > Then I remember that a perl based webpage that I wrote 12 years ago just > keeps working, even as I upgrade perl with every Debian stable release, > and I?m happy about that. It makes me wonder if I am ever going to > regret using Haskell because there, I?d have to decide whether I want to > invest time to upgrade my code or simply stop using it. > > I definitely do not want to stop Haskell from evolving. Maybe we can > make a more stable Haskell experience opt-in? This is one step in that > direction, solving (as always) only parts of the problem. > > = The problem = > > One problem is that our central library "base" is both an implementation > and an interface. As the implementation is tied to the compiler, and the > interface comes with the implementation, you cannot upgrade one without > the other. > > = My solution: frozen-base = > > My solution would be to provide a new library, let?s call it > frozen-base, which decouples the interface (frozen-base) from the > implementation (still base). > > We would start with one particular version of base, say, 4.6. With > GHC-7.6 (which comes with base 4.6), frozen-base would simply re-export > its modules?. On newer compilers and newer versions of base, it would > re-create the old interface using CPP. So if your program depends on > frozen-base only, you can expect it to compile with newer versions of > GHC ? achievement unlocked. > > = How to get new features, then? = > > But does that mean that you do not get to use great new functionality in > later versions of base, such as Data.Bool.bool? No: When a new version > of base gets released, and a module gets changed, than frozen-base will > ship a _new_ module, named > Data.Bool1 > that matches that interface. The next change in base causes yet another > module to be created, i.e. > Data.Bool2 > So if you need to use Data.Bool.bool, in one of your modules, you simply > change the import from "import Data.Bool" to "import Data.Bool2", adjust > your code to the new interface, and are ready to go. Note that you only > had to adjust to the changes in Data.Bool, nothing else. Note that you > also had to touch only a single module in your program, the others still > use whatever interface they were using. > > Your dependency on frozen-base would have to indicate a lower version > bound, i.e. specify the lowest version that has all the Data.Bool > variants that you desire, but ? by design ? never an upper version.? > > = When does it not work? = > > Of course, the promises by froze-base are not absolute: There are > changes in base that frozen-base cannot protect you against: Data type > changes, some type class changes, type class instances. I don?t have any > great ideas here, but maybe they are rare enough so that frozen-base is > still useful. > > = What about the Prelude? = > > I did not talk about the Prelude. There probably is not a good solution, > and I?d simply leave the Prelude frozen. Maybe later GHC has a nice way > to specifying which Prelude to use in a certain module, then you could > use "Prelude1", "Prelude2" etc. in the same manner. > > = How does it related to base-compat? = > > The idea is similar to what base-compat provides, but the other way > around: base-compat allows you to use the latest features of base on > older compilers, while frozen-base would allow you to use the API of old > base versions on newer systems. > > Frozen-base might subsume base-compat by providing, say Data.Bool2 with > the API from base-4.8 also on systems with base-4.6. > > = How does it related to the split base proposal = > > Depending on how exactly base is being reconstructed, it might become a > pure interface package on its own, or at least independent from > compiler-specific bits. Then it might be feasible that, say, after the > release of ghc-7.10 there is a new upload of base-4.6.0.n that provides > the 4.6 API, but compiles on ghc-7.10. This way, if you depend on > base == 4.6.* > you could still expect your program to work. If that happens, and also > cabal would learn that a plan with different versions of a interface > only library like base are not a problem, frozen-base might be > obsoleted. > > See https://ghc.haskell.org/trac/ghc/wiki/SplitBase for more on that. > > > = No Conclusion and lots of future work = > > So what do you think? Would you be interested in using this? Do you have > reasons to believe that this will not work as nicely as I think i could? > > > > Greetings, > Joachim > > > > > ? but rejected, it seems > ? or a sensible subset; I could imagine not exporting certain .Internal > modules and things like OldTypeable that are about compatibility > themselves. > ? or just one on the very major version number (frozen-base < 2), which > to allow for exceptional breaking changes ? a redesign of the module > naming scheme for example. > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.mvd at gmail.com Thu Feb 26 14:18:20 2015 From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=) Date: Thu, 26 Feb 2015 14:18:20 +0000 Subject: [Haskell-cafe] safe ways how to get head/last of Seq (or Foldable in general) Message-ID: Hi, today I was a bit surprised that apparently there is no easy way how to safely get the head element of `Seq` in a point-free way. Of course there is `viewl`, but it seems the data type has no folding function (something like 'foldViewL :: b -> (a -> Seq a -> b) -> b`. Is there any existing function like `Seq a -> Maybe a` to safely retrieve the head (or last) element? If not, I'd suggest to add headMaybe :: (Foldable t) => t a -> Maybe a headMaybe = getFirst . foldMap (First . Just) and similarly lastMaybe to Data.Foldable. Thanks, Petr -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Feb 26 14:21:38 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 26 Feb 2015 09:21:38 -0500 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: <1424957771.1948.49.camel@joachim-breitner.de> References: <1424957771.1948.49.camel@joachim-breitner.de> Message-ID: I believe that a way to avoid orphan instances without needing huge modules (such as my instance declaration idea) would help a lot in this regard, long term?the smaller modules are, the less trouble changes cause and the better a system you propose can work. On Feb 26, 2015 8:36 AM, "Joachim Breitner" wrote: > Hi, > > = Introduction (can be skipped) = > > Recently, I find myself often worried about stability of our ecosystem ? > may it be the FTP discussion, or the proposed? removal of functions you > shouldn?t use, like fromJust. While all that makes our language and base > libraries nicer, it also means that my chances that code from 3 or 4 > years ago will compile without adjustment on newer compilers are quite > low. > > Then I remember that a perl based webpage that I wrote 12 years ago just > keeps working, even as I upgrade perl with every Debian stable release, > and I?m happy about that. It makes me wonder if I am ever going to > regret using Haskell because there, I?d have to decide whether I want to > invest time to upgrade my code or simply stop using it. > > I definitely do not want to stop Haskell from evolving. Maybe we can > make a more stable Haskell experience opt-in? This is one step in that > direction, solving (as always) only parts of the problem. > > = The problem = > > One problem is that our central library "base" is both an implementation > and an interface. As the implementation is tied to the compiler, and the > interface comes with the implementation, you cannot upgrade one without > the other. > > = My solution: frozen-base = > > My solution would be to provide a new library, let?s call it > frozen-base, which decouples the interface (frozen-base) from the > implementation (still base). > > We would start with one particular version of base, say, 4.6. With > GHC-7.6 (which comes with base 4.6), frozen-base would simply re-export > its modules?. On newer compilers and newer versions of base, it would > re-create the old interface using CPP. So if your program depends on > frozen-base only, you can expect it to compile with newer versions of > GHC ? achievement unlocked. > > = How to get new features, then? = > > But does that mean that you do not get to use great new functionality in > later versions of base, such as Data.Bool.bool? No: When a new version > of base gets released, and a module gets changed, than frozen-base will > ship a _new_ module, named > Data.Bool1 > that matches that interface. The next change in base causes yet another > module to be created, i.e. > Data.Bool2 > So if you need to use Data.Bool.bool, in one of your modules, you simply > change the import from "import Data.Bool" to "import Data.Bool2", adjust > your code to the new interface, and are ready to go. Note that you only > had to adjust to the changes in Data.Bool, nothing else. Note that you > also had to touch only a single module in your program, the others still > use whatever interface they were using. > > Your dependency on frozen-base would have to indicate a lower version > bound, i.e. specify the lowest version that has all the Data.Bool > variants that you desire, but ? by design ? never an upper version.? > > = When does it not work? = > > Of course, the promises by froze-base are not absolute: There are > changes in base that frozen-base cannot protect you against: Data type > changes, some type class changes, type class instances. I don?t have any > great ideas here, but maybe they are rare enough so that frozen-base is > still useful. > > = What about the Prelude? = > > I did not talk about the Prelude. There probably is not a good solution, > and I?d simply leave the Prelude frozen. Maybe later GHC has a nice way > to specifying which Prelude to use in a certain module, then you could > use "Prelude1", "Prelude2" etc. in the same manner. > > = How does it related to base-compat? = > > The idea is similar to what base-compat provides, but the other way > around: base-compat allows you to use the latest features of base on > older compilers, while frozen-base would allow you to use the API of old > base versions on newer systems. > > Frozen-base might subsume base-compat by providing, say Data.Bool2 with > the API from base-4.8 also on systems with base-4.6. > > = How does it related to the split base proposal = > > Depending on how exactly base is being reconstructed, it might become a > pure interface package on its own, or at least independent from > compiler-specific bits. Then it might be feasible that, say, after the > release of ghc-7.10 there is a new upload of base-4.6.0.n that provides > the 4.6 API, but compiles on ghc-7.10. This way, if you depend on > base == 4.6.* > you could still expect your program to work. If that happens, and also > cabal would learn that a plan with different versions of a interface > only library like base are not a problem, frozen-base might be > obsoleted. > > See https://ghc.haskell.org/trac/ghc/wiki/SplitBase for more on that. > > > = No Conclusion and lots of future work = > > So what do you think? Would you be interested in using this? Do you have > reasons to believe that this will not work as nicely as I think i could? > > > > Greetings, > Joachim > > > > > ? but rejected, it seems > ? or a sensible subset; I could imagine not exporting certain .Internal > modules and things like OldTypeable that are about compatibility > themselves. > ? or just one on the very major version number (frozen-base < 2), which > to allow for exceptional breaking changes ? a redesign of the module > naming scheme for example. > > -- > Joachim ?nomeata? Breitner > mail at joachim-breitner.de ? http://www.joachim-breitner.de/ > Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Feb 26 14:24:15 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 26 Feb 2015 15:24:15 +0100 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: References: <1424957771.1948.49.camel@joachim-breitner.de> Message-ID: <1424960655.1948.52.camel@joachim-breitner.de> Hi, Am Donnerstag, den 26.02.2015, 09:17 -0500 schrieb David Feuer: > This sounds like a dependency nightmare to me. care to elaborate? A nightmare for whom? Greetings, Joachim > -- Joachim Breitner e-Mail: mail at joachim-breitner.de Homepage: http://www.joachim-breitner.de Jabber-ID: nomeata at joachim-breitner.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From michael at snoyman.com Thu Feb 26 14:26:08 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 26 Feb 2015 14:26:08 +0000 Subject: [Haskell-cafe] safe ways how to get head/last of Seq (or Foldable in general) References: Message-ID: The mono-traversable package provides headMay[1] which works for Seq. [1] http://www.stackage.org/haddock/nightly-2015-02-25/mono-traversable-0.9.0.1/Data-MonoTraversable.html#v:headMay On Thu Feb 26 2015 at 4:18:31 PM Petr Pudl?k wrote: > Hi, > > today I was a bit surprised that apparently there is no easy way how to > safely get the head element of `Seq` in a point-free way. Of course there > is `viewl`, but it seems the data type has no folding function (something > like 'foldViewL :: b -> (a -> Seq a -> b) -> b`. > > Is there any existing function like `Seq a -> Maybe a` to safely retrieve > the head (or last) element? > > If not, I'd suggest to add > > headMaybe :: (Foldable t) => t a -> Maybe a > headMaybe = getFirst . foldMap (First . Just) > > and similarly lastMaybe to Data.Foldable. > > Thanks, > Petr > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Feb 26 15:03:19 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 26 Feb 2015 10:03:19 -0500 Subject: [Haskell-cafe] safe ways how to get head/last of Seq (or Foldable in general) In-Reply-To: References: Message-ID: So are you suggesting that we add these to Data.Foldable? headMay = foldr (\x _ -> Just x) Nothing lastMay = foldl (\_ x -> Just x) Nothing On Feb 26, 2015 9:18 AM, "Petr Pudl?k" wrote: > Hi, > > today I was a bit surprised that apparently there is no easy way how to > safely get the head element of `Seq` in a point-free way. Of course there > is `viewl`, but it seems the data type has no folding function (something > like 'foldViewL :: b -> (a -> Seq a -> b) -> b`. > > Is there any existing function like `Seq a -> Maybe a` to safely retrieve > the head (or last) element? > > If not, I'd suggest to add > > headMaybe :: (Foldable t) => t a -> Maybe a > headMaybe = getFirst . foldMap (First . Just) > > and similarly lastMaybe to Data.Foldable. > > Thanks, > Petr > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petr.mvd at gmail.com Thu Feb 26 16:13:54 2015 From: petr.mvd at gmail.com (=?UTF-8?B?UGV0ciBQdWRsw6Fr?=) Date: Thu, 26 Feb 2015 16:13:54 +0000 Subject: [Haskell-cafe] safe ways how to get head/last of Seq (or Foldable in general) References: Message-ID: Yes, that'd be my suggestion. ?t 26. 2. 2015 v 16:03 odes?latel David Feuer napsal: > So are you suggesting that we add these to Data.Foldable? > > headMay = foldr (\x _ -> Just x) Nothing > lastMay = foldl (\_ x -> Just x) Nothing > On Feb 26, 2015 9:18 AM, "Petr Pudl?k" wrote: > >> Hi, >> >> today I was a bit surprised that apparently there is no easy way how to >> safely get the head element of `Seq` in a point-free way. Of course there >> is `viewl`, but it seems the data type has no folding function (something >> like 'foldViewL :: b -> (a -> Seq a -> b) -> b`. >> >> Is there any existing function like `Seq a -> Maybe a` to safely retrieve >> the head (or last) element? >> >> If not, I'd suggest to add >> >> headMaybe :: (Foldable t) => t a -> Maybe a >> headMaybe = getFirst . foldMap (First . Just) >> >> and similarly lastMaybe to Data.Foldable. >> >> Thanks, >> Petr >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ab at fmap.me Thu Feb 26 18:19:01 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Thu, 26 Feb 2015 21:19:01 +0300 Subject: [Haskell-cafe] RankNTypes question Message-ID: <54EF6395.3020108@fmap.me> Hi Cafe, I can't find how can I do this: {-# LANGUAGE RankNTypes #-} example :: forall a. (forall b. b) -> a example = undefined The first `forall` is for cosmetic reasons. If I understand correctly this is a safe and legit function (please correct me if I'm wrong!). I thought that I can just define `example = id` and GHC would do the rest, but alas, that didn't happen. Thanks! -- Nikolay. From ab at fmap.me Thu Feb 26 18:36:42 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Thu, 26 Feb 2015 21:36:42 +0300 Subject: [Haskell-cafe] RankNTypes question In-Reply-To: References: <54EF6395.3020108@fmap.me> Message-ID: <54EF67BA.3010603@fmap.me> Hm, now that I look at it, I've given the wrong example which badly describes what I want -- sorry. Let me give you a more specific one: {-# LANGUAGE RankNTypes #-} test :: (forall a. (a -> a)) -> (Int -> Int) test = id-- something else should be here i.e., I want to "specialize" a polymorphic value -- in this case, a polymorphic function to the function on `Int`s. On 02/26/2015 09:24 PM, Marcin Mrotek wrote: > Hello, > > id has type a -> a, a function from some type to exactly the same > type. Your function would be from any type to any other (the same type > as given being a special case). It seem to me that > > example _ = undefined > > is the only legal definition. What do you exactly want the function to do? > > Kind regards, > Marcin Mrotek -- Nikolay. From ab at fmap.me Thu Feb 26 18:50:31 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Thu, 26 Feb 2015 21:50:31 +0300 Subject: [Haskell-cafe] RankNTypes question In-Reply-To: References: <54EF6395.3020108@fmap.me> <54EF67BA.3010603@fmap.me> Message-ID: <54EF6AF7.90800@fmap.me> Ah, thanks! For some reason I haven't even thought of it -- I knew that `id` was wrong because of the type, but had no idea what else to try. Feeling stupid now. On 02/26/2015 09:46 PM, Marcin Mrotek wrote: > Well still, id is (a -> a). So given some function (forall b. b -> b) > it's result is a function (forall b. b -> b). This works: > > test :: (forall a. a -> a) -> Int -> Int > test f a = f a > > Kind regards, > Marcin Mrotek -- Nikolay. From marcin.jan.mrotek at gmail.com Thu Feb 26 18:53:41 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Thu, 26 Feb 2015 19:53:41 +0100 Subject: [Haskell-cafe] RankNTypes question In-Reply-To: <54EF6395.3020108@fmap.me> References: <54EF6395.3020108@fmap.me> Message-ID: Ah sorry, I think I responded only to you, not to the whole list. If anyone else is interested, my answer was: test :: (forall a. a -> a) -> Int -> Int test f a = f a Also consider this: foo :: Maybe a -> Maybe b foo Nothing = Nothing vs. foo :: Maybe a -> Maybe b fooo a at Nothing = a You don't actually need RankNTypes to bump into this. Don't feel stupid, I remember running into this kind of things frequently when I was trying to define Prisms (from lens) by hand ;) Kind regards, Marcin Mrotek From ky3 at atamo.com Thu Feb 26 19:24:49 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 27 Feb 2015 02:24:49 +0700 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: <54EF2A28.6070009@ro-che.info> References: <1424957771.1948.49.camel@joachim-breitner.de> <54EF2A28.6070009@ro-che.info> Message-ID: On Thu, Feb 26, 2015 at 9:14 PM, Roman Cheplyaka wrote: > I don't think frozen-base by itself is enough to achieve the goal of > compiling n-year-old code without modifications. > I second Joachim's concerns about stability. While not completely au fait with the technicalities of frozen-base, it does seem to me that something more is needed. > Just a couple of examples that jump to mind: > > - the recent change to require extensions for inferred types > I did a search on ghc tickets and while a few seems to fit the bill, I don't know what this refers to. > - AMP (e.g. your code had a monad defined without an applicative instance) > As a first pass, punt on this? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Feb 26 19:36:47 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 26 Feb 2015 20:36:47 +0100 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: References: <1424957771.1948.49.camel@joachim-breitner.de> <54EF2A28.6070009@ro-che.info> Message-ID: On Thu, Feb 26, 2015 at 8:24 PM, Kim-Ee Yeoh wrote: > > On Thu, Feb 26, 2015 at 9:14 PM, Roman Cheplyaka wrote: >> Just a couple of examples that jump to mind: >> >> - the recent change to require extensions for inferred types > > I did a search on ghc tickets and while a few seems to fit the bill, I don't > know what this refers to. GHC 7.10 requires extensions like FlexibleContexts on inferred signatures if writing down the signature would need the extension. See the top bullet point here [1]. Erik [1] https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html#idp5770992 From ky3 at atamo.com Thu Feb 26 19:47:14 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 27 Feb 2015 02:47:14 +0700 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: References: <1424957771.1948.49.camel@joachim-breitner.de> <54EF2A28.6070009@ro-che.info> Message-ID: On Fri, Feb 27, 2015 at 2:36 AM, Erik Hesselink wrote: > GHC 7.10 requires extensions like FlexibleContexts on inferred > signatures if writing down the signature would need the extension. See > the top bullet point here [1]. > > [1] > https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html#idp5770992 Thank you, Erik. Something that comes to mind immediately is a pragma to turn it off. You don't happen to know the patch this was in, do you? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Thu Feb 26 19:50:58 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 26 Feb 2015 20:50:58 +0100 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: <1424957771.1948.49.camel@joachim-breitner.de> References: <1424957771.1948.49.camel@joachim-breitner.de> Message-ID: On 26-02-2015 14:36, Joachim Breitner wrote: > Hi, [--snip--] > > But does that mean that you do not get to use great new functionality in > later versions of base, such as Data.Bool.bool? No: When a new version > of base gets released, and a module gets changed, than frozen-base will > ship a _new_ module, named > Data.Bool1 > that matches that interface. The next change in base causes yet another > module to be created, i.e. > Data.Bool2 > So if you need to use Data.Bool.bool, in one of your modules, you simply > change the import from "import Data.Bool" to "import Data.Bool2", adjust > your code to the new interface, and are ready to go. Note that you only > had to adjust to the changes in Data.Bool, nothing else. Note that you > also had to touch only a single module in your program, the others still > use whatever interface they were using. Having actually worked with code using this approach to versioning, I think I can safely say that it is absolute hell in practice -- way worse than sprinkling a few CPP directives here and there. Granted, in my particular case data structures were also versioned thusly, and so you'd end up with reams of boilerplate (but only sometimes boilerplate!) Bool1<->Bool2 conversion code. Similar problems would ensue if semantics of Foo1.frobnicate() and Foo2.frobnicate() were subtly different, but you'd happened to call the wrong one. Not to mention all the namespace pollution if you need to access both Foo1 and Foo2 in the same module. There's also the mental overhead of having to be aware of all the Foo1, Foo2, ... modules and the differences between them. (There's probably a lot more pain that I've just repressed, but that's just off the top of my head.) The proper solution to this problem (as with so many things) is another layer of indirection, namely a proper way to separate API and implementation. (Aka "Backpack" or similar.) Regards, From ollie at ocharles.org.uk Thu Feb 26 21:04:03 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 26 Feb 2015 21:04:03 +0000 Subject: [Haskell-cafe] Idiom Brackets for GHC (first full proposal) Message-ID: <8761aoxu4c.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Hi all, A few days ago I made a post here to gauge interest in adding idiom brackets to GHC. Response was a bit more mixed than I was hoping, but no one seemed to drastically against the idea, so I've moved forward with a more detailed proposal. You can find the full proposal here: https://ocharles.org.uk/IdiomBrackets.html A particular difference in my proposal from existing solutions comes from my desire to lift almost *all* expressions - with the original syntax - into idiom brackets. This means normal function application and tuples, but also case expressions, let bindings, record construction, record update, infix notation, and so on. At first I was skeptical about this, but I am finding uses for this more and more. I really like how it lets me use the interesting data (that is, whatever is "under" the applicative functor) where it's most relevant - rather than having to build a function and thread that value back through. Examples of this can be seen in my proposal. To prove its use, I've been working with this Template Haskell expression: https://ocharles.org.uk/IdiomExp.hs It *almost* does exactly what I want, the only problem is I can't get Template Haskell to give me a difference between $(i [| const True False |]) and $(i [| (const True) False |]) which I was planning to be significant. The proposal has mostly grown into my own personal notebook, so I'm happy to clarify anything that is vague/contradictory/confusing. Look forward to hearing your thoughts! -- Ollie From mail at joachim-breitner.de Thu Feb 26 23:07:37 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 27 Feb 2015 00:07:37 +0100 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: References: <1424957771.1948.49.camel@joachim-breitner.de> Message-ID: <1424992057.13156.5.camel@joachim-breitner.de> Hi, Am Donnerstag, den 26.02.2015, 20:50 +0100 schrieb Bardur Arantsson: > Having actually worked with code using this approach to versioning, I > think I can safely say that it is absolute hell in practice -- way worse > than sprinkling a few CPP directives here and there. Interesting, and good to hear about that! > Granted, in my > particular case data structures were also versioned thusly, and so you'd > end up with reams of boilerplate (but only sometimes boilerplate!) > Bool1<->Bool2 conversion code. The way I imagine it to work, this would happen here, as the actual data type will always be the one from the current system?s base. > Similar problems would ensue if semantics > of Foo1.frobnicate() and Foo2.frobnicate() were subtly different, but > you'd happened to call the wrong one. Not to mention all the namespace > pollution if you need to access both Foo1 and Foo2 in the same module. Well, that should not ever need happen (comparable to how today, you never access base-4.6:Foo and base-4.7:Foo in the same package ? I hope). > There's also the mental overhead of having to be aware of all the Foo1, > Foo2, ... modules and the differences between them. (There's probably a > lot more pain that I've just repressed, but that's just off the top of > my head.) > > The proper solution to this problem (as with so many things) is another > layer of indirection, namely a proper way to separate API and > implementation. (Aka "Backpack" or similar.) But that is precisely what frozen-base is trying to provide ? just APIs, no implementations. Note that it should merely re-export stuff from base (or maybe base-compat or similar), and simply guarantee that the set of exported functions of one particular module does not change any more. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From roma at ro-che.info Thu Feb 26 23:28:12 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 27 Feb 2015 01:28:12 +0200 Subject: [Haskell-cafe] Idiom Brackets for GHC (first full proposal) In-Reply-To: <8761aoxu4c.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> References: <8761aoxu4c.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> Message-ID: <54EFAC0C.7050501@ro-che.info> I'm starting to like this. Except the weird difference between spaces on different levels that you point out, i.e. [| const True False |] vs [| (const True) False |] On 26/02/15 23:04, Oliver Charles wrote: > Hi all, > > A few days ago I made a post here to gauge interest in adding idiom > brackets to GHC. Response was a bit more mixed than I was hoping, but no > one seemed to drastically against the idea, so I've moved forward with a > more detailed proposal. > > You can find the full proposal here: > > https://ocharles.org.uk/IdiomBrackets.html > > A particular difference in my proposal from existing solutions comes > from my desire to lift almost *all* expressions - with the original > syntax - into idiom brackets. This means normal function application and > tuples, but also case expressions, let bindings, record construction, > record update, infix notation, and so on. > > At first I was skeptical about this, but I am finding uses for this more > and more. I really like how it lets me use the interesting data (that > is, whatever is "under" the applicative functor) where it's most > relevant - rather than having to build a function and thread that value > back through. Examples of this can be seen in my proposal. > > To prove its use, I've been working with this Template Haskell > expression: > > https://ocharles.org.uk/IdiomExp.hs > > It *almost* does exactly what I want, the only problem is I can't get > Template Haskell to give me a difference between > > $(i [| const True False |]) > > and > > $(i [| (const True) False |]) > > which I was planning to be significant. > > The proposal has mostly grown into my own personal notebook, so I'm > happy to clarify anything that is vague/contradictory/confusing. > > Look forward to hearing your thoughts! > > -- Ollie > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From david.feuer at gmail.com Fri Feb 27 06:38:58 2015 From: david.feuer at gmail.com (David Feuer) Date: Fri, 27 Feb 2015 01:38:58 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: I am still struggling to understand why you want this to be a law for Foldable. It seems an interesting property of some Foldable instances, but, unlike Edward Kmett's proposed monoid morphism law, it's not clear to me how you can use this low to prove useful properties of programs. Could you explain? On Wed, Feb 25, 2015 at 5:40 PM, Gershom B wrote: > I think I can now float an amended law that is a further step in the right > direction. First I will give the law, and then I will attempt to both > motivate why the amended treatment is needed, and why the weakening of the > initial proposal is a legitimate approach. Finally, I will discuss some > remaining issues that it would be nice to examine, including some sketches > of related but alternate approaches. > > So, the new law: > > === > for a lawful Foldable f, and > > given a fresh newtype GenericSet = GenericSet Integer deriving (Eq, Ord), > and mkGenericSet = GenericSet, where GenericSet is otherwise fully abstract > > then > > forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet). maybe True > (`Foldable.elem` x) (g x) === True > == > > You may recall that the prior formulation asked that this condition hold for > all a., (x :: f a), and so required an external notion of equality. Here, we > ask that it only hold at a _specified type_ -- i.e. "GenericSet". > > So, in what sense was the older formulation "too strong"? Here is a minimal > case. > > data TBox a where > TAny :: a -> TBox a > TString :: String -> TBox String > > TBox is just a box with some optional type information, and it should be > able to be equipped with the obvious Foldable instance. However, we can now > write a function such as > > discrim :: forall a. TBox a -> Maybe a > discrim (TAny x) = Just x > discrim (TString _) = "zoinks" > > This is to say that if we _know_ that TBox contains a string, we can now > take _any_ string out of it. Clearly, the existence of such functions means > that the obvious Foldable instance cannot satisfy the stronger law. > > By contrast, the straightforward Foldable instance for TBox still satisfies > the weaker law, as we only test the action on "GenericSet" -- and since we > have defined GenericSet as a fresh newtype, we know that it cannot have a > tag to be matched on within a GADT we have already defined. Hence, our law, > though it gives a universal property, does not give this property itself > "universally" _at every type a_ but rather at a "generic type". This is by > analogy with the technique of using "generic points" in algebraic geometry > [1] to give properties that are not "everywhere true" but instead are true > "almost everywhere", with a precise meaning given to "almost" -- i.e. that > the space for which they do not hold _vanishes_. > > This is to say, a Foldable satisfying the proposed law will not have the > property hold "at all types," but rather at "almost all types" for an > analogously precise meaning of "almost". I believe that a statement of why > GenericSet is indeed "generic" in some topological sense is possible, > although I have not fully fleshed this out. > > To my knowledge, the introduction of this sort of approach in an FP context > is new, but I would welcome any references showing prior art. > > Aside from dealing with GADTs in some fashion, the new approach has a few > other useful features. First, by formulating things directly in terms of > "Foldable.elem" we omit the need for some sort of notion of equality in the > metalogic -- instead we can use the "Eq" typeclass directly. Furthermore, > this happens to sidestep the "toList" problem in the initial approach -- it > directly allows search of potentially infinite structures. > > There are still a few things that could potentially be better. > > 1) The "fully internal" approach means that we are now subject to the "bias" > of "||" -- that is to say that _|_ || True -> _|_, but True || _|_ -> True. > So we do not fully capture the searchability of infinite structures. This > may indicate that a retreat to a metalogical description of "elem" with > unbiased "or" is in order. > > 2) While we can generically characterize a Foldable instance on some f > "almost everywhere" this is at the cost of giving it _no_ characterization > at the points where our generic characterization fails. It would be nice to > establish some sort of relation between the generic characterization and the > action at specified points. However, I am not quite sure how to present > this. An alternate approach could be to specify a Foldable law for any `f` > that first takes `f` (which may be a GADT) to a related type `f1` (which > must be an ordinary ADT) that squashes or omits dictionaries and equality > constraints, and likewise takes the Foldable instance to a related instance > on f1, and then provides a condition on f1. So rather that retreating from > universal to generic properties, we instead take hold of the machinery of > logical relations directly to establish a law. I would be interested in > being pointed to related work along these lines as well. > > 3) An additional drawback of the "Generic Point" approach as given is that > we chose to derive only two particular typeclasses -- Eq and Ord. An > alternate approach would be to quantify over all a, but then give the > property in terms of say "newtype Generify a = Generify a deriving (...)" > which derives all classes on "a" that do not feature "a" in a positive > position. Doing this would also mean a retreat from a fully internal notion > of equality, of course... > > Anyway, this is clearly still work in progress, but I would appreciate any > feedback on the direction this is going, or references that may seem useful. > > Cheers, > Gershom > > [1] https://en.wikipedia.org/wiki/Generic_point > > On Thu, Feb 12, 2015 at 6:33 PM, Edward Kmett wrote: >> >> With Foldable we do have a very nice law around foldMap. >> >> A monoid homomorphism g is a combinator such that >> >> g mempty = mempty >> g (mappend a b) = mappend (g a) (mappend (g b) >> >> For any monoid homomorphism g, >> >> foldMap (g . f) = g . foldMap f >> >> We can use that to construct proofs of an analogue to "the banana split >> theorem" for foldr, but rephrased in terms of foldMap: >> >> foldMap f &&& foldMap g = foldMap (f &&& g) >> >> Getting there uses the fact that fst and snd are both monoid >> homomorphisms. >> >> There are also laws relating the behavior of all of the other combinators >> in Foldable to foldMap. >> >> Ultimately the reasons for the other members of the class are a sop to >> efficiency concerns: asymptotic factors in terms of time or stack usage >> matter. >> >> -Edward >> >> >> On Thu, Feb 12, 2015 at 5:22 PM, Kim-Ee Yeoh wrote: >>> >>> (removing Libraries, since not everyone on HC is on that list) >>> >>> I do not know all of the context of Foldable, but one I do know that's >>> not been mentioned is the implicit rule-of-thumb that every type class >>> should have a law. >>> >>> So the undercurrent is that if Foldable doesn't have a law, should it >>> even be a type class? This has led to efforts to uncover laws for Foldable. >>> >>> Worth discussing in a separate thread is the criterion itself of "if it >>> doesn't have a law, it's not a type class". Useful sometimes, but that's not >>> the sine qua non of type classes. >>> >>> >>> >>> -- Kim-Ee >>> >>> On Fri, Feb 13, 2015 at 2:47 AM, Gershom B wrote: >>>> >>>> For a long time, many people, including me, have said that "Foldable has >>>> no laws" (or Foldable only has free laws) -- this is true, as it stands, >>>> with the exception that Foldable has a non-free law in interaction with >>>> Traversable (namely that it act as a proper specialization of Traversable >>>> methods). However, I believe that there is a good law we can give for >>>> Foldable. >>>> >>>> I earlier explored this in a paper presented at IFL 2014 but >>>> (rightfully) rejected from the IFL post-proceedings. >>>> (http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of the >>>> way there, but I believe now have a better approach on the question of a >>>> Foldable law -- as sketched below. >>>> >>>> I think I now (unlike in the paper) can state a succinct law for >>>> Foldable that has desired properties: 1) It is not "free" -- it can be >>>> violated, and thus stating it adds semantic content. 2) We typically expect >>>> it to be true. 3) There are no places where I can see an argument for >>>> violating it. >>>> >>>> If it pans out, I intend to pursue this and write it up more formally, >>>> but given the current FTP discussion I thought it was worth documenting this >>>> earlier rather than later. For simplicity, I will state this property in >>>> terms of `toList` although that does not properly capture the infinite >>>> cases. Apologies for what may be nonstandard notation. >>>> >>>> Here is the law I think we should discuss requiring: >>>> >>>> * * * >>>> Given Foldable f, then >>>> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a >>>> --> a `elem` toList x >>>> * * * >>>> >>>> Since we do not require `a` to be of type `Eq`, note that the `elem` >>>> function given here is not internal to Haskell, but in the metalogic. >>>> >>>> Furthermore, note that the use of parametricity here lets us make an >>>> "end run" around the usual problem of giving laws to Foldable -- rather than >>>> providing an interaction with another class, we provide a claim about _all_ >>>> functions of a particular type. >>>> >>>> Also note that the functions `g` we intend to quantify over are >>>> functions that _can be written_ -- so we can respect the property of data >>>> structures to abstract over information. Consider >>>> >>>> data Funny a = Funny {hidden :: a, public :: [a]} >>>> >>>> instance Foldable Funny where >>>> foldMap f x = foldMap f (public x) >>>> >>>> Now, if it is truly impossible to ever "see" hidden (i.e. it is not >>>> exported, or only exported through a semantics-breaking "Internal" module), >>>> then the Foldable instance is legitimate. Otherwise, the Foldable instance >>>> is illegitimate by the law given above. >>>> >>>> I would suggest the law given is "morally" the right thing for Foldable >>>> -- a Foldable instance for `f` should suggest that it gives us "all the as >>>> in any `f a`", and so it is, in some particular restricted sense, initial >>>> among functions that extract as. >>>> >>>> I do not suggest we add this law right away. However, I would like to >>>> suggest considering it, and I believe it (or a cleaned-up variant) would >>>> help us to see Foldable as a more legitimately lawful class that not only >>>> provides conveniences but can be used to aid reasoning. >>>> >>>> Relating this to adjointness, as I do in the IFL preprint, remains >>>> future work. >>>> >>>> Cheers, >>>> Gershom >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From ollie at ocharles.org.uk Fri Feb 27 07:58:48 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 27 Feb 2015 07:58:48 +0000 Subject: [Haskell-cafe] Idiom Brackets for GHC (first full proposal) In-Reply-To: <54EFAC0C.7050501@ro-che.info> References: <8761aoxu4c.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> <54EFAC0C.7050501@ro-che.info> Message-ID: So you would argue that these should desugar to the same thing? I'm on the fence - on the one hand its nice to be able to leave a few 'pure's out, but on the other those parenthesis have no syntactic meaning before, so it's questionable why they suddenly do inside idiom brackets. I can live with needing a few more 'pure's though. - Ollie On 26 Feb 2015 23:28, "Roman Cheplyaka" wrote: > I'm starting to like this. Except the weird difference between spaces on > different levels that you point out, i.e. > > [| const True False |] > > vs > > [| (const True) False |] > > > > > On 26/02/15 23:04, Oliver Charles wrote: > > Hi all, > > > > A few days ago I made a post here to gauge interest in adding idiom > > brackets to GHC. Response was a bit more mixed than I was hoping, but no > > one seemed to drastically against the idea, so I've moved forward with a > > more detailed proposal. > > > > You can find the full proposal here: > > > > https://ocharles.org.uk/IdiomBrackets.html > > > > A particular difference in my proposal from existing solutions comes > > from my desire to lift almost *all* expressions - with the original > > syntax - into idiom brackets. This means normal function application and > > tuples, but also case expressions, let bindings, record construction, > > record update, infix notation, and so on. > > > > At first I was skeptical about this, but I am finding uses for this more > > and more. I really like how it lets me use the interesting data (that > > is, whatever is "under" the applicative functor) where it's most > > relevant - rather than having to build a function and thread that value > > back through. Examples of this can be seen in my proposal. > > > > To prove its use, I've been working with this Template Haskell > > expression: > > > > https://ocharles.org.uk/IdiomExp.hs > > > > It *almost* does exactly what I want, the only problem is I can't get > > Template Haskell to give me a difference between > > > > $(i [| const True False |]) > > > > and > > > > $(i [| (const True) False |]) > > > > which I was planning to be significant. > > > > The proposal has mostly grown into my own personal notebook, so I'm > > happy to clarify anything that is vague/contradictory/confusing. > > > > Look forward to hearing your thoughts! > > > > -- Ollie > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri Feb 27 10:09:27 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 27 Feb 2015 12:09:27 +0200 Subject: [Haskell-cafe] Idiom Brackets for GHC (first full proposal) In-Reply-To: References: <8761aoxu4c.fsf@nixos.i-did-not-set--mail-host-address--so-tickle-me> <54EFAC0C.7050501@ro-che.info> Message-ID: <54F04257.5000802@ro-che.info> On 27/02/15 09:58, Oliver Charles wrote: > So you would argue that these should desugar to the same thing? I guess I'm talking more generally here. On the one hand, I find this practical and convenient. On the other hand, it (almost by design) breaks our usual intuition of how the space works. E.g. in most other cases id x is the same as x, but inside idiom brackets they mean x and pure x, respectively. I don't have a specific suggestion, just a concern. > I'm on > the fence - on the one hand its nice to be able to leave a few 'pure's > out, but on the other those parenthesis have no syntactic meaning > before, so it's questionable why they suddenly do inside idiom brackets. > > I can live with needing a few more 'pure's though. > > - Ollie > > On 26 Feb 2015 23:28, "Roman Cheplyaka" > wrote: > > I'm starting to like this. Except the weird difference between spaces on > different levels that you point out, i.e. > > [| const True False |] > > vs > > [| (const True) False |] > > > > > On 26/02/15 23:04, Oliver Charles wrote: > > Hi all, > > > > A few days ago I made a post here to gauge interest in adding idiom > > brackets to GHC. Response was a bit more mixed than I was hoping, > but no > > one seemed to drastically against the idea, so I've moved forward > with a > > more detailed proposal. > > > > You can find the full proposal here: > > > > https://ocharles.org.uk/IdiomBrackets.html > > > > A particular difference in my proposal from existing solutions comes > > from my desire to lift almost *all* expressions - with the original > > syntax - into idiom brackets. This means normal function > application and > > tuples, but also case expressions, let bindings, record construction, > > record update, infix notation, and so on. > > > > At first I was skeptical about this, but I am finding uses for > this more > > and more. I really like how it lets me use the interesting data (that > > is, whatever is "under" the applicative functor) where it's most > > relevant - rather than having to build a function and thread that > value > > back through. Examples of this can be seen in my proposal. > > > > To prove its use, I've been working with this Template Haskell > > expression: > > > > https://ocharles.org.uk/IdiomExp.hs > > > > It *almost* does exactly what I want, the only problem is I can't get > > Template Haskell to give me a difference between > > > > $(i [| const True False |]) > > > > and > > > > $(i [| (const True) False |]) > > > > which I was planning to be significant. > > > > The proposal has mostly grown into my own personal notebook, so I'm > > happy to clarify anything that is vague/contradictory/confusing. > > > > Look forward to hearing your thoughts! > > > > -- Ollie > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Feb 27 10:45:43 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 27 Feb 2015 10:45:43 +0000 Subject: [Haskell-cafe] Kind synonyms Message-ID: <20150227104543.GN32112@weber> Is there an extension that will allow me to do type T = (*, *) so I can replace type family F (k :: (*, *)) with type family F (k :: T) ? Tom From jan.stolarek at p.lodz.pl Fri Feb 27 10:54:36 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Fri, 27 Feb 2015 11:54:36 +0100 Subject: [Haskell-cafe] Kind synonyms In-Reply-To: <20150227104543.GN32112@weber> References: <20150227104543.GN32112@weber> Message-ID: <201502271154.36490.jan.stolarek@p.lodz.pl> > Is there an extension that will allow me to do No. See https://ghc.haskell.org/trac/ghc/ticket/9632 Janek --- Politechnika ????dzka Lodz University of Technology Tre???? tej wiadomo??ci zawiera informacje przeznaczone tylko dla adresata. Je??eli nie jeste??cie Pa??stwo jej adresatem, b? d?? otrzymali??cie j? przez pomy??k?? prosimy o powiadomienie o tym nadawcy oraz trwa??e jej usuni??cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From o.klinke at dkfz-heidelberg.de Fri Feb 27 16:43:34 2015 From: o.klinke at dkfz-heidelberg.de (Dr. Olaf Klinke) Date: Fri, 27 Feb 2015 17:43:34 +0100 (CET) Subject: [Haskell-cafe] Free monoids in Haskell Message-ID: Dear Dan, you posted an entry on the Comonad.Reader blog about free monoids in Haskell. I commented about FM being a monad, and meanwhile verified that indeed every monoid is an FM-algebra. The proofs are analogous to proving that the continuation (_ -> r) -> r for fixed r is a monad and that r is an algebra for it, respectively. Moreover, the FM-algebra stucture is a monoid homomorphism w.r.t. the monoid instance you gave for (FM a). I'd like to ask what happens when one omits the Monoid constraint. That is, what are the elements of newtype Y a = Y { runY :: forall b. (a -> b) -> b } (Y a) is like (Control.ForFree.Yoneda Identity a), that is, elements of (Y a) should be natural transformations from the reader functor ((->) a) to the identity functor. If that is true, then the Yoneda lemma tells us that (Y a) is isomorphic to (Identity a), but at least operationally that seems not to be the case: u = runY (return undefined) has different semantics than u' = runY (Y undefined) as can be seen by applying both to const (). So return does not map ? to (Y ?). I wonder whether one can exhibit other elements not equal to any return(x). Of course (Identity a) is actually the lifted a, since ??I dentiyt ?. Yet this does not serve as an explanation for u vs. u', as both u and u' are of the form (Y _), but one function evaluates its argument while the other does not. Olaf From dan.doel at gmail.com Fri Feb 27 18:17:09 2015 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 27 Feb 2015 13:17:09 -0500 Subject: [Haskell-cafe] Free monoids in Haskell In-Reply-To: References: Message-ID: Well, the answer is 'supposed' to be that Y is the identity monad. It might not quite work out that way due to bottoms, though. Lots of stuff doesn't work out in Haskell for that reason. In fact, it doesn't even form a category because of the lifted function space: id . _|_ = \x -> id (_|_ x) = (\x -> _|_) /= _|_ This inequality is detectable by seq. In the identity case, it is actually not true that the Identity commonly used in Haskell is lifted, because it is defined with a newtype, and so: _|_ = Identity _|_ holds. You can check this with seq as well. Both ((undefined :: Identity Int) `seq` ()) and ((Identity undefined :: Identity Int) `seq` ()) are undefined. However, I think (removing seq from the equation) Y is actually be equivalent to the lifted identity monad (or, it's probably not correct to call it the "identity monad," but whatever its proper name is). Presumably the isomorphism would go: data Z a = Z a toZ :: Y a -> Z a toZ (Y e) = e Z toY :: Z a -> Y a toY (Z x) = Y $ \k -> k x Note that Y is also defined with newtype, so there is no lifting involved except for the function space itself being lifted. And some equations to consider: toZ _|_ = _|_ Z = _|_ toY _|_ = _|_ -- because of the pattern match toY (toZ _|_) = _|_ toZ (toY _|_) = _|_ toY (Z _|_) = Y $ \k -> k _|_ toZ (Y $ \k -> k _|_) = Z _|_ toZ (toY (Z _|_)) = Z _|_ toY (toZ (return _|_)) = return _|_ So this looks promising. The monkey wrench comes in when we consider: Y $ \_ -> _|_ because: toZ (Y $ \_ -> _|_) = (\_ -> _|_) Z = _|_ toY (toZ (Y $ \_ -> _|_)) = _|_ And as mentioned before, seq can detect this difference. However, seq is the only way to detect this difference, as far as I know. So if seq on functions were given a semantics that didn't distinguish `undefined` from `const undefined` (which would make 'the category of Haskell types and functions' an actual category), then it seems quite likely that Y would be properly isomorphic to Z. This is a rather expected result, too, because Y is how we Church (or Boehm-Berarducci) encode things. And taking laziness and bottoms into account, it's not surprising that it is the encoding of the lifted definition Z instead of the unlifted definition Identity. Hope that helps some. -- Dan On Fri, Feb 27, 2015 at 11:43 AM, Dr. Olaf Klinke < o.klinke at dkfz-heidelberg.de> wrote: > Dear Dan, > > you posted an entry on the Comonad.Reader blog about free monoids in > Haskell. I commented about FM being a monad, and meanwhile verified that > indeed every monoid is an FM-algebra. The proofs are analogous to proving > that the continuation (_ -> r) -> r for fixed r is a monad and that r is an > algebra for it, respectively. Moreover, the FM-algebra stucture is a monoid > homomorphism w.r.t. the monoid instance you gave for (FM a). > > I'd like to ask what happens when one omits the Monoid constraint. That > is, what are the elements of > > newtype Y a = Y { runY :: forall b. (a -> b) -> b } > > (Y a) is like (Control.ForFree.Yoneda Identity a), that is, elements of (Y > a) should be natural transformations from the reader functor ((->) a) to > the identity functor. If that is true, then the Yoneda lemma tells us that > (Y a) is isomorphic to (Identity a), but at least operationally that seems > not to be the case: > u = runY (return undefined) > has different semantics than > u' = runY (Y undefined) as can be seen by applying both to const > (). So return does not map ? to (Y ?). I wonder whether one can exhibit > other elements not equal to any return(x). Of course (Identity a) is > actually the lifted a, since > ??I dentiyt ?. > Yet this does not serve as an explanation for u vs. u', as both u and u' > are of the form (Y _), but one function evaluates its argument while the > other does not. > > Olaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan at evanrutledgeborden.dreamhosters.com Fri Feb 27 18:23:45 2015 From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com) Date: Fri, 27 Feb 2015 13:23:45 -0500 Subject: [Haskell-cafe] Skolems! Message-ID: An extension of the message Tom sent a little while back, we've discovered a more in depth example of this possible GHC bug. It is exacerbated by GADTs, but can be fixed with NoMonoLocalBinds. Without GADTs and just leveraging ExistentialQuanitification it works fine. We've included a pretty exhaustive set of examples. {-# LANGUAGE ExistentialQuantification, GADTs #-} {- removing MonoLocalBinds fixes all of these errors {-# LANGUAGE ExistentialQuantification, GADTs, NoMonoLocalBinds #-} -} module PossibleGHCBug where data SumType = SumFoo | SumBar class SomeClass a where someType :: a -> SumType data SomeExistential = forall a. SomeClass a => SomeExistential a noError :: String -> [SomeExistential] -> String noError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" noError2 :: String -> [SomeExistential] -> String noError2 n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c :: SumType -> String c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n noError3 :: String -> [SomeExistential] -> String noError3 n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d :: SomeClass a => a -> String d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n partialTypedError :: String -> [SomeExistential] -> String partialTypedError n st = n ++ concatMap cname st where cname :: SomeExistential -> String cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n fullError :: String -> [SomeExistential] -> String fullError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n justNError :: String -> [SomeExistential] -> String justNError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> n ignoreNError :: String -> [SomeExistential] -> String ignoreNError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> fst ("foo", n) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Fri Feb 27 19:17:37 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 27 Feb 2015 14:17:37 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: On February 27, 2015 at 1:39:10 AM, David Feuer (david.feuer at gmail.com) wrote: > I am still struggling to understand why you want this to be a law for > Foldable. It seems an interesting property of some Foldable instances, > but, unlike Edward Kmett's proposed monoid morphism law, it's not > clear to me how you can use this low to prove useful properties of > programs. Could you explain? I think there are a number of purposes for laws. Some can be thought of as ?suggested rewrite rules? ? and the monoid morphism law is one such, as are many related free approaches. Note that the monoid morphism law that Edward provides is _not_ a ?proposed? law ? it is an ?almost free theorem? ? given a monoid morphism, it follows for free for any Foldable. There is no possible foldable instance that can violate this law, assuming you have an actual monoid morphism. So Edward may have proposed adding it to the documentation (which makes sense to me) ? but it provides absolutely no guidance or constraints as to what an ?allowable? instance of Foldable is or is not. But there are other reasons for laws than just to provide rewrite rules, even though it is often desirable to express laws in such terms. Consider the first Functor law for example ? fmap id === id. Now clearly we can use it to go eliminate a bunch of ?fmap id? calls in our program, should we have had them. But when would that ever be the case? Instead, the law is important because it _restricts_ the range of allowable instances ? and so if you know you have a data type, and you know it has a functor instance, you then know what that functor instance must do, without looking at the source code. In ?An Investigation of the Laws of Traversals? from where we get our current Traversable laws, for example,?Jaskelioff and Rypacek explain their motivation as establishing coherence laws that ?capture the intuition of traversals? and rule out ?bad? traversals (i.e. ones that violate our intuition). That?s the sort of goal I?m after ? something that rules out ?obviously bad? Foldable instances and lets us know something about the instances provided on structures without necessarily needing to read the code of those instances ? and beyond what we can learn ?for free? from the type. Let me give an example. If you had a structure that represented a sequence of ?a?, and you discovered that its Foldable instance only folded over the second, fifth, and seventeenth elements and no others ? you would, I expect, find this to be a surprising result. You might even say ?well, that?s a stupid Foldable instance?. However, outside of your gut feeling that this didn?t make sense, there would be no even semi-formal way to say it was ?wrong?. Under a law such as I am trying to drive towards, we would be able to rule out such instances, just as our traversable laws now let us rule out instances that e.g. drop elements from the resultant structure. Hence, if you saw such a structure, and saw it had a Foldable instance, you would now know something useful about the behavior of that instance, without having to examine the implementation of Foldable ? one of those useful things being, for example, that it could not possibly, lawfully, only fold over the fifth and seventeenth elements contained but no others. (Now how to specify such a law that permits the _maximum_ amount of useful information while also permitting the _maximum_ number of instances that ?match our intuition? is what my last post was driving at ? I think I am closer, but certainly there remains work to be done). In fact, we should note that when a Foldable is also Traversable, we do have a law specifying how the two typeclasses cohere, and because Traversable _does_ have strong laws, this _does_ suffice to well characterize Foldable in such a case. One nice property of the sort of law I have been driving at is that it will _agree_ with the current characterization in that same circumstance ? when Foldable and Traversable instances both exist ? and it will allow us to extend _those same intuitions_ in a formal way to circumstances when, for whatever reason, a Traversable instance does _not_ exist. I hope this helps explain what I?m up to? Cheers, Gershom > > On Wed, Feb 25, 2015 at 5:40 PM, Gershom B wrote: > > I think I can now float an amended law that is a further step in the right > > direction. First I will give the law, and then I will attempt to both > > motivate why the amended treatment is needed, and why the weakening of the > > initial proposal is a legitimate approach. Finally, I will discuss some > > remaining issues that it would be nice to examine, including some sketches > > of related but alternate approaches. > > > > So, the new law: > > > > === > > for a lawful Foldable f, and > > > > given a fresh newtype GenericSet = GenericSet Integer deriving (Eq, Ord), > > and mkGenericSet = GenericSet, where GenericSet is otherwise fully abstract > > > > then > > > > forall (g :: forall a. f a -> Maybe a), (x :: f GenericSet). maybe True > > (`Foldable.elem` x) (g x) === True > > == > > > > You may recall that the prior formulation asked that this condition hold for > > all a., (x :: f a), and so required an external notion of equality. Here, we > > ask that it only hold at a _specified type_ -- i.e. "GenericSet". > > > > So, in what sense was the older formulation "too strong"? Here is a minimal > > case. > > > > data TBox a where > > TAny :: a -> TBox a > > TString :: String -> TBox String > > > > TBox is just a box with some optional type information, and it should be > > able to be equipped with the obvious Foldable instance. However, we can now > > write a function such as > > > > discrim :: forall a. TBox a -> Maybe a > > discrim (TAny x) = Just x > > discrim (TString _) = "zoinks" > > > > This is to say that if we _know_ that TBox contains a string, we can now > > take _any_ string out of it. Clearly, the existence of such functions means > > that the obvious Foldable instance cannot satisfy the stronger law. > > > > By contrast, the straightforward Foldable instance for TBox still satisfies > > the weaker law, as we only test the action on "GenericSet" -- and since we > > have defined GenericSet as a fresh newtype, we know that it cannot have a > > tag to be matched on within a GADT we have already defined. Hence, our law, > > though it gives a universal property, does not give this property itself > > "universally" _at every type a_ but rather at a "generic type". This is by > > analogy with the technique of using "generic points" in algebraic geometry > > [1] to give properties that are not "everywhere true" but instead are true > > "almost everywhere", with a precise meaning given to "almost" -- i.e. that > > the space for which they do not hold _vanishes_. > > > > This is to say, a Foldable satisfying the proposed law will not have the > > property hold "at all types," but rather at "almost all types" for an > > analogously precise meaning of "almost". I believe that a statement of why > > GenericSet is indeed "generic" in some topological sense is possible, > > although I have not fully fleshed this out. > > > > To my knowledge, the introduction of this sort of approach in an FP context > > is new, but I would welcome any references showing prior art. > > > > Aside from dealing with GADTs in some fashion, the new approach has a few > > other useful features. First, by formulating things directly in terms of > > "Foldable.elem" we omit the need for some sort of notion of equality in the > > metalogic -- instead we can use the "Eq" typeclass directly. Furthermore, > > this happens to sidestep the "toList" problem in the initial approach -- it > > directly allows search of potentially infinite structures. > > > > There are still a few things that could potentially be better. > > > > 1) The "fully internal" approach means that we are now subject to the "bias" > > of "||" -- that is to say that _|_ || True -> _|_, but True || _|_ -> True. > > So we do not fully capture the searchability of infinite structures. This > > may indicate that a retreat to a metalogical description of "elem" with > > unbiased "or" is in order. > > > > 2) While we can generically characterize a Foldable instance on some f > > "almost everywhere" this is at the cost of giving it _no_ characterization > > at the points where our generic characterization fails. It would be nice to > > establish some sort of relation between the generic characterization and the > > action at specified points. However, I am not quite sure how to present > > this. An alternate approach could be to specify a Foldable law for any `f` > > that first takes `f` (which may be a GADT) to a related type `f1` (which > > must be an ordinary ADT) that squashes or omits dictionaries and equality > > constraints, and likewise takes the Foldable instance to a related instance > > on f1, and then provides a condition on f1. So rather that retreating from > > universal to generic properties, we instead take hold of the machinery of > > logical relations directly to establish a law. I would be interested in > > being pointed to related work along these lines as well. > > > > 3) An additional drawback of the "Generic Point" approach as given is that > > we chose to derive only two particular typeclasses -- Eq and Ord. An > > alternate approach would be to quantify over all a, but then give the > > property in terms of say "newtype Generify a = Generify a deriving (...)" > > which derives all classes on "a" that do not feature "a" in a positive > > position. Doing this would also mean a retreat from a fully internal notion > > of equality, of course... > > > > Anyway, this is clearly still work in progress, but I would appreciate any > > feedback on the direction this is going, or references that may seem useful. > > > > Cheers, > > Gershom > > > > [1] https://en.wikipedia.org/wiki/Generic_point > > > > On Thu, Feb 12, 2015 at 6:33 PM, Edward Kmett wrote: > >> > >> With Foldable we do have a very nice law around foldMap. > >> > >> A monoid homomorphism g is a combinator such that > >> > >> g mempty = mempty > >> g (mappend a b) = mappend (g a) (mappend (g b) > >> > >> For any monoid homomorphism g, > >> > >> foldMap (g . f) = g . foldMap f > >> > >> We can use that to construct proofs of an analogue to "the banana split > >> theorem" for foldr, but rephrased in terms of foldMap: > >> > >> foldMap f &&& foldMap g = foldMap (f &&& g) > >> > >> Getting there uses the fact that fst and snd are both monoid > >> homomorphisms. > >> > >> There are also laws relating the behavior of all of the other combinators > >> in Foldable to foldMap. > >> > >> Ultimately the reasons for the other members of the class are a sop to > >> efficiency concerns: asymptotic factors in terms of time or stack usage > >> matter. > >> > >> -Edward > >> > >> > >> On Thu, Feb 12, 2015 at 5:22 PM, Kim-Ee Yeoh wrote: > >>> > >>> (removing Libraries, since not everyone on HC is on that list) > >>> > >>> I do not know all of the context of Foldable, but one I do know that's > >>> not been mentioned is the implicit rule-of-thumb that every type class > >>> should have a law. > >>> > >>> So the undercurrent is that if Foldable doesn't have a law, should it > >>> even be a type class? This has led to efforts to uncover laws for Foldable. > >>> > >>> Worth discussing in a separate thread is the criterion itself of "if it > >>> doesn't have a law, it's not a type class". Useful sometimes, but that's not > >>> the sine qua non of type classes. > >>> > >>> > >>> > >>> -- Kim-Ee > >>> > >>> On Fri, Feb 13, 2015 at 2:47 AM, Gershom B wrote: > >>>> > >>>> For a long time, many people, including me, have said that "Foldable has > >>>> no laws" (or Foldable only has free laws) -- this is true, as it stands, > >>>> with the exception that Foldable has a non-free law in interaction with > >>>> Traversable (namely that it act as a proper specialization of Traversable > >>>> methods). However, I believe that there is a good law we can give for > >>>> Foldable. > >>>> > >>>> I earlier explored this in a paper presented at IFL 2014 but > >>>> (rightfully) rejected from the IFL post-proceedings. > >>>> (http://gbaz.github.io/slides/buildable2014.pdf). That paper got part of > the > >>>> way there, but I believe now have a better approach on the question of a > >>>> Foldable law -- as sketched below. > >>>> > >>>> I think I now (unlike in the paper) can state a succinct law for > >>>> Foldable that has desired properties: 1) It is not "free" -- it can be > >>>> violated, and thus stating it adds semantic content. 2) We typically expect > >>>> it to be true. 3) There are no places where I can see an argument for > >>>> violating it. > >>>> > >>>> If it pans out, I intend to pursue this and write it up more formally, > >>>> but given the current FTP discussion I thought it was worth documenting this > >>>> earlier rather than later. For simplicity, I will state this property in > >>>> terms of `toList` although that does not properly capture the infinite > >>>> cases. Apologies for what may be nonstandard notation. > >>>> > >>>> Here is the law I think we should discuss requiring: > >>>> > >>>> * * * > >>>> Given Foldable f, then > >>>> forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a > >>>> --> a `elem` toList x > >>>> * * * > >>>> > >>>> Since we do not require `a` to be of type `Eq`, note that the `elem` > >>>> function given here is not internal to Haskell, but in the metalogic. > >>>> > >>>> Furthermore, note that the use of parametricity here lets us make an > >>>> "end run" around the usual problem of giving laws to Foldable -- rather than > >>>> providing an interaction with another class, we provide a claim about _all_ > >>>> functions of a particular type. > >>>> > >>>> Also note that the functions `g` we intend to quantify over are > >>>> functions that _can be written_ -- so we can respect the property of data > >>>> structures to abstract over information. Consider > >>>> > >>>> data Funny a = Funny {hidden :: a, public :: [a]} > >>>> > >>>> instance Foldable Funny where > >>>> foldMap f x = foldMap f (public x) > >>>> > >>>> Now, if it is truly impossible to ever "see" hidden (i.e. it is not > >>>> exported, or only exported through a semantics-breaking "Internal" module), > >>>> then the Foldable instance is legitimate. Otherwise, the Foldable instance > >>>> is illegitimate by the law given above. > >>>> > >>>> I would suggest the law given is "morally" the right thing for Foldable > >>>> -- a Foldable instance for `f` should suggest that it gives us "all the as > >>>> in any `f a`", and so it is, in some particular restricted sense, initial > >>>> among functions that extract as. > >>>> > >>>> I do not suggest we add this law right away. However, I would like to > >>>> suggest considering it, and I believe it (or a cleaned-up variant) would > >>>> help us to see Foldable as a more legitimately lawful class that not only > >>>> provides conveniences but can be used to aid reasoning. > >>>> > >>>> Relating this to adjointness, as I do in the IFL preprint, remains > >>>> future work. > >>>> > >>>> Cheers, > >>>> Gershom > >>>> > >>>> _______________________________________________ > >>>> Haskell-Cafe mailing list > >>>> Haskell-Cafe at haskell.org > >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://www.haskell.org/mailman/listinfo/haskell-cafe > >>> > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From chrisdone at gmail.com Fri Feb 27 19:32:51 2015 From: chrisdone at gmail.com (Christopher Done) Date: Fri, 27 Feb 2015 20:32:51 +0100 Subject: [Haskell-cafe] Full page Haskell 2010 report request Message-ID: Hi, has anyone managed to produce a single-page HTML export of the Haskell 2010 report? Here's one I made by munging together the multi-page one: https://www.haskell.org/report/mono/2010#x8-440003.12 (this link is currently unpublished on the home page). But it's incomplete due to link references and things. I'd like a proper output but in the interest of my mental health prefer not to touch LaTeX except by proxy through other poor souls. Anyone managed to do this? A full, linkable page (don't worry about the section/para links, I added them with a few lines of JS, I can do it again) is really conducive to discussion of Haskell's finer points. Ciao! From kc1956 at gmail.com Fri Feb 27 22:23:57 2015 From: kc1956 at gmail.com (KC) Date: Fri, 27 Feb 2015 14:23:57 -0800 Subject: [Haskell-cafe] Full page Haskell 2010 report request In-Reply-To: References: Message-ID: I'm missing the challenges Can't Haskell parse multiple HTML pages into one? Semi-easily? -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Feb 27, 2015 11:33 AM, "Christopher Done" wrote: > Hi, has anyone managed to produce a single-page HTML export of the > Haskell 2010 report? > > Here's one I made by munging together the multi-page one: > https://www.haskell.org/report/mono/2010#x8-440003.12 (this link is > currently unpublished on the home page). > > But it's incomplete due to link references and things. I'd like a > proper output but in the interest of my mental health prefer not to > touch LaTeX except by proxy through other poor souls. > > Anyone managed to do this? A full, linkable page (don't worry about > the section/para links, I added them with a few lines of JS, I can do > it again) is really conducive to discussion of Haskell's finer points. > > Ciao! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From diaz.carrete at gmail.com Fri Feb 27 23:00:01 2015 From: diaz.carrete at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz?=) Date: Fri, 27 Feb 2015 15:00:01 -0800 (PST) Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: References: Message-ID: <06e128af-0094-47d0-b780-065f939adc3d@googlegroups.com> Hi, Sorry for the slight derail, but I wanted to ask the following doubt: if a Foldable type also happens to be a Monoid (say, like Set) does that automatically imply that toList mempty = [] ? On Friday, February 27, 2015 at 8:18:05 PM UTC+1, Gershom B wrote: > > On February 27, 2015 at 1:39:10 AM, David Feuer (david... at gmail.com > ) wrote: > > I am still struggling to understand why you want this to be a law for > > Foldable. It seems an interesting property of some Foldable instances, > > but, unlike Edward Kmett's proposed monoid morphism law, it's not > > clear to me how you can use this low to prove useful properties of > > programs. Could you explain? > > I think there are a number of purposes for laws. Some can be thought of as > ?suggested rewrite rules? ? and the monoid morphism law is one such, as are > many related free approaches. > > Note that the monoid morphism law that Edward provides is _not_ a > ?proposed? law ? it is an ?almost free theorem? ? given a monoid morphism, > it follows for free for any Foldable. There is no possible foldable > instance that can violate this law, assuming you have an actual monoid > morphism. > > So Edward may have proposed adding it to the documentation (which makes > sense to me) ? but it provides absolutely no guidance or constraints as to > what an ?allowable? instance of Foldable is or is not. > > But there are other reasons for laws than just to provide rewrite rules, > even though it is often desirable to express laws in such terms. Consider > the first Functor law for example ? fmap id === id. Now clearly we can use > it to go eliminate a bunch of ?fmap id? calls in our program, should we > have had them. But when would that ever be the case? Instead, the law is > important because it _restricts_ the range of allowable instances ? and so > if you know you have a data type, and you know it has a functor instance, > you then know what that functor instance must do, without looking at the > source code. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Fri Feb 27 23:18:56 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 27 Feb 2015 18:18:56 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: <06e128af-0094-47d0-b780-065f939adc3d@googlegroups.com> References: <06e128af-0094-47d0-b780-065f939adc3d@googlegroups.com> Message-ID: So consider. data Thing a = OneThing a instance Monoid a => Monoid (Thing a) where mempty = OneThing mempty? In this case, I think a) we can equip thing with a lawful ?mappend? in the obvious fashion. b) there is no reason to expect that `toList mempty = []` either with or without a law such as I?m looking for. Cheers, Gershom On February 27, 2015 at 6:00:07 PM, Daniel D?az (diaz.carrete at gmail.com) wrote: > Hi, > > Sorry for the slight derail, but I wanted to ask the following doubt: if a > Foldable type also happens to be a Monoid (say, like Set) does that > automatically imply that toList mempty = [] ? > > On Friday, February 27, 2015 at 8:18:05 PM UTC+1, Gershom B wrote: > > > > On February 27, 2015 at 1:39:10 AM, David Feuer (david... at gmail.com > > ) wrote: > > > I am still struggling to understand why you want this to be a law for > > > Foldable. It seems an interesting property of some Foldable instances, > > > but, unlike Edward Kmett's proposed monoid morphism law, it's not > > > clear to me how you can use this low to prove useful properties of > > > programs. Could you explain? > > > > I think there are a number of purposes for laws. Some can be thought of as > > ?suggested rewrite rules? ? and the monoid morphism law is one such, as are > > many related free approaches. > > > > Note that the monoid morphism law that Edward provides is _not_ a > > ?proposed? law ? it is an ?almost free theorem? ? given a monoid morphism, > > it follows for free for any Foldable. There is no possible foldable > > instance that can violate this law, assuming you have an actual monoid > > morphism. > > > > So Edward may have proposed adding it to the documentation (which makes > > sense to me) ? but it provides absolutely no guidance or constraints as to > > what an ?allowable? instance of Foldable is or is not. > > > > But there are other reasons for laws than just to provide rewrite rules, > > even though it is often desirable to express laws in such terms. Consider > > the first Functor law for example ? fmap id === id. Now clearly we can use > > it to go eliminate a bunch of ?fmap id? calls in our program, should we > > have had them. But when would that ever be the case? Instead, the law is > > important because it _restricts_ the range of allowable instances ? and so > > if you know you have a data type, and you know it has a functor instance, > > you then know what that functor instance must do, without looking at the > > source code. > > > > > >_______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From r.wobben at home.nl Sat Feb 28 08:40:31 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 28 Feb 2015 09:40:31 +0100 Subject: [Haskell-cafe] how to make this work recursive ? Message-ID: <54F17EFF.7010902@home.nl> Hello, I found out that for 1 item I can do this : node = Node leaf "msg 1" leaf And for 2 items I can do this : node = Node leaf "msg1" (Node leaf "msg2" leaf) But now I wonder how I can make this work with recursion. It seems that I keep the first 2 items and change the 3th one from leaf to another node Roelof From sumit.sahrawat.apm13 at iitbhu.ac.in Sat Feb 28 10:53:06 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Sat, 28 Feb 2015 16:23:06 +0530 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: <54F17EFF.7010902@home.nl> References: <54F17EFF.7010902@home.nl> Message-ID: Draw the trees, and then try to partition every node into (left, element, right). For example, in your first example (Node leaf "msg 1" leaf), we get Node "msg 1" ??? leaf ??? leaf In the second example, Node "msg 1" ??? leaf ??? Node "msg 2" -- A sub-tree ??? leaf ??? leaf Now, substituting a leaf with a Node in the above tree will lead to larger trees. For another example, look here: http://en.wikipedia.org/wiki/Tagged_union#Examples On 28 February 2015 at 14:10, Roelof Wobben wrote: > Hello, > > I found out that for 1 item I can do this : node = Node leaf "msg 1" leaf > And for 2 items I can do this : node = Node leaf "msg1" (Node leaf "msg2" > leaf) > > But now I wonder how I can make this work with recursion. It seems that I > keep the first 2 items and change the 3th one from leaf to another node > > Roelof > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 28 11:07:48 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 28 Feb 2015 12:07:48 +0100 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: References: <54F17EFF.7010902@home.nl> Message-ID: <54F1A184.8060800@home.nl> An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Sat Feb 28 11:16:33 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Sat, 28 Feb 2015 16:46:33 +0530 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: <54F1A184.8060800@home.nl> References: <54F17EFF.7010902@home.nl> <54F1A184.8060800@home.nl> Message-ID: First, consider the two possible cases, insert :: LogMessage -> MessageTree -> MessageTree insert m Leaf = Node Leaf m Leaf -- Inserting into an empty tree (base case for recursion) insert m (Node l m r) = undefined -- Try working it out here. You will need to decide where to insert the message in a way such that the properties of binary tree are not violated. If you can decided that at each recursive step and proceed accordingly, you will hit the base case soon enough. On 28 February 2015 at 16:37, Roelof Wobben wrote: > > That part I understand . > > it's more how I do it here : > > Lets say I have this : > > data MessageType = Info > | Warning > | Error Int > deriving (Show, Eq) > > type TimeStamp = Int > > data LogMessage = LogMessage MessageType TimeStamp String > | Unknown String > deriving (Show, Eq) > > data MessageTree = Leaf > | Node MessageTree LogMessage MessageTree > deriving (Show, Eq) > > Now I have to put all the LogMessages in a binary tree. > with this signature : insert :: LogMessage -> MessageTree -> MessageTree > > I think I need recursion here but I still not see how I can make the > clauses. > Normally you can say somethig like this [] -> 0 or 1 -> but here it > seems to be all seperate logMessages > > Roelof > > > > > > Sumit Sahrawat, Maths & Computing, IIT (BHU) schreef op 28-2-2015 om 11:53: > > Draw the trees, and then try to partition every node into (left, element, > right). > > For example, in your first example (Node leaf "msg 1" leaf), we get > > Node "msg 1" > ??? leaf > ??? leaf > > In the second example, > > Node "msg 1" > ??? leaf > ??? Node "msg 2" -- A sub-tree > ??? leaf > ??? leaf > > Now, substituting a leaf with a Node in the above tree will lead to > larger trees. > For another example, look here: > http://en.wikipedia.org/wiki/Tagged_union#Examples > > On 28 February 2015 at 14:10, Roelof Wobben wrote: > >> Hello, >> >> I found out that for 1 item I can do this : node = Node leaf "msg 1" leaf >> And for 2 items I can do this : node = Node leaf "msg1" (Node leaf >> "msg2" leaf) >> >> But now I wonder how I can make this work with recursion. It seems that I >> keep the first 2 items and change the 3th one from leaf to another node >> >> Roelof >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > Regards > > Sumit Sahrawat > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Sat Feb 28 11:17:37 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 28 Feb 2015 05:17:37 -0600 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: <54F1A184.8060800@home.nl> References: <54F17EFF.7010902@home.nl> <54F1A184.8060800@home.nl> Message-ID: On Sat, Feb 28, 2015 at 5:07 AM, Roelof Wobben wrote: > > That part I understand . > > it's more how I do it here : > > Lets say I have this : > > data MessageType = Info > | Warning > | Error Int > deriving (Show, Eq) > > type TimeStamp = Int > > data LogMessage = LogMessage MessageType TimeStamp String > | Unknown String > deriving (Show, Eq) > > data MessageTree = Leaf > | Node MessageTree LogMessage MessageTree > deriving (Show, Eq) > > Now I have to put all the LogMessages in a binary tree. > with this signature : insert :: LogMessage -> MessageTree -> MessageTree > > I think I need recursion here but I still not see how I can make the > clauses. > Normally you can say somethig like this [] -> 0 or 1 -> but here it > seems to be all seperate logMessages > Whether you need recursion or not depends on where you're to insert the message. For instance, you could turn them into a list with: insert message tree = Node tree message Leaf Try drawing a few pictures of what that produces, and you'll see why it's probably not what you want. You should be able to tell by looking at the MessageTree type that you have two cases: one where you're passed something matching a Node, and one where you're passed something that's just a Leaf. The latter can't be recursive, so it's going to terminate any recursion. Following the advice given to you for the Hanoi problem, try writing it first. Then all you have to do is figure out how to handle the case where you're given a Node instead of a Leaf. Figuring out where in the MessageTree you want to insert the Logmessage will probably be required to do that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bneijt at gmail.com Sat Feb 28 11:23:53 2015 From: bneijt at gmail.com (Bram Neijt) Date: Sat, 28 Feb 2015 12:23:53 +0100 Subject: [Haskell-cafe] What other prelude to cleanly convert text-files into json Message-ID: Dear reader, I wrote some tiny code to parse files into json (to automate escaping multi-line text). It quickly became a collection of "import qualified" and "T.unpack, T.pack" calls that made the whole thing look ugly [1]. What "alternative prelude" would help in getting clean code when combining "aeson" and reading text files? Greetings, Bram [1] Source can be read here: https://gist.github.com/bneijt/9bdb4b1759790a8463c9 From spam at scientician.net Sat Feb 28 13:24:58 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 28 Feb 2015 14:24:58 +0100 Subject: [Haskell-cafe] Would you use frozen-base In-Reply-To: <1424992057.13156.5.camel@joachim-breitner.de> References: <1424957771.1948.49.camel@joachim-breitner.de> <1424992057.13156.5.camel@joachim-breitner.de> Message-ID: On 27-02-2015 00:07, Joachim Breitner wrote: >> The proper solution to this problem (as with so many things) is another >> layer of indirection, namely a proper way to separate API and >> implementation. (Aka "Backpack" or similar.) > > But that is precisely what frozen-base is trying to provide ? just APIs, > no implementations. Note that it should merely re-export stuff from base > (or maybe base-compat or similar), and simply guarantee that the set of > exported functions of one particular module does not change any more. Indeed, but (usually) it's no good if you can see the layer of indirection :). From r.wobben at home.nl Sat Feb 28 13:39:48 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 28 Feb 2015 14:39:48 +0100 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: References: <54F17EFF.7010902@home.nl> <54F1A184.8060800@home.nl> Message-ID: <54F1C524.4060706@home.nl> An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Sat Feb 28 15:08:03 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Sat, 28 Feb 2015 20:38:03 +0530 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: <54F1C524.4060706@home.nl> References: <54F17EFF.7010902@home.nl> <54F1A184.8060800@home.nl> <54F1C524.4060706@home.nl> Message-ID: You're missing an argument to insert, assuming that it is indeed there, consider this: insert msg tree = tree' where tree' = undefined -- Take a LogMessage (msg) and a MessageTree (tree) -- and return a new MessageTree (tree') Therefore, the result of insert in your case, i.e. "MessageTree Leaf" should be of type MessageTree. And thus, we get MessageTree Leaf :: MessageTree -- Takes a (Leaf :: LogMessage) and produces a MessageTree which implies, MessageTree :: LogMessage -> MessageTree -- A Data constructor Obviously no such data constructor exists. A data constructor of this type would exist only if you wrote something like: data MessageTree = MessageTree LogMessage | ... which would not make sense. On 28 February 2015 at 19:09, Roelof Wobben wrote: > I tried this : > > insert :: LogMessage -> MessageTree -> MessageTree > insert s = > case words s of > (_:_: "This is not the right format") -> MessageTree Leaf > _ -> MessageTree Node > LogMessage Leaf > > > But I see this errormessages which I do not understand : > > > src/LogAnalysis.hs at 38:49-38:60 > Not in scope: data constructor > MessageTree > src/LogAnalysis.hs at 39:49-39:60 > Not in scope: data constructor > MessageTree > > > > Mike Meyer schreef op 28-2-2015 om 12:17: > > On Sat, Feb 28, 2015 at 5:07 AM, Roelof Wobben wrote: > >> >> That part I understand . >> >> it's more how I do it here : >> >> Lets say I have this : >> >> data MessageType = Info >> | Warning >> | Error Int >> deriving (Show, Eq) >> >> type TimeStamp = Int >> >> data LogMessage = LogMessage MessageType TimeStamp String >> | Unknown String >> deriving (Show, Eq) >> >> data MessageTree = Leaf >> | Node MessageTree LogMessage MessageTree >> deriving (Show, Eq) >> >> Now I have to put all the LogMessages in a binary tree. >> with this signature : insert :: LogMessage -> MessageTree -> MessageTree >> >> I think I need recursion here but I still not see how I can make the >> clauses. >> Normally you can say somethig like this [] -> 0 or 1 -> but here it >> seems to be all seperate logMessages >> > > Whether you need recursion or not depends on where you're to insert the > message. For instance, you could turn them into a list with: > > insert message tree = Node tree message Leaf > > Try drawing a few pictures of what that produces, and you'll see why > it's probably not what you want. > > You should be able to tell by looking at the MessageTree type that you > have two cases: one where you're passed something matching a Node, and one > where you're passed something that's just a Leaf. The latter can't be > recursive, so it's going to terminate any recursion. Following the advice > given to you for the Hanoi problem, try writing it first. > > Then all you have to do is figure out how to handle the case where > you're given a Node instead of a Leaf. Figuring out where in the > MessageTree you want to insert the Logmessage will probably be required to > do that. > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahammel87 at gmail.com Sat Feb 28 16:31:49 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Sat, 28 Feb 2015 08:31:49 -0800 Subject: [Haskell-cafe] Bounded STM Queues with load shedding In-Reply-To: References: Message-ID: Forwarding from Haskell-Beginners: Hi list, It would be handy for me to have a bounded STM Queue along the lines of TBQueue with the difference that when the queue is full, a call to writeTBQueue is a non-blocking no-op. This is in the context of an asynchronous logging system. If the load (somehow) gets heavy enough that the log message queue is taking up a lot of memory, It's better to lose a few log messages than to have processes block until the logger catches up. Are there any off-the-shelf solutions? Cheers, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Sat Feb 28 16:51:30 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 28 Feb 2015 19:51:30 +0300 Subject: [Haskell-cafe] Bounded STM Queues with load shedding In-Reply-To: References: Message-ID: <1425142290.3201.1.camel@gmail.com> On Sat, 2015-02-28 at 08:31 -0800, Alex Hammel wrote: > Forwarding from Haskell-Beginners: > > Hi list, > > It would be handy for me to have a bounded STM Queue along the lines of > TBQueue with the difference that when the queue is full, a call to > writeTBQueue is a non-blocking no-op. > > This is in the context of an asynchronous logging system. If the load > (somehow) gets heavy enough that the log message queue is taking up a lot > of memory, It's better to lose a few log messages than to have processes > block until the logger catches up. > > Are there any off-the-shelf solutions? You can try the stm-chans package: http://hackage.haskell.org/package/stm-chans-3.0.0.2/docs/Control-Concurrent-STM-TBMQueue.html#v:tryWriteTBMQueue Thanks, Yuras > > Cheers, > Alex > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From ahammel87 at gmail.com Sat Feb 28 16:56:37 2015 From: ahammel87 at gmail.com (Alex Hammel) Date: Sat, 28 Feb 2015 08:56:37 -0800 Subject: [Haskell-cafe] Bounded STM Queues with load shedding In-Reply-To: <1425142290.3201.1.camel@gmail.com> References: <1425142290.3201.1.camel@gmail.com> Message-ID: Perfect, thanks! On 28 Feb 2015 08:51, "Yuras Shumovich" wrote: > On Sat, 2015-02-28 at 08:31 -0800, Alex Hammel wrote: > > Forwarding from Haskell-Beginners: > > > > Hi list, > > > > It would be handy for me to have a bounded STM Queue along the lines of > > TBQueue with the difference that when the queue is full, a call to > > writeTBQueue is a non-blocking no-op. > > > > This is in the context of an asynchronous logging system. If the load > > (somehow) gets heavy enough that the log message queue is taking up a lot > > of memory, It's better to lose a few log messages than to have processes > > block until the logger catches up. > > > > Are there any off-the-shelf solutions? > > You can try the stm-chans package: > > http://hackage.haskell.org/package/stm-chans-3.0.0.2/docs/Control-Concurrent-STM-TBMQueue.html#v:tryWriteTBMQueue > > Thanks, > Yuras > > > > > Cheers, > > Alex > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sat Feb 28 17:02:02 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 28 Feb 2015 12:02:02 -0500 Subject: [Haskell-cafe] Skolems! In-Reply-To: References: Message-ID: The weirdest part of this to me is the very last line -- This typechecks: _ -> "bar" :: String But this complains about a (rigid, skolem) type (and "n" really is just a string): _ -> fst ("bar" :: String, n :: String) Tom El Feb 27, 2015, a las 13:23, "evan at evan-borden.com" escribi?: > An extension of the message Tom sent a little while back, we've discovered a more in depth example of this possible GHC bug. It is exacerbated by GADTs, but can be fixed with NoMonoLocalBinds. Without GADTs and just leveraging ExistentialQuanitification it works fine. We've included a pretty exhaustive set of examples. > > {-# LANGUAGE ExistentialQuantification, GADTs #-} > > {- removing MonoLocalBinds fixes all of these errors > {-# LANGUAGE ExistentialQuantification, GADTs, NoMonoLocalBinds #-} > -} > > module PossibleGHCBug where > > data SumType = SumFoo | SumBar > > class SomeClass a where > someType :: a -> SumType > > data SomeExistential = forall a. SomeClass a => SomeExistential a > > noError :: String -> [SomeExistential] -> String > noError n st = n ++ concatMap cname st > where cname (SomeExistential p) = d p > > d p = c $ someType p > > c p = case p of > SumFoo -> "foo" > _ -> "asdf" > > noError2 :: String -> [SomeExistential] -> String > noError2 n st = n ++ concatMap cname st > where cname (SomeExistential p) = d p > > d p = c $ someType p > > c :: SumType -> String > c p = case p of > SumFoo -> "foo" > _ -> "asdf" ++ n > > noError3 :: String -> [SomeExistential] -> String > noError3 n st = n ++ concatMap cname st > where cname (SomeExistential p) = d p > > d :: SomeClass a => a -> String > d p = c $ someType p > > c p = case p of > SumFoo -> "foo" > _ -> "asdf" ++ n > > > partialTypedError :: String -> [SomeExistential] -> String > partialTypedError n st = n ++ concatMap cname st > where cname :: SomeExistential -> String > cname (SomeExistential p) = d p > > d p = c $ someType p > > c p = case p of > SumFoo -> "foo" > _ -> "asdf" ++ n > > fullError :: String -> [SomeExistential] -> String > fullError n st = n ++ concatMap cname st > where cname (SomeExistential p) = d p > > d p = c $ someType p > > c p = case p of > SumFoo -> "foo" > _ -> "asdf" ++ n > > justNError :: String -> [SomeExistential] -> String > justNError n st = n ++ concatMap cname st > where cname (SomeExistential p) = d p > > d p = c $ someType p > > c p = case p of > SumFoo -> "foo" > _ -> n > > ignoreNError :: String -> [SomeExistential] -> String > ignoreNError n st = n ++ concatMap cname st > where cname (SomeExistential p) = d p > > d p = c $ someType p > > c p = case p of > SumFoo -> "foo" > _ -> fst ("foo", n) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From fr33domlover at riseup.net Sat Feb 28 17:27:16 2015 From: fr33domlover at riseup.net (fr33domlover) Date: Sat, 28 Feb 2015 19:27:16 +0200 Subject: [Haskell-cafe] Hackage and Free Software Message-ID: Hello haskellers! I would like to make a proposal regarding the license of software in Hackage. One of the major parts of the Haskell community infrastructure in the package database server Hackage. As far as I know - please correct me if I'm wrong - Hackage makes no restriction on the license of packages upload to it. But as a community working in cooperation to make good software, the Haskell community has embraced licenses like (L)GPL, MIT and BSD, which are free software licenses. Actually the all-rights-reserved tag in Hackage [1] has only two packages tagged by it - the dummy no-op project HNop, and another package whose COPYING file contains a broken link and whose README says "BSD style license". Software freedom is an ethical basis for collaboration on making software that's truly good and loayl to its users, and providing them control and freedom to access and use their computing resources. It seems to me that the Haskell community is already enbracing this ethical basis, but Hackage doesn't provide any guarantees and it means that you'd have to check each package to be sure. By having that all-rights-reserved tag it also in a way welcomes software that doesn't go by these rules - however it seems that no packages do that even in the presence of the possibility. I'd like to make a suggestion: have Hackage accept only packages released under free software licenses. This is probably true for most/all packages there, but making it official will both send a strong message to and from the community, and provide people with the security and peace of mind, knowing their software is free as in freedom. It is also possible that companies use Haskell to create proprietary software using permissive-licensed libraries and tools from Hackage. I hope this isn't true, but even if it is, this software isn't offered by Hackage and I hope its existence doesn't affect the community's use of Hackage and free software. Would you consider to embrace free software officially, including in Hackage? Thanks for reading, waiting to hear from the community and from haskell.org maintainers, fr33domlover [1] http://hackage.haskell.org/packages/tag/all-rights-reserved --- fr33domlover GPG key ID: 63E5E57D (size: 4096) GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From clintonmead at gmail.com Sat Feb 28 17:28:41 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 1 Mar 2015 04:28:41 +1100 Subject: [Haskell-cafe] Parallel numeric class hierarchy Message-ID: Let's say for arguments sake I want to make a new finer grained numeric class hierarchy. But, I also want to have the following occur: (1) Existing modules which have defined data types which have Num instances can be used with functions in my new hierarchy (2) New data types defined in the new hierarchy automatically get Num instances if appropriate so they can be used in existing modules. I know this is somewhat of a vague question but roughly how would I go about this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.wobben at home.nl Sat Feb 28 17:29:55 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Sat, 28 Feb 2015 18:29:55 +0100 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: References: <54F17EFF.7010902@home.nl> <54F1A184.8060800@home.nl> <54F1C524.4060706@home.nl> Message-ID: <54F1FB13.3040206@home.nl> An HTML attachment was scrubbed... URL: From michael at snoyman.com Sat Feb 28 17:50:54 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sat, 28 Feb 2015 17:50:54 +0000 Subject: [Haskell-cafe] What other prelude to cleanly convert text-files into json References: Message-ID: I haven't looked at your code since I'm on a mobile, but classy-prelude, of which I'm one of the maintainers, does provide functions that generally work with the Text data type. On Sat, Feb 28, 2015, 1:24 PM Bram Neijt wrote: > Dear reader, > > I wrote some tiny code to parse files into json (to automate escaping > multi-line text). > > It quickly became a collection of "import qualified" and "T.unpack, > T.pack" calls that made the whole thing look ugly [1]. > > What "alternative prelude" would help in getting clean code when > combining "aeson" and reading text files? > > Greetings, > > Bram > > [1] Source can be read here: https://gist.github.com/ > bneijt/9bdb4b1759790a8463c9 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Feb 28 17:57:25 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 28 Feb 2015 12:57:25 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: <06e128af-0094-47d0-b780-065f939adc3d@googlegroups.com> References: <06e128af-0094-47d0-b780-065f939adc3d@googlegroups.com> Message-ID: The Foldable/Monoid constraints are unrelated in behavior, so not necessarily. Why? At first blush you might think you'd get there via the free theorems, but Monoid is only on *, so you can use the inclusion of the argument in the Monoid instance to incur further constraints. newtype Foo a = Foo a deriving (Monoid, Foldable) now Foo has instance Foldable Foo instance Monoid m => Monoid (Foo m) it lifts the Monoid to the element inside, but if you fold it you get the single value contained inside of it, not mempty. Now if you want to upgrade this approach all the way to Alternative, rather than Monoid then the free theorem arguments start getting teeth. foldMap f empty = mempty should then (almost?) hold. I say almost because you *might* be able to have empty be an infinitely large tree which never gets down to values somehow, in which case that law would require deciding an infinite amount of work. I haven't sat down to prove if the latter is impossible, so I characterize it as at least plausible. -Edward On Fri, Feb 27, 2015 at 6:00 PM, Daniel D?az wrote: > Hi, > > Sorry for the slight derail, but I wanted to ask the following doubt: if a > Foldable type also happens to be a Monoid (say, like Set) does that > automatically imply that toList mempty = [] ? > > On Friday, February 27, 2015 at 8:18:05 PM UTC+1, Gershom B wrote: >> >> On February 27, 2015 at 1:39:10 AM, David Feuer (david... at gmail.com) >> wrote: >> > I am still struggling to understand why you want this to be a law for >> > Foldable. It seems an interesting property of some Foldable instances, >> > but, unlike Edward Kmett's proposed monoid morphism law, it's not >> > clear to me how you can use this low to prove useful properties of >> > programs. Could you explain? >> >> I think there are a number of purposes for laws. Some can be thought of >> as ?suggested rewrite rules? ? and the monoid morphism law is one such, as >> are many related free approaches. >> >> Note that the monoid morphism law that Edward provides is _not_ a >> ?proposed? law ? it is an ?almost free theorem? ? given a monoid morphism, >> it follows for free for any Foldable. There is no possible foldable >> instance that can violate this law, assuming you have an actual monoid >> morphism. >> >> So Edward may have proposed adding it to the documentation (which makes >> sense to me) ? but it provides absolutely no guidance or constraints as to >> what an ?allowable? instance of Foldable is or is not. >> >> But there are other reasons for laws than just to provide rewrite rules, >> even though it is often desirable to express laws in such terms. Consider >> the first Functor law for example ? fmap id === id. Now clearly we can use >> it to go eliminate a bunch of ?fmap id? calls in our program, should we >> have had them. But when would that ever be the case? Instead, the law is >> important because it _restricts_ the range of allowable instances ? and so >> if you know you have a data type, and you know it has a functor instance, >> you then know what that functor instance must do, without looking at the >> source code. >> >> >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Feb 28 17:59:08 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 28 Feb 2015 12:59:08 -0500 Subject: [Haskell-cafe] A Proposed Law for Foldable? In-Reply-To: <06e128af-0094-47d0-b780-065f939adc3d@googlegroups.com> References: <06e128af-0094-47d0-b780-065f939adc3d@googlegroups.com> Message-ID: The Foldable/Monoid constraints are unrelated in behavior, so not necessarily. Why? At first blush you might think you'd get there via the free theorems, but Monoid is only on *, so you can use the inclusion of the argument in the Monoid instance to incur further constraints. newtype Foo a = Foo a deriving (Monoid, Foldable) now Foo has instance Foldable Foo instance Monoid m => Monoid (Foo m) it lifts the Monoid to the element inside, but if you fold it you get the single value contained inside of it, not mempty. Now if you want to upgrade this approach all the way to Alternative, rather than Monoid then the free theorem arguments start getting teeth. foldMap f empty = mempty should then (almost?) hold. I say almost because you *might* be able to have empty be an infinitely large tree which never gets down to values somehow, in which case that law would require deciding an infinite amount of work. I haven't sat down to prove if the latter is impossible, so I characterize it as at least plausible. -Edward On Fri, Feb 27, 2015 at 6:00 PM, Daniel D?az wrote: > Hi, > > Sorry for the slight derail, but I wanted to ask the following doubt: if a > Foldable type also happens to be a Monoid (say, like Set) does that > automatically imply that toList mempty = [] ? > > On Friday, February 27, 2015 at 8:18:05 PM UTC+1, Gershom B wrote: >> >> On February 27, 2015 at 1:39:10 AM, David Feuer (david... at gmail.com) >> wrote: >> > I am still struggling to understand why you want this to be a law for >> > Foldable. It seems an interesting property of some Foldable instances, >> > but, unlike Edward Kmett's proposed monoid morphism law, it's not >> > clear to me how you can use this low to prove useful properties of >> > programs. Could you explain? >> >> I think there are a number of purposes for laws. Some can be thought of >> as ?suggested rewrite rules? ? and the monoid morphism law is one such, as >> are many related free approaches. >> >> Note that the monoid morphism law that Edward provides is _not_ a >> ?proposed? law ? it is an ?almost free theorem? ? given a monoid morphism, >> it follows for free for any Foldable. There is no possible foldable >> instance that can violate this law, assuming you have an actual monoid >> morphism. >> >> So Edward may have proposed adding it to the documentation (which makes >> sense to me) ? but it provides absolutely no guidance or constraints as to >> what an ?allowable? instance of Foldable is or is not. >> >> But there are other reasons for laws than just to provide rewrite rules, >> even though it is often desirable to express laws in such terms. Consider >> the first Functor law for example ? fmap id === id. Now clearly we can use >> it to go eliminate a bunch of ?fmap id? calls in our program, should we >> have had them. But when would that ever be the case? Instead, the law is >> important because it _restricts_ the range of allowable instances ? and so >> if you know you have a data type, and you know it has a functor instance, >> you then know what that functor instance must do, without looking at the >> source code. >> >> >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumit.sahrawat.apm13 at iitbhu.ac.in Sat Feb 28 18:49:45 2015 From: sumit.sahrawat.apm13 at iitbhu.ac.in (Sumit Sahrawat, Maths & Computing, IIT (BHU)) Date: Sun, 1 Mar 2015 00:19:45 +0530 Subject: [Haskell-cafe] how to make this work recursive ? In-Reply-To: <54F1FB13.3040206@home.nl> References: <54F17EFF.7010902@home.nl> <54F1A184.8060800@home.nl> <54F1C524.4060706@home.nl> <54F1FB13.3040206@home.nl> Message-ID: Don't worry. Keep these points in mind and re-read my previous mail. Regarding data vs. type constructors. 1) Leaf :: MessageTree (Leaf is a MessageTree) 2) MessageTree is a type constructor (takes types and gives new types) 3) Node is a data constructor (takes values and gives a new MessageTree) Regarding insertion. 1) The "insert" function takes a message and tree, and returns a tree with that message inserted into it 2) We absolutely have to provide it a tree 3) If we insert an invalid message in the tree, it does not get added. Then we get ..... the same tree back. If you still cannot see a problem in your code, ask yourself the following: 1) What type does the output of insert (MessageTree Leaf) have, and what type should it have 2) What happens if we insert an invalid string in a non-empty tree (according to your code) Don't forget to re-read the previous mail. Hope this drives the point home. On 28 February 2015 at 22:59, Roelof Wobben wrote: > Sorry, > > But I do not understand what you mean. > > What I try to do is this > > If you have a LogMessage which contains " This is not the right format " > then the LogMessage is not inserted in the tree. > Every other message are inserted in the tree. > > So that is why I make a MessageTree with only one Leaf. > > Roelof > > > > Sumit Sahrawat, Maths & Computing, IIT (BHU) schreef op 28-2-2015 om 16:08: > > You're missing an argument to insert, assuming that it is indeed there, > consider this: > > insert msg tree = tree' > where tree' = undefined > -- Take a LogMessage (msg) and a MessageTree (tree) > -- and return a new MessageTree (tree') > > Therefore, the result of insert in your case, i.e. "MessageTree Leaf" > should be of type MessageTree. > And thus, we get > > MessageTree Leaf :: MessageTree > -- Takes a (Leaf :: LogMessage) and produces a MessageTree > > which implies, > > MessageTree :: LogMessage -> MessageTree > -- A Data constructor > > Obviously no such data constructor exists. A data constructor of this > type would exist only if you wrote something like: > > data MessageTree = MessageTree LogMessage > | ... > > which would not make sense. > > On 28 February 2015 at 19:09, Roelof Wobben wrote: > >> I tried this : >> >> insert :: LogMessage -> MessageTree -> MessageTree >> insert s = >> case words s of >> (_:_: "This is not the right format") -> MessageTree Leaf >> _ -> MessageTree Node >> LogMessage Leaf >> >> >> But I see this errormessages which I do not understand : >> >> >> src/LogAnalysis.hs at 38:49-38:60 >> Not in scope: data constructor >> MessageTree >> src/LogAnalysis.hs at 39:49-39:60 >> Not in scope: data constructor >> MessageTree >> >> >> >> Mike Meyer schreef op 28-2-2015 om 12:17: >> >> On Sat, Feb 28, 2015 at 5:07 AM, Roelof Wobben wrote: >> >>> >>> That part I understand . >>> >>> it's more how I do it here : >>> >>> Lets say I have this : >>> >>> data MessageType = Info >>> | Warning >>> | Error Int >>> deriving (Show, Eq) >>> >>> type TimeStamp = Int >>> >>> data LogMessage = LogMessage MessageType TimeStamp String >>> | Unknown String >>> deriving (Show, Eq) >>> >>> data MessageTree = Leaf >>> | Node MessageTree LogMessage MessageTree >>> deriving (Show, Eq) >>> >>> Now I have to put all the LogMessages in a binary tree. >>> with this signature : insert :: LogMessage -> MessageTree -> MessageTree >>> >>> I think I need recursion here but I still not see how I can make the >>> clauses. >>> Normally you can say somethig like this [] -> 0 or 1 -> but here it >>> seems to be all seperate logMessages >>> >> >> Whether you need recursion or not depends on where you're to insert the >> message. For instance, you could turn them into a list with: >> >> insert message tree = Node tree message Leaf >> >> Try drawing a few pictures of what that produces, and you'll see why >> it's probably not what you want. >> >> You should be able to tell by looking at the MessageTree type that you >> have two cases: one where you're passed something matching a Node, and one >> where you're passed something that's just a Leaf. The latter can't be >> recursive, so it's going to terminate any recursion. Following the advice >> given to you for the Hanoi problem, try writing it first. >> >> Then all you have to do is figure out how to handle the case where >> you're given a Node instead of a Leaf. Figuring out where in the >> MessageTree you want to insert the Logmessage will probably be required to >> do that. >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Regards > > Sumit Sahrawat > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Regards Sumit Sahrawat -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sat Feb 28 18:50:26 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 28 Feb 2015 19:50:26 +0100 Subject: [Haskell-cafe] Hackage and Free Software In-Reply-To: <20150228172448.0B40EBC942@haskell.org> References: <20150228172448.0B40EBC942@haskell.org> Message-ID: <20150228185026.GA10871@x60s.casa> On Sat, Feb 28, 2015 at 07:27:16PM +0200, fr33domlover wrote: > I'd like to make a suggestion: have Hackage accept only packages > released under free software licenses. This is probably true for > most/all packages there, but making it official will both send a > strong message to and from the community, and provide people with > the security and peace of mind, knowing their software is free as > in freedom. I was pretty sure there was a note somewhere on hackage to only upload software with open source licences, but alas I cannot find it now... (maybe I am confusing myself with another package archiver?). I agree having a "please use a licence approved by the OSI/FSF" could prevent problems and seems a sensible choice in any case. From silvio.frischi at gmail.com Sat Feb 28 19:11:05 2015 From: silvio.frischi at gmail.com (silvio) Date: Sat, 28 Feb 2015 20:11:05 +0100 Subject: [Haskell-cafe] is it possible to implement Functor for ByteString and Text Message-ID: <54F212C9.6040509@gmail.com> I have recently heard that some people want to burn bridges (introducing Foldable and Traversable to Prelude) and I've been wondering if it was possible somehow allow Text and Bytestring like containers to make use of those functions. Something along the lines of import qualified Data.ByteString as BS newtype ByteString' a = ByteString' BS.ByteString type ByteString = ByteString' Word8 instance (ByteString' a ~ ByteString' Word8) => Functor (ByteString') where fmap f (ByteString' bs) = ByteString' $ BS.map f bs Or if DataContexts worked as you would expect. newtype (Word8 ~ a) => ByteString' a = ByteString' BS.ByteString However I couldn't find a solution and I was just wondering if it is possible. P.S. Using GADTS it does actually work for Foldable, but only because it doesn't have to output any ByteStrings. It doesn't work for Functor for instance. data ByteString' a where ByteString' :: BS.ByteString -> ByteString' Word8 type ByteString = ByteString' Word8 instance Foldable ByteString' where foldr f ini (ByteString' bs) = BS.foldr f ini bs Silvio From fryguybob at gmail.com Sat Feb 28 19:11:48 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Sat, 28 Feb 2015 14:11:48 -0500 Subject: [Haskell-cafe] Bounded STM Queues with load shedding In-Reply-To: References: <1425142290.3201.1.camel@gmail.com> Message-ID: Note that this is what orElse is for, turning a blocking API unto a choice. You could write tryWriteTBQueue as: tryWriteTBQueue queue v = (writeTBQueue queue v >> return True) `orElse` (return False) Ryan On Sat, Feb 28, 2015 at 11:56 AM, Alex Hammel wrote: > Perfect, thanks! > On 28 Feb 2015 08:51, "Yuras Shumovich" wrote: > >> On Sat, 2015-02-28 at 08:31 -0800, Alex Hammel wrote: >> > Forwarding from Haskell-Beginners: >> > >> > Hi list, >> > >> > It would be handy for me to have a bounded STM Queue along the lines of >> > TBQueue with the difference that when the queue is full, a call to >> > writeTBQueue is a non-blocking no-op. >> > >> > This is in the context of an asynchronous logging system. If the load >> > (somehow) gets heavy enough that the log message queue is taking up a >> lot >> > of memory, It's better to lose a few log messages than to have processes >> > block until the logger catches up. >> > >> > Are there any off-the-shelf solutions? >> >> You can try the stm-chans package: >> >> http://hackage.haskell.org/package/stm-chans-3.0.0.2/docs/Control-Concurrent-STM-TBMQueue.html#v:tryWriteTBMQueue >> >> Thanks, >> Yuras >> >> > >> > Cheers, >> > Alex >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Sat Feb 28 19:15:28 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 28 Feb 2015 13:15:28 -0600 Subject: [Haskell-cafe] Hackage and Free Software In-Reply-To: <20150228172446.3CB4EBC986@haskell.org> References: <20150228172446.3CB4EBC986@haskell.org> Message-ID: On Sat, Feb 28, 2015 at 11:27 AM, fr33domlover wrote: > Hello haskellers! > I'd like to make a suggestion: have Hackage accept only packages released under > free software licenses. Anything that excludes software that we could use, or otherwise discourages people from making software available to the community, is a bad idea. A restriction to OSF-approved licenses would exclude anything released under a Creative Commons license, since the OSF doesn't list those, which makes sense as they aren't "software licences" per se. And your restriction of "released under a license" would exclude public domain software - at least in countries that recognize such a thing. Yes, these are nits, but these are nits that could cause someone to decide not to put software that is otherwise perfectly acceptable on Hackage. > Actually the all-rights-reserved tag in Hackage [1] has only two packages > tagged by it - the dummy no-op project HNop, and another package whose COPYING > file contains a broken link and whose README says "BSD style license". This is a general problem on any site that offers downloads with a license type tag. What happens if the selected license tag and the included license have different rights? My suspicion is that if it went to court, you could justify using it under either license, meaning that such things are effectively dual licensed. We might make add a statement making that explicit. In particular, an "all-rights-reserved" tag implies that you may have to ask someone's permission to even download the package from Hackage, so it doesn't make a lot of sense. Given that - with the dual license interpretation - it effectively isn't used, removing it might make sense. Or renaming it to "other not listed" may be more appropriate. From david.feuer at gmail.com Sat Feb 28 19:41:22 2015 From: david.feuer at gmail.com (David Feuer) Date: Sat, 28 Feb 2015 14:41:22 -0500 Subject: [Haskell-cafe] is it possible to implement Functor for ByteString and Text In-Reply-To: <54F212C9.6040509@gmail.com> References: <54F212C9.6040509@gmail.com> Message-ID: This is impossible. The type of fmap is fmap :: Functor f => (a->b) -> f a -> f b You can use a GADT to effectively restrict what a is, because the caller won't be able to provide a non-bottom f a if a has the wrong type. But the caller can choose absolutely any type for b, and there's nothing you can do about that. David On Sat, Feb 28, 2015 at 2:11 PM, silvio wrote: > I have recently heard that some people want to burn bridges (introducing > Foldable and Traversable to Prelude) and I've been wondering if it was > possible somehow allow Text and Bytestring like containers to make use > of those functions. Something along the lines of > > import qualified Data.ByteString as BS > > newtype ByteString' a = ByteString' BS.ByteString > > type ByteString = ByteString' Word8 > > instance (ByteString' a ~ ByteString' Word8) => Functor (ByteString') > where > fmap f (ByteString' bs) = ByteString' $ BS.map f bs > > > Or if DataContexts worked as you would expect. > > newtype (Word8 ~ a) => ByteString' a = ByteString' BS.ByteString > > However I couldn't find a solution and I was just wondering if it is > possible. > > P.S. Using GADTS it does actually work for Foldable, but only because it > doesn't have to output any ByteStrings. It doesn't work for Functor for > instance. > > data ByteString' a where > ByteString' :: BS.ByteString -> ByteString' Word8 > > type ByteString = ByteString' Word8 > > instance Foldable ByteString' where > foldr f ini (ByteString' bs) = BS.foldr f ini bs > > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From fr33domlover at riseup.net Sat Feb 28 19:43:46 2015 From: fr33domlover at riseup.net (fr33domlover) Date: Sat, 28 Feb 2015 21:43:46 +0200 Subject: [Haskell-cafe] Hackage and Free Software In-Reply-To: References: <20150228172446.3CB4EBC986@haskell.org> Message-ID: Hello Mike, First of all, thanks for the feedback. On 2015-02-28 Mike Meyer wrote: > On Sat, Feb 28, 2015 at 11:27 AM, fr33domlover > wrote: > > Hello haskellers! > > I'd like to make a suggestion: have Hackage accept only packages released > under > > free software licenses. > > Anything that excludes software that we could use, or otherwise > discourages people from making software available to the community, is > a bad idea. A restriction to OSF-approved licenses would exclude > anything released under a Creative Commons license, since the OSF > doesn't list those, which makes sense as they aren't "software > licences" per se. And your restriction of "released under a license" > would exclude public domain software - at least in countries that > recognize such a thing. As to creative commons - indeed they aren't meant for software (maybe except for CC0, which is basically like public domain). But I also don't think people want to use them once they see the problem: If you want it permissive, you have Apache for example (also BSD/MIT), and if you want copyleft you have GPL (also AGPL, etc.). As to public domain: It's actually just fine! It's true than most countries recognize lack of license as "all rights reserved", but I also think it's a very small and trivial task for a maintainer to add a few license lines to state that the software should be globally treated as public domain. So public domain software is just fine, free software. In some websites it's common to publish code snippets under Creative Commons - if I'm not mistaken StackOverflow is like this - but Hackage is a package database and not a snippet manager, so the snippet situation is probably irrelevant, I hope. > Yes, these are nits, but these are nits that could cause someone to > decide not to put software that is otherwise perfectly acceptable on > Hackage. That depends on what "acceptable" means. In the worst case you can have separation between free and nonfree software by tag, and make it possible to turn nonfree software on/off using a cabal-install commandline option. This will allow people to upload first, and then think and understand the licensing situation. Once they do, they can properly tag their project. Could that work? > > Actually the all-rights-reserved tag in Hackage [1] has only two packages > > tagged by it - the dummy no-op project HNop, and another package whose > COPYING > > file contains a broken link and whose README says "BSD style license". > > This is a general problem on any site that offers downloads with a > license type tag. What happens if the selected license tag and the > included license have different rights? My suspicion is that if it > went to court, you could justify using it under either license, > meaning that such things are effectively dual licensed. We might make > add a statement making that explicit. > > In particular, an "all-rights-reserved" tag implies that you may have > to ask someone's permission to even download the package from Hackage, > so it doesn't make a lot of sense. Given that - with the dual license > interpretation - it effectively isn't used, removing it might make > sense. Or renaming it to "other not listed" may be more appropriate. That's what I thought too when I saw all-rights-reserved. > GPG key ID: 63E5E57D (size: 4096) GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From chrisdone at gmail.com Sat Feb 28 19:56:59 2015 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 28 Feb 2015 20:56:59 +0100 Subject: [Haskell-cafe] is it possible to implement Functor for ByteString and Text In-Reply-To: References: <54F212C9.6040509@gmail.com> Message-ID: You could have class IsWord8 a instance IsWord8 Word8 instance (IsWord8 a) => Functor (ByteString a) where ... It would be a legitimate instance. On 28 February 2015 at 20:41, David Feuer wrote: > This is impossible. The type of fmap is > > fmap :: Functor f => (a->b) -> f a -> f b > > You can use a GADT to effectively restrict what a is, because the > caller won't be able to provide a non-bottom f a if a has the wrong > type. But the caller can choose absolutely any type for b, and there's > nothing you can do about that. > > David > > On Sat, Feb 28, 2015 at 2:11 PM, silvio wrote: >> I have recently heard that some people want to burn bridges (introducing >> Foldable and Traversable to Prelude) and I've been wondering if it was >> possible somehow allow Text and Bytestring like containers to make use >> of those functions. Something along the lines of >> >> import qualified Data.ByteString as BS >> >> newtype ByteString' a = ByteString' BS.ByteString >> >> type ByteString = ByteString' Word8 >> >> instance (ByteString' a ~ ByteString' Word8) => Functor (ByteString') >> where >> fmap f (ByteString' bs) = ByteString' $ BS.map f bs >> >> >> Or if DataContexts worked as you would expect. >> >> newtype (Word8 ~ a) => ByteString' a = ByteString' BS.ByteString >> >> However I couldn't find a solution and I was just wondering if it is >> possible. >> >> P.S. Using GADTS it does actually work for Foldable, but only because it >> doesn't have to output any ByteStrings. It doesn't work for Functor for >> instance. >> >> data ByteString' a where >> ByteString' :: BS.ByteString -> ByteString' Word8 >> >> type ByteString = ByteString' Word8 >> >> instance Foldable ByteString' where >> foldr f ini (ByteString' bs) = BS.foldr f ini bs >> >> >> Silvio >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From chrisdone at gmail.com Sat Feb 28 19:58:06 2015 From: chrisdone at gmail.com (Christopher Done) Date: Sat, 28 Feb 2015 20:58:06 +0100 Subject: [Haskell-cafe] is it possible to implement Functor for ByteString and Text In-Reply-To: References: <54F212C9.6040509@gmail.com> Message-ID: Ah, I'm talking nonsense. Ignore me. On 28 February 2015 at 20:56, Christopher Done wrote: > You could have > class IsWord8 a > instance IsWord8 Word8 > instance (IsWord8 a) => Functor (ByteString a) where ... > > It would be a legitimate instance. > > On 28 February 2015 at 20:41, David Feuer wrote: >> This is impossible. The type of fmap is >> >> fmap :: Functor f => (a->b) -> f a -> f b >> >> You can use a GADT to effectively restrict what a is, because the >> caller won't be able to provide a non-bottom f a if a has the wrong >> type. But the caller can choose absolutely any type for b, and there's >> nothing you can do about that. >> >> David >> >> On Sat, Feb 28, 2015 at 2:11 PM, silvio wrote: >>> I have recently heard that some people want to burn bridges (introducing >>> Foldable and Traversable to Prelude) and I've been wondering if it was >>> possible somehow allow Text and Bytestring like containers to make use >>> of those functions. Something along the lines of >>> >>> import qualified Data.ByteString as BS >>> >>> newtype ByteString' a = ByteString' BS.ByteString >>> >>> type ByteString = ByteString' Word8 >>> >>> instance (ByteString' a ~ ByteString' Word8) => Functor (ByteString') >>> where >>> fmap f (ByteString' bs) = ByteString' $ BS.map f bs >>> >>> >>> Or if DataContexts worked as you would expect. >>> >>> newtype (Word8 ~ a) => ByteString' a = ByteString' BS.ByteString >>> >>> However I couldn't find a solution and I was just wondering if it is >>> possible. >>> >>> P.S. Using GADTS it does actually work for Foldable, but only because it >>> doesn't have to output any ByteStrings. It doesn't work for Functor for >>> instance. >>> >>> data ByteString' a where >>> ByteString' :: BS.ByteString -> ByteString' Word8 >>> >>> type ByteString = ByteString' Word8 >>> >>> instance Foldable ByteString' where >>> foldr f ini (ByteString' bs) = BS.foldr f ini bs >>> >>> >>> Silvio >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mwm at mired.org Sat Feb 28 20:18:23 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 28 Feb 2015 14:18:23 -0600 Subject: [Haskell-cafe] Hackage and Free Software In-Reply-To: <54f21a89.ed16460a.1d6a.ffff9ddcSMTPIN_ADDED_MISSING@mx.google.com> References: <20150228172446.3CB4EBC986@haskell.org> <54f21a89.ed16460a.1d6a.ffff9ddcSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Sat, Feb 28, 2015 at 1:43 PM, fr33domlover wrote: On 2015-02-28 Mike Meyer wrote: > > Anything that excludes software that we could use, or otherwise > > discourages people from making software available to the community, is > > a bad idea. A restriction to OSF-approved licenses would exclude > > anything released under a Creative Commons license, since the OSF > > doesn't list those, which makes sense as they aren't "software > > licences" per se. And your restriction of "released under a license" > > would exclude public domain software - at least in countries that > > recognize such a thing. > > As to creative commons - indeed they aren't meant for software (maybe except > for CC0, which is basically like public domain). But I also don't think people > want to use them once they see the problem: If you want it permissive, you have > Apache for example (also BSD/MIT), and if you want copyleft you have GPL (also > AGPL, etc.). And what if I want something like the CDDL or the EPL? Those are both licenses that the OSI says are popular. > As to public domain: It's actually just fine! It's true than most countries > recognize lack of license as "all rights reserved", but I also think it's a > very small and trivial task for a maintainer to add a few license lines to > state that the software should be globally treated as public domain. > > So public domain software is just fine, free software. You're addressing the nits, not the core issue I tried to raise: placing restrictions on what licenses (or lack thereof) are acceptable will discourage people from making software available via Hackage. > > Yes, these are nits, but these are nits that could cause someone to > > decide not to put software that is otherwise perfectly acceptable on > > Hackage. > That depends on what "acceptable" means. In the worst case you can have > separation between free and nonfree software by tag, and make it possible to > turn nonfree software on/off using a cabal-install commandline option. > > This will allow people to upload first, and then think and understand the > licensing situation. Once they do, they can properly tag their project. Could > that work? I don't know. I suspect that if you do that, a lot of people would never bother tagging their packages. Would that work for you? You also talk like free/non-free was a binary decision, when it isn't. The OSI lists licenses that aren't compatible with the GPL - like the aforementioned EPL and CDDL. People releasing software under one of those will want to avoid GPL licensed software, whereas people releasing GPL licensed software will want to avoid those licenses, but they are all free. Or I may not care. If I build a binary that uses one package that's GPL-licensed and one that uses an incompatible OSI-approved license, I can distribute my source under whatever terms I want, because my source doesn't include source from those packages. I can build and run binaries myself with no problems, and that may be fine. But I can't distribute binaries because I can't satisfy both licenses simultaneously, and that may not be acceptable. From marcin.jan.mrotek at gmail.com Sat Feb 28 20:41:24 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Sat, 28 Feb 2015 21:41:24 +0100 Subject: [Haskell-cafe] ANN: diagrams-hsqml - a Qt5, QtQuick Canvas backend Message-ID: Hello, I wrote a Diagrams backend that paints on QtQuick (Qt5) canvases through HsQML. It's somewhat half-baked at this point and I haven't fully tested it, but it's good enough for my puroposes (rendering charts through Chart-diagrams) and I have more urgent things to do right now, so I decided to release it as it is. http://hackage.haskell.org/package/diagrams-hsqml https://github.com/marcinmrotek/diagrams-hsqml https://github.com/marcinmrotek/diagrams-hsqml/issues There's one bug I already know of but have no idea how to fix; namely when rendering charts from Chart-diagrams all text is fully filled, with a properly rendered black tex laid on top of it. This can be worked around by setting the font colour to transparent. Bug reports and help in improving the backend by all means welcome. Best regards, Marcin Mrotek From fa-ml at ariis.it Sat Feb 28 20:59:38 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 28 Feb 2015 21:59:38 +0100 Subject: [Haskell-cafe] Hackage and Free Software In-Reply-To: References: <20150228172446.3CB4EBC986@haskell.org> Message-ID: <20150228205938.GA12510@x60s.casa> On Sat, Feb 28, 2015 at 01:15:28PM -0600, Mike Meyer wrote: > Anything that excludes software that we could use, or otherwise > discourages people from making software available to the community, is > a bad idea. A restriction to OSF-approved licenses would exclude > anything released under a Creative Commons license, since the OSF > doesn't list those, which makes sense as they aren't "software > licences" per se. And your restriction of "released under a license" > would exclude public domain software - at least in countries that > recognize such a thing. > > Yes, these are nits, but these are nits that could cause someone to > decide not to put software that is otherwise perfectly acceptable on > Hackage. Those restrictions would be, in my opinion, a good idea. Rejecting say CC-SA (CC0 is FSF approved), etc. code means rejecting licences with clear and documented problems in them, problems which would cause quite a lot of headaches down the road. Having to pick a licence from the bazillion ones [1] approved by the FSF or the OSI streamlines the choice and avoids licence creep with a minimal risk of scaring the uploader away. I must admit, as fr33domlover notes, that this problem isn't present in hackage as now (I yet have to meet a library not licenced as GPL/ MIT/BSD3), but after finding this gem on github may be used in commercial projects and applications with the one-time purchase of a commercial license. For non-commercial, personal, or open source projects and applications, you may use under the terms of the GPL v3 License. You may use for free. I say: "Better safe than sorry" ;) [1] http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses#Approvals From vogt.adam at gmail.com Sat Feb 28 21:11:54 2015 From: vogt.adam at gmail.com (adam vogt) Date: Sat, 28 Feb 2015 16:11:54 -0500 Subject: [Haskell-cafe] Parallel numeric class hierarchy In-Reply-To: References: Message-ID: On Sat, Feb 28, 2015 at 12:28 PM, Clinton Mead wrote: > Let's say for arguments sake I want to make a new finer grained numeric > class hierarchy. But, I also want to have the following occur: > > (1) Existing modules which have defined data types which have Num instances > can be used with functions in my new hierarchy > (2) New data types defined in the new hierarchy automatically get Num > instances if appropriate so they can be used in existing modules. > > I know this is somewhat of a vague question but roughly how would I go about > this? You could use overlapping & undecidable instances to get (1) and (2): class Plus a where plus :: a -> a -> a class NewNum a -- no methods -- a type using the "new" hierarchy data X = X Int instance Plus X where X a `plus` X b = X (a+b) instance NewNum X instance Num a => Plus a where plus = (Prelude.+) instance (Plus a, Minus a, ... , NewNum a) => Num a where (+) = plus Having an extra constraint NewNum stops "() + ()" from being an infinite loop where we can make an instance Num () if we have an instance Plus () which exists if we have Num () ... The usual objection to overlapping instances (that adding an import can change the result of the program), is probably less of a problem here than usual because + and plus have a chance of still doing the same thing when somebody defines "instance Num X" separately. Regards, Adam From mwm at mired.org Sat Feb 28 21:29:06 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 28 Feb 2015 15:29:06 -0600 Subject: [Haskell-cafe] Hackage and Free Software In-Reply-To: <20150228205938.GA12510@x60s.casa> References: <20150228172446.3CB4EBC986@haskell.org> <20150228205938.GA12510@x60s.casa> Message-ID: On Sat, Feb 28, 2015 at 2:59 PM, Francesco Ariis wrote: > Those restrictions would be, in my opinion, a good idea. Rejecting > say CC-SA (CC0 is FSF approved), etc. code means rejecting licences > with clear and documented problems in them, problems which would > cause quite a lot of headaches down the road. > I don't have a problem if you want to do that. But by disallowing those licenses on Hackage, you've taken away *MY* ability to decide if those problems are problems for my use case. There are open source projects that are systematically excising GPL'ed software because of the problems it shares with ShareAlike licenses. Should we disallow the GPL because some people have problems with it? Making Hackage better to help users sort out which licenses they are willing to accept in their project - which I personally would like to do on a project-by-project basis! - is a solution to these problems. Restricting the licenses that are acceptable on Hackage to meet some arbitrary set of criteria is a knee-jerk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From psyzy3 at nottingham.ac.uk Sat Feb 28 23:40:08 2015 From: psyzy3 at nottingham.ac.uk (Zongzhe Yuan) Date: Sat, 28 Feb 2015 23:40:08 +0000 Subject: [Haskell-cafe] A Question about IO Message-ID: Hi i have a question about IO monad. Sometimes IO do something and return something, i wonder if the return type, for example is IO Int means it will return an int, could i purely fetch the int? but i fail, i cannot construct a function, i use do notation but i found i must use something to pass the int to another monad. But i could write a function has the type of Maybe a -> a and it is easily. Maybe monad and IO monad both instance monad but why i can?t do that? Zongzhe Yuan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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 psyzy3 at nottingham.ac.uk Sat Feb 28 23:44:44 2015 From: psyzy3 at nottingham.ac.uk (Zongzhe Yuan) Date: Sat, 28 Feb 2015 23:44:44 +0000 Subject: [Haskell-cafe] A Question about IO monad Message-ID: Hi i have a question about IO monad. Sometimes IO do something and return something, i wonder if the return type, for example is IO Int means it will return an int, could i purely fetch the int? but i fail, i cannot construct a function, i use do notation but i found i must use something to pass the int to another monad. But i could write a function has the type of Maybe a -> a and it is easily. Maybe monad and IO monad both instance monad but why i can?t do that? Zongzhe Yuan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. 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.