Hi all,
I am a complete Lisp newbie, coming from a mixed programming background
(chronologically Haskell, Java and Python over the past 7 years), and
have started to learn Common Lisp.
I have been working through the Lisp Primer
(http://mypage.iu.edu/~colallen/lp/) and Learning Lisp Fast
(http://cs.gmu.edu/~sean/lisp/LispTutorial.html) to get a quick start
on the language while I am waiting for copies of "Practical Common
Lisp" (Seibel) and "The ANSI Common Lisp Book" (Paul Graham)
In the meantime, I have a question on how people develop lisp programs:
In python I am used to coding by writing modules, and executing the
modules. This amounts to writing (one or more) python files and typing
"python test.py" at the command prompt. This compiles any called
modules that haven't already been compiled, and the runs the script
"test.py"
In CLisp so far, I have been playing in the top level, and am now
starting to experiment with functions. I have been trying to achieve a
similar edit-save-run development cycle in CLisp, but so far have only
been able to get a edit-save-compile-run cycle:
clisp -K full -c test.cl
clisp -K full test.fas
What am I missing? Are there command line options to do this all in one
step?
Thanks,
On Jan 1, 6:55 pm, "Ant" <······@gmail.com> wrote:
> Hi all,
>
> I am a complete Lisp newbie, coming from a mixed programming background
> In the meantime, I have a question on how people develop lisp programs:
>
> In python I am used to coding by writing modules, and executing the
> modules. This amounts to writing (one or more) python files and typing
> "python test.py" at the command prompt. This compiles any called
If I understand what you're asking correctly then Lisp is very much
geared up for this way of working. The only thing you may have to get
your head around a bit is the image based approach to programming. When
you start up your copy of clisp it is loading up an image containing
the interesting bits of Lisp and you add to this when you write your
functions and macros. You can then save out the image for later use if
you want.
If you start up clisp without the arguments then you will be at the
REPL (a bit like the Python shell) and you can work with Lisp
interactively.
You can of course keep you code in files as with Python but you're
probably going to want to use a Lisp aware editor to do this and most
people will recommend Slime which is built on Emacs.
You can get a good leg up while you wait for your copy of PCL to arrive
by going to the PCL site (http://www.gigamonkeys.com/book/). From here
you can read the book on-line to get a head start and also download a
(possibly slightly old) distribution of a Lisp system, emacs and Slime
all pre-packaged for your OS. It's called 'Lispbox'. The early parts of
PCL go through all of this step by step.
I hope this is useful.
Phil
Ant wrote:
> similar edit-save-run development cycle in CLisp, but so far have only
> been able to get a edit-save-compile-run cycle:
>
> clisp -K full -c test.cl
> clisp -K full test.fas
>
> What am I missing? Are there command line options to do this all in one
> step?
"clisp test.cl" to run JIT, or a shebang line in the source file.
--
Dan
www.prairienet.org/~dsb
Ant wrote:
> Hi all,
>
> I am a complete Lisp newbie, coming from a mixed programming background
> (chronologically Haskell, Java and Python over the past 7 years), and
> have started to learn Common Lisp.
>
> I have been working through the Lisp Primer
> (http://mypage.iu.edu/~colallen/lp/) and Learning Lisp Fast
> (http://cs.gmu.edu/~sean/lisp/LispTutorial.html) to get a quick start
> on the language while I am waiting for copies of "Practical Common
> Lisp" (Seibel) and "The ANSI Common Lisp Book" (Paul Graham)
>
> In the meantime, I have a question on how people develop lisp programs:
>
> In python I am used to coding by writing modules, and executing the
> modules. This amounts to writing (one or more) python files and typing
> "python test.py" at the command prompt. This compiles any called
> modules that haven't already been compiled, and the runs the script
> "test.py"
>
> In CLisp so far, I have been playing in the top level, and am now
> starting to experiment with functions. I have been trying to achieve a
> similar edit-save-run development cycle in CLisp, but so far have only
> been able to get a edit-save-compile-run cycle:
>
> clisp -K full -c test.cl
> clisp -K full test.fas
>
> What am I missing?
http://www.franz.com/downloads/
http://www.lispworks.com/downloads/index.html
The yobs will be along shortly to tell you about Emacs and Slime.
I /did/ manage years back to DL and install VisualCLisp, but a quick
Google just turns up dead links. And the "about" box thanks Dubbya for
killing tens of thousands of people for no reason, a bit of a negative
for my money.
hth, kt
--
The Dalai Lama gets the same crap all the time.
-- Kenny Tilton on c.l.l when accused of immodesty
On Jan 1, 9:02 pm, Ken Tilton <·········@gmail.com> wrote:
> Ant wrote:
> > Hi all,
>
> > I am a complete Lisp newbie, coming from a mixed programming background
> The yobs will be along shortly to tell you about Emacs and Slime.
Guilty.
I hope someone posts this sort of question in a few months time when my
editor hits 0.1. It'll be nice to get one download served before
everyone tears me to pieces and I have to change my name or go off and
learn Ruby or something...
Phil
"Ant" <······@gmail.com> writes:
> In the meantime, I have a question on how people develop lisp programs:
>
> In python I am used to coding by writing modules, and executing the
> modules. This amounts to writing (one or more) python files and typing
> "python test.py" at the command prompt. This compiles any called
> modules that haven't already been compiled, and the runs the script
> "test.py"
In Lisp, I usually start by opening a file, adding and evaluating a
defpackage form and an in-package form, and then writing functions. I
compile and run individual functions, not the contents of the entire
file, during development.
> In CLisp so far, I have been playing in the top level, and am now
> starting to experiment with functions. I have been trying to achieve a
> similar edit-save-run development cycle in CLisp, but so far have only
> been able to get a edit-save-compile-run cycle:
I find it's more of an edit-compile-run cycle in Lisp, again mostly at
the function level. My editor is connected to my Lisp, and there's a
keystroke to send the function definition to Lisp for
compilation. Then I switch to the repl and test out the new function
to make sure it returns the expected values for some input, or how it
works together with existing functions.
I don't always save the file after making edits, either, since the
code is sent directly from the editor's in-memory buffer to the Lisp
process.
You can get this level of editor integration with all commercial CL
environments and, with emacs and slime, virtually all free CL
environments too.
Some people don't bother with tight editor integration. I used to
think people like that were crazy, but Rob Warnock seems to get a lot
of interesting work done that way. :)
> clisp -K full -c test.cl
> clisp -K full test.fas
>
> What am I missing? Are there command line options to do this all in one
> step?
You can just do this:
clisp -K full test.cl
That's not how I usually work, though, and I don't think many people
develop and test Common Lisp programs this way.
Zach
Zach Beane wrote:
...
> You can just do this:
>
> clisp -K full test.cl
I knew it would be something simple... For now this will do me - I
usually edit in vi (I'm sure this will go down well with the emacs
crowd here ;-) ), and running the source files like this gives me an
environment I am used to.
When I get into it a bit more and start to develop something
substantial, rather than simple test scripts for learning concepts,
I'll look back at this thread and the other ideas.
Thanks.
Zach Beane <····@xach.com> wrote [re-ordering slightly]:
+---------------
| Some people don't bother with tight editor integration. I used to
| think people like that were crazy, but Rob Warnock seems to get a
| lot of interesting work done that way. :)
+---------------
Since I use "vi", I don't get the hyper-tight editor integration
of Emacs+SLIME, but I do tend to develop with both an editor ("vi")
window and a REPL (usually to "CMUCL") window open[1], using either
X Windows mouse-based copy & paste to update changes to single functions
from the editor to the REPL, or for bigger changes writing the file out
and then executing a customized (REDO) function in the REPL [REDO often
just does an (ASDF:OPERATE 'ASDF:LOAD-OP system)]. Personally, I find
that *much* more time is spent on thinking & editing & testing than on
any "editor integration" issues. But YMMV.
+---------------
| In Lisp, I usually start by opening a file, adding and evaluating a
| defpackage form and an in-package form, and then writing functions. I
| compile and run individual functions, not the contents of the entire
| file, during development.
+---------------
Ditto, except the evaluation of small bits gets done by copy&pasting
forms from the editor to the REPL, as noted above.
+---------------
| I find it's more of an edit-compile-run cycle in Lisp, again mostly
| at the function level.
+---------------
Ditto.
+---------------
| My editor is connected to my Lisp, and there's a keystroke to send
| the function definition to Lisp for compilation.
+---------------
With X Windows, that's a two stroke mouse gesture [copy, paste]
rather than a chorded keystroke, but the workflow is the same.
+---------------
| Then I switch to the repl and test out the new function
| to make sure it returns the expected values for some input,
| or how it works together with existing functions.
+---------------
Ditto.
+---------------
| I don't always save the file after making edits, either...
+---------------
Ditto. [Though as noted above, for large changes I *do* save
the file out and then (REDO)...]
+---------------
| ...since the code is sent directly from the editor's in-memory
| buffer to the Lisp process.
+---------------
Different here, of course.
+---------------
| You can get this level of editor integration with all commercial
| CL environments and, with emacs and slime, virtually all free CL
| environments too.
+---------------
And that's great -- I have no criticisms of that at all, if one
can use it. [I find that I can't, for a combination of ergo issues
and long habits doing it otherwise.] I just want people to know
that *not* having a "Lisp IDE" is no excuse for not being productive
with Lisp anyway.
-Rob
[1] If developing a web app, add to this a web browser window, and
the REPL window is really the REPL in the Lisp-based persistent
application server. And sometimes one more small window with a
"tail -f" running on the Apache error log file.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> Zach Beane <····@xach.com> wrote [re-ordering slightly]:
> [...]
> +---------------
> | I don't always save the file after making edits, either...
> +---------------
>
> Ditto. [Though as noted above, for large changes I *do* save
> the file out and then (REDO)...]
>
> +---------------
> | ...since the code is sent directly from the editor's in-memory
> | buffer to the Lisp process.
> +---------------
>
> Different here, of course.
>
> +---------------
> | You can get this level of editor integration with all commercial
> | CL environments and, with emacs and slime, virtually all free CL
> | environments too.
> +---------------
>
> And that's great -- I have no criticisms of that at all, if one
> can use it. [I find that I can't, for a combination of ergo issues
> and long habits doing it otherwise.] I just want people to know
> that *not* having a "Lisp IDE" is no excuse for not being productive
> with Lisp anyway.
More over, it's quite feasable, with very little custom job, to work
exclusively from the REPL, while gathering edited code into a source
file.
http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/
You can use your favorite editor thru CL:ED to edit the functions, and
let your CL code collect them in a source file.
With a more complete ibcl.lisp, I'd be near to advise newbies to use
this mode, since it'd let them have a closer contact with the lisp
REPL, with less concern for the editor or IDE.
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
Pascal Bourguignon <···@informatimago.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > I just want people to know that *not* having a "Lisp IDE" is
| > no excuse for not being productive with Lisp anyway.
|
| More over, it's quite feasable, with very little custom job, to work
| exclusively from the REPL, while gathering edited code into a source
| file.
| http://www.informatimago.com/develop/lisp/small-cl-pgms/ibcl/
| You can use your favorite editor thru CL:ED to edit the functions, and
| let your CL code collect them in a source file.
+---------------
Interesting, thanks. I'll take a look at it.
Since I do tend to keep one or more editor windows open on source
files which are in flux, I have a little function "LOAD*" that
maintains a list of files I'm currently working on, sort of like
an interactive, ultra-simple ASDF [or "make", for any newbies
following this], except with no inter-file dependencies:
(LOAD* files...) Adds the filenames to an internal saved list,
then does a recursive (LOAD*).
(LOAD*) Examines the saved list of files, and recompiles
and/or reloads them if the source has changed since
the last LOAD* [using the CMUCL ":IF-SOURCE-NEWER
:COMPILE" extension to CL:LOAD].
(LOAD* :SHOW) Shows the saved list of files.
(LOAD* :CLEAR) Clears the saved list of files.
As long as changes are small, it's quicker to copy/paste functions
from the editor window(s) to the REPL. For larger changes, it's easier
to write out changed editor buffers and then (LOAD*) in the REPL.
The REDO function I mentioned before is often defined in the REPL
as just "(defun redo () (progn (load*) (current-regression-test)))".
-Rob
p.s. Once upon a time I tried automating this even further, by
starting up a background CMUCL thread that polled to see if any
of the files in the LOAD* list had changed, and if so, automatically
run a (LOAD*) -- that is, any write from an editor would trigger a
recompile/reload. But I quickly found that that was just a little bit
*too* eager, since if I made interdependent changes in multiple files
then the first write would trigger a recompile before a consistent
state had been reached on disk. So I stopped doing that. ;-}
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Ant" <······@gmail.com> writes:
> What am I missing? Are there command line options to do this all in one
> step?
The real thing you'll likely end up doing, just like I did and just
like so many others did, is changing from developing per-file to
developing per-function. It's kind of the Lisp Way and it works very
well. You write a function, compile it, and test it at the REPL.
Then you write another, and do the same with it. Eventually you will
have a bunch of functions working together, individually tested, and
you can put them together into a program with a user interface.
Consider how you write your Python code now. If you are like me, you
do something like this:
$ vi file.py
#!/usr/bin/env python
import <some set of modules>
class <a class>:
<a class definition>
function <a function>:
<blah>
<some code that serves only to test the functions and classes above>
$ python file.py
<test output>
$ vi file.py
<change test code and try again>
Etc.
This is mandatory in C, and therefore common practice in most other
languages that were all created by C programmers. You *can* work with
the REPL in python, but it doesn't gain you much because you don't
have your work saved in a file and it's also hard to edit what you've
already written.
With Lisp, Emacs + SLIME is the preferred way to do things because it
gives you every benefit of having the REPL for interactive development
but keeps your work in Emacs buffers which you can easily save to
files. (In fact, I tend to save the buffer then run compile-file
rather than compiling individual defuns as many people prefer.)
You can probably get close to the same benefits, although not all of
them, by using multiple terminal windows or the screen multiplexer.
Keep a clisp REPL open in one and a vi session open in another, then
save the file and switch to the REPL to run (load "myfile.lisp") (or,
if you prefer to do so during development, compile the file and load
the resulting .fas).
> * Ant <······@tznvy.pbz> [2007-01-01 10:55:47 -0800]:
>
> In CLisp so far, I have been playing in the top level, and am now
> starting to experiment with functions. I have been trying to achieve a
> similar edit-save-run development cycle in CLisp, but so far have only
> been able to get a edit-save-compile-run cycle:
>
> clisp -K full -c test.cl
> clisp -K full test.fas
>
> What am I missing? Are there command line options to do this all in
> one step?
http://clisp.cons.org/impnotes/clisp.html#opt-load-comp
--
Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod)
http://openvotingconsortium.org http://mideasttruth.com http://camera.org
http://memri.org http://dhimmi.com http://ffii.org http://jihadwatch.org
The only thing worse than X Windows: (X Windows) - X
Ant wrote:
> What am I missing? Are there command line options to do this all in one
Besides all the good answers you got, I recommend you check Marco
Beringer's video about developing lisp with emacs and :
http://common-lisp.net/movies/slime.mov
It's worth even if you decide not to use emacs. I'll have an idea of
what look for in a lisp environment.
Pedro Kroger
In article <·······················@v33g2000cwv.googlegroups.com>,
"Ant" <······@gmail.com> wrote:
> Hi all,
>
> I am a complete Lisp newbie, coming from a mixed programming background
> (chronologically Haskell, Java and Python over the past 7 years), and
> have started to learn Common Lisp.
>
> I have been working through the Lisp Primer
> (http://mypage.iu.edu/~colallen/lp/) and Learning Lisp Fast
> (http://cs.gmu.edu/~sean/lisp/LispTutorial.html) to get a quick start
> on the language while I am waiting for copies of "Practical Common
> Lisp" (Seibel) and "The ANSI Common Lisp Book" (Paul Graham)
>
> In the meantime, I have a question on how people develop lisp programs:
>
> In python I am used to coding by writing modules, and executing the
> modules. This amounts to writing (one or more) python files and typing
> "python test.py" at the command prompt. This compiles any called
> modules that haven't already been compiled, and the runs the script
> "test.py"
'Modules' are usually organized by some DEFSYSTEM. Some
old-school guys are using Unix make. With any DEFSYSTEM
you would have commands like LOAD-SYSTEM, COMPILE-SYSTEM,
EDIT-SYSTEM, ...
Typically you would develop with the REPL (read eval print loop)
of your Lisp system. You would also develop your software
in an interactive fashion. You can do batch-programming like
development for Lisp, but that is not your only option.
There is some class of programs where interactive
development might not work, but usually it is preferrable.
Thus you get development-cycle times that are proportional
to the code change. With batch programming you get
development-cycle times that are proportional to the
whole software size.
A typical development session would be:
- drink some tea and think about the task...
- start your Lisp (unless it is already running)
- load your systems (unless they are already preloaded with
your Lisp image)
- edit some source and execute it from the editor or the listener.
don't restart your Lisp unless it is necessary.
- get your code working
- refactor your code so that it 'looks' nice
- make sure that loading your code into a fresh Lisp does work
- optional: write out a new Lisp image with your changes
- done for today...
>
> In CLisp so far, I have been playing in the top level, and am now
> starting to experiment with functions. I have been trying to achieve a
> similar edit-save-run development cycle in CLisp, but so far have only
> been able to get a edit-save-compile-run cycle:
>
> clisp -K full -c test.cl
> clisp -K full test.fas
>
> What am I missing? Are there command line options to do this all in one
> step?
>
> Thanks,
"Ant" <······@gmail.com> writes:
> In CLisp so far, I have been playing in the top level, and am now
> starting to experiment with functions. I have been trying to achieve a
> similar edit-save-run development cycle in CLisp, but so far have only
> been able to get a edit-save-compile-run cycle:
>
> clisp -K full -c test.cl
> clisp -K full test.fas
>
> What am I missing? Are there command line options to do this all in one
> step?
If you want to do this with edittign separate from running the code (not
really recommended for the long haul, but maybe simpler to start), you
should just start up clisp and then type the following at the command
line:
(load (compile-file "test.cl"))
and then invoke the function(s) that you want to test.
However, normally one would want to use a development environment, such as
Emacs+Slime+Clisp to allow you to do your work directly from the editor
buffer and skip the "Save" step in your workflow.
You then get a edit-evaluate-run flow instead. (You could also use a
edit-compile-run workflow).
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> "Ant" <······@gmail.com> writes:
>
>> In CLisp so far, I have been playing in the top level, and am now
>> starting to experiment with functions. I have been trying to achieve a
>> similar edit-save-run development cycle in CLisp, but so far have only
>> been able to get a edit-save-compile-run cycle:
>>
>> clisp -K full -c test.cl
>> clisp -K full test.fas
>>
>> What am I missing? Are there command line options to do this all in one
>> step?
>
> If you want to do this with edittign separate from running the code (not
> really recommended for the long haul, but maybe simpler to start), you
> should just start up clisp and then type the following at the command
> line:
>
> (load (compile-file "test.cl"))
>
> and then invoke the function(s) that you want to test.
Well, when one is a beginner, and using clisp, it's better not to
compile the code, since the clisp debugger works better with the
interpreter than with compiled functions.
COMPILE or COMPILE-FILE must be considered a late optimization step,
and only called just before delivery...
> However, normally one would want to use a development environment, such as
> Emacs+Slime+Clisp to allow you to do your work directly from the editor
> buffer and skip the "Save" step in your workflow.
>
> You then get a edit-evaluate-run flow instead. (You could also use a
> edit-compile-run workflow).
Indeed.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
"Ant" <······@gmail.com> writes:
> clisp -K full -c test.cl
> clisp -K full test.fas
Oh, it may also be worthwhile to supply the -ansi flag as well, so that
you are working with the ANSI Common Lisp version of CLISP. That will
make portability easier to achieve and also let you avoid some surprises
when using various tutorials or other Common Lisp books or resources.
--
Thomas A. Russ, USC/Information Sciences Institute