May 2003 - Haskell - Haskell.org

Re: The Fun of Programming Edited by Gibbons and de Moor
by John Peterson 27 May '03

27 May '03

I'll get this on the "Haskell Bookshelf" at haskell.org as soon as I can. I'd like to add that this is a really good book! It would be really enjoyable to teach a class from it. I'd like to collect the code from the book over at haskell.org so that it will be easier to get at all of the excellent examples in it. John

1 0

Pattern matching 'undefined'
by Alain Cremieux 27 May '03

27 May '03

Hi, I want to represent a list of (key, values) in Haskell, where key are predefined strings So I define a datatype using field labels : data UR = MkUR { fieldA :: Int, fieldB :: Int, fieldC :: String } deriving (Show) and, for example, we have testUR = MkUR {fieldA = 1} testUR' = MkUR {fieldA = 2, fieldB = 3, fieldC = "C"} Now I want to write a function which transforms my datatype in [(String, String)] where a (key, value) element exists if the field is present, and none if the field does not exist. attrList :: UR -> [(String, String)] attrList u = al "fieldA" (fieldA u) ++ al "fieldB" (fieldB u) ++ al "fieldC" (fieldC u) al :: (Show a) => String -> a -> [(String, String)] al fn fv = [(fn, show fv)] Of course, as written, "attrList testUR'" succeeds and "attrList testUR" fails (Missing field in record construction Main.fieldB) I need to match against undefined, which is impossible. Is there a solution (probably involving irrefutable patterns, ~) ? Or is there a better way than using field labels (they are useful though, because I can define types to check the content at compile time, like data Location = Top | Bottom, which is far better than defining everything to be a String) Thank you for your help, Alain

3 4

ANNOUNCE: New Chameleon version
by Martin SULZMANN 27 May '03

27 May '03

New features: A Haskell Programmer's Guide to Chameleon Lexically Scoped Annotations Interactive Debugging in Haskell See http://www.comp.nus.edu.sg/~sulzmann/chameleon/ for details. Martin

1 1

Problems with 'readFile'
by Niels Reyngoud 24 May '03

24 May '03

Hello, We are two students from the University of Utrecht (the Netherlands) working on a project in Haskell. During work on the project, we encountered a problem with the 'readFile' IO Monad. readFile stops reading a file when it encounters ASCII character 26, as the following piece of coding shows. We've tested this with both the Hugs interpreter and the GHC compiler, but both encounter the same problem. Are there any known solutions for this? Regards, Richard Nieuwenhuis and Niels Reyngoud ------------ module Main where main = do let output = problemtext putStr output putStr "\n\n" writeFile "outputfile.txt" output text <- readFile "outputfile.txt" putStr text problemtext :: String problemtext = "strange\SUBstrange"

6 5

RE: GHCi ASCII art
by Simon Marlow 24 May '03

24 May '03

> since the content of this list is in general so completely beyond > my feeble Haskell comprehension, I feel I must make a nuisance of > myself with some inane criticism of the GHCi ASCII art ... ! > > > % ghci > > ___ ___ _ > > / _ \ /\ /\/ __(_) > > / /_\// /_/ / / | | GHC Inter[..], v[..] 5.04.2, > for H[..] 98. > > / /_\\/ __ / /___| | http://www.haskell.org/ghc/ > > \____/\/ /_/\____/|_| Type :? for help. > > > Aaaargh... > > Surley there is an arty type out there who can improve on > that illegible mess which is believe, supposed to be "GHCi" ! Don't blame us, blame Figlet (http://www.figlet.org/) Cheers, Simon

2 1

IO monad and lazy evaluation
by Graham Klyne 23 May '03

23 May '03

There seems to be a difficult-to-justify interaction between lazy evaluation and monadic I/O: [[ -- file: SpikeIOMonadCloseHandle.hs -- Does hClose force completion of lazy I/O? import IO showFile fnam = do { fh <- openFile fnam ReadMode ; fc <- hGetContents fh ; hClose fh ; putStr fc } test = showFile "SpikeIOMonadCloseHandle.hs" ]] If I load this into Hugs and run it, the output is a single blank line. If I reverse the order of hClose and putStr, the source code is displayed. I think I can understand why this is happening, but it seems to me that there's a violation of referential transparency here: I can't see any reasonable justification for the value of 'fc' to vary depending on whether it's actually used before or after some other I/O operation. I suppose I was expecting the call of hClose to force complete evaluation of any value that depends on the state prior to hClose. I've no idea if there's a reasonable way to implement that. My concern is that this weakens the claim for monads that they provide a seamless integration between pure functional and stateful code; cf.: [[ We believe that, on the contrary, there are very significant differences between writing programs in C and writing in Haskell with monadic state transformers and IO: [...] - Usually, most of the program is neither stateful nor directly concerned with IO. The monadic approach allows the graceful coexistence of a small amount of imperative code and the large purely functional part of the program [...] - The usual coroutining behaviour of lazy evaluation, in which the consumer of a data structure coroutines with its producer, extends to stateful computation as well. As Hughes argues (Hughes 1989), the ability to separate what is computed from how much of it is computed is a powerful aid to writing modular programs ]] -- http://research.microsoft.com/Users/simonpj/Papers/state-lasc.ps.gz #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

10 20

ICALP2003: Early registration deadline May 28.
by icalp2003＠TUE.nl 23 May '03

23 May '03

------------------------------Call For Participation----------------------- We apologize for the reception of multiple copies of this message. ---------------------------------------------------------------------------- ICALP2003 Thirtieth International Colloquium on Automata, Languages and Programming Eindhoven, The Netherlands, June 30 - July 4, 2003 http://www.win.tue.nl/icalp2003/ DEADLINE FOR EARLY REGISTRATION MAY 28 The 30th annual meeting of the European Association of TheoreticalComputer Science will be held in Eindhoven, The Netherlands, at the Technische Universiteit Eindhoven. As with the journal Theoretical Computer Science (TCS), the scientific program of the Colloquium will be split into two parts: Track A of the meeting will cover Algorithms, Automata, Complexity and Games, while Track B covers Logic, Semantics and Theory of Programming. The full program, containing 84 accepted papers and 6 invited contributions is now available at the ICALP2003 website ( http://www.win.tue.nl/icalp2003/Schedule.html ). Invited speakers Jan Bergstra: Polarized process algebra and program equivalence Anne Condon: Problems in RNA secondary structure prediction and design Amos Fiat: Some issues regarding search, censorship, and anonimity in peer to peer networks Petra Mutzel: The SPQR-tree data structure in graph drawing Doron Peled: Model checking and testing combined Moshe Vardi: Logic and automata, a match made in heaven Workshops and surrounding events In the weekends preceeding and following ICALP2003 nine workshops of interest to the EACTS-community will be held at the conference venue, a list is available at conference website ( http://www.win.tue.nl/icalp2003/Workshops.html ). In the week before ICALP (June 24-27), two more international conferences in computer science are hosted by the TU Eindhoven at the same venue: the 24th International Conference on Application and Theory of Petri Nets, ATPN 2003, and the Conference on Business Process Management, BPM 2003. Besides these scientific events, a number of other activities such as excursions, a social event, a festive award presentation, and an event on education in theoretical computer science are part of ICALP2003. For a complete overview, see the "Events" section of the website ( http://www.win.tue.nl/icalp2003/Events.html ). Venue Eindhoven is the fifth largest city in the Netherlands, with good railconnections to the rest of the country and neighbouring countries. It can be reached by train from Schiphol, the main airport of the Netherlands, in only 1.5 hours. The campus of the Technische Universiteit Eindhoven is located in the centre of the city, within walking distance of the train station and the conference hotels. Registration The important dates for registration are: Deadline for early registration May 28 Deadline for late registration June 20 The conference website contains an online registration form which also allows you to make reservations at the conference hotels ( http://www.win.tue.nl/icalp2003/Registration.html ) Contact information ICALP2003 Office Technische Universiteit Eindhoven Department of Mathematics and Computing Science P.O. Box 513 5600MB Eindhoven The Netherlands Telephone: +31 40 2474124 Fax: +31 40 2475361 E-mail: icalp2003(a)tue.nl URL: www.win.tue.nl/icalp2003/

1 0

Licensing of Haskell code
by Mark Carroll 23 May '03

23 May '03

I should mention to contributors to the Haskell community that the precise licensing of their code can matter a lot. With my commercial company hat on, we tend to have to avoid using Haskell stuff that is GPL'd, and I worry generally about proliferation of such code impeding efforts to have Haskell take off in industry. BSD-style licenses are a lot easier because they don't "infect" other code from the same application, which may even be from other commercial partners, etc. (The LGPL is probably better in this respect, too.) With my altruistic idealist hat on, I am glad that the GPL impacts the commercial software industry, I think it was generally a good idea, and maybe it's for the greater good even it disadvantages some companies. And, if a company doesn't like that something's GPL'd, they can track down the authors and negotiate to be licensed the code on some other basis. My point is not to tell people how they should license their code, although I'd be happy to discuss that over on haskell-cafe. I hope I can avoid opening too large a can of worms here. My points are more that: It matters which particular "opensource" licence you pick, so review them and choose carefully, based on your beliefs and ideals. It would be really great if it were somehow easy for Haskell developers to be easily able to check the licensing status of various bits of code - tools, libraries, etc. - that their software uses, or that they are thinking of having it use. It's not too hard to look into now, but after the Haskell community and hierarchical libraries have grown much more I don't know if one might wish that something had been built in early on that somehow eases semi-automated checking. -- Mark

7 7

RE: Licensing of Haskell code
by Simon Marlow 23 May '03

23 May '03

Ashley Yakely writes: > OK, this may not be immediately practical, but... as > contracts, would it > be possible to express licenses in a Haskell-like language? > Didn't Simon > PJ do some kind of work on this? There seem to be interesting > covariant/contravariant properties here, for instance, if I > require you > to allow A to anyone who does B, then that is satisfied if you allow > more than A to anyone who does less than B. I think that's a great idea. I've often thought that there ought to be a formal system for reasoning about source code licenses, at least so there would be a way to unambiguously decide when one license is "compatible" with another, and what precisely are the obligations on a programmer when distributing a work consisting of code licensed in two different ways. An DSL for licenses would be even better, since you'd presumably be able to interrogate the system to determine the properties of license combinations. Cheers, Simon

2 1

RE: Licensing of Haskell code
by Graham Klyne 23 May '03

23 May '03

This sounds like a possible application for the description logic (DL) [1] based systems that are being built for the semantic web... E.g. use DL-type structures to describe different software licensing terms ... what is permitted, what conditions apply, etc. If the licences concerned fall within the expressive constraints of DLs, a DL subsumption calculation should be able to derive the appropriate description of terms of if one is required to conform to multiple such licences (and if the permitted uses in such a subsumption is the empty set, one may deduce the licences are incompatible.) ALl of which, I think, would be readily expressed in Haskell. Another related, but different, approach might be based on some work I did for content negotation in Internet protocols, some time ago [2]. This takes a different slice through the form of logical expressions used to describe some set of possibilities, and algorithms for combining those expressions. #g -- [1] http://citeseer.nj.nec.com/borgida95description.html This is one of very many possible citations... it happens to be one that I found useful as an introduction to description logic ideas. I've also found some of Deborah McGuinness' papers in this area to be helpful. [2] http://www.ietf.org/rfc/rfc2533.txt At 12:16 23/05/03 +0100, Simon Marlow wrote: >Ashley Yakely writes: > > OK, this may not be immediately practical, but... as > > contracts, would it > > be possible to express licenses in a Haskell-like language? > > Didn't Simon > > PJ do some kind of work on this? There seem to be interesting > > covariant/contravariant properties here, for instance, if I > > require you > > to allow A to anyone who does B, then that is satisfied if you allow > > more than A to anyone who does less than B. > >I think that's a great idea. I've often thought that there ought to be >a formal system for reasoning about source code licenses, at least so >there would be a way to unambiguously decide when one license is >"compatible" with another, and what precisely are the obligations on a >programmer when distributing a work consisting of code licensed in two >different ways. > >An DSL for licenses would be even better, since you'd presumably be able >to interrogate the system to determine the properties of license >combinations. > >Cheers, > Simon > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0