4 ms·

The graphic is too fuzzy -- but I'm trying to figure out why the AST for fib in Ruby would be so complex...

• chrisseaton 6y ago
  Ruby has more complicated semantics. An example of a concrete difference here is that Ruby checks for overflow on integer maths, where Java does not. This means each maths operation is a little cluster of nodes, rather than a single node. Another example is that Ruby has dynamic typing, so values that come into the function need to be type checked, and values going out need to put into a format where they can have their type inspected. One more example is that the call to fib in Java is static - we know exactly where that goes. In Ruby the call is dynamic, so we need to check we're calling the correct method. Here's a full SVG copy of that diagram https://www.dropbox.com/s/k68id9aqu258blw/fib-ruby.svg https://www.dropbox.com/s/k68id9aqu258blw/fib-ruby.svg.
  • thelazydogsback 6y ago
    Thanks - I knew all that, but I guess I expected those semantics to be implicit rather than explicit. I guess because we're not really looking at an "AST" but an intermediate executable representation. Certainly this is good for understanding what Ruby is doing, but not so useful for understanding what fib is doing - trees vs. forest. I guess what you really want is to be able to zoom into IL-semantics only if you care about such things, otherwise you show only enough detail to get across the algorithm being expressed -- possibly with the addition of declaratively showing additional constraints that have been added by the runtime without showing how the contraints have been satisfied.