- Haskell - Haskell.org

Binary files and NHC98
by José Romildo Malaquias 14 Oct '00

14 Oct '00

Hello. In order to experiment with the Binary module distributed with nhc98, I wrote the attached program which writes a binary file and then reads it. When executed, I got an extra byte (8) that I cannot explain: [65,66,67,68,8] Any clues why it appears? Regards, Romildo -- Prof. José Romildo Malaquias <romildo(a)iceb.ufop.br> Departamento de Computação Universidade Federal de Ouro Preto Brasil

1 0

Haskore and nhc98
by José Romildo Malaquias 14 Oct '00

14 Oct '00

Hello. I am just curious whether anybody has already tried Haskore (http://www.haskell.org/haskore/) with the NHC98 Haskell compiler. I am trying to do it, while GHC 4.08.1 is non functional in my RH Linux 7.0 box. Romildo -- Prof. José Romildo Malaquias <romildo(a)iceb.ufop.br> Departamento de Computação Universidade Federal de Ouro Preto Brasil

1 0

(no subject)
by Luciano Caixeta Moreira 13 Oct '00

13 Oct '00

unsubscribe haskell(a)haskell.org

1 0

Haskell to XSLT?
by Sylvan Ravinet 13 Oct '00

13 Oct '00

Hello, I was wondering if there are ways to translate Haskell code to XSLT. Any ideas? Thank you for your help, Best regards, -Sylvan -- No, try not. Do, or do not. There's no try. -Yoda Sylvan Ravinet: http://www.ravinet.com/sylvan/contact/ -- This message is Copyright 2000 by Sylvan Ravinet. All rights (and responsibility) reserved.

1 0

How does one find lazyness bottlenecks?
by Sengan 13 Oct '00

13 Oct '00

Now that ghc 4.08 has a time profiler, I've been improving a program I wrote over the last year. However now the GC time dominates the execution time (>60%). I can see that my program is not being lazy, but I have no idea why. How can I use profiling (or any other means) to determine where my program is not being sufficiently lazy? Are there papers on such things I could read? Sengan

3 2

RE: type class
by Mark P Jones 11 Oct '00

11 Oct '00

Hi Zhanyong, | In Haskell, instances of a type class can only be well-formed type | constructors ... | Note there is no type constructor abstraction. | | In practice, I found this rule too restrictive. There are good reasons for the restrictions that were alluded to in my constructor classes paper, and again in Typing Haskell in Haskell. Some text from emails written when this topic came up previously is attached to the end of this message. Actually, the first part of the attached email deals with a different problem (making Set an instance of Monad), but since that also came up for discussion again quite recently, I don't think it will hurt to include it again here. | How about extending TC with a branch for abstraction: | | TC ::= ... | | /\a. TC -- abstraction | | This is too powerful and will get out of control -- we surely don't want | to give TC the full power of lambda-calculus. So let's impose a | restriction: in /\a.TC, a must occur free in TC *exactly once*. This | way, abstraction can only be used to specify with respect to which | argument a partial application is. (or I think so -- I haven't tried to | prove it.) My instinct (which perhaps somebody will prove incorrect) is that this will not help. Suppose, for example, that you needed to unify ([a],[b]) with f c as part of the type inference process. How would you solve this problem? Alas, there are several different, and incompatible ways: ([a], [b]) = (/\a. ([a],[b])) a = (/\b. ([a],[b])) b = (/\c. (c, [b])) [a] = (/\d. ([a], d)) [b] = (/\e. e) ([a], [b]) Note that the /\-terms in each of these examples satisfies your restriction. So I don't think you'll be able to obtain most general unifiers or principal types with this restriction. In my opinion, Dale Miller's work on Higher-order patterns (introduced, I think in about 1991, but I don't have references) would probably be the best starting point for serious experimentation in this area. Hope this helps, Mark -- From the archives: ------------------------------------------------------- Hi Michael, | "...type synonyms must be fully applied". I think the above | example is a valid objection to this. I'll append some text that I wrote on a previous occasion when somebody asked why type synonyms couldn't be partially applied. I hope that it will help to explain why the restriction is not easy to lift, however desirable it might be. The example there was a little different, but I'm sure that you'll see the correspondence. | The other example of something that I want to declare as a monad, but | which I can not is this: Consider a type of collection of some sort that | requires the types of the elements to be instances of some specific class. This too is a problem that has come up quite a few times in the past. As yet, I'm not sure that anyone has a definitive answer for it either, although the work that John Hughes presented at the Haskell workshop on Restricted Datatypes is perhaps the closest that anyone has come so far. A general problem here is that there are differences between conventional mathematics---where you can have sets of any type---and the mathematics of programming languages---where interesting set datatypes can only be constructed on types whose elements have, at least, an equality. In Haskell terms, mathematics has an equality function of type: forall a. a -> a -> Bool; the same operator is available to mathematicians who reason about Haskell programs. But Haskell programmers have to make do with a more restrictive operator of type forall a. Eq a => a -> a -> Bool. (Which is not actually an equality operator at all when you look at what's really going on; it's just a kind of identity function or projection!) All the best, Mark Here's the text I promised: | I'd like to use monadic code on the following type | type IOF b a = b -> IO a | The following seemed reasonable enough: | instance Monad (IOF b) where ... | But Hugs and GHC both object ... The example is rejected because type synonyms can only be used if a full complement of arguments has been given. There are at least two kinds of problem that can occur if you relax this restriction, but both are related to unification/matching. Suppose that we allow your definition. And suppose that we also allow: instance Monad ((->) env) where ... which is a perfectly reasonable thing to do (it's the reader monad). Now what should we do when faced with the problem of unifying two type expressions like: m c and b -> IO a ... Haskell unifies these with the substitution: {m +-> ((->) b), c +-> IO a}, but with your instance decl, you might have preferred { m +-> IOF b, c +-> a }. In other words, it's ambiguous, and the choice between these two could change the semantics because you'll end up picking different instances depending on which choice you make. Or consider what you really mean when you write (IOF b) ... my guess is that you're thinking of it as adding a kind of lambda, so that IOF b = \a. a -> IO b This is appealing, but also means that we'd need to move up to higher-order unification which is undecidable and non-unitary. For example, now we could match m c to b -> IO a in all kinds of interesting ways: b -> IO a = (\b . b -> IO a) b = (\a . b -> IO a) a = (\z . b -> z) (IO a) = (\z . b -> IO a) Int = ... Now we really have ambiguity problems to worry about! Requiring type synonyms to be fully applied --- in effect, telling us that a synonym is nothing more than an abbreviation, and has no other consequences for the semantics --- seems like a nice way to avoid these problems. ----------------------------------------------------------------------------

2 1

PLI 2001-Call for workshop proposals
by b.venneri 09 Oct '00

09 Oct '00

CALL FOR WORKSHOP PROPOSALS Principles, Logics and Implementations of high-level programming languages (PLI 2001) Firenze, Italy September 3 - 7, 2001 http://music.dsi.unifi.it/pli01 PLI 2001, a federation of colloquia which includes ICFP 2001 (ACM-SIGPLAN International Conference on Functional Programming) and PPDP 2001 (ACM-SIGPLAN International Conference on Principles and Practice of Declarative Programming), will be held in Firenze, Italy, September 3 -7 2001. Affiliated workshops will be scheduled from September 2 through September 8. Researchers and practitioners are invited to submit workshop proposals, that may be sent to the PLI 2001 Workshop Chair Betti Venneri, venneri(a)dsi.unifi.it, by e-mail (Postscript, Pdf, ASCII) with "PLI01 Workshop Submission" in the subject header. Proposals should include * a short scientific justification of the proposed topic (somehow related to the colloquia), * names and contact information of the organizers, * expected number of participants and duration (the preference is for one day-long workshops), and any other relevant information (e.g., invited speakers, publication policy, etc.). THE DEADLINE FOR RECEIPT OF PROPOSALS IS JANUARY 8, 2001. Proposals will be evaluated by the PLI 2001 Workshop Chair, the ICFP and PPDP Program Chairs and Conference Chairs. Notification of acceptance will be made by February 2, 2001. Workshop selection committee: Xavier Leroy (INRIA, France), ICFP 2001 Program Chair Benjamin C. Pierce (Univ. of Pennsylvania), ICFP 2001 Conference Chair Harald Sondergaard (Univ. of Melbourne), PPDP 2001 Program Chair Rocco De Nicola (Univ. of Firenze), PPDP 2001 Conference Chair Betti Venneri (Univ. of Firenze), PLI 2001 Workshop Chair. web page: http://music.dsi.unifi.it/pli01/wkshops

1 0

Mailing list software changing
by Simon Marlow 09 Oct '00

09 Oct '00

Dear Haskell & Haskell-cafe, At haskell.org we're migrating the mailing lists from majordomo (which is somewhat old and clunky) to Mailman, which will amongst other things make my life a lot easier, provide better archives, add digest support and allow subscription/unsubscription via a web interface. You should all receive a notification shortly about subscription to the new lists. Unfortunately it seems we have to do this, because the confirmation contains the password for accessing & modifying your personal subscription details on the web. If you *don't* receive a confirmation in the next 24 hours, please let me know. Heres hoping everything goes smoothly, and once again I apologise for the extra spam in your mailbox. Cheers, Simon

1 0

(no subject)
by Alberto Domínguez 05 Nov '99

05 Nov '99

1 0

beginner's questions - fix f
by Bob Koutsky 03 Jan '70

03 Jan '70

Hello, After watching members of this list discussing some for me really incomprehensible details of Haskell standard, I feel sort of silly for asking something probably very basic, but I'd be very grateful for any answer: Some time ago, I have decided to educate myself in functional programming, and I choose Haskell as a language of choice. I purchased "Haskell school of expression" and began to study it. Everything went well, I understood (at least intuitively) everything, but then, suddenly, I hit a wall: ------------------------------------------------------------ Exercise 9.9: remainder a b = if a < b then a else remainder (a-b) b fix f = f (fix f) Rewrite remainder using fix so that it is not recursive. ------------------------------------------------------------ Function fix left me completely puzzled. With help of hugs I found out that its type is "( a -> a ) -> a", but I have absolutely no idea how it could be used to do anything useful. It seems to me that argument to f on the right side of fix's definition must always evaluate to the same value, no matter how deep the recursion is, so there is no point to use it. I guess I am missing something very obvious, but what is it? Can somebody provide me with an example how to use fix for something just a bit useful, if possible to rewrite remainder? thank you, Bob Koutsky

4 3