[Ironruby-core] Green paper on IronRuby

Ryan Riley ryan.riley at panesofglass.org
Sat Aug 23 16:45:21 EDT 2008

Speaking of continuations, what is the status of continuations for IronRuby?
Is it in or out? If it's in, then I would think you should leave it.

On Sat, Aug 23, 2008 at 9:44 AM, John Lam (IRONRUBY) <jflam at microsoft.com>wrote:

> Hi Ivan,
> I thought I'd give a few quick comments on your paper:
> - re: Duck Typing - I wouldn't characterize Ruby as not caring, or "caring
> less" about its type hierarchy. Ruby does depend on the type hierarchy
> (which includes mixins) to determine the method resolution order when
> dispatching method calls.
> - re: implicit type conversions - while it's true that Ruby does not
> perform implicit type conversions by default for the case of 1 + "1",
> programmers are free to (and have done) overloads of the "+" method to do
> exactly this kind of thing.
> - I think it would be better to simply describe the typing models
> (static/dynamic, weak/strong) by example in different exemplar languages
> followed by some examples in Ruby that characterizes it as a strong/dynamic
> language.
> - In the case of your conversion argument, "Ruby won't allow you however to
> change the type of an integer object without an explicit conversion step ...
> ". The conversion step actually creates a new object - it doesn't change the
> type of an existing object. This is an important distinction since "changing
> the type of an object" would infer somehow changing the 'shape' of the
> object. This can be accomplished in Ruby by adding / removing / changing
> mixins, adding / removing / changing methods etc. In other languages like
> Python, you can change the 'shape' of a class by redefining what its base
> class is. This, to me, is the essence of what makes a language 'dynamically
> typed' - you can change types at runtime vs. baking them at compile time.
> - re: closures - blocks also capture their containing lexical scope.
> Lambdas are required to turn blocks into first-class entities (assigning to
> variables).
> - re: continuations - I would cut out the section on continuations entirely
> since it is an esoteric construct that is not consistently supported across
> all Ruby implementations.
> - re: example of overloading System::String: You introduce global variables
> in your example without explaining what they are. I would rewrite this using
> only local variables since we have the artificial limitation of not
> supporting locals yet in our console.
> - re: WPF example. There's a lot of magic included in the require 'wpf'
> line of code. While this is early in the book, I would definitely call out
> the magic in require 'wpf', or at least make a goal of explaining how that
> magic works in a subsequent chapter that you can forward ref from the
> example.
> Thanks,
> -John
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> > bounces at rubyforge.org] On Behalf Of Ivan Porto Carrero
> > Sent: Friday, August 22, 2008 12:31 PM
> > To: ironruby-core at rubyforge.org
> > Subject: [Ironruby-core] Green paper on IronRuby
> >
> > Manning just published my green paper on ironruby.
> > http://manning.com/free/green_carrero.html
> >
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core

Ryan Riley
ryan.riley at panesofglass.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080823/27791275/attachment.html>

More information about the Ironruby-core mailing list