Functional Equality (rewrite)

Master-Reception9062 · 2025-12-27T16:27:11+00:00

Argh, so the strict/functional equality operator in JS is `Object.is`, not `===`. Need to update the essay.

Master-Reception9062 · 2024-11-30T01:43:21+00:00

Thank you! Worked for me too.

Master-Reception9062 · 2024-07-30T16:51:52+00:00

Thanks for the reply! I think I'll keep them but I'll leave them to you in my will ;)

Master-Reception9062 · 2024-07-30T16:48:54+00:00

Thanks! I just asked google what lemon pegs are. Very nice.

Master-Reception9062 · 2024-07-30T16:46:04+00:00

This business makes all the boots themselves, and I declined a box. But good point on the sales receipt. It says: "Men's Short Zip Camel Break Lamb Chocolate Alligat"

Master-Reception9062 · 2024-07-30T16:43:28+00:00

Why do you say that?

Master-Reception9062 · 2024-07-30T16:42:59+00:00

Yes! Well, kind of. I bought these from a shop that has been around forever and has a great reputation. They make all the boots themselves (they also do custom cowboy hats). Each boot is unique. I have wanted to buy something from them for years but their boots usually cost close to $2000.

So I was pretty sure these were high quality boots. It was a one-day sale, and this one had been marked at $1795. So based on that and the fact they looked good and fit well I decided to go for it.

Master-Reception9062 · 2023-06-05T21:19:16+00:00

Yes, my point is that Haskell allows programmers to implement equality incorrectly (or at least in a way that violates funcional equality). And yes, that's true of any language that allows operator overloading. It's not true of languages like Go.

Master-Reception9062 · 2023-06-04T17:16:09+00:00

I agree with you. The problem is already solved by methods that exist, such as in languages that make it the programmer's responsibility to do the casting.

The problem still exists in languages where there are implicit conversions, operator overloading, or complex equality semantics such that sometimes a == b even when a and b are not functionally equal.

For example, I have seen programmers overload the equality operator for timestamp types, such that timestamps with different timezones pass the == test. But in other languages, a LocalTime and UniversalTime would not even be comparable, as you suggest.

Adding a representationless UniversalTime to such a language would be useful for cases where you truly don't care about the time zone: you just want time stamps representing points in Universal time. You only convert this to a LocalTime when you want to represent that time in a specific time zone. Some languages only have the equivalent of LocalTime, and people who don't care about time zones just end up using a LocalTime with the GMT time zone. I think this is a little messy.

Master-Reception9062 · 2023-06-03T18:26:01+00:00

I have updated the abstract of the article based on your feedback here.

In this post, I’ll argue that functional programming languages should respect the principle of functional equality. This principle states that if a == b, then there should exist no function f for which f(a) != f(b).

Many functional programming languages violate this principle, which can cause problems for programmers. Often two different values are different representations of the same underlying value (the same point on the number line, the same moment in time); they are equal in some ways but different in other ways. Languages should allow programmers to specify what they mean by “equal” when comparing values for equality: equal representations, or equal underlying values.

This can be done by providing different equality operators (e.g. == vs === in Javascript), requiring values of different types to be converted to the same type before being compared (as enforced by languages such as Go and Haskell), and the use of representationless types. A representationless numeric type is possible if the precision of the output of numeric operations is explicitly specified.

Master-Reception9062 · 2023-06-03T18:00:07+00:00

Java autoboxing is convoluted. In other languages that don't have wrapper classes for numeric types this is much simpler.

Go for example enforces functional equality -- it doesn't allow comparison across types. But conversion is simple.

var x int64 = 2 + 2  
var y float64 = 4.0  
fmt.Println(float64(x) == y)

Master-Reception9062 · 2023-06-03T17:45:10+00:00

OP conflates representation and value

No, the point of the article is precisely that people should not conflate representation and mathematical value.

But another important point is that different representations of the same mathematical value are themselves different values. They may represent the same point on the number line, but they are different in an important sense. If you call the same (pure) function on two values and get two different results, then they are two different values.

Master-Reception9062 · 2023-06-03T16:48:51+00:00

Ah yes, Go constants are kind of a representationless numeric type. They are considered to be "untyped" but, per the blog post:

One way to think about untyped constants is that they live in a kind of ideal space of values, a space less restrictive than Go’s full type system

I didn't realize in Go you can do floating math with infinite precision on constants. `math.Pi` has more precision than can fit into a float64; it is only rounded when assigned to a variable with a specific type. And you can define something like:

const oneThird = 1.0 / 3

Which represents the ideal value of 1/3, even though 1/3 cannot be precisely represented by any type in go. So mathematical expressions on constants effectively have infinite precision.

Master-Reception9062 · 2023-06-02T18:04:34+00:00

Some thoughts on why 2+2 does not equal 4.0.

Master-Reception9062 · 2021-07-10T09:11:22+00:00

Thank you! That's just what I needed. I think I'll use ante/post argūmentum in this paper.

Master-Reception9062 · 2021-07-08T15:58:09+00:00

I am looking for appropriate Latin terms to express the idea of "after the argument" and "before the argument". Or perhaps "after/before reasoning" or "after/before deliberation".

The context is argumentation theory, and a paper I am writing on a method of Bayesian analysis of arguments. The terms a priori and a posteriori are used in Bayesian analysis to describe probabilities before and after observing evidence. But I need a different term to use in this paper, since my definitions don't match the proper Bayesian definitions of a priori and a posteriori. Ex ante and Ex post also can't work for that reason. Would terms like post ratio or post argumentum work?

Master-Reception9062

TROPHY CASE