[Ironruby-core] Few questions on DLR

Ales Sturala lists at ruby-forum.com
Sat Jun 7 12:23:19 EDT 2008

I have few questions about DLR, mostly about how it works inside.

1) So my first question is about compiling. I actually didn’t find much
information about this, but I know that in DLR I can interpret or
compile code. I wonder how to compile code into executable file or into
dll so I could simply use it in other .NET applications. Is it possible?
I expect, that in case of compiling my code into dll, I would have to do
also some modifications on my AST, let’s say in case of ToyScript, I
would have to wrap it into some static class and from all the functions
make static methods etc, right?

2) Second question is still connected to compiling, I can’t figure out
how calling methods works. I understand, that you take the DLR AST and
emit the IL code, but what happens when there is a DLR node
Ast.Expression.Call(typeof(Helpers).GetMethod(“WriteLine”)), how do you
emit code of this method when all you have is something you can call,
but you can’t get to the code tree of this method?
DLR caches

3) How many dynamic sites are in the application’s execution? Is it one
dynamic site for one language so if I have application written one part
in IronPhyton and rest in IronRuby, then there will be two dynamic sites
in the execution?

4) Do dynamic actions always provide better performance and so we should
use it everywhere? It seems that if I use dynamic action on every
arithmetic operation, but let’s say only addition (+) has a rule in a
binder, then for every other arithmetic operation (- * /) will be always
generated just a static node, right? So is there some other advantage
for using dynamic actions in this case? For example ToyScript uses
actions almost everywhere, even for every arithmetic operation while
only addition has a rule in a binder.

5) now my hypothetical question...
All the caching is done on runtime, so each new execution of my code
starts with empty cache and actions are searched thru all actions in
binder of my language, eventually thru all actions in binder of DLR,
right? Could you say how this is expensive on running real applications?
Is it possible to improve it? I understand that you can’t exactly say,
what actions will be used on runtime, but you have a source code of the
program so you could assume what rules can and which can’t be used,
simple example:

x = 5;
x + x;

I know, that I need only rule for (+) and two integers. Or another

if (System.Console.ReadLine() == “x”)
  x = “abc”;
  x = 5;

x + x;

Now I know that I need only rules where operation is (+) and left and
right side is string or int.
There is limited number of nodes, so I think it could be possible for
each node to define something like preconditions (expected types of
input expressions) and post condition (of what all types can be the
result). Then when code is compiled, I could go thru DLR AST, from
bottom up, infer types and when I get to action node I know, what are
all the possible types of input expressions. Then I can say what rules
from action binder most probably will be used and what rules will not be
used. This just can’t be implemented only inside DLR but also developer
of the language would have to define those pre and post conditions for
each action inside action binder of his language. Another possibility
would be not removing all the rules ‘I assume won’t be used’, but just
shifting rules I expect will be used at the beginning of the rules list
so they could be found much faster.
Of course there is still that question if there would be even some
significant performance improvement using this analysis or not.
Posted via http://www.ruby-forum.com/.

More information about the Ironruby-core mailing list