scripting in CL -- please comment
in [Lisp]
|
From: Tim X on 5 Dec 2009 19:44 mpeever <mpeever(a)gmail.com> writes: > I've been experimenting with CL scripting for about a year now. We've > got a significant amount of SBCL code working in our Legato Networker > environment. We've started small, but so far we're really happy with > it. I'm currently considering the benefits of replacing some > significant Perl processes in CL. There are some pending changes that > are much more daunting in Perl than CL. > > We wrote a quick-and-dirty toolkit to clean up some of the OS > interfacing: we've more or less tried to imitate Perl's operators. Our > toolkit appears to work on SBCL, CCL, and ECL. Making it support > multiple implementations was important, as we're still very much in > pilot mode: we may yet have to make some drastic changes and we need > to be able to move quickly. > > We've been taking advantage of the core-dump facilities in CL > implementations for code roll-outs. It makes updates and changes very > simple, especially once we hit a critical mass point. > > I'm very interested to hear about your experiences. While I can see the appeal of using CL for scripting, I'm interested in why people choose this approach rather than using one of the lispy dialects that have been specifically designed for this type of purpose. I'm thinking of things like guile, lush, rep etc. Tim -- tcross (at) rapttech dot com dot au
From: Richard Fateman on 5 Dec 2009 20:34 W. James wrote: > > I cannot see "appeal" of Commune-Lisp for anything. > Obviously you've scanned the internet for comments, and you are reading this newsgroup. I therefore conclude that CL must have some considerable appeal to you, contrary to your claim. Why don't you troll over to some other newsgroup?
From: Tamas K Papp on 6 Dec 2009 01:35 On Sun, 06 Dec 2009 11:44:43 +1100, Tim X wrote: > mpeever <mpeever(a)gmail.com> writes: > >> I've been experimenting with CL scripting for about a year now. We've >> got a significant amount of SBCL code working in our Legato Networker >> environment. We've started small, but so far we're really happy with >> it. I'm currently considering the benefits of replacing some >> significant Perl processes in CL. There are some pending changes that >> are much more daunting in Perl than CL. >> >> We wrote a quick-and-dirty toolkit to clean up some of the OS >> interfacing: we've more or less tried to imitate Perl's operators. Our >> toolkit appears to work on SBCL, CCL, and ECL. Making it support >> multiple implementations was important, as we're still very much in >> pilot mode: we may yet have to make some drastic changes and we need to >> be able to move quickly. >> >> We've been taking advantage of the core-dump facilities in CL >> implementations for code roll-outs. It makes updates and changes very >> simple, especially once we hit a critical mass point. >> >> I'm very interested to hear about your experiences. > > While I can see the appeal of using CL for scripting, I'm interested in > why people choose this approach rather than using one of the lispy > dialects that have been specifically designed for this type of purpose. > I'm thinking of things like guile, lush, rep etc. For me, it takes a lot of time to learn all the nooks and crannies of a language, and doing this for the occasional script doesn't justify the investment. Maybe all those dialects are "lispy", but they have different names for standard functions, slightly different semantic conventions, etc, all of which would lead to minor annoyances. So I chose to roll the thing in CL, and I was pleased, it took very little time. I will continue to do these things in the future. Tamas BTW, lush sucks bigtime, eg it doesn't have lexical scoping. I tried the it a while ago and it was a major disappointment.
From: Juanjo on 6 Dec 2009 07:32 On Dec 4, 11:34 am, Tamas K Papp <tkp...(a)gmail.com> wrote: > Hi, > > I had to write a simple script, and decided to do it in CL. It is the > language I know best, and I wanted to learn how to generate standalone > executables in ECL (it was dead simple -- the whole thing is 38K). > > I would appreciate if people could comment on the code. It is nothing > complicated and runs fine, I just want to learn the idiomatic way to > use CL for scripting. If you want to preserve all characters in the input, opening in binary mode might be better. Besides this, for purpose of efficiency, read- sequence with a fixed buffer is much better than read-line. And mkstemp is essential if your process may run concurrently with others. (defun open-unique (&optional (base-path "/tmp/")) ;; Using mkstemp ensures that file is not overwritten by a concurrent ;; process. SBCL has a similar POSIX extension. (let ((path (ext:mkstemp base-path))) (open path :direction :output :if-exists :overwrite))) (defun copy-stream (input output &optional (buffer-length 1024)) (loop with buffer = (make-string buffer-length) for read = (read-sequence buffer input) while (plusp read) do (write-sequence buffer output :start 0 :end read)))
From: W. James on 6 Dec 2009 08:44
Tamas K Papp wrote: > > While I can see the appeal of using CL for scripting, I'm interested in > > why people choose this approach rather than using one of the lispy > > dialects that have been specifically designed for this type of purpose. > > I'm thinking of things like guile, lush, rep etc. > > For me, it takes a lot of time to learn all the nooks and crannies of > a language, and doing this for the occasional script doesn't justify > the investment. Maybe all those dialects are "lispy", Maybe? They are more "lispy" than the monstrosity known as Commune-Lisp, COBOL-Lisp, Commode-Lisp, etc. This isn't comp.lang.commune-lisp, it's comp.lang.lisp. Get it? > but they have > different names for standard functions, Of what "standard" are you speaking? This isn't comp.lang.commune-lisp, it's comp.lang.lisp. Get it? > slightly different semantic > conventions, etc, all of which would lead to minor annoyances. So I > chose to roll the thing in CL, and I was pleased, it took very little > time. To a Commode-Lisper, it seemed to take little time to produce that huge, reeking, steaming pile of spaghetti-code (complete with "goto"). This proves that development in this "language" is always glacially slow. > I will continue to do these things in the future. One who has spent part of his life learning the ugly, convoluted, massive COBOL-Lisp finds it too painful to face the realization that all of that time was wasted. He must continue to serve the beast. Guy L. Steele, Jr., July 1989: I think we may usefully compare the approximate number of pages in the defining standard or draft standard for several programming languages: Common Lisp 1000 or more COBOL 810 ATLAS 790 Fortran 77 430 PL/I 420 BASIC 360 ADA 340 Fortran 8x 300 C 220 Pascal 120 DIBOL 90 Scheme 50 -- |