June 2004 - Haskell-Cafe

Re: Modelling Java Interfaces with Existential data types
by Ralf Laemmel 11 Jun '04

11 Jun '04

Hi Mike, Let's redirect to Haskell cafe. http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06288.ht… http://www.mail-archive.com/glasgow-haskell-users%40haskell.org/msg06289.ht… thanks for your time to look into the HList paper. >1. It looks like your HList is basically a "sugarized" version of > >data AnyMyInterface = Impl1 MyImplementation1 | Impl2 MyImplementation2 > >with the same drawback: you require me to explicitly list all the possible >implementations of my interface I don't think that anything was required to be explicit: If you mean this here: type MyList = MyImplementation1 :*: MyImplementation2 :*: HNil ... then note that this type is inferred! So with HLists, there is nothing like your Impl1 and Impl2, and no new datatype like your AnyMyInterface. Just for clarity: (i) I like comparing Haskell datatypes with Java classes. (ii) In Haskell, when you want to say that you have different implementations for the same interface, or when you want to say that different datatypes provide implementations of a certain interface, then you use Haskell's type class system. (iii) When you define an interface in Java, you rather define a type class in Haskell. Type class are of course more powerful, but we don't mind. (iv) When you say "implements" in Java, you rather say "instance" in Haskell. (v) When you define the methods of the interface to be implemented in Java, you define the methods of the instance. I would claim the Haskell code ends up being more modular :-) You immediately get a simple form of Java-like interface polymorphism in Haskell, say when you got a constraint, then you are polymorphic over implementations (instances) of that constraint. The crux of your concern seems to be that you want to package values of different types (Java: classes). Indeed you want to have heterogeneous containers modulo subtyping. And our lovely HLists are just good for that, but they come with the added value that they don't make the elements opaque as it is the case with the sometimes troublesome existentials. > It >might be possible to load them via hs-plugins or to obtain using something >similar to Clean Dynamics (btw, is there anything similar available for >Haskell?). Data.Dynamics Not needed here. >2. There will also be problems in gluing the utility/legacy code. E. g. if I >want to call any list function on HLists (e.g. reverse). The idea of having >heterogeneous FiniteMap can be implemented by storing the single-element >lists, but it will complicate the code, which will work with the map. I concur. Using HList for everything is perhaps too invasive. The HList paper makes clear that there are certain cases where HLists are really needed, and they are complementary what generics provide you with in Java. I was just able to use them for something were a Generic Java programmer uses Generics and subtyping for. So existentials are perhaps Ok. However, directly comparing the opaque values is untypeable, >I'm completely confident with applying (==) to different type. It's quite a >common operation in OO-world. Yes, what you need is type-safe cast. See paper 1 here: http://www.cs.vu.nl/boilerplate/ >I would like to have the following behaviour: > >instance Eq AnyMyInterface where > (==) (AnyMyInterface a1) (AnyMyInterface a2) = > if (typeOf a1) == (typeOf a2) then false else a1 == a2 > Java is just a weakly typed subset of Haskell :-) Here we go ... -- Yet another heterogeneous equality yaHEq :: (Typeable a, Typeable b, Eq a) => a -> b -> Bool yaHEq a b = case cast b of Just a' -> a == a' Nothing -> False *Main> yaHEq True True True *Main> yaHEq True "True" False *Main> As you said yesterday that the equality issue is your main problem, let's wipe this out for existentials as well. I revise your existential wrapper type to include all goodies that are needed, say Eq and Typeable: data AnyMyInterface = forall a. ( Eq a , Typeable a , MyInterface a ) => AnyMyInterface a This is just your list type: type MyList' = [AnyMyInterface] Here are two lists: list4 = [ AnyMyInterface $ MyImplementation1 10 , AnyMyInterface $ MyImplementation1 10 ] list5 = [ AnyMyInterface $ MyImplementation1 10 , AnyMyInterface $ MyImplementation2 10 ] Here is a demo: *Main> list4!!0 == list4!!1 True *Main> list5!!0 == list5!!1 False Cheers, Ralf PS1: All code is here: http://homepages.cwi.nl/~ralf/HList/code.html PS2: I guess Sheard's work on parameterised modules might also interest you. http://portal.acm.org/citation.cfm?id=507648&dl=ACM&coll=portal And John Huges Restricted Data types as it shows how to reify dictionaries:

3 4

Re: Haskell-Cafe Digest, Vol 10, Issue 3
by Ron de Bruijn 11 Jun '04

11 Jun '04

>G'day all. Good day to you too. >I don't know what you mean by "more complex". A dot >is just a dot, and >it has no internal structure that we can get at using >category theory >alone. Some dots may play specific roles in relation >to other dots and >arrows, but no dot is any more complex than any other, >really. Well, intuitvively seen, I meant. In some categories, the dot might stand for a functor, and in some other as a simple object. >For a counter-example, think of the dual category >Set^{op}. A morphism >f : a -> b in that category means that there is a >function f^{op} : b -> a > >where a and b are sets, however f probably isn't a >function at all. Well, what is it then? I see a function as something where you put something in and you get a result. In this case, you already say, there is a morphism b->a, wel than the following of b to a and return a then is a function? A couple of days ago, I thought of the distinction between a function and a morphism, as in that a function operates on a hole set of objects, a.k.a. domain. And a morphism only on one. Is that the distinction you mean? If all of the above is false, then probably I don't know what a function is. (It looks like the more you are busy with things, the less you seem to know of it). >In a category which is a partial order, there is a >morphism f : a -> b >if and only if a <= b. (Or is it a => b? Can never >remember.) Here, >the morphisms really have no internal structure at >all. If the >category >has a finite number of objects, you can represent the >whole thing using >a bit matrix, and each morphism can be identified with >a bit set to >"true". Preserving internal structure is not much more than preservation of composition, right? >I think the problem here is that you have the idea >that a morphism is >a process that turns one object into another. In many >(probably most) >interesting, practically significant cases, that's >true, but it need >not be. Well, I think I don't know what a function is, because the following of an arrow, represents at least for me a clear mapping of turning one object in to another. Or do you mean things like in logic, that you can see the morphism, as relations (instances of axioms) between logic objects. So the morphism a->b would mean that a implicates b. This way, the arrow is not a process of turning an a into a b. Hmm, that seems logical. >I think it really helps to try to understand category >theory mostly as >a language for talking about things, and not >necessarily "things" in >and of themselves. Using this understanding, a >morphism is a noun, not >a verb. It's a concrete thing describing a >relationship between >objects, >not necessarily an action that you perform on objects. I think you have already answered my question this way. But a confirmation would be nice. It seems I had to read your explanation >1 time. >I don't know if any of this helps or not. Well, it certainly helps. Then the multiplication issue: Is the following a good summary? A multiplication is just a name for an operation that is defined or not defined for each mathematical construction in terms of to which laws the operation should comply. The laws are then things like communativity and so on. Regards, Ron __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [Haskell-cafe] Join and it's relation to >>= and return
by Ron de Bruijn 11 Jun '04

11 Jun '04

I am pretty sure, that >>= is to monads what * is to for example natural numbers, but I don't know what the inverse of >>= is. And I can't really find it anywhere on the web(papers, websites, not a single sole does mention it. It should have type, at least that's what I think: inv::M a->M b I say this, because I find this definition of a multiplication operation: 1. There exists a unique special element called neutral such that the operation on any element and the neutral does not change the element. 2. For every element there exists an inverse such that the operation on an element and its inverse is always neutral. 3. The operation is associative: it does not matter how you apply the operation to three elements. You may apply it to the first two and then to the result and the third element. Or you may first apply the operation to the last two and then to the first and the result of the previous operation. An operation may also be commutative 4. The order of two elements in operation is not important. According to 2 there should be an inverse. For join such an inverse is simple: to apply the type constructor on the monad. But I tried to somehow link it with bind, but than the types don't seem to match. So to be concrete: what's the inverse of bind? If I did make some errors, please tell me so. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

8 8

Re: [Haskell-cafe] RE: Modelling Java Interfaces with Existential data types
by MR K P SCHUPKE 10 Jun '04

10 Jun '04

>interested in how to (ab?)use type classes Surely there's no such thing as abuse of a language feature in a language with formal semantics! Keean.

1 0

Re: [Haskell-cafe] Join and it's relation to >>= and return
by Ron de Bruijn 10 Jun '04

10 Jun '04

Hello again, I have thought a while about morphisms and although I had written down in my paper that a functor and also a natural transformation are also morphisms, but in a different category, I now am not sure anymore of this. If you see everything(objects and morphisms) as dots and arrows, and some arrows and some dots are just some more complex than others, then this holds, but is that legal? Intuitively seen, it is. According to some paper, morphisms are not like functions, in that you can apply some morphism to an object, but that you can only compose them. But I would say that if you have the morphism f:a->b, that is a arrow from dot a to dot b. That there clearly is a notion of following that arrow, in effect applying a function. And suppose there is the following path of morphisms: a---->b---->c---->d, with a..d are dots. Then I would say there are three functions(constructed by composition)(in fact more, because of identity mapping) from a that when followed give new objects. This following of arrows, looks a lot like general function application, as in f(x) = 2x for example. It's btw quite hard to write the essence of monads down in a clear and precise way. I hope you can give some feedback on the above. Ragards, Ron P.S. The question about multiplication still stands. Probably multiplication is a set of laws defined on a mathematical object that must hold. And for each mathematical object there is such definition. Is this correct? __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

2 1

Re: how to write a list builder? fixpoint?
by Graham Klyne 08 Jun '04

08 Jun '04

[moved to Haskell-cafe] This makes my head hurt! Let me see if I get this right. When the type checker sees: build' as a a2 ... then it invokes the second instance of BuildList (i.e. BuildList a (a->r)) and returns the value: build'(a:as) a2 ... But when it sees just: build' as a (as a value, not used as a function application), then the type checker invokes the first instance and returns: reverse$ a:as So they key here appears to be that the type-checker can distinguish between function application and other uses of an expression? #g -- At 18:18 01/06/04 -0700, oleg(a)pobox.com wrote: > > Is it possible to write a function to build a list [a]? > > so that I can write [a,b,c,d] as "getBuilt $ build a b c d"? > >Yes, in the format very close to desired. > > > {-# OPTIONS -fglasgow-exts #-} > > {-# OPTIONS -fallow-undecidable-instances #-} > > > > module Foo where > > > > class BuildList a r | r-> a where > > build' :: [a] -> a -> r > > > > instance BuildList a [a] where > > build' l x = reverse$ x:l > > > > instance BuildList a r => BuildList a (a->r) where > > build' l x y = build'(x:l) y > >That's it. It works both on GHC and Hugs. > >*Foo> build' [] True :: [Bool] >[True] >*Foo> build' [] True False :: [Bool] >[True,False] >*Foo> build' [] True False False :: [Bool] >[True,False,False] >*Foo> build' [] 'a' 'b' 'c' 'd' 'e' :: [Char] >"abcde" >*Foo> build' [] (1::Int) :: [Int] >[1] >*Foo> build' [] (1::Int) (2::Int) :: [Int] >[1,2] >*Foo> build' [] (1::Int) (2::Int) (3::Int) :: [Int] >[1,2,3] > >Note that the type annotation [Bool] etc. at the end is required: it >is the delimiter of the list. Who would have thought that the type >annotation can play the role of Nil... > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Modelling Java Interfaces with Existential data types
by Tom Pledger 08 Jun '04

08 Jun '04

Hi. Another way is to take advantage of Haskell's laziness: > class Foo a where > foo :: a -> Int > > data Oof1 = Oof1 Int > instance Foo Oof1 where foo (Oof1 i) = i > > data Oof2 = Oof2 Int > instance Foo Oof2 where foo (Oof2 i) = i > > list1 = [foo (Oof1 10), foo (Oof2 20)] That's all it takes. The applications of foo in list1 don't get evaluated until list1 is used, e.g. by sum. Regards, Tom

1 0

forkIO preemption
by S. Alexander Jacobson 07 Jun '04

07 Jun '04

When you forkIO and one of the threads blocks (e.g. on a socket or a readchan), do execution automatically resume on other threads and does the blocked thread consume timeslices while it is blocked? In other words, is there any performance penalty in setting timeslices very large in a server app (where all I care about is throughput)? -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com

1 0

Join and it's relation to >>= and return
by Ron de Bruijn 07 Jun '04

07 Jun '04

Hello, The last 3 or 4 days I have been studying a lot of Category Theory so that I would be able to explain the concept of a monad to some people at the university in a "learn to present something"-course. newtype S a = State -> (a,State) -- functor T to map objects mapS::(a-> b) -> (S a -> S b) -- functor T to map morphisms unitS :: a -> S a --\eta joinS::S(S a)-> S a -- \mu This is a complete monad using a direct mapping from Category Theory. I really like it, because it's mathematically grounded. But I don't know how to map this to Haskell monads using the standard "bind" and "return", as I explain below. Although, I do believe I understand most parts of it(as in Functor, Natural Transformation and so on), I don't really understand how the join function (conventional monadic multiplication as it's called in the documentation) relates to the >>= and return functions that are mostly used. I read somewhere at Google that join can be expresed in terms of >>= and return, but I couldn't find it anymore. I also read that the Kleisli triple has more resemblance to how monads are used in practice, but it has some additional constraints. I don't understand why there are these additional constraints and I don't understand it's relevance, because according to some book there's a one-one mapping from monads to Kleisli triples and reverse. I also don't understand why join is a "multiplication", because a multiplication takes two operands (as in 5*4), at least all multiplication operators I know do so. I think what's happening is that one structure is taken out of the other. And then, the two are "merged" in some way. So this way, there are two operands. Is this correct? (I really could use a function definition in Haskell of join in terms of bind and return). Can somebody explain me (with a lot of detail) how this works? Regards, Ron __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

emacs haskell-mode indentation
by Nathan Weston 01 Jun '04

01 Jun '04

I am learning haskell from "The Haskell School of Expression", and finding the indentation in the emacs mode rather unhelpful. When I try to type in the following example from the book: main = runGraphics ( do w <- openWindow "Graphics" (300,300) drawInWindow w (text(100,200) "Hello, world!") k <- getKey w closeWindow w ) emacs wants to indent it like so: main = runGraphics ( do w <- openWindow "Graphics" (300,300) drawInWindow w (text(100,200) "Hello, world!") k <- getKey w closeWindow w ) (For those not using a fixed-width font, in the first example, everything lines up under the 'w <-', in the second, everything lines up under the 'do') If I let emacs have its way, I get a syntax error. Am I doing something wrong here? Is the emacs mode broken? Thanks, Nathan

2 1