September 2001 - Haskell

Prelude and (:) and []((:), []) bugs?
by Ian Lynagh 19 Sep '01

19 Sep '01

As far as I can tell, the report doesn't allow (:) or []((:), []) in the export list, yet the hugs prelude has the first and the GHC prelude has the second. Have I missed something that allows them or is this a bug in the preludes or the report? Thanks Ian

1 0

Re: Tab "\t" character behaviour in (Win)hugs/ghc
by Sigbjorn Finne 19 Sep '01

19 Sep '01

Rijk-Jan van Haaftenrjchaaft(a)cs.uu.nl writes: > > Recently, Craig Delehanty discovered that there is > a difference in behaviour of putStr "a\tb" between > Hugs and WinHugs (see comp.lang.functional). > > Hugs interprets it as a alignment character: > >putStr "a\tb" > "a b" > > > (7 spaces) > but in WinHugs, it is always the same as 8 spaces: > >putStr "a\tb" > "a b" > > > (8 spaces) > > What does the language definition say about this? Nothing at all, I believe, but the convention is for tab characters to be interpreted by an output device as moving the cursor to the next tab stop/alignment column. In the absence of any custom set of tab stops, the convention is to space them evenly every 8 characters. So, WinHugs is being unnecessarily non-standard to interpret "\t" as being a shorthand for 8 spaces. I've changed this to have it fall into line with the conventional interpretation & checked in the tweak. Thanks for reporting this. --sigbjorn

5 5

Tabs and Haskell
by George Russell 19 Sep '01

19 Sep '01

Alistair David Reid wrote: > "Rijk-Jan van Haaften" <rjchaaft(a)cs.uu.nl>: > >> What does the language definition say about [tabs]? > > Sigbjorn: > > Nothing at all, I believe, but the convention is [...] > > The Haskell 1.4 report says what is meant to happen (section 1.5) > (which was to follow the convention). > > The Haskell 98 report omits this section. > > I would like to report this omission as a bug in the report. Absolutely not. Tab interpretation is OS dependent, it isn't for the language to specify. In any case, you would also need to specify the effect of backspaces, vertical tabs . . . Basically, I think that if your program relies on Unix-like tab handling, you have only yourself to blame . . .

1 0

A monad for type casting
by Koen Claessen 19 Sep '01

19 Sep '01

Hi all, Here is a little experiment I did a while ago. I was trying to isolate the capability of the ST monad to deal with different types at the same time. (Following up on a discussion at the Haskell Workshop in 2000, where we discussed that the ST monad is really a combination of different features that should be separated.) The idea is that one has a monad, "O s", in which one can create objects with identity, of type "Object s a": type O s a -- abstract, Monad type Object s a -- abstract newObject :: O s (Object s a) The idea is now that, we want to be able to compare these objects for equality. But not only that! Given two objects of possibly different types, say "Object s a" and "Object s b", if they are equal, then so must their types be! So, instead of making "Object s a" an instance of "Eq", we provide the following function: compareObject :: Object s a -> Object s b -> Maybe (a -> b) If the objects are not equal, we get "Nothing". But, if the objects are equal, we also get a "proof" of that you can cast between their types. This monad is safe, and can be used as a basis for monads in which one wants to implement something like "STRef"s. I provide an implementation of an (inefficient, but complete) ST monad, only using the O monad. I conjecture this functionality cannot be implemented in Haskell 98, nor in any of the known safe extensions of Haskell. Here, I provide an implementation that works with Hugs. Any comments? One thing I would like to propose for GHC and Hugs is to provide a function like "compareObject" for "STRef"s and "IORef"s. Regards, /Koen. ===== module Object ( O -- :: * -> * -> *; Monad , Object -- :: * -> * -> * , newObject -- :: O s (Object s a) , compareObject -- :: Object s a -> Object s b -> Maybe (a -> b) , runO -- :: (forall s . O s a) -> a ) where ------------------------------------------------------------------- -- This module is an attempt to isolate the capability of the ST -- monad of dealing with several types at the same time. -- -- The idea is that objects of type "Object s a" represent `objects -- with identity', that are associated with a type a. There exists -- a comparison function that checks if two objects have the same -- identity. If this is the case, the associated types should be -- the same too, and a witness function is provided. -- -- To ensure that objects with the same identity really are the -- same object, and also to avoid polymorphically typed objects, -- we have to create the objects in a monad. We also have to use the -- "trick with the s", also used in the realization of the ST -- monad in Haskell. This trick also ensures we can never compare -- two "Object"s from two different "O"-threads. -- -- I conjecture that it is impossible to implement this module in -- pure Haskell with any of the known safe extensions. (So it is -- even impossible if you are allowed to use the ST monad.) -- -- Koen Claessen, 19 November 2000 ------------------------------------------------------------------- ------------------------------------------------------------------- -- type O, type Object: -- "O" is a state monad keeping track of unique tags. "Object" -- only contains a tag for checking equality. newtype O s a = MkO (Int -> (a, Int)) newtype Object s a = MkObject Int instance Monad (O s) where return x = MkO (\n -> (x, n)) MkO m >>= f = MkO (\n -> let (a, n') = m n ; MkO m' = f a in m' n') ------------------------------------------------------------------- -- newObject: -- creating a new object is creating a new tag. newObject :: O s (Object s a) newObject = MkO (\n -> (MkObject n, n+1)) ------------------------------------------------------------------- -- compareObject: -- We check if the objects are equal. If so, we know we can safely -- cast. compareObject :: Object s a -> Object s b -> Maybe (a -> b) compareObject (MkObject tag1) (MkObject tag2) | tag1 == tag2 = Just unsafeCoerce | otherwise = Nothing -- boo! primitive unsafeCoerce "primUnsafeCoerce" :: a -> b ------------------------------------------------------------------- -- runO: -- Executing the state monad. runO :: (forall s . O s a) -> a runO m = let MkO f = m ; (a, _) = f 0 in a ------------------------------------------------------------------- -- the end. ===== module MyST ( ST -- :: * -> * -> *; Monad , STRef -- :: * -> * -> *; Eq , newSTRef -- :: a -> ST s (STRef s a) , writeSTRef -- :: STRef s a -> a -> ST s () , readSTRef -- :: STRef s a -> ST s a , runST -- :: (forall s . ST s a) -> a ) where ------------------------------------------------------------------- -- This module implements an inefficient version of the ST -- monad in "normal" Haskell; the only extensions we use are -- existential and universal quantification, and the "Object" module. -- -- The implementation is inefficient because it uses lists as -- lookup tables. -- -- Koen Claessen, 19 November 2000 ------------------------------------------------------------------- import Object ( O , Object , newObject , compareObject , runO ) ------------------------------------------------------------------- -- type ST, type State, type Entry, type STRef: -- the implementation is straightforward: "ST" is a state monad -- in a type "State", which is a lookup table of existentially -- quantified "Entry"s. We also implement a weaker form of -- equality on "STRef"s. newtype ST s a = MkST (State s -> O s (a, State s)) type State s = [Entry s] data Entry s = forall a . Object s a := a newtype STRef s a = MkSTRef (Object s a) instance Monad (ST s) where return x = MkST (\n -> do return (x, n)) MkST m >>= f = MkST (\n -> do (a, n') <- m n ; let MkST m' = f a in m' n') instance Eq (STRef s a) where MkSTRef tp1 == MkSTRef tp2 = case tp1 `compareObject` tp2 of Just _ -> True Nothing -> False ------------------------------------------------------------------- -- newSTRef, readSTRef, writeSTRef, runST: -- the only interesting things happening here are the safe casts -- by "readSTRef" and "writeSTRef" (note that they are done in -- different directions). newSTRef :: a -> ST s (STRef s a) newSTRef a = MkST $ \st -> do tp <- newObject return (MkSTRef tp, (tp := a) : st) readSTRef :: STRef s a -> ST s a readSTRef (MkSTRef tp) = MkST $ \st -> do return (find st tp, st) where find ((tp1 := a) : st) tp2 = case tp1 `compareObject` tp2 of Just cast -> cast a Nothing -> find st tp2 writeSTRef :: STRef s a -> a -> ST s () writeSTRef (MkSTRef tp) a = MkST $ \st -> do return ((), update st tp a) where update (ent@(tp1 := a) : st) tp2 a' = case tp2 `compareObject` tp1 of Just cast -> (tp1 := cast a') : st Nothing -> ent : update st tp2 a' runST :: (forall s . ST s a) -> a runST m = let MkST f = m in runO (do (a,_) <- f []; return a) ------------------------------------------------------------------- -- the end.

1 0

TIE: A CHR-based Type Inference Engine
by Martin Sulzmann 18 Sep '01

18 Sep '01

Dear all, the following might be of interest to Haskellians and Types people. I'd like to announce the availability of TIE: A CHR-based Type Inference Engine We present a generic type inference algorithm for Hindley/Milner style systems based on Constraint Handling Rules (CHRs). The system has been implemented in Haskell. We also provide a number of examples which show the expressiveness of the system. You can download it from http://www.cs.mu.oz.au/~sulzmann/chr/ Martin Sulzmann

1 0

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