Working towards finalization

[piegamesde]

• Defined absorption and absorbable terms
• Adapted the existing RFC text to make use of these definitions, resulting in simplications of the text in many cases.
• Updated with section to match the implementation
• Updated the function declaration section to match the implementation
  • Sometimes, the function body may get absorbed
  • This used to be a special case scoped to bindings only, so it got removed there
• Updated the operators section to match the implementation
  • Specify the format of non-chainable operators (somehow those got lost in the past)
• Reworked bindings section. It should now be clear and specific enough.
• Minor wording fixes

[infinisil]

Suggested change

	Operators which always return a truth value like `==` and `<` are non-chainable.
	[Operators](https://nixos.org/manual/nix/stable/language/operators.html#operators) with no associativity are non-chainable.

[infinisil]

Suggested change

	Function application is not treated as an "operator" in the sense of this section, see [function application](#function-application) instead.
	From the [list of operators](https://nixos.org/manual/nix/stable/language/operators.html#operators), this section focuses on binary operators.
	Function application is not treated as an "operator" in the sense of this section, see [function application](#function-application) instead.

[infinisil]

This feels like an obscure edge case that we shouldn't handle this specially. I expect it to be very rare to have multi-line expressions on both sides.

I think it would be fine to force the normal binary operator case instead, and limit this special case only to when one side fits on one line.

[piegamesde]

This special case dates from a time where the infrastructure for "if one side fits on a single line" did not exist, so having it also for both sides expanded was just a (sufficiently rare) false positive. I can try to narrow it down in the code

[infinisil]

Suggested change

	- Conversely, when a `with` cannot get absorbed, its but shouldn't be either.
	- Conversely, when a `with` cannot get absorbed, its body shouldn't be either.

[infinisil]

It was pretty clear from the last meeting that it's not just terms that should be treated as absorbable.

[infinisil]

And this contradicts the example: If { ... } is absorbable, then with bar; { ... } is also absorbable according to this sentence, which means it should be this:

  foo = with foo; with bar; [
    # multiline
    baz
  ];

[piegamesde]

It was pretty clear from the last meeting that it's not just terms that should be treated as absorbable.

Within the context of with statements, absorbing anything else does not make much sense.

Within the context of general expressions, the property "absorbable" does not give much value to define, as it is heavily context dependent. (See below)

And this contradicts the example

No it is not, since the body of with foo; is not an absorbable term. The relevant question at hand here is not "is with bar; absorbable?", but instead "will with bar; be absorbed?". Because the first question would only look at the expression itself and its content. But the second question actually correctly represents the fact that the actual behavior is also dependent on the outer context.

If you want, you can see it as "being absorbable is a necessary condition for absorbtion", however this usually is such a weak condition for anything other than absorbable terms that it does not help that much to formally define "absorbable expression".