You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The new Internal module is marked as Trustworthy. #151
I'm not sure I agree. Simply renaming a module does not affect its safety - Safe Haskell is for a very narrow purpose, namely to ensure the user can trust the type system and abstraction facilities provided by the language, it doesn't encompass any broader notion of safety.
Subject to this, Safe Haskell provides the following guarantees for code compiled
in the safe language:
...
• Module encapsulation. Haskell provides an effective module
system that is used to control access to functions and data
types. In the safe language these module boundaries are strictly
enforced; a user of a module that contains an abstract data type
is only able to access or create values through the functions
exported.
which have been argued e.g. to make and keep GeneralizedNewtypeDeriving and Data.Coerce unsafe.
@phadej I think you might have a different interpretation of "Module encapsulation" than the intended one. Safe Haskell only promises that the semantics of abstraction are respected, it doesn't promise that you can't see the representation of a datatype by importing it from some other module.
@phadej I think you might have a different interpretation of "Module encapsulation" than the intended one. Safe Haskell only promises that the semantics of abstraction are respected, it doesn't promise that you can't see the representation of a datatype by importing it from some other module.
Fair.
It seems that this is not 100% clear. Data.Text.Internal is unsafe (or rather not explicitly marked to be anything, its haddock says it's Safe-Inferred but that is a bug in haddock), but Data.Set.Internal are Trustworthy.
It seems we shouldn't assume that Safe Haskell code (i.e. importing only safe or trustworthy) modules cannot violate any internal invariants of data types, because there can be trustworthy way to break them.
Activity
simonmar commentedon Oct 19, 2023
I'm not sure I agree. Simply renaming a module does not affect its safety - Safe Haskell is for a very narrow purpose, namely to ensure the user can trust the type system and abstraction facilities provided by the language, it doesn't encompass any broader notion of safety.
phadej commentedon Oct 19, 2023
@simonmar please bring this to the table at GHC steering committee. https://www.microsoft.com/en-us/research/wp-content/uploads/2012/01/safe-haskell.pdf says in section 3.1
which have been argued e.g. to make and keep GeneralizedNewtypeDeriving and
Data.Coerceunsafe.EDIT: the ghc issue https://gitlab.haskell.org/ghc/ghc/-/issues/8827 and https://gitlab.haskell.org/ghc/ghc/-/issues/8745
simonmar commentedon Oct 19, 2023
@phadej I think you might have a different interpretation of "Module encapsulation" than the intended one. Safe Haskell only promises that the semantics of abstraction are respected, it doesn't promise that you can't see the representation of a datatype by importing it from some other module.
phadej commentedon Oct 19, 2023
Fair.
It seems that this is not 100% clear.
Data.Text.Internalis unsafe (or rather not explicitly marked to be anything, its haddock says it's Safe-Inferred but that is a bug inhaddock), butData.Set.Internalare Trustworthy.It seems we shouldn't assume that Safe Haskell code (i.e. importing only safe or trustworthy) modules cannot violate any internal invariants of data types, because there can be trustworthy way to break them.