(Lisp newbie, obviously.)
How can I convert a string to a list of characters?
I want to write a function that takes "Hello" and gives (H e l l o).
Everything I've tried gives me either ("H" "e" "l" "l" "o") or (#\H #\e
#\l #\l #\o).
r_stiltskin wrote:
> (Lisp newbie, obviously.)
>
> How can I convert a string to a list of characters?
>
> I want to write a function that takes "Hello" and gives (H e l l o).
>
> Everything I've tried gives me either ("H" "e" "l" "l" "o") or (#\H #\e
> #\l #\l #\o).
>
Here are some more choices:
CL-USER 8 > (loop for c across "Hello"
collect (make-symbol (string c)))
(#:H #:\e #:\l #:\l #:\o) ; uninterned symbols
CL-USER 9 > (loop for c across "Hello"
collect (intern (string c)))
(H \e \l \l \o) ; interned symbols, ignore the \'s (case sensitivity)
CL-USER 10 > (loop for c across "Hello"
collect (intern (string (char-upcase c))))
(H E L L O) ; interned symbols, string is all upper case
CL-USER 11 > (map 'list (lambda (c) (intern (string c))) "Hello") ; another way
(H \e \l \l \o)
CL-USER 12 >
Wade
thanks all. Yes Svein, I definitely want to learn how to write my own
parser. In fact I guess that's my main goal at this point. The math
part is incidental -- to give the parser something interesting to do.
I'm puzzled. Can someone give me a brief explanation of the distinctions
between a symbol a, a character #\a, a string "a", an interned symbol, an
uninterned symbol?
And what does \ have to do with case sensitivity?
Or if that's too much to explain here, any suggestions as to where I
should look for answers?
r_stiltskin wrote:
> thanks all. Yes Svein, I definitely want to learn how to write my own
> parser. In fact I guess that's my main goal at this point. The math
> part is incidental -- to give the parser something interesting to do.
>
> I'm puzzled. Can someone give me a brief explanation of the distinctions
> between a symbol a, a character #\a, a string "a", an interned symbol, an
> uninterned symbol?
A character is *just* a character, with no more trappings.
The string "a" is in fact a one-dimensional array containing one element,
that element being the character #\a. This is why you can frob strings
using the standard array functions.
The symbol A is a data structure with a number of properties; these
properties include a name, which is the string "A", a package association,
a value association and a function association. All of these can be empty,
except for the name. (The name *can* be an empty string, but not actually
unbound.)
An interned symbol has an associated package in the package field, and, more
importantly, that package has a hash-table entry mapping from the name to
the symbol. Thusly, you'll get the symbol from the reader.
An uninterned symbol doesn't have a package association, and no package has
an entry for the symbol; therefore, it is impossible for a read to return
it. This means that it can only be used by storing it in variables, and has
the important implication that they're safe to use in macros; it is
impossible for a programmer to write code that would use the same symbol as
the macro does, since they're generated programmatically and can't be read.
> And what does \ have to do with case sensitivity?
>
Lisp is case-sensitive, but by default the reader upcases every symbol and
the printer prints escape-keys as appropriate so you can use output as
input.
H is read as a symbol named "H".
h is read as a symbol named "H".
\h is read as a symbol named "h".
> Or if that's too much to explain here, any suggestions as to where I
> should look for answers?
gigamonkeys.com/book explains this, among other things.
The hyperspec (www.lispworks.com) contains the specification, which can be a
bit hard reading but is /very/ useful. You can get at it using C-c C-d h in
Slime. (If you aren't using Slime, you probably should be; visit
www.cliki.net/slime)
r_stiltskin wrote:
> thanks all. Yes Svein, I definitely want to learn how to write my own
> parser. In fact I guess that's my main goal at this point. The math
> part is incidental -- to give the parser something interesting to do.
>
> I'm puzzled. Can someone give me a brief explanation of the distinctions
> between a symbol a, a character #\a, a string "a", an interned symbol, an
> uninterned symbol?
> And what does \ have to do with case sensitivity?
>
> Or if that's too much to explain here, any suggestions as to where I
> should look for answers?
Besides Svein's good suggestions, I can also recommend taking a look at
Chapter 2 in Guy Steele's "Common Lisp the Language, 2nd Edition".
Google for "CLtL2" and download that book as HTML.
Pascal
Hmmm...
There's more to this than meets the eye. I'm sure those books will be
very helpful. Coincidentally, I just got slime yesterday. So now I have
one more thing to add to my "learn-right-now" list: how to use emacs.
Well, I should have done that already anyway.
All I've done so far with lisp is write some simple functions just to get
the hang of it. So, when I was writing something like
(setq a (cons 'b '(c d e)))
I was just thinking of a as a variable and b, c, d and e as characters in
a very general sense without really thinking in terms of types. In terms
of Svein's post, all of my a,b,c,d,e are symbols, yes?
One more thing: I'm surprised by:
>Lisp is case-sensitive, but by default the reader upcases every symbol
and
>the printer prints escape-keys as appropriate so you can use output as
input.
I was under the impression that it is case-insensitive. Using my simple
example (above), if I type:
> a
the result is
(B C D E)
and similarly, if I define a function
(defun myReverse (L)
....
I can call it using
(myReverse x)
or
(myreverse x)
or
(MYREVERSE x)
and clisp doesn't seem to care.
So how is it case-sensitive?
"r_stiltskin" <········@very.spam.yahoo.com> writes:
> Hmmm...
> There's more to this than meets the eye. I'm sure those books will be
> very helpful. Coincidentally, I just got slime yesterday. So now I have
> one more thing to add to my "learn-right-now" list: how to use emacs.
> Well, I should have done that already anyway.
>
> All I've done so far with lisp is write some simple functions just to get
> the hang of it. So, when I was writing something like
> (setq a (cons 'b '(c d e)))
> I was just thinking of a as a variable and b, c, d and e as characters in
> a very general sense without really thinking in terms of types. In terms
> of Svein's post, all of my a,b,c,d,e are symbols, yes?
Yes.
(defvar a nil)
(defvar b nil)
(setq a (cons 'b '(c d e)))
(setq b (cons 'a '(c d e)))
[26]> (car a)
B
[27]> (symbol-value (car a)) ; or (symbol-value 'b)
(A C D E)
[28]> (car b)
A
[29]> (symbol-value (car b)) ; or (symbol-value 'a)
(B C D E)
[30]> (symbol-value 'a)
(B C D E)
But SYMBOL-VALUE works only because these symbol have a global,
dynamic binding.
[31]> (let ((c (cons 'a '(c d e))))
(symbol-value (cadr a))) ; or (symbol-value 'c)
*** - SYMBOL-VALUE: C has no dynamic value
There, the symbol C is not modified by LET. It's only used to name a
variable inside the body of LET.
> One more thing: I'm surprised by:
> >Lisp is case-sensitive, but by default the reader upcases every symbol
> and
> >the printer prints escape-keys as appropriate so you can use output as
> input.
>
> I was under the impression that it is case-insensitive. Using my simple
> example (above), if I type:
> > a
> the result is
> (B C D E)
>
> and similarly, if I define a function
> (defun myReverse (L)
> ....
> I can call it using
> (myReverse x)
> or
> (myreverse x)
> or
> (MYREVERSE x)
> and clisp doesn't seem to care.
>
> So how is it case-sensitive?
It is case sensitive in the sense that:
(not (eq (quote |myReverse|) (quote |MYREVERSE|)))
eg.: |myReverse| is not the same symbol as |MYREVERSE|
Now, whether myReverse is the same symbol as myreverse or MYREVERSE
depends on the readtable case, that is what the reader does to the
strings "myReverse", "myreverse" or "MYREVERSE" before interning them.
The default setting for the readtable case is to upcase all unescaped
symbol names. Therefore, it looks like it's case insensitive. But
it's not.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Litter box not here.
You must have moved it again.
I'll poop in the sink.
"r_stiltskin" <········@very.spam.yahoo.com> writes:
> (setq a (cons 'b '(c d e)))
You're heading toward shooting yourself in the foot. When doing
something like this do it this way instead:
(setf a (cons 'b (list 'c 'd 'e)))
<queue KT's (appropriate) rant here>
> of Svein's post, all of my a,b,c,d,e are symbols, yes?
Yes.
...
> So how is it case-sensitive?
Simple, strings and symbols, whose names are strings, which have
different case are not the "same". You missed the bit about the
_Reader_ automatically _upcasing_ symbol names _before_ interning.
Examples:
(string= "Abc" "ABc") ==> nil
(eq 'abc '|abc|) ==> nil
OTOH,
(string-equal 'abc "abc") ==> t
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay <······@foo.com> wrote:
>> (setq a (cons 'b '(c d e)))
>You're heading toward shooting yourself in the foot. >When doing
>something like this do it this way instead:
>(setf a (cons 'b (list 'c 'd 'e)))
It should be clear by now that I'm just barely beyond "hello, world" in
lisp, but OK, I'll bite:
Why does (setq a (cons 'b '(c d e))) endanger my foot?
r_stiltskin wrote:
> jayessay <······@foo.com> wrote:
>
>>>(setq a (cons 'b '(c d e)))
>>
>>You're heading toward shooting yourself in the foot. >When doing
>>something like this do it this way instead:
>>
>>(setf a (cons 'b (list 'c 'd 'e)))
>
> It should be clear by now that I'm just barely beyond "hello, world" in
> lisp, but OK, I'll bite:
> Why does (setq a (cons 'b '(c d e))) endanger my foot?
Because you've constructed a list that is partially a read-only and
potentially shared, and partially not. '(c d e) evaluates to a list
that is read only, but (cons 'b '(c d e)) evaluates to a cons-cell that
is not read only. So now you have a list where you can modify the CAR
and the CDR, but you can not modify the second, third, or fourth slots.
Using LIST to make a list ensures that you get a fresh, modifiable list,
and not one that is read only or shared.
-- MJF
"r_stiltskin" <········@very.spam.yahoo.com> writes:
> jayessay <······@foo.com> wrote:
>
> >> (setq a (cons 'b '(c d e)))
>
> >You're heading toward shooting yourself in the foot. >When doing
> >something like this do it this way instead:
>
> >(setf a (cons 'b (list 'c 'd 'e)))
>
> It should be clear by now that I'm just barely beyond "hello, world" in
> lisp, but OK, I'll bite:
> Why does (setq a (cons 'b '(c d e))) endanger my foot?
Because it is highly likely that you are using constant data even
though you are probably thinking '(c d e) is giving you a _new_ list
each time you use it.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay <······@foo.com> writes:
> Because it is highly likely that you are using constant data even
> though you are probably thinking '(c d e) is giving you a _new_ list
> each time you use it.
Incidentally, when I was learning Perl, I was rather surprised
that [1, 2, 3] returns a reference to a fresh array every time,
i.e. it is more like (vector 1 2 3) than #(1 2 3). Apparently,
Perl does not have a syntax that would embed a constant object
within a function, like QUOTE and LOAD-TIME-VALUE do in Common
Lisp and static does in C. Instead, such objects must be named
and defined outside the function, like (let (...) (defun ...)).
jayessay <······@foo.com> wrote:
> >"r_stiltskin" <········@very.spam.yahoo.com> writes:
> > jayessay <······@foo.com> wrote:
> >
> > >> (setq a (cons 'b '(c d e)))
> >
> > >You're heading toward shooting yourself in the foot. >When doing
> > >something like this do it this way instead:
> >
> > >(setf a (cons 'b (list 'c 'd 'e)))
> >
> > It should be clear by now that I'm just barely beyond "hello, world"
in
> > lisp, but OK, I'll bite:
> > Why does (setq a (cons 'b '(c d e))) endanger my foot?
> Because it is highly likely that you are using constant data even
> though you are probably thinking '(c d e) is giving you a _new_ list
> each time you use it.
Actually I wasn't thinking about that aspect at all, but now that you guys
brought it up I'm curious. Maybe I'm still not getting your point, but I
tried the following:
Break 2 [3]> (setq list1 '(b c d))
(B C D)
Break 2 [3]> (setq list2 (cons 'a list1))
(A B C D)
Break 2 [3]> (rplaca (cdr (cdr list2)) 'x)
(X D)
Break 2 [3]> list2
(A B X D)
Break 2 [3]> list1
(B X D)
Does that contradict what you were saying, or is the behavior
implementation-specific (I'm using Gnu Clisp 2.33.2) or were you writing
about something else altogether?
On further thought, maybe my example confirms what you're saying: that the
original list and the cdr of the "new" list formed by cons are one and the
same, so applying rplaca to either variable list1 or list2 changes the
value returned by both.
But I don't understand what you're saying is 'read only'. I haven't come
across an instance of a list (or a part of a list) that I couldn't modify.
"r_stiltskin" <········@very.spam.yahoo.com> writes:
> On further thought, maybe my example confirms what you're saying: that the
> original list and the cdr of the "new" list formed by cons are one and the
> same, so applying rplaca to either variable list1 or list2 changes the
> value returned by both.
>
> But I don't understand what you're saying is 'read only'. I haven't come
> across an instance of a list (or a part of a list) that I couldn't modify.
It's not that you can't; it's that you shouldn't:
The consequences of modifying a literal object are undefined.
If that doesn't instill the appropriate fear and loathing in you, it
should. When something says "undefined", it means that it might be
impossible, it might be shared, closure-like, among one or several
functions, or it might corrupt the heap and/or cause nasal demons.
Put another way, *don't do that*.
Never pass a literal value to a function you aren't sure won't modify
it, never return one from a global (defun-ed) function, and you'll be
safe enough.
If in doubt, wrap copy-tree around it.
"r_stiltskin" <········@very.spam.yahoo.com> writes:
> On further thought, maybe my example confirms what you're saying: that the
> original list and the cdr of the "new" list formed by cons are one and the
> same, so applying rplaca to either variable list1 or list2 changes the
> value returned by both.
>
> But I don't understand what you're saying is 'read only'. I haven't come
> across an instance of a list (or a part of a list) that I couldn't modify.
Just one thing, by the way - please include some context in your
postings. My newsreader does not show read articles by default, and
remembering what you're talking about required some concentration.
"r_stiltskin" <········@very.spam.yahoo.com> writes:
> Actually I wasn't thinking about that aspect at all, but now that you guys
> brought it up I'm curious. Maybe I'm still not getting your point, but I
> tried the following:
>
> Break 2 [3]> (setq list1 '(b c d))
> (B C D)
> Break 2 [3]> (setq list2 (cons 'a list1))
> (A B C D)
> Break 2 [3]> (rplaca (cdr (cdr list2)) 'x)
> (X D)
> Break 2 [3]> list2
> (A B X D)
> Break 2 [3]> list1
> (B X D)
>
> Does that contradict what you were saying, or is the behavior
> implementation-specific (I'm using Gnu Clisp 2.33.2) or were you writing
> about something else altogether?
Try this on CLisp:
;; We define foo as a function that returns a quoted list:
[1]> (defun foo () '(a b c))
FOO
[2]> (foo)
(A B C)
;; If we print the function foo, we can see that the source code
;; includes the list that is returned. Other Lisp systems will
;; print this differently, and if the function is compiled, it may
;; be difficult to find the list, but it is there somewhere.
[3]> (print #'foo)
#<CLOSURE FOO NIL (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO '(A B C))>
#<CLOSURE FOO NIL (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO '(A B C))>
;; So far, so good.
[4]> (defvar *test* (foo))
*TEST*
[5]> *test*
(A B C)
;; This next line is illegal code with undefined consequences.
[6]> (setf (cdr *test*) 'surprise)
SURPRISE
;; But it seems to work....
[7]> *test*
(A . SURPRISE)
;; But FOO has changed, too!
[8]> (foo)
(A . SURPRISE)
[9]> (print #'foo)
#<CLOSURE FOO NIL (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO '(A . SURPRISE))>
#<CLOSURE FOO NIL (DECLARE (SYSTEM::IN-DEFUN FOO)) (BLOCK FOO '(A . SURPRISE))>
Literal quoted lists in your source code become *part* of your source
code, so modifying them may have unintended consequences. In this
case, the modification ended up changing the definition of FOO, but
there is no guarantee that it won't crash the system or do worse.
"r_stiltskin" <········@very.spam.yahoo.com> writes:
> jayessay <······@foo.com> wrote:
>
> > >"r_stiltskin" <········@very.spam.yahoo.com> writes:
>
> > > jayessay <······@foo.com> wrote:
> > >
> > > >> (setq a (cons 'b '(c d e)))
> > >
> > > >You're heading toward shooting yourself in the foot. >When doing
> > > >something like this do it this way instead:
> > >
> > > >(setf a (cons 'b (list 'c 'd 'e)))
> > >
> > > It should be clear by now that I'm just barely beyond "hello, world"
> in
> > > lisp, but OK, I'll bite:
> > > Why does (setq a (cons 'b '(c d e))) endanger my foot?
>
> > Because it is highly likely that you are using constant data even
> > though you are probably thinking '(c d e) is giving you a _new_ list
> > each time you use it.
>
> Actually I wasn't thinking about that aspect at all, but now that you guys
> brought it up I'm curious. Maybe I'm still not getting your point, but I
> tried the following:
>
> Break 2 [3]> (setq list1 '(b c d))
> (B C D)
> Break 2 [3]> (setq list2 (cons 'a list1))
> (A B C D)
> Break 2 [3]> (rplaca (cdr (cdr list2)) 'x)
> (X D)
> Break 2 [3]> list2
> (A B X D)
> Break 2 [3]> list1
> (B X D)
>
> Does that contradict what you were saying, or is the behavior
> implementation-specific (I'm using Gnu Clisp 2.33.2) or were you writing
> about something else altogether?
It's worse than that.
You don't see it because you've tried it on the REPL.
Try it within a function:
;; With clisp (implementation dependant behavior below):
[1]> (defun prep (x) (cons x '(t a i l)))
PREP
[2]> (defparameter list (prep 'list-1))
LIST
[3]> list
(LIST-1 T A I L)
[4]> (values (function-lambda-expression 'prep))
(LAMBDA (X) (DECLARE (SYSTEM::IN-DEFUN PREP)) (BLOCK PREP (CONS X '(T A I L))))
[5]> (setf (third list) 'x)
X
[6]> list
(LIST-1 T X I L)
[7]> (values (function-lambda-expression 'prep))
(LAMBDA (X) (DECLARE (SYSTEM::IN-DEFUN PREP)) (BLOCK PREP (CONS X '(T X I L))))
[8]> (prep 'new-list)
(NEW-LIST T X I L)
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
"r_stiltskin" <········@very.spam.yahoo.com> writes:
>
> jayessay <······@foo.com> wrote:
>
> > >"r_stiltskin" <········@very.spam.yahoo.com> writes:
> > > Why does (setq a (cons 'b '(c d e))) endanger my foot?
>
> > Because it is highly likely that you are using constant data even
> > though you are probably thinking '(c d e) is giving you a _new_ list
> > each time you use it.
>
> Actually I wasn't thinking about that aspect at all, but now that you guys
> brought it up I'm curious. Maybe I'm still not getting your point, but I
> tried the following:
>
> Break 2 [3]> (setq list1 '(b c d))
> (B C D)
> Break 2 [3]> (setq list2 (cons 'a list1))
> (A B C D)
> Break 2 [3]> (rplaca (cdr (cdr list2)) 'x)
> (X D)
> Break 2 [3]> list2
> (A B X D)
> Break 2 [3]> list1
> (B X D)
>
> Does that contradict what you were saying, or is the behavior
> implementation-specific (I'm using Gnu Clisp 2.33.2) or were you writing
> about something else altogether?
Actually, this example doesn't really illustrate the difference. In
this case you would get the same result if you had set list1 to be
(list 'b 'c 'd). That is because you are explicitly sharing structure
when you use list1 as the cdr of list2. In lisp, arguments are not
magically copied behind your back. The line
(setq list2 (cons 'a list1))
sets up a structure like
list1
|
|
V
+---+---+ +---+---+ +---+---+ +---+-----+
list2 ----->| A | *-+-->| B | *-+-->| C | *-+-->| D | NIL |
+---+---+ +---+---+ +---+---+ +---+-----+
So, since part of the list structure is shared, you should not be
surprised when a change through one access route changes the structure.
The problem comes with the use of a constant form (indicated by the
quote), since the compiler is allowed by the Common Lisp Spec to assume
constants are truly constant and introduce additional structure
sharing.
The difference is that if you do
(setq list1 (list 'b 'c 'd))
(setq list2 (list 'b 'c 'd))
the compiler MUST produce the following structures:
+---+---+ +---+---+ +---+-----+
list1 ----->| B | *-+-->| C | *-+-->| D | NIL |
+---+---+ +---+---+ +---+-----+
+---+---+ +---+---+ +---+-----+
list2 ----->| B | *-+-->| C | *-+-->| D | NIL |
+---+---+ +---+---+ +---+-----+
If, instead, you were to do
(setq list1 '(b c d))
(setq list2 '(b c d))
then at its option, the compiler could produce the structure above, or
it could optimize space by producing the shared structure below:
list1
|
|
V
+---+---+ +---+---+ +---+-----+
list2 ----->| B | *-+-->| C | *-+-->| D | NIL |
+---+---+ +---+---+ +---+-----+
since '(b c d) is supposed to be a constant, there should be no
difference in the behavior of a conforming program. But a conforming
program is not allowed to modify its constants. That would mean that
the following:
(setf (car (cdr list2)) 'x)
would not be conforming, and is likely to be highly confusing to the
programmer.
--
Thomas A. Russ, USC/Information Sciences Institute
r_stiltskin wrote:
> (Lisp newbie, obviously.)
>
> How can I convert a string to a list of characters?
>
> I want to write a function that takes "Hello" and gives (H e l l o).
>
> Everything I've tried gives me either ("H" "e" "l" "l" "o") or (#\H #\e
> #\l #\l #\o).
What you want is what you get:
("H" "e" "l" "l" "o") is a list of strings.
(#\H #\e #\l #\l #\o) is a list of characters. (#\ is the notation for
single characters in Common Lisp.)
(H e l l o) would be a list of symbols. I can't imagine a scenario in
which that would be useful. What are you trying to do?
Pascal
The cute answer is I'm trying to learn lisp. ;)
As part of this process, I'm trying to write a program that can take an
algebra equation (nothing too complicated - one unknown, 1st degree, no
trig functions,...) which the user inputs as a string, parse it, verify
that its syntax is valid, evaluate and rearrange the terms, and finally
solve for the unknown.
So I'm stuck at the beginning of step 1. Argggh.
r_stiltskin wrote:
> The cute answer is I'm trying to learn lisp. ;)
>
> As part of this process, I'm trying to write a program that can take an
> algebra equation (nothing too complicated - one unknown, 1st degree, no
> trig functions,...) which the user inputs as a string, parse it, verify
> that its syntax is valid, evaluate and rearrange the terms, and finally
> solve for the unknown.
>
> So I'm stuck at the beginning of step 1. Argggh.
Well, let me point you at http://gigamonkeys.com/book/, so you have a
tutorial. (Save a tree - buy the paper edition.)
Besides that, you seem to want to write your own parser. That's doable, but
another possibility might be to have the user input the formula as
something like (+ (* x 2) (* y 4) 5) instead of 2x + 4y = -5, and use
Lisp's own reader.
You can always retrofit an infix parser later.
You want the INFIX package. Look for it in the CMU AI.Repository.
Cheers
Marco
r_stiltskin wrote:
> The cute answer is I'm trying to learn lisp. ;)
>
> As part of this process, I'm trying to write a program that can take an
> algebra equation (nothing too complicated - one unknown, 1st degree, no
> trig functions,...) which the user inputs as a string, parse it, verify
> that its syntax is valid, evaluate and rearrange the terms, and finally
> solve for the unknown.
>
> So I'm stuck at the beginning of step 1. Argggh.
>
Marco Antoniotti <·······@cs.nyu.edu> wrote:
>You want the INFIX package. Look for it in the CMU >AI.Repository.
Thanks, Marco. I'm sure that'll come in handy at some point, but right
now my goal is to learn to write my own simple parser.
On Tue, 15 Mar 2005 01:15:10 -0500, r_stiltskin wrote:
> Marco Antoniotti <·······@cs.nyu.edu> wrote:
>
>>You want the INFIX package. Look for it in the CMU >AI.Repository.
>
> Thanks, Marco. I'm sure that'll come in handy at some point, but right
> now my goal is to learn to write my own simple parser.
I needed to do this a while back, as I wanted a very simple converter from
infix to RPN syntax. I was amazed at how easy it was to do this in Lisp,
and how small the resulting code was (if you don't need RPN output, just
the infix parser, it's even smaller). You might like to take a look at my
solution:
http://www.abstractnonsense.com/convert.lisp.html
But I think you're right - you can learn a lot from writing your own!
Cheers,
Bill.