November 2002 - Haskell

Feature Structures
by Markus.Schnell＠infineon.com 20 Nov '02

20 Nov '02

Has anybody tried to implement (typed) feature structures in Haskell with unification? I'm trying to build my own library, but if there is already support for it, I would consider using this alternative. Thanks, Markus -- Markus Schnell Speech Interface Group, Infineon Technologies AG Tel +49 (89) 234-20875, Fax +49 (89) 234-21670

2 1

RE: ANNOUNCE: Hugs98 November 2002 release
by i 20 Nov '02

20 Nov '02

[mybox] gunzip hugs98-Nov2002.tar.gz [mybox] tar xvf hugs98-Nov2002.tar ................................... x hugs98-Nov2002/fptools/libraries/base/Text/ParserCombinators/Parsec/examples/Mondrian/Pretty.hs, 2918 bytes, 6 tape blocks tar: directory checksum error [mybox] :( -- http://www.kuro5hin.org/users/i --- On Wed 11/20, Sigbjorn Finne wrote: > We are pleased to announce a new release of Hugs98, an interpreter > and programming environment for developing Haskell programs. _______________________________________________ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com

1 0

Why no findM ? simple Cat revisited
by Ahn Ki-yung 20 Nov '02

20 Nov '02

Simple Cat (revisitied) \begin{code} import IO findM f [] = return Nothing findM f (x:xs) = do { v <- x; if f v then return (Just v) else findM f xs } isLeft (Left _) = True isLeft _ = False main = findM (isLeft) (hCat stdin) where hCat h = try (hGetLine h) : hCat h \end{code} This is my answer for the question of my own, which is posted a couple There are mapM, filterM in the Haskell 98 Standard Library. But why no findM there ? As you can see from simple cat, it seems quite useful. I think fildM should be added to the module Monad. -- Ahn Ki-yung

2 1

Re: Functional dependencies and Constructor Classes
by Yoann Padioleau 20 Nov '02

20 Nov '02

Martin Sulzmann <sulzmann(a)comp.nus.edu.sg> writes: > Hi, > > I was wondering whether other people made similiar observations. > Functional dependencies seem to be expressiveness enough to encode > some of the kinding rules required for Constructor Classes. read this page: http://cvs.haskell.org/Hugs/pages/hugsman/exts.html I think that the designer of constructor class and functionnal depedencies is the same person si it makes sense that one generalise the other. nevertheless i found constructor class more elegant for many problems. Your solution is less elegant that the one using constructor classes. I found too that type error messages of class using functionnal depedencies are not easy to read. There is often ambiguity in code that are not easy to solver. this problem does not appear with constructor classes. > > Take a look at the Haskell code below > (runs under hugs -98 or ghci -fglasgow-exts-fallow-undecidable-instances) > > Martin > > > > -- An alternative to constructor classes > > module Fmap where > > {- Instead of > class Functor f where fmap :: (a->b)->(f a->f b) > > use > -} > > class Fmap a b fa fb | a fb -> b fa, > b fa -> a fb, > fa fb -> a b > where fmap2 :: (a->b)->(fa -> fb) > > {- We require: > > (1) fmap2 transforms a function into another function, > i.e. fmap2's type should always be of shape (a->b)->(fa->fb) > > (2) b, fa uniquely determine a and fb > > (3) a, fb " b and fa > > (4) fa, fb " a and b > > Note that (1) is enforced by the class definition. (2)-(4) are enforced by FDs. > > My guess/conjecture is that the above axiomatization of functors is equivalent to the > one found in Haskell98. > -} > > -- some Examples > > {- The following is a variation of an example taken from Mark Jones original paper > "A System of Constructor Classes: Overloading and Implicit Higher-Order Polymorphism". > He used this example to motivate the introduction of constructor classes. The example > is type correct using the alternative formulation of functors. > -} > > cmap :: (Fmap a b fb1 fb, Fmap a1 b1 fa fb1) => > (a1 -> b1) -> (a -> b) -> fa -> fb > cmap f g = (fmap2 g) . (fmap2 f) > > > -- identity functor > instance Fmap a a a a where fmap2 h = h > > -- functor composition > -- Instance is not allowed, cause leads to undecidable type inference > > {- > instance (Fmap a b c d, Fmap e f a b) => Fmap e f c d > where fmap2 h = fmap2 (fmap2 h) > -} > > comp :: (Fmap fa1 fb1 fa fb, Fmap a b fa1 fb1) => > (a -> b) -> fa -> fb > comp h = fmap2 (fmap2 h) > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Yoann Padioleau, INSA de Rennes, France, Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**

3 3

ANNOUNCE: Hugs98 November 2002 release
by Sigbjorn Finne 20 Nov '02

20 Nov '02

We are pleased to announce a new release of Hugs98, an interpreter and programming environment for developing Haskell programs. Sources and binaries are freely available on the World-Wide Web. Feature highlights of this new release are: - Much improved FFI support (contributed by Alastair Reid), bringing Hugs really very close to the Haskell FFI specification. - Adoption of a significant subset of GHC's hierarchical libraries (contributed by Ross Paterson). - An (allegedly) complete implementation of the Haskell98 module system (Sigbjorn Finne). - Numerous bug fixes since the previous major release in Dec 2001. The home page for Hugs is at http://haskell.org/hugs. Send email to hugs-users-request(a)haskell.org to join the hugs-users mailing list. Bug reports should be sent to hugs-bugs(a)haskell.org. Send email to hugs-bugs-request(a)haskell.org to subscribe to the hugs-bugs list. Enjoy! ---------------------------------------------------------------------------- -- The Hugs 98 system is Copyright (c) Mark P Jones, Alastair Reid, the Yale Haskell Group, and the OGI School of Science & Engineering at OHSU, 1994-2002, All rights reserved. It is distributed as free software under the license in the file "License", which is included in the distribution. ---------------------------------------------------------------------------- --

2 1

MD5 in Haskell
by Peter Thiemann 20 Nov '02

20 Nov '02

Folks, there used to be a Haskell implementation of MD5 and other cryptographic hashes available on http://c93.keble.ox.ac.uk/~ian/haskell/ Unfortunately, this URL seems to be obsolete (I cannot access it and it does not come up in Google anymore). If anybody out there still holds on to a copy of this, please send it to me! -Peter

3 2

Re: Functional dependencies and Constructor Classes
by Yoann Padioleau 19 Nov '02

19 Nov '02

Martin Sulzmann <sulzmann(a)comp.nus.edu.sg> writes: > Yoann Padioleau writes: > > nevertheless i found constructor class more elegant for many problems. > > Your solution is less elegant that the one using constructor classes. > > > > Yes, the current presentation of constructor classes might be easier > to comprehend. > > > I found too that type error messages of class using functionnal depedencies > > are not easy to read. There is often ambiguity in code that are not easy to solver. > > this problem does not appear with constructor classes. > > > > Well, that's the point of my encoding of functors using FD's. No > ambiguities will arise! > > The issue I want to raise is whether constructor classes are redundant > in the presence of FDs (yes, yes, we still might want to stick to the > constructor class representation, but that's a different issue). Oh, sorry, i misinterpret what you wanted to say. > > Martin > > > -- Yoann Padioleau, INSA de Rennes, France, Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**

1 0

Functional dependencies and improvement
by Martin Sulzmann 19 Nov '02

19 Nov '02

Hi, yet again FD's! In my previous example I employed FD's to improve constraints. However, there are cases where FD's seem to be overly restrictive. Take a look at the Haskell code below. Have others made similar experiences? Martin -- FDs are sometimes overly restrictive module Insert where class Insert a b | b -> a where insert :: a->b->b class Leq a where leq :: a->a->Bool instance Leq a => Insert a [a] -- we're not so interested in the values for the purpose of this example -- hugs or ghc will complain about the following instance instance Insert Int [Float] -- though this makes sense! Elements of value Int should allowed to be stored as Floats {- Reason: Improvement in case of FDs seems overly restrictive Consider Mark Jones paper "Type Classes with Functional Dependencies", page 12, Section 6.2. In case of the above type class we require that for each constraint Insert t1 t2 and declaration instance C => Insert t1' t2' where if phi(t2) = t2' then phi(t1) = t1' for some substitution phi. However, we have that phi([a]) = [Float] and phi(a) \not= Int where phi=[a |-> Float]. The problem is that the improvement strategy does not take into account the context in the instance declaration. Solution: We should only improve 'Insert a [b]' to 'Insert b [b]' where phi=[a |-> b] in case we additionally find 'Leq b'. Though, this cannot be specified with FD's. -}

2 1

Functional dependencies and Constructor Classes
by Martin Sulzmann 18 Nov '02

18 Nov '02

Hi, I was wondering whether other people made similiar observations. Functional dependencies seem to be expressiveness enough to encode some of the kinding rules required for Constructor Classes. Take a look at the Haskell code below (runs under hugs -98 or ghci -fglasgow-exts-fallow-undecidable-instances) Martin -- An alternative to constructor classes module Fmap where {- Instead of class Functor f where fmap :: (a->b)->(f a->f b) use -} class Fmap a b fa fb | a fb -> b fa, b fa -> a fb, fa fb -> a b where fmap2 :: (a->b)->(fa -> fb) {- We require: (1) fmap2 transforms a function into another function, i.e. fmap2's type should always be of shape (a->b)->(fa->fb) (2) b, fa uniquely determine a and fb (3) a, fb " b and fa (4) fa, fb " a and b Note that (1) is enforced by the class definition. (2)-(4) are enforced by FDs. My guess/conjecture is that the above axiomatization of functors is equivalent to the one found in Haskell98. -} -- some Examples {- The following is a variation of an example taken from Mark Jones original paper "A System of Constructor Classes: Overloading and Implicit Higher-Order Polymorphism". He used this example to motivate the introduction of constructor classes. The example is type correct using the alternative formulation of functors. -} cmap :: (Fmap a b fb1 fb, Fmap a1 b1 fa fb1) => (a1 -> b1) -> (a -> b) -> fa -> fb cmap f g = (fmap2 g) . (fmap2 f) -- identity functor instance Fmap a a a a where fmap2 h = h -- functor composition -- Instance is not allowed, cause leads to undecidable type inference {- instance (Fmap a b c d, Fmap e f a b) => Fmap e f c d where fmap2 h = fmap2 (fmap2 h) -} comp :: (Fmap fa1 fb1 fa fb, Fmap a b fa1 fb1) => (a -> b) -> fa -> fb comp h = fmap2 (fmap2 h)

1 0

CFP for LDTA 2003: ACM SIGPLAN Workshop
by Pierre-Etienne.Moreau＠loria.fr 18 Nov '02

18 Nov '02

Please apologize if you receive multiple copies of this message. ********************************************************** *** LDTA 2003: ACM SIGPLAN Workshop *** *** APRIL, 6, 2003 *** *** WARSAW, POLAND *** *** *** *** http://www-sop.inria.fr/LDTA2003 *** ********************************************************** Scope: ------ The aim of this one day workshop is to bring together researchers from academia and industry interested in the field of formal language definitions and language technologies, with a special emphasis on tools developed for or with these language definitions. Benefits of such active research fields are, among others: - Program analysis, transformation, generation - Formal analysis of language properties - Automatic generation of language processing tools Although these benefits are well-known, they are in current practices hardly exploited. For example, language definitions can be augmented in a manner that not only compilers/interpreters can be automatically generated but also other tools such as syntax-directed editors, debuggers, partial evaluators, test case generators, documentation generators, etc. Domains of applications that are of interest for this workshop are among others: - Language components, modeling languages - Re-engineering, re-factoring - Aspect-oriented programming, adaptive programming - Domain-specific languages - XML processing - Visualization and graph transformation Invited Talk: ------------- Hassan Ait Kaci, Distinguished Scientist, Research an Development, ILOG, France. Tool demonstrations: -------------------- The one day LDTA 2003 workshop program will also include a session on tool demonstrations. Submission procedure and publication: ------------------------------------- Submission process will be open in autumn 2002. Papers (of at most 15 pages) should be submitted electronically as (optionally compressed/gzipped) PostScript or PDF files to one of the program committee chairs: Barrett Bryant (bryant(a)cis.uab.edu) or Joao Saraiva (jas(a)di.uminho.pt) The message should also contain a text-only abstract and author information. Final copies of accepted papers, after revision, must not be longer than 20 pages and have to respect the proceedings style. Accepted papers will be published and available during the workshop. After revision, final copies of the accepted papers will be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science. Author's instructions are given here. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and after acceptance be published in a special issue devoted to LDTA 2003 of the journal Science of Computer Programming (Elsevier Science). Organizing Committee: --------------------- Isabelle Attali, INRIA Sophia Antipolis Mark van den Brand, CWI Amsterdam Pierre-Etienne Moreau, LORIA-INRIA Nancy Program committee co-chairs: ---------------------------- Barrett R. Bryant, University of Alabama at Birmingham, USA Joao Saraiva, University of Minho, Portugal Program Committee members: -------------------------- Don Batory, University Texas / Austin (USA) Uwe Glaesser, Simon Fraser University (Canada) Katsuhiko Gondow, JAIST (Japan) Uwe Kastens, University Paderborn (Germany) Paul Klint, CWI (The Netherlands) Jan Madey, University of Warsaw (Poland) Marjan Mernik, University of Maribor (Slovenia) Thomas Noll, University Aachen (Germany) Oege de Moor, Oxford University Computing Laboratory, (England) Peter D. Mosses, BRICS, University Aarhus (Denmark) Eelco Visser, Utrecht (The Netherlands) ----------------------------------------------------------------------- IMPORTANT DATES ----------------------------------------------------------------------- December 1st 2002 Submission of full paper January 20th 2003 Notification February 15th 2003 Final version due April 6th 2003 LDTA 2003

1 0