WIP:Format formalization #30
Conversation
* Technically I started some sequence class definitions already too.
* It should be reviewed to catch any silly errors.
* Some mixing of math text (just set operations and notation) has
happened. The notation itself still follows BNF pretty closely,
and I definitely would not call it MBNF. With Wikipedia and some
knowledge of set operations it should be easy to figure out the
formalizations.
* The spec comments at the top of the mds-format.txt file did not
mention including the length of the blocks, and they were
unnecessary anyway. The final grammar for the class <mds> is
very much just that initial specification with a little verbosity.
|
Looks good to me! Do you think the specs could be made fully BNF compliant? Development of future file converters/parsers could be made easier if we get it fully compliant. Though the current format is good enough, in my opinion. |
| where | ||
| <character'> = <newline> △ <character> | ||
|
|
||
| ;; Do we need all of utf8? | ||
| ;; I tend to prefer generality, but maybe this is too much. | ||
| <character> ::= <set of all valid utf8> |
There was a problem hiding this comment.
The main deviation I have made is here. Both <newline> △ <character> and <set of all valid utf8> (I should add codepoints to that text) are shortcuts, but otherwise we need to define our <string> class by including EVERY character we want to be valid in this file. Even with just lower and uppercase ascii that will add clutter, but if we want to make sure that Asian, Arabic, Jewish, etc... authors can add their real given name to MDS files, then the grammar should include more than ascii. Defining such a class without shortcuts would mean a seriously long class definition where we would need to include all of the characters (many have to be represented as strings, since they are multibyte).
NB. Multibyte strings don't break the C or ascii rules, so allowing all utf8 codepoints doesn't require any changes in your code (probably).
There was a problem hiding this comment.
Given the massive class definitions that would be in the file without the Set based shortcuts I think it would be harder to implement parsers. At least, to make it easier we would need comments explaining what the giant right side content is, so we would essentially have some ad hoc implementation of these shortcuts as informal comments. Anyway, I just thought this perspective would help us think about it. If you think the current approach is fine, then I guess we have no issue. I will work on a formalization for the MDM files in whatever free time I get this week ;)
There was a problem hiding this comment.
Let's keep it that way then. No need to be 100% BNF compliant.
I tried to explore other ways this evening, it's just not worth it. Your current implementation is good!
There was a problem hiding this comment.
In case we want anything from the established extended BNFs https://en.m.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
|
Hi, sorry I didn't get back to this laast week. I should have time this weekend. |
I have a first draft of BNF-derivative formalization of the mds file format.
I can do one for the mdm format too.
The second commit message has a lot of information, so I suggest reading it.