A change to paths for blocks

I must bring this up again... because I find it one of the annoying things about using blocks as data structures. You might think I've gone crazy to mention it. (Perhaps it's true.)

Yes, at times I want to use a block like a "structure" (a non-contextual storage object.) It's usually for simple little scripts where I don't want to build an object, etc. For example, right now I'm working on a small script to help construct the C part of plugin interfaces.

For example, if I have a block:

user: [name: "Steve"  age: 38  country: France]

there are times when I want to use the words for selecting their related values, like:

print user/age

Of course, this does not currently work, because the selector must be of identical type (it is age: not age.) Therefore, I must write:

print select user to-set-word 'age
38

To modify the value, it's even less friendly looking:

change next find user to-set-word 'age 40

and, of course, it's not really that simple if we're not sure that the word age is within the block. We would need to check the result of FIND before doing the CHANGE.

But, what if we could write:

print user/age
38
user/age: 40
print user/age
40

It's not a new idea, but it seems useful -- simple, friendly.

However, it's not free. There are issues and consequences.

For instance, if I have a block:

blk: [a: b b: 10]
probe blk/b
b:

This happens because the path selection action will match any word. This is necessary for backward compatibility.

I'm sure that some of you will have strong opinions one way or the other. It took only a few lines of code to modify R3 A77 to try it out. Only the path behavior has changed; SELECT has not changed and can be used for the compatible behavior.

We will see where this takes us.

11 Comments