August 2003 - Haskell

CFP: CLIMA IV - 4th Intl. Workshop on Computational Logic in Multi-Agent Systems
by João Alexandre Leite 03 Aug '03

03 Aug '03

========================================================================== SECOND CALL FOR PAPERS CLIMA IV Fourth International Workshop on Computational Logic in Multi-Agent Systems January 6-7, 2004, Fort Lauderdale, Florida, USA http://centria.di.fct.unl.pt/~jleite/climaIV/index.htm Post-Proceedings will be published in Springer Verlag LNAI Submission Deadline: September 19th Co-located with the 7th LPNMR and the 8th AIMATH =========================================================================== Over recent years, the notion of agency has claimed a major role in defining the trends of modern research. Influencing a broad spectrum of disciplines such as Sociology, Psychology, Philosophy and many more, the agent paradigm virtually invaded every sub-field of Computer Science, not least because of the Internet and Robotics. Multi-agent Systems (MAS) are communities of problem-solving entities that can perceive and act upon their environments to achieve their individual goals as well as joint goals. The work on such systems integrates many technologies and concepts in artificial intelligence and other areas of computing. There is a full spectrum of MAS applications that have been and are being developed; from search engines, educational aids to electronic commerce and trade. Although commonly implemented by means of imperative languages, mainly for reasons of efficiency, the agent concept has recently increased its influence in the research and development of computational logic based systems. Computational Logic, by virtue of its nature both in substance and method, provides a well-defined, general, and rigorous framework for systematically studying computation, be it syntax, semantics, procedures, or implementations, environments, tools, and standards. The purpose of this workshop is to discuss techniques, based on computational logic, for representing, programming and reasoning about multi-agent systems in a formal way. This is clearly a major challenge for computational logic, to deal with real world issues and applications. Following the workshop on Multi-Agent Systems in Logic Programming affiliated with ICLP'99, the first CLIMA workshop took place in London, UK, affiliated with CL'2000. The 2001 edition of CLIMA, took place in Paphos, Cyprus, affiliated with ICLP'01. CLIMA'02 took place in Copenhagen, Denmark, and was affiliated with ICLP'02 and part of FLOC'02. We solicit unpublished papers that address formal approaches to multi-agent systems. The approaches as well asbeing formal must make a significant contribution to the practice of multi-agent systems. Relevant techniques include, but are not limited to, the following: * Nonmonotonic reasoning in MAS * Planning under incomplete information in MAS * Logical foundations of MAS * Usage of abduction in MAS * Representation of knowledge and belief in MAS * Knowledge and belief updates in MAS * Temporal reasoning for MAS * Theory of argumentation for MAS * Negotiation and co-operation for MAS * Communication languages for MAS * Distributed constraint satisfaction in MAS * Modal logic approaches to MAS * Logic based programming languages for MAS * Distributed theorem proving for MAS * Logic based implementations of MAS * Decision theory for MAS * Logic based agents for the Internet SUBMISSION INSTRUCTIONS We welcome and encourage the submission of high quality, original papers, which are not simultaneously submitted for publication elsewhere. Please refer to the workshop web pages for further instructions concerning the submission procedures. IMPORTANT DATES * Submission: September 19th, 2003 * Notification of Acceptance: October 17th, 2003 * Final version due: November 13th, 2003 * CLIMA IV: January 6-7th, 2004 PROCEEDINGS Post-proceedings will be published by Springer-Verlag as a volume of the Lecture Notes on Artificial Intelligence (LNAI) series. Informal proceedings will be available at the workshop and online. PROGRAM COMMITTEE * Chitta Baral, Arizona State University, USA * Gerd Brewka, University of Leipzig, Germany * Jürgen Dix, The University of Manchester, UK * Thomas Eiter, Vienna University of Technology, Austria * Klaus Fischer, DFKI, Germany * Michael Fisher, University of Liverpool, UK * James Harland, Royal Melbourne Inst. of Tech., Australia * Katsumi Inoue, Kobe University, Japan * Gerhard Lakemeyer, Aachen Univ. of Technology, Germany * João Leite, New University of Lisbon, Portugal * Yves Lespérance, York University, Canada * John Jules Ch. Meyer, Univ. of Utrecht, The Netherlands * Leora Morgenstern, IBM, USA * Luís Moniz Pereira, New University of Lisbon, Portugal * Fariba Sadri, Imperial College, UK * Ken Satoh, National Institute of Informatics, Japan * Renate Schmidt, The University of Manchester, UK * Guillermo Simari, Universidad Nacional del Sur, Argentina * V. S. Subrahmanian, University of Maryland, USA * Francesca Toni, Imperial College, UK * Paolo Torroni, University of Bologna, Italy * Wiebe van der Hoek, University of Liverpool, UK * Cees Witteveen, Delft Univ. of Tech., The Netherlands WORKSHOP ORGANIZERS: * Jürgen Dix, The University of Manchester, UK (dix(a)cs.man.ac.uk) * João Leite, New University of Lisbon, Portugal (jleite(a)di.fct.unl.pt) INQUIRIES: Please send program suggestions and inquires to either of the organizers.

1 0

Laziness
by Dominic Steinitz 02 Aug '03

02 Aug '03

Could someone explain to me why this doesn't work test l = hs where hs = map (\x -> [x]) [0..abs(l `div` hLen)] hLen = length $ head hs whereas this does test l = hs where hs = map (\x -> [x]) (0:[1..abs(l `div` hLen)]) hLen = length $ head hs I would have thought laziness would allow the compiler to know that hs would contain at least one element and therefore calculate hLen. Dominic.

2 1

Haskell for educative games
by Andre W B Furtado 02 Aug '03

02 Aug '03

Does anyone know if Haskell is/was used to develop educative games? Do you recommend some papers on the subject? Thanks a lot, -- Andre Furtado

1 0

Re: Libraries and hierarchies
by John Meacham 01 Aug '03

01 Aug '03

confluence! Inspired by some posts the other day I implemented an immutable GUID naming scheme for interfaces with Haskell. I thought it would require compiler support, but it turns out a good 90% solution can be done as a separate program quite nicely and there are not too tough workarounds for the other 10%. http://repetae.net/john/computer/haskell/hsguid/ This is not really the same as your proposal, but is somewhat related and addresses many of the same issues. (and might be a bit lighter weight) actually, they would probably mix well as your proposed system could just use the same GUID pragmas hsguid uses as input. Let me know what y'all think. library developers, add a GUID to your code. it's easy and takes no resources, but could save users of your library a lot of hassle. :) John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john(a)foo.net ---------------------------------------------------------------------------

2 2

CSMR 2004 - CALL FOR PAPERS
by csmr2004＠unisannio.it 01 Aug '03

01 Aug '03

8th European Conference on Software Maintenance and Reengineering March 24 - 26, 2004 Tampere, Finland Call for Papers The European Conference on Software Maintenance is the premier European conference on the theory and practice of evolution, maintenance and reengineering of software systems. Now approaching its eight edition, we invite you to contribute to the discussion on the issues of developing maintainable systems and evolving, migrating and reengineering existing ones. The theme of this year's conference will be "the maintenance and evolution of the software architecture". Although nowadays the importance of designing a robust software architecture is well-understood by the industry, the activities related to its maintenance and evolution are rather immature and unsystematic. We solicit contributions on this theme. The topics of interest include, but are not restricted to: Evolution, maintenance and reengineering Software architecture recovery and evolution Automated software maintenance Software metrics Economical aspects of software evolution Pattern languages for evolution, maintenance and reengineering Experience reports (successes and failures) Tools and enabling technologies for evolution, maintenance and reengineering tools Formal methods to support evolution, maintenance and reengineering System assessment for evolution, maintenance and reengineering Migration, wrapping and interfacing legacy systems Dealing with legacy systems towards new technologies Data reengineering Reverse engineering of embedded systems Web-site evolution, maintenance and reengineering Migration towards Web-services Evaluation and assessment of reverse engineering tools Maintenance of open source projects Product family migration and maintenance One of the basic intentions of this conference is to offer a European forum for discussion and exchange of experiences among researchers and practitioners. Therefore, besides academics, we kindly invite all those in companies developing maintenance tools, offering reengineering services or going through legacy systems migration experiences to contribute by submitting papers or presenting innovative tools, solutions or experience reports. This conference is not limited to European participants. Authors from outside Europe are also welcomed. SUBMISSIONS Two types of submissions will be accepted: full length papers (not exceeding 4000 words in length and including a 150-200 word abstract) and short papers (not exceeding 2000 words in length and including a 75-100 word abstract) The official langue is Enligh. Authors are requested to submit electronically a PostScript or PDF version of their papers. In addition, they should send a separate file containing the title of the paper, full names, affiliations, postal and e-mail addresses, fax and telephone numbers of all authors. IEEE Computer Society Press will publish the CSMR 2004 Proceedings. Full papers exceeding 10 pages (4 pages for short papers) will be charged for pages in excess. Authors of accepted papers must sign the IEEE copyright form. At least one author of each accepted submission must register and present the paper at the conference. The Program Committee will select the best paper of the conference and a prize will be awarded for the winner. The Program Committee will select the winner and a formal presentation of the winner will be made in Tampere at CSMR 2004. SPECIAL SESSIONS Sessions of special interest, workshops, and tool demonstrations are welcomed. Please send suggestions to the program chair before the submissions closing date. SUBMISSION METHOD For submission details please visit the conference website: http://www.cs.tut.fi/~csmr2004/. Papers can also be submitted via email to the program chair. FINAL FORMAT OF PAPERS Accepted papers must be revised to conform with IEEE style guidelines at http://www.computer.org/cspress/instruct.htm.

1 0

a breaking monad
by Hal Daume 01 Aug '03

01 Aug '03

i've noticed in a lot of my imperative-looking monadic code, i have lots of stuff that looks like: > ... = do > q <- some test > if q > then return some constant > else do > major code body here lots of these things embedded makes the code hard to read and introduces way too much indentation (i'm one of those who doesn't like curly braces). one solution to this is to write it as: > ... = do > q <- some test > if q then return some constant else do > major code body here but this is ugly, IMO :). my solution was to fashion a monad transformer that supports a break statement. basically, it looks like: > data Break b m a = Break { runBreak :: m (Maybe b, a) } > > instance MonadTrans (Break b) where > lift x = Break $ do a <- x; return (Nothing, a) > > instance Monad m => Monad (Break b m) where > return a = Break $ return (Nothing, a) > b >>= k = Break $ runBreak b >>= \ (broken, a) -> > case broken of > Nothing -> runBreak (k a) > Just br -> return (Just br, undefined) > > breakable :: Monad m => Break a m a -> m a > breakable b = runBreak b >>= \ (broken, a) -> > case broken of > Nothing -> return a > Just br -> return br > > break :: Monad m => b -> Break b m a > break b = Break (return (Just b, undefined)) essentially you introduce code blocks with the "breakable" function and then can break with the break function. a useful combinator i've found is: > breaksTo :: Monad m => m Bool -> b -> Break b m () > breaksTo k b = lift k >>= \x -> if x then break b else return () using this, you can write stuff which looks like: > test1 :: IO [String] > test1 = breakable $ do > lift $ putStrLn "Enter something, or nothing to quit:" > l <- lift $ getLine > when (null l) $ break [] > rest <- lift test1 > return (l:rest) > > test2 :: IO () > test2 = breakable $ repeatM $ do > x <- lift $ getLine >>= passThrough putStrLn > when (null x) $ break () > > test3 :: Handle -> IO [String] > test3 h = breakable $ do > hIsEOF h `breaksTo` [] > lift $ do > l <- hGetLine h > rest <- test3 h > return (l:rest) where passThrough and repeatM are: > repeatM :: Monad m => m () -> m () > repeatM x = x >> repeatM x > > passThrough :: Monad m => (a -> m b) -> a -> m a > passThrough f a = f a >> return a so, my questions are: does this exist in some other form I'm not aware of? is there something fundamentally broken about this (sorry for the pun)? any other comments, suggestions? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

3 3

Submission deadline SNPD03 approaching
by Annette Stümpel 01 Aug '03

01 Aug '03

============================================================== CALL FOR PAPERS Fourth International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD03) October 16-18, 2003 Luebeck, Germany http://www.isp.uni-luebeck.de/snpd03/index.htm ============================================================== Scope and Topics ================ The conference provides an international forum for scientists to present research results in the areas of software engineering, artificial intelligence, networking and parallel/distributed computing. The conference particularly welcomes contributions at the junction of theory and practice disseminating basic research with immediate impact on practical applications. The conference will cover a broad range of topics including theory, methods, applications, and tools. The conference concentrates on software issues and is structured into the following tracks: Software Engineering and Information Engineering Component-Based Software Engineering Internet Technology and Applications Information Management Systems Software Engineering Education Parallel and Distributed Computing Communication Systems and Networks Mobile and Wireless Computing Visual and Multimedia Computing Artificial Intelligence, Data Mining, Knowledge Discovery Neural Networks and Genetic Algorithms Economic and Financial Systems Control Systems Image, Acoustic, Speech and Signal Processing Venue ===== After Reims (2000), Nagoya (2001) and Madrid (2002) this years SNPD conference will be held at the Moevenpick Hotel in Luebeck. The Hanseatic town of Luebeck is located in Northern Germany close to the Baltic Sea with frequent train connections to major airports. The medieval town was appointed as world cultural heritage by the United Nations. Important Deadlines =================== Full Paper Submission: August 15, 2003 Notification of Acceptance: September 10, 2003 Camera-ready Papers: September 24, 2003 Conference Proceedings & Journal ================================ Accepted papers limited to 8 pages will be published in the conference proceedings with ISBN. After the conference a selection of excellent papers will be published in a special issue of the International Journal of Computer and Information Science. For further details, please visit the conference web page http://www.isp.uni-luebeck.de/snpd03/index.htm.

1 0

Text I/O library proposal, first draft
by Ben Rudiak-Gould 01 Aug '03

01 Aug '03

[Crossposted to Haskell and Libraries. Replies to Libraries.] {- Good things about this text library design: * Efficient implementation should be straightforward * Character coder interface is public, so users can supply their own encodings, or write coder transformers (there are some in the proposal) Bad things: * There's no way to implement fgetpos/fsetpos type functionality, because coders don't expose their internal state. (In fact, there would need to be a way to explicitly copy the state, since it may well include IORefs, Ptrs, etc.) Is this a serious problem? -} module System.TextIOFirstDraft (...) where -- A BlockRecoder takes source and destination buffers and does some sort -- of translation between them. It returns the number of values (not -- bytes!) consumed and the number of values produced. It does not have to -- empty the input buffer or fill the output buffer on each call, but it -- must do something (i.e. it's not acceptable to return (0,0)). Coders -- will in general have internal state which is updated on each call. type BlockRecoder from to = Ptr from -> BlockLength -> Ptr to -> BlockLength -> IO (BlockLength,BlockLength) type TextEncoder = BlockRecoder Word32 Octet type TextDecoder = BlockRecoder Octet Word32 -- IO TextEncoder and IO TextDecoder below denote "coder factories" which -- produce a new coder in its initial state each time they're called. compatibilityEncoder :: IO TextEncoder -- "mod 256" currentLocaleEncoder :: IO TextEncoder iso88591Encoder :: IO TextEncoder latin1Encoder = iso88591Encoder utf8Encoder, utf16BEEncoder, utf16LEEncoder, utf32BEEncoder, utf32LEEncoder :: IO TextEncoder compatibilityDecoder :: IO TextDecoder currentLocaleDecoder :: IO TextDecoder iso88591Decoder :: IO TextDecoder latin1Decoder = iso88591Decoder utf8Decoder, utf16BEDecoder, utf16LEDecoder, utf32BEDecoder, utf32LEDecoder :: IO TextDecoder -- An attempt at supporting setlocale-type locale strings. lookupEncoder :: String -> Maybe (IO TextEncoder) lookupDecoder :: String -> Maybe (IO TextDecoder) -- prependBOM takes an existing UTF encoder and causes it to prepend -- a BOM (byte-order mark) to its output. autodetectUTF takes an existing -- decoder and modifies it to check for a BOM, switching to the -- appropriate type of UTF decoding if one is found. prependBOM :: IO TextEncoder -> IO TextEncoder autodetectUTF :: IO TextDecoder -> IO TextDecoder -- Attaches a TextInputChannel to the supplied InputChannel. After -- this operation the InputChannel should be considered owned by the -- TextInputChannel; any attempt to use it directly will cause -- unpredictable results. This takes a decoder factory rather than a -- decoder to prevent the error of attaching the same decoder to more than -- one channel. icAttachTextDecoder :: InputChannel -> IO TextDecoder -> IO TextInputChannel ticGetChar :: TextInputChannel -> IO Char ticGetLine :: TextInputChannel -> IO String ticLazyGetContents :: TextInputChannel -> IO String ocAttachTextEncoder :: OutputChannel -> IO TextEncoder -> IO TextOutputChannel tocPutChar :: TextOutputChannel -> Char -> IO () tocPutStr :: TextOutputChannel -> String -> IO () tocPutStrLn :: TextOutputChannel -> String -> IO () -- ... etc ... -- Ben

2 1