Pervasive Methods

Ruby
21

On 1/4/07, [email protected] [email protected] wrote:

id obj

it has to hang of another object otherwise

class C
def foo
send :inspect # keyword or method?
end
end

Hmmm … maybe I need some enlightening, but this is what I came up with
…

cat a.rb
def if(*a) p a end

if true then puts ‘keyword 1’ end

if(true)
puts ‘keyword 2’
end

ruby a.rb
keyword 1
keyword 2

That’s the beauty of keywords – the parser is going to intercept them
and invoke the appropriate function via the lexer. Unless I did not
properly define my “if” method there.

TwP

22

[email protected] wrote:

On Fri, 5 Jan 2007, Trans wrote:

Or maybe

obj!send message

that’s pretty good. i was leaning towards a module so we could just try to
write it as an extension now though…

it’s backwards but… imitation of implementation:

module Kernel

def send! obj
  @send_f ||= Functor.new{|op,*a| obj.send(op,*a)}
end

def class! obj
  obj.class
end

def id! obj
  obj.object_id
end

# ...

end

then:

obj = “hello”
obj!class #=> String

obj = 1
obj!send + 2 #=> 3

T.

23

Trans wrote:

Then go “p p” :wink:

Toliet humor --I can’t beleive I said that! blush X-)

In anycase what about uppercase:

obj.SEND message
obj.CLASS
obj.ID

or maybe ‘::’ can have some significance?

obj::send message
obj::class
obj::id

T.

24

[email protected] wrote:

The mnemonics are all wrong if you flip it:

obj <- message # sending the message to the object
obj -> message # sending the object to the message?

You have to think of <- as a two character operator. Of course
the parser would also have to think of it that way. There would have to
be some white space to have it parse as ‘<’ and ‘-’ separately. My only
point is that it can be parsed, but a syntax that was a bit more
stable with respect to white space would certainly be better.

I realize it’s not as intuitive at first glance, but i don’t think it’s
“all wrong”. in fact, “->” is what Perl and PHP both use rather then a
‘.’ so there is already plenty of precedence for it. the mnemonic
disconnect you suggest really comes from calling the obj a “receiver”.
if it’ll help we can avoid that term and find a better way to “read”
this.

As for the class search idea, that can be done easily enough with:

recv.as(BasicObject) -> :class

This introduces the same problem I pointed out with respect to the
semantics of #send but this time with #as.

Ah, good point. Damn, and I really liked the #as method too.

In fact it is worse because
you’ve got normal method call syntax but completely different semantics
since
recv.as(BasicObject)
will parse as an expression to be evaluated as the lhs of the ‘->’
operator.
What kind of object would #as return and how would the -> operator know
about the receiver?

Well, that’s not really an issue i don’t think. It just returns a
suitable proxy. But your first point makes it rather mute in any case.

class A; def m; end; end
class B < A; def m; end; end

class C
def example
self.m # calls B#m
(self, A) <- :m # calls A#m (kind of ugly syntax though)
end
end

Agree with that, which is what I’ve used #as for too. Can the (self, A)
syntax you suggest really work w/o problem? I fear it might go against
Matz’s no look-ahead rule for the parser. Is that true? And if it is,
have you any other suggestion for it?

T.

25

Chris C. wrote:

:: is the scoping operator, so unless we can make crazy lowercase
constants that can be run, I don’t think that that’s teh way to go

irb(main):001:0> obj = “string”
=> “string”
irb(main):002:0> obj::class
=> String

T.

26

On Sat, 6 Jan 2007, Gregory B. wrote:

On 1/4/07, [email protected] [email protected] wrote:

still. shorter is good. maybe something like

__( obj ).send message

This is a really bad idea, but I might as well put it out there. I
don’t think it’s possible to do presently, but I think it’s about as
ugly as everything else suggested, no more, no less.

but it’s possible NOW. see the latest annouce on the list!

-a

27

Yes, it calls methods, but just normal methods, you can’t make methods
that cannot be called with ., but can with ::. But constants cannot
be called with . (or can they?)

28

On 1/5/07, [email protected] [email protected] wrote:

ugly as everything else suggested, no more, no less.

but it’s possible NOW. see the latest annouce on the list!

Oh, sorry ara. I was actually talking about the arrow.

29

[email protected] wrote:

recv.private_method # error
recv.class # is this Object#class? is this for recv
recv <<- :stuck_out_tongue: # standard dispatch with access to private method :stuck_out_tongue:
named methods

BasicObject could be frozen so that its methods can’t be redefined/
undefined.

Regardless of my particular suggestions I think it is helpful to view
the issues (1,2,3)
separately rather than as a larger indivisible problem.

Great observations and well summarized. Thank you!

I like you’re ‘<-’ idea. I think you make a very good point about this
being a dynamic dispatch operator. It did not dawn on me before but it
doesn’t make a whole lot of sense to have overridable dyanimic dispatch
but not for literal dispatch. #send should just mean ‘.’ And I would
suggest that unless #send is going to control all dispatching,
including literal calls, then another operator as you suggest is the
right idea.

The operator you suggest however would probably have to be flipped to
avoid ambiguity with Symbol#@-. Eg. recv < -:class (I know rare. but
possible).

As for the class search idea, that can be done easily enough with:

recv.as(BasicObject) -> :class

Though is would be better to code #as into core. But I would like to
see a short hand for the BasicObject case. Maybe

recv ~> :class

To outline, this would give ruby a complete set of dispatch operators:

. literal
<- dynamic
<<- functional (dynamic)
<~ pervasive (dynamic)

T.

30

:: is the scoping operator, so unless we can make crazy lowercase
constants that can be run, I don’t think that that’s teh way to go

31

On Jan 5, 2007, at 1:55 PM, [email protected] wrote:

I wonder if 1 & 2 might be better addressed via syntax. Something
like:

recv.m # standard dispatch with literal method name
recv <- :m # standard dispatch with dynamic method name

Another thought on the syntax:

recv.m a1
recv._ :m, a1 # dispatch to named method
recv.! :m, a1 # dispatch to named method (include private methods)

The mnemonic is that the underscore represents a blank method name
and the
blank is filled in by the first argument. Just think of the sequence
“."
and “.!” as syntax and not as the standard dot with methods "” and “!”.

Of course this means that “_” and “!” would not be valid method names
(well,
“!” is already invalid

Gary W.

P.S. Does anyone else think that language design is unnecessarily
constrained
by insisting on ASCII/Latin-1 characters? It sure would be nice to
assume that
source code was in Unicode and thus gain access to some more interesting
characters to use for language semantics.

P.P.S. Yes, I know about APL.

Gary W.