On Sat, Sep 28, 2002 at 03:02:23PM +0900, Nikodemus Siivola wrote:
> 
> On Fri, 27 Sep 2002, William Djaja Tjokroaminata wrote:
> 
> > designed more like a "superset" of Ruby, the addition being some hints on
> > type checking.  How strong the type checking is can be controlled by a
> > parameter, in which case type_check_level == 0 reduces "R" to Ruby.  Sure,
> > it will not be as fast and efficient as Ruby, but for experimentation I
> 
> Actually the idea is almost the opposite: Ruby should be dynamic. R Should
> be a statically typed _subset_ of Ruby. Ruby should be the flexible human
> oriented language, while R would be it's faster, but less flexible cousin.
> 
> > C/C++/Java programmers to learn this new language.  Here I am just trying
> 
> Nonononono -- R should be a statically typed compiled language that is easy
> for _Ruby_ programmers to learn.
> 
> For example, from what I have understood of your network simulator, if R
> existed, you would keep the Ruby part in Ruby, and replace the C-part with
> R. Ruby for people, R for speed.

OK, I'll toy a little with the nature of the R language.

Were R to exist, I think it would be sensible that it should
 * be compiled: at the beginning simple translation to C would make it 
 * be less dynamic than Ruby: closed classes. 
   That way method lookup would be faster.
 * have no GC, or at least have one separed from Ruby's main one.
   Important as the object model would be different.
 * have lower-level classes (perhaps as literal values) for low-level
   arrays and such stuff, thus having C-like types wrapped in real
   classes (otherwise we end up with C w/ different syntax)
 * perhaps be statically typed? (but types could be inferred so it feels
   more like Ruby, by not having to declare them always)

It could also be procedural (not OOP), but being able to create classes
would ease mapping them to Ruby. And otherwise it would be too similar
to C, and nothing would be gained.

Some other things not so important would be
 * allowing generic programming (so we don't miss Ruby's dynamic
   typing too much)
 * complete OOP, but inheritance, data hiding, etc... don't seem to be
   too important for R.

Things to throw away:
 * "virtual" methods
 * reflection
 * open classes
 * high-level classes such as Array, Hash, Class, etc (in fact (almost)
   all of Ruby's!)
 * GC? (see above)
 * exceptions (?) -> would have to be implemented w/ longjmp and that
   would break Ruby's ones
 
It is important for R to stay as close as possible to Ruby, that's its
raison d'?tre. Ideally, it would be identical but for the dynamic
features of Ruby and the presence of lower-level standard types.

Is my first take on R well oriented?

And now the main questions: Why would anybody use it? What should we do to
make it a better option than C for writing Ruby extensions?
I believe this comes down to identifying the issues people face when
writing extensions w/ C and figuring out how to avoid them in R...


-- 
 _           _                             
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ 
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
	Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
  
Sic transit discus mundi
	-- From the System Administrator's Guide, by Lars Wirzenius