> 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,
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
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 --
Hi,
>> I am looking for help in design of a stateful tree walker.
>
> I think that you can use Data.Traversable to great effect.
thanks, the advice has helped. I can't use it directly since i didn't yet come
up with a consistent solution to serialization of events, but I am going to
compile the
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
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 righ
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
ou 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
___
Haske
--- 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
> I think you, and probably Marc Weber as well, are confusing what a
> constraint on a class head means. Suppose you have:
>
> class Monad m => Foo m
>
> That constraint means that every instance of class Foo must also be an
> instance of class Monad. So, as I explained in my email to Marc, we
>
> HTH.
>
Hi David,
how is this different from inferring that if a type variable is an instance of
class it is subject to constraints imposed on the class?
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/li
>> 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
12 matches
Mail list logo
