The following programs exhibit a essential use of Object
Oriented techniques:
- ciasdis , who (in)famously analysed colorforth, disassemble and reassemble
- manx2, who plays multi part, polyphonic music on instruments with varying drivers,

percussion and during tone.
The bad news is that is based on a one screen mini-oop.
The challenge :
show me one sophisticated program, that takes advantage from
features they are advocated
- or show me how these programs could be simplified by
more advanced oop.
Am I applying oop to the more involved programs?
Groetjes Albert

On 2021-10-14, albert@SPENARNC.XS4ALL.NL <albert@SPENARNC.XS4ALL.NL> wrote:
> The following programs exhibit a essential use of Object
> Oriented techniques:
> - ciasdis , who (in)famously analysed colorforth, disassemble and reassemble
> - manx2, who plays multi part, polyphonic music on instruments with varying drivers,
>
> percussion and during tone.
> The bad news is that is based on a one screen mini-oop.
> The challenge :
> show me one sophisticated program, that takes advantage from
> features they are advocated
> - or show me how these programs could be simplified by
> more advanced oop.
> Am I applying oop to the more involved programs?
> Groetjes Albert
>

oop is just vtable, that is table of pointers to
functions. Else is composition, embedding data into
data :P
And finally data hiding...

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On Thursday, October 14, 2021 at 1:30:03 AM UTC-7, alb...@spenarnc.xs4all.nl wrote:
> The challenge :
> show me one sophisticated program, that takes advantage from
> features they are advocated

My MSP430 assembler HJA430 uses my LIST.4TH and rquotations.
https://board.flatassembler.net/topic.php?t=21841

You would presumably not consider this to be a sophisticated program.
I don't actually consider it to be very sophisticated either --- it was easy.
All of my programs use LIST.4TH --- all of them were easy to write.

On 15/10/2021 16:16, Hugh Aguilar wrote:
> On Thursday, October 14, 2021 at 1:30:03 AM UTC-7, alb...@spenarnc.xs4all.nl wrote:
>> The challenge :
>> show me one sophisticated program, that takes advantage from
>> features they are advocated
>
> My MSP430 assembler HJA430 uses my LIST.4TH and rquotations.
> https://board.flatassembler.net/topic.php?t=21841

"I don't want others to follow me --- that is why I don't provide source-code."

In the absence of which there is no reason to believe.

>
> You would presumably not consider this to be a sophisticated program.
> I don't actually consider it to be very sophisticated either --- it was easy.
> All of my programs use LIST.4TH --- all of them were easy to write.
>

On Thursday, October 14, 2021 at 10:16:11 PM UTC-7, Hugh Aguilar wrote:
> On Thursday, October 14, 2021 at 1:30:03 AM UTC-7, alb...@spenarnc.xs4all.nl wrote:
> > The challenge :
> > show me one sophisticated program, that takes advantage from
> > features they are advocated
> My MSP430 assembler HJA430 uses my LIST.4TH and rquotations.
> https://board.flatassembler.net/topic.php?t=21841

I rely heavily on inheritance. My LIST.4TH is my work-horse and it has a lot of
features that are useful for application programs --- so, inheritance is the key.
I don't have polymorphism --- I don't consider that to be useful, and it is hard to do.

Here we have had this thread:
https://groups.google.com/g/comp.lang.forth/c/WYGu4YFhhas

On Wednesday, October 13, 2021 at 5:17:00 PM UTC-7, Doug Hoffman wrote:
> On 10/13/21 6:02 PM, Ruvim wrote:
> > One of basic OOP features is encapsulation. So it's very unexpected to
> > an OOP model to not isolate instance variable accessors of different
> > classes from each other (and even from other code out of the classes).
> >
> > As I can see, a sound OOP model cannot be implemented without utilizing
> > namespaces.
> I won't disagree. You have seen a version that encapsulates using
> wordlist primitives. It would not be hard to incorporate that or maybe
> provide encapsulation in some other way that you like.

This focus on polymorphism is impractical.
The Forth-200x committee have never succeeded in implementing a
general-purpose linked-list. Peter Knaggs attempt was grossly incompetent:
https://groups.google.com/g/comp.lang.forth/c/cMa8wV3OiY0/m/INBDVBh0BgAJ
The Forth-200x committe would fail badly at writing an MSP430 assembler
comparable to my HJA430 --- it was easy though, given LIST.4TH.
On that FASM thread I said this:
----------------------------------------------------------
....the code-blocks have a list of lists. The first node is the first level, the second node
is the second level, etc.. Each node is a list of forward references that have to be resolved
when the code block finishes with }, and this code block is then removed from the list of lists
so that what was the second node is now the first level.
----------------------------------------------------------
This is not sophisticated programming --- this is basic OOP programming that any
high-school student would be familiar with --- the Forth-200x committee worry about
polymorphism, but they don't really know anything about practical programming.

On Saturday, October 16, 2021 at 2:22:27 PM UTC-7, Hugh Aguilar wrote:
> The Forth-200x committee have never succeeded in implementing a
> general-purpose linked-list. Peter Knaggs attempt was grossly incompetent:
> https://groups.google.com/g/comp.lang.forth/c/cMa8wV3OiY0/m/INBDVBh0BgAJ
> The Forth-200x committe would fail badly at writing an MSP430 assembler
> comparable to my HJA430 --- it was easy though, given LIST.4TH.
> On that FASM thread I said this:
> ----------------------------------------------------------
> ...the code-blocks have a list of lists. The first node is the first level, the second node
> is the second level, etc.. Each node is a list of forward references that have to be resolved
> when the code block finishes with }, and this code block is then removed from the list of lists
> so that what was the second node is now the first level.
> ----------------------------------------------------------

On second thought, Peter Knaggs' idiotic attempt at linked-lists would work
for HJA430 (if Peter Knaggs actually wrote the code for it). The most idiotic
limitation of his design is that it is limited to structs that have only one cell-sized
field. In the case of HJA430 though, my structs do have only one cell-sized field.
So, this is a rare case in which Peter Knaggs' weird limitation would not be a problem.
Here is a small excerpt from my HJA430 code (that DXforth doesn't believe exists):
-------------------------------------------------------------------
list
w field .adr
constant adr

: init-adr \ adr node -- node
init-list >r
r@ .adr !
r> ;

: new-adr \ adr -- node
adr alloc
init-adr ;

: kill-adr \ head --
each[ dealloc ]each ;

\ Already defined are:
\ JUMPS this is an ADR list of ADR lists of forward jump-instruction addresses
\ BEGINS this is an ADR list of code-block beginning addresses

\ JUMPS is an ADR list. 1ST is the ADR list of jump instructions to >, 2ND of jump instructions to >>, etc..
\ BEGINS is an ADR list of destinations. 1ST is <, 2ND is <<, etc..
\ The code-blocks can be nested to any depth. At this time however, I only support <<<< <<< << < > >> >>> >>>> for jumps.
\ Jumping to great-grand-parents <<<< or >>>> is not recommended because this is ugly confusing code.
\ Code should be factored better and/or labels should be used to simplify the code blocks.
\ Conditional jumps to <<<< <<< << < > >> >>> >>>> are always 10-bit --- they abort if out-of-range.
\ The unconditional JMP does optimize as either a 10-bit <JMP> or a 16-bit GOTO if necessary.
\ The user must fix out-of-range jumps manually, typically using structured control-flow to hop over a GOTO.
\ I don't want hidden inefficiencies resulting from the assembler fixing problems automatically.
-------------------------------------------------------------------

JUMPS is for resolving forward references to the ends of the code blocks and
BEGINS is for holding the beginnings of the code blocks.
Also, the labels have an ADR list for resolving forward references to the label.

I originally had HJA430 optimize conditional jumps as an opposite-conditional hop over
an unconditional 16-bit jump. I dropped this for three reasons:

1.) There is always the cost of inserting NOP instructions to provide enough room.
This is only an issue with forward conditional jumps, not backward conditional jumps.

2.) This is almost never needed because a 10-bit jump is almost never out-of-range.
This was more of an issue in my 65c02 assembler because the offset was 8-bit,
but even then an out-of-range conditional jump was pretty rare.

3.) I don't like assemblers doing optimization internally because the user can't easily
determine how many clock-cycles his code takes without disassembly.

So, I got rid of the optimization.
In the rare cases that the 10-bit forward conditional jump is out-of-range, assembly aborts
with a helpful error-message and the user fixes the problem manually.
Backward conditional jumps do not get optimized despite the fact that #1 above
is not an issue --- #3 above is still an issue --- #2 above is also still true.

On 17/10/2021 10:15, Hugh Aguilar wrote:
>
> On second thought, Peter Knaggs' idiotic attempt at linked-lists would work
> for HJA430 (if Peter Knaggs actually wrote the code for it). The most idiotic
> limitation of his design is that it is limited to structs that have only one cell-sized
> field. In the case of HJA430 though, my structs do have only one cell-sized field.
> So, this is a rare case in which Peter Knaggs' weird limitation would not be a problem.
> Here is a small excerpt from my HJA430 code (that DXforth doesn't believe exists):
> ...

Teasing an audience with a doc but not the code only raises questions e.g.
'Why exactly did Hugh need linked lists, structs, rquotions etc for a forth
assembler?'. Pitching a forth assembler to non-forthers will likely be seen
as evidence of 'forth nuttiness'. More things they didn't need.