-
Notifications
You must be signed in to change notification settings - Fork 74.7k
Human Consumable Language Independent DSL #70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, 8000 you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
E.g. something similar to: NextFlow - http://www.nextflow.io/, Akka Streams - http://doc.akka.io/docs/akka-stream-and-http-experimental/2.0-M1/scala.html?_ga=1.145140147.660277140.1447135141, http://www.pothosware.com/, https://github.com/Primetalk/SynapseGrid, http://tinkerpop.incubator.apache.org/, http://noflojs.org/ though non are perfect examples. |
Also the generated language specific code can be optimised beyond hand written code. |
In the Tensorflow white paper they compare this with Halide DSL in some way. |
I think it would be better to converge on standard languages in the scientific community such as R and Python. ML is too general a field for a single DSL. |
... or we can devise our own syntax. http://www.nextflow.io/ and Akka Streams syntax seams appealing through both are internal DSL. |
Another old but somewhat similar effort: http://trad4.sourceforge.net/ |
Maybe we should wait and see if the need for a new DSL arises... Python is easy to extend into a DSL as it is. For anyone who wants to create a DSL, I recommend XText. |
XText is a good choice. I think we should aim for a DSL sooner than later before everything becomes too concrete to change without backward compatibility issues. If you look at some of the DSL, they look more nicer and more concise and also more productive. |
More productive for who? For ML professionals who have whole ecosystems in Python, for example? We should first identify our userbase for the DSL, maybe make it a part of a modeling tool rather than translate directly to code. |
@sirinath You have already suggested 8 different DSLs. That is a lot! Feel free to give a try implementing one or two if you want to! It is actually pretty easy with tensorflow. The entire computation graph can be submitted as protobuf message. All you need to do is a DSL to generate proto message. You can generate nice protobuf code for some 30+ languages and in any of them you can implement any DSL you can think off. If you do, please, share the results with the community. Others may find it useful too! |
I am not suggesting these that tensorflow should support of be in these DSLs. What I am saying is you should study the body of knowledge what is there in the DSL world and design a new DSL such that you have one code base from which you can generate any of the language specific implementation. In the case of language like Python the DSL will be translated to mix of Python with C++ bindings. In case of C++ and maybe some languages you can have the conversion to pure implantation in that language depending on the translation mechanism. E.g. if you look at Vert.x (see advance section in http://vertx.io/docs/, https://github.com/vert-x3/vertx-codegen, https://github.com/vert-x3/vertx-codetrans) they have tools in place to do translational from one implementation to another in a rather crude way. If this was in a DSL you have one maintainable code base with a cross translating cartilage to do the code conversion. This will be bug free and also more optimised than hand written code in the generated languages as you can do specific optimisation perhaps which cannot be done in a generic compiler for the language. |
Vertx.io makes it 9 suggested DSLs! You should give it a try implement at least one. Especially the "bug free" is a quality not to be found everywhere. BTW: python_op_gen.cc can help you get started and generate a lot of the code for you if you tweak it for whatever DSL you have in mind. |
Above references are just examples or projects you can learn from when designating the new DSL for tensorflow. You can just borrow the good parts from each if they are relevant in designing the new DSL. There need to be one through out DSL which is close to DAG / Dataflow concepts and which can represent among other ML algorithms. |
Not for a "program in any desired language" (you want a generic AST for that) but use caffe protobuf DSL for creating artificial neuronal networks: |
My main interest is to explore on using this as a Dataflow Computing framework than ML capabilities. |
But thanks I will check them out. |
https://github.com/ajtulloch/dnngraph is an example of a Haskell EDSL that outputs Caffe/Torch/GraphViz ATM, I'll explore a TensorFlow backend as well if that's handy for folks. |
@ajtulloch yes, that is indeed very nice haskell dsl! It would be nice add tensorflow support there. |
@ajtulloch That sounds good! |
Additional Options for Saver
I started experimenting with Go support for TensorFlow and stumbled on need for a common DSL too. Writing a new internal DSL in Go (or C#, or Ruby, etc) is an option, but in that case there would be two or more ways to define a graph. A Go developer who became accustomed to defining graphs in Go may have a trouble understanding a graph definition in Python, and vice versa. So, I don't think each language should define its own way of defining a graph, there should be one way. At the same time, I see "Graph construction" in Improve support for C++ only users roadmap item. Does this mean C++ will have its own internal DSL for graph construction? That would be unfortunate. I'd be much more in favor of one DSL that compiles to GraphDef file that can be loaded in Python/C++/Go/etc. Alternatively, the C++ backend could have a dsl parser, so dsl does not need to be compiled. |
A partially correlated coming soon https://www.tensorflow.org/versions/master/resources/xla_prerelease |
Automatically closing due to lack of recent activity. |
Force a PYTHON_BIN_PATH to control action_env
…stream-eigen-update-180718 changing the eigen commit pointer to the official bitbucket repo
PiperOrigin-RevId: 449111398
Is there a possibility to have a human consumable language independent DSL from which a program in any desired language can be generated.
The text was updated successfully, but these errors were encountered: