On 10/13/21 6:02 PM, Ruvim wrote:
> On 2021-10-10 16:03, Doug Hoffman wrote:
>> On 10/10/21 6:24 AM, Ruvim wrote:
>>> On 2021-09-12 16:19, Doug Hoffman wrote:
>>>> After paring away, the following code would be my idea of a mini-oop
>>>> extension for Forth.
> [...]
>>> The word "var" unconditionally creates a new definition on every use.
>>> So, it shadows the previous definition with the same name. (1)
>>> Probably, such definitions should be local for their classes.
>>
>> mini-OOF does it this way and many seem to like it.
>
> It seems, those many who like it need just a toy.
>
> 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.

> By the way, the magnitude of the "state-smartness" problem was
> overestimated. The only problem in this regard is the problem of
> incomplete "postpone", and this problem can be easy solved via a
> standard polyfill.

Ok.

> [...]
>>> Also, you need the class to make an early bound method call.
>
> I mean unification: to do it by providing a class for both early binding
> and accessing another's instance variables.

Anyone could change the mini-oop I show if they want different behavior.

>> Yes, the provided code in the original post of this thread shows how in
>> the example use code. Is it a problem to provide the class when wanting
>> early binding?  e.g., [ point :: draw ]
>> Again, I always get complaints about "too much code" and "it is too
>> complicated". [ point :: draw ] is dead simple to use with very little
>> support code.
>
> It doesn't look like a code that compiles anything.
>
> A better variant:
>
>   [ point ]-> draw
> or
>   [ point ]:: draw
>
> Where
>
>   : ]:: ( cls "name" -- ) ] ' >body swap mfa fm compile, ; immediate
>
> Also it's less likely to be misused.
>
> But switching to interpretation state looks too forced and unnatural in
> any case.

The nice thing is one can change the code in any way one desires.
I chose [ point :: draw ] because it is a "tiny-oop" syntax that has
been seen before in Forth.

>> Here  https://github.com/DouglasBHoffman/FMS2  I use:
>>
>> self  draw  \ late bind
>> eself draw  \ early bind
>
> I also saw "own draw" for early binding in some OOP implementations.
>
>
> But my choice is to use early binding in a simple way (without any
> special things), and use some special things/decorators for late binding
> only. Rationale: late binding is required much less frequently than
> early binding.

Interesting. That is exactly the behavior chosen by the implementers of
Neon(1984). They also accomplished encapsulation without using
wordlists. Andrew McKewan wrote an ANS compatible Neon-like extension
and published it in Forth Dimensions, March 1997. It is very much like
what the Win32Forth people have adopted, I believe. Some have criticized
it for using message-object ordering (and some other things). If you
want to see McKewan's code I could send it to you. I don't have a link,
just the files.

-Doug

> --
> Ruvim

Hi,

McKewan's code is on Taygeta:

ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/CLASS10.TXT
ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/CLASS10.ZIP

Regards,
pahihu

Doug Hoffman ezt írta (2021. október 14., csütörtök, 2:17:00 UTC+2):
> If you
> want to see McKewan's code I could send it to you. I don't have a link,
> just the files.
>

On 10/13/21 6:02 PM, Ruvim wrote:
> On 2021-10-10 16:03, Doug Hoffman wrote:

>> Here  https://github.com/DouglasBHoffman/FMS2  I use:
>>
>> self  draw  \ late bind
>> eself draw  \ early bind

> But my choice is to use early binding in a simple way (without any
> special things), and use some special things/decorators for late
> binding only. Rationale: late binding is required much less
> frequently than early binding.

An alternative is to use faster late binding. I have uploaded a virtual
table version of FMS2 to the above github location. Additionally there
is now an early binding syntax: message-to-class. Example:

:class point
cell bytes x
cell bytes y
:m :init ( x y --) y ! x ! ;m
:m :get ( -- x y) x @ y @ ;m
;class

\ instantiate a point object, place it in p2
10 20 point p p value p2

\ default is late bind of :get to contents of p2
: test1 p2 :get .s ;
test1 \ => 10 20

\ force early bind of :get to contents of p2 using message-to-class
: test2 p2 point :get ;
test2 \ => 10 20

Not exactly what you were thinking, but achieving early binding by
using eself and message-to-class seems not complex. Perhaps not even
needed with faster late binding.

-Doug

Doug Hoffman ezt írta (2021. szeptember 12., vasárnap, 15:20:02 UTC+2):
> After paring away, the following code would be my idea of a mini-oop
> extension for Forth. Not a 12 liner, but loc will be recovered quickly
> as classes are written.

Hi,

It is a nice little late-bound thingy, I've played it with a little.

pahihu

: oallot ( cls -- obj) dup dfa @ here swap allot tuck ! ;
: oalloc ( cls -- obj) dup dfa @ allocate throw tuck ! ;
: dynamic ( cls -- obj) oalloc dup >R :init R> ;
0 value supClass
: class ( supClass 'name' -- cls) dup to supClass class ;
: super ( 'name' -- ) ' >body supClass mfa fm compile, ; immediate
: :his ( otherobj 'ivar -- 'otherivar) self - + ;

object
cell var objRefCnt

:m :class ( -- cls ) self @ ;m

:m :className ( -- ca u )
self :class body> >name count ;m

:m :sizeOf ( -- n ) self :class dfa @ ;m

:m :copy ( -- hObj' )
self self :class oalloc tuck self :sizeOf move
dup objRefCnt :his 1 swap ! ;m

:m :equals ( obj -- ) self = ;m

:m :hash ( -- u) self ;m

:m :init ( -- ) 1 objRefCnt ! ;m

:m :free ( -- ) self free throw ;m

:m :retain ( -- ) 1 objRefCnt +! ;m

:m :release ( -- )
-1 objRefCnt +!
objRefCnt @ 0= IF self :free THEN ;m

:m :print ( -- ) self :className type ." @" self h. ;m

drop

On 10/19/21 2:50 PM, pahihu wrote:

> It is a nice little late-bound thingy, I've played it with a little.

> : oallot ( cls -- obj) dup dfa @ here swap allot tuck ! ;
[..]> : :his ( otherobj 'ivar -- 'otherivar) self - + ;

> object
[..]
> :m :print ( -- ) self :className type ." @" self h. ;m
> drop

Yes. It is simple enough that one can readily customize to make it
do what you want. Linked lists (for late binding) are surprisingly fast.
I think duck typing is a very useful model.

-Doug

On 2021-10-14 03:16, Doug Hoffman wrote:
> On 10/13/21 6:02 PM, Ruvim wrote:
>> On 2021-10-10 16:03, Doug Hoffman wrote:
>>> On 10/10/21 6:24 AM, Ruvim wrote:
>>>> On 2021-09-12 16:19, Doug Hoffman wrote:

>> [...]
>>
>> I mean unification: to do it by providing a class for both early
>> binding and accessing another's instance variables.
>
> Anyone could change the mini-oop I show if they want different behavior.
[...]
> The nice thing is one can change the code in any way one desires.

Of course. But it's also true for any open source code.

The only common purpose of distributing/sharing source codes (in Forth)
is to evolve the Forth ecosystem. And one important factor of that is
code reuse in general.

Increasing the number of flavors of the same OOP module makes the
corresponding portability areas (for code reuse) smaller and more
fragmented.

So it's probably better to improve a popular OOP module than create an
incompatible fork of it.

Maybe this mini-oop can be also considered just as a
tutorial/illustration. But then it should be better commented.

[...]
>> But my choice is to use early binding in a simple way (without any
>> special things), and use some special things/decorators for late
>> binding only. Rationale: late binding is required much less frequently
>> than early binding.
>
> Interesting. That is exactly the behavior chosen by the implementers of
> Neon(1984). They also accomplished encapsulation without using
> wordlists. Andrew McKewan wrote an ANS compatible Neon-like extension
> and published it in Forth Dimensions, March 1997. It is very much like
> what the Win32Forth people have adopted, I believe. Some have criticized
> it for using message-object ordering (and some other things). If you
> want to see McKewan's code I could send it to you. I don't have a link,
> just the files.

Yes, I'm interested. I wanted to ask why don't you publish this code on
GitHub for history. But later I saw a post of Pahihu that the code is
already available online at

ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/CLASS10.TXT
ftp://ftp.taygeta.com/pub/Forth/Applications/ANS/CLASS10.ZIP

--
Ruvim

On Sunday, September 12, 2021 at 8:20:02 AM UTC-5, Doug Hoffman wrote:
> After paring away, the following code would be my idea of a mini-oop
> extension for Forth. Not a 12 liner, but loc will be recovered quickly
> as classes are written. Thanks to Bernd Paysan for a couple of ideas:
>
> -Doug
[snip code]

Hi, Doug. Is there any chance you could give a bit of explanation of the code
for me and the other silent noobs in the back row? It seems really cool,
but I just don't get it. Can't seem to shake the PostScript pov that I bring
to my Forth interest.
Like, I understand the "what" if that makes sense. The overall example
of how to use it is clear and easy to follow. But the "what it is doing" part.
That's what I'm having difficulty teasing out as an interested naif.
TIA
--droog

On Friday, October 22, 2021 at 9:48:19 PM UTC-5, luser droog wrote:
> On Sunday, September 12, 2021 at 8:20:02 AM UTC-5, Doug Hoffman wrote:
> > After paring away, the following code would be my idea of a mini-oop
> > extension for Forth. Not a 12 liner, but loc will be recovered quickly
> > as classes are written. Thanks to Bernd Paysan for a couple of ideas:
> >
> > -Doug
> [snip code]
>
> Hi, Doug. Is there any chance you could give a bit of explanation of the code
> for me and the other silent noobs in the back row? It seems really cool,
> but I just don't get it. Can't seem to shake the PostScript pov that I bring
> to my Forth interest.
> Like, I understand the "what" if that makes sense. The overall example
> of how to use it is clear and easy to follow. But the "what it is doing" part.
> That's what I'm having difficulty teasing out as an interested naif.
> TIA
> --droog

Is there an old post from Bernd Paysan that I should search up for context,
or is that a reference to a private communication?

luser droog <luser.droog@gmail.com> writes:
>Is there an old post from Bernd Paysan that I should search up for context,
>or is that a reference to a private communication?

<https://bernd-paysan.de/mini-oof.html> may be what you are looking for.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 10/22/21 10:48 PM, luser droog wrote:
> On Sunday, September 12, 2021 at 8:20:02 AM UTC-5, Doug Hoffman wrote:
>> After paring away, the following code would be my idea of a mini-oop

> Hi, Doug. Is there any chance you could give a bit of explanation of the code

Read this file and it should explain how the code works:

https://github.com/DouglasBHoffman/FMS2/blob/master/FMS2LL/FMS2LL.f

FMS2LL.f is a more full featured implementation of the same basic oop
engine. If you have any questions after looking at that feel free to ask.

-Doug

On Saturday, October 23, 2021 at 3:46:14 AM UTC-5, Doug Hoffman wrote:
> On 10/22/21 10:48 PM, luser droog wrote:
> > On Sunday, September 12, 2021 at 8:20:02 AM UTC-5, Doug Hoffman wrote:
> >> After paring away, the following code would be my idea of a mini-oop
> > Hi, Doug. Is there any chance you could give a bit of explanation of the code
> Read this file and it should explain how the code works:
>
> https://github.com/DouglasBHoffman/FMS2/blob/master/FMS2LL/FMS2LL.f
>
> FMS2LL.f is a more full featured implementation of the same basic oop
> engine. If you have any questions after looking at that feel free to ask.
>
> -Doug

Thanks, guys. I read those. I didn't quite sink in, but then I kinda drifted off into
other stuff. I guess I need to go back to Starting Forth and read the second
half more carefully. I think it's the CREATE ... DOES> that I'm shaky on and that
prevents me from really following the whole thing. So, back to the book, then
those links again, then back to OP. If/when I do that, I will be back with question.
Until then, ... thanks for the help. I'll get there.

--droog

On 11/20/21 10:02 PM, luser droog wrote:

> I guess I need to go back to Starting Forth and read the second half
> more carefully. I think it's the CREATE ... DOES> that I'm shaky on
> and that prevents me from really following the whole thing. So, back
> to the book,
When I was learning Forth the create...does> penny dropped for me when I
read the 2nd ed. of Starting Forth Chapter 11. Unfortunately the online
versions of SF that I see follow the 1st ed.. In the preface to the 2nd
ed. Brodie says "I've rewritten the explanations of ... defining words
.... which upon re-reading I found somewhat obtuse.

A quick summary using CONSTANT as an example:

A defining word has a time sequence that involves 3 distinct times.

Time 1) Define the defining word CONSTANT
: constant ( n 'name' -- ) create , does> ( -- addr ) @ ;

Time 2) Execute CONSTANT which in turn performs 3 actions
76 constant trombones
Action 1. create a dictionary header with the name trombones
Action 2. comma the value (e.g., 76) from the stack into the
constant's parameter field
Action 3. reset trombone's code pointer field to point to the
code after does>

Time 3) Execute trombones. Since trombones now points to the code
following does>, it fetches the value (76), pushing it
onto the stack. Notice that at Time 3) does> first pushes
onto the stack the child's pfa.

-Doug

On Monday, November 22, 2021 at 6:49:40 AM UTC-6, Doug Hoffman wrote:
> On 11/20/21 10:02 PM, luser droog wrote:
>
> > I guess I need to go back to Starting Forth and read the second half
> > more carefully. I think it's the CREATE ... DOES> that I'm shaky on
> > and that prevents me from really following the whole thing. So, back
> > to the book,
> When I was learning Forth the create...does> penny dropped for me when I
> read the 2nd ed. of Starting Forth Chapter 11. Unfortunately the online
> versions of SF that I see follow the 1st ed.. In the preface to the 2nd
> ed. Brodie says "I've rewritten the explanations of ... defining words
> ... which upon re-reading I found somewhat obtuse.
>
>
> A quick summary using CONSTANT as an example:
>
> A defining word has a time sequence that involves 3 distinct times.
>
> Time 1) Define the defining word CONSTANT
> : constant ( n 'name' -- ) create , does> ( -- addr ) @ ;
>
> Time 2) Execute CONSTANT which in turn performs 3 actions
> 76 constant trombones
> Action 1. create a dictionary header with the name trombones
> Action 2. comma the value (e.g., 76) from the stack into the
> constant's parameter field
> Action 3. reset trombone's code pointer field to point to the
> code after does>
>
> Time 3) Execute trombones. Since trombones now points to the code
> following does>, it fetches the value (76), pushing it
> onto the stack. Notice that at Time 3) does> first pushes
> onto the stack the child's pfa.
>

Hmm. It all seems so simple now (which makes me suspect I've missed
something). Let me see if I can extend it to a pair.

: pair ( x y 'name' -- ) create swap , , does> ( -- addr ) ;
: x @ ;
: y cell + @ ;

Something like that? Hmmm. That's pretty nifty.

On Monday, November 22, 2021 at 6:49:40 AM UTC-6, Doug Hoffman wrote:
> On 11/20/21 10:02 PM, luser droog wrote:
>
> > I guess I need to go back to Starting Forth and read the second half
> > more carefully. I think it's the CREATE ... DOES> that I'm shaky on
> > and that prevents me from really following the whole thing. So, back
> > to the book,
> When I was learning Forth the create...does> penny dropped for me when I
> read the 2nd ed. of Starting Forth Chapter 11. Unfortunately the online
> versions of SF that I see follow the 1st ed.. In the preface to the 2nd
> ed. Brodie says "I've rewritten the explanations of ... defining words
> ... which upon re-reading I found somewhat obtuse.

Aha. Mine's a 1st edition. I like buying "acceptable"-quality used books
in the hope they have fun notes and highlighting.* I might hunt up a 2ed.

*I got really lucky with a copy of Iverson's 1962 APL book. The copy I
got had wrong answers written in (!) and wrong corrections to the
figure references in the text (Iverson got that stuff right the first time).

On 11/23/21 9:23 PM, luser droog wrote:

> Hmm. It all seems so simple now (which makes me suspect I've missed
> something). Let me see if I can extend it to a pair.
>
> : pair ( x y 'name' -- ) create swap , , does> ( -- addr ) ;
> : x @ ;
> : y cell + @ ;
>
> Something like that?
Actually the following does the same thing:

: pair ( x y 'nam' -- ) create swap , , ;
\ x and y as you have them

If that's what you want it is fine as is. But the real power of create
.... does> is achieved by giving action to the does> part. For example:

: pair' ( x y 'name' -- )
create swap , , does> ( -- x y ) dup @ swap cell+ @ ;

10 20 pair' p1
30 40 pair' p2
p1 . . \ => 20 10
p2 . . \ => 40 30

I may have mislead you with the stack effect in the trombones example.

-Doug