Common Lisp HyperSpec says that require and ****modules**** are deprecated.
But I still see we use require all the time. What should we use?
They were deprecated long ago. The standard was published in 1994. What were the consequences? None, since no new standard has been published and no new standard is being worked on.
So, if your Common Lisp implementations provide a useful definition and implementation of PROVIDE, REQUIRE and *MODULES*, then use it.
There are other tools that care about loading and creating libraries and applications (usually called 'Systems'). Often these have some kind of interface, so that (REQUIRE 'SOME-SYSTEM) loads that system and so that after loading that system it has been 'provided'.
ASDF seems to be a pretty popular and modern way for loading systems.
to load foo:
(asdf:load-system :foo)
and under ABCL, Clozure CL, CMUCL, ECL and SBCL, it hooks into cl:require. So cl:require seems fine.
Related
I'm interested in seeing how low-level a programmer can go in pure Common Lisp (or, failing that, in implementation-specific extensions). Google hasn't been able to find me much information about this, so I'd like to hear what the experts have to say. This post mentioned a feature of SBCL to define what the author called "virtual operators", but searching for "common lisp virtual operators" didn't yield much. The author also mentioned how hard it was to find documentation about it. Do similar systems exist for other implementations, is there any basis for it in the standard (though considering that such a feature would mostly be used for writing ISA-specific code, portability shouldn't really be high on the priorities for users of it), and where can documentation for features such as this be found?
It would be great to find a way to extend the "programmable programming language" concept to low-level code as well (especially for areas where efficiency is highly important and other libraries written in C or assembly may not be available).
This is very implementation specific and not portable at all.
Yes, SBCL uses VOPs, but other implementations have completely different compilation targets.
If you intend to go low-level in a somewhat portable way, you have two avenues:
Optimize using declarations, inlining, manual unrolling etc., checking your progress with disassemble
Implement a static blob externally, then interface it with an FFI
I am somewhat familiar with Scheme. I am reading OnLisp, and would love to do a real world project in it. Most likely web development. I would love to know what kind of setup people use to develop websites in lisp. I have a couple of macs at home and I have figured I would use clozure cl. I am wary of a few things though. I have read on the internets that cl doesn't have reliable threading facility nor good networking. Is this true? What was your experience?
PS:Don't tell me about clojure :). Lisp is a itch I need to scratch.
Currently I'm using Restas a framework based on Hunchentoot and inspired by the route system of Rails. I also use Postmodern to interact with a PostgreSQL database and I generate HTML with cl-markup though I'm thinking about switching to cl-who which looks more customizable.
When I've started I've also considered using Parenscript to generate the JavaScript but now I'm just happy with Mootools and plain JavaScript.
Everything runs on SBCL and is available with Quicklisp.
Not sure why it wouldn't have "good networking"; you can't rely on threads if you want to write a portable Common Lisp application since certain implementations don't support them (AFAIK, just clisp, though you can compile it with experimental thread support). If you plan on picking an implementation and sticking with it, you won't have that problem.
The "standard" CL web stack is Hunchentoot/cl-who/clsql, though you can find tutorials that run on Araneida or Portable AllegroServe.
The setup I use is Debian/SBCL running quicklisp and the above systems along with MySQL (though I'm seriously considering jumping over to Postgres) for the database and nginx to run in front of Hunchentoot serving any static content.
mck- has been maintaining the heroku common lisp webapp.
https://github.com/mck-/heroku-cl-example/tree/
The problem with Common Lisp's "networking" is, we don't have sockets in CL standard, so each implementation has it's own socket API. We have some attempts to give a common interface though, like usocket. You can find a list of networking related packages here.
If you need a web framework, look into Caveman. I haven't used it yet but it looks like the most complete CL web framework I've ever seen.
I seek a GNU Common Lisp package which implements forkpty(); openpty() would also be a big plus, and login_tty() would be a luxury I could live with. (Duckduckgo, Google, etc. were of no help.) Is there such? Where?
https://github.com/cffi-posix/
seems to be the right place to put the code you are looking for.
The idea is to port standard UNIX header files to CFFI-* packages.
LISP is not know for its libraries, which is often though to be a side effect of its power (and lack of portability, and fragmented community, etc.). You are welcome to make your own and put it on github (or a similar platform)!
This is a rather unsatisfying non-answer, so:
No, there probably isn't. If there is it is likely to not be portable enough to work on your implementation anyway.
There is Gambit Scheme, MIT Scheme, PLT Scheme, Chicken Scheme, Bigloo, Larceny, ...; then there are all the lisps.
Yet, there's not (to my knowledge) a single popular scheme/lisp on LLVM, even though LLVM provides lots of nice things like:
easier to generate code than x86
easy to make C FFI calls
...
So why is it that there isn't a good scheme/lisp on LLVM?
LLVM provides a lot, but it's still only a small part of the runtime a functional language needs. And C FFI calls are uncomplicated because LLVM leaves memory management to be handled by someone else. Interacting the Garbage Collector is what makes FFI calls difficult in languages such as Scheme.
You might be interested in HLVM, but it's still more than experimental at this point.
For CL: Clasp is a Common Lisp implementation on LLVM, and mocl implements a subset of Common Lisp on LLVM.
For Scheme: there's a self-hosting Scheme->LLVM demo and a prototype LLVM backend for Bigloo Scheme.
For Clojure: there's Rhine, which is a Clojure-inspired lisp.
There's a very small and apparently unoptimised Scheme compiler here:
http://www.ida.liu.se/~tobnu/scheme2llvm/
Taking your question literally,
Writing compilers is hard.
A poor implementation like the one linked above can block new implementations. People going to the LLVM page see that there's a Scheme already, and don't bother writing one.
There's a limited number of people who write and use Scheme (I'm one, not a hater, btw).
There are lots of existing Scheme intepreters and compilers and there's not a screaming need to have a new one.
There's not an immediate, clear benefit to writing a new interpreter using LLVM. Would it be faster, easier, more flexible, better in some way than the other dozens of Scheme implementations?
The LLVM project went with another language (C) to demo their technology, and haven't seen a need to implement a lot of others.
I think that it could be a lot of fun for someone to build an LLVM-based Scheme compiler. The Scheme compilers in SICP and PAIP are both good examples.
Maybe I'm completely misunderstanding the question or context, but I believe that you could use ECL, which is a Common Lisp that compiles down to C, and use the Clang compiler to target LLVM (instead of GCC).
I'm not sure what (if any) benefit this would give you, but it would give you a Lisp running on LLVM =].
One thing to keep in mind is that many of these implementations have C FFIs and native-code compilers that significantly predate LLVM.
CL-LLVM provides Common Lisp bindings for LLVM. It takes the FFI approach, rather than attempting to output LLVM assembly or bitcode directly.
This library is available via Quicklisp.
mocl is a compiler for a relatively static subset of Common Lisp. It compiles via LLVM/Clang.
there's not (to my knowledge) a single
popular scheme/lisp on LLVM
Currently, llvm-gcc is the nearest thing to a popular implementation of any language on LLVM. In particular, there are no mature LLVM-based language implementations with garbage collection yet. I am sure LLVM will be used as the foundation for lots of exciting next-generation language implementations but that will take a lot of time and effort and it is early days for LLVM in this context.
My own HLVM project is one of the only LLVM-based implementations with garbage collection and its GC is multicore-capable but loosely bound: I used a shadow stack for an "uncooperative environment" rather than hacking the C++ code in LLVM to integrate real stack walking.
There is a Scheme2LLVM, apparently based on SICP:
The code is quite similar to the code in the book SICP (Structure and Interpretation of Computer Programs), chapter five, with the difference that it implements the extra functionality that SICP assumes that the explicit control evaluator (virtual machine) already have. Much functionality of the compiler is implemented in a subset of scheme, llvm-defines, which are compiled to llvm functions.
I don't know if it's "good".
GHC is experimenting with a scheme backend and getting really exciting preliminary results over their native code compiler. Granted, that's haskell. But they've recently pushed new changes into LLVM making tail calls easier IIRC. This could be good for some scheme implementation.
When I started learning CL from Practical Common Lisp, as is preached in the book, I started off with Allegro CL compiler. I stopped using it, since its commerical, yet free bit didn't impress me. It needed a connection to its remote server for some licensing stuffs.
I switched to 'clisp' and am using it. Now, I have been hearing about SBCL and planning to start using it as well.
So, the question is: How do the various ANSI CL implementations differ? Any practical experience of using one over the other ?
Thank you.
See Common Lisp Implementations: A Survey by Daniel Weinreb.
If you are on a machine that can run SBCL, you should use it. It's
the fastest free Lisp compiler (it can generate code that is as fast
as Haskell, OCaml, Java, C, and C++, which are all very very fast,
especially compared to Python and Ruby). It also is a fairly complete
implementation, and supports most of Swank's features (for SLIME), which is nice when you are developing.
As some of the other comments mention, you won't really notice any
differences when you are first starting out. All the free CL
implementations are "fast enough" and support all the features you'll need. But if you start writing
production software, you will appreciate SBCL's features. OTOH, there's really no reason not to switch now.
I have been looking at Win32 solutions to the same question. As far free Lisp implementations on Windows, I would strongly recommend Clozure CL (CCL). There are several reasons for this. The first is that Clozure supports 32- and 64-bit binaries. It's very fast, and somewhat compact. But most importantly, it's consistent and correct. I find it to be an extremely mature Lisp, after working with Lispworks (which I miss) for several years. CCL does a very nice job with native OS threads, sockets, and some other elements that are not part of the CL spec. Its implementation of CLOS seems to be extremely thorough. And it's GC and memory management are excellent. I compared CCL to SBCL on Win32, and while SBCL was a bit faster on several benchmarks, it cons'd up a lot more, and its image kept growing and growing, even after several forced GCs. Meanwhile, CCL was consistent, small, quick, and lovely to use. And if you want a platform that's consistent across Windows, Mac, and Linux, and has both 32- and 64-bit support, then look no further.
I did try CormanLisp on Win32, and there were many things about it I liked. But it does not run properly on 64-bit Windows platforms, and is limited to Win32. It's also not free, and somehow I had it crash on me when I'd throw some garbage code at it. I also was easily able to make SBCL crash. Not so with CCL. Rock-solid. Really, those guys did an amazing job, and ultimately will help keep Lisp alive.
As for SLIME, I didn't try to get SLIME working with SBCL, but I did get it working nicely with CCL. No matter what your fancy is, I advise that people write code to be easily portable. Aim for Windows, Mac, and Linux, and aim for 64-bit. If you consider these, then CCL is your best choice overall.
A last attempt at an answer to this is to consider what is wrong with the others. Here's what I've come to find:
CLISP is nice, but is far slower, relative to SBCL or CCL. I see little upside
SBCL seems poor on Win32. Image size can get big.
CormanLisp is good on Win32, but not portable, and does not support Windows x64.
It also seems that Roger Corman is not actively developing CormanLisp, which is
a shame, but it's the reality.
Clojure (with a "j") is not Common Lisp. As nice as it may be, I think that
if you already know CL, then it's not worth the overhead of learning Clojure's
many differences. I'm sure some may pick them up fast, but I surely did not.
(If Java-compatible code is what you're after, then look at ABCL).
dave
There are portions of ANSI CL that leave certain details up to the implementations to determine; you will find that for those parts of the standard, each implementation will have its own quirks.
Also, look for things that are important to the runtime but not defined in the language: things like threading and multiprocessing and garbage collection will vary substantially in performance and reliability.
I have found SBCL to be the easiest implementation to work with in Linux; it has good support for threading in Linux. I can't say much about the garbage collector, because it hasn't mattered to me much yet.
On Windows, your best bet will probably be Allegro or LispWorks, although I've had some success with clisp on Windows. The Windows port of SBCL is progressing, but I haven't used it much, so I can't really comment.
Generally speaking, an understanding of these kinds of things that are difficult to acquire through research or analysis; it comes through experience. Just pick a decent implementation that you're comfortable with, and get to work. You'll figure out the tricky stuff as you go.
I don't know enough to give you a detailed answer, but I noticed that SBCL was considerably faster then Clisp when I was working with CL for my AI class. Unless you have a compelling reason not to, I'd suggest going with SBCL.
I've heard that Clisp is easier to install and is more portable than SBCL (which has lots of processor-specific optimizations), but if you're using Linux they're both easy enough to fetch from the package manager.
I found the error messages in clisp to be more friendly and help me find the problem faster.
It seems that SBCL's REPL is not friendly compared with clisp ? E.G. I can use TAB key to auto-complete input in clisp.
so clisp is a better for lisp newbie.
I've had pretty good luck with installing clisp using cygwin if you're under windows.
Depends on your OS of choice
Windows - use ecl or abcl
Linux - use sbcl or ecl or abcl or cmucl
Mac - ccl or ecl or sbcl
Other - abcl or ecl or sbcl
EDIT:
Sbcl on windows lacks threading and is, in general not that stable, and none of core maintainers use windows.
ecl is much better choice for cross platform lisps, its feature set is equaly stable on all major platforms.
EDIT 2011-10:
Sbcl windows now has threading support. It is not yet fully merged in mainiline, but there is a fork which is pretty stable which have threading and other Windows specific goodies.