Cobra Data Language

[Charles]

I often need to load in configuration data or potentially exchange data between two Cobra programs. There is of course XML, JSON, YAML, etc. but it would be nice to have something Cobra-centric as another option. Here is a quick, incomplete example:

{
    'id': 500,
    'created': <2009-07-08 00:07>,
    'isActive': true,
    'location': Point(5, 10),
    'numbers': [2, 4, 6, 8]
}

As in Cobra, dictionaries and lists are not whitespace sensitive so you could write:

{"up": 1, "down": -1}

And here is a very lightweight spec. I'm looking for feedback and questions.

primitives:
    ints
    decimals/floats
    strings   "foo"  'bar'
    nil
    booleans: true, false

extended primitives:
    dates   <2009-07-07>
    times   <23:00>  <23:00:00>
    datetimes   <2009-07-07[T]23:00:00>
    timespan   <???>
    colors   <#ef7d99>  <#eee>  <rgb 128 128 128>  <rgb .5 .5 .5>  <hsb .9 .8 .7>

objects:
    ClassName()
    ClassName(value, value)
    ClassName(property=value, property=value)
    ClassName(value, value, property=value)

lists:
    [1, 2, 3]

sets:
    {1, 2, 3}
    {,}
    
maps/dictionaries:
    {key: value, key: value}
    {:}

[Charles]

Also there would be comments like # and /# ... #/

Also with my former open source project Webware for Python, we really ended up preferring that the top level of our config could be "foo = bar" like so:

id = 500
created = <2009-07-08 00:07>
isActive = true
location = Point(5, 10)
numbers = [2, 4, 6, 8]

Which is easier to type and easier on the eyes.

Finally, there is the speculative idea that we could also support an indented format. This would be an option, not a requirement. It would eliminate much of the punctuation around lists and dictionaries [ ] { } ,. But frankly I don't plan on tackling that right now.

[todd.a]

I think this format will serve 90% of the use cases for configuration and even flat file storage. My only tweaks would be using having an implicit dictionary instead of having to surround everything with { } and ignoring the single quotes. I also favor vertical bars to angle brackets like in the DateTime e.g. It would look like:

id: 500,
created: |2009-07-08 00:07|,
isActive: true,
location: Point(5, 10),
numbers: [2, 4, 6, 8]

This will help greatly in the data storage cases, since logging can simply be an append-to-file. The indented form is also a good idea for nested data collections like dictionaries. Look forward to seeing it in the core as .Net is very xml centric which is often overkill, verbose, and even ugly.

[Caligari]

Is there perhaps a reason to also include <r, g, b, a> for colors? I know we alpha frequently where I work, but it might not be such an issue for most people.

[Kurper]

I'm not sure what this would have to offer beyond YAML. A more convenient format for dates and colors would certainly be nice to have, but I don't know that being able to do

Code: Select all

|2009-07-07[T]23:00:00|

is superior enough to either doing

Code: Select all

!DateTime { year: 2009, month: 7, day: 7, hour: 23, minute: 0, second: 0}

or doing

Code: Select all

"2009-07-07 23:00:00"

and running DateTime.Parse() on it to be worth creating a new, incompatible configuration format. Similarly,

Code: Select all

#ffffff

is certainly not worse than

Code: Select all

!Color { red: ff, green: ff, blue: ff}

but it's not massively better, either. And I doubt writing the parser for this would be significantly easier than writing one for an equivalent subset of YAML.

[Charles]

@webnov8, I strongly prefer "id = 500" over "id: 500,". Plus with your approach to the shortened format, only { and } are being saved which is almost no point.

@webnov8, Any reason you like |extended primitive| over <extended primitive>? I find <> easier to type, I like the open/close nature of < and >, and I'm also used to seeing that format in Python's repr output (which admittedly makes me biased).

@Calligari, Yes I think alpha channel should be an optional 4th channel. Thanks for bringing it up.

@Kurper:

-- I definitely see "!DateTime { year: 2009, month: 7, day: 7, hour: 23, minute: 0, second: 0}" as being inferior due to excessive length. Sometimes I'm typing these files by hand!

-- "2009-07-07 23:00:00" is not viable for dates because it's a string.

-- Not sure what you meant by incompatible format re: DateTime.parse. I'm sure it will take the ISO YYYY-MM-DD[T]HH:MM format inside the <> or ||.

-- I think <#ffffff> is massively better than !Color { red: ff, green: ff, blue: ff}

-- Re: YAML, well I love Cobra, so I'd like a Cobra-centric option for data. This doesn't remove the fact that there are 2 libraries for YAML on .NET plus the option of writing your own. Or using JSON.


More feedback is welcome. So far the only change is adding the alpha channel to the colors.

[todd.a]

@Chuck regarding the opening and closing { } what you said is true but I was thinking in terms of log files. It is easy to deal with { } but a tad more efficient if you can just call File.append, only { and } are being saved but for e.g. in logging i can quickly use

writer = File.appendText('foo.log')
writer.writeLine('key: value')

and not have to worry about the }. As for <> vs. || see below.

@Kurper using vertical bars is purely a matter of syntax. I am a huge fan of beautiful design, especially minimalist art. That means I gravitate towards concise nice and good looking syntax. It is easier to type <> as Chuck pointed out but |foo| looks better to me. So keep in mind it's just a matter of syntactic beauty.

Btw, it's easier to type : than = but either one will work for me . I am pro : in the sense that all of the config is a dictionary by default, as for = i like it since a more INI feel can be accomplished but with better types.

[Kurper]

-- "2009-07-07 23:00:00" is not viable for dates because it's a string.

-- Not sure what you meant by incompatible format re: DateTime.parse. I'm sure it will take the ISO YYYY-MM-DD[T]HH:MM format inside the <> or ||.

I think with all the [code]s my post was a bit unclear. What i meant was that you can just write date: "2009-07-07 23:00:00" and then use DateTime.parse on it in your library-using code, or even define a custom Cobra type so that you can say date: !CobraDate "2009-07-07 23:00:00" and it'll parse it for you. Given the relative ease of doing these things, the incompatibilities added with a new data language would not be warranted.

In fact, now that I look at the YAML docs some more, it'd actually be possible (and easy) to add a new date format that is just <2009-07-07 23:00:00>, without the moderately ugly !CobraDate stuff, and do the same thing for colors and any other data type you want. See, for instance, http://pyyaml.org/wiki/PyYAMLDocumentation#Constructorsrepresentersresolvers. I'm not certain that this is allowed by the YAML spec, but since PyYAML does it it's probably not horribly against the spec either.

Additionally, as I understand it, there aren't any full-featured YAML libraries for .NET, so writing one in Cobra and putting it out as a .dll would also make for some pretty good publicity - I'm sure thousands of developers would love a complete .NET YAML parser and emitter.

-- Re: YAML, well I love Cobra, so I'd like a Cobra-centric option for data. This doesn't remove the fact that there are 2 libraries for YAML on .NET plus the option of writing your own. Or using JSON.

Honestly, I don't see how this would be Cobra-centric beyond the fact that nobody using anything but Cobra would be able to read it without writing a custom parsing library. The differences from YAML seem to be far more along the lines of "things that are nice to have in a data language and YAML only supports moderately well" than "things that Cobra applications require, but other applications don't."

[Charles]

Additionally, as I understand it, there aren't any full-featured YAML libraries for .NET, so writing one in Cobra and putting it out as a .dll would also make for some pretty good publicity - I'm sure thousands of developers would love a complete .NET YAML parser and emitter.

If you want to pursue this, that would be great. webnov8 has cranked out some open source libs on bitbucket recently and I think I will as well at some point.

Honestly, I don't see how this would be Cobra-centric beyond the fact that nobody using anything but Cobra would be able to read it without writing a custom parsing library. The differences from YAML seem to be far more along the lines of "things that are nice to have in a data language and YAML only supports moderately well" than "things that Cobra applications require, but other applications don't."

It's Cobra-centric because the syntax is based on the Cobra programming language. To create a set in CDL you type the same thing you type in Cobra: {1, 2, 3}. I don't even see how to do sets in YAML. Once you show me, it will probably not be Cobra-language compatible (at the syntax/compiler level). With the exception of the extended primitives, everything in CDL is valid Cobra.

The differences from YAML aren't about trying to improve YAML. The differences are incidental by-products of CDL's adoption of Cobra syntax.

I encourage you to pursue a Cobra-based YAML parser since that's what you want. Don't let CDL dissuade or distract you.

[torial]

Just curious -- did this CDL ever get implemented?

I dislike the verbosity of XML, and even managed to convince my team to use JSON instead for a recent contract