On Mon, May 3, 2010 at 7:22 PM, Seth Burleigh <seth@tewebs.com> wrote:
So, I guesssing that there isn't a simple parser which replaces the
funcall of the non-obfuscated lisp name with the actual obfuscated
function call? Instead literally the lisp 'funcall' is called? Some
other mechanism i should look up since i need to be able to call the
lisp functions.

I am a bit confused by the jump of requirements. But let me explain the following: each lisp function gets compiled to a C function with one of these signatures

cl_object f1(cl_narg narg, cl_object arg1, ...)

cl_object f2(cl_object arg1, cl_object arg2, ..., cl_object argn)

In the first case the "..." are actual optional arguments (this happens for &key, &optional and &rest functions) and in the second case it is a lisp function with N arguments.

In principle you could call these functions directly, but we obfuscate the names on purpose so as to have  the functions not collide with each other (in CL you may define the same function twice and you are happy, in C it is not possible).

What Matthew showed was that it is possible to use FUNCALL + a pointer to the symbol naming the function to call that function. In addition to this there is a mechanism to actually *name* the function, that is specifying to ECL what C name the function must have. In this case the function will be exported and you can call it.
then when we 'load' a fas we're actually loading a shared library, we
call init_FAS_code and pass in a flag object, the flag object will then
contain the compiler_cfuns array which contains the function pointers
which can then be used to access the functions. Is this the way it

More or less so. For each pointer the Common Lisp creates a CFUN object (compiled-function in the Common Lisp type system) which keeps the pointer, the name and the number of arguments it takes. This object is a Common Lisp one and can be used by FUNCALL. It is then stored in the appropriate slot of a symbol so that you can also use the symbol instead in FUNCALL.
So, now conceptually my ideal .fas would also store an .h file which
contains all the function definitions and structure, class defs, etc per
package scope (lets not worry how we get those, im thinking of clang as
it is a structured compiler with an api).

Well, getting CLang to do that is not simpler than embedding CLang in ECL and using it as a compiler instead. Then you can forget about the rest of your problems because all definitions will be available to you. Furthermore by that price you would get ECL with an embedded compiler that can be distributed anywhere.

So, again, if you turn ECL into a C compiler then you can do what you want, but this is no little feat. Otherwise there are way simpler ways to live with C -- and actually I do not see the point in creating an infrastructure where your C code is so tightly packed with the Common Lisp world: it is not reusable at all and by that price you might be working entirely in Common Lisp using FFI.


Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)