[Gsll-devel] About the naming convention in gsll

[Liam Healy]

On Fri, May 16, 2008 at 5:33 PM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
> On Fri, May 16, 2008 at 5:02 PM, Liam Healy <lhealy at common-lisp.net> wrote:
...
>> So I'm willing to change things, certainly.  However, the example
>> you gave I am not sympathetic to; you don't like GSLL taking
>> #'solve-tridiagonal because you do a mass copying of arrays
>> and you want that mandatory and built-in.
>> I don't think copying should be part of the library call because
>> the user is compelled to pay a copying penalty which may
>> (and should) be minimized by working in foreign arrays throughout
>> the computation.   What if the array came from another GSLL
>> calculation; would you build in a copying to CL at the end and then
>> copy it back to C?  What if there were several, or
>> several thousand, such chained calculations?  There were some
>> spots where I struggled with whether to copy or not; in some cases
>> it copies but in places where I felt chaining was likely it does not.
>
> Can you give me advice on how to handle that?  maybe a pointer to some
> documentation?  I tried divining from hyperlisp on numeric types, but
> did not get far.
>
> I am not familiar with the concept of foreign array.  I'll try to read
> up on that.
>
Unfortunately, there isn't a huge amount of documentation.  Basically,
for most implementations, the array needs to exist on the foreign (C)
side for GSL to have access to it, and an identical copy needs to
exist the CL side for your Lisp functions to access it.  Keeping them
in sync is requires copying.  That is what you are doing with the
letm binding of say a* to a: you are copying a (CL) to a* (C).
At the end, if you do a #'data of the result, you are copying back.

Once ffa is incorporated, I hope it will all be there under the hood
without anyone having to worry about it.  But that unfortunately
is not going to happen in the next few weeks anyway.

>
>>
...

>>
>> I am unclear on what the point of the macro is; if it were a function
>> it would do the same thing.  There is no passing by value in any case
>> as far as I know; do you mean a copying of arrays?  You're
>> going to get that anyway; there's no way to avoid it in ANSI standard
>> CL.
>>
>
> I was trying to avoid passing by value.  The way I understood macros,
> the macro would be expanded into a let form during compilation, and
> thus the original variables would be used.
>
You are not ever going to pass by value.  I don't know of any language
in which arrays are passed by value (maybe C if you put it in a struct
and pass the struct by value).  Perhaps what you mean is that
you are trying to avoid evaluation?  If that is so, you are not doing
this; it is still evaluating (as it must), it is just doing the
evaluation after the macro expansion.

Liam