BLOCK! and OBJECT! Parity in Pathing/Picking

Development Internals
19

We've clearly come at this from a different perspective...

  • ME: Rebol is a dynamic medium with irregular parts that you're encouraged to mix up and compose and dialect in all kinds of wacky ways.

    • I look at [foo bar bar baz] and I see: [ سم الله الرحم 😈 ⠼⠚⠃]

  • YOU: Live in a world where Rebol is the database as well as the language.

    • You look at [foo bar bar baz] and are able to see:

          KEY      VALUE 
+---------+---------+
|   foo   |   bar   |
+---------+---------+
|   bar   |   baz   |
+---------+---------+

I don't see that. I don't see this magic number 2, and even if I were to see the magic number 2, I don't see the KEY=>VALUE mapping because what if it said:

[foo bar bar baz bar mumble]

In object KEY=>VALUE access, the last SET-WORD! assignment in the creation wins. But when treating this as a keyed thing, presumably you want the first thing to win?

But that applies to any argument, whether you were seeking out SET-WORD! or not.

And I've struggled with the idea that PICK doesn't do equality matching for INTEGER! but treats that as an index:

>> block: [4 2 3 1]

>> block.3
== 3  ; not 1, as it would be if skipping by 2 and geting what's after a 3

So I think if these little blocks are just lexically light ways of specifying objects, you should treat them as an object specialization dialect and move on. I've suggested maybe imbuing {{...}} with that ability...

>> data: {{foo bar bar baz}}
== &[object! [  ; or map, or whatever, different discussion
    foo: 'bar
    bar: 'baz
]]

Then there's the idea that it's just some large dataset, loaded or has been constructed as a BLOCK!, and you don't really want to have to create a key/value structure for it. I really feel like if you're doing this, SELECT and FIND are probably the place to do it.

The uniformity pleases me, e.g. with SELECT 1

>> block: [4 2 3 1]

>> select block 3
== 1

Here you are beholden not to "pickquality" but to plain old equality. Your keys are expected to match what you're asking. You have a :SKIP count to say when your operations aren't implicitly going by 2 (with dialected function calls you could even put the skip count in the call)

And maybe SELECT should return a pack if you're selecting in this fashion:

>> block: [a b b b x y]

>> select:3 block 'b
== \~['x 'y]~\  ; antiform (pack!)

So it would by default decay to the first element:

>> block: [a b b b x y]

>> var: select:3 block 'b

>> var
== x

But you could capture up to (SKIP - 1) elements:

>> [var1 var2]: select:3 block 'b

>> var1
== x

>> var2
== y

That's... pretty cool, I think you'd agree.

It's a little weird that FIND skips 1 by default and SELECT skips 2 by default... but if this implicit idea has been found useful there's probably no reason to make SELECT skip 1 and force you to write select:2 to get a skip of 2.

1 Like