UNMAKE and the Death Of Construction Syntax

Development Debugger
1

I don't really believe in textual construction syntax in its historical sense. You can't generically "mold" things out as a string in a way that LOAD can resurrect what you had...too much is lost when the binding goes away and whatever parts of the structure that weren't List-like go away. Today's mold and construction syntax is a dead end.

What I do believe in is the idea that while the interpreter is still running, you can ask a complex data structure to give back a reified array description of itself. This description should be concrete where it can be...but if it can't, it needs to give you some kind of POINTER! type that can be further probed.

Think about something that could be used to implement an object browser like in the JavaScript console:

RsxAB
Imagine that first level of result, which gives you things and then you have an arrow to go deeper.

The idea that you actually would get enough information to reconstitute the data structure is interesting, so let's imagine we call this UNMAKE, and we seek it to have that property:

>> obj: {x: 1 + 2, y: first [(a b) (c d)], z: <thing>, f: does [print "hi"]}

>> unset $obj.z

>> unmake obj
== @{x: 3 y: '(a b) z: ~ f: {\0x52d0000a0f48\}}

>> obj2: make unmake obj

>> obj = obj2
== ~true~  ; anti

So here I'm imagining that MAKE would react differently to @{...}, and see that as an instruction to REMAKE what it originally had... or, if you made adjustments, it would be able to affect it.

>> reified: unmake obj
== @{x: 3 y: '(a b) z: ~ f: {\0x52d0000a0f48\}}

>> reified.3: [c d e]
== @{x: 3 y: [c d e] z: ~ f: {\0x52d0000a0f48\}}

>> remake obj reified

>> obj.y
== [c d e]

For this to work, those pointer references have to keep the thing they point to alive somehow. So that would be part of POINTER!'s mechanics.

MOLD would be a client of UNMAKE, where you'd have some depth at which you ask it to go into the pointers, but if it hit a pointer it would just dead end you there with some placeholder:

>> mold obj
== "@{x: 3 y: '(a b) z: ~ f: ~<action!>~}"

>> mold/depth obj 2
== "@{x: 3 y: '(a b) z: ~ f: @{action! [] [print "hi"]}"

And you'd just use that for debug output.

This is only a sketch...but it points in a direction that I think could actually be useful.

1 Like
2

So I'm going to go ahead and kill off MOLD:ALL

MOLD:ALL's ostensible goal was to take information that's hidden in a value, and make it visible:

rebol2>> mold next [a b]
== [b]

rebol2>> mold/all next [a b]
== "#[block![a b]2]"

rebol2>> data: load "#[block![a b]2]"
== [b]

>> back data
== [a b]

I don't believe anyone has made effective use of this.

Moreover, Red has been going along how long... and doesn't have it:

red>> help mold
USAGE:
     MOLD value

DESCRIPTION: 
     Returns a source format string representation of a value. 
     MOLD is an action! value.

ARGUMENTS:
     value        [any-type!] 

REFINEMENTS:
     /only        => Exclude outer brackets if value is a block.
     /all         => TBD: Return value in loadable format.
     /flat        => Exclude all indentation.
     /part        => Limit the length of the result.
        limit        [integer!] 

RETURNS:
     [string!]

In 2015 it was asked if MOLD/ALL would include the series index. The answer was probably, but the issue was closed as completed. It is now 2024, and:

red>> mold/all next [a b]
== "[b]"

So all it seems to be doing is contributing to weird bugs

My own feelings on this not being a productive design path at this time...along with the empirical evidence that no one has shown it executing or being useful...means I am getting rid of it.

Any future of this kind of idea is--I think--part of a different idea, which UNMAKE has the inklings of. Right now it's just another thing in the way of addressing pragmatic designs for the needs of today's MOLD.

1 Like