Is there anyone working on a compiler for compiling Ruby code to work on
parrot?
The latest effort Cardinal seemed to die off before it got started,
presumably due to the immaturity of Parrot.
However version 0.1.0 of Parrot is set to be released on the 29th of
this month wich should include support for objects, so this seems to be
the ideal time to get a compiler project started up.
Cardinal was set up on Savannah but this seems to be a perfect project
to start up on Rubyforge.
I’d love to see that, but I really don’t think I can help ,even if dan
sugalsky says that compilers are easy[1]
PDD 15 (objects) is done IIRC , so a ruby compiler could be started
prolly
Is there anyone working on a compiler for compiling Ruby code to work on
parrot?
The latest effort Cardinal seemed to die off before it got started,
presumably due to the immaturity of Parrot.
However version 0.1.0 of Parrot is set to be released on the 29th of
this month wich should include support for objects, so this seems to be
the ideal time to get a compiler project started up.
So they’re promising object support at the end of the month? I’ve
heard this for almost two years now. I’ll believe it when I see it.
Cardinal was set up on Savannah but this seems to be a perfect project
to start up on Rubyforge.
Is anyone else interested in this?
I’m very interested in this. I was the one who setup the project at
Savannah (now I don’t even know where I put the passwords for it, it’s
been so long ago). I definately want to see a Ruby front-end for
Parrot. Back when I started the project I wasn’t working. Since then
I’ve been going to grad school and more recently I’ve gotten a job and
I’m still going to grad school so I really don’t have a lot of time to
commit to this.
Please feel free start a Cardinal project on Rubyforge. Even if
Object support in Parrot doesn’t come out this month, it will eventually happen(at least I hope so :). In the meantime there are
lots of other tasks that could be done. The foremost being that we
need a good parser for Ruby (Cardinal isn’t the only project that
needs this). I just saw another post that mentioned Ripper again.
Might be worth a try. There’s also Ruth. At any rate, I think the
main focus right now needs to be on the frontend until the backend
issues (object support in Parrot) are ironed out.
Cardinal was set up on Savannah but this seems to be a perfect project
to start up on Rubyforge.
Also on RubyForge is Ripper (http://rubyforge.org/projects/ripper/), which
would probably make a good choice for the parser for this compiler.
Ripper is in need of development help. Minero Aoki is reportedly very
busy these days with other projects and has moved the project to RubyForge
in an effort to get more people engaged.
Thanks for the suggestion. I’ve downloaded the tarball of the cvs files
and started experimenting with it.
From what I’ve seen it does seem to be close to what we need. Once it’s
finished it seems that in order to build a compiler all you’d have to do
is subclass the Ripper class and add in callbacks that output the
correct code.
I’ll try to help with Ripper thoughmy C skills are rather rusty so I’m
not sure how much I’ll be able to help.
Is there anyone working on a compiler for compiling Ruby code to work on
parrot?
The latest effort Cardinal seemed to die off before it got started,
presumably due to the immaturity of Parrot.
However version 0.1.0 of Parrot is set to be released on the 29th of
this month wich should include support for objects, so this seems to be
the ideal time to get a compiler project started up.
So they’re promising object support at the end of the month? I’ve
heard this for almost two years now. I’ll believe it when I see it.
AFAIK, The spec for the object support has been written and Dan has
promised to check a basic implementation in to the source tree in time
for the feature freeze monday.
Cardinal was set up on Savannah but this seems to be a perfect project
to start up on Rubyforge.
Is anyone else interested in this?
I’m very interested in this. I was the one who setup the project at
Savannah (now I don’t even know where I put the passwords for it, it’s
been so long ago). I definately want to see a Ruby front-end for
Parrot. Back when I started the project I wasn’t working. Since then
I’ve been going to grad school and more recently I’ve gotten a job and
I’m still going to grad school so I really don’t have a lot of time to
commit to this.
Please feel free start a Cardinal project on Rubyforge. Even if
Object support in Parrot doesn’t come out this month, it will eventually happen(at least I hope so :). In the meantime there are
lots of other tasks that could be done. The foremost being that we
need a good parser for Ruby (Cardinal isn’t the only project that
needs this). I just saw another post that mentioned Ripper again.
Might be worth a try. There’s also Ruth. At any rate, I think the
main focus right now needs to be on the frontend until the backend
issues (object support in Parrot) are ironed out.
I’ve tried out Ripper and it seems to be very close to what we need for
a front end. Though I’ll also take a look at Ruth.
There are AFAIK at least two projects that convert Ruby code into
bytecode, I wonder how easy it would be to modify them so they emit
parrot bytecode? I admit I’m not clear about how they work.
I agree that the front end is the best place to start working on the
project.
Hi.
This is probably naive, but I was wondering why you couldn’t just use Ruby’s
existing front-end implementation to parse and build an AST, and then build
a seperate generator that takes the AST as input to compile and emit Parrot
VM code? I haven’t looked at Ruby’s implementation, so I don’t know how it
was designed, but if it was designed to seperate concerns: tokenizing,
parsing, semantic checking, optimization, etc., then as long as you know
what each part returns, you should be able to build new components for each
stage. In this case, you’d want to build a new Parrot code generator that
takes the AST that Ruby currently creates when interpreting a program
(assuming Ruby creates an AST, of course). You might also be able to make a
generator for .NET in this way … Anyway. I was just thinking you could
leverage the existing code, and save some time and effort. But, perhaps what
I’m saying can’t be done - or can’t be done using Ruby’s existing C
implementation. Just an idea.
Is there anyone working on a compiler for compiling Ruby code to
work on parrot?
The latest effort Cardinal seemed to die off before it got started,
presumably due to the immaturity of Parrot.
However version 0.1.0 of Parrot is set to be released on the 29th of
this month wich should include support for objects, so this seems to
be the ideal time to get a compiler project started up.
So they’re promising object support at the end of the month? I’ve
heard this for almost two years now. I’ll believe it when I see it.
AFAIK, The spec for the object support has been written and Dan has
promised to check a basic implementation in to the source tree in time
for the feature freeze monday.
Cardinal was set up on Savannah but this seems to be a perfect
project to start up on Rubyforge.
Is anyone else interested in this?
I’m very interested in this. I was the one who setup the project at
Savannah (now I don’t even know where I put the passwords for it, it’s
been so long ago). I definately want to see a Ruby front-end for
Parrot. Back when I started the project I wasn’t working. Since then
I’ve been going to grad school and more recently I’ve gotten a job and
I’m still going to grad school so I really don’t have a lot of time to
commit to this.
Please feel free start a Cardinal project on Rubyforge. Even if
Object support in Parrot doesn’t come out this month, it will eventually happen(at least I hope so :). In the meantime there are
lots of other tasks that could be done. The foremost being that we
need a good parser for Ruby (Cardinal isn’t the only project that
needs this). I just saw another post that mentioned Ripper again.
Might be worth a try. There’s also Ruth. At any rate, I think the
main focus right now needs to be on the frontend until the backend
issues (object support in Parrot) are ironed out.
I’ve tried out Ripper and it seems to be very close to what we need
for a front end. Though I’ll also take a look at Ruth.
Does anyone know where I can find Ruth? I’ve tried looking on Rubyforge
and RAA but haven’t been able to find it.
Question: is the AST a bunch of ruby classes, which can be
manipulated/navigated through Ruby?
One day, I hope, to extend my editor so it can interact with Rubys AST,
then some really nice things becomes possible:
advanced syntax coloring which can identify syntax-errors.
obtain advanced help about the code under the cursor.
advanced code completion.
···
On Sat, 21 Feb 2004 09:54:25 -0500, Sean Ross wrote:
This is probably naive, but I was wondering why you couldn’t just use Ruby’s
existing front-end implementation to parse and build an AST, and then build
a seperate generator that takes the AST as input to compile and emit
–
Simon Strandgaard
There are AFAIK at least two projects that convert Ruby code into
bytecode, I wonder how easy it would be to modify them so they emit
parrot bytecode? I admit I’m not clear about how they work.
One of these projects may be ByteCodeRuby [1]. Feel free to use
lib/bcr/compile.rb if it helps you and the licence (Ruby’s) suits you.
Better to look in CVS rather than use the latest build, which is a
little old now.
However I’m not sure how good the fit will be. BCR works off a
DOM-style parser (Ruth) and compiles to a stack-based virtual machine.
It sounds like you might be using Ripper, which is SAX-style, and
compiling to Parrot, which is register-based.
On Sat, 21 Feb 2004 09:54:25 -0500, Sean Ross wrote:
This is probably naive, but I was wondering why you couldn’t just use Ruby’s
existing front-end implementation to parse and build an AST, and then build
a seperate generator that takes the AST as input to compile and emit
[snip]
Cool… a ruby2ast converter.
Question: is the AST a bunch of ruby classes, which can be
manipulated/navigated through Ruby?
One day, I hope, to extend my editor so it can interact with Rubys AST,
then some really nice things becomes possible:
advanced syntax coloring which can identify syntax-errors.
obtain advanced help about the code under the cursor.
advanced code completion.
–
Simon Strandgaard
I think we definitely need a meta-aware ruby interpreter that you can
hook some stuff when it’s parsing it’s own file. Or even just an
interpreter switch that dumps the parse tree in a couple of different
formats, if it’s too hard to get it at runtime. This would make it much
easier for alot of things.
Hi.
This is probably naive, but I was wondering why you couldn’t just use Ruby’s
existing front-end implementation to parse and build an AST,
I think this is what ruth , bytecoderuby and YAPV do.
Yes, ruth and bytecoderuby (since it uses ruth!?) use the parser in your
current ruby, and with almost certainty that also goes for YAPV. Good
thing is that it really parses exactly the same language and you don’t
have to do much yourself. Bad thing is not all info is there.
ripper, OTOH, uses ruby’s parse.y
In theory should be in sync with Ruby’s parser since it is based on it
but might lag if there are changes to Ruby’s (although I think changes
are minor in practice). Downside: more work.
And then Rockit/Ruby: Rockit is a stand-alone parser generator with
clean grammar grammar. Upside: more easily readable Ruby grammar.
Actions can be plugged in. Generates AST-building actions from grammar.
Rockit supports tree traversal, pretty-printing etc for all its
AST’s/grammars. Downside: Not yet released ;). Can get out of sync/might
not parse exactly same language.
This is probably naive, but I was wondering why you couldn’t just
use Ruby’s
existing front-end implementation to parse and build an AST, and
then build
a seperate generator that takes the AST as input to compile and emit
[snip]
Cool… a ruby2ast converter.
Question: is the AST a bunch of ruby classes, which can be
manipulated/navigated through Ruby?
One day, I hope, to extend my editor so it can interact with Rubys
AST, then some really nice things becomes possible:
advanced syntax coloring which can identify syntax-errors.
obtain advanced help about the code under the cursor.
advanced code completion.
–
Simon Strandgaard
I think we definitely need a meta-aware ruby interpreter that you can
hook some stuff when it’s parsing it’s own file. Or even just an
interpreter switch that dumps the parse tree in a couple of different
formats, if it’s too hard to get it at runtime. This would make it
much easier for alot of things.
This sounds like a Ruby version of Perls B::** modules, which I agree
would be a very good thing.
Though would it be best to do this by modifying the interpreter, or by
using one of Ripper, Ruth or Rocket?
···
On Sat, 21 Feb 2004 09:54:25 -0500, Sean Ross wrote:
One thing about Ripper that I heard at the RubyConf (someone please
correct me if I’m wrong) is that matz plans on using it for Rite’s
parser, so eventually it is guaranteed to always be in sync with the
most current Ruby. For that reason it seems like it would be great for
folks to be improving it now, as it means less work for matz in the
long run.
Nathaniel
<:((><
···
On Feb 22, 2004, at 03:58, Robert Feldt wrote:
[Ripper] In theory should be in sync with Ruby’s parser since it is
based on it but might lag if there are changes to Ruby’s (although I
think changes are minor in practice). Downside: more work.
I think we definitely need a meta-aware ruby interpreter that you can
hook some stuff when it’s parsing it’s own file. Or even just an
interpreter switch that dumps the parse tree in a couple of different
formats, if it’s too hard to get it at runtime. This would make it
much easier for alot of things.
This sounds like a Ruby version of Perls B::** modules, which I agree
would be a very good thing.
Though would it be best to do this by modifying the interpreter, or by
using one of Ripper, Ruth or Rocket?
I’m not 100% up to speed with Perls B::* modules but my vision for Ruth
was to do (what I think is) the same thing for Ruby: lift the internal
representation to the language level. This is useful no matter which
Ruby parser you eventually go for for a compiler project, IMHO since you
can test your stuff against it.
