From: ··@flash.bellcore.com
Subject: updating random slots in (say) defstruct
Date:
Message-ID: <18963@bellcore.bellcore.com>
> In article <·····@bellcore.bellcore.com> ··@flash.bellcore.com writes:
> >There appears to be no Common LISP way to similarly update a random
> >slot. The best one can do seems to be:
>
> You can do
>
> (setq updater-function #'(lambda (object value)
> (setf (test-one object) value)))
>
> (funcall updater-function instance value)
>
Yes, that's so. But given a defstruct with 50 slots, i must define an
updator function for each, which seems wasteful, given that the DEFSTRUCT
has already defined one.
> In ANSI Common Lisp you'll be able to use #'(setf test-one) to access the
> updater function directly.
Ah, now this is closer to what i was looking for. But what i want to
do, is define a SETFable function created with (INTERN (string-append
<defstruct-name> "-" <slot-name>)). Perhaps i really have to throw the
whole expression i've consed up to EVAL. But that really is a bit
gross.
Peter Clitherow
In article <·····@bellcore.bellcore.com> ··@flash.bellcore.com writes:
> > In article <·····@bellcore.bellcore.com> ··@flash.bellcore.com writes:
>
> > In ANSI Common Lisp you'll be able to use #'(setf test-one) to access the
> > updater function directly.
>
> Ah, now this is closer to what i was looking for. But what i want to
> do, is define a SETFable function created with (INTERN (string-append
> <defstruct-name> "-" <slot-name>)). Perhaps i really have to throw the
> whole expression i've consed up to EVAL. But that really is a bit
> gross.
Well, you could set up your own hash table or other data structure to
convert the symbols returned by INTERN into the functions (using e.g.
#'(setf test-one) to find out what they are). Better yet,
you could use some such data structure to directly map the pairs
(defstruct-name slot-name) into setf functions.
Or, some simple poking around might well tell you how to access the
SETF functions already there in your implementation. E.g. I think in
Allegro if you look at the property list of a symbol with a setf-able
function it is pretty clear how to find the setf function. Of course,
this will not be portable, and may even break with a new release of
your lisp.
--
Lou Steinberg
uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
arpa: ···@cs.rutgers.edu
From: Eliot Handelman
Subject: Re: updating random slots in (say) defstruct
Date:
Message-ID: <12955@phoenix.Princeton.EDU>
In article <························@atanasoff.rutgers.edu> ···@atanasoff.rutgers.edu (Lou Steinberg) writes:
;In article <·····@bellcore.bellcore.com> ··@flash.bellcore.com writes:
;
;> But what i want to
;> do, is define a SETFable function created with (INTERN (string-append
;> <defstruct-name> "-" <slot-name>)). Perhaps i really have to throw the
;> whole expression i've consed up to EVAL. But that really is a bit
;> gross.
I ran into a similar problem, compounded by the fact that I wanted to
define a few extra options to defstruct, so I wound up writing a
defstruct preprocessor. I save any values that interest me, such as the
names of all the accessors.
Zetalisp had the defstruct-description structure to access basic information,
like the names of all the slots, the names of the accessors to each slot, etc.
Too bad CL dropped it. Why was that? Anything to do with metaobjects?
In article <·····@phoenix.Princeton.EDU> ·····@phoenix.Princeton.EDU (Eliot Handelman) writes:
Zetalisp had the defstruct-description structure to access basic information,
like the names of all the slots, the names of the accessors to each slot, etc.
Too bad CL dropped it. Why was that? Anything to do with metaobjects?
In a lot of cases like this, the feature did not carry over into CL
because, while many people saw the motivation, they didn't all like
the details, and it didn't seem that the time or energy existed to
form a concensus. Quite a few good Zetalisp features were left by the
wayside in this way. Often we (Moon and I) told everybody that the
features were genuinely important, but the others didn't believe us,
thinking the features were too complicated and not very useful. Now a
some of them are (apparently) being added as part of the ANSI
standardization process, as the user demand becomes clear.
From: Jeff Dalton
Subject: Re: updating random slots in (say) defstruct
Date:
Message-ID: <1569@skye.ed.ac.uk>
In article <·····@bellcore.bellcore.com> ··@flash.bellcore.com writes:
>Yes, that's so. But given a defstruct with 50 slots, i must define an
>updator function for each, which seems wasteful, given that the DEFSTRUCT
>has already defined one.
But the system may not have defined one. Instead of having a setter
function for each slot of each defstruct type, it may just have one
setter function that's used for all slots and is called with an int
that gives the offset of the slot in the structure. For example,
> (defstruct struct a-slot)
struct
> (macroexpand-1 (setf (struct-a-slot x) 'z))
(system:structure-set x 0 'z)
-- Jeff