Hi all, after recently reading Paul Graham's Lisp articles, I figured
that I ought to learn this great language :)
So I'm making my way through ANSI Common Lisp & I think I am at the
stage where I have a reading knowledge of basic stuff & I'm wanting to
do some more advanced things. I'd like some advice please.
1) I normally develop with VIM, gcc and gdb/Insight as a debugger.
>From what I can tell most Lispers don't really use VIM, they use Emacs.
I don't really want to learn another editor though :) What
development environments (editing/debugging) do Lispers use & are there
some links somewhere that will get me started using them?
I read a lot about interactive Lisp debugging, is there a good article
that will teach me about working in a Lisp environment?
2) In my free time I usually tinker with toy games, physics, etc & I
usually use SDL & OpenGL. I've looked into various ways to interface
to C code, but haven't really found any comprehensive howtos. I can't
get any SDL packages working with clisp, but I have managed to get the
Debian cl-sdl package running with CMUCL. Though the way I got it
running didn't feel right - I had to do
(asdf:operate 'asdf:load-op 'sdl)
(load "sdl-test.lisp")
(sdl-test:start)
This feels a little long winded, and the start symbol is exported by
sdl-test, so how come I need to specify the package?
Is there an easier way?
3) LUSH Lisp (http://lush.sourceforge.net/) looks quite neat, easy
interfacing to SDL & OpenGL & has basic examples. However it looks
like the interpreter is an older design and doesn't have lexical
scoping - should I just use this or will it colour my view of modern
Common Lisps?
Thanks
Brad
Hi,
I'm also a recent newbie, a little further down the learning curve.
Check out "Practical Common Lisp", the online version is free
(http://www.gigamonkeys.com/book/). I like my hard-cover copy, though,
for reference :-)
If you don't like Emacs, try downloading the free trial version of
Allegro or LispWorks. They have GUIs with debugging, code editing,
REPL, etc. You'll be glad you did. You'll be at a Lisp prompt quickly
and can start playing around. This is what I have recommended to some
friends at work, but for Emacs-affine folk I usually recommend Lisp in
a Box.
For SDL, check out CL-SDL (http://cl-sdl.sourceforge.net/) - I liked it
a lot, and it works with different Lisp implementations.
If you don't like loading your SDL library each time there are 2
options:
1) You can put lisp forms in a startup file to load the SDL library
each time.
2) You can save a lisp image (basically a memory dump) to a file, and
specify that as the startup image when you run your lisp. This will
start up faster.
I took a quick look at the Lush page - it says "Lisp-like", so I guess
it isn't Common Lisp. If you want to learn Common Lisp, stick to an
implementation that aims at conforming to the standard.
-Harold
Harold wrote:
...
> 2) You can save a lisp image (basically a memory dump) to a file, and
> specify that as the startup image when you run your lisp. This will
> start up faster.
The last time I used cl-sdl and cmucl, which was probably 18e, dumping
images with foreign libraries loaded didn't work as well as you'd want.
So if you load cl-sdl, dump and image, and then load the image, cl-sdl
is there, but libsdl.so isn't. I don't know if this is still the case,
but I'd bet that it is. I'd test it, but my linux machine is in the
small nation of Jeffersonia, and I can't get to it.
On Tue, 13 Sep 2005 12:01:36 -0500, Andy Cristina <········@gmail.com> wrote:
> The last time I used cl-sdl and cmucl, which was probably 18e,
> dumping images with foreign libraries loaded didn't work as well as
> you'd want. So if you load cl-sdl, dump and image, and then load the
> image, cl-sdl is there, but libsdl.so isn't.
<······································@cons.org/msg01289.html>
This is a CMUCL-specific problem - LispWorks, e.g., copes well with
saved images that use foreign libraries.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
The 2 main advantages of Emacs over VIM for Lisp are
- Emacs can run a shell prompt (or, better, a Lisp REPL) in a different
"buffer".
- Emacs can be extended to add commands like "Send the highlighted
section of code to the Lisp REPL".
Together, those features make Emacs+SLIME+Lisp very interactive. With
VIM I find myself running two terminal sessions: one with VIM and
another with the Lisp REPL - and I have to keep issuing (load
"file.lisp") over and over. But if you do that, I recommend clisp
because it has better support for command-line work (e.g. Ctrl-R to
search backwards for an earlier expression).
"Harold" <·······@gmail.com> writes:
> The 2 main advantages of Emacs over VIM for Lisp are
>
> - Emacs can run a shell prompt (or, better, a Lisp REPL) in a different
> "buffer".
>
> - Emacs can be extended to add commands like "Send the highlighted
> section of code to the Lisp REPL".
>
> Together, those features make Emacs+SLIME+Lisp very interactive. With
> VIM I find myself running two terminal sessions: one with VIM and
> another with the Lisp REPL - and I have to keep issuing (load
> "file.lisp") over and over. But if you do that, I recommend clisp
> because it has better support for command-line work (e.g. Ctrl-R to
> search backwards for an earlier expression).
>
I'd recommend checking out www.vim.org -
it seems you can now setup VIM to run a repl in a window and send bits
of lisp to it from another window - not the power of slime, but may be
sufficient for learning purposes. Looks like you can get many of the
syntax highlighting and formatting advantages seen in emacs in VIM as
well.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
··············@gmail.com wrote:
> Hi all, after recently reading Paul Graham's Lisp articles, I figured
> that I ought to learn this great language :)
> So I'm making my way through ANSI Common Lisp & I think I am at the
> stage where I have a reading knowledge of basic stuff & I'm wanting to
> do some more advanced things. I'd like some advice please.
>
> 1) I normally develop with VIM, gcc and gdb/Insight as a debugger.
>>From what I can tell most Lispers don't really use VIM, they use Emacs.
> I don't really want to learn another editor though :) What
> development environments (editing/debugging) do Lispers use & are there
> some links somewhere that will get me started using them?
There is Emacs of course and most integrated (commercial) CL system
provide you with an .... Emacs-like environment. If you do not want a
commercial system, there is SLIME (which is an .... Emacs add-on). Hence
forget VIM and learn the real thing :)
> I read a lot about interactive Lisp debugging, is there a good article
> that will teach me about working in a Lisp environment?
>
> 2) In my free time I usually tinker with toy games, physics, etc & I
> usually use SDL & OpenGL. I've looked into various ways to interface
> to C code, but haven't really found any comprehensive howtos. I can't
> get any SDL packages working with clisp, but I have managed to get the
> Debian cl-sdl package running with CMUCL. Though the way I got it
> running didn't feel right - I had to do
> (asdf:operate 'asdf:load-op 'sdl)
> (load "sdl-test.lisp")
> (sdl-test:start)
> This feels a little long winded, and the start symbol is exported by
> sdl-test, so how come I need to specify the package?
> Is there an easier way?
What do you have in mind?
> 3) LUSH Lisp (http://lush.sourceforge.net/) looks quite neat, easy
> interfacing to SDL & OpenGL & has basic examples. However it looks
> like the interpreter is an older design and doesn't have lexical
> scoping - should I just use this or will it colour my view of modern
> Common Lisps?
Lush is not the real thing. There are plenty ot OpenGL interfaces to
Common Lisp as well as a few for SDL. Hence stick with the real thing. :)
Cheers
--
Marco
··············@gmail.com writes:
> 1) I normally develop with VIM, gcc and gdb/Insight as a debugger.
> >From what I can tell most Lispers don't really use VIM, they use Emacs.
> I don't really want to learn another editor though :) What
I was a longtime vi user who one day had some time and downloaded
emacs. There is a learning curve but once past it I never missed vi
at all. I do value and use vi for its conciseness and power when I
need quick editing. But for programming I won't tough anything but
emacs. I recommend you give emacs a week or two..
··············@gmail.com writes:
>
> 1) I normally develop with VIM, gcc and gdb/Insight as a debugger.
>>From what I can tell most Lispers don't really use VIM, they use Emacs.
> I don't really want to learn another editor though :) What
> development environments (editing/debugging) do Lispers use & are there
> some links somewhere that will get me started using them?
Well, since you mentioned Paul Graham, ISTR that one of his essays talks
about observing what lots of other intelligent hackers are or aren't
doing. In this case, a whole lot of intelligent folks are using
emacs...
More seriously, I do not know if any current text editor as completely
supports Lisp as emacs (or the various vendor-specific emacs-like
editors). SLIME, for example, is an excellent environment which runs
within emacs.
Plus, once one has gotten familiar emacs, one can read news, send mail,
browse the web, chat on IM, play nethack and work in the shell--without
ever leaving emacs.
Not that it's the best possible editor or anything like that--it's
not--but it is a very useful onw.
> I read a lot about interactive Lisp debugging, is there a good article
> that will teach me about working in a Lisp environment?
You may wish to take a look at Practical Common Lisp (online at
<http://www.gigamonkeys.com/>, but consider buying the paper version);
it's an excellent introduction to Lisp which covers things like the
condition system (imagine exception handling on steroids). As for
debugging, the language itself provides a little bit, but a lot more is
typically provided by the implementation.
> 2) In my free time I usually tinker with toy games, physics, etc & I
> usually use SDL & OpenGL. I've looked into various ways to interface
> to C code, but haven't really found any comprehensive howtos.
One of the many problems in the Lisp community seems to be that everyone
is already top-notch and therefor no-one sees a need for comprehensive
newbie how-tos. That said, cliki is a useful resource. I believe that
UFFI and CFFI are the current foreign function interfaces (CFFI is built
atop UFFI?). I've not had a need to do it yet, and so haven't gotten
around to investigating.
> I can't get any SDL packages working with clisp, but I have managed to
> get the Debian cl-sdl package running with CMUCL. Though the way I
> got it running didn't feel right - I had to do
>
> (asdf:operate 'asdf:load-op 'sdl)
> (load "sdl-test.lisp")
> (sdl-test:start)
>
> This feels a little long winded, and the start symbol is exported by
> sdl-test, so how come I need to specify the package? Is there an
> easier way?
Well, I don't know about CMUCL, but SBCL (one of its descendants) hooks
ASDF into REQUIRE, so you could do this:
(require :sdl)
Practical Common Lisp (which you'll often see referred to as PCL) goes
into quite a bit of detail about the package system. Off the top of my
head, I think the problem is that you're in the CL-USER package, which
doesn't use the SDL-TEST package. Package A may export a symbol FOO,
but it's not visible to package B without B using A. Or so I think--I'm
still quite a newbie.
In SLIME, you could just type ',!pSDL-TEST<RET>' to change packages;
alternatively, you could type '(in-package :sdl-test)' into any REPL.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The sysadmin has graciously deigned not to cast you headlong
into a pit of rabid wombats. Please bear this in mind when
composing your message or request. --Chris Suslowicz
On Tue, 13 Sep 2005 11:47:26 -0400, <··············@gmail.com> wrote:
> 1) I normally develop with VIM, gcc and gdb/Insight as a debugger.
>> From what I can tell most Lispers don't really use VIM, they use Emacs.
> I don't really want to learn another editor though :) What
> development environments (editing/debugging) do Lispers use & are there
> some links somewhere that will get me started using them?
> I read a lot about interactive Lisp debugging, is there a good article
> that will teach me about working in a Lisp environment?
Well, I'm too much of a newbie to answer the other 2, but for Emacs
+ Slime is defaintly the way to go. It's just go integrated. Plus paredit
ties in nicely. That keeps all your parens straight at all times. At a
very simplistic level, it adds a ) when you type a (, but it seems to do a
lot more than that to keep them all indented properly, etc. It's really
the only way to go IMO. It's just such a tight integration.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
This seems to work okay, given 2 minutes sanity checking with "Lisp in
a Box". I set the Viper mode to 1 (as much Vi as it can do) and the
only weird things were: a) that I had to hit 'i' to be in insert mode
to enter a command at the REPL (e.g. after using y and p to copy/paste
commands to the REPL), and b) that I had to use the mouse to issue
Slime commands from the menu bar.
On Tue, 13 Sep 2005 15:13:36 -0400, <··············@gmail.com> wrote:
> I've just found that Emacs can be made to work in a VI like mode with
> the use of Viper. Any comments on how well this works with Lisp &
> SLIME?
>
> Brad
>
Nope, as frankly I've never gotten along well with VI ;)
The nice think about emacs is that you can use it like a plain text
editor. It's not modal. Just type your text. You'll probably want a GUI
version, then you'll have menus for any command you'd need, and can learn
the keyboard shortcuts at whatever pace you desire.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Yeah :) But from being able to edit efficiently in VI, I really don't
want to go back to a dumb style notepad editor :)
Also the Emacs control key combination makes my fingers curl!
On Tue, 13 Sep 2005 16:05:50 -0400, <··············@gmail.com> wrote:
> Yeah :) But from being able to edit efficiently in VI, I really don't
> want to go back to a dumb style notepad editor :)
> Also the Emacs control key combination makes my fingers curl!
Well, assuming you're using XWindows, throw
Option "XkbOptions" "ctrl:nocaps"
in the keyboard section of your xconfig. That'll turn your capslock key
into an addictional ctrl key. Just perfect for hitting with your pinky.
That's the way it should be and makes emacs 100x more pleasant to use.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
··············@gmail.com writes:
>
> Yeah :) But from being able to edit efficiently in VI, I really don't
> want to go back to a dumb style notepad editor :)
Trust us--emacs may be modeless (this isn't _quite_ true, BTW, but is
close enough), but it's certainly neither dumb nor notepad-style. For
example, this message was sent with emacs--not just edited, _sent_.
> Also the Emacs control key combination makes my fingers curl!
Yeah, they predate the Mac's keys, which have been near-universally
picked up. OTOH, they are relatively easy to use, esp. if one remaps
Caps Lock to control--there are ways to do this for every OS.
--
Robert Uhl <http://public.xdi.org/=ruhl>
`What would you do if you won $1,000,000?'
`Well, I guess I'd spend the first $900,000 on women and beer, then just
waste the rest.'
··············@gmail.com wrote:
> Hi all, after recently reading Paul Graham's Lisp articles, I figured
> that I ought to learn this great language :)
> So I'm making my way through ANSI Common Lisp & I think I am at the
> stage where I have a reading knowledge of basic stuff & I'm wanting to
> do some more advanced things. I'd like some advice please.
>
> 1) I normally develop with VIM, gcc and gdb/Insight as a debugger.
>>From what I can tell most Lispers don't really use VIM, they use Emacs.
> I don't really want to learn another editor though :) What
> development environments (editing/debugging) do Lispers use & are there
> some links somewhere that will get me started using them?
> I read a lot about interactive Lisp debugging, is there a good article
> that will teach me about working in a Lisp environment?
>
> 2) In my free time I usually tinker with toy games, physics, etc & I
> usually use SDL & OpenGL. I've looked into various ways to interface
> to C code, but haven't really found any comprehensive howtos. I can't
> get any SDL packages working with clisp, but I have managed to get the
> Debian cl-sdl package running with CMUCL. Though the way I got it
> running didn't feel right - I had to do
> (asdf:operate 'asdf:load-op 'sdl)
> (load "sdl-test.lisp")
> (sdl-test:start)
> This feels a little long winded, and the start symbol is exported by
> sdl-test, so how come I need to specify the package?
> Is there an easier way?
>
> 3) LUSH Lisp (http://lush.sourceforge.net/) looks quite neat, easy
> interfacing to SDL & OpenGL & has basic examples. However it looks
> like the interpreter is an older design and doesn't have lexical
> scoping - should I just use this or will it colour my view of modern
> Common Lisps?
>
> Thanks
> Brad
>
Is this another "D" person moving on to Lisp? I wish you luck. It's
been great for me.
I also have to echo the others in this thread about editors. I was a VI
user, although maybe not quite as accomplished as you, and after
spending some time with emacs and SLIME, I am annoyed to have to go back
to the modal nature of VI. Give it some time and you'll most likely
enjoy the new environment.
Oh, and the language rocks, too.
BA
Yeah, actually it is :) I still like D a lot & would use it over C++
anyday, but Lispniks are just so darned enthusiastic that I had to
check it out. From all my reading (PCL, and up to Macros in ACL) I am
starting to understand why Lispers are enthusiastic. Also, P Graham is
extremely convincing!
I think my main issue is that working with a Lisp environment is so
different to the edit/compile/run/debug cycle of traditional programs
that I am having trouble delinating where I should be doing things.
Is there a page on Cliki that is along the lines of "The newbie guide
to Lisp, for an experienced C programmer"? That is what I need,
perhaps with winter coming on I'll make a contribution to Cliki and
write one.
Cheers
Bradb
Yeah, actually it is :) I still like D a lot & would use it over C++
anyday, but Lispniks are just so darned enthusiastic that I had to
check it out. From all my reading (PCL, and up to Macros in ACL) I am
starting to understand why Lispers are enthusiastic. Also, P Graham is
extremely convincing!
I think my main issue is that working with a Lisp environment is so
different to the edit/compile/run/debug cycle of traditional programs
that I am having trouble delinating where I should be doing things.
Is there a page on Cliki that is along the lines of "The newbie guide
to Lisp, for an experienced C programmer"? That is what I need,
perhaps with winter coming on I'll make a contribution to Cliki and
write one.
Cheers
Bradb
Yeah, actually it is :) I still like D a lot & would use it over C++
anyday, but Lispniks are just so darned enthusiastic that I had to
check it out. From all my reading (PCL, and up to Macros in ACL) I am
starting to understand why Lispers are enthusiastic. Also, P Graham is
extremely convincing!
I think my main issue is that working with a Lisp environment is so
different to the edit/compile/run/debug cycle of traditional programs
that I am having trouble delinating where I should be doing things.
Is there a page on Cliki that is along the lines of "The newbie guide
to Lisp, for an experienced C programmer"? That is what I need,
perhaps with winter coming on I'll make a contribution to Cliki and
write one.
Cheers
Bradb
On Tue, 13 Sep 2005 20:12:39 -0400, <··············@gmail.com> wrote:
> Yeah, actually it is :) I still like D a lot & would use it over C++
> anyday, but Lispniks are just so darned enthusiastic that I had to
> check it out. From all my reading (PCL, and up to Macros in ACL) I am
> starting to understand why Lispers are enthusiastic. Also, P Graham is
> extremely convincing!
> I think my main issue is that working with a Lisp environment is so
> different to the edit/compile/run/debug cycle of traditional programs
> that I am having trouble delinating where I should be doing things.
> Is there a page on Cliki that is along the lines of "The newbie guide
> to Lisp, for an experienced C programmer"? That is what I need,
> perhaps with winter coming on I'll make a contribution to Cliki and
> write one.
>
> Cheers
> Bradb
>
This is where emacs+slime really shines.
My typical setup is a horizontally split window with the code in the top
window an my REPL in the bottom. To load/compile code into the running
REPL, I can either use Ctrl c Ctrl c to compile and load the current top
level form (defun), leaving anything else from the file as is, or I can
use Ctrl c Ctrl k to compile and load the entire file. When the lisp image
encounters an error, it pops up a debugger. That's the nice thing about
slime, it wraps all the implementation-specific interactions under a
standard interface.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Tyler Eaves" <······@mailshack.com> writes:
>
> This is where emacs+slime really shines.
>
> My typical setup is a horizontally split window with the code in the top
> window an my REPL in the bottom.
I have that, with another (emacs) window alongside running w3m-emacs
with the HyperSpec inside. Wonderful for a newbie.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Q: Can some one tell how bad the digital divide was before the
information age?
A: It was basically Boole and Turing on one side, and all the other
slobs in the world one the other. Things have gotten better pretty
steadily since then.
On Wed, 14 Sep 2005 17:03:52 -0400, Robert Uhl <·········@NOSPAMgmail.com>
wrote:
> "Tyler Eaves" <······@mailshack.com> writes:
>>
>> This is where emacs+slime really shines.
>>
>> My typical setup is a horizontally split window with the code in the top
>> window an my REPL in the bottom.
>
> I have that, with another (emacs) window alongside running w3m-emacs
> with the HyperSpec inside. Wonderful for a newbie.
>
That's neat. Mind posting (or emailing) the relevant parts of your .emacs?
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Tyler Eaves" <······@mailshack.com> writes:
>
>>> This is where emacs+slime really shines.
>>>
>>> My typical setup is a horizontally split window with the code in the
>>> top window an my REPL in the bottom.
>>
>> I have that, with another (emacs) window alongside running w3m-emacs
>> with the HyperSpec inside. Wonderful for a newbie.
>
> That's neat. Mind posting (or emailing) the relevant parts of your
> .emacs?
Oh, no .emacs twiddling involved (well, very little--see below): I just
create an emacs frame with C-x 5 2, then fire up slime with M-x slime,
then C-x 3 to split the frame into two windows side-by-side, then C-x 2
to split the left window into two more windows top-and-bottom. I really
ought to write a quick little function to do exactly that. It might
look something like this:
(defun rau-slime-env ()
(interactive)
(make-frame-command)
(slime)
(split-window-horizontally)
(split-window-vertically))
The above needs some tweaking, but it should be a good start.
There is one slight bit of emacs hackery I use to ensure that
hyperspec-lookup always uses w3m (instead of my normal browser, which is
Firefox):
(defadvice hyperspec-lookup (around use-w3m-in-hyperspec activate)
"Always use w3m to lookup things in hyperspec"
(let ((browse-url-browser-function 'w3m-browse-url))
(message "foobar")
ad-do-it))
--
Robert Uhl <http://public.xdi.org/=ruhl>
Hell No! We won't relent to your artificial socioeconomic subsidisation
of political contributors and special interests!
"Tyler Eaves" <······@mailshack.com> writes:
>
> Hay, that's cool stuff. I never really learned any emacs frame
> commands beyond C-x 2 (until now).
Learning emacs is like studying theology: the more one learns, the more
one realises one has to learn. Although emacs _is_ a finite subject; I
hope that someday before I die I actually understand the whole thing.
It's not bloody likely, though.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I've seen things you people can't imagine. Chimneysweeps on fire over
the roofs of London. I've watched kite-strings glitter in the sun at
Hyde Park Gate. All these things will be lost in time, like
chalk-paintings in the rain. Time for your nap. --Peter da Silva
On 9234 day of my life Robert Uhl wrote:
> Although emacs _is_ a finite subject; I hope that someday before I
> die I actually understand the whole thing. It's not bloody likely,
> though.
While you learn more and more Emacs, Stallman will add more and more
functions to learn... It is infinite race...
--
Ivan Boldyrev
Outlook has performed an illegal operation and will be shut down.
If the problem persists, contact the program vendor.
··············@gmail.com writes:
[...]
> I read a lot about interactive Lisp debugging, is there a good article
> that will teach me about working in a Lisp environment?
OK, these are movies, not articles, but very good ones:
http://common-lisp.net/torrents/slime.torrent
http://lispm.dyndns.org/mov/dsl-in-lisp.mov
> 2) In my free time I usually tinker with toy games, physics, etc & I
> usually use SDL & OpenGL. I've looked into various ways to interface
> to C code, but haven't really found any comprehensive howtos. I can't
> get any SDL packages working with clisp, but I have managed to get the
> Debian cl-sdl package running with CMUCL. Though the way I got it
> running didn't feel right - I had to do
> (asdf:operate 'asdf:load-op 'sdl)
> (load "sdl-test.lisp")
> (sdl-test:start)
> This feels a little long winded, and the start symbol is exported by
> sdl-test, so how come I need to specify the package?
> Is there an easier way?
See
http://www.lispworks.com/documentation/HyperSpec/Body/m_in_pkg.htm
http://www.lispworks.com/documentation/HyperSpec/Body/f_use_pk.htm
or
http://www.lispworks.com/documentation/HyperSpec/Body/11_.htm
http://www.gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html
for the whole story.
Andras
··············@gmail.com wrote:
> I can't
> get any SDL packages working with clisp, but I have managed to get the
> Debian cl-sdl package running with CMUCL.
After trying a lot of different things, I ended up in the same
situation. But I'm a newbie too...
> 3) LUSH Lisp (http://lush.sourceforge.net/) looks quite neat, easy
> interfacing to SDL & OpenGL & has basic examples. However it looks
> like the interpreter is an older design and doesn't have lexical
> scoping - should I just use this or will it colour my view of modern
> Common Lisps?
I did try Lush just for the same reasons. Unfortunately the examples do
not go far enough (and readily use abstractions like full-blown
structured sprites (sdl-sprite), with a position and frames of
animation, rather than basic stuff like simple blitting), and the docs
for SDL stuff are scarce.
On the other hand, the docs for cl-sdl don't even seem to exist.
The main reason I discarded Lush is that so much modern Common Lisp
stuff seems to be missing from it; as you say, it's an older design. I
kept looking for things like setf... After almost completing a basic
Space Invaders, I said "enough!", and I don't think I'll turn back.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Lisp newbie tips
Date:
Message-ID: <REM-2005sep16-002@Yahoo.Com>
> From: ··············@gmail.com
> I read a lot about interactive Lisp debugging, is there a good
> article that will teach me about working in a Lisp environment?
This is not a direct answer, but more of a bit of advice: If by
debugging you mean first you write this very large program, with no
unit testing of any of it, and then it doesn't work and you try to
diagnose why it doesn't work and how to fix it, I suggest you try to
avoid that sort of debugging almost completely. Instead I recommend
you test each line of code as you write it, and unit-test each
function as you complete it, and keep those unit tests as comments
adjacent to the function definition. Build tools bottom-up, so that
when you're writing each new function you pretty much know all the
other functions you're calling from inside it are already working fine,
so any bug you encounter is (almost surely) in the very last line of
code you wrote or changed, or some function you thought was handling
all cases correctly turns out not to be working correctly in which case
you simply go back to repair that one function and then when it's
working better you pick up where you left off in debugging the new
function that calls the now-fixed function.
> 3) LUSH Lisp (http://lush.sourceforge.net/) looks quite neat, easy
> interfacing to SDL & OpenGL & has basic examples. However it looks
> like the interpreter is an older design and doesn't have lexical
> scoping - should I just use this or will it colour my view of modern
> Common Lisps?
I'm not familiar with LUSH, so I don't know whether it has lexical
scoping or not, but assuming you're correct that it doesn't: Many times
I find it handy to use a mapping function such as MAPCAR which maps
down a list of values but also references some relatively static
binding in the lexical context (either a value that is constant across
the mapping loop, or some sort of accumulator or counter). If you have
lexical scoping, this is a breeze. But without lexical scoping you
basically have to use dynamic bindings instead. The only real gotcha is
that you must always remember to declare those bindings as "special"
(Lisp jargon for dynamic), so that compiled code will continue to work
the same as interpreted code did. Be sure to use some naming convention
for all special variables so you don't accidently use one of them
elsewhere where you didn't need dynamic binding and wouldn't want to
pay the extra cost of dynamic binding for no benefit. If you ever want
to port such a function to CL, you can leave it as-is initially, then
eventually change those relatively-static bindings to lexical bindings,
reducing the runtime overhead somewhat.
In the rare case where you might want to use lexical scoping to create
a shared private binding, such as:
(let ((x 5))
(defun getx () x)
(defun setx (newx) (setq x newx))
(defun incx () (incf x)))
that's rather harder to fake by dynamic bindings, so you'll just have
to avoid doing that, or set up some sort of global variable with a long
name nobody would accidently step on, or use OOP if that's available.
I don't think it's *necessary* to use Emacs; I have spent some time
trying, including using Viper, but I haven't yet managed to make the
switch.
I use Vim, using vilisp (it's on vim.org) to allow me to, e.g., "\es"
to evaluate the current toplevel s-expression, or "\laf" to load the
active file. In principle it also allows CLHS lookup. I find it a very
productive editing environment -- I lose out on SLIME's debugging
features, etc., but I can throw text around very rapidly.
For a real integrated environment, one can use vimsh to embed a shell
session in a Vim buffer, then use vilisp to connect to it... voila, a
REPL in your editor.
vilisp can run arbitrary commands, not just a Lisp, so I actually use
it to connect over SSH to a Lisp web server inside a screen session.
Transparent connection to a remote REPL.
I wrote up a little post about this some time ago:
<http://www.holygoat.co.uk/blog/entry/2004-10-06-2>