▲ 71 ▼ Unison | A friendly, statically-typed, functional programming language from the future · Unison programming language (www.unison-lang.org) submitted 2 years ago by starman@programming.dev to c/programming@programming.dev 44 comments fedilink hide all child comments A friendly programming language from the future.
[–] steersman2484@sh.itjust.works 9 points 2 years ago (1 child) There are no imports, these are type annotations permalink fedilink source parent hideshow 2 child comments replies: [–] christophski@feddit.uk -4 points 2 years ago (3 children) Do I really have to declare that something requires exceptions? permalink fedilink source parent hideshow 6 child comments replies: [–] steersman2484@sh.itjust.works 8 points 2 years ago (1 child) 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 permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 1 point 2 years ago (1 child) 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). permalink fedilink source parent hideshow 2 child comments replies: [–] steersman2484@sh.itjust.works 1 point 2 years ago (1 child) 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? permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 2 points 2 years ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Pipoca@lemmy.world 1 point 2 years 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. permalink fedilink source parent [–] steersman2484@sh.itjust.works 1 point 2 years 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? permalink fedilink source parent [–] sloppy_diffuser@sh.itjust.works 2 points 2 years ago That's one of the things I appreciate in a language/framework. Drives me nuts getting an exception from a dependency of a dependency of a dependency. Even better if its baked into the type system and I can't run my code without handling it. permalink fedilink source parent [–] Pipoca@lemmy.world 1 point 2 years ago* Functional languages typically have type inference, so the type signatures are entirely optional. I haven't looked that deeply at unison, but I'd be entirely unsurprised if it had global type inference and if all or most type signatures were optimal. It's less that you have to declare something can do IO or throw an exception, and more that you're calling something from the standard library that does IO or throws an exception. Most stuff does neither. There's a type level distinction between normal, regular pure code, and impure effectful code, so it's easy to tell from the type signature whether a function is pure or not. permalink fedilink source parent
[–] christophski@feddit.uk -4 points 2 years ago (3 children) Do I really have to declare that something requires exceptions? permalink fedilink source parent hideshow 6 child comments replies: [–] steersman2484@sh.itjust.works 8 points 2 years ago (1 child) 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 permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 1 point 2 years ago (1 child) 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). permalink fedilink source parent hideshow 2 child comments replies: [–] steersman2484@sh.itjust.works 1 point 2 years ago (1 child) 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? permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 2 points 2 years ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Pipoca@lemmy.world 1 point 2 years 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. permalink fedilink source parent [–] steersman2484@sh.itjust.works 1 point 2 years 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? permalink fedilink source parent [–] sloppy_diffuser@sh.itjust.works 2 points 2 years ago That's one of the things I appreciate in a language/framework. Drives me nuts getting an exception from a dependency of a dependency of a dependency. Even better if its baked into the type system and I can't run my code without handling it. permalink fedilink source parent [–] Pipoca@lemmy.world 1 point 2 years ago* Functional languages typically have type inference, so the type signatures are entirely optional. I haven't looked that deeply at unison, but I'd be entirely unsurprised if it had global type inference and if all or most type signatures were optimal. It's less that you have to declare something can do IO or throw an exception, and more that you're calling something from the standard library that does IO or throws an exception. Most stuff does neither. There's a type level distinction between normal, regular pure code, and impure effectful code, so it's easy to tell from the type signature whether a function is pure or not. permalink fedilink source parent
[–] steersman2484@sh.itjust.works 8 points 2 years ago (1 child) 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 permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 1 point 2 years ago (1 child) 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). permalink fedilink source parent hideshow 2 child comments replies: [–] steersman2484@sh.itjust.works 1 point 2 years ago (1 child) 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? permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 2 points 2 years ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Pipoca@lemmy.world 1 point 2 years 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. permalink fedilink source parent [–] steersman2484@sh.itjust.works 1 point 2 years 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? permalink fedilink source parent
[–] robinm@programming.dev 1 point 2 years ago (1 child) 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). permalink fedilink source parent hideshow 2 child comments replies: [–] steersman2484@sh.itjust.works 1 point 2 years ago (1 child) 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? permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 2 points 2 years ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Pipoca@lemmy.world 1 point 2 years 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. permalink fedilink source parent [–] steersman2484@sh.itjust.works 1 point 2 years 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? permalink fedilink source parent
[–] steersman2484@sh.itjust.works 1 point 2 years ago (1 child) 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? permalink fedilink source parent hideshow 2 child comments replies: [–] robinm@programming.dev 2 points 2 years ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Pipoca@lemmy.world 1 point 2 years 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. permalink fedilink source parent [–] steersman2484@sh.itjust.works 1 point 2 years 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? permalink fedilink source parent
[–] robinm@programming.dev 2 points 2 years ago (2 children) 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. permalink fedilink source parent hideshow 4 child comments replies: [–] Pipoca@lemmy.world 1 point 2 years 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. permalink fedilink source parent [–] steersman2484@sh.itjust.works 1 point 2 years 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? permalink fedilink source parent
[–] Pipoca@lemmy.world 1 point 2 years 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. permalink fedilink source parent
[–] steersman2484@sh.itjust.works 1 point 2 years 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? permalink fedilink source parent
[–] sloppy_diffuser@sh.itjust.works 2 points 2 years ago That's one of the things I appreciate in a language/framework. Drives me nuts getting an exception from a dependency of a dependency of a dependency. Even better if its baked into the type system and I can't run my code without handling it. permalink fedilink source parent
[–] Pipoca@lemmy.world 1 point 2 years ago* Functional languages typically have type inference, so the type signatures are entirely optional. I haven't looked that deeply at unison, but I'd be entirely unsurprised if it had global type inference and if all or most type signatures were optimal. It's less that you have to declare something can do IO or throw an exception, and more that you're calling something from the standard library that does IO or throws an exception. Most stuff does neither. There's a type level distinction between normal, regular pure code, and impure effectful code, so it's easy to tell from the type signature whether a function is pure or not. permalink fedilink source parent