🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.modula2
Article #1005

Re: PIM3/PIM4 and JPI M2

#1005
From: Aubrey McIntosh
Date: Sat, 28 Jul 1990 14:33
42 lines
2880 bytes
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)
Technical Details
Message-ID: <18472@rpp386.cactus.org>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!execu!sequoia!rpp386!aubrey
References: <2301.26AF3E2A@puddle.fidonet.org>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!execu!sequoia!rpp386!aubrey
From: aubrey@rpp386.cactus.org (Aubrey McIntosh)
Newsgroups: comp.lang.modula2
Subject: Re: PIM3/PIM4 and JPI M2
Message-ID: <18472@rpp386.cactus.org>
Date: 28 Jul 90 14:33:37 GMT
References: <2301.26AF3E2A@puddle.fidonet.org>
Reply-To: aubrey@rpp386.UUCP (Aubrey McIntosh)
Organization: vima, Austin TX
Lines: 42