Re: value-flavoured structures

Ruvim <ruvim.pinka@gmail.com> writes:

On 2024-10-04 22:04, Anton Ertl wrote:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2024-10-04 15:52, Anton Ertl wrote:

It can be defined: Gforth has SET-TO

...

I wonder why a kind of "TO" is not used to set this field/property, and
*maybe* a kind of "ACTION-OF" to get this property.

 
Interesting idea.  Maybe in some future version.

Thinking some more about it, better not:

SET-TO SET-OPTIMIZER etc. all work on the latest definition.  The
methods that they set work on an NT or XT passed on the stack.  The
usual behaviour of defer-flavoured words is that the context is the
same.  If you have

defer d
' foo is d
action-of d

That's always the same global D.  For a defer-flavoured field,
likewise:

0
  value: vf
  defer: df
constant mystruct

create foo mystruct allot

1   foo to vf
' . foo is df

foo vf .
2 foo df

So having TO TO instead of SET-TO would disobey this principle.

For COMPILE, there is the additional problem that it is a deferred
word, so when you do "IS COMPILE," you change the behaviour for all
uses of "COMPILE,", not just of the latest definition.  The actual
method of each definition is called OPT-COMPILE,.

What advantages do you see in *using* the to-based setters?

Over using SET-... words?

1) It's a popular and convenient mechanism.

2) I can find out the setter from looking at the central word:

``vf .hm
\ output:
opt:     $7F43EB229B98
to:      $7F43EB229BE0
extra:   $7F43EB229B60

int:    noop
comp:   default-name>comp
string: named>string
link:   named>link  ok

Ok, $7F43EB229BE0 is not very informative, but I can still make use of
that:

$7F43EB229BE0 xt-locate
struct-val.fs:88
...
cell      ' aligned   ' @   !a-table   wrap+value: value:   ( u1 "name" -- u2 ) \ gforth-experimental
...

The lack of flexibility of standard TO has not deterred them from
using that.

>
This statement contains the logical fallacy "Survivorship bias" [1].
>
There are different use cases. In some use cases the discussed
flexibility is not needed, in other — it is needed.

That's a very Forthy way of looking at it.  The usual argument for
getters and setters is that that flexibility might be needed in the
future, so you don't use a mechanism like variables or values that
does not provide this flexibility, in order to avoid having to change
all the places where the variable or value is used, and only have to
change the place where the getter and setter is defined.  In this
scenario value-flavoured words must not be used unless the flexibility
for TO is provided (i.e., they must not be used in standard Forth).

But yes, there are probably not many people with that mindset in the
Forth community.  Forth-94 seems to have had some of that, though,
with words like GET-CURRENT and SET-CURRENT instead of a (user)
variable CURRENT that had existing practice at the time.  I wish they
had defined GET-BASE and SET-BASE instead of BASE.

For example, it could be a defining word "val" that is used as "val x"
and creates the getter "x" and the setter "set-x".
>
Such a word "val" can be defined like this:
>
  [undefined] name> [if]
    : name> ( nt -- xt )
      name>interpret dup if exit then
      drop [: -14 throw ;]
    ;
  [then]
>
  : val ( "name" -- )
    create 0 , [: does> @ ;] execute
    0. <# latest-name name>string holds s" set-" holds #>
    ['] : execute-parsing
    latest-name name> >body lit,
    postpone ! postpone ;
  ;
>
 \ Re "latest-name" see [2]
>
  \ test
  t{ val x -> }t
  t{ x -> 0 }t
  t{ 3 set-x -> }t
  t{ x -> 3 }t
>
>
  \ Let's redefine the setter "set-x"
  : set-x ( u -- )
    dup 10 u> abort" too big value for x"
    set-x
  ;
>
  t{ 4 set-x x -> 4 }t
  t{ 11 ' set-x catch 2drop  x -> 4 }t
>
>
Could you show how to implement that in Gforth when the to-based setter
"to x" is used?

: to-x ( u xt -- )
  >r dup 10 u> abort" too big value for x" r> >body ! ;

to-table: x-table to-x
' >body x-table to-class: x-to
0 value x
' x-to set-to

4 to x x . \ prints "4"
11 to x

The last line produces the following error:

*the terminal*:13:7: error: too big value for x
11 to >>>x<<<

NB: the solution must not change the original "x", it must redefine "x".
The difference is that the new definition *can* be in a different word
list, in which case both definitions (old and new) can be used depending
on the context.

Let's see.  To make it easier to see what is going on I use a
different name for the redefined word.

0 value y
synonym z y
' x-to set-to

4 to y
z . \ prints 4
11 to y
z . \ prints 11
11 to z \ aborts with "error: too big value for x"

For a bounds-checking TO I find this requirement strange, however.

This shows that some people don't like the to-based approach.

 
Does it?  Are they using getters and setters instead?  No.

>
How do you know this?

I see many more postings with TO than with setters and getters.

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