Dear Stephen, Kenneth and <the rest of the mailing-list>,<div><br></div><div>Thanks for your replies.</div><div><br></div><div>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]).<br><br>Anyway, I'll tell you why I want JSON as the intermediary and what kind of format it should confirm to.</div><div><br></div><div>Here's an example setup when applied to the Web domain, but it would also apply to other domains:</div><div>0. JSON written that generates documentation for the user/developer</div><div>1. This JSON then used to generate a REST API in language <y>, including database models, endpoints and t<span style="color:rgb(34,34,34);font-size:14px;line-height:22.1200008392334px">ests</span> with JSON mocks (via LLVM). Additionally input validation code will be attached to the models (and/or endpoints)</div><div>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)*</div><div>3. "JSON documentation" (like 0.) generated from this source-code (via LLVM)</div><div>4. JSON documentation used to generate frontend code, including tests with mocks, endpoint request (success/error handling), input validation & form generation (via JSON schema)</div><div>5. Restricted* changes made to frontend code, e.g.: validation logic (regex?)</div><div>6. Repeat 3. Repeat 1.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Now that you know my full use-case you'll be better equipped to provide suggestions with how to proceed</div><div><br></div><div>Thanks for your continued help,</div><div><br></div><div>Alec Taylor</div><div><br></div><div>* Edits to non-restricted places are fine, but won't get picked up by the JSON generator</div><div><br>PS: capn proto is awesome [for unrelated stuff], thanks for the link :)</div><div><br>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<br><br>On Saturday, June 20, 2015, Kenneth Adam Miller <<a href="mailto:kennethadammiller@gmail.com">kennethadammiller@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 20, 2015 at 9:22 AM, Stephen Cross <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','scross@scross.co.uk');" target="_blank">scross@scross.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> reproduce the code in that language<br>
<br>
</span>Is the intention to exactly reproduce the original source code? Or<br>
some code that's functionally equivalent?<br>
<div><div><br>
On Sat, Jun 20, 2015 at 8:05 AM, Alec Taylor <<a href="javascript:_e(%7B%7D,'cvml','alec.taylor6@gmail.com');" target="_blank">alec.taylor6@gmail.com</a>> wrote:<br>
> Considering engineering my own code-generator. If I do go ahead, will<br>
> open-source the end result.<br>
><br>
> Needs to read [parse] one language, and output JSON (conformant to a<br>
> specific JSON-schema).<br>
><br>
> Then needs to read JSON, and reproduce the code in that language, and<br>
> [possibly] merge the generated code with existing code.<br>
><br>
> Languages I'm looking to support are all rather popular (Python, Go, Rust,<br>
> JavaScript).<br>
><br>
> Any pointers—e.g.: specific LLVM libraries and sub-projects to use—would be<br>
> appreciated.<br>
><br>
> Thanks<br>
><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="javascript:_e(%7B%7D,'cvml','LLVMdev@cs.uiuc.edu');" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','LLVMdev@cs.uiuc.edu');" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>
</blockquote></div>