> > I also think its neat that you seem to have found a use for cyclic
> > unification. This is definitely an impetus to extend the language to
> > include cyclic types. (I don't expect we'll do this for a while
> > though. You might consider modifying the Glasgow Haskell compiler to
> > includ
> a)). Mycroft first suggested a type system that would allow such
> functions to be typed, but I think it is still an open question as to
> whether an inference algorithm exists for the type system. (There was
> a paper published that claimed an algorithm, but it was later withdrawn
> as incorr
> I also think its neat that you seem to have found a use for cyclic
> unification. This is definitely an impetus to extend the language to
> include cyclic types. (I don't expect we'll do this for a while
> though. You might consider modifying the Glasgow Haskell compiler to
> include this you
> Apart from the implementation (which doesn't seem to be a problem if
> the right alg. is used[*]) does anyone know of more subtle problems with
> cyclic types [such as not being able to define the type system using
> the traditional sequent style]? Is this a well-studied area?
>
The only probl
> Date: Fri, 26 Feb 1993 15:52:38 GMT
> From: [EMAIL PROTECTED]
> Subject: Re: Stupid Haskell question
>
> Apart from the implementation (which doesn't seem to be a problem if
> the right alg. is used[*]) does anyone know of more subtle problems with
>
Guy, You write,
But now suppose that some of the annotations refer to FooTree items
(another thing I forgot to say). I suppose I could do
data FooTree a b = Leaf b | Node a (FooTree a b)
a (FooTree a b)
Date: Tue, 23 Feb 93 17:18:19 GMT
From: wadler <[EMAIL PROTECTED]>
...
I don't understand. Can't you handle this is as follows?
data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b)
data Annote a b c = MkAnnote Info (FooTree (Annote a b c) b) c
and t
Guy S., Phil W.,...
I ran into exactly this problem in two different applications.
The first was the same that Guy S. points out, namely adding
arbtrirary but well-typed annotations to a parse-tree. The solution I
eventually ended up using (after di
Date: Tue, 23 Feb 93 10:16:58 GMT
From: wadler <[EMAIL PROTECTED]>
Given your correction, I think that the type declaration
data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b)
will handle things only a little less neatly than the use of
wrappers, and will allo
Given your correction, I think that the type declaration
data FooTree a b = Leaf b | Node a (FooTree a b) a (FooTree a b)
will handle things only a little less neatly than the use of
wrappers, and will allow you to use type inference in much the
way you wish. What do you think? Cheers, --
Guy,
I agree that the report should be updated to express the restriction we
really have in mind. Simon: as editor, this is your bailiwick!
I also think its neat that you seem to have found a use for cyclic
unification. This is definitely an impetus to extend the language to
include cyclic typ
I blew it! My example had a bad flaw. See below.
Date: Mon, 22 Feb 93 19:30:19 GMT
From: wadler <[EMAIL PROTECTED]>
Guy,
I agree that the report should be updated to express the restriction we
really have in mind. Simon: as editor, this is your bailiwick!
I also think its
Guy asks the following (non-stupid) Haskell question, which I reply to
below. The question points out an area in the Haskell report that
seems to be unclear; and a place where it might be worthwhile to change
the design to be less conservative but more uniform.
Guy's question:
-
Date: Mon, 22 Feb 93 14:28:47 GMT
From: wadler <[EMAIL PROTECTED]>
Guy asks the following (non-stupid) Haskell question, which I reply to
below. The question points out an area in the Haskell report that
seems to be unclear; and a place where it might be worthwhile to
14 matches
Mail list logo
