January 2002 - Haskell

(no subject)
by David Feuer 25 Jan '02

25 Jan '02

Martin Said: > Those two constructs are not the same > Compare > newtype T1 = C1 Bool > data T2 = C2 !Bool > the difference is that the constructor C1 does not exist, so only the following values exist for T1: > C1 True (which is the represented as True) > C1 False (which is the represented as False) > C1 _|_ (which is represented as non-termination or error) > however, for T2, another value exist, namely _|_. > So, pattern matching on (T2 x) may fail it the value is > _|_. You are > right that semantically newtype is the same as always matching lazily on the constructor. The report says clearly that for a newtype like T1, C1 _|_ = _|_ This is the same as for T2 and C2. As for as I can tell, the only difference in the Report between a newtype and a tuple type with a completely strict constructor is in the rules for pattern matching. So I am trying to find someone who can explain the reason for the difference in the rules! I really want to know, because I think/hope that it will help me understand certain things about how to write efficient code. > The case for a tuple type (a,b,c) for instance, is different. Here there > is a constructor, you can even type it by itself, it is > (,,), try ":t > (,,)" in hugs or ghci. I don't understand what you're talking about here.... Of course there's a constructor... This message has been brought to you by the letter alpha and the number pi.

2 1

newtype pattern matching
by Feuer 25 Jan '02

25 Jan '02

Why is pattern matching on newtypes lazy? Does this add to efficiency somehow? If not, it seems to be just another rule to keep straight.

2 3

vim syntax highlighting file for TeX and Haskell in the same file
by Ian Lynagh 25 Jan '02

25 Jan '02

Hi all I have written a vim syntax highlighting file which, given a literate script with TeX markup surrounding the Haskell code, will highlight both the TeX and Haskell. lhaskell.vim is at http://c93.keble.ox.ac.uk/~ian/haskell-vim/lhaskell.vim along with haskell.vim and tex.vim, but you should not need these as they should come with vim. lhaskell.vim should go in ~/.vim/syntax/ or somewhere else in your runtimepath (type ":set runtimepath" in vim to see it) A demo of what it should look like is at http://c93.keble.ox.ac.uk/~ian/haskell-vim/Demo.png I'm not sure how well it will work (if at all) in versions of vim prior to 6.0. Enjoy! Ian

2 1

RE: ideas for compiler project
by George Russell 24 Jan '02

24 Jan '02

One thing I would very much like to see done in a functional language is fault-tree analysis. A fault tree has as nodes various undesirable events, with as top node some disaster (for example, nuclear reactor meltdown) and as leaves various faults which can occur, with their probabilities (valve fails, operator doesn't notice red flashing light, and so on). Each internal node has a logical operator (often just AND or OR) associated with it; the fault associated with that node cannot happen unless the operator applied to the children nodes occurs; EG ("the water pressure won't get too high unless the valve fails AND the operator doesn't notice the red flashing light"). Thus you can (assuming all the faults at the leaves are independent) bound the probability of the top node happening by bounding the probability of a particularly horrendous logical expression in a number of independent binary variables being true. Unfortunately working out the probability is extremely hard to do (it's #P-complete) and simulation (running it lots of times) is not accurate since the top probability is (hopefully) extremely low, and so hard to estimate accurately without an awful lot of tests. So the commercial software for this (extremely important) problem has to adopt a very large number of heuristic approaches, for example trying to split the problem into smaller parts which only have a few nodes in common, trying to come up with a set of "cut sets" of faults, such that the top event cannot occur unless at least one of the cut sets has all faults occurring, and so on. There are lots of potential logical reorderings you can attempt on the tree to try to simplify things. The challenge is to come up with a reasonable way of finding a good upper bound for the top probability, while keeping your code sufficiently simple that those of us who live near nuclear reactors can trust it. I think my approach would be to regard this as a graph transformation problem where the aim is to transform the input fault tree into one of a simpler form (where it is not too hard to bound the top probability) by a number of well-defined operations guaranteed not to decrease the top probability. The heuristic part of the program (the largest part) would use a number of ad hoc methods (such as simulations and attempting to compute partial derivatives in terms of node probabilities) to search for the reduction which increases the top probability the least; it would hand over the result of its search to a verification part which would compute the actual bound, so that only the verification part would have to be guaranteed bug-free. Has anyone done anything like this already, by the way? There ought to be money in it . . .

1 0

Explicit Universal Quantification Bug?
by Jay Cox 24 Jan '02

24 Jan '02

I'm trying to learn more about Explicit Universal Quantification so I decide to run the following supposedly correct code from the ghc user guide: >module Dummy where > >import ST > >newtype TIM s a = TIM (ST s (Maybe a)) > >runTIM :: (forall s. TIM s a) -> Maybe a >runTIM t = case t of {TIM l -> runST l} however when i try to actually compile it with ghc 5.02.1 it gives this error ... C:\exp>ghc -fglasgow-exts -package lang x.lhs ~ x.lhs:8: Inferred type is less polymorphic than expected Quantified type variable `s' escapes It unifies with `s1', which is mentioned in the environment The following variables in the environment mention `s1' l :: ST s1 (Maybe a) Signature type: forall s. ST s a1 Type to generalise: ST s1 (Maybe a) When checking an expression type signature In the first argument of `runST', namely `l' In a case alternative: runST l C:\exp> ... so, is this a bug? I noticed also the following code compiles fine. (slightly modified from a message on this list titled "Re: Type problem with ST monad" dating April 23, 1999 >module Dummy where > >import ST > >newtype TIM s a = TIM (ST s (Maybe a)) > >runTIM :: (forall s. TIM s a) -> Maybe a >runTIM t = runST (deTIM t) > >deTIM (TIM t) = t so, is using a pattern matching function the truly accepted way instead of using the case statement mentioned in the docs? Is the ghc manual outdated? Thanks Jay Cox

1 0

Re: Instance contexts constraining only type variables?
by Wolfgang Jeltsch 24 Jan '02

24 Jan '02

Wolfgang Lux wrote: > Wolfgang Jeltsch wrote > > > Hello, > > say I have a type T defined the follwing way: > > newtype T a b = T (a b) > > Now I want to make every T a b with a b beeing an instance of Eq also an > > instance of Eq where (==) just test for equality of the encapsulated values. > > I > > try this > > instance Eq (a b) => Eq (T a b) where > > (T x) == (T x') = x == x' > > but it seems that this is not Haskell 98 conformant. > > You probably meant a and b being an instance of Eq, No! Look at the definition of T. Right to the equals sign there is T (a b) which implies that a b has kind * and therefore kind (a) = kind (b) -> * if for any type t kind (t) is the kind of t. So a can never be an instance of Eq because it doesn't have kind *. Every value of type T encapsulates exactly one value which is of type a b. I want to test for equality of these values wherefore a b has to be an instance of Eq. By the way, why is (* -> *) -> * -> * the infered kind of T and not for instance ((* -> *) -> *) -> (* -> *) -> *? > so you should write it > down the same way :-) > > instance (Eq a,Eq b) => Eq (T a b) where > ... > > Wolfgang > > -- > Wolfgang Lux Phone: +49-251-83-38263 > Institut fuer Wirtschaftinformatik FAX: +49-251-83-38259 > Universitaet Muenster Email: wlux(a)uni-muenster.de Wolfgang

1 0

RE: H98 Report: semantics of pattern matching
by Simon Peyton-Jones 24 Jan '02

24 Jan '02

| From: Ross Paterson [mailto:ross@soi.city.ac.uk] | Sent: 21 January 2002 17:20 | To: haskell(a)haskell.org | Subject: H98 Report: semantics of pattern matching | | | In section 3.17 Pattern Matching, there are some | inconsistencies between the informal and formal semantics: Tbanks very much Ross. I agree with all your suggestions and will implement them. Simon

1 0

Make Lots of $$$$$$$$$$$$$$$$
by ky_1064＠yahoo.com 24 Jan '02

24 Jan '02

1 0

Re: type class VS struct/functor
by Mike Gunter 24 Jan '02

24 Jan '02

You can also export the type without exporting the constructors. That way "import"ers can use the type in type signatures and instance declarations while still not being able to use anything but the exported interface. E.g. instead of Module Set ( emptySet , makeSet , firstOfSet ) where use Module Set ( Set -- <=========== , emptySet , makeSet , firstOfSet ) where . (The non-hiding export is Module Set ( Set(..) -- <=========== , emptySet , makeSet , firstOfSet ) where .) This is covered in the Haskell report; see: http://www.haskell.org/onlinereport/modules.html#abstract-types . mike > At 13:15 2002-01-22 -0500, Hongwei Xi wrote: > ><...> > >In Haskell, I guess that the one implemented later is always chosen. > >Why can't I have two different implementations for an interface? > > Actually, I can't think of situations where I would desire this. > Could you please give an example? > > >Another problem with Haskell classes is that there is currently > >no way of hiding type information. For instance, suppose that > >I want to implement a module for operations on sets but I do > >not want to reveal what data representation I use for sets. Is > >there a way of doing this in Haskell? > > > >--Hongwei > > There is: Use restricted exports. Only export functions on the > datatype, and don't export the datatype itself. For example: > > ----------------------- > Module Set > ( emptySet > , makeSet > , firstOfSet > ) where > > -- Not exported, only locally visible > data Set a = EmptySet | OneElementSet a > > -- Using these functions, everyone can > -- make, change and read Set's > emptySet :: Set a > emptySet = EmptySet > > makeSet :: a -> Set a > makeSet x = OneElementSet x > > firstOfSet :: Set a -> a > firstOfSet EmptySet = error "Set.firstOfSet: Empty set" > firstOfSet (OneElementSet x) = x > ----------------------- > > Regards, > > Rijk-Jan van Haaften > > > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell

1 0

type class VS struct/functor
by 안기영 23 Jan '02

23 Jan '02

I prefer Haskell style type classes because using them one can overload functions. e.g. \begin{code} class Container a where celem :: Eq b => b -> a b -> Bool cmap :: (Eq b, Eq c) => (b->c) -> a b -> a c data MyList a = MyList [a] deriving Show instance Container MyList where celem x (MyList l) = elem x l cmap f (MyList l) = MyList (map f l) \end{code} What does ML struct/functor have anything better than type classes ? For the user type classes feels like implicit functor istantiations to specific sturucture, and struct/functor seems just bugglling the user to do more typing which can be automated by using type classes. Type classes are more than automatic functor instantiation since it can construct hierarcy between types and you can implement implicit type conversoins. I think ML, especially nML - the Korean dialact of ML being developed in ROPAS(http://ropas.kaist.ac.kr/) - should throw away struct/functor or deprecate them and move to type classes. p.s. Am I asking ML to metamorph into eager Haskell ? :-)

3 2