[self-interest] Re: Method are not objects?

[Marko Mikulicic]

Richard wrote:

> Marko Mikulicic wrote:
> > Richard wrote:
> > > I don't know if I agree with this syntax because I'd think of a:: as
> > > a two parameter method. I think a different symbol should be used in
> > > order to distinguish the two operations (perhaps the exclamation mark?).
> >
> > "a::" is not a two parameter method, because every argument in a keyworded
> > message
> > send must have it's associated keyword (capitalized): "a:B:".
> > I think the "a: arg1 : arg2" sytax would be very confusing and non-productive. It
> > could
> > be only useful when converting other languages wich uses prefix-syntax (Java)
> > into Self-Smalltalk,
> > but then it could be "a: arg1 A2: arg2 A3: arg3 ...." as a convention.
> >  Using another symbol  reduces the elegance of the language and breaks
> > compatibility.
> > Self has the fewest possible reserved symbols, and ":" is used for message
> > passing.
> > "::" could be seen as a message to the slot itself and not to the object
> > contained in the slot.
>
> I still don't agree with the syntax. It doesn't matter that a:: is not
> a useful/valid selector, it can still be thought of as a selector even
> in Smalltalk.

In fact my syntax is a message send, it's no "special syntax".
But you have right: with "::" one
thinks it is a keyworded send, but it takes no args.
So maybe, it will be better to use a convention, as used with "a, a:", "_Primitive",
....
rather than something specified in a syntax (to keep the basic syntax simple).


> And if you're going to start addressing slots then you're
> opening a huge can of worms; I have nothing against it as long as you
> allow other meaningful messages that you can send to slots (like, the
> time when they were last accessed or modified, or the permissions on the
> slot, which may be too expensive in the general case but are necessary
> for a modern secure OS).
>
> Much more important, you are treating "method containing slots" *very*
> differently from "data containing slots". After all, the "no evaluate"
> syntax for an assignable slot x would be x:, but that's already taken.

(| a <- 3 |) creates a assignable slot. wich is a pair of "a","a:"
in this case (| a <-3 . a: arg = (arg+) |) in Self4 is ambigue, is already taken by
the
"a"'s assignement primitive. I thought to create another slot "a::" (or "a!" if you
like)
that contains an "unevaluative read" of whatever slot named "a".
The existence of this slot is controlled by the initialization of the original slot,
just like
the presence of "a:" is determinated by ( | a | ) or ( | a = constant | ).
A read write method slot could change directly the method, althrouhg this
functionality
can be easly done using dynamic inheritance, as Jacel pointed out. But something of
more interest is possibility to get, in some way, the real method object out of the
slot.

>
>
> So far, you're merely reimplementing mirror functionality using different
> syntax and that just gets you a net increase in complexity in the language
> (admittedly for a net decrease in complexity in users' code). It seems to
> me that you are thinking in terms of autoevaluate versus return of methods
> but that's just an implementation detail and so not relevant to users. The
> way you must think about it (in fact, the thinking behind the auto-evalua-
> tion of method containing slots) is to look at what is returned from calling
> the slot. Whether the slot contains data or a method, it always returns
> what looks to be the result of a method (unless the method evaluates to a
> method?).

But no method can evaluate to a method now, because of method autoevaluation.
This is what disturbs me. I want to type  (| a = (|| (|b| c) )| ) a  and get the "(|b|
c)" method back.
but this doesn't work.

> If you want to add another type of slot to the scheme (as opposed
> to a completely abstract feature) that is associated with any existing slot
> then it has to be possible for them to be associated with slots that contain
> data (the x! slot would return a method that evaluates to what's stored in x).

Sorry, I don't understand what you mean by "the x! slot would return a method that
evaluates to what's stored in x".
How could this help if you want to extranct a method out of "x". Having returned a
method that evaluates to the value (possibly another method, raw) contaned in the slot
"x". Wouldn't it be simpler to return just the raw "x" ?
Did you mean: "the x! slot would contain a method that when evaluated will return
what's stored in x "   ?

>
>
> A user can choose to designate a slot as assignable or constant. They should
> also be able to choose whether the slot will be "data only" (no associated x!
> slot) or "data and method".

Yes, of course.

Maybe there could be handly to designate a simple way to flag slots, so weak slots
(GC) can also be implemented.

Maybe the user could indicate what will be the name of the "accessor" slot so that no
strange slot names ("a!","a::",...) will be used
but explicitly . For example: (|  b <mymethod= (|| method) |) where "mymethod" will
say the parser
what will be the name of the (x!) raw access slot that will be created with a "raw
read primitive".
This syntax is just a product of my tired mind and is not a syntax proposal but just
an example. The thing should be simple
and unambigue and handle "read-only" and "read-write" slots.
The idea behind this is that maybe is better to force poeple who want to use this
feature to prepare the slots to be used this way.
The programs wich will need to inspect arbitrary objects will be only debuggers and
they are not a part of the language, and traditionally
use all kind of tricks (_primitives are not so bad tricks, so Self  will still be
ahead of the others).

>
> How much of a code base does Self have anyways? Is compatibility *that*
> important?

Self4 is a complete system, with fundamental framework and a complete GUI and IDE,
plus smalltalk-emulator and more...
I think a little dialectization would not harm, but a major one break our already
little community.

Marko