Thanks, that link works. Though the file linked there is misnamed. It
has the extension .tar.gz even though it’s just a tar file.
It seems that the choice for a front end is between Ripper and Ruth.
Both’ll need a bit of development before they can be used, and neither
is documented.
Personally I think Ruth is the better choice since it has fewer
dependencies (Ripper needs bison and gperf) and it’s interface seems to
be simpler.
Though it has the problem that when parsing a method definition using
the standard parse method there’s no way to find out what parameters the
methods takes. However I think there might be lower level methods which
can be used in this case.
ISTM the best bet would be to design the compiler so that the parser can
be swapped easily. Looking at the archives for Cardinal I noticed there
was talk of Rite having a seperate parser component. Being able to use
that as a parser would be very useful.
I’m going to set up a project on Rubyforge in order to work on this.
Thanks, that link works. Though the file linked there is misnamed. It
has the extension .tar.gz even though it’s just a tar file.
It seems that the choice for a front end is between Ripper and Ruth.
Both’ll need a bit of development before they can be used, and neither
is documented.
Personally I think Ruth is the better choice since it has fewer
dependencies (Ripper needs bison and gperf) and it’s interface seems
to be simpler.
Though it has the problem that when parsing a method definition using
the standard parse method there’s no way to find out what parameters
the methods takes. However I think there might be lower level methods
which can be used in this case.
ISTM the best bet would be to design the compiler so that the parser
can be swapped easily. Looking at the archives for Cardinal I noticed
there was talk of Rite having a seperate parser component. Being able
to use that as a parser would be very useful.
I’m going to set up a project on Rubyforge in order to work on this.
On Ruby parsers I might also mention that the new version of Rockit
(that I’ve used internally in my research for some time) has a Ruby
parser. Rockit’s new model is to automatically generate an AST-builder
class that builds an AST for you when parsing. If you want your own
callbacks without building the AST you can just subclass or write your
own builder class and initialize the parser class with that. It seems to
be a fairly good compromise between the different parsing “styles”. I
have planned to release it for long but it has some non-open code that I
need to get rid of. I’ve sat dates before so I won’t do that again
though so you might be better off with something else for now…
Anyway, the idea is that both Ruth and Rockit’s Ruby parser should
generate the same AST so that they can be tested against each other for
conformance.
Thanks, that link works. Though the file linked there is misnamed. It
has the extension .tar.gz even though it’s just a tar file.
It seems that the choice for a front end is between Ripper and Ruth.
Both’ll need a bit of development before they can be used, and neither
is documented.
Personally I think Ruth is the better choice since it has fewer
dependencies (Ripper needs bison and gperf) and it’s interface seems
to be simpler.
Though it has the problem that when parsing a method definition using
the standard parse method there’s no way to find out what parameters
the methods takes. However I think there might be lower level methods
which can be used in this case.
ISTM the best bet would be to design the compiler so that the parser
can be swapped easily. Looking at the archives for Cardinal I noticed
there was talk of Rite having a seperate parser component. Being able
to use that as a parser would be very useful.
I’m going to set up a project on Rubyforge in order to work on this.
On Ruby parsers I might also mention that the new version of Rockit
(that I’ve used internally in my research for some time) has a Ruby
parser. Rockit’s new model is to automatically generate an AST-builder
class that builds an AST for you when parsing. If you want your own
callbacks without building the AST you can just subclass or write your
own builder class and initialize the parser class with that. It seems to
be a fairly good compromise between the different parsing “styles”. I
have planned to release it for long but it has some non-open code that I
need to get rid of. I’ve sat dates before so I won’t do that again
though so you might be better off with something else for now…
Anyway, the idea is that both Ruth and Rockit’s Ruby parser should
generate the same AST so that they can be tested against each other for
conformance.
/Robert
How hard is it to just piggyback on top of parse.y from the ruby source?
Or does a lot of evaluation take place still in that file. You could
however just change what each of the actions to do to match your
backend. Unless you want the byte-code compiler to be entirely self
hosting of course. But if Rocket depends on bison anyhow you don’t get
anyway.
I guess the problem I am seeing with the parrot compiler is all the code
that is C-calls into the interpreter. How do you plan on keeping that
ability, while adding the benefit of parrot? I’m curious how the
interop works with parrot.
Another point is that while I think this is a great idea, maybe we
should push to get a Rite compiler working, but make it have some sort
of pluggable middle/backend so that we can drop out bytecode or just
interpret in C. It just seems awkward to rush ahead and get a bytecode
compiler for a bytecode platform that hasn’t completely standardized,
just before the language your compiling is going through a standards
change that may break code.
Thanks, that link works. Though the file linked there is misnamed.
It has the extension .tar.gz even though it’s just a tar file.
It seems that the choice for a front end is between Ripper and Ruth.
Both’ll need a bit of development before they can be used, and
neither is documented.
Personally I think Ruth is the better choice since it has fewer
dependencies (Ripper needs bison and gperf) and it’s interface seems
to be simpler.
Though it has the problem that when parsing a method definition
using the standard parse method there’s no way to find out what
parameters the methods takes. However I think there might be lower
level methods which can be used in this case.
ISTM the best bet would be to design the compiler so that the parser
can be swapped easily. Looking at the archives for Cardinal I
noticed there was talk of Rite having a seperate parser component.
Being able to use that as a parser would be very useful.
I’m going to set up a project on Rubyforge in order to work on this.
On Ruby parsers I might also mention that the new version of Rockit
(that I’ve used internally in my research for some time) has a Ruby
parser. Rockit’s new model is to automatically generate an
AST-builder class that builds an AST for you when parsing. If you
want your own callbacks without building the AST you can just
subclass or write your own builder class and initialize the parser
class with that. It seems to be a fairly good compromise between the
different parsing “styles”. I have planned to release it for long but
it has some non-open code that I need to get rid of. I’ve sat dates
before so I won’t do that again though so you might be better off
with something else for now…
Anyway, the idea is that both Ruth and Rockit’s Ruby parser should
generate the same AST so that they can be tested against each other
for conformance.
/Robert
How hard is it to just piggyback on top of parse.y from the ruby
source? Or does a lot of evaluation take place still in that file.
You could however just change what each of the actions to do to match
your backend. Unless you want the byte-code compiler to be entirely
self hosting of course. But if Rocket depends on bison anyhow you
don’t get anyway.
Ripper uses parse.y to generate it parser, so it is possible.
I guess the problem I am seeing with the parrot compiler is all the
code that is C-calls into the interpreter. How do you plan on keeping
that ability, while adding the benefit of parrot? I’m curious how the
interop works with parrot.
I’m not sure that I follow you here.
Do you mean how to handle the eval instruction? In parrot there’s an
opcode that registers a function as being a compiler. then another
opcode is used to compile a string to bytecode.
If you mean how to call code written in c there’s the NCI interface
which so far has been used to create parrot bindings to PostgreSQL and SDL
Another point is that while I think this is a great idea, maybe we
should push to get a Rite compiler working, but make it have some sort
of pluggable middle/backend so that we can drop out bytecode or just
interpret in C. It just seems awkward to rush ahead and get a
bytecode compiler for a bytecode platform that hasn’t completely
standardized, just before the language your compiling is going through
a standards change that may break code.
My understanding is that Matz isn’t going to release Rite until it is at
a stage where it is running reasonably. I’m not sure how we can push to
get Rite working till then.
I like the idea of having a plugable back end to the Rite compiler so it
would be possible to get it to target the Rite Vm, Parrot, .net or the JVM.
Still even if this project is supersceded by Rite, I think it would at
least make a good prototype.
