Maybe the most incredible part – did Claude write a recursive descent parser from scratch for this? https://github.com/enspirit/elo/blob/9f07fefcdf65c169089f123... Not that it's super complex, but I'm surprised it didn't pick up an npm package. I wrote tarsec[1] and have been eyeing ohmjs[2]. And of course nearley is a classic. [1] https://github.com/egonSchiele/tarsec [2] https://ohmjs.org [3] https://nearley.js.org
That git commit is very impressive (for Claude) Edit: Oh, I think the main dev is just using Claude to do the commits (I guess to summarise changes, etc). It does not mean that Claude wrote all that code.
Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
11–20 of 36 posts
Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#12Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#13Love the idea, but I don't think this "built for [...] non-technical users" works. All the examples were more confusing to me vs a regular programming language and definitely not accessible to non-technical users. Also, why would I want to compile to multiple languages? If I'm building a no-code platform, I won't bother supporting 3 different languages since I'm the only one seeing the code.
Yeah, P30D as presumably intuitive to non-technical users has me chuckling Also, knowing that TODAY > signup + P30D transpiles to TODAY > signup + 30.days in Ruby. Which one is more readable?
Probably TODAY + Duration({ days: 30 }) would be a better example then.
Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#14Maybe the most incredible part – did Claude write a recursive descent parser from scratch for this? https://github.com/enspirit/elo/blob/9f07fefcdf65c169089f123... Not that it's super complex, but I'm surprised it didn't pick up an npm package. I wrote tarsec[1] and have been eyeing ohmjs[2]. And of course nearley is a classic. [1] https://github.com/egonSchiele/tarsec [2] https://ohmjs.org [3] https://nearley.js.org
That git commit is very impressive (for Claude) Edit: Oh, I think the main dev is just using Claude to do the commits (I guess to summarise changes, etc). It does not mean that Claude wrote all that code.
The parser was built gradually though, with logs of increments under automated tests.
Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#15Third example on the site does not in fact compile to SQL
I need to check what we will do in that case.
Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#16This looks perfect for people who desire terseness above all. The examples make my head hurt.
Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#17I really like this idea! I wish I knew other data expression engines for js. I feel like adding filtering languages into our http endpoints is one of those forever bespoke tasks. This is probably not the right form for tackling that problem, since it is a fairly complex query language & processor and doesn't cleanly map to something we'd use in a URL query string. But it makes me miss odata a little bit. And it makes…
Might be an alternative with less complexity for a simple filtering use case.
Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#18Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#19Re: Elo – A data expression language which compiles to JavaScript, Ruby, and SQL
#20Maybe the most incredible part – did Claude write a recursive descent parser from scratch for this? https://github.com/enspirit/elo/blob/9f07fefcdf65c169089f123... Not that it's super complex, but I'm surprised it didn't pick up an npm package. I wrote tarsec[1] and have been eyeing ohmjs[2]. And of course nearley is a classic. [1] https://github.com/egonSchiele/tarsec [2] https://ohmjs.org [3] https://nearley.js.org
When I was a CS student, they seemed like magic to me as well, but later I got to revisit them for a project at work, and finally managed to understand the logic.
Imo, the biggest complexity in using them comes from how they handle operator precedence, with recursive nested expressions in the grammar, which I still don't find intuitive at all.
If you decide to hand-roll your own parser/syntax today, I recommend you look at Pratt-parsers, they are much nicer to write by hand. Modern languages (Rust, Go) , ironically are much simpler to parse, since they defined the syntax in such a way that they can be parsed unambigously by looking 1-2 tokens ahead.
And since all of them follow the same logic, AI has a ton of sources to learn from.
I'm also working on my programming language, and AI assistants have been able to generate these parsers for well over a year.