A friendly programming language from the future.

  • steersman2484@sh.itjust.works
    link
    fedilink
    arrow-up
    9
    arrow-down
    1
    ·
    1 year ago

    Yes, in functional programming you want to use pure functions. Exceptions are impure, therefore it has to be declared.

    Other functional languages don’t even have exceptions

    • robinm@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I’m surprised about this statement, I would have said that exceptions are the consequence of an impure operation (that may or may not fail differently every time you call it).

      • steersman2484@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        I’m currently learning functional languages and have only limited knowledge, but from what I’ve read now you are right. Throwing exceptions is pure, but catching them is impure.

        In this case I guess the printLine function can throw an exception therefore the calling function must be declared with Exception?

        • robinm@programming.dev
          link
          fedilink
          arrow-up
          2
          ·
          1 year ago

          I would even have said that both throwing and catching should be pure, just like returning an error value/handling should be pure, but the reason for the throw/returning error itself is impure. Like if you throw and ioerror it’s only after doing the impure io call, and the rest of the error reporting/handling itself can be pure.

          • steersman2484@sh.itjust.works
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Sounds good,

            but would the preferred way be to use a wrapper type, which holds either the data or the error and avoid exceptions completely?

          • Pipoca@lemmy.world
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Pure functions should be referentially transparent; you should be able to replace them with whatever value they evaluate to without changing the semantics of your code.

            Throwing is referentially impure: what value do you get from calling x => throw new RuntimeException()?

            Instead, functional languages prefer to return a tagged union of the value or the error.