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.
–
Justin Johnson.
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.
–
Justin Johnson.
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.
–
Justin Johnson.
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.
–
Justin Johnson.
[matz]:
- 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: 10I 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”)
I like Python’s way of not distinguishing between named and “unnamed”
parameters. The above would be:
def initialize(cpu, os = "Windows", **info)
You could call it as
PC.new("P-III", "Linux", clock: "600MHz", hdd: "30G")
Or (with named parameters order is flexible):
PC.new(os: "Linux", cpu: "P-III", clock: "600MHz", hdd: "30G")
I like the flexibility of not having to decide which parameters
should be named/unnamed.
Obviously, this would require some major changes to ruby. Also,
there might be performance penalties. For example, you would have
to store the names of all parameters with the method (though
that would be nice for introspection).
// Niklas
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.
–
Justin Johnson.
yes = "yes" no = "no" x = nil p x.nil? yes: noHmm. Not interesting?
Well, the main thing here is that the ‘?’ and ‘:’ are part of the
accompanying symbols so they would be classed as part of the symbol name.
Ruby already does this for symbols ending in ‘?’. I don’t see what the
problem is. If we were talking about a C/C++ parser then that’s a different
matter…
Also, ‘yes:’ would only be valid inside a method argument list and so would
cause a parsing error in this case.
–
Justin Johnson.
yes = "yes" no = "no" x = nil p x.nil? yes: noHmm. Not interesting?
Well, the main thing here is that the ‘?’ and ‘:’ are part of the
accompanying symbols so they would be classed as part of the symbol name.
Ruby already does this for symbols ending in ‘?’. I don’t see what the
problem is. If we were talking about a C/C++ parser then that’s a different
matter…
Also, ‘yes:’ would only be valid inside a method argument list and so would
cause a parsing error in this case.
–
Justin Johnson.
yes = "yes" no = "no" x = nil p x.nil? yes: noHmm. Not interesting?
Well, the main thing here is that the ‘?’ and ‘:’ are part of the
accompanying symbols so they would be classed as part of the symbol name.
Ruby already does this for symbols ending in ‘?’. I don’t see what the
problem is. If we were talking about a C/C++ parser then that’s a different
matter…
Also, ‘yes:’ would only be valid inside a method argument list and so would
cause a parsing error in this case.
–
Justin Johnson.
yes = "yes" no = "no" x = nil p x.nil? yes: noHmm. Not interesting?
Well, the main thing here is that the ‘?’ and ‘:’ are part of the
accompanying symbols so they would be classed as part of the symbol name.
Ruby already does this for symbols ending in ‘?’. I don’t see what the
problem is. If we were talking about a C/C++ parser then that’s a different
matter…
Also, ‘yes:’ would only be valid inside a method argument list and so would
cause a parsing error in this case.
–
Justin Johnson.
ts decoux@moulon.inra.fr writes:
I always liked that idea, and was never too sure why it never got
discussed further.You must change the API for extensions
I don’t think so. The change I was discussing was that
pierre(a, :b => 1, :c => 2)
could instead be written
pierre a b: 1 c: 2
so that the b: and c: would be picked up and converted to a hash as
now. I think it’s parsable, and it doesn’t change the internals at
all.
Cheers
Dave
well, i wasn’t going to go into it, but…i’ll be brief:
function arguments are equivalent to arrays, hence
f(x, y, z) ==is like== f[x, y, z]
why do we have two structures for the same thing: () and ? a waste of
a deliminator!
following through with the idea, would it not be nice to do something
like:
f{a=>x, b=>y, c=>z}
though in my opinion {} should be for procs only, then we wouldn’t need
to ever say Proc.new.
and the construct a => x. what is that really? should it not be its own
Class?
and other stuff like that…
~transami
On Tue, 2002-07-30 at 09:14, Michael Campbell wrote:
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.
What about leaving the current API as is, and adding new methods to the
API that support named parameters (perhaps one method to “name” the
parameters and another to call methods using named parameters)?
Paul
On Wed, Jul 31, 2002 at 12:13:10AM +0900, ts wrote:
I always liked that idea, and was never too sure why it never got
discussed further.You must change the API for extensions
In the case of C++, there is a C++ standard and a committee who composed
that standard.
There’s also no compiler in existence that is 100% compliant with that
standard. As a result, most of us either rely on the language features
that the greatest number of compilers support or just write for a
specific compiler.
Sometimes, there are extra features a compiler supports that come in
handy (g++, for example, supports the typeof operator). Some of these
features, if they are useful enough, often have a pretty good chance of
making their way into the standard.
Paul
On Wed, Jul 31, 2002 at 01:44:50AM +0900, Michael Campbell wrote:
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?
philp,
i agree. that makes more sense.
you point out an important distinction between assignment, which is what
your doing when you pass parameters, ans hash association/pairs.
On Tue, 2002-07-30 at 11:13, Philipp Meier wrote:
I’d prefer “=” instead of “:” because passing parameters is a kind of
assignment in the scope of the functions body:
–
~transami
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.
Interesting, but what are your criteria for
a “pure” language implementation? How does
multithreading capability make it non-pure?
Does regular expression capability make it
non-pure?
By the way: Your messages seem to be showing
up two or three times on the list. A bug in
your posting software perhaps?
Cheers,
Hal
----- Original Message -----
From: “Justin Johnson” justinj@mobiusent.com
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 1:16 PM
Subject: Re: Ruby Language Q’s
Obviously, this would require some major changes to ruby. Also,
there might be performance penalties. For example, you would have
to store the names of all parameters with the method (though
that would be nice for introspection).
ruby know the name of the parameters otherwise it will not possible to
write this
pigeon% ruby -riis -e 'def x(a, b = 12, &d) end; puts dump Object, :x'
def x(a, b = 12, &d)
end
pigeon%
Guy Decoux
Obviously, this would require some major changes to ruby. Also,
there might be performance penalties. For example, you would have
to store the names of all parameters with the method (though
that would be nice for introspection).
You already have the parameter symbols in the method definition.
def my_method( pos, width, height )
…
end
my_method( pos: 10, width: 20, height: 30 )
The place you don’t have them (at the moment) is with native C functions as
Ruby methods:
VALUE rb_my_method( VALUE self, VALUE arg1 )
{
…
}
Thinking aloud: would the argument order be taken care of at parsing time?
my_method( height: 30 width: 20, pos: 10 )
is reordered to:
my_method( pos: 10, width: 20, height: 30 )
or even:
my_method( 10, 20, 30 )
–
Justin Johnson.
Obviously, this would require some major changes to ruby. Also,
there might be performance penalties. For example, you would have
to store the names of all parameters with the method (though
that would be nice for introspection).
You already have the parameter symbols in the method definition.
def my_method( pos, width, height )
…
end
my_method( pos: 10, width: 20, height: 30 )
The place you don’t have them (at the moment) is with native C functions as
Ruby methods:
VALUE rb_my_method( VALUE self, VALUE arg1 )
{
…
}
Thinking aloud: would the argument order be taken care of at parsing time?
my_method( height: 30 width: 20, pos: 10 )
is reordered to:
my_method( pos: 10, width: 20, height: 30 )
or even:
my_method( 10, 20, 30 )
–
Justin Johnson.
Hello –
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.
But that just takes us back to the question: what is “Ruby”? In other
words: what is this antecedent, pure, Ur-Thing onto which Matz has
added all these other things? I can’t identify this thing, so I tend
to look at the distribution as definitively “Ruby” – not atomic (when
it comes to library stuff and extensions), but definitive in language
features.
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.
Or: the standard could be defined as drop-in replaceability (in both
directions) for current stable Ruby. (Mind you, that’s unofficial 
Or maybe passing the Rubicon test suite.
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.
It all depends how you define “the language itself” Again, I tend
to define it as “this thing that Matz wrote and calls ‘Ruby’”.
Anyway, in case it’s not clear in the midst of all my ostensible
philosophizing, I do look forward to seeing the project.
David
On Wed, 31 Jul 2002, Justin Johnson wrote:
–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav