Re: [scala] Stuff to think about: the new .Net approach regarding async processes

[Meredith Gregory]

Dear Simon,

Some of the ppl involved in informing .net features and design include, but are not limited to

• Simon Peyton-Jones
• Don Symes
• Andy Gordon
• Erik Meijer
• Brian Beckman
• Lucian Wischik

Of all the descriptions that come to mind when i think about this crew, kids playing with things they don't understand? Well... in the same way that John Horton Conway is like a kid playing with things when he does mathematics, maybe.

Personally, i think the saddest thing about .net is the choice of MSFT mgt to hobble it's migration to Unix-based platforms. Were it able to compete freely and fairly with the JVM on the full range of platforms i think we would all benefit.

This is far off topic for Scala. So, i've added a transition to scala-debate.

Best wishes,

--greg

On Tue, Jan 4, 2011 at 3:55 PM, Simon Ochsenreither <[hidden email]> wrote:

Hi Nono!

In my opinion the .NET people are kids playing with things they don't really understand. They did an almost good job when they were just copying the Java language and the JVM spec (and fixing some of the design mistakes while doing it).

But if they keep up the speed with which they introduce new keywords into the language they will be the new heir to COBOL and ABAP.

I'm glad that in Scala libraries can be written to look "like keywords" without having to massacre the language spec every new release for the PR department.

Bye,

Simon

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

[Ben Hutchison-3]

On Wed, Jan 5, 2011 at 7:50 AM, Live Nono <[hidden email]> wrote:
> I had previously a look at delimited continuations but they felt quite
> abstract to me and I didn't see such an easy path to use async
> calls... But most probably it's only me. Has someone some examples
> aimed at this context ? => currently I would be at pain to do async
> call in a web app, using scala, as "nicely" as this async CTP.

+1. What is appealing about .Net's new "async" keyword is that it
packages up continuations into a user-friendly form that addresses one
of the most compelling use cases for continuations: to make asynch
calls appear synchronous from the callers perspective.

- "async" is more composable and much nicer to read & write than a
callback closure
- It seems to address a major scalability issue with synchronous RPC
mechanisms like RMI, that they tie up a thread on the client
machine(s) for the duration of the call
- Futures are no substitute for async because they block the calling thread

 I too would like to see something as easy-to-consume as "async" in Scala.

-Ben

[Razvan Cojocaru-2]

There is something as easy to consume in scala as "async":
https://github.com/razie/gremlins/blob/master/ScalaWorkflows.markdown 

...Including the let bang from F# :)

        def wfa1 = seq {
          val a = let! async { _ + "-a" }
          matchLater { case _ => a.get + "-b" }
        }

Or even proper CSP: this expression is valid:

        v(c) (c ? P | c ! Q)

I wish I had more time to spend on this project, I think it could turn into
something very useful in just in just a few weeks...

As to the async itself - nah. Actors like akka are much better thought out
as a foundation for async stuff, including schedulers, transactors etc. A
much better ecosystem in my opinion.

Although I deeply resent the syntax in F#, I do like the way they wrapped
the thing in a proper monad though... the async/let-bang part I mean.

-----Original Message-----
From: Ben Hutchison [mailto:[hidden email]]
Sent: January-04-11 9:23 PM
To: Live Nono
Cc: Josh Suereth; Ittay Dror; [hidden email]
Subject: [scala-debate] Re: [scala] Stuff to think about: the new .Net
approach regarding async processes

On Wed, Jan 5, 2011 at 7:50 AM, Live Nono <[hidden email]> wrote:
> I had previously a look at delimited continuations but they felt quite
> abstract to me and I didn't see such an easy path to use async
> calls... But most probably it's only me. Has someone some examples
> aimed at this context ? => currently I would be at pain to do async
> call in a web app, using scala, as "nicely" as this async CTP.

+1. What is appealing about .Net's new "async" keyword is that it
packages up continuations into a user-friendly form that addresses one of
the most compelling use cases for continuations: to make asynch calls appear
synchronous from the callers perspective.

- "async" is more composable and much nicer to read & write than a callback
closure
- It seems to address a major scalability issue with synchronous RPC
mechanisms like RMI, that they tie up a thread on the client
machine(s) for the duration of the call
- Futures are no substitute for async because they block the calling thread

 I too would like to see something as easy-to-consume as "async" in Scala.

-Ben

[Tony Morris]

On 05/01/11 12:23, Ben Hutchison wrote:

> On Wed, Jan 5, 2011 at 7:50 AM, Live Nono <[hidden email]> wrote:
>> I had previously a look at delimited continuations but they felt quite
>> abstract to me and I didn't see such an easy path to use async
>> calls... But most probably it's only me. Has someone some examples
>> aimed at this context ? => currently I would be at pain to do async
>> call in a web app, using scala, as "nicely" as this async CTP.
> +1. What is appealing about .Net's new "async" keyword is that it
> packages up continuations into a user-friendly form that addresses one
> of the most compelling use cases for continuations: to make asynch
> calls appear synchronous from the callers perspective.
>
> - "async" is more composable and much nicer to read & write than a
> callback closure
> - It seems to address a major scalability issue with synchronous RPC
> mechanisms like RMI, that they tie up a thread on the client
> machine(s) for the duration of the call
> - Futures are no substitute for async because they block the calling thread
>
>  I too would like to see something as easy-to-consume as "async" in Scala.
>
> -Ben

I heard a rumour that such a thing is scheduled for inclusion into
scalaz soon.

--
Tony Morris
http://tmorris.net/

[Martin Odersky]

On Wed, Jan 5, 2011 at 5:02 AM, Tony Morris <[hidden email]> wrote:

On 05/01/11 12:23, Ben Hutchison wrote:
> On Wed, Jan 5, 2011 at 7:50 AM, Live Nono <[hidden email]> wrote:
>> I had previously a look at delimited continuations but they felt quite
>> abstract to me and I didn't see such an easy path to use async
>> calls... But most probably it's only me. Has someone some examples
>> aimed at this context ? => currently I would be at pain to do async
>> call in a web app, using scala, as "nicely" as this async CTP.
> +1. What is appealing about .Net's new "async" keyword is that it
> packages up continuations into a user-friendly form that addresses one
> of the most compelling use cases for continuations: to make asynch
> calls appear synchronous from the callers perspective.
>
> - "async" is more composable and much nicer to read & write than a
> callback closure
> - It seems to address a major scalability issue with synchronous RPC
> mechanisms like RMI, that they tie up a thread on the client
> machine(s) for the duration of the call
> - Futures are no substitute for async because they block the calling thread
>
>  I too would like to see something as easy-to-consume as "async" in Scala.
>
> -Ben

I heard a rumour that such a thing is scheduled for inclusion into
scalaz soon.

Cool!

I think that delimited continuations are the right `substrate' on which to base async as a library feature. But they themselves are too low-level; they need to be abstracted a bit to make them more user-friendly.

Cheers

 -- Martin
 

[Daniel Sobral]

Like https://github.com/jsuereth/scala-arm/blob/master/src/test/scala/resource/TestJDBC.scala, for instance?

One advantage of Scala's delimited continuations is how one can create libraries out of its abstractions.

On Wed, Jan 5, 2011 at 00:23, Ben Hutchison <[hidden email]> wrote:

On Wed, Jan 5, 2011 at 7:50 AM, Live Nono <[hidden email]> wrote:
> I had previously a look at delimited continuations but they felt quite
> abstract to me and I didn't see such an easy path to use async
> calls... But most probably it's only me. Has someone some examples
> aimed at this context ? => currently I would be at pain to do async
> call in a web app, using scala, as "nicely" as this async CTP.

+1. What is appealing about .Net's new "async" keyword is that it
packages up continuations into a user-friendly form that addresses one
of the most compelling use cases for continuations: to make asynch
calls appear synchronous from the callers perspective.

- "async" is more composable and much nicer to read & write than a
callback closure
- It seems to address a major scalability issue with synchronous RPC
mechanisms like RMI, that they tie up a thread on the client
machine(s) for the duration of the call
- Futures are no substitute for async because they block the calling thread

 I too would like to see something as easy-to-consume as "async" in Scala.

-Ben

--
Daniel C. Sobral

I travel to the future all the time.

[Simon Ochsenreither]

Hi Meredith,

I certainly didn't think of the Haskell people and related ones here
... they are nothing less than half-gods.

I mean those average programmers, who actually have to work out how a
feature or API will look and work. It is much like in the early days
of Java where people wrote e. g. the numeric classes without having
ever seen number theory before that. Or String handling (without
having an idea about how Unicode works ... but Unicode was "almost
new" at that time)

But in my humble opinion many of these things can be apologized,
because they tried quite some new things in the VM, the language, had
limited resources, not much time, etc., which just took concentration
away from these "simple" or "basic" things.
The .NET people can't be apologized that way.

They have the resources, they had all the blueprints, they copied the
whole language and VM spec for their first version of "C#/.NET", they
know the cases where things worked and where it didn't from Java
already. There is no excuse except for marketing reasons to butcher
all these new things into the language spec.

They have seen what happens. They should have known better. They
should act better than that.

Thanks and bye,

Simon

[Alex Cruise-2]

On Wed, Jan 5, 2011 at 4:59 AM, Simon Ochsenreither <[hidden email]> wrote:

... the early days of Java ... String handling (without having an idea about how Unicode works ... but Unicode was "almost new" at that time)

Minor correction... In 1995, all the Unicode you could ever want would fit comfortably in 16 bits per character.  Java switched to UTF-16 after Unicode got bigger, but unfortunately, the change couldn't be entirely transparent to user code--see the recent "ropes" thread.

-0xe1a

[JamesJ-2]

If delimited continuations are indeed "the way to go", when do they
become a part of the default language compiler instead of a plugin?
Or are there still "issues"?  How mature is this technology in Scala?

James

[Meredith Gregory]

Dear James,

Great question! So... some of the stumbling blocks at the moment are

• Direct style means -- roughly -- that all the collections are going to have to be continuations friendly.
• Monadic style means -- well, you're going to have to program monadically.

This is a bit of a false dichotomy, but i adopt it for expository purposes. Either of these is a bit of a challenge: the former to the Scala team or community; the latter to the programmer coming from Java. To my mind we've passed the tipping point and monads are the new "object" technology -- making the latter a preferred choice. However, this adoption curve has a very long tale. So a good choice -- from the point of view of serving the community best -- is by no means clear.

Best wishes,

--greg

On Wed, Jan 5, 2011 at 2:45 PM, JamesJ <[hidden email]> wrote:

If delimited continuations are indeed "the way to go", when do they
become a part of the default language compiler instead of a plugin?
Or are there still "issues"?  How mature is this technology in Scala?

James

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

[Raoul Duke]

On Wed, Jan 5, 2011 at 4:23 PM, Meredith Gregory
<[hidden email]> wrote:
> Direct style means -- roughly -- that all the collections are going to have
> to be continuations friendly.
> Monadic style means -- well, you're going to have to program monadically.

is it possible to implement it one way under the covers, then support
either up above? i mean - and i don't know what the heck i'm talking
about at all - i thought one could do continuations via monads. would
that be helpful? or impossible? or a complete syntax error of a
thought?

[Meredith Gregory]

Dear Raoul,

Another great line of questioning! Tiark and i briefly discussed this on this list. The shape of the delimited continuations library is such that it already mostly like a layered approach, but it needs a bit of tweaking if we wanted to align it with, say, the monadic approach outlined by Simon P-J, et al (and mostly adopted by Oleg Kiselyov in some of his Haskell examples).

i understand the argument for direct style. i understand Martin's feelings about finding a friendly interface; and, at this point, i've come to believe that if anyone could do it, Martin's team can. Personally, i really like the approach mentioned above because it actually exposes some deeper underlying stuff waiting for us to exploit. For example, if you differentiate the data type of the lambda calculus what you get looks remarkably like the syntactic structure underlying the monadic approach. This means that there's the potential to exploit Connor McBride's tricks in his Clowns to the Left of Me, Joker's to the right paper provide generic programming for the control level. Again, i suspect that really friendly interfaces for the control side of what delimited continuations can do lie in that direction. But, that's just the way my mind works, ymmv.

All of this also opens up the discussion of having differentiation available for all the immutable collection types, at least; but i digress.

Best wishes,

--greg

On Wed, Jan 5, 2011 at 4:26 PM, Raoul Duke <[hidden email]> wrote:

On Wed, Jan 5, 2011 at 4:23 PM, Meredith Gregory
<[hidden email]> wrote:
> Direct style means -- roughly -- that all the collections are going to have
> to be continuations friendly.
> Monadic style means -- well, you're going to have to program monadically.

is it possible to implement it one way under the covers, then support
either up above? i mean - and i don't know what the heck i'm talking
about at all - i thought one could do continuations via monads. would
that be helpful? or impossible? or a complete syntax error of a
thought?

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

[Josh Suereth]

The library part of delimited continuations library is part of the standard library jar, and the plugin is included with all distributions.  It's lack of automatic inclusion in maven/sbt is unfortunate and something I'd like to correct in the moderate future (it's still on the bottom of my todo list, which is rather lengthy).

The compiler plugin itself is separate I think for design resigns.  It's also convenient to have a nice example of what's possible with compiler plugins.

On Wed, Jan 5, 2011 at 5:45 PM, JamesJ <[hidden email]> wrote:

If delimited continuations are indeed "the way to go", when do they
become a part of the default language compiler instead of a plugin?
Or are there still "issues"?  How mature is this technology in Scala?

James