Show HN: Monocle – bidirectional code generation library

Delete the post and repost it and I'll vote it up.

A friend who did some work on the project said it reminded him of lenses in functional programming. Since the company name was Snooty Software, he suggested calling the library Monocle, which seems appropriate :-)

If there is an existing parser, like for a lot of templating languages, this is can be done, since templates are parsed to ruby in a separate step. Otherwise, it would require creating a ruby-based parser for a language, or porting the concepts to that language.

For regular languages (not templating), if they have good tooling for converting to/from AST it's quite possible. The codebase isn't very flexible right now, but it's also not very big. In fact monocle itself is less than 900 lines of code.

I'm not sure if it makes sense for monocle to support multiple languages, or if each language should have its own port. Someone writing monocles in a specific language probably wants to do custom scripting in the language they're used to.

Templating languages are trickier, because they usually don't have great tooling. In fact, we wrote our own tooling to convert from ERB to builder (a template system where you generate HTML through Ruby methods) and back. So for any templating language you would probably write a tool that converts from that language to builder, and back.

On the other hand, ERB is about as free-form as it gets. Templating languages that are more strict are probably easier to add. For more info on how ERB is supported, I wrote another post that goes into detail: https://blog.luitjes.it/posts/erb2builder/

Yep, visual cafe was interesting. I was used to Delphi and I didn’t understand why cafe was so much worse.

I remember! The times where RAD was the next big thing.

I only used it after it was "remixed" into JBuilder. I actually used Visual Age from IBM, which I reckon was similar to Visual Cafe.

Mito looks interesting! Regarding the sin, I don't think it entirely applies here, unless I'm misunderstanding you - I'm not super familiar with transpilers.

In this case the template is also ruby code, but with placeholders for the values. So both the template and the input get parsed into ASTs, then both of them are recursively walked and compared on the fly. During that walk it builds up the data structure with initial values.

In the code generation direction it walks one AST and does lookups and rewrites with values from the values.

Does that make sense?

Inflex (https://inflex.io/) does this bidirectional editing: you can edit any data structure as either a graphical object or the associated code, and the other one updates appropriately. (See e.g. https://discourse.inflex.io/t/how-to-make-and-access-a-recor...)

As for the problem of which things of a data frame are generated from a formula and which are from normal form, Inflex compares the structure with the AST of the source, making it easy to tell that [{foo: ...}] are normal form and so editable graphically, whereas xs.filter(..) is not. The neat thing is you can still edit formulae that are deep within a normal form nested structure.

It helps that Inflex doesn’t have syntactic sugar, what’s parsed is what is in the final AST. It also has a symbolic evaluator, somewhat, so it’s fine to have a list of functions for example and edit the list. The evaluator produces the same AST, rather than an alien format.

This bidirectionality also applies to rich text editors. (https://mobile.twitter.com/InflexHQ/status/14923564133263360...)

Mito has the advantage of being a familiar language and ecosystem, but Python itself has a traditional runtime, it’s imperative and not expression oriented, and lacks sound static type information, so it’s inherently more difficult to achieve some things with it that are easier with a typed pure functional language, especially a custom one.

Wow, those projects look really cool! There's definitely some overlap there.

I'd love to see it used for other projects/languages. At the bottom of the post I put a bunch of ideas that I'd integrate with it, if I had more time.

OP here, we actually considered using the GetPut/Putget/CreateGet terminology during a refactor, but it didn't seem to map perfectly. As I understand it, with lenses you generally define them through a DSL. Monocle lets you define them through example code. The goal was to make it as easy as possible for a decent programmer to write a lot of them. I couldn't find that type abstraction in academic work, but it's entirely possible I didn't use the right search terms.

https://en.wikipedia.org/wiki/Round-trip_engineering :

> Round-trip engineering (RTE) is a functionality of software development tools that synchronizes two or more related software artifacts, such as, source code, models, configuration files, and even documentation.[1] The need for round-trip engineering arises when the same information is present in multiple artifacts and therefore an inconsistency may occur if not all artifacts are consistently updated to reflect a given change. For example, some piece of information was added to/changed in only one artifact and, as a result, it became missing in/inconsistent with the other artifacts.

Source-to-source_compiler > See also > #ROSE, : https://en.wikipedia.org/wiki/Source-to-source_compiler

It is a compiler/decompiler, data models is just a simple example. There are also examples of generating and parsing controllers, views, schema and route files. But you can define your own templates, so you can parse/generate pretty much anything that has conforms to a common structure.

Yeah, bidirectional code gen for no-code tools was our use case too (there's a demo video in the post if you're interested). I saw a bidirectional no-code platform called Vision X the other day, people are definitely working on it. Are the prototypes you worked on online somewhere? It sounds interesting!

There are a bunch of ideas for dev tools in the original post. For example if you integrate with linters, you could define more complex code smells without all the AST juggling. Upgrading rails apps (or other frameworks that have a similarly well-defined structure) to new versions might work, by defining monocles for old the old and new version.

I use a mixed approach for OpenAPI, but not bidirectional.

I have OpenAPI pieces generated from my Go source code (comment, types, function signatures) as JSON.

I also have a manually-edited master YAML document that refers to generated bits via $ref links.

I then use openapi-preprocessor [1] (disclaimer: I wrote it) to produce a final openapi.json file which is committed in the repo.

When I want to extend the API in a spec-first process, I can add the new routes manually in the YAML file. When I do the implementation I replace the manual bits by the generated one when they are ready. When committing I can check the diff of openapi.json to verify I'm not losing in the process.

[1] https://github.com/dolmen-go/openapi-preprocessor