Ruby Language Q's

ruby-talk
41

As you remark yourself, this would break the syntax of passing the value
of an assignment to a method. Som poeple might think this is dirty
programming, but I happen to use it a lot.

I vote for “:” for named method parameters. Then again, I probably will
not use the feature. Too Perlish for my taste.

Curne

···

I’d prefer “=” instead of “:” because passing parameters is a kind of
assignment in the scope of the functions body:

class PC
def initialize(cpu, os=“Windows”, **info)
@cpu = cpu # “cpu” is a mandatory named arg
@os = os # “os” is with the default value
@info = info # symbol=>value hashtable
end
end
PC.new(os=“Linux”, cpu=“P-III”, clock=“600MHz”, hdd=“30G”)

Although I must admit that this is incompatible to how ruby works
currently:

def foo(param=“bar”)
param
end

param=“my value”

foo() # => “bar”
foo(“baz”) # => “baz”
foo(param=“qux”) # => “qux”
param # => “qux” !!!

Therefor there certainly is a need for discussion :slight_smile:

-billy

–
curne@curnomatic.dk | If a vegetarian eats vegetables, what does a
humanitarian eat? | Cell Phairony Inc.

42

Apologies (yet again) for the multiple posts.

I’m trying to find out if this is a problem with Outlook or the news
provider.

···

–
Justin Johnson

43 
yes = "yes"
no = "no"
x = nil
p x.nil? yes: no

Hmm. Not interesting?

Well, the main thing here is that the ‘?’ and ‘:’ are part of the
accompanying symbols so they would be classed as part of the symbol name.
Ruby already does this for symbols ending in ‘?’. I don’t see what the
problem is. If we were talking about a C/C++ parser then that’s a different
matter…

Really? That surprises me about Ruby … lets see:

irb(main):014:0> "".size ? true : false
true

irb(main):013:0> "".size? true : false        
SyntaxError: compile error
(irb):13: parse error
"".size? true : false
               ^
        from (irb):13

Okay, I guess you’re right. If a method is defined having a
trailing ‘?’ then whitespace matters. Totally surprised me.

But then, this is funny:

irb(main):003:0> 1 ? true : false
true

irb(main):002:0> 1?true:false
true

There IS no method #1? defined. Why doesn’t the second code
snippet also generate a parse error? Interestingly:

irb(main):015:0> true? true : false
SyntaxError: compile error
(irb):15: parse error
true? true : false
            ^
        from (irb):15

irb(main):016:0> true?true:false   
SyntaxError: compile error
(irb):16: parse error
true?true:false
          ^
        from (irb):16

irb(main):017:0> true ? true : false
true

I would not have expected the middle code snippet to generate
a parse error (given that “1?true:false” doesn’t) … since
#true? isn’t a defined method, either.

This is all using:

$ ruby -v
ruby 1.6.7 (2002-03-19) [i386-linux]

It also happens in Ruby 1.7.2 as well:

$ ruby-1.7.2 -v
ruby 1.7.2 (2002-05-30) [i686-linux]

Also, ‘yes:’ would only be valid inside a method argument list and so would
cause a parsing error in this case.

Why would it cause a parsing error? Really, it would cause an
“ArgumentError: wrong # of arguments(1 for 0)” as #nil?'s arity
is 0, but (if the named parameter “foo: bar” was implemented)
you would be passing it 1 arg, the object referenced in variable
“no” as the “yes” parameter to #nil? which doesn’t exist.

– Dossy

···

On 2002.08.12, Justin Johnson justinj@mobiusent.com wrote:

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

44

   pierre a b: 1 c: 2

unreadable for me, and I've used APL :slight_smile:

Guy Decoux

45

I see little advantage to doing this, since the function still has to
take its parameters out of the hash. In python, I can write:

def foo(a, b, c):
print a, b, c

foo(a=1, b=2, c=3)
foo(c=3, b=2, a=1)
foo(42, 42, c=9)

and I don’t have to change foo at all in order for this to work. If
Ruby were to get named parameters, I would really dislike changing all
my “legacy” code to support named parameters.

Paul

···

On Wed, Jul 31, 2002 at 12:43:02AM +0900, Dave Thomas wrote:

I don’t think so. The change I was discussing was that

pierre(a, :b => 1, :c => 2)

could instead be written

pierre a b: 1 c: 2

so that the b: and c: would be picked up and converted to a hash as
now. I think it’s parsable, and it doesn’t change the internals at
all.

46

What about leaving the current API as is, and adding new methods to the
API that support named parameters (perhaps one method to "name" the
parameters and another to call methods using named parameters)?

This is not the problem. When you write an extension, you use the same API
than ruby. If you change the API, you must completely change the source
of ruby.

I've the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for *all* methods of ruby

Guy Decoux

47

Tom Sawyer transami@transami.net writes:

···

On Tue, 2002-07-30 at 11:13, Philipp Meier wrote:

I’d prefer “=” instead of “:” because passing parameters is a kind of
assignment in the scope of the functions body:

philp,

i agree. that makes more sense.

you point out an important distinction between assignment, which is what
your doing when you pass parameters, ans hash association/pairs.

But syntactically that’s compatible: it’s currently acceptable Rby to
write

puts(a = “hello”)

Dave

48

Hi,

···

At Wed, 31 Jul 2002 19:58:07 +0900, Justin Johnson wrote:

Thinking aloud: would the argument order be taken care of at parsing time?

my_method( height: 30 width: 20, pos: 10 )

is reordered to:

my_method( pos: 10, width: 20, height: 30 )

or even:

my_method( 10, 20, 30 )

Theoretically impossible. Which method is really called is
unknown until invocation.

–
Nobu Nakada

49

It all depends how you define “the language itself” :slight_smile: Again, I tend
to define it as “this thing that Matz wrote and calls ‘Ruby’”.

Your quite right - until somebody creates another implementation…

It is difficult to derive the core language because Ruby relies on internal
modules such as Kernel for much of it’s basic behaviour.

I’d say that classes/modules such as the following:

Object, Class, Module, Kernel, TrueClass, FalseClass, NilClass, FixNum,
Integer, Numeric, Enumerable, Comparable, BigNum, Proc, Method, Array, Hash,
String …

are part of the core language along with reserved executable code statements
such as if, while, until etc.

FileIO, networking modules, HTML modules etc, I would not class as core
language but as useful extension modules.

···

–
Justin Johnson

“David Alan Black” dblack@candle.superlink.net wrote in message
news:Pine.LNX.4.30.0207310707350.15292-100000@candle.superlink.net…

Hello –

On Wed, 31 Jul 2002, Justin Johnson wrote:

The question being… what exactly is an implementation of Ruby? I
know this has come up before, but I still don’t have a handle on it.

That is a very good question. I think Matz’s implementation is Ruby
with
lots of practical and script-useful add-ons. It’s an incredibly
pragmatic
tool. A lot of this is owed to the language concepts.

But that just takes us back to the question: what is “Ruby”? In other
words: what is this antecedent, pure, Ur-Thing onto which Matz has
added all these other things? I can’t identify this thing, so I tend
to look at the distribution as definitively “Ruby” – not atomic (when
it comes to library stuff and extensions), but definitive in language
features.

Point is, because there’s only one implementation, there isn’t an
official(?) language standard yet. Ruby is not an academic ideal, it’s
a
tangible tool.

Or: the standard could be defined as drop-in replaceability (in both
directions) for current stable Ruby. (Mind you, that’s unofficial :slight_smile:
Or maybe passing the Rubicon test suite.

I’m hoping to implement a pure language version. No perlisms, no FileIO,
no
SAFE, no threads, just classes, modules, arrays, strings…enough for
the
language itself to be complete.

It all depends how you define “the language itself” :slight_smile: Again, I tend
to define it as “this thing that Matz wrote and calls ‘Ruby’”.
Anyway, in case it’s not clear in the midst of all my ostensible
philosophizing, I do look forward to seeing the project.

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

50

There IS no method #1? defined.

in `1?true:false' `1' is interpreted as a Fixnum

    irb(main):015:0> true? true : false

  true? is interpred as a method call

    irb(main):017:0> true ? true : false

There is a space between `e' and `?', this can't be the method true?

#true? isn't a defined method, either.

This is resolved at compile time, ruby don't know if a method is defined
or not

Guy Decoux

51

ts decoux@moulon.inra.fr writes:

pierre a b: 1 c: 2

unreadable for me, and I’ve used APL :slight_smile:

Smalltalk? Rather than

  drawWidget(fred, :x => 10, :y => 20, :color => :red)

we could write interfaces like

  drawWidget fred   x: 10   y: 20  color: red

The Ruby Tk constructors could replace the current instance_eval trick
with this syntax and lose the confusing scoping rules.

Just an idea…

Dave

52

Not necessarily. There can be a transition period in which not all
methods support named parameters (and if you try to call these methods
using named parameters, you will get an exception). And it’s not a
complete change of the Ruby source; you need only change the Init_*
functions.

The same would be true for extensions that don’t define names for their
parameters.

Paul

···

On Wed, Jul 31, 2002 at 01:10:55AM +0900, ts wrote:

This is not the problem. When you write an extension, you use the same API
than ruby. If you change the API, you must completely change the source
of ruby.

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

53

Two comments:

  1. I think the commas are a separate issue.
    Personally I’d write it: pierre a, b: 1, c: 2
    (with or without parens).

  2. Paul makes an excellent point. What I’d propose,
    then, is this:
    a. Keep the notation as I showed it above.
    b. Don’t make it just syntax sugar for a hash;
    make the interpreter smart enough to handle this
    notation (in which case legacy methods will be able
    to automagically handle named parameters).

Example:

def mymethod(shape, width, height)
#… no special code in here
end

mymethod “rectangle”, height: 200, width: 400

Just my thoughts.

Hal

···

----- Original Message -----
From: “Paul Brannan” pbrannan@atdesk.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 10:56 AM
Subject: Re: Ruby Language Q’s

On Wed, Jul 31, 2002 at 12:43:02AM +0900, Dave Thomas wrote:

I don’t think so. The change I was discussing was that

pierre(a, :b => 1, :c => 2)

could instead be written

pierre a b: 1 c: 2

so that the b: and c: would be picked up and converted to a hash as
now. I think it’s parsable, and it doesn’t change the internals at
all.

I see little advantage to doing this, since the function still has to
take its parameters out of the hash.

54

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

The idea was that it wasn’t a language change as such, just a way of passing
named parameters if thats how you chose to build your interface.

If you want your interface to be compact:

a_method( x, y )

If your interface needs to be more descriptive:

a_method width: 20, height: 40, name: "Fred"

You choose.

···

–
Justin Johnson.

“ts” decoux@moulon.inra.fr wrote in message
news:200207301605.g6UG5kN22428@moulon.inra.fr…

What about leaving the current API as is, and adding new methods to the
API that support named parameters (perhaps one method to “name” the
parameters and another to call methods using named parameters)?

This is not the problem. When you write an extension, you use the same
API
than ruby. If you change the API, you must completely change the source
of ruby.

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

Guy Decoux

55

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

The idea was that it wasn’t a language change as such, just a way of passing
named parameters if thats how you chose to build your interface.

If you want your interface to be compact:

a_method( x, y )

If your interface needs to be more descriptive:

a_method width: 20, height: 40, name: "Fred"

You choose.

···

–
Justin Johnson.

“ts” decoux@moulon.inra.fr wrote in message
news:200207301605.g6UG5kN22428@moulon.inra.fr…

What about leaving the current API as is, and adding new methods to the
API that support named parameters (perhaps one method to “name” the
parameters and another to call methods using named parameters)?

This is not the problem. When you write an extension, you use the same
API
than ruby. If you change the API, you must completely change the source
of ruby.

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

Guy Decoux

56

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

The idea was that it wasn’t a language change as such, just a way of passing
named parameters if thats how you chose to build your interface.

If you want your interface to be compact:

a_method( x, y )

If your interface needs to be more descriptive:

a_method width: 20, height: 40, name: "Fred"

You choose.

···

–
Justin Johnson.

“ts” decoux@moulon.inra.fr wrote in message
news:200207301605.g6UG5kN22428@moulon.inra.fr…

What about leaving the current API as is, and adding new methods to the
API that support named parameters (perhaps one method to “name” the
parameters and another to call methods using named parameters)?

This is not the problem. When you write an extension, you use the same
API
than ruby. If you change the API, you must completely change the source
of ruby.

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

Guy Decoux

57

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

The idea was that it wasn’t a language change as such, just a way of passing
named parameters if thats how you chose to build your interface.

If you want your interface to be compact:

a_method( x, y )

If your interface needs to be more descriptive:

a_method width: 20, height: 40, name: "Fred"

You choose.

···

–
Justin Johnson.

“ts” decoux@moulon.inra.fr wrote in message
news:200207301605.g6UG5kN22428@moulon.inra.fr…

What about leaving the current API as is, and adding new methods to the
API that support named parameters (perhaps one method to “name” the
parameters and another to call methods using named parameters)?

This is not the problem. When you write an extension, you use the same
API
than ruby. If you change the API, you must completely change the source
of ruby.

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

Guy Decoux

58

Are you saying you disapprove of this choice
for named parameters? If you disapprove, I agree.
If you approve, I disagree. Confused yet? (If you
don’t approve, I can’t help but refrain from not
disagreeing.)

What I mean is: The fact that an assignment returns
a value is an integral part of Ruby’s express-orientation.
It enables stacked assignments, asssignments embedded
inside expressions, etc.

Heck, I’m used to this from C fram ages ago. I’d hate to
see it go away (nor do I foresee that).

It even bothers me a tiny bit when Ruby gives me a
warning about: if x = y then…

Sometimes I want to tell the interpreter: “I know the
difference between = and ==. Don’t nag me.” But of course,
I don’t do it often, and it’s not a big deal.

Hal

···

----- Original Message -----
From: “Dave Thomas” Dave@PragmaticProgrammer.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, July 30, 2002 1:26 PM
Subject: Re: Ruby Language Q’s

Tom Sawyer transami@transami.net writes:

On Tue, 2002-07-30 at 11:13, Philipp Meier wrote:

I’d prefer “=” instead of “:” because passing parameters is a kind of
assignment in the scope of the functions body:

philp,

i agree. that makes more sense.

you point out an important distinction between assignment, which is what
your doing when you pass parameters, ans hash association/pairs.

But syntactically that’s compatible: it’s currently acceptable Rby to
write

puts(a = “hello”)

59

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

The idea was that it wasn’t a language change as such, just a way of passing
named parameters if thats how you chose to build your interface.

If you want your interface to be compact:

a_method( x, y )

If your interface needs to be more descriptive:

a_method width: 20, height: 40, name: "Fred"

You choose.

···

–
Justin Johnson.

“ts” decoux@moulon.inra.fr wrote in message
news:200207301605.g6UG5kN22428@moulon.inra.fr…

What about leaving the current API as is, and adding new methods to the
API that support named parameters (perhaps one method to “name” the
parameters and another to call methods using named parameters)?

This is not the problem. When you write an extension, you use the same
API
than ruby. If you change the API, you must completely change the source
of ruby.

I’ve the strange impression that you want named parameter only for user
defined methods. If I have named parameter, I expect also to have named
parameters for all methods of ruby

Guy Decoux

60

Yes, of course. I’m still stuck in static compiler thinking.

I suppose that named arguments would incur a performance overhead then…
:frowning:

···

–
Justin Johnson.

nobu.nokada@softhome.net wrote in message
news:200207311111.g6VBBY614629@sharui.nakada.kanuma.tochigi.jp…

Hi,

At Wed, 31 Jul 2002 19:58:07 +0900, > Justin Johnson wrote:

Thinking aloud: would the argument order be taken care of at parsing
time?

my_method( height: 30 width: 20, pos: 10 )

is reordered to:

my_method( pos: 10, width: 20, height: 30 )

or even:

my_method( 10, 20, 30 )

Theoretically impossible. Which method is really called is
unknown until invocation.

–
Nobu Nakada