> 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.
>
Well, I think Jameson kind of contradicted that concern, and I think I see
his point. My concern was that, generally, calling C functions (which is
quite common in Julia) involves pushing arguments onto the stack and then
calling the routine. So for the routine to know the number of output
arguments, you would need to pass that in a similar manner.
Mex files have a specific mechanism for doing this, and require (?) that
you write a wrapper ("gateway routine") for any C function that you want to
write. Python is similar. In contrast, in Julia it's not necessary to
write a wrapper (although it can be good to do so to provide a nicer
programming interface). But either way, the call to C code is much more
direct--you're not required to write a wrapper. But then, you have to
follow C calling conventions.
My concern was actually the other way around--it's possible to pass
pointers to Julia functions to C code as a callback. My impression was
that the same rules then apply--the Julia function would be required to
adhere to C calling conventions.
Jameson suggested, though, that in either case, there's a bit of compiler
translation going on behind the scenes. For the case that matters (passing
Julia functions to C), this probably means that the compiler is making sure
the function is compiled (or automatically wrapped) in such a way that it
can be called using C conventions, and which would be different from how
the function would be called in Julia. In theory, then, you could do
something similar for Matlab.
All that is to say... I was wrong. ;-)
At any rate, this has been discussed before (probably multiple times), and
right now it doesn't look like Julia will evolve in that direction. For
one, while Julia looks a lot like Matlab (on purpose), the goal hasn't been
to mimic all of Matlab's design, especially when that conflicts with
Julia's own design goals. The more important reason at this point, though,
is probably momentum: if someone had made a decision to include this
feature a while ago, it probably would have been fine. At this point, the
core language itself has generally been pretty stable, so adding this would
be a pretty disruptive change, and the people who are actually working on
the compiler (like Jameson) are focused on other concerns.
Cheers,
Kevin
> 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]> 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
>>>>
>>>
>>
