- Glasgow-haskell-users

Re: Records in Haskell
by Matthew Farkas-Dyck 12 Jan '12

12 Jan '12

Certainly not no conflicts: lambda expressions. On 30/12/2011, Colin Adams <colinpauladams(a)gmail.com> wrote: > On 30 December 2011 15:55, Matthew Farkas-Dyck <strake888(a)gmail.com> wrote: > >> On 30/12/2011, Andriy Polischuk <quuxity(a)gmail.com> wrote: >> > Yet another idea: >> > Consider using '\' as record access operator. No conflicts with anything >> at >> > all, and, >> > moreover, it really looks like hierarchical access. Reminds of >> filesystems >> > though. >> >> I hope this is a joke. >> > > Why? >

7 15

Unboxed mutable variables (was: Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?)
by Johan Tibell 12 Jan '12

12 Jan '12

On Thu, Jan 12, 2012 at 12:54 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: > For boxed arrays you need a PrimOp of course (like catMutVar#). For unboxed > arrays you could get away with FFI, but a PrimOp would be better because it > could be inline. But to get it inline would mean modifying the native and > LLVM backends to support CAS operations. > > If I were you I would use FFI for now. The cost of the out-of-line call is > much less than the cost of the CAS anyway. A gcc dependency is not a big > deal, it's available on all Unix-like platforms and I don't see us removing > it from the Windows installs any time soon. In a recent project (http://hackage.haskell.org/package/ekg) I found myself wanting unboxed mutable integers with CAS semantics (to implement simple counters). What would be required to support (1) unboxed mutable variables, and (2) CAS semantics for these. I guess (2) is easy once you have (1). Just add some new primops. -- Johan

2 3

Easiest way to extend CAS (casMutVar#) to boxed/unboxed Vector elements?
by Ryan Newton 12 Jan '12

12 Jan '12

Hello there, I was wondering what the recommendations would be for getting CAS on [mutable] vector elements? I thought that as a first step I might create an a library that does the trick only for unboxed vectors, by using bits-atomic (i.e. FFI + GCC intrinsics). Roman Leshchinskiy recommended against depending on GCC. He thought, therefore, that not only boxed arrays but unboxed ones would need an extra PrimOp to be handled properly: > You can't rely on gcc extensions because code is usually compiled with the > native code generator nowadays and doesn't go through gcc. The dependency > on gcc will (hopefully) be dropped eventually anyway. So you'd probably > also want primops for unboxed arrrays and Addr#. Any advice? Thanks, -Ryan

2 1

Re: Unit unboxed tuples
by Dan Doel 11 Jan '12

11 Jan '12

Copying the list, sorry. I have a lot of trouble replying correctly with gmail's interface for some reason. :) On Tue, Jan 10, 2012 at 11:14 AM, Dan Doel <dan.doel(a)gmail.com> wrote: > On Tue, Jan 10, 2012 at 5:01 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> On 09/01/2012 04:46, wren ng thornton wrote: >>> Shouldn't (# T #) be identical to T? >> >> No, because (# T #) is unlifted, whereas T is lifted. In operational terms, >> a function that returns (# T #) does not evaluate the T before returning it, >> but a function returning T does. This is used in GHC for example to fetch a >> value from an array without evaluating it, for example: >> >> indexArray :: Array# e -> Int# -> (# e #) I don't really understand this explanation. (# T #) being unlifted would mean it's isomorphic to T under the correspondence e <-> (# e #). _|_ = (# _|_ #) : (# T #), so this works. Does the difference have to do with unboxed types? For instance: foo :: () -> Int# foo _ = foo () bar :: () -> (# Int# #) bar _ = (# foo () #) baz = case bar () of _ -> 5 -- 5 quux = case foo () of _ -> 5 -- non-termination Because in that case, either (# Int# #) is lifted, or the Int# is effectively lifted when inside the unboxed tuple. The latter is a bit of an oddity. -- Dan

5 6

kinds for `*'
by Serge D. Mechveliani 11 Jan '12

11 Jan '12

People, GHC provides some extensions for kinds. Does this make possible different kinds, for example, for `*' ? Prelude.Num has * :: a -> a -> a. And mathematicians also like to denote as `*' (\cdot in TeX) a "multiplication of a vector v by a coefficient r". It is expressed by the declaration class (Num r, ...) => LeftModule r v where * :: r -> v -> v Regards, ------ Sergei mechvel(a)botik.ru

2 1

Unit unboxed tuples
by Simon Peyton-Jones 10 Jan '12

10 Jan '12

Dear GHC users I've just discovered something very peculiar with unboxed tuples in GHC. f2 x = (# True, False #) f1 x = (# True #) f0 x = (# #) What types do these functions have? f2 :: a -> (# Bool, Bool #) f1 :: a -> (# Bool #) BUT f0 :: a -> b -> (# b #) I think this is stupid. It should be f0 :: a -> (# #) But in fact even that type isn't what you expect (ie the analogue of f :: a -> () ) Here are the kinds of the type constructors: (,,) :: * -> * -> * -> * (,) :: * -> * -> * () :: * (# ,, #) :: * -> * -> * -> # (# , #) :: * -> * -> # BUT (# #) :: * -> # In both respects unboxed unit tuples are behaving differently to boxed ones. This seems bonkers. I propose to fix this, but I wanted to check if anyone is relying on the current odd behaviour. Simon

10 17

More primops for integer arithmetic with overflow reporting
by Herbert Valerio Riedel 10 Jan '12

10 Jan '12

Hello GHC HQ, As the {Int,Word}{,8,16,32,64} types in Haskell are usually regarded to follow modulo arithmetic (w.r.t. to the Num-class ops), I was trying to implement efficient non-modulo Safe{Int,Word}{,8,16,32,64} types which would throw exceptions when the result falls outside the value domain representable. As ISAs often have hardware support to detect such overflows (e.g. on x86-64 via the OF/CF flags), I guess that by exploiting hardware support, this might allow for a reasonably efficient implementation of non-modulo integer arithmetic. So far I've only found 'addIntC#' and 'subIntC#' which perform the kind of operation I'm looking for. But this is only for signed integers, and as far as multiplication is concerned, there's a 'mulIntMayOflo#' but that may provide false negatives according to the documentation. Therefore, I was wondering whether it'd make sense for GHC to provide more primops for the {Int,Word}{,8,16,32,64} types which return the result value together with an overflow-flag. Thanks, hvr

2 1

renamed GMP symbols in GHC
by Michal Konečný 10 Jan '12

10 Jan '12

Dear all, Several issues related to the way GMP is included in GHC were publicly discussed in the past with the goal of replacing GMP. As summarised in this wiki by Peter Tanski, the main issues were: (1) Licensing (2) Memory Structure; Simultaneous Access to GMP by Foreign (C) code in the Same Binary. My immediate concern is (2) as I develop programs that link with MPFR, which uses GMP. So far I got around the issue by compiling GHC with integer-simple. This is fine for me but I feel the need to recompile ghc may be hindering some people who would like to try my software that links with MPFR. I have therefore been looking for a way to overcome (2) that could make it to the default build of GHC. As suggested by Simon PJ in this email, a simple way to deal with issue (2) is to "*copy* GMP, changing all the function names". I recently found some time and had a go at implementing this suggestion and it turned out to be quite easy. I described my recipe to do such a "copy" here but currently I have been able to test it only on x86 Linux and GHC 7.2.1. I checked that the renaming makes a difference by running all QuickCheck tests of my AERN-Real-MPFR package. Some of these tests persistently fail when compiled with a standard GHC. All tests succeed with GHC/integer-simple and also with GHC 7.2.1 using the renamed GMP. I was wondering whether such a change (more polished and tested on all common platforms) could make it to the future official GHC releases. If the GHC developers would support this change, I would be happy to put more work into it. I think the following concrete changes would be required in the GHC distribution: (a) make a ghc build always use the bundled GMP (b) apply a renaming script onto the GMP tar before adding it to the GHC source bundle (c) rename symbols analogously in integer-gmp/cbits/* An alternative to (b) is to apply the renaming to the GMP sources just before building it. One thing I am not clear about is the impact such a change would have on lincensing. My understanding is that GHC sources include GMP sources and in the absence of an installed GMP library, they are statically linked into the integer-gmp package. (Does it mean that the integer-gmp package should be LGPL lincensed?) The suggested changes would mean that this kind of linking would happen always, not only when no other GMP library is available on the system. In either case, it seems to me that using integer-gmp as a shared library would still be OK for producing non-LGPL code. I would be grateful for your views and guidance. Best regards, Michal -- |o| Michal Konecny <mikkonecny(a)gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston

9 20

GHC 7.0.4 recursion while trying to derive type
by Bogdan Opanchuk 10 Jan '12

10 Jan '12

Hello, Consider the following code: {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, OverlappingInstances, UndecidableInstances, FunctionalDependencies #-} class Container a b | a -> b where make :: b -> a data Cont a = Cont a deriving (Show, Eq) instance Container (Cont a) a where make x = Cont x -- Part A instance (Container a b, Show a, Eq a, Num b) => Num a where fromInteger x = make (fromInteger x) d = fromInteger 3 :: Cont Integer -- Part B class Convertable a where fromInt :: Integer -> a instance Convertable Integer where fromInt = id instance (Container a b, Convertable b) => Convertable a where fromInt x = make (fromInt x) e = fromInt 3 :: Cont Integer main = do print d print e Part A and B are basically the same, the only difference being that A uses existing Num typeclass, and B creates a new one. The problem is that it compiles and works in GHC 7.2.2, but in 7.0.4 (which is the one included in the most recent Haskell Platform, that's why I bumped into this issue) part A generates the following error: t4.hs:17:31: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dNum :: Num b19 [ skipped ] $dNum :: Num b0 In the first argument of `make', namely `(fromInteger x)' In the expression: make (fromInteger x) In an equation for `fromInteger': fromInteger x = make (fromInteger x) My understanding is that in line "fromInteger x = make (fromInteger x)" compiler should take into account that 1) the signature for make is "make :: b -> a" 2) type b is known at the moment of creating instance (because a == Cont Integer, which is an instance of Container (Cont Integer) Integer). and cast "fromInteger x" to type b and pass it to make. In 7.0.4 part B (which is based on the same idea) works correctly, so it may have something to do with how fromInteger is defined in GHC guts. So, the question is, could anyone please tell me, is what I am trying to do actually correct, and what was changed from 7.0.4 to 7.2.2 to make it work? Thank you in advance. Best regards, Bogdan

3 5

ConstraintKinds and default associated empty constraints
by Bas van Dijk 09 Jan '12

09 Jan '12

I'm playing a bit with the new ConstraintKinds feature in GHC 7.4.1-rc1. I'm trying to give the Functor class an associated constraint so that we can make Set an instance of Functor. The following code works but I wonder if the trick with: class Empty a; instance Empty a, is the recommended way to do this: {-# LANGUAGE ConstraintKinds, TypeFamilies, FlexibleInstances #-} import GHC.Prim (Constraint) import Prelude hiding (Functor, fmap) import Data.Set (Set) import qualified Data.Set as S (map, fromList) class Functor f where type C f :: * -> Constraint type C f = Empty fmap :: (C f a, C f b) => (a -> b) -> f a -> f b class Empty a; instance Empty a instance Functor Set where type C Set = Ord fmap = S.map instance Functor [] where fmap = map testList = fmap (+1) [1,2,3] testSet = fmap (+1) (S.fromList [1,2,3]) Cheers and thanks for a great new feature! Bas

9 22