March 2001 - Haskell - Haskell.org

tuple component functions
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

S.D.Mechveliani writes: > As Haskell has the standard functions fst, snd to decompose (a,b), > maybe, it worths to provide also > tuple31, tuple31, tuple31, > ... > tuple51, tuple52, tuple53, tuple54, tuple55 > > for the tuples of n = 3,4,5 ? I've found some of these useful, except I named them differently: > fst3 :: (a,b,c) -> a > fst3 (x,_,_) = x > snd3 :: (a,b,c) -> b > snd3 (_,x,_) = x > thd3 :: (a,b,c) -> c > thd3 (_,_,x) = x .... never got around to quadruples etc. I also defined (some of these may be untested): > tripl :: a -> (a,a,a) > tripl x = (x,x,x) > curry3 :: ((a, b, c) -> d) -> a -> b -> c -> d > curry3 f x y z = f (x, y, z) > uncurry3 :: (a -> b -> c -> d) -> ((a, b, c) -> d) > uncurry3 f t = f (fst3 t) (snd3 t) (thd3 t) > applyTriple :: (a -> b, a -> c, a -> d) -> a -> (b,c,d) > applyTriple (f,g,h) x = (f x, g x, h x) > cross3 :: (a -> b, c -> d, e -> f) -> (a,c,e) -> (b,d,f) > cross3 (f,g,h) (x,y,z) = (f x, g y, h z) > mapTriple :: (a -> b) -> (a, a, a) -> (b, b, b) > mapTriple = cross3 . tripl > applyFst3 :: (a -> b) -> (a, c, d) -> (b, c, d) > applyFst3 f = applyTriple (f . fst3, snd3, thd3) > applySnd3 :: (a -> b) -> (c, a, d) -> (c, b, d) > applySnd3 f = applyTriple (fst3, f . snd3, thd3) > applyThd3 :: (a -> b) -> (c, d, a) -> (c, d, b) > applyThd3 f = applyTriple (fst3, snd3, f . thd3) > applyArgs3 :: (a -> b) -> (c -> d) -> (e -> f) -> (b -> d -> f -> g) -> (a -> c -> e -> g) > applyArgs3 af1 af2 af3 f = \x y z -> f (af1 x) (af2 y) (af3 z) > rotl :: (a -> b -> c -> d) -> (b -> c -> a -> d) > rotl f y z x = f x y z > rotr :: (a -> b -> c -> d) -> (c -> a -> b -> d) > rotr f z x y = f x y z > rotl4 :: (a -> b -> c -> d -> e) -> (b -> c -> d -> a -> e) > rotl4 f y z t x = f x y z t > rotr4 :: (a -> b -> c -> d -> e) -> (d -> a -> b -> c -> e) > rotr4 f t x y z = f x y z t Some more combinators (only for pairs so far): > twin :: a -> (a,a) > twin x = (x,x) > swap :: (a,b) -> (b,a) > swap (x,y) = (y,x) -- apply a pair of functions to one argument > applyPair :: (a -> b, a -> c) -> a -> (b, c) > applyPair (f, g) x = (f x, g x) -- apply a pair of functions to a pair > cross :: (a -> b, c -> d) -> (a, c) -> (b, d) > cross (f, g) = applyPair (f . fst, g . snd) -- compose a pair of functions onto one function > dotPair :: (a -> b, a -> c) -> (d -> a) -> (d -> b, d -> c) > dotPair (f, g) h = (f . h, g . h) -- compose a pair of functions onto a pair of functions > dotCross :: (a -> b, c -> d) -> (e -> a, f -> c) -> (e -> b, f -> d) > dotCross (f, g) (h, i) = (f . h, g . i) > mapPair :: (a -> b) -> (a, a) -> (b, b) > mapPair = cross . twin > applyFst :: (a -> b) -> (a, c) -> (b, c) > applyFst f = applyPair (f . fst, snd) > applySnd :: (a -> b) -> (c, a) -> (c, b) > applySnd f = applyPair (fst, f . snd) > applyArgs :: (a -> b) -> (c -> d) -> (b -> d -> e) -> (a -> c -> e) > applyArgs af1 af2 f = \x y -> f (af1 x) (af2 y) > betweenFst :: (a -> b -> c) -> (a, d) -> (b, e) -> c > betweenFst = applyArgs fst fst > betweenSnd :: (a -> b -> c) -> (d, a) -> (e, b) -> c > betweenSnd = applyArgs snd snd I find these combinators useful, and probably other people have their own versions - it would be nice to get them standardised, so we all speak the same language. By standardised, I mean a prominent version that will be adopted by users, not necessarily a committee process. Tim

3 2

ICFP programming contest
by trb＠eastpac.com.au 03 Jan '03

03 Jan '03

Michael Hobbs writes: > Just took a look at the results for the ICFP contest. Am I correct in > assuming that "LA" stands for Lennart Augustsson and that "Si^3" stands > for Simon Marlow, Simon Peyton-Jones, Sigbjorn Finne? Is there a URL for the results ? Tim

2 1

CFP: JFP on SAIG
by Walid Taha 08 Jul '01

08 Jul '01

CALL FOR PAPERS A Special Issue of JFP on Semantics, Applications, and Implementation of Program Generation http://cs-www.cs.yale.edu/~taha/saig/jfp.html Program generation has the prospect of being an integral part of a wide range of software development processes. Recent studies investigate different aspects of program generation systems, including their semantics, their applications, and their implementation. Existing theories and systems address both high-level (source) language and low-level (machine) language generation. A number of programming languages now support program generation and manipulation. These languages can have different goals, use different different implementation techniques, and target different applications. In this context, a PLI workshop dedicated to this theme (SAIG'00) was held this year. Following on from this workshop, a special issue of the Journal of Functional Programming will be devoted to the same theme. Full-length, archival-quality submissions are solicited on topics including both theoretical and practical models and tools for building program generation systems, Examples include: * Semantics, type systems, and implementations for multi-stage languages. * Run-time specialization systems: e.g. compilers, operating systems. * High-level program generation (applications, foundations, environments). * Symbolic computation, linking and explicit substitution, in-lining and macros. Reports on applications of these techniques to real-world problems are especially encouraged, as are submissions that relate ideas and concepts from several of these topics, or bridge the gap between theory and practice. Contributors to SAIG'00 are encouraged to submit, but submission is open to everyone. Papers will be reviewed as regular JFP submissions, and acceptance in the special issue will be based on relevance to the theme. The special issue also welcomes high-quality survey and position papers that would benefit a wide audience. Accepted papers exceeding the space restrictions will be published as regular JFP papers. Submissions should be sent to the guest editor (address below), with a copy to Nasreen Ahmad (nasreen(a)dcs.gla.ac.uk) Submitted articles should be sent in postscript format, preferably gzipped and uuencoded. In addition, please send, as plain text, title, abstract, and contact information. The submission deadline is February 1st, 2001. For other submission details, please consult an issue of the Journal of Functional Programming or see the Journal's web page at http://www.dcs.gla.ac.uk/jfp/. Guest Editor Editor in Chief Walid Taha Department of Computer Science Philip Wadler Yale University Avaya Labs P.O. Box 208285 700 Mountain Ave, Room 2T-402, New Haven, CT 06520-8285, Murray Hill, NJ 07974-0636, USA. USA. Email: taha(a)cs.yale.edu Email: wadler(a)avaya.com Phone: +1 203 432 6496 Phone: +1 908 582 4004 Fax : +1 203 432 0593 Fax: +1 908 582 5857

1 5

question class tree
by Maldonado Castiblanco Camilo Ernesto 02 Apr '01

02 Apr '01

I need a class tree for haskell. where can i find it?

2 1

ffi & recursive data types
by dario.bahena＠correo.unam.mx 02 Apr '01

02 Apr '01

hi ... I'm new in ffi stuff and tools like greencard. Everything was working ok, until I wanted to: translate a haskell recursive data type(list,trees,etc) into a corresponding C type and back again. How can I do this? Thanks in advance saludos dario estepario ... ------------------------------------------------- Obtén tu correo en www.correo.unam.mx UNAMonos Comunicándonos

2 1

Re: Welcome to the "Haskell" mailing list
by luc 31 Mar '01

31 Mar '01

haskell-request(a)haskell.org wrote: > Welcome to the Haskell(a)haskell.org mailing list! > > To post to this list, send your email to: > > c > hi. im just a newcomer to haskell (www.taesch.com) quite impressed till now ! im trying to have haxml lib running with hugs and had the following problem : 1) under win, quite an issue to tun the cpp stuff. did it under linux, (for info) 2) then i had a "maybeA" which is unknown. some lib i had to add ? ("maybe" doesnt seems to work) 3) a module declare a "with" function, which hugs doenst seem to like . renamed it withlt for now. this make me thinks that this lib is probably not tested under hugs98. could someone confirm that ? as im too newbies, im maybe missing something obvious. Id better asking, i thought. thanks Luc

3 2

A GUI toolkit looking for a friend
by Simon Peyton-Jones 31 Mar '01

31 Mar '01

Gentle Haskellers This message is to invite offers to complete a promising port of the Clean Object I/O library to Haskell. As you know, there are quite a few GUI toolkits for Haskell, but none of them has become a de-facto standard. One confusing aspect is that there are different "levels": (see http://haskell.org/libraries/#guigs) * Low-level veneers on top of existing libraries. HOpenGL, GTK, TclHaskell, the Win32 library, all fall into this category. They are rich, but hard to use because you have to adopt the programming model of the library, which is usually very imperative. * Very high-level systems, such as Fudgets, Haggis, FranTk. These are rather sophisticated and (esp Fudgets, FranTk) attempt to break with the imperative programming model. But I don't think any of them has been acclaimed as The Right Way To Do It. We're still looking! * Strangely, there are very few "in the middle" systems. One might hope for an interface that was somewhat independent of the low-level library, and somewhat more Haskell friendly, than the low-level veneers, but not as ambitious as the high-level systems. On top of that, some libraries deal in graphical user interfaces (buttons, menus..) and some deal in graphics (pictures, lines, shading). I think we should encourage the development of more "in the middle" systems. One example is Koen Claessen's Yahu system, http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/yahu.html However, there is another functional language that has put years of development into a GUI library: Clean. The Clean Object I/O library is well-documented and the Clean team have had a lot of experience in using it. It runs on both Windows and Mac, but not currently on Unix. http://www.cs.kun.nl/~clean/About_Clean/page_modified/page_modified.html Maybe we should build on their experience! Peter Achten, its author, spent a few weeks in Cambridge, porting the Clean library to Haskell. The results are very promising. The main ideas come over fine, translating unique-types to IO monad actions, and the type structure gets a bit simpler. So what we need now is to complete the port. Peter didn't have time to bring over all the widgets, nor did he have time to clean up the Haskell/C interface. (Clean's FFI is not as well-developed as Haskell's, so the interface can be made much nicer.) The other significant piece of work would be to make it work on Unix, perhaps by re-mapping it to GTK or TkHaskell or something. So the main burden of this message is: Would anyone be interested in completing the port? Fame (if not fortune) await you! The prototype that Peter developed in is the hslibs/ CVS repository, and the GHC team would be happy to work with you to support your work. (The more compiler-independent we can make the library, the better.) Peter Achten is willing to play consultant too. The Clean team are happy for the code to be open source -- indeed, all the hslibs/ code is BSD-licensed. It would not be the work of a moment. There are subtle issues involved (especially involving concurrency), and the design is not complete, so it isn't just boring hacking. So it should fun. Anyone interested? Maybe more than one person could work on it together. [And are there any other "in-the-middle" libraries I've overlooked?] Simon

3 2

RE: FixIO/ Tackling Awkward Squad
by Simon Peyton-Jones 31 Mar '01

31 Mar '01

| Dear Haskellers, | After enjoying "Tackling the Awkward Squad" (Simon | Peyton Jones), I wonder what other elements of the | squad can be tackled in a simular way? Right now I am | thinking about FixIO. This little bugger seems to show | up in a lot of code! Can we give it an operational | semantics a la Tackling the awkward squad? I am quite | stumped on this one, so i wont event post my meager | attempts, but rather hope someone brighter then me | will :) We need to add a new Value "FixIO N"... I'd be inclined to do it like this: fixIO m = do { v <- newEmptyMVar ; result <- m (unsafePerformIO (takeMVar v)) ; putMVar v result ; return result } Of course, this just begs the question of what exactly unsafePerformIO might mean, and we can only really answer that when we give an operational semantics to the functional part of the language as well as the imperative part. But perhaps the meaning of fixIO becomes clearer with the above. (Of course an implementation is free to implement it some other way too.) Simon

6 12

Re: question class tree
by Matthias Fischmann 31 Mar '01

31 Mar '01

Cris Okasaki [http://www.cs.columbia.edu/~cdo] has written tons of papers on functional data structures, I guess you can steal code from there. There was also a file containing all the examples from his book `Purely Functional Data Structures' (Cambridge University Press, 1998, and everybody sais it's a must although I haven't seen it yet). Unfortunately, I could not find it any more. Matthias Maldonado Castiblanco Camilo Ernesto <2003250(a)mail.escuelaing.edu.co> writes: > I need a class tree for haskell. where can i find it? > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Matthias Fischmann | Research Engineer | +358 (9) 8565 7474 fis(a)ssh.fi | SSH Communication Security Corp | +358 (40) 752 5291

1 0

Parameterising Class Constraints in Existential Types
by Ashley Yakeley 30 Mar '01

30 Mar '01

Is this valid (extended) Haskell? -- class MyClass a b where foo :: a -> b -> Int data Special = forall b. (MyClass Int b)=> MkSpecial b data General a = forall b. (MyClass a b)=> MkGeneral b -- Hugs complains about the 'General' line but has no problem with the 'Special' line... -- Ashley Yakeley, Seattle WA

2 1