CRuby (Was: R)

ruby-talk
21

Actually, I agree, so I guess I’m in that minority
also.

I’d advocate three pieces for this (with the third
being the most controversial, I think).

  1. A traditional spec – part technicalese, part legalese
  2. A set of tests that must pass (could overlap greatly
    with Rubicon)
  3. A Ruby-in-Ruby “reference” implementation. Not for
    everyday use, but as a rigorous/readable/working
    description of the language.

In connection with #3, I’d advocate making future language
changes by altering the reference (R-in-R) interpreter,
getting it working, and then translating (manually?) to C
or whatever. (In other words, use Ruby as a prototyping tool
on itself, since Ruby coding is faster/easier.)

But that is not likely to happen, since the vast bulk of
work on the interpreter is still done by Matz, and my
impression is that he would not choose to work that way.

Hal

···

----- Original Message -----
From: dblack@candle.superlink.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Friday, October 04, 2002 1:35 PM
Subject: Re: CRuby (Was: R)

Yes – what I was getting at was the question of determining what
exactly “the full Ruby language” consists of :slight_smile: I think I’m in the
minority, in that I would actually advocate a formal definition.

22

dblack@candle.superlink.net wrote:

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?

How would you create a formal definition for something that doesn’t have
a name? :wink:

The closest thing we have now to a formal definition may be Rubicon, but
it isn’t exactly suited for use a definition.

/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!

23

dblack@candle.superlink.net wrote in message
news:Pine.LNX.4.44.0210041432070.2677-100000@candle.superlink.net…

Yes – what I was getting at was the question of determining what
exactly “the full Ruby language” consists of :slight_smile: 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.

May I join your minority?
It depends of course on how formal you want to be.

I’d like EBNF for the Ruby grammar more than anything.
A documentation of primary databases that bridge the gab between built-in
datatypes and objects: integer, boolean, float, nil, range types.
Operators such as ?, + etc.

Then a minimal list of classes without which Ruby isn’t Ruby like Object and
Class, Hash, Array, String.
Global constants ($ whatever, which I’d like to redelegate to an extension).

Mikkel

24
  1. A Ruby-in-Ruby “reference” implementation. Not for
    everyday use, but as a rigorous/readable/working
    description of the language.

I don’t really like that because it could easily become unprecise by
depending on some special case in the implementation it is running on.

The same danger applies to a must pass set of test cases, but I find this
more relevant and realistic - after all it makes it possible to compare
implementations even if it can’t always tell which one is correct.

Mikkel

25

You may very well turn out to be in the majority, but I feel differently.
If you had a formal definition of ruby, you’d end up having various
implementations, but never fully compatible.

IMHO that is the major problem of various languages: C, Scheme, etc.
haveyou. One language, one implementation is to me one of the strong
points of Perl, Java, Ruby, etc.

But if there were such a specification, I’d hope it was a minimal as
possible: define a small core set of features, using which the rest could
be implemented.

– Nikodemus

···

On Sat, 5 Oct 2002, MikkelFJ wrote:

exactly “the full Ruby language” consists of :slight_smile: I think I’m in the
minority, in that I would actually advocate a formal definition.

26

MikkelFJ wrote:

  1. A Ruby-in-Ruby “reference” implementation. Not for
    everyday use, but as a rigorous/readable/working
    description of the language.

I don’t really like that because it could easily become unprecise by
depending on some special case in the implementation it is running on.

That is really the situation right now. The “ruby” implementation is the
reference, and it’s not always clear what is essential behavior and what
is just side-effects.
But it isn’t that big a problem. We haven’t come across many problems
like that when creating a new implementation. My guess is that this
aspect was worse in creating the win32-port than it is in
re-implementing the interpreter.

/Anders

···

–

A n d e r s B e n g t s s o n | ndrsbngtssn@yahoo.se
Stockholm, Sweden |

Följ VM på nära håll på Yahoo!s officielle VM-sajt www.yahoo.se/vm2002
Håll dig ajour med nyheter och resultat, med vinnare och förlorare…

27

“Nikodemus Siivola” tsiivola@cc.hut.fi wrote in message
news:Pine.GSO.4.44.0210050007520.5486-100000@kekkonen.cs.hut.fi…

You may very well turn out to be in the majority, but I feel differently.
If you had a formal definition of ruby, you’d end up having various
implementations, but never fully compatible.

It’s like saying don’t make a dictionary over english words, someone might
starting using the words and get it wrong.

IMHO that is the major problem of various languages: C, Scheme, etc.
haveyou. One language, one implementation is to me one of the strong
points of Perl, Java, Ruby, etc.

Actually, C is one of the most cross-compatible languages - if there are
quirks, it mostly relates to a) before the ANSI standard, b) not yet
supporting C99 - but that doesn’t break existing functionality.
You can always find incompatible code due to platform dependencies but that
is beside the point.

C# is in the mono project is largely compatible with Microsofts
implementation, except for some libraries. This is thanks to the
specification Microsoft shipped along with the initial C# announcement.

Java certainly has more than one implementation.

But one implementation isn’t necessarily bad - I just don’t think the lack
of a specification should decide that - then you might end up like Pascal:
Pascal never really took over the world - mostly because Pascal source was
tied to the implemented under which it was developed.
I believe there are two Dylan implementations and one standard - and they
are mostly source compatible.

But if there were such a specification, I’d hope it was a minimal as
possible: define a small core set of features, using which the rest could
be implemented.

Yes - it shouldn’t become a Java giant spec. which subsequently needs to be
stripped many times to supported embedded Java. That said, the original Java
VM spec. is a fairly readable, but that doesn’t the libraries.

Mikkel

28

OTOH, a spec like ANSI C is so minimal that platform specific extensions are almost necessary… breaking the portability C is supposed to provide.

IMO, the spec should have 2 levels, one for the core features (the ansi c of ruby) and another one for the less basic features (the posix of ruby).

···

On Sat, 5 Oct 2002 08:08:53 +0900 “MikkelFJ” mikkelfj-anti-spam@bigfoot.com wrote:

But if there were such a specification, I’d hope it was a minimal as
possible: define a small core set of features, using which the rest could
be implemented.

Yes - it shouldn’t become a Java giant spec. which subsequently needs to be
stripped many times to supported embedded Java. That said, the original Java
VM spec. is a fairly readable, but that doesn’t the libraries.

Mikkel

–
To call me “awesome” is an understatement.