in reply to Re^2: sourcefilter with complete parser?
in thread sourcefilter with complete parser?
Please let me point out that 100% translation is always possible if you don't care about performance.
The most brutal force (if this word exists) is done by emulating the CPU of a processor supporting the language.
I'm not interested to emulate or translate more than 80% of a language even if it might be quite easy with some LISP dialects were most of the complicated constructs are just implemented in some core stuff.
Let me give you an example: there is a very subtle difference how JS and Perl numify strings.
Frankly I don't care to support software which relies on such differences. It even throws warnings.
DB<116> use warnings;0+"2" => 2 DB<117> 0+"ss2" => 0 DB<118> 0+"3ss2" => 3 DB<119> use warnings;0+"3ss2" Argument "3ss2" isn't numeric in addition
>>> a="ss2"; 0+parseInt(a) NaN >>> a="3ss2"; 0+parseInt(a) 3
Of course it's possible to wrap every variable in numeric context with a function which numifies the Perl way.
Such a code would be incredibly slow.
But only supporting the "normal" scalar case were strings are to be treated like numbers is far faster.
Just substract zero:
>>> a="2"; 0+a "02" >>> a="2"; 0+a-0 2
My theory is that it's pretty feasible to create a new language which is a subset of Perl5 or Perl6 and creates acceptable JS.
"Acceptable" doesn't mean 100% compatible. Neither different versions of Perl nor JS are ever 100% compatible.
perlito is already quite good at this.
Cheers Rolf
( addicted to the Perl Programming Language)
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^4: sourcefilter with complete parser?
by raiph (Deacon) on Dec 16, 2013 at 19:15 UTC | |
by LanX (Saint) on Dec 16, 2013 at 21:45 UTC | |
by raiph (Deacon) on Dec 17, 2013 at 19:02 UTC | |
by LanX (Saint) on Dec 18, 2013 at 15:12 UTC | |
by raiph (Deacon) on Dec 19, 2013 at 00:24 UTC |