3 ms·

So COMEFROM is now a first-class feature of the most popular programming language in the world. Intercal really was ahead of its time.

nickitolas 7y ago
Could you elaborate?
- braythwayt 7y ago
  COMEFROM began as a joke comtrol-flow construct, but the principle turns out to have a deep semantic value: https://en.wikipedia.org/wiki/COMEFROM https://en.wikipedia.org/wiki/COMEFROM Aspect-Oriented Programming is a kind of COMEFROM. The proposition in the comment is that await is another.
pjmlp 7y ago
Just like Lisp and Algol 68 on other domains, apparently good features tend to take time to become mainstream.
- bandrami 7y ago
  It's a good point, and I remember even some fairly "serious" comp sci people saying COMEFROM was less of a joke than it originally seemed.
bzbarsky 7y ago
I'm not sure I quite see the analogy to COMEFROM. The "problem" with COMEFROM is that at the "target" location (the one control comes from) there is no in-source indication of the control flow transfer. So what looks like linear code turns out to have this unexpected detour to the location of the COMEFROM instruction. This hinders understandability of the code. "await" in JS doesn't have that problem: there is an explicit control flow operation, in the form of resolving a promise, that eventually transfers control to the location of the "await" call. And even then, it's async from a run-to-completion perspective, so doesn't affect linear code, modulo other await calls. I guess the concern is that you could have linear code that calls a function, which does an "await" and you would effectively have a control flow detour that's hidden from view? In that sense, I guess this is sort of like COMEFROM... At least you have to explicitly opt in (via "async function", or async module) for it to be a problem. Anyway, a better analogy from my point of view is that async/await is a very limited form of call-with-current-continuation or so. And with generator functions, JS already had that sort of, but without some of the nice ergonomics.
- bandrami 7y ago
  > I guess the concern is that you could have linear code that calls a function, which does an "await" and you would effectively have a control flow detour that's hidden from view? That's the main issue. The overall control flow cannot be known until the entire abstract syntax tree is generated.
  - bzbarsky 7y ago
    To be fair, that's a problem with GOTO as well (which JS doesn't have, yes); you don't have to go all the way to COMEFROM to get that.... That said, with JS you can't know the overall control flow even one you have the AST, because that `foo()` function call could go anywhere depending on what people did to the global scope independently of your AST. Come to think of it, you can't even determine control flow from the AST in C, unless everything involved has static linkage...

nickitolas 7y ago

Could you elaborate?

braythwayt 7y ago
COMEFROM began as a joke comtrol-flow construct, but the principle turns out to have a deep semantic value: https://en.wikipedia.org/wiki/COMEFROM https://en.wikipedia.org/wiki/COMEFROM Aspect-Oriented Programming is a kind of COMEFROM. The proposition in the comment is that await is another.

pjmlp 7y ago

Just like Lisp and Algol 68 on other domains, apparently good features tend to take time to become mainstream.

bandrami 7y ago
It's a good point, and I remember even some fairly "serious" comp sci people saying COMEFROM was less of a joke than it originally seemed.

bzbarsky 7y ago

I'm not sure I quite see the analogy to COMEFROM. The "problem" with COMEFROM is that at the "target" location (the one control comes from) there is no in-source indication of the control flow transfer. So what looks like linear code turns out to have this unexpected detour to the location of the COMEFROM instruction. This hinders understandability of the code. "await" in JS doesn't have that problem: there is an explicit control flow operation, in the form of resolving a promise, that eventually transfers control to the location of the "await" call. And even then, it's async from a run-to-completion perspective, so doesn't affect linear code, modulo other await calls. I guess the concern is that you could have linear code that calls a function, which does an "await" and you would effectively have a control flow detour that's hidden from view? In that sense, I guess this is sort of like COMEFROM... At least you have to explicitly opt in (via "async function", or async module) for it to be a problem. Anyway, a better analogy from my point of view is that async/await is a very limited form of call-with-current-continuation or so. And with generator functions, JS already had that sort of, but without some of the nice ergonomics.

bandrami 7y ago
> I guess the concern is that you could have linear code that calls a function, which does an "await" and you would effectively have a control flow detour that's hidden from view? That's the main issue. The overall control flow cannot be known until the entire abstract syntax tree is generated.
- bzbarsky 7y ago
  To be fair, that's a problem with GOTO as well (which JS doesn't have, yes); you don't have to go all the way to COMEFROM to get that.... That said, with JS you can't know the overall control flow even one you have the AST, because that `foo()` function call could go anywhere depending on what people did to the global scope independently of your AST. Come to think of it, you can't even determine control flow from the AST in C, unless everything involved has static linkage...