- Beginners - Haskell.org

Re: [Haskell-beginners] Functions as containers; implications on being a Monad ((->) r)
by Alex Belanger 04 Jun '16

04 Jun '16

Does it help if I bring your: (\x -> x+7) <$> (+3) => (+10) It doesn't magically become `(+10)`. The previous step unseen is `(+7) . (+3)`. fmap for ((->) r) is defined as function composition `.`. fmap f g = f . g You can think of functors as containers or contexts; both analogies work well up to some degree (with the latter maybe more abstract and thus flexible). Another small terminology tip that could help you with your thinkering might be to call ((->) r) a partially applied function. Suddently, it narrows how you can potentially use/combine them. Last tip, Monad ((->) r) is commonly refered to as the Reader monad. Example of how it'd be used: doThings = do a <- (*2) b <- (+10) return (a + b) Notice how we can work with partially applied functions to which something have yet to be applied and create a new partial function whose argument is going to fill all the open holes. This isn't easy to explain without looking at the types of everything, so I encourage you to write it down and work out the types (: Alex On Jun 4, 2016 12:41 AM, "Raja" <rajasharan(a)gmail.com> wrote: Everyone agrees ((->) r) is a Functor, an Applicative and a Monad but I've never seen any good writeup going into details of explaining this. So I was trying to brainstorm with my brother and went pretty far into the concept for quite a few hours, but still got stuck when it came to Monads. Before I showcase the question/problem I wanted to share our thinking process. Lets stick with common types like Maybe a, [a], simple function (a -> b) **Everything is a Container** Just 4 => this is a container wrapping some value [1,2,3] => this is a container wrapping bunch of values (+3) => this is a container wrapping domains & ranges (infinite dictionary) **When is a Container a Functor** If we can peek inside a container and apply a simple function (a->b) to each of its values and wrap the result back inside the container, then it becomes a Functor. Let's use (\x -> x+7) as simple function along with above three Containers (\x -> x+7) <$> Just 4 => Just 11 (\x -> x+7) <$> [1,2,3] => [8,9,10] (\x -> x+7) <$> (+3) => (+10) -- well there is no Show defined but you get the idea **When is a Container an Applicative** The simple function from above is also now wrapped inside a container and we should be able to peek to use it just like functor. Also lets simplify (\x -> x+7) to (+7). Just (+7) <*> Just 4 => Just 11 [(+7)] <*> [1,2,3] => [8,9,10] (\x -> (+7)) <*> (+3) => (+10) -- again no Show defined but works when pass a number -- but (+7) still needs to be wrapped in a Container though **When is a Container a Monad** This time we don't have a simple function (a->b) instead we have a non-simple function (a -> Container). But rest stays almost the same. We have to first peek inside a container and apply non-simple function to each of its values. Since its a non-simple function we need to collect all the returned Containers, unwrap them and wrap them all back in a Container again. (it almost feels like unwrap and wrapping them back is going to complicate things) Also Non-simple function cannot be reused as is for all three Containers like in Functors & Applicatives. Just 4 >>= (\x -> Just (x+7)) => Just 11 [1,2,3] >>= (\x -> [x+7]) => [8,9,10] (+3) >>= (\x -> (+7)) => (+7) Wait a minute ... the last line doesn't look right. Or should I say it doesn't feel right to discard the `x' altogether. OK let's jump to do this: (+3) >>= (\x -> (+x)) => ??? -- apparently this solves for the equation: f(x) = 2x + 3 (is 2x + 3 obvious for anyone??? it took us way longer to derive it) (Does it have anything to do with Monad laws by any chance?) This is where it feels like "Functions as containers" concept starts to breakdown; its not the right analogy for Monads. What does it even mean to unwrap a bunch of functions and wrap them back again? Hope this intrigues some of you as it did to us. Any thoughts and comments greatly appreciated. Thanks, Raja _______________________________________________ Beginners mailing list Beginners(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

1 0

help on writing a typeclass
by Silent Leaf 04 Jun '16

04 Jun '16

I got a function, named mdk (don't ask). It happens it's a method of a class, as follows: class C a where mdk :: C b => a -> b -> (a, b) yet i got another function, called so far mdk' mdk' :: C b => b -> a -> (a, b) Say there are the following instances: instance C X where mdk x b = ... :: C b => (X, b) mdk' b x = ... :: C b => (X, b) instance C Y where mdk y b = ... :: C b => (Y, b) mdk' b y = ... :: C b => (Y, b) if you get what's happening, mdk and mdk' are basically the same method, save for the final type-result, which is reversed, without data loss mind you (aka (A, B) and (B, A) could be the same type, if only i knew of a way to make a type in haskell without forcing the order (a kind of set or something). so, there are four cases: input have types, in this order, X and Y, and expected output is (X, Y): then mdk from X's instance of C is called/must be used; input have types Y and X, output (X, Y): X's mdk' input X and Y, output (Y, X): Y's mdk input Y and X, output (Y, X): Y's mdk' it might seem confusing, but all amounts to the issue that even though (Y, X) is strictly equivalent, in my program, to (X, Y), in principle haskell differentiate the types. thus i have to write two versions of mdk for each type, even though the methods "X's mdk" and "Y's mdk'" are identical, and same for the two other methods. indeed: mdk :: C b => X -> b -> (X, b) mdk' :: C b => b -> Y -> (Y, b) are identical signatures, if in the first one you replace `b` with Y, and in the latter you replace `b` with X, and ofc if you consider (X,Y) == (Y,X). only one of those two methods should be enough to handle the job, and be chosen by the compiler on the sole value of the type of the first variable; but the fact both methods return tuples of "mirrored" types, crushes that. if i only write `mdk` instances, as soon as the compiler will meet this following signature: mdk :: a -> b -> (b, a) it will crash an exception, because mdk's original signature has for output value a tuple whose first type should here be `a`, because it's meant to be the type of the first argument, not the second. thus, at last my question: can i tell the compiler to consider (b, a) and (a, b) as identical types (don't worry it's not really a tuple in my program, but it's equivalent)? if not, can i make an overloading of mdk so it accepts both a->b->(a,b) and a->b->(b,a)? hope i didn't lose anyone. if so, do tell me, i'll try to clarify. thanks in advance of the time spent trying to understand my problem!

2 2

"type" declarations: utterly transparent synonyms?
by Silent Leaf 03 Jun '16

03 Jun '16

I'd like to be sure when one defines a type with "type", it truly merely creates a synonym, and no matter what one could replace the left side by the right side in the whole program, and vice versa, and it wouldn't change a thing in the actual meaning, value of the program. Eg if i define: type In2 t = t -> t -> t I can thereafter replace for any type t, any signature like f :: t -> t -> t with f :: In2 t then strictly no consequence other than visual in the source code, by me, will occur. Thanks!

3 3

why is there no typeclass common to all containers?
by Silent Leaf 03 Jun '16

03 Jun '16

All in the title. I haven't used them much, but I saw Map or Vector types were forcing the user to use qualified functions unless you want nameclash with the more basic, typically list-oriented functions. So, why not have a massive, general purpose interface so the type only can separate between containers --which would allow for cross-container polymorphism, i suppose, more easily, even though it's not necessarily the most widespread need. So, do i miss something? Is there in fact a class of that kind? If so why not? Thanks in advance! :)

6 9

documenting individual method arguments with Haddock
by Patrick Pelletier 28 May '16

28 May '16

In Haddock, individual function arguments can be documented like this: f :: Int -- ^ The 'Int' argument -> Float -- ^ The 'Float' argument -> IO () -- ^ The return value Since a typeclass method is very much like a function, I assumed I could document individual arguments of methods the same way. For example: -- | Class representing a connection to a collection of bulbs. -- In the case of a LAN connection, this would be all bulbs on the LAN. -- In the case of a cloud connection, this would be all bulbs associated -- with the cloud account for a particular access token. class Connection t where -- | Retrieve information about some or all lights. Corresponds to -- <http://api.developer.lifx.com/docs/list-lights List Lights> endpoint. -- Beware that on a @LanConnection@, it takes time for lights to be -- discovered, so the list of lights will be empty immediately after -- the connection is created. listLights :: t -- ^ The connection. -> [Selector] -- ^ The lights to list. -> [InfoNeeded] -- ^ A hint about what information is desired -- in the results. This hint is used -- by @LanConnection@, but is ignored by -- @CloudConnection@. -> IO [LightInfo] However, when I generate documentation (using Haddock 2.17.2, via "stack haddock"), the text "A hint about what information is desired" doesn't appear anywhere in the generated documentation. Is there a way I can include this sort of per-argument documentation for my typeclass methods? Thanks, --Patrick

1 0

Re: [Haskell-beginners] How to best handle classes of types, interactions and listing of different types?
by Alex Belanger 26 May '16

26 May '16

Monoid would fit the picture as far as "concatenating" the same type go. What you could do is have constructors that defines which types can be concatenated together then only that wrapper type implements the final Monoid instance. On May 26, 2016 9:44 AM, "Silent Leaf" <silent.leaf0(a)gmail.com> wrote: I understand your example. Still it's useless if we need the value of the multiplied vectors, more than just a list of their lengths after the operation, unless i missed something. At any rate; I'm trying to create a representation of mathematical sets. The tricky part being, they're precisely capable to handle any kind of content, including themselves. But I think I went too overboard, trying to handle the idea of sets that could contain strictly any type (at once). In practice, the basic elements will be rather similar, and known enough at least so that I can merely use ADTs for the various "types" of elements, and same for sets themselves. If needed I can create two instances of monoids, one for And, one for Or, using newtype wrappers. It's vaguely a hassle but anyway it'll only be useful if i have to create functions that could work on both monoids (separately), which would be interesting enough so i don't merely duplicate the job. There's also the possibility i need to use existing functions already using monoids... For now I think i'll be ok with ADTs and one common wrapper for all elements. Thanks still, I'll think about your idea, it's rather interesting. Le mardi 24 mai 2016, Daniel Bergey <bergey(a)alum.mit.edu> a écrit : > On 2016-05-23 at 12:06, Silent Leaf <silent.leaf0(a)gmail.com> wrote: >> Say there's a class, many types that can instantiate it. Then, i in fact need to be able >> to concatenate (mappend would be ideal!), make lists of values of different types, all >> instantiating the class. > > In most cases, when Haskell beginners want to make a list that contains > several types from a single type class, there's a better way to organize > the code. If you post your code, I'll try to suggest a specific > solution. > > In general, try to find a simple data type that captures the same fields > & functions as an unknown type that is part of the type class. Here's > an example. > > We have a type class for vectors in a metric space, and instances for > 2D, 3D, etc. > >> class Metric v where >> length :: v -> Double >> (*^) :: Double -> v -> v > > This class has the law: s * length v == length (s *^ v) > > Instead of a heterogeneous list [ V2 1 2, V3 3 4 5, V4 6 7 8 9], we make > a list that just has the length of each vector, and lets us multiply > those lengths by a scalar. In this case, we don't even need to write a > new data type, the type is simply Double. We can write: > >> [ length (V2 1 2), length (V3 3 4 5), length (V4 6 7 8 9) ] > > And (*) gives us what Metric does with (*^). Of course, with your > class, it's probably not so obvious how to transform the class this way. > > It's certainly possible to make a record with functions as members, > moving in the object-oriented direction. Existential types (with a > class constraint inside the data constructor) are even more rarely used. > > cheers, > bergey > _______________________________________________ Beginners mailing list Beginners(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

2 1

How to best handle classes of types, interactions and listing of different types?
by Silent Leaf 26 May '16

26 May '16

Hi! I'm still studying the theory of Haskell, but i also wanted to start dabbling with guideless coding, all by myself, and it happens experience is just as much important as theoretical knowledge! I'm not surprise mind you :P Say there's a class, many types that can instantiate it. Then, i in fact need to be able to concatenate (mappend would be ideal!), make lists of values of different types, all instantiating the class. I'm a bit lost on this. There are at least two sorts of ways to handle said group of types, but i'm not certain either is best, and i'm not even very much satisfied about either. Plus they don't specifically differ as regards handling of listing or otherwise interacting *between* different instances of the same class (or alternately, different types born from the same Type constructor). First idea i had, was based on making a class indeed, as well i just love this type of polymorphism (visavis other paradigms). Each type would only have to instantiate the key metshods, and no need of wrappers to use said methods, so on this respect it's pretty great. However, as soon as we want operations between values of different types, it rather gets tricky. The only way i know of to make a heterogeneous list is to use ExistentialQuantificators, create a newtype (or data?) wrapper for the class, allowing for any type to be in, without parameters. Now, the problem i have with this, is the wrapping: if i wanna make a list of types, i gotta wrap all values, and if this list becomes member of a superlist of the same polymorphic type, i gotta wrap this very sublist again with the "class wrapper". Maybe i'm imagining problems and i won't actually need to touch too much to the wrapping if i write the correct functions or instances, but from where i am, permanent wrapping seems tiresome, very much in fact removes the purpose of a class: to allow polymorphic functions without need to wrap the types of inputs/outputs inside a newtype. Which lead me to the second solution: forget the class, and make a type constructor that basically gets a list of key-methods and one field for the wrapped type. Basically it amounts to OOP, at least it seems so. I'm not really a big fan of the thing, and eventually i realized it wouldn't help me more visavis trans-type methods, especially an idea of one or more monoidal instances for the class, or the type constructor that replaces it. (Actually I'm not wholly certain as of how I'm supposed to handle Type constructors instead of classes, as I only know how to make heterogeneous out of a class, not out of a type constructor, even if its polymorphic key-methods are fields included in it. (hope i'm being clear enough, don't hesitate telling me otherwise!) So, as I'm kinda beginner as regards actual coding, i'm asking advice on the subject. Maybe the problem is in how i look at the problem, and I shouldn't even be there trying to do what i try to do. Any alternative solution or viewpoint is heartily welcome! I resume my problem once more: how to handle cross-type interactions and grouping when they only have a class in common, and if possible without having to use ExistentialQuantificators, unless there's a way to keep the wrappers far away, invisible, automatic. Thanks a lot in advance! (Ideas of specialized tutorials are also very much welcome!)

3 4

All About Monads
by Cezar Elnazli 23 May '16

23 May '16

Hello, I am currently going through "All About Monads" on the Haskell Wiki. I see that it also has a Github repository[1]. However, the repository seems outdated to the point where the Makefile no longer works (I was not able to build the wiki), some (if not most) of the examples no longer compile, or they do so with warnings (e.g. example12.hs), and even the formatting of the published article on the wiki seems broken. What I'm asking is if the repository I mentioned is the correct one, and if it makes any sense to send a pull request or if it is worth the effort to fork it and update the code. Thanks! [1]: https://github.com/dag/all-about-monads

2 1

Code golf
by Tilmann 21 May '16

21 May '16

given: inputA :: IO String inputB :: IO String update :: String -> String -> IO () Is there an elegant way to refactor / code golf this: doIt :: IO () doIt = do a <- inputA b <- inputB update a b liftM2 doesn't work in this case.. Thank you!

4 8

How to write console apps? Can't find any library, tutorial... at all
by Silent Leaf 20 May '16

20 May '16

All in the title! I'm seeking a way to write a console app that isn't just asking questions one line after another with putStr and getLine. More something like Vim or Emacs when they're in the terminal (i don't wanna create a text ed, but it's the kind of programs i'm seeking to write: which takes up all the space on the screen, where you can write at many different places, and keyboard-driven, up to why not mouse- too, if the terminal (and haskell bindings) allow it. So, does anyone know any library to do this? Any tutorial, maybe? I'm seeking for hours, but every time i type stuff like "console application haskell" in google, it just gives me irrelevant answers --as is the trend it seems subjectively, of those last months, with our bestest G-friend. :( thanks a lot in advance for anything!

5 6