Author: larry Date: Thu Feb 7 10:45:55 2008 New Revision: 14502 Modified: doc/trunk/design/syn/S06.pod
Log: Some implementation notes about the conflict between autothreading and only subs Modified: doc/trunk/design/syn/S06.pod ============================================================================== --- doc/trunk/design/syn/S06.pod (original) +++ doc/trunk/design/syn/S06.pod Thu Feb 7 10:45:55 2008 @@ -13,9 +13,9 @@ Maintainer: Larry Wall <[EMAIL PROTECTED]> Date: 21 Mar 2003 - Last Modified: 5 Feb 2008 + Last Modified: 7 Feb 2008 Number: 6 - Version: 92 + Version: 93 This document summarizes Apocalypse 6, which covers subroutines and the @@ -2843,4 +2843,34 @@ particular parameter, an attempt will be made to match it as if it had been written C<-a -b -c>. +=head2 Implementation note on autothreading of only subs + +The natural way to implement autothreading for multi subs is to +simply have the junctional signatures (the ones that can accept +Objects/Junctions as well as Any parameters) match more loosely than +the non-autothreading versions, and let multiple dispatch find the +appropriate sub based on the signature. Those generic routines +then end up redispatching to the more specific ones. + +On the other hand, the natural implementation of only subs is to +call the sub in question directly for efficiency (and maybe even +inline it in some cases). That efficiency is, after all, the main +reason for not just making all subs multi. However, this direct +call conflicts with the desire to allow autothreading. It might +be tempting to simply make everything multi dispatch underneath, +and then say that the "only" declaration merely means that you get +an error if you redeclare. And maybe that is a valid approach if +the multiple dispatch mechanism is fast enough. + +However, a direct call still needs to bind its arguments to its +parameters correctly, and it has to handle the case of failure to +bind somehow. So it is also possible to implement autothreading +of only subs based on failover from the binding failure. This could +either be a one-shot failover followed by a conversion to a multi call, +or it could failover every time you try to autothread. If we assume +that junctional processing is likely to be fairly heavyweight most of +the time compared to the cost of failing to bind, that tends to argue +for failing over every time. This is also more conducive to inlining, +since it's difficult to rewrite inlined calls. + =for vim:set expandtab sw=4:
