Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ames!ucsd!usc!samsung!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: ANS Forth
Message-ID: <1073.UUL1.3#5129@willett.UUCP>
Date: 3 Jun 90 21:33:52 GMT
References: <9006011903.AA03706@ucbvax.Berkeley.EDU>
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 29

In <9006011903.AA03706@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes:

> Claiming the *possibility* of user extensions ISN'T GOOD ENOUGH.
> 
> The good news is that ANS Forth DOES standardize a number of much needed
> extensions, including files, floating point, memory allocation, strings,
> local variables, extended memory access, run-time search order control,
> and error handling.
> 
> ANS Forth will make the situation a lot better, if it is not already too
> late.

Actually it seems to be as if you and Mr.  Wavrik are not really in
disagreement.  There is nothing about a clean "core" system that would
prevent ANSI from declaring various "extensions".  X3J11 (the 'C' effort)
did something along those lines by declaring various name spaces.
Identifers were "allocated" to various groups (users and implementers) on
the basis of their leading characters.  The only anomaly in this was the
preexisting libraries.  They used identifiers which would otherwise be left
to the users.  Additionaly X3J11 specified various behaviours that the
compiler 'could do' and but which the user must not assume any knowledge
of, when composing conforming code.  Forth may be just too much of an
anarchy for an approach like that to work, though.

-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]