Re: [Haskell-cafe] Re: New slogan for haskell.org
On Nov 28, 2007 6:16 PM, Laurent Deniau [EMAIL PROTECTED] wrote: I can't see how it could be one page of C unless the page is 10 lines long ;-) The following code is the direct translation of your Haskell code (except that it prints the result instead of building a list). a+, ld. #include stdio.h #include intset.h Which C standard defines intset.h? Juanma ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.
On 9/27/07, ok [EMAIL PROTECTED] wrote: (What the heck _is_ Tangut, anyway?) http://en.wikipedia.org/wiki/Tangut_language Juanma ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Newbie qustion about monads
On Thu, 02 Oct 2003 14:57:22 +0200, Juanma Barranquero [EMAIL PROTECTED] wrote:
data Accum s a = Ac [s] a
instance Monad (Accum s) where
return x = Ac [] x
Ac s1 x = f = let Ac s2 y = f x in Ac (s1++s2) y
output :: a - Accum a ()
output x = Ac [x] ()
After trying this one, and also
output :: a - Accum a a
output x = Ac [x] x
I though of doing:
data Accum a = Ac [a] a
because I was going to accumulate a's into the list.
That didn't work; defining = gave an error about the inferred type
being less polymorphic than expected ('a' and 'b' unified, etc.).
After thinking a while, I sort of understood that = is really more
polymorphic, i.e., even if it is constraining [s] to be a list (because
it is using ++), it really is saying nothing about the contents of the
list. It is output who's doing the constraint, but, with the very same
monad, I could do:
output :: [a] - Accum Int [a]
output x = Ac [length x] x
or
output :: a - Accum [a] a
output x = Ac [[x]] x
or whatever.
But then I wondered, is there any way to really define
data Accum a = Ac [a] a
i.e., constraining it to use a for both values, and make a monad from it?
Curious,
Juanma
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Newbie qustion about monads
I have an extremely-newbie question about monads and how to interpret the monadic laws; I asked that same question yesterday on IRC and the answers were interesting but non-conclusive (to me anyway). I'm trying to learn monads by reading All About Monads, version 1.0.2. I though of defining a monad like that: data Counted a = Ct Int a instance Monad (Counted) where return x = Ct 1 x Ct n x = f = let (Ct n' x') = f x in Ct (n+n') x' -- fail as default The intent is that Counted objects count the number of times an operation is applied to them. (For the purpose of the question, that's irrelevant anyway: the problem would be the same if I assigned a random number to the Int on each calling of =.) According to All About Monads, the first monadic law says: (return x) = f == f x In my case, let's suppose I define: reverseCounted :: [a] - Counted [a] reverseCounted x = return (reverse x) so I do: c1 = return xxx = reverseCounted -- c1 == Ct 2 xxx c2 = reverseCounted xxx -- c2 == Ct 1 xxx Now comes the question: In what sense should I interpret the == in the monadic law? Obviously, c1 and c2 are not structurally equal. If I can accept that two Counted things are equal even if they are not identical, is enough for me to define: instance Eq a = Eq (Counted a) where Ct _ x == Ct _ y = x == y to satisfy the first law? Yesterday I was said that it'd work if c1 and c2 are mutually substitutable. They are, for the purposes of equality, though evidently not for every purpose. A simple: count (Ct n _) = n allows me to distinguish between them. Juanma ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Newbie qustion about monads
On Thu, 02 Oct 2003 11:22:13 +0200 Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote: As you discovered, there is no meaningful count of operations. If an operation doesn't do anything, do you count it? It's not about counting the operations (that's just an example), but accumulating any kind of state. For example: data Accum a = Ac [a] a instance Monad Accum where return x = Ac [x] x Ac _ x = f = let Ac l x' = f x in Ac (l ++ [x']) x' dupAcc x = Ac [x,x] x m1 = (return 'a') = dupAcc -- Ac aaa 'a' m2 = dupAcc 'a'-- Ac aa 'a' but monad laws say that return *really* doesn't do anything I don't see it. As I understand, the problem (if any) would be in my implementations of either = or f (dupAcc, in this case). I get the same values for m1 and m2 even if I define return x = Ac [] x. I'm not trying to create useful monads (I'm pretty sure they aren't :), but understanding the concepts. So, the question remains: when the monad laws say that (return x) = f == f x what is intended in that ==? Eq.== for instance Eq MyCustomMonad where x == y = whatever... or a more profound kind of equality? Juanma ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: AW: Newbie qustion about monads
On Thu, 2 Oct 2003 13:16:13 +0200 [EMAIL PROTECTED] wrote: The Monad class is just called Monad because it is intended to cover a monad. But it doesn't ensure the laws. That is your sole responsibility. Yeah, I know. But it's difficult to ensure I'm satisfying the laws when I'm not entirely sure what do they ask from me... You can define it to your liking as long as it is commutative. Ah, that's what I was expecting. So, in both my examples, defining: instance Eq MyMonad where MM _ x == MM _ y = x == y would suffice and the first law would be satisfied. Thanks, Juanma ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Newbie qustion about monads
On Thu, 2 Oct 2003 12:30:54 +0100 Alastair Reid [EMAIL PROTECTED] wrote: Observational equivalence. For monads like list and maybe, this boils down to the normal equality because the standard equality on these types is exactly observational equality. For monads like IO, you can't define an Eq instance so it comes down to what can the user of the program observe. OK. But in my examples, the difference is observable only if I do define a count or equivalent to show it. Otherwise, c1/c2 (or m1/m2) are indistinguishable. (There's a little circularity there and I'm ignoring the exception part of parser monads but, hopefully, you get the idea.) Yes, thanks a lot. Juanma ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Newbie qustion about monads
On Thu, 02 Oct 2003 14:27:29 +0200 Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote: Accumulating state is fine. These definitions don't accumulate state: 'return' should yield a neutral state, and the above = ignores the state of the lhs. You're right. data Accum s a = Ac [s] a instance Monad (Accum s) where return x = Ac [] x Ac s1 x = f = let Ac s2 y = f x in Ac (s1++s2) y output :: a - Accum a () output x = Ac [x] () Nice. Thanks! Juanma ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Newbie qustion about monads
On Thu, 2 Oct 2003 16:09:11 +0100, Alastair Reid [EMAIL PROTECTED] wrote: So you should not interpret the '==' in the monad law as requiring you to define an Eq instance. If you do define an Eq instance, it ought to be reflexive, symmetric and transitive (i.e., an equivalence) if you want functions with Eq constraints to behave in a meaningful way. Thanks, I understand now. (Incidentally, the == I was defining was an equivalence, AFAICS.) Also, although there's probably no necessity for your Eq instance to match your notion of equality between computations (i.e., the == used in the monad laws), I think you'll end up very confused if you define an Eq instance which doesn't match in the same way that having Eq on pairs ignore the 2nd field would confuse you. Sure. I imagine only very specialized monads will need an Eq that doesn't match the equality implicit in the monad laws. As Derek has pointed out, I'm yet far from reaching a point where I should worry about that :) Thanks for your comments, Juanma ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
How to detect finite/infinite lists?
Extremely-newbie questions: Is there any way to know if a list is finite or infinite, other than doing: length l and waiting forever? :) I ask because I was learning Haskell by writing some pretty naive implementation of surreal numbers, where I used lists for left and right surreal sets, and I wanted to do some operations on the sets (like finding the maximum/minimum), but obviously just on finite sets. I vaguely suspect the answer is going to be: No, because lists are lazy (at least when they are :) and there's no general way to know beforehand how many elements they're going to have. But still, if I write x = [1..5] the compiler knows pretty well x is not going to grow any new member... (Unrelated) Is there any standard function to do: interleave [] _ = [] interleave _ [] = [] interleave (x:xs) (y:ys) = x : y : interleave xs ys It's pretty easy to implement as shown or via zipWith, but given that Haskell 98 already includes some basic functions (like cycle, iterate, etc.) I wonder if I've missed this one somehow. Thanks, /L/e/k/t/u ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: How to detect finite/infinite lists?
On Thu, 18 Sep 2003 15:53:12 -0400, Derek Elkins [EMAIL PROTECTED] wrote: In Haskell 98, no. With a slightly impure extension (observable sharing) sometimes but in general, no. Interesting. just use a data structure that says, an infinity of x. The simplest thing I would think of is to follow the arithmetic operation exactly. data SN = Zero | Up | Down | SN :+: SN | SN :*: SN | SN :^: SN | Omega SN :) Thanks, /L/e/k/t/u ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
