
Show HN: Enophp – PHP library for the eno notation language - simonrepp
The eno notation language[1] now also has an official PHP library:<p><a href="https:&#x2F;&#x2F;eno-lang.org&#x2F;php&#x2F;" rel="nofollow">https:&#x2F;&#x2F;eno-lang.org&#x2F;php&#x2F;</a><p>It features the same API and featureset as the JavaScript &#x2F; Python &#x2F; Ruby libraries, and also comes with the same extensive testsuite that has been growing during implementation of the other libraries, with already well over 90% coverage at the time of release.<p>Happy to hear your feedback and answer any questions!<p>[1] A user-friendly format for file-based content: <a href="https:&#x2F;&#x2F;eno-lang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;eno-lang.org&#x2F;</a>
======
deathanatos
I'm curious what data types exist in this? The (loose) specification says,

> _In eno there is no type differentiation on the language level, there are
> only textual representations ( "strings"), which are always referred to as
> values._

Yet the example seems to show floating points being parsed as such. While I
can see allowing the implementation some leeway — they may not all have the
same notion of integral types, for example, Python & JS parse JSON "3"
"differently" — Python as an int, JSON as a "Number" (IEEE floating point) —
this seems more vague than you'd want. But that could just be due to the spec
still coming along.

Is there anything you think Eno accomplishes over TOML (my present choice when
dealing w/ configuration files, great for humans) or YAML (arbitrary but more
complex data structures that still need to be touched or input by a human;
more complex, but generally still human usable) or JSON/CBOR (machine to
machine interchange of loosely typed data)? (I list them all since I presently
"use" them all for slightly different choices.)

And +1 for having ABNF. (Even if rough.) And I appreciate that it is specified
in terms of Unicode code points, which is very appropriate IMO for a textual
language.

~~~
simonrepp
The design principle for types in eno is that the _language_ itself has no
notion of types, there are only plain textual representations. Meaning, types
are _never inferred_ from a document. Instead, when parsing an eno document
the _application_ explicitly requests the type it expects for each field,
thereby validating the document during parsing. From the perspective of the
_libraries_ for parsing eno, types are defined as simple functions/closures (I
call them "loaders"), that basically take the string value from a field and
validate/transform and return it as the proper type. Some of these loaders
currently ship with the libraries for convenience (int, float, datetime, etc.
- this is not a hard specification though, just a sensible predefined
toolbox), but there can be any number of types, whichever types an application
needs in addition can be defined and used on the fly.

This is the main point that differentiates eno from almost all TOML/YAML/JSON
like formats, and the implication of this is that eno is extremly simple and
very accessible for non-technical users (so far all casestudies have verified
this to be true) and a highly reliable data source for developers, but it also
comes at the cost of losing generic de/serializability, so it depends on the
usecase whether eno should be chosen over other formats. :)

There are also some other things that are unique to eno (e.g. all parser and
validation error messages are fully localized and in user-friendly humanized
language) or painfully missing in some other formats (e.g. having any number
of "multiline string" fields that don't hang indented against an invisible
left margin somewhere in the document), feel free to explore further on the
website if you're curious!

Thanks for your interest and the feedback on the ABNF (much appreciated!),
hope I could clarify things a bit. :)

