Oh I see. I didn't noticed the Basic.toString. This is the only function in
Elm that accepts anything anyway. If you swap that particular function to
anything else it cannot work.
On Friday, January 20, 2017 at 5:41:48 PM UTC+1, Martin Cerny wrote:
>
> 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.
