January 2001 - Haskell

Re: Extending the do-notation
by Sebastien Carlier 08 Jan '01

08 Jan '01

> import Monad > ... > do y <- liftM unzip m1 Thanks. I'm constantly amazed by the number of tricks one has to know before he can write concise code using the do-notation (among other things, I used to write "x <- return $ m" instead of "let x = m"). Is there a paper demonstrating the most common coding styles for do-notation ? Another question concerning the do-notation: I noticed that most parts of ghc do not use it. Is it because the code was written before the notation was available, because the do-notation is too weak to express these parts, or for another fundamental reason ?

3 2

2nd CfP: ESSLLI 01 Student Session
by Kristina Striegnitz 08 Jan '01

08 Jan '01

!!! Concerns all students in Logic, Linguistics and Computer Science !!! !!! Please circulate and post among students !!! We apologize, if you receive this message more than once. ESSLLI 2001 STUDENT SESSION SECOND CALL FOR PAPERS August 13-24 2001, Helsinki, Finland Deadline: February 18, 2001 http://www.coli.uni-sb.de/~kris/esslli We are pleased to announce the Student Session of the 13th European Summer School in Logic, Language and Information (ESSLLI 2001) organized by the University of Helsinki under the auspices of the European Association for Logic, Language and Information (FoLLI). ESSLLI 2001 will be held at the University of Helsinki in August 2001. We invite submission of papers for presentation at the ESSLLI 2001 Student Session and for appearance in the proceedings. PURPOSE: This sixth ESSLLI Student Session will provide, like the other editions, an opportunity for ESSLLI participants who are students to present their own work in progress and get feedback from senior researchers and fellow-students. The ESSLLI Student Session encourages submissions from students at any level, from undergraduates (before completion of the Master Thesis) as well as postgraduates (before completion of the PhD degree). Papers co-authored by non-students will not be accepted. Papers may be accepted for full presentation (30 minutes including 10 minutes of discussion) or for a poster presentation. The accepted papers will be published in the ESSLLI 2001 Student Session proceedings, which will be made available during the summer school. KLUWER BEST PAPER AWARD: As in previous years, the best paper will be selected by the program committee and will be offered a prize by Kluwer Academic Publishers consisting in 1000 Dfl worth of books. REQUIREMENTS: The Student Session papers should describe original, unpublished work, completed or in progress that demonstrates insight, creativity, and promise. No previously published papers should be submitted. All topics within the six ESSLLI subject areas (Logic, Language, Computation, Logic & Language, Logic & Computation, Language & Computation) are of interest. FORMAT OF SUBMISSION: Student authors should submit an anonymous extended abstract headed by the paper title, not to exceed 5 pages in length exclusive of references and send a separate identification page (see below). Note that the length of the full papers will not be allowed to exceed 10 pages. Since reviewing will be blind, the body of the abstract should omit author names and addresses. Furthermore, self-references that reveal the author's identity (e.g., "We previously showed (Smith, 1991)... ") should be avoided. It is possible to use instead references like "Smith (1991) previously showed...". For any submission, a plain ASCII text version of the identification page should be sent separately, using the following format: Title: title of the submission First author: firstname lastname Address: address of the first author ...... Last author: firstname lastname Address: address of the last author Short summary: abstract (5 lines) Subject area (one of): Logic | Language | Computation | Logic and Language | Logic and Computation | Language and Computation If necessary, the program committee may reassign papers to a more appropriate subject area. The submission of the extended abstract should be in one of the following formats: PostScript, PDF, RTF, or plain text. But note that, in case of acceptance, the final version of the paper has to be submitted in LaTeX format. Please, use A4 size pages, 11pt or 12pt fonts, and standard margins. Submissions outside the specified length and formatting requirements may be subject to rejection without review. The extended abstract and separate identification page must be sent by e-mail to: kris(a)coli.uni-sb.de by FEBRUARY 18, 2001 ESSLLI 2001 INFORMATION: In order to present a paper at ESSLLI 2001 Student Session, at least one student author of each accepted paper has to register as a participant at ESSLLI 2001. The authors of accepted papers will be eligible for reduced registration fees. For all information concerning ESSLLI 2001, please consult the ESSLLI 2001 web site at http://www.helsinki.fi/esslli. IMPORTANT DATES: Deadline for submission of abstracts: February 18, 2001. Authors Notifications: April 17, 2001. Final version due: May 18, 2001. ESSLLI-2001 Student Session: August 13-24, 2001. PROGRAM COMMITTEE: Raffaella Bernardi, University of Utrecht (Logic & Language) Patrick Blackburn, Loria Nancy (Logic & Language) Gilles Dowek, INRIA (Computation) Ruth Kempson, King`s College London (Language) Carsten Lutz, University of Aachen (Logic & Computation) Ani Nenkova, Columbia University (Logic) Ilkka Niemel�, Helsinki University of Technology (Logic & Computation) Malvina Nissim, University of Pavia (Language) Susanne Salmon-Alt, Loria, Nancy (Language & Computation) Jan Schwinghammer, University of the Saarland (Computation) Kristina Striegnitz, University of the Saarland (Chair) Yde Venema, University of Amsterdam (Logic) Shuly Wintner, University of Haifa (Language & Computation) For any question concerning the ESSLLI 2001 Student Session, please, do not hesitate to contact me: Kristina Striegnitz Computational Linguistics, University of the Saarland, Germany phone: +49 - 681 - 302 4503 email: kris(a)coli.uni-sb.de

1 0

A dictionary implementation in Hasekll
by Shlomi Fish 07 Jan '01

07 Jan '01

Does anybody knows of an implementation for an efficient dictionary (such as a hash, an AVL tree, a B-Tree etc. ) in Haskell? Can an array do that? I'd like something that can map any type to any other type based on a comparison function, and perhaps a hashing function. TIA, Shlomi Fish ---------------------------------------------------------------------- Shlomi Fish shlomif(a)vipe.technion.ac.il Home Page: http://t2.technion.ac.il/~shlomif/ Home E-mail: shlomif(a)techie.com The prefix "God Said" has the extraordinary logical property of converting any statement that follows it into a true one.

2 1

Extending the do-notation
by Sebastien Carlier 07 Jan '01

07 Jan '01

Sometimes I need to write code which looks like this: > do x <- m1 > let y = unzip x > ... -- never using x anymore I thinks the following extension to do-notation would be useful: > pat <- exp1 # exp2 ; exp3 would be rewritten as > exp2 >>= ((\pat -> exp3) . exp1) so that the above example could be rewritten more compactly: > do y <- unzip # m1 I think the biggest problem with this extension is the choice of a proper symbol. Does this extension already exist ? (I only checked the Haskell 98 report).

4 3

Movement in a frictionless environment
by R.Daniel 07 Jan '01

07 Jan '01

Hi, could anyone tell me where to find some info about generating movement on a frictionless environment? I need to put a ball running in a window, given an initial speed and then let it run along with the rules of phisics....can anyone give me a hint on where to find info, or on how to do that? I would be most greatefull. Thankx ----->R.Daniel ICQ 28959546

2 1

(no subject)
by kh0ndor＠aeiou.pt 07 Jan '01

07 Jan '01

which is the function in haskell that allows to generate us an amount of aleatory numbers I thank your help __________________________________________________________ Mensagem enviada pelo Xekmail: webmail grátis do AEIOU http://xekmail.aeiou.pt

2 1

Re: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
by Julian Assange 06 Jan '01

06 Jan '01

Peter Douglass <peterd(a)availant.com> writes: > Julian Assange wrote (Dec 28, 2000): > > > This is why all non S-exp like lanaguage are doomed to progressive > > syntactic cancer as the useful parts of operator name space and syntax > > space become progressively polluted and mutated by one fad after > > another. > > Could you expand on this? I would think that all languages have identifies > that, through common usage become standardized, and that this meaning > becomes a de-facto part of the language. Do you feel that this has not > happened in Lisp/Scheme? The identifier space in lisp/scheme has wide tree depth and is (essentially) lexically scoped. Infix operator identifiers in other languages are the antithesis of this. It could be argued, both fairly and unfairly, that the verbosity of S-exp bracketing leaves short identifiers less desirable than they otherwise would be, however tree-width arguments remain. Polution of syntax space is a more difficult problem. As new syntactic axioms are intruded, they should remain consistant with the existing syntax elements. This poses ever increasing restraint on the evolution of the language. New syntax elements appear less intuitive and more arbitary in an attempt to fit in with the morass of ever increasing restraints. If these restraints are not honnored, the language becomes inconsistant. Eventually the language is guarenteed to become either inconsistant or moribund as the number of interactions between language elements overwhelms a language designers attempts understand them. The same is even more true of language semantics. The trouble lays in finding initial axioms which can cleave large sections of future concept space between them. -- Julian Assange |If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and proff(a)iq.org |work, but rather teach them to long for the endless proff(a)gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery

1 0

RE: Are anonymous type classes the right model at all? (replying to Re: Are fundeps the right model at all?)
by Peter Douglass 05 Jan '01

05 Jan '01

Julian Assange wrote (Dec 28, 2000): > This is why all non S-exp like lanaguage are doomed to progressive > syntactic cancer as the useful parts of operator name space and syntax > space become progressively polluted and mutated by one fad after > another. Could you expand on this? I would think that all languages have identifies that, through common usage become standardized, and that this meaning becomes a de-facto part of the language. Do you feel that this has not happened in Lisp/Scheme? --PeterD

1 0

Re: Learning Haskell and FP
by Benjamin L. Russell 05 Jan '01

05 Jan '01

On Wed, 3 Jan 2001 22:55:17 -0800 (PST) Fritz K Ruehr <fruehr(a)willamette.edu> wrote: > > [snip] > > An O'Reilly "nutshell" book is an even better suggestion > than > my "Design Patterns in Haskell" of a few days back, at > least > from the perspective of marketing and promotion. > > But it raises the issue of an appropriate animal mascot > for > the cover; I can only come up with the Uakari, an > exotic-looking > rainforest monkey, which sounds similar to "Curry". > > (look here for a picture:) > > <http://www.animalsoftherainforest.com/uakari.htm> Lalit Pant ( lalitp(a)acm.org ) (alternatively, lalit_pant(a)yahoo.com ) wrote an article in the May 2000 issue of _Java Report_ entitled "Developing Intelligent Systems With Java and Prolog" that described a Prolog implementation of the A-star search algorithm. Lalit stated that Prolog was useful for algorithm prototyping. Perhaps Lalit Pant and Simon Peyton Jones could collaborate together on an article, perhaps overseen by Paul Hudak, on prototyping search algorithms in Haskell, also for _The Java Report?_ If this article then had a high readership, maybe the article's success could then justify publication of an O'Reilly _Haskell in a Nutshell_ book? --Ben P. S. (Hi Doug Fields. I didn't know that you were reading this mailing list. I guess that I should also greet Professor Paul Hudak: Hello, Professor Hudak. Sorry about Collectively Speaking. How's jazz in general?) Benjamin L. Russell russell(a)brainlink.com benjamin.russell.es.94(a)aya.yale.edu "Furuike ya! Kawazu tobikomu mizu no oto." --Matsuo Basho

1 0

RE: Problem with functional dependencies
by Simon Peyton-Jones 04 Jan '01

04 Jan '01

I think you can simplify the example. Given class HasFoo a b | a -> b where foo :: a -> b instance HasFoo Int Bool where ... Is this legal? f :: HasFoo Int b => Int -> b f x = foo x You might think so, since HasFoo Int b => Int -> b is a substitution instance of HasFoo a b => a -> b but if we infer the type (HasFoo Int b => Int -> b) for f's RHS, we can then "improve" it using the instance decl to (HasFoo Int Bool => Int -> Bool), and now the signature isn't a substitution insance of the type of the RHS. Indeed, this is just what will happen if you try with GHC, because GHC takes advantage of type signatures when typechecking a function defn, rather than first typechecking the defn and only then comparing with the signature. I don't know what the answers are here, but there's more to this functional dependency stuff than meets the eye. Even whether one type is more general than another has changed! Simon | -----Original Message----- | From: qrczak(a)knm.org.pl [mailto:qrczak@knm.org.pl] | Sent: 17 December 2000 19:30 | To: haskell(a)haskell.org | Subject: Problem with functional dependencies | | | The following module is rejected by both | ghc -fglasgow-exts -fallow-undecidable-instances | and | hugs -98 | | -------------------------------------------------------------- | ---------- | class HasFoo a foo | a -> foo where | foo :: a -> foo | | data A = A Int | data B = B A | | instance HasFoo A Int where | foo (A x) = x | | instance HasFoo A foo => HasFoo B foo where | foo (B a) = foo a | -------------------------------------------------------------- | ---------- | | The error messsage says that the type inferred for foo in B's instance | is not general enough: the rhs has type "HasFoo B Int => B -> | Int", but | "HasFoo B foo => B -> foo" was expected.

6 8