Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.lang.forth
Subject: Re: Non-Forth systems/languages.
Summary: Forth vendors are somewhat responsible
Message-ID: <7803@pt.cs.cmu.edu>
Date: 2 Feb 90 11:54:05 GMT
References: <363.UUL1.3#5129@willett.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 30

In article <363.UUL1.3#5129@willett.UUCP>, ForthNet@willett.UUCP (ForthNet articles from GEnie) writes:
>    To: STEVE PALINCSAR               Refer#: 1565
>  From: ARCHIE WARNOCK                  Read: NO
>  Subj: C + libriaries                Status: PUBLIC MESSAGE
> 
>  Me, too.  I recall the debate, and I'm somewhat surprised that somebody
>  didn't raise that point (ain't hindsight wonderful).  Still, the
>  difference is that most of the stuff in the standard C libraries is in
>  _every_ compiler. ...
>  ...  You sure can't say _that_ about Forth systems.  Nearly
>  everything outside the standard is named differently in different
>  systems.

Partly this is because Forth vendors have traditionally based
their sales differentiation on newer/slicker/better kernel
implementations and extension sets (which 
promotes incompatibility) instead of newer/slicker/better
support, development environments, etc.  I am hoping that this
will change on the move to ANS-Forth, but somehow I doubt it.
The ANS extensions aren't inclusive enough to accomplish this,
and probably can't be, since there is no "standard practice" for
what to include in Forth most libraries.  Forth vendors should realize
that the time has come to stop basing their reason for existence
on promoting incompatibility in the name of "better" base systems.

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
Senior Scientist at Harris Semiconductor, adjunct professor at CMU.
I don't speak for them, and they don't speak for me.