March 2012 - Glasgow-haskell-users

Bug with unicode characters in file names
by Volker Wysk 13 Mar '12

13 Mar '12

Hi This is some file "äöü.hs" with three German umlauts in the file name: main = putStrLn "äöü" Now I want to get the dependendency information. Therefore I call: ghc -M äöü.hs The following gets added to the Makefile: # DO NOT DELETE: Beginning of Haskell dependencies Ã¤Ã¶Ã¼.o : Ã¤Ã¶Ã¼.hs # DO NOT DELETE: End of Haskell dependencies The umlauts get transformed from three UTF-8 encoded characters (six bytes) to six UTF-8 encoded characters (twelve bytes). I'm sending this to glasgow-haskell-users instead of glasgow-haskell-bugs, because the latter does not seem to accept my messages. I receive nothing, neither the message in the mailing list, nor any error message. Bye, V.W.

3 2

packaged up polykinded types can't index type families?
by Nicolas Frisby 13 Mar '12

13 Mar '12

I suspect I'm tripping on a gap in the PolyKinds support. I'm trying to package up a type-level generic view. It uses PolyKinds — and DataKinds, but I think it's the PolyKinds that matter. If I compile everything locally in the same build, it works fine. If I isolate the spine view declarations in their own package, I get type errors. A quick search turned up this omnibus, which I'm guessing might fix my problem. http://hackage.haskell.org/trac/ghc/changeset/3bf54e78cfd4b94756e3f21c00ae1… I was hoping someone might be able to identify if that's the case. I can wait for 7.6.1 if I must, but I was wondering if there's a workaround. (If I avoid PolyKinds, it works. But I have to simulate PolyKinds for a finite set of kinds, which is pretty obfuscating and not general. If you're curious, checkout the type-spine package. This whole email regards my trying to generalize and simplify that package with PolyKinds.) In a distillation of my use case, we have two modules. The first is the type-level spine view. > {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds, TypeOperators, > UndecidableInstances, TemplateHaskell, EmptyDataDecls #-} > module Spine where > > type family Spine a :: * > > data Atom n -- represents a totally unapplied type name > data f :@ a -- |represents a type-level application > > -- this is an "unsaturated instance", which might be a no-no, but > -- at least isn't obviously causing the current problem > type instance Spine (f a) = f :@ a > > -- all other instances are for unapplied types names: > ----- e.g. type instance Spine N = Atom N > spineType :: Name -> Q [Dec] > spineType n = let t = conT n in > (:[]) `fmap` tySynInstD ''Spine [t] [t| Atom $t |] The second module is a distilled use case. > {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds, TypeOperators, TemplateHaskell #-} > > module Test where > > import Spine -- our first module above > > type family IsApp (a :: *) :: Bool > type instance IsApp (Atom n) = False > type instance IsApp (a :@ b) = True > > -- example types and use > data A = A > data F a = F a > > concat `fmap` mapM spineType [''A, ''F] > > isApp :: (True ~ IsApp (Spine a)) => a -> () > isApp _ = () > > test :: () > test = isApp (F A) If Spine.hs and Test.hs are in the same directory and I load Test in ghci, it type-checks fine. If I instead use cabal to install Spine as its own package, the subsequent type-checking of Test.test fails with: > Couldn't match type `IsApp ((:@) (* -> *) * F A)' with `'True' The :bro Spine command returns the same information regardless of how Test imports Spine. > *Test> :bro Spine > type family Spine k a :: * > data Atom k n > data (:@) k k f a > spineType :: ...snip... Why can "IsApp (... :@ ...)" reduce if Spine was locally compiled but not if it's pulled from a package? Is there some crucial info that the package interfaces can't yet express? Is there an open bug for this? Thanks for your time, Nick

2 1

Boxed foreign prim
by Edward Kmett 13 Mar '12

13 Mar '12

I'm currently working with a lot of very short arrays of fixed length and as a thought experiment I thought I would try to play with fast numeric field accessors In particular, I'd like to use something like foreign prim to do something like > foreign import prim "cmm_getField" unsafeField# :: a -> Int# -> b > unsafeField :: a -> Int -> b > unsafeField a (I# i) = a' `pseq` unsafeField# a' i -- the pseq could be moved into the prim, I suppose. > where a' = unsafeCoerce a > fst :: (a,b) -> a > fst = unsafeField 0 > snd :: (a,b) -> b > snd = unsafeField 1 This becomes more reasonable to consider when you are forced to make something like > data V4 a = V4 a a a a using > unsafeIndex (V4 a _ _ _) 0 = a > unsafeIndex (V4 _ b _ _) 1 = b > unsafeIndex (V4 _ _ c _) 2 = c > unsafeIndex (V4 _ _ _ d) 3 = d rather than > unsafeIndex :: V4 a -> Int -> a > unsafeIndex = unsafeField But I can only pass unboxed types to foreign prim. Is this an intrinsic limitation or just an artifact of the use cases that have presented themselves to date?

4 6

Getting the file descriptor of a handle, without closing it
by Volker Wysk 12 Mar '12

12 Mar '12

Hello! A few months ago, I started a discussion about how to extract the file descriptor of a handle, without the side effect of closing the handle. Bas van Dijk kindly provided the following function: unsafeWithHandleFd :: Handle -> (Fd -> IO a) -> IO a (The action in the second argument is applied to the file descriptor of the handle in the first argument.) Now I'm trying to use it, but it appears to have a bug. This program shows it: snip---------------------------------------------------------------------- import IO import GHC.IO.Handle.Types -- haType, haDevice import GHC.IO.Handle.Internals -- withHandle', do_operation import System.Posix.Types -- Fd import System.IO.Error -- ioeSetErrorString import Data.Typeable -- cast import GHC.IO.Exception -- IllegalOperation import GHC.IO.FD hiding (stdin, stdout, stderr) -- fdFD import Foreign.C -- CInt import Control.Concurrent.MVar (MVar) main = do -- Works okay unsafeWithHandleFd stdin $ \fd -> putStrLn ("stdin: fd = " ++ show fd) -- Blocks unsafeWithHandleFd stdout $ \fd -> putStrLn ("stdout: fd = " ++ show fd) -- By Bas van Dijk unsafeWithHandleFd :: Handle -> (Fd -> IO a) -> IO a unsafeWithHandleFd h@(FileHandle _ m) f = unsafeWithHandleFd' h m f unsafeWithHandleFd h@(DuplexHandle _ _ w) f = unsafeWithHandleFd' h w f unsafeWithHandleFd' :: Handle -> MVar Handle__ -> (Fd -> IO a) -> IO a unsafeWithHandleFd' h m f = withHandle' "unsafeWithHandleFd" h m $ \h_@Handle__{haDevice} -> case cast haDevice of Nothing -> ioError (System.IO.Error.ioeSetErrorString (System.IO.Error.mkIOError IllegalOperation "unsafeWithHandleFd" (Just h) Nothing) "handle is not a file descriptor") Just fd -> do x <- f (Fd (GHC.IO.FD.fdFD fd)) return (h_, x) snip---------------------------------------------------------------------- The first call of unsafeWithHandleFd, works as expected. The second one blocks. I need unsafeWithHandleFd, or something similar, in order to port my HsShellScript library (http://volker-wysk.de/hsshellscript/index.html) to the current version of GHC. If someone who understands the internals of the GHC IO libraries, had a hint, or even a fix, I'd be very grateful. Sincerely, Volker Wysk

3 4

Unable to build GHC-7.4.1 on OpenIndiana
by Paul Graphov 11 Mar '12

11 Mar '12

Hello GHC-users! I'm trying to compile GHC-7.4.1 under OpenIndiana and get the following error all the time: ghc.mk:85: *** Make has restarted itself 2 times; is there a makefile bug?. Stop. I googled a bit and found that this can be a result of touching some files during build. But actually no files were touched, I've even restarted compilation from scratch to check it. Currently I have GHC-7.2.2. that was installed via http://pkg.openindiana.org/sfe, GNU Make 3.81 I use "quick" build flavour in build/build.mk (but it doesn't seem to matter) Also i've installed these packages to make it build: pkg install gcc pkg install system/header pkg install developer/library/lint pkg install header-math Thanks.

2 2

Emacs mode for reading Cmm
by Johan Tibell 09 Mar '12

09 Mar '12

Hi, I created a tiny Emacs mode for reading Cmm, which I found myself doing lately. The mode is focused on reading Cmm at the moment, not writing it. Patches are welcome. Installation: 1. Download cmm-mode.el from https://github.com/tibbe/cmm-mode 2. Put the file somewhere on your Emacs load path. 3. Add (require 'cmm-mode) to your Emacs init file. Files ending in .cmm will automatically use the Cmm mode. -- Johan

1 0

How unsafe are unsafeThawArray# and unsafeFreezeArray#
by Johan Tibell 09 Mar '12

09 Mar '12

Hi, I just ran across some code that calls unsafeThawArray#, writeArray#, and unsafeFreezeArray#, in that order. How unsafe is that? * Is it unsafe in the sense that if someone has a reference to the original Array# they will see the value of that pure array change? * Is it unsafe in the sense things will crash and burn? I looked at the implementation of unsafeFreezeArray#, which is emitPrimOp [res] UnsafeFreezeArrayOp [arg] _ = stmtsC [ setInfo arg (CmmLit (CmmLabel mkMAP_FROZEN_infoLabel)), CmmAssign (CmmLocal res) arg ] but I couldn't find any implementation of unsafeThawArray#. Is it a no-op? It seems to me that if unsafeFreezeArray# changes the head of the array heap object so should unsafeThawArray#. Cheers, Johan

5 6

Re: thoughts on the record update problem
by Gershom B 08 Mar '12

08 Mar '12

On Thu, Mar 8, 2012 at 4:52 PM, Greg Weber <greg(a)gregweber.info> wrote: > syntax we would like. Does that make sense? I take it that you agree > that we should separate the discussion of semantics from > implementation: this is a perfect example of why. If we can describe semantics without concern for the possibility/needs of implementation, then I've got some _great_ proposals I'd like to make! --Gershom

1 0

thoughts on the record update problem
by Barney Hilken 08 Mar '12

08 Mar '12

There are actually four problems with overloaded record update, not three as mentioned on the SORF page. This is an attempt to solve them. The SORF update mechanism. ------------------------------ SORF suggests adding a member set to the class Has which does the actual updating just as get does the selecting. So set :: Has r f t => t -> r -> r and r {n1 = x1, n2 = x2} is translated as set @ "n2" x2 (set @ "n1" x1) The Problems. ----------------- 1. It's not clear how to define set for virtual record selectors. For example, we might define data Complex = Complex {re :: Float, im :: Float} instance Has Complex "arg" Float where get r = atan2 r.im r.re but if we want to set "arg", what should be kept constant? The obvious answer is "mod", but we haven't even defined it, and there are plenty of cases where there is no obvious answer. 2. If the data type has one or more parameters, updates can change the type of the record. Set can never do this, because of its type. What is more, if several fields depend on the parameter, for example data Twice a = Twice {first :: a, second :: a} any update of "first" which changes the type must also update "second" at the same time to keep the type correct. No hacked version of set can do this. 3. The Haskel implementation of impredicative polymorphism (from the Boxy Types paper) isn't strong enough to cope with higher rank field types in instances of set. 4. The translation of multiple updates into multiple applications of set is not the same as the definition of updates in the Haskel report, where updates are simultaneous not sequential. This would be less efficient, and in the case of virtual record selectors, it wouldn't be equal, and is arguably incorrect. Point 3 could possibly be fixed by improving the strength of the type system, but SPJ says this is a hard problem, and no-one else seems ready to tackle it. Points 1, 2 & 4 suggest that any solution must deal not with individual fields but with sets of fields that can sensibly be updated together. The Proposed Solution. -------------------------- This is an extension to SORF. I don't know if the same approach could be applied to other label systems. 1. Introduce a new form of class declaration: class Rcls r where r {n1 :: t1, n2 :: t2} is translated as class (Has r n1 t1, Has r n2 t2) => Rcls r where setRcls :: t1 -> t2 -> r -> r setRcls is used internally but hidden from the user. 2. Instances of record classes can use a special form of default. So data Rec = Rec {n1 :: t1, n2 :: t2} instance Rcls Rec is translated as instance Rcls Rec where setRcls x1 y1 (Rec _ _) = Rec x1 y1 provided all the fields in the class occur in the data type with the correct types. In general, the definition of the update function is the same as the Haskel98 translation of update, solving problem 4. 3. The syntax of record updates must be changed to include the class: r {Rcls| n1 = x1, n2 = x2} is translated as setRcls x1 x2 r Updating a subset of the fields is allowed, so r {Rcls| n1 = x1} is translated as setRcls x1 (r.n2) r 4. Non default instances use the syntax: instance Rcls Rec where r {Rcls| n1 = x1, n2 = x2} = ...x1..x2.. which is translated as instance Rcls Rec where setRcls x1 y1 r = ...x1..x2.. in order to allow virtual selectors. This solves problem 1, because updates are grouped together in a meaningful way. An extended example is given below. 5. Record classes can have parameters, so class TwiceClass r where r a {first :: a, second :: a} data Twice a = Twice {first :: a, second :: a} instance TwiceClass Twice translates as class TwiceClass r where setTwiceClass :: a -> a -> r b -> r a data Twice a = Twice {first :: a, second :: a} instance TwiceClass Twice where setTwiceClass x y (Twice _ _) = Twice x y which allows updates to change the type correctly. This solves problem 2. 6. Problem 3 *almost* works. The translation of class HRClass r where r {rev :: forall a. [a] -> [a]} is class Has r "rev" (forall a. [a] -> [a]) => HRClass r where setHRClass :: (forall a.[a] -> [a]) -> r -> r which is fine as far as updating is concerned, but the context is not (currently) allowed by ghc. I have no idea whether allowing polymorphic types in contexts would be a hard problem for ghc or not. None of my attempted work-rounds have been entirely satisfactory, but I might have missed something. Comments ------------- 1. This makes the "special syntax for Has" pretty useless. When you have a set of labels you want to use together, you usually want to use update as well as selection, so it's better to define a record class, and use that. 2. The record classes can also be used for controlling the scope of polymorphic functions. For example, if you want to use a label "name" with the assumption that it refers to the name of a person, define a class class Person r where r {name :: String} and only create instances where the assumption is correct. Any functions polymorphic over the class Person can only be applied to instances you have declared. You can later use the same label for the name of a product class Product r where r {name :: String} but it's a different class with its own instances and the type checker will complain if you apply Person code to Product types. 3. It feels a bit odd to have the class which controls selection functions (Has) automatically defined, once for all, but the classes which control update functions must be defined by the programmer, and instances declared manually. However, I haven't found any way to make any kind of multiple Has class work. Example -------------- The following example illustrates some of the things that are possible with this approach. We want to represent complex numbers as pairs of Floats: data Complex1 = Complex1 {real :: Float, imag :: Float} in order to update records, we define a class: class Cartesian c where c {real :: Float, imag :: Float} instance Cartesian Complex1 but we also want to access complex numbers by modulus and argument, so we define virtual selectors: class Polar c where c {mod :: Float, arg :: Float} instance Has Complex1 "mod" Float where get (Complex1 x y) = sqrt (x * x + y * y) instance Has Complex1 "arg" Float where get (Complex1 x y) = atan2 y x instance Polar Complex1 where _ {Polar| mod = r, arg = th} = Complex1 (r * cos th) (r * sin th) Note that we can update x and y by {Cartesian| real = x, imag = y} or r and theta by {Polar| mod = r, arg = theta} but we cant mix them: there is no way to simultaneously update x and theta, unless we define a new class to do that. We can change the representation to cache mod and arg without changing the classes: data Complex2 = Complex2 {real :: Float, imag :: Float, mod :: Float, arg :: Float} now both update functions are virtual, though none of the selectors are: instance Cartesian Complex2 where _ {Cartesian| real = x, imag = y} = Complex2 x y (sqrt (x * x + y * y)) (atan2 y x) instance Polar Complex2 where _ {Polar| mod = r, arg = th} = Complex2 (r * cos th) (r * sin th) r th Alternatively, we might want to use whichever representation was last updated: data Complex3 = Complex3a {real :: Float, imag :: Float} | Complex3b {mod :: Float, arg :: Float} now everything is virtual: instance Has Complex3 "real" Float where get (Complex3a x y) = x get (Complex3b r th) = r * cos th instance Has Complex3 "imag" Float where get (Complex3a x y) = y get (Complex3b r th) = r * sin th instance Cartesian Complex3 where _ {Cartesian| real = x, imag = y} = Complex3a x y instance Has Complex3 "mod" Float where get (Complex3a x y) = sqrt (x * x + y * y) get (Complex3b r th) = r instance Has Complex3 "arg" Float where get (Complex3a x y) = atan2 y x get (Complex3b r th) = th instance Polar Complex3 where _ {Polar| mod = r, arg = th} = Complex3b r th Sorry this is so long! Barney.

3 9

Records in Haskell: Type-Indexed Records (another proposal)
by Matthew Farkas-Dyck 08 Mar '12

08 Mar '12

Hello all. I wrote a new proposal for the Haskell record system. It can be found at http://hackage.haskell.org/trac/ghc/wiki/Records/TypeIndexedRecords Records are indexed by arbitrary Haskell types. Scope is controlled as scope of key types. No fieldLabel declarations needed (as in DORF). Cheers, strake

2 4