[LLVMdev] Code-generation: lang=>JSON, JSON=>lang and merging into lang

[Alec Taylor]

*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>