haxe.org Added haxe-targets graphviz diagram to intro compiler-targets doc.

Added haxe-targets graphviz diagram to intro compiler-targets doc.

Open uvtc opened this issue 5 years ago • 17 comments

Diagram (started by Brian Tiffin) to show how the different language/platform Haxe targets can reach the different end-user platforms (VM, Browser, Interpreter, Executable).

Still needs work, but @Simn said "looks really good!", so I thought it should go up now and folks can add clarifications later as they come up.

Oct 18 '18 13:10 uvtc

Nice graph!

Suggestions:

Haxe --interp should also point to Interpreter, then it doesnt have to be that lonely there.
Arrow From Ecmascript to Browser maybe needs label "JavaScript"
Arrow From Ecmascript to Interpreter maybe needs label "node.js"

Oct 18 '18 13:10 markknol

Thanks! Thanks to Brian for getting the ball rolling!

Is haxe --interp on the same level as "Interpreter"? Is it used in production? Making an --interp-labeled arrow go straight to Interpreter unfortunately makes the diagram wider and also messier.

img haxe-targets temp

I didn't include "JavaScript" on the arrow from ECMAScript to Browser because it's not a tool that gets from one to the other. My understanding is that ECMAScript is, for nearly all intents and purposes, equivalent to JavaScript. And I see that it's haxe --js, and not haxe --ecma, so maybe I should just change it in the diagram to say "JavaScript".

I didn't include node.js because I didn't include any specific VMs or Interpreters. I think the diagram would become too heavy if we tried to include the JVM,CLR, Node.js, the Python & Lua & PHP interpreters (not sure of the names), Flash player, etc. Add to that, each target language may have multiple VMs/Interpreters.

My thought is that the labels on the arrows are to show what tool gets you from one box to the next (so, maybe I should remove "HL/JIT" and "HL/C"). The viewer already has their own platform and tool-set in mind --- they just need to see that Haxe can get them there.

Oct 18 '18 14:10 uvtc

Well depends on what you mean by "in production". It can be used in CI, to build tools, to generate stuff on the fly, its used by people, so it should be there.

Maybe you could rotate everything 90 degrees to not have everything horizontally?

     > hashlink  > vm
haxe > c# > executable
     > java > vm
     > .. > etc

Oct 18 '18 15:10 markknol

Hm. I don't know how to rotate the diagram, but that's a good idea. Will have to look into that later.

Here's another version where I've put light blue borders on everything that Haxe can generate, and also included a couple of other bytecode boxes so it's easier to see the "bytecode level" below the "source code level":

haxe targets with bytecode

Does it look better with those bytecode boxes in there as well?

Oct 18 '18 15:10 uvtc

Other notes:

I would rename ECMAScript to JavaScript, because thats what we call this target https://haxe.org/manual/target-javascript.html
Indeed, you could leave "javascript" as label on arrow out, but from JavaScript to Interpreter "node.js" makes sense to me
I would keep "HL/JIT" and "HL/C"

Oct 18 '18 15:10 markknol

Yeah I pressed send accidentally while I was typing, didnt mean that.

Oct 18 '18 15:10 markknol

Ok, found the left-to-right option, which yields:

Not quite as crazy about it, but it does fit on the page much better.

Oct 18 '18 15:10 uvtc

As @Simn would say "looks really good!"

Oct 18 '18 15:10 markknol

So, better with, or without, the separate bytecode layer? Here it is, left-to-right, without the bytecode layer (and with Haxe -> Interpreter directly, labeled "--interp"):

haxe targets, vertical