Re^8: Why Perl 6 is taking so !@#$ long

[dragonchild]

Yes. Does, say, GHC run on every platform Perl5 runs on? What about all the issues in perlport? That's the issue with non-C VMs.

[BrowserUk]

Actually, it quite possible that GHC would run on more modern platforms that Perl, but I'm not convinced that is relevant.

Most people using Perl use binary distributions. Even on Linux, a large proportion of people install perl via OS specific distribution tools.

I know I'll cop a load of abuse for saying this, but I do not see the imperative that says it must be possible to build the entire tool chain, including the compilers that compile the compilers, from source.

So long as

1. The sources of the VM can be built on each target platform.
2. The tools required to do so, are available for each target platform--even if those tools are more easily obtained in binary form.
3. The sources of the tools are available under a non-restrictive licence so that they can be built by anyone, and can be ported to new platforms where the need and interest is strong enough.
4. And those tools have an active and on-going support community.

Then I fail to see the benefit of discarding all the benefits that would acrue from using a higher level language compiler, in favour of C and gcc, just because they're ubiquitous?

If Perl6 and the VM are any good, then once you have a set of working binaries for both, then you can set up another project to port those tools themselves, to Perl6/VM assembler.

Just as Perl5 builds a miniperl to use in the construction of the real thing, so you could eventually arrive at a VM written in it's own source language and use a (downloaded) binary distribution to bootstrap a fully self-compiled toolset.

There is always a bootstrap problem. You need a C compiler (or binary distribution) to build gcc before you can use gcc. So what is wrong with requiring a binary distribution of compiler X to start the chain for the VM?

[diotalevi]

I can get perl5 for my NetBSD Sparc but can't get GHC. I suppose that means I can't get Pugs for it either.

[Anonymous Monk]

If the choice is between...
1. A Haskell based Perl6 that runs on 90% of hardware but is available now and...
2. A Parrot based Perl6 which runs of 99% of hardware, but is 5 years out
...I'd choose the Haskell/Perl6 solution and leave the worry over the other 9% of hardware to the future. (And I'd venture a guess that it'd be about 1000 times easier to get GHC working on NetBSD/SPARC then to get parrot in usable shape.)

[BrowserUk]

Hmm. According to the GHC supported platforms list:

sparc-unknown-openbsd

Supported, including native-code generator. The same should also be true of NetBSD

[dragonchild]

Just as Perl5 builds a miniperl to use in the construction of the real thing, so you could eventually arrive at a VM written in it's own source language and use a (downloaded) binary distribution to bootstrap a fully self-compiled toolset.

I thought we were talking about a VM. VMs are virtual. I'm not seeing where compilation to native ASM is part of a VM's responsabilities.

[BrowserUk]

I believe that a bytecode to native compiler has always been a part of the overall plan, albeit with a somewhat low priority.

It has to be easier to write a bytecode to C compiler once you have a working interpreter as a reference platform, than to do so from scratch?