4 ms·

Added the example to the same Gist: https://gist.github.com/mraleph/5991990#file-example5-dart https://gist.github.com/mraleph/5991990#file-example5-dart

by mraleph 13y ago

swannodette 13y ago
Excellent! Though this is precisely illustrative of what I was talking about with respect to JavaScript likely needing promises and generators for non-trivial work. Is Dart going to add sugar over both futures and streams?
- mraleph 13y ago
  Unfortunately I am not aware about concrete plans. I also doubt anything large will happen to the language until after 1.0 Right now there are two separate issues in the Dart's bugtracker: one for Futures https://code.google.com/p/dart/issues/detail?id=104 https://code.google.com/p/dart/issues/detail?id=104 one for Streams https://code.google.com/p/dart/issues/detail?id=7002 https://code.google.com/p/dart/issues/detail?id=7002 but none contain any details of how the syntax will look like at the end.
  - swannodette 13y ago
    Yeah I would be concerned about the Future/Stream dual in Dart, the dualism seems to currently be baked into the API in unfortunate ways - http://api.dartlang.org/docs/releases/latest/dart_async/Stream.html http://api.dartlang.org/docs/releases/latest/dart_async/Stre...
    - mraleph 13y ago
      Well, this dualism is used to communicate important distinction: single value vs. multiple values, so streams return futures in the places where it is absolutely meaningful to do so e.g. first element of a stream can be obviously viewed as a one element stream but it is also a Future because it is at most one value.
    - munificent 13y ago
      I'm on the Dart team and spent time talking to the corelib team when Streams were first added. I had a proposal at the time to unify streams and futures. My contention was that a future was just a stream that only emits one value and then closes. Florian convinced me that that was trying to hard to jam them together. Instead, there's methods to convert from one to the other when you want: new Stream.fromFuture() Future<List> Stream.toList() Future.asStream() Asynchrony is still quite hard to work with compared to a language with coroutines and blocking, but the Future/Stream distinction doesn't seem to cause many problems in practice.
      - swannodette 13y ago
        Yes but I'd argue that your original intuition was probably correct - we don't have this distinction in core.async because we have channels and they can be used for both one offs and stream processing. Of course the reason to eliminate the distinction would be to simplify sugar over asynchronous code a la F#, C#, Scala and now core.async. mraleph seemed to suggest this is being considered for Dart.

Added the example to the same Gist: https://gist.github.com/mraleph/5991990#file-example5-dart https://gist.github.com/mraleph/5991990#file-example5-dart

by mraleph 13y ago

Added the example to the same Gist: https://gist.github.com/mraleph/5991990#file-example5-dart https://gist.github.com/mraleph/5991990#file-example5-dart

swannodette 13y ago

Excellent! Though this is precisely illustrative of what I was talking about with respect to JavaScript likely needing promises and generators for non-trivial work. Is Dart going to add sugar over both futures and streams?

mraleph 13y ago
Unfortunately I am not aware about concrete plans. I also doubt anything large will happen to the language until after 1.0 Right now there are two separate issues in the Dart's bugtracker: one for Futures https://code.google.com/p/dart/issues/detail?id=104 https://code.google.com/p/dart/issues/detail?id=104 one for Streams https://code.google.com/p/dart/issues/detail?id=7002 https://code.google.com/p/dart/issues/detail?id=7002 but none contain any details of how the syntax will look like at the end.
- swannodette 13y ago
  Yeah I would be concerned about the Future/Stream dual in Dart, the dualism seems to currently be baked into the API in unfortunate ways - http://api.dartlang.org/docs/releases/latest/dart_async/Stream.html http://api.dartlang.org/docs/releases/latest/dart_async/Stre...
  - mraleph 13y ago
    Well, this dualism is used to communicate important distinction: single value vs. multiple values, so streams return futures in the places where it is absolutely meaningful to do so e.g. first element of a stream can be obviously viewed as a one element stream but it is also a Future because it is at most one value.
  - munificent 13y ago
    I'm on the Dart team and spent time talking to the corelib team when Streams were first added. I had a proposal at the time to unify streams and futures. My contention was that a future was just a stream that only emits one value and then closes. Florian convinced me that that was trying to hard to jam them together. Instead, there's methods to convert from one to the other when you want: new Stream.fromFuture() Future<List> Stream.toList() Future.asStream() Asynchrony is still quite hard to work with compared to a language with coroutines and blocking, but the Future/Stream distinction doesn't seem to cause many problems in practice.
    - swannodette 13y ago
      Yes but I'd argue that your original intuition was probably correct - we don't have this distinction in core.async because we have channels and they can be used for both one offs and stream processing. Of course the reason to eliminate the distinction would be to simplify sugar over asynchronous code a la F#, C#, Scala and now core.async. mraleph seemed to suggest this is being considered for Dart.