Hi guys. I'm going through Holub's book on compilers, and working out
the code in lisp. Listing 1.1 starts out
#define EOI 0 /* end of input */
#define SEMI 1 /* ; */
#define PLUS 2 /* + */
(...)
I've translated this as
(defconstant EOI 0 "End of input")
(defconstant SEMI 1 ";")
(defconstant PLUS 2 "+")
(...)
My question is, what's the prettiest way to enumerate constants like
that? Keywords are nice, but won't cause "Undefined symbol ..." when
I make a typo. What I don't like about the multiple DEFCONSTANT
forms, other than the repetition of DEFCONSTANT, is the need to
manually assign a unique value, to allow comparisons with EQ. The
integers used are not even ideal, because
(eq EOI 0)
would probably not give the answer that you want.
Perhaps
(defconstant EOI :eoi "End of input")
(defconstant SEMI :semi ";")
(defconstant PLUS :plus "+")
is better?
Thanks a lot for any tips!
-Tim
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
···@tenkan.org (Tim Daly, Jr.) writes:
> Hi guys. I'm going through Holub's book on compilers, and working out
> the code in lisp. Listing 1.1 starts out
>
> #define EOI 0 /* end of input */
> #define SEMI 1 /* ; */
> #define PLUS 2 /* + */
>
> (...)
This is the standard C idiom for faking symbols it works when you're
careful to make sure it doesn't break. But you're using Lisp, so I
highly recommend using symbols to represent a symbolic value. It's
such a relief compared to C.
> I've translated this as
>
> (defconstant EOI 0 "End of input")
> (defconstant SEMI 1 ";")
> (defconstant PLUS 2 "+")
>
> (...)
>
>
> My question is, what's the prettiest way to enumerate constants like
> that? Keywords are nice, but won't cause "Undefined symbol ..." when
> I make a typo. What I don't like about the multiple DEFCONSTANT
> forms, other than the repetition of DEFCONSTANT, is the need to
> manually assign a unique value, to allow comparisons with EQ. The
> integers used are not even ideal, because
>
> (eq EOI 0)
>
> would probably not give the answer that you want.
I'd do it like this:
(defmacro define-constant-symbols (&rest forms)
`(progn
,@(mapcar #'(lambda (form)
(etypecase form
(cons (let ((symbol (first form))
(docstring (when (second form)
(list (second form)))))
`(defconstant ,symbol ,symbol ,@docstring)))
(symbol `(defconstant ,symbol ,symbol))))
forms)))
(define-constant-symbols
(EOI "End of input")
(SEMI ";")
(PLUS "+")
BLAH)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ···@tenkan.org (Tim Daly, Jr.) writes:
>
(...)
> > My question is, what's the prettiest way to enumerate constants like
> > that? Keywords are nice, but won't cause "Undefined symbol ..." when
>
(...)
> I'd do it like this:
>
> (defmacro define-constant-symbols (&rest forms)
> `(progn
> ,@(mapcar #'(lambda (form)
> (etypecase form
> (cons (let ((symbol (first form))
> (docstring (when (second form)
> (list (second form)))))
> `(defconstant ,symbol ,symbol ,@docstring)))
> (symbol `(defconstant ,symbol ,symbol))))
> forms)))
>
> (define-constant-symbols
> (EOI "End of input")
> (SEMI ";")
> (PLUS "+")
> BLAH)
Very nice! I'll probably use that frequently in the future.
Did you leave out those quotes on purpose? I like it when the symbols
evaluate to themselves, like this:
(defmacro define-constant-symbols (&rest forms)
`(progn
,@(mapcar #'(lambda (form)
(etypecase form
(cons (let ((symbol (first form))
(docstring (when (second form)
(list (second form)))))
`(defconstant ,symbol ',symbol ,@docstring)))
(symbol `(defconstant ,form ',form))))
forms)))
But I figure that's probably what you meant.
Thanks for the input!
-Tim
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
···@tenkan.org (Tim Daly, Jr.) writes:
> Very nice! I'll probably use that frequently in the future.
>
> Did you leave out those quotes on purpose? I like it when the symbols
> evaluate to themselves, like this:
>
>
> (defmacro define-constant-symbols (&rest forms)
> `(progn
> ,@(mapcar #'(lambda (form)
> (etypecase form
> (cons (let ((symbol (first form))
> (docstring (when (second form)
> (list (second form)))))
> `(defconstant ,symbol ',symbol ,@docstring)))
> (symbol `(defconstant ,form ',form))))
> forms)))
>
>
> But I figure that's probably what you meant.
Yes, I was typing too fast directly into the mail :-/
Obviously if you're going to be declaring constants like this, you
should make sure they're in an appropriate package, so you don't make
all sorts of crazy constants that get in the way of picking nice
variable names. I'd probably make a TOKENS package or something, and
use TOKENS:SEMI, etc...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" <···@whirlwind.OCF.Berkeley.EDU> wrote in message
····················@whirlwind.OCF.Berkeley.EDU...
> ···@tenkan.org (Tim Daly, Jr.) writes:
>
> > Very nice! I'll probably use that frequently in the future.
> >
> > Did you leave out those quotes on purpose? I like it when the symbols
> > evaluate to themselves, like this:
> >
> >
> > (defmacro define-constant-symbols (&rest forms)
> > `(progn
> > ,@(mapcar #'(lambda (form)
> > (etypecase form
> > (cons (let ((symbol (first form))
> > (docstring (when (second form)
> > (list (second form)))))
> > `(defconstant ,symbol ',symbol ,@docstring)))
> > (symbol `(defconstant ,form ',form))))
> > forms)))
> >
> >
> > But I figure that's probably what you meant.
>
> Yes, I was typing too fast directly into the mail :-/
>
> Obviously if you're going to be declaring constants like this, you
> should make sure they're in an appropriate package, so you don't make
> all sorts of crazy constants that get in the way of picking nice
> variable names. I'd probably make a TOKENS package or something, and
> use TOKENS:SEMI, etc...
I think this would be a could time for the +constant+ naming convention, eg
+semi+ Then you could still have
(let ((semi (make-instance 'truck)))
....)
with no visual confusions (and less typing than tokens:semi)
IMO...
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
···@tenkan.org (Tim Daly, Jr.) wrote in message news:<··············@bob.intern>...
>
> (defconstant EOI 0 "End of input")
> (defconstant SEMI 1 ";")
> (defconstant PLUS 2 "+")
I would only do this if I needed to communicate with some external
library which required integer parameters, which have nice names in
that other language.
Also note that the above makes EOI, SEMI and PLUS into special
variables everywhere in your program. It's a bad idea to introduce
such specials into the COMMON-LISP-USER package; always use the *...*
convention, or else confine such specials into a package that is under
your control.
> (...)
>
>
> My question is, what's the prettiest way to enumerate constants like
> that? Keywords are nice, but won't cause "Undefined symbol ..." when
> I make a typo.
There is no problem if you properly handle all the cases everywhere.
The ECASE construct is your friend:
(ecase flavor
((:vanilla) (make-instance 'vanilla-ice-cream))
(:stawberry) (make-instance 'strawberry-ice-cream)))
;; error signaled if flavor is not :vanilla or :strawberry
You can also make lists of keywords that are supported in a given
situation, and use it to implement checks:
(defconstant *tokens* '(:eoi :semi ...))
(defun tokenp (sym) (find sym *token-kinds*))
Now you can go as far as to define a token type:
(deftype token (&optional type) '(satisfies tokenp))
Now you can do things like
(check-type some-value token)
* Kaz Kylheku wrote:
> Also note that the above makes EOI, SEMI and PLUS into special
> variables everywhere in your program. It's a bad idea to introduce
> such specials into the COMMON-LISP-USER package; always use the *...*
> convention, or else confine such specials into a package that is under
> your control.
It doesn't make them special *variables*, since you can't bind them!
However it does globally affect bindings (by making some illegal). I
use +...+ for this kind of thing (which I think is common).
--tim
The world rejoiced as ···@tenkan.org (Tim Daly, Jr.) wrote:
> Hi guys. I'm going through Holub's book on compilers, and working out
> the code in lisp. Listing 1.1 starts out
>
> #define EOI 0 /* end of input */
> #define SEMI 1 /* ; */
> #define PLUS 2 /* + */
>
> (...)
>
> I've translated this as
>
> (defconstant EOI 0 "End of input")
> (defconstant SEMI 1 ";")
> (defconstant PLUS 2 "+")
>
> (...)
>
>
> My question is, what's the prettiest way to enumerate constants like
> that? Keywords are nice, but won't cause "Undefined symbol ..." when
> I make a typo. What I don't like about the multiple DEFCONSTANT
> forms, other than the repetition of DEFCONSTANT, is the need to
> manually assign a unique value, to allow comparisons with EQ. The
> integers used are not even ideal, because
>
> (eq EOI 0)
>
> would probably not give the answer that you want.
It seems to me that you're creating values when all you need are
symbols.
My tendancy would be to not "enumerate" anything.
Any time you need to point at EOI, SEMI, and PLUS, reference 'EOI,
'SEMI, and 'PLUS, perhaps in some particular namespace.
In C, they didn't /have/ symbols, so they needed to simulate it via
the set of constants.
In Lisp, that's the first thing you start with; just write code that
does things like:
(setf foo (if (eof-p stream)
'EOI
(do-something-to stream)))
And later:
(cond
((eq foo 'EOI)
(do-end-of-input-processing))
((member foo '(SEMI PLUS))
(process-semi-and-plus-together)))
Why simulate a construct in C that was actually a simulation of
something that Lisp does perfectly well 'naturally' that was missing
in C?
If there's to be a case where Lisp would be considered a "symbol
processing" language, this is it...
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/internet.html
">in your opinion which is the best programming tools ?
The human brain and a keyboard." -- Nathan Wagner
Tim Daly, Jr. wrote in message <··············@bob.intern>...
>
>Hi guys. I'm going through Holub's book on compilers, and working out
>the code in lisp. Listing 1.1 starts out
>
> #define EOI 0 /* end of input */
> #define SEMI 1 /* ; */
> #define PLUS 2 /* + */
>
> (...)
>
>I've translated this as
>
> (defconstant EOI 0 "End of input")
> (defconstant SEMI 1 ";")
> (defconstant PLUS 2 "+")
>
> (...)
>
>
>My question is, what's the prettiest way to enumerate constants like
>that?
Do you even need the defs? Since this is Lisp, the parser can just work with
symbols such as 'eoi or :eoi.
If you process the returned symbols with ecase, you'll get an error at
runtime.
Mind you, if you really want enumeration you can create a macro that will
work like enum.
kenny
clinisys
* Tim Daly, Jr.
| I'm going through Holub's book on compilers, and working out the code in
| lisp. Listing 1.1 starts out
I am not familiar with the book, but the "usual" way to return tokens
from the tokenizer, which I presume this is all about, is to fake dynamic
types pretty badly. E.g., your tokenizer would return (the integer) SEMI
and possibly some other value or write something into a pointer you
passed the tokenizer. The caller would dispatch upon the "type" of the
returned value to do something interesting with the token.
In Common Lisp, we have real dynamic types and you may return a real
object from the tokenizer. Normally, you would return an instance of any
of the token classes. In the case of trivial things like symbols, return
the symbol. That is, return the symbol for + and ; and whatever else
your tokenizer has produced. Call `intern� on the string you collect
from the input source in the tokenization phase in the appropriate
package. (If your vocabulary of symbols is restricted, you may want to
use `find-symbol� and signal or handle a syntax error at this point.)
Note that you are reinventing some of the fundamentals of Common Lisp in
this part of your project. Common Lisp already has the function `read�
that tokenizes and returns Common Lisp objects. You may want to study
how it works before you try to do something like it. Lots of data types
are available in Common Lisp that should be usable directly, such as
symbol names, integers, floating-point numbers, etc. Much of the work
you are about to do, if my guess about the purpose of your question is
correct, will be to build the lexer/tokenizer/reader functions for your
new language. If you really want to do this in Common Lisp instead of C,
you should investigate the higher-level purpose of the C code. You may
be very surprised at how much smaller the Common Lisp code is compared to
the C code.
Somebody should have written a book on compiler design in Common Lisp.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> * Tim Daly, Jr.
> | I'm going through Holub's book on compilers, and working out the code in
> | lisp. Listing 1.1 starts out
>
> I am not familiar with the book, but the "usual" way to return tokens
> from the tokenizer, which I presume this is all about, is to fake dynamic
> types pretty badly. E.g., your tokenizer would return (the integer) SEMI
> and possibly some other value or write something into a pointer you
> passed the tokenizer. The caller would dispatch upon the "type" of the
> returned value to do something interesting with the token.
>
> In Common Lisp, we have real dynamic types and you may return a real
> object from the tokenizer. Normally, you would return an instance of any
> of the token classes. In the case of trivial things like symbols, return
> the symbol. That is, return the symbol for + and ; and whatever else
> your tokenizer has produced. Call `intern� on the string you collect
> from the input source in the tokenization phase in the appropriate
> package. (If your vocabulary of symbols is restricted, you may want to
> use `find-symbol� and signal or handle a syntax error at this point.)
>
> Note that you are reinventing some of the fundamentals of Common Lisp in
> this part of your project. Common Lisp already has the function `read�
> that tokenizes and returns Common Lisp objects. You may want to study
> how it works before you try to do something like it. Lots of data types
> are available in Common Lisp that should be usable directly, such as
> symbol names, integers, floating-point numbers, etc. Much of the work
> you are about to do, if my guess about the purpose of your question is
> correct, will be to build the lexer/tokenizer/reader functions for your
> new language. If you really want to do this in Common Lisp instead of C,
> you should investigate the higher-level purpose of the C code. You may
> be very surprised at how much smaller the Common Lisp code is compared to
> the C code.
>
> Somebody should have written a book on compiler design in Common
> Lisp.
Alas, it would be too short (as you point out, Common-Lisp tends to be
concise especially at this task). American textbook authors are paid
by the pound and such a booklet wouldn't be of interest. ;-)
Kidding aside, Norvig's _Principals of Artificial Intelligence_ (PAIP)
has a couple of nice chapters on this subject. Even if you are not
particularly interested in AI, I cannot recommend this book highly
enough. It gives many nice examples of Lisp in action.
Instead of using constants, I would suggest using the symbols
themselves with properties hanging off of them (this is how, e.g.,
emacs keeps track of lisp tokens for its lisp indenting mode, also
PAIP uses this technique in its language processing section). Another
way might be to use a (eq) hash-table with the symbol/token as a
lookup key. I haven't seen the latter approach in any example, so it
may be a false path, and I would be interested if someone with more
experience than I would comment on its feasibility.
--
Johan KULLSTAM <··········@attbi.com> sysengr
Johan Kullstam <··········@attbi.com> writes:
> Erik Naggum <····@naggum.no> writes:
>
> > Somebody should have written a book on compiler design in Common
> > Lisp.
>
> Alas, it would be too short (as you point out, Common-Lisp tends to be
> concise especially at this task). American textbook authors are paid
> by the pound and such a booklet wouldn't be of interest. ;-)
That, or they could actually write a good compilers book! As opposed
to they way things are now, where you pretty much have to learn from
papers. It's not that I have anything against papers, but it's not
the greatest way to learn a new subject.
> Instead of using constants, I would suggest using the symbols
> themselves with properties hanging off of them (this is how, e.g.,
> emacs keeps track of lisp tokens for its lisp indenting mode, also
> PAIP uses this technique in its language processing section). Another
> way might be to use a (eq) hash-table with the symbol/token as a
> lookup key. I haven't seen the latter approach in any example, so it
> may be a false path, and I would be interested if someone with more
> experience than I would comment on its feasibility.
The hash-table method always works, but it's messier. If you just
want one global namespace for the meanings of the symbols' properties,
I recommend using the symbols' plists. Using hash tables forces you
to deal with the reified environment. Of course, if you want to be
able to capture this environment, then you want it reified, and using
a hash-table is the way to go. Well, hash-tables or alists, depending
on whether you want to be able to do things like
(let ((*foo-environment* (acons bar-sym bar-val *foo-environment)))
...)
easily or not.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> That, or they could actually write a good compilers book! As opposed
> to they way things are now, where you pretty much have to learn from
> papers. It's not that I have anything against papers, but it's not
> the greatest way to learn a new subject.
Could you recommend any papers?
-Tim
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Johan Kullstam <··········@attbi.com> writes:
...
> Kidding aside, Norvig's _Principals of Artificial Intelligence_ (PAIP)
> has a couple of nice chapters on this subject. Even if you are not
> particularly interested in AI, I cannot recommend this book highly
> enough. It gives many nice examples of Lisp in action.
...
Amazon does not list that book. Close matches are:
Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp
by Peter Norvig, ISBN: 1558601910; (January 1992)
Principles of Artificial Intelligence
by Nils J. Nilsson ,ISBN: 0934613109; Reprint edition (June 1986)
I guess you are referring to the first one, at least I think that is
the one that goes by the name PAIP.
--
H�kon Alstadheim, hjemmepappa.
······@online.no (H�kon Alstadheim) writes:
> Johan Kullstam <··········@attbi.com> writes:
>
> ...
> > Kidding aside, Norvig's _Principals of Artificial Intelligence_ (PAIP)
> > has a couple of nice chapters on this subject. Even if you are not
> > particularly interested in AI, I cannot recommend this book highly
> > enough. It gives many nice examples of Lisp in action.
> ...
>
> Amazon does not list that book. Close matches are:
>
> Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp
> by Peter Norvig, ISBN: 1558601910; (January 1992)
>
>
> Principles of Artificial Intelligence
> by Nils J. Nilsson ,ISBN: 0934613109; Reprint edition (June 1986)
>
> I guess you are referring to the first one, at least I think that is
> the one that goes by the name PAIP.
Ah yes, my bad. Not only did i misspell "principles", but it should
have been paradigms. Thanks for the correction. _Paradigms of
Artificial Intelligence Programming_ it is, then.
--
Johan KULLSTAM
Erik Naggum <····@naggum.no> writes:
> * Tim Daly, Jr.
> | I'm going through Holub's book on compilers, and working out the code in
> | lisp. Listing 1.1 starts out
>
> I am not familiar with the book, but the "usual" way to return tokens
> from the tokenizer, which I presume this is all about, is to fake dynamic
> types pretty badly. E.g., your tokenizer would return (the integer) SEMI
Good point. I didn't look at the tokens as a form of typing, but I
guess it's a good chance to take advantage of the CL type system.
*snip*
> Note that you are reinventing some of the fundamentals of Common Lisp in
> this part of your project. Common Lisp already has the function `read�
Yes, I know. But I'm not really doing this because I need a parser
right now; I'm just trying to absorb the material in the book. I
don't want to use READ for the same reason that I wouldn't want to
just use SORT if I were studying Knuth's "Sorting and Searching".
> that tokenizes and returns Common Lisp objects. You may want to study
> how it works before you try to do something like it. Lots of data types
Good idea. That would be a good place to see the 'lispy' way of doing
lexing.
*snip*
> Somebody should have written a book on compiler design in Common Lisp.
Amen, Brother Maynard.
-Tim
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----