September 2008 - Haskell-Cafe

Re: A problem with nested regions and higher-order?functions
by Chung-chieh Shan 08 Sep '08

08 Sep '08

Mario Bla??evi?? <mblazevic(a)stilo.com> wrote in article <23051.1216949255$1220747147(a)news.gmane.org> in gmane.comp.lang.haskell.cafe: > I'm trying to apply the nested regions (as in Lightweight Monadic > Regions by Oleg Kiselyov and Chung-chieh Shan) design pattern, if > that's the proper term, in hope to gain a bit more type safety in > this little library I'm working on (Streaming Component Combinators, > available on Hackage). I guess the problem is that I'm getting too > much type safety now, because I can't get the thing to compile. ... Hi! Thanks for your interest. It sounds like a promising application of region checking. I actually side with the type checker on this problem: > > type SingleHandler x y = forall r1s rs. Ancestor r1s rs => > > Handle r1s x -> Region rs y > > type DoubleHandler x y z = forall r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) => > > Handle r1d x -> Handle r2d y -> Region rd z Here a SingleHandler is defined as an operation, in an arbitrary region on an arbitrary handle, that is valid as long as the region of the operation descends from the region of the handle. For example, reading a string from an arbitrary open file is a "SingleHandler File String". However, copying a string from an arbitrary open file to another fixed file is not a SingleHandler, because such an operation is valid only in a region that descends from the destination file handle's region! That's what GHC complained about as it checks your mapD: > > mapD :: (SingleHandler x z -> SingleHandler y z) > > -> DoubleHandler x w z -> DoubleHandler y w z > > mapD f d = \y w-> f (\x-> d x w) y So we really need to change the type of mapD if we want it to be accepted by a sound type system. The simplest way is to not require that mapD return a DoubleHandler (a binary operation that works in an arbitrary region): mapD :: ((Handle r1 x -> Region r z) -> (Handle r1 x -> Region r z)) -> ((Handle r1 x -> Handle r2 w -> Region r z) -> (Handle r1 x -> Handle r2 w -> Region r z)) mapD f d = \y w-> f (\x-> d x w) y This type is a special case of the type automatically inferred for mapD by Haskell if you omit the type signature. Haskell doesn't have any trouble type-checking higher-order functions, such as this mapD, but higher-rank types can call for manual annotations, as illustrated below. Another way to get mapD to type-check is to pass it (as its first argument) not a SingleHandler transformer but a transformer of operations that may work only in descendents of a given region r2. We want to write type H r2 x y = forall r1 r. (Ancestor r1 r, Ancestor r2 r) => Handle r1 x -> Region r y mapD :: (forall r2. H r2 x z -> H r2 y z) -> DoubleHandler x w z -> DoubleHandler y w z mapD f d = \y w-> f (\x-> d x w) y ("forall r2" takes scope over both "H r2 x z" and "H r2 y z" above) but GHC doesn't see that we intend to unify the "r2d" in the expansion of "DoubleHandler y w z" with the "r2" in this type signature of "mapD". So, we need to put an explicit type annotation on the use of "f" in the body of "mapD". To do so, we add {-# LANGUAGE ScopedTypeVariables #-} and expand the type synonym "DoubleHandler y w z" in the type signature of "mapD": mapD :: forall x y z w r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) => (forall r2. H r2 x z -> H r2 y z) -> DoubleHandler x w z -> Handle r1d y -> Handle r2d w -> Region rd z mapD f d = \y w-> (f :: H r2d x z -> H r2d y z) (\x-> d x w) y Not so pretty anymore, but it does pass the type checker (GHC 6.8.2). -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig ----- Ken Shan

1 0

experimental static blog engine in Haskell (file based, markdown syntax)
by jinjing 08 Sep '08

08 Sep '08

Hia, It's called Panda. It's pretty young, no theme, no tags, no comments, around 360 lines of code and uses Kibro to bootstrap. hosted on GitHub: http://github.com/nfjinjing/panda/ a quick demo at: http://jinjing.blog.easymic.com/ cheers, - jinjing

2 2

building unix package on windows
by jean-christophe mincke 08 Sep '08

08 Sep '08

Hello, I have installed GHC and cygwin on windows XP and I am trying to build the unix package (required to install HApps) ** When I use .../ghc/gcc as c compiler I receive the following error during the configure* D:\temp\haskell\unix-2.3.0.0>runhaskell Setup configure --ghc --prefix=D:\apps\h-lib Configuring unix-2.3.0.0... checking for gcc... gcc checking for C compiler default output file name... *configure: error: C compiler cannot create executables* See `config.log' for more details. and config.log says that : * ld: crt2.o: No such file: No such file or directory* ** When I use the gcc in cygwin : /usr/bin/gcc, the configure phase is ok but the build stop on the following error:* D:\temp\haskell\unix-2.3.0.0>runhaskell Setup build Preprocessing library unix-2.3.0.0... *In file included from System\Posix\DynamicLinker\Module.hsc:57:0: include/HsUnix.h:32:23: sys/times.h: No such file or directory* include/HsUnix.h:38:26: sys/resource.h: No such file or directory include/HsUnix.h:41:22: sys/wait.h: No such file or directory include/HsUnix.h:62:21: termios.h: No such file or directory include/HsUnix.h:65:25: sys/utsname.h: No such file or directory include/HsUnix.h:68:17: pwd.h: No such file or directory include/HsUnix.h:71:17: grp.h: No such file or directory include/HsUnix.h:81:17: pty.h: No such file or directory include/HsUnix.h:84:18: utmp.h: No such file or directory include/HsUnix.h:87:19: dlfcn.h: No such file or directory In file included from System\Posix\DynamicLinker\Module.hsc:57:0: include/HsUnix.h: In function `__hsunix_wifexited': include/HsUnix.h:103:0: warning: implicit declaration of function `WIFEXITED' include/HsUnix.h: In function `__hsunix_wexitstatus': include/HsUnix.h:104:0: warning: implicit declaration of function `WEXITSTATUS' include/HsUnix.h: In function `__hsunix_wifsignaled': include/HsUnix.h:105:0: warning: implicit declaration of function `WIFSIGNALED' include/HsUnix.h: In function `__hsunix_wtermsig': include/HsUnix.h:106:0: warning: implicit declaration of function `WTERMSIG' include/HsUnix.h: In function `__hsunix_wifstopped': include/HsUnix.h:107:0: warning: implicit declaration of function `WIFSTOPPED' include/HsUnix.h: In function `__hsunix_wstopsig': include/HsUnix.h:108:0: warning: implicit declaration of function `WSTOPSIG' include/HsUnix.h: In function `__hsunix_rtldDefault': include/HsUnix.h:115:0: error: `RTLD_DEFAULT' undeclared (first use in this function) include/HsUnix.h:115:0: error: (Each undeclared identifier is reported only once include/HsUnix.h:115:0: error: for each function it appears in.) include/HsUnix.h: In function `__hsunix_lstat': include/HsUnix.h:134:0: warning: implicit declaration of function `lstat' include/HsUnix.h: In function `__hsunix_mknod': include/HsUnix.h:140:0: warning: implicit declaration of function `mknod' compiling dist\build\System\Posix\DynamicLinker\Module_hsc_make.c failed *command was: d:\apps\ghc\bin\ghc.exe -c -package base-3.0.2.0 -package directory-1.0.0.1 -Iinclude dist\build\System\Pos ix\DynamicLinker\Module_hsc_make.c -o dist\build\System\Posix\DynamicLinker\Module_hsc_make.o* Could someone help me. Thank you J-C

2 1

Re: [Haskell] Top Level <-
by Adrian Hey 08 Sep '08

08 Sep '08

I have a feeling this is going to be a very long thread so I'm trying to go to Haskell cafe again (without mucking it up again). Derek Elkins wrote: > Haskell should be moving -toward- a capability-like model, not away from > it. Could you show how to implement Data.Random or Data.Unique using such a model, or any (preferably all) of the use cases identified can be implemented? Like what about implementing the socket API starting with nothing but primitives to peek/poke ethernet mac and dma controller registers? Why should Haskell should be moving -toward- a capability-like model and why does top level <- declarations take us away from it? Regards -- Adrian Hey

21 178

language proposal: ad-hoc overloading
by Ryan Ingram 07 Sep '08

07 Sep '08

The point of having a strongly typed language is so the compiler can do more work for you. But right now I do a lot of typing (pun not intended) to appease the compiler. Let me give you an example: module Prob where import qualified Data.Map as M ... newtype Prob p a = Prob { runProb :: [(a,p)] } combine :: (Num p, Ord a) => Prob p a -> Prob p a combine m = Prob $ M.assocs $ foldl' (flip $ uncurry $ M.insertWith (+)) M.empty $ runProb m Do you see it? All those "M." just seem dirty to me, especially because the compiler should be able to deduce them from the types of the arguments. My proposal is to allow "ad-hoc" overloading of names; if a name is ambiguous in a scope, attempt to type-check the expression against each name. It is only an error if type-checking against all names fails. If type-checking succeeds for more than one then the expression is ambiguous and this is also an error. Pros: shorter code, less busywork to please the compiler Cons: potentially exponential compile time? Any thoughts? -- ryan

16 25

HXT from schema to data model
by Pierre-Edouard Portier 07 Sep '08

07 Sep '08

Hi! Is there a way to generate a data model and a set of picklers from an XML (or RelaxNG) Schema using the HXT tool box? Thank You, Pierre-Edouard

2 1

Online Real World Haskell, problem with Sqlite3 chapters
by david48 07 Sep '08

07 Sep '08

In the online version of Real world Haskell, there's a problem with examples in ghci when the module Database.HDBC.Sqlite3 is imported. It goes on like this for all of chapter 21 and 22. Example : ( note: this is not me trying to reproduce the examples, it's an actual copy & paste from the site url http://book.realworldhaskell.org/read/using-databases.html ) ghci> :module Database.HDBC Database.HDBC.Sqlite3 Could not find module `Database.HDBC.Sqlite3': Use -v to see a list of the files searched for. ghci> conn <- connectSqlite3 "test1.db" <interactive>:1:8: Not in scope: `connectSqlite3' ghci> :type conn <interactive>:1:0: Not in scope: `conn' ghci> disconnect conn <interactive>:1:0: Not in scope: `disconnect' <interactive>:1:11: Not in scope: `conn'

11 14

A problem with nested regions and higher-order functions
by Mario Blažević 07 Sep '08

07 Sep '08

I forgot the subject, sorry for reposting... I'm trying to apply the nested regions (as in Lightweight Monadic Regions by Oleg Kiselyov and Chung-chieh Shan) design pattern, if that's the proper term, in hope to gain a bit more type safety in this little library I'm working on (Streaming Component Combinators, available on Hackage). I guess the problem is that I'm getting too much type safety now, because I can't get the thing to compile. Most of the existing code works, the only exceptions seem to be various higher-order functions. I've reduced the problem to several lines of Literate Haskell code below, can anybody find a solution or confirm there isn't one? > {-# LANGUAGE EmptyDataDecls, Rank2Types #-} > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, IncoherentInstances #-} > module Main where > main = undefined I'll call the main type, originally a monad transformer, simply Region. I'm leaving out the Monad and MonadTransformer instances, because they don't contribute to the problem. The parameter r is the phantom region type. > newtype Region r a = Region a The Ancestor class is used to denote relationship between two regions where one is nested in another. > data Child r > class Ancestor r r' > instance Ancestor r (Child r) > instance Ancestor r1 r2 => Ancestor r1 (Child r2) Handle is a simple wrapper around a value. It carries information about the region that originates the value. > data Handle r x = Handle x A typical calculation in the Region monad will take a bunch of Handles inherited from an Ancestor region and do something with them. The Ancestor constraint is there to ensure that the handles are not fake but genuinely inherited. > type SingleHandler x y = forall r1s rs. Ancestor r1s rs => > Handle r1s x -> Region rs y > type DoubleHandler x y z = forall r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) => > Handle r1d x -> Handle r2d y -> Region rd z And now I get to the problem. The following higher-order function doesn't type-check: > mapD :: (SingleHandler x z -> SingleHandler y z) > -> DoubleHandler x w z -> DoubleHandler y w z > mapD f d = \y w-> f (\x-> d x w) y I get the same error from GHC 6.8.2 and 6.8.2: Test.lhs:36:28: Could not deduce (Ancestor r2d rs) from the context (Ancestor r1s rs) arising from a use of `d' at Test.lhs:36:28-32 Possible fix: add (Ancestor r2d rs) to the context of the polymorphic type `forall r1s rs. (Ancestor r1s rs) => Handle r1s x -> Region rs z' In the expression: d x w In the first argument of `f', namely `(\ x -> d x w)' In the expression: f (\ x -> d x w) y The same code compiles just fine if all the Ancestor constraints are removed. I don't see any place to add the extra (Ancestor r2d rs) constraint, as GHC recommends. I think it ought to be able to figure things out based on the exisisting constraints, but I may be wrong: perhaps higher-order functions pose a fundamental problem for type-level programming. Can anybody shed any light on this?

1 0

(no subject)
by Mario Blažević 07 Sep '08

07 Sep '08

Hello. I'm trying to apply the nested regions (as in Lightweight Monadic Regions by Oleg Kiselyov and Chung-chieh Shan) design pattern, if that's the proper term. I was hoping to gain a bit more type safety in this little library I'm working on -- Streaming Component Combinators, available on Hackage. I guess the problem is that I'm getting too much type safety now, because I can't get the thing to compile. Most of the existing code works, the only exceptions seem to be various higher-order functions. I've reduced the problem to several lines of Literate Haskell code below, can anybody think of a solution or a reason there can't be one? > {-# LANGUAGE MultiParamTypeClasses, EmptyDataDecls, Rank2Types #-} > {-# LANGUAGE FunctionalDependencies, FlexibleInstances, IncoherentInstances #-} > module Main where > main = undefined I'll call the main type, originally a monad transformer, simply Region. I'm leaving out the Monad and MonadTransformer instances, because they don't contribute to the problem. The parameter r is the phantom region type. > newtype Region r a = Region a The Ancestor class is used to denote relationship between two regions where one is nested in another. > data Child r > class Ancestor r r' > instance Ancestor r (Child r) > instance Ancestor r1 r2 => Ancestor r1 (Child r2) Handle is a simple wrapper around a value. It carries information about the region that originates the value. > data Handle r x = Handle x A typical calculation in the Region monad will take a bunch of Handles inherited from an Ancestor region and do something with them. The Ancestor constraint is there to ensure that the handles are not fake but genuinely inherited. > type SingleHandler x y = forall r1s rs. Ancestor r1s rs => > Handle r1s x -> Region rs y > type DoubleHandler x y z = forall r1d r2d rd. (Ancestor r1d rd, Ancestor r2d rd) => > Handle r1d x -> Handle r2d y -> Region rd z And now I'm getting to the problem. The following higher-order function doesn't type-check: > mapD :: (SingleHandler x z -> SingleHandler y z) > -> DoubleHandler x w z -> DoubleHandler y w z > mapD f d = \y w-> f (\x-> d x w) y I get the same error from GHC 6.8.2 and 6.8.2: Test.lhs:36:28: Could not deduce (Ancestor r2d rs) from the context (Ancestor r1s rs) arising from a use of `d' at Test.lhs:36:28-32 Possible fix: add (Ancestor r2d rs) to the context of the polymorphic type `forall r1s rs. (Ancestor r1s rs) => Handle r1s x -> Region rs z' In the expression: d x w In the first argument of `f', namely `(\ x -> d x w)' In the expression: f (\ x -> d x w) y The same code compiles just fine if all the Ancestor constraints are removed. I don't see any place to add the extra (Ancestor r2d rs) constraint, as GHC recommends. I think it ought to be able to figure things out based on the exisisting constraints, but I may be wrong: perhaps higher-order functions pose an insurmountable problem for type-level programming in Haskell. Can anybody shed any light on this?

1 0

Re: [xmonad] ANNOUNCE: xmonad 0.8 released!
by Don Stewart 06 Sep '08

06 Sep '08

nomeata: > Hi, > > Am Freitag, den 05.09.2008, 18:38 -0700 schrieb Don Stewart: > > xmonad packages are available in the package systems of at least: > > > > Debian, Gentoo, Arch, Ubuntu, OpenBSD, > > NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware > > > > and 0.8 packages will appear in coming days (some are already available). > > Debian xmonad and xmonad-contrib package uploaded (although > xmonad-contrib is in the two-day delayed queue, to give autobuilders a > chance to build xmonad first). Great work, Joachim! Thanks for being so responsive on this. Go Debian! -- Don

2 3