After several rewrites of my GC memory code and implementing most of the
code for Ruby runtime, I’m now posed with the issues of parsing and language
specification. All the class/module/object/methods/vars code is in place.
It’s cool to see the arms and legs working…now to put the heart in place!
Goals:
Use Bison to generate parser - if I can’t integrate that well with C++,
use PCCTS instead.
Generate AST - this is kind of how Ruby executes now, from a code tree.
Generate VM Bytecode. Stack/register based connundrum.
Matz - I’ve enjoyed trawling through 7 years of history in the form of your
original Ruby C code!
You weren’t kidding when you said the current Ruby interpreter is
astonishingly complex!
I’m hoping that by creating a solid C++ version, I’ve improved the API and
reduced the number of programming errors possible through safer type
checking etc.
I’d like to hear from any Ruby programmers here what they would change about
the implementation - the language and it’s built-in features rather than any
support libraries. Some of my thoughts:
Ruby comes with a hell of a lot of features built-in, like the Perl $
variables and so on. Shouldn’t all this perhaps be classed as an extension?
I kind of like the idea of a very clean and elegant language out of the box.
I like the idea of named method parameters (ala Smalltalk, Objective-C).
There was a discussion elsewhere showing something similar using hash
tables. With a bit of syntactic sugar… :var => 10 could be var: 10
Ruby comes with a hell of a lot of features built-in, like the Perl $
variables and so on. Shouldn’t all this perhaps be classed as an extension?
I kind of like the idea of a very clean and elegant language out of the box.
This would be nice if it can be done without impacting performance a
whole lot. I wonder if plugging in $_ could be done tidily, though.
I like the idea of named method parameters (ala Smalltalk, Objective-C).
There was a discussion elsewhere showing something similar using hash
tables. With a bit of syntactic sugar… :var => 10 could be var: 10
I always liked that idea, and was never too sure why it never got
discussed further.
After several rewrites of my GC memory code and implementing most of the
code for Ruby runtime, I’m now posed with the issues of parsing and language
specification. All the class/module/object/methods/vars code is in place.
It’s cool to see the arms and legs working…now to put the heart in place!
Goals:
Use Bison to generate parser - if I can’t integrate that well with C++,
use PCCTS instead.
Have you considered using Spirit (http://spirit.sourceforge.net/)?
Spirit lets you write your EBNF grammar as C++ code, by using template
tricks and overloaded operators. Very nifty.
I’m hoping that by creating a solid C++ version, I’ve improved the API and
reduced the number of programming errors possible through safer type
checking etc.
What exactly do you mean by “safer type checking”? This statement can
mean lots of different things.
Also, don’t forget to consider exception-safety. It’s important in
Ruby, since almost any function can raise an exception. It would be
even more important in a C++ implementation of Ruby.
Paul
···
On Tue, Jul 30, 2002 at 11:55:54PM +0900, Justin Johnson wrote:
I’d like to hear from any Ruby programmers here what they would change about
the implementation - the language and it’s built-in features rather than any
support libraries.
I wonder if I could interject a sort of philosophical question as a
preliminary here. It’s something I’ve never understood, and I want
to, because I think having different implementations of Ruby is a very
cool thing.
The question being… what exactly is an implementation of Ruby? I
know this has come up before, but I still don’t have a handle on it.
For example, if your interpreter lets me use named parameters, it
ceases to be a drop-in replacement for Ruby. To my way of thinking,
it then by definition ceases to be an implementation of Ruby.
This isn’t about the merits of the changes you (or other implementors)
might make. My concern is what happens when there are various Rubies
around (whether or not they are more/less/equally elegant than/as
Ruby), and people start writing ostensible Ruby code that requires a
certain Ruby implementation.
When I brought this up briefly a while back that Matz didn’t seem as
worried about it as I am I’m only worried in the sense that I
don’t yet get how an “implementation of Ruby” is defined, and
therefore don’t see how differently behaving Rubies would interact.
i think matz himself once suggested he wish he hadn’t put all those perl
like constructs in there. can’t remember where that was, some interview.
and i have to agree. i stay clear of them most of the time myself.
by the way, what is your goal with your version of ruby? i’ve been
considering doing some language experimentation myself using the Ruby
source.
···
On Tue, 2002-07-30 at 08:55, Justin Johnson wrote:
Ruby comes with a hell of a lot of features built-in, like the Perl $
variables and so on. Shouldn’t all this perhaps be classed as an extension?
I kind of like the idea of a very clean and elegant language out of the box.
After several rewrites of my GC memory code and implementing most of the
code for Ruby runtime, I’m now posed with the issues of parsing and language
specification. All the class/module/object/methods/vars code is in place.
It’s cool to see the arms and legs working…now to put the heart in place!
Good to hear that!
Matz - I’ve enjoyed trawling through 7 years of history in the form of your
original Ruby C code!
Actually more than 9 years. Someone got to rewrite the code.
I’m not sure yet it is going to be yours. But it is a good news
anyway.
Ruby comes with a hell of a lot of features built-in, like the Perl $
variables and so on. Shouldn’t all this perhaps be classed as an extension?
I kind of like the idea of a very clean and elegant language out of the box.
Interesting idea.
I like the idea of named method parameters (ala Smalltalk, Objective-C).
There was a discussion elsewhere showing something similar using hash
tables. With a bit of syntactic sugar… :var => 10 could be var: 10
I want something more, for example:
class PC
def initialize(cpu:, os: “Windows”, **info) @cpu = cpu # “cpu” is a mandatory named arg @os = os # “os” is with the default value @info = info # symbol=>value hashtable
end
end
PC.new(os: “Linux”, cpu: “P-III”, clock: “600MHz”, hdd: “30G”)
matz.
···
In message “Ruby Language Q’s” on 02/07/30, “Justin Johnson” justinj@mobiusent.com writes:
I like the idea of named method parameters (ala Smalltalk, Objective-C).
There was a discussion elsewhere showing something similar using hash
tables. With a bit of syntactic sugar… :var => 10 could be var: 10
–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)
I like the idea of named method parameters (ala Smalltalk,
Objective-C).
There was a discussion elsewhere showing something similar using
hash
tables. With a bit of syntactic sugar… :var => 10 could be
var: 10
I always liked that idea, and was never too sure why it never got
discussed further.
Would this be a required feature, or optional? Would I be REQUIRED
to name all parameters? That would break, well, all existing code,
I’d think.
Well, see what happened to lisp, got blown up, changed, incompatible,
common lisp came, and slowly all were walking back to that - but on
the good side, scheme and T were born (and again various dialects)
I suppose having something like the r5rs for ruby (r1rr?:), and marking
own extensions as exactly that - extensions, would help. Especially if
things which can be brought in with libraries and other ruby modules are
offered as modules to the ‘true’ ruby (i.e. one that is only “r1rr” compliant).
Most manuals of scheme implementations e.g. refer to r4/5rs for all
the stuff, and document things not implemented or extensions. This way
you can, if you (have to) port from one imp to another, easily locate
all possible problems. Now if you offered modules which offer functionalities
in other ruby interpreters, and say "when you go from ruby-X to matz-ruby,
just require ‘ruby-X-compliance’, well …
-Martin
···
On Wed, Jul 31, 2002 at 12:29:58AM +0900, David Alan Black wrote:
[…]
The question being… what exactly is an implementation of Ruby? I
know this has come up before, but I still don’t have a handle on it.
For example, if your interpreter lets me use named parameters, it
ceases to be a drop-in replacement for Ruby. To my way of thinking,
it then by definition ceases to be an implementation of Ruby.
This isn’t about the merits of the changes you (or other implementors)
might make. My concern is what happens when there are various Rubies
around (whether or not they are more/less/equally elegant than/as
Ruby), and people start writing ostensible Ruby code that requires a
certain Ruby implementation.
I’m relatively new to Ruby, so pardon me if I’m not making much
sense.
For a few months I’ve been reading Ruby related mailing lists,
I repeatedly saw people’s opnions split into two: one group likes
to make Ruby clean and equipped cool features, and the other more
worried of compatibility issues.
I, as one, was attracted to the changes Ruby brought into the
programming communities and would love to see it more agressively
improve itself as a language. However, I see its need to be
maintained. I believe the usual solution to this is to split
the implementation into two versions, one for maintenance and
one with incompatible features. Is there such a thing like
’Next Generation Ruby’, being developped and / or discussed
separate from the current maintenance-mode implementation?
Or is the plan to make gradual changes to the current
implementation so that there doesn’t have to be two parallel
development work?
It seems there are already alternative implementation of Ruby
being discussed. Now may be a good time to discuss
Next-Generation and agree on a same set of features.
Developping a new language specification would be nice. Then,
a set of test cases would be necessary too.
Ruby comes with a hell of a lot of features built-in, like the Perl $
variables and so on. Shouldn’t all this perhaps be classed as an extension?
I kind of like the idea of a very clean and elegant language out of the box.
Interesting idea.
I think so too.
class PC
def initialize(cpu:, os: “Windows”, **info) @cpu = cpu # “cpu” is a mandatory named arg @os = os # “os” is with the default value @info = info # symbol=>value hashtable
end
end
PC.new(os: “Linux”, cpu: “P-III”, clock: “600MHz”, hdd: “30G”)
This isn’t about the merits of the changes you (or other
implementors)
might make. My concern is what happens when there are various
Rubies
around (whether or not they are more/less/equally elegant than/as
Ruby), and people start writing ostensible Ruby code that requires
a
certain Ruby implementation.
I’m not sure this is relevant, but the gnu c++ compiler allows a
number of things that “normal” c++ does not; how do they handle that?
I’d prefer “=” instead of “:” because passing parameters is a kind of
assignment in the scope of the functions body:
class PC
def initialize(cpu, os=“Windows”, **info) @cpu = cpu # “cpu” is a mandatory named arg @os = os # “os” is with the default value @info = info # symbol=>value hashtable
end
end
PC.new(os=“Linux”, cpu=“P-III”, clock=“600MHz”, hdd=“30G”)
Although I must admit that this is incompatible to how ruby works
currently:
On Wed, Jul 31, 2002 at 01:27:57AM +0900, Yukihiro Matsumoto wrote:
In message “Ruby Language Q’s” > on 02/07/30, “Justin Johnson” justinj@mobiusent.com writes:
I like the idea of named method parameters (ala Smalltalk, Objective-C).
There was a discussion elsewhere showing something similar using hash
tables. With a bit of syntactic sugar… :var => 10 could be var: 10
I want something more, for example:
class PC
def initialize(cpu:, os: “Windows”, **info) @cpu = cpu # “cpu” is a mandatory named arg @os = os # “os” is with the default value @info = info # symbol=>value hashtable
end
end
PC.new(os: “Linux”, cpu: “P-III”, clock: “600MHz”, hdd: “30G”)
The question being… what exactly is an implementation of Ruby? I
know this has come up before, but I still don’t have a handle on it.
That is a very good question. I think Matz’s implementation is Ruby with
lots of practical and script-useful add-ons. It’s an incredibly pragmatic
tool. A lot of this is owed to the language concepts.
Point is, because there’s only one implementation, there isn’t an
official(?) language standard yet. Ruby is not an academic ideal, it’s a
tangible tool.
I’m hoping to implement a pure language version. No perlisms, no FileIO, no
SAFE, no threads, just classes, modules, arrays, strings…enough for the
language itself to be complete.
I think the language has more potential than just competing with
Perl/Python.
The question being… what exactly is an implementation of Ruby? I
know this has come up before, but I still don’t have a handle on it.
That is a very good question. I think Matz’s implementation is Ruby with
lots of practical and script-useful add-ons. It’s an incredibly pragmatic
tool. A lot of this is owed to the language concepts.
Point is, because there’s only one implementation, there isn’t an
official(?) language standard yet. Ruby is not an academic ideal, it’s a
tangible tool.
I’m hoping to implement a pure language version. No perlisms, no FileIO, no
SAFE, no threads, just classes, modules, arrays, strings…enough for the
language itself to be complete.
I think the language has more potential than just competing with
Perl/Python.
by the way, what is your goal with your version of ruby? i’ve been
considering doing some language experimentation myself using the Ruby
source.
The goal is to reduce back down to the pure language. Practically, I need
something that I can embed although there’s no reason why it wouldn’t make a
strong stand alone version.
Once I’ve got a fast, well-written pure implementation, I’ll be in a better
position to see where it can go next.
by the way, what is your goal with your version of ruby? i’ve been
considering doing some language experimentation myself using the Ruby
source.
The goal is to reduce back down to the pure language. Practically, I need
something that I can embed although there’s no reason why it wouldn’t make a
strong stand alone version.
Once I’ve got a fast, well-written pure implementation, I’ll be in a better
position to see where it can go next.
by the way, what is your goal with your version of ruby? i’ve been
considering doing some language experimentation myself using the Ruby
source.
The goal is to reduce back down to the pure language. Practically, I need
something that I can embed although there’s no reason why it wouldn’t make a
strong stand alone version.
Once I’ve got a fast, well-written pure implementation, I’ll be in a better
position to see where it can go next.
I’m only worried in the sense that I