Using paths in parse set

[GiuseppeChillemi]

Set inside parse actually accepts only words. When you must set them inside a context, a map or any other element accepting paths, you must use a temporary word and then Red code in paren! as:

parse data [set str string! (myobject/mystring: str)]

It would save a lot of code if set in parse could accept paths. (We actually have this syntax for the native set)

Thank you!

[hiiamboris]

In the meantime you can compose parse rules though, e.g. parse data compose [set (in myobject 'mystring) string!]

[GiuseppeChillemi]

Thanks, but this in very simple situations. I have parse with set code + a ton of other red code in paren! All the other would get composed too.

[dockimbel]

bind is your friend:

ctx: object [a: b: c: none]
parse [1 2.0 3] bind [set a integer! set b float! set c integer!] ctx

gives:

>> ctx
== make object! [
    a: 1
    b: 2.0
    c: 3
]

You can even write a wrapper on bind to swap the arguments order, to make it more readable in such cases.

[hiiamboris]

Or parse the rule and replace paths with bound words :)

[greggirwin]

Let me ask: why wouldn't we want to just allow paths, as set does normally? It nothing else, it's more consistent.

• Imagine you have more than one context you want to deal with. Simple bind no longer works well.
• Adding more abstraction can make things harder to understand.

Historically, we didn't have set path! capability in Rebol. Red added it, and it's fantastic. What I did in the past was collect data, then assign it in actions. We can do that as well, which is easy to understand, but not nearly as concise, and is more error prone.

[GiuseppeChillemi]

Thanks Gregg,

Rebol2 hadn't MAP!, which is another valid datatype target where paths apply, it is the reason why SET syntax hadn't it. But Red is MUCH MORE POWERFUL! Now we have lit-path! and supporting paths, in parse, syntax would bring it on par with the new datatypes improvements in Red.

Looking at my code, this solution would:

• nearly halves the size of the parsing block
• become immediately recognizable the target of the SET operation
• be zeroed the number of errors in case of multiple contexts with the same words.
• be really coincise and expressive

Gregg knows I am asking this because I am working on parsing Red function specs to map! for the creation of alternativce interfaces and documentation purpose. I have now a full parser but the code would much more readable and maintainable having paths in SET.

Thank you

[greggirwin]

@dockimbel is this more involved than allowing paths after set and using native set rather than _context/set?