Note that existing SVG programs can easily be converted to Postscript
by simply including the correct libraries and replace "SVGopen" by
"PSopen" and "SVGclose" by "PSclose".
Hans Bezemer <the.beez.speaks@gmail.com> writes:
Note that existing SVG programs can easily be converted to Postscript
by simply including the correct libraries and replace "SVGopen" by
"PSopen" and "SVGclose" by "PSclose".
That's interesting as Postscript itself is a rather broken version of
Forth. Do you mean with SVG calls you can do all the usual Postscript
stuff including text rendering?
I just wrote some Postscript code recently and hit some ridiculous snags
due to dumb stuff in the language. They were fixable but "traps for the >unwary" as it were.
Hans Bezemer <the.beez.speaks@gmail.com> writes:
Note that existing SVG programs can easily be converted to Postscript
by simply including the correct libraries and replace "SVGopen" by
"PSopen" and "SVGclose" by "PSclose".
That's interesting as Postscript itself is a rather broken version of
Forth. Do you mean with SVG calls you can do all the usual Postscript
stuff including text rendering?
I just wrote some Postscript code recently and hit some ridiculous snags
due to dumb stuff in the language. They were fixable but "traps for the unwary" as it were.
I experienced no "ridiculous snags". Actually the language is
kind of nice and safer than Forth.
I remember that the Adobe manuals were pretty good but I didn't use them
this time. If I had to do something more serious in Postscript I'd
probably read through the Adobe manuals again first.
In article <871pb7l36f.fsf@nightsong.com>,
Paul Rubin <no.email@nospam.invalid> wrote:
That's interesting as Postscript itself is a rather broken version of >>Forth. Do you mean with SVG calls you can do all the usual Postscript >>stuff including text rendering?
I just wrote some Postscript code recently and hit some ridiculous snags >>due to dumb stuff in the language. They were fixable but "traps for the >>unwary" as it were.
Maybe you weren't fully embracing the language. Don't expect it
to be Forth.
I think of PostScript as being Lisp, more or less, but with
quasi-Forth syntax ...
On Tue, 08 Sep 2026 02:09:43 -0300, Kragen Javier Sitaker wrote:
I think of PostScript as being Lisp, more or less, but with
quasi-Forth syntax ...
PostScript is homoiconic, but the resemblance to Lisp ends there. Lisp
has macros, PostScript doesnrCOt. Lisp needs macros,
PostScript does in fact have something like readmacros; in particular, readhexstring was the recommended way to handle image data, so that the
image data didnrCOt have to be loaded into a PostScript object by way of
the PostScript parser.
2. A function type. rCLIn Lisp, functions are first class objects--
theyrCOre 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.rCY Yes; PostScript goes even harder here than
Lisp, because thererCOs actually no way to define a named function in PostScript. You have to define an anonymous function and pass it as
an argument to /bind in order to give it a name. This is somewhat
related to homoiconicity but is not the same thing.
4. A new concept of variables. rCLIn 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.rCY
PostScript does work this way, as does Smalltalk (not
coincidentally, from the same lab, which was also heavily into
Lisp). ItrCOs easy to forget how unusual this was, because now
languages more or less like this dominate the scene: Python, JS,
Ruby, PHP, Lua, and to some extent, even Java and C#. But none of
the other popular languages of the day worked that way.
5. Garbage-collection. Yes.
6. Programs composed of expressions. Not really, but closer than any
of the currently popular languages.
7. A symbol type. Yes, PostScript distinguishes /names from strings,
which is arguably the feature of all of these that is most
distinctive to Lisp (the only other languages that do this are Ruby, Smalltalk, and, in a way, JS), and PostScript shares it.
8. A notation for code using trees of symbols. Yes. The only
difference is that in conventional Lisp theyrCOre binary trees, while
in PostScript theyrCOre N-ary ordered trees.
9. rCLThe whole language always availablerCY, i.e., arbitrarily
overlapping compile time and runtime. Yes.
Given that PostScript clearly hits 8 out of 9 of these criteria, and
arguably all 9, while no then-popular language other than Lisp came
anywhere close, I think itrCOs pretty clear that it mostly belongs to
the Lisp family.
Its resemblance to Lisp is much deeper than just being homoiconic.
Forth hits #1, #3, and #9.
Given that you can parse expressions from the input stream at
compile time and generate code at runtime, you can obviously
implement Lisp-like macros in PostScript. It just isnrCOt an
established practice.
The one very non-Lispy weird thing, which doesn't have a similar
feature in any other language I know of, is that the executable bit
set by `cvx` is an attribute of references, not objects. So `{dup
mul}` and `[dup mul]` can be the same object as seen through two
different references. ThatrCOs why making `square` executable required calling `def` again rather than just `cvx`.
(Please forgive in advance the LLM-like wording of what follows. I
wrote it entirely by hand, including reading the documents I linked, but IrCOve been coaxing
Lisp needs macros, because it also has
"special forms" for syntactic constructs that implement things like
control constructs, declarations etc. PostScript doesnrCOt have "special >forms", since all these concepts are implemented as built-in
functions. Which is also why it doesnrCOt need macros.
Also, Forth never heard of homoiconicity ...
PostScript has several other key similarities to Lisp. Referencing Paul >Graham's "What Made Lisp Different" <https://paulgraham.com/diff.html>:
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."
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."
5. Garbage-collection.
6. Programs composed of expressions. Not really, but closer than any of
the currently popular languages.
7. A symbol type. Yes, PostScript distinguishes /names from strings,
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.
Forth hits #1, #3, and #9.
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.
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.
On Tue, 8 Sep 2026 20:34:07 -0000 (UTC), Lawrence DrCOOliveiro wrote:
Lisp needs macros, because it also has rCLspecial formsrCY for
syntactic constructs that implement things like control constructs,
declarations etc. PostScript doesnrCOt have rCLspecial formsrCY, since
all these concepts are implemented as built-in functions. Which is
also why it doesnrCOt need macros.
You cannot get around this kind of stuff. Postscript has a subparser
for executable arrays ({ ... }) that behaves completely differently
from the regular parser that is also used to build literal arrays ([
... ]).
Also, Forth never heard of homoiconicity ...
The traditional indirect-threaded-code implememtations can be
considered homoiconic, and I wrote a word in the 1980s that made use
of this property to show a call graph of Forth words. Also,
decompilers made use of this property.
At the time that PostScript was designed, most Lisps did not have
macros; they still had fexprs.... PostScript first shipped in 01982,
Given that PostScript clearly hits 8 out of 9 of these criteria, and
arguably all 9, while no then-popular language other than Lisp came
anywhere close, I think itrCOs pretty clear that it mostly belongs to the Lisp family.
On Wed, 09 Sep 2026 06:42:05 GMT, Anton Ertl wrote:[...]
You cannot get around this kind of stuff. Postscript has a subparser
for executable arrays ({ ... }) that behaves completely differently
from the regular parser that is also used to build literal arrays ([
... ]).
if len(ctx.currentprocs) != 0 :
ctx.currentprocs[-1].append(the_obj)
else :
ctx.execute(the_obj, doproc = False)
#end if
#end interpret
So the only difference in the parser between being inside a procedure >definition (there is an entry in the ctx.currentprocs stack of
in-progress procedure definitions) and outside it comes down to that
last if-statement: if inside, append the just-parsed object (symbol,
literal, nested procedure, whatever) to the current procedure
definition; if outside, just execute it directly.
The traditional indirect-threaded-code implememtations can be
considered homoiconic, and I wrote a word in the 1980s that made use
of this property to show a call graph of Forth words. Also,
decompilers made use of this property.
ThatrCOs a limited form of read-only introspection. You couldnrCOt do >transformations on the AST or such, could you?
For a start, that would
require dynamic memory allocation, which Forth doesnrCOt have.
(Please forgive in advance the LLM-like wording of what follows. I
wrote it entirely by hand, including reading the documents I linked, but >IrCOve been coaxing
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Tue, 08 Sep 2026 02:09:43 -0300, Kragen Javier Sitaker wrote:
I think of PostScript as being Lisp, more or less, but with
quasi-Forth syntax ...
PostScript is homoiconic, but the resemblance to Lisp ends there. Lisp
has macros, PostScript doesnrCOt. Lisp needs macros,
At the time that PostScript was designed, most Lisps did not have
macros; they still had fexprs. Some Lisps did have macros, most notably >MACLISP, but they had not yet become central to language style the way
they are today. Remember that PostScript first shipped in 01982, when
the world was dominated by BASIC, FORTRAN, and COBOL.
PostScript does in fact have something like readmacros; in particular, >readhexstring was the recommended way to handle image data, so that the
image data didnrCOt have to be loaded into a PostScript object by way of
the PostScript parser. But, for the most part, like Smalltalk,
PostScript uses a lightweight lambda syntax for most of the things you
would use macros for in Lisp.
Kragen--
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:<SNIP>
Also, Forth never heard of homoiconicity ...
The traditional indirect-threaded-code implememtations can be
considered homoiconic, and I wrote a word in the 1980s that made use
of this property to show a call graph of Forth words. Also,
decompilers made use of this property.
- anton--
ThatrCOs a limited form of read-only introspection. You couldnrCOt do >transformations on the AST or such, could you? For a start, that would >require dynamic memory allocation, which Forth doesnrCOt have.
Even Java could probably manage what Forth does, and nobody would call--
it rCLhomoiconicrCY.
In article <117r5b2$u52n$5@dont-email.me>,
Lawrence D|+Oliveiro <ldo@nz.invalid> wrote:
<SNIP>
That|o??s a limited form of read-only introspection. You couldn|o??t do >>transformations on the AST or such, could you? For a start, that would >>require dynamic memory allocation, which Forth doesn|o??t have.
Infinite memory is as good as dynamic memory. I can expand my Forth
to e.g. 128 Gbyte that is for all practical purposes infinite.
On Wed, 9 Sep 2026 08:28:18 -0000 (UTC), Lawrence DrCOOliveiro wrote:
ThatrCOs a limited form of read-only introspection. You couldnrCOt do
transformations on the AST or such, could you? For a start, that
would require dynamic memory allocation, which Forth doesnrCOt have.
Infinite memory is as good as dynamic memory. I can expand my Forth
to e.g. 128 Gbyte that is for all practical purposes infinite. Then
it is a small change to use ALLOCATE that is not in the kernel of my
Forth, but it is a loadable extension.
On Wed, 9 Sep 2026 08:28:18 -0000 (UTC), Lawrence DrCOOliveiro wrote:
On Wed, 09 Sep 2026 06:42:05 GMT, Anton Ertl wrote:
You cannot get around this kind of stuff. Postscript has a
subparser for executable arrays ({ ... }) that behaves completely
differently from the regular parser that is also used to build
literal arrays ([ ... ]).
if len(ctx.currentprocs) != 0 :
ctx.currentprocs[-1].append(the_obj)
else :
ctx.execute(the_obj, doproc = False)
#end if
#end interpret
So the only difference in the parser between being inside a
procedure definition (there is an entry in the ctx.currentprocs
stack of in-progress procedure definitions) and outside it comes
down to that last if-statement: if inside, append the just-parsed
object (symbol, literal, nested procedure, whatever) to the current
procedure definition; if outside, just execute it directly.
Sounds very much like compile state and interpret state.
The traditional indirect-threaded-code implememtations can be
considered homoiconic, and I wrote a word in the 1980s that made use
of this property to show a call graph of Forth words. Also,
decompilers made use of this property.
ThatrCOs a limited form of read-only introspection. You couldnrCOt do
transformations on the AST or such, could you?
Changing the compiled code was not common, but used. ...
However, the more common approach is to change the source code and
load it again (typically in a new session, or after a FORGET or a
marker). And in Postscript and Lisp that's also the case.
For a start, that would require dynamic memory allocation, which
Forth doesnrCOt have.
Forth has what is usually understood under "dynamic memory
allocation", but it's not clear why that should be required for
writing to code.
On Tue, 08 Sep 2026 22:38:58 -0300, Kragen Javier Sitaker wrote:
PostScript does in fact have something like readmacros; in particular,
readhexstring was the recommended way to handle image data, so that the
image data didnrCOt have to be loaded into a PostScript object by way of
the PostScript parser.
ItrCOs just a function. ItrCOs like saying Python has rCLreadmacrosrCY because
the JSON and XML library modules have functions for reading input
2. A function type. rCLIn Lisp, functions are first class objects-- [...]
Homoiconicity comes in because the function body is stored in an array object, which is a PostScript language type, and its contents are also objects of various PostScript language types.
rCLIn Lisp, functions are first class objects-- theyrCOre 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.rCY
Where PostScript is lacking is in missing support for lexical binding. Anybody who has done much PostScript programming knows how awkward it
is to simulate anything resembling local variables.
5. Garbage-collection. Yes.
Note that this was only added in PostScript level 2. In the original
language implementation, memory management had to be done in (I think
itrCOs called) mark-release style, using explicit calls to the rCLsaverCY
and rCLrestorerCY functions.
6. Programs composed of expressions. Not really, but closer than any
of the currently popular languages.
No distinction between rCLstatementsrCY and rCLexpressionsrCY.
7. A symbol type. [...]
True enough.
Java has the option for rCLinternedrCY strings, which is a way of having a symbol type without having a symbol type, if you like.
8. A notation for code using trees of symbols. Yes. The only
difference is that in conventional Lisp theyrCOre binary trees, while
in PostScript theyrCOre N-ary ordered trees.
In Lisp, the tree structure is apparent in the static syntax. In
PostScript, the tree structure (such as it is) gets largely
constructed dynamically at run time, and need not correspond to static
syntax at all.
Given that PostScript clearly hits 8 out of 9 of these criteria, and
arguably all 9, while no then-popular language other than Lisp came
anywhere close, I think itrCOs pretty clear that it mostly belongs to
the Lisp family.
Only insofar as every dynamic language rCLmostly belongs to the Lisp familyrCY.
[...]
the executable bit set by `cvx` is an attribute of references, not
objects.
The same is true of read and write access bits -- except for
dictionaries.
I remember doing some experiments with an Apple LaserWriter and a
Macintosh II back in the late 1980s. Someone had cracked the
encryption of the rCLeexecrCY operator, and we used this to discover that there was this other thing called rCLcexecrCY (only allowed within
encrypted rCLeexecrCY execution, which is why you never saw it in public code) that let you load MC68000 machine code into the printer and hook
into an API provided by the PostScript interpreter to manipulate
PostScript objects and make function calls.
[...] The Macintosh compilers already generated MC68000 machine code,
and I was able to whip up build scripts to link that code into the
right format, with appropriately-set-up header fields, so that the
printer would load and execute it.
Thank you for that wonderful exposition of PostScript, I'm almost tempt-
ed to write my very own P.S. interpreter, but that's going to have to
wait a better time, as I already have n+1 projects.
Best wishes, and happy coaxing Lawrence!
Kragen Javier Sitaker <kragen@canonical.org> writes:
PostScript has several other key similarities to Lisp. Referencing Paul >>Graham's "What Made Lisp Different" <https://paulgraham.com/diff.html>:
Given your claim below that Forth has only #1, #3, #9, let's look at
the others:
2. A function type. rCLIn Lisp, functions are first class objects-- >>theyrCOre 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.rCY
Forth has execution tokens.
4. A new concept of variables. rCLIn 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.rCY
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.
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.
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.
8. A notation for code using trees of symbols. Yes. The only
difference is that in conventional Lisp theyrCOre binary trees, while in >>PostScript theyrCOre 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).
Forth hits #1, #3, and #9.
And also #2, and partially #6, #7, and #8.
Apparently you could typically go for longer than a day before filling
all of memory. Not sure if this was a sign of how large memories had
become by then, or how slow Lisp machines were ...
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:
On Tue, 08 Sep 2026 22:38:58 -0300, Kragen Javier Sitaker wrote:
PostScript does in fact have something like readmacros; in
particular, readhexstring was the recommended way to handle image
data, so that the image data didnrCOt have to be loaded into a
PostScript object by way of the PostScript parser. >> >> ItrCOs just
a function. ItrCOs like saying Python has rCLreadmacrosrCY because >>
the JSON and XML library modules have functions for reading input
ItrCOs a function that runs while the PostScript source code is being
read, which means that it can change the interpretation of that
source code.
YourCOd have to be able to write something in Python which gave you a
session like this:
$ python3
Python 3.11.2 (main, Aug 26 2024, 07:20:54) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from somemodule import typeof
>>> typeof(oagjijgw) # or ideally even without the parentheses
<ast.Name object at 0x7f52bb870130>
I claim that this `typeof` function is impossible to write in
Python, because the parser throws a NameError before `typeof` has a
chance to run, given that I havenrCOt defined `oagjijgw` previously.
Homoiconicity comes in because the function body is stored in an
array object, which is a PostScript language type, and its contents
are also objects of various PostScript language types.
The analogous statements were true of most Lisps in 01982, because
`lambda` was basically implemented as `quote` when it was the
argument of a function (or subr), but they are true of almost no
other programming languages except assembly language, so this is
another similarity between PostScript and Lisp.
However, the analogous statements are not true of most current
Lisps, which have adopted the position that lambda-expressions are
lists, and functions are not lists.
Perhaps you would argue that PostScript is homoiconic and SBCL and
Racket are not. However, most people who know the word do consider
them to be homoiconic, because, even though the *runtime
representation* of functions does not contain objects of various
Lisp language types, the *source code* is just a Lisp list, so
building Lisp code in Lisp is easy:
Unfortunately, this definition of homoiconicity suggests that any
language compiled from sequences of characters is rCLhomoiconicrCY
unless for some reason it lacks the ability to manipulate sequences
of characters.
But, look again at PGrCOs explanation of what he means by rCLa function typerCY:
rCLIn Lisp, functions are first class objects-- theyrCOre 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.rCY
The only one of these that plausibly relates to homoiconicity is
rCLhave a literal representationrCY. In old Lisps you could just print
out the definition of any function as an S-expression, but, as we
see above with Racket, that is not currently the case; we get
something like `#<FUNCTION (LAMBDA ()) {534960EB}>` or
`#<procedure>`. But thatrCOs still a string representation! And *most* languages don't have the ability to print out, for example, struct
literals.
Where PostScript is lacking is in missing support for lexical
binding. Anybody who has done much PostScript programming knows how
awkward it is to simulate anything resembling local variables.
This is another similarity between PostScript and the then-popular
Lisps, which almost entirely used dynamic scope like PostScript,
rather than lexical scope like almost all other programming
languages. However, it is true that the facility is more convenient
to use in Lisp.
HererCOs a slightly reformatted interactive session showing how
awkward it is to simulate anything resembling local variables, in
case anyone is curious:
...
This is definitely more awkward than in most languages, but it
doesnrCOt seem prohibitive to me.
7. A symbol type. [...]
True enough.
Java has the option for rCLinternedrCY strings, which is a way of having a >> symbol type without having a symbol type, if you like.
ThatrCOs true, and in particular thatrCOs useful if yourCOre implementing some
kind of language parser or interpreter in Java. Python has this too.
8. A notation for code using trees of symbols. Yes. The only
difference is that in conventional Lisp theyrCOre binary trees, while
in PostScript theyrCOre N-ary ordered trees.
In Lisp, the tree structure is apparent in the static syntax. In
PostScript, the tree structure (such as it is) gets largely
constructed dynamically at run time, and need not correspond to
static syntax at all.
IrCOm not sure I agree. HererCOs my example of tree-structured code in PostScript, from the previous post:
GS>/sign {dup 0 gt {pop /positive} {0 lt {/negative} {/zero} ifelse} ifelse} def
This is an executable array of six things, the fourth of which is `{pop /positive}`. To me, thatrCOs *more* apparent from the static syntax than
the fact that in `(lambda (x y) (sqrt (+ (* x x) (* y y))))` the car of
the car of the cdr of the cdr is `sqrt`.
I remember doing some experiments with an Apple LaserWriter and a
Macintosh II back in the late 1980s. Someone had cracked the
encryption of the rCLeexecrCY operator, and we used this to discover
that there was this other thing called rCLcexecrCY (only allowed within
encrypted rCLeexecrCY execution, which is why you never saw it in
public code) that let you load MC68000 machine code into the
printer and hook into an API provided by the PostScript interpreter
to manipulate PostScript objects and make function calls.
Wow, thatrCOs amazing! I only ever knew that there was some
controversy about extracting fonts. Maybe this is how it was done?
In comp.lang.forth albert@spenarnc.xs4all.nl wrote:
In article <117r5b2$u52n$5@dont-email.me>,
Lawrence D|+Oliveiro <ldo@nz.invalid> wrote:
<SNIP>
That|o??s a limited form of read-only introspection. You couldn|o??t do >>>transformations on the AST or such, could you? For a start, that would >>>require dynamic memory allocation, which Forth doesn|o??t have.
Infinite memory is as good as dynamic memory. I can expand my Forth
to e.g. 128 Gbyte that is for all practical purposes infinite.
Maybe it is enough for use with Forth. I have a computation that
runs out of memory in IIRC 100 GB. I do not think giving it full
128 GB would make a big difference. OTOH I am pretty sure that
this computation is finite, I simply do not know how much it
needs, maybe 256 GB, maybe terabyte.
More important, if you do not reclaim memory you eventually will
run out of it. And modern processors are fast, so it can happen
faster than you suspect. Of course, this is matter of programming
style. In Lisp program when I monitor memory use I see gigabytes
allocated in seconds. Without GC after few minutes all 128 GB
that I have would be gone.
----
Waldek Hebisch
On Wed, 09 Sep 2026 14:42:10 +0200, albert wrote:
On Wed, 9 Sep 2026 08:28:18 -0000 (UTC), Lawrence DrCOOliveiro wrote:
ThatrCOs a limited form of read-only introspection. You couldnrCOt do
transformations on the AST or such, could you? For a start, that
would require dynamic memory allocation, which Forth doesnrCOt have.
Infinite memory is as good as dynamic memory. I can expand my Forth
to e.g. 128 Gbyte that is for all practical purposes infinite. Then
it is a small change to use ALLOCATE that is not in the kernel of my
Forth, but it is a loadable extension.
Interestingly enough, some Lisp machines behaved in a similar way.
They lacked garbage collection. After memory became full, you took a
snapshot of all the live objects in your machine state, and rebooted. >Reloading the snapshot left all the garbage behind, so you were able
to resume work from there, until memory filled up again.
Apparently you could typically go for longer than a day before filling
all of memory. Not sure if this was a sign of how large memories had
become by then, or how slow Lisp machines were ...
Still, you get the point that thatrCOs a crude way of managing memory.
It is not good for handling long-running tasks.
Also on modern multitasking systems, you might need to be running
other things simultaneously, besides your Forth or Lisp program. So
having the one process hog all available resources is ... not very
sociable.
(Apologies if this sounds like AI slop; IrCOve been interacting with
Claude Opus 5 a lot today, and although I didnrCOt use any LLM to write
any of this, its voice may be leaking into mine.)
Forth is not strongly-typed. IrCOm not aware of any high-level dynamic language that is not strongly-typed. At a bare minimum, you need to
know what value is a pointer and what isnrCOt, otherwise memory
management is not going to be a happy business.
Lawrence DrCOOliveiro <ldo@nz.invalid> writes:<snip>
On Tue, 08 Sep 2026 22:38:58 -0300, Kragen Javier Sitaker wrote:
But, look again at PGrCOs explanation of what he means by rCLa function typerCY:2. A function type. rCLIn Lisp, functions are first class objects-- [...] <snip>
rCLIn Lisp, functions are first class objects-- theyrCOre 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.rCY
The only one of these that plausibly relates to homoiconicity is rCLhave a literal representationrCY. In old Lisps you could just print out the definition of any function as an S-expression, but, as we see above with Racket, that is not currently the case; we get something like
`#<FUNCTION (LAMBDA ()) {534960EB}>` or `#<procedure>`. But thatrCOs
still a string representation! And *most* languages don't have the
ability to print out, for example, struct literals.
What makes a rCLstring literalrCY or rCLinteger literalrCY a *literal* is that
you can put it in your source code without having to give it a name.
So the most plausible gloss of PGrCOs rCLhas a literal representationrCY is that there are Lisp expressions which create new functions when
evaluated, which is just as true of modern Common Lisp and Scheme as it
was of Franz Lisp in 01982. And itrCOs obviously true of PostScript, but
not of C, Pascal, BASIC, etc.
In PG writing things are presented in specific way because of his
agenda: he wants to show that Lisp is a "top point" of developement of programming languages.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 122:20:47 |
| Calls: | 1,194 |
| Files: | 1,352 |
| Messages: | 290,355 |