I recently came across small lisp dialect called femtolisp, written by Jeff Bezanson, the author of famous Julia Language.
(For more information about femtolisp visit https://code.google.com/p/femtolisp/ and https://github.com/JeffBezanson/femtolisp) and I really like it.
However, I wonder is there some way to call C functions from femtolisp?
No, there is currently no way to call arbitrary C functions from within the femtolisp language. As Matt B. says, there is an extension API that lets you write functions in C (which can in turn call any C function) and register them to become callable from femtolisp. It would be possible to use this mechanism to add a ccall function that used e.g. libffi to call any C function.
Related
I'm now watching the talk Engineering Julia for Speed given by Lionel Zoubritzky on JuliaCon 2018. The talked mentioned a function called removetype at about 13:24. I'm wondering how that function could be defined? Thanks.
This is a relatively old video, so I am not sure which Julia version is used there, but currently this function is Base.inferencebarrier (at least as of Julia 1.6 - since it is not exported it is not part of a public API and should not be considered guaranteed to be defined in the future).
Fortunately it is easy enough to define it yourself (I am copy-pasting the current definition):
inferencebarrier(#nospecialize(x)) = Ref{Any}(x)[]
The function makes sure that the compiler is not able to perform type inference of its return type. It is mostly useful if you want to avoid excessive recompilation of your code (the biggest benefit is for cheap higher-order functions).
I have recently seen that there is a macro defined in base/c.jl called ccallable, but it is not clear to me what its usefulness is. It seems to be undocumented.
After reading the documentation a little more carefully, I would summarise the usefulness of this macro as follows:
Make the annotated function be callable from C using its name. This can, for example, be used to expose functionality as a C-API when creating a custom Julia sysimage.
OK, let me try to rephrase my question.
Actually I wanted to know how is Function Application implemented in FP.
Is it done like a function call in imperative languages, where a stack frame is added for each call and removed on each return.
Or, is it like in inline functions, where the function call statement is replaced by the function definition.
Also, in terms of implementation of a function application, what is the significance of the statement functions in FP are mappings between domains and corresponding ranges. It is obviously not possible to maintain a mapping for each domain-range entry pair, so what exactly does the statement imply...
This question is broad enough that I can't answer it completely, since I don't know every single functional programming language. But I can tell you how it's done in one language, F#. You asked whether function application is done like a function call in imperative languages (another stack frame added for each call) or whether it's done as inline functions... and in F# the answer is both. The F# compiler is allowed to choose whether to create a stack-frame-using function call, or whether to inline the function at the call site; generally the choice is made based on the size of the compiled function. If the function compiles down to fewer than N bytes of compiled code (I can't tell you the exact number, but knowing the exact number doesn't actually matter) then the compiler will usually inline that function call; if it takes more than N bytes then the function call will use a stack frame. (Except in the case of tail-recursive calls, which are compiled to the equivalent of a goto and don't use a stack frame).
P.S. You can force the compiler's hand by using the inline keyword, which forces that function to be inlined at the call site every time. Most F# programmers don't recommend doing that on a regular basis, because the compiler is smart enough that it's usually not a good idea to override its decisions. (Also, the inline keyword means that the types of the function's parameters must be resolvable at compile time, so there are some functions for which that changes the semantics, but that's a little off-topic for the question you asked so I won't go into it. Except to say that in F#, statically-resolved type parameters or SRTPs are a very complicated subject, and you can do some very advanced things with them if you understand them.)
Is it a common thing for Julia users to encapsulate functionality into own modules with the module keyword?
I've been looking at modules and they seem to use include more than actually using the module keyword for parts of code.
What is the better way?
Julia has 3 levels of "Places you can put code"
include'd files
submodules
packages -- which for our purposes have exactly 1 (non-sub) module.
I use to be a big fan of submodules, given I come from python.
But submodules in julia are not so good.
From my experience, code written with them tends to be annoying both from a developer, and from a user perspective.
It just don't work out cleanly.
I have ripped the submodules out of at least one of my packages, and switched to plain includes.
Python needs submodules, to help deal with its namespace -- "Namespaces are great, lets do more of those".
But because of multiple dispatch, julia does not run out of function names -- you can reuse the same name, with a different type signature, and that is fine (Good even)
In general submodules grant you separation and decoupling of each submodule from each other. But in that case, why are you not using entirely separate packages? (with a common dependency)
Things that I find go wrong with submodules:
say you had:
- module A
- module B (i.e A.B)
- type C
One would normally do using A.B
but by mistake you can do using B since B is probably in a file called B.jl in your LOAD_PATH.
If you do this, then you want to access type C.
If you had done using A.B you would end up with a type A.B.C, when you entered the statement B.C().
But if you had mistakenly done using B, then B.C() gives you the type B.C.
And this type is not compatible, with functions that (because they do the right using) expect as A.B.C.
It just gets a bit messy.
Also reload("A.B") does not work.
(however reload often doesn't work great)
Base is one of the only major chuncks of julia code that uses submodules (that I aware of). And even Base is pushed a lot of those into seperate (stdlib) packages for julia 0.7.
The short is, if you are thinking about using a submodule,
check that it isn't a habit you are bringing over from another language.
And consider if you don't just want to release another separate package.
Can I write a DLL file that exports functions for use from or that use Common Lisp?
Each Common Lisp implementation has a different way to extend it from various foreign languages. Which implementation do you intend to use?
The GNU CLISP implementation allows one to define external modules written in C that expose objects, symbols, and functions to Lisp. The documentation for writing an external module is complete, but you'll likely find it difficult to integrate this into the rest of your build process, unless you're already using make or shell scripts to automate portions of it.
Alternately, you can turn the question around and ask how do you access C libraries from Common Lisp. Again, most implementations have a foreign function interface, or FFI that allows them to reach out to various other languages. CLISP has an FFI, but you can also use a package like CFFI for portability among Common Lisp implementations. The CLISP documentation describes the trades in these two approaches.
ECL may be another good choice for you if you intend to embed Common Lisp within your C program.
(..i'm not 100% sure what you mean, but i'll just throw some bits out there and see what happens..)
Most Lisps can do the C <--> Lisp type thing by ways of FFI, and there are compatibility layers/libraries for doing FFI like the already mentioned CFFI.
So you can pretty much always have Lisp call C functions and have C call Lisp functions, and most do it by loading .dll/.so files into the already running Lisp process. Note that this tends to be what other environments like Python (PyGTK etc.) do too. This is often exactly what you want, so you might perhaps want to ignore most of what I say below.
The only Lisp I can think of that enables one to do things the "other way around", i.e., load a .dll/.so which "is" Lisp or is produced by Lisp into an already running C process, is ECL.
In many cases it really does not matter where you put the entry point or the "main() function" to use C terms, so if you'd like to use some other Lisp besides ECL but are thinking you "can't because .." this is something to reconsider since, yeah, you can in many cases just shuffle thing around a bit.
However, it's almost always a much better idea to user other IPC mechanisms and avoid any kind of FFI when you can.