The following example compiles with PC.Compile but doesn' t with Builder.Compile (Tested on Bluebottle Release 2.7.03). Please do only use PC.Compile and report Bugs. MODULE Foo; CONST digits = 10; ops = 5; TYPE DigitBtn = RECORD END; OpBtn = RECORD END; (* auxiliary type used for grouping related items *) Buttons = RECORD digits : ARRAY digits (* constant *) OF DigitBtn; ops : ARRAY ops (* constant *) OF OpBtn; END; END Foo. Vasile Rotaru wrote:

Hi, all

I don't know whether the following code is correct or not, but both Compiler.Compile and PC.Compile choke on it. (The first with a trap, the second with a criptical report "PC.Compile not done (10/10)".)

CONST digits = 10; ops = 5;

TYPE Button = .. DigitBtn = .. OpBtn = ..

(* auxiliary type used for grouping related items *) Buttons = RECORD digits : ARRAY digits (* constant *) OF DigitBtn; ops : ARRAY ops (* constant *) OF OpBtn; END

Of course I may change the name of constants (digits => numOfDigits), but still there must be either a error reported or an .Obx/.Obj file at the end.

Regards, Vasile -- Oberon@inf.ethz.ch mailing list for ETH Oberon and related systems https://www.mail.inf.ethz.ch/lists/listinfo/oberon

-- Oberon@inf.ethz.ch mailing list for ETH Oberon and related systems https://www.mail.inf.ethz.ch/lists/listinfo/oberon

"Daniel Keller" <keller@creacare.com> wrote:

Please do only use PC.Compile and report Bugs.

I don't know how but I cannot reproduct the reported behaviour. Too bad, for my reputation... Still, PC.Compile fail on this module MODULE OFACalc; (** ObjectFull Abstract Calculator **) CONST plus = 0; minus = 1; times = 2; div = 3; equals = 4; nop = 5; digits = 10; ops = 5; (* array bounds *) TYPE Component = OBJECT VAR calc : Calculator; (* 'up' reference *) END Component; Button = OBJECT(Component) VAR PROCEDURE Activate; BEGIN END Activate; END Button; DigitBtn = OBJECT(Button) VAR val : LONGINT; (* 0 <= val <= 9 *) PROCEDURE Activate; BEGIN calc.DigitPressed(val); END Activate; END DigitBtn; OpBtn = OBJECT(Button) VAR op : LONGINT; (* plus <= op <= equals *) PROCEDURE Activate; BEGIN calc.OpPressed(op); END Activate; END OpBtn; Value = OBJECT(Component) VAR repr : ARRAY 32 OF CHAR; op : LONGINT; val : LONGREAL; PROCEDURE UpdateVal (digit: LONGINT); BEGIN END UpdateVal; PROCEDURE SetOp (op0: LONGINT); BEGIN END SetOp; PROCEDURE Eval (num: LONGREAL; op: LONGINT); BEGIN END Eval; END Value; (* Auxiliary types, used for grouping related objects *) Buttons = RECORD digits : ARRAY digits OF DigitBtn; ops : ARRAY ops OF OpBtn; END; Values = RECORD res, last : Value; END; Calculator = OBJECT VAR values : Values; buttons : Buttons; PROCEDURE DigitPressed (digit: LONGINT); BEGIN values.last.UpdateVal(digit); END DigitPressed; PROCEDURE OpPressed (op: LONGINT); BEGIN values.res.Eval(values.last.val, values.last.op); values.last.SetOp(op); END OpPressed; END Calculator; END OFACalc. The problem still seems to be in the Buttons RECORD. Commenting out the buttons field in the Calculator object helps. On the other side changing the names of constants doesn't. A most irritating behaviour. And the compilation fails with the same criptic (I insist on it) message: "Compiling OFACalc (9/9) not done". For a change on a more elaborate version of the same example it fails with (10/10) message. Does it mean a progress??? Regards, Vasile

"Daniel Keller" <keller@creacare.com> wrote:

Vasile,

The bug you have describe has been fixed. It will be released at the end of the year. If you need it before, let me know,

regards Daniel

Well, this is good work. I can't say I need it (the fix) badly, for my puposes, I can do with Builder.Compile as well. But since I like doing things differently (this being one of the reasons I use NO and BB) I can send you another bug/deviation from the standard. You cannot do WITH foo.bar: Bar DO (* stuff *) END; either using Compiler OR PC. Still the Oberon Report states clearly: WITH qualident : qualident DO .. END; Checking the (dinamic) type of a exported variable may be bad practice, but checking the type of a RECORD field may have some uses. Regards, Vasile PS. I am just curious if this qualifies as gratitude :)

"Daniel Keller" <keller@creacare.com> wrote:

Vasile,

We will try to make Paco complient to the standard. Paco will support at least WITH := Qualident : Qualident. Ev. WITH := Designator : Qualident, but that's not clear yet.

Well, (as Svejk will have been said) "if we are conversating now so nicely" may I ask why the support for Oberon-2 WITH was dropped in Active Oberon (Paco)? Just that WITH is not widely used in the Oberon sources, or are the more subtle reasons? Anyone at ETH who knows the story?

We also will give up the perfomance gain of WITH and introduce type checks so that the following will trap:

(* type Child is extension of type Parent *) PROCEDURE Bar(p: Parent); PROCEDURE NewParent; BEGIN NEW(p); END NewParent;

BEGIN IF p IS Child THEN WITH p: Child DO NewParent; (* p has dynamic type Parent, but fields of Child are still accessible !!! *) END; END; END Bar;

I see, (down/up)casting in a WITH statement may be a dangerous/unsafe thing to do. So, even the simplest languages have the dark corners.. Maybe just a price to pay for "dinamicity". But are the runtime checks really necessary? Would it not suffice to make the "casted" pointer immutable/readonly within a WITH statement? It makes perfect reason with me, and this can be checked at compile-time, if i guess correctly. (Not a trivial task still, as your example shows)

regards, Daniel

You cannot do

WITH foo.bar: Bar DO (* stuff *) END;

either using Compiler OR PC. Still the Oberon Report states clearly:

WITH qualident : qualident DO .. END;

Regards, Vasile