Feature #16799: Add more functional features,make ruby more friendly.

• Status: Rejected
• Assignee: -
• Target version: -

[jackmaple (maple jack)]

Classes are currently first-class citizens in Ruby, but functions are not.
This leads to a situation where the function calls are not uniform, for example:

def boo(x)
  return x
end
boo2 = -> x { x }
a = boo 10
b = boo2.call(10)
or
b = boo2.(10)
or
b = boo2[10]

This is very confusing to people from other languages (JavaScript, Python, etc.), or people who are just starting to learn ruby.
If the method calling format can be unified, and the method is also a first-class citizen, then a higher-order function can be realized, and the method name is just a variable,so maybe more things can be done,and it might be better if the lambda is changed to the following form,for example(suppose):

method1 = (f,n) -> f(n)
or
method1 = (f,n) -> {
    return f(n)
}
or
method1 = (f,n) -> do
    return f(n)
end
#call method
result = method1(x -> x * 2,10)  #result = 20

The same can also be achieved as follows:

def method1(f,n)
    return f(n)
end

def double(x)
    return x * 2
end
# &double is reference double method.
result = method1(&double,10)     #result = 20

We can also use closures in methods(suppose):

def method1()
    param = []
    def method2(x)
        param.push(x)
        return param
    end
    return method2
end
f = method1
f(10)

Or you can implement decorators:

def decorator(f)
    def child_method(*param)
        puts(param)
        return f(*param)
    end
    return child_method
end

def method1(x)
    return x
end
#Here will cover the implementation of method1,include method1 method internal recursive reference.
#Because the method name is just a variable.
method1 = decorator(&method1)
method1(10)

Although the syntax change is not good, but it makes ruby easier to use.
These are just some of my thoughts, thanks.

[jackmaple (maple jack)]

• Description updated (diff)

[jackmaple (maple jack)]

• Description updated (diff)

[jackmaple (maple jack)]

• Description updated (diff)

[jackmaple (maple jack)]

• Description updated (diff)

[jackmaple (maple jack)]

• Description updated (diff)

[shevegen (Robert A. Heiler)]

method1 = (f,n) -> do
  return f(n)
end

I think a syntax change such as this may be very problematic.

People would not typically expect this, and even if we, say, assume that this
may be a better syntax for newcomers, it would also be a change for people
who have come adjusted to the syntax without the ->.

I understand your comment about confusion to newcomers, but ruby also embraces
a "more than one way" to think about problems, aka flexibility, so I am not
sure that this can be used as primary means to explain why the above syntax
should be added as such.

It also depends a LOT on the individual style. For example zverok uses a
very different style from, say, my style (I rarely use procs and lambdas
or "functional" composition, for instance).

I am not suggesting that the whole idea may not be good per se, but I am very
sceptical of the cost/benefit situation. I am just not sure if the change is
worth it.

[jackmaple (maple jack)]

Yes, changing the syntax is currently not a good choice, but I think it is necessary to modify the method call syntax to maintain the same form, and the method name is just a variable name (in order to support more flexible functional programming), all method types should be consistent (Method), these are just some of my points. Thank you.

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

I'd love to enhance the language to be nice to functional programming but at the same time, we have to be nice to existing programs by keeping compatibility. Proposed new syntaxes are incompatible changes so that we cannot accept them.

• Anonymous function definition syntax is too trivial. Yes, it's different from most languages, but you can be used to it.
• The single namespace (method and variable), so-called lisp-1 semantics is too far away from Ruby's lisp-2 semantics. Changing this is too big incompatibility and unacceptable. Languages like Scala uses different syntax to accomplish functional programming without having lisp-1 semantics (func _ instead of func in Scala).

Matz.

[nobu (Nobuyoshi Nakada)]

In addition to matz's note, we had tried the single namespace once some years ago.
Finally we found that the incompatibility was much bigger than expected before, and abandoned.