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

[Richard]

Marko Mikulicic wrote:
> 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.

Or even worse, it looks like you're assigning something to the slot a: :-)

> 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).

> (| 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.

My concern was to make it possible to have x, x:, x! and x:! as four
separate slots. Both x! and x:! would return methods associated with
x and x: respectively.

And you know, this syntax isn't that good since it might make more
sense to have x! return an object and x return a method so that !
would be the value message. But that would completely break all code.

> 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.

Maybe the ! syntax could be extended so that (| a = (|| (|b| c. self!)| ) a
but I'm not sure that self refers to what I want it to return at that point.
And if you can omit self from self sends, does that mean that ! alone should
be meaningful? :-)

> 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 "   ?

Sorry, I keep thinking about x as a data slot and x: as a method slot.
If x already contains a method then x! would return the contents of x
but if it contained 5 then x! would return (5).

> > 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.

Hehe, now that's an interesting idea! Of course, depending on what it's used
for,
it could quickly become very expensive.

> 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.

Yes, good point.

> 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.

There are advantages to a small community. If the new language were sufficiently
and clearly superior that porting the code base would be done quickly, then it
might not break up the community. OTOH, are you certain that adding x! and x:!
syntax for slots would make it qualify as a different language? The reason I
picked x! to return methods and x to return results was precisely to not make
any big changes.