Hi,
thanks for the answer. I however think I am missing something here - why
wouldn't the compiler know what to give to the function? If I understand
Elm correctly, it does not create multiple instances of functions with type
variables for each type they are used with (as C++ would do). Instead Elm
acts akin to Java's type erasure: there is only one copy of a generic
function and it is supposed to handle any input (and Elm indeed generates
only one copy of the function). So in your example, all 'c.convert'
functions accept anything (so the "foo" string is not a problem) and return
an X so the result is 'List X'.
Or is this just a quirk the current Elm compiler implementation?
Thanks
Martin
On Friday, 20 January 2017 16:56:23 UTC+1, Maxime Dantec wrote:
>
> Imagine a list of `Convertor a` like this :
>
> convertors : List (Convertor x)
> convertors =
> convertor1 :: convertor2 :: []
>
> mapConvertors = List.map (\c -> c.convert "foo") convertors
>
>
> You can see here, that you cannot map over `Convertor::convert` if you
> don't know what to give to the function.
>
> Is it clear ? I can be more thorough if you want.
>
>
> On Friday, January 20, 2017 at 12:06:49 PM UTC+1, Martin Cerny wrote:
>>
>> Hi all,
>> I was trying to do some Elm Voodoo and I stumbled upon a funny thing. It
>> is probably deeply wrong, but I want to understand why it is wrong :-)
>>
>> What I was trying to do was to define a type like this:
>>
>> type alias Convertor a =
>> { convert : b -> a
>> }
>>
>>
>> Here I get "Type alias `Convertor` must declare its use of type variable
>> b"
>> Now, I understand, why you cannot have
>>
>> type alias X a = { field1: a, field2: b }
>>
>> But with the source type of functions, things are IMHO different than
>> with values. You cannot write values of unbound types and you could not
>> decide whether two instances of X are really the same type.
>> But you can easily write functions that have unbound source types - like
>> this one:
>>
>> convertString: a -> String
>> convertString x =
>> (toString x) ++ "_Foo"
>>
>>
>> And since all of functions with this signature really have the same type
>> at JavaScript level, two instances of 'Convertor a' would always had the
>> same type.
>>
>> Now if I had
>> c: Convertor String
>> c = {convert = convertString}
>> the whole thing seems type-safe...
>>
>> So my question is:
>> Is this syntax forbidden, because it is an obscure feature that is not
>> worth supporting, or would this syntax really allow for some type unsafe
>> code?
>>
>> Thanks!
>>
>> Martin
>>
>>
>>
--
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.
