Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tektronix!nosun!qiclab!m2xenix!puddle!p101.f4.n494.z5.fidonet.org!Pat.Terry
From: Pat.Terry@p101.f4.n494.z5.fidonet.org (Pat Terry)
Newsgroups: comp.lang.modula2
Subject: Re: PIM3/PIM4 and JPI M2
Message-ID: <2429.26B3DD50@puddle.fidonet.org>
Date: 29 Jul 90 06:30:47 GMT
Sender: ufgate@puddle.fidonet.org (newsout1.26)
Organization: FidoNet node 5:494/4.101 - Settler City Fido, Grahamstown RSA
Lines: 77

In Message-ID: <1990Jul25.074022.21528@diku.dk> Jens Tingleff writes

 > >then in PIM I think you have to write
 > >IMPLEMENTATION MODULE a;
 > >  FROM x IMPORT y (*again*);
 > > ...
 > >but in JPI you do not.
 > 
 > Not to turn this into any sort of super-correctness-war, but PIM2 ed 3 
 > ref. man. sect 14 page 168 has
 > 
 >         "..Definition and implementation modules exist in pairs. Both
 >          may contain import lists, and all objects declared in the
 >          definition module are available in the corresponding
 >          implementation module without explicit import"
 > 
 > "Ahh", I hear you cry (and my self as well), "it says declaration, not
 > import". Well, I'd say an import was a declaration, refering to sect 4,
 > page 146, of same work, scope rules augmentations:

This is one of those messy ones, admittedly.  I think the DP D106 makes
it clear that they have to be reported in Standard modula-2, ie an import is  
not a declaration.

Curiously, of the 6 PC compilers I have

2 (FTL and JPI) do not require reimportation (and flag this as a funny)
4 (FST, Logitech, Collier, QuickMod) do require reimportation

 > This is the sort of thing a lot of compiler writers like to get wrong... .

Yup

 >         ".... The key idea behind these type transfers is,
 >          however, that they do not involve any actual computation. .."
 > 
 > what is meant by ``"casting" or coercion'' above ? 

Exactly that - you don't compute, you just reinterpret a bit pattern.  For  
16 bit twos complement INTEGER/CARDINAL it makes no difference for half the  
range.  For REAL(integer) it would make a big difference.  (16 bits would
be too small, just for a start, in most cases)


 > is what an article in PCW (Personal COmputer World) claimed to be alright,
 > in a M-2 series they had some time ago.
 > 
 > VAR
 >   r : REAL; i : INTEGER;
 > BEGIN
 >   i := VAL(INTEGER, r);         (* NO NO NO *)
 > END.
 > 
 > which I'm sure is wrong. 

Well, in D106 it will be correct.  if you had set r := 123.456 then i 
would have been assigned the value 123

 > The `FLOAT()' and `TRUNC()' functions should (surely) be used. 

In PIM, they only apply to CARDINAL/REAL.  In D106 their equivalents apply more
widely, and it has been decided that the PIM model was too restrictive.

 > PIM2 ed 3 ref man sect 10.2 describes the VAL function 
 > as
 >         "VAL(T,x)       the value with ordinal number x and with type T.
 >                         T is any enumeration type, or CHAR, INTEGER
 >                         or CARDINAL. VAL(T, ORD(x)) = x, if x is of type 
 > T."

In D106 this applies more widely too, ie to REAL and LONGREAL as well.



--  
uucp: uunet!m2xenix!puddle!5!494!4.101!Pat.Terry
Internet: Pat.Terry@p101.f4.n494.z5.fidonet.org