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