Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Wednesday, March 28, 2018 at 2:25:42 AM UTC-5, Gregory Ewing wrote:
> Rick Johnson wrote:
> > The only difference is when you want to make a call from a
> > _reference_, which, as you and i well know, is not the
> > most common way func/meths are called (these are rare).
> 
> No, but it's the case we're talking about here. If
> functions don't behave the same way in all circumstances,
> you can't claim them to be first-class.

Just for the record: i never made any such claim. O:-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Thu, Mar 29, 2018 at 12:28 AM, Steven D'Aprano
 wrote:
> On Tue, 27 Mar 2018 11:34:17 +1100, Chris Angelico wrote:
>
>> Question: How do you get a reference to a Ruby function? Or are they not
>> first-class objects?
>
> https://stackoverflow.com/questions/4294485/how-do-i-reference-a-function-
> in-ruby
>
> Especially this answer, which is worth reading:
>
> https://stackoverflow.com/a/4294660
>
> As best I can interpret it, Ruby starts with the premise that functions
> and methods are NOT first-class values -- or rather, since Ruby functions
> are actually methods of Object, there are no functions, only methods, and
> they are not first-class values.
>
> obj.method, despite superficially looking like the same as Ruby's dot
> syntax for attribute access, actually is syntax for calling the method.
>
> In practice, that's not as restrictive as it may seem. Where Python would
> pass a function object to a higher-order function, Ruby would usually
> pass an anonymous block or possibly a Proc.
>

Fair enough. There's no particular reason for *functions* per se to be
first-class, as long as you can do the same conceptual thing of "here,
you over there, have this piece of code to use". IMO
functions/callables are the cleanest way to do that, but if you have
to pass a code block, that's no worse than I've seen people do:
constructing an anonymous function that just calls some other
function. Not a big deal in the scheme of things.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Tue, 27 Mar 2018 11:34:17 +1100, Chris Angelico wrote:

> Question: How do you get a reference to a Ruby function? Or are they not
> first-class objects?

https://stackoverflow.com/questions/4294485/how-do-i-reference-a-function-
in-ruby

Especially this answer, which is worth reading:

https://stackoverflow.com/a/4294660

As best I can interpret it, Ruby starts with the premise that functions 
and methods are NOT first-class values -- or rather, since Ruby functions 
are actually methods of Object, there are no functions, only methods, and 
they are not first-class values.

obj.method, despite superficially looking like the same as Ruby's dot 
syntax for attribute access, actually is syntax for calling the method.

In practice, that's not as restrictive as it may seem. Where Python would 
pass a function object to a higher-order function, Ruby would usually 
pass an anonymous block or possibly a Proc.

-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Rick Johnson wrote:

The only difference is when you want to make a call from a
_reference_, which, as you and i well know, is not the most
common way func/meths are called (these are rare).


No, but it's the case we're talking about here. If
functions don't behave the same way in all circumstances,
you can't claim them to be first-class.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Wed, Mar 28, 2018 at 1:22 PM, Rick Johnson
 wrote:
> On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
>> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
> [...]
>> > Since when did utilizing a method to request a specific
>> > value become some sort of magic?
>>
>> Since it requires a special method that has super powers no
>> method you can write yourself can do.
>
> That's hilarious. I guess you never called __init__? LOL!

Ah yes, argument by ridicule. An excellent way to cover over the fact
that you have not a shred of truly viable argument to bring out.

Last I checked, __init__ was just like any other dunder method: a
perfectly ordinary method that happens to be called by someone else. A
callback method, if you will.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
[...]
> > Since when did utilizing a method to request a specific
> > value become some sort of magic?
>
> Since it requires a special method that has super powers no
> method you can write yourself can do.

That's hilarious. I guess you never called __init__? LOL!

> Can you write a pure-Ruby method that does the same thing
> as Object.method, using only standard, public parts of the
> Ruby API? No special debugger hooks or "subject to change
> without warning" internal APIs or other private
> implementation details.

I'm not your personal tutor, Steven. And i'm not about to
waste one second of my time writing a solution to a non-
problem. Ruby already provides a well-known mechanism to
retrieve the method object. If you seek assistance, why
don't you go over the Ruby-list and ask them for help. I'm
sure they'd be very eager to help after hearing all the nice
things you've said about Ruby.

> > Even though i prefer Python's way better, the implicit
> > return of Python function references is far more "magical"
> > than making an explicit call to a method will ever be.
>
> Let's say you have an object, lassie = Dog(). How do you
> get access to her tail? Do you use dot syntax:
>
> lassie.tail

I dunno, because you failed to provide a class definition
for `Dog`, so i have nothing to go on save this horrid
explanation of yours. It'd be like me asking you to list the
contents of my refrigerator. Listen, post a code sample and
then i'll comment on it. Until then, don't expect me to read
your mind.

> [snip: more questions about some mysterious Dog class
> (probably stored at Area 51!)]
>
> Ruby attributes are always private.

Indeed. Unlike Python, Ruby is a pure OO language, and thus,
demands that public attributes must be explicitly made
public. Think of Ruby as existing somewhere between Python
and Java. Ruby tries to be as pure about OOP as it can
without becoming as onerous as Java. So yeah, you can safely
assume that Python and Ruby are not the same language
(surprising, i know!)

> You must write accessor getter and setter methods if you
> want to access them from outside the instance or class.

Yes. Unlike Python, Ruby doesn't believe in the philosophy
of "consenting adults" (where privatization of attributes
and methods is done using something as ridiculously brittle
as leading underscores [insert laugh track here]). And Ruby
sure as heck does not promote the utterly annoying Python
misfeature otherwise known as "name mangling".

Which reminds me!!!

So you think Ruby is the _only_ language that has
misfeatures? Well, feast your eyes on this Python
perversion!

>>> class Fu(object):
def bar1(self):
pass
def _bar2(self):
pass
def __bar3(self):
pass
>>> fu = Fu()
>>> [name for name in dir(fu) if 'bar' in name]
['_Fu__bar3', '_bar2', 'bar1']

What happened to the method named "__bar3"?

Where did it go?

"Hey Python, I want my symbol back!"

Tip: Better go check Area 51, cause i assure you, Steven,
you won't find that symbol anywhere in Python. It's gone
dude! Off in another parallel universe. Probably hangin'
with the Squaches and eatin' beef jerky, for all we know.

And to think! During this entire thread you have gone out of
your way to call Ruby inconsistent and accuse her of
returning surprising results... well then... tell us Mr.
D'Aprano, how does the crow taste? Hmm?

> But once you have those accessors, you can use lassie.tail
> to access the member (attribute) tail, and lassie.bark to
> *call* the method. There is no member "bark" because
> methods aren't values.

Care to provide some code that will prove your point? Or are
we condemned to suffer more of these horrid explanations of
yours?

PS: If you need help writing the Dog class, send me a PM.
And if you're nice, maybe i'll help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
> On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
[...]
> > Cool, so Greg was right: you can't get a reference to a method or
> > function. You need magic to simulate it.
>
> Since when did utilizing a method to request a specific value become
> some sort of magic?

Since it requires a special method that has super powers no method you 
can write yourself can do.

Can you write a pure-Ruby method that does the same thing as 
Object.method, using only standard, public parts of the Ruby API? No 
special debugger hooks or "subject to change without warning" internal 
APIs or other private implementation details.

I don't believe you can.

If you can emulate Object.method, without calling Object.method either 
directly or indirectly, then it is not magic.

But if you can't, then it relies on private, esoteric knowledge of the 
Ruby internals not available to anyone else. In other words, magic.



[...]
> Even though i prefer Python's way better, the implicit return of Python
> function references is far more "magical" than making an explicit call
> to a method will ever be.

Let's say you have an object, lassie = Dog(). How do you get access to 
her tail? Do you use dot syntax:

lassie.tail

or do you call some sort of special "attribute access method"?

lassie.attribute("tail")


Of course you use the first. How is dot attribute syntax "implicit"? The 
dot for attribute access is right there, as is the name of the attribute.

None of this changes one iota if we write `lassie.bark` instead of 
`lassie.tail`. There's nothing "implicit" about it, it is as explicit as 
you can possibly get: use the dot attribute access (pseudo)operator to 
get a reference to the attribute, regardless of whether that attribute is 
a tail or a method.

The difference with Ruby is that they treat methods as a distinct kind of 
thing to other members, even though they use the same syntax (dot) for 
both. Yay for inconsistency!

Ruby attributes are always private. You must write accessor getter and 
setter methods if you want to access them from outside the instance or 
class. But once you have those accessors, you can use lassie.tail to 
access the member (attribute) tail, and lassie.bark to *call* the method. 
There is no member "bark" because methods aren't values.

That means to get access to a first-class value of the bark method, you 
need a special function, Object.method, which uses magic to wrap the 
method in an ordinary Ruby object. That's not needed in Python, because 
methods already are ordinary Python objects.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 4:47:05 PM UTC-5, Gregory Ewing wrote:
> Rick Johnson wrote:
> > rb> Object.method("print_name").call("Meathead")
>
> Yes, but the point is that you have to have to use a different
> syntax to call it. This is like having to say
>
> f.__call__(arg)
>
> in Python instead of just
>
> f(arg)

You _can_ call a Ruby func/method directly by name, and i've
already demonstrated that fact. For example, the following is
perfectly legit (although untested):

def f(arg)
nil
end
f("arg")

And here is the equivalent code in Python (notice the
similarities):

def f(arg):
pass
f("arg")

The only difference is when you want to make a call from a
_reference_, which, as you and i well know, is not the most
common way func/meths are called (these are rare).

Here is Ruby 1.9:

ref = Object.method("f")
ref.call("arg")

And the Python equivalent:

ref = f
ref("arg")

NOTE: Of course, the "Python equivalent" assumes `f` is in
the current module space, whereas in Ruby, Object is
available _everywhere_.

As you can see, there is nothing "magical" about the Ruby
code. Sure, one could claim it is more onerous (and i would
agree). But to claim it is "magic" (as Chris did) is absurd.

PS: I must stress again that i am using Ruby version 1.9 and
have been for many years. I must also stress there have been
many changes in the Ruby language since 1.9 and i have not
kept up with them. So, it may be possible to do `ref("arg")`
in the newer versions. The point is, before anyone accuses
Ruby of not doing X, Y or Z -- they really should go read
the docs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Rick Johnson wrote:

rb> Object.method("print_name").call("Meathead")


Yes, but the point is that you have to have to use a different
syntax to call it. This is like having to say

   f.__call__(arg)

in Python instead of just

   f(arg)

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Chris Angelico wrote:

Ahh, that explains it. Great. So how do you build higher-order
functions? Or don't you?


You don't, exactly. You have to pass around objects
with a method to invoke when you want to "call" them.

Ruby has a code-block syntax that helps with this
somewhat, but I don't think you can invoke one with
the same syntax that you use for calling a method.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 11:35:31 AM UTC-5, Chris Angelico wrote:
> Why are you suggesting that this is magic?

_You_ are the one who leveled the accusation that Ruby's
methodology for fetching a function reference (a la):

Object.method(meth-name-here)

is "magic". I'm merely requesting that you defend _your_
accusation. That's all.

> Yep, one of the most misunderstood lines in the zen.
> "Explicit" means "stuff I like", and "implicit" means
> "stuff I don't like". Or at least, that's how I see this
> used.

Perhaps (and unfortunately) some folks in this community
interpret the zen as you claim, however, the words explicit
and implicit have clear definitions, and thus, to ascribe
them to personal "likes" is a miscarriage of both
comprehension and objectivity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Wed, Mar 28, 2018 at 3:28 AM, Rick Johnson
 wrote:
> On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
> [...]
>> Cool, so Greg was right: you can't get a reference to a
>> method or function. You need magic to simulate it.
>
> Since when did utilizing a method to request a specific
> value become some sort of magic?
>
> Do you consider this to be magic?
>
> os.lstdir('C:\\')

That requests the "lstdir" method of the "os" object, most likely a
module. And then it calls that. Nope, not magic. When you use the name
"os", you get the object referenced by that name. When you put a dot
after an object, you get an attribute of that object. When you put
parentheses after an object, you call it. Why would it be magic?

> What about this?
>
> ''.join(map(chr, [109, 101, 97, 116, 32, 104, 101, 97, 100]))
>

You have a string literal, and you get a method off that object.
Etcetera. Why are you suggesting that this is magic?

> Even though i prefer Python's way better, the implicit
> return of Python function references is far more "magical"
> than making an explicit call to a method will ever be.
>
> Python Zen Says: "Explicit is better than implicit"

Yep, one of the most misunderstood lines in the zen. "Explicit" means
"stuff I like", and "implicit" means "stuff I don't like". Or at
least, that's how I see this used.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
[...]
> Cool, so Greg was right: you can't get a reference to a
> method or function. You need magic to simulate it.

Since when did utilizing a method to request a specific
value become some sort of magic?

Do you consider this to be magic?

os.lstdir('C:\\')

What about this?

''.join(map(chr, [109, 101, 97, 116, 32, 104, 101, 97, 100]))

Even though i prefer Python's way better, the implicit
return of Python function references is far more "magical"
than making an explicit call to a method will ever be.

Python Zen Says: "Explicit is better than implicit"

Hmm, i suppose Python's constancy is overrated[1]. 

[1] Which is merely a nice way of saying: "It's a lie!".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 11:00 PM, Rick Johnson
 wrote:
> On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote:
>> Chris Angelico wrote:
>> > Question: How do you get a reference to a Ruby function? Or are they
>> > not first-class objects?
>>
>> They're not first-class. So, you can't.
>
> If Chris means: "how do you get a reference to a Ruby
> function object", then yes, it _is_ possible! Consider the
> following:
>
> ## Ruby 1.9 ##
> rb> def print_name(name); puts "Your name is #{name.inspect}"; end
> rb> print_name("Chris")
> "Chris"
>
> In this case, since the function `print-name` was defined
> outside of an class definition, Ruby will add the function
> as a method of `Object` (Ruby is more purist about OOP than
> Python). So, to get a reference to the function object
> (which is now a method of `Object`!), all we need to do is
> call a method named "method" ("gigity") and pass it the name
> of the method as a string:
>
> rb> Object.method("print_name")
> #
> rb> Object.method("print_name").call("Meathead")
> Your name is "Meathead"
>
> PS: Greg, please inform Chris that Google is his friend. ;-)

Cool, so Greg was right: you can't get a reference to a method or
function. You need magic to simulate it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 3:24:48 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:

> Printing a string and calling a function is obfuscated code? Deary me.

When the programmer can't be bothered to invent names more
descriptive than `a` and `b`, why yes, yes it is.

> And besides, while I'm more than happy to take (undeserved)
> credit for all the things Ruby gets right, I draw the line
> at being blamed for Ruby misfeatures like parens-less
> function calls, and the inconsistent behaviour they lead
> to.

What version are you testing this "misfeature" on?
Personally, I'm using 1.9, so i have no idea if the
"misfeature" has been repaired or not. The latest stab;e
release is 2.5.0. There have been a ton of changes since
1.9!

> > > Because of this "fix", the printed strings no longer
> > > match the code being executed, but the strange,
> > > inconsistent behaviour still occurs.
> > 
> > The supposed "inconsistent behavior" here has absolutely
> > nothing to do with Ruby, no, it's all on _you_. _YOU_ are
> > the one who created a non-sensical function
> 
> I love watching you trying to squirm your way out of
> admitting that you screwed up. Returning the input plus two
> is nonsensical is it?

When the function is named `a`, why yes, yes it is!

> As I said, don't blame me for Ruby's poor design.  By the
> way, there are precisely the same number of clues that:  a
> is a function as there are for:  super  in Ruby. But you
> know that, because you were vehemently defending the use of
> super with no parens and why it isn't inconsistent for it
> to do something completely different from super() with
> parens.

Okay, Mr. "Language Designer"... how do _you_ propose to
implement Ruby's super in a way that provides these same
three distinct forms:

(1) implicit passing of args: `super`
(2) explicit passing if args: `super(arg1, arg2, ..., argN)`
(3) no arg passing: `super()`

Let's hear it! And don't forget to make your design
consistent with func/meth calls, even though super is not a
func at all -- but i digress!

> So now you're claiming I hacked the Ruby interpreter to
> support non- standard code? I can smell the desperation in
> you from the other side of the planet.  Rick, nothing I did
> was illegal Ruby code. Everything I did was 100% following
> the rules of the Ruby language.

The rules you violated were _style_ and _sanity_ rules.
Every wise programmer knows that readability dictates one
space on each side of an operator:

YES: a + b
NO: a+b
NO: a+ b
NO: a +b
HELL NO: a+   b

Ruby is punishing you for your petulant behavior. And if i
were you, i'd be kissing Matz's backside for only giving you
a "surprising result". Because if *I* were the creator of
Ruby, i'd have Ruby format your hard-drive for doing _less_.

But i look forward to your proposed solutions to Ruby's so-
called "broken expressions and inconsistent super". Oh guru,
please enlighten us with your language design wisdom.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote:
> Chris Angelico wrote:
> > Question: How do you get a reference to a Ruby function? Or are they
> > not first-class objects?
>
> They're not first-class. So, you can't.

If Chris means: "how do you get a reference to a Ruby
function object", then yes, it _is_ possible! Consider the
following:

## Ruby 1.9 ##
rb> def print_name(name); puts "Your name is #{name.inspect}"; end
rb> print_name("Chris")
"Chris"

In this case, since the function `print-name` was defined
outside of an class definition, Ruby will add the function
as a method of `Object` (Ruby is more purist about OOP than
Python). So, to get a reference to the function object
(which is now a method of `Object`!), all we need to do is
call a method named "method" ("gigity") and pass it the name
of the method as a string:

rb> Object.method("print_name")
#
rb> Object.method("print_name").call("Meathead")
Your name is "Meathead"

PS: Greg, please inform Chris that Google is his friend. ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:

> On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote:
>> Rick, you're supposedly familiar with Ruby. And yet, you didn't notice
>> that your supposed "fix" didn't touch any executable code, all it did
>> was modify the strings being printed.
> 
> Because the goal was to *UN-OBFUSCATE* the code, not to provide a
> solution for the problem _you_ created.

Printing a string and calling a function is obfuscated code? Deary me.

And besides, while I'm more than happy to take (undeserved) credit for 
all the things Ruby gets right, I draw the line at being blamed for Ruby 
misfeatures like parens-less function calls, and the inconsistent 
behaviour they lead to.


>> Because of this "fix", the printed strings no longer match the code
>> being executed, but the strange, inconsistent behaviour still occurs.
> 
> The supposed "inconsistent behavior" here has absolutely nothing to do
> with Ruby, no, it's all on _you_. _YOU_ are the one who created a
> non-sensical function 

I love watching you trying to squirm your way out of admitting that you 
screwed up. Returning the input plus two is nonsensical is it?

Thank the gods I didn't add *three*, your head probably would have 
exploded in confusion.


> with a single char name; and _YOU_ are the one who
> placed a call to that function in the middle of an expression, which, on
> first glance, looks to be a common numeric addition or string
> concatenation. There are no syntactical clues that `a` is a function.

As I said, don't blame me for Ruby's poor design.

By the way, there are precisely the same number of clues that:

a

is a function as there are for:

super

in Ruby. But you know that, because you were vehemently defending the use 
of super with no parens and why it isn't inconsistent for it to do 
something completely different from super() with parens.


> Thus, it is _YOU_ who is to blame for the supposed "unexpected output".
> 
> Ruby followed the rules.
> 
> But you didn't.

So now you're claiming I hacked the Ruby interpreter to support non-
standard code? I can smell the desperation in you from the other side of 
the planet.

Rick, nothing I did was illegal Ruby code. Everything I did was 100% 
following the rules of the Ruby language.

But you know that. I'm just enjoying watching you trying to weasel out of 
acknowledging that you massive screwed up by editing the strings instead 
of the function calls.

I look forward to reading your increasingly desperate claims that it was 
not only intentional but the correct thing to do.




-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Stephen Hansen]

On Mon, Mar 26, 2018, at 2:19 PM, Rick Johnson wrote:
>Sure, the behavior that Steven
> uncovered is odd, but it could be that Maz harbors a strong
> disliking for undisciplined pupils, and thus, he designed
> and placed this little trap in the hopes the pain it induced
> might encourage the petulant little meat-heads to follow
> some sensible styling rules.

My god, I've been away from this list for quite awhile, but we're still 
entertaining this fool? 

-- 
Stephen Hansen
  m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 5:54 PM, Gregory Ewing
 wrote:
> Chris Angelico wrote:
>>
>> Question: How do you get a reference to a Ruby function? Or are they
>> not first-class objects?
>
>
> They're not first-class. So, you can't.
>

Ahh, that explains it. Great. So how do you build higher-order
functions? Or don't you?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Chris Angelico wrote:

Question: How do you get a reference to a Ruby function? Or are they
not first-class objects?


They're not first-class. So, you can't.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Gregory Ewing]

Ned Batchelder wrote:
"Ranting Rick" isn't trying 
to enlighten, educate, or learn. He's trying to rile people up, and he 
is good at it.


I don't think he's even trying, it just come naturally
to him. Rick rants the way wind blows and water wets.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 6:11:31 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote:
[...]
> > Hmm. If "syntax parser rules" could prevent poorly
> > formatted code, then there'd be no need for style guides.
>
> It may be telling that my team has minimal style standards
> for C/C++, and none at all for Python... [We don't feel it
> requires any.]

Hmm, which would indicate to me you're part of a small,
tight-nit group of like-minded folks. However, what works
well for small groups begins to fall apart in larger
social environment.

> > > > No self-respecting professional programmer would ever
> > > > write in such a manner.
>
> I should also have said that I think this assumes a certain
> level of expertise with the language.  We all start out as
> novices with every new language, and may spend a very long
> time there, depending on how much we use it...

Hmm, very true. If only Steven had been more experienced with
Ruby, then he would have known to avoid that pitfall. O:-)

> > Perl is a special case (and thus not a good retort)
> > because the language itself was purposely intended to be
> > cryptic.
>
> I think Larry would disagree with that assessment...

And that's an opinion he gets to have ;-)

[...]

> > IOWs: It's not a bug, dude, it's a feature.
>
> I dunno, this smells a lot like BS.
>
> Ruby touts itself as being a simple language with elegant
> syntax. This thread is my only exposure to it to date, but
> what I've seen here is, frankly, the exact opposite of
> that.

And do you normally judge the worthiness of an entire
language based on one poorly styled non-idiomatic example
created by somone who is (admittingly) not intimately
familiar with the language?

> You should not need a map to distinguish function
> calls from variables,

I agree that the Python mandated empty parens is a nicely
intuitive indication of a func-call, and that's why i use
the empty parens in all my Ruby code (even though Ruby does
not force me to). Hmm, I'm not sure why Matz chose to make
the syntax optional. But whatever his reason may have benn,
i just hold down shift, and strike two keys, and -- whamo --
my coding style is consistent.

> or operands from function arguments,

Agreed. The syntax "foo(x, y, z)" nicely encapsulates
the arguments whereas "foo x, y, z" does not.

> let alone have the latter depend on the position of the
> operator token relative to any whitespace between it and
> the two tokens on either side of it.  That's hard to read,
> complicated, inelegant, and just poor syntax. [My opinion,
> obviously.] That's not enough exposure to decide that the
> language isn't simple and elegant overall, but it certainly
> does induce a strong negative prejudice.

You shouldn't dismiss Ruby over this one little issue. Need
i remind you that Python has its fair share of warts? In
fact, here is one involving Python's implicit self which
occasionally bites even the seasoned pythonista:

>>> class Foo(object):
... def bar(self, arg1, arg2, arg3):
... pass
>>> foo = Foo()
>>> foo.bar(1,2)
Traceback (most recent call last):
  File "", line 1, in 
foo.bar(1,2)
TypeError: bar() takes exactly 4 arguments (3 given)

(A reinactment of programmer mental state follows)

"Huh?" o_O

"I gave _three_ arguments, you say?" o.O

"Wuh-wuh-what?" O_O

"_THREE_?" #_O

"What the hell are your talking about Python?" ಠ_ಠ

"Are you blind?" (╯°□°）╯︵ ┻━┻

"Cause I'm _looking_ at the freaking code..."  ＼(°ロ＼)

"And i'm _looking_ at the freaking exception..." (／ロ°)／

"but what you're telling me just don't add up!" \(`Д´)

"YOU LIAR!!!"  ┻━┻︵ヽ(`Д´)ﾉ︵ ┻━┻

"Okay. Alright. Listen. I _swears_..."  щ(ﾟДﾟщ)

"I only gave you *TWO* arguments -- just two!" (屮ﾟДﾟ)屮

"WOE IS ME!" （´Д｀）

"I'm so terribly vexed!" (>_<)

"What have i done to deserve this?" （ ´,_ゝ`)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 10:10 AM, Python  wrote:
> Ruby touts itself as being a simple language with elegant syntax.
> This thread is my only exposure to it to date, but what I've seen here
> is, frankly, the exact opposite of that.  You should not need a map to
> distinguish function calls from variables, or operands from function
> arguments, let alone have the latter depend on the position of the
> operator token relative to any whitespace between it and the two
> tokens on either side of it.  That's hard to read, complicated,
> inelegant, and just poor syntax. [My opinion, obviously.] That's not
> enough exposure to decide that the language isn't simple and elegant
> overall, but it certainly does induce a strong negative prejudice.

My understanding of Ruby's design model is that it prefers "intuitive"
to "easy to explain". That means there's a lot of magic to make things
behave the way you would expect. The trouble is that you then end up
with edge cases; the benefit is that you get an easy REPL. Let me
compare three REPLs for you (I'm not a Ruby expert so I won't use it
here):

=== JavaScript ===
rosuav@sikorsky:~$ node
> function f() {
... let x = 1
... let y = 2
... return x + y
... }
undefined
> f()
3
>

=== Pike ===
rosuav@sikorsky:~$ pike
Pike v8.1 release 11 running Hilfe v3.5 (Incremental Pike Frontend)
Ok.
> int f() {
>> int x = 1;
>> int y = 2;
>> return x + y;
>> }
> f();
(1) Result: 3
>

=== Python ===
rosuav@sikorsky:~$ python3
Python 3.8.0a0 (heads/literal_eval-exception:ddcb2eb331, Feb 21 2018, 04:32:23)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
... x = 1
... y = 2
... return x + y
...
>>> f()
3
>>>

===

Python and Pike have fairly simple rules. In Python, a statement ends
at the newline, and a function's body must be indented. That means I
have to hit Tab at the beginning of each line until I'm done. (AIUI
other Python front ends do things differently, but I don't have
ipython handy to test.) Pike defines things by semicolons, so I have
to toss a semicolon after each statement, even in the REPL (it's
annoying to have to write "f();" not just "f()"), but the UI doesn't
need indentation, and it just modifies the prompt to indicate nesting
level (which is controlled by braces).

JavaScript, on the other hand, has far more complex rules. The benefit
is that, like with Python, semicolons aren't required, and like with
Pike, indentation can be skipped when you're typing at the REPL. The
downside is that... well, let's try breaking one of those lines.
First, in Pike:

rosuav@sikorsky:~$ pike
Pike v8.1 release 11 running Hilfe v3.5 (Incremental Pike Frontend)
Ok.
> int f() {
>> int x = 1;
>> int y = 2;
>> return
>> x + y;
>> }
>
> f()
>> ;
(1) Result: 3
>

Exactly the same. The semicolons define it. A line break after "f()"
requires the semi before the code runs. The line break after "return"
doesn't change anything.

rosuav@sikorsky:~$ node
> function f() {
... let x = 1;
... let y = 2;
... return
... x + y;
... }
undefined
> f();
undefined
>

Strange... even though I have all the semicolons, it's still borked.
Because JS has complicated rules about implicit semicolons. Yes, this
is an edge case (the "return" statement takes an optional expression,
so it's legal on its own - it'd be different if I broke the line
before or after an equals sign, for instance, as the two lines
wouldn't be legal on their own), but you get more edge cases when you
create more magic.

Ruby appears to have created a corner case here. It's an extremely
weird one, and it's a consequence of the fact that (a) you can call a
function just by naming it OR by naming it and giving a parameter, and
(b) the plus operator has both unary and binary forms. But you can't
change the plus operator without breaking a LOT of people's
expectations (and even if you decide to disallow unary plus, the exact
same problem will happen with unary minus, and you can't get rid of
that one), and the ability for functions to accept optional arguments
is an excellent feature. So the only way to solve this is to remove
the ability for functions to be called without parentheses.

Question: How do you get a reference to a Ruby function? Or are they
not first-class objects?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Ned Batchelder]

On 3/26/18 7:10 PM, Python wrote:

Humans are already good enough at making mistakes that they
require no additional encouragement, such as what is
provided by allowing such syntactical horrors.

Agreed. And that's why we must respect and follow the code
styling wisdom which has been passed down by those who
struggled before us. Sure, the behavior that Steven
uncovered is odd, but it could be that Maz harbors a strong
disliking for undisciplined pupils

[...]

IOWs: It's not a bug, dude, it's a feature.

I dunno, this smells a lot like BS.


It's a losing game to engage Rick in debate: "Ranting Rick" isn't trying 
to enlighten, educate, or learn. He's trying to rile people up, and he 
is good at it.


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote:
> On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote:
> > On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
> [...]
> > > Ruby followed the rules.
> > > But you didn't.
> >
> > Nonsense... Your language's syntax parser is what defines
> > the rules. All of the expressions Stephen wrote did not
> > yeild a syntax error, therefore he "followed the rules."
> 
> Hmm. If "syntax parser rules" could prevent poorly formatted
> code, then there'd be no need for style guides.

It may be telling that my team has minimal style standards for C/C++,
and none at all for Python... [We don't feel it requires any.]

> > > No self-respecting professional programmer would ever
> > > write in such a manner.

I should also have said that I think this assumes a certain level of
expertise with the language.  We all start out as novices with every
new language, and may spend a very long time there, depending on how
much we use it...  So, basically, I'm saying that's false. :)

> > I think your expectation here is much too high.  I've seen
> > A LOT of Perl written by, for example, professional
> > testers, of this ilk, and I've seen it cause bugs when a)
> > they got the syntax very slightly wrong, or b) they got the
> > syntax right but someone else to whom the intention wasn't
> > clear "fixed" it.
> 
> Perl is a special case (and thus not a good retort) because
> the language itself was purposely intended to be cryptic.

I think Larry would disagree with that assessment...

> Thus, what Perl programmers consider to be "normal and
> perfectly acceptable code" would cause the rest of us to run
> away in horror.

Regardless of what Larry says, I agree with that assessment.  Perl has
been relegated to "only use when there is no option" in my regieme,
which basically means only when it is absolutely necessary to maintain
some legacy garbage that's already Perl.

> > Humans are already good enough at making mistakes that they
> > require no additional encouragement, such as what is
> > provided by allowing such syntactical horrors.
> 
> Agreed. And that's why we must respect and follow the code
> styling wisdom which has been passed down by those who
> struggled before us. Sure, the behavior that Steven
> uncovered is odd, but it could be that Maz harbors a strong
> disliking for undisciplined pupils
[...]
> IOWs: It's not a bug, dude, it's a feature.

I dunno, this smells a lot like BS.

Ruby touts itself as being a simple language with elegant syntax.
This thread is my only exposure to it to date, but what I've seen here
is, frankly, the exact opposite of that.  You should not need a map to
distinguish function calls from variables, or operands from function
arguments, let alone have the latter depend on the position of the
operator token relative to any whitespace between it and the two
tokens on either side of it.  That's hard to read, complicated,
inelegant, and just poor syntax. [My opinion, obviously.] That's not
enough exposure to decide that the language isn't simple and elegant
overall, but it certainly does induce a strong negative prejudice.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
[...]
> > Ruby followed the rules.
> > But you didn't.
>
> Nonsense... Your language's syntax parser is what defines
> the rules. All of the expressions Stephen wrote did not
> yeild a syntax error, therefore he "followed the rules."

Hmm. If "syntax parser rules" could prevent poorly formatted
code, then there'd be no need for style guides.

> > No self-respecting professional programmer would ever
> > write in such a manner.
>
> I think your expectation here is much too high.  I've seen
> A LOT of Perl written by, for example, professional
> testers, of this ilk, and I've seen it cause bugs when a)
> they got the syntax very slightly wrong, or b) they got the
> syntax right but someone else to whom the intention wasn't
> clear "fixed" it.

Perl is a special case (and thus not a good retort) because
the language itself was purposely intended to be cryptic.
Thus, what Perl programmers consider to be "normal and
perfectly acceptable code" would cause the rest of us to run
away in horror.

"Debug that mess?" o_O

"NO WAY!"

> Humans are already good enough at making mistakes that they
> require no additional encouragement, such as what is
> provided by allowing such syntactical horrors.

Agreed. And that's why we must respect and follow the code
styling wisdom which has been passed down by those who
struggled before us. Sure, the behavior that Steven
uncovered is odd, but it could be that Maz harbors a strong
disliking for undisciplined pupils, and thus, he designed
and placed this little trap in the hopes the pain it induced
might encourage the petulant little meat-heads to follow
some sensible styling rules.

IOWs: It's not a bug, dude, it's a feature.

PS: ("meat-head": it's what's for dinner)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
> > Because of this "fix", the printed strings no longer match
> > the code being executed, but the strange, inconsistent
> > behaviour still occurs.
> 
> The supposed "inconsistent behavior" here has absolutely
> nothing to do with Ruby, no, it's all on _you_.

This is utter nonsense.  Ruby's parser allowed the
unintuitive/inconsistent behavior, so it has everything to do with
Ruby. 

The fact that the language allows you to write such expressions means
that SOMEONE WILL.  Your own messages seem to promote Ruby's
paren-less function calls as a good thing (which I vehemently disagree
with, but I can accept that's a matter of preference).  However, a
language that allows (a + b) to evaluate to a different value from
(a +b) (at the same execution point) is syntactically abysmal.

> Ruby followed the rules.
> But you didn't.

Nonsense... Your language's syntax parser is what defines the rules.
All of the expressions Stephen wrote did not yeild a syntax error,
therefore he "followed the rules."  

> No self-respecting professional programmer would ever write
> in such a manner. 

I think your expectation here is much too high.  I've seen A LOT of
Perl written by, for example, professional testers, of this ilk, and
I've seen it cause bugs when a) they got the syntax very slightly
wrong, or b) they got the syntax right but someone else to whom the
intention wasn't clear "fixed" it.

Humans are already good enough at making mistakes that they require no
additional encouragement, such as what is provided by allowing such
syntactical horrors.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Chris Angelico]

On Tue, Mar 27, 2018 at 5:37 AM, Rick Johnson
 wrote:
> The supposed "inconsistent behavior" here has absolutely
> nothing to do with Ruby, no, it's all on _you_. _YOU_ are
> the one who created a non-sensical function with a single
> char name; and _YOU_ are the one who placed a call to that
> function in the middle of an expression, which, on first
> glance, looks to be a common numeric addition or string
> concatenation. There are no syntactical clues that `a` is a
> function. Thus, it is _YOU_ who is to blame for the supposed
> "unexpected output".
>
> Ruby followed the rules.
>
> But you didn't.

Yeah, it's entirely Steven's fault that he was expecting cricket but
Ruby wanted to play Calvinball. But hey, Ruby was totally following
the rules.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Mon, Mar 26, 2018 at 10:43:32AM +, Steven D'Aprano wrote:
> The kicker is that out of these four legal, parenthesis-free ways of 
> calling function a, *three* of them interpret the expression as:
> 
> call a with no arguments
> then add b using the binary plus operator
> 
> but the last, differing only in whitespace, interprets it as:
> 
> call a with a single argument, unary-plus b

Thanks for the explanation.  That's fucking stupid.  I usually prefer
to refrain from cursing in posts but in this case I think that level
of emphasis is required.  And FWIW, this convinces me that Ruby is not
a language I ever want to use.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Python]

On Sun, Mar 25, 2018 at 10:33:49AM -0700, Rick Johnson wrote:
> > [steve@ando ruby]$ ruby ws-example.rb
> > a + b => 7
> > a+b   => 7
> > a+ b  => 7
> > a +b  => 3
> >
> > Here's the source code:
> >
> > # --- cut ---
> > def a(x=4)
> > x+2
> > end
> >
> > b = 1
> > print "a + b => ", (a + b), "\n"
> > print "a+b   => ", (a+b), "\n"
> > print "a+ b  => ", (a+ b), "\n"
> > print "a +b  => ", (a +b), "\n"
> > # --- cut ---
> 
> 
> Short of demonstrating that you have knack for writing
> obfuscated code :-), i don't see the point here. 

I think the point is 7 != 3...

> Here, i took the liberty of un-obfuscating your code [...]

Not to me, you didn't.  While I don't know ruby, I already got from
context that "a" was a function call, including without the parens,
albeit annoying to read.  I've previously seen that in Perl, and never
liked it there either, because you can't immediately tell by looking
at it whether it is a variable or a function call.  While I think that
itself speaks to Stephen's consistency point, I don't think that's too
controvercial.

But what I don't get is how the last print statement prints 3.  There
seems to be some kind of magic happening related to the positioning of
the + relative to the operand(s).  That's neither consistent nor
intuitive.  Or, it's some other thing caused by a detail I overlooked,
but if so your "unobfuscated" version did nothing to clarify what that
detail is, even after scrutinizing it somewhat closely.  In either
case, I can't imagine how Ruby arrives at the answer 3.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote:
> Rick, you're supposedly familiar with Ruby. And yet, you
> didn't notice that your supposed "fix" didn't touch any
> executable code, all it did was modify the strings being
> printed.

Because the goal was to *UN-OBFUSCATE* the code, not to
provide a solution for the problem _you_ created.

> Because of this "fix", the printed strings no longer match
> the code being executed, but the strange, inconsistent
> behaviour still occurs.

The supposed "inconsistent behavior" here has absolutely
nothing to do with Ruby, no, it's all on _you_. _YOU_ are
the one who created a non-sensical function with a single
char name; and _YOU_ are the one who placed a call to that
function in the middle of an expression, which, on first
glance, looks to be a common numeric addition or string
concatenation. There are no syntactical clues that `a` is a
function. Thus, it is _YOU_ who is to blame for the supposed
"unexpected output".

Ruby followed the rules.

But you didn't.

Like a mad scientist you injected obfuscation into your
source code and then blamed Ruby because your poor naming
conventions and your clumsily formed expressions did not
produce the "purdy little result" you expected.
Congratulations, you have forsaken the most vital principle
of good programming -> Readability Counts!.

"Code is read more often than it is written" (ring a bell?).

No self-respecting professional programmer would ever write
in such a manner. Its the kind of crapola that will get you
fired in 2 seconds. Yet, here you are -- THE GREAT AND
POWERFUL D'APRANO -- thumping your chest over this
horrendous code and acting as if we should be proud of you.

Yip of the day: No one is proud of you.

> Here's the code again:

No thanks. I've seen more than i care to see of your little
"examples".

> Of course we can solve the problem by always using
> parentheses when making function calls.

I'm sorry, but _we_ are not required to solve the problems
_you_ create. _You_ made that mess, and now _you_ can clean it
up.

> But that misses the point that Ruby allows this
> inconsistency in the first place.

Hmm, i see. And if the operator of an automobile purposesly
drives off a cliff, who do you blame: driver or
manufacturer?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Sun, 25 Mar 2018 19:16:12 -0700, Rick Johnson wrote:

> On Sunday, March 25, 2018 at 5:57:28 PM UTC-5, Steven D'Aprano wrote:
> 
>> [supposed "fix" to the sample script snipped]
>>
>> You know Rick, every time I start to think that talking to you like an
>> adult might result in a productive and intelligent conversation, you
>> pull a stunt like this.  Once I recover from laughing at your inability
>> to read a simple eight line Ruby script, and then laughing even harder
>> at your inability to tell the difference between a string in Ruby and
>> an actual function call, I *might* come back and read the rest of your
>> post.

[...]

> If not, then explain to this group exactly how i failed.


Rick, you're supposedly familiar with Ruby. And yet, you didn't notice 
that your supposed "fix" didn't touch any executable code, all it did was 
modify the strings being printed. Because of this "fix", the printed 
strings no longer match the code being executed, but the strange, 
inconsistent behaviour still occurs.

For the benefit of those who aren't Ruby experts, the code I used before 
(see below) defines a function called "a", then prints four ways of 
calling that function that differ only in whitespace. For example:

print "a + b => ", (a + b), "\n"


prints the string "a + b", then calls a and adds b using the same syntax 
as that shown in the string, then prints a newline.

The kicker is that out of these four legal, parenthesis-free ways of 
calling function a, *three* of them interpret the expression as:

call a with no arguments
then add b using the binary plus operator

but the last, differing only in whitespace, interprets it as:

call a with a single argument, unary-plus b


Here's the code again:


# --- cut ---
def a(x=4)
x+2
end

b = 1
print "a + b => ", (a + b), "\n"
print "a+b   => ", (a+b), "\n"
print "a+ b  => ", (a+ b), "\n"
print "a +b  => ", (a +b), "\n"
# --- cut ---

and your "fix" was to modify the *strings* without touching the actual 
function calls. Well done Rick.

Of course we can solve the problem by always using parentheses when 
making function calls. But that misses the point that Ruby allows this 
inconsistency in the first place.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Sunday, March 25, 2018 at 5:57:28 PM UTC-5, Steven D'Aprano wrote:

> [supposed "fix" to the sample script snipped]
>
> You know Rick, every time I start to think that talking to
> you like an adult might result in a productive and
> intelligent conversation, you pull a stunt like this.  Once
> I recover from laughing at your inability to read a simple
> eight line Ruby script, and then laughing even harder at
> your inability to tell the difference between a string in
> Ruby and an actual function call, I *might* come back and
> read the rest of your post.

Q1: Do my modifications throw an error???

If so, then provide this group with the exception message
and you shall be redeemed.

Q2: Did my "fix" fail to meet the highly generalized
qualification of "un-obfuscating the code"???

If not, then explain to this group exactly how i failed.

Steven, your highly competitive nature is apparent
to any and all who frequent this group. And i'm sure i speak
for everyone here when i say that we all appreciate the vast
wealth of knowledge you bring to the table. But this time
you have allowed your emotions to get the better of you, and
now your friendly barbs have become purposeful
misrepresentations.

Listen, if i make a false statement or give bad advice on
this list, then i _want_ someone to call me on it. But for
you to cast accusations without providing any evidence to
support those accusations, is beneath the dignity of this
mailing list. I stand behind my "code fix" and i confidently
claim that not only does it meet the requirements, it also
runs without error. And if you disagree with my claim, then
bring forth your evidence.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Sun, 25 Mar 2018 10:33:49 -0700, Rick Johnson wrote:

> On Sunday, March 25, 2018 at 9:11:35 AM UTC-5, Steven D'Aprano wrote:
>> On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
> [...]
>> I never said anything about not allowing it. But since you've gone on
>> the defence about parens-free function calls, how is this for
>> "consistency" in Ruby?
>>
>> [steve@ando ruby]$ ruby ws-example.rb a + b => 7
>> a+b   => 7
>> a+ b  => 7
>> a +b  => 3
>>
>> Here's the source code:
>>
>> # --- cut ---
>> def a(x=4)
>> x+2
>> end
>>
>> b = 1
>> print "a + b => ", (a + b), "\n"
>> print "a+b   => ", (a+b), "\n"
>> print "a+ b  => ", (a+ b), "\n"
>> print "a +b  => ", (a +b), "\n"
>> # --- cut ---
> 
> 
> Short of demonstrating that you have knack for writing obfuscated code
> :-), i don't see the point here.

[supposed "fix" to the sample script snipped]


You know Rick, every time I start to think that talking to you like an 
adult might result in a productive and intelligent conversation, you pull 
a stunt like this.

Once I recover from laughing at your inability to read a simple eight 
line Ruby script, and then laughing even harder at your inability to tell 
the difference between a string in Ruby and an actual function call, I 
*might* come back and read the rest of your post.



-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Sunday, March 25, 2018 at 9:11:35 AM UTC-5, Steven D'Aprano wrote:
> On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:
[...]
> I never said anything about not allowing it. But since
> you've gone on the defence about parens-free function
> calls, how is this for "consistency" in Ruby?
>
> [steve@ando ruby]$ ruby ws-example.rb
> a + b => 7
> a+b   => 7
> a+ b  => 7
> a +b  => 3
>
> Here's the source code:
>
> # --- cut ---
> def a(x=4)
> x+2
> end
>
> b = 1
> print "a + b => ", (a + b), "\n"
> print "a+b   => ", (a+b), "\n"
> print "a+ b  => ", (a+ b), "\n"
> print "a +b  => ", (a +b), "\n"
> # --- cut ---


Short of demonstrating that you have knack for writing
obfuscated code :-), i don't see the point here. One could
easily induce the same level of obfuscation by redefining
numeric operators in an unintuitive manner. But, if your
point is that Ruby's "parens-free function calls" can be
confusing in some highly contrived cases in which the
programmer can't be bothered to write code in a manner that
is intuitive, well then, all we have to do is add the
parens, and poof!, we're back in the land of sanity again.

Here, i took the liberty of un-obfuscating your code by
doing the kind of back-breaking manual labor known only to
the unfortunate inhabitants of Soviet-era gulags, and i did
it by mererly adding the empty parens to each of your method
calls. Here goes:

UH!

> print "a() + b => ", (a + b), "\n"

AG!

> print "a()+b   => ", (a+b), "\n"

OO!

> print "a()+ b  => ", (a+ b), "\n"

EE!

> print "a() +b  => ", (a +b), "\n"

(wipes-sweat-from-brow) Oh boy. That was tough.


> No, its weird because in *both cases* there are no
> arguments given, but in one case there are no arguments
> passed, but in the other case, some unknown number of
> invisible arguments are passed.
>
> Consider a bunch of Ruby function calls:
>
> f()  # calls f with no arguments
> f# calls f with no arguments
> foo()# calls foo with no arguments
> foo  # calls foo with no arguments
> bar()# calls bar with no arguments
> bar  # calls bar with no arguments
> super()  # calls the superclass method with no arguments
> super# MAGIC HAPPENS! calls the superclass method with
>some unknown number of arguments!


The "unknown number of arguments" is equivalent to whatever
is defined by the method. In this form, Ruby's "arg-less-
super" is saving you the trouble of repeating code in a
confined space (aka: method body). Because hey, misspellings
can and do happen ya know. And if the intent of a method is
merely to pass along the arguments _verbatim_ -- which is a
common pattern utilized by OO programmers -- then why bother
with all the superfluous typing and risk the spelling
errors? Besides, Ruby does not abide by the Pythonic concept
of "explicit is better than implicit"; and there is nothing
wrong with that.

Futhermore, since when did you assume that Ruby's super was
a standard func/meth call? Because, it isn't. The only
overlap in consistency between them, is that, as is the case
with Ruby methods, you can call Ruby's super with or without
parenthesis. But the similarities stop there. 

`super` (more generally) is a fundamental feature of most OO
languages which provides a ubiquitous methodology for access
to the superclass object. Now, how exactly that feature is
implemented in each OO language depends greatly on the needs
and opinions of the devs/users of said language. So of
course Ruby's super will not behave _exactly_ like a Ruby
function, nor should it! Neither should it be assumed to
work exactly like Python's super, because now we're talking
about a completely different language with completely
different design philosophy. However, feel free to quote
from any official source which argues (hopefully
compellingly) that Ruby's super somehow fundamentally
violates the nature of what is expected from an OO language.

Finally, you forgot to show the third (explicit argument
passing form) of Ruby's super:

super(ag1, ar2, ..., argN)

> If you want to argue that's a useful feature, okay, I'll
> give you the benefit of the doubt. But useful or not, it's
> still weird and surprising. And deeply, fundamentally
> inconsistent.

I'm not here to protect Ruby. But if Ruby's super is as
"weird and surprising" and "deeply, fundamentally
inconsistent" as you claim it to be, well then, you've
failed to provide sufficient evidence here. 

We are entitled to our own opinions, Steven. But we are not
entitled to our own facts.
-- 
https://mail.python.org/mailman/listinfo/python-list

Ruby parens-free function calls [was Re: Accessing parent objects]

[Steven D'Aprano]

On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote:

>> - with no arguments, using the parenthesis-free syntax,
>>   Ruby automagically forwards the same arguments to the (single)
>>   parent;
> 
> Which is merely a natural result of Ruby's function/method call syntax.
> Not allowing a parenthesis-free super call would not only be
> inconsistent, it would be foolishly inconsistent.

I never said anything about not allowing it. But since you've gone on the 
defence about parens-free function calls, how is this for "consistency" 
in Ruby?

[steve@ando ruby]$ ruby ws-example.rb
a + b => 7
a+b   => 7
a+ b  => 7
a +b  => 3


Here's the source code:

# --- cut ---
def a(x=4)
x+2
end

b = 1
print "a + b => ", (a + b), "\n"
print "a+b   => ", (a+b), "\n"
print "a+ b  => ", (a+ b), "\n"
print "a +b  => ", (a +b), "\n"
# --- cut ---



>> So there's weird magic going on where `super` and `super()` both call
>> the method but with different arguments. Ewww.
> 
> It's only weird because you are judging through a Python lens. Ruby is
> not Python. And Python is not Ruby.

No, its weird because in *both cases* there are no arguments given, but 
in one case there are no arguments passed, but in the other case, some 
unknown number of invisible arguments are passed.

Consider a bunch of Ruby function calls:

f()  # calls f with no arguments
f# calls f with no arguments
foo()# calls foo with no arguments
foo  # calls foo with no arguments
bar()# calls bar with no arguments
bar  # calls bar with no arguments
super()  # calls the superclass method with no arguments
super# MAGIC HAPPENS! calls the superclass method with
   some unknown number of arguments!


If you want to argue that's a useful feature, okay, I'll give you the 
benefit of the doubt. But useful or not, it's still weird and surprising. 
And deeply, fundamentally inconsistent.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list