February 2003 - Haskell

time since the epoch
by Mike T. Machenry 24 Feb '03

24 Feb '03

I am looking for a simple way to get the current days sincethe epoch. Most language's standard time library have a get-seconds function that returns the number of seconds since the epoch, thus the function is for example in scheme: (define (days-since-epoch) ((get-seconds) / (* 60 60 24))) But it seems that in haskell the standard definition for the time library will not give me seconds since the epoch. There is technically enough information in the CalendarTime structure to calculate it, but it is a pretty complicated algorithm. Not to mention the fact that it is the exact opposite of the algorithm used to get that information in the first place, so I'd like to not have to undo it and just get the seconds as they are. Thanks for the help -mike

4 5

haskell wish list
by Hal Daume III 24 Feb '03

24 Feb '03

This seems to have been down for some time. Anyway capable of reviving it? -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

11 13

two easy questions
by Mike T. Machenry 24 Feb '03

24 Feb '03

Question 1: Is there an easier, more elegant way to write this code? output a b c d e = println "Hello, this is " ++ show a ++ " a really hard " "to write function that " ++ show b ++ " would be easier to write with " "a printf " ++ show c ++ show d ++ show e Question 2: Is there a way to express the following relationship? I want to have a set of symbols with ordering and another set that is part of that ordering but with a different parent. For exammple, data Player = Detective | Fugitive deriving (Enum) data Detective = Red | Green | Blue deriving (Enum) data Fugitive = MrX deriving (Enum) I want (succ Blue) == MrX and (pred MrX) == Blue. I could do this by putting them all in the same enumeration but I want to be able to test that the symbol is a Detective or Fugitive. By the way, how do I test that it's a detective? Do I pattern match it? foo Detective(x) = if x == Purple then ... else ... -- ? Thanks for the help. -mike

6 9

Theorem proving
by Dmitry Malenko 22 Feb '03

22 Feb '03

Hi, All! Searching the web I've come across some theorem provers for Haskell. I wonder if somebody is using them in his daily work. Any way I would like to hear your opinions about some of the provers as well as about the whole idea of proving programs rather than testing them. -- Best regards, Dmitry Malenko. +----------------------------------------------------+ Registered Linux user #258004 ALT Linux Team http://www.altlinux.ru +----------------------------------------------------+ Do you guys know what you're doing, or are you just hacking?

1 0

Re: Q. about XML support
by oleg＠pobox.com 22 Feb '03

22 Feb '03

Joe English wrote: > case nodeName node of > "html:p" -> ... > "html:h1" -> ... > "html:pre" -> ... > The approach I'm thinking of is to let the application programmer > define an "internal" namespace environment, then rewrite > element and attribute names in the parsed document to > use the locally-defined prefixes. SXML [1] treats the namespaces precisely this way. All element and attribute names are fully resolved extended names, that is, with the namespace URI if any, e.g., http://www.w3.org/1999/xhtml:p All the names are symbols (a.k.a. interned strings), which means that multiple occurrences of the same seemingly long name share all of the name's characters. However, it is still awkward to read such names. Therefore, SXML provides for so-called user ns-shortcuts. They look like XML Name prefixes, with an important distinction: ns-shortcuts are in a one-to-one correspondence with the namespace URIs. XML Namespace prefixes do not have this property. Furthermore, ns-shortcuts are determined by the author of the processing application whereas XML Namespace prefixes are chosen by the author of a document. SXML specification discusses the issue of XML Namespaces in XML AST at great length -- and points out to more discussion, about dealing with namespaces in XPath and XSLT. Incidentally, SXML is a language-neutral specification. One can easily use Expat to write SXML. There are parsers that convert XML and a (possibly ill-formed) HTML to SXML. An example code [2] demonstrates parsing and unparsing of a namespace-rich document: a DAML RDF file. DAML (DARPA Agent Markup Language) ontologies typically use a great number of namespaces. The example code demonstrates that parse . unparse . parse === parse [1] http://pobox.com/~oleg/ftp/Scheme/SXML.html [2] http://cvs.sf.net/cgi-bin/viewcvs.cgi/ssax/SSAX/examples/daml-parse-unparse… (written in Scheme, sorry)

1 0

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