-
Interesting. There’s a JavaScript demo to play around with the syntax at https://eno-lang.org/demo/. Would be neat to get some kind of generic parse tree (JSON?) for an eno document.
I’m a bit unclear on what it means that “all whitespace is optional”, and how to deal with whitespace in values. It appears that leading and trailing whitespace in a field like
Greeting: Hello Worldis stripped. It seems that to encode leading whitespace, you need a block:
---Greeting Hello World ---Greeting(This is relevant to me as this seems like a possible alternative to YAML that requires less painful indentation while offering raw multi-line blocks. I’m currently using YAML as a format for puzzles, but it’s not perfect, compare puzzle-draw.)
-
For the generic JSON-like parse tree you can use https://eno-lang.org/javascript/#Section-raw, note however that this debug output tree only contains strings (the parser does not know about your types) and as most elements can be turned into arrays by repetition in eno, most elements are wrapped as such in the raw inspection format by default (here again the parser cannot know :)).
Regarding whitespace you are correct - leading and trailing whitespace is always stripped, except in blocks, where all whitespace is retained verbatim, and your usecase is exactly the thing this mechanism is designed for, would be happy to hear about your experience in case you do try eno to store your puzzles! (Also feel free to get in contact in case of questions or if anything in the documentation can be improved)
-
Looks like line continuations or escaping might work for including whitespace: https://eno-lang.org/advanced/
-
Leading and trailing whitespace removal also happens for line continuations (except for the space separator itself which is added in by the parser), escaping only exists for keys, no value in eno ever has to be escaped, that is one of the design principles in the language to keep non-technical users from running into unpredictable and for them often unsolvable behavior. :)
Thanks a lot for helping out! - I’ll take the fact that not everything is clear yet as a nudge for myself to improve documentation in the coming weeks and months! ;)
-
-
I said this on HN, but I’ll repeat it here: I don’t think built-in complex data parsing is smart. Leave dates, email addresses, urls, colors, and latitude and longitude (!) to the devs, or maybe move it to a plugin. But including it opens you up to endlessly having to fix something that is orthogonal to your goal: a structured, plain-text notation language.
Also, don’t validate email addresses or urls with regex, please. Most of these examples on Wikipedia don’t work with your regex, and a fair number of the invalid ones do. Just check for a
@and move on if you must.Quoting the creator on Hacker News:
I think this actually strikes a nice balance between “smart” and “dumb”. I agree wholeheartedly about the e-mail address regex, though.
Yeah, I’m glad it’s not magical, but it still feels weird to have them encoded in the current “core” parsers. How is converting a normal string of numbers to a dictionary different than calling “parse_lat_long”? Sure, you get the error message, but there are also instances when you don’t need 6 points of precision which invalidates the whole function. Just make it easily extensible and let users define their own.
Yeah, I agree.
Your point got through loud and clear and I will consider it closely, as all are :) thanks again for bringing it up!
Just in case you haven’t seen it already, here’s my response on HN that at least should explain why I put in non-thoroughly engineered type loaders (even though I myself highly regard thoroughness) https://news.ycombinator.com/item?id=17777113