November 2000 - Haskell

no non-typevariable in instance declarations
by José Romildo Malaquias 15 Nov '00

15 Nov '00

Hello. I found that Hugs differs from GHC 4.08.1 and from NHC98 1.00 in instance declarations where the instance head has only type variables: Hugs accepts them while the other two rejects. Attached is a small program that demonstrates it. Hugs happily runs the program and outputs the list ["NUM","Integer","NUM"] NHC98 spits the message In file ./t.hs: 6:23 Found a but expected one of [ ( <conid> GHC is more verbose in its message: t.hs:6: Illegal instance declaration for `C a' (There must be at least one non-type-variable in the instance head) Compilation had errors Why GHC and NHC98 are more restrictive than Hugs? This style of instantiation would be very helpful when dealing with type extensions in Haskell (based on classes to provide the interface for common operations on the extendable type). Regards, Romildo -- Prof. José Romildo Malaquias <romildo(a)iceb.ufop.br> Departamento de Computação Universidade Federal de Ouro Preto Brasil

4 8

Haskell T-Shirt Contest
by John Peterson 14 Nov '00

14 Nov '00

Tired of seeing people in OCaml TShirts at ICFP? Ready to show the world what language *real* programmers use? Well, here's your chance. We're going to add a "store" to haskell.org to offer Haskell stuff for your holiday shopping convenience. We're going to start with T-shirts and other stuff with a Haskell logo on it using cafepress (www.cafepress.com) Here's how it works: Send me a design usable by cafepress (see their web site for more information). I'm willing to add any reasonable design to the haskell store - there isn't going to be a just one winner in this contest. Entries not related to Haskell or in really bad taste may be rejected but I'll try to be fair. I'll link the store into haskell.org and we'll be ready to go. Anything related to Haskell is OK - you can send in a design for hugs or ghc or any other part of the Haskell universe. Items will be sold at no markup - this isn't a fund raiser. It's just a way for the Haskell community to become a little more visable. Send your graphics to peterson-john(a)cs.yale.edu - I'll try to get the into the store as soon as possble. If you know of any other sites similar to cafepress that could sell other things let me know. All entrants will receive a copy of Hugs 98, completely free of charge. Rejected entries will receive ghc instead. :-) :-) John

1 0

extended deadline for PADO-II
by Symposium on Program as Data Objects 13 Nov '00

13 Nov '00

News: - Because of the number of requests for extensions, the deadline of PADO-II is extended uniformly until Friday 1st of December. - A satellite workshop on Implicit Computational Complexity, ICC'01, is now co-located with PADO-II and MFPS XVII. ---------- Call for Papers Symposium on Programs as Data Objects (PADO-II) Aarhus, Denmark, May 21-23, 2001 http://www.brics.dk/pado2/ PADO-II will bring together researchers working in the areas of programming and programming languages. The symposium focuses on techniques and supporting theory for treating programs as data objects. Technical topics include, but are not limited to: * Program manipulation: program specialization, type specialization, partial evaluation, normalization, reflection, rewriting, run-time code generation, self-application. * Program analysis: abstract interpretation, constraints, type inference, binding-time analysis. * Theoretical issues in representing and classifying programs: semantics, algorithmics, logics. * Applications: interpretation, compilation, compiler generation, verification, certification, meta-programming, instrumentation, incremental computation, staging, prototyping, debugging. Original results that bear on these and related topics are solicited. Prospective authors should submit papers through PADO-II's home page to arrive no later than December 1, 2000, which is an extended deadline. Authors concerned about the appropriateness of a topic are encouraged to consult with the program chairs prior to submission. Complete papers should be submitted electronically, either in PostScript or in PDF. (If this is a problem, please contact the program chairs.) Filenames should result from the catenation of the names of its authors (ie, *not* "paper.ps", "pado2.ps", "popl00.ps", etc., but, eg, "dupond-dupont.ps.gz", "brown-al.ps.gz", or "pedersen.ps.gz"). Submissions should not exceed 14 pages in the LNCS format <http://www.springer.de/comp/lncs/authors.html>. They must designate a corresponding author, include an e-mail address, and contain page numbers (just add "\pagestyle{plain}" before "\begin{document}"). Submitted papers will be judged on the basis of relevance, significance, correctness, originality, and clarity. They should include a clear identification of what has been accomplished and why it is significant. Submissions must include an abstract and a discussion of related work. They must describe work that has not previously been published in a major forum. The authors should indicate if a closely related paper is also being considered for another conference or journal. Authors will be notified of acceptance by January 16, 2001. Full versions of the accepted papers should be formatted in the LNCS format, and received no later than February 16, 2001. Accepted papers will be presented at the symposium and will appear in the proceedings, which will be published as a Springer LNCS volume. Further information about the symposium is available in its home page at <http://www.brics.dk/pado2/>. Chairpersons: Olivier Danvy <danvy(a)brics.dk> Andrzej Filinski <andrzej(a)brics.dk> BRICS, University of Aarhus, Denmark Program Committee: Torben Amtoft, Boston University, USA Charles Consel, LaBRI / ENSERB, France Catarina Coquand, Chalmers University, Sweden Radhia Cousot, Ecole Polytechnique, France Yoshihito Futamura, Waseda University, Japan Fritz Henglein, IT University, Denmark Peter Lee, Carnegie Mellon University, USA Annie Liu, Stony Brook, USA Dave MacQueen, Bell Labs, USA James S. Royer, Syracuse University, USA Morten Heine Sørensen, IT Practice, Denmark Carolyn L. Talcott, Stanford University, USA Jon L White, CommerceOne, Inc., USA PADO-II is held in conjunction with MFPS XVII and ISS'01.

1 0

(no subject)
by Juergen Pfitzenmaier 13 Nov '00

13 Nov '00

Ashley Yakeley wrote at Sun, 12 Nov 2000 23:20:31 -0800: > C++ provides a convenient mechanism for cleaning up stuff, the > destructor, which is guaranteed to .... and asked if something like the C++ destructor could be done in haskell. Don't try this. One of the main attractions of C++ destructors is a guaranteed order their execution. This is too ugly for a lazy language. pfitzen

1 0

Hugs and Linux
by david.landell＠stud.ki.se 13 Nov '00

13 Nov '00

I can't get hugs98 to work under my linuxplatform. I have the Red Hat distirbution 7.0. The problem is that hugs requires a file called "readline.so.3" and I have "readline.so.4" on my system. Does anyone know how to get around this problem?? Best regards, David Landell

7 6

RE: Imperative Object Destruction
by Simon Marlow 13 Nov '00

13 Nov '00

> >That's the problem. And I think your solution is overly complicated. > > > >Why not copy what Common Lisp does, just that Haskell can do > it without > >macros: > > > >withOpenFile :: FilePath -> IOMode -> (Handle -> IO a) -> IO a > >withOpenFile name mode action = do > > handle <- openFile name mode > > result <- (action handle) `finally` (hClose handle) > > return result > > > >Usage: > > > >count :: Handle -> IO Int > >read :: Handle -> IO [Byte] > > > > fileLength <- withOpenFile "filename" ReadMode $ \handle -> > > count handle > > fileContent <- withOpenFile "filename" ReadMode $ \handle -> > > read handle > > Doesn't fulfill condition 2: > > 2. no read or write operations are performed on file-handles > that have > not yet been opened, or that have already been closed. > > ...since you can do > > stealHandle = withOpenFile "filename" ReadMode (\handle -> handle) > stealHandle >>= read If you want to enforce this kind of encapsulation using the type system, you could try using the runST trick, something like: withOpenFile :: FilePath -> IOMode -> (forall s . OpenFile s -> IO a) -> IO a of course, this needs the universal quantification extensions implemented in Hugs & GHC. Cheers, Simon

1 0

Re: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 02:39, Hannah Schroeter wrote: >And that yields an exception, as the handle is definitely closed. > >Is there any *real* problem with this? Well, it doesn't solve the problem I'm interested in. The file-handling is just an example, I'd like to solve it for any kind of object destruction, so that this kind of error is always caught at compile-time. -- Ashley Yakeley, Seattle WA

2 1

Re: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 02:30, Ashley Yakeley wrote: > stealHandle = withOpenFile "filename" ReadMode (\handle -> handle) > stealHandle >>= read Sorry, that should read stealHandle = withOpenFile "filename" ReadMode return stealHandle >>= read -- Ashley Yakeley, Seattle WA

1 0

Re: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 02:18, Hannah Schroeter wrote: >That's the problem. And I think your solution is overly complicated. > >Why not copy what Common Lisp does, just that Haskell can do it without >macros: > >withOpenFile :: FilePath -> IOMode -> (Handle -> IO a) -> IO a >withOpenFile name mode action = do > handle <- openFile name mode > result <- (action handle) `finally` (hClose handle) > return result > >Usage: > >count :: Handle -> IO Int >read :: Handle -> IO [Byte] > > fileLength <- withOpenFile "filename" ReadMode $ \handle -> > count handle > fileContent <- withOpenFile "filename" ReadMode $ \handle -> > read handle Doesn't fulfill condition 2: 2. no read or write operations are performed on file-handles that have not yet been opened, or that have already been closed. ...since you can do stealHandle = withOpenFile "filename" ReadMode (\handle -> handle) stealHandle >>= read -- Ashley Yakeley, Seattle WA

2 1

RE: Imperative Object Destruction
by Ashley Yakeley 13 Nov '00

13 Nov '00

At 2000-11-13 01:27, Chris Angus wrote: >why not create an abstract datatype > >OpenFile a which is a monad > >data OpenFile a = OpenFile (Maybe FileHandle -> IO a) > >and create you operations in terms of this > >openFile :: String -> OpenFile () >count :: OpenFile Int >read :: Int -> OpenFile [Byte] > >then you could habe a run function > >runOF :: OpenFile a -> IO a > >which ran whatever you wanted for the file and ensured tahthe file was >closed correctly afterwards. This is a slight generalisation of my scheme, from which withFile :: OpenFile a -> String -> IO a withFile operation name = runOF (openFile name >> operation) >How we would do this with 2 files however I'm not so sure. Looks like you can't. This might work, however: read :: (Int,Int) -> OpenFile IO [Byte] write :: (Int,[Byte]) -> OpenFile IO () withFile :: OpenFile a -> String -> a copyFile :: OpenFile OpenFile IO () withFile (withFile copyFile "dest") "source" ...but I'm not sure how to write copyFile. -- Ashley Yakeley, Seattle WA

1 0