Re: value-flavoured structures

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

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

1. From the lexical point of view, "to foo" and "set-foo" are almost the
same.  "to foo" can even be considered a separate fancy word with a
space in its name.

 Even closer: With the to-recognizer you can write ->FOO.
 

3. "set-foo" can be easily redefined (for example, if you want to check
the assigned value to prevent some bugs in advance).
"to foo" *cannot* be redefined. Although, one can redefine "to" to check
its argument and have a special action when its argument is "foo" — this
is very cumbersome.

 Wrong.
It can be defined: Gforth has SET-TO
<https://gforth.org/manual/Words-with-user_002ddefined-TO-etc_002e.html>
which allows you to define what TO FOO does.

Yes, I know ))
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.

If you mean that a standard program cannot define it, true,

Of course, I mean a standard program (and that is by default).
Otherwise my statement would be a denial of the obvious truth ;)

but that's just a matter of what is currently standardized.

Yes, this is by default.

4. "set-foo" can be accessed using qualified names, such as
mymodule::set-foo  or  mymodule( set-foo )
A variant like "to mymodule::foo" could work,

By "could work" I mean that this can potentially work in *any* system that have the corresponding capabilities (e.g., the Recognizers API).

a variant like "to mymodule( set-foo )" cannot work.

Typo: this should be read "to mymodule( foo )"

 Let's see:
 [~/gforth:152808] gforth
Gforth 0.7.9_20241003
Authors: Anton Ertl, Bernd Paysan, Jens Wilke et al., for more type `authors'
Copyright © 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
vocabulary voc  ok
also voc definitions  ok
5 value val  ok
previous  ok
voc:val  ok 1
. 5  ok
7 to voc:val  \ <----------  ok
also voc  ok
val . 7  ok
previous  ok
8 ->voc:val  \ <-----------  ok
voc:val . 8  ok
3 +>voc:val  \ <-----------  ok
voc:val . 11  ok

Behaves as expected!

 I pointed out exactly where TO VOC:VAL, ->VOC:VAL and +>VOC:VAL occur.
No not only can it work, it already works in Gforth.  And here the
"standard program excuse" does not apply, because neither your
qualification syntax nor Gforth's scope-recognizer are standardized.

Yes, that's right!

Bottom line: I don't see any advantages in *using* a to-based setter
over a separate setter.

 However, lots of Forth programmers have defined VALUEs, and barely any
have defined getters and setters.

Do you mean that this is due to some advantages in *using*?
I think, this is because `VALUE` (and co.) is a very old technique that is provided out of the box by many systems.  In contrast, to use separate getters and setters you need to create your own tool to define them.

The discussions have been aboyt
values vs. variables, not about values vs. getters and setters.

This shows that some people don't like the to-based approach.
I seen that some implementers provide "value" and "to" only for third party programs and don't use them themselves.
--
Ruvim