September 2005 - Haskell-Cafe

RE: [Haskell-cafe] Nofib documentation
by Simon Peyton-Jones 19 Sep '05

19 Sep '05

I don't think there's a nofib reference document. (Would someone like to write one?) The standard/slow/fast inputs are meant to vary the input data to the benchmarks so they take more or less time. Not all programs are set up that way because we didn't write all of them, and don't necessarily understand how they work. Any help in getting slow/fast data for programs currently lacking them would be great. Simon ________________________________ From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Monique Louise Sent: 17 September 2005 13:51 To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] Nofib documentation Hi all. does anyone know where can I find a better documentation for Nofib benchmark? Is there any reference which contains the "standard" and "slow" inputs? In the CVS tree I just found the standard/slow/fast outputs. Thanks in advance, -- ________________________________ Monique Louise B.Monteiro Msc Student in Computer Science Center of Informatics Federal University of Pernambuco

1 0

RE: [Haskell-cafe] generics question, logical variables
by Ralf Lammel 19 Sep '05

19 Sep '05

Hi Frederik, [I call this "the dreadful lack of kind polymorphism strikes back" :-)] I put SPJ on cc; perhaps he can suggest a way to improve in this area. Based on input, I could try to work on this issue in the not so remote future. Let me briefly recapitulate. My recollection is that deriving works for Typeable, Tyepable1, ..., if all type parameters are of type kind "*". Whenever you can derive a Typeablen instance with n > 0, you can instead ask for Typeable to be derived. The reason why you cannot get both a Typeable and say a Typeable42 instance is that there are generic instances for getting an "n-1 instance" from the "n instance". However, this is also precisely the reason why you don't want them both. That is, you get everything you can ask for, if you have the "n instance" for the actual arity of the type constructor in question. (Getting a smaller n or no n just means that you limit polymorphic type case.) Recall that you *may* need a n>0 instance if you want to do polymorphic type case according to the SYB2 paper. As long as you are fine with monomorphic generic function extension, the plain Typeable instance should be fine. However, the real limitation is here, *indeed*, as said, that GHC does not derive Typeable[1|2|...] for parameter kinds other than "*". This was the reason that I had to hand-code some Typeable instances in your original example. Let us also be honest about another limitation of the current deriving code. "deriving Data" gives you Data instances that do *not* support polymorphic type case. That is the following code prints 0, 1, 0 whereas you may expect 0, 1, 2. newtype Foo x = Foo x deriving (Typeable, Data) f :: Data a => a -> Int f = const 0 `ext1Q` (\(_::Maybe x) -> 1) `ext1Q` (\(_::Foo y) -> 2) main = do print $ f True print $ f (Just True) print $ f (Foo (Just True)) This is the reason that I had to handcode some Data instances in your original example, which wasn't hard BTW. We thought that these two limitations were Ok since we didn't expect people to write many polymorphic datatype constructors on which SYB should work. Sounds like a feature request. Now I wonder how much work it is to improve the situation. We need to make the GHC deriving code a bit more kind-aware. I guess we are still not at the point where we want to add kind polymorphism to Haskell? Would be a nice topic for future work on SYB. Clearly, the GH folks have done splendid work in this area. Getting full-blown kind polymorphism in normal Haskell though seems to be less of a topic, simply because we do not have many scenarios around that would *really* require it. Does anyone want to speak up and mention scenarios that would benefit from kind polymorphism? (In Haskell, we are likely to see kind polymorphism, if at all, in the form of type classes whose type parameters can be of different, perhaps of all kinds.) Frederik, for the time being I propose to look into TH code for deriving Tyepable/Data instances and to make it fit for your purposes. There are several versions of Ulf Norell's code around. You may also use SYB3 with the TH code that readily comes with it. Thanks for bringing this up. Regards, Ralf > -----Original Message----- > From: Frederik Eaton [mailto:frederik@a5.repetae.net] > Sent: Sunday, September 18, 2005 7:50 PM > To: Ralf Lammel > Cc: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] generics question, logical variables > > Hi Ralf, > > I'm revisiting this project and just have another question. The story > seems to be that GHC cannot derive Typeable1, or Typeable when > Typeable1 is available - so anyone who wants to use ext1Q must define > special instances for all of the datatypes they use, is this correct? > Will this change soon? > > Aside from that, your 'idify' in PseudoFmap2 certainly seems to have > the correct type for this application. However, the absence of > automatic derivation is somewhat of an impediment. > > Thanks for your help. > > Frederik > > On Tue, Aug 30, 2005 at 02:25:08PM -0700, Ralf Lammel wrote: > > Frederik, > > > > > As for your code example, it looks very interesting, but are you > > > saying that this could turn into an extension of the Data.Generics > > > library, or that this is something I could be implementing in terms of > > > what's already there? > > > > The posted code works with GHC 6.4 (SYB2) intentionally and actually. I > > have attached another attempt (again GHC 6.4, based on SYB2) which might > > be more useful for your purposes, and it may be useful in general, in > > fact. > > > > What I defined this time is a "certainty-improving" function: > > > > idify :: (Typeable1 f, Monad m, Data (a f), Data (a Id)) > > => (forall a. f a -> m a) -> a f -> m (a Id) > > > > That is, the function "idify get" takes a value whose type is > > parameterized in a type constructor f (such as Maybe or IORef), and the > > function attempts to establish Id instead of f on the basis of the > > function argument "get". > > > > > What is the 'a' parameter for in "force"? > > > > > > force :: ( Data (t Maybe a) > > > , Data (t Id a) > > > , Term t Maybe a > > > , Term t Id a > > > ) => t Maybe a -> t Id a > > > > The previous attempt was a more parameterized blow than required in your > > case. (I was guessing about what "typed logical variables" could mean. > > I was assuming that you would need some extra layer of embedding types > > on top of the Haskell term types. Looking at your code, this was not the > > case.) > > > > > For the part which I asked for help with, to get around my trouble > > > with generics, I defined a class GenFunctor and an example instance. > > > The intent is that generics should be able to provide this > > > functionality automatically later on, but you can see what the > > > functionality is. > > > > Let's look at the type of your GenFunctor: > > > > class GenFunctor f where > > gfmapM :: (Monad m, FunctorM b) => (forall x . a x -> m (b x)) -> f > > a -> m (f b) > > > > This type can be seen as a more relaxed version of the idify operation > > above. That is, idify fixes GenFunctor's b to Id. The particular > > encoding of idify (attached) takes advantage of this restriction. I > > wonder whether I should bother. (Exercise for reader :-)) > > > > > However, I am stuck on something else, the program doesn't typecheck > > > because of use of another function I defined, 'cast1'. Maybe you can > > > take a look. I had thought that I would be able to write a generic > > > 'unify' but I get the error: > > > > > > GenLogVar.hs:82:19: > > > Ambiguous type variable `a' in the constraint: > > > `Data a' arising from use of `cast1' at GenLogVar.hs:82:19-23 > > > Probable fix: add a type signature that fixes these type > > variable(s) > > > > > > This is because I need to do something special when I encounter a > > > "Var" variable in unification, but the compiler seems to not like the > > > fact that the type argument of the Var data type is not known. > > > > Please try to avoid new cast operations at all costs. :-) > > Your code can be arranged as follows: > > > > (i) Use extQ1 to dispatch to a special case for "Var x" for the first > > argument. (ii) In this special case, use again ext1Q to dispatch to a > > special case for "Var y" for the second argument. (iii) At this point, > > *cast* the variable value of *one* variable to the type of the other. > > > > So the problem with your code, as it stands, is that the target type of > > cast is ambiguous because you cast *both* arguments. The insight is to > > make the cast asymmetric. Then, not even polymorphism is in our way. > > > > Interesting stuff! > > > > Ralf > > > > > > -- > http://ofb.net/~frederik/

2 1

RE: [Haskell-cafe] generics question, logical variables
by Simon Peyton-Jones 19 Sep '05

19 Sep '05

Ralf, I'm a bit snowed under at the moment with the POPL PC meeting, but I'm quite open to changing GHC's "deriving" behaviour. It's not hard to change. The hard thing is figuring out just what the specification should be. So if you and others are able to evolve a better design, I'd be happy to implement it. (And of course think about it too.) I'm afraid that full-blown kind polymorphism is probably a bit of a stretch, though it comes up every now and again. So the best monomorphic compromise would be good. There's also the question of whether we should make any changes in GHC's libraries to take SYB3 (using classes) into account... Simon | -----Original Message----- | From: Ralf Lammel | Sent: 19 September 2005 04:34 | To: frederik(a)ofb.net | Cc: haskell-cafe(a)haskell.org; Simon Peyton-Jones | Subject: RE: [Haskell-cafe] generics question, logical variables | | Hi Frederik, | | [I call this "the dreadful lack of kind polymorphism strikes back" :-)] | | I put SPJ on cc; perhaps he can suggest a way to improve in this area. Based on input, I could try to | work on this issue in the not so remote future. | | Let me briefly recapitulate. My recollection is that deriving works for Typeable, Tyepable1, ..., if all | type parameters are of type kind "*". Whenever you can derive a Typeablen instance with n > 0, you | can instead ask for Typeable to be derived. The reason why you cannot get both a Typeable and say a | Typeable42 instance is that there are generic instances for getting an "n-1 instance" from the "n | instance". However, this is also precisely the reason why you don't want them both. That is, you get | everything you can ask for, if you have the "n instance" for the actual arity of the type constructor in | question. (Getting a smaller n or no n just means that you limit polymorphic type case.) Recall that | you *may* need a n>0 instance if you want to do polymorphic type case according to the SYB2 paper. | As long as you are fine with monomorphic generic function extension, the plain Typeable instance | should be fine. | | However, the real limitation is here, *indeed*, as said, that GHC does not derive Typeable[1|2|...] for | parameter kinds other than "*". This was the reason that I had to hand-code some Typeable instances | in your original example. | | Let us also be honest about another limitation of the current deriving code. "deriving Data" gives you | Data instances that do *not* support polymorphic type case. That is the following code prints 0, 1, 0 | whereas you may expect 0, 1, 2. | | newtype Foo x = Foo x deriving (Typeable, Data) | | f :: Data a => a -> Int | f = const 0 | `ext1Q` (\(_::Maybe x) -> 1) | `ext1Q` (\(_::Foo y) -> 2) | | main = do | print $ f True | print $ f (Just True) | print $ f (Foo (Just True)) | | | This is the reason that I had to handcode some Data instances in your original example, which wasn't | hard BTW. We thought that these two limitations were Ok since we didn't expect people to write many | polymorphic datatype constructors on which SYB should work. Sounds like a feature request. | | Now I wonder how much work it is to improve the situation. We need to make the GHC deriving code | a bit more kind-aware. I guess we are still not at the point where we want to add kind polymorphism | to Haskell? Would be a nice topic for future work on SYB. Clearly, the GH folks have done splendid | work in this area. Getting full-blown kind polymorphism in normal Haskell though seems to be less of a | topic, simply because we do not have many scenarios around that would *really* require it. | | Does anyone want to speak up and mention scenarios that would benefit from kind polymorphism? (In | Haskell, we are likely to see kind polymorphism, if at all, in the form of type classes whose type | parameters can be of different, perhaps of all kinds.) | | Frederik, for the time being I propose to look into TH code for deriving Tyepable/Data instances and to | make it fit for your purposes. There are several versions of Ulf Norell's code around. You may also use | SYB3 with the TH code that readily comes with it. | | Thanks for bringing this up. | | Regards, | Ralf

1 0

Dread __DISCARD__
by Wolfgang Thaller 19 Sep '05

19 Sep '05

> I'm on Mac OS 10.4.2, using ghc 6.4 (from the haskell.org .dmg) and > gcc 4.0.0. Other wxHaskell programs (the samples and my own > experiments) compile without tripping over this. GHC 6.4 is incompatible with gcc 4.0.0 when -O or -via-C is used. You can work around this problem by either not using -via-C and always adding -fasm *after* -O, or by setting your default compiler to gcc-3.3 using sudo gcc_select 3.3 ... but be aware that this also affects other C compilations; switch back using sudo gcc_select 4.0 I suspect that you compiled the program with -O before, and then switched to -O0 without removing your .o files. If you compiled wxHaskell yourself, then the problem might also be in wxHaskell (you'd have to recompile it then). The upcoming GHC 6.4.1 will of course fix this problem. Cheers, Wolfgang

3 2

Eq Type Class: Overloading (==)
by Tom Hawkins 18 Sep '05

18 Sep '05

Hello, Is it possible to overload (==) to a type other than a -> a -> Bool? I have an abstract datatype that somewhat behaves like a C integer: a comparison returns a boolean represented as the same datatype: (==) :: my_type -> my_type -> my_type Thanks for any help! -Tom

9 12

Nofib documentation
by Monique Louise 17 Sep '05

17 Sep '05

Hi all. does anyone know where can I find a better documentation for Nofib benchmark? Is there any reference which contains the "standard" and "slow" inputs? In the CVS tree I just found the standard/slow/fast outputs. Thanks in advance, -- ________________________________ Monique Louise B.Monteiro Msc Student in Computer Science Center of Informatics Federal University of Pernambuco

1 0

Re: [Haskell] Re: [Haskell-cafe] Haskell versus Lisp
by David F. Place 17 Sep '05

17 Sep '05

On Sep 16, 2005, at 6:26 PM, Glynn Clements wrote: > Haskell's safety and > consistency can get in the way, while Lisp's freedom can be quite > unsafe and inconsistent. I have many years of experience designing and implementing commercial software in lisp and I strongly agree with the second part of this sentence. However, my more recent experience with Haskell makes me doubt very much the first part. Haskell's powerful type system hasn't in the least cramped my style and lazy evaluation eliminates 99% of the need for macros in lisp. (The other 1% is syntactic sugar of doubtful utility.) Since Haskell supports recursive polymorphic types it can easily handle all of the metaprogramming problems where lisp first made its mark. I don't see any reason to continue to use lisp. ps. This thread was on Haskell-cafe which seems more appropriate, so I'm bringing it back. -------------------------------- David F. Place mailto:d@vidplace.com

2 1

Use Haskell to extract GXL representation
by Sara Kenedy 17 Sep '05

17 Sep '05

Dear you all, Currently, I am working with Haskell and GXL file (Graph eXchange Language). GXL is a sublanguage of XML and its syntax is based on XML DTD. 1) In my work, I use GXL representation to represent a quantification (e.g. forall(x:Z|x = 3 and x^2 - 3x + 2 =0)) 2) My objective is to write a Haskell module to extract the content of the GXL file such that a prover theorem (e.g, ICS) and a computer algebra system (e.g, Matlab) can read the content of GXL file. If any of you have experiences or any ideas about the problem, please share with me. I really appreciate for that.Thanks a lot. Sara.

2 1

Use Haskell to extract GXL file (GXL representation)
by Sara Kenedy 16 Sep '05

16 Sep '05

Dear you all, Currently, I am working with GXL file (Graph eXchange Language). GXL is a sublanguage of XML and its syntax is based XML DTD. In my work, I use GXL representation to represent a quantification: forall(x:Z|x = 3 and x^2 - 3x + 2 =0) My objective is to write a Haskell module to extract the content of the GXL file such that a computer algebra system (e.g, Matlab) or a prover theorem (e.g, ICS) can read the content of GXL file. Anybody

1 0

killing a running thread interactively
by S. Alexander Jacobson 16 Sep '05

16 Sep '05

If I am running a server interactively. (using ghci). Is there any way to kill its running threads without terminating the interpreter? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0