Right now number parsing is PoC quality.

Goal is to support everything that Zig supports, ideally by leveraging the Zig stdlib parser.

See src/cli/convert.zig for more information.

Also see #17 for the overall goal of completing ziggy convert.

In the construction of a Schema struct, we currently check for:

• Duplicate tag literal definitions
• Usage of unknown tag literals
• Duplicate struct definitions
• Duplicate struct field
• Usage of unknown struct names
• Duplicate mentions of the same Struct inside of a struct union expression

What's missing:

• Recognizing types of infinite size (ie self-references outside of a map or array container)
• Recognizing definitions impossible to reach from the root expression

Note that the presence of any automatically colors everything.

How to get started

Here we perform the aforementioned analysis:

Below those lines it would make sense to call a new function that performs the remaining checks.
It might make sense to add a field or two to the existing types (eg StructRule, Rule).

Look at src/Parser.zig for inspiration.

Interface prototype to start from:

pub fn stringify(value: anytype,  opts: StringifyOptions, writer: anytype) !void {}

pub const StringifyOptions = struct {
    whitespace: enum { minified, some_space_options, tab } = .minified,
    emit_null_fields: bool,
};

This is a good starting point, dealing with emitting tagged strings and other complications can be tackled in a follow up issue.

Follow up feature: support for a nonportable_numbers_as_strings: bool option.

Right now string parsing is PoC quality.

Goal is to support everything that Zig supports, ideally by leveraging the Zig stdlib parser.

Related design question: we want to be able to report an error at a given line and column. What's the correct way or reporting column number in the presence of things like emojis?

Sometimes there might be fields that have default values that for one reason or another might not need to be serialized / deserialized, as initing them with their default value is always the correct choice.

Right now this is needed to implement this feature in a type:

    pub const ziggy_options = struct {
        pub fn stringify(
            value: Assets,
            opts: ziggy.serializer.StringifyOptions,
            indent_level: usize,
            depth: usize,
            writer: anytype,
        ) !void {
            _ = value;
            _ = opts;
            _ = indent_level;
            _ = depth;

            try writer.writeAll("{}");
        }

        pub fn parse(
            p: *ziggy.Parser,
            first_tok: ziggy.Tokenizer.Token,
        ) !Assets {
            try p.must(first_tok, .lb);
            _ = try p.nextMust(.rb);
            return .{};
        }
    };

1. Since the outer type has a field of this type, you must find a "placeholder" value to put there.
2. You have to parse it correctly, otherwise you will leave in the stream tokens that need do be consumed.

Ideally this should be a setting that one can specify in ziggy_options

Right now the JSON converter is using std.json to parse a tree of json.Value but this way we lose line and column information when producing diagnostics.

This means that right now we print error: missing field 'foo', but we can't tell at which line and column of the original json file this field was missing (ie where the surrounding object closes).

To make this happen, we need to switch to a different approach that involves not losing information about the original token stream.

One potentially interesting solution is to start from a JSON token stream and produce a Ziggy AST.

See src/cli/convert.zig for more information.

Also see #17 for the overall goal of completing ziggy convert.

Related issues

• #14
• #21
• #15
• #16

Additionally support for PATH mode still needs to be implemented, alongside all the other minor flags.

See ziggy convert --help for a full list of features that must be supported.

The README currently says "Binary Format \ Note: this part is still vaporware \ An optimized binary representation that omits field names and avoids escaping strings." I suggest that designing a binary format from scratch may be some work and, while there are good reasons for creating a new text format like Ziggy, creating a new binary format may be too much. Why not using CBOR, standardized in RFC 8949?

1. It already exists, with a lot of implementations,
2. It is optimized for storage space, and simplicity of parsers,
3. Its data model is very close from the one of JSON so it seems it would be fine for Ziggy.

At the moment, given the following files, conversion will succeed:

build.json

{
        "name": "zine",
        "version": "0.0.1"
        "dependencies": {
                "foo": {
                        "Remote": {
                                "url": "https",
                                "hash": "aaa"
                        }
                },
                "bar": {
                        "Local": {
                                "path": "/usr"
                        }
                }
        }
}

build.ziggy-schema

root = Project

struct Project {
    name: bytes,
    version: bytes,
    dependencies: map[Remote | Local],
}

struct Remote {
   url: bytes,
   hash: bytes,   
}

struct Local {
  path: bytes,
} 

Result:

{
    .name = "zine",
    .version = "0.0.1",
    .dependencies = {
        "foo": Remote {
            .url = "https",
            .hash = "aaa",
        },
        "bar": Local {
            .path = "/usr",
        },
    },
}

The goal is to also make the following JSON files succeed at importing:

Shape matching:

{
	"name": "zine",
	"version": "0.0.1"
	"dependencies": {
		"foo": {
			"url": "https",
			"hash": "aaa"
		},
		"bar": {
			"path": "/usr"
		}
	}
}

type field:

{
	"name": "zine",
	"version": "0.0.1"
	"dependencies": {
		"foo": {
			"type": "Remote",
			"url": "https",
			"hash": "aaa"
		},
		"bar": {
			"type": "Local",
			"path": "/usr"
		}
	}
}

Comments should work also exactly like in Zig: only single-line, using //.

See src/cli/convert.zig for more information.

Also see #17 for the overall goal of completing ziggy convert.