Jay Cox writes:
| One day I was playing around with types and I came across this type:
|
| >data S m a = Nil | Cons a (m (S m a))
:
| >instance (Show a, Show (m (S m a))) => Show (S m a) where
| > show Nil = "Nil"
| > show (Cons x y) = "Cons " ++ show x ++ " " ++ show y
|
| which b
On Sun, May 27, 2001 at 10:46:37PM -0500, Jay Cox wrote:
> >data S m a = Nil | Cons a (m (S m a))
>...
> >instance (Show a, Show (m (S m a))) => Show (S m a) where
> > show Nil = "Nil"
> > show (Cons x y) = "Cons " ++ show x ++ " " ++ show y
...
> >show s
> >s = Cons 3 [Cons 4 [], Cons 5 [Cons
S. Alexander Jacobson writes:
| On Fri, 25 May 2001, Zhanyong Wan wrote:
| > As you explained, the parse of an expression depends the types of the
| > sub-expressions, which imo is BAD. Just consider type inference...
Also, we can no longer take a divide-and-conquer approach to reading
code,
One day I was playing around with types and I came across this type:
>data S m a = Nil | Cons a (m (S m a))
The idea being one could use generic functions with whatever monad m (of
course
m doesn't need to be a monad but my original idea was to be able to make
mutable lists with some sort of m
