Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make binary operators closurizable. #5879

Open
lrhn opened this issue Oct 15, 2012 · 6 comments

Comments

@lrhn
Copy link
Member

commented Oct 15, 2012

Make it possible to extract a bound operator, just as extracting a method works.
The only issue is what syntax to use. I suggest one of:

 Haskel-style: (2*) omitting an operand makes it a closure. We don't need to support (*2) as well, it's just not the Dart way. I think parsing will be acceptable - it'll just have to detect some cases that are now an error.
For index/indexSet operators, it will have to be, e.g., (map[]) and (map[]=) .

 Dot-style: 2.* simply putting a '.' before an operator name will treat it like a named access. It's not otherwise valid syntax. For index/indexSet it will be just map.[] and map.[]= .

I prefer the former, but that's just because the latter is ugly.
It's not a high priority on numbers, but it's very relevant on collections;
  var register = (map[]=);
  var lookup = (map[]);
  list.map(map[]); // convert map to function.

@DartBot

This comment has been minimized.

Copy link

commented Oct 15, 2012

This comment was originally written by @seaneagan


wanting to closurize getters and setters is probably equally as common. The second syntax above might work for setters:

a.b=

but not for getters (they're unary). I don't think using get and set is much better:

a get b
a set b

// or

a.get b
a.set b

Using :: has been suggested before, and it seems to work pretty well:

a::b // getter
a::b= // setter
2::+
map::[]
map::[]=

The only thing left would be unary -. Maybe:

(2::unary -)

@rakudrama

This comment has been minimized.

Copy link
Member

commented Oct 15, 2012

I like the Haskel style, but I'm worried that there may be some syntactic issues. '<' is also used for parameterized types.

One way of avoiding unintended consequences is to use 'operator' like the declaration syntax, e.g.

   var addTwo = 2.operator +;

   list.map(map.containsKey); // list of true, false.
   list.map(map.operator[]); // list of values from range of map.

I'm sure you find these even more ugly than map.[], but there is a consistency with the declaration which might help newcomers to the language guess what is happening.

I think all kinds of instance methods should be closurizable.
One reason is that it is a burden to write a correct type for hand-closurized code.
Either you have to guess the type, which may be (or become) inconsistent, or give up on types completely.

If I write (T1 b) => a+b
then I am imposing two type checks, one for T1 and another at the entry to operator+(T2 b).
It may have been my intention to write the same type but there is no mechanism to ensure they stay identical.

I think closurization could be nicely uniform. If we say that the name of getters and setters is 'get x' and 'set x' (instead of 'x' and 'x=') the suggestion of

   a.get x
   a.set x

is completely regular with operators and methods named by an identifier.

@lrhn

This comment has been minimized.

Copy link
Member Author

commented Oct 16, 2012

I actually like the .operator+ notation, but I disqualified it because I don't think it'll work. "operator" is not a keyword, and it's a valid property name. I.e., the syntax "c.operator+(2)" is already valid and means something else.

The "::" notation is viable, and works on getters as well (unlike either of my suggestions pout).

Unary minus is a problem. If it's reasonably implemented, it will be a constant function, but then, it might not be used reasonably.

@gbracha

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2012

Set owner to @gbracha.
Added this to the Later milestone.
Added Accepted label.

@kasperl

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2014

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

@kasperl

This comment has been minimized.

Copy link
Contributor

commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.