Hi Forthers,

I've just added a new PDF file for your enjoyment :

https://www.inventio.co.uk/colorforth/colorForth_and_Object_Oriented_Programming.pdf

Also available from here : https://www.inventio.co.uk/colorforth .

Enjoy :-)

Howerd

Regarding OOP-ization of Forth (if at all) I'd like to suggest
„delegation” model rather than that „classic” one (with its
„polymorphism”, „inheritance” and similar „extras”).

„Delegation” model of OOP is way more comprehensible and
practical.

Oh, I forgot to add an example: the good example
is „snit” TCL package:
https://core.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/www/tcllib/files/modules/snit/snit.html

Zbig schrieb am Dienstag, 5. September 2023 um 10:39:43 UTC+2:
> Oh, I forgot to add an example: the good example
> is „snit” TCL package:
> https://core.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/www/tcllib/files/modules/snit/snit.html

Can you show a practical performance benchmark
against one of the established Forth OOP extensions
like SWOOP or FMS2?

> > Oh, I forgot to add an example: the good example
> > is „snit” TCL package:
> > https://core.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/www/tcllib/files/modules/snit/snit.html
> Can you show a practical performance benchmark
> against one of the established Forth OOP extensions
> like SWOOP or FMS2?

„Apples to oranges”.

What will tell you „performance benchmark” of an OOP package
prepared not just for different implementation, but for
completely different programming language?

No, I don't have such benchmark — and TCL itself is well-known
not being top-performer among scripting languages. Which doesn't
say anything about „delegation” model of OOP.

Zbig schrieb am Dienstag, 5. September 2023 um 11:01:50 UTC+2:
> > > Oh, I forgot to add an example: the good example
> > > is „snit” TCL package:
> > > https://core.tcl-lang.org/tcllib/doc/tcllib-1-18/embedded/www/tcllib/files/modules/snit/snit.html
> > Can you show a practical performance benchmark
> > against one of the established Forth OOP extensions
> > like SWOOP or FMS2?
> „Apples to oranges”.
>
> What will tell you „performance benchmark” of an OOP package
> prepared not just for different implementation, but for
> completely different programming language?
>
> No, I don't have such benchmark — and TCL itself is well-known
> not being top-performer among scripting languages. Which doesn't
> say anything about „delegation” model of OOP.

Fair enough.
In your earlier post you wrote "..regarding OOP-ization of Forth I'd suggest.."
so I asked if you had experienced any benefits to support your suggestion.
But question answered.

No, I didn't even try to prepare anything like this for Forth;
I simply feel no need to do Forth more OOP-ed than its
„standard” tools (like CREATE DOES) allowed since years.

In article <51560991-9547-45ba-bccc-6c87489e119an@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
>No, I didn't even try to prepare anything like this for Forth;
>I simply feel no need to do Forth more OOP-ed than its
>„standard” tools (like CREATE DOES) allowed since years.

I feel almost the same way. My class is in fact create/does>
with multiple named does>es. It takes one screen, two screens
if you count the FORMAT&EVAL it uses.

It is instrumental in more sophisticated programs like manx and
ciasdis. I have put a challenge out, to explain me why inheritance
would benifit those programs. So far, nothing.

Referring to tcl is not sufficient, to go study it.
A few examples that this style of programming is valuable could
do it.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

> Referring to tcl is not sufficient, to go study it.
> A few examples that this style of programming is valuable could
> do it.

Several examples — of course, TCL examples — are on the linked
„snit” page.

Zbig schrieb am Dienstag, 5. September 2023 um 11:26:41 UTC+2:
> No, I didn't even try to prepare anything like this for Forth;
> I simply feel no need to do Forth more OOP-ed than its
> „standard” tools (like CREATE DOES) allowed since years.

Dick Pountain once wrote a whole book about object-oriented Forth
by stacking several CREATE DOES (BUILDS) structures over
each other. I found it rather intriguing at that time, although
many OO purists rejected it.

In article <ad83ae87-cdc2-492a-9db3-d25a86a0ce90n@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
>> Referring to tcl is not sufficient, to go study it.
>> A few examples that this style of programming is valuable could
>> do it.
>
>Several examples — of course, TCL examples — are on the linked
>„snit” page.

Sorry. You have to do better than merely mentionning a web page
before I looked into it.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <50d59e0f-c2bb-4d13-9062-fae74a9a348fn@googlegroups.com>,
minforth <minforth@arcor.de> wrote:
>Zbig schrieb am Dienstag, 5. September 2023 um 11:26:41 UTC+2:
>> No, I didn't even try to prepare anything like this for Forth;
>> I simply feel no need to do Forth more OOP-ed than its
>> „standard” tools (like CREATE DOES) allowed since years.
>
>Dick Pountain once wrote a whole book about object-oriented Forth
>by stacking several CREATE DOES (BUILDS) structures over
>each other. I found it rather intriguing at that time, although
>many OO purists rejected it.

I have studied the book. My conclusion was that he try to manage
a "me too", but failed to present convincing examples why you
would need it.
For example my ciasdis reverse engineers the 64 bit AMD ciforth
to a symbolic assembler program that can be relocated and
changed. That only uses a one screen oop extension.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

minforth <minforth@arcor.de> writes:
>Dick Pountain once wrote a whole book about object-oriented Forth
>by stacking several CREATE DOES (BUILDS) structures over
>each other. I found it rather intriguing at that time, although
>many OO purists rejected it.

Not sure what an OO purist is.

Anyway, I have read the book, and found it interesting at the time.
But the more I learned about object-oriented programming, the more I
found that Pountain mostly missed the point. The essential part of
OOP is run-time polymorphism (dynamic binding). Most of the book does
not deal with this feature at all; IIRC only the last chapter even
concerns itself with this topic, and it does so in a clumsy and
inefficient way. So this book has rightly been ignored by everyone
who really implemented and used OOP in Forth.

If you want to see how a minimalistic OOP package in Forth can look
like, look at <https://bernd-paysan.de/mini-oof.html>.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

Anton Ertl schrieb am Donnerstag, 7. September 2023 um 09:48:30 UTC+2:
> Anyway, I have read the book, and found it interesting at the time.
> But the more I learned about object-oriented programming, the more I
> found that Pountain mostly missed the point. The essential part of
> OOP is run-time polymorphism (dynamic binding). Most of the book does
> not deal with this feature at all; IIRC only the last chapter even
> concerns itself with this topic, and it does so in a clumsy and
> inefficient way. So this book has rightly been ignored by everyone
> who really implemented and used OOP in Forth.

Static polymorphism is limited indeed. But sufficient for many applications.
I wouldn't rule it out of the toolbox.
AFAIK C++ offers both: dynamic and static polymorphism.

minforth <minforth@arcor.de> writes:
>Static polymorphism is limited indeed. But sufficient for many applications.
>I wouldn't rule it out of the toolbox.

The programmers can do the static resolution themselves rather than
burdening the compiler with it. E.g., instead of having an overloaded
@, Forth has @ C@ 2@ F@. Similarly, for <: < U< D< DU< F<.

Standard Forth resolves overloading for TO: it works for VALUE,
2VALUE, and FVALUE. This is the target of repeated criticism of being
unforthy, but it has practical advantages.

The difference here is that words like @ and < receive their arguments
in the stack at run-time, without type information (in standard
Forth), so there is no way the system could resolve an overloaded @ or
<. By contrast, TO sees the name at compile time, and it can be
resolved at compile time using knowledge about the word it is used on.

>AFAIK C++ offers both: dynamic and static polymorphism.

Even C performs overloading resolution of built-in operators
(including < and unary *). C++ also allows user-defined overloading.
But both languages have static type information, which makes this
possible (and looking at the history of C, C added static type
information to B in order to deal with chars (bytes) and char pointers
when Thompson and Ritchie switched from the word-addressed PDP-7 to
the byte-addressed PDP-11).

Forth does not have this, and attempts to perform overloading
resolution in Forth have typically come out very messy, with
STATE-smartness and other atrocities everywhere. Now, after 40 years,
we know how to implement TO alone relatively cleanly, but as soon as
we add +TO and friends, it again becomes messy.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <2023Sep8.101243@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>
>Forth does not have this, and attempts to perform overloading
>resolution in Forth have typically come out very messy, with
>STATE-smartness and other atrocities everywhere. Now, after 40 years,
>we know how to implement TO alone relatively cleanly, but as soon as
>we add +TO and friends, it again becomes messy.

I was not a great fan of it, but Marcel Hendrix succeeded in adding
a number of +TO FROM etc to the transputer Forth.
This applied to VALUEs DVALUEs FLOATs DFLOATs LOCALs DLOCALs alike
and I must admit they are practical.
Probably descendants of this are present in iforth.
I came to look at it as a message form of object orientation, and
documented it as such in the tForth documentation I wrote.
It contributed to the speed of tForth.

>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Thursday, September 7, 2023 at 9:48:30 AM UTC+2, Anton Ertl wrote:
> minforth <minf...@arcor.de> writes:
> >Dick Pountain once wrote a whole book about object-oriented Forth
> >by stacking several CREATE DOES (BUILDS) structures over
> >each other. I found it rather intriguing at that time, although
> >many OO purists rejected it.
> Not sure what an OO purist is.
>
> Anyway, I have read the book, and found it interesting at the time.
> But the more I learned about object-oriented programming, the more I
> found that Pountain mostly missed the point. The essential part of
> OOP is run-time polymorphism (dynamic binding). Most of the book does
> not deal with this feature at all; IIRC only the last chapter even
> concerns itself with this topic, and it does so in a clumsy and
> inefficient way. So this book has rightly been ignored by everyone
> who really implemented and used OOP in Forth.
>
> If you want to see how a minimalistic OOP package in Forth can look
> like, look at <https://bernd-paysan.de/mini-oof.html>.
>
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: https://forth-standard.org/
> EuroForth 2023: https://euro.theforth.net/2023
Hi Anton,
You say "The essential part of OOP is run-time polymorphism", and I think you are right, in that what many ideas like OOP are trying to do is to get back some dynamic functionality, after it has been nailed down as static by one or other of the batch processing languages.
I find it interesting that the Udemy course that I just took (mainly so I could speak to my colleagues in the language they were using) does not mention run-time polymorphism, nor any sort of binding, run-time, compile time etc.
This confirms my theory that "Object Oriented Programming" is a marketing concept that can mean whatever you want it to mean ;-)

Cheers,
Howerd

On 9/09/2023 4:45 am, Howerd wrote:
> On Thursday, September 7, 2023 at 9:48:30 AM UTC+2, Anton Ertl wrote:
>> minforth <minf...@arcor.de> writes:
>>> Dick Pountain once wrote a whole book about object-oriented Forth
>>> by stacking several CREATE DOES (BUILDS) structures over
>>> each other. I found it rather intriguing at that time, although
>>> many OO purists rejected it.
>> Not sure what an OO purist is.
>>
>> Anyway, I have read the book, and found it interesting at the time.
>> But the more I learned about object-oriented programming, the more I
>> found that Pountain mostly missed the point. The essential part of
>> OOP is run-time polymorphism (dynamic binding). Most of the book does
>> not deal with this feature at all; IIRC only the last chapter even
>> concerns itself with this topic, and it does so in a clumsy and
>> inefficient way. So this book has rightly been ignored by everyone
>> who really implemented and used OOP in Forth.
>>
>> If you want to see how a minimalistic OOP package in Forth can look
>> like, look at <https://bernd-paysan.de/mini-oof.html>.
>>
>> - anton
>> --
>> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
>> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>> New standard: https://forth-standard.org/
>> EuroForth 2023: https://euro.theforth.net/2023
> Hi Anton,
> You say "The essential part of OOP is run-time polymorphism", and I think you are right, in that what many ideas like OOP are trying to do is to get back some dynamic functionality, after it has been nailed down as static by one or other of the batch processing languages.
> I find it interesting that the Udemy course that I just took (mainly so I could speak to my colleagues in the language they were using) does not mention run-time polymorphism, nor any sort of binding, run-time, compile time etc.
> This confirms my theory that "Object Oriented Programming" is a marketing concept that can mean whatever you want it to mean ;-)

Motivations are everything. Pountain's motivation appears to have been
making Forth more popular:

"This book is about making Forth more generally useful than it already is;
it is an attempt to break out of the engineering and hardware development
ghetto in which Forth has so far prospered."

In short, he saw Forth in negative terms and believed it could do with a
face-lift. He may not be alone.

Howerd <howerdo@yahoo.co.uk> writes:
>You say "The essential part of OOP is run-time polymorphism", and I think y=
>ou are right, in that what many ideas like OOP are trying to do is to get b=
>ack some dynamic functionality, after it has been nailed down as static by =
>one or other of the batch processing languages.

I don't think so. Simula-67, C++, and Java embrace static
type-checking and the separation of compile time and run time. They
add dynamic dispatch not to get back something, but as a statically
safe way to attack problems whose existence is denied or treated as
irrelevant by those in clf who deny the value of OOP.

>I find it interesting that the Udemy course that I just took (mainly so I c=
>ould speak to my colleagues in the language they were using) does not menti=
>on run-time polymorphism, nor any sort of binding, run-time, compile time e=
>tc.
>This confirms my theory that "Object Oriented Programming" is a marketing c=
>oncept that can mean whatever you want it to mean ;-)

That's true of any popular term; Humpty Dumpty knew that. A few days
ago, I heard or read the story of an Evangelical Christian who reacted
to a story about Jesus read to her from the Holy Bible with something
along the lines that Jesus was far too left-wing.

Still we use terms with common meaning, not with Humpty Dumpty's
meaning. E.g., we look at Wikepdia what they mean.

Concerning OOP,
<https://en.wikipedia.org/wiki/Object-oriented_programming#Features>
lists a large number of features, but many of them tend to be not
universal. In the old times, I have seen definitions of
"object-oriented" that only listed three (in one case) or four (in
another definition) features that are necessary for an OO language. I
don't remember them all, but I think that classes, inheritance, and
garbage collection were listed.

* Prototype-based OO languages (e.g., Self, JavaScript) do without
classes.

* My collegue who teaches object-oriented programming recommends to
avoid inheritance, because inheritance often seduces the programmer
to violate Liskov's substitution principle.

* C++ does without garbage collection and the Wikipedia link above
does not list garbage collection.

While many OO languages have many features listed in Wikipedia as
features, maybe because they are useful for the goals of the
programming language, maybe because the languages that inspired the
new one have it (e.g., inheritance), the question a Forther may ask
themselves is: What is the essential feature. And my answer to that
is: dynamic dispatch.

An example is the Unix VFS (virtual file system) interface. When you
do, say, a read() system call, it is dynamically dispatched to the
actual file system of the file you are accessing. You can consider
the file system type as the class of the file system; there is no
inheritance, not even when a file system is actually derived from
another one (e.g. ext4 is derived from ext2). And there is no garbage
collection. And it's all written in C.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

On Friday, September 8, 2023 at 11:45:07 AM UTC-7, Howerd wrote:
> On Thursday, September 7, 2023 at 9:48:30 AM UTC+2, Anton Ertl wrote:
> > minforth <minf...@arcor.de> writes:
> > >Dick Pountain once wrote a whole book about object-oriented Forth
> > >by stacking several CREATE DOES (BUILDS) structures over
> > >each other. I found it rather intriguing at that time, although
> > >many OO purists rejected it.
> > Not sure what an OO purist is.
> >
> > Anyway, I have read the book, and found it interesting at the time.
> > But the more I learned about object-oriented programming, the more I
> > found that Pountain mostly missed the point. The essential part of
> > OOP is run-time polymorphism (dynamic binding). Most of the book does
> > not deal with this feature at all; IIRC only the last chapter even
> > concerns itself with this topic, and it does so in a clumsy and
> > inefficient way. So this book has rightly been ignored by everyone
> > who really implemented and used OOP in Forth.
> >
> > If you want to see how a minimalistic OOP package in Forth can look
> > like, look at <https://bernd-paysan.de/mini-oof.html>.
> >
> > - anton
> > --
> > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> > comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> > New standard: https://forth-standard.org/
> > EuroForth 2023: https://euro.theforth.net/2023
> Hi Anton,
> You say "The essential part of OOP is run-time polymorphism", and I think you are right, in that what many ideas like OOP are trying to do is to get back some dynamic functionality, after it has been nailed down as static by one or other of the batch processing languages.
> I find it interesting that the Udemy course that I just took (mainly so I could speak to my colleagues in the language they were using) does not mention run-time polymorphism, nor any sort of binding, run-time, compile time etc.
> This confirms my theory that "Object Oriented Programming" is a marketing concept that can mean whatever you want it to mean ;-)
>
> Cheers,
> Howerd

I agree with the statement "The essential part of OOP is run-time polymorphism". I think there is definitely a use case in Forth for run-time polymorphism, but I also think it is kind of rare.

Years ago, the Whitewater Group developed a really cool proprietary language called Actor (along with some other great stuff) that had lots of great ideas that basically evolved Smalltalk up to the next level. One of those ideas was selectively being able to label functions as Static or Dynamic, which allowed the compiler to optimize. Unfortunately, the Whitewater Group was purchased by Borland for their Windows abstraction layer and they killed Actor.

I dropped out of the initial ANSI efforts in 1990 in order to go teach at the University of Zimbabwe, where one of the courses I taught was Object Oriented Programming with Actor. The Whitewater Group was kind enough to provide me with all sorts of materials and free licenses for students. It was really well received and when Borland dropped it, I contacted the Product Manager. She told me that Borland had decided to focus on C++ and had dropped Actor because it competed with it. Really sad.

So, back to Forth, I am all in favor of having Object Oriented extensions that I could plug into a “standard” Forth without having to rewrite them from scratch.

Back to lurk mode,
Ron Braithwaite

On 10/09/2023 1:29 am, Anton Ertl wrote:
> Howerd <howerdo@yahoo.co.uk> writes:
>> You say "The essential part of OOP is run-time polymorphism", and I think y=
>> ou are right, in that what many ideas like OOP are trying to do is to get b=
>> ack some dynamic functionality, after it has been nailed down as static by =
>> one or other of the batch processing languages.
>
> I don't think so. Simula-67, C++, and Java embrace static
> type-checking and the separation of compile time and run time. They
> add dynamic dispatch not to get back something, but as a statically
> safe way to attack problems whose existence is denied or treated as
> irrelevant by those in clf who deny the value of OOP.
>
>> I find it interesting that the Udemy course that I just took (mainly so I c=
>> ould speak to my colleagues in the language they were using) does not menti=
>> on run-time polymorphism, nor any sort of binding, run-time, compile time e=
>> tc.
>> This confirms my theory that "Object Oriented Programming" is a marketing c=
>> oncept that can mean whatever you want it to mean ;-)
>
> That's true of any popular term; Humpty Dumpty knew that. A few days
> ago, I heard or read the story of an Evangelical Christian who reacted
> to a story about Jesus read to her from the Holy Bible with something
> along the lines that Jesus was far too left-wing.
>
> Still we use terms with common meaning, not with Humpty Dumpty's
> meaning. E.g., we look at Wikepdia what they mean.

Wikipedia is more than common meaning. It has set itself up as authority.
The OOP page includes Leo Brodie's criticism from 'Thinking FORTH' (another
authority apparently). This was too much for one reader (see Talk page)
who took the view only criticism from 'recognized' authorities be used - if
at all.

On Saturday, September 9, 2023 at 6:33:32 PM UTC+2, Anton Ertl wrote:
> Howerd <how...@yahoo.co.uk> writes:
> >You say "The essential part of OOP is run-time polymorphism", and I think y=
> >ou are right, in that what many ideas like OOP are trying to do is to get b=
> >ack some dynamic functionality, after it has been nailed down as static by > >one or other of the batch processing languages.
> I don't think so. Simula-67, C++, and Java embrace static
> type-checking and the separation of compile time and run time. They
> add dynamic dispatch not to get back something, but as a statically
> safe way to attack problems whose existence is denied or treated as
> irrelevant by those in clf who deny the value of OOP.
>
> >I find it interesting that the Udemy course that I just took (mainly so I c=
> >ould speak to my colleagues in the language they were using) does not menti=
> >on run-time polymorphism, nor any sort of binding, run-time, compile time e=
> >tc.
> >This confirms my theory that "Object Oriented Programming" is a marketing c> >oncept that can mean whatever you want it to mean ;-)
> That's true of any popular term; Humpty Dumpty knew that. A few days
> ago, I heard or read the story of an Evangelical Christian who reacted
> to a story about Jesus read to her from the Holy Bible with something
> along the lines that Jesus was far too left-wing.
>
> Still we use terms with common meaning, not with Humpty Dumpty's
> meaning. E.g., we look at Wikepdia what they mean.
>
> Concerning OOP,
> <https://en.wikipedia.org/wiki/Object-oriented_programming#Features>
> lists a large number of features, but many of them tend to be not
> universal. In the old times, I have seen definitions of
> "object-oriented" that only listed three (in one case) or four (in
> another definition) features that are necessary for an OO language. I
> don't remember them all, but I think that classes, inheritance, and
> garbage collection were listed.
>
> * Prototype-based OO languages (e.g., Self, JavaScript) do without
> classes.
>
> * My collegue who teaches object-oriented programming recommends to
> avoid inheritance, because inheritance often seduces the programmer
> to violate Liskov's substitution principle.
>
> * C++ does without garbage collection and the Wikipedia link above
> does not list garbage collection.
>
> While many OO languages have many features listed in Wikipedia as
> features, maybe because they are useful for the goals of the
> programming language, maybe because the languages that inspired the
> new one have it (e.g., inheritance), the question a Forther may ask
> themselves is: What is the essential feature. And my answer to that
> is: dynamic dispatch.
>
> An example is the Unix VFS (virtual file system) interface. When you
> do, say, a read() system call, it is dynamically dispatched to the
> actual file system of the file you are accessing. You can consider
> the file system type as the class of the file system; there is no
> inheritance, not even when a file system is actually derived from
> another one (e.g. ext4 is derived from ext2). And there is no garbage
> collection. And it's all written in C.
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: https://forth-standard.org/
> EuroForth 2023: https://euro.theforth.net/2023
Hi Anton,

An excellent summary. Has anyone compiled a list of the way OO Languages use and define OO?
It would be good to see the features and requirements listed for the popular OO languages, all on one page...

BR
Howerd

On 10/09/2023 12:34 pm, Howerd wrote:
>
> An excellent summary. Has anyone compiled a list of the way OO Languages use and define OO?
> It would be good to see the features and requirements listed for the popular OO languages, all on one page...

A run-down of Forth implementations from 1996:

https://www.bradrodriguez.com/papers/oofs.htm

Howerd <howerdo@yahoo.co.uk> writes:
>An excellent summary. Has anyone compiled a list of the way OO Languages us=
>e and define OO?

Yes, a checkbox table might have been helpful to support (or
undermine) my claim that dynamic dispatch is essential, but
<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(object-oriented_programming)>
shows the various syntaxes that the different languages use for the
features. OTOH, showing the syntax probably allows a more
differentiated view than a yes/no checkbox.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

In article <eec8dfed-8c45-4f0e-aace-17dade9c6f29n@googlegroups.com>,
Ron Braithwaite <ron@softwareengineeringllc.com> wrote:
<SNIP>

>I agree with the statement "The essential part of OOP is run-time
>polymorphism". I think there is definitely a use case in Forth for
>run-time polymorphism, but I also think it is kind of rare.

I take a practical stand, and don't want argue principles too much.
But what to think of my specification of my QSORT

8 \ Sort the range FIRST to LAST (inclusive) of item compared
9 \ by the xt COMPARING and exchanged by the xt EXHANGING.
10 \ The xt's are filled in into *< and *<--> and must observe the
11 \ interface. All indices be compatible with these xt's.
12 \ After the call we have that :
13 \ ``For FIRST<=I<J<=LAST I J *< EXECUTE leaves TRUE.''

This restricts the items to be sorted in no way.
If this count as polymorphism, I don't think is rare.
(My MERGESORT is also general, but based on the existance of link
fields.)

>
>Years ago, the Whitewater Group developed a really cool proprietary
>language called Actor (along with some other great stuff) that had lots of
>great ideas that basically evolved Smalltalk up to the next level. One of
>those ideas was selectively being able to label functions as Static or
>Dynamic, which allowed the compiler to optimize. Unfortunately, the
>Whitewater Group was purchased by Borland for their Windows abstraction
>layer and they killed Actor.

They destroyed the code base? That is bad.
This strive for monopoly instead of competition make the Western
economy loose compared to China.

<SNIP>
>
>Back to lurk mode,
>Ron Braithwaite
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -