Hi Phil!
| > (Mark says it was very tricky to implement what Hugs does)
|
| I can't imagine why. Perhaps Mark can explain?
I should clarify. Arranging for constraints that appear in the types of
constructors to show up whenever that constructor is used --- whether in
an application or a patte
Mark P Jones wrote:
> | 2) Does anyone care that this type of thing is not possible?
>
> Yes, they do. That said, I've often found that people are usually happy
> simply to write something like:
>
>newtype Assocs i e = MkAssocs [(i,e)]
>
> I know it's a bit of a pain to be forced to use t
> So doesn't my proposal give you precisely what you want, and no more?
Because my interest is as much in documentation as in constraints on
how the program executes (I admit your method achieves the latter).
If I write, say,
data Eq a => Assoc a b
then I'd like the signatures to ensure that
David Barton is right,
probably.
Looking into Maude www page, i saw the name of Manuel Clavel and
recalled a message on the OBJ language, i listened to, several years
ago. Clever thing.
A program in a really good language has to formulate a set of term
equalities and, - very separately, - a
To my
>> Another question on *rules*.
>> Could they help the implicit type casting?
>> For example, with
>> {rules Num a=> x::a, y::[a] ==> x+y = [x]+y}
>> instance Num a => Num [a] where ...
>> one could expect for x :: Num b=>b the casting
>
> I'm happy with either of the following choices:
>
> * Class constraints on constructors have effect everywhere
> (as in Hugs).
> * Class constraints on constructors are eliminated (call it a
> typo if you must).
I'd be delighted to eliminate them, but we had a long H98 debate
about it (unde
Simon PJ writes:
> ** I therefore PROPOSE that when pattern matching on a constructor,
> ** any context on the data type declaration is ignored.
> Yell if you dislike this; otherwise I'll just add it to the 'bugs' page.
Bleah! (Is that a loud enough yell?)
I'm happy with either of the follow
Folks
Julian has discovered another ambiguity in the Haskell 98 Report. Consider:
data Ord a => T a = MkT a a
We know that MkT has type
MkT :: Ord a => a -> a -> MkT a a
We also know that the dictionary passed to MkT is simply discarded.
The constraint simply makes sure that
| The biggest one is that I would like to be able to make [(ix,el)], [Pair
| ix el], and Array ix el all members of a Find class while should look
| something like this:
|
| class Find c ix el where
| find :: ix -> c -> Maybe el
|
| without having to define a new type or introducing the poss
> >> {rules Num a=> x::a, y::[a] ==>
> x+y = [x]+y}
> >> instance Num a => Num [a] where ...
> >> one could expect for x :: Num b=>b the casting
> >> x + [x,y] -->
> [x] + [x,y]
> > Provided the two
10 matches
Mail list logo
