8 ms·

OK, I give in - I can't for the life of me think of why this is interesting. I mean, it's the equivalent of passing a pointer to a value rather than the value

OK, I give in - I can't for the life of me think of why this is interesting. I mean, it's the equivalent of passing a pointer to a value rather than the value itself in C, and is the bog standard techniques to use in this type of language to achieve multiple return values. But I just don't get why that is interesting - it's a bit more like programming 101...

victorNicollet 11y ago
This is not passing-by-pointer. If you look at the example `swap(i,A[i])` in the "Criticism" section, you'll see that it is not the address of `A[i]`(as evaluated at call time) that is passed, but the entire expression `A[i]` to be re-evaluated every time `i` changes. There isn't a lot of support for this kind of thing in modern languages. Lambdas do come to mind, e.g. `swap(() => i, () => A[i])`, but few languages support returning lvalues from closures without significant boilerplate.
- FrankenPC 11y ago
  Thanks for the explanation. In general, is this considered an anti-pattern? In other words, It's interesting but not advisable to consider in production programming?
  - victorNicollet 11y ago
    It's mostly a language-evolutionary dead end that gave us some good ideas. The original implementations were very bad: pass-by-name was not visible at the calling point, so any function call could suddenly break due to aliasing issues (or change the value of a local variable, which is also the case with pass-by-reference). I am not aware of any widely used modern languages that implement it outside of macros (including C preprocessor macros, LISP, etc.) The original concept has been refined over time and made its way into other languages though, in the form of callbacks, continuations, etc.
    - kybernetikos 11y ago
      > The original implementations were very bad: pass-by-name was not visible at the calling point, so any function call could suddenly break due to aliasing issues (or change the value of a local variable, which is also the case with pass-by-reference). I am not aware of any widely used modern languages that implement it outside of macros (including C preprocessor macros, LISP, etc.) Scala. Call-by-name that is invisible at the call point. It doesn't cause aliasing issues because it's treated like getting passed a lambda, but if any of the code has side effects you can be very surprised about when they occur.
      - karmakaze 11y ago
        I've used Scala's call-by-name, but what I really wanted was call-by-let taking the argument as pure and evaluating at most once in the called function.
        kybernetikos 11y ago
        scala's call-by-name is often used for implementing control-flow like structures, so you can understand why they would want to be able to evaluate it more than once. Having said that, there are so many situations where it can be surprising, I'd probably have had a rule that you have to use {} to indicate call-by-name arguments at call site.
- antimagic 11y ago
  Yup, thanks for the explanation - I missed that on first reading. It seems like an incredibly bad idea though - it makes me think of all of the subtle gotchas involved in using macros in C, where expansion can get very weird when you put an expression in the place of a variable.

victorNicollet 11y ago

This is not passing-by-pointer. If you look at the example `swap(i,A[i])` in the "Criticism" section, you'll see that it is not the address of `A[i]`(as evaluated at call time) that is passed, but the entire expression `A[i]` to be re-evaluated every time `i` changes. There isn't a lot of support for this kind of thing in modern languages. Lambdas do come to mind, e.g. `swap(() => i, () => A[i])`, but few languages support returning lvalues from closures without significant boilerplate.

FrankenPC 11y ago
Thanks for the explanation. In general, is this considered an anti-pattern? In other words, It's interesting but not advisable to consider in production programming?
- victorNicollet 11y ago
  It's mostly a language-evolutionary dead end that gave us some good ideas. The original implementations were very bad: pass-by-name was not visible at the calling point, so any function call could suddenly break due to aliasing issues (or change the value of a local variable, which is also the case with pass-by-reference). I am not aware of any widely used modern languages that implement it outside of macros (including C preprocessor macros, LISP, etc.) The original concept has been refined over time and made its way into other languages though, in the form of callbacks, continuations, etc.
  - kybernetikos 11y ago
    > The original implementations were very bad: pass-by-name was not visible at the calling point, so any function call could suddenly break due to aliasing issues (or change the value of a local variable, which is also the case with pass-by-reference). I am not aware of any widely used modern languages that implement it outside of macros (including C preprocessor macros, LISP, etc.) Scala. Call-by-name that is invisible at the call point. It doesn't cause aliasing issues because it's treated like getting passed a lambda, but if any of the code has side effects you can be very surprised about when they occur.
    - karmakaze 11y ago
      I've used Scala's call-by-name, but what I really wanted was call-by-let taking the argument as pure and evaluating at most once in the called function.
      - kybernetikos 11y ago
        scala's call-by-name is often used for implementing control-flow like structures, so you can understand why they would want to be able to evaluate it more than once. Having said that, there are so many situations where it can be surprising, I'd probably have had a rule that you have to use {} to indicate call-by-name arguments at call site.
antimagic 11y ago
Yup, thanks for the explanation - I missed that on first reading. It seems like an incredibly bad idea though - it makes me think of all of the subtle gotchas involved in using macros in C, where expansion can get very weird when you put an expression in the place of a variable.