Re: Eq instance for (a,b,c,d,e) and upwards
Olaf Chitil writes: > > I think that this discussion about tuples shows that there is a problem > with the Haskell 98 report which should be corrected. I hope Simon > accepts it as a minor bug fix. > > 1) The current wording of paragraph 6.1.4 is highly ambigious. > > > 6.1.4 Tuples > > > >Tuples are algebraic datatypes with special syntax, as defined > >in Section 3.8. Each tuple type has a single constructor. There > >is no upper bound on the size of a tuple. However, some Haskell > >implementations may restrict the size of tuples and limit the > >instances associated with larger tuples. The Prelude and libraries > >define tuple functions such as zip for tuples up to a size of 7. All > >tuples are instances of Eq, Ord, Bounded, Read, and Show. This may be nitpicking, but I would rephrase this last sentence to something like "Tuples whose all component types are instances of Eq, Ord, Bounded, Read, or Show are themselves instances of Eq, Ord, Bounded, Read, or Show respectively." (Eg. (a->a, b) is not an instance of Eq.) Regards, -- Libor _ [EMAIL PROTECTED] Masaryk University, Faculty of Informatics tel +420-5-41512355 Botanicka 68a, Brno, CZ-60200 pgp fingerprint 32 0A AB E1 62 D6 BF 86 82 09 AA 47 2B F4 45 98 ~ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: f :: IO x -> x
Dusan Kolar writes: > Playing with IO monads I made to me a task. Create > a function which counts lines of a file and returns the > number of lines as a result: > > lineNo :: String -> Int > fname number of lines > > To access files I'm using standard file access and operators > defined in class Monad. The problem is, that when I count > the lines, I'm imprisoned by IO monad. Is there any way > (e.g. by converting value to String and obtaining this string as a result) > how to break IO monads? How to make a function of type > > f :: IO [Char] -> [Char] > > I know, that usually it is possible to write whole the > program such a way so that it would not matter to have > a IO monad as a top type, but having a function which counts number > of lines in the file (or watever else) is also not too bad, > at least as fas as I think, but maybe I'm completely wrong. > > Thanks a lot > >Dusan Kolar Dusan, in Haskell there is no such thing because Haskell is referentially transparent language. In Haskell extensions, like ghc, Hugs, there is a function unsafePerformIO :: IO a -> a, which does exactly what you desire. But beware: it is unsafe, nonstandard, and generally regarded as a Bad Thing in programming style. Good luck. -- Libor
Re: A new view of guards
Tony Davie writes:
> >I'm quite comfortable with the idea. Guards are part of the lhs of an
> >equation, and that is where binding takes place.
> >
> >The <- syntax worries me a bit, because in the comprehension use it has a
> >different type, but the let syntax is available, and one can write
> >"let p = e" "for p <- e". I think that, to reduce possible confusion, I would
> >use, and teach, the let form. Given that, I don't object to the funny use of
> ><-.
> >
> >--brian
>
> Yes. I really like the fact that at last guards in comprehensions and those
> in function defns have the same syntax. But shouldn't they have the same
> semantics too? I would rather expect
>
> f g l| x <- l = g x
>
> or something like it, to be the map function.
>
> So I, like Brian, would prefer 'let ... = ...' to '... <- ...'
Actually f _is_ the map function (map^{Id} in identity monad ;-)
(I understand Simon Peyton Jones' proposed syntax as one restricting
the meaning of <- to identity monad just like the list comprehension
[ g x | x <- l ] is restricting <-'s meaning to list monad.)
Seriously, I like the idea.
-- Libor
Libor Skarvada | Masaryk University, Brno, Faculty of Informatics,
[EMAIL PROTECTED] | Botanicka 68a, CZ-60200,phone +420-5-41512355
~
