Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

[[ 🗃 ^yEzqv rel4tion-wiki ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

Tags

master :: projects / razom-basic-store / tickets /

1.mdwn

[[!template id=ticket class=task]] [[!tag /projects/razom-basic-store/decisions]]

[[!meta title=“Static vs dynamic”]]

Issue

Each backend can either be its own type, or a value of one common type.

The strength of the static approach seems to be that types can be verified and matched at compile time. For example, you can’t use one backend when connecting to an instance of the other backend. The strength of the dynamic approach seems to be that you can treat uniformly a mixed list of backends, and more can be added without modifying the existing code.

So far, I have seen many uses of the static approach, but only a single use of the dynamic one. Here’s some code to demonstrate:

Static:

[[!format hs """ class Datastore d where write :: d -> [Statement] -> IO () read :: d -> IO [Statement]

instance Datastore X where write = {- … -} read = {- … -}

instance Datastore X where write = {- … -} read = {- … -}

instance Datastore X where write = {- … -} read = {- … -} """]]

Dynamic:

[[!format hs """ data Datastore = Datastore { write :: [Statement] -> IO () , read :: IO [Statement] }

x :: Datastore x = Datastore { write = {- … -} , read = {- … -} }

y :: Datastore y = Datastore { write = {- … -} , read = {- … -} }

z :: Datastore z = Datastore { write = {- … -} , read = {- … -} } """]]

Decisions

None yet.

[See repo JSON]