Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!willett!dwp
From: dwp@willett.UUCP (Doug Philips)
Newsgroups: comp.lang.forth
Subject: Re: Why is Postscript not Forth?
Message-ID: <509.UUL1.3#5129@willett.UUCP>
Date: 19 Feb 90 03:18:07 GMT
References: <9002161509.AA19458@jade.berkeley.edu>
Organization: Latest link in the ForthNet chain.  (Pgh, PA)
Lines: 61

In <9002161509.AA19458@jade.berkeley.edu>, wmb@ENG.SUN.COM writes:

> [Doing PostScript's closure is not easy nor portable in Forth, but
>  doing Forth's closure's in PostScript is easy.]
Ok, I concede the point here.  I might ask if this doesn't raise the
question of the proper factoring of the Forth closure-making words?

> In PostScript, you can't look at the bits in a stack cell, and you also
> can't pretend that a number is an address and try to "@" that location.
> In nearly all Forth implementations, both of these are possible.
> In PostScript, stack objects are typed, and if you try to use e.g. a
> logical operator on a number object, you get an error signal and the
> operation aborts.
Yes, but can you trivially write a word that converts between types, or
is type-ness inaccesable?

>...[Discussion about the lack of ease of writing a word which will,
>    at runtime, CREATE a word whose name is in the word in which
>    CREATE occurs.]
> Specifically, I mean that I have tried several times to do this, and have
> never come up with a good portable way of doing it, without resorting to
> extremely gruesome mucking about with the mechanics of the input stream,
> which isn't very portable because most of the Forth systems that I care
> about have extended those input stream mechanisms to cope with text files,
> and the input stream hacks aren't portable across those systems.
Again, doesn't this point to a factoring problem with the dictionary
manipulating words?  Having good streams doesn't solve the problem that
there should be a word that creates a dictionary entry from a 'string'
on the stack.  (Define string as addr or addr/len, or what have you).

> This isn't rhetoric.  "Adr len" strings are objectively best, in that
> a) Any character can appear in a string (null-terminated and tagged
>    strings are weak in this respect).
> b) Many types of string manipulation can be performed on "adr len" strings
>    without copying, without allocation of extra memory, and without
>    concerns about "read-only" storage.  (counted strings are weak in
>    these respects).
> c) An "adr len" string can be arbitrarily long.
> d) Any region of memory can be described as an "adr len" string without
>    requiring preallocation of space for either a count byte or a delimiter
>    byte.
> The one weakness of "adr len" strings is an issue of convenience.  There
> are 2 things on the stack instead of 1.
> 
> I believe that the above claims are both verifiable and demonstrable.
Point c works only if you can capture the range of your address space in
a single stack item, unless you have 'long strings' with double
precision integers as their length.  As to points a & d, well, we might
consider a difference between strings and arrays of bytes.  X3J11 did
that.  There are string functions and there are byte array functions.
Not the same things.

> The ANSI committee has settled upon the "adr len" representation for
> all new functions with string arguments.
Considerations of existing practice make this unsurprising.

		-Doug

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