Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for Division
Message-ID: <1324.UUL1.3#5129@willett.UUCP>
Date: 13 Jul 90 03:26:11 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 138

Category 10,  Topic 17
Message 71        Thu Jul 12, 1990
R.BERKEY [Robert]            at 08:19 PDT
 
  Gene LeFave writes 900710,

  GL> I recently read the transcripts of the Genie RT conference
  GL> regarding division.  I found it incredible that the ANSI
  GL> committee is spending so much time and energy on what is for the
  GL> vast majority of programmers a non-issue.

According to the GEnie messages, the committee spent time on division early
on.  More recently the time and energy expended in technical analysis on
integer division may be primarily mine.  This work has been in part a response
to a point raised regarding the Forth-83 division: that it came without a
rationale.  This analysis will remain, independent of what X3.J14 decides.

And I agree as to the questionable expenditure of time.  Had X3 not exhumed
the Forth-79 division, there may well have been more productive use for the
time.  But I find it interesting, I don't mind standing up for the 1982
committee and the Forth-83 Standard where I think criticism has been
misdirected or unfair, and the division effort has not been wasted.  The
rationale for Forth-83 division is more complete now.  One of the results of
the analysis is a better understanding of the rounded-to-zero division.  If
anything, the technical surprise has been just how one-sided are the technical
issues.  During the 1982 meetings the analysis was simpler: MOD is a
mathematically defined operator which Forth-79 had misdefined, the floored
division was useful, and the Forth-79 division was both error prone and
lacking in demonstration of usefulness.  The more recent analysis has further
confirmed these points.  A point made then from a vendor, which relates to one
of Gene's main points, is that most programmers have many concerns other than
division that might lead them to call for customer service, i.e., that
customer support wasn't seen as a significant issue.

I've not assumed that division itself was fundamentally the X3.J14 issue. 
Thusly the technical analysis effort has verified that the ANS committee
involvement with division is not a technical one.  And, it's missing the point
to say that because division is oft discussed, that the problem is discussing
division.  There's more to be learned from this than division alone.

I'm satisfied that the basic technical issues are now well below any
reasonable threshold of doubt, such that any remaining problems with division
are political ones.  A point I make is that there is a lack of criteria by
which X3.J14 makes technical determinations.  I sense that cajolery, more than
reason, functions as a modus operandi.  Is there supposed to be some other
rationale for removing the Forth-83 list of tradeoffs?

 GL> I have never run across a programming language that attempts to
 GL> provide a different division operator than that provided by the
 GL> hardware.

Remember the tale of the emperor with no clothes?  A lot of folks were said to
have thought those clothes admirable.

  GL> I can't imagine a programmer ever expecting the language to
  GL> compensate in this way.

No, I don't accept the innuendo that Forth programmers are to be lacking in
imagination.

How do we determine expectations of a language?  Or, who determines these
expectations (for us)?  I believe that processors and implementations exist
for the needs of users.

  GL> I checked the manuals of a couple of languages and can't find one
  GL> that defines the result of MOD over negative numbers.

I too have seen that technical writers of language manuals tend not to state
how negative operands behave.  Yet, Gene, your thesis would seem to be that
this is somehow related to Forth Standards.  My phone number is (415) 659-1334
x352.  Or if you will leave your phone number I'd be willing to give you a
call.

 GL> The idea that a standard program should run on every interpreter
 GL> is a severe requirement...

A standard program runs only on conforming implementations, not "every"
interpreter.

I think that the implied irrelevance of portability is a challenging question.
On the one hand, Forth survives without much in the way of libraries, or
secondary markets based on portable code.  Is the survival of Forth vendor
fiefdoms good enough?  It was said in 1982 thereabouts that Forth, Inc., was
then marketing some 40 different polyForths--suggesting that if it's been good
enough for the flagship vendor it's good enough for standardization.  Do we
dismiss libraries of portable Forth routines?  Do we care?

The Forth-83 list of tradeoffs places "portability" second only to "functional
correctness".  I don't consider that standardized Forth is Forth--rather that
Forth-83 should be subtitled "Portable Aspects of Forth".

A viewpoint toward giving programs more utility: the lack of committee
attention in Forth-83 to the Standard Program, which seems to have resulted in
more implementations than programs, is reason to move the balance toward the
program.  X3.J14 moves the balance farther toward the implementation.

Then there is the issue that a Standard System is a commodity product. Since
the ability to produce a Forth compiler is something of a given as one of the
capabilities of a Forth programmer, perhaps this low market value of standard
Forth compilers preconditions Machievellian market motives where prejudicing
the careezs!of brde-lance Forth programmers, and locking-in customers, has
beeT5isconstrued as a part of the job of marketing/survival.  (Why would
X3.J14 note that surveys went out to vendors?  I know that as a free-lance
consultant I wasn't surveyed.  Were surveys collected from the customers of
various vendor's, and from authors, teachers, and other consumers, such as
discerning hobbyists?  [Yes, it's not necessarily easy, and I'm not
volunteering.]  A point of concern is that there is at least an appearance
that vendors are accepting preferential treatment.)

Do we dismiss the market for interpreters and compilers built on Standard
Systems?  This last is a personal issue for me as I don't see that the current
BASIS will encourage such designs.  Nor do I think I will be writing the
implementation platforms that would be necessary even just for 680x0, 80x8n,
and Harris chips.

I doubt the committee themselves presently understand how to fit the pieces of
BASIS together.  Things like the recent text that removes the specification of
a bit pattern for zero.  This has weird implications like FALSE is no longer
defineable as 0 CONSTANT FALSE but would be maybe 0 0< CONSTANT FALSE .


 GL> The idea that a standard program should run on every interpreter
 GL> is a severe requirement that could sink the entire process.

Counter to the viewpoint that portability is irrelevant, why would Forth be
the only language whose X3 standard exists more for the implementation than
the program?  I don't know, but perhaps an attempt to propose a non-portable
language to X3, a language that is not seriously expected to be used by
programmers, would be a self-eliminating problem.


   One of those committee members,

   Robert

-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu