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

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

The Discussion

  • User profile image

    VB iterators, Async -  MANY MANY thanks.

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

  • User profile image

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

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

    with now.


    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.'
    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 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. 


    P.S. I thought it was Godel?

  • User profile image

    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.

  • User profile image

    , exoteric wrote

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

    Agreed. I'd like to get Lucian on C9 again. He's super bright and articuate!


  • User profile image

    I agree we need more Lucian. 

    Possible one of the most useful benefits of having Iterators.

      Public Iterator Function AsEnumerable(ByVal f As IEnumerator) As IEnumerable
        While f.MoveNext
          Yield f.Current
        End While
      End Function

  • User profile image

    Kinda dangerous. Reset is might throw on some implementations.

  • User profile image

    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 = ...)

    are used?

  • User profile image
    Michael Evans

    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 !!

  • User profile image

Add Your 2 Cents