Question to Ken Tilton.
Is it possible to use cells to automate simple types like integer or
string instead of slots of CLOS objects ?
Even if it is not supported in cells, is it possible theoretically ?
If yes what mechanizm would you use to achieve that ? I understand MOP
will not be helpfull in this case ?
These are not practical, but rather theoretical questions, exploring
lisp possibilities.
Vagif Verdi wrote:
> Question to Ken Tilton.
A question on cells-devel might have drawn a response from a cells user
who I believe has implemented for what (again) I believe you are asking.
> Is it possible to use cells to automate simple types like integer or
> string instead of slots of CLOS objects ?
Well, that question is a little confusing. 42 never changes, so why do I
need Cells, whose raison d'etre is to manage interdependent, long-lived
state?
But I also hear you saying "Does it have to be CLOS?". No, I almost
finished Cells for defstructs, and the user I had in mind in the first
paragraph, TFB the Younger, did something with defvar/defparameter.
> Even if it is not supported in cells, is it possible theoretically ?
> If yes what mechanizm would you use to achieve that ? I understand MOP
> will not be helpfull in this case ?
> These are not practical, but rather theoretical questions, exploring
> lisp possibilities.
>
Without clarification of the issues I raised above I cannot say much,
except: there is nothing magical about Cells. We allocate an instance of
a little data structure for each slot of each instance whose state
changes we want to manage. Macrology and cool Lisp features make it
possible to hide almost all the wiring, so it only seems magical slash
as if Lisp has been changed.
To manage state change with, say, a defparameter, one simply does more
macrology. The bad news is that reads/writes to a variable do not go
thru an accessor as with CLOS slots, and that is where some of the
wiring is hidden. A symbol macro with the same name as the defvar would
let you hide the read plumbing, but you would still end up with:
(c-setf *x* 42) instead of (setf *x* 42)
where c-setf is short for "cell setf". Hmmm, knowing me I would probably
make that setc instead of c-setf.
hth, kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Vagif Verdi wrote:
> Well, that question is a little confusing. 42 never changes, so why do I
> need Cells, whose raison d'etre is to manage interdependent, long-lived
> state?
>
> But I also hear you saying "Does it have to be CLOS?". No, I almost
> finished Cells for defstructs, and the user I had in mind in the first
[...]
> To manage state change with, say, a defparameter, one simply does more
> macrology. The bad news is that reads/writes to a variable do not go
> thru an accessor as with CLOS slots, and that is where some of the
> wiring is hidden. A symbol macro with the same name as the defvar would
> let you hide the read plumbing, but you would still end up with:
>
> (c-setf *x* 42) instead of (setf *x* 42)
Symbol-macros are also expanded as arguments to setf, so you could use
a Cells class with only one slot.
Paul Khuong
Ken Tilton wrote:
> Vagif Verdi wrote:
> > Question to Ken Tilton.
>
> (c-setf *x* 42) instead of (setf *x* 42)
>
Yes, that's exactly what i had in mind.
One question remains though. Is is possible to still use setf ? say
override it ?
With c-seft it is prone to errors, cause there's no warning and no
error from compilator or program, if you accidentally write seft
instead.
Vagif Verdi wrote:
> Ken Tilton wrote:
>
>>Vagif Verdi wrote:
>>
>>>Question to Ken Tilton.
>>
>>(c-setf *x* 42) instead of (setf *x* 42)
>>
>
>
> Yes, that's exactly what i had in mind.
> One question remains though. Is is possible to still use setf ? say
> override it ?
Hmmm, I suppose. Be careful. :) But....
>
> With c-seft it is prone to errors, cause there's no warning and no
> error from compilator or program, if you accidentally write seft
> instead.
>
Well, the good news is that with Cells we rarely use SETF. We want
things to be functions of other things. So you will not get very many
chances to stomp on the Cell instance actually in the global. But...
Paul points out that a symbol-macro also expands to setf.
Hmmm. What about:
(define-symbol-macro *xxx* (c-variable-accessor '*xxx*))
And:
(defun (setf c-variable-accessor) (new-value symbol)
(c-variable-write symbol new-value))
And:
(defun c-variable-accessor (symbol)
(c-variable-read symbol))
???
c-variable-read and -write left as an exercise. :)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Paul points out that a symbol-macro also expands to setf.
>
> Hmmm. What about:
>
> (define-symbol-macro *xxx* (c-variable-accessor '*xxx*))
>
> And:
>
> (defun (setf c-variable-accessor) (new-value symbol)
> (c-variable-write symbol new-value))
>
> And:
>
> (defun c-variable-accessor (symbol)
> (c-variable-read symbol))
>
> ???
>
> c-variable-read and -write left as an exercise. :)
>
I like this approach! Thx Paul and Kenny!
So if i understand correctly, the approach would be - creating a macro
def-cells-var
where we create a 1 slot object with symbol-macros for mimicking work
with "simple" type.
In this case no need to rewrite seft.
Vagif Verdi wrote:
> Ken Tilton wrote:
>
>>Paul points out that a symbol-macro also expands to setf.
>>
>>Hmmm. What about:
>>
>>(define-symbol-macro *xxx* (c-variable-accessor '*xxx*))
>>
>>And:
>>
>>(defun (setf c-variable-accessor) (new-value symbol)
>> (c-variable-write symbol new-value))
>>
>>And:
>>
>>(defun c-variable-accessor (symbol)
>> (c-variable-read symbol))
>>
>>???
>>
>>c-variable-read and -write left as an exercise. :)
>>
>
>
> I like this approach! Thx Paul and Kenny!
> So if i understand correctly, the approach would be - creating a macro
> def-cells-var
> where we create a 1 slot object with symbol-macros for mimicking work
> with "simple" type.
> In this case no need to rewrite seft.
>
Right, but I do not see why we need a one-slot object. Maybe when I do
this later tonight I will find out what Paul had in mind. :)
Remember, a symbol /is/ an object with /several/ slots, one of which is
its value. Hell, I could even let the value reside there and use a
property on the symbol to hold the Cell. Hmm....
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
>
> Vagif Verdi wrote:
>
>> Ken Tilton wrote:
>>
>>> Paul points out that a symbol-macro also expands to setf.
>>>
>>> Hmmm. What about:
>>>
>>> (define-symbol-macro *xxx* (c-variable-accessor '*xxx*))
>>>
>>> And:
>>>
>>> (defun (setf c-variable-accessor) (new-value symbol)
>>> (c-variable-write symbol new-value))
>>>
>>> And:
>>>
>>> (defun c-variable-accessor (symbol)
>>> (c-variable-read symbol))
>>>
>>> ???
>>>
>>> c-variable-read and -write left as an exercise. :)
>>>
>>
>>
>> I like this approach! Thx Paul and Kenny!
>> So if i understand correctly, the approach would be - creating a macro
>> def-cells-var
>> where we create a 1 slot object with symbol-macros for mimicking work
>> with "simple" type.
>> In this case no need to rewrite seft.
>>
>
> Right, but I do not see why we need a one-slot object. Maybe when I do
> this later tonight I will find out what Paul had in mind. :)
That might have been just an implementation idea. Anyway...
... it works. :) A little macrology (the actual def-c-var and
def-c-parameter) and I really should support ephemerals and slot
cell-specific slot options such as :owning and :unchanged-if, but that
should all fall into place (and will have to wait until I need them <g>).
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Do you intend to include these new features into cells ?
From: Ken Tilton
Subject: Re: cells with simple types (not CLOS objects)
Date:
Message-ID: <bUl5h.17$9B3.1@newsfe10.lga>
Vagif Verdi wrote:
> Do you intend to include these new features into cells ?
>
yes, next time I commit to CVS you should be able to dig up
def-c-variable and near there will be some rough test-code that will let
you see how to use them.
The interesting thing to note is that these are not special variables in
the sense that they cannot be dynamically rebound in a let. Not sure
what that would mean in a dataflow model.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Ken Tilton
Subject: Re: cells with simple types (not CLOS objects)
Date:
Message-ID: <0Co5h.35$9B3.19@newsfe10.lga>
Ken Tilton wrote:
>
>
> Vagif Verdi wrote:
>
>> Do you intend to include these new features into cells ?
>>
>
> yes, next time I commit to CVS you should be able to dig up
> def-c-variable and near there will be some rough test-code that will let
> you see how to use them.
>
> The interesting thing to note is that these are not special variables in
> the sense that they cannot be dynamically rebound in a let. Not sure
> what that would mean in a dataflow model.
OK, yes I do. I used to have a capability of temporarily substituting
one Cell for another as the manager of a slot of an instance. This was
handy for things like a scroll thumb, which goes from following the
scroll position to (when clicked) driving the scroll position. I have
been meaning to resurrect that mechanism anyway. that has code for
gracefully handing off dependent lists and other vital state as control
changes hands.
What I cannot do (without compiler cooperation) is use LET to do it, so
there would have to be a new LET-CELL or LET-C or C-LET or somethin. And
if I do that I can even use symbol-macrolet to take a block of
conventional, procedural, non-cell Lisp and have a Cell or two in there
to help simplify the code -- tho I would expect not as much because
Cells get useful when you have a certain larger amount of state to keep
straight and I tend to keep my code blocks under "larger" anyway.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon