LISP limits?
or a typo?
http://www.paulgraham.com/popular.html
> Being Popular
>
> May 2001
>
> (This article was written as a kind of business plan for a new
...
> 4 Hackability
>
> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of
...
> In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
is this limitation true?
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>> In Common Lisp I have often wanted to iterate through the fields of a
>struct-- to comb out references to a deleted object, for example, or find
>fields that are uninitialized. I know the structs are just vectors
>underneath. And yet I can't write a general purpose function that I can
>call on any struct. I can only access the fields by name, because that's
>what a struct is supposed to mean.
>
>is this limitation true?
Yes. The FAQ contains some suggestions about how you can work around it.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
> >> In Common Lisp I have often wanted to iterate through the fields
> >of a struct-- to comb out references to a deleted object, for
> >example, or find fields that are uninitialized. I know the structs
> >are just vectors underneath. And yet I can't write a general
> >purpose function that I can call on any struct. I can only access
> >the fields by name, because that's what a struct is supposed to
> >mean.
> >
> >is this limitation true?
>
> Yes. The FAQ contains some suggestions about how you can work
> around it.
<http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part5/faq-doc-3.html>
Edi Weitz <···@agharta.de> writes:
> > Yes. The FAQ contains some suggestions about how you can work
> > around it.
>
> <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part5/faq-doc-3.html>
I was surprised that the FAQ doesn't mention that a possible solution
is to declare the structures with (:type vector) or (:type list). This
guarantees you that elements appear in the order specified in the
defstruct, so it's trivial to write some syntactic sugar that gives
you an efficient "structure-value"-function/macro.
(see the section on structures in the hyperspec)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Edi Weitz <···@agharta.de> writes:
>
> > > Yes. The FAQ contains some suggestions about how you can work
> > > around it.
> >
> > <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part5/faq-doc-3.html>
>
> I was surprised that the FAQ doesn't mention that a possible solution
> is to declare the structures with (:type vector) or (:type list). This
> guarantees you that elements appear in the order specified in the
> defstruct, so it's trivial to write some syntactic sugar that gives
> you an efficient "structure-value"-function/macro.
If you declare a structure to be of type vector or list, you loose the
integration of the structure type in the type system.
* (defstruct (zut (:type vector)) a s d)
ZUT
* (type-of (make-zut :a 11 :s 44))
(SIMPLE-VECTOR 3)
* (defstruct (zot) a s d)
ZOT
* (type-of (make-zot :a 11 :s 44))
ZOT
*
You may or may not want that.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> If you declare a structure to be of type vector or list, you loose the
> integration of the structure type in the type system.
Also, you lose some ability for the compiler to optimize based on type
inference. If you use a normal structure accessor, the compiler can
typecheck all data going into the slot, so it can assume the type of
data coming out, if you specify a :type arg to the slot. Since the
list and vector structure implementations have no such guarantee, the
compiler can't assume anything.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain wrote:
>
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > If you declare a structure to be of type vector or list, you loose the
> > integration of the structure type in the type system.
>
> Also, you lose some ability for the compiler to optimize based on type
> inference. If you use a normal structure accessor, the compiler can
> typecheck all data going into the slot, so it can assume the type of
> data coming out, if you specify a :type arg to the slot. Since the
> list and vector structure implementations have no such guarantee, the
> compiler can't assume anything.
Why must the compiler be hindered in this way? Declaring a structure
to be type vector or list just changes the way the system implements
the structure, and prevents one from *dynamically* identifying an object
as being of that structure type. It doesn't prevent the compiler from
making the proper inference from a compile-time type declaration.
Paul
Paul Dietz <············@motorola.com> writes:
> Rahul Jain wrote:
> >
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > > If you declare a structure to be of type vector or list, you loose the
> > > integration of the structure type in the type system.
> >
> > Also, you lose some ability for the compiler to optimize based on type
> > inference. If you use a normal structure accessor, the compiler can
> > typecheck all data going into the slot, so it can assume the type of
> > data coming out, if you specify a :type arg to the slot. Since the
> > list and vector structure implementations have no such guarantee, the
> > compiler can't assume anything.
>
> Why must the compiler be hindered in this way? Declaring a structure
> to be type vector or list just changes the way the system implements
> the structure, and prevents one from *dynamically* identifying an object
> as being of that structure type. It doesn't prevent the compiler from
> making the proper inference from a compile-time type declaration.
Raul has a very good point.
If you use the `:type' option in `defstruct' you cannot go around and
do
(defstruct (foo (:type vector)) a (s 0 :type fixnum) d)
(declaim (type foo *foo*))
(defvar *foo* (make-foo))
`foo' is not a type in the system. It could be, but is it not. There
is no requirement in the CLHS (AFAIK) to enforce the creation of a
`deftype' whenever a `defstruct' is declared with the `:type' option.
We could have it.
(defstruct (foo (:type list)) a (s 0 :type fixnum) d)
could produce also a deftype like
(deftype foo ()
'(complex-list t fixnum t))
(of course you assume the presence of the `complex-list' type :) ). A
CLHS standard `deftype' could be
(deftype foo ()
`(cons t (cons fixnum (cons t))))
You can elaborate on this, but I do not think that there is a
requirement to produce the "correct" type for the `:type' defstructs.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti wrote:
> If you use the `:type' option in `defstruct' you cannot go around and
> do
>
> (defstruct (foo (:type vector)) a (s 0 :type fixnum) d)
>
> (declaim (type foo *foo*))
>
> (defvar *foo* (make-foo))
>
> `foo' is not a type in the system. It could be, but is it not. There
> is no requirement in the CLHS (AFAIK) to enforce the creation of a
> `deftype' whenever a `defstruct' is declared with the `:type' option.
This is a good point. But even without a declaration of the type
of the structure itself, the compiler could still conclude that
the accessor (in this case, foo-s) returns a value of type (in this
case) fixnum, couldn't it?
Paul
Paul Dietz <············@motorola.com> writes:
> Marco Antoniotti wrote:
>
> > If you use the `:type' option in `defstruct' you cannot go around and
> > do
> >
> > (defstruct (foo (:type vector)) a (s 0 :type fixnum) d)
> >
> > (declaim (type foo *foo*))
> >
> > (defvar *foo* (make-foo))
> >
> > `foo' is not a type in the system. It could be, but is it not. There
> > is no requirement in the CLHS (AFAIK) to enforce the creation of a
> > `deftype' whenever a `defstruct' is declared with the `:type' option.
>
> This is a good point. But even without a declaration of the type
> of the structure itself, the compiler could still conclude that
> the accessor (in this case, foo-s) returns a value of type (in this
> case) fixnum, couldn't it?
It could if it generated appropriate type declarations. But (most
likely) there are not.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Paul Dietz <············@motorola.com> writes:
> Rahul Jain wrote:
> >
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > > If you declare a structure to be of type vector or list, you loose the
> > > integration of the structure type in the type system.
> >
> > Also, you lose some ability for the compiler to optimize based on type
> > inference.
[...]
> Why must the compiler be hindered in this way? Declaring a structure
> to be type vector or list just changes the way the system implements
> the structure, and prevents one from *dynamically* identifying an object
> as being of that structure type. It doesn't prevent the compiler from
> making the proper inference from a compile-time type declaration.
When the compiler sees (structure-slot structure) and that structure
was created with :type vector, how will it know that something else
didn't just use (setf (aref structure foo) 'bar) and violate the :type
on the slot declaration?
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain wrote:
> When the compiler sees (structure-slot structure) and that structure
> was created with :type vector, how will it know that something else
> didn't just use (setf (aref structure foo) 'bar) and violate the :type
> on the slot declaration?
I interpret the hyperspec this way:
The hyperspec says (about a :type declaration for a slot)
"This is entirely analogous to the declaration of a variable
or function; it effectively declares the result type of the
reader function."
So, if the slot has been defined with type slot-type, it effectively
defines the type of the function structure-slot to be
(function (t) slot-type). How do we know this isn't violated?
Like any other function type declaration, we're depending on
the programmer to not violate it.
Paul
In article <··············@merced.netfonds.no>,
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
>Edi Weitz <···@agharta.de> writes:
>
>> > Yes. The FAQ contains some suggestions about how you can work
>> > around it.
>>
>> <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part5/faq-doc-3.html>
>
>I was surprised that the FAQ doesn't mention that a possible solution
>is to declare the structures with (:type vector) or (:type list). This
>guarantees you that elements appear in the order specified in the
>defstruct, so it's trivial to write some syntactic sugar that gives
>you an efficient "structure-value"-function/macro.
That's a good idea if you just want to be able to iterate through the
slots, but it's not much better than the suggested methods if you want to
be able to access them by slot name, which is what the FAQ entry is about.
The syntactic sugar would have to build a table mapping from slot names to
indices, and that same sugar can map from slot names to accessors, as
suggested in the FAQ.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Edi Weitz wrote:
> Barry Margolin <······@genuity.net> writes:
>
>
>>In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>>
>>>>In Common Lisp I have often wanted to iterate through the fields
>>>
>>>of a struct-- to comb out references to a deleted object, for
>>>example, or find fields that are uninitialized. I know the structs
>>>are just vectors underneath. And yet I can't write a general
>>>purpose function that I can call on any struct. I can only access
>>>the fields by name, because that's what a struct is supposed to
>>>mean.
>>>
>>>is this limitation true?
>>
>>Yes. The FAQ contains some suggestions about how you can work
>>around it.
>
>
> <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part5/faq-doc-3.html>
taken out of the FAQ:
> If your Common Lisp includes an implementation
> of CLOS that supports the meta-object protocol specified in the
> original X3J13 draft spec (document X3J13/88-003), then it probably will
> allow (SLOT-VALUE <object> '<slot-name>); however, not all
> implementations of CLOS currently provide this.
which CL-implementations support this?
- CLOS that supports the meta-object protocol.
- and allowing: (SLOT-VALUE <object> '<slot-name>)
From: Hannah Schroeter
Subject: Re: CLOS with meta-object protocol - which vendor
Date:
Message-ID: <ajgncm$djc$1@c3po.schlund.de>
Hello!
ilias <·······@pontos.net> wrote:
>[...]
>which CL-implementations support this?
>- CLOS that supports the meta-object protocol.
>- and allowing: (SLOT-VALUE <object> '<slot-name>)
In fact, slot-value is standard, however the behaviour on structures
and conditions is not defined.
In CMUCL, the following works:
* (defstruct a x y)
A
* (setf *a* (make-a :x 1 :y 2))
Warning: Declaring *A* special.
#S(A :X 1 :Y 2)
* (slot-value *a* 'x)
1
* (slot-value *a* 'y)
2
* (pcl:class-slots (class-of *a*))
(#<Structure-Effective-Slot-Definition X {480318CD}>
#<Structure-Effective-Slot-Definition Y {48031C6D}>)
* (mapcar #'pcl:slot-definition-name (pcl:class-slots (class-of *a*)))
(X Y)
* (mapcar #'(lambda (d) (slot-value *a* (pcl:slot-definition-name d))) (pcl:class-slots (class-of *a*)))
(1 2)
A similar thing works for sbcl (substitute "SB-PCL" for "PCL" as package
name though).
And for clisp 2.27, this works:
[1]> (defstruct a x y)
A
[2]> (setf *a* (make-a :x 1 :y 2))
#S(A :X 1 :Y 2)
[3]> (slot-value *a* 'x)
1
[4]> (slot-value *a* 'y)
2
[6]> (clos::class-slots (class-of *a*))
(#(X (:X) 1 (NIL) NIL T NIL) #(Y (:Y) 2 (NIL) NIL T NIL))
There's no direct equivalent of slot-definition-name there, though,
you have to (aref ... 0) for that.
[14]> (mapcar #'(lambda (d) (aref d 0)) (clos::class-slots (class-of *a*)))
(X Y)
etc.
Kind regards,
Hannah.
From: ilias
Subject: Re: CLOS with meta-object protocol - which vendor
Date:
Message-ID: <3D5BF9CC.3080406@pontos.net>
Hannah Schroeter wrote:
> Hello!
>
> ilias <·······@pontos.net> wrote:
>
>>[...]
>
>
>>which CL-implementations support this?
>
>
>>- CLOS that supports the meta-object protocol.
>>- and allowing: (SLOT-VALUE <object> '<slot-name>)
>
>
> In fact, slot-value is standard, however the behaviour on structures
> and conditions is not defined.
>
> In CMUCL, the following works:
...
i'll check you code examples, when i'm more familar with the language in
a few days.
basicly, it is very interesting, that those limits exist. and that
solving this limits is so complicated.
Edi Weitz wrote:
> Barry Margolin <······@genuity.net> writes:
>
>
>>In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>>
>>>>In Common Lisp I have often wanted to iterate through the fields
>>>
>>>of a struct-- to comb out references to a deleted object, for
>>>example, or find fields that are uninitialized. I know the structs
>>>are just vectors underneath. And yet I can't write a general
>>>purpose function that I can call on any struct. I can only access
>>>the fields by name, because that's what a struct is supposed to
>>>mean.
>>>
>>>is this limitation true?
>>
>>Yes. The FAQ contains some suggestions about how you can work
>>around it.
>
>
> <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part5/faq-doc-3.html>
out of the FAQ:
> While it is not possible to write a fully general STRUCTURE-SLOT function,
statement is *false*.
corrected version:
While it is not possible to write a fully general STRUCTURE-SLOT
function *without a CLOS that supports the meta-object protocol*
(portabel solution) or *vendor-specific solutions, e.g.
EXCL:STRUCTURE-REF in Allegro.* (non portable solution)...
Am i right?
ilias <·······@pontos.net> writes:
> out of the FAQ:
> > While it is not possible to write a fully general STRUCTURE-SLOT function,
>
> statement is *false*.
>
> corrected version:
> While it is not possible to write a fully general STRUCTURE-SLOT
> function *without a CLOS that supports the meta-object protocol*
> (portabel solution) or *vendor-specific solutions,
> e.g. EXCL:STRUCTURE-REF in Allegro.* (non portable solution)...
How is something that's non-portable supposed to be fully general? If
it's not portable, it's not general to the language... We all (I hope)
know that implementations can provide specific solutions to specific
problems, but that doesn't mean that those solutions are "fully
general" in any way; particularly not in terms of portability.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Erik Naggum
Subject: Re: does my dream, my hope finishes here?
Date:
Message-ID: <3238429716488328@naggum.no>
* Rahul Jain
| How is something that's non-portable supposed to be fully general?
It could export the same interface in all implementations.
| If it's not portable, it's not general to the language...
Common Lisp implementations are generally not portable, but rest on
implementation-specific details on the particular platform, base compiler,
and operating system. The language implemented is supposedly the same on
all implementations and facilitates portability by making it possible to use
the exact same language everywhere, even though each implementation does
subtly different things on each platform in order to achieve the /specified/
behavior.
The question is whether you have portable code in the implementation or
portable interfaces from the specification.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum <····@naggum.no> writes:
> * Rahul Jain
> | How is something that's non-portable supposed to be fully general?
>
> It could export the same interface in all implementations.
>
>
> | If it's not portable, it's not general to the language...
>
> Common Lisp implementations are generally not portable, but rest on
> implementation-specific details on the particular platform, base compiler,
> and operating system. The language implemented is supposedly the same on
> all implementations and facilitates portability by making it possible to use
> the exact same language everywhere, even though each implementation does
> subtly different things on each platform in order to achieve the /specified/
> behavior.
>
> The question is whether you have portable code in the implementation or
> portable interfaces from the specification.
Right, we were talking about interface portability here, but it's a
good point to clarify. However, I would think that the distinction
between "portable" and "widely ported" (as you worded it, "portable
code" vs. "portable interfaces") can become an issue at times
(especially when you want to support another implementation). E.g., CL
is a portable language. An implementation may be widely ported, but
usually doesn't restrict itself to portable interfaces.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain wrote:
> ilias <·······@pontos.net> writes:
>
>
>>out of the FAQ:
>>
>>>While it is not possible to write a fully general STRUCTURE-SLOT function,
>>
>>statement is *false*.
>>
>>corrected version:
>>While it is not possible to write a fully general STRUCTURE-SLOT
>>function *without a CLOS that supports the meta-object protocol*
>>(portabel solution) or *vendor-specific solutions,
>>e.g. EXCL:STRUCTURE-REF in Allegro.* (non portable solution)...
>
>
> How is something that's non-portable supposed to be fully general? If
> it's not portable, it's not general to the language... We all (I hope)
> know that implementations can provide specific solutions to specific
> problems, but that doesn't mean that those solutions are "fully
> general" in any way; particularly not in terms of portability.
>
the CLOS MOP solution would be portable.
and the meaning of fully general is context-sensitive.
"fully general"
remember how this thread started:
> http://www.paulgraham.com/popular.html
>
> Being Popular
>
> May 2001
>
> (This article was written as a kind of business plan for a new
> ...
> 4 Hackability
>
> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of
> ...
> In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
i quoted:
> And yet I can't write a general purpose function that I can call on any struct.
this switches the context of "general" to "cross-structs" or
"cross-objects" and definitely to "in-language-implementation".
if you mean with general "cross-objects" *and*
"cross-language-implementations", you have to state this.
(i'm just asking myself, if i'm writing clear and understandable)
ilias <·······@pontos.net> writes:
> the CLOS MOP solution would be portable.
It would not be portable to implementations that do not implement the
specific MOP that you are asking for. Note that this includes
information about whether the implementation even supports any kind of
non-trivial MOP on structures, which no standard or semi-standard
requires.
> and the meaning of fully general is context-sensitive.
>
> "fully general"
>
> remember how this thread started:
>
> > http://www.paulgraham.com/popular.html
> > Being Popular
I'd rather be accurate than popular.
> i quoted:
>
> > And yet I can't write a general purpose function that I can call on any struct.
>
> this switches the context of "general" to "cross-structs" or
> "cross-objects" and definitely to "in-language-implementation".
>
>
> if you mean with general "cross-objects" *and*
> "cross-language-implementations", you have to state this.
>
>
> (i'm just asking myself, if i'm writing clear and understandable)
If you're asking yourself what you mean, please answer that question
publically, so that we also have the benefit of knowing what you mean.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain wrote:
> ilias <·······@pontos.net> writes:
>
>
>>the CLOS MOP solution would be portable.
>
>
> It would not be portable to implementations that do not implement the
> specific MOP that you are asking for. Note that this includes
> information about whether the implementation even supports any kind of
> non-trivial MOP on structures, which no standard or semi-standard
> requires.
>
>
>>and the meaning of fully general is context-sensitive.
>>
>>"fully general"
>>
>>remember how this thread started:
>>
>>
>>>http://www.paulgraham.com/popular.html
>>>Being Popular
>>
>
> I'd rather be accurate than popular.
unfriendly: bringing the quote out of context.
irrelevant: your comment.
>
>
>>i quoted:
>>
>>
>>>And yet I can't write a general purpose function that I can call on any struct.
>>
>>this switches the context of "general" to "cross-structs" or
>>"cross-objects" and definitely to "in-language-implementation".
>>
>>
>>if you mean with general "cross-objects" *and*
>>"cross-language-implementations", you have to state this.
>>
>>
>>(i'm just asking myself, if i'm writing clear and understandable)
>
>
> If you're asking yourself what you mean, please answer that question
> publically, so that we also have the benefit of knowing what you mean.
i'll do that. tomorrow. until than, if someone have understood what i've
written, please drop a line.
would make me very happy.
ilias wrote:
> Rahul Jain wrote:
>
>> ilias <·······@pontos.net> writes:
>>
...
>>> i quoted:
>>>
>>>> And yet I can't write a general purpose function that I can call on
>>>> any struct.
... a *general* purpose function ... that i can call on *any struct*
>>> this switches the context of *general* to *cross-structs* or
>>> *cross-objects* and definitely to *in-language-implementation*.
this switches the context of [the word] *general* to the domain
*cross-structs* [so a "general" function is working across different
structs] and definitely to "in-language-implementation" [had better
written: and definitely *not* to *cross-vendor*]
>>> if you mean with general "cross-objects" *and*
>>> "cross-language-implementations" [*cross-vendor*],
>>> you have to state this.
if you mean with [the word] general [the context] "cross-objects" *and*
"cross-language-implementations" [had better written: *cross-vendor*],
you have to state this.
>>> (i'm just asking myself, if i'm writing clear and understandable)
>>
>> If you're asking yourself what you mean, please answer that question
>> publically, so that we also have the benefit of knowing what you mean.
>
> i'll do that. tomorrow. until than, if someone have understood what i've
> written, please drop a line.
so, self, i keep my promise
>
> would make me very happy.
so many facts.
so little time.
understandig.
gentleness.
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>Edi Weitz wrote:
>out of the FAQ:
>> While it is not possible to write a fully general STRUCTURE-SLOT function,
>
>statement is *false*.
>
>corrected version:
>While it is not possible to write a fully general STRUCTURE-SLOT
>function *without a CLOS that supports the meta-object protocol*
>(portabel solution) or *vendor-specific solutions, e.g.
>EXCL:STRUCTURE-REF in Allegro.* (non portable solution)...
>
>
>Am i right?
The MOP isn't necessarily portable, since it's not part of the official
standard. And I think portability was one of the things that we intended
"fully general" to include when we wrote that sentence.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>>Edi Weitz wrote:
>>out of the FAQ:
>>
>>>While it is not possible to write a fully general STRUCTURE-SLOT function,
>>
>>statement is *false*.
>>
>>corrected version:
>>While it is not possible to write a fully general STRUCTURE-SLOT
>>function *without a CLOS that supports the meta-object protocol*
>>(portabel solution) or *vendor-specific solutions, e.g.
>>EXCL:STRUCTURE-REF in Allegro.* (non portable solution)...
>>
>>
>>Am i right?
>
>
> The MOP isn't necessarily portable, since it's not part of the official
> standard. And I think portability was one of the things that we intended
> "fully general" to include when we wrote that sentence.
>
out of the FAQ:
> If your Common Lisp includes an implementation
> of CLOS that supports the meta-object protocol specified in the
> original X3J13 draft spec (document X3J13/88-003),
so, is the meta-object-protocol (MOP) part of the standard or not?
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>so, is the meta-object-protocol (MOP) part of the standard or not?
No, what makes you think it is? Do you see it described in the CLHS?
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>>so, is the meta-object-protocol (MOP) part of the standard or not?
>
>
> No, what makes you think it is? Do you see it described in the CLHS?
>
this makes me think it is:
out of the FAQ:
> If your Common Lisp includes an implementation
> of CLOS that supports the meta-object protocol specified in the
> original X3J13 draft spec (document X3J13/88-003),
*this* makes *me* think that document X3J13/88-003 is the *standard* and
so i conclude that MOP is part of the standard.
i guess i conclude wrong?
if so, then your faq is missleading.
In article <··············@pontos.net>, ilias <·······@pontos.net> wrote:
>Barry Margolin wrote:
>> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>>
>>>so, is the meta-object-protocol (MOP) part of the standard or not?
>>
>>
>> No, what makes you think it is? Do you see it described in the CLHS?
>>
>
>this makes me think it is:
>
>out of the FAQ:
>
>> If your Common Lisp includes an implementation
>> of CLOS that supports the meta-object protocol specified in the
>> original X3J13 draft spec (document X3J13/88-003),
>
>*this* makes *me* think that document X3J13/88-003 is the *standard* and
Don't you see the word "draft"? That means it's *not* the final
specification.
Document names of the form X3J13/##-### are internal documents of the
standardization committee, used for communication during the
standardization process. That's not the naming scheme for published ANSI
standards.
>so i conclude that MOP is part of the standard.
The original proposal for CLOS included the MOP. But what's actually in
the standard was the result of further debate, clarification, and redesign.
We decided that the MOP wasn't ready for standardization, so we left it
out.
If you want to know what's actually in the standard, either purchase a copy
from ANSI, or access the CLHS on the web.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> In article <··············@pontos.net>, ilias <·······@pontos.net> wrote:
>
>>Barry Margolin wrote:
>>
>>>In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>>>
>>>>so, is the meta-object-protocol (MOP) part of the standard or not?
>>>
>>>No, what makes you think it is? Do you see it described in the CLHS?
>>>
>>
>>this makes me think it is:
>>
>>out of the FAQ:
>>
>>>If your Common Lisp includes an implementation
>>>of CLOS that supports the meta-object protocol specified in the
>>>original X3J13 draft spec (document X3J13/88-003),
>>
>>*this* makes *me* think that document X3J13/88-003 is the *standard* and
> Don't you see the word "draft"? That means it's *not* the final
> specification.
>
> Document names of the form X3J13/##-### are internal documents of the
> standardization committee, used for communication during the
> standardization process. That's not the naming scheme for published ANSI
> standards.
>
>>so i conclude that MOP is part of the standard.
>
>
> The original proposal for CLOS included the MOP. But what's actually in
> the standard was the result of further debate, clarification, and redesign.
> We decided that the MOP wasn't ready for standardization, so we left it
> out.
>
> If you want to know what's actually in the standard, either purchase a copy
> from ANSI, or access the CLHS on the web.
aha.
so the draft spec was written in the early state of the standard and
what is written there is not in the current standard which i can access
in CLHS, so i can verify what is standard and what not.
but companies may implement what is specified in the draft spec,
although it is not in the standard, which i basically can see out of the
numbering-scheme.
just wondering about that it is a simple fact: has a vendor implemented
MOP, which is definded in the draft spec, and not in the standard.
so, why that simple fact is not requested at the vendors and written
down in the FAQ, instead of the speculations (which are written down
precisely, i must agree, after rereading carefully with more attention).
conclusion:
- c.l.l FAQ, read with higly precision !
- or contact the vendors directly
i' so tired.
lost control.
must sleep.
...
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>but companies may implement what is specified in the draft spec,
Companies can implement whatever they want. If they want to conform to the
standard they have to implement at least what's in there. But they can and
do implement additional things beyond that. During the standardization
process there were a number of things that we decided weren't ready to be
cast in stone -- we encouraged implementors to try them so that by the next
revision of the standard we would have enough experience to standardize
them.
>just wondering about that it is a simple fact: has a vendor implemented
> MOP, which is definded in the draft spec, and not in the standard.
The latest specification for the MOP is the book "The Art of the Metaobject
Protocol", and most vendors implement it. That book didn't exist at the
time we wrote the FAQ, so the only reference was the draft spec.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
...
>>just wondering about that it is a simple fact: has a vendor implemented
>> MOP, which is definded in the draft spec, and not in the standard.
>
>
> The latest specification for the MOP is the book "The Art of the Metaobject
> Protocol", and most vendors implement it. That book didn't exist at the
> time we wrote the FAQ, so the only reference was the draft spec.
>
i see.
why don't you update the FAQ?
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>why don't you update the FAQ?
I stopped maintaining the FAQ years ago, because other than participating
in this newsgroup I'm not heavily involved in Lisp programming. AFAIK, no
one has volunteered to take over maintenance of it, so it has been stuck in
the same state for years.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>>why don't you update the FAQ?
>
>
> I stopped maintaining the FAQ years ago, because other than participating
> in this newsgroup I'm not heavily involved in Lisp programming. AFAIK, no
> one has volunteered to take over maintenance of it, so it has been stuck in
> the same state for years.
>
xexe!
funny.
we 'fight' about an FAQ, which has been "stuck in the same state for years."
one moment, i take a look... 5 year old (whow) FAQ.
i think the LISP-vendors should do a little work. not only on their
webpages, but here, too.
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>we 'fight' about an FAQ, which has been "stuck in the same state for years."
>
>one moment, i take a look... 5 year old (whow) FAQ.
Lisp hasn't changed too much in that time.
BTW, I think the Unix FAQ is even older, and Unix has evolved quite a bit
since it was last updated.
I think FAQ maintenance used to be much more rewarding, when Usenet was a
kinder and gentler place. :)
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
> >we 'fight' about an FAQ, which has been "stuck in the same state for years."
> >
> >one moment, i take a look... 5 year old (whow) FAQ.
>
> Lisp hasn't changed too much in that time.
>
> BTW, I think the Unix FAQ is even older, and Unix has evolved quite a bit
> since it was last updated.
>
> I think FAQ maintenance used to be much more rewarding, when Usenet was a
> kinder and gentler place. :)
No doubt. I quite enjoyed maintaining the FAQ's I did years ago
... now I wouldn't even consider it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
ilias <·······@pontos.net> writes:
> out of the FAQ:
>
>> If your Common Lisp includes an implementation
>> of CLOS that supports the meta-object protocol specified in the
>> original X3J13 draft spec (document X3J13/88-003),
^^^^^^^^^^
> *this* makes *me* think that document X3J13/88-003 is the *standard*
> and so i conclude that MOP is part of the standard.
The standard is an ANSI document, namely X3.226:1994, and is clearly
labeled as a standard. Document X3J13/88-003 is/was a working
document of the X3J13 TC/WG, and as a "draft spec" (not to be confused
with a draft standard) doesn't have any standing as a standard, or
indeed any other official standing whatsoever. Even for someone not
aware of ANSI terminology or procedure, the words "draft spec" should
have given away that the document under discussion doesn't constitute a
standard.
> i guess i conclude wrong?
You conclude wrong, because you do not read as precisely as you should.
> if so, then your faq is missleading.
This is faulty reasoning. Just because you conclude something wrongly
doesn't automatically imply that the source of information is
misleading. There are a number of other possible causes for your
wrong conclusion, your reading imprecsision being one of them.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
ilias <·······@pontos.net> writes:
> out of the FAQ:
>
>> If your Common Lisp includes an implementation
>> of CLOS that supports the meta-object protocol specified in the
>> original X3J13 draft spec (document X3J13/88-003),
^^^^^^^^^^
> *this* makes *me* think that document X3J13/88-003 is the *standard*
> and so i conclude that MOP is part of the standard.
The standard is an ANSI document, namely X3.226:1994, and is clearly
labeled as a standard. Document X3J13/88-003 is/was a working
document of the X3J13 TC/WG, and as a "draft spec" (not to be confused
with a draft standard) doesn't have any standing as a standard, or
indeed any other official standing whatsoever. Even for someone not
aware of ANSI terminology or procedure, the words "draft spec" should
have given away that the document under discussion doesn't constitute a
standard.
> i guess i conclude wrong?
You conclude wrong, because you do not read as precisely as you should.
> if so, then your faq is missleading.
This is faulty reasoning. Just because you conclude something wrongly
doesn't automatically imply that the source of information is
misleading. There are a number of other possible causes for your
wrong conclusion, your reading imprecsision being one of them.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre R. Mai wrote:
> ilias <·······@pontos.net> writes:
>
>
>>out of the FAQ:
>>
>>
>>>If your Common Lisp includes an implementation
>>>of CLOS that supports the meta-object protocol specified in the
>>>original X3J13 draft spec (document X3J13/88-003),
>>
> ^^^^^^^^^^
>
>
>>*this* makes *me* think that document X3J13/88-003 is the *standard*
>>and so i conclude that MOP is part of the standard.
>
>
> The standard is an ANSI document, namely X3.226:1994, and is clearly
> labeled as a standard. Document X3J13/88-003 is/was a working
> document of the X3J13 TC/WG, and as a "draft spec" (not to be confused
> with a draft standard) doesn't have any standing as a standard, or
> indeed any other official standing whatsoever. Even for someone not
> aware of ANSI terminology or procedure, the words "draft spec" should
> have given away that the document under discussion doesn't constitute a
> standard.
>
>
>>i guess i conclude wrong?
>
>
> You conclude wrong, because you do not read as precisely as you should.
>
>
>>if so, then your faq is missleading.
>
>
> This is faulty reasoning. Just because you conclude something wrongly
> doesn't automatically imply that the source of information is
> misleading. There are a number of other possible causes for your
> wrong conclusion, your reading imprecsision being one of them.
>
> Regs, Pierre.
>
at the time you post this message, did you know the the FAQ is about 5
years old (time-stamps of the file)?
ilias <·······@pontos.net> writes:
> at the time you post this message, did you know the the FAQ is about 5
> years old (time-stamps of the file)?
As the standard has not changed in the past five years, I don't see
how that's relevant. And really, it's not up to the vendors to
maintain a FAQ. Sure, it would be nice if they did, but it would be
just as nice if anyone else did.
(Actually, there was some recent effort to revise the FAQ, though it
doesn't seem to have seen much contribution lately. See the current
draft at http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html and send
in your patches today)
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> ilias <·······@pontos.net> writes:
>
>
>>at the time you post this message, did you know the the FAQ is about 5
>>years old (time-stamps of the file)?
>
>
> As the standard has not changed in the past five years, I don't see
> how that's relevant.
the standard has not changed.
but the "quasi standards", those to which vendors agree, without ANSI.
> And really, it's not up to the vendors to maintain a FAQ.
ok. this is maybe my "philosophical" point of view.
> Sure, it would be nice if they did, but it would be
> just as nice if anyone else did.
>
> (Actually, there was some recent effort to revise the FAQ, though it
> doesn't seem to have seen much contribution lately. See the current
> draft at http://www-jcsu.jesus.cam.ac.uk/~csr21/lispfaq.html and send
> in your patches today)
i'll take a look
>
>
> -dan
>
ilias <·······@pontos.net> writes:
> at the time you post this message, did you know the the FAQ is about 5
> years old (time-stamps of the file)?
Yes, I did. I also knew that 2002 minus 5 is newer than 1994, which
happens to be the time the ANSI standard was published (and the
technical content was frozen much earlier). However even though the
FAQ has been unmaintained for quite a bit of time, nothing materially
changed in relation to the issues surrounding the question at hand.
If it had, I or someone else would have pointed this out in the
discussion.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre R. Mai wrote:
> ilias <·······@pontos.net> writes:
>
>
>>at the time you post this message, did you know the the FAQ is about 5
>>years old (time-stamps of the file)?
>
>
> Yes, I did. I also knew that 2002 minus 5 is newer than 1994, which
> happens to be the time the ANSI standard was published (and the
> technical content was frozen much earlier). However even though the
> FAQ has been unmaintained for quite a bit of time, nothing materially
> changed in relation to the issues surrounding the question at hand.
> If it had, I or someone else would have pointed this out in the
> discussion.
someone has:
Barry Margolin wrotes in message:
·················@paloalto-snr1.gtei.net
> The latest specification for the MOP is the book "The Art of the Metaobject
> Protocol", and most vendors implement it.
The latest specification for the MOP is the book "The Art of the Metaobject
Protocol", and most vendors implement it.
>
> Regs, Pierre.
>
In article <··············@pontos.net>, ilias wrote:
> out of the FAQ:
>
>> If your Common Lisp includes an implementation
>> of CLOS that supports the meta-object protocol specified in the
>> original X3J13 draft spec (document X3J13/88-003),
>
> *this* makes *me* think that document X3J13/88-003 is the *standard* and
> so i conclude that MOP is part of the standard.
What part of ``draft spec'' suggests ``standard''?
Anyway, I don't understand why you are so concerned with these ``limitations''.
Do you actually have a programming problem that requires reflection in the form
of being able to iterate over a structure's slots? Would you know what to do
with MOP? As a complete newbie, you have to learn the basics first before you
can even make value judgments regarding whether something is really a
significant limitation.
Kaz Kylheku wrote:
> In article <··············@pontos.net>, ilias wrote:
>
>>out of the FAQ:
>>
>>
>>>If your Common Lisp includes an implementation
>>>of CLOS that supports the meta-object protocol specified in the
>>>original X3J13 draft spec (document X3J13/88-003),
>>
>>*this* makes *me* think that document X3J13/88-003 is the *standard* and
>>so i conclude that MOP is part of the standard.
>
>
> What part of ``draft spec'' suggests ``standard''?
>
> Anyway, I don't understand why you are so concerned with these ``limitations''.
> Do you actually have a programming problem that requires reflection in the form
> of being able to iterate over a structure's slots?
no
> Would you know what to do with MOP?
tuching his limits.
> As a complete newbie, you have to learn the basics first before you
> can even make value judgments regarding whether something is really a
> significant limitation.
this is false.
From: Tim Bradshaw
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <ey37kirdtgb.fsf@cley.com>
* at news wrote:
> Kaz Kylheku wrote:
>> As a complete newbie, you have to learn the basics first before you
>> can even make value judgments regarding whether something is really a
>> significant limitation.
> this is false.
I can see you're going to do just *fine* here in cll. I'm rather
looking forward to the ritual disembowelling, in particular, although
the bit were we chop your arms and legs off and feed them to
crocodiles is also good.
--tim
Tim Bradshaw wrote:
> * at news wrote:
>
>>Kaz Kylheku wrote:
>>
>>>As a complete newbie, you have to learn the basics first before you
>>>can even make value judgments regarding whether something is really a
>>>significant limitation.
>>
>
>>this is false.
>
>
> I can see you're going to do just *fine* here in cll. I'm rather
> looking forward to the ritual disembowelling, in particular, although
> the bit were we chop your arms and legs off and feed them to
> crocodiles is also good.
feel free.
if you don't feel shame.
ilias wrote:
>> I can see you're going to do just *fine* here in cll. I'm rather
>> looking forward to the ritual disembowelling, in particular, although
>> the bit were we chop your arms and legs off and feed them to
>> crocodiles is also good.
>
> feel free.
>
> if you don't feel shame.
Not at all. We'll all stand round having a laugh, shouting
encouragement. "Oh look, there goes his left leg. Oh, and there goes
his right leg. Ouch. The crock got him by his short and curlies. Bet
that hurt." You know, that sort of thing. The stuff that people who
post to computer language forums on usenet tend to be *really* into.
(sigh).
:(w
"ilias" <·······@pontos.net> wrote in message
·····················@pontos.net...
> Kaz Kylheku wrote:
> > As a complete newbie, you have to learn the basics first before you
> > can even make value judgments regarding whether something is really a
> > significant limitation.
>
> this is false.
>
I agree. If one has a lot of knowledge of languages in general, one can
understand many subtleties of a new language very quickly.
Besides, i see lots of people doing this all the time wrt other languages,
ie confessing to have very little experience with them at the same time as
passing judgment on their capabilities. It isn't always wrong either.
But wrt the current issue (general solution to iterating over a structure's
slots), I don't think ilias' complaints are justified. There are many ways
to skin a cat.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "ilias" <·······@pontos.net> wrote in message
> ·····················@pontos.net...
> > Kaz Kylheku wrote:
> > > As a complete newbie, you have to learn the basics first before you
> > > can even make value judgments regarding whether something is really a
> > > significant limitation.
> >
> > this is false.
> >
>
> I agree. If one has a lot of knowledge of languages in general, one
> can understand many subtleties of a new language very quickly.
That only means that you ``learn the basics'' very quickly, doesn't it?
> But wrt the current issue (general solution to iterating over a
> structure's slots), I don't think ilias' complaints are justified.
> There are many ways to skin a cat.
If he /had/ learned the basics, quickly or not, he wouldn't have asked
this question in the first place, so I think Kaz is right here.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Quoth Nils Goesche <······@cartan.de>:
> "Coby Beck" <·····@mercury.bc.ca> writes:
>
>> "ilias" <·······@pontos.net> wrote in message
>> ·····················@pontos.net...
>> > Kaz Kylheku wrote:
>> > > As a complete newbie, you have to learn the basics first before you
>> > > can even make value judgments regarding whether something is really a
>> > > significant limitation.
>> >
>> > this is false.
>>
>> I agree. If one has a lot of knowledge of languages in general,
>> one can understand many subtleties of a new language very quickly.
>
> That only means that you ``learn the basics'' very quickly, doesn't it?
>
>> But wrt the current issue (general solution to iterating over a
>> structure's slots), I don't think ilias' complaints are justified.
>> There are many ways to skin a cat.
>
> If he /had/ learned the basics, quickly or not, he wouldn't have
> asked this question in the first place, so I think Kaz is right
> here.
I think he's putting the cart before the horse, of defining the
language as being acceptable (or, it seems more likely, not) based on
a problem with a construct (STRUCT) that is contraindicated when
you're trying to do sophisticated metadata lookup.
If you're trying to do really sophisticated things with a data
structure, and it starts getting painful for DEFSTRUCT to do the job,
that's when it makes eminent sense to head to CLOS, which gets you
totally away from the standards-based restrictions of DEFSTRUCT.
For a total newbie to _start_ spelunking in crevices like that is just
silliness.
--
(reverse (concatenate 'string ·············@" "sirhc"))
http://www.ntlug.org/~cbbrowne/lisp.html
"Few people can be happy unless they hate someother person, nation or
creed." -- Bertrand Russell
Christopher Browne wrote:
...
> I think he's putting the cart before the horse, of defining the
> language as being acceptable (or, it seems more likely, not) based on
> a problem with a construct (STRUCT) that is contraindicated when
> you're trying to do sophisticated metadata lookup.
>
> If you're trying to do really sophisticated things with a data
> structure, and it starts getting painful for DEFSTRUCT to do the job,
> that's when it makes eminent sense to head to CLOS, which gets you
> totally away from the standards-based restrictions of DEFSTRUCT.
i'll maybe don't like CLOS.
so i'll maybe implement an own 'CLOS'.
the i'll need what LISP offers.
at the lowest level, with the minimum possible limitations.
with highest degree of flexibiliy at the lowest level.
> For a total newbie to _start_ spelunking in crevices like that is just
> silliness.
i just try to not make a silly decision, based on believing myths and
marketing stuff about the languages and tools.
Before i start coding the systems that i've in my mind in C++ / java, i
look around at another languages first.
I try to evaluate LISP and Smalltalk in the minimum possible time, with
the minimum possible influence of my thinking-processes.
i hope you understand this, and that you'll assist me a little, even if
it is only with your silence.
From: Tim Bradshaw
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <ey3n0rma2jg.fsf@cley.com>
* at news wrote:
> I try to evaluate LISP and Smalltalk in the minimum possible time,
> with the minimum possible influence of my thinking-processes.
I'd suggest that the minimum possible time to evaluate a language
which is not a slight variant on something you already know is about a
year - see http://www.norvig.com/21-days.html. You have to work at
it, too. However you can probably do parallel evaluations to some
extent. Say, maybe, 18 months for CL and SmallTalk. If you want to
become expert in it, it will take 5-10 years (assuming you already are
a fairly fluent programmer).
What you are doing is roughly the equivalent of walking into a nuclear
powerstation and badgering people about whether the lino should be
white or blue.
--tim
Tim Bradshaw wrote:
>
> * at news wrote:
> > I try to evaluate LISP and Smalltalk in the minimum possible time,
> > with the minimum possible influence of my thinking-processes.
>
> I'd suggest that the minimum possible time to evaluate a language
> which is not a slight variant on something you already know is about a
> year - see http://www.norvig.com/21-days.html. You have to work at
> it, too. However you can probably do parallel evaluations to some
> extent. Say, maybe, 18 months for CL and SmallTalk. If you want to
> become expert in it, it will take 5-10 years (assuming you already are
> a fairly fluent programmer).
That's depressingly slow and doesn't correspond with personal experience
in Smalltalk at all. While at Queen Mary Westfield University of London
I took on a reasonably inexperienced programmer to work on a Smalltalk
project in the 80's. The person was an archaeology major who'd done an
MSc conversion course in computing (read 2 years of of a 3 year BSc
doing most of the difficult stuff) and spent a year doing Computer Aided
Learning systems in basic for a defence contractor before he came to
work on my team. Within 6 months he had learnt Smalltalk and
implemented a GUI builder that we used to implement interfaces for a
research project on what-you-see-is-what-i-see shared desktops for IBM.
This was at a time when no commercial smalltalk *had* a GUI builder. He
not only achieved an adequate degree of mastery in 6 months he then
implemented a cutting-edge tool that the rest of the team was able to
use, and to boot, had come from a humanities background.
I have anecdotal evidence of other people who have been able to
implement significant and interesting systems in Smalltalk (such as a
visual functional language for a Ph.D. where functions could be composed
via drag-and-drop). Based on this experience I find your estimates of
how long it takes to achieve depressingly tardy and wonder if it points
to more fundamental problems. Have you actually learnt Smalltalk? If
so, what was your learning experience like there-in?
I don't want to start a flame war but if it is that lisp mastery does
take 5 years for strong programmers then I suggest lisp is far harder to
learn and master than Smalltalk. Predudicially I wouldn't be surprised
because Smalltalk has strong pedagogical underpinnings; amongst its
principal design goals are explorability, readability and
comprehensibility.
>
> What you are doing is roughly the equivalent of walking into a nuclear
> powerstation and badgering people about whether the lino should be
> white or blue.
This is possibly ludicrously condescending. What if ilias has already
done MOP-ish things in other languages and is surprised (as I was when I
implemented a pickling facility for - dare I mention its name here? -
Dylan) that there is no standard iterate-over-slots-by-index reflection
facility for Lisp. That surprise doesn't indicate an inability to use
or master the CLOS MOP, it just indicates that there is considerable
variation amongst MOPs and that there is much to be learned by using
different ones. But to suggest that someone, by asking to do something
quotidian in Smalltalk, Java and Modula3 MOPs, is somehow unable to use
the CLOS MOP without terrible problems (I take it that's what you mean
by "walking into a nuclear powerstation and badgering people about
whether the lino should be white or blue") is extremely condescending.
If that's not what you meant then please elucidate.
--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
Eliot Miranda wrote:
> I don't want to start a flame war but if it is that lisp mastery does
> take 5 years for strong programmers then I suggest lisp is far harder to
> learn and master than Smalltalk. Predudicially I wouldn't be surprised
> because Smalltalk has strong pedagogical underpinnings; amongst its
> principal design goals are explorability, readability and
> comprehensibility.
There is a huge gap between a programmer who is good enough to write
non-trivial applications and an actual language _expert_ .
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
>
> Eliot Miranda wrote:
>
> > I don't want to start a flame war but if it is that lisp mastery does
> > take 5 years for strong programmers then I suggest lisp is far harder to
> > learn and master than Smalltalk. Predudicially I wouldn't be surprised
> > because Smalltalk has strong pedagogical underpinnings; amongst its
> > principal design goals are explorability, readability and
> > comprehensibility.
>
> There is a huge gap between a programmer who is good enough to write
> non-trivial applications and an actual language _expert_ .
Define "huge gap"; but more to the point define "expert". IMO, mastery
"in" a language (ability to solve problems using the language) is as
valid and laudable as mastery "of" a language (ability to
maintain/extend a language). A master in a language is still an
expert. Masters "in" a language may and do use "exotic" features like
MOPs. Feels to me like you're pushing some status agenda. Does one
have to be a language lawyer to use Lisp? If so, that's a serious flaw;
any language that requires a programmer to have mastered a non-trivial
programming system to language lawyer level is too difficult to use. I
don't think Lisp *is* such a system.
So what's your point?
--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
Eliot Miranda wrote:
>
>
> Jochen Schmidt wrote:
>>
>> Eliot Miranda wrote:
>>
>> > I don't want to start a flame war but if it is that lisp mastery does
>> > take 5 years for strong programmers then I suggest lisp is far harder
>> > to
>> > learn and master than Smalltalk. Predudicially I wouldn't be surprised
>> > because Smalltalk has strong pedagogical underpinnings; amongst its
>> > principal design goals are explorability, readability and
>> > comprehensibility.
>>
>> There is a huge gap between a programmer who is good enough to write
>> non-trivial applications and an actual language _expert_ .
>
> Define "huge gap"; but more to the point define "expert". IMO, mastery
> "in" a language (ability to solve problems using the language) is as
> valid and laudable as mastery "of" a language (ability to
> maintain/extend a language). A master in a language is still an
> expert. Masters "in" a language may and do use "exotic" features like
> MOPs. Feels to me like you're pushing some status agenda. Does one
> have to be a language lawyer to use Lisp? If so, that's a serious flaw;
> any language that requires a programmer to have mastered a non-trivial
> programming system to language lawyer level is too difficult to use. I
> don't think Lisp *is* such a system.
No one does not have to be a language lawyer and not even a language expert
to _use_ Lisp (or Smalltalk).
> So what's your point?
My point was simply that there is a difference between someone who is able
to use a language in a useful and non-trivial way and someone who has a
*deep* understanding of a language and all its environment. I think the
claim that one needs ~5-10 years to get an expert programmer even in
languages like Lisp or Smalltalk. If it would be true what you say that one
reaches this level of comprehensability in several months then you actually
claim that those programmers who use the language for several years (> 5
years) do not really learn anything more - I do not believe that.
And please recognize that I actually tried to fullfill your wish not to
start a flame war - I simply tried to ask your question from how I
understand it - so please stop that "define every word you use" flaming
mode. You could have simply asked politely if you by yourself are really
not interested in a flamewar.
ciao,
Jochen
--
http://www.dataheaven.de
From: Tim Bradshaw
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <ey33ctexpp5.fsf@cley.com>
* Eliot Miranda wrote:
> I have anecdotal evidence of other people who have been able to
> implement significant and interesting systems in Smalltalk (such as
> a visual functional language for a Ph.D. where functions could be
> composed via drag-and-drop). Based on this experience I find your
> estimates of how long it takes to achieve depressingly tardy and
> wonder if it points to more fundamental problems. Have you actually
> learnt Smalltalk? If so, what was your learning experience like
> there-in?
I have a nodding acquaintance with it, I wrote some mildly non-trivial
things some years ago.
> I don't want to start a flame war but if it is that lisp mastery
> does take 5 years for strong programmers then I suggest lisp is far
> harder to learn and master than Smalltalk. Predudicially I wouldn't
> be surprised because Smalltalk has strong pedagogical underpinnings;
> amongst its principal design goals are explorability, readability
> and comprehensibility.
I stand by my claim. There is really a lot of evidence that some
skills just take a huge amount of effort to learn. Take playing a
musical instrument: how long does it take to become good at it? Well,
about 5-10 years, and you have to practice really hard, too. It
doesn't seem to matter much whether it's something superficially
`easy' like the piano (basic tone production is solved by the
instrument), or something superficially `hard' like the violin where
it's a fair amount of work just to make the thing make a bearable
noise. In several thousand years of trying, no-one has managed to
make an instrument that is significantly easier to play.
Of course there are always prodigies, but if you look at them, one
interesting thing is that they get so good by doing it *all the time*.
Someone like Mozart spent a *huge* amount of time playing an
instrument. Jimi Hendrix - who, whether you like what he did or not
(I don't, much) was *clearly* some kind of prodigy - spent a really
amazing amount of time just playing the guitar: possibly most of his
waking hours.
Take physics, or maths. How hard do you have to work to become a
first-rate physicist? Very hard, and for 5-10 years. If you start
seriously when you are 17, you will probably be fluent by the time you
are 23-25, and you'll be really good when you're 30. What about the
prodigies? They work even harder. I've seen this at first hand: I
had a chance to be an academic physicist (well, people said so), but I
was just too lazy, and I gave up my PhD. It wasn't because I couldn't
do it, it was because I *didn't work hard enough*.
There are lots of things that are like this, from physics to
blacksmithing. I call these things `craft skills' because they are
typically learnt in some kind of craft setting where people do an
apprenticeship of some kind (and yes, I think physics is a craft
skill: what is a PhD if not an apprenticeship?).
I think programming languages are craft skills, too, and I see no
evidence to counter this. There may be programming languages you can
learn fast, but that's because they are cripplingly lacking in power,
so yes, you don't need to learn much, but that's because you haven't
got far.
Here's a reason why this is true. Let's assume that it's false, and
that there is some language x in which you can become really fluent in
a year, and which is as powerful and flexible as the best of other
languages. This language is a *silver bullet*: anyone using it will
have a *four year advantage* on someone using a normal language. A
four year advantage is enough to make it very hard for *anyone* to
compete. Even a huge monopolist with billions of dollars to spend,
like MS, will find it hard to kill the people who got there four years
earlier. (This is why, incidentally, I think that Itanic is likely to
fail - even though Intel have billions of dollars to spend (and have
spent billions on it), they are probably even more than four years
late to the 64bit market, and they will struggle to displace the
systems that already exist and are deployed in large numbers. They
may succeed because high-level languages mean that the underlying CPU
isn't too important so long as it works and has a big enough address
space.) People using this language x will simply wipe the floor with
the opposition, and walk away with all the money.
But we don't see this happen. Instead the people and languages who
are doing the floor-wiping are the people and languages who manage to
get some kind of monopoly lock. C won because it was incestuously
related to Unix which became the OS of choice because it happened to
run on two generations of popular HW (PDP11 and Vax), and it was given
away to academic institutions. VB is a big deal because MS have worked
strenuously for 15 years to get a monopoly lock on the desktop. C#
might beat Java because of this same lock. Outside of the monopolies
there's competition. Perl beat awk and sed, but Python competes with
it, C++ competes with Java competes with Cobol, and so on. There is,
sadly, less competition than there was because the monopolies have got
so powerful that they have just stifled a lot of it.
My conclusion is that this silver bullet language, x, does not exist,
any more than silver bullet musical instruments exist. Given how rich
you would get if you invented it, I believe that it is not likely that
such a language can exist. Fred Brooks write a rather famous essay on
this, and I think he's right.
What does this say about Lisp, which is often touted as a silver
bullet language that is somehow much more powerful than ordinary
languages? Well, I think it is more powerful, actually: good Lisp
programmers can wipe the floor with lots of other languages. But
Bradshaw's law of conservation of skill applies: because you can do
more with Lisp, it takes you longer to become fluent in it. If you
need to solve tasks that are hard, then you need a certain amount of
skill to do that, and it takes you a certain amount of work to acquire
that skill and thus a certain amount of time. So this is why Lisp
people don't clean up: they take longer to cook. Lisp is not language
x.
This may well be true of SmallTalk too, I'm not familiar enough with
it to say. However if you think it's not true - if you think that
SmallTalk is language x - you need to explain why it has not cleaned
up.
> This is possibly ludicrously condescending. What if ilias has
> already done MOP-ish things in other languages and is surprised (as
> I was when I implemented a pickling facility for - dare I mention
> its name here? - Dylan) that there is no standard
> iterate-over-slots-by-index reflection facility for Lisp.
I can only use the evidence of my eyes, and it doesn't look that way.
--tim
(Note in all the above: I'm not talking about Turing power when I say
a is more powerful than b.)
Tim Bradshaw <···@cley.com> writes:
> Take physics, or maths. How hard do you have to work to become a
> first-rate physicist? Very hard, and for 5-10 years. If you start
> seriously when you are 17, you will probably be fluent by the time you
> are 23-25, and you'll be really good when you're 30. What about the
> prodigies? They work even harder. I've seen this at first hand: I
> had a chance to be an academic physicist (well, people said so), but I
> was just too lazy, and I gave up my PhD. It wasn't because I couldn't
> do it, it was because I *didn't work hard enough*.
Supposedly there exists a "ten-year rule" amongst certain creativity
researchers which states that an individual is incapable of making a
significant contribution to a given field without at least ten years
of significant preparation.
There is a discussion of this rule in an article by Carol S. Dweck
entitled "Beliefs That Make Smart People Dumb" in "Why Smart People
Can Be So Stupid", edited by Robert J. Sternberg, 24-41. Erik Naggum
cited the larger publication's introduction in this group about two
months ago. I hope other people have had a chance to pick up this
book, I very much enjoyed reading a number of its chapters. Thanks,
Erik.
In article <···············@panix3.panix.com>, Carl Shapiro
<·············@panix.com> wrote:
>Tim Bradshaw <···@cley.com> writes:
>
>> Take physics, or maths. How hard do you have to work to become a
>> first-rate physicist? Very hard, and for 5-10 years. If you start
>> seriously when you are 17, you will probably be fluent by the time you
>> are 23-25, and you'll be really good when you're 30. What about the
>> prodigies? They work even harder. I've seen this at first hand: I
>> had a chance to be an academic physicist (well, people said so), but I
>> was just too lazy, and I gave up my PhD. It wasn't because I couldn't
>> do it, it was because I *didn't work hard enough*.
>
>Supposedly there exists a "ten-year rule" amongst certain creativity
>researchers which states that an individual is incapable of making a
>significant contribution to a given field without at least ten years
>of significant preparation.
Herb Simon and others who study expertise have made the claim
that achieving expertise requires ten years of concentrated
study and practice, and have collected data to back up this
claim in domains ranging from chess to pole vaulting. IIRC,
Simon cites Bobby Fisher as one of the rare exceptions -- he
progressed from chess beginner to grand master in just over
nine years.
From: Erik Naggum
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <3238601790221618@naggum.no>
* Carl Shapiro
| Supposedly there exists a "ten-year rule" amongst certain creativity
| researchers which states that an individual is incapable of making a
| significant contribution to a given field without at least ten years of
| significant preparation.
I thought that was "tenure". (Sorry.)
| Thanks, Erik.
I'm happy that the recommendation was well received.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
In article <················@naggum.no>, Erik Naggum wrote:
> * Carl Shapiro
> | Supposedly there exists a "ten-year rule" amongst certain creativity
> | researchers which states that an individual is incapable of making a
> | significant contribution to a given field without at least ten years of
> | significant preparation.
>
> I thought that was "tenure". (Sorry.)
>
> | Thanks, Erik.
>
> I'm happy that the recommendation was well received.
I just ordered that on, but so far I have bought:
a rulebook for arguments
asking the right questions
choosing civility
and the at of reasoning(still reading it)
So far all of them have been good and useful books.
So Erik please make more recommendations, you are a force multiplier
where reading is concerned.
Thanks
marc
>
> --
> Erik Naggum, Oslo, Norway
>
> Act from reason, and failure makes you rethink and study harder.
> Act from faith, and failure makes you blame someone and push harder.
From: Erik Naggum
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <3238543378011762@naggum.no>
* Tim Bradshaw <···@cley.com>
| I'd suggest that the minimum possible time to evaluate a language which is
| not a slight variant on something you already know is about a year - see
| http://www.norvig.com/21-days.html. You have to work at it, too. However
| you can probably do parallel evaluations to some extent. Say, maybe, 18
| months for CL and SmallTalk. If you want to become expert in it, it will
| take 5-10 years (assuming you already are a fairly fluent programmer).
This is unduly pessimistic. If you sit down with the standard and spend the
time it takes to read it /in its own right/ instead of primarily trying to
figure out if it is just like something you already know, it should take 18
months to become an expert. You will be an expert on the language, but not
an expert user of the language. I contend that if you try to become an
expert user of a language without knowing the language, /you will fail/.
I maintain that it is far better for a person to be able to read well than
it is to write well. You become a good writer by reading diligently and
with great interest in how and what other people write. You cannot possibly
become a good writer simply by writing a lot. Nor is it the intention in
advanced societies that each person should start out in life from scratch.
We have public education systems to ensure that people have a really good
chance of not being completely ignorant of how the world they live in works
when they reach the age of suffrage and can inflict harm on society with
their ignorance if they vote for, say, George W. Bush. For a person to be
able to write well, they would have to read several orders of magnitude more
than they write. I fail to understand how programming is any different, yet
I see a lot of people who effectively argue that reading other people's code
would turn them into /worse/ programmers. Few people today argue that
correct spelling is optional, but it appears that some part of the compulsory
education system has failed when more and more writers of English are
amazingly incompetent spellers. Being /aware/ that you spell a word in a
different way than other people and accepted authorities is a necessary
condition for learning to spell right, however. Some people think that this
is undemocratic or object to it on some ideological grounds, just like some
people argue against using standards and specifications in programming.
Reading and understanding specifications is a /prerequisite/ for writing
good code. Being able to subjugate one's personal desires to that of other
people is a /prerequisite/ for working in a team, for other people, and is a
goddamn /requirement/ to make code that works for any other person.
Therefore, being able to read a specification like a standard and submitting
to its requirements instead of thinking "I can do better, I in fact, I /am/
better, than this" and thus screwing up for everybody else.
If you only sit down to toy with a language until you "get it", and refuse
to study it seriously, including reading specifications and other people's
code, you end up writing code like some people write SMTP or NNTP servers
and mail and news software in general -- and your code will rely on the
ability of others to be liberal in what they accept. It is a really bad idea
to believe that one can learn to get it right from doing it wrong many times.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Tim Bradshaw
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <ey3vg69x5tv.fsf@cley.com>
* Erik Naggum wrote:
> This is unduly pessimistic. If you sit down with the standard and
> spend the time it takes to read it /in its own right/ instead of
> primarily trying to figure out if it is just like something you
> already know, it should take 18 months to become an expert. You
> will be an expert on the language, but not an expert user of the
> language. I contend that if you try to become an expert user of a
> language without knowing the language, /you will fail/.
Yes, I'm sorry, I should have said `expert user of' rather than
`expert in', as it's the user of part that I'm mostly interested in.
I agree that becoming an expert in a language can be faster, and is a
prerequisite to becoming an expert user of the language.
--tim
From: Aleksandr Skobelev
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <m365y9s7su.fsf@list.ru>
Tim Bradshaw <···@cley.com> writes:
> * Erik Naggum wrote:
>
> > This is unduly pessimistic. If you sit down with the standard and
> > spend the time it takes to read it /in its own right/ instead of
> > primarily trying to figure out if it is just like something you
> > already know, it should take 18 months to become an expert. You
> > will be an expert on the language, but not an expert user of the
> > language. I contend that if you try to become an expert user of a
> > language without knowing the language, /you will fail/.
>
> Yes, I'm sorry, I should have said `expert user of' rather than
> `expert in', as it's the user of part that I'm mostly interested in.
> I agree that becoming an expert in a language can be faster, and is a
> prerequisite to becoming an expert user of the language.
I've just remembered a book I read some years ago. It was "Designing and
Programming Personal Expert Systems" by Carl Townsend and Dennis Feucht
translated into Russian. Authors claims that an expert in a given domain
differs from a nonexpert by an ability to create chunks (chanks ?)
(bundles of facts and links between them, that are stored and retrieved
as whole things). Average specialist remembers from 50000 to 100000
chunks. It requires 10-20 years to create such volume of data in a man
memory.
On 17 Aug 2002 03:22:58 +0000, Erik Naggum <····@naggum.no> wrote:
> than they write. I fail to understand how programming is any different, yet
> I see a lot of people who effectively argue that reading other people's code
> would turn them into /worse/ programmers. Few people today argue that
Well, it depends:
"The best way to prepare [to be a programmer] is to write programs, and
to study great programs that other people have written. In my case, I
went to the garbage cans at the Computer Science Center and I fished out
listings of their operating system". -- Bill Gates
This tells something about the quality of Mr. Gates' products: garbage in,
garbage out :)
By the way, do you have any suggestions for especially interesting Lisp
code to read?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
From: Eduardo Muñoz
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <uwuqo9qt8.fsf@jet.es>
Paolo Amoroso <·······@mclink.it> writes:
> By the way, do you have any suggestions for especially interesting Lisp
> code to read?
(Jumping over USENET rules)
Me too!
I am a big fan of learning by reading. The
signal/noise ratio of this newsgroup is quite good
but (* traffic (/ code signal)) is a bit low.
--
Eduardo Mu�oz
Tim Bradshaw wrote:
> * at news wrote:
>
>>I try to evaluate LISP and Smalltalk in the minimum possible time,
>>with the minimum possible influence of my thinking-processes.
>
>
> I'd suggest that the minimum possible time to evaluate a language
> which is not a slight variant on something you already know is about a
> year - see http://www.norvig.com/21-days.html. You have to work at
> it, too. However you can probably do parallel evaluations to some
> extent. Say, maybe, 18 months for CL and SmallTalk. If you want to
> become expert in it, it will take 5-10 years (assuming you already are
> a fairly fluent programmer).
>
> What you are doing is roughly the equivalent of walking into a nuclear
> powerstation and badgering people about whether the lino should be
> white or blue.
>
> --tim
what are you doing there? taking one paragrah, bringing my words out of
context, and the comment?
it will take me not more the one month to take my decision. And this
while working fulltime on a project in C++.
"...i try to evaluate [as deep as i need]...".
for you to remember, the *full* post you answered to.
> i'll maybe don't like CLOS.
>
> so i'll maybe implement an own 'CLOS'.
>
> the i'll need what LISP offers.
>
> at the lowest level, with the minimum possible limitations.
>
> with highest degree of flexibiliy at the lowest level.
>
...
> i just try to not make a silly decision, based on believing myths and marketing stuff about the languages and tools.
>
> Before i start coding the systems that i've in my mind in C++ / java, i look around at another languages first.
>
> I try to evaluate LISP and Smalltalk in the minimum possible time, with the minimum possible influence of my thinking-processes.
>
> i hope you understand this, and that you'll assist me a little, even if it is only with your silence.
ilias <·······@pontos.net> writes:
> I try to evaluate LISP and Smalltalk in the minimum possible time,
> with the minimum possible influence of my thinking-processes.
That much is obvious to all of us, yes.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
On Sat, 17 Aug 2002 00:13:34 +0300, ilias <·······@pontos.net> wrote:
> I try to evaluate LISP and Smalltalk in the minimum possible time, with
> the minimum possible influence of my thinking-processes.
This is a worthy goal for compiler writers.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Paolo Amoroso <·······@mclink.it> writes:
> On Sat, 17 Aug 2002 00:13:34 +0300, ilias <·······@pontos.net> wrote:
>
> > I try to evaluate LISP and Smalltalk in the minimum possible time, with
> > the minimum possible influence of my thinking-processes.
>
> This is a worthy goal for compiler writers.
I think you mean compilers themselves. :)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Nils Goesche wrote:
> If he /had/ learned the basics, quickly or not, he wouldn't have asked
> this question in the first place, so I think Kaz is right here.
which question do you mean?
Coby Beck wrote:
...
> But wrt the current issue (general solution to iterating over a structure's
> slots), I don't think ilias' complaints are justified. There are many ways
> to skin a cat.
i don't want to get in details.
i found a limitation in LISP, which i'm wondering about.
and i try to clarify the status of this limitation.
but, as usual, very less precise information and many screams.
newbie.
abstraction.
generalisation.
independent thinking.
good night.
ilias <·······@pontos.net> writes:
> i found a limitation in LISP, which i'm wondering about.
You're a troll, right? Right??
You did _not_ "find a limitation" in lisp in your first week
of perusal. Just take my word for it.
If you want to prove you're not a troll, do the following:
* don't answer this post
* spend 3 months studying and lurking before you profess
any more "opinions" or "discoveries"
* try to realize that an army of people quasi-infinitely
smarter than you are have designed lisp.
Perhaps, then, in 3 months, you'll discover that those
"limitations" are in your mind.
Eventually you might be lucky enough to understand enough
that, when you fail to understand how or why something was
done the way it is, you'll think "Hum, interesting, I wonder
what _I_'m missing?" At that stage you're ready to ask
intelligent questions.
Good luck.
[I have not the slightest hope that this advice will
be heeded, of course. This person is about to irrevocably
place himself in the troll category.]
Alain Picard wrote:
> ilias <·······@pontos.net> writes:
>
>> i found a limitation in LISP, which i'm wondering about.
>
> You're a troll, right? Right??
I'm not _so_ sure about that. He is a bit nasty in some words yes - but I
still think that he really wants to learn Lisp. We could give him at least
a chance. His posts are obviously on topic even if he is not necessarily
right in any of his claims.
To the topic of iterating over structure slots. I want to emphasise that
such things are much less a problem if one uses CLOS and classes instead of
structures. Most (all?) CLs which support CLOS seem to support accessing
the slots of a class - even if they do not support the remaining parts of
the MOP. So _maybe_ this is a limitation of _structures_ in some
implementations but it is not a limitation in Common Lisp qua language.
Claiming that it is a limitation of the language would be the same like
claiming that fixnums are cannot grow arbitrary big (as one should choose
bignums to get this...).
ciao,
Jochen
--
http://www.dataheaven.de
From: Erik Naggum
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <3238605071286211@naggum.no>
* Jochen Schmidt
| I'm not _so_ sure about that. He is a bit nasty in some words yes - but I
| still think that he really wants to learn Lisp. We could give him at least a
| chance. His posts are obviously on topic even if he is not necessarily right
| in any of his claims.
This is interesting. /ilias/ is "on topic"? And what about all the chances he
deliberately squandered? Seriously, this is an ill-behaved runt that people
should not respond to.
| I want to emphasise that such things are much less a problem if one uses CLOS
| and classes instead of structures. […] Claiming that it is a limitation of
| the language would be […] like claiming that fixnums […] cannot grow
| arbitrary big (as one should choose bignums to get this...).
Precisely—it is a feature. Persisting in arguing that it is a limitation when
people tell you otherwise is annoying and only goes to show a lack of desire to
learn the language coupled with a desire to "fix" it. Structures have better
optimizability because their layout is known at compile time, redefinition is
not defined, and single inheritance can only append slots. Choose structures
if you are willing to give up some of the flexibility in exchange for different
performance. Choose classes if you want the flexibility back. Portability
between structures and classes is limited to the constructor functions.
[This should double as a test of posting with UTF-8.]
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
> * Jochen Schmidt
> | I'm not _so_ sure about that. He is a bit nasty in some words yes
- but I
> | still think that he really wants to learn Lisp. We could give him
at least a
> | chance. His posts are obviously on topic even if he is not
necessarily right
> | in any of his claims.
>
> This is interesting. /ilias/
my firstname is something very personal to me.
you've replied not one time directly to my posts.
but you quote my name.
be friendly.
choose civility.
> is "on topic"?
of course i am.
i start the topic.
i know the exact reasons why i've done that.
it looks like you don't.
> And what about all the chances he
> deliberately squandered?
maybe i'm the one who's giving chances.
> Seriously, this is an ill-behaved runt that people
> should not respond to.
i bet your pardon?
be friendly.
choose civility.
> | I want to emphasise that such things are much less a problem if one
uses CLOS
> | and classes instead of structures. […] Claiming that it is a
limitation of
> | the language would be […] like claiming that fixnums […] cannot grow
> | arbitrary big (as one should choose bignums to get this...).
>
> Precisely—it is a feature.
i understand your thought.
you are correct.
but with limits. see below.
> Persisting in arguing that it is a limitation when
> people tell you otherwise is annoying
'argue'.
'tell'.
sorry, if anyone feels annoyed.
> and only goes to show a lack of desire to
> learn the language coupled with a desire to "fix" it.
i've generally a high tendencies to fix.
see my first post in c.l.l.
> Structures have better
> optimizability because their layout is known at compile time,
the layout is know at compile time.
so it should be not a problem, to allow accessing the structure
- by index
- by name
- by telephone-number of your last date.
- by smell
> redefinition is
> not defined, and single inheritance can only append slots.
redefinition?
who cares?
off-topic.
> Choose structures
> if you are willing to give up some of the flexibility in exchange for
different
> performance. Choose classes if you want the flexibility back.
this is ok.
but the implementation of structs in CL raises limitations, that are not
neccessary.
(defstruct_like_ilias_wants () (....))
> Portability
> between structures and classes is limited to the constructor functions.
you forgot the 'flexibility' you've stated above.
you forgot the 'limitation' of the structs.
*switch*
when was the last time you look at water?
take a glas.
feel it.
From: Erik Naggum
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <3238710471513040@naggum.no>
* ·····@lazaridis.de
| you've replied not one time directly to my posts.
Your articles are not worth the energy required to breathe while reading them.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Naggum wrote:
> * ·····@lazaridis.de
> | you've replied not one time directly to my posts.
>
> Your articles are not worth the energy required to breathe while reading them.
unfriendly: taking my words out of the context, forcing them to have
another essence.
i don't care if you reply directly to my post.
i don't care about how you rate my 'articles'.
one more time what i said (in context):
> Erik Naggum wrote:
>> * Jochen Schmidt
>> | I'm not _so_ sure about that. He is a bit nasty in some words yes - but I
>> | still think that he really wants to learn Lisp. We could give him at least a
>> | chance. His posts are obviously on topic even if he is not necessarily right
>> | in any of his claims.
>>
>> This is interesting. /ilias/
>
> my firstname is something very personal to me.
> you've replied not one time directly to my posts.
> but you quote my name.
>
> be friendly.
> choose civility.
and no choose:
- pick again whaterver part you want, take it out of context, and
express what you like to express.
- say a friendly 'i'm sorry' in a direct or indirect form.
·····@lazaridis.de writes:
> > and only goes to show a lack of desire to
> > learn the language coupled with a desire to "fix" it.
>
> i've generally a high tendencies to fix.
> see my first post in c.l.l.
If so, you do so by writing code which provides a unified general
accessor for structs across various CL implementations and sharing it
with others. That would be a fix. Arguing semantics with the denizens
of c.l.l is not fixing it. Cursory examinations of CMUCL reveal that
it is possible to access the layout of structs via their PCL class so
the machinery is there to overcome this limitation. I would wager
that across most of the CLs in use today it would not be difficult,
but cannot speak from direct experience.
Then if such a thing exists we can use it as a group and decide if its
something ready for a standardization effort.
--
Sincerely,
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
From: Tim Bradshaw
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <ey31y8v5j58.fsf@cley.com>
* Craig Brozefsky wrote:
[About slot information for structure objects]
> I would wager
> that across most of the CLs in use today it would not be difficult,
> but cannot speak from direct experience.
Any implementation that has a decent INSPECT / DESCRIBE will have this
functionality somewhere.
--tim
Craig Brozefsky wrote:
> ·····@lazaridis.de writes:
>
>
>> > and only goes to show a lack of desire to
>> > learn the language coupled with a desire to "fix" it.
>>
>>i've generally a high tendencies to fix.
>>see my first post in c.l.l.
>
>
> If so, you do so by writing code which provides a unified general
> accessor for structs across various CL implementations and sharing it
> with others. That would be a fix.
prior to fixing comes analyzing and understanding.
> Arguing semantics with the denizens
> of c.l.l is not fixing it.
i try to collect information, to analyze, to understand.
> Cursory examinations of CMUCL reveal that
> it is possible to access the layout of structs via their PCL class so
> the machinery is there to overcome this limitation. I would wager
> that across most of the CLs in use today it would not be difficult,
> but cannot speak from direct experience.
>
> Then if such a thing exists we can use it as a group and decide if its
> something ready for a standardization effort.
i don't know at this point if it is even worth to spent time with
structures (i mean for me, personally).
see the seperate topic "LISP - why learnig / using structures", i don't
know how to give you a link, may this works:
·····················@pontos.net
ilias <·······@pontos.net> writes:
> i try to collect information, to analyze, to understand.
Then collect it from the only place you can, experimentation and
experience with the different implementations you are concerned with
supporting and see youself using.
--
Sincerely,
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
From: Tim Bradshaw
Subject: Re: MOP - Part of the standard or not?
Date:
Message-ID: <ey3sn1avs8w.fsf@cley.com>
* Craig Brozefsky wrote:
> If so, you do so by writing code which provides a unified general
> accessor for structs across various CL implementations and sharing it
> with others.
Have a look at http://www.tfeb.org/programs/dssv.tar.gz. It's not
`general' - it relies on shadowing DEFSTRUCT with a version that
records slot information, but it is MOP-free and pretty simple (90% of
the complexity is parsing DEFSTRUCT forms to work out the accessor
names, and this may be buggy - it works for my structures). It's
designed as something that you could load early in some program and
which would then allow access to the slots of all structures the
program defines.
Of course it won't satisfy the OP because, well, because he'd rather
have endless discussions about trivia than learn anything, but who
cares about him? Certainly not me.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Craig Brozefsky wrote:
>
> > If so, you do so by writing code which provides a unified general
> > accessor for structs across various CL implementations and sharing it
> > with others.
>
> Have a look at http://www.tfeb.org/programs/dssv.tar.gz. It's not
> `general' - it relies on shadowing DEFSTRUCT with a version that
> records slot information, but it is MOP-free and pretty simple (90% of
> the complexity is parsing DEFSTRUCT forms to work out the accessor
> names, and this may be buggy - it works for my structures). It's
> designed as something that you could load early in some program and
> which would then allow access to the slots of all structures the
> program defines.
This is one of the solutions that I was thinking of when looking at
CMUCL. I'm actually more inclined to rely upon MOP and deal with
inconsistencies. This could be because in the the field of CL systems
I am familiar with, MOP variations are not diverse enough to be a
major problem. Even without a MOP I would imagine some internal
inspectors to be available.
All that said, I rarely use structs.
--
Craig Brozefsky <·····@onshored.com> Senior Programmer
onShore Development http://www.onshore-devel.com
Free Common Lisp Software http://alpha.onshored.com/lisp-software
Erik Naggum wrote:
> * Jochen Schmidt
> | I'm not _so_ sure about that. He is a bit nasty in some words yes
- but I
> | still think that he really wants to learn Lisp. We could give him
at least a
> | chance. His posts are obviously on topic even if he is not
necessarily right
> | in any of his claims.
>
> This is interesting. /ilias/
my firstname is something very personal to me.
you've replied not one time directly to my posts.
but you quote my name.
be friendly.
choose civility.
> is "on topic"?
of course i am.
i start the topic.
i know the exact reasons why i've done that.
it looks like you don't.
> And what about all the chances he
> deliberately squandered?
maybe i'm the one who's giving chances.
> Seriously, this is an ill-behaved runt that people
> should not respond to.
i bet your pardon?
be friendly.
choose civility.
> | I want to emphasise that such things are much less a problem if one
uses CLOS
> | and classes instead of structures. […] Claiming that it is a
limitation of
> | the language would be […] like claiming that fixnums […] cannot grow
> | arbitrary big (as one should choose bignums to get this...).
>
> Precisely—it is a feature.
i understand your thought.
you are correct.
but with limits. see below.
> Persisting in arguing that it is a limitation when
> people tell you otherwise is annoying
'argue'.
'tell'.
sorry, if anyone feels annoyed.
> and only goes to show a lack of desire to
> learn the language coupled with a desire to "fix" it.
i've generally a high tendencies to fix.
see my first post in c.l.l.
> Structures have better
> optimizability because their layout is known at compile time,
the layout is know at compile time.
so it should be not a problem, to allow accessing the structure
- by index
- by name
- by telephone-number of your last date.
- by smell
> redefinition is
> not defined, and single inheritance can only append slots.
redefinition?
who cares?
off-topic.
> Choose structures
> if you are willing to give up some of the flexibility in exchange for
different
> performance. Choose classes if you want the flexibility back.
this is ok.
but the implementation of structs in CL raises limitations, that are not
neccessary.
(defstruct_like_ilias_wants () (....))
> Portability
> between structures and classes is limited to the constructor functions.
you forgot the 'flexibility' you've stated above.
you forgot the 'limitation' of the structs.
*switch*
when was the last time you look at water?
take a glas.
feel it.
Alain Picard wrote:
> ilias <·······@pontos.net> writes:
>
>
>>i found a limitation in LISP, which i'm wondering about.
>
>
> You're a troll, right? Right??
>
> You did _not_ "find a limitation" in lisp in your first week
> of perusal. Just take my word for it.
i've found a limitation in LISP:
my post was:
> LISP limits?
>
> or a typo?
>
>
>> http://www.paulgraham.com/popular.html
>>
>> Being Popular
>>
>> May 2001
>>
>> (This article was written as a kind of business plan for a new
>> ...
>> 4 Hackability
>>
>> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of
>> ...
>> In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
>>
>> is this limitation true?
some people here in c.l.l confirm this limitation.
if you have concrete informations about how to overcome this limitation
(something that is implemented by major CL-vendors, if possible
compatible across the different implementations), please let me know.
thank you.
In article <················@pontos.net>, ilias wrote:
> Alain Picard wrote:
>> ilias <·······@pontos.net> writes:
>>
>>
>>>i found a limitation in LISP, which i'm wondering about.
>>
>>
>> You're a troll, right? Right??
>>
>> You did _not_ "find a limitation" in lisp in your first week
>> of perusal. Just take my word for it.
>
> i've found a limitation in LISP:
You found someone else's expression that he perceives a limitation in Lisp.
That someone else has somehow, in spite of that limitation, profited greatly
from the use of Lisp. By profited, I of course mean dollars. Millions of them.
This is no secret; he himself has informed the word about this, and claimed
that Lisp was a big ingredient in his success. You can read all about it
on his website.
He is now promoting a new programming language. That new programming langauge
would not be even slightly interesting if it could not claim to correct some
limitations in Lisp.
One must read things in their proper context.
>>> http://www.paulgraham.com/popular.html
Note that nearly everyone here is quite familiar with the writings at
www.paulgraham.com. You are not surprising anyone with your citations from
this material.
> if you have concrete informations about how to overcome this limitation
> (something that is implemented by major CL-vendors, if possible
> compatible across the different implementations), please let me know.
If you know of a concrete software project which apparently cannot proceed
without overcoming this limitation, and is willing to pay a developer to solve
the problem, please let me know.
If you know of an ISO- or ANSI-standard programming language, which is more
powerful than Common Lisp, and has equally great vendor support, please let me
know also.
How much other functionality are you willing to *lose* in switching to
a language which has built-in reflection in the form of enumerating
the slots of a structure?
Note Paul Graham's stated reasons for wanting to do that: hunting down
references to objects, and finding uninitialized values. The hidden
implication is that these things are important to do. But hunting down
references to objects is unnecessary, because garbage collection does that.
Finding uninitialized values is unnecessary because Lisp structures don't have
uninitialized values. Slots which have no :initform are initialized with the
value NIL.
(defstruct x (a)(b)(c))
(make-x) ==> #S(X :A NIL :B NIL :C NIL)
ilias <·······@pontos.net> writes:
> if you have concrete informations about how to overcome this
> limitation (something that is implemented by major CL-vendors, if
> possible compatible across the different implementations), please let
> me know.
Sure, use CLOS or write your own generic struct API unifying the
variations betwixt the implementations and providing a portable,
internally consistent interface, perhaps contribute it to CLOCC.
The limitation is not CL, it's the replacement of your real goal with
a miguided set of goals you THINK are indicative of a languages
capabilities. You are choosing these goals because you do not have
the experience yet to evaluate these languages on their own terms.
The condition of CL not having such an interface defined is certainly
a hassle if you are fixated on doing this particular task, but it is
not impossible to use either of the solutions mentioned above, or
perhaps one of the other suggestions, in order to accomplish your real
goal.
Taking this one example as an indicator of a hackability or reflexive
limitation in a programming language yeilds particular ironic results
in the case of CL.
If you are in such a hurry to evaluate languages as you said you were,
you are never going to be able to properly evaluate CL or SmallTalk or
ML or Python or any of the possiblities, let alone operate at a
sufficiently advanced level in any one of them to reach their
respective hackability limitations, or perhaps even complete your goal
in the allotted time.
--
Sincerely,
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
Quoth ilias <·······@pontos.net>:
> Alain Picard wrote:
>> ilias <·······@pontos.net> writes:
>>
>>>i found a limitation in LISP, which i'm wondering about.
>> You're a troll, right? Right??
>> You did _not_ "find a limitation" in lisp in your first week
>> of perusal. Just take my word for it.
>
> i've found a limitation in LISP:
You have found a limitation in _one data structure_ in Lisp.
You would find, in C, that there isn't a straightforward way to
_ensure_ that variables of type "char" can be guaranteed to be able to
store ASCII text.
I'm sure you would find limitations in one thing or another in just
about any software system you cared to look at. But that is
apparently not nearly as interesting as trumpeting that you have found
"a limitation in Lisp.'
> some people here in c.l.l confirm this limitation.
>
> if you have concrete informations about how to overcome this
> limitation (something that is implemented by major CL-vendors, if
> possible compatible across the different implementations), please
> let me know.
If you don't like the way DEFSTRUCT works, then use DEFCLASS instead,
as it is now widely implemented, and does not have this limitation
that you are apparently so worried about.
If you persist in _demanding_ that DEFSTRUCT be "fixed" to conform
with your expectations, people are likely to ask how much you are
prepared to pay for the "bug fix," because you seem to be the only one
around that really cares about having it changed.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://cbbrowne.com/info/finances.html
Overheard in the mall: "What's with your sister and her spitting fetish?"
"ilias" <·······@pontos.net> wrote in message
·····················@pontos.net...
> Alain Picard wrote:
> > ilias <·······@pontos.net> writes:
> >
> >
> >>i found a limitation in LISP, which i'm wondering about.
> >
> > You did _not_ "find a limitation" in lisp in your first week
> > of perusal. Just take my word for it.
>
> i've found a limitation in LISP:
>
To make this a less pointless discussion, can you please define for us what
you mean by limitation?
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Coby Beck wrote:
> "ilias" <·······@pontos.net> wrote in message
...
>>i've found a limitation in LISP:
>>
>
> To make this a less pointless discussion, can you please define for us what
> you mean by limitation?
you seem to be a friendly one, so i'll give you the answer, although you
came late.
remember my initial posting?
> http://www.paulgraham.com/popular.html
> Being Popular
> May 2001
>
> (This article was written as a kind of business plan for a new
> ...
> 4 Hackability
>
> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of
> ...
> In Common Lisp I have often wanted to iterate through the fields of a struct--
...
> I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
>
and i asked
> is this limitation true?
two parts of the text for Paul Graham i'd quoted imply the meaning of
'limitation':
> "being able to do what you want"
> "I have often wanted to..."
limitation = *I* cannot do, what i want to do.
or we could say:
limitation = *n* % of the language users, cannot do what they want to do.
I personally 'felt' this limitation with "C" and "C++" and some others
languages (see my first post to c.l.l).
Of cource, i could build an "object-model" or a "structure_model" to
support this.
but i wan't the fuctionality at the lowest possible language-level.
it's raining.
water is a wonderfull creation.
ilias <·······@pontos.net> writes:
> limitation = *I* cannot do, what i want to do.
This is false. You can do what you want to do, but you're too obsessed
with what name has been chosen for the types in Lisp to do it.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: ilias
Subject: definition of 'limitation' in context of 'programming languages'
Date:
Message-ID: <3D5FD506.7010204@pontos.net>
Rahul Jain wrote:
> ilias <·······@pontos.net> writes:
>
>
>>limitation = *I* cannot do, what i want to do.
>
>
> This is false. You can do what you want to do, but you're too obsessed
> with what name has been chosen for the types in Lisp to do it.
i don't care about names.
i was asked by someone to define 'limitation'.
this i've done. don't switch context.
what i said was:
> limitation = *I* cannot do, what i want to do.
>
> or we could say:
>
> limitation = *n* % of the language users, cannot do what they want to do.
there is an or.
and a second sentence.
and there is an *n*.
the value of *n* depends on *"philosophical views"*.
From: Rahul Jain
Subject: Re: definition of 'limitation' in context of 'programming languages'
Date:
Message-ID: <87y9b4x9pa.fsf@photino.localnet>
ilias <·······@pontos.net> writes:
> Rahul Jain wrote:
> > ilias <·······@pontos.net> writes:
> >
>
> >>limitation = *I* cannot do, what i want to do.
> > This is false. You can do what you want to do, but you're too
> > obsessed
>
> > with what name has been chosen for the types in Lisp to do it.
>
> i don't care about names.
Then why do you insist on using structures and not classes when you
want the functionality of classes and not that of structures?
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: ilias
Subject: Re: definition of 'limitation' in context of 'programming languages'
Date:
Message-ID: <3D6138B8.5010806@pontos.net>
Rahul Jain wrote:
> ilias <·······@pontos.net> writes:
...
> Then why do you insist on using structures and not classes when you
i don't insist.
there is someday maybe some reason that i have to use structs.
> want the functionality of classes and not that of structures?
i don't know the functionality of CL-classes.
From: Rahul Jain
Subject: Re: definition of 'limitation' in context of 'programming languages'
Date:
Message-ID: <87u1lqvfqk.fsf@photino.localnet>
ilias <·······@pontos.net> writes:
> Rahul Jain wrote:
> > ilias <·······@pontos.net> writes:
> ...
> > Then why do you insist on using structures and not classes when you
>
> i don't insist.
> there is someday maybe some reason that i have to use structs.
You never _have_ to use structs for any reason other than
efficiency. If you need efficiency, then you must be prepared to
sacrifice some combination of dynamism, genericity, and reflection.
> > want the functionality of classes and not that of structures?
>
> i don't know the functionality of CL-classes.
So you're complaining about limitations in a language where your
knowledge is severly limited? I suggest you refrain from complaining
until you understand what it is you're complaining about. This should
not be a difficult thing to ask, as you have all the resources (web
sites like the hyperspec, the AMOP spec, and cltl2) you need freely
available, and many excellent resources available (books such as PG's,
Norvig's, Keene's, and AMOP) for a small cost. In case you don't know
yet, www.lisp.org has a huge bibliography section with books, reviews,
and web links.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
"ilias" <·······@pontos.net> wrote in message
·····················@pontos.net...
> Coby Beck wrote:
> > "ilias" <·······@pontos.net> wrote in message
> ...
> >>i've found a limitation in LISP:
> >>
> >
> > To make this a less pointless discussion, can you please define for us
what
> > you mean by limitation?
>
> you seem to be a friendly one, so i'll give you the answer,
I do make a conscious effort to be so. If you incur my wrath ;) you will
find it results in little more than being ignored...
> although you
> came late.
Well, this thread is moving very fast! I try to keep up...
>
> remember my initial posting?
Thank you for the review, I remembered it well.
> two parts of the text for Paul Graham i'd quoted imply the meaning of
> 'limitation':
>
> > "being able to do what you want"
> > "I have often wanted to..."
>
> limitation = *I* cannot do, what i want to do.
There are more objective ways to find limitations to languages than this
criterion. You simply must admit that by this defintion you chose, it is a
completely subjective concept. "I want to use C++ syntax when I write lisp"
"I want infix arithmetic" "I want function names outside of the parens" "I
don't want so many parens" "I want to change class of my structures" Are
all as valid "limitations" of lisp as the one you feel you have discovered.
You can not simply state a personal preference for something that is not
part of ANSI CL and call it a limitation of the language. Nor can Paul
Graham, though his opinions deserve more consideration given his expertise.
>
> limitation = *n* % of the language users, cannot do what they want to do.
This then requires some statistical investigation before you can claim it is
a limitation. My vote is that it is not a limitation, simply a fact to deal
with. There is no problem you can not solve easily and elegantly despite
it. (We must allow for the subjectivity of "elegance" but that is life, I
will not care if you can never agree another approach is equally elegant)
>
> but i wan't the fuctionality at the lowest possible language-level.
If you want that functionality, use defclass, not defstruct (or make-list,
make-array or any other data structure)
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Coby Beck wrote:
> "ilias" <·······@pontos.net> wrote in message
...
>>two parts of the text for Paul Graham i'd quoted imply the meaning of
>>'limitation':
>>
>> > "being able to do what you want"
>> > "I have often wanted to..."
>>
>>limitation = *I* cannot do, what i want to do.
>
>
> There are more objective ways to find limitations to languages than this
> criterion. You simply must admit that by this defintion you chose, it is a
> completely subjective concept.
yes, of course.
1st part of my definition.
> "I want to use C++ syntax when I write lisp"
> "I want infix arithmetic" "I want function names outside of the parens" "I
> don't want so many parens" "I want to change class of my structures" Are
> all as valid "limitations" of lisp as the one you feel you have discovered.
yes. valid 'limitations' based on my definition (1st part of it)
althought different qualities.
> You can not simply state a personal preference for something that is not
> part of ANSI CL and call it a limitation of the language.
ok.
it's a limitation of the ANSI CL Standard.
> Nor can Paul
> Graham, though his opinions deserve more consideration given his expertise.
i quoted Paul Graham as 'someone who wrotes something about LISP'.
not in his status as an expert.
i've not read complete document's of him, so i don't know if i accept
him as an expert (in *thinking*, the only kind of experts which i accept).
>>limitation = *n* % of the language users, cannot do what they want to do.
>
> This then requires some statistical investigation before you can claim it is
> a limitation.
already done.
i found one person, which feels it like a limitation.
i feel it like a limitation.
enougth for me ( *n* > 0 ) to state it as a limitation.
> My vote is that it is not a limitation, simply a fact to deal
> with.
as a conclusion, other languages have no limitations, but simply 'some
facts to deal with' (if you ask the 'other language-lovers', of course).
> There is no problem you can not solve easily and elegantly despite
> it.
easily = low time effort, low brainpower.
elegantly = see below
> (We must allow for the subjectivity of "elegance" but that is life, I
> will not care if you can never agree another approach is equally elegant)
i allow you the subjectivity.
Now, give me an elegant solution for the stated 'limitation' or
'problem' or 'fact to deal with'.
my definition of elegant:
- keeps creativity & productivity of the coder.
- keeps code-size.
- keeps code-speed.
my definition of super-elegant:
- raises creativity & productivity of the coder.
- reduces code-size.
- increases code-speed.
>>but i wan't the fuctionality at the lowest possible language-level.
>
> If you want that functionality, use defclass, not defstruct (or make-list,
> make-array or any other data structure)
*lowest possible language-level*
due to *limitations* in lower level, i have to switch to higher level.
until now, i've got no reply that *proofs* with in a clear, rational &
followable argumentation-line.
your argumentation-line says in essence:
- this is no limitation, but 'some facts to deal with'.
and there we are: philosophy again.
we *may* stop with philosophy, and got to facts:
"LISP - why learnig / using structures"
i don't know how to give you a link, may this works:
·····················@pontos.net
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
> limitation = *I* cannot do, what i want to do.
Then spell out what you want to do and prove that you are
not a troll.
--
This message was not sent to you unsolicited.
Takehiko Abe wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>
>>limitation = *I* cannot do, what i want to do.
>
>
> Then spell out what you want to do and prove that you are
> not a troll.
>
i don't have to prove this.
everyone can choose.
rain has stopped.
could you please explain me, what a 'troll' is?
Edi Weitz wrote:
> Barry Margolin <······@genuity.net> writes:
>
>
>>In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>>
>>>>In Common Lisp I have often wanted to iterate through the fields
>>>
>>>of a struct-- to comb out references to a deleted object, for
>>>example, or find fields that are uninitialized. I know the structs
>>>are just vectors underneath. And yet I can't write a general
>>>purpose function that I can call on any struct. I can only access
>>>the fields by name, because that's what a struct is supposed to
>>>mean.
>>>
>>>is this limitation true?
>>
>>Yes. The FAQ contains some suggestions about how you can work
>>around it.
>
>
> <http://www-2.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part5/faq-doc-3.html>
out of the faq:
> If your Common Lisp includes an implementation
> of CLOS that supports the meta-object protocol specified in the
> original X3J13 draft spec (document X3J13/88-003), then it probably will
> allow (SLOT-VALUE <object> '<slot-name>);
what does the word *probably* mean here?
is the function SLOT-VALUE as described above included in the
specification X3J13?
if yes, a vendor supporting this protocol, *has to* provide this function.
or is the implementation of SLOT-VALUE optionally?
ilias <·······@pontos.net> writes:
> out of the faq:
>
> > If your Common Lisp includes an implementation
> > of CLOS that supports the meta-object protocol specified in the
> > original X3J13 draft spec (document X3J13/88-003), then it probably will
> > allow (SLOT-VALUE <object> '<slot-name>);
>
> what does the word *probably* mean here?
The MOP described in AMOP (I assume that's the one that was in the
X3J13 draft) doesn't really require anything in regards to structure
classes. Therefore, any functionality beyond the CL standard existing
in an implementation that supports that protocol can only be assumed
on a statistical (based on existing implementations) and a subjective
ease-of-implementation judgement. The idea here is that it should be
easy and/or is common to have implemented this feature in a CL with
MOP.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain wrote:
> ilias <·······@pontos.net> writes:
>
>
>>out of the faq:
>>
>>
>>>If your Common Lisp includes an implementation
>>>of CLOS that supports the meta-object protocol specified in the
>>>original X3J13 draft spec (document X3J13/88-003), then it probably will
>>>allow (SLOT-VALUE <object> '<slot-name>);
>>
>>what does the word *probably* mean here?
>
>
> The MOP described in AMOP (I assume that's the one that was in the
> X3J13 draft) doesn't really require anything in regards to structure
> classes. Therefore, any functionality beyond the CL standard existing
> in an implementation that supports that protocol can only be assumed
> on a statistical (based on existing implementations) and a subjective
> ease-of-implementation judgement. The idea here is that it should be
> easy and/or is common to have implemented this feature in a CL with
> MOP.
>
read this paragraph:
assume...assume...statistical...subjective...judgement.
i think such "subjective ease-of-implementation judgments" have not
place in a professional level language FAQ.
i've expected more precise information here.
ilias <·······@pontos.net> writes:
> i've expected more precise information here.
You want precise information on how to create a general implementation
of an implementation-specific feature? And here I was thinking that
you actually wanted someone to take you seriously. I shouldn't have
*assumed* that you had changed your behavior.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -X "Structure is nothing if it is all you got. Skeletons spook X- <-
-> -/ people if [they] try to walk around on their own. I really \- <-
-> -\ wonder why XML does not." -- Erik Naggum, comp.lang.lisp /- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Rahul Jain wrote:
> ilias <·······@pontos.net> writes:
>
>
>>i've expected more precise information here.
>
>
> You want precise information on how to create a general implementation
> of an implementation-specific feature?
no, that is your conclusion.
> And here I was thinking that
> you actually wanted someone to take you seriously. I shouldn't have
> *assumed* that you had changed your behavior.
>
i don't care, if someone takes me seriously.
i simply want some answers, to simple questions.
> LISP limits?
>
> or a typo?
>
>
> http://www.paulgraham.com/popular.html
>
> Being Popular
>
> May 2001
>
> (This article was written as a kind of business plan for a new
> ...
> 4 Hackability
>
> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of
> ...
> In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
>
> is this limitation true?
i got my answers.
the limitatios is true
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>out of the faq:
>
>> If your Common Lisp includes an implementation
>> of CLOS that supports the meta-object protocol specified in the
>> original X3J13 draft spec (document X3J13/88-003), then it probably will
>> allow (SLOT-VALUE <object> '<slot-name>);
>
>what does the word *probably* mean here?
>
>is the function SLOT-VALUE as described above included in the
>specification X3J13?
X3J13 isn't a specification, it's the old name of the committee that
produced the standard.
>if yes, a vendor supporting this protocol, *has to* provide this function.
>
>or is the implementation of SLOT-VALUE optionally?
The function is required to exist, but it's only required to work on
objects of metaclass STANDARD-CLASS. The standard says nothing about
whether it works on objects of metaclass STRUCTURE-CLASS. But the data
needed to make this work is much the same as the data needed to support the
MOP, so we guessed that most implementations that provide the MOP would
also support the extension of SLOT-VALUE on structures.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>>out of the faq:
>>
>>
>>>If your Common Lisp includes an implementation
>>>of CLOS that supports the meta-object protocol specified in the
>>>original X3J13 draft spec (document X3J13/88-003), then it probably will
>>>allow (SLOT-VALUE <object> '<slot-name>);
>>
>>what does the word *probably* mean here?
>>
>>is the function SLOT-VALUE as described above included in the
>>specification X3J13?
>
>
> X3J13 isn't a specification, it's the old name of the committee that
> produced the standard.
>
>
>>if yes, a vendor supporting this protocol, *has to* provide this function.
>>
>>or is the implementation of SLOT-VALUE optionally?
>
>
> The function is required to exist, but it's only required to work on
> objects of metaclass STANDARD-CLASS. The standard says nothing about
> whether it works on objects of metaclass STRUCTURE-CLASS. But the data
> needed to make this work is much the same as the data needed to support the
> MOP, so we guessed that most implementations that provide the MOP would
> also support the extension of SLOT-VALUE on structures.
>
ok, ok! you guessed!
but why don't you state this there?
place your comments as a footnote, so the basic information-flow is not
interupted.
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>ok, ok! you guessed!
>
>but why don't you state this there?
We said "probably". We thought the implication would be obvious.
All we're doing there is listing a number of suggestions.
P.S. Could you please stop changing the Subject line of the thread? "so we
guessed" is a pretty meaningless Subject.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
> >ok, ok! you guessed!
> >
> >but why don't you state this there?
>
> We said "probably". We thought the implication would be obvious.
>
> All we're doing there is listing a number of suggestions.
>
> P.S. Could you please stop changing the Subject line of the thread? "so we
> guessed" is a pretty meaningless Subject.
Thanks Barry. I was just about to say the same.
The changing Subject: is wrecking havoc in GNUS and my mind
processes. :{
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Barry Margolin wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>>ok, ok! you guessed!
>>
>>but why don't you state this there?
>
>
> We said "probably". We thought the implication would be obvious.
many thoughts, many implications, many obvious.
the fact is, that you FAQ is misleading.
it reads to me like the classical "talk-around-the-problem", which is
made by language-lovers.
but real language lovers have no problem to state precisely and open a
language problem.
i don't know paulgraham, but he behaves like a real language-lover:
> http://www.paulgraham.com/popular.html
>
> Being Popular
>
> May 2001
>
> (This article was written as a kind of business plan for a new
> ...
> 4 Hackability
>
> There is one thing more important than brevity to a hacker: being able to do what you want. In the history of
> ...
> In Common Lisp I have often wanted to iterate through the fields of a struct-- to comb out references to a deleted object, for example, or find fields that are uninitialized. I know the structs are just vectors underneath. And yet I can't write a general purpose function that I can call on any struct. I can only access the fields by name, because that's what a struct is supposed to mean.
- identify the weakness.
- publish the weakness.
now i try to
- analyze the current status.
> All we're doing there is listing a number of suggestions.
ok, ok! but do it with more precision.
except you build the FAQs for your personal amusement only.
>
> P.S. Could you please stop changing the Subject line of the thread? "so we
> guessed" is a pretty meaningless Subject.
>
not for me.
i change the subjects, so i'm able to 'navigate' in the djungle what
normally results due to posts which does not affect my questions.
i can stop this, if you proove me, that my behaviour is unfriendly and
if so, that it is more unfriendly that of the out-of-context information
that is filled in usually.
i declare as out-of-context, what has nothing to do with my question
(friendly and in-context: answer to my question, requests for clarifying
my questions, *additional* information after answering my question).
am i a dictator?
or did i simply try to *use* the *net* ?
In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>Barry Margolin wrote:
>> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>>
>>>ok, ok! you guessed!
>>>
>>>but why don't you state this there?
>>
>>
>> We said "probably". We thought the implication would be obvious.
>
>many thoughts, many implications, many obvious.
>
>the fact is, that you FAQ is misleading.
Sorry, we assumed it would be read by intelligent people. But like you
said, we made too many assumptions.
>it reads to me like the classical "talk-around-the-problem", which is
>made by language-lovers.
The language doesn't offer any real built-in solutions, and we said so.
They're all different kinds of workarounds, and this one happens to be
dependent on an extension that some implementors are likely to provide, but
aren't required to.
>but real language lovers have no problem to state precisely and open a
>language problem.
We said there's no fully-general solution.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin wrote:
> In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>
>>Barry Margolin wrote:
>>
>>>In article <················@pontos.net>, ilias <·······@pontos.net> wrote:
>>>
>>>>ok, ok! you guessed!
>>>>
>>>>but why don't you state this there?
>>>
>>>We said "probably". We thought the implication would be obvious.
>>
>>many thoughts, many implications, many obvious.
>>
>>the fact is, that you FAQ is misleading.
>
> Sorry, we assumed it would be read by intelligent people. But like you
> said, we made too many assumptions.
yes, my intelligence lacks.
i repeated a mistake i've done so many times before.
to not check the information source !
evaluate every informations source, even if it seems that its secure.
conclusion here: check, if the usenets FAQs are up to date.
thank you for the lesson!
ilias <·······@pontos.net> writes:
> i can stop this, if you proove me, that my behaviour is unfriendly and
> if so, that it is more unfriendly that of the out-of-context
> information that is filled in usually.
It is confusing. Just pick better subjects that are more descriptive
of the content or topic of that subthread as opposed to metadiscussion
on the flow of the thread. Makes it easier for people coming thru
later to understand it.
Also, I suggest using anewsreader that can thread without looking at
the subject, and can also score up responses directly to you, such as
Gnus.
--
Craig Brozefsky <·····@onshored.com> Senior Programmer
onShore Development http://www.onshore-devel.com
Free Common Lisp Software http://alpha.onshored.com/lisp-software
Craig Brozefsky wrote:
> ilias <·······@pontos.net> writes:
>
>
>>i can stop this, if you proove me, that my behaviour is unfriendly and
>>if so, that it is more unfriendly that of the out-of-context
>>information that is filled in usually.
>
>
> It is confusing. Just pick better subjects that are more descriptive
> of the content or topic of that subthread as opposed to metadiscussion
> on the flow of the thread. Makes it easier for people coming thru
> later to understand it.
>
> Also, I suggest using anewsreader that can thread without looking at
> the subject, and can also score up responses directly to you, such as
> Gnus.
>
>
ok, i understand.
i'll stop this.
sorry for the possibly caused headaches!
In article <················@pontos.net>, ilias wrote:
> Barry Margolin wrote:
>> P.S. Could you please stop changing the Subject line of the thread? "so we
>> guessed" is a pretty meaningless Subject.
>>
>
> not for me.
>
> i change the subjects, so i'm able to 'navigate' in the djungle what
> normally results due to posts which does not affect my questions.
Get a threaded newsreader. Then you can see the ``jungle'' as a nice
tree. You can look for your postings in there and the followups which
appear as children rooted at your postings.
Changing subject lines without a very good reason in mid-thread is considered
rude. Some people filter discussions they are not interested in it by matching
on subject lines. Of course, if the discussion radically drifts from
the original topic, then it makes sense to change the subject line.