[Feature] Pipe Operator for Function Calls

[clsource]

As seen here https://prog21.dadgum.com/32.html

The suffix "K" to indicate kilobytes in numeric literals. For example, you can say "16K" instead of "16384". How many times have you seen C code like this:

char Buffer[512 * 1024];

The "* 1024" is so common, and so clunky in comparison with:

char Buffer[512K];

I personally think this feature is a small improvement to the numeric literals in Wren :)

[mhermier]

While I see great values in having units in a language, I would say no in the proposed syntax as this. The cited example is fine tuned for a very specific and limited usage (assembly does have to deal a lot with allocations sizes).

[clsource]

Maybe can be similar to hex.

• 0k512

Otherwise if more modular is needed I think adding more methods to the Num class would do for these constants.

[mhermier]

I was thinking to something more general like:

import "my_unit" for Ki

512 <operator_here> Ki // Would invoke: Ki.call(512)

[clsource]

Maybe

// A class named constants inside Num. 
Num.constants.kilobyte // With static methods with common values such as 1024
Num.constants.kilobyte(512) // A static method with one parameter that will multiply the value by the constant

[mhermier]

Your solution is the same as doing:

import "constants" for Constant

Constants.kilobyte // With static methods with common values such as 1024
Constants.kilobyte(512) // A static method with one parameter that will multiply the value by the constant

With the advantage that you are in control.

My solution also put you in control, but with a syntax more near to what you originally planned, and can be reused for other stuff:

import "to_list" for ToList

(0..42) <operator_here> ToList

[clsource]

that reminds me more or less to pipes.

(0..42) |> ToList

In my POC here #944 I overloaded the operator in classes.
Maybe here would be an operator only for using call in functions.?

[mhermier]

It would make things more functional style, but it is the more extensible sugar syntax I can think of. In extra, if that as importance or extra usage, it would inverse order of evaluation before execution...

[clsource]

If a pipe operator is added |> just as a syntax sugar to function.call() I totally support the idea.

var Kilobyte = Fn.new{|n| n * 1024}
var Print = Fn.new{|s| System.print(s)}

Print.call(Kilobyte.call(512))

Becomes

var Kilobyte = Fn.new{|n| n * 1024}
var Print = Fn.new{|s| System.print(s)}

512
|> Kilobyte
|> Print

[mhermier]

At usage, it would definitively be equivalent. The operator has to be accepted or changed, but it gives an extra reason to have that language construction.

[clsource]

I will link to the Pipe proposal for JS https://github.com/tc39/proposal-pipeline-operator

The pipe operator attempts to marry the convenience and ease of method chaining with the wide applicability of expression nesting.

The general structure of all the pipe operators is value |> e1 |> e2 |> e3, where e1, e2, e3 are all expressions that take consecutive values as their parameters. The |> operator then does some degree of magic to “pipe” value from the lefthand side into the righthand side.

var kilobyte = Fn.new{|n| n * 1024}
var division = Fn.new{|x, y| x / y }
var print = Fn.new{|s| System.print(s)}

# print.call(division.call(kilobyte.call(512), 2))
512
|> kilobyte 
|> division(2) 
|> print

[PureFox48]

I don't think it would be a good idea to have something like this built into the language (or even the standard library) partly because of the confusion over whether the prefix kilo should mean 1000 or 1024 (and similarly for mega, giga and friends) - see Wikipedia - but also because what one would probably do now is very simple and flexible:

var K = 1024
System.print(512 * K)

On the general question of working with units, Wren is an OO language and, if - for some particular quantity - there's a significant difference between the units and the actual numbers, we should be thinking in terms of creating a class to represent that quantity.

An example of this is financial applications where, because of difficulties in working with floating point, most folks prefer instead to work in cents (or whatever the sub-unit is called) even though it's tedious and error prone to convert from and to the actual monetary amounts.

Recognizing this, I recently created a Money module in Wren which does all this in the background for me. It was a fair bit of work but I was able to build a lot of flexibility into it such as different thousand separators, decimal points, currency symbols etc.

With regard to whether Wren should have pipes, I think that's a more general question regarding how best to chain function calls. Although I'm not keen on having to use the call method all the time, I'm worried that if we start talking about pipes and other functional stuff such as currying and monads, it will make people feel that Wren is turning into a kind of mini-Haskell and run for the hills!

[clsource]

I don't think it would be a good idea to have something like this built into the language (or even the standard library) partly because of the confusion over whether the prefix kilo should mean 1000 or 1024 (and similarly for mega, giga and friends) - see Wikipedia - but also because what one would probably do now is very simple and flexible:

var K = 1024
System.print(512 * K)

On the general question of working with units, Wren is an OO language and, if - for some particular quantity - there's a significant difference between the units and the actual numbers, we should be thinking in terms of creating a class to represent that quantity.

An example of this is financial applications where, because of difficulties in working with floating point, most folks prefer instead to work in cents (or whatever the sub-unit is called) even though it's tedious and error prone to convert from and to the actual monetary amounts.

Recognizing this, I recently created a Money module in Wren which does all this in the background for me. It was a fair bit of work but I was able to build a lot of flexibility into it such as different thousand separators, decimal points, currency symbols etc.

With regard to whether Wren should have pipes, I think that's a more general question regarding how best to chain function calls. Although I'm not keen on having to use the call method all the time, I'm worried that if we start talking about pipes and other functional stuff such as currying and monads, it will make people feel that Wren is turning into a kind of mini-Haskell and run for the hills!

I agree. Having such values inside Wren core may not be a wise idea, if is best to delegate that to an external lib.

For the pipe I think that is just syntax sugar to calling functions. Other functional language constructs would be left to maybe external libs if any, since Wren is OOP after all.

[mhermier]

Looking at the JS paper, the placeholder operator seems overkill (introduce too much complexity in the compiler). Instead, I propose that we can guarantee that we can put at minimum a function as second argument:

512 |> Fn.new {|n| n * 1024} |> Fn.new {|s| System.print(s)} // expect: 524288

So the priority level of the operator should be thought with care.

That said, I consider |> to be a placeholder, to ease the discussion. But since the pattern emerged at least twice, it shows there is a real need for such language construction/syntax sugar.

[PureFox48]

512 |> Fn.new {|n| n * 1024} |> Fn.new {|s| System.print(s)} // expect: 524288

So, vis-à-vis #1128, you can see some value in System.print returning its argument after all :)