Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/20/90)
Hello Pat:
Could you provide me with a list of PIM3/PIM4 descrepancies within JPI M2 2.00?
Chris (JPI Tech Support) refuses to believe that JPI M2 2.00 does not comform to PIM3/PIM4 (with the sole exception of FORWARD).
Chris asked me for a list of deviations. You have pointed several here and there. Could you compile them for me to give to JPI?
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgPat.Terry@p101.f4.n494.z5.fidonet.org (Pat Terry) (07/23/90)
> Hello Pat: > > Could you provide me with a list of PIM3/PIM4 descrepancies within JPI > M2 2.00? I guess it's hard to categorise. JPI will probably argue that the differences are "extensions", not "violations" of PIM. So I guess GOTO is not a violation of PIM. But here are a few that I think are violations. I mentioned the use of IMPORT instead of EXPORT from a module nested within an implementation module already. That is the worst example, perhaps. DEFINITION MODULE a; PROCEDURE y; END a. IMPLEMENTATION MODULE a; MODULE (*inner*) x; (*standard*) EXPORT y; (*JPI*) IMPORT y; PROCEDURE y; ... Also you don't need, so far as I remember, an EXPORT from a local module. You can just use Localmodule.ItsIdentifier outside LocalModule to look at anything. (* local*) MODULE d; (* no import or exports *) VAR x : INTEGER; END d; BEGIN d.x := 6 (* should be illegal*) If you have DEFINITION MODULE a; FROM x IMPORT y; ... END a. then in PIM I think you have to write IMPLEMENTATION MODULE a; FROM x IMPORT y (*again*); ... but in JPI you do not. If you have DEFINITION MODULE a; TYPE b = (c,d,e); END a; (*another*) DEFINITION MODULE x; FROM a IMPORT b; TYPE y = b; END x. then, in JPI, in IMPLEMENTATION MODULE x you cannot refer to c or d or e as you should be able to do. (Mind you, lots of them have this wrong) In JPI BYTE, WORD, ADR and ADDRESS are standard identifiers, but they should be imported from SYSTEM (if only to "brand" the source code non portable). If this is an "extension" it is a silly one, and not in the "spirit" of SYSTEM! In JPI the type casting of the form CARDINAL(g), INTEGER(g), REAL(h) is not "casting" or coercion at all, but conversion (like using VAL. There are probably others. As i think of more i'll try to remember to post them. Hope this helps Pat -- uucp: uunet!m2xenix!puddle!5!494!4.101!Pat.Terry Internet: Pat.Terry@p101.f4.n494.z5.fidonet.org
jensting@skinfaxe.diku.dk (Jens Tingleff) (07/25/90)
Pat.Terry@p101.f4.n494.z5.fidonet.org (Pat Terry) writes: [....] >If you have >DEFINITION MODULE a; > FROM x IMPORT y; > ... >END a. >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: "3. If an identifier defined in a module M1 is exported, the scope expands over the block which contains M1. If M1 is a compilation unit (see Ch 14), it extends to all those units which import M1" This is the sort of thing a lot of compiler writers like to get wrong... . [..] >In JPI the type casting of the form CARDINAL(g), INTEGER(g), REAL(h) is not >"casting" or coercion at all, but conversion (like using VAL. Well: PIM2 ed3 is very careful to mention the fact that `type transfer functions' are implementation defined. It says in chapter 29, page 125 top, ".... 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 ? The example below 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. The `FLOAT()' and `TRUNC()' functions should (surely) be used. 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." So, both the `type transfer functions' and VAL will simply alter the apparent type (apart from byte -> longword conversions in VAL), no "casting" (in, e.g., the C sense, where ``int i; double r = (double)i;'' performs computation). Please correct me if I'm wrong, I know I'm confused.. Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) (07/25/90)
Hello Pat:
Thank you for your post.
Please think of all the concrete examples you can think about. If you can site specific chapters or pages in PIM3/PIM4, all the better.
I believe I finally got Chris (JPI Tech Support) willing to listen about possible PIM3/PIM4 deviations.
If we can provide solid evidence of deviations (extensions do not count), then I believe JPI maybe willing to add a compiler switch to flag those items --- or fix them.
--
uucp: uunet!m2xenix!puddle!273!101!Peter.M..Perchansky
Internet: Peter.M..Perchansky@f101.n273.z1.fidonet.orgaubrey@rpp386.cactus.org (Aubrey McIntosh) (07/28/90)
In article <2301.26AF3E2A@puddle.fidonet.org> Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) writes: >Hello Pat: > > Thank you for your post. > > Please think of all the concrete examples you can think about. If you can site specific chapters or pages in PIM3/PIM4, all the better. > > I believe I finally got Chris (JPI Tech Support) willing to listen about possible PIM3/PIM4 deviations. > > If we can provide solid evidence of deviations (extensions do not count), then I believe JPI maybe willing to add a compiler switch to flag those items --- or fix them. I supervised a project that used an old version of JPI, 1.01 or therabouts. I would have been much more willing to support JPI if there had been some way to have the compiler evaluate a program as strict, minimalist Modula-2. There were two rationals behind this. 1) Surely another vendor will happen along that has a compiler that does everything I need for some future project. If I let the shop spread the extensions through the code, I'm trapped. Now this might seem to be a good marketing decision on JPI's part, but I know for a fact that many shops do use 'second source availability' as a purchasing criterion for many products, and I certainly am aware of it when I buy software tools. 2) The extensions typically give the relaxation of some protection. I ended up debugging an associates code, where he used Trick records and the relaxed typechecking in JPI's compiler. The record in question involved BYTE/WORD size folderol, and matching code to emulate an existing package. The JPI compiler accepted the code, but popped the wrong number of bytes from the stack on return. I believe that the time spent tracking this error down could have been spent writing a transportable piece of code that was clear, easy to maintain, safe. To the extent that I can influence Things That Become, I'd encourage the vendors to make their products work with each others. I'm not advocating that they be identical, and I certainly like the speed that JPI offers just as I like the Tools that Logitech offers. It's just a shame that the discipline to keep them compatible has to be present in junior people. -- Aubrey McIntosh "Find hungry samurai." -- The Old Man 1502 Devon Circle comp.os.minix, comp.lang.modula2 Austin, TX 78723 1-(512)-452-1540 (v)
Pat.Terry@p101.f4.n494.z5.fidonet.org (Pat Terry) (07/29/90)
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
jensting@skinfaxe.diku.dk (Jens Tingleff) (07/31/90)
Pat.Terry@p101.f4.n494.z5.fidonet.org (Pat Terry) writes: >In Message-ID: <1990Jul25.074022.21528@diku.dk> Jens Tingleff writes [..] >Well, in D106 it will be correct. if you had set r := 123.456 then i >would have been assigned the value 123 [..] >In D106 this applies more widely too, ie to REAL and LONGREAL as well. Okay, that does it ;-). WHERE CAN I GET A COPY OF THE (DRAFT) STANDARD ??? [ and how much does it cost ? ] Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
jensting@rimfaxe.diku.dk (Jens Tingleff) (08/06/90)
jensting@skinfaxe.diku.dk (Jens Tingleff) writes: [..] > WHERE CAN I GET A COPY OF THE (DRAFT) STANDARD ??? > [ and how much does it cost ? ] You'll have to shout a little louder, I can't hear you !! [i.e. I haven't received any replies at all] If someone *has* followed up on this, I'd like some e-mail (I haven't seen new articles in this group for the better part of a week, so out mail connection may be dud). Jens Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University Snail mail: DIKU Universitetsparken 1 DK2100 KBH O "It never runs around here; it just comes crashing down" apologies to Dire Straits
randy@m2xenix.psg.com (Randy Bush) (08/12/90)
jensting@rimfaxe.diku.dk (Jens Tingleff) writes: > WHERE CAN I GET A COPY OF THE (DRAFT) STANDARD ??? Here in the US from either o the Computer Society office in Washington DC, or o Modula-2 Users' Association, c/o Stan Osborne, stan@dvi.com -- ..!{uunet,qiclab,intelhf}!m2xenix!randy randy@psg.com randy@m2xenix.uucp
stan@toaster.SFSU.EDU (Stan Osborne) (08/13/90)
In article <1990Aug12.010701.28019@m2xenix.psg.com> randy@m2xenix.psg.com (Randy Bush) writes: >jensting@rimfaxe.diku.dk (Jens Tingleff) writes: >> WHERE CAN I GET A COPY OF THE (DRAFT) STANDARD ??? > >Here in the US from either > o the Computer Society office in Washington DC, or > o Modula-2 Users' Association, c/o Stan Osborne, stan@dvi.com ^^^^^^^ This is not a correct email address for reaching me or MODUS. Email for MODUS can be sent to: modus@cs.sfsu.edu (Internet) or: cshub!modus (uucp) -- Stan Osborne, Computer Science Department, San Francisco State University Internet: stan@cs.sfsu.edu Usenet: cshub!stan Voice: (415) 338-2168