October 2003 - Haskell

LL3, Nov. 8, 2003, Call for participation
by Jeremy Hylton 26 Oct '03

26 Oct '03

Call for Participation Lightweight Languages Workshop 2003 (LL3) ========================================= Saturday, November 8, 2003 MIT, Room 34-101, Cambridge, Mass. http://ll3.ai.mit.edu/ LL3 will be an intense, exciting, one-day forum bringing together the best programming language implementors and researchers, from both academia and industry, to exchange ideas and information, to challenge one another, and to learn from one another. If you plan to attend, please register as soon as possible. There is no cost to attend, but we need to know how much food to order. The workshop will also be broadcast live on the Internet. We are grateful to Microsoft Research for sponsoring the workshop and Internet broadcast. Program ======= Session I: 10:00-11:00 ---------------------- ACME: Toward a LL Testing Framework for Large Distributed Systems Dana Moore and Bill Wright Interactive Web Programming using WASH/CGI Matthias Neubauer Session II: 11:30-12:30 ----------------------- XS: Lisp on Lego MindStorms Taiichi Yuasa Posters and demos -- details will be posted on the web site Session III: 2:00-3:30 ---------------------- Bluespec, Language Support for Next-Generation Hardware Design Rishiyur S. Nikhil The Virtual Machine of Lua Luiz Henrique de Figueiredo Embedding an interpreted language using higher-order functions and types Norman Ramsey Session IV: 4:00-5:00 --------------------- Functional Reactive Programming in Scheme Gregory Cooper Boundaries Dan Sugalski Program Committee ================= Ken Anderson, BBN (co-chair) Jeremy Hylton, Python Software Foundation (co-chair) Geoffrey Knauth, BAE Systems Shriram Krishnamurthi, Brown University Erik Meijer, Microsoft WebData Dan Sugalski, Perl Foundation Greg Sullivan, MIT CSAIL

1 0

Wrapping Code
by Dominic Steinitz 25 Oct '03

25 Oct '03

Does anyone have any views on how to "wrap" code that has been designed to take input from handles but you now want to take input from strings? I want to make minimal changes to a module that already works and to code that uses that module. Here's my thinking below. I'd be interested in other approaches and pros and cons. Dominic. I thought I would only ever have to parse ASN.1 from a socket or a file. So I have ended up with a lot of functions like this: getTagOctets :: Handle -> IO OctetStream getTagOctets h = do x <- hGetChar h let y = fromIntegral (ord x) in if not (testBit y msb) then return [y] else do ys <- getTagOctets h return ((clearBit y msb):ys) It turns out I need to be able to parse ASN.1 from a string. So my first thought was: tagOctets :: String -> (String,OctetStream) tagOctets s = let y = fromIntegral $ ord $ head s in if not $ testBit y $ msb then (tail s,[y]) else let (s',ys) = tagOctets $ tail s in (s',((clearBit y msb):ys)) Now this is very similar and the type signature suggests state monads. So my second thought was this: tagOctets' :: State String OctetStream tagOctets'= do (x:xs) <- get put xs let y = fromIntegral (ord x) in if not (testBit y msb) then return [y] else do ys <- tagOctets' return ((clearBit y msb):ys) Even nearer but still not good enough. So I went for type class: class Monad m => Foo m where get' :: Handle -> m Char instance Foo IO where get' = hGetChar instance Foo (State String) where get' = \_ -> do (x:xs) <- get; put xs; return x And now I can write: tagOctets'' h = do x <- get' h let y = fromIntegral (ord x) in if not (testBit y msb) then return [y] else do ys <- tagOctets'' h return ((clearBit y msb):ys) I can now use this either with a handle or with a string: test'' :: (OctetStream,String) test'' = runState (tagOctets'' stdin) (map (chr . fromIntegral) (encode $ toASN NoTag NULL)) test = do ofh <- openFile "tst.txt" WriteMode hPutStr ofh (map (chr . fromIntegral) (encode (toASN NoTag NULL))) hClose ofh ifh <- openFile "tst.txt" ReadMode (ts::OctetStream) <- tagOctets'' ifh putStrLn $ show ts

2 1

Prelude
by Per Larsson 24 Oct '03

24 Oct '03

Haskell has an elegant mechanism for overloading operators and function names. In the prelude, a lot of efforts have been made to overload arithmetic names and operators for numerical classes. I think it is a pity that the prelude is considerably more careless with other "good" names which, in my opion, should have been included in type classes. For example: &&, ||, (not): These could have been included in a Boolean (ComplementedBoolean) class and reused for other boolean algebras than the Bool data type, e.g. in library Data.Bits, library Data.Set , lifted for monads or simply being available for user defined types e.g. representing logical formulae or parser combinators. ++, concat: These could be the names in the Monoid class instead of tying them to lists. map: This could be the name in the Functor class instead of being tied to lists. null, elem, filter, reverse..etc.: Many of the list functions could be collected in a generic Sequence class, (in the style of the Edison library design, which has an excellent naming scheme also for collections and mappings) and thereby be reused for other list implementations. Given such overloading, as a bonus, some other names can be given a more generic type, e.g. and, or, any, all. There are also other old solutions in the prelude which makes life more difficult for the designers of the new hierachical libraries, I'm thinking for example of the discussions regarding new IO file primitives and new exception handling primitives and the inefficiency of the Read class as a generic parser mechanism. My conclusion is that the prelude is far too big and inflexible, unnecessarily stealing many important names which preferably should be included in type classes, retyped to more general types, or moved to specialized libraries where some experimentation is allowed before standards are cemented. Therefore, it starts to look rusty and should be considered to be shrinked and redesigned in the next haskell standard (before it is too late). Best Regards Per

1 0

when is defaulting supposed to occur?
by Mark Tullsen 23 Oct '03

23 Oct '03

Note the following program x = 1 y = x :: Int This is accepted by ghc but it is rejected hugs (May 2003 cvs): ERROR "IntegerTest.hs":4 - Type error in type annotation *** Term : x *** Type : Integer *** Does not match : Int My guess is that hugs is doing defaulting after a "declaration group" is type-checked, but that ghci leaves 'x' with type 'Num a', then processes further declaration groups, and then does defaulting. I don't see that the report specifies this (did I miss it?). - Mark

2 1

ghc6 behavior with circular instance declaration
by Kenny 23 Oct '03

23 Oct '03

Hi all, currently I got this program of Eq: module Myeq where class Myeq a where myeq :: a -> a -> Bool instance Myeq Int where myeq i j = (i==j) -- convententionally, we write: {- instance (Myeq a) => Myeq [a] where myeq (x:xs) (y:ys) = (myeq x y)&&(myeq xs ys) -} instance (Myeq a,Myeq [a]) => Myeq [a] where myeq (x:xs) (y:ys) = (myeq x y)&&(myeq xs ys) I want to make the 2nd call of myeq to be of an instance function from the context instead of a recursive call. And obviously there is an obvious cycle in the instances declaration. I run it in ghc6.0.1, it is reported well-typed, but when I run it with some arguments, I get a run-time error. Loading package base ... linking ... done. Compiling Myeq ( Myeq.hs, interpreted ) Ok, modules loaded: Myeq. *Myeq> myeq [] [] Context reduction stack overflow; size = 21 Use -fcontext-stack20 to increase stack size to (e.g.) 20 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `Myeq [a]' arising from use of `myeq' at <interactive>:1 `myeq at [[a]]' arising from use of `myeq' at <interactive>:1 When generalising the type(s) for `it' There have been several similar dicussion before in this mailing list, and in one of the thread Simon says he could resolve this coinductive instances by adding the current goal into the axiom set. Is that the reason this program passed type-check? we guess if this is true, the evidence construction of the myeq_ListofInt becomes myeq_ListofInt = ec myeq_Int myeq_ListofInt when this function is applied with some argument, the execution loops at the point when it tries to evaluate myeq_ListofInt. Here we assume operation semantic is call-by-value. If the operation semantic is call-by-name, this program will terminates. Here I am just making a wild guess how ghc is implemented. Can someone verify whether this is true? Regards, -Kenny __________________________________________________ Do You Yahoo!? Faster. Easier. Bingo. http://sg.search.yahoo.com

2 1

RE: ghc6 behavior with circular instance declaration
by Simon Peyton-Jones 23 Oct '03

23 Oct '03

| -- convententionally, we write: | {- | instance (Myeq a) => Myeq [a] where | myeq (x:xs) (y:ys) = (myeq x y)&&(myeq xs ys) | -} | | instance (Myeq a,Myeq [a]) => Myeq [a] where | myeq (x:xs) (y:ys) = (myeq x y)&&(myeq xs ys) | | | | I want to make the 2nd call of myeq to be of an | instance function from the context instead of a | recursive call. And obviously there is an obvious | cycle in the instances declaration. I don't know why you would possibly want this. So far as I can see from your message, the recursive dictionary you are trying to build is exactly the same as what GHC will build automatically from the "conventional" instance declaration. | I run it in ghc6.0.1, it is reported well-typed, but | when I run it with some arguments, I get a run-time | error. | | Loading package base ... linking ... done. | Compiling Myeq ( Myeq.hs, interpreted ) | Ok, modules loaded: Myeq. | *Myeq> myeq [] [] | | Context reduction stack overflow; size = 21 You must have use -fallow-undecidable-instances, and if you do that, you risk divergence. It's really not clear what you expect to happen. Simon

2 1

ANNOUNCE HToolkit 1.2 released
by Krasimir Angelov 23 Oct '03

23 Oct '03

Dear Haskellers, I am pleased to announce HToolkit 1.2 for Haskell. The HToolkit is a platform independent package for Graphical User Interface. The package is split into two libraries GIO and Port. The Port is a low-level Haskell 98+FFI compatible API, while GIO is a high-level user friendly interface to Port. The current release supports all Windows based platforms and Linux/Unix platforms with GTK/GNOME toolkit. There are many new features and many bugfixes. The 1.2 release is a source incompatible with 1.0 release. Home page ~~~~~~~~~ http://htoolkit.sourceforge.net Incompatible changes: ~~~~~~~~~~~~~~~~~~~~~ 1. There is a new API for creating: - radio menu items (MenuRadioItem) - check boxes (CheckBox) - radio buttons (RadioBox) In the new API each widget is created idependently from the other widgets and after that they are linked together to form a group of related items. 2. The 'drawInWidget' function is renamed to 'paintIn' and the 'drawInBitmap' is renamed to 'paintInBitmap'. 3. The 'dialogFont' function is removed. Both windows and dialogs now use the same font (returned from the 'defaultFont' function). 4. The 'defaultFont', 'defaultFontDef', 'dialogColor', 'windowColor' and 'textColor' functions now return values which are system dependent. The returned values are given from the current theme selected in Windows/GNOME. 5. The 'itemCount' attribute of Menu is removed. There is a new 'count' attribute which is defined in the type class and instances are defined for Popup, ListBox, Notebook, Menu and ToolBar types. 6. The 'visible' attribute of Entry is renamed to 'password'. 7. The windows and the dialogs are created invisible by default and can be shown with the 'showWindow' or 'runDialog' (for dialogs) functions. New features ~~~~~~~~~~~~ 1. The implementation for the ToolBar is completed. Unfortunatelly in this release the toolbars for Linux don't work. The reason is that the CVS version of Port uses GTK 2.3. 2. Each window and dialog can be shown/hidden with the 'showWindow' and 'hideWindow' functions or by changing the value of the new attribute 'visible'. The attribute is read/write and its current value determines whether the window is visible. The windows and the dialogs are created invisible by default and can be shown with the 'showWindow' or 'runDialog' (for dialogs) functions. 4. In HToolkit 1.0 when the dialog size becomes smaller than the minimal size required to layout the controls, the dialog automatically shows scrollers. In HToolkit 1.2 the dialogs cannot be shrinked to a size smaller than the minimal. Under Windows a size gripper is drawn at the righthand bottom corner of the resizable dialogs just like the modern resizable dialogs under Windows. 5. The controls are created invisible by default and are shown only if they are included in the layout expression of their parent. In this way it is possible to dynamically hide/show and rearrange the controls. 6.Three new controls are added: Notebook, GroupBox and CompoundControl. The CompoundControl is a container for other controls with automatic scrollbars. The control supports 'mouse', 'keyboard' and 'paint' events just like the toplevel windows and dialogs. The primary purpose of CompoundControl is to create new custom controls. 7. The layout algorithm is extended with 'stretch', 'hstretch' and 'vstretch' functions in addition to 'fill', 'hfill' and 'vfill'. The new functions stretch only the specified control to fit the entire space without affecting the rest controls in the table. Cheers, Krasimir __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

2 2

RESOLVED - Question abt num
by Pratik Bhadra 23 Oct '03

23 Oct '03

Thanks for your attention :) The problem has been resolved. Pratik -------------------------------- Pratik Bhadra Undergraduate Section Leader The University of Texas at Austin College of Natural Sciences Junior BS Computer Sciences ---------------------------------

1 0

Question abt Num
by Pratik Bhadra 23 Oct '03

23 Oct '03

Hi I have a data type Expr for handling Expressions data Expr = Lit1 Int | Lit2 Bool | Var String | BinOp Op Expr Expr As you can see, I am trying to have an Expression have both Int and Bool values so that I can work with both arithmetic (+,-,*,/) and logical(and,or,<,<=,>,>=) operators. What I am aiming at is to parse a line which contains an expression, evaluate it and return the result. I am facing some problems in this regard. When I write the evaluate function, the Haskell compiler refuses to compile my code as it says, instance of Num Expr required. Any ideas what I am supposed to do to fix that? My evaluate code is as follows... evaluate :: Expr -> Store -> Expr evaluate ( Lit1 n ) st = n evaluate ( Lit2 n ) st = n evaluate ( Var v ) st = value st v -- returns the value of v evaluate ( BinOp op e1 e2 ) st = opValue op v1 v2 where v1 = evaluate e1 st v2 = evaluate e2 st opValue :: Op -> Expr -> Expr -> Expr opValue Add e1 e2 = e1 + e2 opValue Sub e1 e2 = e1 - e2 opValue Mul e1 e2 = e1 * e2 opValue Div e1 e2 = e1 / e2 opValue LT e1 e2 = e1 < e2 opValue LE e1 e2 = e1 <= e2 opValue GT e1 e2 = e1 > e2 opValue GE e1 e2 = e1 >= e2 opValue And e1 e2 = e1 && e2 opValue Or e1 e2 = e1 || e2 Now I can't return an Int as I return a Bool at times and hence I return an Expr. What does the error...instance of Num Expr or instance of Fractional Expr required mean? Thanks in advance! Pratik -------------------------------- Pratik Bhadra Undergraduate Section Leader The University of Texas at Austin College of Natural Sciences Junior BS Computer Sciences ---------------------------------

4 3

Enum on Float/Double
by George Russell 23 Oct '03

23 Oct '03

The situation with Enum on Ratio is pretty bad but at least it's not hopeless, since rational numbers are at least exact. But for Float/Double it seems to be a total disaster area. Since it seems to be impossible to abolish Enum Float/Double altogether, would it at least be possible to make it rather more useful, by making succ x return the next representable float after x (or x if x is non-finite) and pred x the previous representable float. This would (a) be useful; (b) make mathematical sense; (c) is tricky to implement with the existing primitives. Before someone else points it out, this is of course unimplementable should someone in the future implement infinite-precision reals in Haskell, but as (barring a solution to the halting problem) Eq would be as well, that does not bother me. My preference would be for succ (+-0) to return the smallest positive real, since then you could define succ x to be the unique y with x < y and forall z . z < y => not (x < z), where such a y exists, and I'm not sure if the Haskell standard knows about signed zeros. Feri wrote > Everybody working with floats should know their quirks While in an ideal world, everyone who represented a mouse position or anything else as a float should have a PhD in numerical analysis, in practice they do not. Indeed I think the Haskell Library Report contains quite a few examples of floating point code which a numerical analyst would have written rather better. So I don't think it's good enough to treat every Float/Double operation as if it had an implicit "UNSAFE" flag indicating that the compiler was entitled to wierd behaviour only comprehensible to experts, as seems to be the case with floating enumerations now.

8 11