- Haskell-Cafe - Haskell.org

Sets symmetric difference
by Jenny678 18 Jun '06

18 Jun '06

Hello, Know Somebody the code for symmetric difference (Sets) examples >symmetric_difference [1..8][5..7] >[1,2,3,4,8] >symmetric_ difference [1..8][] >[1,2,3,4,5,6,7,8] >symmetric_ difference [1..12][10..20] >[1,2,3,4,5,6,7,8,9,13,14,15,16,17,18,19,20] Thanks for Help -- View this message in context: http://www.nabble.com/Sets-symmetric-difference-t1805165.html#a4919646 Sent from the Haskell - Haskell-Cafe forum at Nabble.com.

2 1

SMTP, HTTP, Telnet
by Lyle Kopnicky 17 Jun '06

17 Jun '06

Hi all, Anybody know of some good Haskell libraries providing: * an SMTP client, * an HTTP client, * or a Telnet client? There's a significant amount to these protocols, over and above the socket layer. Thanks, Lyle Kopnicky

2 1

RE: why isn't everything an instance of Data?
by Ralf Lammel 17 Jun '06

17 Jun '06

Hi Frederik, Cc Haskell-café as proposed by Frederik, > Why isn't everything an instance of Data? > > It seems natural to give every type which is defined via 'data' an > automatic Data instance. This would make implementing many things much > simpler. Certain types such as functions would only be able to have > "stub" instances, for instance not allowing traversal of constructor > arguments, but this would no more hurt the user than not having such > instances defined in the first place. To clarify, what I am suggesting > is that Data no longer be a class but an interface - one would be able > to call 'toConstr' on any type. [Ralf Lammel] I get your overall question but let me ask about one detail. When you say "an interface", what does this mean in the Haskell sense (where normally a type-class is like an OO interface *anyhow*)? > Is there a fear that this would lead to "sloppy programming"? [Ralf Lammel] I agree that it could be convenient to assume gfoldl and all that as true primitives. Personally, I wouldn't necessarily like that: Haskell's type system seems to be designed to (mostly) distinguish parametrically polymorphic functions from the rest; just as much as it (mostly) makes explicit any effects involved in a computation. Also, how would these primitives need to be implemented? We would need a whole lot of type information in the sense of reflection to be around at run-time. > Also, it would be nice if it were possible to have the compiler infer, > in a function such as > > cast :: a -> Maybe b > > that 'a' and 'b' are instances of the same classes. However, unless > I'm mistaken this would require 'cast' to have special status with the > compiler (or for there to be some new syntax allowing one to indicate > that two type variables implement the same classes). [Ralf Lammel] There are several problems here. First, I doubt that we want to establish "that 'a' and 'b' are instances of the same classes". That sounds like a too special case. I guess we would want to establish that a given type instantiates a given type class. Second, our new cast operation (which would indeed be very much like an OO down-cast) would need to be a special primitive indeed, including special syntax. If we had first-class type-classes, special syntax is not needed, but we would still need a primitive for the actual cast. Third, we need to come up with some fairly tricky means of getting the dictionary for a type "out of the blue" at run-time. This would be sort of possible (certainly for monomorphic types) if we had the type of the value/expression around at run-time, so that we can use it to look up a dictionary from a global pool. However, that type is not available without extra effort. To summarize, if this was the question, this expectation seems to lead pretty far away from what we have in Haskell and likely to get anywhere soon -- as far as I can tell. > But without such > inferences, the Generics stuff has limited usefulness - so much in > Haskell is based on classes, but the only class one can use in the > argument of say 'everywhere' is Data itself: > > everywhere :: (forall a . Data a => a -> a) -> forall a . Data a => a -> a [Ralf Lammel] There are two stories here: a) Any type-specific case can make any amount of type-class assumptions even in the original SYB1 style. This gets you pretty far in practice. b) If you want to write generic functions whose set of types is characterized by a designated type class, then you need to use SYB3 style. HTH, Ralf PS: Some related stuff ... - I uploaded a new SYB paper recently: http://www.cwi.nl/~ralf/syx/ - We also updated the SYB site to include other people's SYB papers: http://www.cs.vu.nl/boilerplate - See Pablo Nogueira's paper "Context-Parametric Polykinded Types" for some interesting GH-related issues on type classes; http://www.cs.nott.ac.uk/~pni/Papers/ - Finally, I plan to use my new blog for Haskell-related stuff as well: http://blogs.msdn.com/ralflammel/

1 0

putStrLn
by Jenny678 16 Jun '06

16 Jun '06

Hello, Can somebody help me I want to work with putStrLn main n = putStrLn "*" for example How must I define the code that: >main 5 >***** Thanks for any help -- View this message in context: http://www.nabble.com/putStrLn-t1799896.html#a4905456 Sent from the Haskell - Haskell-Cafe forum at Nabble.com.

3 2

Inferring types from functional dependencies
by Jeff.Harper＠handheld.com 16 Jun '06

16 Jun '06

Thank you. I followed your suggestion and implemented my default Divide as you've shown below. oleg(a)pobox.com wrote: > If we assume that we need Reciprocate only if we are going to use the > 'default' method, the solution becomes obvious. It does involve > overlapping and undecidable instances, sorry. These extensions are > really useful in practice. Here's the solution: > > > class Divide a b c | a b -> c where > > (/) :: a -> b -> c > > > Here's the most general instance. It applies when nothing more > specific does. It is in this case that we insist on being able to > take the reciprocal: > > > instance (Reciprocate b recip, Multiply a recip c) => > > Divide a b c where > > (/) x y = x * (recip y)

1 0

Rotating matrices
by Thomas Sutton 16 Jun '06

16 Jun '06

Dear list, I'm currently engaged in an attempt to wrap my head around type arithmetic. To make sure that I've understood, I plan to write a few operations on matrices a la Oleg's Number Parameterised Types. Before I get down to it, I've been making sure I know how to implement the operations (so that all I need to think about later is the type arithmetic). Today I've been looking at rotating matrices, i.e: taking a column- wise matrix and making it row-wise and, in the process, swapping the dimensions (thus a 3*2 matrix becomes a 2*3 matrix). I've been working with lists of lists for simplicity and have come up with: > rotate' :: [[a]] -> [[a]] > rotate' [] = [] > rotate' xs = (map (head) xs ):(rotate' $ filter (not . null) $ map (tail) xs) which seems to work just fine. While this solution is adequate (it seems to work for infinite structures as well, which is good), I originally set out to solve this problem with a fold or a mapAccum of some sort (I don't really care if it doesn't work with infinite structures). Can anyone suggest a way to write this with a fold (or tell me why it isn't a good idea)? Cheers, Thomas Sutton

4 3

what do you think of haskell ? (yes, it's a bit general ...:)
by minh thu 16 Jun '06

16 Jun '06

hi all folks, i'm diving into haskell for more than one year now. the reason for that is just that i like haskell. (i'm a computer science student) but i consider to move back to c/c++. here are my thoughts. i've no specific question but i'd like to have your opinion. here we go: haskell is really nice : short phrased, declarative, math-feeling, the type system ensure low bug amount (i surely forget other nice things). but haskell is quite ugly in some way : * array : if i want to write something involving array, i could use list, and a lot (too much!) of array types (io/st, mutable/immutable, c-friendly (storable). worst, code involving one type can need to be rewritten for another type. * laziness / array (again) (i am biased since i have no knowledge of haskell profiling / performance seeking) always with array code, i was forced (maybe it's because i dont know enough) to use iouarray : if not, performance|memory consumption were low|high. but with iouarray, i cant use an array of MyType; i have to use an array of (say) float (it's ok if i have only float in MyType). that kind of thing is what i think is *really* low-level. in c, i can have an array of what-i-want. * randomIO side-effect is nicely resolved with monad. and you have to thread your state. if you're writing your monad or use a transformer, things are quite explicitly (even if it's implicit in the do notation) threaded. but the threading of the randomIO argument is really not explicit for me : it just means that the underlying/threaded state in the IO monad can encapsulated a lot of things. it feels exactly like a c function. but usually, you cant design a c-like function in haskell (i.e. a function with state). * more things i dont remember... * generally my general feeling for haskell vs c is: in haskell i always have to learn new things to get my work done ; although haskell is really easy to learn in the first step, it's becoming increasingly hard to get what's the *trick* to do what i want. e.g. writing myfunction x1 .. xn | x1 `seq` ... False = undefined is not declarative (and i still have to learn to identify where it helps and where it doesn't) the c language take some more time to learn at the beginning but that's it! what you can learn by after is better c programming. there are memory management, pointers, side-effects, but you can do what you want, it behaves as expected and you dont have to learn (in a academic paper) how to use an array or how to do io. :) please don't tell me "you're stupid, go back to your c and leave this glorious mailing list" did you had the same feeling ? does it disappear ? how ? thanks a lot, vo minh thu

9 18

Everything but the lazyness - idea for force/delay lists
by Brian Hulley 16 Jun '06

16 Jun '06

Hi - I've been thinking about how to get an extremely fast language with all the benefits of Haskell ie completely pure with no side effects, but with monads, higher order functions, type classes etc, but without the lazyness. I know this is controversial, but having started to write a serious program in Haskell, I find that almost all of it doesn't need any lazyness at all, yet I have to constantly mess up my code by using Tuple2 a b instead of (a,b), ! in all my data types, and millions of brackets to use $! (which has the wrong associativity for passing multiple arguments strictly) etc and I can't do anything about the slowness and possible space leaks introduced by library functions which are lazy, not to mention the fact that afaiu the lifted type system necessary for any language which supports lazyness, and general undecidability results means that it will probably be impossible to ever compile lazy code to be as fast as OCaml etc. (This is not to say Haskell is too slow - I find the app I'm writing at the moment runs fast enough (given all my strictness annotations) it's just that lazyness is making my life more difficult rather than easier and is probably also costing something in terms of speed.) The one place where I'm using lazyness is where I need to glue the output of one computation to another by using a lazy list. In effect I'm using a lazy list as the equivalent of an iterator in C++ - the elements are only created when needed, but once read, I only read them once, so I don't need the memoization properties of lazyness. When I first started to learn Haskell, I thought lazyness was essential for monads and hence an acceptable price to pay for using them. However I now think that monads would work perfectly without lazyness, since they are usually always defined in terms of >>= (not >> as I'd thought when I didn't know Haskell). Other uses of lazyness are of course infinite structures and fixpoints etc. I think the use of a lazy list as a read-once-on-demand stream could be achieved just as easily by a strict language with some syntactic sugar by redefining the meaning of []: data GlueList a = Empty | Cons a [a] type [a] = () -> GlueList a force :: (() -> a) -> a force f = f () Pattern matching could then be changed so that p [a] = exp is short for: p x = case force x of Cons a y -> case force y of Empty -> exp and p [h|t] = exp -- Prolog style list sugar p x = case force x of Cons h t -> exp and in an expression, [exp1,...] would be expanded into the appropriate delayed construction eg: x = [a] x = \() -> Cons a (\() -> Empty) (List comprehensions could just be written using do notation). There could also be extra syntactic support for force/delay eg !exp to mean exp () and ~exp to mean \()->exp. With this extra sugar, it might be relatively painless to still use infinite data structures. Lazyness seems to sometimes be used to accomplish things that could easily be implemented in other ways, perhaps even better, and with more control (and certainly more explicitness) over the exact aspect of lazyness that is being used in a certain situation eg memoization, desugared attribute grammars, list-as-glue, etc. The advantages would be that the resulting language would be simpler to understand and could execute like lightning so there would be no need to use C or ML ever again. Afaik the full speed advantage can't be achieved just by syntactic sugar for regular Haskell since regular Haskell, even with seq etc, still needs to use a lifted type system, but syntactic sugar could certainly be used to implement such a language on top of Haskell to investigate if the complete absence of lazyness would cause any problems in practice. If I get time I might try to do this but I've shared the idea here in the vague hope someone else might want to do it first :-) There certainly seems to be a "gap in the market" between the perfection of lazy Haskell's monads, typeclasses etc and strict ML's side effects and less expressive type system. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

3 3

do we have something like isDefined or isNull in Haskell?
by Vladimir Portnykh 16 Jun '06

16 Jun '06

Suppose there is a data definition in Haskell: data MyType = MyType { date :: Double, weight :: Double, height :: Double } deriving (Eq, Ord, Show) Is it possible to check if the field height, for example, is filled in(defined)? Can we give default values in Haskell? Many thanks and sorry fro so sily questions. Vladimir _________________________________________________________________ The new MSN Search Toolbar now includes Desktop search! http://join.msn.com/toolbar/overview

5 5

Learning C after Haskell
by Chad Scherrer 15 Jun '06

15 Jun '06

Ok, so I'm doing things somewhat backward. I've been using Haskell for a while now, whenever I get a chance to. But in order to become more involved in high-performance computing projects at my work, I need to learn C. I've heard a lot of people say that experience in Haskell can improve one's abilities in other languages, but I also wonder how different the C "way of doing things" is different from Haskell's. My question is, as I learn C, are there any particular Haskell concepts I should keep in the back of my mind, or is it better to approach C from scratch? Thanks in advance! Preparing for a foot-shooting, Chad

4 4