Geek Answers Handbook

Hierarchical module name for level programs

So let's say I wrote some level-level program in Haskell:

type family NAryFn (n::Nat) (dom::*) (cod::*) :: * type instance NAryFn Ze dom cod = cod type instance NAryFn (Su n) dom cod = dom -> NAryFn n dom cod

I think this is useful, and I want to use it throughout my project. So I put it in a module.

What would be a good hierarchical name for a module? (cf Haskell Hierarchical Modules )

Many data structures live in Data ( Data.Text , Data.List , etc.), various methods of structuring effects are in Control , for example, Control.Monad or Control.Applicative .

Where should programs work at the level level? Type ? TypeFamily ? Is consensus reached?

+6
source share
1 answer

I checked the hackers, and most packages that provide level-level functionality live in the Data hierarchy under Data.Type , Data.TypeLevel or the like, and sometimes Data.Number.Etc.TypeLevel . However, there are a few exceptions.

A package like a natural number lives under TypeLevel: http://hackage.haskell.org/package/type-level-natural-number

The tfp package lives under types: http://hackage.haskell.org/package/tfp

Several nicolas frisby packages live under the type: http://hackage.haskell.org/package/type-booleans and http://hackage.haskell.org/package/type-cereal , for example.

Thus, there is currently no consensus. Personally, I think Types is the right place for all of these things, but as usual with the Haskell community, it all ends with Data .

The dangers of a language where almost everything is second to none, I suppose :-)

You can see some, but not all, packages of type types in the "System Type" category during hacking: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:type%20system

+1
source

More articles:


All Articles