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.

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.

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.

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.

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

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.

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

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

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?

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.

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?

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?

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.

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?

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.

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?