Numerous examples in SICP use constructs such as
(define make-card cons)
(define card-rank car)
(define card-suit cdr)
for the sake of data abstraction.
Obviously they could have chosen
(define (make-card r s)
(cons r s))
(define (card-rank c)
(car c))
(define (card-suit c)
(cdr c))
Which would port alomost instantly to CL.
It turns out that in scheme, and due to its Lisp1-ness,
the former aliasing is "toll-free" as far as I understand.
Would the following (which happens to work with LispWorks)
be the right way to do that aliasing in CL?
CL-USER 1 > (setf (symbol-function' make-card) #'cons)
#<Function ((compiler::def-nil-function cons) . cons) 204AD802>
CL-USER 2 > #'cons
#<Function ((compiler::def-nil-function cons) . cons) 204AD802>
CL-USER 3 > #'make-card
#<Function ((compiler::def-nil-function cons) . cons) 204AD802>
CL-USER 4 > (make-card 'h 1)
(h . 1)
My only worry is the fact that I create the alias on the fly
without any previous definition. What would be a better
alternative?
Many Thanks
--
JFB
verec <·····@mac.com> writes:
> On 2008-08-16 22:54:53 +0100, verec <·····@mac.com> said:
> Macro-ising it gives:
>
> (defmacro make-function-alias (alias org)
> `(progn
> (setf ,alias nil) ;; <<========== poor man's make-bound ...
> (setf (symbol-function (quote ,alias)) (function ,org))))
Your macro has undefined behavior.
You can just write:
(defmacro make-function-alias (alias org)
`(setf (symbol-function (quote ,alias)) (function ,org)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
On 2008-08-17 00:45:39 +0100, ···@informatimago.com (Pascal J.
Bourguignon) said:
> verec <·····@mac.com> writes:
>> On 2008-08-16 22:54:53 +0100, verec <·····@mac.com> said:
>> Macro-ising it gives:
>>
>> (defmacro make-function-alias (alias org)
>> `(progn
>> (setf ,alias nil) ;; <<========== poor man's make-bound ...
>> (setf (symbol-function (quote ,alias)) (function ,org))))
>
> Your macro has undefined behavior.
>
> You can just write:
>
> (defmacro make-function-alias (alias org)
> `(setf (symbol-function (quote ,alias)) (function ,org)))
Yep, Thanks, You're right. (Well, I don't know that you are right,
I do know that I tried your example and that it works -- just
nitpicking :-)
I was struck by the assynmetry of the existence of MAKUNBOUND
on one hand, and the non existence of its counterpart, until I
realized/remembered that symbols are brought to existence by
the reader ...
So I guess that the closest I will ever get to MAKUNBOUND's
counterpart is INTERN:
(defun test ()
(makunbound (intern "MYSMBOL")))
which is just an expansive no-op, right?
Many Thanks
--
JFB
On Aug 17, 6:11 am, verec <·····@mac.com> wrote:
> So I guess that the closest I will ever get to MAKUNBOUND's
> counterpart is INTERN:
>
> (defun test ()
> (makunbound (intern "MYSMBOL")))
>
> which is just an expansive no-op, right?
Not exactly; you intern MYSYMBOL in the current package. The
MAKUNBOUND call is a no-op because the symbol isn't bound to a value.
You might be also looking for FMAKUNBOUND (which does the same thing
but for the function value) and UNINTERN (which removes the symbol
from the package).
On Sat, 2008-08-16 at 22:54 +0100, verec wrote:
> Numerous examples in SICP use constructs such as
>
> (define make-card cons)
> (define card-rank car)
> (define card-suit cdr)
>
> for the sake of data abstraction.
>
> Obviously they could have chosen
>
> (define (make-card r s)
> (cons r s))
> (define (card-rank c)
> (car c))
> (define (card-suit c)
> (cdr c))
>
> Which would port alomost instantly to CL.
>
> It turns out that in scheme, and due to its Lisp1-ness,
> the former aliasing is "toll-free" as far as I understand.
what about:
(declaim (inline make-card))
(defun make-card (r s)
(cons r s))
..?
--
Lars Rune Nøstdal
http://nostdal.org/
AJAX/Comet for Common Lisp @ http://groups.google.com/group/symbolicweb
verec wrote:
> Numerous examples in SICP use constructs such as
>
> (define make-card cons)
> (define card-rank car)
> (define card-suit cdr)
>
> for the sake of data abstraction.
>
> Obviously they could have chosen
>
> (define (make-card r s)
> (cons r s))
> (define (card-rank c)
> (car c))
> (define (card-suit c)
> (cdr c))
>
> Which would port alomost instantly to CL.
>
> It turns out that in scheme, and due to its Lisp1-ness,
> the former aliasing is "toll-free" as far as I understand.
Not quite.
In Common Lisp, there is difference between the following two forms.
(defun make-card (r s)
(cons r s))
(setf (symbol-function 'make-card) #'cons)
The first form has more useful information for a Lisp compiler. For
example, it can perform checks that you use the correct number of
arguments in call sites, and can use optimized calling conventions based
on the kinds of arguments a function receives (no &optional, &key and
&rest parameters in this case, for example).
If you (declaim (inline make-card)) you should not even get the double
call overhead. (On systems where inlining is not supported, you can try
define-compiler-macro for similar effects.)
There is probably a double call overhead, though, if you pass
#'make-card around as a first-class value.
I guess similar optimizations and trade offs are possible in good Scheme
compilers.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> In Common Lisp, there is difference between the following two forms.
>
> (defun make-card (r s)
> (cons r s))
>
> (setf (symbol-function 'make-card) #'cons)
>
> The first form has more useful information for a Lisp compiler. For
> example, it can perform checks that you use the correct number of
> arguments in call sites, and can use optimized calling conventions
> based on the kinds of arguments a function receives (no &optional,
> &key and &rest parameters in this case, for example).
I might be misremembering (and am too busy watching the Olympics to do
any serious research on the matter), but I don't see any a priori
reason that the compiler can't do the same kind of arg checking in the
case of setf of symbol-function that it does in defun. I think many
compilers don't. But there is nothing fundamental in the fact of a
Lisp1 that allows a compiler to do any better with
(define make-card cons)
The exact same issues apply. All of the names needed to do the right
thing are known to the compiler at compile time, so it's just a matter
of what it chooses to record and what it chooses to check for later.
If there is an implementation that doesn't make these things equivalent
(and I suspect there are some--perhaps many), that's just an issue of
the compiler not doing it, not something the standard forbids or
the Lisp2 paradigm doesn't allow.
Now, of course, (setf (symbol-function x) y) won't get that treatment.
But that wasn't what was under discussion. Short of using something
like eval, I don't know how you'd make that work in Scheme.
The notation matters are attributes of the Lisp1/Lisp2 issue, but the
performance behavior of this is not... except that a caller of
make-card compiled separately in CL with no knowledge of what's in the
cell can reliably jump to the function cell contents feeling assured
that it's a function in there whereas making that work in Scheme
involves secretly being a Lisp2 and not telling anyone because if you
really and truly implement a Lisp1 in the obvious way, a separately
compiled module can't just jump to a variable's contents since it
might not contain a function. So the theoretical performance issue is
actually the reverse of what you suggest, Pascal... or so it seems to
me.
Kent M Pitman wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> In Common Lisp, there is difference between the following two forms.
>>
>> (defun make-card (r s)
>> (cons r s))
>>
>> (setf (symbol-function 'make-card) #'cons)
>>
>> The first form has more useful information for a Lisp compiler. For
>> example, it can perform checks that you use the correct number of
>> arguments in call sites, and can use optimized calling conventions
>> based on the kinds of arguments a function receives (no &optional,
>> &key and &rest parameters in this case, for example).
>
> I might be misremembering (and am too busy watching the Olympics to do
> any serious research on the matter), but I don't see any a priori
> reason that the compiler can't do the same kind of arg checking in the
> case of setf of symbol-function that it does in defun. I think many
> compilers don't. But there is nothing fundamental in the fact of a
> Lisp1 that allows a compiler to do any better with
> (define make-card cons)
> The exact same issues apply. All of the names needed to do the right
> thing are known to the compiler at compile time, so it's just a matter
> of what it chooses to record and what it chooses to check for later.
> If there is an implementation that doesn't make these things equivalent
> (and I suspect there are some--perhaps many), that's just an issue of
> the compiler not doing it, not something the standard forbids or
> the Lisp2 paradigm doesn't allow.
I should have stressed more that I was specifically talking about Common
Lisp here, not about Lisp in general.
In general, none of these forms can have special treatment by the
compiler, unless this an explicit agreement between a language
specification and the language users.
The reason is that (a) (setf (symbol-function 'make-card) ...) can, in
general, have arbitrary, Turing-complete expressions as their right-hand
side, and (b) in a highly reflective language such as Lisp, new code can
be loaded at arbitrary times during runtime which change such variables
on the fly which assign unexpected values to such function cells that
the compiler doesn't have a chance to know about in advance. Taken
together, this means that a compiler cannot guarantee good checks of
arguments at invocation sites, but in general just give warnings and
make vague promises wrt the accuracy of such warnings.
The case in Common Lisp, is different though, because Section 3.2.2.3
poses some constraints of what you can and cannot do with (explicit, I
think) function definitions. Without such specification-enforced
constraints, there is not much a compiler can do. [1]
> The notation matters are attributes of the Lisp1/Lisp2 issue, but the
> performance behavior of this is not... except that a caller of
> make-card compiled separately in CL with no knowledge of what's in the
> cell can reliably jump to the function cell contents feeling assured
> that it's a function in there whereas making that work in Scheme
> involves secretly being a Lisp2 and not telling anyone because if you
> really and truly implement a Lisp1 in the obvious way, a separately
> compiled module can't just jump to a variable's contents since it
> might not contain a function. So the theoretical performance issue is
> actually the reverse of what you suggest, Pascal... or so it seems to
> me.
I would expect that a runtime check whether something is a function or
not is a simple test for a bit flag in the addressed memory location,
which should be reasonably fast in modern CPUs. But consider this
definition again:
(defun make-card (r s)
(cons r s))
If you pass #'make-card around as a first-class value and then invoke it
in some arbitrary place that doesn't know about the source of the
function, there will be a call to both #'make-card and, as a
consequence, to #'cons.
However, if you have this definition:
(setf (symbol-function 'make-card) #'cons)
...and then you pass around #'make-card, you will only have the call to
#'cons. I would expect that this has a bigger impact on efficiency.
(Inlining doesn't help here, because #'make-card should also preserve
the object identity of the respective function object.)
Maybe I'm missing some further optimization opportunities here that a
compiler could apply, though... (This kind of speculation about
efficieny is a bit too much guesswork anyway, so I should better stop
doing that... ;)
Pascal
[1] The situation with R6RS Scheme is different, because R6RS has turned
Scheme into a statically typed language wrt variable assignments.
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Kent M Pitman wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> In Common Lisp, there is difference between the following two forms.
>>>
>>> (defun make-card (r s)
>>> (cons r s))
>>>
>>> (setf (symbol-function 'make-card) #'cons)
>>>
>>> The first form has more useful information for a Lisp compiler. For
>>> example, it can perform checks that you use the correct number of
>>> arguments in call sites, and can use optimized calling conventions
>>> based on the kinds of arguments a function receives (no &optional,
>>> &key and &rest parameters in this case, for example).
>> I might be misremembering (and am too busy watching the Olympics to
>> do
>> any serious research on the matter), but I don't see any a priori
>> reason that the compiler can't do the same kind of arg checking in the
>> case of setf of symbol-function that it does in defun. I think many
>> compilers don't. But there is nothing fundamental in the fact of a
>> Lisp1 that allows a compiler to do any better with (define make-card
>> cons)
>> The exact same issues apply. All of the names needed to do the right
>> thing are known to the compiler at compile time, so it's just a matter
>> of what it chooses to record and what it chooses to check for later.
>> If there is an implementation that doesn't make these things
>> equivalent (and I suspect there are some--perhaps many), that's just
>> an issue of
>> the compiler not doing it, not something the standard forbids or the
>> Lisp2 paradigm doesn't allow.
>
> I should have stressed more that I was specifically talking about
> Common Lisp here, not about Lisp in general.
>
> In general, none of these forms can have special treatment by the
> compiler, unless this an explicit agreement between a language
> specification and the language users.
>
> The reason is that (a) (setf (symbol-function 'make-card) ...) can, in
> general, have arbitrary, Turing-complete expressions as their
> right-hand side, and (b) in a highly reflective language such as Lisp,
> new code can be loaded at arbitrary times during runtime which change
> such variables on the fly which assign unexpected values to such
> function cells that the compiler doesn't have a chance to know about
> in advance. Taken together, this means that a compiler cannot
> guarantee good checks of arguments at invocation sites, but in general
> just give warnings and make vague promises wrt the accuracy of such
> warnings.
>
> The case in Common Lisp, is different though, because Section 3.2.2.3
> poses some constraints of what you can and cannot do with (explicit, I
> think) function definitions. Without such specification-enforced
> constraints, there is not much a compiler can do. [1]
>
>> The notation matters are attributes of the Lisp1/Lisp2 issue, but the
>> performance behavior of this is not... except that a caller of
>> make-card compiled separately in CL with no knowledge of what's in the
>> cell can reliably jump to the function cell contents feeling assured
>> that it's a function in there whereas making that work in Scheme
>> involves secretly being a Lisp2 and not telling anyone because if you
>> really and truly implement a Lisp1 in the obvious way, a separately
>> compiled module can't just jump to a variable's contents since it
>> might not contain a function. So the theoretical performance issue is
>> actually the reverse of what you suggest, Pascal... or so it seems to
>> me.
>
> I would expect that a runtime check whether something is a function or
> not is a simple test for a bit flag in the addressed memory location,
> which should be reasonably fast in modern CPUs. But consider this
> definition again:
>
> (defun make-card (r s)
> (cons r s))
>
> If you pass #'make-card around as a first-class value and then invoke
> it in some arbitrary place that doesn't know about the source of the
> function, there will be a call to both #'make-card and, as a
> consequence, to #'cons.
>
> However, if you have this definition:
>
> (setf (symbol-function 'make-card) #'cons)
>
> ...and then you pass around #'make-card, you will only have the call
> to #'cons. I would expect that this has a bigger impact on efficiency.
>
> (Inlining doesn't help here, because #'make-card should also preserve
> the object identity of the respective function object.)
>
>
> Maybe I'm missing some further optimization opportunities here that a
> compiler could apply, though... (This kind of speculation about
> efficieny is a bit too much guesswork anyway, so I should better stop
> doing that... ;)
(progn
(car (cons 1 2)))
(progn
(setf (symbol-function 'kons) (function cons))
(car (kons 1 2)))
Compilers may have a difficulty to open-code the call to cons in the second case.
They may also have a difficulty in replacing (car (kons 1 2)) by 1 ;
they could do it more easily with (car (cons 1 2)).
--
__Pascal Bourguignon__
This is what I've been using:
(defmacro defalias (new-alias original)
`(defmacro ,new-alias (&rest args)
`(,',original ,@args)))
Don't know if this is a bad way to do it, but it aliases macro's too
so works for me.
Ali <·············@gmail.com> writes:
> This is what I've been using:
>
> (defmacro defalias (new-alias original)
> `(defmacro ,new-alias (&rest args)
> `(,',original ,@args)))
>
> Don't know if this is a bad way to do it, but it aliases macro's too
> so works for me.
As long as you don't try:
(defalias sine sin)
(mapcar (function sine) '(1 2 3)) ; or
(mapcar (quote sine) '(1 2 3))
--
__Pascal Bourguignon__ http://www.informatimago.com/
Un chat errant
se soulage
dans le jardin d'hiver
Shiki
On Aug 22, 1:20 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> As long as you don't try:
>
> (defalias sine sin)
> (mapcar (function sine) '(1 2 3)) ; or
> (mapcar (quote sine) '(1 2 3))
Well, I lied just a bit...
(defmacro defmac (name args &body form)
`(progn
(defmacro ,name ,args ,@form)
(setf ,name (lambda (&rest argies) (eval (cons ',name argies))))))
I'm pretty sure this also isn't the nice way to do it, for one it uses
eval, which I think I shouldn't be doing.
Secondly the I'm pretty sure the name needs to be gensymed, but, works
for me...
Ali <·············@gmail.com> writes:
> (defmacro defmac (name args &body form)
> `(progn
> (defmacro ,name ,args ,@form)
> (setf ,name (lambda (&rest argies) (eval (cons ',name argies))))))
>
> I'm pretty sure this also isn't the nice way to do it, for one it uses
> eval, which I think I shouldn't be doing.
> Secondly the I'm pretty sure the name needs to be gensymed, but, works
> for me...
Actually GENSYMing the name would be completely worthless. The whole
point of a GENSYM is to generate an uninterned symbol. And by
definition, an uninterned symbol is one that you can't get, accidentally
or on purpose, by using its name.
So if you use a gensym as the name of a function, you won't ever be able
to call that function.*
Try the following to see how it doesn't work:
(defmacro defuseless (args &body form)
`(defun ,(gensym) ,args ,@form))
And then try calling the function:
CL-USER> CL-USER> (defuseless (a b) (+ a b))
#:G26
CL-USER> (#:G26 2 3)
Error: attempt to call `#:G26' which is an undefined function.
[condition type: UNDEFINED-FUNCTION]
...
CL-USER> (G26 2 3)
Error: attempt to call `G26' which is an undefined function.
[condition type: UNDEFINED-FUNCTION]
...
------------
* Unless you keep a reference to the actual symbol object returned by
GENSYM, but in that case it would be easier to just keep a pointer to
the function itself.
--
Thomas A. Russ, USC/Information Sciences Institute
On Aug 22, 8:31 pm, ····@sevak.isi.edu (Thomas A. Russ) wrote:
> Actually GENSYMing the name would be completely worthless.
Ah, yes I see that now... very silly. Need to read up on the hazy bits
before posting!
Ali wrote:
> On Aug 22, 1:20 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> As long as you don't try:
>>
>> (defalias sine sin)
>> (mapcar (function sine) '(1 2 3)) ; or
>> (mapcar (quote sine) '(1 2 3))
>
> Well, I lied just a bit...
>
> (defmacro defmac (name args &body form)
> `(progn
> (defmacro ,name ,args ,@form)
> (setf ,name (lambda (&rest argies) (eval (cons ',name argies))))))
>
> I'm pretty sure this also isn't the nice way to do it, for one it uses
> eval, which I think I shouldn't be doing.
> Secondly the I'm pretty sure the name needs to be gensymed, but, works
> for me...
Yes, this is a pretty bad way to do this. You also use setf on a global
name that hasn't been introduced properly by a
defvar/defparamater/define-symbol-macro. By doing that you invoke
undefined behavior and cannot be sure about whether such variables will
be lexical or special, because that's implementation-dependent then.
Better provide separate alias definition facilities for macros and
functions.
(defmacro defalias (f1 f2)
`(progn
(declaim (inline f1))
(defun f1 (&rest args)
(declare (dynamic-extent args))
(apply #'f2 args))
(define-compiler-macro f1 (&rest args)
`(,',f2 ,@args))))
Untested...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
(defmacro defalias (f1 f2)
`(progn
(declaim (inline ,f1))
(defun ,f1 (&rest args)
(declare (dynamic-extent args))
(apply #',f2 args))
(define-compiler-macro ,f1 (&rest args)
`(,',f2 ,@args))))
That works, with the added commas.
Thanks for the tip about (setf), Clisp wasn't complaining so I had
figured it was cool.
On Aug 22, 5:03 pm, Ali <·············@gmail.com> wrote:
> (defmacro defalias (f1 f2)
> `(progn
> (declaim (inline ,f1))
> (defun ,f1 (&rest args)
> (declare (dynamic-extent args))
> (apply #',f2 args))
> (define-compiler-macro ,f1 (&rest args)
> `(,',f2 ,@args))))
Amazing how many great lengths geeks go just to prove something is
possible, like emulating lisp1 in lisp2. :)
BTW, what's all the fuss about def in Lisp literature? defun, defvar,
define, define-syntax, define-foo... jeez!
defalias sounds about as bad as defalio...
Why not a simple (alias foo bar)? Just to get simple syntax
highlighting for free?
On Sep 3, 12:56 am, namekuseijin <············@gmail.com> wrote:
> On Aug 22, 5:03 pm, Ali <·············@gmail.com> wrote:
>
> > (defmacro defalias (f1 f2)
> > `(progn
> > (declaim (inline ,f1))
> > (defun ,f1 (&rest args)
> > (declare (dynamic-extent args))
> > (apply #',f2 args))
> > (define-compiler-macro ,f1 (&rest args)
> > `(,',f2 ,@args))))
>
> Amazing how many great lengths geeks go just to prove something is
> possible, like emulating lisp1 in lisp2. :)
>
> BTW, what's all the fuss about def in Lisp literature? defun, defvar,
> define, define-syntax, define-foo... jeez!
> defalias sounds about as bad as defalio...
>
> Why not a simple (alias foo bar)? Just to get simple syntax
> highlighting for free?
http://common-lisp.net/project/definer
Cheers
--
Marco
P� Wed, 03 Sep 2008 08:53:53 +0200, skrev Marco Antoniotti
<·······@gmail.com>:
> On Sep 3, 12:56�am, namekuseijin <············@gmail.com> wrote:
>> On Aug 22, 5:03�pm, Ali <·············@gmail.com> wrote:
>>
>> > �(defmacro defalias (f1 f2)
>> > � �`(progn
>> > � � � (declaim (inline ,f1))
>> > � � � (defun ,f1 (&rest args)
>> > � � � � (declare (dynamic-extent args))
>> > � � � � (apply #',f2 args))
>> > � � � (define-compiler-macro ,f1 (&rest args)
>> > � � � � `(,',f2 ,@args))))
>>
>> Amazing how many great lengths geeks go just to prove something is
>> possible, like emulating lisp1 in lisp2. :)
>>
>> BTW, what's all the fuss about def in Lisp literature? �defun, defvar,
>> define, define-syntax, define-foo... jeez!
>> defalias sounds about as bad as defalio...
>>
>> Why not a simple (alias foo bar)? �Just to get simple syntax
>> highlighting for free?
>
> http://common-lisp.net/project/definer
>
> Cheers
> --
> Marco
>
From the page:
Now you say:
(def function foo (x)
(+ x 42))
and
(def macro foo (y)
`(list ,y 42))
and
(def generic bar (x)
(:method ((x string)) ...))
and
(def method bar :before ((x symbol)) ...
And how exactly are you going to tell function 'foo from macro 'foo?
Don't you mean OR (def... ?
--------------
John Thingstad
On Sep 3, 10:18 am, "John Thingstad" <·······@online.no> wrote:
> På Wed, 03 Sep 2008 08:53:53 +0200, skrev Marco Antoniotti
> <·······@gmail.com>:
>
>
>
> > On Sep 3, 12:56 am, namekuseijin <············@gmail.com> wrote:
> >> On Aug 22, 5:03 pm, Ali <·············@gmail.com> wrote:
>
> >> > (defmacro defalias (f1 f2)
> >> > `(progn
> >> > (declaim (inline ,f1))
> >> > (defun ,f1 (&rest args)
> >> > (declare (dynamic-extent args))
> >> > (apply #',f2 args))
> >> > (define-compiler-macro ,f1 (&rest args)
> >> > `(,',f2 ,@args))))
>
> >> Amazing how many great lengths geeks go just to prove something is
> >> possible, like emulating lisp1 in lisp2. :)
>
> >> BTW, what's all the fuss about def in Lisp literature? defun, defvar,
> >> define, define-syntax, define-foo... jeez!
> >> defalias sounds about as bad as defalio...
>
> >> Why not a simple (alias foo bar)? Just to get simple syntax
> >> highlighting for free?
>
> >http://common-lisp.net/project/definer
>
> > Cheers
> > --
> > Marco
>
> From the page:
>
> Now you say:
> (def function foo (x)
> (+ x 42))
>
> and
> (def macro foo (y)
> `(list ,y 42))
>
> and
> (def generic bar (x)
> (:method ((x string)) ...))
>
> and
> (def method bar :before ((x symbol)) ...
>
> And how exactly are you going to tell function 'foo from macro 'foo?
> Don't you mean OR (def... ?
Yep. It is a Italian bad transliteration (not that the Italian is
correct either) :)
Thanks for the catch, I'll fix the web pages...
Cheers
--
Marco
Tobias C. Rittweiler wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Tobias C. Rittweiler wrote:
>>> Pascal Costanza <··@p-cos.net> writes:
>>>
>>>> (defmacro defalias (f1 f2)
>>>> `(progn
>>>> (declaim (inline f1))
>>>> (defun f1 (&rest args)
>>>> (declare (dynamic-extent args))
>>>> (apply #'f2 args))
>>>> (define-compiler-macro f1 (&rest args)
>>>> `(,',f2 ,@args))))
>>>>
>>>> Untested...
>>> The DYNAMIC-EXTENT looks wrong.
>> Why?
>
> What is if F2 is defined like (defun f2 (&rest args) args)?
It's the responsibility of f2 to handle this case correctly. Note that
it's already the case that rest arguments can share structure with the
last argument to apply, so you can never know where your arguments come
from and where they are allocated.
A better version would be this:
(defun f2 (&rest args)
(declare (dynamic-extent args))
(copy-list args))
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Tobias C. Rittweiler wrote:
> > Pascal Costanza <··@p-cos.net> writes:
> >
> >> Tobias C. Rittweiler wrote:
> >>> Pascal Costanza <··@p-cos.net> writes:
> >>>
> >>>> (defmacro defalias (f1 f2)
> >>>> `(progn
> >>>> (declaim (inline f1))
> >>>> (defun f1 (&rest args)
> >>>> (declare (dynamic-extent args))
> >>>> (apply #'f2 args))
(also, there's an error in the macro here, since this inserts the
literal F2 function instead of the one referenced by the macro's F2
argument.)
> >>>> (define-compiler-macro f1 (&rest args)
> >>>> `(,',f2 ,@args))))
> >>>>
> >>>> Untested...
> >>> The DYNAMIC-EXTENT looks wrong.
> >> Why?
> > What is if F2 is defined like (defun f2 (&rest args) args)?
>
> It's the responsibility of f2 to handle this case correctly. Note that
> it's already the case that rest arguments can share structure with the
> last argument to apply, so you can never know where your arguments come
> from and where they are allocated.
Actually, I disagree. Unless you are advocating that NO functions
return structure shared with their &rest arguments.
At the time F2 is written, the programmer doesn't yet know that someone
is going to invoke it in a context where the &rest argument will share
structure with a value that has been declared to have DYNAMIC-EXTENT.
That is all external to the function.
Safer would be not to assume that the handling of the argument list will
be "safe" for dynamic extent. But in an environment where one has
sufficiently strong programming conventions and restrictions, one can
avoid such issues. A case can be made that for general library
programming, it would be wise not to return shared structure from &rest
variables.
> A better version would be this:
>
> (defun f2 (&rest args)
> (declare (dynamic-extent args))
> (copy-list args))
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Tobias C. Rittweiler wrote:
>>> Pascal Costanza <··@p-cos.net> writes:
>>>
>>>> Tobias C. Rittweiler wrote:
>>>>> Pascal Costanza <··@p-cos.net> writes:
>>>>>
>>>>>> (defmacro defalias (f1 f2)
>>>>>> `(progn
>>>>>> (declaim (inline f1))
>>>>>> (defun f1 (&rest args)
>>>>>> (declare (dynamic-extent args))
>>>>>> (apply #'f2 args))
>
> (also, there's an error in the macro here, since this inserts the
> literal F2 function instead of the one referenced by the macro's F2
> argument.)
>
>>>>>> (define-compiler-macro f1 (&rest args)
>>>>>> `(,',f2 ,@args))))
>>>>>>
>>>>>> Untested...
>>>>> The DYNAMIC-EXTENT looks wrong.
>>>> Why?
>>> What is if F2 is defined like (defun f2 (&rest args) args)?
>> It's the responsibility of f2 to handle this case correctly. Note that
>> it's already the case that rest arguments can share structure with the
>> last argument to apply, so you can never know where your arguments come
>> from and where they are allocated.
>
> Actually, I disagree. Unless you are advocating that NO functions
> return structure shared with their &rest arguments.
>
> At the time F2 is written, the programmer doesn't yet know that someone
> is going to invoke it in a context where the &rest argument will share
> structure with a value that has been declared to have DYNAMIC-EXTENT.
> That is all external to the function.
>
> Safer would be not to assume that the handling of the argument list will
> be "safe" for dynamic extent. But in an environment where one has
> sufficiently strong programming conventions and restrictions, one can
> avoid such issues. A case can be made that for general library
> programming, it would be wise not to return shared structure from &rest
> variables.
Yes, the last point is exactly the main reason for my suggestion that
it's the responsibility of f2 to take care of this situation. If you
have total control over the code for your program, then you can make
more optimistic assumptions, but most of the time, you use third-party
libraries, and then you have to be more defensive in your programming style.
To put it differently: Because of the existence of the dynamic extent
declaration in Common Lisp, &rest parameters should always be assumed to
be potentially stack allocated.
I don't know whether the Common Lisp specification could have been more
careful in avoiding such border cases here, but we have to deal with
what we have...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> > What is if F2 is defined like (defun f2 (&rest args) args)?
>
> It's the responsibility of f2 to handle this case correctly. Note that
> it's already the case that rest arguments can share structure with the
> last argument to apply, so you can never know where your arguments
> come from and where they are allocated.
I think it's common (and very reasonable) to expect arguments to be
heap-allocated in the general case, and not have dynamic extent---
including &rest lists. (This doesn't preclude caution regarding
structure-sharing, of course.)
-T.
Kent M Pitman wrote:
> ...
> The notation matters are attributes of the Lisp1/Lisp2 issue, but the
> performance behavior of this is not... except that a caller of
> make-card compiled separately in CL with no knowledge of what's in the
> cell can reliably jump to the function cell contents feeling assured
> that it's a function in there whereas making that work in Scheme
> involves secretly being a Lisp2 and not telling anyone because if you
> really and truly implement aLisp1in the obvious way, a separately
> compiled module can't just jump to a variable's contents since it
> might not contain a function. So the theoretical performance issue is
> actually the reverse of what you suggest, Pascal... or so it seems to
> me.
I have in the past wrote a article on the harm of the jargon lisp 1
and lisp 2.
For the general readers in lisp groups, please see:
Why You should Not Use The Jargon Lisp1 and Lisp2
http://xahlee.org/emacs/lisp1_vs_lisp2.html
Plain text version follows:
--------------------------------------
Why You should Not Use The Jargon Lisp1 and Lisp2
Xah Lee, 2008-01-10
[The following is originally posted as a reply in comp.lang.lisp about
“Lisp-1” vs “Lisp-2”.]
Someone (·········@gmx.net) wrote:
«
Having read Touretzky's introduction and the first half of Paul
Graham's On Lisp↗, I'm wondering what the advantages of a Lisp-2 are
over a Lisp-1
It seems to me that a Lisp-2's ability to use a single symbol to
represent both a function and a value is a minor advantage, although
I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2
requires the clunky, IMHO, #' operator and cannot have a elegant,
universal DEFINE like Scheme's.
Yet I've heard that a Lisp-1's macros are necessarily less
powerful than those of a Lisp-2. Is that true? Are there some other
big advantages of a Lisp-2 that I'm missing?
»
Please try to avoid the jargons lisp1 and lisp2.
Recently i have just wrote a longish essay on the harm of jargons in
functional languages. (See: Jargons And High Level Languages)
The jargon lisp1 and lisp2 is one of better example that illustrate
the issue.
• The jargon is opaque. The words do not convey its meaning.
• Being a opaque jargon, it is often used subconsciously by people in
a group, to communicate that they are in-group. (a class-
differentiation strategy of human animals; as is much of slang↗'s
purpose) And consequently, these jargons are thrown about often
without the writers actually understanding, or wishing to discuss
about it in any way.
Further, it is my opinion, this issue is very minor, having little
real-world practical impact. It is not unlike a war about which end of
egg one should crack. (i.e. big endian vs little endian; See:
Gulliver's Travels. PART I — A VOYAGE TO LILLIPUT, Chapter 4)
Why is this issue minor? Consider it broadly in human animal's
computing activities. I give 2 examples:
Consider that in the 1960 people went to moon. (Moon landing↗) Imagine
what complexities involved in the physics, mathematics, computation,
at a time when computer are some one thousand times slower than today,
using punch-cards, and there are not much computer languages, not even
modular programing.
For another example, consider today's PHP language. Linguistically, it
is one of the most badly designed language, with many inconsistencies,
WITH NO NAMESPACE MECHANISM, yet, it is so widely used that it is in
fact one of the top 5 most deployed languages. If one of PHP or lisps
and all associated applications written in them is to suddenly
disappear from the face of this earth as a catastrophic punishment
from Zeus, and all the leaders of nations is to have experts to assess
the damage as they do with natural disasters, it is probable that PHP
would be the much greater loss.
Now, suppose we narrow the scope of “lisp1 vs lisp2” to its context:
computer language design. There are many issues in language design.
For example: dynamic scope vs lexical scope, various models of typing
systems (dynamic, static, variable/value based, algebraic types, no
types, with or without inference system), computing model (OOP,
Functional, procedural, pattern matching, database), evaluation model
(greedy vs lazy) ... etc. Among all language design issues, the
“lisp1” vs “lisp2” is really one of the least significant, which
actually arise practically only in Lisp due to its peculiar concept of
its “symbols”.
The existence of a name to a concept or idea, especially a opaque
jargon, tends to get people to throw the name and argue about it
unnecessarily.
To people in the lisp communities, please stop using the term. If
necessary, say Common Lisp's model or Scheme Lisp's model, or, use a
communicative term like multi-meaning-space and single-meaning-space.
The “Why” of “multi-meaning-space”
Now, in the following, i wish to discuss some associated issue. In
particular, thoughts on how multi-meaning-space came about.
There's a curious question. Why is the “lisp1 vs lisp2” happens only
in lisp, and we don't have “perl1 vs perl2”, “java1 vs java2”, “ML1 vs
ML2”, or any language with a variation on this?
This has to do with the concept of lisp's symbol, which doesn't exist
in other languages (notably except Mathematica).
Now, a further question is then, why Common Lisp's symbol of a
particular name can have multiple meanings? (That is, a name in CL can
both be a variable and a function in the same block of code at the
same time. (This peculiar fact, we might give it a professional
terminology for ease of communication, and we might call it: Common
Lisp's multi-meaning-space, or just multi-meaning-space, meaning-
space.))
Now, the question is, why do Lisps before Common Lisp have this multi-
meaning-space feature?
I do not know much about the technical aspects of Lisp's history.
However, i can venture a educated guess.
Old Lisps's multi-meaning-space feature, just like so many of its
features (cons, sort destroying its variable, and semi-regular syntax
using nested parens, etc), is simply designed as is without
necessarily explicit, important, rationales. In other words, it is
probably a characteristic that happens to be convenient, easy to
implement, or not thought about at the time, or simply went one way
than the other. (as opposed to, prominent issues that calls for
conscious, explicit, decisions with important ramifications, such as
syntax (sexp), symbols system, evaluation model, ...etc.)
Now, as i mentioned before, this (single/multi)-meaning-space issue,
with respect to human animal's computing activities, or with respect
to the set of computer design decisions, is one of the trivial, having
almost no practical impact. And, because some human animals, in the
history of their power struggle, is produced the byproduct of the
jargons “lisp1” and “lisp2”. And due to the fact that which end of egg
to crack is now blessed with a terminology that has all the
countenance of impartiality, it furnishes and fuels countless
arguments and fightings on this non-issue between the Scheme Lisp and
Common Lisp factions, even when the origin of the power struggle on
this particular issue (the Common Lisp Standard) has long died. (more
specifically, every few months the issue will rise up in
comp.lang.lisp or comp.lang.scheme, with all colors and types of
activities from sincere to trite to re-examination to political
struggle to pacification.)
Note: for the technical details of the Common Lisp's meaning-space,
and the origin of the jargons “lisp1” and “lisp2”, see: Technical
Issues of Separation in Function Cells and Value Cells↗, by Richard P
Gabriel, Kent M Pitman, 1988.
--------------------------------
Xah
∑ http://xahlee.org/
☄
From: Kent M Pitman
Subject: Re: the jargon lisp1 vs lisp2 [was: function aliasing]
Date:
Message-ID: <u63pejkbq.fsf@nhplace.com>
[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
·······@gmail.com" <······@gmail.com> writes:
> Please try to avoid the jargons lisp1 and lisp2.
This suggestion is not a constructive one because it offers no useful
substitution. Indeed, these terms were never suggested as general
purpose, but have taken on a life of their own primarily because there
is no better term that is easily pronounceable. "having a single
namespace" or "having a particular finite number of namespaces" is
just not pithy.
> * The jargon is opaque. The words do not convey its meaning.
I somewhat agree, but human language tends to be a living thing,
adapting as needed. No word starts out transparent. I think there
are valid criticisms of this term, but I think you weaken yourself
here. I think you want to say it's not general-purpose, in that it
doesn't offer itself as an adjective to be applied to other languages.
In its original context, that wasn't necessary, but if a small and
easily pronounceable adjective were devised, I think it would catch
on. However, I suspect such a word would be necessarily opaque at the
outset, which is why I don't think this is a good criticism. Opacity
is often a necessary first step in the adoption of a new word.
> * Being a opaque jargon, it is often used subconsciously by people in
> a group, to communicate that they are in-group.
Actually, while I agree with you that this sometimes happens, the
function is to avoid that, and I actually think it does this
successfully. In particular, there's nothing wrong with being in-group
if the group is descriptive. For example, "red" describes something
that is in-group, as I understand you to mean, and "blue" describes
another group. And "purple" yet another group, without creating a
problem for things that want to come and go as long as they do so by
stopping being red or blue or purple, or by starting being such.
The bad words are words that connote groups of features. Words like
Mac-like or PC-like are bad because people can disagree about what
Mac-like or PC-like is, and consequently it's hard to know if Unix-like
(or Linux-like, if you prefer) is Mac-like or PC-like, just as it's hard
to know if Windows Vista is even PC-like if you're used to Windows 95.
Those are group adjectives and create a problem.
But the only criterion for being in the Lisp1 group is having a single
namespace. There is a slight historical ambiguity about Lisp2 because CL
actually has some additional namespaces beyond 2, so whether 2 or 2+ is
the right designation is a wart on the usage.
But all in all, what is powerful about the Lisp1 and Lisp2
terminology, even given its flaws, is that a new language can come
along, as happened with Dylan, and one can discuss which language
family it belongs to--Lisp1 or Lisp2--pretty much independent of the
other features of the language, like whether it has a small or large
library, whether it has an object definition substrate, whether it's
mixed case, etc. In that sense, it's like having terms like
red/green/blue vary independently of tall/short or light/heavy when
describing objects.
> There's a curious question. Why is the "lisp1 vs lisp2" happens only
> in lisp, and we don't have "perl1 vs perl2", "java1 vs java2", "ML1
> vs ML2", or any language with a variation on this?
It could theoretically happen in some of these languages, it's just
that their proponents had a particular bias. Having the terminology
to be able to ask the question is a good feature of the term.
Language exists not just to describe what is but what isn't, so your
very query here is a strength of the term.
The original meaning of the term was to allow the discussion of two
non-existent dialects: CL with one namespace and Scheme with two
namespaces, so again was a discussion of could-be languages that
didn't exist. Much of science is about creating descriptions of what
has not yet been seen so that it can be discussed and measured and
predicted and so on.
But having to understand the terms not as "lisp1" and "lisp2" but as
merely a suffix -1 or -2 weakens the terminology because it's hard to
look up such a term in something like google. That's the one thing
that really bothers me personally about the terms.
In my personal opinion, your inquiries on the nature of languages
would make a much more interesting set of topics than your tirades on
what words people should be using to make those inquiries, in my
opinion. People will use whatever words they can get away with, as
long as others understand them. Indeed, your posts sometimes contain
creative use of English itself, and I see no problem with that. I saw
a post complaining about it, but all in all, we understand you. I'm
always grateful that the worldwide debate on these matters, and on a
great many other topics, occurs in English at all, even when carried
out by people whose native languages are other than English. If that
means there is some sloppy use of English, so what? It's easier for me
than if the language were another that I happened not to know.
And I feel somewhat the same about the Lisp1 and Lisp2 terms. They
were made for a specific purpose. It was fun to see them take on a
life of their own. It gives me the sense that the writing had an
impact, and that's kind of fun. But at the same time, I cringe a
little at the sloppy nature of them, just as you seem to. If there
were better terms, I might advocate them myself. You didn't suggest
any or, if I liked them, I might be endorsing them. I'm really trying
hard to be friendly and supportive of your remarks here, but you're
not giving me a lot to work with. So, for now, I'm forced to conclude
that these terms suffice.
Kent M Pitman <······@nhplace.com> wrote on 02 Sep 2008 17:4:
> ·······@gmail.com" <······@gmail.com> writes:
>> Please try to avoid the jargons lisp1 and lisp2.
>
> This suggestion is not a constructive one because it offers no useful
> substitution. [...] If there were better terms, I might advocate them
> myself. You didn't suggest any or, if I liked them, I might be endorsing
> them.
Oh, but Kent, he did, actually. The Mighty and Infallible Xah wrote:
To people in the lisp communities, please stop using the term [lisp1
or lisp2]. If necessary, say Common Lisp's model or Scheme Lisp's
model, or, use a communicative term like multi-meaning-space and
single-meaning-space.
Now, there's a lot to criticize about the Godlike Xah. But failing to at
least offer an alternative to lisp1/lisp2 (however poor the offer may be), is
not a Xahian failure.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Men occasionally stumble over the truth, but most of them pick themselves up
and hurry off as if nothing had happened. -- Winston Churchill (1874-1965)
On Tue, 02 Sep 2008 15:34:56 -0700, Don Geddis <···@geddis.org> wrote:
>Kent M Pitman <······@nhplace.com> wrote on 02 Sep 2008 17:4:
>> ·······@gmail.com" <······@gmail.com> writes:
>>> Please try to avoid the jargons lisp1 and lisp2.
>>
>> This suggestion is not a constructive one because it offers no useful
>> substitution. [...] If there were better terms, I might advocate them
>> myself. You didn't suggest any or, if I liked them, I might be endorsing
>> them.
>
>Oh, but Kent, he did, actually. The Mighty and Infallible Xah wrote:
>
> To people in the lisp communities, please stop using the term [lisp1
> or lisp2]. If necessary, say Common Lisp's model or Scheme Lisp's
> model, or, use a communicative term like multi-meaning-space and
> single-meaning-space.
>
>Now, there's a lot to criticize about the Godlike Xah. But failing to at
>least offer an alternative to lisp1/lisp2 (however poor the offer may be), is
>not a Xahian failure.
The whole point of the terms "lisp 1" and "lisp 2" was to avoid undue
association with either CL or Scheme, both of which carry connotations
which have nothing to do with the name space argument. Suggesting the
Common Lisp model vs the Scheme model reintroduces all the baggage the
Lisp 1 & 2 terminology sought to avoid. If Xah had done even minimal
research on the subject, he would have known that.
George
George Neuner <········@comcast.net> wrote on Wed, 03 Sep 2008:
> The whole point of the terms "lisp 1" and "lisp 2" was to avoid undue
> association with either CL or Scheme, both of which carry connotations
> which have nothing to do with the name space argument. Suggesting the
> Common Lisp model vs the Scheme model reintroduces all the baggage the Lisp
> 1 & 2 terminology sought to avoid. If Xah had done even minimal research
> on the subject, he would have known that.
Yes, yes, of course true. And, in fact, all perfectly well explained in
Kent's original paper that introduced the jargon for the very first time.
But as The Kenny has taught me, it is not in the nature of The Xah to do
research, even of the minimal kind. Besides (as Kenny also said), The Xah
can no more be wrong, than Picasso could by painting both eyes on one side of
a face.
The Mighty Xah has risen above the primitive notions of "right" and "wrong"
that you and I and the other mere mortals are still bound by.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
What is it that makes a complete stranger dive into an icy river to save a
solid-gold baby? Maybe we'll never know. -- Deep Thoughts, by Jack Handey
P� Wed, 03 Sep 2008 06:30:37 +0200, skrev George Neuner
<········@comcast.net>:
>
> The whole point of the terms "lisp 1" and "lisp 2" was to avoid undue
> association with either CL or Scheme, both of which carry connotations
> which have nothing to do with the name space argument. Suggesting the
> Common Lisp model vs the Scheme model reintroduces all the baggage the
> Lisp 1 & 2 terminology sought to avoid. If Xah had done even minimal
> research on the subject, he would have known that.
>
I fail to see how that relates to Xaw's post.
multi-meaning-space and single-meaning-space is no more bound to Scheme or
Common Lisp than Lisp1 and Lisp2.
(Lisp2... Should'nt it be Lisp5 or LispN?)
--------------
John Thingstad
John Thingstad wrote:
> P� Wed, 03 Sep 2008 06:30:37 +0200, skrev George Neuner
> <········@comcast.net>:
>
>>
>> The whole point of the terms "lisp 1" and "lisp 2" was to avoid undue
>> association with either CL or Scheme, both of which carry connotations
>> which have nothing to do with the name space argument. Suggesting the
>> Common Lisp model vs the Scheme model reintroduces all the baggage the
>> Lisp 1 & 2 terminology sought to avoid. If Xah had done even minimal
>> research on the subject, he would have known that.
>>
>
> I fail to see how that relates to Xaw's post.
> multi-meaning-space and single-meaning-space is no more bound to Scheme
> or Common Lisp than Lisp1 and Lisp2.
> (Lisp2... Should'nt it be Lisp5 or LispN?)
One problem with "multi-meaning-space and single-meaning-space" is that
each term is ambiguous, depending on where you put the implicit
parentheses. When I first read it (as a not-entirely-native speaker of
english) I briefly parsed multi-meaning-space as equivalent to Lisp1
(because its single namespace serves multiple kinds of symbol, and
programmers are responsible for disambiguation) and single-meaning-space
as equivalent to Lisp2 (because each namespect serves only one kind of
symbol).
(The word "kind" is not ideal in the paragraph above, but I think people
will understand what I'm getting at.)
paul
On 2008-09-02 22:42:49 +0100, Kent M Pitman <······@nhplace.com> said:
> Indeed, your posts sometimes contain
> creative use of English itself, and I see no problem with that.
Me neither :-(
How about
(defan fict (n]
(of (= n O) 1
(* n (fackt (- n I)}]>
??
Why should we tolerate from humans what we cannot tolerate from
machines? :-)
> I saw
> a post complaining about it, but all in all, we understand you.
Are you sure?
> I'm
> always grateful that the worldwide debate on these matters, and on a
> great many other topics, occurs in English at all, even when carried
> out by people whose native languages are other than English. If that
> means there is some sloppy use of English, so what? It's easier for me
> than if the language were another that I happened not to know.
Let's count Kent in the "I don't mind/care about rotten English" camp.
As a foreigner, I am thrilled by language quality and ease of flow
(a rare ingredient in most c.l.* groups), and I'd rather read beautiful
but meaningless poems than sensible arguments where the extent of the
noise (spelling/grammar) just covers the message ...
But that's just me :-)
--
JFB
verec <·····@mac.com> writes:
> How about
> (defan fict (n]
> (of (= n O) 1
> (* n (fackt (- n I)}]>
> ??
> Why should we tolerate from humans what we cannot tolerate from
> machines? :-)
Have a look at Harald Wertz's work on phaenarete:
http://www.ai.univ-paris8.fr/~hw/manMachine.pdf
--
__Pascal Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein
On 2008-09-02 14:13:14 +0100, ·······@gmail.com" <······@gmail.com> said:
> I have in the past wrote a article on the harm of the jargon lisp 1
> and lisp 2.
Please, Xah for the respect of your readers, try to use a correct
English. This mistake ("wrote" instead of "written") is recurrent
in your postings, and I am far more a foreigner than you are. Also
"An" as in "an article" wouldn't hurt either :-)
--
JFB
On Sep 2, 1:51 pm, verec <·····@mac.com> wrote:
> On 2008-09-02 14:13:14 +0100, ·······@gmail.com" <······@gmail.com> said:
>
> > I have in the past wrote a article on the harm of the jargon lisp 1
> > and lisp 2.
>
> Please,Xah for the respect of your readers, try to use a correct
> English. This mistake ("wrote" instead of "written") is recurrent
> in your postings,
O! Thanks for alerting me to that. I actually didn't notice i had it
wrong.
> ... Also
> "An" as in "an article" wouldn't hurt either :-)
For this, see:
To An or Not To An
http://xahlee.org/Periodic_dosage_dir/bangu/an.html
Plain text version follows:
-------------------------------
To An or Not To An
Xah Lee, 2004-07
As most of you know, there are canons about when to use “an” to
supplant the “a” article. The rule is simplistic, but not simple. For
example, a uninitiated foreigner might think that as long as the word
begin with one of the vowel letters a e i o u, then stick with “an”
instead “a”, but, to foreigner's chagrin, this is not so. For example,
an hour, a unit, are the correctly prescribed forms. As a consequence,
the matter gets hairy, and has often confounded me as a matter of
practice. To which i have concocted a plan from two principles: (1) to
hell with it. (2) a scheme to thwart grammarians and their presence in
society.
Of the two, (1) is out of pragmatism. For, often i do not have a good
time in figuring out which is right despite my intelligence. (because,
there are complications, for example, in front of acronyms (e.g. “an
FAQ” or “a FAQ”), and other times the pronunciation is not universal
regarding whether the word begins with a vowel sound.) Therefore, i
thought by simply sticking with “a” always, is a way towards efficient
communication, with, the consideration of time spent by the composer
as well as his readership. Of the second reason (2), is a plan i had
for a while, of which i think i have alluded to here and there in this
forum in the past. This is a scheme i devised to check the harms done
by the army of academicians and grammarians, to cause them headaches
and pain as they have caused me and the populace.
Although my simple plan of sticking with “a” is sound, but i do find
problems with it. Because, sometimes, if i post a short sentence
involving the article (e.g. “Here's a article on xyz.”), people might
get the idea that i'm rather cloddish because i used the incorrect
form of the article, and thus perhaps forego of checking out xyz i
wanted them to see. Thus is my dilemma that i'm bringing attention
here. To this dilemma, i have also devised plans against it. I haven't
had it down precisely, but roughly the principles are:
(A) if posting/publishing just a short sentence involving the said
article that is traditionally to be a “an”, then use “an”. (therefore
giving a indication that i'm rather educated)
(B) when publishing a long article or essay, stick with “a”
throughout.
(C) if the context or article is serious, then stick with the
canonical form. (as to avoid association with insincerity, or
divisiveness. e.g. when writing a love letter to a girl i really want)
As you can see, my second-tier principles are also sound, and does
resolve my dilemma that resulted from my first-tier principles on the
whole. However, one may not notice that this system is getting a bit
involved. As, often i have to think about what are my audiences, their
level of English proficiency, or the purpose or context of my
composition, and whether if it is a single sentence that might expand
to a essay later. The one most serious complication is that if for
example, in a forum where i post multiple messages over time, some
with just a single sentence that involved a “an”, then i may appear
inconsistent, as if “a” and “an” are chosen at random. (not even
considering the occurrences where i simply made unintended typos of
“an” and “a”)
So at the end, frankly, i think in my writings it is this
inconsistency one will find throughout, especially of folks who have
read many of my articles but not sufficiently a lot to know that i
have some systemic beefs with English, and consequently deem me a rube
with regards to the fine points of English. I really do hate it. What
do you think of it?
Convenient Wikipedia link: A and an↗.
Xah
∑ http://xahlee.org/
☄
On Tue, 2 Sep 2008 15:22:31 -0700 (PDT), ·······@gmail.com"
<······@gmail.com> wrote:
>On Sep 2, 1:51 pm, verec <·····@mac.com> wrote:
>> On 2008-09-02 14:13:14 +0100, ·······@gmail.com" <······@gmail.com> said:
>>
>>[...]
>>
>> ... Also
>> "An" as in "an article" wouldn't hurt either :-)
>
>For this, see:
>
>To An or Not To An
>http://xahlee.org/Periodic_dosage_dir/bangu/an.html
>
>[...]
>
>This is a scheme i devised to check the harms done
>by the army of academicians and grammarians, to cause them headaches
>and pain as they have caused me and the populace.
Sorry about the "headaches and pain" that the "army of academicians
and grammarians" have caused you.
Just a short note regarding the "canonical" (to borrow your term) use
of the articles 'a' vs. "an": It's actually much less complicated
than you describe:
a) If the following syllable begins with a vowel phoneme, use "an";
e.g., "an apple."
b) If the following syllable begins with a consonant phoneme, use
'a'; e.g., "a bird."
That's all there really is to it. The confusion with articles
preceding acronyms is caused by confusion with the pronunciation of
the acronyms; e.g., in the case of "SQL" (according to "SQL
Fundamentals" (see
http://databases.about.com/od/sql/a/sqlfundamentals.htm)):
>By the way, the correct pronunciation of SQL is a contentious issue
>within the database community. In their SQL standard, the American
>National Standards Institute declared that the official pronunciation
>is "es queue el." However, many database professionals have taken to
>the slang pronunciation "sequel." The choice is yours.
Without loss of generality, suppose that there were different
varieties of SQL, and that we wished to refer to one of them. Then,
since the "es" syllable above begins with the vowel phoneme 'e'
followed by the consonant phoneme 's' (there are actually two phonemes
in the single syllable '"es"), using that pronunciation, we would say
"an SQL." However, since the "se" syllable above begins with the
consonant phoneme 's' followed by the vowel phoneme 'e', using that
pronunciation, we would say "a SQL." Hence the confusion.
Remember, it is the pronunciation, not the spelling, that matters. For
example, "hair" and "heir" both begin with the letter 'h,' but begin
with different phonemes, since the consonant phoneme corresponding to
the letter 'h' is actually enunciated in "hair" ("hair" is pronounced
identically to "hare"), but is silent in "heir" ("heir" is pronounced
identically to "air"). So, we have the following:
c) a hair
d) an heir
Of course, you are free to use articles any way you wish; this
description was just offered to cause minimal "headaches and pain" in
clarifying the issue. Many people have difficulties with usage of 'a'
vs. "an" (including, until recently, one worker with a Ph.D. in my
office), so don't worry if you feel confused on occasion.
-- Benjamin L. Russell
Benjamin L. Russell <············@Yahoo.com> writes:
>On Tue, 2 Sep 2008 15:22:31 -0700 (PDT), ·······@gmail.com"
><······@gmail.com> wrote:
>>On Sep 2, 1:51 pm, verec <·····@mac.com> wrote:
>>> On 2008-09-02 14:13:14 +0100, ·······@gmail.com" <······@gmail.com> said:
>>>
>>>[...]
>>>
>>> ... Also
>>> "An" as in "an article" wouldn't hurt either :-)
>>
>>For this, see:
>>
>>To An or Not To An
>>http://xahlee.org/Periodic_dosage_dir/bangu/an.html
>>
>>[...]
>>
>>This is a scheme i devised to check the harms done
>>by the army of academicians and grammarians, to cause them headaches
>>and pain as they have caused me and the populace.
>Sorry about the "headaches and pain" that the "army of academicians
>and grammarians" have caused you.
What's more, I really think that Grammarians were forced into a submission
of this feature because of the common usage of English speaking people.
Using a or an is largely a matter of colloquial spoken English niceties,
rather than existing for the benefit of written English. In my experience,
such usages are not the favorites of Grammarians.
Aaron
--
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) +++++++++++++++
Email: <·······@sacrideo.us> | WWW: <http://www.sacrideo.us>
Scheme Programming is subtle; subtlety can be hard.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Thu, 4 Sep 2008, Aaron W. Hsu wrote:
> Benjamin L. Russell <············@Yahoo.com> writes:
>
> >On Tue, 2 Sep 2008 15:22:31 -0700 (PDT), ·······@gmail.com"
> ><······@gmail.com> wrote:
>
> >>On Sep 2, 1:51 pm, verec <·····@mac.com> wrote:
> >>> On 2008-09-02 14:13:14 +0100, ·······@gmail.com" <······@gmail.com> said:
> >>>
> >>>[...]
> >>>
> >>> ... Also
> >>> "An" as in "an article" wouldn't hurt either :-)
> >>
> >>For this, see:
> >>
> >>To An or Not To An
> >>http://xahlee.org/Periodic_dosage_dir/bangu/an.html
> >>
> >>[...]
> >>
> >>This is a scheme i devised to check the harms done
> >>by the army of academicians and grammarians, to cause them headaches
> >>and pain as they have caused me and the populace.
>
> >Sorry about the "headaches and pain" that the "army of academicians
> >and grammarians" have caused you.
>
> What's more, I really think that Grammarians were forced into a submission
> of this feature because of the common usage of English speaking people.
> Using a or an is largely a matter of colloquial spoken English niceties,
> rather than existing for the benefit of written English. In my experience,
> such usages are not the favorites of Grammarians.
>
It's not that complicated.
Adding a consonant between vowels
makes it easier to speak because there is
no need to add breaks to separate the vowels, or
change mouth position without adding an extra sound
when saying to consonants in a row. It's a time saver.
And, when listening to people speaking, it's easier to
separate the words when the first sound in the next word
is not very similar to the last word in the previous word.
Less chance for confusion.
Furthermore, writing similary to how we speak, simply
does make sense.
Maybe this is not so obvious for people with
east-asian accents?
On Thu, 4 Sep 2008, Kjetil S. Matheussen wrote:
> On Thu, 4 Sep 2008, Aaron W. Hsu wrote:
>
> > Benjamin L. Russell <············@Yahoo.com> writes:
> >
> > >On Tue, 2 Sep 2008 15:22:31 -0700 (PDT), ·······@gmail.com"
> > ><······@gmail.com> wrote:
> >
> > >>On Sep 2, 1:51 pm, verec <·····@mac.com> wrote:
> > >>> On 2008-09-02 14:13:14 +0100, ·······@gmail.com" <······@gmail.com> said:
> > >>>
> > >>>[...]
> > >>>
> > >>> ... Also
> > >>> "An" as in "an article" wouldn't hurt either :-)
> > >>
> > >>For this, see:
> > >>
> > >>To An or Not To An
> > >>http://xahlee.org/Periodic_dosage_dir/bangu/an.html
> > >>
> > >>[...]
> > >>
> > >>This is a scheme i devised to check the harms done
> > >>by the army of academicians and grammarians, to cause them headaches
> > >>and pain as they have caused me and the populace.
> >
> > >Sorry about the "headaches and pain" that the "army of academicians
> > >and grammarians" have caused you.
> >
> > What's more, I really think that Grammarians were forced into a submission
> > of this feature because of the common usage of English speaking people.
> > Using a or an is largely a matter of colloquial spoken English niceties,
> > rather than existing for the benefit of written English. In my experience,
> > such usages are not the favorites of Grammarians.
> >
>
> It's not that complicated.
>
> Adding a consonant between vowels
> makes it easier to speak because there is
> no need to add breaks to separate the vowels, or
> change mouth position without adding an extra sound
> when saying to consonants in a row. It's a time saver.
^^
Personally, I have a much bigger problem separating
two, to and too. :-)
On 2008-09-04, Kjetil S. Matheussen <··············@notam02.no> wrote:
> Personally, I have a much bigger problem separating
> two, to and too. :-)
>
...reminds me of a question asked on a Ph.D qualifying oral exam (that
appealed to me as a long time lisp hacker).
The question dealt with the issue of possible differences in expressive power
between spoken and written English. The candidate was asked, "Is there a
sentence in English which can be spoken but which can not be written down?"
Such a sentence is, "There are three **s in the English language -- two, to
and too." What, in the written form, do you use for **? In the written form,
there is no meta-word for the concept of being a two, to or too. (Picking any
one of the three to use in the written form would make the sentence
incorrect).
P.S. Yes, there also is the digit 2. But, then there are four **s in the
English language and the point still stands.
Bob Woodham <·······@cs.ubc.ca> writes:
> On 2008-09-04, Kjetil S. Matheussen <··············@notam02.no> wrote:
>> Personally, I have a much bigger problem separating
>> two, to and too. :-)
>>
>
> ...reminds me of a question asked on a Ph.D qualifying oral exam (that
> appealed to me as a long time lisp hacker).
>
> The question dealt with the issue of possible differences in expressive power
> between spoken and written English. The candidate was asked, "Is there a
> sentence in English which can be spoken but which can not be written down?"
>
> Such a sentence is, "There are three **s in the English language -- two, to
> and too." What, in the written form, do you use for **? In the written form,
> there is no meta-word for the concept of being a two, to or too. (Picking any
> one of the three to use in the written form would make the sentence
> incorrect).
You can use the international phonetic alphabet to write that "word".
I think it would still qualify as English.
"There are three tū's in the English language -- two, to and too."
Wouldn't the sentence
« What is the translation of the Russian word "интернет" in English? »
be a gramatical English sentence too?
> P.S. Yes, there also is the digit 2. But, then there are four **s in the
> English language and the point still stands.
The digit 2 is not THE three (or four) tū's, but a symbol that may
represent one of them.
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
P� Thu, 04 Sep 2008 21:18:44 +0200, skrev Bob Woodham <·······@cs.ubc.ca>:
>
> Such a sentence is, "There are three **s in the English language -- two,
> to
> and too." What, in the written form, do you use for **? In the written
> form,
> there is no meta-word for the concept of being a two, to or too.
> (Picking any
> one of the three to use in the written form would make the sentence
> incorrect).
Truth with modifications.
You forget it could be spelled in the phonetic alpabet.
There are four tu:'s in the english language 2, two, to and too.
--------------
John Thingstad
On 2008-09-04, John Thingstad <·······@online.no> wrote:
> P� Thu, 04 Sep 2008 21:18:44 +0200, skrev Bob Woodham <·······@cs.ubc.ca>:
>
>>
>> Such a sentence is, "There are three **s in the English language -- two,
>> to
>> and too." What, in the written form, do you use for **? In the written
>> form,
>> there is no meta-word for the concept of being a two, to or too.
>> (Picking any
>> one of the three to use in the written form would make the sentence
>> incorrect).
>
> Truth with modifications.
> You forget it could be spelled in the phonetic alpabet.
>
> There are four tu:'s in the english language 2, two, to and too.
Perhaps I should have emphasized that, for the example, the written form
should be direct rendering, in standard English, of the spoken form. Of
course, there are phonetic alphabets and ways to invoke/quote words from other
languages and notations.
If you want to argue that your sentence is a correct standard English written
form then, in fact, the sentence becomes factually incorrect since then
"There are five **s in the English language tu, 2, two, to and too"
(and you run the risk of falling into an infinite recursion).
I think there really are issues here of a self-referential paradox and the
need for a quoting mechanism or equivalent way to step outside the standard
written language to make it all work. That's why the example appeals to me,
as a lisp hacker, and why I thought it might appeal to others here too.
It's not worth belaboring the point, however.
P� Tue, 02 Sep 2008 15:13:14 +0200, skrev ······@gmail.com
<······@gmail.com>:
multi-meaning indicates that there is some form of ambiguity going on here.
To be more precise perhaps context-free-symbols and
context-sensitive-symbols would be more accurate?
--------------
John Thingstad
P� Wed, 03 Sep 2008 10:42:16 +0200, skrev John Thingstad
<·······@online.no>:
> P� Tue, 02 Sep 2008 15:13:14 +0200, skrev ······@gmail.com
> <······@gmail.com>:
>
> multi-meaning indicates that there is some form of ambiguity going on
> here.
> To be more precise perhaps context-free-symbols and
> context-sensitive-symbols would be more accurate?
To be more precise perhaps context-free-symbols and
context-sensitive-symbols would be more BETTER?
Sorry about the imprecision :)
--------------
John Thingstad
From: Kent M Pitman
Subject: Re: the jargon lisp1 vs lisp2 [was: function aliasing]
Date:
Message-ID: <uljy8tsn0.fsf@nhplace.com>
[ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
"John Thingstad" <·······@online.no> writes:
> På Wed, 03 Sep 2008 10:42:16 +0200, skrev John Thingstad
> <·······@online.no>:
>
> > På Tue, 02 Sep 2008 15:13:14 +0200, skrev ······@gmail.com
> > <······@gmail.com>:
> >
> > multi-meaning indicates that there is some form of ambiguity going
> > on here.
> > To be more precise perhaps context-free-symbols and
> > context-sensitive-symbols would be more accurate?
>
> To be more precise perhaps context-free-symbols and
> context-sensitive-symbols would be more BETTER?
> Sorry about the imprecision :)
Actually, context-free identifiers and context-sensitive identifiers
(or perhaps "... identifier resolution") would probably capture most
of what I think I meant to say. Not symbols, of course, since there's
yet another axis along which symbols are used in-the-meta in various
ways, according to context.
And once in a while, the actual non-one number is relevant, but most
of the time just context-sensitive at all is what matters. I've also
referred to Lisp-Omega, meaning a Lisp with an arbitrary number of
namespaces... using primitives like (value x function) or (value x
variable) or (value x my-personal-namespace), but I guess that's also
just a special case of context-sensitive, though.
The difference between Xah's suggested term multi-meaning and your
context-sensitive is (to me) whether the extra bit(s) that give one
the info on which meaning to use is conveyed implicitly or explictly.
The term multi-meaning doesn't take a position on the matter, but the
term context-sensitive suggests that the information is, in particular,
implicitly conveyed. And I do think that issue is central.
Kent M Pitman <······@nhplace.com> writes:
> [ comp.lang.lisp only; http://www.nhplace.com/kent/PFAQ/cross-posting.html ]
>
> "John Thingstad" <·······@online.no> writes:
>
>> På Wed, 03 Sep 2008 10:42:16 +0200, skrev John Thingstad
>> <·······@online.no>:
>>
>> > På Tue, 02 Sep 2008 15:13:14 +0200, skrev ······@gmail.com
>> > <······@gmail.com>:
>> >
>> > multi-meaning indicates that there is some form of ambiguity going
>> > on here.
>> > To be more precise perhaps context-free-symbols and
>> > context-sensitive-symbols would be more accurate?
>>
>> To be more precise perhaps context-free-symbols and
>> context-sensitive-symbols would be more BETTER?
>> Sorry about the imprecision :)
>
> Actually, context-free identifiers and context-sensitive identifiers
> (or perhaps "... identifier resolution") would probably capture most
> of what I think I meant to say. Not symbols, of course, since there's
> yet another axis along which symbols are used in-the-meta in various
> ways, according to context.
>
> And once in a while, the actual non-one number is relevant, but most
> of the time just context-sensitive at all is what matters. I've also
> referred to Lisp-Omega, meaning a Lisp with an arbitrary number of
> namespaces... using primitives like (value x function) or (value x
> variable) or (value x my-personal-namespace), but I guess that's also
> just a special case of context-sensitive, though.
>
> The difference between Xah's suggested term multi-meaning and your
> context-sensitive is (to me) whether the extra bit(s) that give one
> the info on which meaning to use is conveyed implicitly or explictly.
> The term multi-meaning doesn't take a position on the matter, but the
> term context-sensitive suggests that the information is, in particular,
> implicitly conveyed. And I do think that issue is central.
Being so general is ambiguous in that an identifier has a multitude of
meanings that depend on where it is used (as a variable, in
(MAKE-INSTANCE '...), as a hash key, and so on), so to say a Lisp has
context-sensitive identifiers (or symbols) doesn't convey a whole
lot. Of course those uses aren't all syntactically special like the
car of a form, but they could be. At least Lisp-1 and Lisp-2 don't
have any interpretations other than the one you assigned.
I can't recall hearing the terms Lisp-1 and Lisp-2 used other than in
the context of special lookup rules for function calls. Perhaps the
term could refer specifically to a double meaning for symbols used as
operators. Puncalls?
Paul Donnelly <·············@sbcglobal.net> writes:
> I can't recall hearing the terms Lisp-1 and Lisp-2 used other than in
> the context of special lookup rules for function calls. Perhaps the
> term could refer specifically to a double meaning for symbols used as
> operators. Puncalls?
Today the metaphor is more important than logical arguments. Lisp-1 vs.
Lisp-2 makes Lisp-2 seem somehow second class. Common Lispers seem to
rely on logic, which is not always capable of delivering winning
arguments. Talking about single namespace vs. multiple namespace might
be better at describing the issue but still relies on judgment rather
than knee jerk responses.
Maybe we should talk about first class symbols as those that have both
function and property list values. Then Common Lisp has first class
symbols (while Scheme and most other languages don't).
Scheme has the nice metaphor of hygienic macros that implies Common Lisp
somehow leaks puss filled symbols. How washing one's hands relates to
variable capture I have know idea, but people like metaphors. A better
term (Common Lisp wise) might be that scheme has sterile macros. That
way the Common Lisp macros could be called potent or virile.
--
Barry Fishman
Barry Fishman <·············@acm.org> writes:
> Paul Donnelly <·············@sbcglobal.net> writes:
> > I can't recall hearing the terms Lisp-1 and Lisp-2 used other than in
> > the context of special lookup rules for function calls. Perhaps the
> > term could refer specifically to a double meaning for symbols used as
> > operators. Puncalls?
>
> Today the metaphor is more important than logical arguments. Lisp-1 vs.
> Lisp-2 makes Lisp-2 seem somehow second class.
Funny, I've always thought it highlighted the single-issue / single-POV
nature of Scheme and the inclusive pluralism of CL, and have in fact
pointed to the fact that although the issue is narrowly tied to the
variable namespacing, it's no accident that Scheme is on the side of 1
and CL is on the side of two, since the Scheme community shows itself to
have at least a preference (I might go so far as "bias", but the word might
sound to some pejorative) for making everyone do things the same way.
The big success that is CL is the notion that people can live together in
reasonable harmony in a community designed with pluralism at its core, yet
without miring themselves in the classical Tower of Babel problem you might
expect from such pluralism. Examples of such elements in the CL design
that are very disparate in their character yet show a preference for "2" (or,
at least, "n>1") over "1" include, but are not limited to:
* multiple, arguably redundant, conditional constructs [sorted out by
macroexpand into a common substrate]
* multiple looping constructs [again sorted out by macroexpand]
* support for multiple namespaces [macro creation constructs capable of
papering over a number of the elements]
* support for multiple syntaxes [readmacros canonicalize input into a
standard set of notations for interchange use, insulating cooperating
programs from the vagueries of one person's input preference over another's
in most cases]
* structs vs classes [sorted out by CLOS and MOP into a relatively coherent
whole]
* multiple packages [permitting the same symbol name to have different
object identity in various circumstances]
Critics will point to details of this and say "well, it's got rough edges".
And yes, they'll be right. But suppose we pointed to the details of our
pluralistic open society in the United States and someone said "because it
is not rigorously administered, it's a sham and should be replaced by a
totalitarian state". That wouldn't make it better.
Lisp has a history of being bold and setting a goal that sometimes exceeds
the reality but pushes people forward to come up with new techniques to bring
people closer together. Setting no such goal, not surprisingly, yields fewer
advances in such areas because the problem has been defined away and it's not
as obvious to people that it needs to be explored.
> Common Lispers seem to rely on logic, which is not always capable of
> delivering winning arguments. Talking about single namespace
> vs. multiple namespace might be better at describing the issue but
> still relies on judgment rather than knee jerk responses.
>
> Maybe we should talk about first class symbols as those that have both
> function and property list values. Then Common Lisp has first class
> symbols (while Scheme and most other languages don't).
I've thought about this issue a bit, and I believe the issue is slightly
mired in syntax, but I think a good Lisp would have made keywords be what
other languages call "canonical strings", and it might be reasonable to say
that that's all Scheme's symbols are. I don't think the Scheme community
would really mind that, actually, except for history. They often refer to
symbols as keywords, I think they just object to our preference for a leading
colon (or sometimes Dylan's trailing colon, though while that's harder to
parse it's easier to explain in at least some cases because it matches
English in its usage) as the marker. If we all used standard terminology,
then Lisp would be the only language with symbols and Scheme would have
keywords. Then again, there are some changes I might make in Lisp's symbols
if I had it to do over. But I guess my real point is that I don't like the
idea of relegating Scheme's data to "second class" any more than I do
like they or anyone relegating ours to. I think the right solution is to
come up with good descriptive names that all communities could use.
> Scheme has the nice metaphor of hygienic macros that implies Common Lisp
> somehow leaks puss filled symbols.
Heh. :)
> How washing one's hands relates to
> variable capture I have know idea, but people like metaphors. A better
> term (Common Lisp wise) might be that scheme has sterile macros. That
> way the Common Lisp macros could be called potent or virile.
Perhaps we should calls ours "naturally antibacterial" since they don't
attract the problem that Scheme needs to clean up...
I'm reminded of the old joke about an MIT student and a Harvard
student in a bathroom. The MIT student starts to leave without washing
his hands when the guy from Harvard says to him, "At Harvard, we're
taught to wash our hands after we urinate." The MIT guy shrugs and
replies, "At MIT, we're taught not to urinate on our hands."
(If any Harvard folks have a good joke about MIT to offer in return,
I'll happily endure one if that will restore the balance of honor.
I didn't make the joke here to take a dig at Harvard, only to make
the obvious point about the perceptions and realities of hygiene.)
>
> Maybe we should talk about first class symbols as those that have both
> function and property list values. Then Common Lisp has first class
> symbols (while Scheme and most other languages don't).
>
What does that have to do with anything?
The spec does not spesify what should be in that plist it just sais you
shouldn't mess with it.
In particular you can't depend on the keys the functions uses being stored
there.
(On LispWorks)
CL-USER 3 > (pprint (symbol-plist 'list))
(COMPILER::LWX86-TRANSFORMS
(SYSTEM::LISTN-5TRANSFORM SYSTEM::LISTN-4TRANSFORM
SYSTEM::LISTN-3TRANSFORM
SYSTEM::LISTN-2TRANSFORM
COMPILER::LIST-WITH-NO-ARGS
COMPILER::LIST1-TRANSFORM)
COMPILER::LWX86-FNDEFS
#<COMPILER::FUNCTION-DESCRIPTOR LIST>
CLOS::PLIST-POINTER-TO-CLASS-TESTER
(#<BUILT-IN-CLASS LIST 2044C3E7> . LIST)
CLOS::PLIST-POINTER-TO-CLASS
(#<BUILT-IN-CLASS LIST 2044C3E7> . LIST)
TYPE::DIRECT-TYPE-PREDICATE
LISTP
TYPE::SYSTEM-TYPE
T
TYPE::TYPE-EXPANSION
#<Function ((DEFTYPE LIST) . 1) 20199C72>)
CL-USER 14 > (defun test (&key one two three) (values one two three))
TEST
CL-USER 15 > (compile 'test)
TEST
NIL
NIL
CL-USER 16 > (symbol-plist 'test)
NIL
--------------
John Thingstad
On 2008-08-22 00:02:16 +0100, Ali <·············@gmail.com> said:
> On Aug 16, 10:54 pm, verec <·····@mac.com> wrote:
>> (define make-card cons)
>> (define card-rank car)
>> (define card-suit cdr)
>
>> CL-USER 4 > (make-card 'h 1)
>> (h . 1)
>
> CL-USER 5 > (card-rank (make-card 'h 1))
> H
>
> CL-USER 6 > (card-suit (make-card 'h 1))
> 1
>
> Wrong way round, no? ;)
I knew of the blunder the second I released the mouse ...
Funny it took one whole week for someone to comment om it :-)
--
JFB