I have always been baffled why CLOS instances are printed as #<z hex>
while structures as #s(z slots).
What is wrong with
> (defclass z-clos () (a b c))
> (setq v (make-instance 'z-clos))
#s(z-clos)
> (setf (slot-value v 'a) 10)
> v
#s(z-clos a 10)
(except for possible user being confused by thinking that V is a
structure-object, not a standard-object - actually, not even that since
the slot names are not keywords)?
While I am at it, is it okay to redefine a structure class as a clos
class and vice versa?
i.e.,
> (defclass z () (a b c))
> (defstruct z a b c)
and
> (defstruct z a b c)
> (defclass z () (a b c))
Thanks.
--
Sam Steingold (http://www.podval.org/~sds)
The only guy who got all his work done by Friday was Robinson Crusoe.
Sam Steingold <···@gnu.org> writes:
> I have always been baffled why CLOS instances are printed as #<z hex>
> while structures as #s(z slots).
Well, CLOS allows/encourages you to do a lot of complex initialization of
objects (perhaps interning them, computing hidden slot values, etc.).
Structures (without extra work from outside) don't do as much of that, so
#S is more likely to be right.
Also, traditionally, people have felt #S made a "structure", and there was
a lot of fussing about whether it generalized to classes. (I think it did
and proposed to generalize it to be a legal print mode for *any* type that
the system wanted to use it for, but others disagreed--either on technical
grounds or because of the late timing of when I proposed this.)
> What is wrong with
> > (defclass z-clos () (a b c))
> > (setq v (make-instance 'z-clos))
> #s(z-clos)
> > (setf (slot-value v 'a) 10)
> > v
> #s(z-clos a 10)
Actually, this brings up another point. #S notation uses :xxx as the init
keyword. Some CLOS slots have no init keyword.
> While I am at it, is it okay to redefine a structure class as a clos
> class and vice versa?
Probably only if you recompile all the uses. The whole point of structure
class is that it's allowed to be open-coded. Unless the system does more
dependency-tracking than it's reuired to do, it won't know what to recompile
when you change the metaclass.
Off the track a little bit.
(defstruct zut a s d)
(make-instance (find-class 'zut))
What should this do? (I am lazy and have not looked up the CLHS)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
I believe this should fail. make-instance is a generic function, defined
to operate on standard classes. While zut would be a structure-class.
Regards,
Sunil
Marco Antoniotti wrote:
> Off the track a little bit.
>
> (defstruct zut a s d)
>
> (make-instance (find-class 'zut))
>
> What should this do? (I am lazy and have not looked up the CLHS)
>
> Cheers
>
>
Sunil Mishra <·······@notmyemail.com> writes:
> I believe this should fail. make-instance is a generic function, defined
> to operate on standard classes. While zut would be a
> structure-class.
Yep. It was just a CLHS click away :) It is unfortunate that you
cannot get the constructor of a STRUCTURE-CLASS easily, otherwise you
could have written
(defmethod make-instance ((sc structure-class) &rest initargs)
(apply (constructor-of sc) initargs))
> Regards,
>
> Sunil
>
> Marco Antoniotti wrote:
> > Off the track a little bit.
> >
> > (defstruct zut a s d)
> >
> > (make-instance (find-class 'zut))
> >
> > What should this do? (I am lazy and have not looked up the CLHS)
> >
> > Cheers
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th 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'.
> * In message <···············@world.std.com>
> * On the subject of "Re: (defstruct z) & (defclass z)"
> * Sent on Thu, 26 Jul 2001 18:31:09 GMT
> * Honorable Kent M Pitman <······@world.std.com> writes:
>
> Sam Steingold <···@gnu.org> writes:
>
> > I have always been baffled why CLOS instances are printed as #<z hex>
> > while structures as #s(z slots).
>
> Well, CLOS allows/encourages you to do a lot of complex initialization of
> objects (perhaps interning them, computing hidden slot values, etc.).
> Structures (without extra work from outside) don't do as much of that, so
> #S is more likely to be right.
yes, but you have to do the extra work in both CLOS and structure worlds
to break the simple meaning, i.e., #s would work just fine for both
defclass and defstruct out of the box.
let me put it this way: is it legal for an implementation to use the #s
notation for printing defclass instances?
> Also, traditionally, people have felt #S made a "structure", and there was
> a lot of fussing about whether it generalized to classes. (I think it did
> and proposed to generalize it to be a legal print mode for *any* type that
> the system wanted to use it for, but others disagreed--either on technical
> grounds or because of the late timing of when I proposed this.)
oh, how would I _love_ to see that!
too bad CL specifies the ambiguous #p"" pathname syntax instead of the
simple an clear #s(pathname)!
> > What is wrong with
> > > (defclass z-clos () (a b c))
> > > (setq v (make-instance 'z-clos))
> > #s(z-clos)
> > > (setf (slot-value v 'a) 10)
> > > v
> > #s(z-clos a 10)
>
> Actually, this brings up another point. #S notation uses :xxx as the
> init keyword. Some CLOS slots have no init keyword.
so? slots do have _names_, and _they_ are what I suggest to be used.
#s(z-clos a 10) is to be translated to
(let ((v (make-instance 'z-clos)))
(setf (slot-value v 'a) 10)
v)
(see CLOCC/CLLIB/closio.lisp where I print and read clos objects as #[])
any chance there might be an addendum to the standard, specifying this
#s() for various things and maybe some new functions, like split-seq?
--
Sam Steingold (http://www.podval.org/~sds)
.sigs are like your face - rarely seen by you and uglier than you think
On 26 Jul 2001, Sam Steingold wrote:
> so? slots do have _names_, and _they_ are what I suggest to be used.
> #s(z-clos a 10) is to be translated to
> (let ((v (make-instance 'z-clos)))
> (setf (slot-value v 'a) 10)
> v)
Yuck! What about initialize-instance and friends?
Tim
Tim Moore <·····@herschel.bricoworks.com> writes:
>
> On 26 Jul 2001, Sam Steingold wrote:
> > so? slots do have _names_, and _they_ are what I suggest to be used.
> > #s(z-clos a 10) is to be translated to
> > (let ((v (make-instance 'z-clos)))
> > (setf (slot-value v 'a) 10)
> > v)
> Yuck! What about initialize-instance and friends?
Right. It might be that the class has initialize-instance methods that
assume these slots are already set up. You must do this by init keywords
to make-instance or by working through a lower level interface than
make-instance.
Sam Steingold <···@gnu.org> writes:
> let me put it this way: is it legal for an implementation to use the #s
> notation for printing defclass instances?
I'm not sure if standard-class is required to use #<...> or if the notation
is there just the logical option. An implementation could probably get away
with a documented deviation on this point, though I bet a lot of weird issues
would be tripped up in the process. That doesn't mean it's not worth someone
doing the experiment.
> [ :xxx vs xxx as slot name indicators ]
> so? slots do have _names_, and _they_ are what I suggest to be used.
Yes, but the folding is documented/required in the case of structures.
I was just observing that this would make for a non-uniform semantics,
since the extension's use of keywords would be different than the
non-extended use. That might not matter in practice unless your
implementation also allowed you to mix the two metaclasses in inheritance;
then it would come into play. The standard doesn't require implementations
to support such mixing to be possible.
> #s(z-clos a 10) is to be translated to
> (let ((v (make-instance 'z-clos)))
> (setf (slot-value v 'a) 10)
> v)
> (see CLOCC/CLLIB/closio.lisp where I print and read clos objects as #[])
>
> any chance there might be an addendum to the standard, specifying this
> #s() for various things and maybe some new functions, like split-seq?
The standard? I don't speak for the committee and am presently not even
ON the committee. But my guess based on my knowledge of them from the
past is: Not likely.
The language? Well, the only thing that makes it defined by the standard
rather than "some book somebody wrote" or another source of authority
is community consensus. For that matter, true extensions can be pervasively
available ("de facto standards") whether or not a coherent document "requires"
it.
Sam Steingold wrote:
> I have always been baffled why CLOS instances are printed as #<z hex>
> while structures as #s(z slots).
People who use CLOS instances often create highly circular networks of
objects, which wouldn't print right in #s syntax, even with *print-circle*
in effect. The only thing that works right in practice on these classes
are print-object methods. Whereas structures are more often used for
random aggregation of data, like #s(space-time x y z time).
> While I am at it, is it okay to redefine a structure class as a clos
> class and vice versa?
When you do that, you change the class' metaclass. What happens then with
the existing subclasses and existing instances of the class? It is highly
tricky to implement correctly (cf. update-instance-for-redefined-class).
Bruno