Libraries for day-to-day projects ?
Hi all, I'm fairly new to this mailing list and Scheme / Lisp as well. I come from a Python background and must admit the features present in Python that are coming from the Lisp world make me feel comfortable in my new language. I am planning on using Scheme as my default language for some projects of mine and I am wondering what is in the ecosystem of libraries and packages that would allow me to get some additions to the core feature quickly. There is "quicklisp" for Common Lisp packages and libraries. It seems to be somewhat similar to "pip" and "easy_install" in Python. Is there something equivalent that I could make use of with Gambit Scheme ? I was told that Chicken Scheme has a lot of libraries and packages to help deal with the day-to-day tasks a developer might run into. I believe this is specific to Chicken Scheme, not Gambit. Am I right ? Some possible tasks I may have to deal with : - regex - directories and files navigation, creation, renaming, etc. - web server - numerical computation (linear algebra, arrays, matrices, vectors, etc.) - symbolic computation - html generation / templating - database interaction Any hint or advice would be appreciated. -- Eric
On Tue, Jul 8, 2014 at 4:15 PM, Eric Parent <eric@eparent.info> wrote:
Hi all,
I'm fairly new to this mailing list and Scheme / Lisp as well.
I come from a Python background and must admit the features present in Python that are coming from the Lisp world make me feel comfortable in my new language.
I am planning on using Scheme as my default language for some projects of mine and I am wondering what is in the ecosystem of libraries and packages that would allow me to get some additions to the core feature quickly.
There is "quicklisp" for Common Lisp packages and libraries. It seems to be somewhat similar to "pip" and "easy_install" in Python. Is there something equivalent that I could make use of with Gambit Scheme ? I was told that Chicken Scheme has a lot of libraries and packages to help deal with the day-to-day tasks a developer might run into. I believe this is specific to Chicken Scheme, not Gambit. Am I right ?
Some possible tasks I may have to deal with : - regex - directories and files navigation, creation, renaming, etc. - web server - numerical computation (linear algebra, arrays, matrices, vectors, etc.) - symbolic computation - html generation / templating - database interaction
Any hint or advice would be appreciated.
Hi Eric, I'm trying to work on that problem with the project http://schemespheres.org It is sort of Quicklisp for Gambit, with multiplatform support. It is not "complete" in the sense that some important parts are missing, but the upcoming version brings full support for Linux/OSX/iOS/Android. This version is currently beta (the development branch of the github projects). I will work soon also integrating or developing most of the things you mention, although I've been more focused on the general aspects of integrating several libraries/modules and multiplatform support. Most notably, it's lacking database interaction and a web server, but of course it's planned in the future. Most of those things can be found as independent project, and my intention is to merge some of them in the project (with the due credit and licenses). Some times this is straightforward and some times it isn't, and that's one of the reasons of the project. Spheres are fully compatible with Gambit, so you don't have to worry about getting locked into the platform. Hope it helps, and I hope the project grows to better provide that what you need. Álvaro
On Jul 8, 2014, at 9:59 AM, Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com> wrote:
Hi Eric,
I'm trying to work on that problem with the project http://schemespheres.org It is sort of Quicklisp for Gambit, with multiplatform support. It is not "complete" in the sense that some important parts are missing, but the upcoming version brings full support for Linux/OSX/iOS/Android. This version is currently beta (the development branch of the github projects). I will work soon also integrating or developing most of the things you mention, although I've been more focused on the general aspects of integrating several libraries/modules and multiplatform support. Most notably, it's lacking database interaction and a web server, but of course it's planned in the future. Most of those things can be found as independent project, and my intention is to merge some of them in the project (with the due credit and licenses). Some times this is straightforward and some times it isn't, and that's one of the reasons of the project. Spheres are fully compatible with Gambit, so you don't have to worry about getting locked into the platform.
Hope it helps, and I hope the project grows to better provide that what you need.
I'd love to see SchemeSpheres turn into a Quicklisp for Gambit. It might be challenging to achieve that. Some perspective about what Quicklisp is and what it does might be helpful. The instructions for installing Quicklisp on a supported Common Lisp implementation are: 1. Download this link: http://beta.quicklisp.org/quicklisp.lisp 2. Load that file in your Lisp. That's it; you're done. All 1,000 or so Quicklisp-supported libraries are now available to use. If you want, you can add a small blob of code to your Lisp's init file that will automatically initialize Quicklisp any time you start the Lisp. Quicklisp itself can do that for you, if you like: eval (ql:add-to-init-file) and it will detect which Lisp you're running and add its startup code to the appropriate init file. From some Lisps you can even skip Step 1 above, because they can load quicklisp.lisp directly from the URL. Once you have Quicklisp, using it is about as easy as it could possibly be. Run ql:system-apropos to find out the exact name of a library you're interested in, then run ql:quickload with the name of the library. Done. Quicklisp interoperates with ASDF, the system-definition tool, making it equally easy to use its libraries in your projects. All you have to do is add a :depends-on clause to your system definition, mentioning the names of any Quicklisp libraries you want to use, make sure that you've installed them using ql:quickload, and you're done. Quicklisp doesn't have anything like SchemeSpheres' concept of "spheres". Its collection of libraries is a completely flat list of a thousand or so individual libraries with no sort of hierarchy or organization imposed on them. I haven't found that to be a weakness. On the contrary, it's simply one less thing I need to learn about in order to use it. If it has a weakness it's that, with over a thousand libraries available and no reliable source of summaries of what they're for, it can take significant time to find out exactly which libraries you might want to use. That's a pretty small quibble in the scheme of things, though. Quicklisp is incredibly useful and convenient. I use it in 100% of my Common Lisp projects, and I miss it whenever I'm working in another language. There are pretty good package managers for some other languages, but it's hard to beat Quicklisp for convenience and ease of use. The fact that it works with most Common Lisp implementations is just gravy.
On Tue, Jul 8, 2014 at 5:31 PM, mikel evins <mevins@me.com> wrote:
On Jul 8, 2014, at 9:59 AM, Álvaro Castro-Castilla < alvaro.castro.castilla@gmail.com> wrote:
Hi Eric,
I'm trying to work on that problem with the project http://schemespheres.org It is sort of Quicklisp for Gambit, with multiplatform support. It is not "complete" in the sense that some important parts are missing, but the upcoming version brings full support for Linux/OSX/iOS/Android. This version is currently beta (the development branch of the github projects). I will work soon also integrating or developing most of the things you mention, although I've been more focused on the general aspects of integrating several libraries/modules and multiplatform support. Most notably, it's lacking database interaction and a web server, but of course it's planned in the future. Most of those things can be found as independent project, and my intention is to merge some of them in the project (with the due credit and licenses). Some times this is straightforward and some times it isn't, and that's one of the reasons of the project. Spheres are fully compatible with Gambit, so you don't have to worry about getting locked into the platform.
Hope it helps, and I hope the project grows to better provide that what you need.
I'd love to see SchemeSpheres turn into a Quicklisp for Gambit. It might be challenging to achieve that. Some perspective about what Quicklisp is and what it does might be helpful.
The instructions for installing Quicklisp on a supported Common Lisp implementation are:
1. Download this link: http://beta.quicklisp.org/quicklisp.lisp
2. Load that file in your Lisp.
That's it; you're done. All 1,000 or so Quicklisp-supported libraries are now available to use.
If you want, you can add a small blob of code to your Lisp's init file that will automatically initialize Quicklisp any time you start the Lisp. Quicklisp itself can do that for you, if you like: eval (ql:add-to-init-file) and it will detect which Lisp you're running and add its startup code to the appropriate init file.
From some Lisps you can even skip Step 1 above, because they can load quicklisp.lisp directly from the URL.
Once you have Quicklisp, using it is about as easy as it could possibly be. Run ql:system-apropos to find out the exact name of a library you're interested in, then run ql:quickload with the name of the library. Done.
Quicklisp interoperates with ASDF, the system-definition tool, making it equally easy to use its libraries in your projects. All you have to do is add a :depends-on clause to your system definition, mentioning the names of any Quicklisp libraries you want to use, make sure that you've installed them using ql:quickload, and you're done.
Quicklisp doesn't have anything like SchemeSpheres' concept of "spheres". Its collection of libraries is a completely flat list of a thousand or so individual libraries with no sort of hierarchy or organization imposed on them. I haven't found that to be a weakness. On the contrary, it's simply one less thing I need to learn about in order to use it.
If it has a weakness it's that, with over a thousand libraries available and no reliable source of summaries of what they're for, it can take significant time to find out exactly which libraries you might want to use. That's a pretty small quibble in the scheme of things, though. Quicklisp is incredibly useful and convenient. I use it in 100% of my Common Lisp projects, and I miss it whenever I'm working in another language.
There are pretty good package managers for some other languages, but it's hard to beat Quicklisp for convenience and ease of use. The fact that it works with most Common Lisp implementations is just gravy.
Thanks for the explanation, I appreciate. I might have used the similarity to Quicklisp too lightly, since I just took the reference regarding the concept of "set of libraries for day-to-day projects". I'd say that the concept is closer to the Yeoman project + a set of generic libraries. I don't see SchemeSpheres reaching that kind of integration any time soon. The model is more adapted to Gambit's C/universal code generation (doesn't intend to be multi-implementation at the moment), and tries to make it easier to use and automate some of Gambit's features. I don't see the idea of a flat super-module working well for Gambit, but maybe I'm wrong on this. This leads me to a question: would Gambit be able to discard unused function in some way? I guess it's a hard thing to do since the generated code needs to be linked and thus only a link-time optimization would be able to do that... and still, that would be for C functions. Perhaps a post-syntactic expansion done at the Scheme code level could achieve that, and pave the road towards the concept of Quicklisp. Either that or a module-per-function approach. But this last approach wouldn't allow Gambit to provide for the single-host optimization, am I right? Álvaro
On Jul 8, 2014, at 10:56 AM, Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com> wrote:
Thanks for the explanation, I appreciate. I might have used the similarity to Quicklisp too lightly, since I just took the reference regarding the concept of "set of libraries for day-to-day projects". I'd say that the concept is closer to the Yeoman project + a set of generic libraries.
I don't see SchemeSpheres reaching that kind of integration any time soon. The model is more adapted to Gambit's C/universal code generation (doesn't intend to be multi-implementation at the moment), and tries to make it easier to use and automate some of Gambit's features. I don't see the idea of a flat super-module working well for Gambit, but maybe I'm wrong on this.
I don't see why it wouldn't work as well for Gambit as for Common Lisp. A Quicklisp-style tool would be helpful for any Scheme implementation that supported it. Even if it was Gambit-only, I'd still be a fan. Judging by the effect that Quicklisp has had on the Common Lisp world, it's probably reasonable to expect that people would want to port it, and that library authors would want to make their libraries work with it.
This leads me to a question: would Gambit be able to discard unused function in some way? I guess it's a hard thing to do since the generated code needs to be linked and thus only a link-time optimization would be able to do that... and still, that would be for C functions.
Perhaps a post-syntactic expansion done at the Scheme code level could achieve that, and pave the road towards the concept of Quicklisp. Either that or a module-per-function approach. But this last approach wouldn't allow Gambit to provide for the single-host optimization, am I right?
I don't think you need that to implement a Quicklisp-style tool. I mean, it wouldn't hurt, but it's not required. What's required is - a collection of libraries that work well with Gambit - some analog of ASDF that makes it easy to load all of these libraries, and easy for each library to declare its dependencies on others - an easily-accessible repository for the libraries - an efficient way to collect updates to the libraries and make them accessible from the repo - a tool that enables you to quickly and easily search the libraries by name and description - a tool that enables you to quickly and easily download and install any given library - an easy way to tell the tools about nonstandard and local repositories - an easy way to tell the tools that you want a specific version of a library, or multiple versions of a library That's kind of a lot, but on the other hand, Zach is just one guy and does it in his spare time.
Ok. Let's see this list. I'm interested in ways of improving SchemeSpheres, so this is quite useful. Keep in mind, however, that providing support for mobile devices brings complexity and limitations to what can be achieved.
- a collection of libraries that work well with Gambit
Well, that's certainly what I'm trying to do. However, there are some issues generally involving different syntax systems. I think there have been some improvements in this area recently in SS.
- some analog of ASDF that makes it easy to load all of these libraries, and easy for each library to declare its dependencies on others
That functionality is part of SS, even platform-conditional dependencies (like, GL or GLES for mobile for instance).
- an easily-accessible repository for the libraries
I'm using github. Installation is done through cloning a repo and running a script.
- an efficient way to collect updates to the libraries and make them accessible from the repo
Not sure what you mean by this. I'm using github, and people who have contributed to SS have done it through git forking and pull requests.
- a tool that enables you to quickly and easily search the libraries by name and description
That's a big TODO. I love this idea and I want to provide it. The first step is documenting everything, and that is a pretty big task.
- a tool that enables you to quickly and easily download and install any given library
The tool is called SSpheres, and does this. Is not perfect, as many things being improved, but it works.
- an easy way to tell the tools about nonstandard and local repositories
This is important, and easy to add (although not available at the moment). I thought about it as a necessary functionality since the beginning.
- an easy way to tell the tools that you want a specific version of a library, or multiple versions of a library
Same here. I intend to implement versions with Git tags for this. At the moment "versioning" is just used for differentiating targets (such as "debug", "optimized", etc..) Thank you for your interaction, I really appreciate.
Thank to you guys for this discussion about schemesphere. I was thinking about going towards Common Lisp (CL) for a long time and ended up really doing Scheme at work in the first place. I think I'll have a look at the Chicken Scheme (and it's "eggs" systems apparently from which Python was inspired) and eventually CL; I even have found a nice tutorial "Lisp for the Web" that's really inspiring. Cheers, Eric 2014-07-08 12:38 GMT-04:00 Álvaro Castro-Castilla < alvaro.castro.castilla@gmail.com>:
Ok. Let's see this list. I'm interested in ways of improving SchemeSpheres, so this is quite useful. Keep in mind, however, that providing support for mobile devices brings complexity and limitations to what can be achieved.
- a collection of libraries that work well with Gambit
Well, that's certainly what I'm trying to do. However, there are some issues generally involving different syntax systems. I think there have been some improvements in this area recently in SS.
- some analog of ASDF that makes it easy to load all of these libraries, and easy for each library to declare its dependencies on others
That functionality is part of SS, even platform-conditional dependencies (like, GL or GLES for mobile for instance).
- an easily-accessible repository for the libraries
I'm using github. Installation is done through cloning a repo and running a script.
- an efficient way to collect updates to the libraries and make them accessible from the repo
Not sure what you mean by this. I'm using github, and people who have contributed to SS have done it through git forking and pull requests.
- a tool that enables you to quickly and easily search the libraries by name and description
That's a big TODO. I love this idea and I want to provide it. The first step is documenting everything, and that is a pretty big task.
- a tool that enables you to quickly and easily download and install any given library
The tool is called SSpheres, and does this. Is not perfect, as many things being improved, but it works.
- an easy way to tell the tools about nonstandard and local repositories
This is important, and easy to add (although not available at the moment). I thought about it as a necessary functionality since the beginning.
- an easy way to tell the tools that you want a specific version of a library, or multiple versions of a library
Same here. I intend to implement versions with Git tags for this. At the moment "versioning" is just used for differentiating targets (such as "debug", "optimized", etc..)
Thank you for your interaction, I really appreciate.
-- Eric
On Jul 8, 2014, at 11:52 AM, Eric Parent <eric@eparent.info> wrote:
Thank to you guys for this discussion about schemesphere.
I was thinking about going towards Common Lisp (CL) for a long time and ended up really doing Scheme at work in the first place.
I think I'll have a look at the Chicken Scheme (and it's "eggs" systems apparently from which Python was inspired) and eventually CL; I even have found a nice tutorial "Lisp for the Web" that's really inspiring.
Chicken is definitely a nice implementation and its eggs are great. There are a lot of them, and the Chicken distribution includes a command-line tool, "chicken-install", that makes it dead easy to download and install them. I tend to use Gambit rather than Chicken, usually, but I have to admit that Chicken's huge collection of libraries is always a temptation, and sometimes I give in to it.
Any particular reason why you prefer Gambit over Chicken ? Performance ? More standard compliant ? Le 2014-07-08 13:05, "mikel evins" <mevins@me.com> a écrit :
On Jul 8, 2014, at 11:52 AM, Eric Parent <eric@eparent.info> wrote:
Thank to you guys for this discussion about schemesphere.
I was thinking about going towards Common Lisp (CL) for a long time and ended up really doing Scheme at work in the first place.
I think I'll have a look at the Chicken Scheme (and it's "eggs" systems apparently from which Python was inspired) and eventually CL; I even have found a nice tutorial "Lisp for the Web" that's really inspiring.
Chicken is definitely a nice implementation and its eggs are great. There are a lot of them, and the Chicken distribution includes a command-line tool, "chicken-install", that makes it dead easy to download and install them.
I tend to use Gambit rather than Chicken, usually, but I have to admit that Chicken's huge collection of libraries is always a temptation, and sometimes I give in to it.
On Jul 9, 2014, at 11:23 AM, Eric Parent <eric@eparent.info> wrote:
Any particular reason why you prefer Gambit over Chicken ? Performance ? More standard compliant ?
It might be hard to answer that question. I've used both of them for many years. I like them both a lot. I might use Gambit more often because a few years ago I was writing some apps on iOS and OS X and found it easier to make Gambit work with iOS than to make Chicken work with it. Once I started building some apps using Gambit, it became a sort of self-reinforcing proposition, since I soon knew more about how to make Gambit do what I wanted than about how to make Chicken do it. That may be all there is to it. I still always consider Chicken, and sometimes I choose it--particularly if I want to do something relatively small and Chicken has good libraries to support it. In general, there are more likely to be supporting libraries for a given task in Chicken, simply because its library ecosystem is huge. It's a good implementation and I'm never sorry to use it. But I also really like Gambit, and I've learned my way around it well enough to make it an attractive choice in a lot of cases. For one thing, I hacked its innards a few times successfully to make it do new things, and that makes me confident I can do it again. Its chief disadvantage is that it doesn't have Chicken's vast cornucopia of libraries. I think Gambit usually comes out ahead in benchmarks, but not so far ahead that it should make a difference in choosing between them in most cases; both of them are good compilers that generate good code for a variety of interesting platforms. On the other hand, if there were a Scheme that compiled to native code--or even efficient bytecode--in RAM, that supported saving and loading images, that worked on at least OS X, Linux, and Windows, and that had a foreign function interface capable of dynamic linking to foreign libraries without wrapping them in Scheme-specific glue code, I'd probably switch to that in an instant. WIll Clinger's MacScheme had all those features except platform portability, and I miss it. Heck, it even knew how to compile different functions to bytecode or native code and run both kinds of functions from the same runtime. Environments like that are getting harder to come by lately.
Many thanks to you all, (Mikel, Alvaro, Marc and Dirk, for all the comments and explanations. That's really interesting to me. I'll probably attend the ILC at Université de Montréal in August and will surely attend the presentation on SchemeSphere if I'm there. I'll go through the guided tour of "Chicken Republic" and get familiar with its egg system until then. Cheers, Eric 2014-07-09 12:39 GMT-04:00 mikel evins <mevins@me.com>:
On Jul 9, 2014, at 11:23 AM, Eric Parent <eric@eparent.info> wrote:
Any particular reason why you prefer Gambit over Chicken ? Performance ? More standard compliant ?
It might be hard to answer that question. I've used both of them for many years. I like them both a lot.
I might use Gambit more often because a few years ago I was writing some apps on iOS and OS X and found it easier to make Gambit work with iOS than to make Chicken work with it. Once I started building some apps using Gambit, it became a sort of self-reinforcing proposition, since I soon knew more about how to make Gambit do what I wanted than about how to make Chicken do it. That may be all there is to it.
I still always consider Chicken, and sometimes I choose it--particularly if I want to do something relatively small and Chicken has good libraries to support it.
In general, there are more likely to be supporting libraries for a given task in Chicken, simply because its library ecosystem is huge. It's a good implementation and I'm never sorry to use it.
But I also really like Gambit, and I've learned my way around it well enough to make it an attractive choice in a lot of cases. For one thing, I hacked its innards a few times successfully to make it do new things, and that makes me confident I can do it again.
Its chief disadvantage is that it doesn't have Chicken's vast cornucopia of libraries.
I think Gambit usually comes out ahead in benchmarks, but not so far ahead that it should make a difference in choosing between them in most cases; both of them are good compilers that generate good code for a variety of interesting platforms.
On the other hand, if there were a Scheme that compiled to native code--or even efficient bytecode--in RAM, that supported saving and loading images, that worked on at least OS X, Linux, and Windows, and that had a foreign function interface capable of dynamic linking to foreign libraries without wrapping them in Scheme-specific glue code, I'd probably switch to that in an instant. WIll Clinger's MacScheme had all those features except platform portability, and I miss it. Heck, it even knew how to compile different functions to bytecode or native code and run both kinds of functions from the same runtime.
Environments like that are getting harder to come by lately.
-- Eric
On Jul 8, 2014, at 11:38 AM, Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com> wrote: [...snip...]
- an easily-accessible repository for the libraries
I'm using github. Installation is done through cloning a repo and running a script.
Zach uses Github, too.
- an efficient way to collect updates to the libraries and make them accessible from the repo
Not sure what you mean by this. I'm using github, and people who have contributed to SS have done it through git forking and pull requests.
Libraries go through various versions. You want it to be easy for your tools to fetch the latest versions of libraries, and to fetch specific versions of libraries when the user wants that. Here's what a typical interaction with Quicklisp looks like; let's suppose I know I want to use a library called "fad". I start by searching to see if Quicklisp knows about it: CL-USER> (ql:system-apropos "fad") #<SYSTEM cl-fad / cl-fad-0.7.2 / quicklisp 2014-05-25> #<SYSTEM cl-fad-test / cl-fad-0.7.2 / quicklisp 2014-05-25> Notice that the metadata maintained by Quicklisp reports both the version that cl-fad assigns to itself, and also an independent version maintained by Quicklisp. That means that Quicklisp can tell the differences between versions independently of the version-naming convention of any particular library. However, it also means that Quicklisp has to do its own (minimal) packaging in order to wrap its version number around the library. That's not such a bad thing, as it turns out, since it also means that using Quicklisp to get a library means you can rely on getting a consistent version of it.
- a tool that enables you to quickly and easily search the libraries by name and description
That's a big TODO. I love this idea and I want to provide it. The first step is documenting everything, and that is a pretty big task.
You can do a lot even without documentation of the libraries. Many libraries in Quicklisp have sparse or even nonexistent documentation. I'm not saying that's good; what I am saying is that the apropos search is useful even if you only have library names.
- a tool that enables you to quickly and easily download and install any given library
The tool is called SSpheres, and does this. Is not perfect, as many things being improved, but it works.
- an easy way to tell the tools about nonstandard and local repositories
This is important, and easy to add (although not available at the moment). I thought about it as a necessary functionality since the beginning.
Quicklisp enjoys a sort of shortcut here: it uses ASDF to load libraries, and you can tell Quicklisp about local libraries simply by adding pathnames to ASDF's registry of search paths. You mentiond that you have a library-loading tool; perhaps a similar arrangement would work for SchemeSpheres.
- an easy way to tell the tools that you want a specific version of a library, or multiple versions of a library
Same here. I intend to implement versions with Git tags for this. At the moment "versioning" is just used for differentiating targets (such as "debug", "optimized", etc..)
Thank you for your interaction, I really appreciate.
Sure; if it makes it easier to build SchemeSpheres and make it great, I'm glad to help.
Let me make a plug here… Álvaro will be giving a tutorial on SchemeSpheres on the first day of the International Lisp Conference at the University of Montreal on August 15. Some other Gambit users will be there. So if you are interested in knowing more about SchemeSpheres, and to meet fellow Gambiters, don’t miss this opportunity and register! http://ilc2014.iro.umontreal.ca It would be nice to see a good turnout of Gambiters at ILC! Marc On Jul 8, 2014, at 11:31 AM, mikel evins <mevins@me.com> wrote:
On Jul 8, 2014, at 9:59 AM, Álvaro Castro-Castilla <alvaro.castro.castilla@gmail.com> wrote:
Hi Eric,
I'm trying to work on that problem with the project http://schemespheres.org It is sort of Quicklisp for Gambit, with multiplatform support. It is not "complete" in the sense that some important parts are missing, but the upcoming version brings full support for Linux/OSX/iOS/Android. This version is currently beta (the development branch of the github projects). I will work soon also integrating or developing most of the things you mention, although I've been more focused on the general aspects of integrating several libraries/modules and multiplatform support. Most notably, it's lacking database interaction and a web server, but of course it's planned in the future. Most of those things can be found as independent project, and my intention is to merge some of them in the project (with the due credit and licenses). Some times this is straightforward and some times it isn't, and that's one of the reasons of the project. Spheres are fully compatible with Gambit, so you don't have to worry about getting locked into the platform.
Hope it helps, and I hope the project grows to better provide that what you need.
I'd love to see SchemeSpheres turn into a Quicklisp for Gambit. It might be challenging to achieve that. Some perspective about what Quicklisp is and what it does might be helpful.
The instructions for installing Quicklisp on a supported Common Lisp implementation are:
1. Download this link: http://beta.quicklisp.org/quicklisp.lisp
2. Load that file in your Lisp.
That's it; you're done. All 1,000 or so Quicklisp-supported libraries are now available to use.
If you want, you can add a small blob of code to your Lisp's init file that will automatically initialize Quicklisp any time you start the Lisp. Quicklisp itself can do that for you, if you like: eval (ql:add-to-init-file) and it will detect which Lisp you're running and add its startup code to the appropriate init file.
From some Lisps you can even skip Step 1 above, because they can load quicklisp.lisp directly from the URL.
Once you have Quicklisp, using it is about as easy as it could possibly be. Run ql:system-apropos to find out the exact name of a library you're interested in, then run ql:quickload with the name of the library. Done.
Quicklisp interoperates with ASDF, the system-definition tool, making it equally easy to use its libraries in your projects. All you have to do is add a :depends-on clause to your system definition, mentioning the names of any Quicklisp libraries you want to use, make sure that you've installed them using ql:quickload, and you're done.
Quicklisp doesn't have anything like SchemeSpheres' concept of "spheres". Its collection of libraries is a completely flat list of a thousand or so individual libraries with no sort of hierarchy or organization imposed on them. I haven't found that to be a weakness. On the contrary, it's simply one less thing I need to learn about in order to use it.
If it has a weakness it's that, with over a thousand libraries available and no reliable source of summaries of what they're for, it can take significant time to find out exactly which libraries you might want to use. That's a pretty small quibble in the scheme of things, though. Quicklisp is incredibly useful and convenient. I use it in 100% of my Common Lisp projects, and I miss it whenever I'm working in another language.
There are pretty good package managers for some other languages, but it's hard to beat Quicklisp for convenience and ease of use. The fact that it works with most Common Lisp implementations is just gravy.
_______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
participants (4)
-
Eric Parent -
Marc Feeley -
mikel evins -
Álvaro Castro-Castilla