Thanks, but I would keep using SDLang :
https://sdlang.org/
Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
41–50 of 68 posts
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#42Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#43What I was looking for on the website and think is more than implementing a parser in another language is schema support. That is, you should provide something like XSD for XML, JSONSchema for JSON, TOLS for TOML. Why? There is a need (see above enumeration) to declaratively specify how an Eno file should look like. I do not want validation to creep into my code, like you do with `document.string('author', required:…
Yay thanks for the detailed input! If there is demand or initiative for a portable schema solution I'll gladly support it! The native architecture in the eno libraries is programmatic because that does have its own powerful merits which are employed to the fullest in the API design, like always there's not one best choice, and the 'validation creeping into code' can be turned around into 'external schema definition c…
I've come to really appreciate the difference between "syntactically correct" (ie: is a file valid xml) vs "semantically correct" (ie: does it follow a specific dtd if it's valid xml.) More than that, I've come to realize how many other people don't have this appreciation even though they will identify problems that directly relate to this distinction in every day usage.# #twitter
# \#twitter
To truly be able to have a portable file format, there needs to be a way to do both validations reliably in different contexts (eg: different languages). If you ignore this part of your design then it may become the slowest part of the eno ecosystem because your grammar will have quirks that you'll end up needing to support long-term. I suggest toying with this functionality now and providing something which is extremely pessimistic on what it will pass. Only loosen things up as people show a need and keep your entire spec as tight as possible.
I would imagine that you could even use eno syntax to describe document structure, much like xml/dtd has such strong parallels with each other. Then you get the fast parser in both places essentially for free!
Finally, on the format of eno itself, I'm curious on your thoughts relating to unicode characters that visually masquerade as common characters. eg:
http://www.fileformat.info/info/unicode/char/ff1a/index.htm
Sample usage:
---
author： Jane Doe
email： jane@eno-lang.org
---
Does this parse?
How about this:
---
author： Jane Doe:
email： jane=doe@eno-lang.org
---
What do I do if I want a "#" in a name?
---
@hackernews = 0xC0FFEE
---
or:
---
@hackernews = 0xC0FFEE
---
Are quotes optional somehow? Can I put arbitrary things into an identifier?
Cheers and keep up the great work!
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#44Kinda worthless rant, but I'm tired of reconsidering configuration file markup language every couple of years, and please remind me: why TOML isn't perfect?
TOML/YAML: You could read a truncated TOML file and not realize it.
On YAML, not if you enforce the usage of document end markers (e.g. an optional feature one could require if their use case demanded it). Though that's rarely a concern for configuration file formats in my opinion. If your transport (or storage) layer is that unreliable you probably don't need a human readable format in the first place.
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#45Earlier quoted context omitted.
That was true several years ago, much less so today
Python 2 is still the only python provided out of the box on Mac.
Python 2 is EOL in just over a year. Why would anyone write for a piece of software that will be completely unsupported in 18 months?
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#46After a quick look I have a lot of questions 1) Unlike YAML or JSON this doesn't parse into a simple array structure, but a library dependent object hierarchy? 2) Is the API of the libraries also part of the language spec? 3) Can I assume that document.lookup() will be available as document->lookup() in the PHP library? 4) What about programming language specifics that may differ between languages? Will the PHP objec…
1) Yes! (You can directly dump it to a language-native structure with the raw() method too, this is not 1:1 YAML/TOML style generic deserialization though as there are no fixed types in eno)
2) Some detail aspects of whitespace-parsing around the line continuation syntax will need to be specified by the language, the shared official API I am implementing for the different platforms is fully open to improvement and future reinvention though, I'd love to see a completely new take for a library API if it comes up in the future. :)
3) Definitely!
4) I try to keep things as consistent as possible across the platforms, but if there are important language specific paradigms I think these should be taken advantage of! I can't answer details regarding the PHP implementation yet but keep in touch, I'm happy about a dialogue here! (Also I can't be good at everything :)).
5) I want one! Obviously there can't be a stable generic "just dump it already" implementation, but a smart builder-type API is definitely on the list, I even started one for enojs but had to re-prioritize because there was so much else to do for the whole ecosystem. ;)
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#47Earlier quoted context omitted.
That was true several years ago, much less so today
Python 2 is still the only python provided out of the box on Mac.
Yes, but the fact that running `swift` in command line while system python is active spews an unholy amount of error messages is an indication than even there it is going away.
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#48Earlier quoted context omitted.
Yay thanks for the detailed input! If there is demand or initiative for a portable schema solution I'll gladly support it! The native architecture in the eno libraries is programmatic because that does have its own powerful merits which are employed to the fullest in the API design, like always there's not one best choice, and the 'validation creeping into code' can be turned around into 'external schema definition c…
I've come to really appreciate the difference between "syntactically correct" (ie: is a file valid xml) vs "semantically correct" (ie: does it follow a specific dtd if it's valid xml.) More than that, I've come to realize how many other people don't have this appreciation even though they will identify problems that directly relate to this distinction in every day usage. To truly be able to have a portable file forma…
Syntax vs Semantics is distinguished by ParseError vs ValidationError in the eno libraries - I'll keep the importance of distinguishing them in mind for the schema development too - thanks for pointing this out!
Right now only an ASCII colon is interpreted as an operator, but this looks like a question to thoroughly consider for the next and final spec (which is planned for 2019, currently we're in frozen RC) - work on this currently happens at https://github.com/eno-lang/eno.
There is escaping for arbitrary keys by using backticks - see the advanced language feature documentation at https://eno-lang.org/advanced/, in the case of # #twitter you wouldn't need it though unless you omit the space.
Thanks for your input, appreciate it!
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#49Earlier quoted context omitted.
Python 2 is still the only python provided out of the box on Mac.
Python 2 is EOL in just over a year. Why would anyone write for a piece of software that will be completely unsupported in 18 months?
Because, it is installed on Macs, as I said. I don't want to have to teach people how to install python 3, when they already have python 2, which is fine.
Also, redhat had promised support for a while yet, and I expect spoke to keep it working until they replace with Python 3 (or remove python altogether?)
Re: Show HN: Eno – A lightning fast, user-friendly YAML/TOML alternative
#50I'm left looking for a spec, like a real spec-flavored specification with all the gritty details, written like you would want if you were writing a parser. It doesn't seem like there is one, yet.
You're right, not yet! Jump-starting the whole ecosystem was a major time investment for me but now that there is public exposure providing a formal spec has a higher priority because someone might actually see it and do something with it ;) Keep an eye on https://github.com/eno-lang/eno, this is where I'm working on it, I'll also announce it on the newsletter (http://eepurl.com/dA9LcH) when it's there!