CRuby = subset of Ruby + typed methods + compiler to C
The main difference is the typing of functions and their
arguments. The generated source is intended to be linked with the Boehm GC.
By default methods return values of the same type as the receiver, but this
behaviour can be overridden with the -> operator.
The current “implementation” is definitely only a toy, but those interested
in the consept are welcome to the sources. I am going to mull over this for
a while further and either dump the sources on my homepage and leave it at
that – or register a Savannah project.
The next stage would be a proof-of-concept implementation that
automagically generates a ruby-api to the generated C-code.
CRuby = subset of Ruby + typed methods + compiler to C
The name CRuby could be a little confusing. The Python people use
CPython to refer to the original Python interpreter, as opposed to the
Java implementation Jython (formerly JPython).
We have a Java implementation too, namely JRuby, but no widely accepted
name for the original Ruby interpreter.
Thursday, October 03, 2002, 9:41:53 PM, you wrote:
CRuby = subset of Ruby + typed methods + compiler to C
The main difference is the typing of functions and their
arguments. The generated source is intended to be linked with the Boehm GC.
By default methods return values of the same type as the receiver, but this
behaviour can be overridden with the → operator.
The current “implementation” is definitely only a toy,
i don’t see “char*–>String*” converter, nor support for
variable-sized arguments list
but those interested
in the consept are welcome to the sources.
We have a Java implementation too, namely JRuby, but no widely
accepted
name for the original Ruby interpreter.
Maybe I’m being obtuse here, but I always considered the original
Ruby interpreter to be called “ruby”. I wasn’t aware there were
other names out there vying for contention.
CRuby = subset of Ruby + typed methods + compiler to C
The name CRuby could be a little confusing. The Python people use
CPython to refer to the original Python interpreter, as opposed to the
Java implementation Jython (formerly JPython).
We have a Java implementation too, namely JRuby, but no widely accepted
name for the original Ruby interpreter.
What about RubyC (pronounced as Rubik)?
···
–
Giuseppe “Oblomov” Bilotta
“E la storia dell’umanità, babbo?”
“Ma niente: prima si fanno delle cazzate,
poi si studia che cazzate si sono fatte”
(Altan)
(“And what about the history of the human race, dad?”
“Oh, nothing special: first they make some foolish things,
then you study which foolish things have been made”)
Maybe I’m being obtuse here, but I always considered the original
Ruby interpreter to be called “ruby”. I wasn’t aware there were
other names out there vying for contention.
Michael,
I may be the obtuse one, since I had to look up the word “obtuse” in my
English-Swedish dictionary.
Since the interpreter and the language share the same name, how do you
know if “ruby” refers to the interpreter or language?
Curiosity: To see how it would be done.
Curisoity is always a very good reason;
Study: A C-project I am working on has me more and more convinced that
what I really want is a high-level C-generator. This was the first
experiment.
I was once experimenting with mapping C-code to FPGAs, but
6 years ago FPGA had a very limited number of gates (wire was the real
problem). I got really frustated as my nice code didn’t fit at once as it
was not always so easy to work out the exact size and wiring before, so
I started writing a C-code generator to do a sort of binary-search of
the largest-possible size. That was brute-force.
Whare are you working on.
Speed: I have / had no concrete goals, and no benchmarks as of yet, but
I would expect to land somewhere between Ruby and proper C.
Makes sense and is a nice way of shipping Ruby applications.
On Fri, Oct 04, 2002 at 03:23:20AM +0900, Anders Bengtsson wrote:
Michael Campbell wrote:
Maybe I’m being obtuse here, but I always considered the original
Ruby interpreter to be called “ruby”. I wasn’t aware there were
other names out there vying for contention.
Michael,
I may be the obtuse one, since I had to look up the word “obtuse” in my
English-Swedish dictionary.
Since the interpreter and the language share the same name, how do you
know if “ruby” refers to the interpreter or language?
–
/ Alexander Bokovoy
Thursday, October 03, 2002, 10:23:20 PM, you wrote:
Michael Campbell wrote:
Maybe I’m being obtuse here, but I always considered the original
Ruby interpreter to be called “ruby”. I wasn’t aware there were
other names out there vying for contention.
Since the interpreter and the language share the same name, how do you
know if “ruby” refers to the interpreter or language?
in the ruby, “Ruby” and “ruby” is not the same things :)))
Maybe I’m being obtuse here, but I always considered the original
Ruby interpreter to be called “ruby”. I wasn’t aware there were
other names out there vying for contention.
Michael,
I may be the obtuse one, since I had to look up the word “obtuse” in my
English-Swedish dictionary.
Since the interpreter and the language share the same name, how do you
know if “ruby” refers to the interpreter or language?
Since at the moment there’s no formal definition of Ruby abstracted
from the interpreter (ruby), I think having them share the name is the
clearest thing. It’s hard (for me) to know what it would mean, as of
now, to say, “I’m writing a program in Ruby,” except that the program
would run under ruby. (Not that that means it would not run under,
e.g., JRuby.)
Looks like you’re right
It’s rather obvious about what (the interpreter or the language)
the given discussion is from a context of sentence. Isn’t it ?
···
On Fri, Oct 04, 2002 at 03:38:57AM +0900, Alexander Bokovoy wrote:
Since the interpreter and the language share the same name, how do you
know if “ruby” refers to the interpreter or language?
Similar to perl and Perl cases?
–
[ Wojtek gminick Walczak ][ http://gminick.linuxsecurity.pl/ ]
[ gminick (at) hacker.pl ][ gminick (at) underground.org.pl/ ]
Since the interpreter and the language share the same name, how do you
know if “ruby” refers to the interpreter or language?
Since at the moment there’s no formal definition of Ruby abstracted
from the interpreter (ruby), I think having them share the name is the
clearest thing. It’s hard (for me) to know what it would mean, as of
now, to say, “I’m writing a program in Ruby,” except that the program
would run under ruby. (Not that that means it would not run under,
e.g., JRuby.)
An interesting corner case is when you write a script in a language that
is clearly Ruby, but uses Java APIs not available in “ruby”.
But anyway, I think we can manage with “Ruby” for the language and
“ruby” for the original interpreter for most uses.
/Anders
···
–
A n d e r s B e n g t s s o n | ndrsbngtssn@yahoo.se
Stockholm, Sweden |
Gratis e-mail resten av livet på www.yahoo.se/mail
Busenkelt!
Since at the moment there’s no formal definition of Ruby abstracted
from the interpreter (ruby), I think having them share the name is the
clearest thing. It’s hard (for me) to know what it would mean, as of
now, to say, “I’m writing a program in Ruby,” except that the program
would run under ruby. (Not that that means it would not run under,
e.g., JRuby.)
It’s really simple: file names as in " require ‘graph’ " … a typically in
lowercase in Ruby, an so is the ruby interpreter.
Ruby as a concept is like a class of programs and is therefore named in
uppercase like “Graph.new”
Assuming JRuby covers the full Ruby language, both ruby and jruby would
interpret Ruby programs.
However, to paraphrase the introduction from “The Ruby Way”: mr. Fulton:
"When all nouns in german begin with uppercase, then why is “deutsch” in
lowercase - it’s the name of the language… The professor answered: “Don’t
fight it”. I liked that.
Except “deutsch” is an adjective different from the name of the german
language “Deutsch”. It’s an obvious mistake - germans don’t have exceptions
to rules
Since at the moment there’s no formal definition of Ruby abstracted
from the interpreter (ruby), I think having them share the name is the
clearest thing. It’s hard (for me) to know what it would mean, as of
now, to say, “I’m writing a program in Ruby,” except that the program
would run under ruby. (Not that that means it would not run under,
e.g., JRuby.)
It’s really simple: file names as in " require ‘graph’ " … a typically in
lowercase in Ruby, an so is the ruby interpreter.
I figured it was because unix programs are usually lowercase.
Whatever
Ruby as a concept is like a class of programs and is therefore named in
uppercase like “Graph.new”
Assuming JRuby covers the full Ruby language, both ruby and jruby would
interpret Ruby programs.
Yes – what I was getting at was the question of determining what
exactly “the full Ruby language” consists of I think I’m in the
minority, in that I would actually advocate a formal definition.
Otherwise it’s hard, for me at least, to think of ruby as just one of
arbitrarily many ways to gain access to Ruby.
Since the interpreter and the language share the same name, how do you
know if “ruby” refers to the interpreter or language?
Since at the moment there’s no formal definition of Ruby abstracted
from the interpreter (ruby), I think having them share the name is the
clearest thing. It’s hard (for me) to know what it would mean, as of
now, to say, “I’m writing a program in Ruby,” except that the program
would run under ruby. (Not that that means it would not run under,
e.g., JRuby.)
An interesting corner case is when you write a script in a language that
is clearly Ruby, but uses Java APIs not available in “ruby”.
That’s where I get caught in the philosophical question: without a
formal language definition, how can a program be said to be written in
Ruby, if it doesn’t run under ruby?
I don’t think this is likely to be a practical problem, since for any
given project (e.g., JRuby), things will be documented, and people
will know where they diverge, if at all. But it still stops me from
treating “Ruby” as an abstraction (yet).
