I appreciate the input :) but the thing is that the typing concept in eno as it is now is essentially what makes eno eno. Every application that uses eno decides for itself what types it supports and requires, and that in turn is how eno manages to be so simple and usable on the language level, even for completely non-technical people who normally feel uncomfortable with the idea of editing their content as raw text files.
If I would add types and type inference again, then I would essentially arrive at YAML and TOML again, and I don't want to reinvent them. ;)
But if I actually misunderstood you there, please let me know and do clarify!
Is so spartan that everyone need to encode dates somehow, to make a simple example. I think this are the base types (also, my experience with RDBMs and building a relational lang now, and always having troubles with cvs, json, and others formats in ETL kind-of-task):
- String
- Floats. Can be split Ints/Floats but stick to just Float is ok. However, make it Float64.
- Date(Time). And be ISO. Not ambiguity.
- Boolean
- Decimal64. This is a pet peeve of mine. A lot of data in the business space is about money, and floats are not ok. What if like in rebool $3.2 is decimal?
Then the composites.
ie: This is json + dates/decimal. And make a single encoding (utf8?).
Is insane that, for example, you save a CVS in excel and open it again and excel get lost, and can't parse it fine.
Apart from this, url, email, host, website, phone, cellphone, city, country, state are so common that maybe with a import like "!schema:common-fields" or something.
If I would add types and type inference again, then I would essentially arrive at YAML and TOML again, and I don't want to reinvent them. ;)
But if I actually misunderstood you there, please let me know and do clarify!