Re: Ruby's Future

On Fri, 2002-02-22 at 16:57, Paul Brannan wrote:
> On Sat, Feb 23, 2002 at 06:19:51AM +0900, Sean Middleditch wrote:
> > 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.
> 
> eval is optional.  Instead of doing this:
>   eval(x)
> 
> you can do this:
>   my_proc = eval("proc { |a,b,c| #{x} }")
>   my_proc.call(a, b, c)
> 
> For tasks that aren't computationally intensive, I notice a 4x
> improvement in speed doing this.

Both of those solutions used eval().  ^,^  It's not the speed of eval
I'm worried about, it's the point of having the parser/compiler loaded
into memory at all times (also incurring a bigger startup time on
stand-alone interpreter).

Not to mention eval() is rather insecure and ugly.  Assuming the parse
tree/byte code is stored sanely, a very lite and simple API can be
generated that will allow building/manipulating the tree.  That could be
made into a loadable module (not everyone needs it).  Or, hell, just put
the parser and eval() into a loadable module - precompiled byte code
files will run much faster, and source files won't suffer too much of a
penalty at compile time.

> 
> > 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.
> 
> Definitely.  And get rid of those global variables.
> 
> > 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).
> 
> Hmm... is this what rb_thread_wait_for does?  There's no inline
> documentation for many of these functions, so sometimes it's hard to
> tell.
> 
> The way I handle this is with an ACE reactor; the reactor is wrapped so
> I can add Ruby IO objects to the reactor.  99% of the time, my
> application is sitting inside the reactor event loop.  When data is
> available on an fd, a callback is made, either into C++ code or Ruby
> code, depending on who registered the fd.  Ruby threads can be running
> in the background while the reactor is sitting in an rb_thread_select
> loop.
> 
> If a callback hangs, then the program will hang, but if a background
> thread hangs, then I'm still safe.

I didn't know Ruby had that in there.  Indeed, like you said, it is
mostly undocumented.  But, you also mention hangs are possible...
scripts, which are possibly entered by the user at runtime (depending on
your application), should *never* have the ability to hang or crash your
application.  If user data can ever cause a hang or crash, I consider it
a serious bug ... user data cannot be trusted to be safe or accurate.

> 
> > 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.
> 
> Would something like:
> 
>   io.fcntl(Fcntl::F_SETFL, Fcntl::O_NONBLOCK)
> 
> work?
> 
> (Granted, a nice wrapper library around this would be nice)

Well, again, that would make Ruby non-block... But say I have a script
running in my app.  My app needs to respond to events (lets say user
input).  If Ruby is blocking, the script runs, the whole app is
unresponsive until the script is done blocking.  With the above code,
the script would have to run in a loop or something, constantly checking
the fd, which would not in any way necessary return execution context to
the embedding app, and it would actually just cause an increae in CPU
usage.

> 
> > 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())
> 
> I don't know why you'd want to do this, but why can't you simply iterate
> over all the methods in IO and undef them?

First, I shouldn't have to do that.  Second, that is a memory and CPU
waste.  Third, that won't totally get rid of them.

The reason is fairly simple.. you can quite easily have applications in
which I/O is *bad* (user scripts running on a server, in which you don't
want the scripts to access files, load modules that might circumvent
security, or send I/O to the system (for a number of reasons - log
contamination if you log stdout/stderr, performance hit for I/O access,
and so on).

Those libraries are not necessary for an application to run, they
shouldn't be there (libc is not built into C - it is merely a standard
API that your average C program expects to find)

> 
> > 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 was pleased how short your list was :)

Short != easy.  ~,^  Gods know i've tried implementing that feature list
enough times to with no complete success.  But then, I don't have nearly
as much language coding experience (or even plain coding experience) as
the majority of Ruby hackers.  ^,^

> 
> Paul
>