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

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

The sources of the VM can be built on each target platform.
The tools required to do so, are available for each target platform--even if those tools are more easily obtained in binary form.
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.
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?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^9: Why Perl 6 is taking so !@#$ long

Replies are listed 'Best First'.
Re^10: Why Perl 6 is taking so !@#$ long by diotalevi (Canon) on Feb 28, 2006 at 19:11 UTC
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. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^11: Why Perl 6 is taking so !@#$ long by Anonymous Monk on Feb 28, 2006 at 20:08 UTC
If the choice is between... A Haskell based Perl6 that runs on 90% of hardware but is available now and... 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.)	[reply]
Re^12: Why Perl 6 is taking so !@#$ long by diotalevi (Canon) on Feb 28, 2006 at 20:09 UTC
Agreed. It'd be nice if you weren't anonymous so I could have just sent this to you directly. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^11: Why Perl 6 is taking so !@#$ long by BrowserUk (Patriarch) on Feb 28, 2006 at 19:34 UTC
Hmm. According to the GHC supported platforms list: sparc-unknown-openbsd Supported, including native-code generator. The same should also be true of NetBSD Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^12: Why Perl 6 is taking so !@#$ long by diotalevi (Canon) on Feb 28, 2006 at 19:36 UTC
Yeah, it's a nice theory. Four days into attempting to get a port of GHC to run on my machine, I gave up. I just keep the Sparc because it's the only SMP machine I have and I think it's sometimes important to test things on a real SMP box. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]
Re^13: Why Perl 6 is taking so !@#$ long by BrowserUk (Patriarch) on Feb 28, 2006 at 20:01 UTC
Re^10: Why Perl 6 is taking so !@#$ long by dragonchild (Archbishop) on Feb 28, 2006 at 20:53 UTC
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. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^11: Why Perl 6 is taking so !@#$ long by BrowserUk (Patriarch) on Feb 28, 2006 at 22:02 UTC
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? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]