Mirko,<br><br>I was unsure of what you meant when you first mentioned a macro.  It should be pointed out that unlike in the C world, a lisp macro is not a forced inline version of a function.  The is an inline declaration statement that (on efficiency minded compilers) inlines functions in your code.  Macros are used for different things that functions.  99.9% (perhaps 100%) of the time, using a macro as you have described is not a good idea as you can get better functionality by defining an function (inlined if necessary).<br>
<br>Also, I am happy to see that Liam has posted a reply clearing up the comment on passing arrays by value.  In most languages (including CL) certain objects are passed by value (in Lisp, numbers and characters), and some are passed by pointer, err, reference, don't know what exactly to call it (in Lisp, pretty much everything else).  This was a point of confusion in my head when I first learned Lisp; it took me a while to realize that Lisp's implicit behavior is exactly the same as C's explicit behavior (with the exception of C's struct copying).<br>
<br>
Foreign Friendly Arrays (FFA) is a library.  You will not find info on
it in the hyperspec.  Look at the author's website (I believe this is your work, Tamas, right?) or the archives of this
mailing list for that matter.<br>
<br>Zach<br><br><br><div class="gmail_quote">On Fri, May 16, 2008 at 3:44 PM, Tamas K Papp <<a href="mailto:tpapp@princeton.edu">tpapp@princeton.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Fri, May 16, 2008 at 05:02:18PM -0400, Liam Healy wrote:<br>
<br>
> amenable to changing it, but I think Zach's suggestion about<br>
> packages is what I intended: you shouldn't really program in<br>
> the GSLL package; make your own package like gsll-user and<br>
> you can do whatever you want.<br>
<br>
</div>I would agree.  Putting gsll: before function names is the way to go.<br>
<div class="Ih2E3d"><br>
> I don't think copying should be part of the library call because<br>
> the user is compelled to pay a copying penalty which may<br>
> (and should) be minimized by working in foreign arrays throughout<br>
<br>
</div>I second that.  In a lot of calculations, many matrices are<br>
intermediate results and will be discarded anyhow, there is little<br>
sense in copying them.<br>
<div class="Ih2E3d"><br>
> As a side point, I am working on incorporating<br>
> foreign-friendly arrays, and there is a separate function<br>
> (currently called make-array*) that creates arrays, similar to<br>
> make-array, but the type specification is mandatory.  If<br>
> you are using SBCL, the C array is the CL array;<br>
> if not, the right thing will always happen (once debugged...).<br>
<br>
</div>I am looking forward to that...<br>
<font color="#888888"><br>
Tamas<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Gsll-devel mailing list<br>
<a href="mailto:Gsll-devel@common-lisp.net">Gsll-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel</a><br>
</div></div></blockquote></div><br>