i remember being in a situation where i had to find a's type via _ a because a :: _ did not work. but now i do not understand how this could ever be necessary and start to doubt my memory. it drives me crazy.
i remember being in a situation where i had to find a's type via _ a because a :: _ did not work. but now i do not understand how this could ever be necessary and start to doubt my memory. it drives me crazy.
_ is a typed hole, which should provide you with inferred type and suggestions for possible values - it should work in all circumstances where a's type can be inferred by itself :: _ annotation on the other hand is actually something that can be accepted by the compiler in some forms given the right extension - the fact that it tells you about possible type is more of a side effect I guess
i remember being in a situation where i had to find a's type via _ a because a :: _ did not work. but now i do not understand how this could ever be necessary and start to doubt my memory. it drives me crazy.
_ is a typed hole, which should provide you with inferred type and suggestions for possible values - it should work in all circumstances where a's type can be inferred by itself :: _ annotation on the other hand is actually something that can be accepted by the compiler in some forms given the right extension - the fact that it tells you about possible type is more of a side effect I guess
you are not answering my question or do i misunderstand you?
What I think Matt is saying is that if you have e.g. "use inferred types" enabled, writing a :: _ might successfully infer a type and not give you an error saying what it is.
_ is a typed hole, which should provide you with inferred type and suggestions for possible values - it should work in all circumstances where a's type can be inferred by itself :: _ annotation on the other hand is actually something that can be accepted by the compiler in some forms given the right extension - the fact that it tells you about possible type is more of a side effect I guess
you are not answering my question or do i misunderstand you?
I was trying to say that a :: _ may not be a "supported" feature in general
Not sure about concrete cases where it may not work - maybe you were accidentally using it without parens? E.g., a $ b :: c gets parsed as (a $ b :: c) instead of a $ (b :: c), which may not be what you want
i remember being in a situation where i had to find
a
's type via_ a
becausea :: _
did not work. but now i do not understand how this could ever be necessary and start to doubt my memory. it drives me crazy.rednaZ said:
_
is a typed hole, which should provide you with inferred type and suggestions for possible values - it should work in all circumstances wherea
's type can be inferred by itself:: _
annotation on the other hand is actually something that can be accepted by the compiler in some forms given the right extension - the fact that it tells you about possible type is more of a side effect I guessrednaZ said:
where
a
is any expression.TheMatten said:
you are not answering my question or do i misunderstand you?
What I think Matt is saying is that if you have e.g. "use inferred types" enabled, writing
a :: _
might successfully infer a type and not give you an error saying what it is.ah, thanks. i did not understand that.
but it is not the answer i was looking for. even with
PartialTypeSignatures
it will still generate a warning.Ah, yes, thanks @Georgi Lyubenov // googleson78
rednaZ said:
I was trying to say that
a :: _
may not be a "supported" feature in generalNot sure about concrete cases where it may not work - maybe you were accidentally using it without parens? E.g.,
a $ b :: c
gets parsed as(a $ b :: c)
instead ofa $ (b :: c)
, which may not be what you want