• Re: Value Flavored Structs( was Re: Library Code)

    From dxforth@21:1/5 to S Jack on Tue Mar 15 15:48:45 2022
    On 15/03/2022 04:37, S Jack wrote:
    On Sunday, March 13, 2022 at 8:32:24 PM UTC-5, dxforth wrote:
    Where's the gain for breaking convention? Were I to implement ' foo FORGET >> it would necessitate a second vocab search using xt to find the nfa. It

    I don't have that cost; my xt (pfa) to nfa doesn't require a search so tick is the
    only search and is factored out.

    You've factored out the search for the target address. Perhaps it's all you need. For most of us FORGET still needs to search every vocab and thread
    in the dictionary and trim those at the appropriate point. And that's not counting the things that may need to be undone such as DEFERs pointing to
    words that no longer exist.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From S Jack@21:1/5 to dxforth on Tue Mar 15 01:13:51 2022
    On Monday, March 14, 2022 at 11:48:48 PM UTC-5, dxforth wrote:
    On 15/03/2022 04:37, S Jack wrote:
    On Sunday, March 13, 2022 at 8:32:24 PM UTC-5, dxforth wrote:
    Where's the gain for breaking convention? Were I to implement ' foo FORGET >> it would necessitate a second vocab search using xt to find the nfa. It

    I don't have that cost; my xt (pfa) to nfa doesn't require a search so tick is the
    only search and is factored out.
    You've factored out the search for the target address. Perhaps it's all you need. For most of us FORGET still needs to search every vocab and thread
    in the dictionary and trim those at the appropriate point. And that's not counting the things that may need to be undone such as DEFERs pointing to words that no longer exist.

    No, I trim the vocabularies but I don't fix broken vocab chains. I do, however, fence
    at a vocabulary when I create one. Then FORGET will bomb if a vocabulary is in the
    memory being affected and I know to manually fix it. Nor do I deal with DEFERs
    pointing to de-allocated memory. Those are piss-ant problems that seldom affect me
    and have no bearing on FORGET word order.
    --
    me

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Paul Rubin on Wed Mar 16 09:21:11 2022
    Paul Rubin <no.email@nospam.invalid> writes:
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    so you can tell if it started as a 2VALUE etc.
    2VALUEs and FVALUEs are fundamentally incompatible with VALUEs,
    CVALUEs, WVALUEs, LVALUEs: the latter produce a cell (and TO consumes
    a cell for them), while 2VALUEs produce two cells, and FVALUEs produce
    a float.

    Yes, that is the idea of having a companion to ADDR that makes the type
    and (maybe implicitly) size info available. So you can implement
    something like TO in terms of ADDR and its companion.

    We implement TO through a method for word headers. For
    value-flavoured fields, this method knows how to compute the address
    and what access to perform at this address. No explicit type
    information needed.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to S Jack on Wed Mar 16 09:26:37 2022
    S Jack <sdwjack69@gmail.com> writes:
    On Friday, March 11, 2022 at 12:35:40 AM UTC-6, Marcel Hendrix wrote:
    On Friday, March 11, 2022 at 2:25:06 AM UTC+1, S Jack wrote:
    [..]
    Actually, I would fully endorse such a move. But not for TO etc.,
    where the prefix construct has clear advantages.

    That the parsing word could do some optimization (if that's what you are >referring to as the clear advantage) did play somewhat in decision to not >change TO and IS . But that advantage didn't appear to be too significant
    ( I could easily be wrong there.)

    In Gforth's development version TO first gets the nt of the word, and
    then calls the method (TO) for the word. We do not have any
    optimization disadvantages from that. I explain the details below,
    but it's actually Bernd Paysan who came up with most of this (with
    some feedback from me and a key part played by Matthias Koch's literal
    stack).

    Here is an implementation of VALUE and TO in development Gforth. This
    is a simplified version of the actual implementation, but it works (at
    least for the example below).

    \ First, the method implementation of the method (TO) for VALUEs:
    : value-to ( n value-xt -- ) \ gforth-internal
    \g this is the TO-method for normal values
    >body ! ;

    \ The implementation of COMPILE, for VALUE-TO:
    : compile-value-to ( xt-value-to -- )
    drop ]] >body ! [[ ;
    ' compile-value-to optimizes value-to

    \
    : value ( n "name" -- )
    create ,
    ['] @ set-does> \ like DOES> @ ;
    ['] value-to set-to \ The method implementation for (TO) is now VALUE-TO
    ;

    : name>(to) ( nt -- xt-(to-implementation )
    \ given an nt, the following magic incantation produces the xt of
    \ the (TO) implementation of the word represented by nt.
    >namehm @ >hmto @ ;

    \ Now we (re)implement the method selector (TO)
    : (to) ( v nt -- )
    dup name>(to) execute ;

    \ and an optimized implementation of COMPILE, for (TO) (for TO "name")
    : compile-(to) ( xt-(to -- )
    lits# if \ do we have the nt as literal?
    \ if so, resolve the method lookup now, during compilation
    drop lits> ( xt-name ) dup >lits name>(to) compile,
    else \ if there is no literal preceding the (TO)
    :, \ compile a call to (to)
    then ;
    ' compile-(to) optimizes value-to

    \ IS and TO are interchangeable in Gforth
    \ interpretation semantics for TO; (') produces the nt of "name"
    : <IS> ( v "name" -- ) \ gforth
    (') (to) ;

    \ compilation semantics for TO
    : [IS] ( compilation "name" -- ; run-time v -- ) \ gforth bracket-is
    (') ]] literal (to) [[ ; immediate

    \ now combine them into the word TO
    ' <IS> ' [IS] interpret/compile: TO ( value "name" -- ) \ core-ext
    \g changes the value of @var{name} to @var{value}

    And here's an example of using this (gives the same result whether you
    first load the code above or not):

    0 value x
    5 to x
    cr x . \ 5
    : to-x to x ;
    see to-x \ : to-x ['] x ! ;
    6 to-x
    cr x . \ 6

    The output of SEE TO-X is slightly different, but equivalent to the
    one shown above.

    As you can see in the output of SEE TO-X, the method (TO) has been
    completely resolved at compile time, despite [IS] (the compilation
    semantics of TO) passing the nt of "name" to (TO). This works by
    LITERAL actually pushing the nt on the compile-time literal stack, and
    the optimized COMPILE, implementation of (TO) checking whether there
    is a literal, and resolving the method at compile time in that case.

    This alone would lead to compiling

    : to-x ['] x value-to ;

    But we also have an optimizing COMPILE, implementation of VALUE-TO,
    leading to the final result. In present Gforth >BODY is a
    noop,otherwise the decompiler would show:

    : to-x <x> ! ;

    <x> denotes the PFA of a word. In that case you would also see more
    clearly that COMPILE,ing >BODY (in COMPILE-VALUE-TO) with a non-empty
    literal stack is optimized away by just changing the top value on the
    literal stack.

    Ok, you might say that this is quite a chunk of code for a result that
    other systems get more directly with less code. The benefit of this
    approach is that we don't have the pitfalls of STATE-smart words and
    yet the full performance benefits of a fast implementation of TO. We
    can also easily add additional word types on which TO can be applied
    (such as value-flavoured fields): just implement the (TO)
    implementation and the defining word.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Doug Hoffman on Wed Mar 16 13:50:37 2022
    Doug Hoffman <dhoffman888@gmail.com> writes:
    On 3/10/22 8:58 AM, Anton Ertl wrote:
    Doug Hoffman <dhoffman888@gmail.com> writes:
    On 3/8/22 5:05 PM, Anton Ertl wrote:
    But ... (... value-flavoured fields) have nothing to do with OOP;
    they miss an essential feature of OOP: dynamic binding.

    So they would be a simpler subset of an oop extension.

    No.

    The syntax is the same.

    No.

    My apologies, these statements apply to VALUEs and FVALUEs and LOCALs. I
    had been reading N.Nelson's 2020 EuroForth paper "Extending the Value >Concept" where he talks first about VALUEs and then STRUCTs. So yes,
    with value flavored STRUCTs we need an extra stack input item so the
    syntax is not exactly the same (though very similar IMO).

    No, the syntax

    TO <name>

    is not the same as the syntax

    ( object ) method-selector

    and also not the same as your "simple Neon modification"

    ( object ) method-selector **

    Many Forths already do the following:

    0 value v
    1 to v
    1 +to v
    v . \ => 2

    0e fvalue fv
    1e to fv
    1e +to fv
    fv f. \ => 2.0000000

    : test 0 locals| lv |
    1 to lv 1 +to lv lv . ;
    test \ => 2

    So the above shows 3 different "types" of Forth "objects" that all
    respond to the same (overloaded) messages, I mean operators.

    In Forth we have words and cells. And the difference is that

    TO <word>

    requires <word> in the input stream, whereas a method in a competent
    Forth OOP extension expects a cell on the stack that contains the
    address of an object. In
    <2022Mar16.102637@mips.complang.tuwien.ac.at> I showed how TO can be implemented in an object-oriented way by getting the nt of <word>, and
    then passing that to the method selector (TO). That does not mean at
    all that they are the same, as demonstrated by e.g., Gforth 0.7, where
    TO is implemented completely differently and in a not so easily
    extended way.

    The
    underlying code may be a case statement or whatever. My point was that
    this *syntax* is identical to <parameter> <message> <object>. I
    understand fully that it is not exactly the same as oop. But the syntax
    above is no different.

    Of course it's different, because in the general case addresses of
    objects are passed on the stack, and therefore have to be pushed
    before invoking the method selector.

    The oop discussions are dead.

    Well, I thought that we had reached consensus at least on passing
    objects on the stack (aka "object method" syntax), but you seem to
    want to ressurect this part of these discussions.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ice Black@21:1/5 to All on Wed Mar 16 13:02:38 2022
    REQUIRE lib/string.f

    : words-with-char ( s-addr ch -- count ) {: strIn ch | input words count :}
    string new TO input
    strIn input [string]-> !

    " " input [string]-> split TO words

    0 TO count
    words [array]-> get-count 0 DO
    ch I words [array]-> get [string]-> find-ch 0> IF
    count 1+ TO count
    THEN
    LOOP

    input delete
    words delete
    count
    ;

    : test
    " The oop discussions are dead" [CHAR] a words-with-char . CR
    ;
    test
    2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Rubin@21:1/5 to Anton Ertl on Wed Mar 16 16:34:19 2022
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    We implement TO through a method for word headers. For
    value-flavoured fields, this method knows how to compute the address

    Right, but what about wanting to use ADDR to pass the address to
    something? It is theoretically desirable to have the result of ADDR
    also be able to report the size and access methods. Maybe not in Forth
    though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Paul Rubin on Thu Mar 17 07:47:07 2022
    Paul Rubin <no.email@nospam.invalid> writes:
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    We implement TO through a method for word headers. For
    value-flavoured fields, this method knows how to compute the address

    Right, but what about wanting to use ADDR to pass the address to
    something? It is theoretically desirable to have the result of ADDR
    also be able to report the size and access methods.

    Practically we have not found a need yet. If there was one, I would
    hope that the access methods are sufficient; size is doable (maybe
    useful for MOVE), but the type is probably best just represented as a
    getter and a setter method.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jan Coombs@21:1/5 to Paul Rubin on Thu Mar 17 09:14:18 2022
    On Wed, 16 Mar 2022 16:34:19 -0700
    Paul Rubin <no.email@nospam.invalid> wrote:

    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    We implement TO through a method for word headers. For
    value-flavoured fields, this method knows how to compute the address

    Right, but what about wanting to use ADDR to pass the address to
    something? It is theoretically desirable to have the result of ADDR
    also be able to report the size and access methods. Maybe not in Forth though.

    An advantage of not having the address is that the system could de-fragment and perform other memory storage operations transparently in the background.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Jan Coombs on Thu Mar 17 09:46:18 2022
    Jan Coombs <jan4comp.lang.forth@murray-microft.co.uk> writes:
    An advantage of not having the address is that the system could
    de-fragment and perform other memory storage operations transparently
    in the background.

    Certainly for value-flavoured fields we are out of luck, because we
    would need to have complete compile-time knowledge about where struct
    addresses reside.

    But of course one might pursue this idea further, and design a "Forth"
    system which does not give out general addresses, only typed addresses
    which allow the system to determin exactly which cells are addresses
    and which are other things; and this can then be used for precise
    garbage collection. The resulting language would probably have a much
    more Java-like feeling, but maybe it would be closer to traditional
    Forth than I expect. Certainly oForth has some features that I
    associated with "not Forth", but it turned out to be much Forthier
    than I had expected.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Anton Ertl on Thu Mar 17 12:36:20 2022
    anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    But of course one might pursue this idea further, and design a "Forth"
    system which does not give out general addresses, only typed addresses
    which allow the system to determin exactly which cells are addresses
    and which are other things; and this can then be used for precise
    garbage collection.

    Of course the question is if precise garbage collection is a goal
    worth the costs. And if so, what the right approach is. E.g., OCaml
    is a language with a type system that makes it possible to track all
    addresses with compiler smarts and without general tagging of all
    data; yet when I looked at the Ocaml implementation, it used a bit in
    every cell to say whether that cell contained an address or not; this
    saved complexity in the compiler.

    In any case, I have thought some more about how a Forth system without
    general addresses (a Managed Forth) could look like: I am thinking
    about a system with somewhat Java-like objects (rather than a system
    like Lisp or Postscript with only a few built-in types). The Forth
    system would have a separate objects stack that contains references to
    these objects, as well as the usual data stack that contains integers (including characters), and of course the FP stack.

    The objects are the usual ones with fields (aka object variables or
    instance variables), but also arrays. You access a field with a value-flavoured access word, say LIST-NEXT (list -- obj). You access
    an array with the value-flavoured [] (array u -- v). There is no
    address arithmetic or somesuch. An array access is bounds-checked
    (and somewhat type-checked), a field access checks that it accesses
    the right kind of object. There is no address arithmetics. Whether
    field names are private, public, or configurable is beyond the present discussion.

    Discussion: We get from the low-level nature of Forth into what is
    known as "managed languages", with all advantages (better security as
    long as we don't call C libraries for performance reasons:-) and
    disadvantages (some performance techniques can no longer be used).

    Related work: Oforth seems to have similar goals, but it does not use
    a separate object stack, which means that it needs some compiler
    smarts or more run-time provisions for differentiating between
    addresses and non-addresses. Postscript also has only one typed
    stack. By contrast, separating the object stack from the data stack
    allows full performance for integer operations without compiler
    smarts.

    I doubt that I will find the time to pursue this idea further in the foreseeable future.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From minforth@arcor.de@21:1/5 to Anton Ertl on Thu Mar 17 08:20:03 2022
    Anton Ertl schrieb am Donnerstag, 17. März 2022 um 14:27:18 UTC+1:
    an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
    But of course one might pursue this idea further, and design a "Forth" >system which does not give out general addresses, only typed addresses >which allow the system to determin exactly which cells are addresses
    and which are other things; and this can then be used for precise
    garbage collection.
    Of course the question is if precise garbage collection is a goal
    worth the costs. And if so, what the right approach is. E.g., OCaml
    is a language with a type system that makes it possible to track all addresses with compiler smarts and without general tagging of all
    data; yet when I looked at the Ocaml implementation, it used a bit in
    every cell to say whether that cell contained an address or not; this
    saved complexity in the compiler.

    In any case, I have thought some more about how a Forth system without general addresses (a Managed Forth) could look like: I am thinking
    about a system with somewhat Java-like objects (rather than a system
    like Lisp or Postscript with only a few built-in types). The Forth
    system would have a separate objects stack that contains references to
    these objects, as well as the usual data stack that contains integers (including characters), and of course the FP stack.

    The objects are the usual ones with fields (aka object variables or
    instance variables), but also arrays. You access a field with a value-flavoured access word, say LIST-NEXT (list -- obj). You access
    an array with the value-flavoured [] (array u -- v). There is no
    address arithmetic or somesuch. An array access is bounds-checked
    (and somewhat type-checked), a field access checks that it accesses
    the right kind of object. There is no address arithmetics. Whether
    field names are private, public, or configurable is beyond the present discussion.

    Discussion: We get from the low-level nature of Forth into what is
    known as "managed languages", with all advantages (better security as
    long as we don't call C libraries for performance reasons:-) and disadvantages (some performance techniques can no longer be used).

    Related work: Oforth seems to have similar goals, but it does not use
    a separate object stack, which means that it needs some compiler
    smarts or more run-time provisions for differentiating between
    addresses and non-addresses. Postscript also has only one typed
    stack. By contrast, separating the object stack from the data stack
    allows full performance for integer operations without compiler
    smarts.

    I doubt that I will find the time to pursue this idea further in the foreseeable future.

    There is one additional difficulty: exception handling.

    CATCH/THROW should include the object stack, and rewind it including
    freeing memory of discarded objects. While this would be no rocket science
    for pure data objects, freeing classes or objects with pointers to other objects
    could become rather complex.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to minf...@arcor.de on Thu Mar 17 16:48:52 2022
    "minf...@arcor.de" <minforth@arcor.de> writes:
    CATCH/THROW should include the object stack, and rewind it

    Yes.

    including
    freeing memory of discarded objects. While this would be no rocket science >for pure data objects, freeing classes or objects with pointers to other ob= >jects
    could become rather complex.=20

    For a garbage collector nothing has to be done; it keeps only
    reachable data around, so if a reference on the object stack was the
    last ones to an object, its memory will be reclaimed on the next
    garbage collection. Actually the name is a bit misleading, because
    garbage collection, especially copying garbage collection only
    collects non-garbage and considers everything else reclaimable memory.

    For reference counting references deleted with THROW are just the same
    as references deleted with DROP: decrease the reference count, and
    reclaim the memory if the count reaches 0. THROW also does not change
    anything about the circular reference Achilles heel of reference
    counting.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Doug Hoffman@21:1/5 to Anton Ertl on Fri Mar 18 06:20:33 2022
    On 3/16/22 9:50 AM, Anton Ertl wrote:
    Doug Hoffman <dhoffman888@gmail.com> writes:

    The oop discussions are dead.

    Well, I thought that we had reached consensus at least on passing
    objects on the stack (aka "object method" syntax), but you seem to
    want to ressurect this part of these discussions.

    No. I am too heavily invested now in object-method to want to change.
    I was just commenting that method-object works fine also. The sudden resurrection of method-object via method-flavored fields (structs) is
    pretty strong proof though I know you don't agree with that observation.
    I am done with this.

    -Doug

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jali Heinonen@21:1/5 to All on Fri Mar 18 04:47:53 2022
    perjantai 18. maaliskuuta 2022 klo 12.20.39 UTC+2 Doug Hoffman kirjoitti:
    On 3/16/22 9:50 AM, Anton Ertl wrote:
    Doug Hoffman <dhoff...@gmail.com> writes:

    The oop discussions are dead.

    Well, I thought that we had reached consensus at least on passing
    objects on the stack (aka "object method" syntax), but you seem to
    want to ressurect this part of these discussions.
    No. I am too heavily invested now in object-method to want to change.
    I was just commenting that method-object works fine also. The sudden resurrection of method-object via method-flavored fields (structs) is
    pretty strong proof though I know you don't agree with that observation.
    I am done with this.

    -Doug

    I have never felt the need for full OOP implementation. My ideal implementation would be just UDT with methods and could done using map and object stack to store the "self" pointer. Words inside object namespace could be called using some syntactical
    sugar. I think inheritance makes code hard to maintain and follow.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Doug Hoffman@21:1/5 to Jali Heinonen on Fri Mar 18 07:59:16 2022
    On 3/18/22 7:47 AM, Jali Heinonen wrote:

    I have never felt the need for full OOP implementation.

    You are not alone. Many find it sufficient to use just parts of oop
    behavior, which seems very reasonable to me. I don't think it is
    possible to define, regardless of programming language, exactly what is
    a "full" oop implementation. At least one won't get much agreement about
    this. I don't see that as a problem.

    -Doug

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ice Black@21:1/5 to All on Fri Mar 18 12:18:12 2022
    пʼятниця, 18 березня 2022 р. о 13:59:22 UTC+2 Doug Hoffman пише:
    On 3/18/22 7:47 AM, Jali Heinonen wrote:

    I have never felt the need for full OOP implementation.
    You are not alone. Many find it sufficient to use just parts of oop behavior, which seems very reasonable to me. I don't think it is
    possible to define, regardless of programming language, exactly what is
    a "full" oop implementation. At least one won't get much agreement about this. I don't see that as a problem.

    -Doug

    I'm a big fun of oop, but not crazy with it. OOP is just a methodology to deal with the complexity of the program. If the problem can be solved without it, probably it would be better to avoid it. The advantage of oop in complex solution is the ability
    to operate on next level of abstraction in some sort of unified way, i.e. - dynamic arrays, lists, maps, strings, threads...

    Yeah, what is "full" oop implementation definition is a bit complex. Let's stick to the classic defintion: if system provides the ability of encapsulation, inheritance and polymorphism - it is full oop. Automatic garbge collection is good feature in
    general if you are ok with perfomrance overhead, but not related to oop. (I think if you turn something ON, you are also responsible to turn this OFF).

    Could someone explain the terminology used in this thread:
    "UDT"?
    "object method" syntax?
    "method-flavored fields (structs)"?

    Thank you in advance.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Ice Black on Sat Mar 19 07:24:59 2022
    Ice Black <blackice7777@gmail.com> writes:
    Yeah, what is "full" oop implementation definition is a bit complex. Let's = >stick to the classic defintion: if system provides the ability of encapsula= >tion, inheritance and polymorphism - it is full oop.

    Where does this classic definition come from.

    Could someone explain the terminology used in this thread:
    "UDT"?

    Never heard of that.

    "object method" syntax?

    Neon (an early Forth system that claimed to implement object
    orientation) and its descendants used a syntax somewhat like:

    make-rectangle rectangle1 \ create rectangle1 object
    draw rectangle1 \ send message "draw" to object "rectangle1"

    This was the "method object" (aka "message object") syntax. The
    disadvantage is that it requires the object to be represented by a
    named word. Later object extensions for Forth avoided that problem by
    passing the address of the object on the stack. If you have a named
    word for the object, this results in the syntax

    rectangle1 draw

    In the discussions around syntax, this was often referred to as
    "object method" syntax. However, this term highlights a superficial
    difference and hides the fundamental difference, so I prefer not to
    use it.

    "method-flavored fields (structs)"?

    Forth has defining words VARIABLE and VALUE.

    variable var
    0 value val

    You access the words defined with these words as follows:

    \ write access
    1 var !
    1 to var
    \ read access
    var @ .
    val .

    Later defining words typically created words that behave like
    variables (variable-flavoured) or that behave like values
    (value-flavoured). E.g., standard locals are value-flavoured, while
    the standardized field words are variable-flavoured (you need to use
    @, ! to access a field defined with FIELD:, C@ and C! to access a
    field defined with CFIELD:, etc.).

    I don't remember "method-flavoured" in this discussion (it does not
    occur in any posting I have written).

    Gforth does have defining words that define defer-flavoured words,
    though. Can you guess how they behave?

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Ice Black on Sun Mar 20 16:15:24 2022
    Ice Black <blackice7777@gmail.com> writes:
    Gforth does have defining words that define defer-flavoured words,=20
    though. Can you guess how they behave?

    Do you mean defining word 'forward'? I took a look at the implementation bu= >t it is too complex, I just get the general idea how I would implement this= >.

    No, I did not mean FORWARD. FORWARD is an interesting demonstration
    of how various recent Gforth features can be used for good effect, but understanding it is fairly involved. You can find an explanation in <2018Dec31.161743@mips.complang.tuwien.ac.at> (<http://al.howardknight.net/?ID=164779351600>, unfortunately
    truncated, but the main explanation is there).

    But what I meant is, e.g., defer-flavoured locals:

    : foo {: xt: x :}
    x \ this EXECUTE's the xt stored in x
    ;

    1 2 ' + foo . \ 3

    You can also use ACTION-OF and IS on defer-flavoured words, but if you
    do a lot of that, it's probably better to use a value-flavoured or variable-flavoured word in combination with EXECUTE.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Marcel Hendrix on Sun Mar 20 18:47:28 2022
    Marcel Hendrix <mhx@iae.nl> writes:
    On Sunday, March 20, 2022 at 5:33:53 PM UTC+1, Anton Ertl wrote:
    But what I meant is, e.g., defer-flavoured locals:

    : foo {: xt: x :}
    x \ this EXECUTE's the xt stored in x
    ;

    1 2 ' + foo . \ 3

    You can also use ACTION-OF and IS on defer-flavoured words, but if you
    do a lot of that, it's probably better to use a value-flavoured or
    variable-flavoured word in combination with EXECUTE.

    Sorry, but what is the difference with a standard
    : foo ( ? xt -- arity1 ) ( F: ? -- arity2 )
    >R ( something ) R> EXECUTE ( something else ) ;
    ?

    For this small example, there is no significant difference from that or

    : foo execute ;

    So what is the purpose of ACTION-OF
    or IS then?

    ACTION-OF is if you want to get the xt from x rather than EXECUTEing
    it. IS is if you want to change what xt x EXECUTEs. Just like with
    any other DEFERred word. A usage example:

    : A {: w^ k x1 x2 x3 xt: x4 xt: x5 | w^ B :} recursive
    k @ 0<= IF x4 x5 + ELSE
    B k x1 x2 x3 action-of x4 [{: B k x1 x2 x3 x4 :}L
    -1 k +!
    k @ B @ x1 x2 x3 x4 A ;] dup B !
    execute THEN ;
    : man-or-boy? ( n -- n' ) [: 1 ;] [: -1 ;] 2dup swap [: 0 ;] A ;

    This is Gforth's variant of Knuth's man-or-boy test. As is usual for
    Knuth's examples, there is no intrinsic point, so don't try to
    understand it; but you can see how defer-flavoured locals are used
    here directly and with ACTION-OF.

    The unexpected thing is that I have found more uses for
    defer-flavoured locals than for variable-flavoured locals.

    - 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcel Hendrix@21:1/5 to Anton Ertl on Sun Mar 20 11:38:48 2022
    On Sunday, March 20, 2022 at 5:33:53 PM UTC+1, Anton Ertl wrote:
    Ice Black <blacki...@gmail.com> writes:
    Gforth does have defining words that define defer-flavoured words,
    though. Can you guess how they behave?

    Do you mean defining word 'forward'? I took a look at the implementation
    but it is too complex, I just get the general idea how I would implement
    this.

    No, I did not mean FORWARD. FORWARD is an interesting demonstration
    of how various recent Gforth features can be used for good effect, but understanding it is fairly involved. You can find an explanation in <2018Dec3...@mips.complang.tuwien.ac.at> (<http://al.howardknight.net/?ID=164779351600>, unfortunately
    truncated, but the main explanation is there).

    But what I meant is, e.g., defer-flavoured locals:

    : foo {: xt: x :}
    x \ this EXECUTE's the xt stored in x
    ;

    1 2 ' + foo . \ 3

    You can also use ACTION-OF and IS on defer-flavoured words, but if you
    do a lot of that, it's probably better to use a value-flavoured or variable-flavoured word in combination with EXECUTE.

    Sorry, but what is the difference with a standard
    : foo ( ? xt -- arity1 ) ( F: ? -- arity2 )
    >R ( something ) R> EXECUTE ( something else ) ;
    ?
    I assume foo does not store the xt, because then it would be called
    like 1 2 foo , not as 1 2 ' + foo . So what is the purpose of ACTION-OF
    or IS then?

    -marcel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From minforth@arcor.de@21:1/5 to Anton Ertl on Sun Mar 20 13:31:09 2022
    Anton Ertl schrieb am Sonntag, 20. März 2022 um 19:55:38 UTC+1:
    : A {: w^ k x1 x2 x3 xt: x4 xt: x5 | w^ B :} recursive
    k @ 0<= IF x4 x5 + ELSE
    B k x1 x2 x3 action-of x4 [{: B k x1 x2 x3 x4 :}L
    -1 k +!
    k @ B @ x1 x2 x3 x4 A ;] dup B !
    execute THEN ;
    : man-or-boy? ( n -- n' ) [: 1 ;] [: -1 ;] 2dup swap [: 0 ;] A ;

    This is Gforth's variant of Knuth's man-or-boy test. As is usual for
    Knuth's examples, there is no intrinsic point, so don't try to
    understand it; but you can see how defer-flavoured locals are used
    here directly and with ACTION-OF.

    Only morons tell you that Forth is a write-only language. ;-)
    Brain guys call it a Turing tarpit.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From luser droog@21:1/5 to Anton Ertl on Sun Mar 20 22:12:30 2022
    On Thursday, March 17, 2022 at 4:55:25 AM UTC-5, Anton Ertl wrote:
    Jan Coombs <jan4comp....@murray-microft.co.uk> writes:
    An advantage of not having the address is that the system could
    de-fragment and perform other memory storage operations transparently
    in the background.
    Certainly for value-flavoured fields we are out of luck, because we
    would need to have complete compile-time knowledge about where struct addresses reside.

    But of course one might pursue this idea further, and design a "Forth"
    system which does not give out general addresses, only typed addresses
    which allow the system to determin exactly which cells are addresses
    and which are other things; and this can then be used for precise
    garbage collection. The resulting language would probably have a much
    more Java-like feeling, but maybe it would be closer to traditional
    Forth than I expect. Certainly oForth has some features that I
    associated with "not Forth", but it turned out to be much Forthier
    than I had expected.
    - anton

    AFAIUI that's almost exactly how Java was borne. Gosling's previous projects had been a popular implementation of emacs, and Sun NeWS , a windowing
    system built using object-oriented PostScript.

    https://www.academia.edu/27027623/A_User_Interface_Toolkit_in_Object_Oriented_PostScript_Owen_M_Densmore

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From minforth@arcor.de@21:1/5 to luser droog on Mon Mar 21 00:06:17 2022
    luser droog schrieb am Montag, 21. März 2022 um 06:12:32 UTC+1:
    On Thursday, March 17, 2022 at 4:55:25 AM UTC-5, Anton Ertl wrote:
    Jan Coombs <jan4comp....@murray-microft.co.uk> writes:
    An advantage of not having the address is that the system could >de-fragment and perform other memory storage operations transparently
    in the background.
    Certainly for value-flavoured fields we are out of luck, because we
    would need to have complete compile-time knowledge about where struct addresses reside.

    But of course one might pursue this idea further, and design a "Forth" system which does not give out general addresses, only typed addresses which allow the system to determin exactly which cells are addresses
    and which are other things; and this can then be used for precise
    garbage collection. The resulting language would probably have a much
    more Java-like feeling, but maybe it would be closer to traditional
    Forth than I expect. Certainly oForth has some features that I
    associated with "not Forth", but it turned out to be much Forthier
    than I had expected.
    - anton
    AFAIUI that's almost exactly how Java was borne. Gosling's previous projects had been a popular implementation of emacs, and Sun NeWS , a windowing system built using object-oriented PostScript.

    https://www.academia.edu/27027623/A_User_Interface_Toolkit_in_Object_Oriented_PostScript_Owen_M_Densmore

    Reflection is one of Java's prominent features and thus it needed fat pointers (typed addresses) from the beginning.

    Forth's header structure can be thought of as fat pointer to code segments.
    TO is overloaded and thus either the compiler or the runtime system needs
    type information. So you have some reflection also within Forth.

    Unfortunately type information varies from one Forth system to the next
    (even often between releases of a Forth system) which makes code sharing practically impossible.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)