Flex
harc.ycr.org
harc.ycr.org
Also, I've previously looked into Ometa, the predecessor of Ohm and I found it to be the possibly cleanest parsing solution available. Check it out if you ever feel parsing-monious.
[1] http://blog.databigbang.com/parsing-s-expressions-in-c-using...
How do I see any of these actually in action? Do they work?
Will they be released at some point or are they proof of concept work that will never see the light of day beyond an academic paper?
Though I also understand that they probably want to work as deeply as possible on these things without the distraction of an open source/contributor community.
http://worrydream.com/LearnableProgramming/
good ideas live a lot longer than code.
If Flex was a business with a trademark this would count as infringement without a doubt. Same type of product, same name.
https://blogs.adobe.com/flex/2012/08/flex-trademark-assigned...
In fact, I wish more projects based on Ometa and Ohm allowed this so there's a better chance they can bootstrap each other. Of course, some semantics might still be missing but at least parsing would work.
So right now, I can write the grammar G1 for a language L1 in Ohm and parse strings written in L1 by putting them in examples.
If L1 is a language for describing grammars (such as a Ohm with a slightly different syntax), one of the "example" could be the grammar G2 for a language L2. But then I can't give the editor examples of L2 to be parsed!
(Of course if L1 has extra semantics instead of just syntax, it wouldn't be easy to change anyway, except by editing the Ohm Editor's source.)
A sample use case:
G2 is something like this:
https://github.com/asrp/pymetaterp/blob/master/pymetaterp/bo...
The example/input written in L2 that I want to give it is something like this
https://github.com/asrp/pymetaterp/blob/master/pymetaterp/py...
I could of course, rewrite this input in Ohm's grammar just so I can visualize the parse in the Ohm editor but it would be faster if I only needed to write G1 (that is, G2 translated to Ohm but matching the same language as L2=L1) and make minor adjustments to the input.
A full translation of this "input" to Ohm would also make it harder for me to port bugs fixed in the Ohm version back to the original version.
The next step would be to make this input the grammar G3 and give it inputs which can be visualized in the editor.
I'm not sure if you intend to have the Ohm editor used like this or not though.
Very nice project, by the way. I really like how you show the parts of the inputs that matches, with the option of expanding rules.
Have used it in the past, would use it again.
> Like its older sibling OMeta, Ohm supports object-oriented grammar extension. One thing that distinguishes Ohm from other parsing tools is that it completely separates grammars from semantic actions. In Ohm, a grammar defines a language, and semantic actions specify what to do with valid inputs in that language. Semantic actions are written in the host language -- e.g., for Ohm/JS, the host language is JavaScript. Ohm grammars, on the other hand, work without modification in any host language. This separation improves modularity, and makes both grammars and semantic actions easier to read and understand.
You can read all about it here: https://github.com/harc/ohm
It reminds me of some previous roles where my key task was "translating" abstracted information and creating interfaces for less technical audiences to interact with technical information.
Seriously, thanks for the encouragement. I'm really hoping the latest version will be good enough to share at long last.
edit: the answer from his paper: "Typical applications are built from at least three distinct technology stacks: a database, a programming language, and a UI framework. Each of these technologies has its own semantics, and much of the complexity of application programming stems from the need to glue them together. Chorus instead provides a single unified model built upon our prior work on Subtext (Edwards 2004-2014). Our statically typed tree structures are effectively databases: the types are schemas, collections serve as tables, and references serve as relationships. All data is persistent, and all execution is performed in concurrent transactions."
Do you know of others?
Together with Brett Victor his Inventing on Principle, I usually show this https://vimeo.com/140738254 to people when explaining my daily existence and the unfairness of it (as in; some of us have these ideas and yet, my CPU cores + memory are overloaded doing trivial db queries to do code completion and rendering HTML because that is what we write GUI's including code editors in now :).
[0] https://web-beta.archive.org/web/20130810132017/coherence-la...
What the hell does this even mean? Usually I don't mind marketing-speak at all, but this is literally comical. I was expecting some art or creative related .. something. What I got was tools for building programming languages.
I agree with the other commenters, though, that the statement of vision is unclear; the meaning of it is hard to pin down to something concrete. What the Flex group is actually trying to do remains ambiguous after reading it. If it matters that people who run across that statement without other context can understand it, you may be leaving value on the table that could be captured with a more intelligible version of it.
> At flex we believe that good interfaces should empower users. We try to blur the line between simply using a user-interface and being a programmer. We do this by thinking about new ways to intuitively represent programming concepts, and endeavor to provide tools that have a smooth learning curve that takes you all the way from just being a user to being a programmer.
Unless I'm horribly misunderstanding your goals. Which really I probably am because you're horribly vague.
I think their ideas go beyond just making programming more accessible (your summary), but more along the lines of "using computers as instruments of enriching thinking".
One of the projects (Chorus) even specifically mentions and rejects programming as a problem-solving tool (for that specific domain of problems), instead opting for thought-process enhancement from the other side, basically making spreadsheets on steroids.
Introducing a parser generator workflow to a project that already has access to Ruby is almost certainly Doing It Wrong. Every time I've tried it, I ended up scrapping it and just did it in Ruby with a DSL. You're going to want to access and control whatever it is you're writing with Ruby, so why not just stay in the language?
I guess if you're coding in something really dull like Go or Java, you can easily get to a point to where the developer experience is constrained by the language so you need a new one.
I've made many parsers in my career. I even wrote a SIP parser using antlr which I'm particularly proud of. There are lots of places where you need to parse.
So my impression is that in general, parser generators are underused, not overused.
Anything that encourages people to use parser generators is IMHO a good thing. Ideally, parser generators should become as ubiquitous as template languages, with an similar race between libraries for ease of use, suitability for the most common cases, and lower entry barrier.
I think I really am just really spoiled by Ruby.
But that's exactly my point: You can do that for template systems, but not for parser generators. (Well, you can, but your choices aren't nearly as nice.)
It's easy to see what role a template system can play in such a project, much harder, for me anyway, to see what one would actually use parsing for outside of the rarefied context of building a new general purpose programming language. Anything you'd want to parse, there are already going to be parsers written. Just pick one and go.
If you're just screwing around, by all means knock yourself out. But in all the real work serving real humans I've ever done, I have never been able to justify building out a parsing system. I can't even look at a regular expression without wanting to rip it out.
I can see if you're maintaining the library that, say, does TOML parsing for Lua. But that's not in the realm of the everyday.
Whatever you need out of a configuration file format, it's probably already been done, and someone else has already done the hard work of specifying the language and writing a parser for it, all you have to do is hook into it.