- Beginners - Haskell.org

Tyepclasses and creating 'Num' instances
by Stuart Hungerford 23 Feb '15

23 Feb '15

Hi, Many thanks to everyone who responded to my earlier question about hierarchies of typeclasses. I have a followup question regarding creating instances. Suppose I have this additive semigroup typeclass: class (Num a) => AddSemigroup a where (|+|) :: a -> a -> a (|+|) = (+) I'd like to make 2-element tuples instances of AddSemigroup, provided their elements are: instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) GHC says it "Could not deduce (Num (a, b))" in this situation, which seems fair enough so I tried: instance (AddSemigroup a, Num a, AddSemigroup b, Num b) => AddSemigroup (a, b) With the same result. Separate instances seem to work though: instance (Num a, Num b) => Num (a, b) instance (AddSemigroup a, AddSemigroup b) => AddSemigroup (a, b) At this point I feel like I must be duplicating instances that are provided in a standard way in the prelude somewhere, or more likely I've misunderstood the ideas around creating instances? Any advice much appreciated, Stu

3 2

how to check the format of a string ?
by Roelof Wobben 22 Feb '15

22 Feb '15

Hello, Im still busy with CIS 194 Now im facing this problem. There is a log file of strings. Most of them are of this format char Number [chars] What is the best way to check if the string has this format ? Regex or another way ? Roelof

4 6

Re: [Haskell-beginners] Hello + Testing Framework
by Michael Orlitzky 22 Feb '15

22 Feb '15

On 02/22/2015 11:26 AM, fr33domlover wrote: > > In the cabal user guide I read about the test-suite type "detailed-0.9" being > preferred for new projects. Later after choosing Tasty I started adding basic > support to my dummy project, and in the cabal integration section I see it says > to use the older "exitcode-stdio-1.0". > > I also don't see a clear way to use detailed, because Tasty supplies its > "defaultMain" function meant to generate an executable. But I just tool a brief > look, not touched internals of Tasty at all. > No one uses the detailed-0.9 interface, and there's not a single working example anywhere so no one ever will. Just stick with exitcode-stdio-1.0 and tasty (which works great, by the way). The recommendation in the users guide is wishful thinking.

1 0

Hello + Testing Framework
by fr33domlover 22 Feb '15

22 Feb '15

First of all, hello! I'm a fresh Haskell beginner and this is my first message to Haskell MLs. I recently began a tiny dummy project. Its code is minimal and its purpose it to help me learn all the common developer tasks that aren't coding: debugging, releasing, testing and so on. Especially organizing the project repository, before I start "real" things. My first problem was choosing a test framework and integrating it with `cabal test`. There's a lot of info, sometimes contradicting due to changes in recent years. Anyway I'll just blog about this later and now get to the point. I chose Tasty as my test framework. In the cabal user guide I read about the test-suite type "detailed-0.9" being preferred for new projects. Later after choosing Tasty I started adding basic support to my dummy project, and in the cabal integration section I see it says to use the older "exitcode-stdio-1.0". I also don't see a clear way to use detailed, because Tasty supplies its "defaultMain" function meant to generate an executable. But I just tool a brief look, not touched internals of Tasty at all. The question: Should I use deatiled-0.9? If yes, how? Or should I just use exitcode-stdio-1.0 as the Tasty manual says? Thanks in advance! --- fr33domlover <http://www.rel4tion.org/people/fr33domlover> GPG key ID: 63E5E57D (size: 4096) GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D

1 0

Fwd: tower hanoi problem
by Joel Neely 22 Feb '15

22 Feb '15

I personally find the assertion more confusing than helpful. Interpreting a pattern of "x:xs" as "acknowledging the base case" by eliminating it first reads to me as a double negative: "if it is not the case that this list does not have a first element" or some such. I simply prefer to read it as a positive assertion: the list has a head, and here's what to do with it. To my eye, this also scales nicely when there are multiple terminal cases. Here's a tiny example. Given a list of fractional numbers, produce a smoothed list, where each value is averaged with its immediate neighbors (except the first and last, which fail to have both neighbors), as shown below. [0.0,4.0,2.0,6.0,1.0,2.0] [ 2.0,4.0,3.0,3.0 ] It seems natural to my eye to express this as, "A list with at least three elements contributes a value to the result", as in: smooth :: Fractional n => [n] -> [n] smooth (a:z@(b:c:_)) = (a + b + c) / 3 : smooth z smooth _ = [] I prefer this to the alternatives (at least the ones that I came up with) that either explicitly compute the length to compare it to 3, or that explicitly fret over the (multiple!) cases that terminate the recursion. smooth' :: Fractional n => [n] -> [n] smooth' [] = [] smooth' [_] = [] smooth' [_,_] = [] smooth' (a:z@(b:c:_)) = (a + b + c) / 3 : smooth' z I don't care for having to wade through three terminal cases to get to the one that interests me, for multiple reasons: - It strikes my eye as visual noise that offers no useful information compared to the first (shorter) solution. - Depending on the intelligence of the compiler, it may waste run time by testing for cases that will only be true near the end of a long argument list. - I can argue termination by observing that the recursive evaluation (smooth z) is made on a shorter argument. - In a lazy language, termination may not be an issue! Evaluating *Main> take 10 $ smooth [0,1..] [1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0] works just fine without smooth having to arrive at the end of its argument. Again, tastes may vary. I haven't thought of a way to do this with a fold or comprehension that seems as clear to me. I would be interested in seeing such a solution if someone else sees a way to do it. -jn- ---------- Forwarded message ---------- From: Dudley Brooks <dbrooks(a)runforyourlife.org> Date: Thu, Feb 19, 2015 at 9:48 AM Subject: Re: [Haskell-beginners] tower hanoi problem To: Joel Neely <joel.neely(a)gmail.com> And to clarify my point, I would say that mathematically you do always have to "take care of" (worry about) the base case first ... and you did! And in the code, not just in your thinking: Using "x:xs", rather than "(head xs)", in the first line acknowledges the base case by making sure to eliminate it first -- "x:xs" works precisely because it doesn't separate the *concerns*; it contains an implicit "if this is not the base case". What it does (why it's useful syntactic sugar) is let you separate (and reorder) the *actions*. A guard using "x:xs" does not actually have the very clean SOC which you recommend, with the result that the concept "base case" is actually represented in *two* places in your code. Question: Could you write it without the first line using "x:xs" or some other construction which has an implicit "if this is not the base case"? Probably yes ... probably some kind of "where" clause might put it typographically at the end. But that would be because Haskell's interpreter/compiler executes the test in the "where" clause first. Checking whether we're looking at the base case would still be the first major execution step. I suspect that there's no way to escape that ... the most that can be done is to "look like" you're escaping it. On 2/19/15 4:47 AM, Joel Neely wrote: Just to clarify the point of my earlier comment... I suggest that the "separation of concerns" (SOC) principle has many applications. A common use shows up in the advice to represent each distinct concept exactly one place in the code, and to do so in a way that supports orthogonality (the freedom to mix-and-match). In this case, I used it to separate the thought process of designing the code from the lexical layout of the code. I have no business legislating the order in which someone else thinks about the cases (sometimes more than two!) encountered in decomposing a problem. However, in my experience, the order in which I think about parts of the code, and the order in which they are laid out in the source file, are separate concerns. And I have often found it useful to consider them separately. For example, in some problems (and language implementations) it may help performance to ensure that the most frequent case is considered first, especially when there are multiple cases to consider or when the distinguishing conditions are costly to evaluate. I find that making my guards (conditions) explicit allows me the freedom to order the alternatives in whatever way I find useful, without having to worry about introducing a defect in the code. Incidentally, I also find it interesting to see the subtle effects that our terminology has on the way we approach problems. Thinking of a list as "it may be empty or not" takes my thoughts in a different direction than if I think "it may have a head or not". By all means, think about your recursive functions any way you wish! Just please don't tell me that I must place them is a specific order in my code. Regards, -jn- On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks <dbrooks(a)runforyourlife.org> wrote: > On 2/18/15 5:29 PM, Mike Meyer wrote: > > On Wed, Feb 18, 2015 at 7:16 PM, Dudley Brooks < > dbrooks(a)runforyourlife.org> wrote: > >> Hmm. Well, I'd say that that's a feature of, specifically, Haskell's >> pattern-matching strategy and list-description syntax, rather than of >> recursion in general or the structure of this particular problem. In other >> languages with recursion you might have no choice except to start with the >> base case, even for this problem, or else you'd get the same kind of error >> you mention below (depending on the language). I think it's good when >> you're *learning* recursion to always start with the base case(s). >> > I disagree that this is a Haskell-specific feature. Any else-if like > structure will have this property, no matter what language it's in. That > Haskell provides a syntax as part of the function declaration is special, > but that doesn't let you avoid the else-if construct when the problem > requires it. > > I don't understand. I don't believe I said anything about avoiding > else-if, or about not avoiding it. But I'm not quite sure what you mean. > Are you referring to > > if condition1 > then instruction1 > elseif condition2 > then instruction2 > > ? > > But what is condition1? Wouldn't it probably be the base case, and > instruction1 the procedure on the base case? > > Is there something special about "elseif" that guarantees that > instruction1 *before* it won't crash if condition1 isn't the base case??? > I'm probably totally missing your intention here. > > But anyway, isn't it actually just Haskell's syntax "x:xs" that lets the > pattern be tested and bypassed without crashing on an empty list, so that > it *can* fall through to the base case at the end? If Haskell only had the > syntax "(head xs), then that *would* crash on the empty list if the empty > list had not previously been taken care of as a base case, as Joel Neely > pointed out. > > I didn't mean that *no* other language might have such a syntactical > construction. (I didn't mean "specifically Haskell", I meant "specifically > the pattern matching". Sorry about the ambiguity.) So if some other > language has such a construction, then it's still the *syntax* that lets > you cheat on the base case; it's not the structure of the problem itself > nor the basic underlying notion of recursion. > > I would also argue that in Mr Neely's first example, while the *explicit* > base case [] is at the end, nevertheless the first line still *implicitly* > refers to the base case: pattern matching on "x:xs" says "*if* the data > has the structure x:xs", i.e. "if it is not a bunch of other stuff ... > including *not the empty list*!)". Certainly you couldn't merely do the > recursive step first without a condition like this particular one. The > reason this syntax *seems* to let you avoid thinking about the base case > first is because secretly it says "only try this step if we're not looking > at the base case"! > > It may be my fondness for proof by induction, but I think doing the base > case first is a good idea for another reason. The code for the recursive > cases assumes that you can correctly handle all the "smaller" cases. If > that's wrong because some assumption about the base case turns out to be > false when you actually write it, then you have to rewrite the recursive > cases for the correct base case. So it's better to make sure your base case > is going to work before you start writing the code that's going to use it. > > I was a math major, not a CS major, so I'm also prejudiced in favor of > base case first. And, as stated above, I think we *are* actually > *considering* the base case first! (We're merely putting off telling what > to *do* with that base case.) I think that the "syntactic sugar" of some > languages obscures (intentionally, for purposes of convenience) what's > really happening mathematically. > > > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato -- Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato

3 3

Re: [Haskell-beginners] How to manage typeclass hierarchies and instances?
by Stuart Hungerford 22 Feb '15

22 Feb '15

>> -- in Semigroup.hs >> >> class Semigroup a where >> (|.|) :: a -> a -> a >> >> instance Semigroup Integer where >> (|.|) = (+) >> >> >> -- In Monoid.hs >> >> class (Semigroup a) => Monoid a where >> identity :: a >> >> instance Monoid Integer where >> identity = 0 >> >> >> -- In Group.hs >> >> class (Monoid a) => Group a where >> inverse :: a -> a >> >> instance Group Integer where >> (|.|) = (+) >> identity = 0 >> inverse = (-) >> >> >> In Group.hs I'm trying to create an (additive) group instance for >> Integer values but GHC complains that (|.|) and identity are not >> "visible" typeclass methods. > > You only get one instance per type, so the Semigroup/Monoid instances > for Integer are "set in stone." When you "import Semigroup" and "import > Monoid", those instances come into scope. So in Group.hs, '|.|' and > 'identity' are already defined for Integer. All you need is, > > instance Group Integer where > inverse = negate Thanks for that insight. Ignoring the instance issue for a minute, suppose I wanted to define a typeclass Additive where I'd like to set default implementations for the methods: class (Num a, Group a) => Additive a where (|.|) = (+) -- etc... In this situation GHC says (|.|) is not a visible method. If I add a type declaration for (|.|) am I effectively "shadowing" the method from Semigroup with a new method rather than supplying a default implementation? Thanks, Stu

4 4

How to manage typeclass hierarchies and instances?
by Stuart Hungerford 20 Feb '15

20 Feb '15

Hi, I'm experimenting with Haskell typeclasses and could do with some advice on managing superclasses and instance declarations. Suppose I have these modules (please ignore any misunderstandings of abstract algebra concepts): -- in Semigroup.hs class Semigroup a where (|.|) :: a -> a -> a instance Semigroup Integer where (|.|) = (+) -- In Monoid.hs class (Semigroup a) => Monoid a where identity :: a instance Monoid Integer where identity = 0 -- In Group.hs class (Monoid a) => Group a where inverse :: a -> a instance Group Integer where (|.|) = (+) identity = 0 inverse = (-) In Group.hs I'm trying to create an (additive) group instance for Integer values but GHC complains that (|.|) and identity are not "visible" typeclass methods. I understand that if I explicitly recreate Semigroup and Monoid instances for Integer in Group.hs it will fix the visibility issue--at the cost of duplicating the instances already defined in Semigroup.hs and Monoid.hs. I'm starting to wonder whether it's a good idea to create typeclass instances in the same modules as the typeclass definitions? In my case I could create a separate Instances.hs with the instance declarations but how do Haskellers generally handle this situation? Thanks, Stu

2 1

pattern matching on strings ?
by Roelof Wobben 20 Feb '15

20 Feb '15

Hello, Im try to the solve the exercise which does the following : "E 2 562 help he and convert it into (Error 2) 562 "help help First I thought to split the string on the " " but according to google Haskell do not have a split function. Can I use pattern matching on some way ? Roelof

6 6

Re: [Haskell-beginners] tower hanoi problem
by Doug McIlroy 19 Feb '15

19 Feb '15

On 2/19/15 4:47 AM, Joel Neely wrote: > Incidentally, I also find it interesting to see the subtle effects > that our terminology has on the way we approach problems. Thinking of > a list as "it may be empty or not" takes my thoughts in a different > direction than if I think "it may have a head or not". A telling aphorism. It will stick with me for a long time. Regarding the problem that sparked this discussion, Hanoi: if you think first about the base case, it's likely to be this: to transfer a oone-disc pile from A to B using C as an intermediate, move A to B. If you think first about the recursive step, you'll likely come up with a different base case: to transfer zero discs, do nothing. With this insight, you've generalized your original understanding of the problem. Doug

1 0

function to read file and return list of contents not compiling
by Geoffrey Bays 19 Feb '15

19 Feb '15

Haskellers: I want to write a function that takes a class name and reads from a file and then returns the list of String of the file lines. I have experimented with various return types, but GHC does not like any of them. Here is my function: readData :: String -> IO String -- what type here?? readData classNameP = do let fileName = classNameP ++ ".txt" contents <- readFile fileName lines contents Not to complain, but this would not be difficult in any other language I have tried, so I could use some explanation. I suspect it has to do with understanding the IO Monad. Many Thanks Geoffrey

2 3