Re: Keyword Arguments

On 6/22/2012 10:50 AM, David Goehrig wrote:
> First of all, thank you Kevin and Steve for this wonderful thread. It has been one of the best discussions I've seen on an emotional issue in a long time.

Thanks, I'm enjoying it, too. :-)


> A few observations:
>
> 1.) Steve is right - having done a lot of work with metamorphic objects which "type shift" via reparenting or altering their slots dynamically, ( cf. Plaid language for the concept http://www.cs.cmu.edu/~aldrich/plaid/ ) the entire notion of "type" in a language like IO is separate from identity, and as initialization via constructor should be considered harmful. Smalltalkers may be familiar with the limitations become: which don't apply to languages like io.

Type may be "separate" from identity, but even in Io there are 
informal constraints on the state and behavior of each object which 
amounts to its "type".  The fact that Io doesn't provide much help 
in identifying and formalizing those constraints just means that the 
programmer has to manage them himself.


> 2.) JIT is ad hoc by design, and a lot of work in Self had to do with backing out (deoptimization) of JIT to maximize overall performance. Type info as constraints do not ensure better performance, as they may require additional type conversions which can be more expensive than a naive interpreter.  Having written a few JIT implementations now, my anecdotal experience matches what the Self team published back in the 90s on dynamic deoptimization.

Balancing specialization is a valid concern, but before we even get 
to that stage, we have to effectively track types that we can reason 
about, whether those types are stated by the programmer directly, or 
through heuristic inference from values.

Last time I checked, Io's type system was spread amongst using 
IoTag, nominally using slot names or the string in `type`, and maybe 
checking for specific protos.  I took a guess that Steve implemented 
the libJIT bindings by assuming a static type based upon the slot 
names, e.g. `if`.  That kind of typing is ok, but it also limits the 
ability and usefulness of the JIT.


> 3.) keyword arguments violate encapsulation if viewed as setting the internal state of the object. It is not the Object doing the internalization but an external compiler mucking with the internals of an object. As per point 1, this is untennable in a distributed environment where compilation may occur via proxy, and the underlying representations may be platform / architecture specific.

What if we view keyword arguments as calling setters as I've described?


> 4.) Steve's approach comes out of behavioralism of live objects.  By avoiding complicating the compiler (itself a live object with behavior) he can minimize the opportunities for static typers to write non-behavioral friendly code. It really avoids a conceptual model that violates the spirit of the language.

Abuse due to bad programming habits is an interesting aspect that I 
think Steve was suggesting as well.  Perhaps that potential for 
abuse could outweigh the benefits of keyword arg syntax, but it 
doesn't outweigh the benefits of a better type system in my opinion.

Kevin