red/docs

Red-related user documentation repository

GiuseppeChillemi

@GiuseppeChillemi

I have expected x/y

GiuseppeChillemi

@GiuseppeChillemi

Also this does not work:

x: [y [z ww]]
a: 'y/z
x/(a)
== none

>> x/y/z
== ww

GiuseppeChillemi

@GiuseppeChillemi

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)

Oldes Huhuman

@Oldes

/a/b would have to be a new datatype which now even don't have a name... or you would have to kill refinement! datatype like HF did in Ren-C and have /a as a path! (but that is a block! type, not a word! like refinement!)

But to be honest... I don't think that having /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.

Boleslav Březovský

@rebolek

Please, no. HF doesn't understand Rebol so he decided to rewrite it and with each change he finds out he did something wrong so he needs to change it later to even more arcane construct... Ren-C has no documentation because it can't. It's always a moving target, it's impossible to document it.

@Oldes why do you think it makes sense?

Oldes Huhuman

@Oldes

Have I said that it makes sense?

Boleslav Březovský

@rebolek

@Oldes Oh sorry, I read it as "I think"

I need to use a bigger font I guess :)

Oldes Huhuman

@Oldes

@GiuseppeChillemi why you think that:

mystruct: [
   size: /heading/size
   body: /body
   extra: /footer/extra/
]

is better than:

mystruct: [
   size:  heading/size
   body:  body
   extra: footer/extra
]

GiuseppeChillemi

@GiuseppeChillemi

@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.

@greggirwin Do you think I could make a request for it?

Oldes Huhuman

@Oldes

What you don't see is how expensive such a code is internally.. and also dangerous, if you do some complicated code inside the parenthesis. I remember how Carl was long time refusing to implement it in Rebol.

Oldes Huhuman

@Oldes

You could also play with code like:

>> p: as path! [a b/c d]
== a/b/c/d
>> length? p
== 3
>> p/('b/c)
== d
>> to block! p
== [a b/c d]

GiuseppeChillemi

@GiuseppeChillemi

Oldes, I can see it and I can understand the fears you have but I use the 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.

(A personal note, I consider this feature the second most powerful thing after parse).

Oldes Huhuman

@Oldes

(code)/(code) (as a path) is a nonsense... you would not be able to write (1 + 1)/(2 * 2)

And I don't have any fears ;-) I have nothing against word/(index + 1). I was requesting it in Rebol to be implemented years ago... I just see also the dark sides. Occasionally.

GiuseppeChillemi

@GiuseppeChillemi

I see, but if there could be a solution, I think it's whort trying to find it.

Oldes Huhuman

@Oldes

Every solution has its price and sometimes the price is too high. But go ahead and make a wish ;-)

GiuseppeChillemi

@GiuseppeChillemi

@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

Oldes Huhuman

@Oldes

I don't think it should be more discussed in chat.. write a wish and you get it refused most probably... /(code)/(code) is imho ugly even without long expressions and I don't see any real usage why it should complicate everything.

Btw... If you want to feed your brain, you can start here: https://www.curecode.org/rebol3/ticket.rsp?id=2094

GiuseppeChillemi

@GiuseppeChillemi

@Oldes In fact it is not LONG and COMPLICATED CODE the target use but a simple thing like: (word)/(idx)/(word-reduced-to-path). Nothing more simple and powerful than this!

To the Red team, if they will like it, to find a way to do this.

Toomas Vooglaid

@toomasv

@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

@GiuseppeChillemi

Isn't // already used?

Toomas Vooglaid

@toomasv

If you use mod, then yes, just add one more / :)

Oldes Huhuman

@Oldes

@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.

Still don't see any real use for (code)/(code) pattern. Which would be so important that we would have to reconsider complete code evaluation.

Especially when (code)/(code) can be written in a Redbol way like: pick (code) (code)

GiuseppeChillemi

@GiuseppeChillemi

Think about some series sharing the same structure and stored in different words:

mystruct: [
   size:  heading/size
   body:  body
   extra: footer/extra
]

foreach series [s-one s-two s-three s-four] [
  Print ["Size is:" probe (series)/('mystruct/size)]
]

Oldes Huhuman

@Oldes

Not mentioning that someone must also write a compiler to support this theoretical code pattern. :/

GiuseppeChillemi

@GiuseppeChillemi

And if you have multiple elements which have the same row structure:

foreach series [s-one s-two s-three s-four] [
  repeat idx length? series [
     Print ["Size is:" probe (series)/(idx)/('mystruct/size)]
  ]
]

Oldes Huhuman

@Oldes

Just write a wish and forget it... because I don't believe it will happen! Or you can talk to HF.. which will figure out something.. he has open mind for such a requests

GiuseppeChillemi

@GiuseppeChillemi

HF has just a couple of good ideas but he is totally changing the way Redbol languages works, without realizing the solid grounds, even neurological ones, Carl idea are based onto. Also, he is forgetting the importance of code/skill reuse (20 years of Rebol experience); and that everyone needs something stable to work with. I have seen different members suffering from this experimental stage. Red is now ready and it has its first commercial application. As things are now, we will see REN-C apps in another 5 to 10 years time frame. I will deliver my fist application made with red (tm) just after the new Android+Ports release.

GiuseppeChillemi

@GiuseppeChillemi

@toomasv This one //: make op! :path is the way to start with.

GiuseppeChillemi

@GiuseppeChillemi

I have created a gist to show the application field of relative paths: https://gist.github.com/GiuseppeChillemi/93febe44dffd5dfae764b3cd6ad86988

(Thank you @toomasv !)

Toomas Vooglaid

@toomasv

:smile_cat:

Gregg Irwin

@greggirwin

@Oldes' resolve on @GiuseppeChillemi's gist is very nice. It gives it a name, is very idiomatically Red, and is simple and elegant.

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.

@toomasv's path func is nice too.

Gregg Irwin

@greggirwin

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.

Nenad included paren support in paths for Rebol compatibility but, if we look at Red as a data format, with very tight and sometimes confusing lexical interactions, it does come with a cost.

GiuseppeChillemi

@GiuseppeChillemi

@greggirwin Gregg, you have already asked time ago for examples that shows reasons to use parens and I did it. They are an essential part to have one line data structure selectors that summarize what needs more lines to be expressed. Everything can be abused and become hugly but it is the price of power. I remember me having written hugly parse expressions that made Ladislav gone grazy but the solution was not to restrict parse because it can be used to write such code, I have simply learned write neat and readable one. So, removing power from a language for this reason, is not the right way to go: we should teach how to use that power, instead of removing it because it can wrongly used!

GiuseppeChillemi

@GiuseppeChillemi

@greggirwin Also, about parens "hurting readability", I totally disagree, it's the opposite. Every day I face the problem of having too much information off-screen. It confuses me because I have to move back and forth to find what-is-what in structures, words, and logic. It is nice to have "my-field" but coding is not just having a neat name, it is also defining and debugging its content, especially when your path accessor is not doing what it has been meant to do. When you have multiple data structures, it is really handy to have their access logic in one line because the information is all there. It is like function's specs, in the same line you have: 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.

Toomas Vooglaid

@toomasv

@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.

Gregg Irwin

@greggirwin

Moving to red/red.

Where communities thrive

People

Repo info

Activity