February 2004 - Haskell

RE: [Haskell] GHC Core & backend
by Simon Peyton-Jones 23 Feb '04

23 Feb '04

I don't see why it should be hard to use GHC's back end in this way. GHC's core language is pretty stable. I don't find the external representation of Core very appealing, but it's really meant for computers not people. An important constraint is that Core is *typed*, so you'd need a front end that kept type information around. Best thing would be to try a small experiment, to climb the learning curve a bit. Compile some little programs with GHC and see what Core they produce. Try generating a little Core. And so on. Kirsten Chevalier has quite a bit of experience of producing External Core using GHC, transforming it externally, and stuffing it back into GHC. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Arjan van | IJzendoorn | Sent: 13 February 2004 12:43 | To: haskell(a)haskell.org | Subject: [Haskell] GHC Core & backend | | Hello all, | | Is anybody using GHC's backend as a backend for their own compiler? | | In the paper "An external representation for the GHC Core Language" the | introduction states that "there are many (undocumented) idiosyncracies in | the way GHC produces Core from source Haskell". And that "it will be hard to | produced Core that can be integrated with GHC-produced core, and we don't | aim to support this". Has this changed since the time of writing this paper? | | It would be cool if, let's say, Helium (http://www.cs.uu.nl/helium) could | use all of GHC's libraries... | | Regards, Arjan van IJzendoorn | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [Haskell] Compiling HXmlToolbox-3.01 on Mac OS X
by Sachin Desai 23 Feb '04

23 Feb '04

I've found that if I modify the Makefile and include -i<path-to-md5-directory> everything compiles and links fine. I did however have to make a small change to MD5.lhs removing the then clause. I don't believe this was correct but nevertheless it does compile and programs run. #ifdef __GLASGOW_HASKELL__ #define rotL rotateL #include "Zord64_EASY.hs" #else Could someone more knowledgeable explain what compiler flag, if any, is needed for the compilation to succeed with the above statement. I presume the problem was that MD5 was compiled "differently" than expected. The package as it came would not compile, make returned with nothing needs to be made, so I had to manually compile the file with the commands in the Makefile. -- Sachin On Feb 23, 2004, at 4:10 AM, Uwe Schmidt wrote: > Sachin Desai schrieb: > >> Has anyone successfully compiled this Toolbox on Mac OS X (10.3.2)? >> I've installed ghc made through darwinports, compiled and installed >> MD5 >> and am getting errors when building the toolbox. > > >> Skipping HTTP ( ./http/HTTP.hs, ./http/HTTP.o ) >> Compiling Browser ( ./http/Browser.hs, ./http/Browser.o ) > > it's not really a problem of the toolbox, but of the sources > we use for http access. the http modules are copied from Warrick Gray, > please look into the sources. we plan to rework the http input, to > modularize > it and to configure it for direct http support or via external > programs, or to > use only file access. Graham Klyne had similar problems when compiling > under > windows. perhaps a newer version of the http module may solve the > problem. > > uwe schmidt > > -- > > University of Applied Sciences, Wedel, Germany > http://www.fh-wedel.de/~si/index.html >

1 0

RE: [Haskell] "exists" keyword and "existential" types
by Simon Peyton-Jones 23 Feb '04

23 Feb '04

| I find myself confused by the lack of an "exists" quantifier to complement | "forall". It imposes seemingly arbitrary restrictions on the ways in which | types can be expressed, and makes some seemingly harmless (and useful) | types entirely inexpressible. | | For example, it seems as though runST could just as well be given the type | | runST :: forall a. exists s. ST s a -> a | | This isn't necessarily better than the usual type, but why can't it be | expressed? And it might actually be better: introducing exists would make | it possible to hoist quantifiers from both sides of the function arrow, | rather than just the RHS as GHC does now. | | And it would be nice to be able to pass around values of type | (exists t. Interface t => t), which behave just like OOP interface | pointers. I don't see how | | openInputStream :: FilePath -> IO (exists t. InputStream t => t) It's easier to suggest extensions to an already complicated type system than it is to give a watertight specification of the extension, still less to implement them. Mark Shields and I (mainly Mark) did go through the exercise of specifying a type system for Haskell with first-class existentials. It was extremely complicated, so much so that I cannot even explain *why* it was extremely complicated, though Mark may be able to. In my mind, it stands as an un-met challenge: can one add first-class existentials to Haskell (along with first-class universal quantification, of course). I know the Utrecht guys are thinking about doing this in (some version of) Helium. Once you have a good specification, there remains the challenges of (a) giving a reasonably simple type inference algorithm, and (b) implementing it. If anyone feels like running with this one, I'd like to suggest as a baseline the paper that Mark and I wrote about first-class universals "Practical type inference for higher-rank polymorphism". It's on my home page. http://research.microsoft.com/%7Esimonpj/papers/putting/index.htm The reason it makes a good starting point is that it gives a complete, executable type-inference engine for first-class universal polymorphism, well suited for extension with first-class existentials. And, of course, it comes with a very detailed tutorial (the paper). | > True, but why is this? Is there a deep reason why we can use nested | > foralls as the arguments to (->), but not as the arguments to any other | > type constructor? | | Apparently it makes type-checking Very Very Hard. Simon PJ may have | explained it to me ("impredicative", he called it), but I don't remember | offhand. This question, too, is discussed at some length in the paper. It is possible to do type inference in an impredicative system, but it's much harder. Le Botlan and Remy have an excellent paper, about a language called MLF, that describes such a system, but it's not for the faint hearted. Simon

1 0

"exists" keyword and "existential" types
by Ben Rudiak-Gould 23 Feb '04

23 Feb '04

I find myself confused by the lack of an "exists" quantifier to complement "forall". It imposes seemingly arbitrary restrictions on the ways in which types can be expressed, and makes some seemingly harmless (and useful) types entirely inexpressible. For example, it seems as though runST could just as well be given the type runST :: forall a. exists s. ST s a -> a This isn't necessarily better than the usual type, but why can't it be expressed? And it might actually be better: introducing exists would make it possible to hoist quantifiers from both sides of the function arrow, rather than just the RHS as GHC does now. And it would be nice to be able to pass around values of type (exists t. Interface t => t), which behave just like OOP interface pointers. I don't see how openInputStream :: FilePath -> IO (exists t. InputStream t => t) would cause any more problems than data Foo = forall t. InputStream t => Foo t openInputStream :: FilePath -> IO Foo What am I missing? While looking through old posts for insight, I came across a thread from last April started by Simon P-J, who wrote: > > Many of you have grown to love existential data types, which we current > write like this: > > data T = forall a. Foo a (a -> Int) > > Mark and I chose 'forall' rather than 'exists' to save grabbing another > keyword from the programmer. And indeed, the type of the constructor > Foo is > Foo :: forall a. a -> (a->Int) -> T > > But every single time I explain this to someone, I find I have to make > excuses for using the term 'forall'. I say "it really means 'exists', > but we didn't want to lose another keyword". > > I have gradually concluded that our decision was a mistake. (In > fairness to Mark, I think I was the primary advocate for it.) I reckon > that we should > > Allow 'exists' > Deprecate 'forall' (for defining existentials, that is) > Eventually allow only 'exists' > But I think the use of "forall" in this context is correct, and "exists" incorrect. I find it easy to explain: you're creating many different "Foo" constructors, one for every possible type a, so when you extract a value from a Foo you're getting some type a, but you don't know which. Using "exists" here would express something different, namely that there's only one Foo, but you don't know (and it mustn't matter) what type it expects to be bound to a, and therefore you can't apply Foo to a value unless that value is general enough to encompass all possible types for a. This gives the constructor function a rank-2 type, or equivalently an existentially-quantified variable at the top level. When you match against the value you're getting something which has to be able to stand in for any type. I think the source of confusion is not the use of forall, but the term "existential types". There is nothing existential about them! The type variables involved can be either existentially or universally quantified, depending on the context. They use exists in exactly the contexts where "ordinary" type variables use forall, and vice versa. Instead of changing the forall, I think we should change the name "existential types" to something which approximately reflects what they actually are, like "inaccessible types" or "hidden types". "Abstract types" would also be a possibility, but I think it would be confused with the separate concept of using module scope to hide value constructors. My other suggestions might also cause that kind of confusion, but I still think they're better than "existential types", which seems to have no more to do with the concept being expressed than "left-handed types" or "male types" would have. -- Ben

5 7

Re: graphs and trees again
by Wolfgang Jeltsch 23 Feb '04

23 Feb '04

Am Dienstag, 13. Januar 2004 22:56 schrieb Ross Paterson: > On Tue, Jan 13, 2004 at 09:36:58PM +0100, Wolfgang Jeltsch wrote: > > Am Dienstag, 13. Januar 2004 19:12 schrieb Ross Paterson: > > > * made the types abstract, but provided the equivalent constructor and > > > destructor functions. I'm not sure that gains anything. > > > > Well, I did this to be consistent with the Graph module where abstract > > types are crucial. Yes, it doesn't make much sense. But declaring > > Forest via newtype instead of type surely makes sense because this way > > you're able to define a meaningful Functor instance. > > You get to write fmap instead of map . fmap, but you lose the ability > to treat forests simply as lists. With an seperate forest type, you are also able to use functions which work with arbitrary functors. > > > * added upwards and downwards accumulators (except that your "upwards" > > > accumulator is actually a variant downwards accumulator, with > > > quadratic performance). > > > > What do you mean with "a variant"? Is foldl a variant foldr? > > A downwards accumulation normally replaces each value with the foldl > of the path (list) of items from the root to here (as yours does). > An upwards accumulation normally replaces the values each item with > the (tree) fold of that subtree: > > foldTree :: (a -> [b] -> b) -> Tree a -> b > foldTree n (Node a ts) = n a (map (foldTree n) ts) > > upAccumTree :: (a -> [b] -> b) -> Tree a -> Tree b > upAccumTree f = foldTree ft > where ft a ts = Node (f a (map root ts)) ts > root (Node a _) = a > > It's a different generalization of scanr: yours replaces each item with > a foldr on the list of ancestors. > > BTW, do you have any uses for these things? (The unfolds are useful > for search problems.) I use flattenTree $ downAccuTree (flip (:)) [] $ spanningTree vertex graph to get paths from a graph vertex to every reachable vertex (actually, the reversed paths). Wolfgang

2 2

CVS access library in Haskell?
by Jan Scheffczyk 23 Feb '04

23 Feb '04

Hi all, does anyone know of a Haskell library that provides access to CVS controlled files? Access libraries to other revision control systems, e.g., subversion or arch, would also be greatly appreciated. Yes, I know of darcs, which is great work I think. Still, direct CVS access is of importance. Cheers, Jan

2 1

Compiling HXmlToolbox-3.01 on Mac OS X
by Sachin Desai 23 Feb '04

23 Feb '04

Has anyone successfully compiled this Toolbox on Mac OS X (10.3.2)? I've installed ghc made through darwinports, compiled and installed MD5 and am getting errors when building the toolbox. For example, when I perform "make HXmlParser", I get the following (the first run compiled the modules, hence the Skipping) ghc -Wall -O -fglasgow-exts -i./hparser:./hdom:./hvalidator:./hxpath:./parsec:./http:./popen --make -package lang -package net -package util -o HXmlParser examples/HXmlParser.hs Chasing modules from: examples/HXmlParser.hs Skipping RE ( ./hvalidator/RE.hs, ./hvalidator/RE.o ) Skipping AssocList ( ./hdom/AssocList.hs, ./hdom/AssocList.o ) Skipping NTree ( ./hdom/NTree.hs, ./hdom/NTree.o ) Skipping ParsecPos ( ./parsec/ParsecPos.hs, ./parsec/ParsecPos.o ) Skipping ParsecError ( ./parsec/ParsecError.hs, ./parsec/ParsecError.o ) Skipping ParsecPrim ( ./parsec/ParsecPrim.hs, ./parsec/ParsecPrim.o ) Skipping ParsecChar ( ./parsec/ParsecChar.hs, ./parsec/ParsecChar.o ) Skipping ParsecCombinator ( ./parsec/ParsecCombinator.hs, ./parsec/ParsecCombinator.o ) Skipping Base64 ( ./http/Base64.hs, ./http/Base64.o ) Skipping XmlTreeTypes ( ./hdom/XmlTreeTypes.hs, ./hdom/XmlTreeTypes.o ) Skipping XmlKeywords ( ./hdom/XmlKeywords.hs, ./hdom/XmlKeywords.o ) Skipping XmlTreeFunctions ( ./hdom/XmlTreeFunctions.hs, ./hdom/XmlTreeFunctions.o ) Skipping MonadStateIO ( ./hdom/MonadStateIO.hs, ./hdom/MonadStateIO.o ) Skipping Parsec ( ./parsec/Parsec.hs, ./parsec/Parsec.o ) Skipping POpen ( ./popen/POpen.hs, ./popen/POpen.o ) Skipping HTTP ( ./http/HTTP.hs, ./http/HTTP.o ) Compiling Browser ( ./http/Browser.hs, ./http/Browser.o ) .. lots of warnings ... ./http/Browser.hs:196: Warning: Pattern match(es) are non-exhaustive In the definition of `headerToCookies': Patterns not matched: _ (Header (HdrCustom _) _) _ (Header HdrCacheControl _) _ (Header HdrConnection _) _ (Header HdrDate _) ... ./http/Browser.hs:926: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: HEAD PUT OPTIONS TRACE ghc-6.2: unknown package name: Main make: *** [HXmlParser] Error 1 Does anyone have any insight on why I'm getting this? I've just started to learn Haskell and am not too familiar with the compilation process. Thanks. -- Sachin.

2 1

hmake -- on Windows?
by Graham Klyne 20 Feb '04

20 Feb '04

I just took a quick look at hmake, and it appears to be very Unix/Linux-centred in its applicability. In particular, the installation instructions seem to dpeend on a 'configure' utility, which I think is a Unix/Linux feature that I'm not aware is available for Windows. Am I missing something here? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

3 2

URI handling code; proposed Network.URI replacement
by Graham Klyne 20 Feb '04

20 Feb '04

I've completed the functionality of my proposed upgrade to Network.URI, though there are still a couple of issues that need to be resolved with the ongoing RFC2396bis work (none critical to the general functionality). This is still work-in-progress, but I'm airing it now to see if folks think it's an acceptable upgrade to the existing Network.URI module. There is an extensive test suite that runs without fault under Hugs and GHCi. This module duplicates the general functionality of the old GHC Network.URI module, and adds: - functions to parse different categories of URI (relative, absolute, URI-reference, etc.) - functions to test for different kinds of URI (returning Bool instead of Maybe URI). - 'relativeFrom', a function to calculate a relative URI with respect to a given base, to complement the existing 'relativeTo'. - functions to perform some common forms of URI normalization. - default behaviour is to not display the password field associated with userinfo in a URI. (This area needs some tidying up). The structure of the underlying URI implementation has changed quite a lot, but I've also defined some accessor functions that reflect the original structure fields. (Oops, I just noticed I forgot to export them) The code can be browsed at: http://www.ninebynine.org/Software/HaskellUtils/Network/ #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: [Haskell] Re: Data.Set whishes
by Bayley, Alistair 20 Feb '04

20 Feb '04

Excuse my ignorance, but why can't you just say: import qualified Data.Set as Set > Hello, > > the naming scheme you mention is nice, in my opinion. > > Alas, it has a problem with hierarchical module names. For > example, you > cannot write Set.empty but have to write Data.Set.empty > instead. As modules > get more and more nested, the qualified names get longer and longer. > > A solution would be if Haskell would allow "partially > qualified" names, e.g., > you import Data and are able to say "Set.empty" afterwards. > > Wolfgang ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1