[deathanatos]

I'm curious what data types exist in this? The (loose) specification says,

> In eno there is no type differentiation on the language level, there are only textual representations ("strings"), which are always referred to as values.

Yet the example seems to show floating points being parsed as such. While I can see allowing the implementation some leeway — they may not all have the same notion of integral types, for example, Python & JS parse JSON "3" "differently" — Python as an int, JSON as a "Number" (IEEE floating point) — this seems more vague than you'd want. But that could just be due to the spec still coming along.

Is there anything you think Eno accomplishes over TOML (my present choice when dealing w/ configuration files, great for humans) or YAML (arbitrary but more complex data structures that still need to be touched or input by a human; more complex, but generally still human usable) or JSON/CBOR (machine to machine interchange of loosely typed data)? (I list them all since I presently "use" them all for slightly different choices.)

And +1 for having ABNF. (Even if rough.) And I appreciate that it is specified in terms of Unicode code points, which is very appropriate IMO for a textual language.

[simonrepp]

The design principle for types in eno is that the language itself has no notion of types, there are only plain textual representations. Meaning, types are never inferred from a document. Instead, when parsing an eno document the application explicitly requests the type it expects for each field, thereby validating the document during parsing. From the perspective of the libraries for parsing eno, types are defined as simple functions/closures (I call them "loaders"), that basically take the string value from a field and validate/transform and return it as the proper type. Some of these loaders currently ship with the libraries for convenience (int, float, datetime, etc. - this is not a hard specification though, just a sensible predefined toolbox), but there can be any number of types, whichever types an application needs in addition can be defined and used on the fly.

This is the main point that differentiates eno from almost all TOML/YAML/JSON like formats, and the implication of this is that eno is extremly simple and very accessible for non-technical users (so far all casestudies have verified this to be true) and a highly reliable data source for developers, but it also comes at the cost of losing generic de/serializability, so it depends on the usecase whether eno should be chosen over other formats. :)

There are also some other things that are unique to eno (e.g. all parser and validation error messages are fully localized and in user-friendly humanized language) or painfully missing in some other formats (e.g. having any number of "multiline string" fields that don't hang indented against an invisible left margin somewhere in the document), feel free to explore further on the website if you're curious!

Thanks for your interest and the feedback on the ABNF (much appreciated!), hope I could clarify things a bit. :)