Type-safely embed DSLs directly into Java
1–10 of 27 posts
Re: Type-safely embed DSLs directly into Java
#2The graphql example is not the greatest, but I would personally use GQL Code Generator to create a little strongy typed client for all your .graphql files:
https://graphql-code-generator.com/docs/plugins/java
Not sure if there's a strong use-case in general here. Even Groovy code, which is a popular choice for JVM DSL languages, has pretty excellent stub generation.
Re: Type-safely embed DSLs directly into Java
#3The graphql example is not the greatest, but I would personally use GQL Code Generator to create a little strongy typed client for all your .graphql files: https://graphql-code-generator.com/docs/plugins/java Not sure if there's a strong use-case in general here. Even Groovy code, which is a popular choice for JVM DSL languages, has pretty excellent stub generation.
But the main idea with this is to avoid the pitfalls of conventional code generation such as GQL Code Generator. See "The Big Picture"[1] in the core docs.
[1] https://github.com/manifold-systems/manifold/tree/master/man...
Re: Type-safely embed DSLs directly into Java
#4The graphql example is not the greatest, but I would personally use GQL Code Generator to create a little strongy typed client for all your .graphql files: https://graphql-code-generator.com/docs/plugins/java Not sure if there's a strong use-case in general here. Even Groovy code, which is a popular choice for JVM DSL languages, has pretty excellent stub generation.
But the main idea with this is to avoid the pitfalls of conventional code generation such as GQL Code Generator. See "The Big Picture"[1] in the core docs. [1] https://github.com/manifold-systems/manifold/tree/master/man...
When I see "no code on disk" I see that as a downside. What happens when this generated code has a bug? How do I set a break point in this code? How do I see the code to know what it is doing?
Extending the compiler is great... until it isn't. Imagine a feature in java the language not working correctly due to a compiler bug. Debugging or working around this issue could be very difficult. With compiler extensions, you are now widening the opportunity for this type of bug to occur.
More principled code generation systems like Racket's macro system do in fact let you expand the code to see what's generated while avoiding having a separate build step, and even have a macro debugger for interactive debugging. Mainstream languages have a ways to go before we get this kind of tooling for language extension frameworks. Until then, I think I prefer having a separate build step with on-disk, visible, and debug-able code.
Re: Type-safely embed DSLs directly into Java
#5Earlier quoted context omitted.
But the main idea with this is to avoid the pitfalls of conventional code generation such as GQL Code Generator. See "The Big Picture"[1] in the core docs. [1] https://github.com/manifold-systems/manifold/tree/master/man...
When I see "no code on disk" I see that as a downside. What happens when this generated code has a bug? How do I set a break point in this code? How do I see the code to know what it is doing? Extending the compiler is great... until it isn't. Imagine a feature in java the language not working correctly due to a compiler bug. Debugging or working around this issue could be very difficult. With compiler extensions, yo…
> What happens when this generated code has a bug?
That's a bug in the generator and should be treated as such. Patch or throw out the generator. It's not sustainable to review and patch "generated code", because then it's just "code".
The only reason I need code-on-disk is if I need to generate bindings into multiple languages.
Re: Type-safely embed DSLs directly into Java
#6Earlier quoted context omitted.
But the main idea with this is to avoid the pitfalls of conventional code generation such as GQL Code Generator. See "The Big Picture"[1] in the core docs. [1] https://github.com/manifold-systems/manifold/tree/master/man...
When I see "no code on disk" I see that as a downside. What happens when this generated code has a bug? How do I set a break point in this code? How do I see the code to know what it is doing? Extending the compiler is great... until it isn't. Imagine a feature in java the language not working correctly due to a compiler bug. Debugging or working around this issue could be very difficult. With compiler extensions, yo…
I definitely agree; the author clearly thought no on-disk produced code was a feature, but it makes me nervous. Similarly, the author then goes on to say how the framework supports circular dependencies between manifolds, or manifolds that each modify one another's types ... and I immediately think that will create debugging nightmares.
Re: Type-safely embed DSLs directly into Java
#7Earlier quoted context omitted.
But the main idea with this is to avoid the pitfalls of conventional code generation such as GQL Code Generator. See "The Big Picture"[1] in the core docs. [1] https://github.com/manifold-systems/manifold/tree/master/man...
When I see "no code on disk" I see that as a downside. What happens when this generated code has a bug? How do I set a break point in this code? How do I see the code to know what it is doing? Extending the compiler is great... until it isn't. Imagine a feature in java the language not working correctly due to a compiler bug. Debugging or working around this issue could be very difficult. With compiler extensions, yo…
You can see the generated code in the IDE via Edit | View Java Source when a resource is selected. And you can debug it as well. Sort of the best of both worlds. What makes Manifold most interesting, however, is the entire dev experience when used in the IDE. This short screencast demonstrates some of that: http://manifold.systems/images/graphql.mp4
Re: Type-safely embed DSLs directly into Java
#8Earlier quoted context omitted.
When I see "no code on disk" I see that as a downside. What happens when this generated code has a bug? How do I set a break point in this code? How do I see the code to know what it is doing? Extending the compiler is great... until it isn't. Imagine a feature in java the language not working correctly due to a compiler bug. Debugging or working around this issue could be very difficult. With compiler extensions, yo…
> What happens when this generated code has a bug? That's a bug in the generator and should be treated as such. Patch or throw out the generator. It's not sustainable to review and patch "generated code", because then it's just "code". The only reason I need code-on-disk is if I need to generate bindings into multiple languages.
But looking at the generated code, in the specific context where it was produced, is possibly a key step to understanding the bug in the generator. How else are you going to understand how to patch it, or whether the it's bad enough that you have to "throw out the generator" (if you can afford to do that)?
Re: Type-safely embed DSLs directly into Java
#9I'm curious how this works under the hood, looks like it's added as an annotation processor, and the DSL is embedded in specially formatted comments, but not in annotations. This implies to me the annotation processor is processing the comments in a source file? I did not know annotation processors could do this! Also implies comments carry through to the compiled .class files which I did not think they did either (runtime bytedcode weaving)?
Re: Type-safely embed DSLs directly into Java
#10Earlier quoted context omitted.
When I see "no code on disk" I see that as a downside. What happens when this generated code has a bug? How do I set a break point in this code? How do I see the code to know what it is doing? Extending the compiler is great... until it isn't. Imagine a feature in java the language not working correctly due to a compiler bug. Debugging or working around this issue could be very difficult. With compiler extensions, yo…
I definitely agree; the author clearly thought no on-disk produced code was a feature, but it makes me nervous. Similarly, the author then goes on to say how the framework supports circular dependencies between manifolds, or manifolds that each modify one another's types ... and I immediately think that will create debugging nightmares.
In most cases, the devs that should be concerned about debugging generated code are the authors of the generator. If there are bugs in released code, consumers of the API should file against them. In any respect, as I mentioned in a previous comment when a resource is selected you can view its generated source via Edit | View Java Source.