The Eno notation language • Hacker News Board

Re: The Eno notation language

#11

Post by simonrepp » Thu, Aug 16, 2018, 12:23 PM UTC

FreeFull wrote: post #6

Is there a comparison to TOML?

I'll attempt to list some major points: - TOML keys are alphanumeric, in eno they allow the full unicode range - In eno there are no inline syntax constructs like in TOML, this is simpler although sometimes more verbose - TOML has fixed types and type syntax rules on the language level, eno has arbitrary application-defined types - TOML is designed for completely generic de/serialization (through fixed types), eno relies on domain-specific serialization

There are also (maybe even more) important paradigmatic differences concerning how the parser APIs differ, and also need to differ, given the different typing approach in TOML vs. eno, but I'll limit this to the language points for brevity here. :)

Generally speaking - the higher the volume of content/configuration/data there is in a given application or the more it is relevant that the application is also accessible and easily usable for users without a technical background or the more your data and types are application specific and possibly exotic, the more I would recommend eno.

On the other hand, the more generic your data (especially the more it requires generic serialization), the more it is shared by myriads of different applications, the more it is handled by a very technical audience, the more I would recommend TOML.

Re: The Eno notation language

#12

Post by kolektiv » Thu, Aug 16, 2018, 12:24 PM UTC

From a relatively short glance, I don't see any mention of what problem this is trying to solve. Data interchange? Storage? Consumption/production?

I see some excitingly magical looking type "inference" happening though. That ruby code is sure that the value associated with Malaga is a lat/long pair is it? Not a temperature range, etc.? So, some very optimistic approach to types, no real way to validate content, and some quirky looking syntax (: , but also #\n: apparently? If I have more than two levels?)

I'm not sure what this is for. I am pretty sure that those people using it are going to run up against a whole thrilling raft of edge cases...

Re: The Eno notation language

#13

Post by fnordsensei » Thu, Aug 16, 2018, 12:29 PM UTC

teddyh wrote: post #2

# cities Den Haag: 52.069961, 4.302315 Málaga: 36.721447, -4.421291 Here, “cities” looks like a comment, but it is part of the syntax, otherwise this example code would not work: document.section('cities').lat_lng('Málaga') The actual comment syntax is “>”: > comment

It looks like the H1 tag in markdown, where the number of #'s indicate title level.

Re: The Eno notation language

#14

Post by simonrepp » Thu, Aug 16, 2018, 12:36 PM UTC

teddyh wrote: post #2

# cities Den Haag: 52.069961, 4.302315 Málaga: 36.721447, -4.421291 Here, “cities” looks like a comment, but it is part of the syntax, otherwise this example code would not work: document.section('cities').lat_lng('Málaga') The actual comment syntax is “>”: > comment

Yes exactly - Hashes denote 'sections' in eno!

In the language design phase this was heavily inspired by markdown, because of the already widely familiar concept of 'headings' - I collected feedback from users that (although they showed considerable anxiety given the prospect that they were to use text files to edit their content in the future instead of a fancy web interface) they found working with markdown (quote) "super easy", so markdown was therefore an influential factor for some aspects of the language design. :)

Re: The Eno notation language

#15

Post by simonrepp » Thu, Aug 16, 2018, 12:38 PM UTC

fnordsensei wrote: post #13

teddyh wrote: post #2

# cities Den Haag: 52.069961, 4.302315 Málaga: 36.721447, -4.421291 Here, “cities” looks like a comment, but it is part of the syntax, otherwise this example code would not work: document.section('cities').lat_lng('Málaga') The actual comment syntax is “>”: > comment

It looks like the H1 tag in markdown, where the number of #'s indicate title level.

Spot on, that's how it works!

Re: The Eno notation language

#16

Post by simonrepp » Thu, Aug 16, 2018, 12:43 PM UTC

nautilus12 wrote: post #8

Thought this was about hammocks :(

There is considerable shortage of available three-letter file extensions that don't sound like robots from star wars, so unfortunately a sacrifice had to be made there :)

Re: The Eno notation language

#17

Post by simonrepp » Thu, Aug 16, 2018, 12:45 PM UTC

mstijak wrote: post #5

This reminds me of an old project of mine called NIML - Non-Indented Markup Language. http://mstijak.github.io/niml/index.html

Pretty cool, I remember coming across it during research for eno actually! small internet :)

Re: The Eno notation language

#18

Post by jacobevelyn » Thu, Aug 16, 2018, 1:06 PM UTC

simonrepp wrote: post #14

teddyh wrote: post #2

# cities Den Haag: 52.069961, 4.302315 Málaga: 36.721447, -4.421291 Here, “cities” looks like a comment, but it is part of the syntax, otherwise this example code would not work: document.section('cities').lat_lng('Málaga') The actual comment syntax is “>”: > comment

Yes exactly - Hashes denote 'sections' in eno! In the language design phase this was heavily inspired by markdown, because of the already widely familiar concept of 'headings' - I collected feedback from users that (although they showed considerable anxiety given the prospect that they were to use text files to edit their content in the future instead of a fancy web interface) they found working with markdown (quote)…

This is a really cool project! I don't need quite the power of eno (yet!) in my CLI journaling app[1], but I similarly value the power of users being able to just easily read and write their own data. (I went with Markdown for the data store.)

[1]: https://github.com/JacobEvelyn/friends

Re: The Eno notation language

#19

Post by wemdyjreichert » Thu, Aug 16, 2018, 1:15 PM UTC

Oh, yay, yet another markup language (dammit, that's yaml, oops). More stuff to confuse people. Why did the world need this? Solving what? Also, I thought at first it was "emo", then I thought it was referring to hammocks.

Re: The Eno notation language

#20

Post by TuringTest » Thu, Aug 16, 2018, 1:43 PM UTC

kolektiv wrote: post #12

From a relatively short glance, I don't see any mention of what problem this is trying to solve. Data interchange? Storage? Consumption/production? I see some excitingly magical looking type "inference" happening though. That ruby code is sure that the value associated with Malaga is a lat/long pair is it? Not a temperature range, etc.? So, some very optimistic approach to types, no real way to validate content, and…

In the latest years I've seen a trend towards syntax-lightweight languages.

Developers are already well served with their powerful programming languages, able to express very complex concepts and relations with terse syntax. But those high-level languages have very complex grammars, and each token must be carefully placed with respect to their surrounds to make sure that it compiles and expression types are well matched.

There's an unmet need at the other side of the complexity spectrum, with languages that can't express complex concepts, but which accept simple terms expressed with extremely simple syntax and grammar; to the point that non-programmers may be able to create and edit those files. For building documents we first had BBCode and now have Markdown as the emerging standard; but things like templates and simple scripting needs require a language which can express some computations and relations.

Developers first wrote ad-hoc parsers for their configuration files, and are now well served with JSON for structured data serialization. But that format is still too complex for casual use by inexperienced users. Something like eno could work for them in a context where defining data structures and assignment to variables is needed.