[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.lisp

Scala has some cool object system features

Jim Newton

3/2/2016 10:30:00 AM

I've been watching some videos on Scala, but I haven't tried to use it yet.
https://www.youtube.com/watch?v=g...

One cool thing that it does is introduces features.
Classes can not only inherit from other classes, but also from features.
And one cool thing is you can put restrictions on features.
You can tell a feature: refuse to mix-in to a class which does not inherit from a particular class.
You can also tell a feature: refuse to mix-in to a class which doesn't have a particular slot or which
does not implement a particular method.

That's something I've wanted in CLOS. I.e., I have wanted to create a mix-in class which would
extend certain capability. The unfortunate restriction in CLOS is that if one class
inherits from another, then that inheritance sets an ordering constraint on the classes.

In some cases I don't care whether the dependent class comes before or after
in the inheritance list.

This seems pretty cool to me, separating the idea of dependence from order-of-dependence.
12 Answers

Rainer Joswig

3/2/2016 7:12:00 PM

0

On 2016-03-02 10:30:13 +0000, Jim Newton said:

> I've been watching some videos on Scala, but I haven't tried to use it yet.
> https://www.youtube.com/watch?v=g...
>
> One cool thing that it does is introduces features.
> Classes can not only inherit from other classes, but also from features.
> And one cool thing is you can put restrictions on features.
> You can tell a feature: refuse to mix-in to a class which does not
> inherit from a particular class.
> You can also tell a feature: refuse to mix-in to a class which doesn't
> have a particular slot or which
> does not implement a particular method.
>
> That's something I've wanted in CLOS. I.e., I have wanted to create a
> mix-in class which would
> extend certain capability. The unfortunate restriction in CLOS is
> that if one class
> inherits from another, then that inheritance sets an ordering
> constraint on the classes.
>
> In some cases I don't care whether the dependent class comes before or after
> in the inheritance list.
>
> This seems pretty cool to me, separating the idea of dependence from
> order-of-dependence.


Flavors had some of these. Made more sense in an OO system where
methods are organized around classes.

See the documentation of Symbolics Common Lisp: Flavors

http://bitsavers.informatik.uni-stuttgart.de/pdf/symbolics/software/genera_8/Symbolics_Common_Lisp_Programming_Cons...


Pages 531ff

especially the various options like :REQUIRED-FLAVORS, :REQUIRED-METHODS etc.

Kaz Kylheku

3/2/2016 8:22:00 PM

0

On 2016-03-02, Jim Newton <jimka.issy@gmail.com> wrote:
> I've been watching some videos on Scala, but I haven't tried to use it yet.
> https://www.youtube.com/watch?v=g...
>
> One cool thing that it does is introduces features.
> Classes can not only inherit from other classes, but also from features.
> And one cool thing is you can put restrictions on features.
> You can tell a feature: refuse to mix-in to a class which does not inherit from a particular class.
> You can also tell a feature: refuse to mix-in to a class which doesn't have a particular slot or which
> does not implement a particular method.
>
> That's something I've wanted in CLOS. I.e., I have wanted to create
> a mix-in class which would extend certain capability. The
> unfortunate restriction in CLOS is that if one class inherits from
> another, then that inheritance sets an ordering constraint on the
> classes.
>
> In some cases I don't care whether the dependent class comes before or
> after in the inheritance list.

A (way toward a?) solution might be to avoid more than one level of
inheritance. Don't inherit form anything that has inherited already.

I.e. separate the mixins from the mixtures. If you want a new mixture
that is like another one but with this other thing mixed, then make it
from scratch using the same ingredients and not by inheriting the
mixture.

Make sense? Or not?

Kaz Kylheku

3/2/2016 8:27:00 PM

0

On 2016-03-02, Kaz Kylheku <330-706-9395@kylheku.com> wrote:
> On 2016-03-02, Jim Newton <jimka.issy@gmail.com> wrote:
>> I've been watching some videos on Scala, but I haven't tried to use it yet.
>> https://www.youtube.com/watch?v=g...
>>
>> One cool thing that it does is introduces features.
>> Classes can not only inherit from other classes, but also from features.
>> And one cool thing is you can put restrictions on features.
>> You can tell a feature: refuse to mix-in to a class which does not inherit from a particular class.
>> You can also tell a feature: refuse to mix-in to a class which doesn't have a particular slot or which
>> does not implement a particular method.
>>
>> That's something I've wanted in CLOS. I.e., I have wanted to create
>> a mix-in class which would extend certain capability. The
>> unfortunate restriction in CLOS is that if one class inherits from
>> another, then that inheritance sets an ordering constraint on the
>> classes.
>>
>> In some cases I don't care whether the dependent class comes before or
>> after in the inheritance list.
>
> A (way toward a?) solution might be to avoid more than one level of
> inheritance. Don't inherit form anything that has inherited already.
>
> I.e. separate the mixins from the mixtures. If you want a new mixture
> that is like another one but with this other thing mixed, then make it
> from scratch using the same ingredients and not by inheriting the
> mixture.

And, by the way, "same ingredients" doesn't preclude having a way to
ask "what are the mixins of such and such a class" and use the
results of that expression to define the new one:

(my-defclass foo (bar (:bases-of xyzzy :excluding quux)) ...)

This fictitious syntax inherits bar, but not xyzzy; rather, it inherits
the superclasses of xyzzy without xyzzy itself. But from among those
superclasses, it excludes quux, if it occurs.

Thus foo is clearly not a new kind of xyzzy; it just shares some of
its attributes (those that come from some of its superclasses).



>
> Make sense? Or not?


--
Music DIY Mailing List: http://www.kylhe...
ADA MP-1 Mailing List: http://www.kylhe...

Jim Newton

3/3/2016 9:29:00 AM

0

On Wednesday, March 2, 2016 at 9:22:26 PM UTC+1, Kaz Kylheku wrote:
.. separate the mixins from the mixtures. If you want a new mixture
> that is like another one but with this other thing mixed, then make it
> from scratch using the same ingredients and not by inheriting the
> mixture.
>

No doubt CLOS is very strong and flexible, but of course has limitations, as any system does.
Another thing I've occasionally like to do is make a method applicable if the class inherits from
two particular classes. I.e., if the instance if of class-A and also of class-B, then do this. I
seem to recall this was needed for debugging reasons... If I've inherited the debug-class and
also the feature-X class, then do this extra debugging-specific thing to debug-feature-X.

Of course there are ways to workaround this. E.g., the method could specialize on debug-class and contain logic to specifically check for feature-x-class. That's not so bad in the end, since the
ugliness is in the debug-class.

taruss

3/3/2016 7:35:00 PM

0

On Thursday, March 3, 2016 at 1:29:03 AM UTC-8, Jim Newton wrote:

> Another thing I've occasionally like to do is make a method applicable if the class inherits from
> two particular classes. I.e., if the instance if of class-A and also of class-B, then do this.

The Loom knowledge representation system (http://www.isi.edu...) had
some interesting extensions to method dispatch that took advantage of the
dynamic concept classification. In particular, it would allow you write
methods on the conjunction of classes, and then apply them to instances that
satisfied both of the criteria. This was even more flexible, since Loom
methods also supported query-based matching as well.

http://www.isi.edu...documentation/manual/html-functions/defmethod.html
http://www.isi.edu...documentation/tutorial2.1.html#RTFToC24


Note that this capability was not carried over to PowerLoom.

-Tom (former Loom developer)

Stefan Monnier

3/7/2016 6:49:00 PM

0

> No doubt CLOS is very strong and flexible, but of course has
> limitations, as any system does. Another thing I've occasionally like
> to do is make a method applicable if the class inherits from two
> particular classes. I.e., if the instance if of class-A and also of
> class-B, then do this. I seem to recall this was needed for debugging
> reasons... If I've inherited the debug-class and also the feature-X
> class, then do this extra debugging-specific thing to debug-feature-X.

That asks for the ability to define new kinds of specializers, such as
an (and SPEC1 SPEC2) specializer which would accept values that are
accepted by both SPEC1 and SPEC2.

I guess something like what is proposed in
http://arxiv.org/pdf... should be able to do that.

I think Emacs's cl-generic-define-generalizer might also let you define
such an `and' specializer.


Stefan

Jim Newton

3/8/2016 12:32:00 PM

0


> That asks for the ability to define new kinds of specializers, such as
> an (and SPEC1 SPEC2) specializer which would accept values that are
> accepted by both SPEC1 and SPEC2.
>
> I guess something like what is proposed in
> http://arxiv.org/pdf... should be able to do that.
>
> I think Emacs's cl-generic-define-generalizer might also let you define
> such an `and' specializer.
>
>
> Stefan

For sure one thinks of AND and OR specializers when reading the Rhodes/Moringen/Lichteblau
paper. But there are some delicate issues which still have to be resolved. It is very interesting,
and I'd love to investigate it.

One issue of course is sorting methods into the "correct" order of applicability. And you'd have
to think long about what "correct" means.

For example in the presence of (defclass X (A B) ...) (defclass Y (X) ...)
If there are methods such as the following.

(defmethod F ((o (OR A B))) ...) ; (1) less specific than both A and B
(defmethod F ((o (OR A X))) ...) ; (2) less specific than both A and X
(defmethod F ((o (OR A Y))) ...) ; (3) less specific than both A and Y
(defmethod F ((o A)) ...)
(defmethod F ((o B)) ...)
(defmethod F ((o (AND A B))) ...) ; (4) more specific than both A and B
(defmethod F ((o (OR X Y))) ...) ; (5) less specific than both X and Y
(defmethod F ((o X)) ...)
(defmethod F ((o (AND A X))) ...); more specific than both A and X
(defmethod F ((o Y)) ...)
(defmethod F ((o (AND A Y))) ...) ; more specific than both A and Y

(F (make-instance 'Y))

It is pretty clear how to order and AND/OR method with respect the the classes
it references, but it is not clear how to order them relative to each other.
Or worse, if there is a method such as
(defmethod F ((o (OR (eql 42) X)) ...)
or worse
(defmethod F ((o (OR (AND A B) (AND X Y)))) ...)

Madhu

3/9/2016 1:15:00 AM

0


* Stefan Monnier <jwvmvqa6sg5.fsf-monnier+comp.lang.lisp@gnu.org> :
Wrote on Mon, 07 Mar 2016 13:48:50 -0500:

|
| I guess something like what is proposed in
| http://arxiv.org/pdf... should be able to do that.
|
| I think Emacs's cl-generic-define-generalizer might also let you define
| such an `and' specializer.

CL's generics are a trainwreck from the bottomless pit.

Consider the "&context" genius. Basic functionality has been rewritten
to use this infrastructure, one of the functions is this:

(cl-defmethod gui-backend-get-selection (selection-symbol target-type
&context (window-system x)
&optional time-stamp terminal)
(x-get-selection-internal selection-symbol target-type time-stamp terminal))

perspicuous, no? But This is how I, at user level, have to call a
function which eventually calls this method:

(defun xclip-selection-value--internal (type)
(cond ((and (fboundp 'x-selection-exists-p) ; X build
(eq window-system 'x))
(cond ((x-selection-exists-p type)
(cond ((x-selection-owner-p type)
(let ((window-system 'x)) ;; <---------XXXXXXXXXXXX
(gui--selection-value-internal type)))
(t (xclip-selection-value--synchronous type))))))
(t (xclip-selection-value--synchronous type))))

Thanks stefan!

Because special variables are still currently still usable, I could
still get the behaviour I wanted -- in this example: to get the X
selection in a multitty tty context with emacs --daemon. Of course, who
would want to do that? right?


&context is the just the nwolib design to get rid of evil special
variables and promote lexical scoping. cl-generic-define-generalizer
sounds as bad as the pcase definer forms: `pcase' being another genius,
catering to a psychotic adopter population who will rewrite and make all
existing code unsuable in other contexts... for unrelated reasons!
(except for the use of pcase!)

and all this works because these shepherds are fattening the flock for
the slaughter

and isn't that what programming language research today has become all
about? catering to the "self-decapitating self-disempowering"
programmer while providing all the illusions of empowerment, while he
decapitates himself adopting the outcome of the research.

Now gnu emacs was a political tool all along, but were some tasks where
you had to use emacs to get the job done because there was no other tool
which coulf do it. This is systematically being changed. (For eg. you
cant look at large binary (512K) files without a newline in a pinch now,
for eg., or even the newline free 4MB javascript that google groups
pushes, without emacs hanging..)

Now gnu emacs was a political tool all along, but now even that goal
seems to have changed to something subtly different. Judging from the
introduction of infrastructure, mandating use of the new infrastructure,
removal of freshly "obsoleted" functionality, making those tasks
IMPOSSIBLE in emacs. This is not random ecosystem based development,
but reveals a subtile higher intelligence co-ordinating these changes
with a cofrresponding manipulation of "public opinion"

Stefan Monnier

3/9/2016 6:59:00 PM

0

> One issue of course is sorting methods into the "correct" order of
> applicability. And you'd have to think long about what
> "correct" means.

Yes, it's quite messy,


Stefan

Stefan Monnier

3/9/2016 7:00:00 PM

0

> (cond ((and (fboundp 'x-selection-exists-p) ; X build
> (eq window-system 'x))
> (cond ((x-selection-exists-p type)
> (cond ((x-selection-owner-p type)
> (let ((window-system 'x)) ;; <---------XXXXXXXXXXXX
> (gui--selection-value-internal type)))

Hmm... AFAICT, if we're in this branch, then we know that (eq
window-system 'x) is true, so the let-binding above is redundant.


Stefan