Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Kragen Javier Sitaker Newsgroups: comp.lang.forth Subject: Re: Postscript in 4tH Date: Thu, 10 Sep 2026 01:44:59 -0300 Organization: Primarily biological and memetic Lines: 115 Message-ID: <8733vhaf5g.fsf@debian> References: <117hl2n$1ne4b$1@dont-email.me> <871pb7l36f.fsf@nightsong.com> <875x0gib1k.fsf@debian> <117prfv$gq7e$3@dont-email.me> <87o6e7cifh.fsf@debian> <2026Sep9.093521@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 10 Sep 2026 04:47:19 +0000 (UTC) Injection-Info: dont-email.me; logging-data="1808625"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+njUtLWxUAKsuMwln9jZ7j"; posting-host="c87f7b499d57f9157cd7adfbbe69f310" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cancel-Lock: sha1:MLNvtQRZavHCKcn2P06qbz24l4E= sha1:q31o8iLd9SfshYCoUSvS5Cg8M48= sha256:jrN0otDPTBTZ7NrxjMOR0Nlo+QMXBCcyuK6kEIeiCkQ= sha1:qVdj64mA3uo8TzaF4Ak7Nt4jNPE= sha256:hS1R6MV72sA4Qy4DgFycKlqS8AHTnDUOuRH7NLl6TV4= Xref: csiph.com comp.lang.forth:135640 anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Kragen Javier Sitaker writes: >>PostScript has several other key similarities to Lisp. Referencing Paul >>Graham's "What Made Lisp Different" : > > Given your claim below that Forth has only #1, #3, #9, let's look at > the others: > >>2. A function type. “In Lisp, functions are first class objects-- >>they’re a data type just like integers, strings, etc, and have a literal >>representation, can be stored in variables, can be passed as arguments, >>and so on.” > > Forth has execution tokens. I thought about this when posting. Xts certainly can be stored in variables or passed around as arguments or results. But orthodox Forth doesn’t have Joy-like quotations, which I think is the language feature that allows you to claim that functions “have a literal representation”, although it does have `:noname`. Orthodox Forth is almost the same as C in this sense, in that you must define all of your functions at the top level. Function pointers such as Forth xts provide a very significant gain in expressiveness, but function *literals* add so much expressiveness that you can use them to define custom control structures, as in Smalltalk (or PostScript). Lisp programs also commonly create new functions at runtime, although in modern Lisp this is largely limited to creating closures. Forth has closures in the form of `create does>`, but because that appends to the dictionary, you don’t normally do it willy-nilly, usually only when you are loading a program. >>4. A new concept of variables. “In Lisp, all variables are effectively >>pointers. Values are what have types, not variables, and assigning or >>binding variables means copying pointers, not what they point to.” > > In Forth, neither variables nor values have types that are known to > the Forth system. The way to use that is that the programmer must > know the type, and that typically means always storing the same type > into a variable. That is certainly true, but to my eye, Forth is much more similar to assembly, Fortran, or C in this sense than to Lisp. You might `create` an array and give it a name, for example, and you can think of that name as referring to the beginning of the array (like a label in assembly language) or to the entire array (as in Fortran or C), but it definitely does not refer to a cell somewhere holding a *pointer to* the array, the way it does in Lisp and PostScript (or Python, or JS, or Lua, or Smalltalk, etc.) Forth uses the term `variable` for single-cell variables, and those are often used to store integers that are not pointers. Some Lisps (and, for example, Lua and Squeak) avoid “boxing” their integers in a memory allocation by packing type bits into a pointer, but this trick is invisible to the language semantics, while it is very visible in Forth. >>6. Programs composed of expressions. Not really, but closer than any of >>the currently popular languages. > > Forth is like Postscript here: Programs composed of words (operators > in Postscript), which work on values on the stack. Yes. D’Oliveiro suggested that what PG intended here was that there’s no distinction between statements and expresions, which is plausible; but, as I see it, in neither PostScript nor Forth do we have clear-cut expressions in the syntax, so even if PostScript (and Forth) fit what PG intended to say, they do not fit what he actually said. >>7. A symbol type. Yes, PostScript distinguishes /names from strings, > > Forth distinguishes name tokens from strings, but they do not play the > role they play in Lisp or Postscript; in particular, you have to > create new named words outside a colon definitions, and if you use a > named word to get a unique value, you tend to use its body address, > not its name token. I had forgotten about name tokens; thank you for the reminder. >>8. A notation for code using trees of symbols. Yes. The only >>difference is that in conventional Lisp they’re binary trees, while in >>PostScript they’re N-ary ordered trees. > > As mentioned in <2026Sep9.084205@mips.complang.tuwien.ac.at>, one > might consider the indirect-threaded code representation and its > modern equivalents for inlining to be such a notation, but in Forth > many control structures become branches, whereas in Postscript the > controlled stuff is a procedure (in Forth terminology, a quotation). As you say, Forth flattens the tree into an array at compile time. Also, though, it is entirely omitted from the standards, so that Forths that do not use threaded code can still count as “compliant”. The things in the array are generally not name tokens, but execution tokens. PostScript supports either one, and people usually do `bind` their subroutines, replacing the symbols with subroutine pointers, so that they run faster: GS>/square {dup mul} def GS>4 square = 16 GS>/square load === {dup mul} GS>/square load bind === {--dup-- --mul--} >>Forth hits #1, #3, and #9. > > And also #2, and partially #6, #7, and #8. Well, that’s certainly a defensible position, but I think it’s still debatable. Thank you very much for your thought-provoking post. Kragen