I'm a python/c/c++ programmer, I'm using emacs, and I read hackers & painters, and I read SICP, and I'm starting reading practical common lisp, but the problem is, I need a library reference as python documentation do(also with how to communicate with C library), so I can actual using lisp in real life. any links? (current focus on common-lisp)
and, after I can really use lisp, how can I learn from others, and dive into the lisp community?
maybe a total lisp reference contains all, but I didn't find one.
Perhaps you are looking for the Common Lisp HyperSpec?
It covers all of ANSI Common Lisp, but will not tell you "how to communicate with C library" since that is implementation dependent.
The Common Lisp Quick Reference gives you a nice overview of the core language. It can be printed to small booklets.
For things like communication to C etc. you need to use the manuals of the libraries (say, CFFI or the specific FFI of the CL implementation) or implementations.
Which Lisp implementation(s) are you using?
CLISP Implementation Notes
SBCL manual
full LispWorks manuals in HTML, PDF and PS
full Allegro CL manuals
Related
I'm trying to calculate a Student-t probability. I really need the incomplete beta function for this, but I can't find any good function in Lua. Does it exist?
I've ported over the code from Numerical Recipes in C, and it works, but it's not open source license. I need something with a real license, like GPL, MIT, etc.
There's also Apophenia, at http://apophenia.info/ . It doesn't yet have Lua bindings, but I'd even be willing to work with you on developing one. It's plain C and its only complication for binding is the setup for variadic functions. Even this is not especially complicated; just push a lot of extra nils onto the stack as needed.
Lua Fun is a high-performance practical programming library designed for LuaJIT tracing just-in-time compiler. The library affords a set of extra than 50 programming primitives usually determined in languages like Standard ML, Haskell, Erlang, JavaScript, Python and even Lisp.
I find modern functional programming languages and the paradigm in general to be very interesting. A lot of functional programming languages are able to generate efficient native code either by using C as an intermediate language or with their own code generators. I'm talking about languages like Haskell, OCaml, LISP or Scheme (SBCL, Chiken, Gambit and etc). But knowing that functional programming languages requires a big runtime library, that is usually implemented in C (for garbage collection for example), I'd like to ask is it really possible to create bare metal code in such language and only using it without the need to go back to C (for example for OS development, or for running native code on embedded device without operating system)? Is there any functional programming language that doesn't depend on runtime (even if it would be a language subset)? Is there any functional language in which I can reimplement the runtime that it needs (for example languages like Ada, D, Nimrod, Pascal has runtimes that are written in the language itself)? What alternative functional languages do I have for bare metal development these days?
Why such hate for C? Functional languages have to use a lower-level language for producing machine-level code.
And you can also write C in a very pure functional way. C offers to the developer the freedom to follow any programming style she wishes.
You can easily follow the functional paradigm in C by applying principles that you have learned from other functional languages, i.e.:
No mutation.
No malloc.
Avoid state.
Model in terms of verbs rather than nouns.
Use recursion instead of iteration.
et.c.
There is a book with an intro to Functional C.
I'd like to ask is it really possible to create bare metal code in
such language and only using it without the need to go back to C
Bare metal/machine-level/object code are 1GL (1st generation programming languages) made of binary numbers, represented by 1s and 0s.
Most 3GL or 4GL that use a compiler can generate object code.
Is there any functional programming language that doesn't depend on
runtime (even if it would be a language subset)
Well, every application that runs on top of an OS has to use the OS's API. Nearly all popular OSes are written in C/C++. That includes Windows, Linux, MacOS, Android et.c.
So, when creating an app for an OS, you may have to depend on the OS's runtime environment (that is usually written in C/C++).
Is there any functional language in which I can reimplement the
runtime that it needs (for example languages like Ada, D, Nimrod,
Pascal has runtimes that are written in the language itself)
Yeap, you can write your own runtime library for any language you wish, but that's not an easy task to do.
What alternative functional languages do I have for bare metal
development these days?
I suggest that you choose your favorite functional language (Haskell, F#, Scala or whatever) and just forget about the runtime. There are many and good reason that it is written in C. And AFAIK that isn't going to change anytime soon.
By programming in Scala you use the JVM and with F# the CLR or the WinRT. Maybe these options could help you.
EDIT: If what you really want to ask is if it is possible to write an OS in a functional language, then the answer is yes.
House is an OS written in Haskell. The FFI provides the necessary functionality for (a) calling low-level routines for accessing hardware, and (b) managing memory explicitly.
MirageOS is in OCaml, and there have been OSs implemented in ML.
Generally, any "Turing Complete" programming language can be used to create an operating system, and most functional languages like LISP, Haskell, OCaml, and so on are Turing Complete.
I'm thinking there will be very few (if any) alternatives since the primitives will then be system dependent and your object file needs to have it's own GC. (functional languages need a runtime GC)
You can make your own domain specific language in your favorite functional language, perhaps Scheme, that utilize some sort of assembler, like Sassy, to eventually output raw machine code. But really this is just making your own compiler.
A much simpler option to use C as an intermediate. Many does this since most systems have a C compiler. Devices comes with reference implementations in C.
A different alternative is to make a system like SBCL cross compile to your architecture and use it as the runtime OS of your device.
BTW: SBCL has very little implemented in other languages than Common Lisp. The main part is probably the GC. The GC code could have been implemented in CL, but that would have made debugging far more complex and with a buggy GC you get all sorts of strange behaviour.
I want to do some simulations with ACT-R and I will need a Common Lisp implementation. I have three Common Lisp implementations available: (1) CLISP [1], (2) ECL [1], and (3) SBCL [1]. As you might have gathered from the links I have read a bit about all three of them on Wikipedia. But I would like the opinion of some experienced users. More specifically I would like to know:
(i) What are the main differences between the three implementations (e.g.: What are they best at? Is any of them used only for specific purposes and might therefore not be suited for specific tasks?)?
(ii) Is there an obvious choice either based on the fact that I will be using ACT-R or based on general reasons?
As this could be interpreted as a subjective question
I checked What topics can I ask about here and What types of questions should I avoid asking? and if I read correctly it should not qualify as forbidden fruit.
I wrote a moderately-sized application and ran it in SBCL, CCL, ECL, CLISP, ABCL, and LispWorks. For my application, SBCL is far and away the fastest, and it's got a pretty good debugger. It's a bit strict about some warnings--you may end up coding in a slightly more regimented way, or turn off one or more warnings.
I agree with Sylwester: If possible, write to the standard, and then you can run your code in any implementation. You'll figure out through testing which is best for your project.
Since SBCL compiles so agressively, once in a while the stacktrace in the debugger is less informative than I'd like. This can probably be controlled with parameters, but I just rerun the same code in one of the other implementations. ABCL has an informative stacktrace, for example, as I recall. (It's also very slow, but if you want real Common Lisp and Java interoperability, it's the only option.)
One of the nice things about Common Lisp is how many high-quality implementations there are, most of them free.
For informal use--e.g. to learn Common Lisp, CCL or CLISP may be a better choice than SBCL.
I have never tried compiling to C using ECL. It's possible that it would beat SBCL on speed for some applications. I have no idea.
CLISP and LispWorks will not handle arbitrarily long argument lists (unless that's been fixed in the last couple of years, but I doubt it). This turned out to be a problem with my application, but would not be a problem for most code.
Doesn't ACT-R come out of Carnegie Mellon? What do its authors use? My guess would be CMUCL or SBCL, which is derived from CMUCL. (I only tried CMUCL briefly. Its interpreter is very slow, but I assume that compiled code is very fast. I think that most people choose SBCL over CMUCL, however.)
(It's possible that this question belongs on Programmers.SE.)
In general, SBCL is the default choice among open-source Lisps. It is solid, well-supported, produces fast code, and provides many goodies beyond what the standard mandates (concurrency primitives, profiling, etc.) Another implementation with similar properties is CCL.
CLISP is more suitable if you're not an engineer, or you want to quickly show Lisp to someone non-engineer. It's a pretty basic implementation, but quick to get running and user-friendly. A Lisp-calculator :)
ECL's major selling point is that it's embeddable, i.e. it is rather easy to make it work inside some C application, like a web-server etc. It's a good choice for geeks, who want to explore solutions on the boundary of Lisp and the outside world. If you're not intersted in such use case I wouldn't recommend you to try it, especially since it is not actively supported, at the moment.
Their names, their bugs and their non standard additions (using them will lock you in)
I use CLISP as REPL and testing during dev and usually SBCL for production. ECL i've never used.
I recommend you test your code with more than one implementation.
I'm currently learning to wrap C++ code in Lisp so I can call C++ functions from Lisp.
I'm learning about SWIG and I would like to know more about the Allegro Common Lisp part of SWIG. I'm using the Express(free) addition of Allegro now and it has a heap limit of like 50mb so it stops me from loading the GNU Scientific Library for Lisp, GSLL.
I'd like to make a huge App which would be using code from GSLL, Lisp wrappers for OpenCV I create with SWIG and other Lisp wrappers for C++ code I create with SWIG, and I'd like to be able to use all of OpenCV's C++ Interface functions from Lisp and SWIG's Allegro Common Lisp C++ support seems the most complete (and correct me if I'm wrong) and best way to wrap the most C++ functions. (I say this because the Allegro Common Lisp section of the SWIG manual much larger than the Common Lisp sections.
I create OpenCV C++ bindings for Lisp in Allegro Common Lisp Express edition and somehow move them over to SBCL or CLISP so I can use all my GSLL code with my OpenCV wrappers in Lisp implementations that don't have a heap limit or does the Allegro/SWIG partnership deem I only use SWIG C++ wrappers made in Allegro with the SWIG Allegro tutorial in Allegro Common Lisp.
Please correct me if I'm wrong in assuming the Allegro Common Lisp's support is more complete than the other implementations', or if there is a better way to wrap all of OpenCV's C++ functions or if OpenCV's C interface is just as complete as the C++ interface and I can just wrap that.
Please cite online resources when pertinent.
SWIG targeted for AllegroCL will generate wrappers specific to Allegro's proprietary FFI and will not be usable on other lisp implementations. Otherwise, SWIG for common-lisp can generate wrappers targeted to CFFI, which serves as a compatibility layer for all of the foreign interfaces of lisps that it supports. As such, however, CFFI tends to be something of a "least common denominator" among supported lisps and likely the SWIG generation will not be as comprehensive.
My understanding is that there is not much that can be done to interoperate fully between C++ and Common-Lisp. I'm aware of some experimental branches of ECL which sought to do so which claimed some degree of success, but I do not believe these reached the point of public release. At the very least, if you were to go that route, you'd be running on a lisp platform with very, very limited support.
There is another option you may wish to look into for generation of C wrappers that may give more comprehensive results, but that targets CLANG and LLVM compiler environment. If that is acceptable, you can have a look on github at the following two projects:
http://github.com/rpav/c2ffi
http://github.com/rpav/c2ffi-cffi
I'm sure I haven't given the answer you may have been wishing for, but I hope it can be of at least some help.
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.