JavaScript is the "VM" to target for D

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:hqlko7$don$1 at digitalmars.com...
> Nick Sabalausky:
>> I use Haxe for any and all PHP and Flash development
>
> I have an OT question: Haxe and similar things add another layer between 
> the code you write and the program that gets run. Isn't this extra 
> distance (and the semantic adaptations it requires) cause of problems? For 
> example when you put a bug in your Haxe code.
>

Sometimes I get errors from the haxe compiler, and sometimes I get errors 
from the PHP runtime. But if I weren't using Haxe then all the errors would 
be from the PHP runtime, so I count that as a net improvement.

About the only problem I've seen from the extra layer of abstraction is that 
the PHP runtime errors show the file/line of haxe's php output instead of 
the file/line in the original haxe source. So you have to go to the php file 
that haxe generated to see where the problem occurred. However:

1. At worst, that's only a minor inconvenience.

2. It's not a completely insurmountable problem. I can think of lots of ways 
that problem could be mitigated, if not outright eliminated. For instance, 
Haxe could output a file-by-file/line-by-line mapping from the php output to 
the haxe source and another program could take the that info and the error 
message and translate back. Or PHP could add some feature or features to 
help in that regard (ie, something comparable to how D's "#line" feature 
exists to make it easy for a theoretical D preprocessor to not screw up the 
line numbers output by DMD). Or, in some cases, Haxe could just tighten up 
it's static analysis and not let the issue get to the run-time stage.

Does that answer your question?