3 ms·

Looks cool. Great first example, it's highly applicable and actually doesn't look bad. Perhaps adding a few more "marketing" things to the readme - or at least

by junon 4y ago

Looks cool. Great first example, it's highly applicable and actually doesn't look bad. Perhaps adding a few more "marketing" things to the readme - or at least, perhaps a few questions you might answer here. - Is this a toy? Or is your intent to polish this for real world use? Just curious. - How does error handling work? - Does this compile down to a language for integration into an application? It's unclear (at least, from reading the docs for a few minutes) what the output artifacts for this are.

kstenerud 4y ago
It's to scratch a personal itch of mine: formal, human readable descriptions of binary data formats. I couldn't find anything suitable for describing the binary format for Concise Encoding (https://concise-encoding.org/ https://concise-encoding.org/), so I did the crazy thing, thinking "how hard could it be?" But it worked out and I have a formal description for it now: * https://github.com/kstenerud/concise-encoding/blob/master/cbe.dogma https://github.com/kstenerud/concise-encoding/blob/master/cb... * https://github.com/kstenerud/concise-encoding/blob/master/cte.dogma https://github.com/kstenerud/concise-encoding/blob/master/ct... So it's primarily geared towards documentation. That being said, there's no reason why tools couldn't use it as well (I'm trying to keep it consistent enough that tools could be built, or possibly even a specialized parser-generator language that uses Dogma as a base, similar to how Antlr uses a modified EBNF). But I've got too many projects going on as it is, so anyone who wants to build tooling, I'm all for it and will help where I can :) Error handling would be an implementation detail. The spec only describes what counts as a malformed grammar, and what counts as an ambiguous grammar (and a small bit about undefined behaviour, which counts as ambiguous).

by junon 4y ago

kstenerud 4y ago

It's to scratch a personal itch of mine: formal, human readable descriptions of binary data formats. I couldn't find anything suitable for describing the binary format for Concise Encoding (https://concise-encoding.org/ https://concise-encoding.org/), so I did the crazy thing, thinking "how hard could it be?" But it worked out and I have a formal description for it now: * https://github.com/kstenerud/concise-encoding/blob/master/cbe.dogma https://github.com/kstenerud/concise-encoding/blob/master/cb... * https://github.com/kstenerud/concise-encoding/blob/master/cte.dogma https://github.com/kstenerud/concise-encoding/blob/master/ct... So it's primarily geared towards documentation. That being said, there's no reason why tools couldn't use it as well (I'm trying to keep it consistent enough that tools could be built, or possibly even a specialized parser-generator language that uses Dogma as a base, similar to how Antlr uses a modified EBNF). But I've got too many projects going on as it is, so anyone who wants to build tooling, I'm all for it and will help where I can :) Error handling would be an implementation detail. The spec only describes what counts as a malformed grammar, and what counts as an ambiguous grammar (and a small bit about undefined behaviour, which counts as ambiguous).