Christopher C. Stacy wrote:
>
> Am I alone on this? I am thinking of getting fed up after all these
> years, and maybe writing a macro so that I can write code like this:
>
> (define-simple-method increment-point ((p point) y)
> (incf x y))
>
> Do you think you would find that very confusing?
>
What is meant to happen in a case like this:
(defclass c
((x))
(define-simple-method m ((c c) y)
;; in other words (+ (slot-value c 'x) y)
(+ x y))
;;; And now later, in another file
(defclass c
((x)
(y)))
Is the rule something like `if there is a lexically visible binding
for a symbol then use that, otherwise treat it as a SLOT-VALUE call?'.
--tim
"Tim Bradshaw" <··········@tfeb.org> writes:
> Christopher C. Stacy wrote:
>>
>> Am I alone on this? I am thinking of getting fed up after all these
>> years, and maybe writing a macro so that I can write code like this:
>>
>> (define-simple-method increment-point ((p point) y)
>> (incf x y))
>>
>> Do you think you would find that very confusing?
>>
>
> What is meant to happen in a case like this:
>
> (defclass c
> ((x))
>
> (define-simple-method m ((c c) y)
> ;; in other words (+ (slot-value c 'x) y)
> (+ x y))
>
> ;;; And now later, in another file
>
> (defclass c
> ((x)
> (y)))
>
> Is the rule something like `if there is a lexically visible binding
> for a symbol then use that, otherwise treat it as a SLOT-VALUE call?'.
IIRC, that was the rule in Flavors.
Ant�nio Leit�o.
"Tim Bradshaw" <··········@tfeb.org> wrote in message news:<··········@odah37.prod.google.com>...
> Christopher C. Stacy wrote:
> >
> > Am I alone on this? I am thinking of getting fed up after all these
> > years, and maybe writing a macro so that I can write code like this:
> >
> > (define-simple-method increment-point ((p point) y)
> > (incf x y))
> >
> > Do you think you would find that very confusing?
> >
mcl's pre-clos window system was written in object-lisp. which
formulated methods much like this (see also the note on lexical
precedence below.) when mcl switched to clos, one particularly handy
macro was one which rewrote defobfuns (as they were called) to
defmethods. it wasn't very long. as i recall, one alternative was to
use with-accessors rather than with-slots, which alleviated the
slot-value shortcomings.
>
> What is meant to happen in a case like this:
>
> (defclass c
> ((x))
>
> (define-simple-method m ((c c) y)
> ;; in other words (+ (slot-value c 'x) y)
> (+ x y))
>
> ;;; And now later, in another file
>
> (defclass c
> ((x)
> (y)))
>
> Is the rule something like `if there is a lexically visible binding
> for a symbol then use that, otherwise treat it as a SLOT-VALUE call?'.
...
>>>>> On 8 Sep 2004 05:09:30 -0700, james anderson ("james") writes:
james> mcl's pre-clos window system was written in object-lisp.
james> which formulated methods much like this (see also the
james> note on lexical precedence below.)
Flavors methods simply provided lexical scope for the instance
variables according to the class hierarchy. That is, X is either
lesically bound by the DEFMETHOD form, or a free reference refers
to an instance variable of the innermost class (from DEFFLAVOR).
If I recall, Object Lisp was much stranger. It was a Gary Drescher
invention -- I remember him hacking on it, but don't remember if it
was first on Coral/Allegro/MCL or the Lisp Machine. Probably the latter.
Object Lisp was similar to how typical AI programs of the day modeled
object relations. That is, it doesn't really distinguish between
classes and objects. Every "object" is AKO another object; objects
are created by cloning other objects, and can play either role in
the system according to the programmer's own conventions.
Object Lisp is multiple inheritence: the make-instance operator takes
a list of parent objects. Method invocation and instance variable
access look sort of like message passing because it all goes through
a function called ASK. But ASK doesn't take messages - you use it to
pass any Lisp form to the object; ASK means "eval this inside yourself".
Methods are defined by DEFOBFUN rather than DEFUN, but you just hack
instance variables with SETQ. The binding of variables is not based
on class definitions because there are no class definitions.
Rather, the object hierarchy of the instance represents a dynamic
evaluation context: you walk up the tree of objects to get the bindings.
(Also, there are introspective functions so you can manually navigate
both the object hierarchy and the object binding frames.) Object Lisp
has a simple object creation protocol that's like make-instance in CLOS.
I never programmed in Object Lisp, but I thought it was KINDOF neat.
P.S.
Just how many Lisp implementations have been named "Allegro", anyway?
······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
> >>>>> On 8 Sep 2004 05:09:30 -0700, james anderson ("james") writes:
> james> mcl's pre-clos window system was written in object-lisp.
> james> which formulated methods much like this (see also the
> james> note on lexical precedence below.)
>
> Flavors methods simply provided lexical scope for the instance
> variables according to the class hierarchy. That is, X is either
> lesically bound by the DEFMETHOD form, or a free reference refers
> to an instance variable of the innermost class (from DEFFLAVOR).
>
> If I recall, Object Lisp was much stranger. It was a Gary Drescher
> invention -- I remember him hacking on it, but don't remember if it
> was first on Coral/Allegro/MCL or the Lisp Machine. Probably the latter.
> Object Lisp was similar to how typical AI programs of the day modeled
> object relations. That is, it doesn't really distinguish between
> classes and objects. Every "object" is AKO another object; objects
> are created by cloning other objects, and can play either role in
> the system according to the programmer's own conventions.
> Object Lisp is multiple inheritence: the make-instance operator takes
> a list of parent objects. Method invocation and instance variable
> access look sort of like message passing because it all goes through
> a function called ASK. But ASK doesn't take messages - you use it to
> pass any Lisp form to the object; ASK means "eval this inside yourself".
yes, i thought it was all pretty spiffy. when i had to port things to
clos, it took a while to get used to the new party line.
...
>>>>> On 8 Sep 2004 05:09:30 -0700, james anderson ("james") writes:
james> mcl's pre-clos window system was written in object-lisp.
james> which formulated methods much like this (see also the
james> note on lexical precedence below.)
Flavors methods simply provided lexical scope for the instance
variables according to the class hierarchy. That is, X is either
lesically bound by the DEFMETHOD form, or a free reference refers
to an instance variable inherited from the innermost class definition.
In other words, it's just supplying an automatic WITH-SLOTS of
all the slots of the instance, which are composed from the
usual multiple inheritence rules. The only problem with this is
that such free references bother some people (but I think it's
sometimes unnecessary to have to spell it out), and this scheme
does not support multiple method dispatch. DEFMETHOD in Flavors
only took one distinguished parameter, always the first; a version
in CLOS would naturally just pick the first specialized parameter.
If I recall, Object Lisp was much stranger. It was a Gary Drescher
invention -- I remember him hacking on it, but don't remember if it
was first on Coral/Allegro/MCL or the Lisp Machine. Probably the latter.
Object Lisp was similar to how typical AI programs of the day modeled
object relations. That is, it doesn't really distinguish between
classes and objects. Every "object" is AKO another object; objects
are created by cloning other objects, and can play either role in
the system according to the programmer's own conventions.
Object Lisp is multiple inheritence: the make-instance operator takes
a list of parent objects. Method invocation and instance variable
access look sort of like message passing because it all goes through
a function called ASK. But ASK doesn't take messages - you use it to
pass any Lisp form to the object; ASK means "eval this inside yourself".
Methods are defined by DEFOBFUN rather than DEFUN, but you just hack
instance variables with SETQ. The binding of variables is not based
on class definitions because there are no class definitions.
Rather, the object hierarchy of the instance represents a dynamic
evaluation context: you walk up the tree of objects to get the bindings.
(Also, there are introspective functions so you can manually navigate
both the object hierarchy and the object binding frames.) Object Lisp
has a simple object creation protocol that's like make-instance in CLOS.
I never programmed in Object Lisp, but I thought it was KINDOF neat.
P.S.
Just how many Lisp implementations have been named "Allegro", anyway?