I'm interested in learning a little bit of Lisp. I've been reading
about Lisp, but I think if I am really going to pick it up I need to
program Lisp.
Is there a good series of programming problems that will require me to
use (and learn) different parts of the language?
>I'm interested in learning a little bit of Lisp. I've been reading
>about Lisp, but I think if I am really going to pick it up I need to
>program Lisp.
I thought the same way. My way of learning was to start doing all of my
class assignments in Lisp. This might not work for you if you don't
already have a reason for programming (classes, a job, some hobby
project). If you just feel that learning a language, such as Lisp,
would be an interesting experience then it is a bit harder because you
need to come up with your own programming tasks.
>Is there a good series of programming problems that will require me to
>use (and learn) different parts of the language?
If you are looking for short exercises to test your understanding of
specific language features, there was a thread on that just a little
while ago called "Looking for rudimentary learning exercises"
http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/ddd5ca5e5b0b9fd3/755d143a77359d94?q=exercises&rnum=1&hl=en#755d143a77359d94
If you are looking for more practical problems whose solutions will
benefit the community, there are many options for that also. You could
submit Lisp solutions to benchmarks at shootout.alioth.debian.org or
work on an open source project. For a list of projects that are
appropriate for inexperienced developers, check out the Summer of Lisp
page at http://www.lispnyc.org/summerofcode.html
Participants in the Summer of Lisp program will be assigned experienced
mentors to help them.
The first few homework assignments in my AI class used exercises from
Graham's _ANSI Common Lisp_ to break us in:
2.1 - 2.5
3.2, 3.3
5.1, 5.2, 5.8
6.2, 6.3
These exercises in conjunction with his exposition are, in my opinion,
the way to get started.
Something I always write in a new language is something that counts
word frequency in a file. Let's you touch on non trivial data
structures, file handling and string processing.
Then I picked a couple of random things out of the air. I implemented
something that picks out boggle words from a boggle grid (you can
google for the rules of boggle), and a black jack game that displays
the cards in ascii.
Justin
Sean asks
> Is there a good series of programming problems that will
> require me to use (and learn) different parts of the
> language?
My favourite context for learning-by-doing is generating
graphical output. Part of the attraction is a childish
delight in the bright saturated colours of the computer
screen. Another attraction is that if your programs are
intended to draw things, bugs manifest themselves as the
drawing coming out wrong.
For example if your code is supposed to draw a right angled
triangle and you have made your own square root routine,
complete with bug, then the hypotenuse will be the wrong
length, and you will see it sticking out too far.
Since I'm running a Unix, it seemed natural to try
generating graphics by drawing on X11 windows using the X11
protocol. That is pretty low level, but my goal was to
learn Lisp, not to learn a higher level X protocol, so I
hoped that sticking to the low level protocol would keep
things simple and not take me too far from my original
goal. My gut feeling is that the low level is the fun level,
at which one can do animations, write silly games, try out
one's own user interface ideas and discover why they suck...
It has not worked out as well as I hoped.
The Common Lisp equivalent to Xlib is CLX. You need to print
off the CLX Programmer's Reference. It is short, which is
good, but it manages this by assuming that you have Volume
One of the Xlib Programming Manual on your book shelf, and
have learned the basic concepts from that. The Xlib
Programming Manual is very well written, but it is for C, so
I had to revise my C so that I could read the example code.
X11 is quite complicated. In particular, it does "Client
Side Refresh". Your program cannot just draw a line on the
screen and expect it to stay there. It must remember the
line and redraw it when the X server says "sorry your window
got covered over, tell me what was on it again". You need to
structure your code with this in mind.
On the other hand I got some 3D visualisation code working
yesterday and it is such fun to play with. I had a definite
goal; I wanted to visualise the Lorenz attractor as part of
a plan to use the chaotic dynamics in a synthetic musical
instrument. Now I find myself distracted by writing code to
generate objects to look at - an icosahedron - a globe made
of lines of latitude and longitude - torus made of lines
looping and winding round it.
When Sean asks for a series of programming problems I
immediately think graphics - even a crude 3D wire-frame
visualisation program taunts you - draw a dodecahedron, draw
a fractal fern in 2D and then turn it into a tree in 3D -
write a crude 3D differential equation solver and look at the
limit cycles.
Is "Play with CLX" a reasonable suggestion?
I've written notes at
http://alan.crowe.name/clx/simple/examples.txt
which offer a far gentler (and sadly incomplete)
introduction to CLX programming than the usual texts.
I've put the 3D-viewer code online at
http://alan.crowe.name/clx/3D-viewer/index.html
a fortnight ahead of it being fit for public presentation.
Like I said, I brought it to life yesterday and it still has
the bolts through its neck.
Alan Crowe
Edinburgh
Scotland
On Thu, 18 Aug 2005 00:09:54 +0100, Alan Crowe wrote:
> My favourite context for learning-by-doing is generating graphical
> output. Part of the attraction is a childish delight in the bright
> saturated colours of the computer screen. Another attraction is that if
> your programs are intended to draw things, bugs manifest themselves as
> the drawing coming out wrong.
That also holds for sound as well. Human pattern-matching to the rescue.
> Like I said, I brought it to life yesterday and it still
> has the bolts through its neck.
I've spent the morning tidying up the code at
http://alan.crowe.name/clx/3D-viewer/index.html
and put in some big block comments describing the
organisation of the code. So it might now be worth a look.
Alan Crowe
Edinburgh
Scotland
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> > Like I said, I brought it to life yesterday and it still
> > has the bolts through its neck.
>
> I've spent the morning tidying up the code at
>
> http://alan.crowe.name/clx/3D-viewer/index.html
>
> and put in some big block comments describing the
> organisation of the code. So it might now be worth a look.
I browsed the code and noticed this bit:
;;;; (gripe-p) => true
;; I hate getting caught out by the fact that CL:T is a constant
;; I want to use t for time
(defconstant true 'cl:t)
(shadow 't)
;; Ofcourse, now I get caught out when (format t ...) doesn't work.
;; It needs to be (format true ...) so that format sees CL:T
;; Format doesn't accept CL-USER:T
Why not just use CL:T instead of TRUE? And why would you want to use
CL-USER::T instead of CL:T?
Zach
Zach asked:
> Why not just use CL:T instead of TRUE? And why would you
> want to use CL-USER::T instead of CL:T?
I want to be able to write
(defun circle (t)
(make-point :x (cos t)
:y (sin t)))
but I cannot use cl:t because cl:t is a constant.
I think that the three leading options are
1) Have a constant called "t" and a variable "time"
2) Have a constant called "true" and a variable called "t"
3) Have a constant called "cl:t" and a variable called "t"
Common Lisp steers one towards option 1, but it feels
uncomfortable when one is working from printed material full
of x(t),y(t),z(t),...
Option 3 fails on both aesthetics and typing, #\: is a
shifted character.
Alan Crowe
Edinburgh
Scotland
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> 3) Have a constant called "cl:t" and a variable called "t"
[snip]
> Option 3 fails on both aesthetics and typing, #\: is a
> shifted character.
When reading code, I think cl:t is much clearer than a new constant
"true".
I think the burden of typing a ":" is relatively light; I don't mind
using keywords and other package-prefixed symbols where necessary.
Zach
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Zach asked:
>
>> Why not just use CL:T instead of TRUE? And why would you
>> want to use CL-USER::T instead of CL:T?
>
> I want to be able to write
>
> (defun circle (t)
> (make-point :x (cos t)
> :y (sin t)))
What's wrong with:
(defun circle (theta) (make-point :x (cos theta) :y (sin theta)))
(Note that with the right emacs configuration, theta shows as: θ
so you still read only one character (and the rigth one at that).
Search for "pretty greek" or "pretty symbols").
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
Alan Crowe <····@cawtech.freeserve.co.uk> wrote:
+---------------
| Is "Play with CLX" a reasonable suggestion?
| I've written notes at
| http://alan.crowe.name/clx/simple/examples.txt
| which offer a far gentler (and sadly incomplete)
| introduction to CLX programming than the usual texts.
...
| http://alan.crowe.name/clx/3D-viewer/index.html
+---------------
Thanks! This is a much better introduction than my own
clumsy first CLX attempts. ;-}
One thing you might want to add, though. In your "examples.txt",
you include the following [understandable!] complaint:
(my-window (xlib:create-window :parent root-window
:x 0 :y 0 :width 200 :height 100)))
This is the line you have been waiting for, that creates a
window. Frustratingly, :x and :y are required parameters.
You have to say where you want it, even though, as a top level
window, the window manager will intervene and put it where it
thinks best. The window manager can also overrule your chosen
width and height, though that is less common.
Fortunately, there is a simple solution for this!! Just add this after
your XLIB:CREATE-WINDOW call but before the XLIB:MAP-WINDOW call:
(xlib:set-wm-properties my-window
:name my-window-title ; a string
:icon-name my-icon-title ; a string
:user-specified-position-p t)
The magic is the ":USER-SPECIFIED-POSITION-P T", which asks the window
manager to respect the requested X & Y from the CREATE-WINDOW call.
Now you can place your windows wherever you want. ;-} ;-}
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock suggests
> Fortunately, there is a simple solution for this!! Just add this after
> your XLIB:CREATE-WINDOW call but before the XLIB:MAP-WINDOW call:
>
> (xlib:set-wm-properties my-window
> :name my-window-title ; a string
> :icon-name my-icon-title ; a string
> :user-specified-position-p t)
I've changed the text of my first example. It now reads
This is the line you have been waiting for, that creates a
window. :x 0 and :y 0 specify the top left. Don't worry if
that is not where you want it to go. Since it is a top
level window, the window manager will intervene and put it
where it thinks best. The window manager can also overrule
your chosen width and height, though that is less common.
(The intervention of the window manager, known as
redirection, is undesirable when you are popping up a menu
window, and can be turned off, that is overridden, with
":override-redirect :on". Don't try this now. Since the
window manager has been told to stay out of it, it will not
put a border round your window, so there might be nothing to
see even if the code works.)
I've uploaded an extra example (that I wrote a while ago) that uses
xlib:change-properties to set the wm_name property so as to
give the window a name. That introduces properties and sets
the scene for menu code that will actually use
:user-specified-position-p t or :override-redirect.
Is there any reason to prefer one or the other?
I used xlib:change-properties because I didn't know about
xlib:set-wm-properties. It is missing from the index of my
copy of the CLX programmer's Reference.
I guess at the difference - set-wm-properties has key
word arguments. When you are changing a window manager
property the argument checking of set-wm-properties protects
you against mis-spelling the property name. When you are
changing an arbitary property, this checking will block you;
you have to use change-properties.
So I've used the wrong one :-(
Alan Crowe
Edinburgh
Scotland
Alan Crowe <····@cawtech.freeserve.co.uk> wrote:
+---------------
| Rob Warnock suggests
| > Fortunately, there is a simple solution for this!! Just add this after
| > your XLIB:CREATE-WINDOW call but before the XLIB:MAP-WINDOW call:
| >
| > (xlib:set-wm-properties my-window
| > :name my-window-title ; a string
| > :icon-name my-icon-title ; a string
| > :user-specified-position-p t)
|
| I've changed the text of my first example. It now reads
| ..
| (The intervention of the window manager, known as
| redirection, is undesirable when you are popping up a menu
| window, and can be turned off, that is overridden, with
| ":override-redirect :on". Don't try this now. Since the
| window manager has been told to stay out of it, it will not
| put a border round your window, so there might be nothing to
| see even if the code works.)
+---------------
Whereas if you use (set-wm-properties :user-specified-position-p t),
the WM still decorates the window (border, titlebar), but (hopefully)
puts it where you asked for it to be with (create-window :x x :y y ...).
+---------------
| I've uploaded an extra example (that I wrote a while ago) that uses
| xlib:change-properties to set the wm_name property so as to
| give the window a name. That introduces properties and sets
| the scene for menu code that will actually use
| :user-specified-position-p t or :override-redirect.
|
| I used xlib:change-properties because I didn't know about
| xlib:set-wm-properties. It is missing from the index of my
| copy of the CLX programmer's Reference.
+---------------
Well, *I* didn't know about XLIB:CHANGE-PROPERTIES, 'cuz I never
read all the way through the CLX Programmer's Reference. ;-}
I learned about XLIB:SET-WM-PROPERTIES from some analogous
code in one of the Elk Scheme XLIB examples, and found that
CLX provided the same function.
And I didn't know about (create-window :override-redirect :on ...),
either, so thanks for that! ;-}
+---------------
| Is there any reason to prefer one or the other?
+---------------
Except for your observation about keyword args vs. positional,
I don't. But then, I really don't know enough about the X Windows
protocol to be giving very much advice. :-(
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Sean" <···········@gmail.com> writes:
> I'm interested in learning a little bit of Lisp. I've been reading
Another approach may be to ask your friends who run small businesses
whether they have some little task--possibly not mission
critical--they would like to automate. This way, if you do the task
well and get interested in Lisp, there may be future opportunities to
get some money for maintaining and enhancing those applications.
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface