ANSWERED: Aesthetics of collection delimiters - braces vs brackets
UPDATE: Considering the feedback I've gotten so far, I consider my question answered, and I will leave my use of braces versus brackets unchanged, there doesn't seem to be any one arguing a preference for brackets while there is considerable preference for braces as they are currently used for sets and such. Thank you.
Design opinion question for a HUMAN READABLE/WRITABLE data/code serialization format alternative to JSON/YAML/XML/SQL/etc, what do you prefer to use aesthetically for collection literal delimiters, between round parenthesis and square brackets and curly braces, and for what kinds of collections each?
Currently I’m using parenthesis for heterogenous/structural literals namely pairs and tuples/headings, while I’m using curly braces for homogeneous literals which are almost everything else including arrays and sets and bags etc, and square brackets are just for interval literals.
Relation literals would be expressed visually as a set literal whose elements are tuple literals, when non-empty.
I am debating swapping the uses of brackets and braces since a different change means my primary reason for choosing braces no longer applies.
A main question I have for you is aesthetically would you rather see a data/code file with more curly braces or more square brackets or do you like each about the same?
Hi Darren, some examples would help enormously. Otherwise I don't have much idea what you're asking.
How do things look using your current approach? What would those look like under the change you're considering?
If these are to be embedded inside an existing language, curly braces { } are pretty much already reserved for grouping blocks of declarations and statements.
I'd like the convention to follow maths that { , , } denotes a set (unordered) whereas ( , , ) denotes a positional tuple (ordered).
HTML/JSON have reserved angle brackets <tag> haven't they? That rather banjaxes using them for greater/less comparisons?
I'd like to use [ ] as a stylistic variant for ( ), so it's easier to see the grouping of deeply-nested expressions ( x, y, [z, (w, v), u], t, (s, r)). But most languages seem to reserve [ ] to mean something different vs ( ).
In my for-myself jottings I write relation values like
{ {S# 1, SName 'Acme', City 'London', Status 10}
, {S# 3, SName 'Perkins', City 'Ely', Status 20}
}
OTOH, large relation values are going to be in the database/possibly entered via some grid-based tool; not appear in program text.
Quote from Darren Duncan on April 9, 2021, 4:59 amDesign opinion question for a HUMAN READABLE/WRITABLE data/code serialization format alternative to JSON/YAML/XML/SQL/etc, what do you prefer to use aesthetically for collection literal delimiters, between round parenthesis and square brackets and curly braces, and for what kinds of collections each?
Currently I’m using parenthesis for heterogenous/structural literals namely pairs and tuples/headings, while I’m using curly braces for homogeneous literals which are almost everything else including arrays and sets and bags etc, and square brackets are just for interval literals.
Relation literals would be expressed visually as a set literal whose elements are tuple literals, when non-empty.
I am debating swapping the uses of brackets and braces since a different change means my primary reason for choosing braces no longer applies.
A main question I have for you is aesthetically would you rather see a data/code file with more curly braces or more square brackets or do you like each about the same?
All the same to me.
To me, it's more important that whatever delimiter scheme you use be consistent and/or have some overall systemic plan, rather than being ad hoc or arbitrary.
As you may have guessed, I'm talking about Muldis Object Notation.
Here is the current version with embedded examples: https://github.com/muldis/Muldis_Object_Notation/blob/master/spec/Muldis_Object_Notation_Syntax_Plain_Text.md
Here is an example relation literal with the current syntax:
(Relation<-{
(name : "Jane Ives", birth_date : 0Lci@y1971|m11|d06,
phone_numbers : (Set<-{"+1.4045552995", "+1.7705557572"})),
(name : "Layla Miller", birth_date : 0Lci@y1995|m08|d27,
phone_numbers : (Set<-{})),
(name : "岩倉 玲音", birth_date : 0Lci@y1984|m07|d06,
phone_numbers : (Set<-{"+81.9072391679"})),
})
Here is an example of what that would look like with the alternate bracketing:
(Relation<-[
(name : "Jane Ives", birth_date : 0Lci@y1971|m11|d06,
phone_numbers : (Set<-["+1.4045552995", "+1.7705557572"])),
(name : "Layla Miller", birth_date : 0Lci@y1995|m08|d27,
phone_numbers : (Set<-[])),
(name : "岩倉 玲音", birth_date : 0Lci@y1984|m07|d06,
phone_numbers : (Set<-["+81.9072391679"])),
])
And here are before+after examples of an interval literal, which would swap the other way:
[2.7..-9.3]
{2.7..-9.3}
There are more examples at the above url. This is still a work in progress in other respects.
Quote from AntC on April 9, 2021, 7:59 amI'd like the convention to follow maths that
{ , , }denotes a set (unordered) whereas( , , )denotes a positional tuple (ordered).
As you'll see in my prior post, I have done the same thing as you gave here, except that parenthesis are both positional AND named tuples; terms in "x:y" form are named and any "y" appearing by itself is positional from left to right.
My tuples are fundamentally named like in a D language but the syntax assigns special names to any written in a positional manner, so ("hello","world") is equivalent to ("\<0>":"hello","\<1>":"world") for example and would canonically serialize in positional syntax. The numbers in the examples are Unicode code point numbers, aka non-printing control characters for the first 31.
Also for context/example, here is all the examples from that spec document extracted into a single larger artifact of the format, which is more analogous to a whole JSON/etc document:
https://github.com/muldis/Muldis_Object_Notation/blob/master/corpora/overview.muon
Quote from Darren Duncan on April 9, 2021, 9:55 amAs you may have guessed, I'm talking about Muldis Object Notation.
No I didn't guess. What is Muldis Object Notation? Don't you mean: Darren's private notation? If it's purely for private use, I agree with Dave: "all the same to me". If it's for public use, isn't there already some public notation that's close enough? Please don't re-invent the wheel.
Here is the current version with embedded examples: https://github.com/muldis/Muldis_Object_Notation/blob/master/spec/Muldis_Object_Notation_Syntax_Plain_Text.md
Here is an example relation literal with the current syntax:
Here is an example of what that would look like with the alternate bracketing:
Yuck
What's the back-arrow <- for? Why do you need to say Set if your notation is there to denote a set? Why do you need to say Relation when a Relation is a Set?
: is used in a lot of languages to show a type-signature. And in some languages to denote list-building. The more common notation for attribute name-value pairs is = as in name = "Jane Ives" -- or of course Tutorial D uses juxtaposition, but I can see that might be ambiguous syntax.
And here are before+after examples of an interval literal, which would swap the other way:
[2.7..-9.3] {2.7..-9.3}
An interval is ordered/not a Set. So you're going to change to using curly braces (which in maths denote a set), to denote a not-set.
There are more examples at the above url. This is still a work in progress in other respects.
[from a later message] more analogous to a whole JSON/etc document:
So this is an interchange protocol, not for programming language text? Is it going to pass any information/structure that can't be expressed in JSON? Please just use JSON. And stop rearranging the deckchairs of your 'work in progress': make some progress on the work. You seem to be suffering from paralysis by analysis.
Quote from AntC on April 9, 2021, 11:02 amIf it's for public use, isn't there already some public notation that's close enough? Please don't re-invent the wheel.
What's the back-arrow
<-for? Why do you need to saySetif your notation is there to denote a set? Why do you need to sayRelationwhen a Relation is a Set?
:is used in a lot of languages to show a type-signature. And in some languages to denote list-building. The more common notation for attribute name-value pairs is=as inname = "Jane Ives"-- or of course Tutorial D uses juxtaposition, but I can see that might be ambiguous syntax.An interval is ordered/not a Set. So you're going to change to using curly braces (which in maths denote a set), to denote a not-set.
So this is an interchange protocol, not for programming language text? Is it going to pass any information/structure that can't be expressed in JSON? Please just use JSON. And stop rearranging the deckchairs of your 'work in progress': make some progress on the work. You seem to be suffering from paralysis by analysis.
This is for public use.
I feel that I'm hardly reinventing the wheel and that what I'm doing is significantly different than existing alternatives.
The curly brace notation is the basis of about a dozen stronger types and the "Foo <-" says which of the stronger types we have.
I have standardized around using the colon to universally mean a generic pair context. The colon seems to be quite commonly used for that.
The thing about the interval is that it was a lot more different than the other collection types and that in its context having different delimiters was useful syntactically.
My format is going to pass a lot of information/struction that can't be expressed in JSON. It is a lot more strongly typed and has a single formal definition that includes edge cases, while JSON lacks consistent standardization.
For example, in JSON all numbers are floats, where I distinguish integers and fractions. I also distinguish tuples from dictionaries. I also explicitly distinguish user-defined types, analogous to class names, from anonymous ones. I also distinguish unordered sets from unordered arrays. I also support comments. And so on.
I make progress as I have time.
It seems more clear to me at this point that the best decision is to keep the curly braces and square brackets as they are, and not further entertain the possibility of swapping them.
Thank you all for your feedback.
As for what I'm doing taking a lot of time and moving slowly, I don't see how this is much worse than how things are going among others in this forum.
After decades of talk there still isn't a widely used Industrial D from anyone else, is there?
Quote from Darren Duncan on April 9, 2021, 11:39 amIt seems more clear to me at this point that the best decision is to keep the curly braces and square brackets as they are, and not further entertain the possibility of swapping them.
Thank you all for your feedback.
As for what I'm doing taking a lot of time and moving slowly, I don't see how this is much worse than how things are going among others in this forum.
After decades of talk there still isn't a widely used Industrial D from anyone else, is there?
In terms of database languages, there isn't a widely used anything-that-isn't-SQL.
Even the most widely used NoSQL systems like MongoDB and Lucene are barely a drop in the bucket compared to SQL DBMSs.