Changes between Version 52 and Version 53 of SafeHaskell


Ignore:
Timestamp:
Jun 7, 2011 8:02:43 PM (3 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 ==