Skip to content
This repository has been archived by the owner on Sep 7, 2018. It is now read-only.

Should signal be that general? #99

Open
DigitalBrains1 opened this issue Mar 15, 2017 · 1 comment
Open

Should signal be that general? #99

DigitalBrains1 opened this issue Mar 15, 2017 · 1 comment

Comments

@DigitalBrains1
Copy link
Member

The function signal currently has the type:

signal :: Applicative f => a -> f a

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:

module Test where

import CLaSH.Prelude
import CLaSH.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.

@christiaanb
Copy link
Member

I kept it general so that you could use signal for DSignal as well. I'm actually thinking of deprecating signal and just have people use pure.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants