Kenneth Adam Miller
2015-Jun-20 13:41 UTC
[LLVMdev] Code-generation: lang=>JSON, JSON=>lang and merging into lang
Possibly protobuf or capn proto would be much more clean alternatives to json. I was working with interpreting instruction semantics a while back, and you shouldn't have to write a parser to get the data structure back into coherent form, you can get what you want automatically and have the structure isolated into a common schema. On Sat, Jun 20, 2015 at 9:22 AM, Stephen Cross <scross at scross.co.uk> wrote:> > reproduce the code in that language > > Is the intention to exactly reproduce the original source code? Or > some code that's functionally equivalent? > > On Sat, Jun 20, 2015 at 8:05 AM, Alec Taylor <alec.taylor6 at gmail.com> > wrote: > > Considering engineering my own code-generator. If I do go ahead, will > > open-source the end result. > > > > Needs to read [parse] one language, and output JSON (conformant to a > > specific JSON-schema). > > > > Then needs to read JSON, and reproduce the code in that language, and > > [possibly] merge the generated code with existing code. > > > > Languages I'm looking to support are all rather popular (Python, Go, > Rust, > > JavaScript). > > > > Any pointers—e.g.: specific LLVM libraries and sub-projects to use—would > be > > appreciated. > > > > Thanks > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150620/114ca7d1/attachment.html>
Alec Taylor
2015-Jun-20 22:10 UTC
[LLVMdev] Code-generation: lang=>JSON, JSON=>lang and merging into lang
Dear Stephen, Kenneth and <the rest of the mailing-list>, Thanks for your replies. Was intentionally not giving the full picture (because I didn't want the cake given away; I.e.: wanted to figure things out for myself [then open-source it all]). Anyway, I'll tell you why I want JSON as the intermediary and what kind of format it should confirm to. Here's an example setup when applied to the Web domain, but it would also apply to other domains: 0. JSON written that generates documentation for the user/developer 1. This JSON then used to generate a REST API in language <y>, including database models, endpoints and tests with JSON mocks (via LLVM). Additionally input validation code will be attached to the models (and/or endpoints) 2. Language <y> edited in a restricted place (e.g.: adding a new mock and a new field to the database model, and adding a new endpoint)* 3. "JSON documentation" (like 0.) generated from this source-code (via LLVM) 4. JSON documentation used to generate frontend code, including tests with mocks, endpoint request (success/error handling), input validation & form generation (via JSON schema) 5. Restricted* changes made to frontend code, e.g.: validation logic (regex?) 6. Repeat 3. Repeat 1. By 6. you start to see the advantage of merging the changed into an existing code-base (rather than starting fresh). The existing code-base would have all the implementation specific logic, such as widgets and themes on the frontend, and transaction design, caching and complex database queries on the REST API end. Will likely confirm to the API Blueprint (AST [JSON]) format or Swagger. In addition to them thinking of edge-cases I haven't, they also do some [limited] code-generation themselves, such as basic clients (and sometimes servers) in various languages, and HTML documentation. Now that you know my full use-case you'll be better equipped to provide suggestions with how to proceed Thanks for your continued help, Alec Taylor * Edits to non-restricted places are fine, but won't get picked up by the JSON generator PS: capn proto is awesome [for unrelated stuff], thanks for the link :) PPS: As I flesh this out more and more, looks like I could generate everything from just looking in the tests rather than code from elsewhere On Saturday, June 20, 2015, Kenneth Adam Miller <kennethadammiller at gmail.com> wrote:> Possibly protobuf or capn proto would be much more clean alternatives to > json. I was working with interpreting instruction semantics a while back, > and you shouldn't have to write a parser to get the data structure back > into coherent form, you can get what you want automatically and have the > structure isolated into a common schema. > > On Sat, Jun 20, 2015 at 9:22 AM, Stephen Cross <scross at scross.co.uk > <javascript:_e(%7B%7D,'cvml','scross at scross.co.uk');>> wrote: > >> > reproduce the code in that language >> >> Is the intention to exactly reproduce the original source code? Or >> some code that's functionally equivalent? >> >> On Sat, Jun 20, 2015 at 8:05 AM, Alec Taylor <alec.taylor6 at gmail.com >> <javascript:_e(%7B%7D,'cvml','alec.taylor6 at gmail.com');>> wrote: >> > Considering engineering my own code-generator. If I do go ahead, will >> > open-source the end result. >> > >> > Needs to read [parse] one language, and output JSON (conformant to a >> > specific JSON-schema). >> > >> > Then needs to read JSON, and reproduce the code in that language, and >> > [possibly] merge the generated code with existing code. >> > >> > Languages I'm looking to support are all rather popular (Python, Go, >> Rust, >> > JavaScript). >> > >> > Any pointers—e.g.: specific LLVM libraries and sub-projects to >> use—would be >> > appreciated. >> > >> > Thanks >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu >> <javascript:_e(%7B%7D,'cvml','LLVMdev at cs.uiuc.edu');> >> http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <javascript:_e(%7B%7D,'cvml','LLVMdev at cs.uiuc.edu');> >> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150621/4818f691/attachment.html>
Alec Taylor
2015-Jun-27 00:29 UTC
[LLVMdev] Code-generation: lang=>JSON, JSON=>lang and merging into lang
*bump* On Sun, Jun 21, 2015 at 8:10 AM, Alec Taylor <alec.taylor6 at gmail.com> wrote:> Dear Stephen, Kenneth and <the rest of the mailing-list>, > > Thanks for your replies. > > Was intentionally not giving the full picture (because I didn't want the > cake given away; I.e.: wanted to figure things out for myself [then > open-source it all]). > > Anyway, I'll tell you why I want JSON as the intermediary and what kind of > format it should confirm to. > > Here's an example setup when applied to the Web domain, but it would also > apply to other domains: > 0. JSON written that generates documentation for the user/developer > 1. This JSON then used to generate a REST API in language <y>, including > database models, endpoints and tests with JSON mocks (via LLVM). > Additionally input validation code will be attached to the models (and/or > endpoints) > 2. Language <y> edited in a restricted place (e.g.: adding a new mock and > a new field to the database model, and adding a new endpoint)* > 3. "JSON documentation" (like 0.) generated from this source-code (via > LLVM) > 4. JSON documentation used to generate frontend code, including tests with > mocks, endpoint request (success/error handling), input validation & form > generation (via JSON schema) > 5. Restricted* changes made to frontend code, e.g.: validation logic > (regex?) > 6. Repeat 3. Repeat 1. > > By 6. you start to see the advantage of merging the changed into an > existing code-base (rather than starting fresh). The existing code-base > would have all the implementation specific logic, such as widgets and > themes on the frontend, and transaction design, caching and complex > database queries on the REST API end. > > Will likely confirm to the API Blueprint (AST [JSON]) format or Swagger. > In addition to them thinking of edge-cases I haven't, they also do some > [limited] code-generation themselves, such as basic clients (and sometimes > servers) in various languages, and HTML documentation. > > Now that you know my full use-case you'll be better equipped to provide > suggestions with how to proceed > > Thanks for your continued help, > > Alec Taylor > > * Edits to non-restricted places are fine, but won't get picked up by the > JSON generator > > PS: capn proto is awesome [for unrelated stuff], thanks for the link :) > > PPS: As I flesh this out more and more, looks like I could generate > everything from just looking in the tests rather than code from elsewhere > > > On Saturday, June 20, 2015, Kenneth Adam Miller < > kennethadammiller at gmail.com> wrote: > >> Possibly protobuf or capn proto would be much more clean alternatives to >> json. I was working with interpreting instruction semantics a while back, >> and you shouldn't have to write a parser to get the data structure back >> into coherent form, you can get what you want automatically and have the >> structure isolated into a common schema. >> >> On Sat, Jun 20, 2015 at 9:22 AM, Stephen Cross <scross at scross.co.uk> >> wrote: >> >>> > reproduce the code in that language >>> >>> Is the intention to exactly reproduce the original source code? Or >>> some code that's functionally equivalent? >>> >>> On Sat, Jun 20, 2015 at 8:05 AM, Alec Taylor <alec.taylor6 at gmail.com> >>> wrote: >>> > Considering engineering my own code-generator. If I do go ahead, will >>> > open-source the end result. >>> > >>> > Needs to read [parse] one language, and output JSON (conformant to a >>> > specific JSON-schema). >>> > >>> > Then needs to read JSON, and reproduce the code in that language, and >>> > [possibly] merge the generated code with existing code. >>> > >>> > Languages I'm looking to support are all rather popular (Python, Go, >>> Rust, >>> > JavaScript). >>> > >>> > Any pointers—e.g.: specific LLVM libraries and sub-projects to >>> use—would be >>> > appreciated. >>> > >>> > Thanks >>> > >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> > >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150627/764481b1/attachment.html>