Try out Elixir, the pipeline operator |> is already there!
http://elixir-lang.org/docs/stable/elixir/Kernel.html#|>/2
According to José Valim -- creator of Elixir -- he borrowed that operator
from F#.
Boshan
···
2016-07-01 9:01 GMT-07:00 Samuel Williams <space.ship.traveller@gmail.com>:
One other idea I had was for assigning to variables.
expression ~> @variable
It’s the same as @variable = expression
Sometimes I’m thinking - compute this thing and then put it into this
variable.
e.g.
if blah
compute()
end ~> @result
avoids ugly indentation of
@result = if
compute
end
especially applicable to case statements and I feel easier to read.
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
More of a side note than anything, but Haskell has this pipe-ish operator as >>=, which it calls 'bind' (pedant defense: it's slightly different in haskell, because haskell, but non-category-theorists don't need to care).
Thanks to currying, Clojure actually has two 'thread' operators: ->, where x -> f -> g passes x as the first argument in f, and f(x, ...) the first argument of g. Meanwhile, x ->> f ->> g passes x as the last argument of f, and passes f(..., x) as the last argument of g.
···
On Jul 1, 2016, at 20:01, Boshan Sun <sunboshan@gmail.com> wrote:
Try out Elixir, the pipeline operator |> is already there!
http://elixir-lang.org/docs/stable/elixir/Kernel.html#|>/2
According to José Valim -- creator of Elixir -- he borrowed that operator from F#.
F# docs - get started, tutorials, reference. | Microsoft Learn
Boshan
2016-07-01 9:01 GMT-07:00 Samuel Williams <space.ship.traveller@gmail.com>:
One other idea I had was for assigning to variables.
expression ~> @variable
It’s the same as @variable = expression
Sometimes I’m thinking - compute this thing and then put it into this variable.
e.g.
if blah
compute()
end ~> @result
avoids ugly indentation of
@result = if
compute
end
especially applicable to case statements and I feel easier to read.
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Sometimes I’m thinking - compute this thing and then put it into this
variable.
According to the Pry wiki, it already does this: you can use '_' to refer to the value of the last expression, which solves the original problem of this thread, I think. Special Locals · pry/pry Wiki · GitHub
Which is not to say that ~> or |> would not have a long list of other uses...
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
would have plenty of uses.
I'm actually quite unsure why it's not present, and the fact that operators
in Ruby seems to be parsed in a very weird way, as you can't really create
your own operators. It's a very limiting design in Ruby.
···
On Mon, Jul 4, 2016 at 10:56 AM, Andy Jones <Andy.Jones@jameshall.co.uk> wrote:
> Sometimes I’m thinking - compute this thing and then put it into this
> variable.
According to the Pry wiki, it already does this: you can use '_' to refer
to the value of the last expression, which solves the original problem of
this thread, I think. Special Locals · pry/pry Wiki · GitHub
Which is not to say that ~> or |> would not have a long list of other
uses...
Click here to view Company Information and Confidentiality Notice.<
http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
I don't see how this is "weird". Many (most?) programming languages do
not allow for user defined operator overloading and very few allow for
user defined operator definition. And when looking at C++ I am not
sure this is such a bad idea altogether. It is certainly not "weird".
Kind regards
robert
···
On Tue, Jul 5, 2016 at 10:16 AM, Thiago Massa <thiagown@gmail.com> wrote:
I'm actually quite unsure why it's not present, and the fact that operators
in Ruby seems to be parsed in a very weird way, as you can't really create
your own operators. It's a very limiting design in Ruby.
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
You can do this pretty easily in Haskell. I expect this to be also easy to
be done in Ruby, at some point of time there was a gem that would let you
do it.
···
On Tue, Jul 5, 2016 at 12:56 PM, Robert Klemme <shortcutter@googlemail.com> wrote:
On Tue, Jul 5, 2016 at 10:16 AM, Thiago Massa <thiagown@gmail.com> wrote:
> I'm actually quite unsure why it's not present, and the fact that
operators
> in Ruby seems to be parsed in a very weird way, as you can't really
create
> your own operators. It's a very limiting design in Ruby.
I don't see how this is "weird". Many (most?) programming languages do
not allow for user defined operator overloading and very few allow for
user defined operator definition. And when looking at C++ I am not
sure this is such a bad idea altogether. It is certainly not "weird".
Kind regards
robert
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
You can do this pretty easily in Haskell.
Well, that does not disprove my point about lacking weirdness, does it?
I expect this to be also easy to
be done in Ruby, at some point of time there was a gem that would let you do
it.
However that worked. And then there's still the question whether it is
desirable to have such functionality in Ruby. Even if it is present in
other languages and fits there well that does not necessarily mean
that it should be in Ruby as well.
I am reluctant here, as with many features that sound cool initially.
Usually Matz finds a very good balance between conciseness and
verbosity of expressions in Ruby and would give him the benefit of the
doubt with this one, too. Also, I tend to prefer slightly more verbose
code (i.e. method names over operators) because it is easier to read
and maintain in my experience.
Kind regards
robert
···
On Tue, Jul 5, 2016 at 1:55 PM, Thiago Massa <thiagown@gmail.com> wrote:
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
Since operators don’t have any kind of lexical or dynamic scope by default, I think letting users add their own operators would create chaos.. Think about if two libraries defined the +% operator.. which one applies in which scope? if you limited scope some how (e.g. just make them pure functions on objects), it might be possible. However, you still need to define some order of evaluation (precedence) which is shared everywhere. Perhaps you can define precedence by some fixed function, e.g. the sum the ascii values or a per-interpreter/parser lookup table 
To be honest, it would probably make the parser slower without any real benefits.. and possibly a lot of downsides. Interesting idea though!
···
On 5/07/2016, at 11:55 PM, Thiago Massa <thiagown@gmail.com> wrote:
You can do this pretty easily in Haskell. I expect this to be also easy to be done in Ruby, at some point of time there was a gem that would let you do it.
On Tue, Jul 5, 2016 at 12:56 PM, Robert Klemme <shortcutter@googlemail.com <mailto:shortcutter@googlemail.com>> wrote:
On Tue, Jul 5, 2016 at 10:16 AM, Thiago Massa <thiagown@gmail.com <mailto:thiagown@gmail.com>> wrote:
> I'm actually quite unsure why it's not present, and the fact that operators
> in Ruby seems to be parsed in a very weird way, as you can't really create
> your own operators. It's a very limiting design in Ruby.
I don't see how this is "weird". Many (most?) programming languages do
not allow for user defined operator overloading and very few allow for
user defined operator definition. And when looking at C++ I am not
sure this is such a bad idea altogether. It is certainly not "weird".
Kind regards
robert
Not sure about Haskell, but can do that on Nemerle for sure. Although it
requires macros and a really weird syntax to specify operators precedence
and associativity. It works, but looks really ugly an error prone. I guess
is best to let languages designers to define their own language operators.
(And yes, I'd really like to have the 'pipe' operator).
~ Ale Miralles.
···
On 5 July 2016 at 13:35, Robert Klemme <shortcutter@googlemail.com> wrote:
On Tue, Jul 5, 2016 at 1:55 PM, Thiago Massa <thiagown@gmail.com> wrote:
> You can do this pretty easily in Haskell.
Well, that does not disprove my point about lacking weirdness, does it?
> I expect this to be also easy to
> be done in Ruby, at some point of time there was a gem that would let
you do
> it.
However that worked. And then there's still the question whether it is
desirable to have such functionality in Ruby. Even if it is present in
other languages and fits there well that does not necessarily mean
that it should be in Ruby as well.
I am reluctant here, as with many features that sound cool initially.
Usually Matz finds a very good balance between conciseness and
verbosity of expressions in Ruby and would give him the benefit of the
doubt with this one, too. Also, I tend to prefer slightly more verbose
code (i.e. method names over operators) because it is easier to read
and maintain in my experience.
Kind regards
robert
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
It is possible to define "new" operators in Ruby. Take a look at the
superators gem[1], afterwards you know you don't want that in core.
Valete,
Marvin
[1]: GitHub - neilconway/superators: Superators add new operators to Ruby
···
Am Tue, 5 Jul 2016 18:35:02 +0200 schrieb Robert Klemme <shortcutter@googlemail.com>:
> [Defining operators in Ruby]
However that worked. And then there's still the question whether it is
desirable to have such functionality in Ruby. Even if it is present in
other languages and fits there well that does not necessarily mean
that it should be in Ruby as well.
--
Blog: http://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F