- Haskell - Haskell.org

can this be written more easily?
by Mike T. Machenry 21 Feb '03

21 Feb '03

Hey Everyone, I am having a hard time making a data structure that I can incrimentally update. Mostly because dealing with arrays is so tough. Does anyone think I'm going about this completely the wrong way? This is what I have. data GameState = GameState { dTickets :: Array Player (Array Ticket Int), fTickets :: Array FugitiveTicket Int, history :: [Move], dLocations :: Array Player Stop, fLocations :: Set Stop } removeTicket :: GameState -> Detective -> Ticket -> GameState removeTicket s d t = s { tickets = (tickets s) // [(d,[(t,((tickets s)!d!t - 1))])] } This remove ticket function is just terrible and it's common for me to have to do operations like this. It's been hard to make this a function that I can pattern match on, because which piece of data is manipulated depends on the parmeter d (Detective) Incase you all didn't notice, I decided to write a game in Haskell to learn it. Thanks for all the useful help. I should know Haskell pretty well by the end of all this. -mike

2 2

Database Mailing List
by Dominic Steinitz 21 Feb '03

21 Feb '03

There seems to be a small group of Haskell users who are interested in building and using interfaces to databases. Would it be possible to set up a mailing list for those interested? I'd be happy to administer it if required (although someone would have to show / tell me what needs doing). Dominic Steinitz

6 5

About "class Coerce a b"
by Nick Name 21 Feb '03

21 Feb '03

Reading the paper "Type Classes with Functional Dependencies" by Mark P. Jones, I noticed he mentions the "Coerce" class as a way to model the subtyping relation. I have looked at the article there referred, "How to make ad-hoc polymorphism less ad-hoc" by Wadler and Blott. By now, I can't find more references to this idea; it looks very promising for when one wants subtyping in haskell: ********** class Subtype a b where convert :: a -> b instance Subtype a a where convert = id call f x = f (convert x) -- Silly but powerful example instance (Show a) => Subtype a String where convert = show -- Does not type if overlapping instances are allowed -- --instance Functor SList where -- fmap f End = End -- fmap f (a:::as) = (call f a):::(fmap f as) ********** This leads to many compilation problems, one has to use -fallow-undecidable-instances (guess why ^___^), -fallow-overlapping-instances and -fglasgow-exts, and fmap is still not typing but... why has no one cared till now? If someone can give me pointers to articles that shows other problems of this approach, or extends this simple idea, I'll be grateful. Vincenzo

2 2

Interesting Read (fwd)
by Rex Page 20 Feb '03

20 Feb '03

Here are two things I found interesting: 1. The author comments that programs are not theorems. He is correct. They are, instead, proofs of theorems. The problem is, programmers almost never know what theorems their programs prove. 2. All of the criteria the authors gives for "good languages" apply, in spades, to Haskell, except the point on libraries. On that one, we're pedaling as fast as we can, but there aren't enough of us. Rex Page ---------- Forwarded message ---------- Date: Tue, 18 Feb 2003 20:22:46 -0800 (PST) From: David Sankel <camio(a)yahoo.com> To: Haskell Mailing List <haskell(a)haskell.org> Subject: Interesting Read An interesting read: http://www.paulgraham.com/popular.html Any thoughts? ---- David J. Sankel _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

5 4

2nd CFP: Workshop on Model Checking and Artificial Intelligence (MoChArt-03)
by Charles Pecheur 20 Feb '03

20 Feb '03

[This is a reminder re-send. Apologies if you receive more than one copy of this message. -- The Organizers.] ===================================================================== CALL FOR PAPERS & PARTICIPATION *************************************** SECOND WORKSHOP ON MODEL CHECKING AND ARTIFICIAL INTELLIGENCE (MoChArt-03) August 10, 2003, Acapulco, Mexico IJCAI-03 Workshop Program http://mochart03.na.infn.it/ *** Submission deadline: March 7, 2003 *** ===================================================================== Model checking (MC) is the name given to the process of determining whether or not a formula of some logic is satisfied by a model for the logic. Model checking is limited by its exponential complexity with respect to the size of the system being verified. Nevertheless, MC procedures for many classes of models and logics of interest have been efficiently automated and successfully applied to a broad range of real-size applications in the last decade. These recent advances have lead to a growth of interest in the use of the technology in Artificial Intelligence (AI). In the meantime, state space exploration is a central aspect of AI, and the AI community has a long and impressive line of research in developing and improving search algorithms over very large state spaces under a broad range of assumptions. MC researchers are showing a growing interest in this vast body of knowledge, as a way to mitigate the state-space explosion problem. Under a slightly different perspective there is growing interest in the use of model checking techniques for verifying and validating AI applications (as opposed to inside these applications themselves). This is becoming a critical issue, as AI techniques are increasingly considered for safety-critical applications such as space missions. AI software typically features unconventional architectures and requirements that ask for specific verification solutions. These solutions will only emerge from a sustained dialogue between the AI and V&V communities, through forums such as this one. The purpose of the Second MoChArt workshop is therefore to bring together researchers with an interest in both MC and AI. The goals are to tease out common themes and differences, identify common problems and their solutions, share experiences with the applicability of techniques from one field to problems from the other, and to identify the key issues to be addressed in increasing the convergence between MC and AI. The workshop will welcome submissions on all ideas, research, experiments and tools that relate to both MC and AI fields. Topics of interest include: - Foundations - Comparisons between MC and AI problems, approaches and algorithms. - Model checking for combined modal/temporal logics - Model checking for logics of common sense reasoning - Model checking approaches to AI - Planning via model checking - Model checking for multi-agent systems - Model checking for diagnosis - Model checking for games - Using concurrency models in AI (Process Algebras, Petri Nets, Statecharts,...) - AI approaches to model checking - AI approaches to the state explosion problem - Heuristics for model checking - AI approaches to automatic abstraction - Model checking for verification of AI systems - Requirements/specifications/properties for AI systems - Automated verification of AI systems - Model checking of multi-agent systems - Model checking of model-based systems - Model checking of knowledge-based systems - Tools related to any of these topics - Case studies related to any of these topics SUBMISSION The workshop notes will include original material. Archived material will also be considered for presentation but will not appear in the proceedings. Shorter papers are encouraged, particularly those exposing novel ideas or work in progress. Authors are invited to submit papers (11pt, letter or A4, no more than 12 pages long) in PostScript format or Adobe PDF by March 7, 2003 to the following e-mail address: mochart03(a)na.infn.it. The first page of each submission should carry the contact details of a nominated contact person, including email address. PARTICIPATION Participation will be by invitation. Potentially interested participants must submit a *short* position statement, indicating the reasons for their interest in the topics of the workshop to the e-mail address mochart03(a)na.infn.it, by April 1, 2003 IMPORTANT DATES AND DEADLINES - Deadline for the submission of papers: March 7, 2003. - Notification of acceptance/rejection of papers: March 30, 2003. - Deadline for the posotion statement: April 1, 2003 - Deadline for the receipt of camera-ready papers: May 15, 2003. ORGANIZING COMMITEE Massimo Benerecetti Dipartimento di Scienze Fisiche Universita di Napoli ``Federico II'' Via Cintia, Complesso Monte S. Angelo I-80126 Napoli, Italy e-mail: bene(a)na.infn.it http://people.na.infn.it/~bene/ Charles Pecheur RIACS / ASE Group NASA Ames Research Center, M/S 269-2 Moffett Field, CA 94035, U.S.A. e-mail: pecheur(a)ptolemy.arc.nasa.gov http://ase.arc.nasa.gov/pecheur ===================================================================== _______________________________________________________________________ Charles Pecheur RIACS / ASE Group NASA Ames Research Center, M/S 269-2 Bldg N-269, Rm 230 Moffett Field, CA 94035, U.S.A. http://ase.arc.nasa.gov/pecheur Phone : +1-650-604-3588 mailto:pecheur@ptolemy.arc.nasa.gov Fax : +1-650-604-3594 Home phone : +1-650-967-5918

1 0

H98 errata
by Ross Paterson 19 Feb '03

19 Feb '03

The definition of getLine given in 8.3: getLine :: IO String getLine = do c <- getChar if c == '\n' then return "" else do s <- getLine return (c:s) is incorrect in view of 7.1: The getLine operation raises an exception under the same circumstances as hGetLine, defined [in] the IO library. ("in" is missing from the published Report.) 21.9.2: The hGetLine computation fails with isEOFError if the end of file is encountered when reading the first character of the line. If hGetLine encounters end-of-file at any other point while reading in a line, it is treated as a line terminator and the (partial) line is returned.

1 0

effect of order of function arguments
by Aaron Denney 19 Feb '03

19 Feb '03

With a recursive function of more than one argument, does it make sense to keep the arguments that tend to remain constant closer to the front? I.e. is this: > interp :: a -> [a] -> [a] > interp y [] = [] > interp y (x:[]) = x:[] > interp y (x:xs) = x:y:interp y xs any better than this: > interp :: [a] -> a -> [a] > interp [] y = [] > interp (x:[]) y = x:[] > interp (x:xs) y = x:y:interp xs y Will any implementations notice interp y x:xs calls interp y, and keep some sort of interp y partial application around? (I don't really expect any effect like this, but even if there were one, I would expect consideration like the fact that "interp constant" is a useful function, while "\x -> interp x const-list" is not so useful to outweigh any such effect. Happily, they don't conflict here. If there is no effect like this, would it make any sense to try to get something similar by hand, and can this actually be done?) -- Aaron Denney -><-

5 4

RE: effect of order of function arguments
by Simon Peyton-Jones 19 Feb '03

19 Feb '03

| GHC used to have an optimisation for static argument like this. It would | turn both of the above programs into a similar form using a local | recursive function: | | interp y xs = interpaux xs | where interpaux [] = [] | interpaux (x:[]) = x:[] | interpaux (x:xs) = x:y:interpaux xs | | GHC doesn't do this anymore. The reason for this is unknown to me. It turned out to be a very minor effect (1-2% of execution time) and hard to tune; with lots of parameters, it's best to make a local function, with just a few it's best to pass the parameters round. S

1 0

RE: Yet another weakly defined bug report
by Simon Marlow 18 Feb '03

18 Feb '03

> The following code runs out of file handles, so I am seeking > enlightenment as to why. > > > -- | add data from a file to the histogram > > addFile :: FiniteMap String Int -> String -> IO (FiniteMap > String Int) > > addFile fm name = do > > x <- readFile name > > return (addHist fm x) > > > > -- | add data from all files in a directory to the histogram > > addDir :: FiniteMap String Int -> String -> IO (FiniteMap > String Int) > > addDir fm dir = do > > dc <- getDirectoryContents dir > > fs <- filterM doesFileExist (map ((dir++"/")++) dc) > > foldM addFile fm fs > > Running addDir on a directory with few hundred files trigs it. > Shouldn't all of each file's contents be consumed by each addFile, and > thus the handle be released? It's not possible to tell from this code whether the readFiles will be fully evaluated or not: it depends on how much evaluation addHist does, and to what extend the result FiniteMap is demanded, amongst other things. These things are always tricky to understand, which is why I recommend not using lazy I/O. File reading is not a pure operation: running out of file descriptors is a good counter-example. Cheers, Simon

6 9

type classes vs. multiple data constructors
by Mike T. Machenry 18 Feb '03

18 Feb '03

I have a type that is as follows: data PlayerState = FugitiveState { tickets :: Array Ticket Int, fHistory :: [Ticket] } | DetectiveState { tickets :: Array Ticket Int, dHistory :: [Stop] } I have a few functions that act on PlayerState. move :: PlayerState -> PlayerState move DetectiveState ... = move FugitivieState ... = I was wondering if it's better to define them as type classes with the operations defined in the class. What do haskellian's do? Oh and if I say Instance Foo Baz where ... and only define a few of the operations in Foo... bdoes Baz take on some default methods? - mike

2 1