May 2002 - Haskell - Haskell.org

Re: fold on Monad?
by C.Reinke 30 May '02

30 May '02

> Suppose I have a task I want to do to each line of a file, > accumulate a result and output it, >.. > I'd like to write something similar to > > main = do res <- foldX process_line initial_value getLine > print res > I feel this ought to be straightforward -- the structure is > obviously some sort of fold, but I shouldn't have to use a > list -- so I must be missing something obvious. What is it? foldr, foldM, etc. derive a recursive computation from the recursive structure of an input list, so you have to feed one in. If you want to bypass the list, you could use IO-observations (getLine, isEOF) instead of list observations (head/tail, null): import IO foldX f c = catch (do l <- getLine r <- foldX f c return $ f l r) (\e->if isEOFError e then return c else ioError e) main = foldX (:) [] >>= print Whether that is a real fold, or what the real fold/unfold would look like, I leave to others;-) The same goes for optimization. Hth, Claus

3 3

[Fwd: F#]
by Paul Hudak 30 May '02

30 May '02

Hey Simon et al at Micro$oft, when will there be an H#? (Ok, I'll settle for Haskell.NET :-) -Paul

2 1

(no subject)
by S.J.Thompson 30 May '02

30 May '02

Functional and Declarative Programming in Education (FDPE02) A one day workshop at PLI'02 Monday 7 October 2002, Pittsburgh, PA, USA SECOND (AND FINAL) CALL FOR SUBMISSIONS ***** ***** Deadline June 25 2002 ***** ***** Functional and declarative programming plays an increasingly important role in computing education at all levels. The aim of this workshop is to bring together educators and others who are interested in exchanging ideas on how to use a functional or declarative programming style in the classroom. Submissions are sought in a variety of forms, including: - Standard presentations (30 minutes) - Short talks or "tricks of the trade" presentations (10 minutes) The organisers would also welcome other sorts of submissions, such as software demos, panels, very short talks and so on. Participants who choose to deliver a standard presentation are asked to submit a draft PostScript paper of five pages; presenters of short talks are asked to submit an abstract of 250 words. These should be submitted by June 25, 2002. Michael Hanus, University of Kiel, Germany Shriram Krishnamurthi, Brown University, RI, USA Simon Thompson, University of Kent, UK More details at the FPDE02 website: FDPE02: http://www.cs.ukc.ac.uk/people/staff/sjt/fdpe02/description.html PLI'02: http://pli2002.cs.brown.edu/ Subject: Functional and Declarative Programming in Education (FDPE02)

1 0

Re: layout rule infelicity
by Ashley Yakeley 30 May '02

30 May '02

At 2002-05-30 04:19, Johannes Waldmann wrote: >same here, for exactly these reasons. students get really confused. > >on the other hand, students regularily get confused by other things as well, >like homework assignments on formal languages, >so that alone is not enough reason to drop the subject altogether :-) In the latter case, they are learning something useful. In the former case, the confusion emerges out of a useless property of the language. Let the students use {;} if it eliminates confusion, it's still perfectly good Haskell. I am certainly not proposing Haskell be modified to eliminate the layout option. I'm just curious as to why Haskell programmers choose to use it. -- Ashley Yakeley, Seattle WA

3 2

Re: layout rule infelicity
by Ashley Yakeley 30 May '02

30 May '02

At 2002-05-30 03:59, Ketil Z. Malde wrote: >Short answer: What's wrong with it is that humans use layout to infer >the semantic meaning, No... layout by itself can't be trusted. It's only a clue. One needs to learn the precise Haskell-specific layout rules, and they're not obvious. -- Ashley Yakeley, Seattle WA

1 0

Re: layout rule infelicity
by Ashley Yakeley 30 May '02

30 May '02

At 2002-05-30 04:10, Johannes Waldmann wrote: >ghc -Wall warns nicely about undeclared top-level types but what about >locals? You'd have to declare them in terms of the top-level types, i.e. other type annotations. I think GHC allows some form of this, but IIRC it's a bit tricky. If it weren't for this difficulty I'd probably type-annotate locals. -- Ashley Yakeley, Seattle WA

1 0

A Bug in Time?
by Dominic Steinitz 30 May '02

30 May '02

Hugs has a bug in Time. I would expect toUTCTime and toCalendarTime to be inverses of toClockTime (modulo the IO monad). toCalendarTime :: ClockTime -> IO CalendarTime toUTCTime :: ClockTime -> CalendarTime toClockTime :: CalendarTime -> ClockTime module Main(main) where import Time main = putStrLn "Hello" test :: Integer -> IO () test x = (toCalendarTime . toClockTime . f $ x) >>= putStrLn . show f x = CalendarTime{ctYear=2002, ctMonth=May, ctDay=30, ctHour=10, ctMin=27, ctSec=11, ctPicosec=x, ctWDay=Thursday, ctYDay=149, ctTZName="BST", ctTZ=3600, ctIsDST=True} GHC gives: Main> test 1 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=1,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Main> test 2 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=2,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Hugs gives Main> test 1 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=0,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Main> test 2 CalendarTime{ctYear=2002,ctMonth=May,ctDay=30,ctHour=10,ctMin=27,ctSec=11,ct Picose c=0,ctWDay=Thursday,ctYDay=149,ctTZName="BST",ctTZ=3600,ctIsDST=True} Dominic Steinitz

1 0

Re: layout rule infelicity
by Ashley Yakeley 30 May '02

30 May '02

At 2002-05-30 02:54, Lennart Augustsson wrote: >If you look at C (& offspring), it's not the {;} that makes the code >readable, it's the indentation that does. So why not acknowledge that? In C, the indentation is an important visual clue, but there are many different indentation styles. It's the braces that actually tell you the beginning and end of a block. I might also use indentation for non-blocks, for instance: void foo (int n) { if (n > 0) bar ( "Sproing!", // title getBounds(n), // bounds true, // bordered true, // bright false, // not transparent true, // use v2 appearance 5, // shadow size null // next ); } Equally, I always indent my braced blocks in Haskell as well as C (& o). If you're used to braces, complicated Haskell expressions with layout look confusing, since it's not immediately clear which indentation style the layout rules are trying to enforce. It's also not clear to the unlearned how best to split an expression onto two lines, or how it interacts with parentheses, etc. And then there are those nasty little infelicities... -- Ashley Yakeley, Seattle WA

1 0

Re: layout rule infelicity
by Ashley Yakeley 30 May '02

30 May '02

At 2002-05-30 02:46, I wrote: >What's the deal with the whole "layout" thing anyway? I've never come >across it before in another language. Oh, wait, there's Python and Ruby. For some reason it doesn't bother me so much with them. -- Ashley Yakeley, Seattle WA

1 0

Announce: HTk - a GUI toolkit for Haskell
by Christoph Lueth 30 May '02

30 May '02

It is our pleasure to announce the release of HTk, a graphical user interface toolkit and library for Haskell. Version 0.98 (World Cup edition) Htk is a typed, portable encapsulation of Tcl/Tk into Haskell. Its distinctive features are the use of Haskell types and type classes for structuring the interface, an abstract notion of event for describing user interaction, and portability across Windows, Unix and Linux. HTk is easily installed -- we provide precompiled binaries for Windows & Linux on x86 and Sparc/Solaris. All you need apart from one of these and a matching version of GHC (5.02.3) is a reasonable recent installation of the Tcl/Tk interpreter "wish". HTk should be particularly useful for teaching, but its reliability and extensive functionality also make it useful in many Haskell projects requiring easily designed graphical user interfaces. This release is for version 0.98. We hope to release version 1.00 in August. The HTk Homepage is http://www.informatik.uni-bremen.de/htk There, you will find binary downloads, source downloads, documention, and much more. HTk is (C) Universität Bremen, 2002. All rights reserved. Please do not hestitate to directed any further questions to <uniform(a)informatik.uni-bremen.de> George Russell <ger(a)informatik.uni-bremen.de> Christoph Lüth <cxl(a)informatik.uni-bremen.de>

3 2