n the spirit of
actual Haskell, but I have to think on it a bit more.
Pablo E. Martinez Lopez (Fidel).
test3 :? part3
]
doing your proposal just another way of write this.
As pointed out by Tommy Thorn, re-using case will be confusing
and redundant.
Pablo E. Martinez Lopez (Fidel).
Errata:
in my previous mail, the text "a la Hoare" should be replaced by "a la
Dijkstra".
Fidel.
I have some questions about the Haskell Report. I will appreciate if
someone could exaplain them. Thanks.
1.- In the version 1.2 there is a restriction that a C-T instance declaration
may only appear either in the module where C or T are declared, but in
the version 1.3 this restriction
> > class MetaData a where
> > constructorName::a->String
> > mapArgs::(MetaData b,MonadPlus c) => (b->c)->a->[c]
>
> results in the error
> Illegal type "[c]" in constructor application
>
> If I replace MonadPlus with Show or Num there is no error.
> (Replacing MonadPlus with Monad also resul
> This ":=:" is, it seems me, the variation that the Haskell "=" corresponds
> to, except one then does not indicate the quantity defined, which is
> causing those ambiguity problems.
I always thought that in Haskell the left hand side is the one being
defined and the right hand side is the one t
> Why Haskell is so? Why case zipRem undefined []
> of
> (ps,xs',ys') -> ((x,y):ps, xs', ys')
>
> does not allow the result of zipRem undefined []
> to be of (ps,xs',ys')
> (which type is declared in zipR
> Haskell position (as I understand it)
> -
> Haskell is incapable of desribing IO, it can only evaluate an expression
> of type IO (). This expression is used by an 'IO monad machine' (which
> is not part of Haskell) to actually execute IO operations. Beca
> Probably so, I do have difficulty understanding this. The point I was
> trying to make is that as far as Haskell is concerned, that there is no
> difference between values of type (IO a) and any other values.
Exactly. That is a powerful thing: you treat computations as values and
other guy is
> I think negative take/drop should be conceptually viewed as
> prepending/appending "empty"/"bottom"/"default value". It would be nice
> if "take 5 (take -1 some_list)" was equal to "take 4 some_list". (I
> guess it would be more difficult to achieve this with the opposite
> order.)
No. If I wan
> > I'm with the option (B): negatives are just outside
> > the domain of take&drop, and should give you an error
> > message.
>
> For the people that share this sentiment, can you please
> explain why ints that are too big should not similarly
> give an error? I can see both being ok, or both b
> Many properties are broken anyway in presence of negative arguments
>
> drop n . drop m = drop (n+m) -- try n = -1, m = 1
> take n . drop m = drop m . take (n+m) -- try n = 1, m = -1
But following Simon assumption about collapsing integers to naturals,
you can
have
collapse n | n<0
"it would be very natural to add a type Natural providing an unbounded
size unsigned integer, just as Integer provides unbounded size signed
integers. We do not do that yet since there is no demand for it."
if that is not too much work could we have that in the library? i think
it would be ver
13 matches
Mail list logo
