{ Rethinking Braces }... as an array type?

Development Datatypes
1

I've historically been pretty attached to braces for strings. They sure can be nice.

But I am increasingly thinking braces might be better applied as a new array type, called FENCE!:

[block] • (group) • {fence}

>> fence: first [{This [would] be @legal}]
== {This [would] be @legal}

>> length of fence
== 4

>> second fence
== [would]

(I like that FENCE is five letters...matching GROUP and BLOCK, and I like that it starts with a distinct character. The name is perfect, and I don't mind it conflicting with the three-backtick "code fence" notation name from other languages!)

So it would act like a BLOCK! or a GROUP! when it was inert. But the real benefit would be the idea that if this braced form got evaluated, it would effectively do a MAKE OBJECT! (or "something along those lines")

>> obj: {x: 10 y: 20, z: 30}
== make object! [  ; whatever this representation is, it's not {x: 10...}
    x: 10
    y: 20
    z: 30
]

This kills two birds with one stone: A neat new dialecting part that would also give a better source notation for objects!

Having its evaluator behavior be "make an object" pushes this from "frivolous third form of array" to being clearly useful on day 1. But I think the array form would soon turn out to not be frivolous.

Carl Himself Wants To Move Away From Braced Strings

In Carl's "ASON" pitch, he moves away from Rebol's choice to make braces an asymmetric string delimiter:

  • "Braces {} are used to denote objects. They are lexical and may be used directly without evaluation (the make constructor is not necessary)."

  • "Braces {} are not used for multi-line strings. A single+double quote format is used for multi-line strings."

I must admit braced strings can make a lot of situations in the text programming world look better than they typically would.

But it comes at a cost for taking the asymmetric delimiter, and is a real weakness against JavaScript and JSON. When rethought as this fun new dialecting part, it actually offers a new edge and plays to Rebol's strengths.

What might the new {...} type do in PARSE? As a branch type? In your own dialects?

My {...} Proposal Is Arrays, Not Object Literals

It might seem like having a source representation of objects that maps directly to the loaded/ in-memory representation would be better. But in practice, you can't really get the loaded form to ever look completely like the source...there's so many issues with nested cyclical structures or things that just don't mold out.

It doesn't work in JavaScript either. Note that you're not supposed to be loading JSON directly in any case into JavaScript...you're always supposed to go through parsers and serializers. So that should be weighed here when looking at the suggestion of a structural type that happens to evaluate to give you an in-memory representation.

Map Representation Via : ?

There was another remark in the Altscript on the role of colon:

For JSON compatiblity:

  • Keys (word definitions) can be written with quotes ("field":)
  • A lone colon (:) will automatically associate to the word/string immediately before it.
  • Commas as element separators are allowed as long as they are not directly followed by a non-digit character (to avoid confusion with comma-based decimal values.)

The note about the colon seems like it might be good for maps.

mapping: {
    1 : "One"
    "Two" : 2
}

This could help avoid the need for SET-INTEGER! or similar.

4 Likes