I'm not saying it's not possible, but given that:
"Parrot is designed with the needs of dynamically typed languages
(such as Perl and Python) in mind, and should be able to run programs
written in these languages more efficiently than VMs developed with
static languages in mind (JVM, .NET)."
it does not seem like Go is a natural fit for this project.
I don't know enough about Parrot to say, but from its description it's not clear it's a good match since Go is not a dynamic language.
It might be a fun project but I don't see a practical purpose to such a port. Go is a static compiled language; why port it to a world for dynamic interpreters?
But to answer your question: It might be possible. Go's types, particularly interfaces, do not map well to the JVM. It's not clear they map well to any predefined typed VM.
-rob
But as Rob pointed out to me when I suggested a similar project,
compilation to native code works well enough, so there is little
advantage to compile to a VM.
If you want to embed Go on other programs, I think that should already
be possible now that you can call Go code from C thanks to iant's
work.
uriel
On Tue, Aug 3, 2010 at 10:09 PM, Remi Gillig <remig...@gmail.com> wrote:
Caveat: I am in no way an expert on Parrot, but...
There are implementations of C99 and QuickBasic for the VM so static languages can clearly be supported, plus it's architecture is not that far removed from the VMs I'm interested in developing with GoLightly - register-based and low-level but with support for memory aggregations as a fundamental register type. It also has garbage collection and VM-level threading. Thus far it looks like a fairly good match for Go and I suspect the main conflict will be an optimised double-dispatcher buried somewhere in its bytecode interpreter - and possibly a polymorphic type rewriter in its JIT compiler to perform predictive method activation. When I have some spare time I'll do a code dive to make sure as now I think about it there's probably a few ideas there I can repurpose :)
Also skimming the docs leaves the impression that a static language could be supported much better on Parrot than a dynamic language can on the JVM without the InvokeDynamic extension.
> It might be a fun project but I don't see a practical purpose to such a port. Go is a static compiled language; why port it to a world for dynamic interpreters?
There might be use cases where Parrot makes the best choice of platform for a particular purpose, and then having a language such as Go which takes concurrency seriously could be a big win. But let's face it, sticking Go wherever Go can go is a pretty reasonable end in its own right if it increases the pool of developers playing with the language.
> But to answer your question: It might be possible. Go's types, particularly interfaces, do not map well to the JVM. It's not clear they map well to any predefined typed VM.
Interfaces are the area that I think would map particularly well to a dynamic VM as they could be implemented very easily as a runtime filter/contract preventing inappropriate objects from entering certain code paths and might be able to indicate to the underlying runtime that certain JIT optimisations were possible from that point onwards. This could be viewed as a more generalised approach to annotations, which Charles Nutter and a few others have been working on in various Ruby dialects as a way of optimising numeric operations.
However I agree that this would be much less robust than the static bounding interfaces provide in Go as for instance in Ruby it's trivial to change the type of an object by adding and removing methods at any point in its lifecycle so the interface becomes less a guarantee and more a suggestion (and probably next to useless, depending on your perspective).
Ellie
Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason