greggirwin on master
Created initial natives.adoc Merge pull request #259 from gl… (compare)
greggirwin on master
Created initial actions.adoc Merge pull request #258 from gl… (compare)
greggirwin on master
Pull content from blog Source … (compare)
The whole application scenery would be to have the relative structure of a data object stored like this:
mystruct: [
size: /heading/size
body: /body
extra: /footer/extra/
]
So you can access the parts of your data building the path as follow:DATA/(mystruct/size)
Which would be reduced to:data/heading/size
Or for full relativeness of paths:
(DATA)/(mystruct/size)
/a
to be a path with length of 2 and actually using blocks in function specification in place of refinements as it is in Ren-C (now - it can be changed in any hour) is a good way.
@Oldes No particular reason, just to have a way to identify it has a "path with a missing part", but you are right, it would make no difference!
The most important part to me is the ability to use ()
on any segment of the path because actually we can't.
>> x: [y z [d r]]
== [y z [d r]]
>> x/('z/d)
== none
The notation (WORD|PATH)/(WORD|PATH)
is a very powerful one to have an absolute flexibly on the selection of elements.
WORD/(code)
syntax every single day and believe me, it makes things a lot easier if properly used. Allowing (code)/(code)
in paths would give extreme power to this selector in all its simplicity.
parse
).
word/(index + 1)
. I was requesting it in Rebol to be implemented years ago... I just see also the dark sides. Occasionally.
@Oldes
(code)/(code)
(as a path) is a nonsense... you would not be able to write(1 + 1)/(2 * 2)
/(code)/(code)
could be a road to this but how to make it without disturbing refineents ;-)
Also, I think it is now time to move elsewhere, I propose red/red
@GiuseppeChillemi Why not make your local adjustments, something like:
>> path: function [a b][to path! append to block! a to block! b]
== func [a b][to path! append to block! a to block! b]
>> length? probe path 'a 'c
a/c
== 2
>> length? probe path 'a/b 'c
a/b/c
== 3
>> length? probe path 'a/b 'c/d
a/b/c/d
== 4
>> length? probe path 'a 'c/d
a/c/d
== 3
>> length? probe path 'a [c d]
a/c/d
== 3
>> length? probe path [a b] [c d]
a/b/c/d
== 4
Or go even further:
>> //: make op! :path
== make op! [[a b]]
>> [a b] // [c d]
== a/b/c/d
>> 'a // 'c/d
== a/c/d
>> 'a // (to path! [c d e f])
== a/c/d/e/f
@GiuseppeChillemi you should be aware that Red in not in version 2.0.0 and that even that if you want to use just word/(code)
, someone must solve a lot of complicated situations, because soon or later there will come someone who starts with:
p: [] p/(loop 100 [append p random 100] random 100)
and will continue until it starts to make problems, which someone else must again solve for you.
(code)/(code)
pattern. Which would be so important that we would have to reconsider complete code evaluation.
(code)/(code)
can be written in a Redbol way like: pick (code) (code)
I did this a long time back, for the refinement issues @GiuseppeChillemi noted:
to-path: func [spec][
; LOAD FORM is used to clean up specs that have refinements
; in them. Refinement values get their sigil doubled, which
; FORM removes, so they are sanitized. More overhead, but we
; could make that optional if this func lives on.
load form append clear '_/_ spec
]
It's really heavy though, with both form
and load
being used, and was just a quick workaround at the time.
path
func is nice too.
I don't remember where the paren-in-path/computed-selector chat was, and can't find it just now, but it is important to note that we intentionally left it out of the path!
docs, because it may be removed. @Oldes correctly points out a number of issues with it, and allowing parens as the first element in a path's lexical form is very, very unlikely to happen. Coming from @meijeru's notes, I am looking at things from the other direction; how can we simplify rules for lexical forms.
I think what @GiuseppeChillemi wants could be called indirect relative paths or even just indirect paths. Now, since words are already a level of indirection, they're really doubly indirect, but that's just more confusing to talk about.
An important aspect here is that paths themselves are not the problem, which we can see based on @Oldes and @toomasv finding other ways to express solutions. The only issue is the lexical form for path!
values. @GiuseppeChillemi's suggestion of /a/b
has a big problem in my mind in that *nix paths starting with a slash mean they start at the root (i.e. aboslute), so having it mean relative is backwards to that meaning.
It's true that common cases like p/(n + 1)
are handy but, unless we make paren path segments a special dialect, their unrestricted power can be abused and hurt readability. Forcing the use of get-word selectors can seem like more work, but the benefit is that the user then has to give the selector a name, which is helpful.
So, @GiuseppeChillemi, no need to open a wish for this.
word [types!] "description"
; in this case, you have name/(logic)
! No off-screen data, no scrolling headache, no large amount of new words, no risk of polluting the global context, and no minding about words context. This is what really hurts coding: too many elements to have in mind to understand what is happening and information scattered everywhere. Parens in paths (if done properly) solves this as Carl solved the problem of documenting the purpose of function arguments and types.
@GiuseppeChillemi Another func you may like:
get-path: func [block [block! hash! paren! object! map!] path [path! block!]][
forall path [block: block/(path/1)]
;foreach i path [block: block/:i] ;This is slightly faster
]
a: [b [c [d e f g]]]
get-path a 'b/c/e
;== f
get-path a 'b/c/2
;== e
get-path [b [c [10 20]]] 'b/c/2
;== 20
get-path [b [c [10 20]]] [b c 2]
;== 20
And of-course you can make it into op again.