Hacker News Reader

> I'm not sure I understand the relationship between partial function and exception handling. Aren't partial functions just curried?

You're thinking "partially applied function", which uses very similar terms but means something completely unrelated.

A partially applied function is a function which is applied to a subset of its formal arguments, yielding a function taking the leftover arguments.

A partial function is contrasted with a total function and the term is about the relation between inputs and outputs, namely does every possible input value yield an output. The example of `first` used in the essay is pretty common because it's quite clear: given `first :: [a] -> a`, what happens if you call `first` with an empty list? Well it can't succeed, it can't just give you an `a` out of nowhere because it doesn't have anything to do that. So despite an empty array being a possible input value, there is no output for it: it is a partial function, it only partially maps its inputs to its outputs.

`first :: [a] -> Maybe a` would be total: in the case of an empty input it returns `None`, otherwise it returns `Some a`.

Ah thanks, I'm used to this being called a "complete function".

`Just a` / `Nothing` in case of Haskell :)

"Partial function" is an overloaded term. In this context it means "a function which does not map its entire domain to an output". This means that there are some inputs which return "Bottom", which happily gets propagated through the system until it is needed as input to some function and then your application explodes.

The downside here is that rather than blowing up your application immediately upon a bug it blows up your application somewhere else depending on your logic.

This can be a useful thing. You can write powerful and elegant algorithms that avoid error management because the bottom values never actually get used. But most people aren't doing that and instead these are time bombs.

> This can be a useful thing. You can write powerful and elegant algorithms that avoid error management because the bottom values never actually get used.

Agreed. This would be with some escape hatch function, maybe even from Unsafe.

But having head in Prelude, without huge warning in the docs, without deprecation warnings, it just, well, not very Haskelly, I'd say.

when bottom is actually reached that point of evaluation, does haskell provide any indication on where it came from? stacktrace or something?

Partial functions are not the same thing as "partially applied functions". Partial functions means that not every element of the domain is mapped to an element of the range, for example:

    divTenBy :: Double -> Double
    divTenBy n = 10 / n

If you actually call the above function you get a runtime exception. We really don't like functions that do this; they are called partial.

Am I missing something subtle? Why would you get a runtime exception if you call this function?

The parent missed a part. If you call it with 0 you get an exception, because division by zero obviously.

No, you don't. You get Infinity. That's how floating point works.

In most languages you get an exception

Which languages would those be?

  $ python3
  Python 3.9.1 (default, Feb  3 2021, 07:04:15)
  [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> 10 / 0
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ZeroDivisionError: division by zero
  >>>

Although Python seems to be the exception to the rule here, your example isn't exactly right. In your example, you're performing integer division, not floating point division. In most languages, integer division by zero is indeed some kind of exception (or UB, which will most likely result in a hardware exception, causing a signal sent to the process). However, floating point division by zero is well-defined, as per definition of floating point arithmetic (in some RFCs), and most languages don't throw exceptions in this case. Python indeed seems to be the exception to the rule.

In Python 3, 1/0 is floating point division. 1//0 would be integer division.

Right, Python2 is still the default on Debian, so I didn't notice.

I guess I'm thinking of Python mostly. I thought OCaml did as well but apparently not.

If you call it with argument 0 you get a runtime exception, because it results in a division by zero.

It's "partial" because it's not defined for 0.

If Double is IEEE 754 compatible then it should be perfectly defined for 0, you'd get +/- infinity. There are algorithms which rely on this.

So it should have been: Double -> Maybe Double

That would be the "right way" to fix this.

(or create a type NotNilDouble, lol)

Or, controversially, define 1/0 = 0.[1]

[1]: https://www.hillelwayne.com/post/divide-by-zero/

Enough controversy in defining std libs as it is :)

The "right" way for division by zero is controversial, though maybe that would be a solution.

It's clearer for partial function "head :: [a] -> a", which takes the first of a list if it exists, and explodes without dignity if the list is empty (this is what makes head partial).

A proposal is "head :: [a] -> Maybe a", so head returns Nothing when the list is empty.

Idris does well here:

https://www.idris-lang.org/docs/current/prelude_doc/docs/Pre...'

Idris does well here:

https://www.idris-lang.org/docs/current/contrib_doc/docs/Dat...

Ah, so partial functions aren't onto (i.e. surjective).

Not exactly, partial functions can be surjective, eg

f :: Int -> Bool

f 0 = True

f 1 = False

f n = f (n + 1)

is surjective onto Bool but also partial (doesn't return for n > 1). In Haskell we say that when a function doesn't return, the output is bottom, written as ⊥.

You could say that a function f : A -> B is partial if f^{-1}(B \ ⊥) is surjective.

No, they are not functions in the mathematical sense. It's not that they don't cover the output space, they don't cover the input space.

>Aren't partial functions just curried? One or more arguments are bound, but not all?

No; a partial function is one that isn't well-defined for the whole of its domain. So, as per the article, head is a partial function because its type signature of [a] -> a implies that all arrays have a head value. But head [] does not. It's a partial function.

What approaches and tools do Haskell developers take to guard against this? I assume in the head case a Maybe would be a better return type? But then why doesn't the Haskell core do that in the head function?

In my experience (which is quite dated at this point; my Haskell usage is back to the turn of the millennium), the usual approach was pattern matching. i.e. if you knew you were going to use a function that might not be defined you would write an alternate case.

The type system isn't helping you at all there.

The feeling I had was that much of the prelude stuff was there to provide for beautiful, terse examples of functional programming and less to protect a software engineer.

Few interesting things in this comment, thanks! What you say makes sense; it sounds like Haskell can't literally hold my hand for me which is fair enough.

I've just started my Haskell journey and the undefined paths through partial function implementation caught me by surprise.

Just skimming Wikipedia it looks like I would want to use "total/strong functional programming" but apparently "total functional programming is not Turing-complete"

https://en.wikipedia.org/wiki/Total_functional_programming

Also found this on the Haskell site after some more googling:

https://wiki.haskell.org/Partial_functions

> Just skimming Wikipedia it looks like I would want to use "total/strong functional programming" but apparently "total functional programming is not Turing-complete"

It isn't, but usually Turing completeness isn't what you want. Take a look at Idris, where functions may explicitly be total or not-necessarily-total.

A partial function is a function where all inputs have an output. For example, calling head on an empty list will throw an exception. To make this a total function you’d need to return a Maybe instead.

*not all inputs

Exactly, meant to say that :)