outplace and chaining

[Araq]

There have been a couple of competing designs in order to add outplace and chaining to Nim. Here is a new one that tries to be convenient to use, simple to implement and without gotchas. Names have been chosen instead of operators for two reasons:

• How they interact with the "dot notation" is obvious.
• Many people prefer words over Perl-like custom operators.

outplace / dup

The current outplace should be renamed to dup focussing on the "works on a duplicate/copy" aspect. dup looks like the following:

macro dup*[T](x: T; calls: untyped): T = discard "implementation not part of the spec"

# examples
var a = @[1, 2, 3, 4, 5, 6, 7, 8, 9]
doAssert a.dup(sort()) == sorted(a)

var aCopy = a
aCopy.insert(10)

doAssert a.dup(insert(10).sort()) == sorted(aCopy)
doAssert a.dup(insert(_, 10).sort()) == sorted(aCopy)

As can be seen in the examples, the 2nd argument to dup is a list of "dot call expressions". The call expression can contain _, if so the _ is replaced by the copy that dup introduces. Otherwise the copy is passed as the first argument to the call.

chain / operateOn / on / use

The operateOn macro should be renamed to use. It looks like this:

macro use*[T](x: T; calls: untyped): void = discard "implementation not part of the spec"

var w: Window
w.use(setColor(green).setPosition(10, 20).setVisible(true))

The same rules apply as for dup, the 2nd argument is a list of dot call expressions with optional _ markers. Notice that dup returns an expression of type T and that use returns an expression of type void.

Block syntax

Both operations also work with a "block syntax", the 2nd argument then is a block of statements that is transformed.

use w:
  setColor(green)
  setPosition(1, 2)
  setVisible(true)

@[1, 2, 3, 4, 5].dup:
  insert 10
  sort()
  filterByIt it != 4

The block syntax does not support control flow, if etc are not allowed, only a flat list of call expressions and for every call the first argument is injected. The macros are deliberately not smart.

Alternatives to consider

• Use with instead of use since it's now very close to Pascal's with statement (only better, because no guesswork is involved).
• Use , for the non-block chaining syntax as it avoids ambiguities and feels more natural:

doAssert a.dup(insert(10), sort()) == sorted(aCopy)

This has the benefit that then simple calls can be written without the ():

doAssert a.dup(algorithm.sort) == sorted(aCopy)

[andreaferretti]

I especially like the block syntax!

[Varriount]

Hm, interesting. While I'm still mulling the RFC over, one thing that does occur to me is that the block form of on somewhat replicates the implicit this/self argument mechanism that other languages use as part of their object-oriented programming features.

[dom96]

As someone that disliked outplace a lot initially (especially with the operator that was initially being proposed), let me say that I love the dup name.

Regarding on though, I think chain would be much better: on is far too short and ambiguous, chain captures the purpose very well and is much easier to search for.

[exelotl]

Question, does on also allow statements that don't operate on the target?
e.g.

on w:
  setPosition(1, 2)
  echo "hello"
  if uiHidden:
    return
  setVisible(true)

This would be preferable to me, as a worthy replacement for the this pragma. But either way I like these additions a lot!

[edit] Hmm even this example is troublesome because it would do w.echo("hello")

[metagn]

Another name for on could be doto or doTo, as in clojure

[Araq]

Question, does on also allow statements that don't operate on the target?

No. In fact, the block has to consist of only calls and control flow is not allowed.

Another name for on could be doto or doTo, as in clojure

Thinking about it more, I think I like use better than on.

[bluenote10]

I'm not so sure about macro based solutions. To me, one of the most important aspects of method chaining is to get auto-completion. Especially when working with unknown interfaces of third-party libraries it is a huge productivity boost for me.

I guess with the proposed macros we would never reach the great feeling of typing . and seeing the entire API when writing chaining expressions -- basically the compiler only sees some untyped expressions and cannot suggest completions. In practice, I already see myself temporarily copy pasting the expression on the left hand side into the line above where I can use . to explore the API. Doing this repeatedly on every method ruins the usual flow of chaining.

What about keeping it simple? Couldn't we simply do a.dup().insert(1).sort() so that we are all the time operating on something the compiler understands?

[Araq]

Couldn't we simply do a.dup().insert(1).sort() so that we are all the time operating on something the compiler understands?

insert returns void, so no, this wouldn't work without a language extension or duplicated APIs.

I guess with the proposed macros we would never reach the great feeling of typing . and seeing the entire API when writing chaining expressions -- basically the compiler only sees some untyped expressions and cannot suggest completions.

A very good point but once these macros become standard, nimsuggest can cheat and understand them and offer good auto-completion.

[bluenote10]

Maybe that can be solved by introducing the convention that inplace modifying methods return discardable Self?

[Araq]

And then dup still has the tool support problem? Please keep in mind that dup is the really useful feature here as it allows us to remove sorted et al from the stdlib.

[akavel]

<bikeshedding>

Would like to add an alternative name tweak (or maybe edit? ed?) for consideration for the chaining macro; personally I find the use one confusing. Sample block syntax:

tweak w:
    setColor(green)
    setVisible(true)

---

As a side note, as far as syntax, I'm also somewhat pondering whether I'd like comma-separated for the inline variant?

w.tweak(setColor(green), setVisible(true))

The benefit in my eyes being that it seems to me to look a bit more similar to the block syntax.
</bikeshedding>

You're obviously free to completely disregard this comment, given it's basically pure bikeshedding!

[Araq]

Actually I'm thinking about w.use(setColor(green), setVisible(true)) (commas instead of dots) because it avoids some ambiguities. tweak is a bit too general for my taste.

[akavel]

(to clarify, the confusion I'm having with use is that it seems to me to imply a different kind of relationship; as in <who> use <noun>, not <who> use <verb>; one more idea that came to me now would be maybe apply? also I thought about sub as shorthand for subject to, but this is very stupid also because confusing with subroutine, but as part of brainstorm, maybe it inspires someone with something better)

(hmmm upon? teeheehee, I love brainstorming names :) flexing the lateral thinking muscles :) )