newtype and access control

Hello everyone, I am watching a talk on YouTube calledWrangling Monad Transformer Stacks. The talk has the following code: code{-# LANGUAGE GeneralizedNewtypeDeriving -#} module DBTrans where newtype WithTrans a = WithTrans (WithDBConn a) deriving (Functor, Applicative, Monad) inDBTrans :: WithTrans a -> WithConn a inDBTrans = ... NOT USING MIXMAX YET? The speaker mentions that by using a newtype, we can perform "access control". The functioninDBTrans is "aware" that the type constructorWithTrans is simply a wrapper forWithDBConn, and that functions outside of the module are not privy to that information. Out of necessity, the speaker has to assume a certain level of Haskell knowledge that I don't have, because I am confused as to what language principles would allow forinDBTrans to be used for access control. I understand that a newtype declaration does create a new type from a "type safey" point of view; that a newtype declaration is required to have a single data constructor with a single (not named) field; and that, once the type-checking is done, the compiler can strip out the newtype wrapper and leave the underlying type (informally speaking, of course), but that still doesn't get me toinDBTrans can do access control. Thank you for any help! Steven Leiva 305.528.6038 leiva.steven@gmail.com http://www.linkedin.com/in/stevenleiva

On Sun, Oct 29, 2017 at 7:52 PM, Steven Leiva
Out of necessity, the speaker has to assume a certain level of Haskell knowledge that I don't have, because I am confused as to what language principles would allow for *inDBTrans* to be used for access control.
As presented, that doesn't seem to be true. If the module exported only the type constructor, then it would be impossible for other modules to pattern match it and access the wrapped value. But the module has no export list, so it exports everything including the data constructor and modules can pattern match to unwrap it; the only other way to get that kind of isolation is for the wrapped data type to not be in scope, but that also doesn't seem to be the case. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Hi Brandon,
I think that exporting the data constructor was a simple oversight. I can
definitely see how, if you don't export the data constructors, other
modules can't pattern match on the newtype value and therefore can't "get
at" the WithDBConn a value.
Thank you!
On Oct 29, 2017 7:58 PM, "Brandon Allbery"
On Sun, Oct 29, 2017 at 7:52 PM, Steven Leiva
wrote: Out of necessity, the speaker has to assume a certain level of Haskell knowledge that I don't have, because I am confused as to what language principles would allow for *inDBTrans* to be used for access control.
As presented, that doesn't seem to be true. If the module exported only the type constructor, then it would be impossible for other modules to pattern match it and access the wrapped value. But the module has no export list, so it exports everything including the data constructor and modules can pattern match to unwrap it; the only other way to get that kind of isolation is for the wrapped data type to not be in scope, but that also doesn't seem to be the case.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (2)
-
Brandon Allbery
-
Steven Leiva