te happily.
Thanks.
Hopefully I'll have some code to contribute soon.
Brandon
>
>
> | -Original Message-
> | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Ashley Yakeley
> | Sent: 07 September 2003 06:57
> | To: [EMAIL PROTECTED]
> | Subject: Circ
In article
<[EMAIL PROTECTED]
.com>,
"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote:
> OK, I yield!
>
> The HEAD now runs this program. It turned out to be a case of
> interchanging two lines of code, which is the kind of fix I like.
Cool, thanks.
--
Ashley Yakeley, Seattle WA
: [EMAIL PROTECTED]
| Subject: Circular Instance Declarations
|
| When -fallow-undecidable-instances is switched on, is there any reason
| why circular instances are forbidden? For instance:
|
| module CircularInsts where
| {
| data D r = ZeroD | SuccD (r (D r));
|
| instance (Eq (r
> A simple irregular type is
> Irr a = Con a (Irr (F a))
> (as long as F uses a)
>
> The sort of instance I'm interested in is something like
> instance (Eq a,Eq (Irr (F a)) => Eq (Irr a)
> where the context only mentions (subexpressions of) type expressions
> encoutered while expanding t
On Wed, 10 Sep 2003, Ashley Yakeley wrote:
> Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
>
> > A simple irregular type is
> > Irr a = Con a (Irr (F a))
> > (as long as F uses a)
>
> Would this be an irregular type, with F as ((->) val)?
>
> data SymbolExpression sym val a = ClosedSymbolExpr
In article <[EMAIL PROTECTED]>,
Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
> A simple irregular type is
> Irr a = Con a (Irr (F a))
> (as long as F uses a)
Would this be an irregular type, with F as ((->) val)?
data SymbolExpression sym val a = ClosedSymbolExpression a |
OpenSymbolEx
On Sun, 7 Sep 2003, Ashley Yakeley wrote:
> In article <[EMAIL PROTECTED]>,
> Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
>
> > Detecting circularity in a derivation is equivalent to accepting a regular
> > infinite derivation for instances. Would you have a use for irregular
> > derivation
In article <[EMAIL PROTECTED]>,
Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
> Detecting circularity in a derivation is equivalent to accepting a regular
> infinite derivation for instances. Would you have a use for irregular
> derivations?
Could you give me an example?
--
Ashley Yakeley,
I have also wanted this, in the context of John Hughes' restricted data
types. In order to simulate these properly, you need circular instances
of this form.
- Hal
On Sun, 2003-09-07 at 21:07, Brandon Michael Moore wrote:
> Hi Ashley
>
> See the thread "Type Class Problem". In his post on Au
In article <[EMAIL PROTECTED]>,
Brandon Michael Moore <[EMAIL PROTECTED]> wrote:
> Actually, I'm surprised someone else has a use for this. I wanted
> circular instances for playing with the paper "Recursion Schemes from
> Comonads". What are you trying to do?
It's for HScheme. The Object type h
Hi Ashley
See the thread "Type Class Problem". In his post on Aug 22 Simon
Peyton-Jones said that it shouldn't be hard to implement, and mentioned
that it would ruin the property that dictionaries can be evaluated by
call-by-value. I couldn't puzzle out enough of the type class system to
make th
Ashley Yakeley wrote:
> Would it be reasonable for the compiler to check back through the
> stack and allow the circularity? It will just create an ordinary
> recursive function.
The following works.
Flags: -fglasgow-exts -fallow-undecidable-instances
data D r = ZeroD | SuccD (r (D r))
in
When -fallow-undecidable-instances is switched on, is there any reason
why circular instances are forbidden? For instance:
module CircularInsts where
{
data D r = ZeroD | SuccD (r (D r));
instance (Eq (r (D r))) => Eq (D r) where
{
ZeroD == ZeroD = True;
13 matches
Mail list logo
