Changes between Version 52 and Version 53 of SafeHaskell


Ignore:
Timestamp:
Jun 7, 2011 8:02:43 PM (4 years ago)
Author:
dterei
Comment:

Add notes on symbol level safety

Legend:

Unmodified
Added
Removed
Modified
  • SafeHaskell

    v52 v53  
    280280 * Would be worthwhile modifying Hackage and Haddock to display Safe Haskell information.
    281281
     282== Symbol Level Safety ==
     283
     284The current design of !SafeHaskell only allows for safety to be specified at the module level. It may be worth while allowing safety to be specified at the symbol level. Such a design would probably look like this:
     285
     286{{{
     287{-# LANGUAGE Trustworthy #-}
     288module A where (
     289        safe: a,b,c,d
     290        unsafe: e,f,g
     291    )
     292
     293[...]
     294}}}
     295
     296In the current module level safety design we would have to design module A as follows:
     297
     298{{{
     299{-# LANGUAGE Safe #-}
     300module A where (
     301        a,b,c,d
     302    )
     303
     304[...]
     305
     306module A.Unsafe where (
     307        e,f,g
     308    )
     309
     310[...]
     311}}}
     312
     313Some points:
     314
     315 * Safety would be specified in the export list. This is in keeping with Haskell design, adding a safe or unsafe keyword (al la Java style) wouldn't.
     316 * These safe and unsafe keywords in an export list would only be allowed for modules marked as Trustworthy. Safe modules exporting unsafe functions don't make much sense.
     317
     318There are a few advantages to having this design over no symbol level safety:
     319
     320 * Easier to use !SafeHaskell with existing libraries as they don't need to split code into multiple modules now, simply change the export list.
     321 * Easier to use libraries that use SafeHaskell as now import declaration don't necessarily need to be changed. Just import the library module as a safe import and any unsafe symbols will be hidden.
     322 * We can also generate better error messages. If a code using a safe import of module A tries to call function 'e', then in the current design since 'e' is in a separate module that can't be imported we complain 'e' is unknown. With symbol level safety we would be able to fail instead saying that 'e' is an unsafe function that can't be used.
     323 * Symbol level design feels overall a little more elegant than the module level design. Especially when in some case module A would need to be split into 3 modules, module A.Imp that contains the whole implementation of A, module A that exports just the safe symbols, and module A.Unsafe that exports the unsafe symbols.
     324
     325There are some disadvantages though:
     326
     327 * More complex implementation.
     328 * More invasive language change. The current module level design for example is backwards compatible and compatible with other Haskell compilers as they will/can simply ignore the Safe and Trustworthy pragmas. Symbol level safety would break this. (OR actually we would need to change the above symbol design to have the safe and unsafe keywords in module export lists to be inside comments as pragmas... this makes them a little less elegant).
     329 * Easier to use can be thought of as a disadvantage as well. Modules are being split up due to their export of unsafe operations. Do we want to make it easier for unsafe operations to be used and exported?
     330 * Current module level design follows an establish idiom in the Haskell community and formalizes it.
     331 * Easier to visually audit code using the module level design.
     332
     333For the moment we are sticking with the module level design. Symbol level is a forward compatible extension to the module level design so we can revisit in the future.
    282334
    283335== Intended uses ==