5 ms·

Infinite.

quickthrower2 7y ago
3 things: 1. Call the function 2. error 3. infinite recursion Technically correct - there are infinite possible error messages.
- im3w1l 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
    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 7y ago
  You need to rethink your #1. How about calling the function derivative? Sounds like you could have used real documentation.
  - dllthomas 7y ago
    > How about calling the function derivative? How would you write this with no constraints on the types involved?
    - wellpast 7y ago
      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 7y ago
        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.
      - dllthomas 7y ago
        > 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.

Infinite.

3 things: 1. Call the function 2. error 3. infinite recursion Technically correct - there are infinite possible error messages.

im3w1l 7y ago
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 7y ago
  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 7y ago
    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 7y ago
  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 7y ago
You need to rethink your #1. How about calling the function derivative? Sounds like you could have used real documentation.
- dllthomas 7y ago
  > How about calling the function derivative? How would you write this with no constraints on the types involved?
  - wellpast 7y ago
    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 7y ago
      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.
    - dllthomas 7y ago
      > 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.