Thread: [ooc-compiler] WITH statement and parametric types
Brought to you by:
mva
Menu
▾
▴
ooc-compiler
|
From: vedmed <ve...@in...> - 2005-06-26 09:53:33
|
I declare parametric type, and want to redefine procedure "Equals":
MODULE Test;
IMPORT Object, Out;
TYPE
Alp(T: Object.Object) = POINTER TO AlpDesc(T);
AlpDesc(T: Object.Object) = RECORD(Object.ObjectDesc)
val: LONGINT;
END;
Bet = POINTER TO BetDesc;
BetDesc = RECORD(Object.ObjectDesc)
END;
Gam = Alp(Bet);
VAR
g1: Gam;
g2: Gam;
PROCEDURE (a: Alp(T)) INIT*(val: INTEGER);
BEGIN
a.val := val;
END INIT;
PROCEDURE (x: Alp(T)) Equals*(y: Object.Object): BOOLEAN;
BEGIN
IF y = NIL THEN
RETURN FALSE;
ELSE
WITH y: Alp(T) DO
RETURN x.val = y.val;
ELSE
RETURN FALSE;
END;
END;
END Equals;
BEGIN
g1 := NEW(Gam, 1);
g2 := NEW(Gam, 1);
IF g1.Equals(g2) THEN
Out.String('equals'); Out.Ln();
ELSE
Out.String('not equals'); Out.Ln();
END;
END Test.
But in this example "Equal" always return FALSE, because of WITH
statement can not recognize parameter "y" as value of type "Alp" or
"Gam". Expressions "WITH y: Alp DO" and "WITH y: Alp(Object.Object) DO"
also not works. So I can't see a way how to get access to field "val" of
parameter "y". I don't know it is bug of compiler or some logic problem.
I suppose that full check of type and all of him parameters is difficult
task for compiler and can slow down compiled programs, but I assume,
that in most cases will be enough only checks of base type.
|
|
From: Michael v. A. <mic...@gm...> - 2005-07-03 14:50:38
|
On 6/26/05, vedmed <ve...@in...> wrote: > I declare parametric type, and want to redefine procedure "Equals": > [...] >=20 > But in this example "Equal" always return FALSE, because of WITH > statement can not recognize parameter "y" as value of type "Alp" or > "Gam". Expressions "WITH y: Alp DO" and "WITH y: Alp(Object.Object) DO" > also not works. So I can't see a way how to get access to field "val" of > parameter "y". I don't know it is bug of compiler or some logic problem. > I suppose that full check of type and all of him parameters is difficult > task for compiler and can slow down compiled programs, but I assume, > that in most cases will be enough only checks of base type. The current implementation cannot cope with types on the right hand side of a type test that include a type variable. It is fundamentally=20 flawed. Unfortunately I botched a test case half a year ago, or I would have known this earlier. I don't know a workaround, and there is no easy fix. I will have to think about this some more. -- mva |
|
From: <ph...@cs...> - 2005-07-03 20:35:00
|
Hi all, On Jul 3, 2005, at 07:50, Michael van Acken wrote: > The current implementation cannot cope with types on the right hand > side of a type test that include a type variable. It is fundamentally > flawed. Unfortunately I botched a test case half a year ago, or I > would > have known this earlier. Is this purely an implementation issue or is there a problem with the Szyperski/Roe proposal itself (which I gather is what you implemented for OOC)? I never tried implementing it myself, but it *looked* solid at the time. Any comments? Peter -- Peter H. Froehlich <><><><><><> http://www.cs.ucr.edu/~phf/ OpenPGP: ABC2 9BCC 1445 86E9 4D59 F532 A8B2 BFAE 342B E9D9 |
|
From: Michael v. A. <mic...@gm...> - 2005-07-04 05:47:27
|
On 7/3/05, Peter Fr=F6hlich <ph...@cs...> wrote: > Hi all, >=20 > On Jul 3, 2005, at 07:50, Michael van Acken wrote: >=20 > > The current implementation cannot cope with types on the right hand > > side of a type test that include a type variable. It is fundamentally > > flawed. Unfortunately I botched a test case half a year ago, or I > > would > > have known this earlier. >=20 > Is this purely an implementation issue or is there a problem with the > Szyperski/Roe proposal itself (which I gather is what you implemented > for OOC)? I never tried implementing it myself, but it *looked* solid > at the time. Any comments? Yes, it is an implementation issue, and no, it has nothing to do with Szyperski/Roe. OOC's implementation is for the most part derived from Generic Java, but carries type information into the run-time environment as well. Neither GJ nor S/R have a run-time component, if I remember correctly. -- mva |
|
From: Michael v. A. <mic...@gm...> - 2005-10-07 16:49:55
|
Sorry, the recent 2.1.9 release does not run the test case below
correctly. I messed up my test suite _again_ by only running type
tests with simple type variables :-/
I'll try to find a solution over the weekend.
-- mva
On 26/06/05, vedmed <ve...@in...> wrote:
> I declare parametric type, and want to redefine procedure "Equals":
>
> MODULE Test;
>
> IMPORT Object, Out;
>
> TYPE
> Alp(T: Object.Object) =3D POINTER TO AlpDesc(T);
> AlpDesc(T: Object.Object) =3D RECORD(Object.ObjectDesc)
> val: LONGINT;
> END;
>
> Bet =3D POINTER TO BetDesc;
> BetDesc =3D RECORD(Object.ObjectDesc)
>
> END;
>
> Gam =3D Alp(Bet);
>
> VAR
> g1: Gam;
> g2: Gam;
>
> PROCEDURE (a: Alp(T)) INIT*(val: INTEGER);
> BEGIN
> a.val :=3D val;
> END INIT;
>
> PROCEDURE (x: Alp(T)) Equals*(y: Object.Object): BOOLEAN;
> BEGIN
> IF y =3D NIL THEN
> RETURN FALSE;
> ELSE
> WITH y: Alp(T) DO
> RETURN x.val =3D y.val;
> ELSE
> RETURN FALSE;
> END;
> END;
> END Equals;
>
> BEGIN
> g1 :=3D NEW(Gam, 1);
> g2 :=3D NEW(Gam, 1);
> IF g1.Equals(g2) THEN
> Out.String('equals'); Out.Ln();
> ELSE
> Out.String('not equals'); Out.Ln();
> END;
> END Test.
>
> But in this example "Equal" always return FALSE, because of WITH
> statement can not recognize parameter "y" as value of type "Alp" or
> "Gam". Expressions "WITH y: Alp DO" and "WITH y: Alp(Object.Object) DO"
> also not works. So I can't see a way how to get access to field "val" of
> parameter "y". I don't know it is bug of compiler or some logic problem.
> I suppose that full check of type and all of him parameters is difficult
> task for compiler and can slow down compiled programs, but I assume,
> that in most cases will be enough only checks of base type.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>
|
|
From: Michael v. A. <mic...@gm...> - 2005-10-09 18:42:47
Attachments:
oo2c_32-2.1.9-2.1.9.1.diff.bz2
|
On 07/10/05, Michael van Acken <mic...@gm...> wrote: > Sorry, the recent 2.1.9 release does not run the test case below > correctly. I messed up my test suite _again_ by only running type > tests with simple type variables :-/ The attached patch should resolve this issue. Please give it a try. -- mva |
Thanks for helping keep SourceForge clean.
X