MacRuby

Ruby
21

On Feb 28, 2008, at 8:46 PM, Laurent S. wrote:

I do like the current implemented one, as many people so far.

duck.foo 1, bar:2

Oh right, duck.foo 1, bar: 2 … not duck foo:1, bar:2 :slight_smile:

22

On Thu, Feb 28, 2008 at 6:19 PM, Rick DeNatale [email protected]
wrote:

form and emit the ‘right thing’.
cases where the Objective-C selector matches the ruby selector,
duck foo:1, bar:2
Or

      duck foo: 1 bar: 2

which is even more elegant, since it’s the same syntax as Smalltalk

The problems with these syntaxes are that it’s hard to parse them, and
that they can lead to ambiguities when wrongly used.

For example,

duck.foo: x, with: y

could be written by mistake as

duck.foo :x, with: y

which has a completely different meaning.

Also, when the parenthesizes are omitted, it may be hard to correctly
parse (assuming that you want to send the message to self)

foo:x, with:y

That’s why I think that the following is the best compromise so far,
between readability and reliability.

foo x, with:y # or foo(x, with:y)

Laurent

23

On 2008.02.29 08:15, Yukihiro M. wrote:

That is very important design decision. Objective-C-ish calling or
Ruby-ish calling. The latter makes program consistent, but the former
makes program obvious. Hmm.

Actually, this would be a really great time to talk about trying to
unify
the keyword argument syntax across implementations so that we do not
have
to have that discussion later or contend with several variants. I know
that
we are not at the 2.0 threshold yet, but obviously folks are starting to
get there.

In the particular case of MacRuby, I would go for implicitness unless
there is a reason that the programmer needs to know the difference. If
we can define an official syntax (and semantics) for keyword arguments
that also helps MacRuby, I think that would be the optimal solution.

I would probably prefer one of the Smalltalkish variants as the
standard:

duck foo: 1, bar: 2

This plausibly conforms to current method semantics:

def duck(**kwargs) # Implicit in the vcall
sym, arg = kwargs.shift
send sym, arg, **kwargs
end

24

On 2/28/08, Laurent S. [email protected] wrote:

foo x, with:y # or foo(x, with:y)
One thing that’s yet to be mentioned is that the Ruby keyword
arguments are position independent so that using Ruby 1.9 semantics:

 foo(x, a: y, b: z)

and
foo(x, b:z, a:y)

are equivalent, but in MacRuby, as I understand it they result in two
different message selectors foo:a:b: and foo:b:a: respectively.

I’m something which I didn’t comment on in an earlier posting might
bear some discussion.

I’d posed a situation where a Ruby class had implemented a foo method
with ruby 1.9 handling of ‘keyword’ arguments via an optional hash as
the last argument of a *args. then asked

duck.foo(1, bar: 2)      #  mapped to foo:bar: what does an

instance of C do with this?

And Laurent responded:

Here, MacRuby will check if duck responds to foo:bar:. If true, this
message is sent with 1 and 2 as arguments. If not true, the foo
message is sent instead with 1 and {:bar => 2} as arguments.

If you’re working with pure Ruby objects, the second code path should
always be taken. Unless you define foo:bar: in your Ruby class.

I’m concerned here about the automatic ‘chicken-type’ and branch in
the caller, for the performance implications if nothing else.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

25

On 2/28/08, Richard K. [email protected] wrote:

On Feb 28, 2008, at 7:44 PM, Evan P. wrote:

tight integration. This is essential what matz says.

    duck foo:1, bar:2

Or

      duck foo: 1 bar: 2

which is even more elegant, since it’s the same syntax as Smalltalk

Somehow I feel like I’m back in late 1981 or early 1982, when Brad
Cox and Tom Love at ITT, I at IBM, and probably others, had read the
August 1981 issue of Byte magazine and were trying independently to
graft Smalltalk onto C independently. Brad, Tom and I later became
friends when we met, but Objective-C certainly outlived ClassC which
never really got any visibility outside of Big Blue.

More seriously, I tend to lean on the side of making things like the
objective-c/ruby interface a little more visibility, since I’ve
learned that transparency isn’t always what it’s cracked up to be.
http://talklikeaduck.denhaven2.com/articles/2007/11/17/cool-but-stupid-things-ive-done

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

26

On 2/28/08, Eero S. [email protected] wrote:

get there.

This plausibly conforms to current method semantics:

def duck(**kwargs) # Implicit in the vcall
sym, arg = kwargs.shift
send sym, arg, **kwargs
end

Except, as I understand the discussion, here duck is a variable
representing the receiver of a message with an objective-c message
selector of foo:bar: and which in Ruby might be written as:

class PotentialClassOfDuck
def foo(first_arg, keywords={})

  end

end

I think that a reasonable Ruby parser would have a hard time seeing:

 duck foo: 1, bar: 2

as anything other that

self.duck(foo:1, foo:2)

So I think we’d need to give it some help and write:

duck.foo: 1, bar:2

which given optional parentheses might also be written(?):

duck.foo(: 1, bar: 2)

but I’m not happy with either of those for several hopefully obvious
reasons having to do with the dependence on the presence or absences
of easily misread punctuation and whitespace.

–
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

27

One cool thing Apple did with the MacRuby GC was have it execute
in a background native thread so garbage collection does not lock
up the program execution flow.

Rich

Is this possible with MRI? If so I’d be willing to give a $100 bounty
if someone made a thread safe version for 1.9 :slight_smile:
-R

28

Roger P. wrote:

One cool thing Apple did with the MacRuby GC was have it execute
in a background native thread so garbage collection does not lock
up the program execution flow.

Rich

Is this possible with MRI? If so I’d be willing to give a $100 bounty
if someone made a thread safe version for 1.9 :slight_smile:

Not easily, or at least not without changing the memory model. Most JVM
GCs work this way though, so you can certainly use JRuby.

  • Charlie
29

On Feb 27, 2008, at 7:42 PM, Laurent S. wrote:

http://trac.macosforge.org/projects/ruby/wiki/MacRuby

MacRuby is still extremely experimental, but a first release is
expected very soon.

This. Is. Sweet.

I’ve been working on a hackish interpreter-on-ObjC (though GNUstep)
for a while, as an experiment. This sounds like exactly what I had in
mind.