September 2002 - Haskell

RE: Main.main naming convention
by Simon Peyton-Jones 10 Sep '02

10 Sep '02

| Another such restriction is the fact that any module which | is called Main *must* have a function which is called main | in it. In combination with the rule that says that any | module which is not explicitly named is called Main, this | gets very annoying when using an interactive Haskell system | such as ghci. (I don't think that Hugs does insists on | this.) Ghci doesn't either, now. Simon

1 0

Hugs help
by Arthur Fleck 10 Sep '02

10 Sep '02

I downloaded and installed (apparently successfully) the binaries for Mac OS X under 10.1.5. When I try to execute from a terminal window (what's the difference between 'hugs' and 'runhugs"?), I get the error message "can't open library: /usr/lib/libncurses.5.dylib". Indeed, there is no such library there, but there is 'libcurses.dylib' there. I'd appreciate finding out where I'm going wrong. Sorry if this is in FAQ, but I had trouble seeing it. Art Fleck

4 3

RE: H98 Report: input functions
by Simon Peyton-Jones 10 Sep '02

10 Sep '02

| In 7.1, the Report says of getChar, getContents and friends: | | "By default, these input functions echo to standard output." | | This would mean that the example given: | | main = interact (filter isAscii) | | would print the input with all ASCII characters duplicated. | | Surely it should say that if the standard input is a terminal device the | input is echoed on that device. Or maybe the sentence should be deleted. Ross's speaks truth. In fact, the overall behaviour of a Haskell program when used from a terminal ought to be predicable regardless of OS. And indeed one expects the behaviour to differ depending on whether stdin is a terminal or a file. So I propose to adopt Ross's modification: "Surely it should say that if the standard input is a terminal device the input is echoed on that device." This describes what Haskell implementations actually do, and it describes the desired behaviour. All this is about the Language Report. In the Library Report, it says that "getLine" is sort for "hGetLine stdin". So that implies that If the standard input (stdin) is a terminal device, any input on stdin is echoed on that device So, for consistency, I propose to add that to the IO chapter of the library report. Does that seem right? It is very late in the day to be fiddling with the Report. I'll emit an update in a separate message. Simon

3 2

Labelled types question
by Andre W B Furtado 09 Sep '02

09 Sep '02

Suppose I have a labelled type 'A' defined like the following one: module Test ( A (b) ) where data A = A { b :: Int, c :: Int } I am exporting only 'A(b)', so why the following code "can see" 'c' ? module Main where import Test main :: IO () main = print (c (A {c=3,b=2})) PROMPT> 3 If Test exports only 'A', not 'A(b)', the I get the expected compilation problem: ERROR "label.hs" (line 6): "c" is not a selector function/field name Am I missing something obvious here? Thanks, -- Andre

1 0

Re: typeclass relations
by S.M.Kahrs 09 Sep '02

09 Sep '02

[snip] > instance Foo Int where > foo = show > > instance Bar Int where > bar a = (show a) ++ " bar!" > > instance Foo Char where > foo = show > > instance Foo a => Bar a where > bar = foo Notice: this last instance derives another instance of Bar Int, etc. > If I try to compile this via GHC it complains loudly unless I feed it > "-fglasgow-exts -fallow-undecidable-instances > -fallow-overlapping-instances", in which case it seems to do the right > thing. However, the warnings (and the names of the flags - "undecidable > instances" doesn't sound good) make me nervous, and confused. Why is > there a problem with saying "every instance of Foo is also an instance of > Bar, and here's how"? The problem is the sublanguage in which you are working. The class constraint simplification starts fairly simply (oh well) in Haskell, but the more powerful you make it the more powerful is the engine that does the job. Eventually you have full-blown Prolog programming at that level, and hence undecidability. The class checker for the above is like a little Prolog program: foo(int). bar(int). foo(char). bar(X) :- foo(X). --- Stefan Kahrs

1 0

typeclass relations
by Abraham Egnor 09 Sep '02

09 Sep '02

I have two typeclasses, Foo and Bar, with some instances, defined as such: module Test where class Foo a where foo :: a -> String class Bar a where bar :: a -> String instance Foo Int where foo = show instance Bar Int where bar a = (show a) ++ " bar!" instance Foo Char where foo = show instance Foo a => Bar a where bar = foo If I try to compile this via GHC it complains loudly unless I feed it "-fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances", in which case it seems to do the right thing. However, the warnings (and the names of the flags - "undecidable instances" doesn't sound good) make me nervous, and confused. Why is there a problem with saying "every instance of Foo is also an instance of Bar, and here's how"? Abe

2 1

RE: H98 Report: input functions
by Simon Peyton-Jones 09 Sep '02

09 Sep '02

| No. A terminal device may echo or it may not. Even if the run-time | explicitly enables echoing, there is no guarantee that it won't | subsequently be disabled. | | Certainly, the existing statement is wrong, though. Well, the question is what the report should say. The minimal change is to delete the remark, but that's undesirable. If the report is silent on this question, the same interactive Haskell program could legitimately behave very differently in different impls, which seems undesirable. Suggestions welcome. (The old wording said "by default", if that helps.) Simon

1 0

Haskell report publication
by Simon Peyton-Jones 09 Sep '02

09 Sep '02

Folks As you know, the Haskell Report (both language and libraries) is going to be published by CUP, both as a special issue of the Journal of Functional Programming (13.1) and as a book. I have to deliver the final copy by the end of the month. So the gate really is closing. In a few days I'll emit my draft final version. I think I'll rewrite the preface so it's less of a rag-bag, but no other significant changes. Last chance guys! Simon

1 0

Main.main naming convention
by Martin Norbäck 09 Sep '02

09 Sep '02

I have a question about the Main.main naming convention. Would it be a good idea to lift the restriction and allow any module which exports a function main :: IO () to be compiled into a separate binary? You'd need to specify which module should be the top-level module when compiling, of course. Why I'm asking is because I have several Main modules in one directory, in files like Program1.hs, Program2.hs and so on, but all of these claims (and must claim) to be "module Main". Java, for instance, allows any class which has a main method to be used at the top level. Regards, Martin -- Martin Norbäck Safelogic AB martin.norback(a)safelogic.se Stena Center 1C +46 (0)31 772 81 70 S-412 92 GÖTEBORG http://www.safelogic.se SWEDEN

1 0

Final CFP: TLDI'03 (Deadline: 5PM EDT, Sept 27, 2002)
by Zhong Shao 08 Sep '02

08 Sep '02

FINAL CALL FOR PAPERS TLDI'03 The ACM SIGPLAN Workshop on Types in Language Design and Implementation (Formerly called TIC, The International Workshop on Types in Compilation) http://www.cs.cmu.edu/~petel/tldi03/ January 18, 2003 New Orleans, Louisiana Co-located with POPL'03 The role of types and proofs in all aspects of language design, compiler construction, and software development has expanded greatly in recent years. Type systems, type analyses, and formal deduction have led to new concepts in compilation techniques for modern programming languages, verification of safety and security properties of programs, program transformation and optimization, and many other areas. In recognition of this expanding role, the ACM SIGPLAN Workshop on Types in Language Design and Implementation (TLDI'03) expands on the previous three International Workshops on Types in Compilation (TIC'97, TIC'98 and TIC'00), to bring together researchers to share new ideas and results in this area. This year, TLDI'03 will be sponsored by ACM SIGPLAN and colocated with POPL'03. Submissions for this event are invited on all interactions of types with language design, implementation, and programming. This includes both practical applications and theoretical aspects. TLDI'03 specifically encourages papers from a broad field of programming language and compiler researchers, including those working in object-oriented, dynamically-typed, late-binding, and mobile-code paradigms, as well as traditional fully-static type systems. Topics of interest include: - Proof-carrying code and certifying compilation - Typed intermediate languages and type-directed compilation - Type-based language support for safety and security - Types for interoperability - Type safety and security of system programming languages - Type-based program analysis, transformation, and optimization - Dependent types and type-based proof assistants - Types for security protocols, concurrency, and distributed computing - Type inference and type reconstruction - Type-based specifications of data structures and program invariants - Type-based memory management This is not meant to be an exhaustive list; papers on novel utilizations of type information are welcome. Authors concerned about the suitability of a topic are encouraged to inquire via electronic mail to the program chair prior to submission. HOW TO SUBMIT A PAPER We solicit submissions on original research not published or submitted for publication elsewhere. Technical summaries, in English and not to exceed 5000 words (approximately 10 pages), should be submitted to the program chair by FRIDAY, SEPTEMBER 27, 2002. Because of hard constraints imposed for the publication of the proceedings, this is a hard deadline. WE WILL BE UNABLE TO ACCEPT FOR REVIEW ANY LATE SUBMISSIONS. To submit a paper, authors should complete the following two steps by the submission deadline: 1) Send an e-mail message to petel(a)cs.cmu.edu containing the title, authors' contact information, and an abstract (not to exceed 200 words) in ASCII. 2) Send the technical summary itself. The summary should also be sent electronically to petel(a)cs.cmu.edu. (Persons to whom electronic submission poses a hardship may make individual arrangements with the program chair.) Adobe Portable Document Format (PDF) is strongly preferred for all submissions. Authors should be sure to use full font inclusion to ensure portability. All papers must be formatted for US Letter (8.5"x11") paper. Postscript (PS) format submissions will also be accepted, provided that they preview and print properly using Ghostscript with standard fonts. All submissions must include a return postal address and an electronic mail address. Receipt of the submissions will be acknowledged by e-mail within 2 days. The proceedings for the workshop will be published by the ACM Press. IMPORTANT DATES Please note: Due to the short time from submission to publication of the proceedings, the submission deadlines given above are firm. - 5:00 PM EDT (= 21:00 UTC), September 27, 2002 Deadline for submission of papers - Friday, Nov. 8, 2002 Notification of acceptance - Monday, Dec. 2, 2002 Camera-ready copy due - Saturday, Jan. 18, 2003 TLDI'03 in New Orleans PROGRAM CHAIR Peter Lee School of Computer Science 5000 Forbes Avenue Carnegie Mellon University Pittsburgh, Pennsylvanie 15213-3891 E-mail: petel(a)cs.cmu.edu Tel.: +1-412-268-3049 Fax: +1-412-268-5577 GENERAL CHAIR Zhong Shao Department of Computer Science 51 Prospect Street Yale University New Haven, Connecticut 06520-8285 E-mail: shao(a)cs.yale.edu Tel: +1-203-432-6828 Fax:+1-203-432-0593 PROGRAM COMMITTEE Alex Aiken, University of California, Berkeley Andrew Appel, Princeton University David F. Bacon, IBM T.J. Watson Research Center Manuel Fahndrich, Microsoft Research Matthew Flatt, University of Utah Atsushi Igarashi, Kyoto University Peter Lee, Carnegie Mellon University Xavier Leroy, INRIA Christine Paulin-Mohring, University of Paris South Scott Smith, The Johns Hopkins University Philip Wadler, Avaya Labs STEERING COMMITTEE Craig Chambers, University of Washington Robert Harper (Chair), Carnegie Mellon University Xavier Leroy, INRIA Gregory Morrisett, Cornell University Atsushi Ohori, JAIST Zhong Shao, Yale University

1 0