WISH: mold to apply /only to other datatypes

[hiiamboris]

It makes little sense for me that mold/only applies only to blocks and nothing else.

Why can't it work e.g. for paren! or hash!?

Or sometimes I have script configuration in a map! and want to load/save it without the surrounding #[] markers and the extra indentation. I have to convert it into a block before molding.

I propose mold/only should remove from:

• maps: #[] markers and 1st indentation level
• objects: make object! [] markers and 1st indentation level
• errors: make error! [] markers and 1st indentation level
• vector: make vector! [] markers (what remains: e.g. [1 2 3] or float! 32 [1.0 2.0 3.0])
• hash: make hash! [] markers
• paren: () markers
• image: make image! [] markers and 1st indentation level (what remains: WxH #{...})
• event markers and indentation when it gets molding support

[greggirwin]

I support this idea wholeheartedly. It's always been a (slight) pain to get the object body for serialization.

[dockimbel]

Seems like a good improvement, I see no drawback, so we can implement it.

[dockimbel]

and 1st indentation level

@hiiamboris This is already handled by /flat refinement. Additionally, you can do manual whitespace cleanup using trim. So I think /only should just remove the type-specific decorators.

[hiiamboris]

and 1st indentation level

@hiiamboris This is already handled by /flat refinement. Additionally, you can do manual whitespace cleanup using trim. So I think /only should just remove the type-specific decorators.

No, /flat is not what we want here. And I don't know how trim can be applied either.
E.g.:

>> print mold/only object [a: b: c: 1]
make object! [
    a: 1
    b: 1
    c: 1
]

Wanted this:

a: 1
b: 1
c: 1

Not this:

    a: 1
    b: 1
    c: 1

[dockimbel]

>> print trim mold object [a: b: c: 1]
make object! [
a: 1
b: 1
c: 1
]

[hiiamboris]

Looks like a kludge to me :)

> print trim mold/only object [a: b: 1 c: #[x 2 y 3]]
make object! [
a: 1
b: 1
c: #[
x: 2
y: 3
]
]

Anyway, don't you think it'll be simply weird if mold/only removes make object! [ but keeps the 4-space indentation?
Especially considering that for blocks it produces expected output:

>> print mold/only to [] object [a: b: 1 c: #[x 2 y 3]]
a: 1
b: 1
c: #[
    x: 2
    y: 3
]

[dockimbel]

After implementing it, I see it causes issues with save implementation that relies on the current behavior of mold/only. E.g. the unit test for red#2072 does not pass anymore... Rebol2 (probably R3 too) relies also on that specific behavior. Maybe we jumped in too quickly...

[hiiamboris]

Is there any justification for why save was implemented to remove brackets but only from the block?

[dockimbel]

save is the primary way to save Red scripts on disk. Using mold/only removes unwanted square brackets in the saved source file. It's possible mold/only was created specifically for that purpose only back in R2 days.

[hiiamboris]

Then why don't we patch save if this behavior is specific to it? Just need to add a only: block? :value line to it.

[dockimbel]

You mean using a dynamic refinement for mold/only? The issue is that the input can contain nested containers of datatype for which we don't want /only applied, but just for the root block. Maybe we could just remove manually those extra square brackets after using a simple mold serializer?

[hiiamboris]

But /only is not propagated down, it only applies to the top level. So what's the issue?

[dockimbel]

You're right, I was confused by my implementation (letting /only be passed through). Patching save is enough.

I'll also remove the extra indentation, I thought it could be useful to keep it, but trim option would remove even nested indentation, which would bad.

[dockimbel]

What about these other datatypes: binary!, bitset!, typeset!, tag!? Any reason to leave them behind?

[hiiamboris]

The reason is I forgot about them :)
Esp. for binary /only would be useful, instead of enbase/base bin 16.
Except for tag!, where mold/only of any-string equals to string! of it, I don't see a practical value. But if for tag! /only is supported, so should be for any-string!.

[dockimbel]

For bitset!, it is not that simple. How to deal with complement bitsets?

>> complement make bitset! #{456468}
== make bitset! [not #{456468}]

[dockimbel]

Pushed on master: red/red@a691592

[greggirwin]

It's not a 1:1 round trip design, as both save and mold are inverses of load. But save really only has that use, while mold can be used for many other reasons. So we need consistent, easy round-tripping for save, but may need to get involved with mold+load as once you remove syntactic markers, only you, the writer, know what it was before it was molded.

[greggirwin]

The main use case I've had, for 25 years now, is saving and loading spec blocks. Beyond that, if we start tinkering too much, to try and make serialized data "cleaner", we do so at the expense of being a clear interchange format. We still have /all, of course, but that's not as user friendly. I would have to mock up some examples of many types at different levels to see if it starts to look too inconsistent, or leads to a schema system as a necessity for consistent round-tripping.