Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thinking about data contracts for inputs and outputs is pretty basic stuff. If you don't do that, how do you know what your code actually does?


They don't, but they're fast and fail often.


There's a gap between things it might make sense to consider as data contracts, and things that can be expressed in practical type systems in common use.

One example: a function which, when given a single element, returns a single transform of that element. When passed a list of elements, returns a map of that transform over the list. You can argue as to whether that's a good idea or not, but I've seen JS functions that make sense in context which do that.

This might just be my lack of type system expressivity knowledge, but how would one annotate the type of that function? I get that you could use a union type on the param and the return value, but not how you link the two.


> how would one annotate the type of that function

Some languages support function overloads like Swift and Kotlin.

    fn foo(input: A, xform: A -> B) -> B
    fn foo(input: [A], xform: A -> B) -> [B]
Hmm, maybe we can generalize that into a Functor.


Yes, this is very common in JS, and somewhat common in other popular dynamic languages. In TypeScript, for example, you'd implement this by defining several overloaded signatures. Note that this isn't C++ or Java, so you still have a single function implementing all of them - the various overloads just specify what happens depending on the arguments you pass.

https://www.typescriptlang.org/docs/handbook/functions.html#...

This is a limited approach, because the overloads aren't a part of a function type - i.e. you can't have an anonymous function value that is overload-typed, it must be a named function. In principle, a similar mechanism could be used for types as well, it just doesn't usually come up in that context (e.g. callbacks typically don't return different things), which is probably why they didn't do it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: