VERY simple question about "?"

Tom C. wrote:

OK, let’s assume we have the language problem solved (ha! - not likely
to happen). Nann-methods == “non-alphabetically-named methods”.

That’s not exactly the same though. You can (with a bit of work) define
arbitrary methods with non-alphanumeric names, but they are not
operators.

The things we’re talking about are called “operators” because they look,
syntactically, like operators in other languages, and are parsed as
such.

 foo + bar          # infix binary plus (method +)
 - foo              # prefix unary minus (method -@)

That is: “arg1 op arg2” instead of “arg1.methodname(arg2)”

The fundamental thing is that the infix/prefix notation shown above is
parsed successfully, but then translated into normal method calls. You
can then define or redefine these methods, just like any other methods.

class Foo
def -@
“minus #{self}”
end
end

f = Foo.new
p -f # operator notation (unary minus)
p f.-@ # same but using explicit method call

The core
problem still remains - what the blazes does that THING
do/mean/produce…???

It produces whatever it is defined to produce :slight_smile:

That is, class Foo may or may not implement the unary minus
operator/method (or any other operator). If it does, it is the
programmer’s choice as to what it does.

Equally, I could define a method Foo#xcikuhruh. It would be my choice
what it does :slight_smile:

You may have an implicit expectation of, say, what the “*” operator
does, i.e. multiplication. But it may not make sense in non-numeric
contexts. For example, the facets library defines a way to combine Proc
objects using *:

----------------------------------------------------------------- Proc#*
*(x)

 Operator for Proc#compose and Integer#times_collect/of.

   a = lambda { |x| x + 4 }
   b = lambda { |y| y / 2 }

   (a * b).call(4)  #=> 6
   (b * a).call(4)  #=> 4

   CREDIT: Dave

An operator precedence table shows all the operators known by Ruby, and
the ways they interact with each other in complex expressions. It
doesn’t make sense to include what they “mean”, because they will mean
different things when applied to different objects. And the joy is, you
can make them mean whatever you like when applied to your objects.

A neat trick I’ve seen is a pathname class which uses the ‘/’ operator
to compose paths: e.g.

path1 = MyPath.new(“home”)
path2 = path1 / “bar” / “baz” # results in /home/bar/baz

Saying that the ‘/’ operator means “division” doesn’t make sense here.

HTH,

Brian.

On 05.01.2009 03:38, Tom C. wrote:

that signals the beginning of a symbol, and a symbol that is actually
productive of something. Makes no sense to me at all, in fact. Maybe
I’m failing to grasp some transformative concept which changes how
things work in the Ruby world.

Seeing operators as methods makes some real sense, on the other hand.
“=” produces something out of what it’s given. It doesn’t just change
meaning, which is all that happens with quotes or “:”. That’s the
distinction I’m seeing, and it seems valid.
I am not sure what you mean by “change meaning”. Can you elaborate?
Meaning, in linguistics as I understand it,

Unfortunately we’re in the domain of programming languages which is
quite different from linguistics. Part of my difficulty understanding
you is probably caused by the fact that you seem to try to tackle
problems of computer languages with tools (terms and theories) from a
complete different domain. While both domains happen to share terms I
think it is not helpful to try to apply linguistics (i.e. the science of
natural languages) to computer languages. It may actually hinder
understanding.

Ditto for the use of “:” in symbols. The “”"
and the “:” are context indicators, but produce nothing. Not so for “+”
in “a+b” or, I think “?a”.

Actually I believe that “?a” does not belong in the same category as
“a+b” because, as Dave and I have pointed out already, “?a” is just
another way to write the integer 97 (“97”, “0141” and “0x61” are other
ways to write 97).

I’ll keep thinking about it.
Basically “?a” is just another textual representation for the integer
97 which happens to be the ASCII code of character “a”. It differs
from string delimiters because the expression “foo” is actually a
String constructor - it will create a new String object whenever it is
executed:

A “textural representation” that PRODUCES something?

I did not mention “produce” in the context of - where do you take that
from?

Doesn’t make sense
to me. Representations simply represent. They “stand for” something
else, and do no more.

Yes, all these character sequences ("?a", “97”, “0141” and “0x61”)
represent the Fixnum instance which in term is a technical
representation (i.e. data) of the (mathematical) number 97. If an
expression of a Ruby program is evaluate that contains any of these
tokens, the token (which is an expression as well, more precisely a
constant expression) evaluates to the said Fixnum instance.

Now, I can define method X, and then say that X “stands for” the method
specification. That’s true, from the compiler’s point of view, among
other things. But to say no more is misleading. “X” can be called, at
which point it ACTS. “Tom” - my name can also be called, but when one
does so IT doesn’t spring into action at all. I might, but IT cannot.

It does, as my example demonstrated. Opposed to “?a” “‘Tom’” is not a
constant expression but a String constructor. (See my example below
which I took the liberty to put together again.)

There is, I therefore assert, a fundamental difference here, and I think
you’re seeing that two different things have the same feature and

Actually I pointed out that “?a” and “‘Tom’” are not the same sort of
thing. (On a certain level they are of course: both are valid syntax
constructs (tokens) of the Ruby language. Actually, both are even
expressions which happen do have different semantics - constant vs. non
constant).

concluding from that that they are the same sort of thing.

Again, I do not know where you take that from. This is certainly
nothing I have intended to convey.

That argument
is obviously flawed. "It’s incomplete, as my “Tom” demonstrations shows.
You say “Basically “?a” is just another textual representation for…” -
I’d agree, except for that “just”. That single word makes the statement
incorrect, to my mind, and also reveals the problem I’m addressing.

Not at all. There are many ways to write down 97 in a Ruby program (as
I have shown above). In that sense “?a” is just another way to write it
down (assuming “97” is considered the most commonly used way).

irb(main):003:0> 3.times { x = “foo”; puts x, x.object_id }
foo
1073491940
foo
1073492040
foo
1073491880
=> 3
irb(main):004:0>

Cheers

robert

On 05.01.2009 23:21, Brian C. wrote:

Robert K. wrote:

Brian, you are contradicting yourself: first you deny the presence of
operators in Ruby and then you talk about them nevertheless. :slight_smile:

Fact is, there are operators in Ruby - and they do have a precedence.
(I am not sure why you put an “only” into the sentence above -
operator precedence is what a precedence table is about.)

Operators in Ruby are nothing more than syntactic sugar for method
calls.

Well, in a way that’s what they are in every procedural language - they
are just a special notation for a method / function invocation, aren’t
they? Even if technically a compiler does not generate a subroutine
call, they represent the code inserted there which is always the same
for the same types of arguments. What makes operators special in some
procedural languages is that they are overloaded (plus for int, plus for
float etc.) while functions cannot be overloaded in those languages.
And, of course, they need a defined precedence because of the different
syntax (i.e. their arguments are not grouped via brackets as for
function / method calls).

The “only” was because the OP wanted the table to include the “meaning”
of each operator. I am agreeing with you that an operator precedence
table should show only operator precedence :slight_smile:

:slight_smile: Ah, I see. In case of Ruby the meaning cannot be included anyway
because operators are overloaded and can be overloaded by the user - so
there is no fixed meaning.

Kind regards

robert

Robert K. wrote:

Operators in Ruby are nothing more than syntactic sugar for method
calls.

Well, in a way that’s what they are in every procedural language - they
are just a special notation for a method / function invocation, aren’t
they?

I don’t think so. Well, not in C anyway. The operation “a + b” is
defined to be an operation on a and b (e.g. integer addition or float
addition). It is not defined as a function call, and it cannot be
changed by the user.

The same applies to Perl I think.

In Ruby, + is not defined in terms of its operation (i.e. what it does
with the arguments), but just that it dispatches to a method on the
left-hand argument. They really are syntactic sugar, since they parse to
exactly the same as the explicit method call syntax:

$ cat add1.rb
1 + 2 * 3
$ cat add2.rb
1.+(2.(3))
$ parse_tree_show add1.rb
s(:call,
s(:lit, 1),
:+,
s(:array, s(:call, s(:lit, 2), :
, s(:array, s(:lit, 3)))))
$ parse_tree_show add2.rb
s(:call,
s(:lit, 1),
:+,
s(:array, s(:call, s(:lit, 2), :*, s(:array, s(:lit, 3)))))

Now, in principle a C compiler could be written such that a+b is
rewritten at the parsing stage to cc_int_add(a,b) or somesuch. But this
wouldn’t be a function like a user-written one. For a start, it would
have to generate machine code or some intermediate VM code directly,
since there is no primitive ‘+’ operator to use. Secondly, it would need
to be able to handle arguments in different combinations of registers,
so that an expression like cc_int_add(a, cc_int_mul(b,c)) doesn’t spill
registers everywhere.

So cc_int_add() might look like a function, but actually it would be a
special node type which generates addition code. In that case, the parse
tree may as well remember that it’s a “+” operator with two arguments,
since converting it to something which looks like a function call (but
isn’t) doesn’t help at all.

Regards,

Brian.

Robert K. wrote:

Brian, you are contradicting yourself: first you deny the presence of
operators in Ruby and then you talk about them nevertheless. :slight_smile:

Fact is, there are operators in Ruby - and they do have a precedence.
(I am not sure why you put an “only” into the sentence above -
operator precedence is what a precedence table is about.)

Operators in Ruby are nothing more than syntactic sugar for method
calls.

The “only” was because the OP wanted the table to include the “meaning”
of each operator. I am agreeing with you that an operator precedence
table should show only operator precedence :slight_smile: