December 2006 - chicago-lisp@common-lisp.net

Re: [chicago-lisp] (no subject)
by dkixk＠earthlink.net 09 Dec '06

09 Dec '06

-----Original Message----- >From: John Quigley <jquigley(a)jquigley.com> >Sent: Dec 8, 2006 12:29 PM >To: Chicago LISP <chicago-lisp(a)common-lisp.net> >Subject: Re: [chicago-lisp] (no subject) > >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. This has nothing to do with "highly optimized code" in the sense of C being optimized. That is, tail-call optimization is not important because of its impact on run-time performace. Consider the two following versions of a naive REPL. One, I call CL because it uses LOOP, which does not exsit in Scheme, and one I call Scheme, because it uses recursion instead of iteration. (defun cl-repl () (loop for cmd from 1 do (format t "~&~A> " cmd) (princ (eval (read))))) (defun scheme-repl (&optional (cmd 1)) (format t "~&~A> " cmd) (princ (eval (read))) (scheme-repl (1+ cmd))) And lets see what happens when we run them in a CL image. PG-USER> (cl-repl) 1> nil NIL 2> (list 1 2 3) (1 2 3) 3> (list 'x 'y 'z) (X Y Z) 4> (list '|x| 'y '|z|) (x Y z) 5> And now we'll break at this point. Leaving out all of the SWANK calls in the stack trace, we find the following: 28: (READ) 29: (LET ((CMD 1)) (DECLARE (TYPE REAL CMD)) (TAGBODY EXCL::NEXT-LOOP (PROGN (FORMAT T "~&~A> " CMD) (PRINC #)) (EXCL::LOOP-REALLY-DESETQ CMD (1+ CMD)) (GO EXCL::NEXT-LOOP) EXCL::END-LOOP)) 30: (CL-REPL) And now what happens with the other version. PG-USER> (scheme-repl) 1> nil NIL 2> (list 1 2 3) (1 2 3) 3> (list 'x 'y 'z) (X Y Z) 4> (list '|x| 'y '|z|) (x Y z) 5> And the stack trace. Again, leaving out all of the SWANK calls. 28: (READ) 29: (SCHEME-REPL 5) 30: (SCHEME-REPL 4) 31: (SCHEME-REPL 3) 32: (SCHEME-REPL 2) 33: (SCHEME-REPL) So, this lisp is not using tail-call elimination for this code. If we write code like scheme-repl, we will eventually wind up with a stack overflow. This has nothing to do with whether or not the code is "highly optimized", as in runs fast as C. It has everything to do with whether or not the code will do the correct thing as a REPL. cl-repl will run in any/all CL images and will work as a REPL no matter how many command one types. scheme-repl in this lisp image will blow up after a large number of commands. In Scheme, scheme-repl would work just as well as cl-repl works in CL because Scheme requires tail-call elimination. Is this really irrelevant to you? Just an optimization issue because if one had infinite memory then the scheme-repl version in this CL would still work for an infinite number of commands? You know, just make sure to document that your user just needs to install the infinite RAM card before using your software. I can understand not wanting to quibble about a few megabytes between friends. One CL implementation only uses 1K and another uses 1M, 2K vs 2M, etc. Sure, that's just an optimization issue. But the difference between n and infinity?

3 3

[chicago-lisp] (no subject)
by Damien Kick 09 Dec '06

09 Dec '06

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.

7 11

Re: [chicago-lisp] (no subject)
by dkixk＠earthlink.net 09 Dec '06

09 Dec '06

-----Original Message----- >From: John Quigley <jquigley(a)jquigley.com> >Sent: Dec 8, 2006 2:20 PM >To: Chicago LISP <chicago-lisp(a)common-lisp.net> >Subject: Re: [chicago-lisp] (no subject) > >dkixk(a)earthlink.net wrote: >> This has nothing to do with "highly optimized code" in the sense of C being optimized. > >Yea, that was a poor statement on my part, and was meant as a mildly >sarcastic remark ('mildly,' because I do system development in C, and I >do like the language). > >The point I didn't take time to develop in that email: that a Lisp's >lack of tail-call optimization at the compiler level isn't an important >issue for me. Nor does it prevent me from writing code in a functional >way. While it puts more responsibility on the developer, having the >choice of using standard recursion can be beneficial (if you want >complete stack back-traces, for instance). I totally agree. Whatever does or does not happen at the compiler level is not important. What I do think is important is whether or not one style is limited within the framework of the language I'm using. So to try and put an end to this debate once and for all, let's try an objective experiment. PG-USER> ;;;; Compile file d:/tmp/duff.lisp ... ;;; Compiling file d:\tmp\duff.lisp ; While compiling REPL-WITH-LOOP: Warning: Variable DUFF-*** is never used. ;;; Writing fasl file d:\tmp\duff.fasl ;;; Fasl write complete PG-USER> (with-open-file (s "duff.lisp") (loop for line = (read-line s nil) while line do (princ line) (terpri))) (in-package :pg-user) (defun duff-user-input () "(make-array (expt 10 4) :initial-element 0)") (defun repl-with-loop () (handler-case (loop for duff-*** = nil then duff-** for duff-** = nil then duff-* for duff-* = (eval (read-from-string (duff-user-input))) finally (return-from repl-with-loop :not-limited)) (error () :limited))) (defun repl-with-funk (&optional duff-* duff-** duff-***) (declare (ignore duff-***)) (handler-case (repl-with-funk (eval (read-from-string (duff-user-input))) duff-* duff-**) (condition () :limited) (:no-error (x) (or x :not-limited)))) NIL PG-USER> (time (repl-with-funk)) ; cpu time (non-gc) 40 msec user, 0 msec system ; cpu time (gc) 381 msec user, 0 msec system ; cpu time (total) 421 msec user, 0 msec system ; real time 481 msec ; space allocation: ; 12,512 cons cells, 14,344,840 other bytes, 0 static bytes :LIMITED PG-USER> (time (eq * (repl-with-loop))) ... but I still don't have the answer to whether or not (eq (repl-with-funk) (repl-with-loop)). I have no evidence yet with which to try and convince you so I'll just forget about it until I know the result. My intuition that tail-call elimination is somehow fundamental to a functional functional style in a "lisp" will have to remain conjecture. Either way, nothing prevents you from writing funktional code but I'll keep using things like loop. Again, until that computation finishes. For now, I guess we'll just have to agree to disagree.

1 0

Re: [chicago-lisp] (no subject)
by dkixk＠earthlink.net 08 Dec '06

08 Dec '06

1 0

[chicago-lisp] Group Name
by David Douthitt 08 Dec '06

08 Dec '06

> * Chicago Area Programming Languages Group (Chicago APL Group) > * Chicago Area Many Languages Group (CAML Group) Gasp! You actually included these ;-) CAML is a different computer language entirely, as is APL.... No relations to LISP...

8 7

[chicago-lisp] IRC anyone?
by John Quigley 08 Dec '06

08 Dec '06

Anyone hang on IRC? I'm in #lisp(a)irc.oftc.net (oftc is similar to freenode in it's mission, however it's run much more professionally). Feel free to drop in and chat, it's pretty lonely in here. - John Quigley

1 0

[chicago-lisp] Project: website
by John Quigley 04 Dec '06

04 Dec '06

Folks: Alright, so all of the meeting attendees seemed to be in agreement with one another on the idea of collaborating on some kind of web software to get our site operational. We'd be interested in getting confirmation from those of you who couldn't join us physically this past Saturday. Now, I don't know very much about web development, particularly in the context of Lisp, so I'm looking forward to gaining better insight. My first question: everyone seemed interested in AllegroServe, and there were no mentions of mod_lisp. Any reasons for this, aside from the fact that Allegro is itself written in Lisp? - John Quigley

2 2

[chicago-lisp] LISP Gardeners
by David Douthitt 04 Dec '06

04 Dec '06

The list of projects is at the ALU site: http://wiki.alu.org/Gardeners_Projects

1 0

[chicago-lisp] quoted list modification-- "let" does not protect values
by David Riggs 03 Dec '06

03 Dec '06

Dear Lispers, I want to have an alist to keep track of occurances of items in a buffer I am searching. So I define a function to do that, and start off with a "let" to set an alist with the strings I am searching for, setting the crd to zero for each. But each time I invoke the function, the old values of the cdr are remembered. For example (defun mytest () (interactive) (let ((dot '("a" . 0)) (n 0)) (setcdr dot (1+ (cdr dot))) (setq n (1+ n)) (print dot)(print n) )) Will increase output ("a" . 1) 1, then ("a" . 2) 1 etc, increasing by one each call (though the "n" value is always reset to 0). If I change the let to be (let ((dot (cons "a" 0)) (n 0)) Then it works as expected, resetting to zero each time. Why does a function which sets a let declaired variable to a quoted alist not reset to inittial value each time it is called? Clearly I am quite unclear about something very fundamental. Would anyone like to straighten me out? Thanks, David Riggs, Oberlin Ohio

1 0

[chicago-lisp] First Call for Papers: TFP 2007, New York
by TFP 2007 01 Dec '06

01 Dec '06

CALL FOR PAPERS Trends in Functional Programming 2007 New York, USA April 2-4, 2007 http://cs.shu.edu/tfp2007/ OR http://tltc.shu.edu/tfp2007/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best articles presented at the symposium for publication in a high-profile volume. TFP 2007 is co-hosted by Seton Hall University and The City College of New York (CCNY) and will be held in New York, USA, April 2-4, 2007 at the CCNY campus. SCOPE OF THE SYMPOSIUM The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles leading-edge, previously unpublished research work Position Articles on what new trends should or should not be Project Articles descriptions of recently started new projects Evaluation Articles what lessons can be drawn from a finished project Overview Articles summarizing work with respect to a trendy subject Articles must be original and not submitted for simultaneous publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Articles on the following subject areas are particularly welcomed: o Dependently Typed Functional Programming o Validation and Verification of Functional Programs o Debugging for Functional Languages o Functional Programming and Security o Functional Programming and Mobility o Functional Programming to Animate/Prototype/Implement Systems from Formal or Semi-Formal Specifications o Functional Languages for Telecommunications Applications o Functional Languages for Embedded Systems o Functional Programming Applied to Global Computing o Functional GRIDs o Functional Programming Ideas in Imperative or Object-Oriented Settings (and the converse) o Interoperability with Imperative Programming Languages o Novel Memory Management Techniques o Parallel/Concurrent Functional Languages o Program Transformation Techniques o Empirical Performance Studies o Abstract/Virtual Machines and Compilers for Functional Languages o New Implementation Strategies o any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2007 program chair, Marco T. Morazan, at tfp2007(a)shu.edu. SUBMISSION AND DRAFT PROCEEDINGS Acceptance of articles for presentation at the symposium is based on the review of extended abstracts (6 to 10 pages in length) by the program committee. Accepted abstracts are to be completed to full papers before the symposium for publication in the draft proceedings and on-line. Further details can be found at the TFP 2007 website. POST-SYMPOSIUM REFEREEING AND PUBLICATION In addition to the draft symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. IMPORTANT DATES Abstract Submission: February 1, 2007 Notification of Acceptance: February 20, 2007 Registration Deadline: March 2, 2007 Camera Ready Full Paper Due: March 9, 2007 TFP Symposium: April 2-4, 2007 PROGRAMME COMMITTEE John Clements California Polytechnic State University, USA Marko van Eekelen Radboud Universiteit Nijmegen, The Netherlands Benjamin Goldberg New York University, USA Kevin Hammond University of St. Andrews, UK Patricia Johann Rutgers University, USA Hans-Wolfgang Loidl Ludwig-Maximilians Universität München, Germany Rita Loogen Philipps-Universität Marburg, Germany Greg Michaelson Heriot-Watt University, UK Marco T. Morazán (Chair) Seton Hall University, USA Henrik Nilsson University of Nottingham, UK Chris Okasaki United States Military Academy at West Point, USA Rex Page University of Oklahoma, USA Ricardo Pena Universidad Complutense de Madrid, Spain Benjamin C. Pierce University of Pennsylvania, USA John Reppy University of Chicago, USA Ulrik P. Schultz University of Southern Denmark, Denmark Clara Segura Universidad Complutense de Madrid, Spain Jocelyn Sérot Université Blaise Pascal, France Zhong Shao Yale University, USA Olin Shivers Georgia Institute of Technology, USA Phil Trinder Heriot-Watt University, UK David Walker Princeton University, USA ORGANIZATION Symposium Chair: Henrik Nilsson, University of Nottingham, UK Programme Chair: Marco T. Morazan, Seton Hall University, USA Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Marco T. Morazan, Seton Hall University, USA ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://tltc.shu.edu/tfp2007/ http://cs.shu.edu/tfp2007/

1 0