You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 7, 2018. It is now read-only.
It seems like it is simply an alias for pure. But I encountered a situation where a type inference failed because of this. I had a component that wrapped another component (adding functionality on top) and where the inner component had a constant output (unused functionality of a connected piece of hardware). The following dumb code illustrates the issue:
moduleTestwhereimportCLaSH.PreludeimportCLaSH.Signal.Internal (signal#)
c1 i = (o1, o2)
where
o1 = register 0 i
o2 = signal 0-- Works:-- o2 = signal# 0
c2 i = (o1, o2)
where
(o1, o2) = c1 i
This fails with the following error:
Test.hs:15:9: error:
• Could not deduce (Applicative f0)
from the context: (Num a1, Num a, Applicative f)
bound by the inferred type of
c2 :: (Num a1, Num a, Applicative f) =>
Signal a1 -> (Signal a1, f a)
at Test.hs:(13,1)-(15,23)
The type variable ‘f0’ is ambiguous
• When checking that the inferred type
o1 :: forall a (f :: * -> *). (Applicative f, Num a) => Signal a1
is as general as its inferred signature
o1 :: Signal a1
In an equation for ‘c2’:
c2 i
= (o1, o2)
where
(o1, o2) = c1 i
Failed, modules loaded: none.
As noted in the example code, using a less general version of signal solves the issue and correctly infers the type of the functions.
Does it serve a purpose that signal is this general? We already have pure anyway, and in which case would you use a function called signal to create something different than a Signal? :-) Perhaps there is a totally valid reason to do it like it is now, but I'd like to point out that it can force people to add type declarations where type inference could otherwise do a fine job.
The text was updated successfully, but these errors were encountered:
The function
signal
currently has the type:It seems like it is simply an alias for
pure
. But I encountered a situation where a type inference failed because of this. I had a component that wrapped another component (adding functionality on top) and where the inner component had a constant output (unused functionality of a connected piece of hardware). The following dumb code illustrates the issue:This fails with the following error:
As noted in the example code, using a less general version of
signal
solves the issue and correctly infers the type of the functions.Does it serve a purpose that
signal
is this general? We already havepure
anyway, and in which case would you use a function calledsignal
to create something different than aSignal
? :-) Perhaps there is a totally valid reason to do it like it is now, but I'd like to point out that it can force people to add type declarations where type inference could otherwise do a fine job.The text was updated successfully, but these errors were encountered: