- Haskell - Haskell.org

Mutually recursive structures
by Timothy Docker 17 Oct '00

17 Oct '00

The following problem has been taxing me.... I have a list of pairs that I have parsed from a input file, which represent a hiirarchy, where the first element is the name of the object, and the second is the name of the parent if there is one: type ParseOutput = [(String,Maybe String)] I wish to convert this to a list of "objects", where from each object I can navigate to the parent object (if any), or the children (if any): data Obj = Obj { name::String, parent::(Maybe Obj), children::[Obj] } type Result = [Obj] convert:: ParseOutput -> Result In a language with mutable references, this would be a relatively straightforward. I would just create a dictionary mapping from name to Obj, and then iterate over them, filling in the parents and children where appropriate. odict = {} for (name,parent) in parseOutput: odict[name] = Obj() for (name,parent) in parseOutput: if parent: parent = odict[parent] child = odict[name] child.parent = parent parent.children.append( child ) This gives away my background! How can I do this in Haskell? If I don't have mutable references, I figure that I must need to use laziness in some way, perhaps similar to how I would build an infinite structure. A hint or two would be great. Tim

2 2

Haskell function with String arguments in DLL
by Christian Lescher 17 Oct '00

17 Oct '00

I'm trying to build a DLL with a Haskell function of type String -> String, that should be called from outside (e.g. VBA), but it still doesn't work. I'm afraid I need an example or some kind of 'step by step instruction'. Who can help me? (I use GHC 4.08.1.) Christian

1 0

Haskell puzzle
by Rishiyur S. Nikhil 16 Oct '00

16 Oct '00

In Haskell, is the following transformation always legal? \x->\y->e transforms to \x y->e After answering this question, please scroll down about 75 lines for a follow-up question. What if the two lambda-bound variables are the same? I.e., the lhs is \x->\x->e Please refer to Section 3.3 of the Haskell 98 Report, para 3 (one line para).

1 0

NHC98 and GHC 4.08.1 differ on monad related functions
by José Romildo Malaquias 14 Oct '00

14 Oct '00

Hello. While porting Haskore to NHC98 I got an error I am not understanding. I have attached a test module that shows the error message: $ nhc98 -c Test.hs ==================================== Error after type deriving/checking: No default for Monad.MonadPlus at 7:1.(171,[(2,209)]) No default for Monad.MonadPlus at 6:1.(174,[(2,208)]) GHC 4.08.1 and Hugs98 accepts the code without complaining. Any hints? Romildo -- Prof. José Romildo Malaquias <romildo(a)iceb.ufop.br> Departamento de Computação Universidade Federal de Ouro Preto Brasil

1 0

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