<div dir="ltr">A quarter century ago I devised similar machinery for Allegro.  It's still in the implementation, and I use it daily for personal scripting tasks:<div><br></div><div><a href="http://franz.com/support/documentation/current/doc/startup.htm#starting-unix-script-3">http://franz.com/support/documentation/current/doc/startup.htm#starting-unix-script-3</a><br>
</div><div><br></div><div>Your work is a very useful thing to have, but let me suggest there are additonal issues to consider.</div><div><br></div><div>The Allegro machinery allows a compiled file to be included as the application.  This eliminates the time necessary to cl:read the source and compile the definition on systems that automatically compile.  For many scripting applications none of this matters.  For most purposes interpreted executions, and/or the compiler, now require such inconsequential time that one shouldn't care how the deed gets done.  But there are situations where it might:</div>
<div><br></div><div>  If the script does nontrivial computation, the difference between interpreted and compiled execution might matter.  (For implementations that always compile, the compilation cost is fixed, but happens upon each execution.)</div>
<div><br></div><div>  If the script is executed with high frequency, perhaps as the implementation of a web page, the cost of launching a heavyweight Lisp image in almost _any_ implementation is likely to be objectionable.  A lightweight C a.out has a small footprint in addition to the various .so libraries it uses, which will tend to stay loaded, and requires minimal startup execution overhead.  Most Common Lisp applications have a larger startup cost because Lip environments are, shall we say, bigger and more capable.</div>
<div><br></div><div>It would be nice to think further how startup overhead could be reduced with precompiled execution</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 2, 2014 at 2:56 PM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My cl-launch demo:<br>
<br>
cl -sp lisp-stripper -i '(print-loc-count "asdf.lisp")'<br>
<br>
Source code for lispwc:<br>
#!/usr/bin/cl -sp lisp-stripper -E main<br>
(defun main (argv)<br>
  (if argv<br>
      (map () 'print-loc-count argv)<br>
      (print-loc-count *standard-input*)))<br>
<br>
And of course:<br>
for l in sbcl ccl clisp cmucl ecl abcl \<br>
         scl allegro lispworks gcl xcl ; do<br>
 cl-launch -l $l -i \<br>
 '(format t "'$l': ~S~%" `#5(1 ,@`(2 3)))' \<br>
 2>&1 | grep "^$l:" # LW, GCL are verbose<br>
done<br>
<br>
Backstory:<br>
<br>
After recent exposure to Python at work, I grew an intense dislike for<br>
that language, and realized that I could do everything in CL instead,<br>
and that the remaining stumbling blocks to using CL as a "scripting<br>
language" were quite small — just missing the ability to put<br>
#!/usr/bin/cl in a script, and there you go.<br>
<br>
And so, I added just this capability to cl-launch, improved it to have<br>
some of the features of buildapp, and made sure it works without a<br>
hitch on each of the 11 implementations with a command-line interface.<br>
This in turn requires updating ASDF and UIOP, and so here we are with<br>
ASDF 3.1.0.86.<br>
<br>
Then, I found that I had to take the word out, and started editing<br>
that way a paper that I'm preparing a paper for ELS 2014 (or else ILC<br>
2014):<br>
      ASDF3, or Why Lisp is Now an Acceptable Scripting Language<br>
<br>
It's incredible how having to explain the code forces you to make it<br>
actually simpler to use. Hence new option -sp in cl-launch, to load<br>
a system and change the current package, all in one go. Hence also<br>
having cl-launch build software with a sequence of --system --load --eval<br>
instead of a single setup file and toplevel system like before:<br>
people already understand a sequence of build commands.<br>
<br>
Also new in ASDF3: command line argument support was improved with a<br>
LispWorks workaround and a new argv0 function; with-input and<br>
with-output accept pathnames as designating a file to open; the bundle<br>
support was much improved and cleaned up; the upgrade mechanism was<br>
slightly improved to cope with the class refactoring; bugs were found<br>
and removed in pathname functions; a weird bug in SCL was worked<br>
around.<br>
<br>
Enjoy!<br>
<br>
TODO: I'm considering modifying the default behavior of cl-launch to<br>
launch a REPL and/or read commands from stdin, like a Unix shell does<br>
when given no script and no commands to run. I'm reserving that for<br>
another round of procrastination.<br>
<br>
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org" target="_blank">http://fare.tunes.org</a><br>
To have a right to do a thing is not at all the same<br>
as to be right in doing it.     — G.K. Chesterton<br>
<br>
</blockquote></div><br></div>