Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not find
quickly – that someone had started such a project. I realise right now that
this might be much slower, but it would seem to me to make it easier to make
something like Rite or some other bytecode system possible, wouldn’t it?
In message “Ruby in Ruby” on 03/07/28, Austin Ziegler austin@halostatue.ca writes:
Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not find
quickly – that someone had started such a project.
It’s Ryan Davis aka zenspider. You can also google for “MetaRuby”.
Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not find
quickly – that someone had started such a project. I realise right now that
this might be much slower, but it would seem to me to make it easier to make
something like Rite or some other bytecode system possible, wouldn’t it?
There are some members of Seattle.rb (hi Ryan), who are working on Ruby in
Ruby. They’re making pretty quick progress.
Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not find
quickly – that someone had started such a project. I realise right
now that
this might be much slower, but it would seem to me to make it easier
to make
something like Rite or some other bytecode system possible, wouldn’t
it?
There are some members of Seattle.rb (hi Ryan), who are working on Ruby
in
Ruby. They’re making pretty quick progress.
Maybe I’m beeing stupid but I can’t see the advantage in doing this other
than intellectual challenge and interest. Is there any other?
Maybe I’m beeing stupid but I can’t see the advantage in doing this other
than intellectual challenge and interest. Is there any other?
robert
Forgive me if I’m wrong, but I thought that this was required to have
self-evaluating code. In other words, you could store off a segment of code
and call eval() on it and have it run for you on the fly. Isn’t some form
of eval() already available? What are its limitations?
My understanding of the technique is that it would make it much easier to
then translate Ruby to another backend (e.g., Parrot, JVM, etc.). I’ll be
the first to admit that I don’t really understand it – I’m not a language
“specialist” that way.
-austin
···
On Wed, 30 Jul 2003 11:15:18 +0900, Robert Klemme wrote:
On Mon, 28 Jul 2003, Austin Ziegler wrote:
Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not find
quickly – that someone had started such a project. I realise right now
that this might be much slower, but it would seem to me to make it
easier to make something like Rite or some other bytecode system
possible, wouldn’t it?
Maybe I’m beeing stupid but I can’t see the advantage in doing this other
than intellectual challenge and interest. Is there any other?
Maybe I’m beeing stupid but I can’t see the advantage in doing this other
than intellectual challenge and interest. Is there any other?
robert
Forgive me if I’m wrong, but I thought that this was required to have
self-evaluating code. In other words, you could store off a segment of code
and call eval() on it and have it run for you on the fly. Isn’t some form
of eval() already available? What are its limitations?
Evaluates the Ruby expression(s) in aString. If aBinding is given,
the evaluation is performed in its context. The binding may be a
Binding object or a Proc object. If the optional file and line
parameters are present, they will be used when reporting syntax
errors. As of Ruby 1.8, local variables assigned within an eval are
only available after the eval if they were defined at the outter
scope before the eval executed. In this way eval has the same
scoping rules as blocks.
def getBinding(str)
return binding
end
str = "hello"
eval "str + ' Fred'" #=> "hello Fred"
eval "str + ' Fred'", getBinding("bye") #=> "bye Fred"
The big advantage is it forces someone to go through and fully
specify the syntax, which is quite valuable. It also would give you a
pluggable library you could use in, say, a syntax-highlighting IDE or
refactoring browser, since you can’t properly highlight syntax or
refactor if you can’t parse the code.
···
On Wed, 30 Jul 2003 11:15:18 +0900, Robert Klemme wrote:
On Mon, 28 Jul 2003, Austin Ziegler wrote:
Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not find
quickly – that someone had started such a project. I realise right now
that this might be much slower, but it would seem to me to make it
easier to make something like Rite or some other bytecode system
possible, wouldn’t it?
Maybe I’m beeing stupid but I can’t see the advantage in doing this other
than intellectual challenge and interest. Is there any other?
–
Dan
--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai dan@sidhe.org have teddy bears and even
teddy bears get drunk
Now, that is the first answer that convinces me - at least partially.
“Dan Sugalski” dan@sidhe.org schrieb im Newsbeitrag
news:a05210617bb4d01c0c2b7@[63.120.19.221]…
Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not
find
quickly – that someone had started such a project. I realise right
now
that this might be much slower, but it would seem to me to make it
easier to make something like Rite or some other bytecode system
possible, wouldn’t it?
Maybe I’m beeing stupid but I can’t see the advantage in doing this
other
than intellectual challenge and interest. Is there any other?
The big advantage is it forces someone to go through and fully
specify the syntax, which is quite valuable.
IMHO this has been done already.
It also would give you a
pluggable library you could use in, say, a syntax-highlighting IDE or
refactoring browser, since you can’t properly highlight syntax or
refactor if you can’t parse the code.
Yep, that’s an advantage!
Thanks!
robert
···
On Wed, 30 Jul 2003 11:15:18 +0900, Robert Klemme wrote:
On Wednesday, July 30, 2003, at 01:05 AM, Dan Sugalski wrote:
It also would give you a pluggable library you could use in, say, a
syntax-highlighting IDE or refactoring browser, since you can’t
properly highlight syntax or refactor if you can’t parse the code.
Over on the pragprog list, Ron Jeffries suggested that it might be
interesting to implement Ruby in Ruby. I thought – but could not find
quickly – that someone had started such a project. I realise right now
that this might be much slower, but it would seem to me to make it
easier to make something like Rite or some other bytecode system
possible, wouldn’t it?
Maybe I’m beeing stupid but I can’t see the advantage in doing this other
than intellectual challenge and interest. Is there any other?
Yes: the ones I came up with last night were somewhat novel, too.
A security sandbox, for running untrusted scripts.
Introspection into other scripts – if the interpreter has an
implementation in ruby, you can get at any part of the representation of
the script.
easy extension of the interpreter for testing, language development
and special uses.
The big advantage is it forces someone to go through and fully
specify the syntax, which is quite valuable.
IMHO this has been done already.
AFAIK the only full specification of the syntax is parse.y (and perhaps
some Japanese book too? I read somewhere that Ruby in a nutshell didn’t
have a proper syntax spec)
It also would give you a
pluggable library you could use in, say, a syntax-highlighting IDE or
refactoring browser, since you can’t properly highlight syntax or
refactor if you can’t parse the code.
Yep, that’s an advantage!
Another possibility (currently explored by the Pypy project and based on
Squeak’s VM) is translating the code, written in some sort of restricted
Ruby (perhaps Robert Feldt’s SRuby) to C, and them compiling. You could
get some serious optimization opportunities if some type inference or
profiling is done before.
···
On Wed, Jul 30, 2003 at 03:25:44PM +0900, Robert Klemme wrote:
Heh. You were one of the people I was thinking of.
···
At 22:00 +0900 7/30/03, Richard Kilmer wrote:
On Wednesday, July 30, 2003, at 01:05 AM, Dan Sugalski wrote:
It also would give you a pluggable library you could use in, say, a
syntax-highlighting IDE or refactoring browser, since you can’t
properly highlight syntax or refactor if you can’t parse the code.
–
Dan
--------------------------------------“it’s like this”-------------------
Dan Sugalski even samurai dan@sidhe.org have teddy bears and even
teddy bears get drunk
In message “Re: Ruby in Ruby” on 03/07/30, Mauricio Fernández batsman.geo@yahoo.com writes:
AFAIK the only full specification of the syntax is parse.y (and perhaps
some Japanese book too? I read somewhere that Ruby in a nutshell didn’t
have a proper syntax spec)
My first book contains pseudo BNF syntax of Ruby as of 1.4.0, but it’s
far from perfect. Besides Ruby syntax cannot be described in simple
BNF. You can extract rules from parse.y by using exyacc.rb in the
sample directory.
Mauricio Fernández batsman.geo@yahoo.com skrev den Wed, 30 Jul 2003
23:42:51 +0900:
It also would give you a
pluggable library you could use in, say, a syntax-highlighting IDE or
refactoring browser, since you can’t properly highlight syntax or
refactor if you can’t parse the code.
Yep, that’s an advantage!
Another possibility (currently explored by the Pypy project and based on
Squeak’s VM) is translating the code, written in some sort of restricted
Ruby (perhaps Robert Feldt’s SRuby) to C, and them compiling. You could
get some serious optimization opportunities if some type inference or
profiling is done before.
Imho, there would be many advantages to a RubyInRuby approach. You can
check my idea papers for RubyVM for a listing
(Data- och informationsteknik). In the long run I
actually think
you could get better or close to C performance from it since the
flexibility
and ease of experimentation it buys you makes more powerful analysis
and optimizations possible. However, that means that there must be a
critical
mass of folks willing to spend time on it.
Our RubyVM/SRuby thing never really got started. If I were to start
something
similar today I think I would aim for the Jalapeno/Java approach, ie.
skipping all intermediate steps and go directly from Ruby to machine code.
It sounds insane but it would be coolest and has the most opportunity for
optimizations in the long run. It would also make Ruby stand out somewhat
since Python is already doing a squeak-like PyPy. A plus with skipping
intermediaries is that they never really quite do what you want which
means you can’t use all your knowledge to make things better/faster etc.
Also you don’t need to learn all the quirks of an intermediate tool
(understanding gcc’s optimization effects for example which motivated c–).
The projects I would study the most for the back end stuff would be
Ocaml (excellent backend that generates assembler and then invokes gas,
resulting performance is top notch), C-- (excellent idea but have never
really taken off), and IBM’s Jalapeno.
When you have the flexibility that a RubyInRuby implementation gives you
you could also connect that to optimizarion techniques like genetic
algoritms
and programming and optimize the code based on real-world data. But that’s
more of bleeding edge programming language research than purely an
implementation project. I guess I’m way too much of a dreamer for my own
good…
