- Haskell - Haskell.org

Re: The future of Haskell discussion
by Yoann Padioleau 18 Sep '01

18 Sep '01

Alastair David Reid <reid(a)cs.utah.edu> writes: > In the case of the Draw monad (which is identical to the > IO monad except that it carries a "device context" around as an > implicit parameter), the different feel comes from aggressive > use of continuations (actually, they're not quite continuations > but I don't have a better word for them). For example, you might > normally write code like this: > > do > old_color <- selectColor blue > old_font <- selectFont helvetica > write_text "Hello World" > selectFont old_font > selectColor old_color > > (Reselecting the old color and font at the end is recommended Win32 > programming style.) > > In the HGL, you instead write: > > setPicture window (withColor blue (withFont helvetica (text "Hello World"))) you can achieve the same in many langage such as c++. I dont really see what is haskell specific in your code. pseudo code (i dont remember exactly c++ :) ): class Draw { Color color; Font font; Widget wid; Draw(Widget w) { wid = w } draw(window) { Color old; Font old; oldc = setColor color; oldf = setFont font; wid.draw(window); setColor oldc; setFont oldf; } withColor (Color c) {color = c} withFont (Font f) {font = f} } new Draw(new textWidget("Hello World"))->withColor(blue)->withFont("helvetica")->draw(window) there are plenty of way to achieve what you do. > > or, equivalently but allegedly easier to read, > > setPicture window $ > withColor blue $ > withFont helvetica $ > text "Hello World" > > where withColor and withFont are defined like this: > > withColor :: Color -> Draw a -> Draw a > withColor c m = do{ old <- selectColor c; a <- m; selectColor old; return a } > > withFont :: Font -> Draw a -> Draw a > withFont f m = do{ old <- selectFont f; a <- m; selectFont old; return a } > > and setPicture exploits the fact that an object of type "Draw a" is a > first class object which can be stored in the window state and > executed when appropriate (e.g., when the window is uniconified). > > > What I'm saying is that Haskell's standard abstraction facilities mean > that even in the IO monad your programming experience can > significantly better than that of a C programmer. (Of course your > experience can also be worse if you don't or can't bring Haskell's > strengths to bear on your problem.) -- Yoann Padioleau, INSA de Rennes, France, http://www.irisa.fr/prive/padiolea Opinions expressed here are only mine. Je n'écris qu'à titre personnel. **____ Get Free. Be Smart. Simply use Linux and Free Software. ____**

2 1

Re: Application letters at the Haskell workshop: suggestion
by Marcin 'Qrczak' Kowalczyk 18 Sep '01

18 Sep '01

Sat, 15 Sep 2001 15:44:52 -0500, Duncan Coutts <dcoutts(a)cray.com> pisze: > I've been using a few variants: single error, multiple error and multiple > error/warning types. I'm also particularly pleased with one that has an > extra combinator which allows seperate 'branches' of an expression to > combine all the errors (if there are any). That allows multiple > *independant* errors to be returned to the user rather than just the first one. Parsec does this and similar things. It tries to generate reasonable messages of the form "expecting foo, found bar" or "unexpected bar" annotated with source position, making use of labels of higher level syntactic constructs inserted in the grammar as well as individual characters matched. I was also experimenting with this. Recently I had no time to work on this, but I will finish it sometime. It's surprisingly hard to get right in all cases, and there are non-obvious decisions to take. For example consider the grammar 'A | B C' and input 'BZ'. We should report that Z was found where C was expected, but do we also report that possibly B was found where A was expected? Depending on the situation both choices can make sense. It depends whether the fact that input began with 'B' really means that the user wanted to write 'B C' (e.g. if in reality 'B' = 'class'; one rarely writes 'class' when he wants to define something else) or it's probably an artifact of the grammar and the error is at the beginning (e.g. if 'B' is an identifier and the rest doesn't look like any of things which could begin with an identifier; the user could mean anything, even misspelled a keyword). Consider the grammar 'A B C | A B D' and input 'ABZ'. Should we merge errors to the form "expecting C or D, found Z", even if both occurrences of 'A B' are independent and really produced by more complex subgrammars? What if lengths of matching prefixes differ? What if the grammar creator gave meaningful names to 'A B C' and 'A B D' as a whole, so we can't report the error where the mismatch occurred? Another complication: we definitely want to perform cuts after enough has been successfully parsed, so we don't keep it in memory and won't consider backtracking that far. I managed to do this, slightly differently than Parsec, but the grammar creator must be aware of this and insert annotations improving backtracking sometimes. This impacts error messages a bit. Getting right descriptions of what was expected or unexpected is not trivial. For example when there is no separate lexer, we rarely have anything besides raw characters as "unexpected". We have something more descriptive only if the grammar explicitly calls 'unexpected' after successfully parsing something. We really don't want to give a message like "expecting 'e', found 'i'" when the real cause is "expecting 'then', found 'thickness'". Sometimes the grammar doesn't give a name and uses a character predicate, so we don't have any description to put into error message. Sometimes the grammar should explicitly mark some parts to not report them as expected; I was getting silly errors about expected whitespace or begin of comment, even though I surely know that whitespace is possible almost everywhere and error messages should concentrate on syntactic errors instead. There are many corner cases giving surprising results. For the grammar 'A (comma A)* right_bracket' and input 'A,A,A,A,A,A,A,]' we really don't want to say for each of the commas that it could be right bracket instead, even though it would indeed allow to successfully parse this part, because the real error is probably only at the end. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

4 4

Subscribe
by John Miller 17 Sep '01

17 Sep '01

ProClarity Corporation John Miller Research & Development <mailto:jmiller@proclarity.com> jmiller(a)proclarity.com (208)344-1630 ext. 111

1 0

PEPM'02: Final Call for Papers
by Peter Thiemann 17 Sep '01

17 Sep '01

FINAL CALL FOR PAPERS 2002 ACM SIGPLAN Workshop on Partial Evaluation and Semantics-Based Program Manipulation (PEPM'02) Portland, Oregon, USA, January 14-15, 2002 (preceding POPL'02) http://www.informatik.uni-freiburg.de/~thiemann/pepm02 Submission deadline: 8 October, 2001 The PEPM'02 workshop will bring together researchers working in the areas of semantics-based program manipulation, partial evaluation, and program generation. The workshop focuses on techniques, supporting theory, and applications of the analysis and manipulation of programs. Technical topics include, but are not limited to: * Program manipulation techniques: transformation, specialization, normalization, reflection, rewriting, run-time code generation, multi-level programming. * Program analysis techniques: abstract interpretation, static analysis, binding-time analysis, attribute grammars, constraints. * Related issues in language design and models of computation: imperative, functional, logical, object-oriented, parallel, distributed, mobile, secure, domain-specific. * Programs as data objects: staging, meta-programming, incremental computation, mobility, tools and techniques, prototyping and debugging. * Applications: systems programming, scientific computing, algorithmics, graphics, security checking, simulation, compiler generation, compiler optimization, decompilation. * Assessment: applicability of program manipulation techniques to particular architectures and language paradigms, scalability, benchmarking, portability. Original results that bear on these and related topics are solicited. Papers investigating novel uses and applications of program manipulation in the broadest sense are especially encouraged. Authors concerned about the appropriateness of a topic are welcome to consult with the program chair prior to submission. SUBMISSION INFORMATION Papers should be submitted electronically via the workshop's Web page. Exceptionally, submissions may be emailed to the program chair: <URL:mailto:thiemann@uni-freiburg.de>. Acceptable formats are PostScript or PDF, viewable by gv. Submissions should not exceed 5000 words, excluding bibliography and figures. Excessively long submissions may be rejected outright. Submitted papers will be judged on the basis of significance, relevance, correctness, originality, and clarity. They should include a clear identification of what has been accomplished and why it is significant. They must describe work that has not previously been published in a major forum. Authors must indicate if a closely related paper is also being considered for another conference or journal. Proceedings will be published with ACM Press. A special issue of the journal "Higher-Order and Symbolic Computation" <URL:http://www.wkap.nl/journals/lasc> is planned afterwards. PROGRAM COMMITTEE Maria Alpuente (U. Politécnica de Valencia, Spain) Evelyn Duesterwald (Hewlett-Packard Labs, USA) Robert Glück (DIKU, Denmark and Waseda University, Japan) Michael Hanus (Christian-Albrecht-University of Kiel, Germany) Zhenjiang Hu (University of Tokyo, Japan) John Hughes (Chalmers Technical University, Sweden) Mark Jones (OGI, USA) Siau-Cheng Khoo (NUS, Singapore) Jakob Rehof (Microsoft Research, USA) João Saraiva (University of Minho, Portugal) Ulrik Schultz (University of Aarhus, Denmark) Peter Thiemann (University of Freiburg, Germany, chair) David Walker (CMU, USA)

1 0

RE: The future of Haskell discussion
by Simon Marlow 17 Sep '01

17 Sep '01

Jeffrey Palmer writes: > I think the question is more along the lines of "Why doesn't Haskell > come bundled with complete, useful and _supported_ libraries?" There's an ongoing effort to rectify the situation. There is a mailing list: libraries(a)haskell.org, which you can join by going to http://www.haskell.org/mailman/listinfo/libraries (there are archives of previous discussion there too). A draft document describes the current plan: http://www.haskell.org/~simonmar/libraries/libraries.html and what source code we have so far is in CVS: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/ Cheers, Simon

1 0

Re: The future of Haskell discussion
by Bill Halchin 17 Sep '01

17 Sep '01

2 1

Call for papers: WICS'2002
by Dr. Muhammad Sarfraz 17 Sep '01

17 Sep '01

Apologies if you receive multiple copies CALL FOR PAPERS WICS'2002 The Fourth Workshop on Information & Computer Science March 17-18, 2002 King Fahd University of Petroleum & Minerals, Dhahran, Saudi Arabia Information & Computer Science Department (KFUPM) in collaboration with IEEE Computer Society Saudi Arabia Chapter Theme: Internet Computing Best papers will be published in A Special Issue Of Information Sciences Journal Important Dates September 30, 2001 Papers due (about 15 pages). November 25, 2001 Notification of acceptance. December 23, 2001 Camera-ready papers. March 17 - 18, 2002 Workshop. For detailed information, please visit: http://www.ccse.kfupm.edu.sa/wics/ Contact Address : Chairman, Organizing Committee, WICS'2002 Department of Information & Computer Science KFUPM # 5066 King Fahd University of Petroleum and Minerals Dhahran 31261, Saudi Arabia Tel.: +966-3-860-2175 Fax: +966-3-860-2174 Email: wics(a)ccse.kfupm.edu.sa WWW: www.ccse.kfupm.edu.sa/wics/

1 0

learing haskell
by Peter Abbot 16 Sep '01

16 Sep '01

hello I am learning haskell for a course on programming languages that I am doing and I am having some trouble getting my head around functional programming. The problem that we are trying to solve is given a certain state, list all of the possible states that you could go through. I was thinking of having the ouput being a collection of lists but cant figure out how to append two list together to get something like: [[1,2,5], [1,2,8], [1,2,9], ...] The approach I am taking is that I have defined a type of State which is equal to Integer. I then have a function that takes a State and return a list of States that can be reached from that state. It is coming up with an algorithm to do both a depth first and breadth first search. Any suggestions would be greatly welcome. thanks Pete

1 0

Re: Type Problem
by Marcin 'Qrczak' Kowalczyk 16 Sep '01

16 Sep '01

Sun, 16 Sep 2001 16:28:01 +0800 (GMT-8), Saswat Anand <saswatan(a)comp.nus.edu.sg> pisze: > trickyFun fun = let x = fun (2::Int) -----------(1) > y = fun 'c' -----------(2) > in "tricky" It can't be done this way in standard Haskell. In GHC and Hugs you can use local universal quantifaction by writing explicit type signature: trickyFun :: (forall a. X a => a -> b) -> String GHC needs to be run with -fglasgow-exts, Hugs needs -98. GHC user's guide describes some limitations, e.g. trickyFun must always be directly applied to an argument. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Type Problem
by Saswat Anand 16 Sep '01

16 Sep '01

Hi, I am wondering how can I pass an overloaded function as a parameter to another function. Consider the following example. I want to tell the compiler that the argument `fun' in `trickyFun' definition is always either ord' or chr', and hence it can find the correct overloaded version in both the cases (1) & (2). Thanks, Saswat class X a where ord' :: a -> Int chr' :: a -> Char instance X Int where ord' = id chr' = chr instance X Char where ord' = ord chr' = id trickyFun fun = let x = fun (2::Int) -----------(1) y = fun 'c' -----------(2) in "tricky"

1 0