Restructuring the ForSyDe.Shallow API

[ugeorge]

Since the API is already structured as collections of modules, I fail to see why the module tree does not reflect that. Proposed structure:

ForSyDe.Shallow
  ForSyDe.Shallow.Core
    ForSyDe.Shallow.Core.Signal
    ForSyDe.Shallow.Core.Vector
    ForSyDe.Shallow.Core.AbsentExt
  ForSyDe.Shallow.MoC
    ForSyDe.Shallow.MoC.Synchronous
      ForSyDe.Shallow.MoC.Synchronous.Process
      ForSyDe.Shallow.MoC.Synchronous.Stochastic
    ForSyDe.Shallow.MoC.CT
    ForSyDe.Shallow.MoC.Untimed
    ForSyDe.Shallow.MoC.Dataflow
    ForSyDe.Shallow.MoC.SDF
    ForSyDe.Shallow.MoC.DomainInterface
    ForSyDe.Shallow.MoC.MoCInterface
  ForSyDe.Shallow.Utility
    ForSyDe.Shallow.Utility.DFT
    ForSyDe.Shallow.Utility.Memory
    ForSyDe.Shallow.Utility.Queue

Should this structure be in the next release?

[ingo-sander]

I agree with this. But how is it now?

[joseedil]

Seems good.

@ingo-sander, currently every module is under the same flat ForSyDe.Shallow hierarchy level.

[ugeorge]

Good, I will proceed on it immediately. The changes do not break the current API, it is only the internal structure which changes, since everything IS exported by ForSyDe.Haskell. According to the Haskell PVP decision tree only the minor version will need to increase, so let us add this to the 3.3.2.0 milestone.

Also, we may take advantage of the API to hide currently un-exported or hidden functions. E.g. delayCT may still be exported by ForSyDe.Shallow.MoC.CT, but hidden by ForSyDe.Shallow.MoC. Thus a user would need to explicitly import ForSyDe.Shallow.MoC.CT to be able to use delayCT, but will not be necessary to load the file (which is hidden anyway if installed via Hackage).

[ugeorge]

@ingo-sander I propose not exporting ForSyDe.Shallow.Utility. The utilities are not part of the core library, and would just mean additional loading time for someone who is not using them. I think they should be imported separately.

Of course, this would mean an API-breaking change and thus the version would become 3.4.0 instead of 3.3.2

[ingo-sander]

I agree with you! The user should explicitly import ForSyDe.Shallow.Utility. Hopefully the library will soon grow...

[ugeorge]

@ingo-sander I've noticed that out of all the utility libs ForSyDe.Shallow.Utility currently only re-exports only:

ForSyDe.Shallow.Utility.DFT
ForSyDe.Shallow.Utility.Memory
ForSyDe.Shallow.Utility.Queue

What happens with the rest, meaning:

ForSyDe.Shallow.Utility.FIR
ForSyDe.Shallow.Utility.FilterLib
ForSyDe.Shallow.Utility.Gaussian
ForSyDe.Shallow.Utility.PolyArith

? Am I supposed to leave them be, i.e. the user should load them individually, or should they be re-exported by ForSyDe.Shallow.Utility as well?

Another possibility would be that ForSyDe.Shallow.Utility does not exist at all (does not re-export anything), and the user only imports the modules she needs, one by one.

[ingo-sander]

@ugeorge Difficult: It seems that FIR includes firSY, so it seems to be a synchronous process. So, I need to look closer on this errand.

[ingo-sander]

@ugeorge This requires a clearly better understanding. For now, leave it as it is. Thus do not export FIR, FliterLib, Gaussian and PolyArith. We need to think this through before version 3.5.0.

[joseedil]

Just a quick update, I confirm forsyde-shallow is coming throught cabal install, even on the problematic install of Arch Linux.

By the way, @ugeorge, which distro are you using?

[ugeorge]

Ubuntu 16.04 and 14.04 (personal and lab VM). Travis is using Ubuntu AFAIK, and I'm not sure about Hackage Matrix. Anyway, the Shallow library should be covered since it mostly uses safe dependencies.