Re: [Haskell-cafe] Newbie list question
type Person = (NI, Age, Balance) type Bank = [Person] credit :: Bank - [Person] credit [(a,b,c)] = [(a,b,c)] if c = 0 then [(a,b,c)] else error overdrawn customer except this doesn't work with things like: credit [(1,2,3),(4,5,6)] Hi, that's because Haskell syntax is made for brains with high modality. When you declare a type, writing a type signature in square brackets make it to be a list of arbitrary number of elements of the inner type; when you write a pattern, one with an element in square brackets matches a single-element list. What you want is to credit abcs = filter (\(a,b,c) - c=0) abcs And if you think it looks like a machine-level assembly language, then you are probably right. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Perl is more learnable than Haskell
If you first language is LISP probably you find easy Haskell and difficult pearl. Hi, my first programming language is lisp (that is, the language I am most fluent in -- recently Common Lisp, earlier Scheme) and I find Haskell a problematic programming language (this is a fresh experience -- I am writing a syndrome-networks based DSS in Haskell now) because it is not a language. Lisp is a language and Haskell is not, in the sense that lisp allows to write programs that can be read aloud and understood from reading the code. Haskell is a notation that is not a literature by itself, and for Haskell, literate programming, that is, writing more comments than code, is a must; while for lisp it is a rather exotic practice. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Perl is more learnable than Haskell
Hi, I'm guessing you're not doing it the right way. cvs -d :pserver:[EMAIL PROTECTED]:/srv/CVSROOT co SYRENE/src By using types, you implementation becomes a lot more readable. Being readable is not enough for being readable aloud. And I think a lot of people here will disagree with you... That's good news. I would not bother to express my option if I thought that there would not be a lot of people who would disagree. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] stateful walk through a tree?
Hi, I am looking for help in design of a stateful tree walker. I have a tree-like data structure (an AST for a small language) for which there is a general stateful walk procedure. That is, each node type is an instance of a walker class, and the walk function is monadic: class Walker a where walk :: a - State Context b The context is used to store names in the scope, for example. Now, I'd like to use Walker as a general class for implementing several different transformations on the tree (like cross-referencing, code emission, tree visualisation). Those transformations will need expanded state. What is the proper design for that? In Common Lisp, for example, I would Context to contain an opaque slot (visitor), and would assign additional state information to it; a would also define a generic function that would dispatch on the visitor (and probably on walker if I end up having more than one walker). How would I do that in Haskell? I'd like to avoid using mutable variables for now (mostly for didactic puproses). David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Why do I have to specify (Monad m) here again?
which would't hurt if GHC would infer m beeing a monad automatically? it is more explicit. for example, this simplifies understanding of error messages generated by compiler. and, if you change 'class' declaration, this will not silently change meaning of 'instance' declaration Hello Bulat, do you mean that the fact that one must keep class and instance declaration in agreement manually is an advantage and not just a limitation of the Haskell type system? Why then not just require that all constraints be declared explicitly. The following code compiles: is it a bad thing that it does? class (Eq a) = Eql a where (=:=) :: a - a - Bool x =:= y = x == y eql :: Eql a = a - a - Bool eql x y = x == y David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: Re: Re[2]: [Haskell-cafe] Why do I have to specify (Monad m) here again?
--- Forwarded message --- From: David Tolpin [EMAIL PROTECTED] To: Sebastian Sylvan [EMAIL PROTECTED] Cc: David House [EMAIL PROTECTED], haskell-cafe@haskell.org Subject: Re: Re[2]: [Haskell-cafe] Why do I have to specify (Monad m) here again? Date: Sun, 18 Feb 2007 23:38:59 +0400 Why the compiler cannot infer class constraint on m from class definition in instance definition while it can in function type definition? But it can't! If you give a type to a function, it will assume zero class constraints unless you specify them (just like it will when you give a type to an instance declaration). If you do something like: Hi Sebastian, it is not the example I brought. In the example I brought I showed how in function type declaration assertion that an instance of a class is also an instance of the other class is used. Take a look at my example. According to what part of the type system logic type inference in instances is not implemented? David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Why do I have to specify (Monad m) here again?
That's completely different. The class in that case guarantees that the type has an Eq class, so it's okay to use the functions in the Eq class. You're using the guarantees supplied by the class. When you write instances, it's the other way around, the class has *requirements* that you must fulfill -- and there are multiple ways of doing it (Haskell won't guess, it will obey what you tell it -- if you don't give any class constraints it won't assume that they are there). Hi Sebastian, could you please point me to a reference (paper/note/something else) that explains that class constraint in a class definition is a guarantee with regard to a type declaration but a requirement with regard to an instance declaration? David Tolpin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Why do I have to specify (Monad m) here again?
On Mon, 19 Feb 2007 00:30:47 +0400, Sebastian Sylvan [EMAIL PROTECTED] wrote: Well, I guess the H98 report would be a good start. But there are multiple tutorials on type classes that will cover this, most of which are available from haskell.org Sebastian, I did read H98 and would like an exact reference. The key point is that Haskell won't guess, and in particular it won't contradict what you tell it. I think that's the major flaw in your reasoning, you expect Haskell to take an explicit type that you, the programmer, supplies, and change it into something else. Why is this rule applied differently to type declarations and to instances? In the original example you are explicitly telling Haskell that m is *not* in the Monad (or any other) class. I am not telling that. I am telling that m is an instance of a class all instances of which are in the Monad class. How is this different from specifying class constraint in type declarations? David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Summarize of Why do I have to specify (Monad m) here again?
On Mon, 19 Feb 2007 02:17:34 +0400, Marc Weber [EMAIL PROTECTED] wrote: Thanks for all the feedback. It did help me a lot. Now I know that if there is something left to discuss the topic should be: Would it make sense to specify partial type declarations ? I don't need an answer right now. Hi Marc, no, it wouldn't. It would make sense to draw the arrow in the class definition in the opposite direction. It does not point in the direction it should in the class case. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
