Wasm has no facility for GC, polymorphic inline cache, or direct DOM integration. They are on the roadmap, but probably far off.

So there isn't a direct path to WASM for many dynamically typed languages. Tcl can get by without all that because it's small enough to just port the whole C interpreter instead of trying to have tcl compile down to wasm. That would be very large, slow, and tricky for Perl, Python, etc.

GC is not as far off as you might think. A markdown overview has been merged and there is a PR for impl in the interpreter. See PRs at https://github.com/WebAssembly/gc

> Wasm has no facility for GC

It shouldn't, GC is a level above Wasm and would complicate languages that don't use it.

> or direct DOM integration

You mean like this: https://github.com/tcr/rust-webplatform ?

The problem with most dynamic langauges you listed is they do things that the web doesn't allow or do them in ways that aren't friendly to a browser.

On GC, maybe you should let them know. They seem to be headed down that path: https://github.com/WebAssembly/design/blob/master/GC.md

Oh, and on direct DOM access. You presented a link to an implementation of indirect DOM access. They have an open issue you might find interesting: https://github.com/tcr/rust-webplatform/issues/20

Assembly language also doesn't have GC or polymorphic inline cache. I imagine that direct DOM integration would end up just being some kind of shared memory thing.

I don't get this kind of complaint. It seems to completely miss the point that webassembly is a compile target, like arm or x86.

It is not a complaint. It is in their plans. They describe it sometimes in VM terms, versus ASM terms.

Without those things, languages like Perl or Python aren't practical, because you would have to download the whole interpeter runtime. That's not a complaint, it is an observation.

Well sure, but a runtime isn't going to change all that much. It's exactly the kind of thing that caches well. I mean a re-usable garbage collector sounds alright, but I don't think it will be used that much. I mean, I presume that you could implement a garbage collector as a shared library, but nobody actually does that.

You have to come at it from the perspective of people that want languages like Perl or Python to run well in WASM. They are thinking of it being used the same way that javascript is today. If WASM has some of the features of a virtual machine (meaning the JVM type, not the hypervisor type), and direct DOM access, that would be possible. Downloading all of the runtime would put them at a disadvantage.

Those things are on the WASM roadmap. So this isn't just me going off on a tangent. https://github.com/WebAssembly/design/blob/master/GC.md

There would be several options I think.

  - translate MoarVM bytecode to WASM
  - add WASM as a Rakudo target
  - write yet another Perl6 compiler that targets the WASM just as niecza targets the CLR

Perl5 will probably end up as a Perl6 slang.

Sounds like an opportunity to step up to the plate!

I've tried. It's just hard, frankly. I'm just not that good a coder :(

Ehh I don't think so. I'm certain that you are a good coder. You just need to learn more about the techniques needed to implement a Perl to WASM compiler, and obviously, a ton of time.

You can do it man.

I know you're being encouraging, but I think you're underestimating the complexity of Perl parser. From what I remember, there were three subsystems that voted for each expression what programmer meant.

You are right, I'm completely ignorant on the topic haha. Could you clarify what you mean by "vote"?

Perl has some syntax that can be ambiguous. To the point that some code can't be parsed without running it.

See this for more on that: http://www.perlmonks.org/?node_id=663393

The stuff which makes perl really awesome are the distributions on CPAN.

Many (though not all) of these distributions contain XS, which is a type of glue between perl and C. Most of these XS distributions are there to link to some library -- Math::GMP, for example, lets perl code use the GNU gmp multi precision math library.

Without some way to make use of distributions with XS parts, then a perl to $other_language_here transpiler is not going to be very interesting.

That makes sense. Library compatibility is a tough issue to deal with. Scala.js faces the same issue when it comes to libraries that depend on the Java stdlib. I believe their goal is to port the entire stdlib, but I'm not sure tbh. It might just be an insurmountable problem.

Actually quite few are XS and XS is painful/a terrible way to plug C code inside of the Perl interpreter's guts. For this reason Perl6 aims to rewrite most of the stuff in Perl6/NQP and use NativeCall to call on external libraries.