Porting Go to Parrot

조회수 59회
읽지 않은 첫 메시지로 건너뛰기

Remi Gillig

읽지 않음,
2010. 8. 3. 오후 4:09:2810. 8. 3.
받는사람 golang-nuts
Hello everyone,

I very much like the concepts expressed in Go. I was searching for
other language related things and found this :

Parrot is a virtual machine designed to efficiently compile and
execute bytecode for dynamic languages. Parrot currently hosts a
variety of language implementations in various stages of completion,
including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6,
APL, and a .NET bytecode translator. Parrot is not about parrots,
though we are rather fond of them for obvious reasons.

http://www.parrot.org/

I don't know exactly how compiling Go works but I was wondering if an
implementation of a Go compiler which targets Parrot would be
possible?

Remi Gillig.

Peter Bourgon

읽지 않음,
2010. 8. 3. 오후 4:15:4210. 8. 3.
받는사람 golang-nuts

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.

Rob 'Commander' Pike

읽지 않음,
2010. 8. 3. 오후 4:18:3810. 8. 3.
받는사람 Remi Gillig, golang-nuts

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

Remi Gillig

읽지 않음,
2010. 8. 3. 오후 6:05:4310. 8. 3.
받는사람 Rob 'Commander' Pike, golang-nuts
Actually, my first idea in this question was related to embedding Go inside an application or a game as a scripting language. From what I've gathered so far on Go, it's clearly not its primary goal but it would be great to be able to embed it. Parrot seemed like a nice solution because it's embeddable.

I will try to see some existing Parrot implementations of languages to grasp how it is done. It surely lacks performance compared to original C implementations (Lua for example) I think.

Thanks for the insight!

Remi Gillig.

Uriel

읽지 않음,
2010. 8. 3. 오후 6:29:4610. 8. 3.
받는사람 Remi Gillig, golang-nuts
Why Parrot and not Inferno's Dis VM:
http://doc.cat-v.org/inferno/4th_edition/dis_VM_design ?

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:

Andrew Francis

읽지 않음,
2010. 8. 3. 오후 9:45:3610. 8. 3.
받는사람 golang-nuts
Hi Remi:

It would be interesting to see if a Go interpreter could be
implemented with the PyPy framework. I recently gave a a EuroPython
talk on prototyping Go's select with stackless.py as a prelude to an
implementation in Stackless Python. Also took the initial baby steps
for implementing select as a language feature.

Cheers,
Andrew

Cory Mainwaring

읽지 않음,
2010. 8. 3. 오후 10:35:0210. 8. 3.
받는사람 Andrew Francis, golang-nuts
Go has language interpreters already, though I doubt they are very robust, or even functional at this point.

Eleanor McHugh

읽지 않음,
2010. 8. 4. 오전 6:52:1210. 8. 4.
받는사람 golang-nuts
On 3 Aug 2010, at 21:18, Rob 'Commander' Pike wrote:
> On 04/08/2010, at 6:09 AM, Remi Gillig wrote:
>> Hello everyone,
>>
>> I very much like the concepts expressed in Go. I was searching for
>> other language related things and found this :
>>
>> Parrot is a virtual machine designed to efficiently compile and
>> execute bytecode for dynamic languages. Parrot currently hosts a
>> variety of language implementations in various stages of completion,
>> including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6,
>> APL, and a .NET bytecode translator. Parrot is not about parrots,
>> though we are rather fond of them for obvious reasons.
>>
>> http://www.parrot.org/
>>
>> I don't know exactly how compiling Go works but I was wondering if an
>> implementation of a Go compiler which targets Parrot would be
>> possible?
>
> 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.

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


Remi Gillig

읽지 않음,
2010. 8. 5. 오전 2:26:5010. 8. 5.
받는사람 golang-nuts
About the use of Go in general, for my purposes I can clearly see its
use as
a game scripting language (concurrency is a big win) and it does not
seem
too hard to understand the concepts for people not used to programming
(game designers for example). The problem is that we currently can't
embed
it to try it out (except through linking with gccgo as mentioned
earlier) but
the principle of a scripting language is to be able to iterate over it
quickly :)

So, implementing Go in Parrot would be great, having a dedicated VM
for Go
would be even more interesting and to embed it, have a nice API to
bind your
own C code or C++ classes with the Go VM (although the concepts of Go
would not map well directly but with some work I'm sure it would be
possible
to write a nice Go API from existing code).

Unfortunately, I don't know how much work all of these things would
involve
and I'm not an expert in any of these areas to work on this.

I tried embedding Ruby once, in SciTE to be precise, it worked OK but
there
was no clean API to do it and it was more of a hack of the Ruby VM
than
anything else. I think embedding is really important but I understand
why it
wasn't done with Go but I wanted to know the feasibility of it.

Remi Gillig.

On Aug 4, 12:52 pm, Eleanor McHugh <elea...@games-with-brains.com>
wrote:
> Games With Brainshttp://feyeleanor.tel
전체답장
작성자에게 답글
전달
새 메시지 0개