>
> toString and the equality operators are the only functions that take
> arguments of unspecified type and return a value with a fixed type
Except for functions that ignore their argument.
It's perfectly valid to do
intoInt : a -> Int
intoInt _ = 3
But it's probably not what you're looking for.
On Fri, Jan 20, 2017 at 11:20 AM, Nick H <falling.maso...@gmail.com> wrote:
> OK, I understand... you're up in the stratosphere somewhere :-)
>
> I can't offer anymore insight, but to back up Maxime. toString and the
> equality operators are the only functions that take arguments of
> unspecified type and return a value with a fixed type.
>
> On Fri, Jan 20, 2017 at 11:06 AM, Martin Cerny <cern...@gmail.com> wrote:
>
>> Thanks for the ideas, but neither is satisfactory for my (crazy and
>> contrived) use case :-)
>>
>> @Maxime:
>> Once again, I maybe missing something, but Basic.toString is not the
>> only function that does that. My particular aim was to combine native
>> functions and functions that simply ignore the parameter which are both
>> examples of functions that can accept anything.
>>
>> Also, more broadly you could have definitions such as:
>> type alias Mapper a =
>> { map : List b -> (b -> a) -> List a
>> }
>>
>> now - due to the erasing implementation of Elm, I can execute the map
>> function safely for any type of input as long as the first two parameters
>> match. Now this latter case would require the compiler to infer things like
>> m : Mapper Int
>>
>> x = m.map ["a" "b"]
>> --x: (String -> Int) -> List Int
>>
>> Which may and may not be the exact same thing the compiler already does
>> for regular functions.
>> There might even be a non-crazy use case for that :-)
>>
>> @Nick:
>> I am aware of that possiblity, but adding type variables is not an option
>> in my use case. I need to be able to call things like (highly contrived for
>> brevity),
>> func: Convertor a -> Int -> String -> (a,a)
>> func conv i s =
>> (conv.convert i, conv.convert s)
>>
>> which I could not do if I bind the type variable outside the individual
>> subexpressions.
>>
>> In case you are wondering why would I want such madness, I was toying
>> with the idea of having automatic serialization/deserialization (JSON/XML
>> etc.) of arbitrary non-function types (records and possibly also union
>> types) in almost pure Elm, with only a single magic native function. The
>> idea was like that:
>> --pure Elm type
>> type TypeInfo a = ...
>>
>> --JavaScript magic
>> getTypeInfo: a -> TypeInfo a
>>
>> --pure Elm
>> decoder: TypeInfo a -> Json.Decode.Decoder a
>>
>> However, I ended up requiring the functions of the aforementioned weird
>> form in TypeInfo a so it probably cannot work. I am aware of cases that
>> could not be solved in principle without help from compiler even if
>> everything worked as I hoped it would (and maybe there are other problems I
>> missed), but I had fun trying :-)
>>
>> Still curious, if this idea could work in general or if it implies some
>> problems for the whole type system...
>>
>> Thanks
>> Martin
>>
>>
>> On Friday, 20 January 2017 19:52:48 UTC+1, Nick H wrote:
>>>
>>> All type variables need to be mentioned on the left side of the type
>>> alias definition. But that doesn't mean you need to bind them. This
>>> compiles fine:
>>>
>>> type alias Convertor b a =
>>> { convert : b -> a
>>> }
>>>
>>> c: Convertor b String
>>> c = {convert = convertString}
>>>
>>> In other words, the unbound type variable needs to be mentioned in the
>>> type signature, even if you are wrapping more abstractions over it.
>>>
>>> On Fri, Jan 20, 2017 at 3:06 AM, Martin Cerny <cer...@gmail.com> 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 elm-discuss...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> 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 elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
