form difference between red and rebol

[x8x]

red:

  form [a/:b]
;   "a/b"

rebol:

  form [a/:b]
;   "a/:b"

Is this on purpose?

[PeterWAWood]

There is a typo in x8x's example, it should be:

red>> form [a/:b]
== "a/b"

[dockimbel]

This change was done on purpose to give more value to form compared to mold, allowing form to clean-up decorations around words, to make them more human-readable (which is the purpose of form).

[iArnold]

For the completeness here, mold gives "[a/:b]" where form gives one of the above.
You want to make it more readable but b could be an index or a var containing the description of the referenced thing. So keeping the : makes more sense to me, because it is not the string "b" that is of interest here, but b's contents. Just my 2 cents.

[Oldes]

I would keep the : char and this is my reason:

>> x: [a 1 b 2]
== [a 1 b 2]
>> x/b
== 2
>> x/:b
** Script Error: Invalid path value: (missing value)
** Near: x/:b
>> b: 1
== 1
>> x/:b
== a

Simply a/b does not have to be same as a/:b

[dockimbel]

@Oldes How are your code example and FORM related? I don't get it. FORM is for serializing values as strings for human-friendly display.

[Oldes]

@dockimbel I don't like when something is changing meaning behind my back. Also don't understand how removing one char can make something more human-friendly in such a case.

[dockimbel]

A string has no meaning, and FORM is not to be used to create LOADable code, that's the job of MOLD. FORM is currently too similar to MOLD, which makes it not very useful. Having FORM undecorate word types adds a feature and doesn't remove any. That said, I don't have a real use-case for it right now, so I'm just wondering if such change would be really beneficial or not.

[Oldes]

I don't agree.. content of the string has meaning... usually.. honestly I'm not sure if I use form in my code.. but I would rather prefer mold to provide really serialized values (mold/all as default) and form not changing meaning of the content. You wanted opinion, you have mine.

[Oldes]

form for me has some meaning when one can automatically insert spaces between values in resulted string.. like this difference:

>> to-string [x/:b x/b]
== "x/:bx/b"
>> form [x/:b x/b]
== "x/:b x/b"

Having result of the second expression just x/b x/b simply is strange in my eyes.

[dockimbel]

You think too much about FORM as a MOLD alternative, which is not. If you think it would be strange, then what about this in Rebol:

>> form [[a] (b) [c] "d"]
== "a b c d"

FORM is already undecorating other datatypes for more "readable" output where the content matters more than the origin datatype, that's its purpose. I'm just proposing to make that more consistent with how any-word! values are FORMed.

[meijeru]

I am in two minds about this, but it is true that e.g. form #"a" == "a" and this is in the same vein. However, used this way, form approaches to string!. Will form find its place between moldand to string!????

[Oldes]

@dockimbel ok.. your argument is strong. Anyway, I don't care much.. I was searching in my code base and found almost none form usage except some really old scripts, where I could use to-string instead. I use mainly reform in case, where I want to insert spaces between strings, which was the main purpose of the form, I believe. But reform is different, as it reduces values first so one does not have to think, if result should be a/:b or just a/b.

I still don't have any idea, why I would need to use form as in your use case above, but that does not mean that someone else could not find it useful somehow.

[dockimbel]

I am not sure either if such change would be beneficial or not in practice, that's why I asked others opinion. FORM has always been an odd function anyway, so its sematics needs some clearing, we could even repurpose it for a text formatting dialect.

[Oldes]

I would use it for text formatting dialect, if you want to modify it from the original functionality anyway.

[Oldes]

Imho... when in Rebol is:

>> form [:a]
== "a"

than probably even your proposed change in path is correct. form is simply confusing.

[rebolek]

I don’ think form is confusing. If you read Rebol’s help string, it says Converts a value to a human-readable string. So IMO it makes sense to convert a/:b to a/b. Red also converts 'a to a, which Rebol does not. This is +1 to Red.

[dockimbel]

@Oldes In Rebol3, it's different than Rebol2, not sure why:

>> form [:a]
== ":a"

[pekr]

I am with Oldes here, while not trying to solve the form vs the mold relation. What does the human readable argument mean anyway? For a programmer, it is going to be confusing imo. Hmm, but then all I want form to do is basically a to-string ...

[Oldes]

to-string is not placing spaces between values, which is the main difference. And the spaces are what makes the result human readable.

[dockimbel]

For the record, in Rebol2:

>> form ['a]
== "a"
>> form [:a]
== "a"
>> form [a:]
== "a"
>> form [/a]
== "a"

[Oldes]

@rebolek Ask yourself if you ever used form and in which cases. I'm pretty sure that you will not find many, because forming block with not reduced values somehow does not make sense. I found form just in very old scripts where it was used with reduce function, probably because there was not reform yet. Confusing it is, because there is so many string creating functions and form is probably the one which is the less useful.

[dockimbel]

What does the human readable argument mean anyway?

Did Carl ever define that precisely somewhere?

[dockimbel]

@Oldes Indeed, the various ways to serialize values are messy in Rebol. That is one of the reasons I wanted to take the time to analyze to conversion matrix before deciding on the rules, and as a side-effect, how FORM should behave.

[Oldes]

form in Rebol just takes not reduced values, converts them to string and join them with space char, if there is more than one. So in my view, it's all about the core conversion, like if to string! first [a/b] should be a/b or ab as it is in Rebol now. Note that this is also in Rebol inconsistent as in this case form is producing different result than just to string!, which is strange.

[Oldes]

I still think that removing some chars from values is not making it human readable... if so, you could also remove @ char from formed email datatype.

[Dobeash]

Removing leading % from file is useful though.

[ghost]

@Dobeash What is your use case for filenames without the leading % ? I don't think that would be of much use to me on Windows, since redbol, for consistency across platforms (which is a good thing) uses unix-like paths and not like that on windows. So even if % gets removed i will have to manipulate the string to get desired path on Windows.

[iArnold]

You could even argue that "a/b" is more human readable than "a/:b" but then "ab" or "a b" will be even more human readable.
"/" is "Forward slash" or "over" "and within this"
":" is "colon" or "get the value of"
That makes "a/:b" human readable enough?

[moliad]

Afaik, FORM is only really used by PRINT

I use print only on data I previously construct (using various methods). so my two cents is to completely remove the current FORM mechanism. its virtually useless

[henrikmk]

For what it's worth, if FORM is supposed to take data and makes it human readable, then the actual output format is up for grabs and may change between versions. That means, it's always risky to parse FORMed data. It just hasn't been risky, since the output of FORM has been largely identical across different REBOL clones, AFAIK.

The way that FORM is used in R2, where I have the most experience, serves as an alternative to MOLD in that it conveniently leaves out square brackets. I use it, because it happens to give the necessary output. This should not be how to use FORM. There ought to be very specific DEBRACKET and BRACKET functions for that.

I always saw FORM as just the very basics of providing human readable REBOL values and if it were to become much more advanced, say, FORMing objects or even images, then the output is really up for grabs and should never be parsed back into Red, unless you really have no choice.

This is because I see FORM eventually becoming configurable for your favorite date and time format, or for specific ways you want to output objects and blocks as ASCII tables or images as ASCII art.

This is a big frustration for me in REBOL, because there's no formal way to configure things like date and time and number decimal formatting, and you always have to build your formatters as slow mezzanines.

[9214]

#3409

Also, GUI tag does not apply here.

[greggirwin]

...if FORM is supposed to take data and makes it human readable, then the actual output format is up for grabs and may change between versions.

@henrikmk makes a good point here. I'll close this, and we can reopen if needed.

[Oldes]

@greggirwin Ok.. so the decision was, that form quote a/:b should be "a/b" and so it is a Rebol bug, right?

[Oldes]

Btw... there is this old blog: http://www.rebol.net/cgi-bin/r3blog.r?view=0304 where Carl said:

What I would really like to see is a table that lists all datatypes on left side, and a column for each of the the FORM, MOLD, and TO STRING! outputs.

I wonder if there is any such a list now.

[meijeru]

@Oldes I made one some time ago. See my gist
If need be you can adapt and rerun the program which generates the html this gist

[Oldes]

@meijeru yes... I've seen it, but I would prefer to see such a table with the suppose to be correct results. For example now I have in Red this:

>> form quote a/b/c:
== "a/b/c:"

but shouldn't it be just "a/b/c"?

[meijeru]

The generating program will just show what is implemented currently. Thus it allows anyone to review and state what they would rather want the implementation to be. Nothing prevents you from making a WISH issue (or a REP) on particular items.

[greggirwin]

@Oldes, they're only bugs if not doing what we want. :^) The table is enormously helpful, because we can see each case and point out what we think should change.

[Oldes]

@greggirwin I agree, but where to see what we want? :-)

[greggirwin]

In your mind. Then write it down for the rest of us. :^)

[greggirwin]

People can certainly copy the table and tweak it manually. That lets us see everything in context.