Lucian Wischik: Inside VB.NET Async and Customizing Awaitable Types

VB iterators, Async -  MANY MANY thanks.

Method instances - WONDERFUL.  That so much more matches how we think about it anyway without the redundant pain.

DAMN YOU Wischik!!! (wraith of khan stylee)

By implementing VB Iterators, what will us VB.nutters VB.netters berate Microsoft 

with now.

mmm.

Yes Unsafe? No

I think Extension Custom Operators would be interesting.

These custom operator have no precedence, so you need to use (  )'s accomplish it.

Public  Operators   Ops_Double

' A Simple one Roots.'

<Extension()>
Public Operator /¯ (ByVal x As Double, ByVal y As Double) As Double


' Inside here the usage of /¯  is an Error '
' Error is Infinite Recursion '


If x =0 Then Throw New AttemptToDivideByZero()
Return  y^(1/x)
End Operator

End Operators

Notice the Public Operators code block, it just like a Sub but it isn't automatic imported into the namespace, you have do this explicitly. To enable the coder to override the built-in operator (ie a new language ones.), they would have to specify a "in this context" keywords. 

Using Operator From { Ops_Double}

which can be nested with one another.

Using Operator From {namespace}

Dim r as Double = 3 /¯ 27

' r = 3  ( The cube root )'

End Using 

Add 2 new keywords Operator & Operators. 

Mmm Async Operators? 

I know it takes vb.net into a rather strange world where the some of grammar is user-defined, but I strongly believe it would be useful and beneficial. 

May be a concept proto-type language VB#  (VB's   c-omega).

I digress, congratulations and thank-you. 

-Adam

P.S. I thought it was Godel?

This is a stellar going deep! Lucian is a great presenter.

It would be nice to have the same symmetry of design between asyncs and iterators in C# as exists in VB although performance is already an issue for iterators for some scenarios where it doesn't scale.

Also, I wonder how this new design will interact with proposals for making iterators more scalable; e.g. see this great post by Wesner Moise on the topic.

So design and interaction with compiler optimization is an interesting topic because when a feature is composable the next logical question must be: is it scalable. Can I take it to the extreme.

Performance woes aside, asyncs and iterators are superb features.

I agree we need more Lucian. 

Possible one of the most useful benefits of having Iterators.

  <Runtime.CompilerServices.Extension()>
  Public Iterator Function AsEnumerable(ByVal f As IEnumerator) As IEnumerable
    f.Reset()
    While f.MoveNext
      Yield f.Current
    End While
    f.Reset()
  End Function

@AdamSpeight2008:
Kinda dangerous. Reset is might throw on some implementations.

I really liked the last question, because I have run into small problems with it.

It was actually Silverlight C# code and it went something like this...

I had I SaveFileDialog and a method, that used a StreamWriter passed to an async method

using (var writer = StreamWriter(dialog.OpenFile()))
{
  WriteResults(writer, dialog.FilterIndex)
}

async void WriteResults(StreamWriter writer, int whatToExport)
{
  if (whatToExport is something that isn't computed)
  {
     await TaskEx.Run(() => Compute(...))
  }

  // write the result here
  // Raises an exception, that the stream is closed
}

This was definitely some behavior I was not expecting. But of course when I think about it, it makes perfect sense that it happened. 

Now, originally the method WriteResults only wrote the results and later came the need to compute additional values before the actual export. So I kinda artificially extended the WriteResults method using Async because the computation could take several seconds and later I wanted to add a progress bar and cool stuff like this. I admit it was a bad "design" decision to do it this way (like I should open the file after the results are available). Nevertheless, it also means that there are some hidden pitfalls when using Async and one should be careful where it's being used.

So my suggestion is this: would it be possible to add a compiler warning if constructs like

using (var x = ...)
{
  SomeAsyncMethod(x);
}

are used?

Lucian was excellent!!! I didn't get lost in translation LOL!!! He is so right about that everyone has the misconception of Async = background process
Great job Lucian !!
 
 

Lucian kicks * ! <a href=”http://www.etigararunway.ro">tigara electronica</a>