ratmice / crimson Goto Github PK

We should probably have some differentiator between when keys are data, and when keys are fields of a structure...
From memory I don't believe there is anything in the current parser which represents fields of structures.

This issue kind of explains part of why crimson is such a weird looking language:

https://github.com/pikkr/pikkr is a partial inspiration, if there are design decisions that we can take which make the language
more amiable to pikkr style parsers we should consider them.

Another weirdness budget issue:

We should implement a type checker for crimson, and try and make it a single pass, which type checks you read.
This should explain some other weird decisions regarding why we chose <type>value rather than value: type.
But anything which prevents type-check-as-you-go... should be considered a defect in the language

Background

Crimson has a dichotomy between ordered and unordered collections,

• Set: {0, 1, 2}
• Array: [0, 1, 2]
• Map: {"foo" = 1, "bar" = 2}

For syntactic consistency it somewhat makes sense to include

• Tree: ["foo" = 1, "bar" = 2]

This rule is commented out of the grammar here:

Argument for

I think that the biggest argument for allowing it comes from the order_preserving feature of the following libraries:
https://docs.rs/crate/toml/latest/features
https://docs.rs/crate/serde_json/latest/features

These existence of these features here wouldn't actually help much for converting between json or toml and crimson ordered/order preserving types depending upon whether this flag is enabled.
But I think the problems associated with these features, and even their mere existence at least provides some motivation
for having an ordered preserving tree.

Argument against

It is kind of weird, and no other serialization languages I know of include any kind of order preserving tree.
Of those languages that don't include it, I know of zero complaints regarding it, If you need order preserving you probably just use an order preserving parser if not you don't.

This would make crimson -> json a non-injective surjective function where Tree and Map both correspond to json's Object,
however I believe that is already the case regarding Set.

Since the syntax is in flux, it may be nice to consider an attribute like #![crimson(version = "0.0.1")] and a way to make such an attribute required, or optionally specified via the parser.

Making required version, would be good for cases like the testsuite where you control the input and implicitly know which version.