November 2004 - Haskell

CfP reminder: LDTA 2005
by Thomas Noll 15 Nov '04

15 Nov '04

[Reminder: deadline Dec. 1st is approaching] ****************************************************************** *** CALL FOR PAPERS *** *** *** *** Fifth Workshop on *** *** Language Descriptions, Tools and Applications *** *** LDTA 2005 *** *** *** *** Satellite event of ETAPS 2005 *** *** April 3, 2005 *** *** Edinburgh, Scotland, UK *** *** *** *** http://www-i2.informatik.rwth-aachen.de/Events/LDTA2005/ *** ****************************************************************** SCOPE: The aim of this one-day workshop is to bring together researchers from academia and industry interested in the field of formal language definitions and language technologies, with a special emphasis on tools developed for or with these language definitions. This active area of research involves the following basic technologies: Program analysis, transformation, and generation Formal analysis of language properties Automatic generation of language processing tools For example, language definitions can be augmented in a manner so that not only compilers or interpreters can be automatically generated but also other tools such as syntax-directed editors, debuggers, partial evaluators, test generators, documentation generators, etc. Although various specification formalisms like attribute grammars, action semantics, operational semantics, and algebraic approaches have been developed, they are not widely exploited in current practice. It is the aim of the LDTA workshops to bridge this gap between theory and practice. Among others, the following application domains can benefit from advanced language technologies: Software component models and modeling languages Re-engineering and re-factoring Aspect-oriented programming Domain-specific languages XML processing Visualization and graph transformation Programming environments such as Eclipse, Rotor, SUN Java, etc. The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications and tools developed for or with these language definitions. INVITED SPEAKER: LDTA 2005 is going to feature an invited talk by Erik Meijer from Microsoft Research. SUBMISSION PROCEDURE AND PUBLICATION: Submission will be open from autumn 2004. Papers (of at most 15 pages) should be submitted electronically as (optionally compressed/gzipped) PostScript or PDF files to one of the program committee chairs. The message should also contain a text-only abstract and contact author information. Please use the ENTCS style available on the ENTCS Macro Home Page http://www.math.tulane.edu/~entcs/ for preparing your submission. Final versions of accepted papers must not exceed 20 pages and have to conform to the proceedings style. Accepted papers will be published and made available during the workshop. After revision, final copies of the accepted papers will be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science. Author's instructions are given here. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, after acceptance, be published in a special issue devoted to LDTA 2005 of the journal Science of Computer Programming (Elsevier Science). PROGRAM COMMITTEE: John Boyland, University of Wisconsin-Milwaukee, USA (co-chair) <Boyland(a)cs.uwm.edu> G?rel Hedin, Lund Institute of Technology, Sweden (co-chair) <Gorel.Hedin(a)cs.lth.se> Shigero Chiba, Tokyo Institute of Technology, Japan Jim Cordy, Queen's University, Kingston, Canada Susan L. Graham, University of California, Berkeley, USA Adrian Johnstone, University of London, UK Paul Klint, CWI, Amsterdam, The Netherlands Jens Knoop, Vienna University of Technology, Austria Eric Madeleine, INRIA, Sophia Antipolis, France Arnd Poetzsch-Heffter, University of Kaiserslautern, Germany Ganesh Sittampalam, Oxford University, UK Anthony Sloane, Macquarie University, Sydney, Australia Doaitse Swierstra, Utrecht University, The Netherlands Kris de Volder, University of British Columbia, Vancouver, Canada Andrew Wendelborn, University of Adelaide, Australia ORGANIZING COMMITTEE: Thomas Noll, RWTH Aachen University, Germany Joost Visser, University of Minho, Braga, Portugal Eric van Wyk, University of Minnesota, Minneapolis, USA IMPORTANT DATES: Submission deadline: December 1, 2004 Notification: January 17, 2005 Final version due: February 15, 2005 Workshop: April 3, 2005

1 0

comment on language shootout
by Isaac Gouy 14 Nov '04

14 Nov '04

On 18/06/2004, JP Bernardy wrote: > I would have liked to re-implement some of the > benchmarks, some of them should not be looked at by > non-haskell programmers, that would give them an > awfulidea of what the language looks like/how it > should be used. Thank you for raising this topic on the Shootout mailing-list. The website now allows for more than one program per benchmark - so it is possible to show both a more-optimised program and a more-elegant program - and even a program so elegant that it doesn't quite do the required task ;-) OTOH while we can just about decide which programs are faster, deciding which of the half-dozen alternatives is the more-elegant could soon become quite tedious. __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 0

Re: comment on language shootout
by Isaac Gouy 14 Nov '04

14 Nov '04

On 18/06/2004, Andr� Pang wrote: > Yeah. Language shootouts are nearly worthless. (And I say that as an > experienced Haskell programmer who uses and loves Objective-C and Perl > for his day job, which are rather different beasts to Haskell.) I > groaned when I heard that the shootout was revived, because I didn't > think they'd improve on the "benchmarks" used to test the various > languages, and they haven't. I can't really be bothered emailing them > about the fallacies involved because it's just too tedious to explain, > and I'm sure they're convinced they're doing a good deed to the world. Your contempt for disclaimers was so convincing that we removed them all. We kept what was always true: "Our goals are to learn about new languages, compare them in various (possibly meaningless) ways and, most importantly, have some fun!" If you can't be bothered helping to improve the "benchmarks" whine as much as you like - it's cheap and it changes nothing. Or think of a good 'lookup' benchmark that makes some sense for both functional and imperative languages (the 'hashtable' benchmark is too bad). > About the only good they serve is to show programmers that there are > other languages out there, which some people may like to explore. > ("Oooo, what's this O'Caml language? Seems to be doing OK in the > speed tests ...") Yes, name recognition is important - which is why the website now shows language names, not just language implementation names. > They're also good for compiler implementors to find > pathological speed cases in their compiler. That's about it. I've been pleasantly surprised that the simplistic performance measurements on the Shootout have been enough to motivate implementation improvements. That's a pretty cool outcome. -snip- __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Problems installing HTTP and Browser modules
by Ranasaria, Kamal Kishor 13 Nov '04

13 Nov '04

Dear Sir, I was trying to install the HTTP module and came across the following error. Would really appreciate if could help me find the cause of the error. Thanking you, Regards, Kamal ##################################################################### ghc -o main -package net -package util --make Main.hs Chasing modules from: Main.hs Compiling Zord64_HARD ( ./Zord64_HARD.lhs, ./Zord64_HARD.o ) ./Zord64_HARD.lhs:17: Warning: No explicit method nor default method for `*' In the instance declaration for `Num Zord64' ./Zord64_HARD.lhs:17: Warning: No explicit method nor default method for `signum' In the instance declaration for `Num Zord64' ./Zord64_HARD.lhs:17: Warning: No explicit method nor default method for `abs' In the instance declaration for `Num Zord64' ./Zord64_HARD.lhs:26: Warning: No explicit method nor default method for `xor' In the instance declaration for `Bits Zord64' ./Zord64_HARD.lhs:26: Warning: No explicit method nor default method for `bitSize' In the instance declaration for `Bits Zord64' ./Zord64_HARD.lhs:26: Warning: No explicit method nor default method for `isSigned' In the instance declaration for `Bits Zord64' ./Zord64_HARD.lhs:43: Warning: No explicit method nor default method for `quotRem' In the instance declaration for `Integral Zord64' ./Zord64_HARD.lhs:46: Warning: No explicit method nor default method for `toRational' In the instance declaration for `Real Zord64' ./Zord64_HARD.lhs:47: Warning: No explicit method nor default method for `toEnum' In the instance declaration for `Enum Zord64' ./Zord64_HARD.lhs:47: Warning: No explicit method nor default method for `fromEnum' In the instance declaration for `Enum Zord64' Compiling Base64 ( ./Base64.hs, ./Base64.o ) Compiling MD5 ( ./MD5.lhs, ./MD5.o ) ./MD5.lhs:14: lexical error #################################################################

2 2

Re: About Random Integer without IO
by Thomas Davie 12 Nov '04

12 Nov '04

On 11 Nov 2004, at 22:02, karczma wrote: > Thomas Davie writes: >> This method unfortunately depends on having a seed first though. > > Which "this method"? Please, quote the text you are referring to > *before* > your answer. >> One must use a different value every time the program is started, >> commonly time or the first few bytes from /dev/random. Any one of >> these is going to require a monadic function to generate (i.e. it >> must come from the environment in some way - it must change every >> time you run the program) So while this eliminates the IO monad from >> most of the program, it must still be initiated using it. > > I understand that you mean the seed-propagation method. > You are *partly* right, that the same program executed several times > will > generate the same sequence, if initialized identically. But there is no > need for monads, it suffices to pass a parameter, or to read a > different > initialization file each time. > Of course, anybody, especially somebody contributing to this list has > the right to be a nit-picker. But, if one is a *practical* user of > random stuff, then he/she usually knows such details. Moreover, it is > sometimes very useful to control absolutely the initialization, to be > able to repeat the experiment, so, professionals in Monte Carlo, etc. > rarely if ever, use time, or system-dependent (and hidden) random > values. > For me the initialization is a *context* problem, which I separate from > the properties of the random generator. It is its quality, lack of > correlations, etc. which is important. Do you know of many problems > requiring an automated, truly random initialization? In this case one > may well delegate this issue to the *launching* of the functional > program, > instead of struggling with it from within. > This is my personal philosophy, everybody is entitled to his/hers. > While I agree that it is often useful to start your program with different parameters each time to seed the random number generator, I would argue that this is often inappropriate - supposing we are writing a very simple program to roll a virtual dice. If the user finds one input that rolls a six, they can then use this repeatedly. Reading an initialisation file is back to the situation of using IO to generate our seed. Thanks Tom Davie

6 6

How to close a type class
by oleg＠pobox.com 12 Nov '04

12 Nov '04

It is well known that type classes in Haskell are open. A user may at any time extend a visible type class by providing a new instance. There are situations where such an extensibility is undesirable. We may want to prevent the user from adding an instance to our class for some specific type -- or for all types (except some finite set of types). This messages shows that this problem is solvable in Haskell with common extensions. The code in this message has been tested with GHC 6.2.1, GHC 6.3.20041106 snapshot, and Hugs -98 (Nov 2003). We first discuss the problem of excluding specific ground types from a type class. That problem easily reduces to the one of defining a class that has no instances and cannot have ones. We then describe excluding non-ground types in the presence of overlapping (and perhaps, incoherent) instance extensions. The latter solution shows how to close a class -- that is, preclude adding any further instances to it. Completely closing the class has a price to pay: the principal type of an expression that involves closed class methods exists and _can_ be inferred -- but cannot be explicitly written. The essence of the technique can be expressed by a well-known phrase How to replace failure by a [long...] list of successes On Thu Nov 11 10:57:42 EST 2004 Ben Rudiak-Gould wrote on Haskell Cafe: > Except how would you prevent the user from declaring an instance for > PrivateState RealWorld? Oh well. Let us indeed consider preventing the user from declaring an instance of our class for a specific ground type. The answer is simple: we declare that instance ourselves. But we make that instance _statically_ unusable. Here's a simple example: > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > > module C1 where > > class C a where op:: a -> String > instance C Int where op x = show x > instance C Char where op x = "char" Suppose we wish to define two instances of that class, C Int and C Char, and prevent the user from declaring an instance of C for a string. So, we define that instance ourselves: > instance Fail String => C String where op = error "thou shall not be" > > class Fail a > > test1 = op (1::Int) > test2 = op 'z' > --test3 = op "str" Here class Fail has no instances (we shall discuss how to guarantee that in a moment). If we uncomment out the test3 line, we get a type error. Thus we have reduced the problem of excluding certain types from a typeclass to the problem of excluding all types from one particular typeclass: Fail. How can we prevent the user from adding instances to Fail? Again, we define the most general instance the class Fail may have: > instance Fail [a] => Fail a If the test3 line stays commented out, the code typechecks and test1 and test2 work as expected. However, if we now uncomment the test3 line, we get the truly impressive type error message (I like the way it looks in Hugs). If overlapping instances extension is off, any attempt to add another instance to class Fail will be rejected by the compiler, because it will be overlapping with our general instance. Let us now turn to a more complex problem of the exclusion of non-ground types in the presence of overlapping instances. For example, suppose we wish to prevent any instances of class C for lists of any type. If overlapping instances are allowed, writing instance Fail [a] => C [a] will not do us much good, because the user may still introduce "instance C [Int]" for specific ground types like Int. Although overlapping (let alone incoherent) instance extensions seem to be quite permissive, there is still a law they must obey: the law of functional dependencies. That law lets us effectively close a class. Indeed, functional dependencies are already a tool to semi-close a class, to disallow a broad subset of instances (the ones that fail the dependency). Our solution requires adding a dummy type parameter to the type class. Note that the signatures of class methods are not affected. > {-# OPTIONS -fglasgow-exts #-} > {-# OPTIONS -fallow-undecidable-instances #-} > {-# OPTIONS -fallow-overlapping-instances #-} > {-# OPTIONS -fallow-incoherent-instances #-} We activate all extensions > module C2 (C(..)) where > > data Private a -- NOT exported > > class C a b | a->b where op:: a -> String > instance C Int (Private Int) where op x = show x > instance C Char (Private Char) where op x = "char" > test1 = op (1::Int) > test2 = op 'z' Here we add a dummy class parameter 'b'. Note that the method signature remains the same -- and so all the uses of the method. To preclude the instantiation of the class for any list, we make the instance ourselves: > instance C [[a]] (Private [[a]]) > => C [a] (Private [a]) where op = error "thou shall not be" The user may try to add a new instance, say instance C [Int] ??? but what can he put instead of ??? Functional dependencies leave *only* one choice: (Private [Int]) -- but the type constructor Private is not exported from C2 and not available. So, effectively the user is prevented from adding any instance of class C for a list of any type -- and the one instance there is, is statically unusable. We can see that if we try to evaluate `op "str"'. We get even more spectacular type error. We can extend that idea to completely close the class C to any new instances -- whatever they may be. We merely need to add to our module C2: > instance C [a] (Private [a]) > => C a (Private a) where op = error "thou shall not be" The class is closed. But there is a price to pay. We can write > module C3 where > import C2 > > test4 x = op x ++ "abc" We can evaluate "test4 'c'", we can get the compiler to infer the principal type for test4 and to show it to us *C3> :t test4 test4 :: forall a. (C a (C2.Private a)) => a -> [Char] but we cannot write that type signature ourselves, because the type constructor C2.Private is not exported. If we wish to give test4 signature, we must use particular instantiations of class C, e.g., "test4:: Int -> String"

3 3

Conceptual overloading of show?
by Graham Klyne 12 Nov '04

12 Nov '04

I raise a topic that has occurred to me repeatedly during my time with Haskell. I am prompted to do so by a discussion in another place, where a significant (and, apparently, recurring) concern about the use and abuse of Java's toString() function is being raised. It seems to me that there are (at least) two important uses for a function like 'show', which may sometimes have very different requirements: (1) creation of some human-readable representation of a value, which may or may not contain sufficient information to reconstruct the value, and (2) creation of a textual serialization of a value from which the value can subsequently be recreated. I find it's not always entirely clear which of these 'show' is intended to be: its pairing with 'read', and the way that String values are formatted including quotes suggests that it is intended to be a case of (2). Language in the Haskell report also strongly gives this impression. But in other situations, 'show' is commonly used in the sense of (1). For example, in the Haskell report, section 7.1, (print function) the Show class is used to create output that is specifically intended for user consumption ("the standard output device (this is normally the user's terminal)"). Where this leads is that I think there should be *two* common value-to-string type classes, one of which is reversible (in the sense that the output of show is intended to be consumable by read), and another that is not required to be reversible and provides output for human consumption. E.g., let's call the new class 'Format': class Format a where format :: a -> String formatList :: [a] -> String instance Format Int where format = show formatList x = showList x [] instance Format Char where format c = [c] formatList = id In many cases, format and show might be the same, built there would be no requirement for an instance for an instance of Format to be an instance of Show, or vice versa. A practical version of format should probably provide for operation via ShowS values, but I don't currently think an equivalent to showsPrec would be necessary. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 2

About Random Integer without IO
by Jose manuel Hernando Cobeña 11 Nov '04

11 Nov '04

4 4

ANNOUNCE: Haskell Communities & Activities Report (7th ed., November 2004)
by Andres Loeh 10 Nov '04

10 Nov '04

Right in time, I am pleased to announce -- on behalf of the many contributers -- that the Haskell Communities and Activities Report (7th edition, November 2004) http://www.haskell.org/communities/ is now available from the Haskell Communities home page in several formats: PDF, for screenreading as well as printing, HTML, for those of you who prefer not to deal with plugins or external viewers, and PostScript, for those of you who have nice quick printers that do not grok PDF. Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. I hope you will find it as interesting a read as we did. If you haven't encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and well in time for the actual deadline ;) ) to the call. The editor collects all the contributions into a single report and feeds that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ---------------------------------------- End of April 2005: target deadline for contributions to the May 2005 edition of the HC&A Report ---------------------------------------- Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to `register' with the editor for a simple e-mail reminder in the middle of April (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Andres Loeh <hcar(a)haskell.org> <andres(a)cs.uu.nl> -- Haskell Communities and Activities Report (http://haskell.org/communities)

1 0

Re: Using implicit parameter constraints in data decl
by Benjamin Franksen 09 Nov '04

09 Nov '04

On Sunday 07 November 2004 20:09, Simon Peyton-Jones wrote: | Definitely a bug. Could you pls make a small module that elicits the | bug, and send it to me? Here it is: > module Test where > > data Test = (?val::Bool) => Test { name :: String } > > instance Show Test where > show p = name p franksen@linux: .../src/testbug > ghc -fimplicit-params TestBug.hs ghc-6.2.2: panic! (the `impossible' happened, GHC version 6.2.2): simplCore/Simplify.lhs:1473: Non-exhaustive patterns in function cat_evals BTW, I see now that the data declaration is syntactically wrong. Anyway, the (syntactically) correct version data (?val::Bool) => Test = Test { name :: String } is rejected by the compiler: TestBug.hs:3: Illegal constraint ?val :: Bool In the context: (?val :: Bool) While checking the context of the data type declaration for `Test' In the data type declaration for `Test' which is unfortunate since it means that you cannot put a function that depends on an implicit parameter into a data structure. There are probably technical reasons for this restriction, but it means that such functions are no longer first class objects. Cheers, Ben

2 5