News for hackers. Stuff that matters.
Re:Implement with Types, Not Your Brain by im3w1l on Tuesday June 25, 2019 @08:01PM (#20280573)
It's my understanding that we have to involve a function call as a fallback, as a function call is the only way we have of producing a value of type c in the general case.

But we could potentially have some list of exceptions.

So one valid implementation would be: If c is string we always return hello world elseif a, b and c are integers we add the two ints. Elseif a and b are the same type we call the function with the argument order swapped. And finally, if none of these are the case, we call call the function with the arguments.

Re:Implement with Types, Not Your Brain by danharaj on Tuesday June 25, 2019 @08:10PM (#20280642)
In a type system like Haskell's, a function with that signature has to be unconditionally polymorphic in its variable types, so you can't have a list of exceptions.
Re:Implement with Types, Not Your Brain by dllthomas on Wednesday June 26, 2019 @03:59PM (#20288543)
If you do want to be able to list exceptions in Haskell, that's what Typeable gets you. But then the type signature is different.
Re:Implement with Types, Not Your Brain by Twisol on Tuesday June 25, 2019 @09:16PM (#20281021)
Types don’t exist at runtime in the way you’re describing. It isn’t possible to express a program that asks what type a value has.

Dynamic types are sometimes called “tags” to distinguish the case in which this information _does_ exist at runtime.