simonrepp

6 ms·

1.
A novel technological approach to vector graphics (“Vector Graphics Complexes”)(kickstarter.com)
23 points by simonrepp 5y ago|25 comments
2.
by simonrepp 7y ago
You are correct! The thinking behind this is that for the majority of file-based configuration and content usecases the expected types are fixed and known beforehand already - ergo it makes more sense that a developer has to specify once
3.
by simonrepp 7y ago
tl;dr: Another alternative to YAML (among many great others), this one designed and developed by me: https://eno-lang.org/ I've been doing a lot of research and development on language design for file-based content (e.
4.
by simonrepp 8y ago
Very cool! If it succeeds and you'd like to publish any part of it at some point, I'll gladly pick it up for a collection of case studies on eno-lang.org, just let me know then. Meanwhile, I've added a commmunity projects sec
5.
by simonrepp 8y ago
Awesome, very happy to see this. Now I'm curious - are you putting this to use somewhere already? Or is it for the time being "just" an experiment for the joy of implementing in itself? :) Thanks for sharing!
6.
by simonrepp 8y ago
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 applic
7.
Show HN: Enophp – PHP library for the eno notation language
17 points by simonrepp 8y ago|2 comments
8.
by simonrepp 8y ago
On npm that's in fact already covered, scrutinize the list https://www.npmjs.com/search?q=eno :)
9.
by simonrepp 8y ago
That road (C or Rust parsing core through bindings) will likely be taken, but for the initial development and jump-starting the ecosystem it was important for me to start with implementations that can be quickly experimented with and iterat
10.
by simonrepp 8y ago
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 w
11.
by simonrepp 8y ago
Associated fifties right away too, although not that colorful :)
12.
by simonrepp 8y ago
Thanks for the encouragement! I like the philosophy of friends! (even though I too don't need quite the power of it (yet). ;))
13.
by simonrepp 8y ago
I appreciate the input :) but the thing is that the typing concept in eno as it is now is essentially what makes eno eno. Every application that uses eno decides for itself what types it supports and requires, and that in turn is how eno ma
14.
by simonrepp 8y ago
Well spotted, good question! It's also been asked in another thread on HN, I'm quoting myself here: "eno has neither indentation nor closing tags of any sort, that means if you use a section to group some values, you need to
15.
by simonrepp 8y ago
Yes through sections ! See https://eno-lang.org/introduction/ . You can nest as deeply as you want and multiple sections on the same level automatically turn into a list of sections. For just a list of flat dictionarie
16.
by simonrepp 8y ago
ruamel.yaml in python does that to a certain degree from what I've read, you might want to check it out if yaml is ok for your usecase! ( https://yaml.readthedocs.io/en/latest/ ) I've given this some thoug
17.
by simonrepp 8y ago
Sure! Cultural research = notoriously underfunded, so although they have and rely on a relational database that holds their data (previously Postgres) the cost and effort associated with maintaining and extending the system is pretty high.
18.
by simonrepp 8y ago
Hey, first off thanks! :) 1a) because faster was only one aspect, it also needed to be easier, even more pressingly that in fact. 1b) see answer by other poster (thanks!) 2) Not whitespace sensitive, no way to enter wrong types through synt
19.
by simonrepp 8y ago
Regarding types check out https://eno-lang.org/javascript/#loaders - basically eno allows arbitrary types on the language level and provides loaders for all primitive types and currently also a small set of non-primiti
20.
by simonrepp 8y ago
One of the design conderations was and is that the format is very strict (and that way predictable), but at the same time as helpful as possible in identifying, communicating and resolving issues. To that end all error messages that can occ
21.
by simonrepp 8y ago
From what I saw, I think for at least a few parsers this might be the case because they are built on generated parser code, and it's just easy to run into unfavorable bits and pieces in the output that way, which can drag down performa
22.
by simonrepp 8y ago
Conveying what types to enter is not an eno-specific problem, as a user without schema or code access you don't know which types a blank YAML/TOML file expects either! Asides the absolutely valid meta solutions (e.g. in-file comme
23.
by simonrepp 8y ago
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 wi
24.
by simonrepp 8y ago
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 A
25.
by simonrepp 8y ago
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
26.
by simonrepp 8y ago
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
27.
by simonrepp 8y ago
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-primi
28.
by simonrepp 8y ago
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
29.
by simonrepp 8y ago
Pretty cool, I remember coming across it during research for eno actually! small internet :)
30.
by simonrepp 8y ago
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 :)

More ›