OOP usage in Forth today

[minf...@arcor.de]

I'd like to read more from users who program real object-oriented Forth
applications.

The OOF hype of 10-15 years ago has subsided, standardization did not
find support, and various implementations seem to gather dust
on their shelves. From mini-oof to Swoop to FMS, just to name a few.

I am not interested in reviving dead-beaten debates. But perhaps time and
experience have given new viewpoints and preferences.

Implementation-wise I had once been experimenting with wordlist entries
in headers (not only for classes) but dropped it due to other priorities
at that time. Before I take this stuff up again I'd like to read other opinions
about good namespace management techniques.

[none albert]

In article <f4cb32af-52d0-4a5b...@googlegroups.com>,

minf...@arcor.de <minf...@arcor.de> wrote:
>I'd like to read more from users who program real object-oriented Forth
>applications.

You can download the cvs archive of manx 2 from my site below
in particular manx.tar.gz.
It is object oriented as hell.
It uses 7 classes, but it could use more.
It is a substantial program, playing multiple part music,polyphonic,on
multiple instruments, driven by a musical score that is essentially
a Forth program.

Moreover I testify that I couldn't pull it off, barring object
oriented techniques.

The oo package fits in one screen, and pulls in 2 auxiliary screens,
to wit an alternative compilation area, and string formatting.

>The OOF hype of 10-15 years ago has subsided, standardization did not
>find support, and various implementations seem to gather dust
>on their shelves. From mini-oof to Swoop to FMS, just to name a few.

Most Forthers jump to the opportunity to implement another tool
that they never use. I implemented the bare minimum that I needed.
Bernd Paysan seems to use his own oo-package too.

<SNIP>

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:
>I'd like to read more from users who program real object-oriented Forth
>applications.

Gforth uses an object-oriented header [paysan&ertl19].

You can also find minos2 in the Gforth source, which uses mini-oof2 as
object-oriented system.

>Before I take this stuff up again I'd like to read other opinions
>about good namespace management techniques.

Object orientation is not about name space management, it's about
polymorphism (dynamic dispatch).

- anton

@InProceedings{paysan&ertl19,
author = {Bernd Paysan and M. Anton Ertl},
title = {The new {Gforth} Header},
crossref = {euroforth19},
pages = {5--20},
url = {http://www.euroforth.org/ef19/papers/paysan.pdf},
url-slides = {http://www.euroforth.org/ef19/papers/paysan-slides.pdf},
video = {https://wiki.forth-ev.de/doku.php/events:ef2019:header},
OPTnote = {refereed},
abstract = {The new Gforth header is designed to directly
implement the requirements of Forth-94 and
Forth-2012. Every header is an object with a fixed
set of fields (code, parameter, count, name, link)
and methods (\texttt{execute}, \texttt{compile,},
\texttt{(to)}, \texttt{defer@}, \texttt{does},
\texttt{name>interpret}, \texttt{name>compile},
\texttt{name>string}, \texttt{name>link}). The
implementation of each method can be changed
per-word (prototype-based object-oriented
programming). We demonstrate how to use these
features to implement optimization of constants,
\texttt{fvalue}, \texttt{defer}, \texttt{immediate},
\texttt{to} and other dual-semantics words, and
\texttt{synonym}.}
}

@Proceedings{euroforth19,
title = {35th EuroForth Conference},
booktitle = {35th EuroForth Conference},
year = {2019},
key = {EuroForth'19},
url = {http://www.euroforth.org/ef19/papers/proceedings.pdf}
}

--
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 2022: https://euro.theforth.net

[minf...@arcor.de]

none albert schrieb am Dienstag, 15. November 2022 um 14:57:50 UTC+1:
> In article <f4cb32af-52d0-4a5b...@googlegroups.com>,
> minf...@arcor.de <minf...@arcor.de> wrote:
> >I'd like to read more from users who program real object-oriented Forth
> >applications.
> You can download the cvs archive of manx 2 from my site below
> in particular manx.tar.gz.
> It is object oriented as hell.
> It uses 7 classes, but it could use more.
> It is a substantial program, playing multiple part music,polyphonic,on
> multiple instruments, driven by a musical score that is essentially
> a Forth program.
>
> Moreover I testify that I couldn't pull it off, barring object
> oriented techniques.
>
> The oo package fits in one screen, and pulls in 2 auxiliary screens,
> to wit an alternative compilation area, and string formatting.

Thanks, manx is an impressive piece of work. I really liked the
repertoire that reminded me of church carillon / glockenspiel charts.

[minf...@arcor.de]

Anton Ertl schrieb am Dienstag, 15. November 2022 um 19:16:34 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >I'd like to read more from users who program real object-oriented Forth
> >applications.
> Gforth uses an object-oriented header [paysan&ertl19].

AFAIU this is a hand-crafted prototype scheme without generic OOP wordset.
When reading the report I was wondering whether I would go to such lengths.
But I am not crtiticizing, research and exploration are the practical means for
progress.

> You can also find minos2 in the Gforth source, which uses mini-oof2 as
> object-oriented system.

So Minos places all objects into the dictionary. Of course, GUI programming
does not create large object pools in heap memory.

> >Before I take this stuff up again I'd like to read other opinions
> >about good namespace management techniques.
> Object orientation is not about name space management, it's about
> polymorphism (dynamic dispatch).

You are right, pardon my poor layman wording. ;-)

(I had been experimenting with hash lists for method overriding, the lists were
scanned whenever SEARCH-WORDLIST found a class/0bject addressing
an ivar/method)

[Doug Hoffman]

On Tuesday, November 15, 2022 at 8:29:31 AM UTC-5, minf...@arcor.de wrote:
> I'd like to read more from users who program real object-oriented Forth
> applications.

I haven't written anything that, e.g., uses objects to play music. My use has
always been for myself and has focussed on formatting raw data
(from data loggers) and analyzing the same. I posted the objects extension
I use on GitHub in case anyone else is interested in it.
https://github.com/DouglasBHoffman/FMS2
But I think most Forthers either write their own OOF or dismiss OOP entirely.

Back in the 1980s and 1990s the Yerk objects extension was
used at the Yerkes Observatory to control telescopes and process
images received by the scopes. Yerk was a close derivative of Neon.
I also liked most of the characteristics of Neon and kept many of
them for FMS.

> The OOF hype of 10-15 years ago has subsided, standardization did not
> find support, and various implementations seem to gather dust
> on their shelves. From mini-oof to Swoop to FMS, just to name a few.

From Chuck Moore: "I created an object in Forth called the month.
And this object had a starting point and a year and the number of days
and stuff like that. This is back, back very early. That's the only object
I've ever done and it was useless. ... So I think object oriented programming
is a mistake." ;-)

> I am not interested in reviving dead-beaten debates. But perhaps time and
> experience have given new viewpoints and preferences.
>
> Implementation-wise I had once been experimenting with wordlist entries
> in headers (not only for classes) but dropped it due to other priorities
> at that time. Before I take this stuff up again I'd like to read other opinions
> about good namespace management techniques.

A long time ago Rodriguez & Poehlman put together a summary of the
various OOFs available and their differing characteristics:
http://www.bradrodriguez.com/papers/oofs.htm
That information is almost fully out of date with Mops being
perhaps the only OOF from their comparison still available as far as I know.

I have no strong opinions on what common OOP features
a Forth objects extension should have. I do know what I prefer
and that includes duck typing and encapsulation of instance variables.
By encapsulation I mean in FMS instance variables can only be modified
and accessed using messages sent to the object. Rodriguez & Poehlman
summarize which OOFs had encapsulation and how it was done.
But others don't care at all about this.
I also prefer to have available "objects as instance variables". This is
not the same as storing a pointer to an object in a container slot.

-Doug

[minf...@arcor.de]

Doug Hoffman schrieb am Mittwoch, 16. November 2022 um 00:00:10 UTC+1:
> On Tuesday, November 15, 2022 at 8:29:31 AM UTC-5, minf...@arcor.de wrote:
> > I'd like to read more from users who program real object-oriented Forth
> > applications.
> I haven't written anything that, e.g., uses objects to play music. My use has
> always been for myself and has focussed on formatting raw data
> (from data loggers) and analyzing the same. I posted the objects extension
> I use on GitHub in case anyone else is interested in it.
> https://github.com/DouglasBHoffman/FMS2
> But I think most Forthers either write their own OOF or dismiss OOP entirely.

I think this is true. Many Forthers use their own Forth and an optimized OOF
extension requires internal knowledge and adaptation of the system. Also
there are differences between objects in dictionary (flash memory) and objects
in heap memory (expensive and power-hungry RAM) to be considered.
IOW different applications often require different OOF features.

> Back in the 1980s and 1990s the Yerk objects extension was
> used at the Yerkes Observatory to control telescopes and process
> images received by the scopes. Yerk was a close derivative of Neon.
> I also liked most of the characteristics of Neon and kept many of
> them for FMS.
> > The OOF hype of 10-15 years ago has subsided, standardization did not
> > find support, and various implementations seem to gather dust
> > on their shelves. From mini-oof to Swoop to FMS, just to name a few.
> From Chuck Moore: "I created an object in Forth called the month.
> And this object had a starting point and a year and the number of days
> and stuff like that. This is back, back very early. That's the only object
> I've ever done and it was useless. ... So I think object oriented programming
> is a mistake." ;-)

I always had the (unfounded) impression that his ego was never his weak trait. ;-)
"if it is useless for me, it is useless"

> > I am not interested in reviving dead-beaten debates. But perhaps time and
> > experience have given new viewpoints and preferences.
> >
> > Implementation-wise I had once been experimenting with wordlist entries
> > in headers (not only for classes) but dropped it due to other priorities
> > at that time. Before I take this stuff up again I'd like to read other opinions
> > about good namespace management techniques.
> A long time ago Rodriguez & Poehlman put together a summary of the
> various OOFs available and their differing characteristics:
> http://www.bradrodriguez.com/papers/oofs.htm
> That information is almost fully out of date with Mops being
> perhaps the only OOF from their comparison still available as far as I know.

At that time I had been intrigued by Andras Zsoters essays:
http://ftp.forth.org/literature//oopf.html
http://forth.org/literature/andras.html

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:
>Anton Ertl schrieb am Dienstag, 15. November 2022 um 19:16:34 UTC+1:
>> "minf...@arcor.de" <minf...@arcor.de> writes:
>> >I'd like to read more from users who program real object-oriented Forth
>> >applications.
>> Gforth uses an object-oriented header [paysan&ertl19].
>
>AFAIU this is a hand-crafted prototype scheme without generic OOP wordset.

Correct.

>When reading the report I was wondering whether I would go to such lengths.

Instead of what?

I am certainly happy with the basic approach. I wonder if the
deduplication is worth the complexity given that Gforth works on
machines with enough RAM, but the basic prototype approach is fine
given the existence of words like DOES> and IMMEDIATE that in a
class-based system would change the class of a word.

And given that we don't plan to use other prototype-based OO
applications, a general prototype-based OO wordset would be needless
generalization.

I wonder if we would do even greater things if we made the header
stuff more extensible, but for now that is difficult, because every
extension or change has to be implemented in both the cross compiler
and the Forth system itself.

>> You can also find minos2 in the Gforth source, which uses mini-oof2 as
>> object-oriented system.
>
>So Minos places all objects into the dictionary.

Why do you think so? mini-oof2 certainly supports allocating objects
on the heap as well as in the dictionary.

>Of course, GUI programming
>does not create large object pools in heap memory.

Counterevidence: the memory usage of typical Web browsers.

Another case for your original question: The parser generator Gray
<http://www.complang.tuwien.ac.at/forth/gray.zip> uses a hand-crafted
object-oriented extension (which later inspired mini-oof) for the
different kinds (classes) of grammar operators.

- anton

[minf...@arcor.de]

Anton Ertl schrieb am Mittwoch, 16. November 2022 um 09:32:14 UTC+1:
> "minf...@arcor.de" <minf...@arcor.de> writes:
> >Anton Ertl schrieb am Dienstag, 15. November 2022 um 19:16:34 UTC+1:
> >> "minf...@arcor.de" <minf...@arcor.de> writes:
> >> >I'd like to read more from users who program real object-oriented Forth
> >> >applications.
> >> Gforth uses an object-oriented header [paysan&ertl19].
> >

> >> You can also find minos2 in the Gforth source, which uses mini-oof2 as
> >> object-oriented system.
> >
> >So Minos places all objects into the dictionary.
> Why do you think so?

Browsing through the minos2 sources I found only few instances of ALLOCATE
that seemed to me more case-by-case than systematic object heap memory
allocations.

> mini-oof2 certainly supports allocating objects on the heap as well as in the dictionary.

Yes, I see. Minos predated oof2 I guess.

> >Of course, GUI programming
> >does not create large object pools in heap memory.
> Counterevidence: the memory usage of typical Web browsers.

IMO this 'evidence' could be counted better under automatic GUI object representation
for display, than under originary GUI programming, but let's not splitting hairs here.

> Another case for your original question: The parser generator Gray
> <http://www.complang.tuwien.ac.at/forth/gray.zip> uses a hand-crafted
> object-oriented extension (which later inspired mini-oof) for the
> different kinds (classes) of grammar operators.

Thanks for this example.

[none albert]

In article <3e88234e-ee15-47f5...@googlegroups.com>,
Doug Hoffman <dhoff...@gmail.com> wrote:
<SNIP>

>From Chuck Moore: "I created an object in Forth called the month.
>And this object had a starting point and a year and the number of days
>and stuff like that. This is back, back very early. That's the only object
> I've ever done and it was useless. ... So I think object oriented programming
> is a mistake." ;-)

Actually coming up with <BUILDS DOES> means he is thinking in an
object oriented way.
So up to a certain point I can't take this principled objection
seriously. I suspect it is more a stance against hard liners.

>
>-Doug

[Gerry Jackson]

I've used Bernd Paysan's mini-oof extensively, albeit with a few minor
extensions, for development of a Lexer, a full-fat Regex, conversion of
Anton Ertl's Gray to generate standalone Forth code (including replacing
his OOF approach with mini-oof), my cross compiler and a few other minor
programs. I've found it offers all the basic features of OO programming
and is small enough to fully understand so that it can easily be
extended (and misused occasionally). It isn't burdened with features
that I "ain't gonna use". I've never modified the tools to use mini-oof2
despite feeling that I ought to.

One thing I haven't done is to use class wordlists for field names,
preferring to use prefixes where name clashes are likely.

--
Gerry

[Gerry Jackson]

On 16/11/2022 08:04, minf...@arcor.de wrote:
> Doug Hoffman schrieb am Mittwoch, 16. November 2022 um 00:00:10 UTC+1:
>> From Chuck Moore: "I created an object in Forth called the month.
>> And this object had a starting point and a year and the number of days
>> and stuff like that. This is back, back very early. That's the only object
>> I've ever done and it was useless. ... So I think object oriented programming
>> is a mistake." ;-)
>
> I always had the (unfounded) impression that his ego was never his weak trait. ;-)
> "if it is useless for me, it is useless"
>

Agreed

--
Gerry

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:
>Anton Ertl schrieb am Mittwoch, 16. November 2022 um 09:32:14 UTC+1:
>> "minf...@arcor.de" <minf...@arcor.de> writes:
>> >Anton Ertl schrieb am Dienstag, 15. November 2022 um 19:16:34 UTC+1:
>> >> "minf...@arcor.de" <minf...@arcor.de> writes:
>> >> >I'd like to read more from users who program real object-oriented Forth
>> >> >applications.
>> >> Gforth uses an object-oriented header [paysan&ertl19].
>> >
>> >> You can also find minos2 in the Gforth source, which uses mini-oof2 as
>> >> object-oriented system.
>> >
>> >So Minos places all objects into the dictionary.
>> Why do you think so?
>
>Browsing through the minos2 sources I found only few instances of ALLOCATE
>that seemed to me more case-by-case than systematic object heap memory
>allocations.

I see two cases of

' new static-a with-allocater

This indicates that these two objects are statically (dictionary)
allocated, while the default is dynamic (heap) allocation, used in all
other occurences of NEW (grep counts 111 total occurences of NEW in
the minos2 files).

>> mini-oof2 certainly supports allocating objects on the heap as well as in the dictionary.
>
>Yes, I see. Minos predated oof2 I guess.

The old Minos uses Bernd Paysan's more heavy-weight OOF. Minos2 uses
mini-oof2; I think Minos2 and mini-oof2 were developed concurrently.

[Anton Ertl]

albert@cherry.(none) (albert) writes:
>In article <3e88234e-ee15-47f5...@googlegroups.com>,
>Doug Hoffman <dhoff...@gmail.com> wrote:
><SNIP>
>>From Chuck Moore: "I created an object in Forth called the month.
>>And this object had a starting point and a year and the number of days
>>and stuff like that. This is back, back very early. That's the only object
>> I've ever done and it was useless. ... So I think object oriented programming
>> is a mistake." ;-)
>
>Actually coming up with <BUILDS DOES> means he is thinking in an
>object oriented way.

Yes, to a limited extent. The same can be said about
indirect-threaded code (and ;CODE): You have polymorphism by treating
different classes (colon definitions, variables, constants, etc.) as
subclasses of the class word. All words can be performed with EXECUTE
and compiled with "," (in indirect-threaded code), and dynamic
dispatch (performing the code pointed to by the CFA) is used for
resolving this polymorphism at run-time.

Of course, unlike general OO programming systems, here you have only
one method (basically EXECUTE) and no way to add more.

[Hans Bezemer]

On Tuesday, November 15, 2022 at 2:29:31 PM UTC+1, minf...@arcor.de wrote:
> The OOF hype of 10-15 years ago has subsided, standardization did not
> find support, and various implementations seem to gather dust
> on their shelves. From mini-oof to Swoop to FMS, just to name a few.

4tH has got FOOS. The name is not an accident. It features an "object method"
syntax, constructors, destructors, early binding, late binding and single inheritance.
No different name spaces, though - although private members are supported.

I've done all classic design patterns - and more. It's fun to tinker with, but I've
never written a FOOS application from scratch. It never feels right. It's got a
handful of standard classes, like hash tables, streams and dynamic strings.

Featurewise - it seems to hold its ground against other Forth OOP frameworks.

I think it's fun to see it execute some (translated) stuff - but I don't feel the need
to create a program from scratch.

Hans Bezemer

[minf...@arcor.de]

Perhaps it is the typical niche domain of Forth: close and fast system control,
or CLI tools and apps, but not that much for data modelling, usually ...

As all-encompassing non-CLI tool and inspired by SmallTalk, Wolf Wijgaard
treated a Forth system as object-oriented 'living' source+code collection:
https://holonforth.com/index.html

Unfortunately HolonForth seems to be abandoned - it had deserved more attention
IMO. Kudos to Wolf!

[Peri Didaskalou]

Thanks Kindly Anton,
for sharing all this very helpful information; including the video of
your EuroForth 2019 presentation! I also agree that polymorphism is
beneficial to GForth.
Peri

[Bob Edwards]

I've adapted Mini-OOF to ESP32forth and Taqoz (for Parallax Propeller 2) and found it to be very usable. In my opinion, CREATE and DOES> are fine for very simple defining words, but the code rapidly goes cryptic as complexity rises. Mini-OOF Classes and Objects remain very readable as complexity rises - which is good for maintenance. Well worth trying.
See https://github.com/bob-g4bby/Bob-Edwards--Forth-Stuff for my code
Cheers, Bob G4BBY

[none albert]

In article <f36dcab5-e919-4ab1...@googlegroups.com>,

That is precisely my experience, with tmanx, ciasdis and other
non-trivial programs. I use my own OOF, even simpler than
Mini-OOF. Basically a multiple CREATE/DOES> .

This e.g. a serial port driver object.
It becomes incredibly messy otherwise.

\ The infamous termios struct from c. See termios.h.
\ Size must be 0x3c.
class TERMIOS
\ Method working on the whole struct
\ Get and set this struct for file DESCRIPTOR.
M: tcget TCGETS SWAP __NR_ioctl XOS ?ERRUR M;
M: tcset TCSETSF SWAP __NR_ioctl XOS ?ERRUR M;

\ All these methods working on the c_iflags field.
M: ixon $0400 set-bits M;
M: no-ixon $0400 clear-bits M;
M: ixoff $1000 set-bits M;
M: no-ixoff $1000 clear-bits M;
M: ixany $0800 set-bits M;
M: no-ixany $0800 clear-bits M;
M: no-ix $1C00 clear-bits M;
M: iraw $FFFF clear-bits M;
M: c_iflag M; 4 ALLOT

M: opost $1 set-bits M;
M: oraw $FFFF clear-bits M;
M: c_oflag M; 4 ALLOT

\ All these methods working on the c_cflags field.
M: parity $100 set-bits M;
M: no-parity $100 clear-bits M;
M: doublestop $40 set-bits M;
M: no-doublestop $40 clear-bits M;
M: size8 $30 set-bits M;
M: size7 $30 clear-bits $10 set-bits M;
M: set-speed-low DUP $F clear-bits SWAP get-code set-bits M;
M: c_cflag M; 4 ALLOT

\ All these methods working on the c_lflags field.
M: icanon $02 set-bits M;
M: no-icanon $02 clear-bits M;
M: echo $08 set-bits M;
M: no-echo $08 clear-bits M;
M: echoe $10 set-bits M;
M: no-echoe $10 clear-bits M;
M: isig $01 set-bits M;
M: no-isig $01 clear-bits M;
M: lraw $FF clear-bits M;
M: c_lflag M; 4 ALLOT

M: c_line M; 1 ( !) ALLOT \ We are now at offset $11

M: set-timeout no-icanon 5 + C! M; \ `VTIME' Timeout in DECISECONDS.
M: set-min no-icanon 6 + C! M; \ `VMIN' Minimal AMOUNT to recieve.
M: c_cc M;
$34 $11 - ALLOT \ to make speeds at an offset of $34

\ The offsets of the c_ispeed and c_ospeed are $34 $38
\ Stolen from c in 32 and 64 bits on a 64 bits system.
\ Set SPEED, for input and output the same.
\ In 64 bits those don't fit, needs an extra "1 CELLS ALLOT".
M: set-speed-high 2DUP ! 4 + ! M;
\ ALIGN \ To 32 bits intended but unaligned word better!
M: c_ispeed M; 4 ALLOT
M: c_ospeed M; 4 ALLOT
M: termios-size ^TERMIOS @ - M;
M: termios-erase >R ^TERMIOS @ R> OVER - ERASE M;
M: termios-compare >R ^TERMIOS @ R> OVER - CORA 1004 ?ERROR M;
1 CELLS ALLOT
endclass

[Marcel Hendrix]

On Thursday, November 17, 2022 at 9:20:03 PM UTC+1, none albert wrote:
[..]

If this is OOF, then I'm doing it too (minus fancy words).

-marcel

[Brian Fox]

On Friday, November 18, 2022 at 1:18:37 AM UTC-5, Marcel Hendrix wrote:

> If this is OOF, then I'm doing it too (minus fancy words).
>
> -marcel

<off topic>
You made me think of the story of the Dutch wife who came
home from the doctor and said:
"Thijs, the doctor said we can't have any more children, so I am going
to sleep in the basement"
Old Thijs said: "If that's going to help, I am sleeping there too!"
</off topic>

[none albert]

In article <b7f0de01-1b66-44e6...@googlegroups.com>,

I claim that is OO, even Anton Ertl admits that <BUILDS DOES>
is a kind of OO approach. What other fancy words you think
I'm using? Not inheritance, duct taping, multiply inheritance,
virtual methods, to name a few.

Have you studied the example?
`parity? and `no-parity? are multiple DOES> actions with
offset 0 w.r.t. to >BODY.
`opost and `oraw are multiple does> actions with
offset 4 w.r.t. to >BODY.

In C there is at least a field involved with parity,
then a mask, and then an action to change the parity.
The last is even too much for C, requiring a method for
each property.
So they request that you get the serial description, patch the data
and set it back, making it 5 rocket.

I'm interested how you go about this serial facility.

If you insist it to call it an eminently Forth like solution
with excellent transparance, inspired by OO, be my guest.

>
>-marcel

[S Jack]

As a single, one and only, definitive OOP does not exists the
ontological aspect of OOP is unresolved **. The same extends to a
Forth OOP. The answer to questions of how much of an OOP is any given
Forth OOP is purely speculative.

A Forth OOP paradigm is unquestionably different from historic Forth
but begs the question of how much mixing of paradigms is
tolerable to a Forth system programmer? None, a total commitment to
or total shunning of an OOP paradigm, or some mixture. No "should" in
the answers; all is preferential.

I fall in line with those who experimented, found it good but can get
by without and so choose, a stylistic choice.

** "A data block bound to a method; all the rest is theory."
--
me

[dxforth]

On 16/11/2022 10:00 am, Doug Hoffman wrote:
> ...

> From Chuck Moore: "I created an object in Forth called the month.
> And this object had a starting point and a year and the number of days
> and stuff like that. This is back, back very early. That's the only object
> I've ever done and it was useless. ... So I think object oriented programming
> is a mistake." ;-)

Depends upon whom you ask...

"The approach taken included many features now associated with object oriented
programming: encapsulation (the basic object was an “image,” with characteristic
parameters and methods), inheritance (you could add new images that would inherit
characteristics of previously defined classes of images) and dynamic binding of
manipulation methods. Moore, the principal architect of this approach, was
unaware of any academic work in this area. Striving to achieve the same goals
as later OOPS writers, he independently derived similar solutions."

https://www.forth.com/resources/forth-programming-language/

[Bernd Paysan]

Am Wed, 16 Nov 2022 11:13:09 GMT schrieb Anton Ertl:
> The old Minos uses Bernd Paysan's more heavy-weight OOF. Minos2 uses
> mini-oof2; I think Minos2 and mini-oof2 were developed concurrently.

Indeed. I wanted to know how far I can get with mini-oof2, and added
things to it as I went along. And that wasn't much.

The more heavy-weight BerndOOF with its scoping makes detecting silly bugs
easier, but it turned out that I don't make these silly bugs anyhow.
There's a scoping system you can load on top of mini-oof2, which is used
for the XML parser in net2o. There, the scoping absolutely makes sense,
since the data coming in is external data, and can be hostile, so
automatic detection if everything is right is absolutely necessary.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
https://bernd-paysan.de/

[Zbig]

https://suzdalnitski.medium.com/oop-will-make-you-suffer-846d072b4dce

https://suzdalnitski.medium.com/oop-design-patterns-bd2c4fb3014c

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

https://ovid.github.io/articles/why-is-object-oriented-programming-bad.html

https://chiefio.wordpress.com/2018/12/27/why-object-oriented-programming-is-bad/

[dxforth]

Why do I get the impression OOP is the new 'whipping boy' :)

[none albert]

In article <ff655dde-1482-4d35...@googlegroups.com>,

Using oo design in my programs greatly moves the boundary of what I
can accomplish. ciasdis tmanx .
[However I don't buy that inheritance, multiple inheritance, duck typing
and several levels of protection --hindrance -- is essential to oo].

It may be possible to convince me of inheritance. I feel that in
https://github.com/albertvanderhorst/forthlisp
the jump tables indexed by a tag (identifying a lisp class)
could be improved by it.
I have introduced oo in an improved version, but the jump tables
still remain.

Groetjes Albert

[Zbig]

A quote from Suzdalnitski's article:

„How can we enforce sufficient constraints to prevent the code from turning into spaghetti? Two options — manually, or automatically. Manual approach is error-prone, humans will always make errors. Therefore, it is logical for such constraints to be automatically enforced.

Unfortunately, OOP is not the solution we’ve all been looking for. It provides no constraints to help with the problem of code entanglement. One can become proficient in various OOP best practices, like Dependency Injection, test-driven Development, Domain-Driven Design, and others (which do help). However, none of that is enforced by the programming paradigm itself (and no such tooling exists that would enforce the best practices).

None of the built-in OOP features help with preventing spaghetti code — encapsulation simply hides and scatters state across the program, which only makes things worse. Inheritance adds even more confusion. OOP polymorphism once again makes things even more confusing — there are no benefits in not knowing what exact execution path the program is going to take at runtime. Especially when multiple levels of inheritance are involved.”

So the use of the „old-fashionable” Forth-screens — instead of the files — is
the better remedy for spaghetti-code (if avoiding „the arrow”). These impose
„constraints to prevent the code from turning into spaghetti”.

As for the OOP paradigm… IMHO it's adding just more „red tape” into program, with
no REAL benefits. Whatever is done using OOP — can be done as well in procedural
way, but it'll be done quicker and in lesser amount of code. The amount of OOP that
CREATE...DOES brings is roughly enough for me. Or — when programming in C — at
most creating „objects” using struct (no polymorphism, no inheritance, no delegation,
nothing like that).

Of course everyone is free to use whatever suits him.

[minf...@arcor.de]

The citation reads like a typical rant from a long gone time when OOP was hyped and people
tried to apply OO tools even to problems that had few to even zero data/method objects.
No wonder results were unsatisfactory. OTOH disciplined programmers following appropriate
coding guidelines write readable structured code even in BASIC or BASH - without Forth screens.

[Zbig]

> The citation reads like a typical rant from a long gone time when OOP was hyped and people
> tried to apply OO tools even to problems that had few to even zero data/method objects.
> No wonder results were unsatisfactory. OTOH disciplined programmers following appropriate
> coding guidelines write readable structured code even in BASIC or BASH - without Forth screens.

„Even in BASH”, you say… then why (according to Suzdalnitski) they somehow
can't do that using C++/C# etc.? Maybe OOP paradigm has something to do
with that?

[minf...@arcor.de]

It is a wide world and Suzdalnitski has his own experience. I am not counter-argumenting here.
I think his words are correct before his personal background. The praise of limited Forth screens
goes hand in hand with factoring to smaller routines (words in Forth speak) which brings some
benefits indeed, but only when the programmer is disciplined. I have seen also lots of ugly
hacked-together blocks in my time, chained together through -->. BTW the word --> had been used
widely then, but for whatever reason did not make it into ANS Forth. With today's large screen
workstations even for embedded programming I prefer a normal text editor and sequential Forth
sources any time.

But back to OOP: avoiding spaghetti code is not its primary use case IMO. When methods are called
only sparingly, inheritance is hardly to find, why use OOP in the first place? Interestingly most successful
"new" programming languages support different programming paradigms, like OO, functional, imperative etc.
Forth doesn't advertise it, but can support those too on a tiny scale, somewhat like a Swiss Army knife.

[Anton Ertl]

"minf...@arcor.de" <minf...@arcor.de> writes:
>I have seen a=
>lso lots of ugly=20
>hacked-together blocks in my time, chained together through -->. BTW the wo=

>rd --> had been used
>widely then, but for whatever reason did not make it into ANS Forth.

I used -->, too, when I programmed with blocks.

The Gforth documentation for --> says:

|[...] Not recommended, because it destroys the independence of
|loading. Use 'thru' (which is standard) or '+thru' instead.

[dxforth]

On 17/12/2022 3:21 am, Anton Ertl wrote:
> "minf...@arcor.de" <minf...@arcor.de> writes:
>> I have seen a=
>> lso lots of ugly=20
>> hacked-together blocks in my time, chained together through -->. BTW the wo=
>> rd --> had been used
>> widely then, but for whatever reason did not make it into ANS Forth.
>
> I used -->, too, when I programmed with blocks.
>
> The Gforth documentation for --> says:
>
> |[...] Not recommended, because it destroys the independence of
> |loading. Use 'thru' (which is standard) or '+thru' instead.

I have --> . It may get used if I'm hacking a definition via the default
screen file FORTH.SCR . Having named screen files I didn't feel the need
+THRU . The following are my screen-file equivalents of INCLUDED INCLUDE .

LOADED ( +n1 +n2 c-addr u -- ) S

Save the current screen-file specification then open the
screen-file specified by c-addr u and load blocks +n1 thru +n2.
At completion close the file and restore the previous screen-file.
If the filename does not include an extension then .SCR is
assumed. Screen-files may be nested.

FLOAD ( +n "filename[.SCR]" -- ) S

Equivalent to: DUP GETFILENAME LOADED

[dxforth]

On 17/12/2022 2:46 am, minf...@arcor.de wrote:
> Zbig schrieb am Freitag, 16. Dezember 2022 um 15:27:18 UTC+1:
>>> The citation reads like a typical rant from a long gone time when OOP was hyped and people
>>> tried to apply OO tools even to problems that had few to even zero data/method objects.
>>> No wonder results were unsatisfactory. OTOH disciplined programmers following appropriate
>>> coding guidelines write readable structured code even in BASIC or BASH - without Forth screens.
>> „Even in BASH”, you say… then why (according to Suzdalnitski) they somehow
>> can't do that using C++/C# etc.? Maybe OOP paradigm has something to do
>> with that?
>
> It is a wide world and Suzdalnitski has his own experience. I am not counter-argumenting here.
> I think his words are correct before his personal background. The praise of limited Forth screens
> goes hand in hand with factoring to smaller routines (words in Forth speak) which brings some
> benefits indeed, but only when the programmer is disciplined. I have seen also lots of ugly
> hacked-together blocks in my time, chained together through -->.

Are screen users any less capable of improving on what they've done? After working with
same for many years I gravitated to a form that satisfied me. I won't say it's the only
or best way.

https://pastebin.com/fAp1MCGg

[Paul Rubin]

Bernd Paysan <be...@net2o.de> writes:
> Indeed. I wanted to know how far I can get with mini-oof2...

Hey, welcome back, it's been a while.

[S Jack]

On Friday, December 16, 2022 at 9:53:44 PM UTC-6, dxforth wrote:
> Are screen users any less capable of improving on what they've done? After working with
> same for many years I gravitated to a form that satisfied me. I won't say it's the only
> or best way.

Forth blocks:
I camp often months at a time in all seasons contending with thunder
storms, freezing nights, blistering days but worst of all Mariah; not
to mention gnats, mosquitoes and flies that can bite through socks and
draw blood, poison plants, thorns that puncher through shoes and
briers that entangle and rip, spiders, snakes, wild pig (do my best to
avoid mountain lion and bear). Living in a house is much easier, but
all the other can be dealt with and life on trail provides many
lasting memories.
--
me

[dxforth]

Here I was thinking screens for source code was an easier alternative
to having one large text file or a multitude of small ones. It wasn't
intended to be a punishment :)

[none albert]

I both use block and files. Each to their advantage.
Example.
I want to use /STRING (remove leading characters)
-LEADING ( remove leading blanks) and
DROP-WORD (remove first blank-delimited word from string)
I put them together in one screen and load that
screen as needed by e.g `` WANT /STRING ''

There is no end to what you want in your Forth and
the result is that you type WORD in gforth it even
overflows the scroll back area, which gives rise to
... more additional words.

Those similar words are nicely tucked away in a screen:
------------------------------------------
( /STRING -LEADING DROP-WORD ) \ AvdH B@aug12

\ From SC trim N char's
: /STRING >R R@ - SWAP R> + SWAP ;

\ Like -TRAILING sc-sc
: -LEADING BEGIN OVER C@ ?BLANK OVER 0= 0= AND
WHILE 1 - SWAP 1 + SWAP REPEAT ;

\ From a STRING remove the first word. Leave the rest STRING.
: DROP-WORD -LEADING BL $/ 2DROP ;
\ : DROP-WORD BEGIN BL $/ 0= WHILE DROP REPEAT DROP ;

------------------------------------------

How would you organize a directory with small files,
containing those three definitions?
Most give up and add it in the kernel right with the
kitchen sink.

On the other hand, if I attack an Euler problem,
I make a nice file with the description up front,
and loading object extension (or not), factorisation
auxiliary (or not), string extensions (or not),
string formatting (or not) by WANT.

Then there is the conditional loading e.g. with ?32 and
?64 that allows 32 bits and 64 bits to sit in the same
file.

With a library file of less than 300 K you will have
nearly all standard words, an assembler, loadable
floating point, binary search, sorting ...

[dxforth]

On 18/12/2022 8:00 pm, albert wrote:
> ...

> With a library file of less than 300 K you will have
> nearly all standard words, an assembler, loadable
> floating point, binary search, sorting ...

Wil Baden described a directory system for blocks (FD5/3).
In my system, executing a module name loads it. Loading the names
is simply a matter of loading the library e.g. 1 FLOAD DOSLIB

https://pastebin.com/VRQ026PA

[none albert]

My system is more convenient, I guess.
WANT AUTOLOAD
After that you can use words that are in the library, and
they are automatically loaded.
In stable programs use WANT explicitly, for a facility like this can
be 100% reliable.

Also you can change the working directory with no influence in the
facility.

~$ lina -a
' SEE
' SEE ? ciforth ERROR # 11 : WORD IS NOT FOUND
' LOCATE
' LOCATE ? ciforth ERROR # 11 : WORD IS NOT FOUND
WANT AUTOLOAD
OK
SEE LOCATE
WANT SEE
WANT LOCATE

: LOCATE
NAME LOCATED
;
OK

Loading individual words from floating point makes no sense.
They are loaded with
WANT -fp-
Now the dummy word -fp- is present, so it doesn't load a second
time.

[dxforth]

On 19/12/2022 9:16 pm, albert wrote:
> In article <tnoofm$12db$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
>> On 18/12/2022 8:00 pm, albert wrote:
>>> ...
>>> With a library file of less than 300 K you will have
>>> nearly all standard words, an assembler, loadable
>>> floating point, binary search, sorting ...
>>
>> Wil Baden described a directory system for blocks (FD5/3).
>> In my system, executing a module name loads it. Loading the names
>> is simply a matter of loading the library e.g. 1 FLOAD DOSLIB
>>
>> https://pastebin.com/VRQ026PA
>
> My system is more convenient, I guess.
> WANT AUTOLOAD

I did consider something like that but limited memory meant going for
cheap.

(BTW for anyone looking at my code the '2LITERAL' should be 'SLITERAL'.
Seems this was a long-standing bug I never noticed until now :)

> ...

> Loading individual words from floating point makes no sense.
> They are loaded with
> WANT -fp-

I'm mostly loading modules rather than individual words. The latter
tends to be infrequent enough that I'll incorporate it in the app
source e.g. via SCOPY utility.

I guess my point is screen-file libraries are useful and convenient
whichever way one chooses to implement them. Of course, one has to
appreciate screens and not view them as a relic of the past that's
'holding Forth back'.

[Zbig]

> (BTW for anyone looking at my code the '2LITERAL' should be 'SLITERAL'.
> Seems this was a long-standing bug I never noticed until now :)

Actually there are both of them: SLITERAL and 2LITERAL.

[dxforth]

How do you mean? The bug was 2LITERAL compiled a reference to a string
in a buffer, as opposed to compiling the string itself. Under the
conditions I'd been using it, the buffer contents didn't change and the
bug remained unnoticed :(

[Zbig]

> > Actually there are both of them: SLITERAL and 2LITERAL.
> How do you mean? The bug was 2LITERAL compiled a reference to a string
> in a buffer, as opposed to compiling the string itself. Under the
> conditions I'd been using it, the buffer contents didn't change and the
> bug remained unnoticed :(

I don't recall if I was using any of that two words — but I took a peek
into kernel.asm; yes, there are both of them defined. So if you're going
to rename 2LITERAL to SLITERAL, then there's a need to do something
with (present) SLITERAL too.

[dxforth]

No, no intent of renaming. I used 2LITERAL in an app where properly SLITERAL
should have been used.

[Zbig]

> No, no intent of renaming. I used 2LITERAL in an app where properly SLITERAL
> should have been used.

Do you mean any application that was available for download
or included directly in package? Which one?

[dxforth]

DOSLIB (supplied with DX-Forth) is subject to change. There is always the
risk previous applications written with it will break on a change or bugfix.
Apps included in the DX-Forth package should be compatible with the version
of DOSLIB enclosed. Apps I distribute separately won't necessarily be
updated. HTH

[Zbig]

> DOSLIB (supplied with DX-Forth) is subject to change. There is always the
> risk previous applications written with it will break on a change or bugfix.
> Apps included in the DX-Forth package should be compatible with the version
> of DOSLIB enclosed. Apps I distribute separately won't necessarily be
> updated. HTH

In my copy of DOSLIB.SCR (66560 bytes from 2022-07-13) there isn't
any occurence of 2LITERAL.

[dxforth]

On 22/12/2022 12:03 pm, Zbig wrote:
>
> In my copy of DOSLIB.SCR (66560 bytes from 2022-07-13) there isn't
> any occurence of 2LITERAL.

That version used the equally wrong 2CONSTANT to define LIB. An update
had LIB inlined so 2CONSTANT initially became 2LITERAL.

[S Jack]

On Sunday, December 18, 2022 at 10:14:49 PM UTC-6, dxforth wrote:
> Wil Baden described a directory system for blocks (FD5/3).

Block directory inspired by late Wil Baden via DxForth
Example main directory:
SCR # 450
0 ( Main Directory )
1 VOC 452 452 SUB_DIR
2 INFO 453 453 SUB_DIR
3 PROFILE 302 \ usr profile
4 SANE 301 \ sane settings
5 SCREEN_OFF 392 \ plain screen mode
6 COPROC 393 \ load co-shell, establish ipc
7 EVARS 307 \ подбор environment variables
8 ZCODES 100 \ extension
9 STRUCTS "f/struct.f" fload \ structures
10 EXTR 017 \ exter extend
11 SCREEN 018 \ screen level extend
12 MISC 019 \ miscellanous extend
13
14
15
ok
Comments:
i. Line 0 is not searched; the other 15 lines are.
i. The first word in the lines are searched for a match. If a match
is made, the search stops and the rest of the line is evaluated.
i. SUB_DIR sets the current directory to the given range of scr
numbers. In the example above the sub-directories VOC and INFO
have only one scr so its number appears twice.
i. Usually other items not sub-directories just return an scr number.
For example, PROFILE would return the number 302. Note that the
line after the keyword is evaluated so the comments apply and don't
produce anything.
Also note that STRUCTS loads a file instead of returning a scr number.

The directory search:
A directory search is performed by the article WA . A string is passed
to WA providing a search path, WA obtains the evaluation and some following
word my use the result:
"/info/stats" WA LISTS
If the first character in the search path is a slash "/", the current
directory is set to the main directory. The words between slashes are
the keywords being searched for. The keywords in the search path may be
lower case but the keywords in the directories must be upper case.
In the above search path the first slash selects the main directory where
INFO changes the current directory to the info sub-directory where
STATS is found and provides an scr number. STATS is a range of
consecutive scr's linked by "-->". LISTS lists an scr, pauses then
lists the next scr until an scr without "-->" is found.

There's more detail but the above covers the salient features.
--
me