4 ms·

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 progr

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.

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.