Hello I'm learning autolisp for cad but thought
maybe this group could help also,
what does the * do in this routine?
(if (not *last_num*)(setq *last_num* 1))
Hello!
G <······@NoSpam> wrote:
>Hello I'm learning autolisp for cad but thought
>maybe this group could help also,
>what does the * do in this routine?
>(if (not *last_num*)(setq *last_num* 1))
Nothing special. It's just part of the variable named with a symbol
whose name is "*last_num*" (maybe in fact "*LAST_NUM*", if autolisp
is similar enough to Common Lisp).
Kind regards,
Hannah.
"G" <······@NoSpam> writes:
> Hello I'm learning autolisp for cad but thought
> maybe this group could help also,
> what does the * do in this routine?
> (if (not *last_num*)(setq *last_num* 1))
Nothing. That is, in lisp, you can use much more characters in
identifiers than in most other languages. Most special characters are
allowed. You can even start identifiers with digits.
To see how it's "parsed", you can write a little function:
;; In Common Lisp. You may have to edit it a little to make it run in autocad.
(defun print-parse-tree (s-expression &optional (level 0))
(if (atom s-expression)
(format t "~VA~A: ~S~%" (* level 3) ""
(type-of s-expression) s-expression)
(progn
(format t "~VALIST:~%" (* level 3) "")
(dolist (sub s-expression)
(print-parse-tree sub (1+ level)))))
s-expression)
> (print-parse-tree '(if (not *last_num*)(setq *last_num* 1)))
LIST:
SYMBOL: IF
LIST:
SYMBOL: NOT
SYMBOL: *LAST_NUM*
LIST:
SYMBOL: SETQ
SYMBOL: *LAST_NUM*
BIT: 1
--> (IF (NOT *LAST_NUM*) (SETQ *LAST_NUM* 1))
So the '*' in your s-expression are all letters in the symbol names.
Now, there's a convention in naming variables:
+name+ is used for constants.
*name* is used for special, dynamic variables (most often, a global variable).
name is used for normal, lexical variables (most often, a local variable).
The use of % and $ may denote some internal, or primitive function,
but this is less often seen.
Note also that we use more easily - than _ in lisp identifiers: *LAST-NUM*
--
"You question the worthiness of my code? I should kill you where you
stand!"
Thanks! I could not find that in the tutorial anywhere.
That seems a little confusing to me having learned
assembler and C in the past. I can see that lisp is
a little different.
On Sun, 02 Oct 2005 15:49:06 +0200, <····@mouse-potato.com> wrote:
>
> That is, in lisp, you can use much more characters in
> identifiers than in most other languages. Most special characters are
> allowed. You can even start identifiers with digits.
Isn't it true that there are not any reserved words in Common Lisp?
--
In Common Lisp quite a few aspects of pathname semantics are left to
the implementation.
GP lisper <········@CloudDancer.com> writes:
>
> On Sun, 02 Oct 2005 15:49:06 +0200, <····@mouse-potato.com> wrote:
> >
> > That is, in lisp, you can use much more characters in
> > identifiers than in most other languages. Most special characters are
> > allowed. You can even start identifiers with digits.
>
> Isn't it true that there are not any reserved words in Common Lisp?
No, that is not true.
External symbols of the COMMON-LISP package are reserved in the sense
that you are limited in what you are allowed to do to them. In
particular, you are not allowed to redefine any built-in functions.
See the HyperLisp spec:
http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
--
Thomas A. Russ, USC/Information Sciences Institute
On 03 Oct 2005 10:17:09 -0700, <···@sevak.isi.edu> wrote:
> GP lisper <········@CloudDancer.com> writes:
>> On Sun, 02 Oct 2005 15:49:06 +0200, <····@mouse-potato.com> wrote:
>> >
>> > That is, in lisp, you can use much more characters in
>> > identifiers than in most other languages. Most special characters are
>> > allowed. You can even start identifiers with digits.
>>
>> Isn't it true that there are not any reserved words in Common Lisp?
>
> No, that is not true.
> External symbols of the COMMON-LISP package are reserved in the sense
> that you are limited in what you are allowed to do to them. In
> particular, you are not allowed to redefine any built-in functions.
>
> See the HyperLisp spec:
>
> http://www.lispworks.com/documentation/HyperSpec/Body/11_abab.htm
And
http://www.lispworks.com/documentation/HyperSpec/Body/01_i.htm
I see that the mathematics functions "+ acos *" etc are included in
the COMMON-LISP package. I was speculating a few months ago about
replacing the lisp floating point calculations with the IBM decimal
number package in such a fashion that any existing source code that
contained the 4 basic functions, + - * / would then operate with
decimal numbers. It was suggested that 'shadow' and a lot of effort
might get what I had in mind.
But now I'm not so sure, it seems that the inclusion of these math
functions into the COMMON-LISP package is probably because of their
usage within the other functions of the COMMON-LISP package. At best
then I could only reuse existing source code after some modification
(mapping + to dec-num-plus, etc), and then only within my
decimal-number package. The alternative is a non-hyperspec
~semi-common lisp with IEEE floating point ripped out, decNumbers
inserted and a careful reworking of "~COMMON-LISP package" within that
new lisp.
[Why would one need this? Floating point errors accumulate, large
numerical simulations end up with such silly results as Mercury
crashing into Venus in some future era. There is a limit to how far a
floating point simulation can be pushed, or in another sense a limit
in how many interacting calculations can be semi-reliably computed.
People that have switched from a single-precision program to a
double-precision program are familiar with these effects. Nowdays, it
is easier to run into this floating point limitation. The future
choices seem to be quad-precision or switching to decimal numbers.]
Thanks for the pointers to "reserved symbols".
--
In Common Lisp quite a few aspects of pathname semantics are left to
the implementation.
GP lisper <········@CloudDancer.com> writes:
> I see that the mathematics functions "+ acos *" etc are included in
> the COMMON-LISP package. I was speculating a few months ago about
> replacing the lisp floating point calculations with the IBM decimal
> number package in such a fashion that any existing source code that
> contained the 4 basic functions, + - * / would then operate with
> decimal numbers. It was suggested that 'shadow' and a lot of effort
> might get what I had in mind.
>
> But now I'm not so sure, it seems that the inclusion of these math
> functions into the COMMON-LISP package is probably because of their
> usage within the other functions of the COMMON-LISP package. At best
> then I could only reuse existing source code after some modification
> (mapping + to dec-num-plus, etc), and then only within my
> decimal-number package. The alternative is a non-hyperspec
> ~semi-common lisp with IEEE floating point ripped out, decNumbers
> inserted and a careful reworking of "~COMMON-LISP package" within that
> new lisp.
But IIRC the only functions that use floating-point numbers that
aren't really related to floating-point operations is MAKE-HASH-TABLE
(rehash-threshold) and FORMAT (and PRINT, PRIN1, PRINC, WRITE).
For the printing, you could give a PRINT-OBJECT method on your
DECIMAL-POINT type, so there remains only MAKE-HAS-TABLE. That's the
only place where you'd need to convert a decimal-point number to a
floating-point number.
AFAKI, all the rest of CL is basically immune to floating-point numbers.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
GP lisper <········@CloudDancer.com> writes:
> On Sun, 02 Oct 2005 15:49:06 +0200, <····@mouse-potato.com> wrote:
>>
>> That is, in lisp, you can use much more characters in
>> identifiers than in most other languages. Most special characters are
>> allowed. You can even start identifiers with digits.
>
> Isn't it true that there are not any reserved words in Common Lisp?
There are no words in Common Lisp.
There are symbols, and symbols "belong" to some packages.
The function binding of symbols that are in the package COMMON-LISP
cannot be modified. And neither can the value binding of constant
symbols in COMMON-LISP.
But otherwise, they can be used as lexical (local) names, and you can
use symbols with same name in other packages as you want.
--
"By filing this bug report you have challenged the honor of my
family. Prepare to die!"
GP lisper wrote:
> On Sun, 02 Oct 2005 15:49:06 +0200, <····@mouse-potato.com> wrote:
>
>>That is, in lisp, you can use much more characters in
>>identifiers than in most other languages. Most special characters are
>>allowed. You can even start identifiers with digits.
>
> Isn't it true that there are not any reserved words in Common Lisp?
You are probably thinking of Scheme.
--
Jens Axel S�gaard
GP lisper wrote:
> On Sun, 02 Oct 2005 15:49:06 +0200, <····@mouse-potato.com> wrote:
>
>>That is, in lisp, you can use much more characters in
>>identifiers than in most other languages. Most special characters are
>>allowed. You can even start identifiers with digits.
>
>
> Isn't it true that there are not any reserved words in Common Lisp?
>
I suppose there are wilfully perverse ways to twist the
package system to use alternative definitions of standard
common lisp functions, but without some fairly extreme
manipulations, you're not allowed to redefine Common
Lisp's standard functions nor use their names to refer
to something else.
You may be thinking of Scheme, another Lisp dialect where
it is literally true that there are no reserved words.
(although if you redefine "lambda" or something, I think
you're probably hosed anyway...).
Bear
Ray Dillinger wrote:
> GP lisper wrote:
>
>> On Sun, 02 Oct 2005 15:49:06 +0200, <····@mouse-potato.com> wrote:
>>
>>> That is, in lisp, you can use much more characters in
>>> identifiers than in most other languages. Most special characters are
>>> allowed. You can even start identifiers with digits.
>>
>> Isn't it true that there are not any reserved words in Common Lisp?
>
> I suppose there are wilfully perverse ways to twist the
> package system to use alternative definitions of standard
> common lisp functions, but without some fairly extreme
> manipulations, you're not allowed to redefine Common
> Lisp's standard functions nor use their names to refer
> to something else.
Shadowing symbols is neither "wilfully perverse" nor an "extreme
manipulation". What's hard to understand about the package system is
_when_ symbols that you use in some source code are interned in a
package (i.e., at read time, when the ASCII text is turned into a series
of s-expressions). As soon as you get that, the package system is
relatively easy to understand, and the package operators start to make
sense.
> You may be thinking of Scheme, another Lisp dialect where
> it is literally true that there are no reserved words.
> (although if you redefine "lambda" or something, I think
> you're probably hosed anyway...).
Here is how you redefine 'lambda in Common Lisp:
(defpackage :my-package
(:use :common-lisp)
(:shadow :lambda)
(:export :lambda))
(in-package :my-package)
(defmacro lambda (formals &body)
(etypecase formals
(symbol `(cl:lambda (&rest ,formals) ,@body))
(cons (loop for tail = formals then (cdr tail)
if (consp tail)
collect (car tail) into args
else if (atom tail)
return `(cl:lambda (,@args
,@(when tail
`(&rest ,tail)))
,@body)))))
Note how cl:lambda is used to refer to the original 'lambda operator of
Common Lisp. BTW, this definition gives you a Scheme-like lambda.
I don't think you're "hosed" here.
(I am also sure that some Scheme implementations allow you to express
similar changes to the language.)
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Ray Dillinger <····@sonic.net> writes:
> You may be thinking of Scheme, another Lisp dialect where
> it is literally true that there are no reserved words.
> (although if you redefine "lambda" or something, I think
> you're probably hosed anyway...).
There are reserved words in Scheme:
<variable> -> <any <identifier> that isn't also a <syntactic keyword>>
<syntactic keyword> -> <expression keyword>
| else | => | define
| unquote | unquote-splicing
<expression keyword> -> quote | lambda | if
| set! | begin | cond | and | or | case
| let | let* | letrec | do | delay
| quasiquote
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
+---------------
| Ray Dillinger <····@sonic.net> writes:
| > You may be thinking of Scheme, another Lisp dialect where
| > it is literally true that there are no reserved words.
|
| There are reserved words in Scheme:
+---------------
Not really:
> (let ((if 37)
(else 53)
(lambda 47)
(begin 12))
(+ if else lambda begin))
149
> (let ((lambda +)
(if /))
(lambda (if 120 5 6) 47))
51
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > Not really:
| > > (let ((if 37)
| > (else 53)
| > (lambda 47)
| > (begin 12))
| > (+ if else lambda begin))
| > 149
|
| This is invalid according to R5RS.
+---------------
Hmmm... Perhaps this is a MzScheme extension, then?
[That's what I was using in the above.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> ····@rpw3.org (Rob Warnock) writes:
>
>> Not really:
>>
>> > (let ((if 37)
>> (else 53)
>> (lambda 47)
>> (begin 12))
>> (+ if else lambda begin))
>> 149
>
> This is invalid according to R5RS.
Only if you are giving too much weight to section 7.1.3
and ignoring sections 4.3 and 5.3 and the end notes.
It gives these rules:
<derived expression> ->
.... most omitted ....
| (let (<binding spec>*) <body>)
<binding spec> -> (<variable> <expression>)
and section 7.1.1 has these rules:
<variable> -> <any <identifier> that isn't also a syntactic keyword>
<syntactic keyword> -> else | => | define | unquote | unquote-splicing
But section 4.3 states:
``The syntactic keyword of a macro may shadow variable
bindings, and local variable bindings may shadow keyword
bindings.''
Section 4.3.1 shows a specific intent to not reserve identifiers:
((letrec-syntax
((my-or (syntax-rules ()
((my-or) #f)
((my-or e) e)
((my-or e1 e2 ...)
(let ((temp e1))
(if temp
temp
(my-or e2 ...)))))))
(let ((x #f)
(y 7)
(temp 8)
(let odd?)
(if even?))
(my-or x
(let temp)
(if y)
y))) ==> 7
Section 4.3.2 also shows that it was not the intent to reserve
these five specific identifiers when they give this example:
(let ((=> #f))
(cond (#t => 'ok)))
Section 5.3 includes the restriction that
``it is an error for a definition or syntax definition to shadow a
syntactic keyword whose meaning is needed to determine whether
some form in the group of forms that contains the shadowing
definition is in fact a definition, or, for internal definitions,
is needed to determine the boundary between the group and the
expressions that follow the group.''
Finally, in the Notes at the end, there is this statement:
``There are no reserved identifiers.''
Joe Marshall <·········@alum.mit.edu> writes:
> Only if you are giving too much weight to section 7.1.3
> and ignoring sections 4.3 and 5.3 and the end notes.
Ok, so it's inconsistent and should be fixed.
> <syntactic keyword> -> else | => | define | unquote | unquote-splicing
<syntactic keyword> includes also <expression keyword>.
BTW, I don't see where syntactic keywords are treated differently
from expression keywords.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Rob Warnock wrote:
> Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> wrote:
> +---------------
> | Ray Dillinger <····@sonic.net> writes:
> | > You may be thinking of Scheme, another Lisp dialect where
> | > it is literally true that there are no reserved words.
> |
> | There are reserved words in Scheme:
> +---------------
>
> Not really:
>
> > (let ((if 37)
> (else 53)
> (lambda 47)
> (begin 12))
> (+ if else lambda begin))
> 149
> > (let ((lambda +)
> (if /))
> (lambda (if 120 5 6) 47))
> 51
> >
Scheme48:
> (let ((if 37)
(else 53)
(lambda 47)
(begin 12))
(+ if else lambda begin))
149
> (let ((lambda +)
(if /))
(lambda (if 120 5 6) 47))
Error: wrong number of arguments
('#{Procedure 90 /} 120 5 6)
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
Rob Warnock wrote:
> This looks like a limitation of Scheme48. Is (/ 120 5 6) also rejected?
>
> In R5RS 6.2.5 "Numerical operations", "/" is defined to accept more than
> two arguments, and contains these examples [and R4RS concurs]:
>
> (/ 3 4 5) ===> 3/20
> (/ 3) ===> 1/3
> (/ 120 5 6)
Warning: invalid arguments
(/ 120 5 6)
(procedure wants: (:number &opt :number))
(arguments are: (:exact-integer :exact-integer :exact-integer))
(&warning)
Error: wrong number of arguments
('#{Procedure 90 /} 120 5 6)
I sent them a note about it...
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
"Ray Dillinger" <····@sonic.net> wrote in message
························@typhoon.sonic.net...
> I suppose there are wilfully perverse ways to twist the
> package system to use alternative definitions of standard
> common lisp functions, but without some fairly extreme
> manipulations, you're not allowed to redefine Common
> Lisp's standard functions nor use their names to refer
> to something else.
Someone else complained about you "perverse" characterization in the first
half of your sentence, I would like to complian about the second half! You
may surely and easily and unambiguoulsy use the names[sic] (should be
symbols) of common lisp standard functions to refer to other things, in fact
any other thing except a function.
(defun bar (list)
(list (make-instance 'list list)))
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> (defun bar (list)
> (list (make-instance 'list list)))
(defmethod make-instance ((class (eql 'list)) &key list)
(copy-list list))
(defun bar (list)
(block list
(catch list
(let ((list (make-instance 'list :list list)))
(if list
(return-from list (list 'returned list))
(throw list (list 'signaled list)))))))
(mapcar (function bar) '( () (list list list) ))
--> ((SIGNALED NIL) (RETURNED (LIST LIST LIST)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
GP lisper sows confusion
> Isn't it true that there are not any reserved words in Common Lisp?
In Common Lisp the names of functions and variables are
symbols, not strings of characters. If there were to be
reserved things in Common Lisp they would be reserved
symbols, not reserved words.
CL does have reserved symbols, see 11.1.2.1.2 Constraints on
the COMMON-LISP Package for Conforming Programs.
Symbols do have names, and unlike functions and variables
the names of symbol are strings of characters, but these
strings do not have to be unique. This interaction
CL-USER(14): (find-all-symbols "X")
(INSPECT::X X TOP-LEVEL::X COMPILER::X EXCL::X SYSTEM::X
EXCL.SCM::X FOREIGN-FUNCTIONS::X :X)
CL-USER(15): (length *)
9
is showing me nine symbols, all called X. So it is hard to
see how there could be reserved words, as opposed to
reserved symbols.
On the other hand CL avoids a boot strapping problem by
not using symbols as the names of packages. Package names
are strings of characters, though you will often see a
string, such as "FOO" designated in various ways, such as
'foo or :foo or #:foo
(mapcar #'string '(foo :foo #:foo)) => ("FOO" "FOO" "FOO")
"11.1.2 Standardized Packages" specifies three standardized
packages.
Name Nicknames
COMMON-LISP CL
COMMON-LISP-USER CL-USER
KEYWORD none
So my inner pedant is screaming: CL has five reserved words
"COMMON-LISP", "COMMON-LISP-USER", "CL", "CL-USER", "KEYWORD".
Alan Crowe
Edinburgh
Scotland
Alan Crowe wrote:
> So my inner pedant is screaming: CL has five reserved words
> "COMMON-LISP", "COMMON-LISP-USER", "CL", "CL-USER", "KEYWORD".
I wonder if you could rename those packages. ;)
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza <··@p-cos.net> writes:
> Alan Crowe wrote:
>
>> So my inner pedant is screaming: CL has five reserved words
>> "COMMON-LISP", "COMMON-LISP-USER", "CL", "CL-USER", "KEYWORD".
>
> I wonder if you could rename those packages. ;)
I expect that you could get away with changing the nicknames "CL" and
"CL-USER", you could *probably* rename "COMMON-LISP" and
"COMMON-LISP-USER", but I'd suspect that loading would stop working if
you did unless you provided a replacement.
I don't think you'd be able to easily rename the keyword package.
Pascal Costanza <··@p-cos.net> writes:
> Alan Crowe wrote:
>> So my inner pedant is screaming: CL has five reserved words
>> "COMMON-LISP", "COMMON-LISP-USER", "CL", "CL-USER", "KEYWORD".
> I wonder if you could rename those packages. ;)
I wonder, if you rename the KEYWORD package and create a new package
named KEYWORD, which package will keywords be interned in? And, if
you intern symbols in the new package, will they receive the special
keyword-interning treatment?