Thanks, Jameson--it's nice to have a response from someone who actually works on the compiler.
Cheers, Kevin On Fri, Mar 6, 2015 at 8:09 PM, Jameson Nash <[email protected]> wrote: > I'd put together one version of a gist of how this could work in the past, > and Jeff's mentioned a similar draft idea he had in an early design > document. In the end, however, I think this just ends up falling in the > category of "features that just aren't actually desirable to have". It adds > complexity to the compiler, true. More importantly though, it adds > additional complexity to the user's concept of a function, and without > sufficient benefit to justify itself. This feature is often useful in > matlab for avoiding the expense of some extra computations (which are often > very expensive in matlab in the first place), but it's also often abused to > have a function do something different. Additionally, it makes > composability much more difficult (since the function call starts to depend > upon the syntax of the call), such that it can be harder to write fully > generic code. > > Julia code is already much more expressive than C, and requires explicit > ccall / cfunction conversions to translate between the languages, so direct > compatibility isn't actually much of a concern. > > On Fri, Mar 6, 2015 at 9:13 PM Kevin Squire <[email protected]> > wrote: > >> On Fri, Mar 6, 2015 at 11:43 AM, J Luis <[email protected]> wrote: >> >>> Is there any fundamental reason why the nargout mechanism cannot (or is >>> very hard) to implement? >>> Because if not I really think it would be very very handy to have it. >>> While we can workaround the nargin concept with the multiple dispatch, the >>> same does help for the nargout. >>> >> >> I'm not an expert on the innards of the Julia compiler, but I believe the >> most important reason is that it interferes with type stability of a >> function, which in turn interferes with the ability of the compiler to >> generate optimized code. >> >> Additionally, functions can currently be used as callbacks from C and >> Fortran code (and there's generally a desire to keep/enhance C >> interactivity as much as possible). If we wanted functions to know the >> number of output parameters, there would need to be a mechanism to provide >> this information to the function at call time (e.g., the number of args >> would perhaps need to be passed in as a hidden parameter). As there is no >> mechanism to do this in C, we would either lose compatibility with C, or >> need to provide a new kind of function, solely for this purpose. >> >> So while adding such functionality might add convenience (mostly for >> people coming from Matlab), it 1) would produce slower, less optimized >> code, and 2) would require adding a new kind of function to the language >> and compiler (which is already pretty complicated). >> >> I think that would be a pretty hard sell to the primary developers. >> >> Cheers! >> >> Kevin >> >
