- Haskell - Haskell.org

EACL2003: 2nd Call for Workshop Proposals, deadline Oct 1
by Steven Krauwer 12 Sep '02

12 Sep '02

EACL-03: 2nd Call for Workshop Proposals Proposal submission deadline: October 1, 2002 The EACL-03 Organizing Committee invites proposals for workshops to be held at EACL-03. EACL-03 will take place in Budapest, Hungary, April 12-17, 2003 with workshops being held on Sunday and Monday, April 13 and 14, 2003. * Workshop topics EACL-03 workshops provide organizers and participants with an opportunity to focus intensively on a specific topic within computational linguistics. Often, workshops concentrate on specific topics of technical interest (e.g., parsing technologies), particular areas of application for language processing technologies (e.g., NLP applied to IR), or community-wide issues that deserve attention (e.g., standardization of resources and tools). We welcome proposals on any topic that is of interest to the EACL community, but we particularly encourage proposals that broaden the scope of our community through the consideration of new or interdisciplinary techniques or applications. We also encourage topics that are specific to the EACL community such as resources and tools for European or Mediterranean languages. * Workshop format Traditionally, workshops are shaped as mini-conferences, but we encourage proposers to consider other formats that exploit the fact that smaller settings allow for more interaction between participants (discussions, panels, working sessions). The default duration of a workshop is one day, but longer or shorter durations can be proposed (but should be justified). Please note that capacity limitations may cause us to request the organizers to shorten a workshop or to merge it with another workshop in a related area. * Financial guidelines The workshop organisers will benefit from the standard logistic facilities provided for the conference e.g., room, equipment, coffee, proceedings. Any additional cost should be covered by the organisers (especially invited speakers, PC meetings etc.). * Registration fees Participants pay a registration fee which is dependent on the duration of the workshop. Participants not registered for the main conference, pay a higher fee. * Proposals Workshop proposals should provide sufficient information to evaluate the quality and importance of the topic, and the size of the interested community. Proposals should be 2-4 pages and contain the following information: * A title and brief description of the workshop topic. * The target audience and projected number of participants along with support for the projected count. Supporting evidence could include a list of potential submitters, a list of conferences that contained papers on the proposed topic, the number of new companies focused on this topic, or recent funding initiatives that address this topic. * Resource needs such as room size and number of days. Include any special requirements for technical support (computer infrastructure, etc.). * The name, postal address, phone number, e-mail address, and webpage of each chair. In addition, indicate the chairs' background in the workshop area. * A preliminary programme committee Proposals should be submitted by electronic mail, in plain ASCII text, as soon as possible but no later than OCTOBER 1, 2002. The subject line should be: "EACL-03 WORKSHOP PROPOSAL". Please e-mail proposals and any inquiries to the Workshop Chair, Steven Krauwer (steven.krauwer(a)let.uu.nl) * Timetable of Important Dates: Workshop proposals due: Oct. 1, 2002 Notification of acceptance: Oct. 7, 2002 Deadline for receipt of workshop Call for Papers and other publicity material: Oct. 21, 2002 Send out Call for Papers: Nov. 1, 2002 Suggested deadline for workshop paper submissions: Jan. 1, 2003 Suggested deadline for notification of workshop paper acceptance: Jan. 21, 2003 Suggested deadline for camera-ready workshop papers: Feb. 13, 2003 Workshop Dates: Apr. 13-14, 2003 * Workshop Committee: Steven Krauwer (ELSNET / Utrecht University), Chair Jean-Pierre Chanod (Xerox Research Centre Europe, Grenoble) Ernst Buchberger (ÖFAI, Vienna) * Additional Information: Conference website: http://www.conferences.hu/EACL03 Workshop website: http://www.elsnet.org/workshops-eacl2003.html

1 0

Translator
by Gustavo Villavicencio 12 Sep '02

12 Sep '02

Hi everybody I need to know if there is a translator from C to Haskell available. I'd also like to know if the usual transformations (fold, unfold, etc. on Haskell code) can be supported by any automatic tool. I'm interested in these kinds of things because I'm using Haskell as support for the denotational semantics of imperative programs in a reverse engineering process. Thanks, gustavo

1 0

Re: typeclass relations
by cwitty＠newtonlabs.com 12 Sep '02

12 Sep '02

"S.M.Kahrs" <S.M.Kahrs(a)ukc.ac.uk> writes: > The class checker for the above is like a little Prolog program: > > foo(int). > bar(int). > foo(char). > bar(X) :- foo(X). So, the type system for C++ lets you encode (some) Haskell programs and the type system for Haskell lets you encode (some) Prolog programs. Now somebody needs to come up with a type system for Prolog that lets you encode C++ programs. Carl Witty

1 0

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

11 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 d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

6 6

Why concatMap instead of concat.map?
by Dr Mark H Phillips 11 Sep '02

11 Sep '02

Hi, Why does Haskell have a special function called concatMap, rather than people just doing "concat.map"? Is it because concatMap has a more sophisticated implementation than doing just "concat.map"? Cheers, Mark. -- Dr Mark H Phillips Research Analyst (Mathematician) AUSTRICS - smarter scheduling solutions - www.austrics.com Level 2, 50 Pirie Street, Adelaide SA 5000, Australia Phone +61 8 8226 9850 Fax +61 8 8231 4821 Email mark(a)austrics.com.au

3 2

RE: H98 Report: Unicode (was: Re: H98 Report: input functions)
by Simon Peyton-Jones 11 Sep '02

11 Sep '02

Ketil says: | While we're at it, are there any plans to remove this paragraph from | section 2.1: | | | Haskell uses a pre-processor to convert non-Unicode character sets | | into Unicode. This pre-processor converts all characters to Unicode | | and uses the escape sequence \uhhhh, where the "h" are hex digits, | | to denote escaped Unicode characters. Since this translation occurs | | before the program is compiled, escaped Unicode characters may | | appear in identifiers and any other place in the program. I agree! This para should go. No impl does it, and the paragraph is inconsistent with the lexical syntax of identifiers (which can't contain escapes like \uhhh). I therefore propose to delete this para altogether. | Note that the 16-bits remark should probably be removed, Unicode code | points extend beyond that nowadays. It was removed some while ago. | Also, if a provision is made for escaped Unicode in identifiers, it | would be nice if the section on layout (2.7) discouraged layout rules | where the indentation level depended on the width of non-space | characters. (Ideally, this would result in a compiler warning.) | In fact, this might always be useful, since some Unicode characters | are defined as double width. OK, here's what I suggest. The Report currently says: "For the purposes of the layout rule, Unicode characters in a source program are considered to be of the same, fixed, width as an ASCII character." I do not propose to change this statement now. Doubtless it could be cleverer, but it's too late for new cleverness. I would, however, be willing to add: "To avoid visual confusion, programmers should avoid writing programs in which the meaning of implicit layout depends on the width of non-space characters." That's more or less what Ketil suggested, and I think is non-controversial. Any comments? Simon

1 0

RE: foralls in class assertions
by Ashley Yakeley 11 Sep '02

11 Sep '02

At 2002-07-22 04:58, Simon Peyton-Jones wrote: >This business of having 'foralls' in a context (whether for a class or >a function) is not hard to implement in principle, but in practice it'd >take few days of hacking I guess. And, more to the point, thinking. >What are the interactions with functional dependencies or implicit >parameters? >(Maybe none, but I've been caught before.) > >So it's really waiting for someone to say "having foralls in contexts >would change my life and I would love you for ever", rather than "it'd >be nice". > >Simon "lazy evaluation" PJ OK, I can't say it would change my life but I did come up with a rather more motivating example. I guess the best I can offer is "I'll buy you a drink next time I'm back in Cambridge" (I have family there, so it does happen). I want to implement typed exceptions somewhat similar to Java. Code would declare type using an "ExceptionMonad" of kind (* -> * -> *): class (forall ex. Monad (mm ex)) => ExceptionMonad mm where { throwX :: x -> mm x a catchX :: mm xa a -> (xa -> mm xb a) -> mm xb a; } Notice how the types of throwX and catchX precisely mirror those of return and (>>=). Now I could write code that throws different kinds of exceptions like this: data FooException = MkFooException String; foo :: (ExceptionMonad mm) => Char -> mm FooException Integer; foo c = ... data BarException = MkBarException | FooBarException FooException; bar :: (ExceptionMonad mm) => mm BarException Integer; bar = do { a <- catchX (foo 'q') (\fx -> throwX (FooBarException fx)); return (a + 1); } This allows you to have typed structured exceptions more easily, which I think is preferable in many cases to relying on "fail" with its String argument... -- Ashley Yakeley, Seattle WA

1 0

Balanced ternary tree
by Sengan.Baring-Gould＠nsc.com 11 Sep '02

11 Sep '02

I was wondering if anyone has implemented a Balanced Ternary Tree module for haskell. According to http://www.ddj.com/documents/s=921/ddj9804a/9804a.htm this would be a better datastructure for symbol tables than the binary tree I am currently using: * Each string is a key, which makes for O(n/2 * log m) comparisons where n is the average string length and m is the number of string in the table, * A balanced ternary tree would be O(n + log m). (DDJ's code does not balance the tree) Sengan

2 1

Using the Parsec library
by Jose Romildo Malaquias 10 Sep '02

10 Sep '02

Hello. Can anyone help me writing a parser for parsing a simplified list of ABC fields (http://www.gre.ac.uk/~c.walshaw/abc/) The grammar I want to test with is the following ------------------ file ::= *field field ::= fieldA | fieldB fieldA ::= "A:" text endOfLine fieldB ::= "B:" text endOfLine restTextB restTextB ::= (text endOfLine) 'not starting with "A:" or "B:"' text ::= *(LETTER | DIGIT | SPACE | ":") endOfLine ::= LF | CR LF ------------------ The parser I am trying: ------------------ file = many field field = fieldA <|> fieldB fieldA = do string "A:" text endOfLine fieldB = do string "B:" text endOfLine restTextB -- not starting with "A:" or "B:" restTextB = do text endOfLine text = many (letter <|> digit <|> space <|> char ':') endOfLine = string "\n" | string "\r\n" ------------------ Example of input: ------------------ A:1 B:Traditional A:2 B:Line 1 Line 2 A Line 3 BBLine 4 A:3 ------------------ Any sugestion on how to implement the 'not starting with "A:" or "B:"' problem? Romildo -- Prof. José Romildo Malaquias Departamento de Computação - Universidade Federal de Ouro Preto http://www.decom.ufop.br/prof/romildo/ malaquias(a)iceb.ufop.br http://uber.com.br/romildo/ romildo(a)uber.com.br

2 1

RE: Labelled types question
by Simon Peyton-Jones 10 Sep '02

10 Sep '02

The code should not be able to see "c". Nor the data constructor "A". You don't say which Haskell implementation you are using. Simon | -----Original Message----- | From: Andre W B Furtado [mailto:awfurtado@homelink.com.br] | Sent: 09 September 2002 19:15 | To: haskell(a)haskell.org | Subject: Labelled types question | | 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 | | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0