
The Eno notation language - tosh
https://eno-lang.org/
======
kolektiv
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 (<key>:
<value>, but also #<section>\n<key>: <value> 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...

~~~
simonrepp
What you're seeing there _is_ actually validation :), the lat/lng type is not
magically inferred but instead explicitly requested by the code - if it were
not valid it would generate a user-friendly, localized error message. Also the
underlying document hierarchy that holds the data is validated. So on the
contrary it is actually hard _not_ to validate content in eno.

The quirky looking syntax you mention is probably familiar to you from YAML or
paper forms ("Name: Joe"), and Markdown ("# Section"), likewise if you have
two levels you use "## Subsection".

There's quite a few things that eno solves (there's only so much space on a
frontpage, sorry), but if you want one of the more prominent ones: It's
considerably hard to win over users without technical background to switch to
secure, statically generated content solutions when the most prominent format
works like this:
[http://yaml.org/spec/1.2/spec.html](http://yaml.org/spec/1.2/spec.html) I've
explained eno in 5mins to a non-technical intern who is now managing content
at a client of mine and in months I haven't heard a single question about how
eno works! User empowerment. <3

~~~
john-aj
> _What you 're seeing there is actually validation :), the lat/lng type is
> not magically inferred but instead explicitly requested by the code - if it
> were not valid it would generate a user-friendly, localized error message.
> Also the underlying document hierarchy that holds the data is validated. So
> on the contrary it is actually hard not to validate content in eno._

Please make this clear on the website! I think it’s a clever idea.

Also, this has garnered some attention on Lobste.rs [1], if you’re interested
to read the discussion there as well.

[1]:
[https://lobste.rs/s/jno6gb/eno_notation_language_libraries](https://lobste.rs/s/jno6gb/eno_notation_language_libraries)

~~~
simonrepp
Thanks for that feedback! I'll see what I can do to communicate the API type
concept better, I'm generally struggling to pack all the bandwidth of things
into the little available prominent space on the website, but eventually I
will get it right for most people I hope. :)

Also thanks for letting me know about the lobste.rs thread, I'll see that I
get invited and answer the few not yet-answered points, couldn't get to it
yesterday unfortunately amidst all the comment and issue and PR flood here and
on github. ;)

------
teddyh

      # 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

~~~
simonrepp
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. :)

~~~
jacobevelyn
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](https://github.com/JacobEvelyn/friends)

~~~
simonrepp
Thanks for the encouragement!

I like the philosophy of friends! (even though I too don't need quite the
power of it (yet). ;))

------
jmaa
What non-indented markup languages gain by avoiding indentation, they lose in
succinctness. What is the difference between a section, a list, and a field
set? When would I use one instead of another?

If your aim is data representation, why not go for JSON, Lua table-notation or
S-expressions? These do not need different syntax for sections, lists or field
sets, but have very clear syntax for a few primary data structures, which you
can them compose however you want.

~~~
simonrepp
section vs. list in eno is like object vs. array in JSON - you need both.

eno has neither indentation nor closing tags of any sort, that means if you
use a section to group some values, you need to start another section to end
the previous one (no closing tags!), that's why there are fieldsets, which
allow short groupings that _automatically_ end with the next
field/list/fieldset.

I share your opinion that a single syntax would be the ideal thing, but not
having closing tags (which keeps the language simple and fast to write)
required a trade-off in the language design to be made.

Why not JSON, Lua table-notation or S-expressions? Because the prime design
goal was to achieve greatest possible simplicity and accessibility - almost
_anyone_ should be able to use it, no matter the background. If possible I
would have wanted eno to be even more reduced and simple, but at some point
you have to draw a line too, otherwise you end up with a toy, and then you
won't ever get adoption by devs either. So this is why eno ... :) Thanks for
your question!

------
tosh
A 50s demo video of autocompletion in Atom powered by introspection:

[https://eno-lang.org/resources/introspection.mp4](https://eno-
lang.org/resources/introspection.mp4)

~~~
qubex
Mention of atom and the fifties caused me to hallucinate Fallout-style
atompunk/Jetsons retrofuturism.

~~~
simonrepp
Associated fifties right away too, although not that colorful :)

------
NoahTheDuke
This looks like a cool project, but I don't know how I feel about the non-
primitive type loaders. Date strings, email addresses, urls, colors, and lat-
long are hard problems, and trying to handle them in the spec is a misstep.
Leave the complex loaders out, strive to handle perfectly just the core list
of primitives, and let devs write their own email or url parsers. (Who is
asking for lat-long parsing?)

(Seriously, the email parser doesn't match most of the Examples [0] on the
Wikipedia page about email validation. Don't use regex to validate unless
you're gonna write `/.* @.*/`.)

[0]:
[https://en.wikipedia.org/wiki/Email_address#Examples](https://en.wikipedia.org/wiki/Email_address#Examples)

~~~
simonrepp
I fully agree with your assessment - eno allows arbitrary types, therefore if
and to what extent non-primitive type loaders should be included as core
functionality needs to be thoroughly considered and negotiated soon. I
included non-primitive loaders (also the exotic lat/lng ;)) to (a) show that
this is a possibility and (b) get hands-on insight how well this works in real
world usage. (in short: I love it so far, but I'd love to hear other
experiences!) It took months to get the whole ecosystem jump-started as a one
man show, so that's why some loaders are ... pragmatically coded, you're of
course right on that, although admittedly I had no idea the email spec was
_that_ complex, thanks for making me aware. ;)

------
mstijak
This reminds me of an old project of mine called NIML - Non-Indented Markup
Language.

[http://mstijak.github.io/niml/index.html](http://mstijak.github.io/niml/index.html)

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

------
FreeFull
Is there a comparison to TOML?

~~~
simonrepp
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.

------
bassman9000
I waiting for the day XML becomes hip again. Then we'll be able to rebuild all
XML parsing tools.

------
nautilus12
Thought this was about hammocks :(

~~~
simonrepp
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 :)

------
IshKebab
Well, it doesn't look particularly intuitive, but it can't be worse than YAML.

------
moomin
INI files 2.0

~~~
wongarsu
I agree, the feature set seems largely inspired by INI files. It seems in
general there is a large demand for a more flexible (and less ugly) version of
INI files.

------
sleepybrett
JAMD (just another Markdown)

------
wemdyjreichert
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.

