Reduce the need for backtracking while typing

AnthonyDGreen commented 7 years ago

There are situations in VB today where you're dotting through an API and you realize you run into a wall that requires backtracking. Examples include needing to perform a cast or needing to await a Task. It breaks the flow of typing/thinking. It can also create a situation where a lot of ceremony starts accruing on the left like multiple CType or Await keywords very far from what they relate to.

In English, sentences are most often structured in Subject-Verb-Object form. This usually fits in well with object-oriented syntax where the subject is the receiver, the verb is the method, and the arguments are the objects: subject.Verb(object). But, there are also times where this order is warped by the way an API is designed (sometimes necessarily).

' For performance reasons this isn't an instance methods.
Dim upper As Char = Char.ToUpper(ch)

In some cases this can be mitigated through the use of extension methods. Extension methods take the less natural Verb(subject, object) form and arrange it ... fluently.

' An extension method makes this read subject-verb.
Dim upper As Char = ch.ToUpper()

A number of proposals have showed up lately that all seem to share a theme of their proponents trying to reduce or eliminate backtracking, either as their primary benefit or a significant secondary one such as #138, #116, and #59.

bandleader commented 6 years ago

@AnthonyDGreen I see the common thread that you're pointing out in these proposals. I wonder if we could extend the -> pipe-forward operator of #165 (which I support enthusiastically) to handle all the cases you are speaking of, with a single, easily-understandable syntax?

-> Await could eliminate backtracking for async tasks, solving #116
-> DirectCast(TypeName) could do this for casting -- #59's "secondary benefit" as you called it
-> SomeFunction for function calls (the original goal of the operator)
I'm sure the community can come up with more things. I'm all for making an existing language element more powerful, reducing the need to add more elements.

This way, it would be a single operator to learn -- all the above constructs would then be obvious to readers of code, and programmers could uncover all the possibilities in a single article.

Caveat: `->` Precedence (and symbol)

The only thing is that we need to clear up the "Precedence and Associativity" issues described there in #165.

To be able to support what I am describing, it should be a 'short' operator, i.e. higher precedence than . -- as you indeed concluded in #165.
However, as currently expressed with whitespace before and after the ->, the expression doesn't intuitively read like it will be processed that way (as opposed to . which has no whitespace). We could either do -> without whitespace, or (preferably in my opinion) choose another symbol that lends itself to this more naturally.

Should I post about that in #165 @AnthonyDGreen?

Thanks

I want to thank you again for your involvement in making VB the beautiful, expressive, readable and productive language it is.

Edit: Didn't realize Anthony had left -- now addressed to @KathleenDollard. Welcome!

bandleader commented 6 years ago

As to which symbol to use for this, see above where I descibed the issues that an arrow symbol causes for operator precendence.

Now I am thinking that .. looks great for this, as it's something like . member access, but with special behaviour. SomeMethodAsync()..Await or someInt..DirectCast(newType) looks beautifully intuitive, and could be used for pipeThis..MyFunction() and it reads very well.

The operator becomes a sort of "dot with superpowers" -- because if you think about it, . is already a pipe operator, in the sense that it pipes your expression into one of its member methods -- but with our .. (or similar) operator, we extend that to let you call any function (or await or typecast) -- in left-to-right execution order, which is the whole point of piping.

Small downside: Piping into a member of an arbitrary class would then need parens to be clear: someChar..(Char.IsLetter) Not a big deal.

Conflict with method cascading: In Dart, .. is used for method cascading (which I suggested for inclusion here: #245), and I don't think we should use it for both, as method cascading is very different in that it discards the result (it returns the left-hand result). Maybe we could use .> for piping instead? Shows that it's a pipe... Or perhaps method cascading should instead use something else? I think still some variation of the dot (as it's still member access) ... maybe simply obj.%SomeSub(), or maybe even obj.<SomeSub() to show that it's the left-hand result that is retained?

AnthonyDGreen commented 6 years ago

@bandleader I think the pipe-forward operator could solve a bunch of these. You should leave your feedback about it there.

bandleader commented 6 years ago

@AnthonyDGreen I'll be glad to, but I do have other occupations, so I have to wait for @KathleenDollard 's response (#248) as to the future of VB, and whether the feedback will actually be seen and used by the LDM to build the feature. Or maybe you know too :)

dotnet / vblang