Project Restructuring v4.0.0

Here are the main proposals for restructuring the forsyde-shallow project and the satellite projects for the next major release (4.0.0). The new structure is partially inspired from the Haddock project.

At this point the current implementation of forsyde-shallow should be split into two packages forsyde-shallow, forsyde-shallow-library and forsyde-shallow-utils. For ease of maintenance and development, all packages, along with forsyde-shallow-examples should be located under the same repository at https://github.com/forsyde/forsyde-shallow (however, they are different possible HackageDB packages).

forsyde-shallow

Gathers all the other packages, contains all the build scripts, overarching test suites, CI & automation scripts, package documentation and whatnot. Similar to the haddock package, it does not export any module itself, but rather glues together other sub-packages. It shall follow the versioning number from the current forsyde-shallow project.

forsyde-shallow-library

Contains a (reduced) core library of the ForSyDe-Shallow project, i.e. all the modules that will be exported by ForSyDe.Shallow, along with relevant test suites. It may follow a new versioning. As it is part of a mature project, I propose starting from 1.0.0.0 rather than 0.1.0.0. Modifications from hereon will be strictly and thoroughly evaluated, and need to be justified.

Modules

• ForSyDe.Shallow.Core, (alternatively ForSyDe.Shallow.Types), represent the core types described by the ForSyDe methodology. That means Signal, AbstExt and Vector, and as of now that's it! The rest are merely container utilities used for convenience and inherit properties from these three.

• ForSyDe.Shallow.MoC, contains the MoC libraries currently implemented. A large audit needs to be performed on each and every module it currently holds.

  A ticked checkbox means that the module will be re-exported by ForSyDe.Shallow. Resolutions and decisions are commented after each module.

  • Adaptivity: Decide whether to keep it as part of the MoC library or move it to forsyde-shallow-utils.

    not discussed yet

  • CSDF: Update documentation. Decide whether an own MoC or as a sub-module of SDF sharing utilities and the delay process, which is identical.

    not discussed yet

  • CT: Needs major cleaning and documentation. According to my Atom research, it is not fully correct.

    not discussed yet

  • DF, formerly Dataflow: Needs to be validated. I need to read the paper and test this library. Discussion on usage is necessary.

    not discussed yet

  • Interface merging DomainInterface and MoCInterface: Needs cleaning and testing.

    not discussed yet

  • SADF: same as CSDF.

    not discussed yet

  • SDF: documentation and maybe restructuring.

    not discussed yet

  • SY, formerly Synchronous: drop Synchronous.Process and Synchronous.Stochastic which will be migrated to forsyde-shallow-utils.

    not discussed yet

  • UT, formerly Untimed: I am not sure whether it has been validated. Usage needs to be discussed and it needs some torough testing.

    not discussed yet

  • DT?: is a simplified version of CT, i.e. carrying values instead of functions, required? If so, implementing it should not be that difficult.

    not discussed yet

forsyde-shallow-utils

This package shall contain the design libraries with useful modeling blocks, helpers, utility functions and types. The development will be more liberal than its core counterpart. It can also follow its own versioning, starting from 0.1.0.0 (more of a beta than actual release at the moment).

Modules

• ForSyDe.Shallow.Data (name analogy to the Haskell Data "umbrella"), alternatively ForSyDe.Shallow.Container, collects all the useful types and type synonyms and associated functions/processes. As of today, here are the sub-modules which should reside here:

  A ticked checkbox means that the sub-module will be re-exported by the parent module. Resolutions and decisions are commented after each module.

  • BitVector

    not discussed yet

  • Matrix: type synonym for Vector (Vector a)

    not discussed yet

  • Cube: type synonym for Vector (Vector (Vector a))

    not discussed yet

  • Memory

    not discussed yet

  • Queue

    not discussed yet

• ForSyDe.Shallow.DSP contains commonly used DSP blocks, filter designs and window generators. Here a bunch of sub-modules can reside and the idea is that they should be imported altogether on-demand, i.e. import ForSyDe.Shallow.DSP (fir). Most existing blocks will be redesigned into a more generic form.

• ForSyDe.Shallow.PolyArith: I have no idea where it belongs to. It might create a module on its own...

• all the other modules and functions migrated from ForSyDe.Shallow.MoC should also find a place here. Maybe ForSyDe.Shallow.Blocks (very uninspired name...)

forsyde-shallow-examples

The examples package is currently a strange one... As it is right now it is not very maintainable since all examples depend on any slight modification of the previous two libraries. It is not extremely elegant either: e.g. importing ForSyDe.Shallow.Example.Heterogeneous.ASKTransceiver.Main is quite a mouthful! I propose this project to be a collection of minimal Stack/Cabal sandboxes paired with their appropriate dependency, and some documentation material. Sure, very small examples like TrafficLight or FibonacciRabbits can be grouped into one Schoolbook or GettingStarted project if needed... Yet any serious application like ASKTransciever, AESA, and future to come, needs its own environment.