- Haskell - Haskell.org

Re: Why is there a space leak here?
by Steinitz, Dominic J 05 Jun '01

05 Jun '01

I'd love it if someone could write a tutorial paper on space leaks. Even with the explanations that have been provided, I find it difficult to understand why expressions get evaluated in a particular order and why garbage collections happen at a given point. Dominic. ------------------------------------------------------------------------------------------------- 21st century air travel http://www.britishairways.com

1 0

Advantages of Paper
by George Russell 05 Jun '01

05 Jun '01

I don't want to seem incredibly Luddite, but there are some things the World Wide Web is not good at, and one of them is permanence. Try for example finding out about Glasgow Haskell from http://www.dcs.gla.ac.uk, which was I think the standard URL a few years ago. In 2050 we may not even have a World Wide Web (remember Gopher?), or if we do URLs as we have them may be as outdated as those e-mail addresses I remember which included lots of percent signs telling the network to send your message to Birmingham via Beachy Head. I find it therefore of concern that many crucial Haskell documents, including the standard and, for example, the various Glasgow Haskell manuals, are only available online. I therefore suggest that they at least be printed out in the form of technical reports, and made available in this form to libraries, which are well-used to storing information long-term. Otherwise the curious in 2050 will be able to locate manuals for FORTRAN II and Simula (as I can do in 5 minutes in the local library), but getting Haskell documentation will be about as easy as reading 5-track paper tape. I don't think it matters if Haskell itself is obsolete in the year 2050, as it probably will be. But it will be a pity if most of the papers written using it are hard to figure out because the documentation itself is missing.

4 4

A pecular algebraic data structure
by Jan Skibinski 05 Jun '01

05 Jun '01

I've been working with one pecular algebraic data structure, named Register, which is described in currently upgraded http://www.numeric-quest.com/haskell/QuantumComputer.html. or in gzipped version of the same document http://www.numeric-quest.com/haskell/QuantumComputer.html.gz. Section 13 of that document outlines the background for the topic of this message. But the section is just way too long to quote it in here. But to summarize it: data Register is pecular because it is indexable but not observable in a standard way, and because two different representations can describe the same state. In theory there should be well defined transformation from one representation to another. This seems to me as a good subject for some research work. Granted that there are many experts on functional data structures out there (I do not want to pressure any of you gurus, so I am not naming anyone :-)), could you please look at the write-up and help me with the following questions? + Is the Register data structure strangely unique, or does it fit somewhere into a hierarchy of known functional data structures? I would be happy to learn that the latter is the case, since I could then start looking at it at a more formal, well known and tested way. + Is a non-uniqness of representation amenable to formal treatment, such as deforestation? Jan

1 0

proof in haskell ?
by luc 04 Jun '01

04 Jun '01

chapter 12 of birds book mention mike spivey' theorem prover. are there anything available in source code about proof in haskell ? (btw , haskell is a great language ! one of the rare that try to "improve lazyness " ! (chaperter 11) thanks Luc

2 1

GHC core representation
by Andrew Tolmach 04 Jun '01

04 Jun '01

Dear Haskellers, Many months after the topic was first raised, there is finally a draft document describing a formal external syntax for GHC's "Core" intermediate language. It is available from http://www.cs.pdx.edu/~apt/ext-core.ps Those who wish to experiment seriously with the format described can download the latest "HEAD" experimental version of GHC. Using the "-fext-core" option when compiling "foo.hs" will generate a file "foo.core" (in additition to any other outputs specified). The document currently gives only an informal semantics "Core;" a much more formal semantics -- which I view as a very important thing to have in practice -- is in progress but not quite ready for public scrutiny. As this is very much a draft (you'll see the holes!), feedback is welcome, but due to the GHC-internals nature of this topic, please direct your comments to glasgow-haskell-users(a)haskell.org or to me personally at apt(a)cs.pdx.edu. I'll be out of email contact for the next month, though, so don't expect replies until July! - Andrew Tolmach

1 0

Re: A problem with the typing system.
by Marcin 'Qrczak' Kowalczyk 03 Jun '01

03 Jun '01

Sat, 02 Jun 2001 23:03:29 +1000, Sean Seefried <s350366(a)student.uq.edu.au> pisze: > zero = \s z ->z > succ x = \s z -> s x (x s z). > > I don't think it's important that I explain why I want the extra > occurrence of x there. I don't understand what the extra x means, so I can only explain what errors mean. I don't know what do you want to archieve. > Occurs check: cannot construct the infinite type: > t = (t -> t3 -> t2) -> t2 -> t1 The type of 's' is requested to take as its first argument 'x', which is a function which takes as its first argument 's' again. So the type of 's' would have to appear as a proper part of itself. > data Church = Ch (forall a.(a -> a -> a) -> a -> a) I would expect data Church = Ch (forall a. (a -> a) -> a) but perhaps it has something to do with your extra 'x'... > succ x = Ch(\s z -> s x (unCh x s z) > > which gives the strange typing error: > > Inferred type is less polymorphic than expected > Quantified type variable `a' is unified with `Church' The constructor Ch has type (forall a. (a -> a -> a) -> a -> a) -> Church and must be applied to a value which is polymorphic itself, i.e. which could be assigned the type '(a -> a -> a) -> a -> a' for any 'a', without knowing anything about the particular choice of 'a'. The type allows a user of the resulting Church value to choose any type for 'a' and use this argument on this type - that's why it must work for all of them. But \s z -> s x (unCh x s z) doesn't have sufficiently general type: 'x' has type Church (because 'unCh' is applied to 'x'), so 's' takes only Church as argument, so what should happen if the user instantiates it with something other than Church? > Is this sort of typing possible within Haskell. I don't know how it's supposed to behave with the extra 'x', so I can't tell what type it could have. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

A problem with the typing system.
by Sean Seefried 02 Jun '01

02 Jun '01

Dear Haskell users, I am playing around with a variation of the Church numerals and it is giving me grief. Usually the definitions for Church numerals appear as follows. zero = \s z -> z succ x = \s z -> s (x s z) But what I would like to do is define them this way. zero = \s z ->z succ x = \s z -> s x (x s z). I don't think it's important that I explain why I want the extra occurrence of x there. Just typing this in hugs or ghci gives problems. In ghci the error message is Occurs check: cannot construct the infinite type: t = (t -> t3 -> t2) -> t2 -> t1 Expected type: t Inferred type: (t -> t3 -> t2) -> t2 -> t1 In the first argument of `x', namely `s' In the second argument of `s', namely `(x s z)' I know about rank-2 polymorphic types. (I don't really understand it but I have used them). I attempted to create a type with the following declaration. data Church = Ch (forall a.(a -> a -> a) -> a -> a) I declared an unCh unCh (Ch a) = a I then declared succ as succ x = Ch(\s z -> s x (unCh x s z) which gives the strange typing error: Inferred type is less polymorphic than expected Quantified type variable `a' is unified with `Church' Signature type: forall a. (a -> a -> a) -> a -> a Type to generalise: (Church -> Church -> Church) -> Church -> Church When checking an expression type signature In the first argument of `Ch', namely `(\ s z -> s x (unCh x s z))' in the definition of function `succ': Ch (\ s z -> s x (unCh x s z)) Doesn't the "type to generalise" fit within the framework of forall a.(a->a->a) ->a ->a. Why should it matter if something is _less_ polymorphic than expected. This is something I do not understand. Now, if I modify the definition to succ = \s z -> s x (unCh x s z) I can at least load the file. succ zero gives me _no_ typing errors. However succ (succ zero) gives me a typing error again. (And I know why) Because the type of succ zero is "(Church -> Church -> Church) -> Church -> Church" and not just simply "Church". (that is what the constructor Ch is supposed to do but it complains of the typing being less polymorphic than expected). Is this sort of typing possible within Haskell. I realise that it is sort of an infinite data type but in my opinion these sorts of things should be able to be typed. Thanks in advance. Sean Seefried.

1 0

fromInteger
by Saswat Anand 01 Jun '01

01 Jun '01

Hi, I can't understand how the arithmatic operators like (+),(-) are defined and fromInteger works in that context. Type Fun a = Int -> a fun :: Fun Int fun = (+1) instance (Num a) => Num (Fun a) where ......... (fun + 2) 10 and (2 + fun) 10 works fine. But how does it know it has to use fromInteger? But If I want these, (Just 2 + fun) 10 and (fun + Just 2) 10 to work, then is there a way to tell which conversion function to use? Thanks, Saswat

1 0

Re: Haskell 98 Report
by Marcin 'Qrczak' Kowalczyk 01 Jun '01

01 Jun '01

31 May 2001 16:10:43 -0600, Alastair David Reid <reid(a)cs.utah.edu> pisze: > and > > if foo has type > > foo :: (Ord a) => ty > > then fooBy has type > > fooBy :: (a -> a -> Bool) -> ty It's (a -> a -> Ordering) -> ty, with the default value being compare. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: fromInteger
by Marcin 'Qrczak' Kowalczyk 01 Jun '01

01 Jun '01

Fri, 1 Jun 2001 15:25:24 -0700, Saswat Anand <iscp9157(a)nus.edu.sg> pisze: > I can't understand how the arithmatic operators like (+),(-) are = > defined and fromInteger works in that context. They are all in class Num. fromInteger is automatically inserted before all integer literals, e.g. '42' is equivalent to 'fromInteger (42::Integer)' and has type 'Num a => a', i.e. the context can provide any numeric type and 42 will have that type by using the appropriate fromInteger. > Type Fun a = Int -> a > > fun:: Fun Int > fun = (+1) > > instance (Num a) => Num (Fun a) where > ......... > > (fun + 2) 10 and (2 + fun) 10 works fine. But how does it know it > has to use fromInteger? (+):: Num a => a -> a -> a >From this type it follows that both arguments of '+' must have the same type (and that this type must be Num). The first argument of '+' in 'fun + 2', i.e. 'fun', has a fully determined type: 'Fun Int'. It follows that the second argument of '+', i.e. '2', must be 'Fun Int' too. It's an integral literal, so it can have any Num type. Unifying 'Num a => a' with 'Fun Int' succeeds and gives an answer what 'a' is here: it's 'Fun Int', and it's ok because it's Num. > But If I want these, > (Just 2 + fun) 10 and (fun + Just 2) 10 > to work, then is there a way to tell which conversion function > to use? No: 'Just 2' has type 'Num a => Maybe a', 'fun' has type 'Fun Int', i.e. 'Int -> Int'. In no way 'Maybe something' can be the same type as 'arg -> result'. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0