I would say not type checking your example is correct behavior. Since all 
occurrences of a type parameter have to resolve to the same type, the value 
of test is not defined if b resolves to anything other than String. And 
thus the compiler expects you to say it is a string. To be more specific, 
if your code would compile, the following would also compile, which is bad:

intToString: Int -> String
intToString a = 
  "Value:" ++ (toString a)

err: Int->Int
err =
  test (Specific intToString)

showError:Int
showError =
  err 5  --Now I am casting a string "Value:5" to int.
 

Martin




On Thursday, 16 February 2017 12:31:25 UTC+1, Rupert Smith wrote:
>
> Related to what I looked into with extensible records, I was also curious 
> as to how strict the typing of case statements is. So I tried this:
>
> type Val a b
>     = General (a -> b)
>     | Specific (a -> String)
>
>
> test : Val a b -> (a -> b)
> test val =
>     case val of
>         General func ->
>             func
>
>         Specific func ->
>             func
>
> Should this not type check? test is returning a function which will accept 
> any type and will prouce some other type that we know nothing about. "a -> 
> String" is a more specific instance of such a function, so should type 
> check as "a -> b"?
>
> Is the case statement typing too strict in requiring an exact match of all 
> its branches? Could it not work by calculating the most general unifier of 
> its branches and assume that type? MGU of a->b and a->String is a->b as it 
> is the minimal thing that unifies with both.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to