5 ms·

> but not between `await asyncFoo()` and `blockingFoo()` Of course there is. The former constraints the type (or return-type) of the function it is used in, th

> but not between `await asyncFoo()` and `blockingFoo()` Of course there is. The former constraints the type (or return-type) of the function it is used in, the latter does not. > but that difference does not require the introduction of an async/await feature I don't remember saying anything about async/await in my original post though.

pron 4y ago
> Of course there is. The former constraints the type (or return-type) of the function it is used in, the latter does not. That's not a semantic difference, but a syntactic one. Syntactic differences are expressed by which programs are accepted or rejected by the language; semantic differences are expressed by programs exhibiting different behaviours. To show a semantic difference you need to find P and Q such that when the value of P is the same in the two programs, the value of Q could be different; that's what expresses the semantics of the code between P and Q. Again, there are some (e.g. P: `(t = currentThread(), true)`, Q: `currentThread() == t`), but they're purely technical. > I don't remember saying anything about async/await in my original post though. You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines.
- valenterry 4y ago
  > Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines. I agree with that statement. > semantic differences are expressed by programs exhibiting different behaviours. It can cause different behaviour whether code runs on the same thread or on a different one (see one of my other posts here). That doesn't have to happen in every program and it doesn't have to happen on each execution, but that still makes it a different behaviour - at least in my terminology. > You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. That's not what I said (or at least not what I meant). I meant that it is doomed to fail to try to generally unify sync and async code on a language (or runtime) level.
  - pron 4y ago
    When people say a language "unifies sync and async code" all they mean is that there is no distinct syntactic category for "async routines". Rather, asynchronous operations are expressed as regular (i.e. synchronous, blocking) methods spawned on another thread. Either you agree that there is no loss in what you can express or believe it is doomed to fail. I don't understand how you can do both.

pron 4y ago

> Of course there is. The former constraints the type (or return-type) of the function it is used in, the latter does not. That's not a semantic difference, but a syntactic one. Syntactic differences are expressed by which programs are accepted or rejected by the language; semantic differences are expressed by programs exhibiting different behaviours. To show a semantic difference you need to find P and Q such that when the value of P is the same in the two programs, the value of Q could be different; that's what expresses the semantics of the code between P and Q. Again, there are some (e.g. P: `(t = currentThread(), true)`, Q: `currentThread() == t`), but they're purely technical. > I don't remember saying anything about async/await in my original post though. You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines.

valenterry 4y ago
> Everything that you can describe with sync and async routines your can describe, with the same ease and semantics, with just sync routines and threads. There is no need for a special syntactic category of asynchronous subroutines. I agree with that statement. > semantic differences are expressed by programs exhibiting different behaviours. It can cause different behaviour whether code runs on the same thread or on a different one (see one of my other posts here). That doesn't have to happen in every program and it doesn't have to happen on each execution, but that still makes it a different behaviour - at least in my terminology. > You said that the lack of need of a syntactic kind for asynchronous routines is a fallacy. It is not. That's not what I said (or at least not what I meant). I meant that it is doomed to fail to try to generally unify sync and async code on a language (or runtime) level.
- pron 4y ago
  When people say a language "unifies sync and async code" all they mean is that there is no distinct syntactic category for "async routines". Rather, asynchronous operations are expressed as regular (i.e. synchronous, blocking) methods spawned on another thread. Either you agree that there is no loss in what you can express or believe it is doomed to fail. I don't understand how you can do both.