From: Sean Middleditch <elanthis@...>
Date: 2002-02-23T06:19:51+09:00
Subject: Re: Ruby's Future

Speaking of which, I remember and argument I brought up (and some of
Matz' comments on that)...

Ruby is not all that great for embedding in other apps.  yes, it works,
yes, you can do some cool things.  But, the Ruby API is designed for
extending Ruby... not for extending another program with Ruby.

I've been working with Lua lately (in MUDix, trying to get lite-weight
scripting), but it falls short, too.  I know some decent LISP variants
that are great, but I don't want to put LISP on a MUD user trying to
write macros for their game.  ^,^

Basically, here are the things that would be really great, for Rite
(Matz said he planned some of these things... dunno if they're still the
case or not):
1.  Precompiled blocks.  Let these byte-codes (hell, even an XML dump of
the code tree) be loadable without the full compiler.  Similarly, eval
would have be optional.  These *are* big bits of code that aren't needed
for apps that need simpler scripting.
2.  Reentrant.  Ruby/Rite should let multiple instances of the
interpreter run at in the same ( or even different ) threads.  The
usefulness with be apparant with the features below.
3.  Breakable execution.  I might want to let a script/Ruby thread run,
but I'd need my app to continuously run as well (think network or GUI
apps).  if the Ruby script has a bug (infinite loop), I don't want my
whole app to lock up.  The app should be able to say "run for 500
milliseconds tops" or "run for 300 expression evaluations."  The thread
could then be "frozen", the controlling app does its work, then lets the
script/thread continue.  The controlling app could do its own magic to
put time limits on threads (to get rid of the scripts with infinite
loops).
4.  Optional non-blocking system requests.  The core I/O and other
blocking requests (files and sockets) should have an option set for
breaking block.  Let's say a script wants to read a file, and the
request would block - instead, the script should be frozen (as in
request 3 above) and the controlling app runs.  When it lets the script
run again, it would check for blocking, read what it can, then break
again if it would block again.  This way, if a script needs system I/O,
it won't lock up the controlling application.
5.  Easily enable/disable core libs.  In some apps, it may be desirable
to completely and totally disable some of the core libs (like I/O), and
so on.  I would want to be able to not load the compiler/eval, not load
I/O, and not allow require, in some of the apps I would embed Ruby in. 
Lua lets you do this, which is nice.  (note: when I say disable I/O, I
mean *all* I/O... even print())
6.  Stackable contexts.  I.e., I should be able to make a global context
to hold global variables/functions/classes, and allow internal contexts
for added classes/variables.  This is more or less doable now with Ruby
threads, but not easily controlled by the embedding application.
7.  Cleaner API.  Things like rb_str_new2() are just ugly.  Of course,
something like ruby_string_new_from() is unaethetic (too long).  But,
API commands should be easily understand just by their name.  I lean
towards longer names over undescriptive names, but I know i'm odd on
that one.

In any event, I know that's a big list of requirements for what I'd want
in Ruby, but everyone has their list, right?  ~,^

I've implemented some 3 mini-languages in the last 4 months or so, each
with a majority of the above features.  Each of them easily beat Ruby in
terms of speed, load time, resource usage, etc.  Of course, they had
very tiny standard libraries (I'm just one person with a few months work
of work on them here.  ^,^).  I've scrapped each because large design
decisions in the beginning of the project more or less made it
impossible to meet all the requirements above (plus the other
requirements, like object oriented behaviour, and pass by reference). 
Obviously, it's not easy to get it right from the start.  ^,^

Anyways, are these features something that might be seen in Ruby
2.0/Rite?  If these features are possible/acceptable, but no one wants
to work on them... I might just decide to work on Ruby instead of
implementing "Sean Generic Mini Language Mark 537".

Sean Etc.

On Fri, 2002-02-22 at 15:51, Paulo Schreiner wrote:
> Hello, folks, what are the plans for the future of ruby? What new
> features are available in 1.7 and planned for 1.8?
> And for 2.0?
> And what is this Rite thing all about?
> 
> Thanks in advance,
> Paulo Schreiner
> 
> 
>