When I load it into LispWorks I get a "syntactic warning for the form (setq x (..." stating "X assumed special". The functions works fine (however ugly it may be).
(2) I would like to write a VERY SIMPLE macro v that is expanded to (subseq g 3). g is a list consisting of 6 elements. I found some fancy complicated examples in the books but I cannot do this simple one.
If x is meant to be used locally, LET should be used in lieu of SETQ.
(let ((x ...)) [body] )
X will be accessible in body.
> (2) > I would like to write a VERY SIMPLE macro v that is expanded to > (subseq g 3). > g is a list consisting of 6 elements. I found some fancy complicated > examples in the books but I cannot do this simple one.
Robert Monfera <monf...@fisec.com> schrieb in im > > (2)
> > I would like to write a VERY SIMPLE macro v that is expanded to > > (subseq g 3). > > g is a list consisting of 6 elements. I found some fancy complicated > > examples in the books but I cannot do this simple one.
Such a macro would make my code much more readable. But I did not express exactly what I was going to do: I wanted to write a macro WITHOUT ANY PARAMETERS like in C
> Such a macro would make my code much more readable. But I did not express > exactly what I was going to do: I wanted to write a macro WITHOUT ANY > PARAMETERS like in C
> is what you're looking for, but what is g, what should it be bound to?
> > Such a macro would make my code much more readable. But I did not express > > exactly what I was going to do: I wanted to write a macro WITHOUT ANY > > PARAMETERS like in C
* Janos Blazi wrote: > Such a macro would make my code much more readable. But I did not express > exactly what I was going to do: I wanted to write a macro WITHOUT ANY > PARAMETERS like in C > #define v (subseq g 3) > Is this possible?
* Janos Blazi wrote: > Thx, this was what> My only remaining problem is that these macros are global. Can I make them > local in some way, like in C > #define v ... > <body> > #undefine v
> > > I would like to write a VERY SIMPLE macro v that is expanded to > > > (subseq g 3).
> > What is the benefit though?
> Such a macro would make my code much more readable. But I did not express > exactly what I was going to do: I wanted to write a macro WITHOUT ANY > PARAMETERS like in C
> #define v (subseq g 3)
> Is this possible?
You can, but such a macro would not normally be considered by expert Lisp programmers to make your code more readable - rather the opposite.
* "Janos Blazi" <jbl...@netsurf.de> | Such a macro would make my code much more readable. But I did not express | exactly what I was going to do: I wanted to write a macro WITHOUT ANY | PARAMETERS like in C | | #define v (subseq g 3) | | Is this possible?
yes, using symbol macros. (it not smart to use them this way.)
* "Janos Blazi" <jbl...@netsurf.de> | Such a macro would make my code much more readable. But I did not express | exactly what I was going to do: I wanted to write a macro WITHOUT ANY | PARAMETERS like in C | | #define v (subseq g 3) | | Is this possible?
yes, using symbol macros. (it not smart to use them this way.)
Well, I have written a small library of routines that solve very simple geometry problems, like calculating the intersection of hyperplanes in 3-space and the like. In this library a straight line in 3-space is represented by a list g consisting of 6 elements. Is g such a list then the line has the parametrization t -> (subseq g 0 3) + t*(subseq g 3) that is the first three elements are the coordinates of a point on the straight line and the second three elements are the direction.
Now it is very comfortable to think of the straight line as having the paramtrization t->a-vec+t*v-vec and this is why I would like to have those macros. After all, it is much better to write (cross-prod v w) instead of (cross-prod (subseq g 3) (subseq h 3).
BTW: THE CODE IS WORKING FINE AND IT WOULD HAVE TAKEN MORE TIME TO IMPLEMENT RATIONAL ARITHMETIC IN C++ (THAT IS VERY IMPORTANT!) THAN WRITING THE WHOLE 500 LINES IN LISP, and then additionally as speed is not an issue it is wonderful to work with the interpreter. It is like working in Maple V only even more comfortable. My geometric objects like striaght lines and points and planes are very naturally represented by the lists in LISP and I decided not to use CLOS at all.
Janos Blazi
H. Tunc Simsek <sim...@EECS.Berkeley.Edu> schrieb in im Newsbeitrag: 384A2BE6.F3535...@EECS.Berkeley.Edu...
> is what you're looking for, but what is g, what should it be bound to?
> > Such a macro would make my code much more readable. But I did not express > > exactly what I was going to do: I wanted to write a macro WITHOUT ANY > > PARAMETERS like in C
In article <amnesia-82h02q/INN-2.2.1/aroma...@broadway.news.is-europe.net>,
Janos Blazi <jbl...@netsurf.de> wrote: >My geometric objects like striaght lines and points and planes are very >naturally represented by the lists in LISP and I decided not to use CLOS at >all.
Why not use DEFSTRUCT, though?
In any case, IMHO your use of global variables that are hard-coded into macro expansions is very poor design. If you want to avoid the overhead of argument passing to functions, try declaring your functions INLINE.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
"Janos Blazi" <jbl...@netsurf.de> writes: > Well, I have written a small library of routines that solve very simple > geometry problems, like calculating the intersection of hyperplanes in > 3-space and the like. In this library a straight line in 3-space is > represented by a list g consisting of 6 elements. > Is g such a list then the line has the parametrization > t -> (subseq g 0 3) + t*(subseq g 3) > that is the first three elements are the coordinates of a point on the > straight line and the second three elements are the direction.
> Now it is very comfortable to think of the straight line as having the > paramtrization > t->a-vec+t*v-vec > and this is why I would like to have those macros. After all, it is much > better to write (cross-prod v w) instead of > (cross-prod (subseq g 3) (subseq h 3).
> BTW: THE CODE IS WORKING FINE AND IT WOULD HAVE TAKEN MORE TIME TO IMPLEMENT > RATIONAL ARITHMETIC IN C++ (THAT IS VERY IMPORTANT!) THAN WRITING THE WHOLE > 500 LINES IN LISP, and then additionally as speed is not an issue it is > wonderful to work with the interpreter. It is like working in Maple V only > even more comfortable. > My geometric objects like striaght lines and points and planes are very > naturally represented by the lists in LISP and I decided not to use CLOS at > all.
It would seem to me that your internal representation could be improved (speed wise) by using structures or displaced arrays.
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
Barry Margolin <bar...@bbnplanet.com> writes: > In any case, IMHO your use of global variables that are hard-coded into > macro expansions is very poor design. If you want to avoid the overhead of > argument passing to functions, try declaring your functions INLINE.
That's good advice, but some implementations pretty much ignore INLINE declarations.
Jeff Dalton <j...@todday.aiai.ed.ac.uk> writes: > Barry Margolin <bar...@bbnplanet.com> writes:
> > In any case, IMHO your use of global variables that are hard-coded into > > macro expansions is very poor design. If you want to avoid the overhead of > > argument passing to functions, try declaring your functions INLINE.
> That's good advice, but some implementations pretty much ignore > INLINE declarations.
> What Common Lisps actually inline things?
CMU CL does inline user defined functions.
Regs, Pierre.
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Jeff Dalton <j...@todday.aiai.ed.ac.uk> wrote: >Barry Margolin <bar...@bbnplanet.com> writes:
>> In any case, IMHO your use of global variables that are hard-coded into >> macro expansions is very poor design. If you want to avoid the overhead of >> argument passing to functions, try declaring your functions INLINE.
>That's good advice, but some implementations pretty much ignore >INLINE declarations.
>What Common Lisps actually inline things?
CMUCL seems to.
-- Kenneth P. Turvey <kt-...@SprocketShop.com> -------------------------------------------- We must all hang together, or most assuredly, we will all hang separately. -- Benjamin Franklin
