D to Javascript converter (a hacked up dmd)

[Adam D. Ruppe]

On Friday, 2 March 2012 at 18:28:15 UTC, Nick Sabalausky wrote:
> Suggestion: Allow all D features even if it
> requires...inefficient-er...boilerplate, BUT then have a system 
> [...]

Eh. A problem there is those pragmas or whatever would be
unrecognized by the real dmd. A command line switch, maybe,
though.

But on pragmas, I have extern(js) and pragma(no_js_output),
but I want to keep them hidden inside the library modules.

Even if you version() something out, if dmd's lexer doesn't
understand it, it won't compile under the normal thing. This
breaks the benefit of same code on both sides.

But, version(generating_js) import something; always works.


That's about as fine-grained as I think it should be.



But, on this stuff, if it is there, I think it is ok to
use it. The key though is to not pay for what you don't use.


The gcfunctions helper app (in src/test/tools) acts like a
static linker here, cutting out unreferenced functions and
variables.


The library now can define a whole mess of functions, and
if you don't use them, they get stripped out of the final
file.


The key is then: a) not referencing stuff in a hidden fashion;
make sure typical D code is still small and b) minimizing
interdependencies, so pulling in one function doesn't pull
in a whole package.



This is something that's generally desirable in regular D,
too (for the same reason, even) so it is I think a good path.