Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!ncar!gatech!rutgers!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: What are the existing standards?
Message-ID: <1894.UUL1.3#5129@willett.pgh.pa.us>
Date: 21 Oct 90 01:58:55 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 54

Category 10,  Topic 1
Message 23        Thu Oct 18, 1990
JETHOMAS                     at 23:38 CDT
 
 >> The point I was making is that even when all previous
 >> implementations _agreed_, the ANSI team has changed things.

 > Can you give me an example Brad?  I don't see where that has
 > happened?

 >> But the implementation proposed by the ANSI TC has, to my
 >> knowledge, been used only by Mitch Bradley.

 > At the risk of making you even more sure that you are "right", I
 > should mention that the ANS CATCH and THROW are not exactly what
 > Mitch uses, but is a reasonable compromise that will work on most
 > systems.

From my perspective, the MAIN thing we should expect of ANSI TC is that they
not 'put new wine into old bottles'.  If the approach is new, then it needs a
new name.  If major vendors use the same name differently, then make a new
name for the old function!  They should minimise the exclusion of existing
code.  It looks like they've been doing a very good job by this criterion.

Beyond that, I don't see how we can be too doctrinaire and still have a
standard.  Various people have a veto.  Assuming they're all rational people
of good will, we still face a collection of good but incompatible ideas.  We
don't want a 'PL/I' standard that requires every idea that sounds good.  We do
want a set of tools that work well with each other.  Trying to get that means
sometimes going with existing practice, and sometimes using something new.
Sometimes a new approach will be required to break a deadlock.  Then other new
methods become supremely practical given the presence of the first. Any rigid
formula for deciding what's acceptable is bound to fail. If they can produce a
flexible system, then all the existing Forths should be writeable in it, and
even small applications could become 'standard' at less than twice the size. 8-
)

You have to at least think you're good at this sort of thing to pay much
attention to Forth.  But Forth programmers tend to do it by keeping a whole
module inside one head.  How would a committee of Forth programmers come up
with a good system?  It would help if they were all very fast programmers who
could adapt to new styles quickly. Then they could sort-of try out new things
to get a feel for them. I'd expect the ones who were best at this would tend
to get their way, provided they could also communicate their ideas well.  I'd
expect Forth programmers to be better than usual at adapting the language to
the problem, but perhaps not so consistent about explaining it....

I predict that there WILL be an ANSI standard.  The people who really need one
will accept one that's less than perfect.  The people who don't need one can
ignore it easier than going to some trouble to block it and get the others
angry at them.  It will be interesting to see what we get.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp