On: Implement with Types, Not Your Brain

[quickthrower2]

3 things:

1. Call the function 2. error 3. infinite recursion

Technically correct - there are infinite possible error messages.

[im3w1l → quickthrower2]

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.

[danharaj → im3w1l]

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.

[dllthomas → danharaj]

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.

[Twisol → im3w1l]

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.

[wellpast → quickthrower2]

You need to rethink your #1.

How about calling the function derivative?

Sounds like you could have used real documentation.

[dllthomas → wellpast]

> How about calling the function derivative?

How would you write this with no constraints on the types involved?

[wellpast → dllthomas]

I hope you're not suggesting that it's impossible to write this function without such constraints. If so, you should jettison your PL as fast as you can.

In any case this is precisely the trouble I believe the typer enthusiast get into. You can keep pulling this yarn, refining your types to match the world as it exists today; meanwhile the dynamic typers forgot about this function days ago and are eating your lunch in productivity.

[dllthomas → wellpast]

> I hope you're not suggesting that it's impossible to write this function without such constraints.

To be concrete about it, that's exactly what I'm suggesting.

Please demonstrate, in any programming language, a derivative function that is parametrically polymorphic - that is, the same machine code will handle absolutely any type that's thrown at it - floating point, integral, string, function, map, set, graph, etc. I do not believe it's possible, unless you have some very different notion of derivative in mind. I would be delighted to learn it is possible, and mildly pleased to learn of a reasonable use of the phrase "derivative function" that's other than what I'm thinking and which makes sense of what you've written above.

[dllthomas → wellpast]

Or... other people working in other languages you (obviously) don't understand have their own effective ways of working which you also don't understand.

It's a lesson that could be better understood by parts of the Haskell community, to be sure, but it's not always clear how useful a tool can be when you don't really know how to use it.

And here, you have repeatedly shown that you really don't know what you're talking about - take the opportunity to learn.