6 ms·

I don’t understand your final point. Are you saying that generics on futures are bad? I don’t see the alternative.

by dfee 6y ago

chrisseaton 6y ago
> Are you saying that generics on futures are bad? Yes - because it means existing code that expects a T cannot accept a Future<T>, which is the colouring problem being discussed. You end up with half your code accepting futures and the other legacy half not accepting them and there's a divide. If you want to use the legacy code you have to force the future potentially before you really needed it. > I don’t see the alternative. The alternative is wherever a function accepts a concrete value T t, also let it accept a future value T t. When t is actually used, then block as if get was called.
- tinco 6y ago
  Does this mean that Rust's Future trait is incorrectly named? Or at least not named according to the academic use of the word? Of course because Rust's runtime or lack thereof aims to be zero overhead a Future could never be without the poll function.. right? You need a runtime to make regular functions accept these magic opaque future values.
  - chrisseaton 6y ago
    Yes not named according to the original paper. Yes it requires some kind of special compiler or runtime support.
- wbl 6y ago
  Isn't Future a functor?
  - chrisseaton 6y ago
    That's not the intention of the original authors, no.
- valenterry 6y ago
  > Yes - because it means existing code that expects a T cannot accept a Future<T> First of all, this is a programming language specific problem, not a general one. A good language allows you to write: someFuture.map(someFunction) Where "someFunction" accepts the plain value of type T that is stored within "someFuture". Yes, you cannot write someFunction(someFuture), but that is a good thing, since asynchronous execution can very well change the behaviour of the program. Hence, I want the compiler (if there is one) to warn me if a variable that I pass to a function is now a Future instead of a plain value. I then map over the Future and I'm good. Or, maybe I want to wait for completion of the future and I'm good. In both cases, there is no reason to write a second version of "someFunction". Therefore... > If you want to use the legacy code you have to force the future potentially before you really needed it. ... this is only true in incapable programming languages.
  - chrisseaton 6y ago
    Isn't this the point I was making? You need support in the language to do this. If you're writing a library routine from scratch as Future<... with the compiler knowing nothing about how to handle it specially then you aren't getting a future as they were originally envisioned and you're missing out.
    - valenterry 6y ago
      > Isn't this the point I was making? I don't think so - let me try to make it more clear, hold on. > You need support in the language to do this. If you're writing a library routine from scratch as Future<... with the compiler knowing nothing about how to handle it specially then you aren't getting a future as they were originally envisioned and you're missing out. You seem to assume that the programming language needs to know of the existence of Futures to help. But that is not the case and probably the reason for the misunderstanding. It is sufficient that the language supports generics/type-parameters as well as a lightweight syntax (such as in the example I gave) and optimally higher kinded types or a similar mechanism. If that is given, the language can be totally agnostic of Futures or async programming in general and it is easily possible to define a Future type as a library-type and use it in the way I described. Scala is a good example of such a language.

I don’t understand your final point. Are you saying that generics on futures are bad? I don’t see the alternative.

by dfee 6y ago

I don’t understand your final point. Are you saying that generics on futures are bad? I don’t see the alternative.

> Are you saying that generics on futures are bad? Yes - because it means existing code that expects a T cannot accept a Future<T>, which is the colouring problem being discussed. You end up with half your code accepting futures and the other legacy half not accepting them and there's a divide. If you want to use the legacy code you have to force the future potentially before you really needed it. > I don’t see the alternative. The alternative is wherever a function accepts a concrete value T t, also let it accept a future value T t. When t is actually used, then block as if get was called.

tinco 6y ago
Does this mean that Rust's Future trait is incorrectly named? Or at least not named according to the academic use of the word? Of course because Rust's runtime or lack thereof aims to be zero overhead a Future could never be without the poll function.. right? You need a runtime to make regular functions accept these magic opaque future values.
- chrisseaton 6y ago
  Yes not named according to the original paper. Yes it requires some kind of special compiler or runtime support.
wbl 6y ago
Isn't Future a functor?
- chrisseaton 6y ago
  That's not the intention of the original authors, no.
valenterry 6y ago
> Yes - because it means existing code that expects a T cannot accept a Future<T> First of all, this is a programming language specific problem, not a general one. A good language allows you to write: someFuture.map(someFunction) Where "someFunction" accepts the plain value of type T that is stored within "someFuture". Yes, you cannot write someFunction(someFuture), but that is a good thing, since asynchronous execution can very well change the behaviour of the program. Hence, I want the compiler (if there is one) to warn me if a variable that I pass to a function is now a Future instead of a plain value. I then map over the Future and I'm good. Or, maybe I want to wait for completion of the future and I'm good. In both cases, there is no reason to write a second version of "someFunction". Therefore... > If you want to use the legacy code you have to force the future potentially before you really needed it. ... this is only true in incapable programming languages.
- chrisseaton 6y ago
  Isn't this the point I was making? You need support in the language to do this. If you're writing a library routine from scratch as Future<... with the compiler knowing nothing about how to handle it specially then you aren't getting a future as they were originally envisioned and you're missing out.
  - valenterry 6y ago
    > Isn't this the point I was making? I don't think so - let me try to make it more clear, hold on. > You need support in the language to do this. If you're writing a library routine from scratch as Future<... with the compiler knowing nothing about how to handle it specially then you aren't getting a future as they were originally envisioned and you're missing out. You seem to assume that the programming language needs to know of the existence of Futures to help. But that is not the case and probably the reason for the misunderstanding. It is sufficient that the language supports generics/type-parameters as well as a lightweight syntax (such as in the example I gave) and optimally higher kinded types or a similar mechanism. If that is given, the language can be totally agnostic of Futures or async programming in general and it is easily possible to define a Future type as a library-type and use it in the way I described. Scala is a good example of such a language.