GET+SET vs PICK+POKE - What's The Difference?

Development Semantics
7

I'll mention that if there were a way to do this, it's definitely not an ACCESSOR/GETTER... but would something like what I proposed as LAZY!:

https://rebol.metaeducation.com/t/applications-of-isotopic-objects/1959

That's an unstable antiform concept where an OBJECT! could be held in suspended animation, waiting to be picked apart by things that understood it... and running its DECAY method otherwise.

Going to our example, the hypothetical situation is that someone "wants" this (or thinks they want it, anyway):

>> struct.million_ints_field.10: 20
== 20

>> struct.million_ints_field.10
== 20

>> struct.million_ints_field
== [1 2 3 4 5 6 ... ]  ; million integer block! synthesized

So STRUCT! is a datatype with a locus of control, responding to TUPLE! picking. But it doesn't want to introduce new fundamental types like C-ARRAY!, it wants you to see:

>> type of struct.million_ints_field
== \~{block!}~\  ; antiform (datatype!)

It doesn't actually have a BLOCK! with a million Cells. It just has the tight-packed native array that's 1000000 * sizeof(int) (which we'd imagine being at most 1/4 the size, FWIW)

The expectation is that it would synthesize this if you didn't pick a single element out of it, which it would do every time you accessed it.

if block? struct.million_ints_field {
    len: length of struct.million_ints_field
    if (first struct.million_ints_field) <> (second struct.million_ints_field) [
       ...
    ]
}

You get the idea. So the concept is dubious to begin with.

Maybe we're to believe that it is viable in smaller examples? And what people want in order to participate in TUPLE!-picking, is to give back something that responds to PICK and POKE (unified operation currently called TWEAK, but it could be PICKPOKE or whatever else).

So we could imagine it responding to the PICK with an antiform OBJECT! that had a TWEAK member and a DECAY member.

Then, the TWEAK machinery would decide--based on whether it was at the terminal or not, if it was going to give back the decayed version or if it would execute another step.

This Is 100% Isomorphic To Inventing Another DATATYPE!

The only difference is that your value of the datatype would be stable, and not decay itself every time.

I've been pushing on making this easier to do, and it should be the case that userspace code should be able to participate in the tuple picking machinery.

1 Like