April 2002 - Haskell - Haskell.org

trying to tie the knot
by Hal Daume III 13 Apr '02

13 Apr '02

Hi All, I thought I was starting to get my head around the whole tying the knot phenomenon, but when my program produced "*** Exception: <<loop>>" I figured I was probably missing something :). Here's what I'm trying to do (I know I could do it without tying the knot, but that seemed like a reasonable approach and I wanted to get my hands dirty or feat wet): I'm reading in a file; that is I have a function String -> MyDataType. More specifically I'm reading in a Tree, and the tree is specified in the file with these "Subtree" fields. So you can be reading along in the tree and then instead of actually seeing a branch or leaf, you'll see somethign like "[S1]" which means "stick subtree S1 in here". later in the file (arbitrarily later), you will see something like "Subtree [S1]" and then following that is that tree. So what I did was I changed my function to a String -> [(String,Tree)] -> (Tree, [(String,Tree)] function where the list is a lookup for the subtrees. I then said: readTrees s = let (t, st) = readTrees' s st in t and then the readTrees' basically read the tree in as normal; except when it gets to something like "[S1]" it does lookup "[S1]" subTrees to get the subtree and then when it gets to "Subtree [S1]" it reads in the subtree and then adds it to the subtree list. Is this not an appropriate use of tying the knot or amd I just doing something wrong? I've attached my code if you want to read it; It's marginally more complex that I've written here jsut because of some of the idiosyncracies in the file format... - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

2 1

RE: deriving over renamed types
by Simon Peyton-Jones 12 Apr '02

12 Apr '02

It's a bug in GHC 5.02 and earlier; fixed in 5.03 Simon | -----Original Message----- | From: Hal Daume III [mailto:hdaume@ISI.EDU] | Sent: 04 April 2002 00:15 | To: Haskell Mailing List | Subject: deriving over renamed types | | | Why can't I do this: | | > import FiniteMap | > type FM = FiniteMap | > instance (Show a, Show b) => Show (FiniteMap a b) where | > show = show . fmToList | > data X = X (FM Int Int) | > deriving (Show) | | if I replace | | > type FM = FiniteMap | | with | | > type FM a b = FiniteMap a b | | it works fine. I wasn't aware there was (supposed to be) a | difference between these two declarations? Is there? | | - Hal | | | -- | Hal Daume III | | "Computer science is no more about computers | hdaume(a)isi.edu | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

2 1

More Haskell Blue Sky: Partial Type Annotations
by Ashley Yakeley 12 Apr '02

12 Apr '02

I sometimes come across a situation when I only want to provide a _partial_ type annotation, perhaps because the full type has some variable unified with some variable in some other type annotation, or something. For instance: f :: forall a. [a] -> [a] -> [a] f x y = g x where g [] = y g (_:_) = x ...there doesn't seem to be a way of giving a type annotation for 'g'. Theoretically it's '[a] -> [a]', but where 'a' is the same as the 'a' in the type signature for 'f'. Under this proposal, unqualified type variables would be considered to be 'free' rather than implicitly forall-qualified. So for instance, any function could be given the partial type annotation 'a -> b'. For instance, all these annotations would be the same given this function: k :: a k :: a -> ba k :: a -> b -> a k :: forall b. a -> b -> a k :: forall a b. a -> b -> a k x y = x ...and these would both be the same, but different from the previous: k' :: Int -> ba k' :: forall b. Int -> b -> Int k' x y = x And so we could write this: f :: forall a. [a] -> [a] -> [a] f x y = g x where g :: [a] -> [a] -- partial annotation may be sufficient g [] = y g (_:_) = x I admit that's a bit of a change, and might break programs... In addition, it doesn't address the occasional need to tie type annotations together, something that has often made me add ugly dummy arguments used just for their type. -- Ashley Yakeley, Seattle WA

4 4

IFL 2002 Announcement
by Ricardo Pe~na 11 Apr '02

11 Apr '02

(Apologies for multiple postings) ============================================================ IFL 2002 14th International Workshop on the IMPLEMENTATION OF FUNCTIONAL LANGUAGES Madrid Spain September 16 - 18, 2002 ============================================================= Important dates --------------- Registration deadline: July 30th, 2002 Submission deadline : August 26th, 2002 further details : http://dalila.sip.ucm.es/ifl02 ============================================================= Scope of IFL 2002 ----------------- The aim of the workshop is to bring together researchers and users actively engaged in the implementation and application of functional programming languages to discuss results and new directions of research. The workshop is intended to provide an open forum for researchers who wish to present and discuss new ideas and concepts, work in progress, preliminary results etc. related primarily but not exclusively to the implementation of functional or function-based languages. A not necessarily exhaustive list of topics includes language concepts type checking compilation techniques (abstract) interpretation automatic program generation (abstract) machine architectures array processing concurrent/parallel programming and program execution heap management runtime profiling and performance measurements debugging and tracing verification of functional programs tools and programming techniques Contributions on applications of functional programming, e.g., in teaching, or on theoretical work in any of the above areas are also welcome. Contributions ------------- All attendees are encouraged to submit papers to be published in the draft proceedings and to give presentations at the workshop. Submitted papers must be written in English, conform to the LNCS format (available at: http://www.springer.de/comp/lncs/authors.html) and not exceed 16 pages. Papers should be submitted by August 26th as postscript or pdf files using the submission page of the workshop accessible through http://dalila.sip.ucm.es/ifl02. After the workshop, we intend to publish a high-quality subset of contributions in the Springer LNCS series. All speakers attending the workshop are invited to submit a paper. Papers for the LNCS proceedings will be refereed according to normal conference standards. -- Ricardo Pe~na e-mail: ricardo(a)sip.ucm.es Departamento Sistemas Informaticos y Programacion Facultad de Informatica Universidad Complutense de Madrid, 28040 MADRID Ph: (+ 34) 91 394 4313 FAX: (+ 34) 91 394 4602 http://dalila.sip.ucm.es/~ricardo

1 0

��Ϣ��!��Ż�!
by tony 11 Apr '02

11 Apr '02

�װ��ѣ� ��ã� ��缼��ţ��޹�˾��ʺ��л��տ��ʼ��ϵ�ϣ��ܳ�Ϊ�� Ҫ��顣��һ�Ҳ��¼��ᾧ��о��ƹ�ͷ�չ�¼��ڻ��Ϣ�� ҵӦ�÷��ĸ��¼��ҵ��:http://www.raeline.net email:webmaster@raeline.net лл�� ˾��2000��ȫ��ʻ��Ƴ��²�Ʒ��ȫ��пռ䶼֧ ��ݿ⣨linux+PHP+Mysol;NT+asp+acess��⽫��ֵ��ѡ�� 1.30M�ռ䣫50M��ҵ��䣫1��ȫ�棬��198Ԫ/�ꡣ ��2.50M�ռ䣫100M��ҵ��䣫1��ȫ�棬��248Ԫ/�ꡣ ��3.100M�ռ䣫100M��ҵ��䣫1��ȫ�棬��318Ԫ/�ꡣ ��4.100M�ռ�+100M��䣫1��+��ַ��ģ��վ+��վ��ҵ��Ϣ ��1000Ԫ �� Ǿ��Ϊ��ṩ��õķ��񡣣��ų��ʧ��Ը��˿Ҳ��Ϊ ��һ��Ĳ��ġ��ǳ�ŵ��ⰴʵ��˿ ��ף��ģ�˳�� webmaster of raeline.net webmaster(a)raeline.net ��缼��ţ��޹�˾ --------------------------------------------------------------- �е�Ⱥ��ʼ�,��ר��(http://www.21cmm.com) ��CMM��У(http://www.21cmm.com)��Ŀ��ר��

1 0

RE: More Haskell Blue Sky: Partial Type Annotations
by Simon Peyton-Jones 11 Apr '02

11 Apr '02

Already in GHC, and describe in our paper on scoped type variables: http://research.microsoft.com/~simonpj/papers/scoped-tyvar Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 11 April 2002 12:11 | To: Haskell List | Subject: More Haskell Blue Sky: Partial Type Annotations | | | I sometimes come across a situation when I only want to provide a | _partial_ type annotation, perhaps because the full type has some | variable unified with some variable in some other type annotation, or | something. For instance: | | f :: forall a. [a] -> [a] -> [a] | f x y = g x where | g [] = y | g (_:_) = x | | ...there doesn't seem to be a way of giving a type annotation | for 'g'. | Theoretically it's '[a] -> [a]', but where 'a' is the same as | the 'a' in | the type signature for 'f'. | | Under this proposal, unqualified type variables would be | considered to be | 'free' rather than implicitly forall-qualified. So for instance, any | function could be given the partial type annotation 'a -> b'. For | instance, all these annotations would be the same given this function: | | k :: a | k :: a -> ba | k :: a -> b -> a | k :: forall b. a -> b -> a | k :: forall a b. a -> b -> a | | k x y = x | | ...and these would both be the same, but different from the previous: | | k' :: Int -> ba | k' :: forall b. Int -> b -> Int | | k' x y = x | | And so we could write this: | | f :: forall a. [a] -> [a] -> [a] | f x y = g x where | g :: [a] -> [a] -- partial annotation may be sufficient | g [] = y | g (_:_) = x | | I admit that's a bit of a change, and might break programs... In | addition, it doesn't address the occasional need to tie type | annotations | together, something that has often made me add ugly dummy | arguments used | just for their type. | | -- | Ashley Yakeley, Seattle WA | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell |

1 0

does this have a name (recusive datatypes)
by Hal Daume III 10 Apr '02

10 Apr '02

Does this have a name: > data S s a = Nil | S a (s (S s a)) it seems to capture the essense of many recursive data structures. With: > newtype Id a = Id a > newtype Pair a = Pair (a,a) we get that: lists are isomorphic to S Id binary trees are isomorphic to S Pair rose trees are isomorphic to S [] probably more... Is there any theory about what types of recursive data structures can be captured with "S" and what types cannot? It seems that those datastructures which are isomorphic to S x for some x (satisfying certain properties) are exactly those on which one can apply things like maps, filters and folds. For instance, > class Map s where map :: (a -> b) -> s a -> s b > instance Map Id where map f (Id i) = Id (f i) > instance Map Pair where map f (Pair (a,b)) = Pair (f a, f b) > instance Map [] where map = Prelude.map > instance Map s => Map (S s) where > map f Nil = Nil > map f (S a ss) = S (f a) (map f ss) (note i haven't actually loaded this class stuff in a compiler so i might have a typo or soemthing, but it should be clear). it seems the same can be applied to folds and filters, so certainly if s is a functor, so is S s, but what more can we say? Also, if we want to write a show instance for S s, this seems to be impossible. Is it? If so, is this a weakness in Haskell (cyclic instance declarations) or is it theoretically not possible? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

3 4

ANNOUNCE: Hugs98 for .NET
by Sigbjorn Finne 10 Apr '02

10 Apr '02

We are pleased to announce the first release of Hugs98 for .NET, April 2002. It sports the following: * A version of the popular Haskell interpreter, Hugs98 (http://haskell.org/hugs) targetted at the Microsoft .NET platform. * Hugs98 for .NET lets you use .NET classes and objects from within the comforts of Haskell. * Hugs98 for .NET lets you wrap up Haskell functions as .NET classes / delegators, providing any .NET language with the ability to call and use Haskell. The distribution comes with documentation and examples demonstrating how to access and interact with .NET -- all available via the Hugs98 for .NET homepage: http://galois.com/~sof/hugs98.net/ One of the main objectives behind this first release is to gauge the level of interest in having a good .NET story for Haskell. Feedback, suggestions for improvements, bug reports etc. are most welcome -- please e-mail these to the author: sof(a)galois.com -------------------------------------------------------------------------- The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the Yale Haskell Group, and the Oregon Graduate Institute of Science and Technology, 1994-2001, All rights reserved. It is distributed as free software under the license in the file "License", which is included in the distribution. The .NET extension is Copyright (c) Sigbjorn Finne, 2002, All rights reserved. It is distributed as free software under the license in the file "License.net", which is included in the distribution. --------------------------------------------------------------------------

1 0

ANNOUNCE: GHC 5.02.3 released
by Simon Marlow 10 Apr '02

10 Apr '02

The (Interactive) Glasgow Haskell Compiler -- version 5.02.3 ============================================================== We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.02.3. The source distribution is freely available via the World-Wide Web, under a BSD-style license. See below for download details. Pre-built packages for Linux, FreeBSD, Solaris and Win32 are also available (or will appear shortly). Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, C++, whatever). A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page at http://www.haskell.org/ GHC's Web page lives at http://www.haskell.org/ghc/ What's new in 5.02.3 ====================== Some important bugfixes: - now works with gcc 3.x - works with newer glibc releases on Linux - loading parsers generated by Happy with the -ag flags into GHCi now works - fix for excessive recompilation when using --make - tryTakeMVar now works - fix some problems with the dynamic linker when loading C libraries into GHCi (using Gtk+HS from GHCi should now work). and various other minor fixes. NOTE: object files created by this vesrion of GHC may be incompatible with object files created by older versions of GHC, so be sure to recompile any pre-compiled libraries you may have lying around. How to get it =============== The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Everybody else gets a .tar.gz which can be installed where you want. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. On-line GHC-related resources =============================== Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ===================== To compile programs with GHC, you need a machine with 64+MB memory, GNU C and perl. This release is known to work on the following platforms: * i386-unknown-{linux,freebsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide included in distribution gives a complete run-down of what ports work; an on-line version can be found at http://www.haskell.org/ghc/docs/latest/building/building-guide.html Mailing lists =============== We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

4 3

Re: deriving over renamed types
by Ashley Yakeley 10 Apr '02

10 Apr '02

At 2002-04-09 04:53, C T McBride wrote: >There's a plentiful supply of good examples arising naturally from >higher-hind polymorphism. * -> * is full of functions with good >properties (eg being functorial or monadic) which aren't datatype >constructors. Haskell's inability to express them and to instantiate type >schemes with them is a serious hindrance to the good functional >programming practice of identifying and abstracting common structure. >Similarly, it's not too hard to find examples where the potential >of local `forall' is thwarted by the lack of the corresponding lambda. I agree. I've come across them. ... >Ashley wrote: > >> > data Zero; >> > data Succ n; >> > >> > type Add Zero b = b; >> > type Add (Succ a) b = Succ (Add a b); > >...you can write this program with type classes, but much less clearly >and directly. For instance: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/truth-framework/ Source/TypeCalc/NaturalType.hs?rev=HEAD&content-type=text/plain> There's more in that folder, including concatenatable mixed lists: <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/truth-framework/Source/Type Calc/> This would have all been _much_ easier with typed lambda and pattern-matching. The biggest problem is that instances are unordered and must be disjoint, whereas pattern cases are of course ordered and don't need to be disjoint. >They're a good tool, but the wrong tool for this job, and >but this job is worth doing well. > >In that respect, I'd caution against pattern matching over * and >higher-kinds, because these kinds are not closed. That's why I argue >in favour of datakinds (given that using genuine term-level data would >involve a seismic shift in Haskell's static/dynamic divide). Hmm. After value lambda and type lambda, are we going to one day want datakind lambda? Alternatively, could one extend classes to be datakinds? Some way of closing them? >But, imagining that Zero and Suc are the constructors of a datakind >Nat over which we can write these programs safely... > >> > data Foo f = MkFoo (f ()); >> > >> > type Succ' = Succ; >> > type Succ'' n = Succ n; >> > >> > -- which of these types are the same? >> > f1 = MkFoo undefined :: Foo Succ; >> > f2 = MkFoo undefined :: Foo Succ'; >> > f3 = MkFoo undefined :: Foo Succ''; >> > f4 = MkFoo undefined :: Foo (Add (Succ Zero)); > >...as has already been pointed out, they all have the same eta-long normal >form, being Foo (/\n -> Succ n). ...and what about this one: f5 = MkFoo undefined :: Foo (/\a ::: Nat => Add a (Succ Zero)); ...? Depending on how 'Add' is defined, f5 may very well be extensionally equivalent to the others. Isn't this going to trip up the programmer some time? >Machines are good at figuring this stuff out, which is why I like their >help when I'm programming. OK. But there needs to be a line drawn in what Haskell is going to figure out. We know it's never going to be able to calculate whether any two functions are extensionally equivalent. -- Ashley Yakeley, Seattle WA

1 0