- Haskell - Haskell.org

(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

layout rule infelicity
by Jon Fairbairn 30 May '02

30 May '02

Two very similar programmmes: > possible_int = do skip_blanks > fmap Just int > +++ (literal "-" `as` Nothing) > possible_int = do skip_blanks > fmap Just int > +++ (literal "-" `as` Nothing) I think this is extremely bad language design! In general I like having layout rules, but I've often thought that they ought to take note of expressions, not just things in {...} and that there ought to be "dead zones" where no programme text is allowed, so that everything starting with the second example and ending with > possible_int = do skip_blanks > fmap Just int > +++ (literal "-" `as` Nothing) should be rejected. This example clinches it for me. Can anyone more au fait with the layout rule figure out how to do it? (My past irritation was that ... if p then q else r is acceptable in some circumstances, but one has to use ... if p then q else r in others. Having programmes rejected I don't mind, but having them accepted when they are too close to right but still wrong, I really do mind) -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

1 0

query about precedence: "$", the lazy function application operator
by Mark Phillips 30 May '02

30 May '02

Hi, As I understand it, function application has highest precedence (10 even!) whereas $, the operator which does the same thing, has lowest precedence (0 even!). But there's something that doesn't make sense to me. Suppose I have functions f :: Int -> Int f x -> x * x g :: Int -> Int g x -> x + 1 The lazy application operator "$" allows me to do: f $ g x instead of f (g x) But I don't understand why it works this way! Let me explain. f is a function, and application has highest precedence, so unless it sees a bracket, it should take the next thing it sees as an argument. Lo and behold the next thing it sees is "$", which is not a bracket! So it should try and apply f to argument $. But oh dear, $ is a function (operator actually); it is not an Int at all! So an error should be reported! So what am I not understanding properly? Thanks, 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