Yeah, I tend to agree. I tried reading it even more closely, and here's how I'm interpreting it:
* In a normal compiler, you have the front-end which generates intermediate code in a pseudo-assembly language, and you have the back end that compiles that intermediate code into assembly language (or into JVM or CLR or even JavaScript, these days...)
* In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware.
I don't know if you're familiar with "shader" languages (for OpenGL and DirectX and similar), but they're written in a syntax that looks very much like C. It's not precisely C, but it looks a whole lot like C -- but every statement effectively generates machine code directly, and they get executed in parallel. So if you're writing a pixel shader that makes everything more red, you'd write a statement like (pseudocode):
output.r += 10;
...and when it drew the texture or polygon to the screen, it would execute your code once for each pixel.
In AnyDSL, it looks like the top level language is very much like a normal (functional) language. That language gets "compiled" into an intermediate abstraction language (like the one using @iterate call), and the final "compilation" step is like the shader language, in that it's letting you define a target-specific implementation, which could include vector functions or pixel shaders or whatever.
If this were C, then the second level would be internal to the compiler and completely opaque, and the final level would be the compiler backend+libraries, which might have calls to implement vector math. If you imagine lifting those backend libraries up into the same compiler, where the libraries are written in a similar language syntax, you can imagine that they can do a lot more to optimize the result, because more of the code gets built at the same time, and a lot of intermediate states can be eliminated at compile time.
But yes, it still feels fundamentally like a compiler. Only a compiler where you can't just link in existing C-based libraries, because then it wouldn't be able to do its magic. So you therefore need to reinvent all the wheels?
I'm wondering how this compares to Xtext[1], which is another framework for developing domain specific languages. Xtext feels more approachable to me, but maybe that's because there appears to be a lot more documentation and tooling.
For example, the docs on Xtext's grammar language[2] seem very intuitive to me, even though I'm not experienced in compilers or language design. I don't have quite the same intuition when looking over the AnyDSL docs[3]. Maybe the Xtext docs are just more goal-oriented, i.e. "Five simple steps to your first language".
Xtext and AnyDSL have very different goals. Xtext is mostly about Syntax and IDE-Support, while AnyDSL is about compilation. With Xtext you'll get support for defining the grammar of your language, but you'll write your own compiler for your DSL - the DSL is "deeply-embedded" in the host language Java, that is: represented as a Java datastructure. In AnyDSL, you don't have any support for custom syntax - all your DSLs are basically just "libraries"/types/functions in the host language Impala - a "shallow" embedding. Java examples of shallow embedding are most "fluent interface" libraries, e.g. jOOQ[1].
This has the benefit that you don't need to know about compiler tech to implement your DSL. However, a domain-specific compiler can optimize using domain-specific knowledge and potentially generate faster code. For this reason AnyDSL/Impala provides online partial evaluation with the '@' operator, which aggressively specializes functions and evaluates at compile time. With the right DSL abstractions, this can result in generated code that is as fast as hand-tuned code.
For a more complete view of the relation between partial evaluation and DSL embedding, have a look at the GPCE'15 paper[2].
We totally agree that the website and documentation (there is some in the github wikis) is lacking at the moment and we're working on them. However, AnyDSL is still a young research project.
I don't know what people are used to these days, but looking at the diagram in the post, if this is what author calls a DSL, then they haven't seen a DSL in their life before. What I see in the image is bog standard use of procedures to abstract code away. Does the word "DSL" these days mean "use functions"?
That "Machine Expert" snipped still looks way too much like a programming language. I fail to see the advantage over rolling a DSL with ANTLR which is reasonably intuitive (I'm assuming this is meant for external DSLs) or better yet using a language workbench like Xtext (which also gives you an Eclipse-IDE for your DSL "for free").
I guess the more the merrier but the linked website doesn't really showcase the tool very well (imo). For quick prototyping I'll probably stick with Prolog DCGs :)
In AnyDSL, Impala is a host language for shallow-embedded DSLs. No parser generators/grammar required/needed as that is not the point.
From the last paragraph of the overview section: "The DSL developer just reuses Impala's infrastructure (lexer, parser, semantic analysis, and code generator). He does not need to develop his own front-end."
We should probably emphasise that and restructure the introduction text.
I think the point is that the machine expert part (which essentially implements an iteration construct) can be provided by a target architecture specific library.
[+] [-] al2o3cr|9 years ago|reply
[+] [-] SomeCallMeTim|9 years ago|reply
* In a normal compiler, you have the front-end which generates intermediate code in a pseudo-assembly language, and you have the back end that compiles that intermediate code into assembly language (or into JVM or CLR or even JavaScript, these days...)
* In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware.
I don't know if you're familiar with "shader" languages (for OpenGL and DirectX and similar), but they're written in a syntax that looks very much like C. It's not precisely C, but it looks a whole lot like C -- but every statement effectively generates machine code directly, and they get executed in parallel. So if you're writing a pixel shader that makes everything more red, you'd write a statement like (pseudocode):
...and when it drew the texture or polygon to the screen, it would execute your code once for each pixel.In AnyDSL, it looks like the top level language is very much like a normal (functional) language. That language gets "compiled" into an intermediate abstraction language (like the one using @iterate call), and the final "compilation" step is like the shader language, in that it's letting you define a target-specific implementation, which could include vector functions or pixel shaders or whatever.
If this were C, then the second level would be internal to the compiler and completely opaque, and the final level would be the compiler backend+libraries, which might have calls to implement vector math. If you imagine lifting those backend libraries up into the same compiler, where the libraries are written in a similar language syntax, you can imagine that they can do a lot more to optimize the result, because more of the code gets built at the same time, and a lot of intermediate states can be eliminated at compile time.
But yes, it still feels fundamentally like a compiler. Only a compiler where you can't just link in existing C-based libraries, because then it wouldn't be able to do its magic. So you therefore need to reinvent all the wheels?
[+] [-] fohara|9 years ago|reply
For example, the docs on Xtext's grammar language[2] seem very intuitive to me, even though I'm not experienced in compilers or language design. I don't have quite the same intuition when looking over the AnyDSL docs[3]. Maybe the Xtext docs are just more goal-oriented, i.e. "Five simple steps to your first language".
[1] https://eclipse.org/Xtext/index.html [2] https://eclipse.org/Xtext/documentation/301_grammarlanguage.... [3] https://github.com/AnyDSL/anydsl/wiki/Tutorial
[+] [-] kagebe|9 years ago|reply
This has the benefit that you don't need to know about compiler tech to implement your DSL. However, a domain-specific compiler can optimize using domain-specific knowledge and potentially generate faster code. For this reason AnyDSL/Impala provides online partial evaluation with the '@' operator, which aggressively specializes functions and evaluates at compile time. With the right DSL abstractions, this can result in generated code that is as fast as hand-tuned code.
For a more complete view of the relation between partial evaluation and DSL embedding, have a look at the GPCE'15 paper[2].
We totally agree that the website and documentation (there is some in the github wikis) is lacking at the moment and we're working on them. However, AnyDSL is still a young research project.
[1] http://www.jooq.org/doc/3.9/manual/sql-building/sql-statemen... [2] http://compilers.cs.uni-saarland.de/papers/gpce15.pdf
[+] [-] d--b|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] TeMPOraL|9 years ago|reply
An actual DSL looks like this:
https://www.irif.fr/~jch/software/cl-yacc/cl-yacc.html
(scroll down to "define-parser")
It enables domain-specific abstractions in code. It's not about just naming your functions right.
[+] [-] hashkb|9 years ago|reply
[+] [-] kriro|9 years ago|reply
I guess the more the merrier but the linked website doesn't really showcase the tool very well (imo). For quick prototyping I'll probably stick with Prolog DCGs :)
[+] [-] kagebe|9 years ago|reply
From the last paragraph of the overview section: "The DSL developer just reuses Impala's infrastructure (lexer, parser, semantic analysis, and code generator). He does not need to develop his own front-end."
We should probably emphasise that and restructure the introduction text.
[+] [-] sddfd|9 years ago|reply
[+] [-] notjack|9 years ago|reply
[+] [-] miguelrochefort|9 years ago|reply
[+] [-] anentropic|9 years ago|reply
[+] [-] matt4077|9 years ago|reply
It appears that the levels of abstraction are solved a bit cleaner, but also not fundamentally different.
(no expert, though. Maybe someone can translate it)
[+] [-] sddfd|9 years ago|reply
I like that iteration constructs, for example, can be implemented simply as higher-order functions.
This way, the compiler already knows how to deal with them and does not require additional definitions regarding parsing or code generation.
[+] [-] HakubJozak|9 years ago|reply