Thanks me too for explanations. Note that I was careful enough to have anticipated that there would likely exist deep reasons why a feature like this would have a strong impact on other aspects of the language performance. But while these performance worries are absolutely valid reasons, I have to disagree on arguments of the kind "adds additional complexity to the user's concept of a function, and without sufficient benefit to justify itself". About these, please, let the users decide. I remember endless discussions on the Mathworks forum about GOTOs where a large number of people considered that a GOTO was a too powerful command to be let used by an average user who would undoubtedly use it to write spaghetti code.
Kevin, curious that you refer that "there is no mechanism to do this in C" because, while it's a particular C environment, the MEX env has this 'nargout' concept and it would really easy up my life if I could use it in Julia when porting the GMT MEX wrapper. sábado, 7 de Março de 2015 às 04:17:26 UTC, Kevin Squire escreveu: > > 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] > <javascript:>> 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] >> <javascript:>> wrote: >> >>> On Fri, Mar 6, 2015 at 11:43 AM, J Luis <[email protected] <javascript:>> >>> 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 >>> >> >
