Idea: replacing `+=` etc. with the canonical "self-call-assign"

[ozra]

Since one can do x.=method a, b, c, perhaps that syntax should be used for operators too. This opens up a couple of symbol-combos that could find better uses, at the least it's one step more consistent.

a = 5
-- instead of:
a *= 2

-- do:
a.= * 2

-- like:
my-list = [1, 9, 4, 7]
my-list.=sort

I have no strong feelings about the idea, it's a thought that might develop.

[Sod-Almighty]

No, += et al are a de facto standard these days, and would only cause confusion if removed.

On a side note, I don't recall seeing the .= notation before. I assume my-list.=sort translates to my-list = my-list.sort? I've not encountered this notation before. Wouldn't it be more useful to have a shorthand notation for performing a call on the members of the list? For example:

my-list.* + 2
-- equivalent to:
my-list.each ~> _1 + 2

my-list.*= + 2
-- equivalent to:
my-list = my-list.map ~> _1 + 2

[ozra]

The foo.=method acts as you described, I use it all the time - it's super-useful.

The idfr.*=+x just looks waaaay too gnarly!

It would be much cleaner to overload * as a one-expression wrapper, calling map (was it from a lang called Groovy you showed that style from?).

This would use no new syntax for making map an operator — but... (big but) — it would require an advanced reworking of the language that I've been thinking about and wanting for a long time (and, again, you know my unfortunate time-constrained situation atm :-( ) — that is: unify lambda and fragment ("eliminate" fragment!_).

To clarify: all the current functionality would be practically available — just in a much cleaner way, a more distilled, unified concept.

Here's a run-down:

• Lambdas args should be able to be type-inferred too (not requiring typing of the args, as currently is)
• Since "fragments" are already part of the argument list in Onyx, rather than something "floating after" like in Ruby/Crystal, the next step to betterment and cleanliness isn't far:
• Instead of the "yield" keyword, one would simply call the lambda "passed" via the args
• One can take as many lambdas as one fancy, instead of just the one fragment (think that was also a feature request?)
• Also, it would fulfil yet another feature-request — type restricting fragment args — since the lambda already can.
• Further, one can have several overloads matching different lambda signatures, while the fragment-concept only takes it or not.
• If the body contains "naked" break or next (not in while, switch, etc. control structures) or an outer return / return outer / some similar wording (new keyword), anywhere in the lambda body, then the compiler knows that the lambda has esoteric control-behaviour: working in the scope it's defined in, rather than in its' own scope. This is the cool part from fragments, the only thing needed to keep. The compiler will then inline the called function and then also the lambda body inlined at the positions where yield formerly was used for the esoteric "block"-concept (the inlining should be preferred in absence of the control statements too though... will think of some formal method of deduction, always inline could be used to begin with).
• Since a lambda is a value, and has type, the * operator can be overloaded in, say, trait Iterable: *(fn Fn) -> map(fn)
• If the result of the map isn't used, it can be optimized away, resulting, in effect, the same thing as an each, but using the exact same overloaded operator.
• back to the existing iteration funcs: for instance each-with-index (makes me puke!) could be replaced with each(fn Fn‹*,*,*›) -> ... (restricting to a lambda with two args, while the "regular" each restricts to a lambda-type with one arg.

So, instead of the proposed weird-looking (in my eyes) syntax; here's the counter example, assuming:

• the "braces-are-blocks-of-code" syntax (#97)
• that a brace-block (block as in C, not as in Ruby) in an expression is interpreted as being an auto-parametrized lambda
• we get:

  
  -- in stdlib:
  trait Iterable
  *(fn Fn) -> map fn

-- in user code: my-list * {it + 2} -- each, because unused result optimized away

my-list.= {it + 2} -- map, assign to self (syntax as per idea of this issue) -- or: my-list = {it + 2} -- map, assign to self (traditional syntax)

-- also, ofc., to anchor it to currently implemented syntax: my-list = (x) -> x + 2 new-list = my-list (x) -> x + 2

Oh, in case `it` is "new to the public" (I've probably forgotten to publish half of the features in Onyx... :-/ ) , if used in a lambda without defined params (auto parametrized) it's the same as `_1` / `%1` (the first arg).

[Sod-Almighty]

These are all great ideas!

outer break might be best. Maybe even something like outer 3 break 2, to break 2 from the outer of the outer scope. Currently we have to use throw/catch in Ruby for that kind of control.

I'm concerned about this plan to unify pods and lambdas/procs. As I recall, Crystal compiles non-block lambdas in-place, meaning that the value of this can't be altered at runtime (as is often necessary for Ruby blocks, e.g. via instance_exec). How will you overcome this?

[ozra]

Well, this was a "fun" idea for further canonicalizing certain things, but the simple comment "don't fuck with such de-facto accepted notation for no reason" is sensible enough that I'll close this.

If there was something discussed here that is of value for another issue, that I've missed moving: ping me or simply copy/paste/rewrite into a comment on an appropriate issue.