Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Standard systems vs. standard programs
Message-ID: <1380.UUL1.3#5129@willett.UUCP>
Date: 23 Jul 90 04:50:28 GMT
References: <11977@sdcc6.ucsd.edu>
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 80

In <11977@sdcc6.ucsd.edu>, ir230@sdcc6.ucsd.edu (john wavrik) writes:
> 
> 1.  [...] They make 0 their standard and declare that "Arithmetic 
>     is broken -- but we feel it is useful for everyone to know what 
>     they must avoid if they want portability." 
> 
> 2.  They set about producing an international standard which has all 
>     the best features. In particular they choose a common base, common 
>     symbols for digits and arithmetic operations, etc. To sooth those
>     current users at home who do not plan to engage in world commerce, 
>     they agree to continue to provide support for the next few years 
>     for their customers' current numeration systems as well as the new 
>     international system. 
> 
> 3.  They decide to devise a complex numeration system which will allow 
>     everyone to continue to use their current base -- but which will 
>     also work with all other bases.

What you said isn't as interesting as what you didn't say.
As I read your message, #2 is the obvious winner and right thing to do.
#1 is a minimalist escape hatch and #3 is a maximalist mess.

Responses of type #1 or #3 do have their appropriate uses.  I won't try
to defend them here.

#2 is based on a flawed assumption that you have your cake (backward
compatability) and eat it too (Brave New Arithmetic World).
There is a contradiction.  You say that the standard will have all the
best features AND that it will support current systems in parallel
with new ones.  So, how do you tell when the best features of system X
are being used as part of the current system or the new one?  Obviously
you need some context.  The X3J14 TC is providing that context by
giving different names to the various operators.  The response to that
seems to be based on a confusion between the object and its name.
[I have not been privy to the contents of the proposals so far before
the committee, so I don't know the history of politics involved here,
and perhaps that assumed background is the reason I'm at odds here.]

You seem to be implying (gad, just come out and bloody say it next time)
that the new {/} {JW/MOD} {DR/MOD} {R2D2/MOD} are really solution #3
instead of solution #2.  Rather than just imply, I'd like to see some
more explicit support.  Again, it seems to me that the dividing line is
being drawn on the basis of the spelling of the name, rather than on the
issue of the semantics.  If you continue to classify the TC's solution
to the {/} "problem" as number #3, I challange you to present a #2
solution to them (and to the net) instead.  If you think that such a
solution has already been presented, please provide the identifying
information and I will gladly follow up on my own.

I see the value is saying that "X" is the wrong solution to problem "Y".
However, if there are no better solutions available to problem "Y", what
should be done, invent a solution?  The TC is forbidden (in theory at least)
from "inventing" new practice.  So, at what point does the synthesis of
your #2 solution stop being existing practice and start being new practice?
I'm not sure I know the answer, but I do know that it isn't a simplistic
"always" or "never".

Point of focus:  Perhaps all those who are thoroughly or even mildly
disgusted with the "watered down ANSI effort" should simply admit that
there are never going to be satisfied with the requisite compromises of
the CONSENSUS and EXISTING-PRACTICE requirements?  Perhaps creating the
BRAVE NEW FORTH is something which would be effort better spent?  I
hardly think, though, that such an effort could afford to ignore the
scrutiny that the ANSI effort has given to Forth, even if the TC's
solutions are not adopted.  Nor will future ANSI efforts be able to
ignore BRAVE NEW FORTH, but it is simply not in the current charter to
build/design BRAVE NEW FORTH.  Perhaps another analogy will make things
even more muddy: (:-) ANSI is working to build a building using
off-the-shelf technologies.  BRAVE NEW FORTH is working to build next
years/months/decades off-the-shelf technologies.  The cross-influences
will obviously be uneven at any given time.  The compromises involved
are vastly different ( {/} {KGB/MOD} {IRS/MOD} {JW/MOD} ) and
(finite versus infinite numeric representations).


-Doug

---
Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp
Daily: ...!{uunet,nfsun}!willett!dwp   [in a pinch: dwp@vega.fac.cs.cmu.edu]