Maybe Functions • Hacker News Board

Re: Maybe Functions

#101

Post by withinboredom » Tue, Mar 12, 2024, 7:05 AM UTC

_ZeD_ wrote: post #100

withinboredom wrote: post #68

Earlier quoted context omitted.

Not exactly. "getUser" not having a user to get is not exceptional unless you only have logged in users. If you have logged-out users, then "getUser" should gracefully handle the case of an unknown, logged-out user (either returning null or some other sentinel value).

Returning null makes "getUser" a "maybeGetUser" function. Like said in TFA that means that any caller might need to check for nullness

Yes, no matter what, they have to check if there is an actual user if the application can have anonymous users. There’s no way around that.

Re: Maybe Functions

#102

Post by eru » Wed, Mar 13, 2024, 4:03 AM UTC

koliber wrote: post #98

eru wrote: post #17

Earlier quoted context omitted.

Interestingly, Python uses exceptions for basic control flow, like end of for-loop.

Semantically, Python separates Exceptions and Errors. The mechanism for throwing and catching them is the same. Here's a quick description from somewhere on the interwebs: An error is an issue in a program that prevents the program from completing its task. In comparison, an exception is a condition that interrupts the normal flow of the program. Then there is StopIteration, which does not fit well into either of the…

Well, by your definition of Exceptions and Errors, errors are something that Python, the formal language as understood by the computer, doesn't know anything about. It's a concept for humans that they can use when analysing programs. And different analyses might come to different conclusions. [0]

You could signal errors via eg returning None or False or throwing an exception. But not throwing an exception could also be an error. (Eg if your for-loop never ends, that might be an error. And that would be synonymous with StopIteration never being thrown.)

[0] Eg for a program like 'cat' it would normally be considered an error, when the file being read doesn't exist. But perhaps in my particular usage, that's expected to occur quite often, and is a normal part of my operation. You can translate this example to Python: FileNotFound might be an error, or a normal condition.

Re: Maybe Functions

#103

Post by moomin » Wed, Mar 13, 2024, 11:37 AM UTC

voxl wrote: post #89

mrkeen wrote: post #57

Earlier quoted context omitted.

The kicker here is that the author implemented a functor and called it a monad. So of course readers are going to think "the monad approach" is confusing and stay away.

I mean even if you implement a more standard Monad interface plenty of functional programmers still find working with Monads to be ugly. It's really not a solved area.

I’ll accept that. But do notation is the closest thing to sensible we have, whereas most of these articles are just constantly trying to chip away at part of the problem in the hope that they’ll be able to make the whole mountain disappear one stone at a time. And to date, I don’t find the evidence promising that they can.

I’m not wedded to stuff like monadic state, I think that might be a bridge too far for regular programming (and besides which, it doesn’t really generalise anyway) but that still leaves a large family of issues that we’re all aware of but trying to dodge.