[chicago-lisp] (no subject)
John Quigley gave a presentation on using SLIME with SBCL on a Debian system yesterday during the Chicago LUG meeting. There is a PDF file version of his presentation but I forgot to jot down the URL for it. John, perhaps you'd send it to the list? Since the presentation was made using Debain, and therefore used apt-get, somebody asked about getting the packages if one didn't use Debian. The following two sites are good places for lots of general information about lisp and have links to all of the packages mentioned during the presentation: <http://common-lisp.net/> <http://www.cl-user.net/asp/root-dir>. After the presentation, John and four of us who came to the meeting mostly because of our interest in the chicago-lisp group got together for a brief chat about chicago-lisp. We talked about what to do going forward and I believe that the consensus was to try to start meeting on a more regular basis. Apparently the space being used for the CLUG meetings would be available for other chicago-lisp gatherings. John asked if everyone was mostly interested in lisp in particular or rather a broader range of topics, for instance functional languages such as Scheme or ML. There was a bit of difference of opinion on this topic and I think it might still be a bit of an open question. One suggestion was that the group might want to start host a web-site, perhaps as an excuse for a group project. A wiki as well as cliki <http://en.wikipedia.org/wiki/ CLiki> and AllegroServer <http://allegroserve.sourceforge.net/> were discussed. Another idea was to adopt a project from Common Lisp Gardeners <http://tinyurl.com/ymgp7h>. For those who might not be familiar with the CL Gardeners (ibid):
A group of people intending to "tend the Common Lisp Garden". Their goal is two-fold : improving the attractiveness of CL for people who are considering using it, and providing those who want to learn the language with a plethora of small projects, so that they can learn it by practicing it, yet in a useful way.
Damien Kick wrote:
John Quigley gave a presentation on using SLIME with SBCL on a Debian system yesterday during the Chicago LUG meeting.
I saw it, and it was delightful. I remembered enough of it to be able to get SLIME working for me on Mac OS X with SBCL and Aquamacs Emacs... I also managed (in part) to get Viper mode working with SLIME. VIPER is "Viper Is a Package for Emacs Rebels" :-) It's a vi emulation mode for Emacs designed for those who don't necessarily want to use Emacs commands but want to stick with vi.
After the presentation, John and four of us who came to the meeting mostly because of our interest in the chicago-lisp group got together for a brief chat about chicago-lisp.
I missed the LISP meeting, even though I was there for the other LUG presentations (being a Linux/UNIX kind of fellow, the LUG was as much fun as the LISP meeting....)
John asked if everyone was mostly interested in lisp in particular or rather a broader range of topics, for instance functional languages such as Scheme or ML. There was a bit of difference of opinion on this topic and I think it might still be a bit of an open question.
I spoke with John afterwards, and that sounds about right. Personally, I'm interested in LISP in particular - and not in AI.
One suggestion was that the group might want to start host a web-site, perhaps as an excuse for a group project.
I tried Araneida; if AllegroServe is already chosen, that's fine; if not, Araneida might be fun. It *is* an open source project after all, and it works fine on SBCL (another open source project...). Araneida is the web server driving CLiki. Would it be possible to create a SLIME link to a development web server/LISP image at the hosting site? Sounds like that would be fantastic - and it is possible over SSH (found a link describing that very thing...)
Folks: Sorry for chiming in late here. Let me give the minutes of the meeting, in brief, first: Chicago Lisp: 2006-12-02 ------------------------------------------ In attendance: John, Michael, Peter, Damien, John Topic: Group's Focus - general trend of feeling was that we should remain a Lisp group - no need to focus on Lisp entirely, we're open to talks and projects that aren't necessarily Lisp specific * that said, most of us are here because we have a particular fondness for Lisp itself * for this reason, we will remain on the Chicago Lisp mailing list for the foreseeable future - try to attract commercial entities, we want to hear of the Lisp jobs! Topic: Meetings - small physical meetings to occur in tandem with the Chicago LUG until we're able to establish our own time/date/space * this will be directly dependent upon how well we reach out to other communities * we should work on fostering a community of folks, and establishing ourselves as independent to the LUG - we'll need interesting presentations to make the meetings have purpose and to attract new memberes * possible presentations ideas: + discussion/explanation of small projects that members are working on + talks regarding aspects of Lisp that were ahead of their time (such as aspect-oriented programming) Topic: Projects - possible collaborative work at Lisp Gardeners - work on setting up a website with a Lisp back-end Topic: Todo - acquire group domain name - gather info/requirements for a website that employs Lips on the backend (AllegroServe, mod_lisp?) - reach out to other dev groups, acquire interest - work on contacting interesting speakers that will help us attract members ------------ SNIP --------------- So, the meeting lasted about 20 or 30 minutes, and we had some nice discussion amongst ourselves. I'm looking forward to getting to know everyone and working on interesting code. Damien Kick wrote:
There is a PDF file version of his presentation but I forgot to jot down the URL for it.
That URL is: http://www.jquigley.com/files/beginners-lisp.tar.bz2
Apparently the space being used for the CLUG meetings would be available for other chicago-lisp gatherings.
Indeed, let's plan on meeting in tandem with the Chicago LUG, at least at the outset. When we have some more members and have had time to think things through, we'll probably be able to establish ourselves independently, with our own meeting date, time and place. Or, indeed, perhaps we stay closely aligned with the LUG for the foreseeable future. This leaves open the possibility of interesting cross-group pollination. I'm open to either, or other, possibilities.
if everyone was mostly interested in lisp in particular or rather a broader range of topics, for instance functional languages such as Scheme or ML. There was a bit of difference of opinion on this topic and I think it might still be a bit of an open question.
I think the general feeling is that we should remain as the Chicago Lisp. I'm happy with that, though I do recognize the problems associated with a group becoming 'pigeon-holed;' if you meet long enough, there's only so many topics one can discuss about a certain technology. The way I see it, the group could also become The Chicago Lisp and: - Programming Language Group (ala, Lambda The Ultimate) - Artificial Intelligence Group (ala, AAIA) - Functional Language Group (ala, RHS was to become?) I personally like the sound of the Chicago Lisp and Programming Language Group. What I just realized: if that were acronym-ized, it might become ChiLPL (which could be pronounced "chill pill" =) I'd like to hear what everyone else has to say on this. Ideally, we get this resolved ASAP. I'd like for us to be galvanized behind a definitive name in the very short term. We need a domain name, which I'm happy to fork over the $20 for if that's agreeable with everyone. One suggestion
was that the group might want to start host a web-site, perhaps as an excuse for a group project. A wiki as well as cliki <http://en.wikipedia.org/wiki/CLiki> and AllegroServer <http://allegroserve.sourceforge.net/> were discussed.
Another idea was to adopt a project from Common Lisp Gardeners
I thought this was a particularly well-conceived idea, and I'm already on their mailing list. I invite other Chicago Lispniks to join me there. This email is already plenty long. I've got a lot of other things to say, but I'll explore those ideas in other, more concise emails. Thanks again everyone! Regards, John Quigley
John Quigley wrote:
The way I see it, the group could also become The Chicago Lisp and:
- Programming Language Group (ala, Lambda The Ultimate) - Artificial Intelligence Group (ala, AAIA) - Functional Language Group (ala, RHS was to become?)
I'm good with names... * Chicago Lispniks * Chicago Lithpers ;-) * Chicago Area Programming Languages Group - that is, Chicago APL Group (heh) * Chicago Area Many Languages Group - that is, CAML Group (heh) * Chicago Lispy Group * Chicago Lispits * Chicago LISPers and Friends * Chicago Area LISPies et al * Chicago LISPit etc. To me, my interest in LISP has never been about AI or functional languages, etc - it was more about the capabilities of it and the programming nature of LISP. OOP on LISP has some interest, but OOP in anything but Ruby and Smalltalk has the feel of being "bolted on" rather than "integrated in" but haven't tried LISP OOP in depth yet.
On 12/4/06, John Quigley <jquigley@jquigley.com> wrote:
Chicago Lisp: 2006-12-02 ------------------------------------------ In attendance: John, Michael, Peter, Damien, John
Hey, don't forget me. I was there for the last 3 muinites! heh. Topic: Group's Focus
- general trend of feeling was that we should remain a Lisp group - no need to focus on Lisp entirely, we're open to talks and projects that aren't necessarily Lisp specific * that said, most of us are here because we have a particular fondness for Lisp itself * for this reason, we will remain on the Chicago Lisp mailing list for the foreseeable future - try to attract commercial entities, we want to hear of the Lisp jobs!
if everyone was mostly interested in lisp in particular or rather
a broader range of topics, for instance functional languages such as Scheme or ML. There was a bit of difference of opinion on this topic and I think it might still be a bit of an open question.
I think the general feeling is that we should remain as the Chicago Lisp. I'm happy with that, though I do recognize the problems associated with a group becoming 'pigeon-holed;' if you meet long enough, there's only so many topics one can discuss about a certain technology.
Hmm, I'm confused. Lets establish some terminology to help clarify: Scheme is a dialect of lisp Common lisp is a dialect of lisp {emacs lisp is too} So let's use "lisp" without any further constraints to refer to the "family" of lisp languages. Now scheme is a impure functional language (i.e. it has a "set" command), just like Common lisp is a impure functional language. I believe ML is a pure functional language. {i don't actually use it though, so don't quote me on that} ---- Now given this, i'm not sure what was just said. heh I would personally prefer having some room for non-lisp languages, but I would still be ok with constraining ourselfs to lisp (i.e. no ML or haskel (or erlang ;) ). I would have a issue though if we were to constrain ourselfs to the common lisp dialect.
I personally like the sound of the Chicago Lisp and Programming Language Group. What I just realized: if that were acronym-ized, it might become ChiLPL (which could be pronounced "chill pill" =)
I'd like to hear what everyone else has to say on this. Ideally, we get this resolved ASAP. I'd like for us to be galvanized behind a definitive name in the very short term.
Chill pill sounds clever to me. But I don't have any real strong feelings on the name.
Topic: Projects - possible collaborative work at Lisp Gardeners - work on setting up a website with a Lisp back-end
One suggestion
was that the group might want to start host a web-site, perhaps as an excuse for a group project. A wiki as well as cliki <http://en.wikipedia.org/wiki/CLiki> and AllegroServer <http://allegroserve.sourceforge.net/> were discussed.
Question. Does Allegroserve *require* you to buy allegro common lisp? You might alienate some potential helpers that way. Also as I mentioned before {in person}, having just implemented a wiki in scheme, I would probably be able to give some guidance if you decide to do a wiki.
Another idea was to adopt a project from Common Lisp Gardeners
I thought this was a particularly well-conceived idea, and I'm already on their mailing list. I invite other Chicago Lispniks to join me there.
This is probably too big of a project, but I'll toss out the idea anyway. What about writing a common lisp "interpreter" in scheme? Then using that platform, people could write common lisp or scheme code. All the standard common lisp libraries could then be available to scheme programs, and would be "continuation safe" (unlike most ffi's). And all the scheme features, and scheme libraries could easily be available to the "interpreted" common lisp code. I.E try to unite the 2 lisp worlds. :) Corey -- ((lambda (y) (y y)) (lambda (y) (y y)))
On Mon, Dec 04, 2006 at 07:06:29PM -0600, Corey Sweeney wrote:
Now scheme is a impure functional language (i.e. it has a "set" command), just like Common lisp is a impure functional language. I believe ML is a pure functional language. {i don't actually use it though, so don't quote me on that}
ML is impure, as is caml, OCaml, and F#. Haskell's probably the most popular purely functional language. There's also Clean, Miranda, and Curry. -johnnnnnnn
On Dec 4, 2006, at 19:06, Corey Sweeney wrote:
On 12/4/06, John Quigley <jquigley@jquigley.com> wrote:
I think the general feeling is that we should remain as the Chicago Lisp. I'm happy with that, though I do recognize the problems associated with a group becoming 'pigeon-holed;' if you meet long enough, there's only so many topics one can discuss about a certain technology.
Of course, the flip side is being thinly spread over too many things. Oh, and John, I apologize as this will duplicate a lot of what I wrote to you in a private e-mail.
Hmm, I'm confused. Lets establish some terminology to help clarify:
Scheme is a dialect of lisp Common lisp is a dialect of lisp {emacs lisp is too}
So let's use "lisp" without any further constraints to refer to the "family" of lisp languages.
``If they're all Lisps, presumably they're all built around some common core. Right?''
Not necessarily. Some years ago, when I was first becoming involved with language standards, I did a personal study of languages in the Lisp family to determine whether there was a common core of operators that were present throughout the family with the same name and semantics. In case you haven't heard of Kent Pitman before (sorry to be repetitive if you already have), he was the editor of the ANSI standard for Common Lisp, the effort to take what was at the time of
Kent Pitman, "Lambda, the Ultimate Political Party" <http:// tinyurl.com/y5ou9j>: the start of the standardization process, any number of divergent Lisp dialects and try to come up with something common. I think he would be in a very good position to know how similar or not all of those various lisp dialects where. Corey wrote:
Now scheme is a impure functional language (i.e. it has a "set" command), just like Common lisp is a impure functional language. I believe ML is a pure functional language. {i don't actually use it though, so don't quote me on that}
Scheme, from comp.lang.functional FAQ <http://tinyurl.com/yl6gln>:
[...] in (strict) functional languages such as SML or Scheme, [...] it is more common to find such programs written with an explicit loop, often expressed recursively. Nevertheless, there is still no need to update the values of the variables involved: [...]
Scheme: (define sum (lambda (from total) (if (= 0 from) total (sum (- from 1) (+ total from))))) (sum 10 0)
Common Lisp, from something as "general purpose knowledge" as Wikipedia <http://tinyurl.com/zql2x>:
Lastly, the Scheme standards documents require tail-call optimization, which the CL standard does not. Most CL implementations do offer tail-call optimization, although often only when the programmer uses an optimization directive. Nonetheless, common CL coding style does not favor the ubiquitous use of recursion that Scheme style prefers -- what a Scheme programmer would express with tail recursion, a CL user would usually express with an iterative expression in do, dolist, loop, or (more recently) with the iterate package.
"Most" Common Lispniks would write an iterative, i.e. non-functional, version, such as the following: (loop for i from 1 upto 10 summing i) When the most exposure to lisp I had was the usual cursory intro from a comparative languages course and a intro to AI course in college, I had the impression that everything in lisp was always recursion. Having been reintroduced by Paul Graham's ANSI Common Lisp, I was under the impression that doing things like using setq should be done only in emergencies. I forget how he phrases it. Something like pretending that it incurs a cost to the function or something like that. But that's why I'm personally glad that Peter Siebel wrote Practical Common Lisp, as it focuses more on getting useful stuff done, and shows quite a bit of the "just get stuff done" aspects of the language. Common Lisp and Scheme do come from different communities. I think it is interesting to note that most all the many divergent lisp dialects that were used at one time <http://tinyurl.com/y7puru>, 3Lisp, Flavors, Franz Lisp, Interlisp, Lisp 1.5, LOOPS, XLisp, ZetaLisp, etc., have been subsumed by Common Lisp. However, Scheme remains distinct. I think that is indicative of the differences between the languages and the communities. But like is mentioned in the comp.lang.functional FAQ (ibid):
It is often possible to write functional-style programs in an imperative language, and vice versa. It is then a matter of opinion whether a particular language can be described as functional or not. If one wants to slide far enough down the slippery slope, even C/C++ could be considered functional languages because one can write such code without using assignment (or iteration (...)).
int sum(int from, int total) { if (from == 0) { return total; } else { sum(from - 1, total + from); } } Many C/C++ compilers support tail-call optimizations, too. However, "most" C/C++ programmers would not write sum like this, using a for loop instead, just like "most" Common Lispniks. Probably because both of these languages consider tail-call optimization as a viable optimization technique (not explicitly mentioned in the standard), not a fundamental aspect of the language (unlike Scheme, which does explicitly require this behavior in the standard). "Most" Schemers would, however, use the recursive version. Corey wrote:
I would personally prefer having some room for non-lisp languages, but I would still be ok with constraining ourselfs to lisp ( i.e. no ML or haskel (or erlang ;) ). I would have a issue though if we were to constrain ourselfs to the common lisp dialect.
I personally would not have an issue with including many divergent dialects in the lisp family. In fact, I would love it if somebody could get Paul Graham to come talk about Arc, the newest vaporware member of the family. I suppose I would have an issue with a lisp group which was not cognizant of the distinctions, though.
Question. Does Allegroserve *require* you to buy allegro common lisp? You might alienate some potential helpers that way.
CMU Common Lisp Steel Bank Common Lisp GNU clisp (only single-threaded operation) OpenMCL Xanalys Lispworks MCL Scieneer Common Lisp (slightly broken as of 2004-02-29) Corman Common Lisp (with non-standard install method, might be broken as of 2004-02-29) Allegro Common Lisp The only reason I mentioned it was that it is an entire HTTP server in CL, as opposed to only part of it, as one would find with something like mod_lisp. But as others have mentioned, there are lots of other alternatives. Personally, I am looking for a lisp group because I like lisp and don't have enough excuse to use it at work. In fact, I think it would be sweet if we could get our hands on an old Symbolics machine and have everything be lisp, from the raw iron all the way up. But I'm strange like that. I don't expect a Linux group to host its web-server on a box running something other
No. There is Portable AllegroServe <http:// portableaserve.sourceforge.net/>. It works with: than Linux and I like my lisp groups to use as much lisp as possible. Corey wrote:
Also as I mentioned before {in person}, having just implemented a wiki in scheme, I would probably be able to give some guidance if you decide to do a wiki.
And there is CLiki <http://www.cliki.net/CLiki> and The Common Lisp Directory <http://tinyurl.com/y3fkb6>, both written in CL. Corey wrote:
This is probably too big of a project, but I'll toss out the idea anyway. What about writing a common lisp "interpreter" in scheme?
Yeah, you're right. It probably is too big of a project. Sure, we could knock out the basics of the language, what with lexical scoping and closures coming for free from Scheme, and adding dynamic scoping (special variables) in a few lines of code. Sure, CL style macros would be a day or two at best. Pathnames, logical pathnames, packages, and reader macros aren't even worth mentioning. CLOS would be a week or two. A full meta-object protocol might take another week. Maybe two. Adding CL style conditions would probably be two weeks, maybe three tops. But doing things like getting unwind- protect and call/cc to play well together might be a bit harder <http://tinyurl.com/y8pl6r>.
On 12/7/06, Damien Kick <dkixk@earthlink.net> wrote:
"Most" Common Lispniks would write an iterative, i.e. non-functional, version, such as the following:
(loop for i from 1 upto 10 summing i)
Interesting. This a tangent, but 90% of the time my iteration needs can be served by map and fold. The other times i use a recursive function. Long ago I used basic-a and C/C++, etc. and when i'd do for loops i'd usually be off by +-1 on my first try. But if "loop" works for you, go for it :) When the most exposure to lisp I had was the usual cursory intro from a
comparative languages course and a intro to AI course in college, I had the impression that everything in lisp was always recursion. Having been reintroduced by Paul Graham's *ANSI Common Lisp*, I was under the impression that doing things like using setq should be done only in emergencies. I forget how he phrases it. Something like pretending that it incurs a cost to the function or something like that. But that's why I'm personally glad that Peter Siebel wrote *Practical Common Lisp*, as it focuses more on getting useful stuff done, and shows quite a bit of the "just get stuff done" aspects of the language.
I avoid using set commands whenever I can, but I probably have differnt goals then you when programming. This is majorly tangental, and has nothing to do with any of our group decisions, but now that I said it, I'm getting really interested. What are peoples goals when programming? Some goals that I see are: * Learn things to improve my own programming technique * Get the current product/feature useable now * Get the current product/feature into a elegant (i.e. easily maintainable) form. I'm sure there are others. I guess the priority order matters to. I think most of the time my priorities are: 1. Learn things to improve my own programming technique {as evidenced by my excessive use of continuations :)} 2. Get the current product/feature into a elegant (i.e. easily maintainable) form. 3. Get the current product/feature useable now But depending on what else is going on (i.e. who's waiting for what i'm working on), then "Get the current product/feature useable now" can get pushed up. How about everyone else? Common Lisp and Scheme do come from different communities. I think it is
interesting to note that most all the many divergent lisp dialects that were used at one time <http://tinyurl.com/y7puru>, 3Lisp, Flavors, Franz Lisp, Interlisp, Lisp 1.5, LOOPS, XLisp, ZetaLisp, etc., have been subsumed by Common Lisp. However, Scheme remains distinct. I think that is indicative of the differences between the languages and the communities. But like is mentioned in the comp.lang.functional FAQ (ibid):
It is often possible to write functional-style programs in an imperative
language, and vice versa. It is then a matter of opinion whether a particular language can be described as functional or not.
If one wants to slide far enough down the slippery slope, even C/C++ could be considered functional languages because one can write such code without using assignment (or iteration (...)).
ya, functional programming can be refered to as a "technique" that can be used in a lot of languages. On the other hand, I'm writing a language that's purely functional, so I'm in the clear on this :)
Corey wrote:
I would personally prefer having some room for non-lisp languages, but I would still be ok with constraining ourselfs to lisp ( i.e. no ML or haskel (or erlang ;) ). I would have a issue though if we were to constrain ourselfs to the common lisp dialect.
I personally would not have an issue with including many divergent dialects in the lisp family. In fact, I would love it if somebody could get Paul Graham to come talk about Arc, the newest vaporware member of the family. I suppose I would have an issue with a lisp group which was not cognizant of the distinctions, though.
I've seen him on the scheme mailing lists lately. He does actually answer his email, so someone could probably just send him a email asking him. It should probably be someone more diplomatic then me :) Question. Does Allegroserve *require* you to buy allegro common lisp? You
might alienate some potential helpers that way.
No. There is Portable AllegroServe <http://portableaserve.sourceforge.net/>. It works with:
- CMU Common Lisp - Steel Bank Common Lisp - GNU clisp (only single-threaded operation) - OpenMCL - Xanalys Lispworks - MCL - Scieneer Common Lisp (slightly broken as of 2004-02-29) - Corman Common Lisp (with non-standard install method, might be broken as of 2004-02-29) - Allegro Common Lisp
The only reason I mentioned it was that it is an entire HTTP server in CL, as opposed to only part of it, as one would find with something like mod_lisp. But as others have mentioned, there are lots of other alternatives. Personally, I am looking for a lisp group because I like lisp and don't have enough excuse to use it at work. In fact, I think it would be sweet if we could get our hands on an old Symbolics machine and have everything be lisp, from the raw iron all the way up. But I'm strange like that. I don't expect a Linux group to host its web-server on a box running something other than Linux and I like my lisp groups to use as much lisp as possible.
I assume no one cares, but I'll mention it anyway: Drscheme comes with a full web server too :) It's based on continuation based dialogs. It's discussed in this paper: http://www.ccs.neu.edu/scheme/pubs/afp2002-f.ps.gz (I think there's a better paper on it, but i couldn't find it today) If you get a symbolics machine I'd be really interested in seeing it. I keep hearing about them, but i can never see it run. (last i saw it only ran on a proprietary card, inserted into a alpha) Corey wrote:
Also as I mentioned before {in person}, having just implemented a wiki in scheme, I would probably be able to give some guidance if you decide to do a wiki.
And there is CLiki <http://www.cliki.net/CLiki> and The Common Lisp Directory <http://tinyurl.com/y3fkb6>, both written in CL.
Corey wrote:
This is probably too big of a project, but I'll toss out the idea anyway. What about writing a common lisp "interpreter" in scheme?
Yeah, you're right. It probably *is* too big of a project. Sure, we could knock out the basics of the language, what with lexical scoping and closures coming for free from Scheme, and adding dynamic scoping (special variables) in a few lines of code. Sure, CL style macros would be a day or two at best. Pathnames, logical pathnames, packages, and reader macros aren't even worth mentioning. CLOS would be a week or two. A full meta-object protocol might take another week. Maybe two. Adding CL style conditions would probably be two weeks, maybe three tops. But doing things like getting unwind-protect and call/cc to play well together might be a bit harder <http://tinyurl.com/y8pl6r>.
Actually, your schedule makes it sound attainable. Basically instead of going after full ANSI-CL compliance, we could get "most" CL features working pretty quick. It wouldn't quite be a commercial development environment, but would provide some of the benifits. Basically the progress of the system could be measured by: When developing a program in the new system, what percentage of it was able to be done in the "emulated" Common Lisp, and how much had to be done in scheme? {also, i havn't cought the concept of unwind-protect and dynamic-wind yet. I just know that people are able to use those types of calls to block my continuations after they see me using continuations to get at stuff they didn't want me in :)} Corey -- ((lambda (y) (y y)) (lambda (y) (y y)))
Corey Sweeney wrote:
I avoid using set commands whenever I can, but I probably have differnt goals then you when programming.
One reason why I tend to think of Lisp as a functional language (even though it is technically multi-paradigm) has to do with the fact that I almost always program in a functional manner. Lisp for me has two primary advantages: a) supports the functional paradigm, and b) homoiconic. I tend to exploit both of those features to their fullest when I program in the language, as these have proven to produce remarkably powerful and bug-free code for me. That some Common Lisp implementations have poor support for optimized functional usage is an unfortunate, but rather irrelevant, point for me. When I need highly optimized code, I develop in C. I use Lisp for its elegance, and because it promotes the creation of rapid, bug-free programs. - John Quigley
Damien Kick wrote:
On Dec 4, 2006, at 19:06, Corey Sweeney wrote:
On 12/4/06, *John Quigley* <jquigley@jquigley.com
Scheme, from comp.lang.functional FAQ <http://tinyurl.com/yl6gln>:
[...] in (strict) functional languages such as SML or Scheme, [...] it is more common to find such programs written with an explicit loop, often expressed recursively. Nevertheless, there is still no need to update the values of the variables involved: [...]
Scheme: (define sum (lambda (from total) (if (= 0 from) total (sum (- from 1) (+ total from))))) (sum 10 0)
Most CL implementations do offer tail-call optimization, although often only when the programmer uses an optimization directive. Nonetheless, common CL coding style does not favor the ubiquitous use of recursion that Scheme style prefers -- what a Scheme programmer would express with tail recursion, a CL user would usually express with an iterative expression in do, dolist, loop, or (more recently) with the iterate package.
"Most" Common Lispniks would write an iterative, i.e. non-functional, version, such as the following:
(loop for i from 1 upto 10 summing i)
When the most exposure to lisp I had was the usual cursory intro from a comparative languages course and a intro to AI course in college, I had the impression that everything in lisp was always recursion.
My first exposure to Lisp was based on the (at the time) textbook used for the Introduction to LISP course. This book was ubiquituous at the time: "Lisp" by Winston and Horn - (at the time, 1st ed.). This book used MACLISP. There was no do - no loop - no dolist - no iterate. Everything was done in recursion. Of course, that's not Common LISP (which was then used by "LISP" by Winston and Horn, 3rd ed.). My understanding of tail-call recursion optimization was that it was just expected to be there and the programmer was expected to learn how to take advantage of it.
Common Lisp and Scheme do come from different communities. I think it is interesting to note that most all the many divergent lisp dialects that were used at one time <http://tinyurl.com/y7puru>, 3Lisp, Flavors, Franz Lisp, Interlisp, Lisp 1.5, LOOPS, XLisp, ZetaLisp, etc., have been subsumed by Common Lisp. However, Scheme remains distinct. I think that is indicative of the differences between the languages and the communities.
Scheme, in reality, is *not* a dialect of Lisp, but rather a new language. One of the biggest differences between the two is scoping: if I remember my terms right, one uses lexical scoping by default and one uses dynamic scoping. Scheme is to Lisp what Pascal is to Modula-2. Scheme is most likely best described as a Lisp descendant.
I personally would not have an issue with including many divergent dialects in the lisp family.
I agree. The more the merrier. No one's mentioned AutoLISP yet....
This is probably too big of a project, but I'll toss out the idea anyway. What about writing a common lisp "interpreter" in scheme?
Yeah, you're right. It probably *is* too big of a project.
I'm not sure how big it is - though it might be too big in Scheme. The Winston & Horn book I mentioned previously used the creation of a LISP interpreter as their last project in the book.
On Dec 4, 2006, at 5:03 PM, John Quigley wrote:
Folks:
Sorry for chiming in late here. Let me give the minutes of the meeting, in brief, first:
Chicago Lisp: 2006-12-02 ------------------------------------------ In attendance: John, Michael, Peter, Damien, John
<snip> Thanks for the meeting summary, and providing a link to the presentation. I've got SLIME going with SBCL here on my MacBook. With any luck I should be able to be at the upcoming meeting of CLUG, and participate in any Lisp discussion/planning that happens at there. WRT the website, I have only briefly tinkered with both Araneida and Portable AllegroServe. Neither one stood out to me as particularly better than the other, but I really only scratched the surface of their capabilities. I think a project to setup a Lisp-backed website for the group would be a decent first undertaking. Jason
participants (7)
-
Corey Sweeney -
Damien Kick -
David Douthitt -
Jason Foreman -
John Quigley -
johnnnnnnn -
Paul F. Dietz