Parametricity, or Comptime is Bonkers

It makes little difference in practice as I'm can just call a weird parametricity-breaking function both in Haskell, Rust, OOP langauges, Zig the same way in a call site where the type argument is known enough to resolve the trait/typeclass predicate/constraint.

Dunno, n=1 but I think this is a huge part of why I tend to find Rust so much more readable than (for example) Go or C#.

Yes, there's Any but in practice it tends to be used much less than reflection. Both because of culture, and because it's much more limited in scope (you can only test for concrete types, not trait membership). And, because it is a trait that you need to ask for… any code using it stands out with a clear "weird stuff is going on here" smell.

Standard ML has nothing like Haskell's Typeable or Rust's Any, and that's a good thing!

You can use exceptions as the underlying representation of a universal type, but it's fundamentally different from a Haskell existential wrapper around Typeable in a very important way:

• In Haskell, every type has a unique, global, canonical Typeable instance.

• In SML, you must explicitly and manually construct the injections and projections into/from your universal type. These injections and projections have a bounded scope like any other SML values. And every time you construct an injection-projection pair, it's different from all previous ones.

For example, if foo_inj and bar_inj are different injections int -> univ, and foo_proj and bar_proj are the corresponding projections univ -> int option, then bar_proj (foo_inj 42) evaluates to NONE, even though foo_proj (foo_inj 42) and bar_proj (bar_inj 42) would both evaluate to SOME 42.

Using such universal types is still a very bad idea in general, but at least SML limits the amount of damage to modularity that you can inflict with them.

It's also easily broken ... Haskell has Typeable

Is what sense do you mean that Typeable breaks parametricity?

What? You can return any value that is of type T so any operation that would be op(a: T,...) -> T would be valid, no? I don't see how it follows that the only valid operation is the identity function.

But it is a completely generic T so you cannot do any operations on it. You can't construct a fresh T object, you can't modify the given ones because you don't know what sort of operations you have available.

Edit: Ok everyone, thanks for the answers! Seems like I'm too Python-brained because taking a type T clearly has a different meaning in Python (and some other languages with generics).

We're starting to feel this pain in Python, too, in fact. In Python, you will often take in a type parameter so that you can construct an instance of it:

class C:
    def __init__(self, x: int): ...

def foo(t: type[C]) -> C:
    return t(7)

Very similar to the Zig example from OP, but executed at runtime.

The issue is that there's no guarantee that every subclass of C will have a compatible constructor signature. In fact, it's very very common for subclasses to have different constructor signatures, since you almost certainly need additional parameters to initialize whatever state the subclass adds. But that breaks foo!

class D(C):
    def __init__(self, x: int, y: str): ...

# BOOM, raises a TypeError!
foo(D)

People have proposed several ways to fix this, but one of the easiest is to recognize that your function doesn't actually need to take in a type, it needs to take in a factory function that records specifically how you want to call it:

def bar(t: Callable[[int], C]) -> C:
    return t(7)

Python classes are callable, and so you can still pass in C, just like with foo. But a type checker can more easily see that D is not a valid argument, without having to change the rules about what type[C] means or whether you're allowed to have incompatible constructors in your subclasses:

# ok
bar(C)
# still raises TypeError, but a static type checker
# can detect that more easily
bar(D)

What? You can return any value that is of type T so any operation that would be op(a: T,...) -> T would be valid, no? I don't see how it follows that the only valid operation is the identity function.

The function has to valid for all T. You know nothing about T, other than that you have a value a that is of type T. So the only way to get a value of type T to return is to use the one that was given to you.

If you don't know anything about T then the only valid T that you can produce is a value that you were given. And the only value you were given is… a. (Or crashing.)

You can still have side effects, yes (the saying comes from the Haskell world where they're much more limited too), but similar ideas tend to translate decently well even there. If you don't know anything about T then you can't use anything about a to inform the side effect either, so why are you taking it at all?

any operation that would be op(a: T,...) -> T would be valid

Well, what operations can those other operations do to an arbitrary T with no bounds?

In new(ish) Python (newer than 3.5?), this would be something like

def mystery[T](arg: T) -> T:
    # What can we do here except return the arg?
    return arg

mystery(1)
mystery("test")

There are some standard library functions that can be used (copy.copy or setattr), but those are already "reflection-like" in a way.

Comptime is also less expressive than macros in some important ways. It can't change the evaluation order. It can't see expressions, only values. You can (almost) read zig functions as if they were written entirely in a strictly-evaluated dynamically-typed language with no staging. The staging only restricts you to the subset of those dynamically-typed programs that can be compiled efficiently.

Almost, because comptime zig is actually a slightly different dialect eg this works in comptime but is UB at runtime:

fn foo() *usize {
  var x: usize = 0;
  return &x;
}