The policy for JSLINQ is defined using .NET attributes. The following attributes in the module Jslinq.Types are available:
[<SecT("...")>]: Security Type Signature expressed as a string. Used on function declarations and class members. See below for more details.
[<Ignore>]: Used on modules. Does not perform a security type check on function declarations inside that module. Used to set up the framework for the type-checked code and the database policy, as the relevant part of it consists only of types.
[<Policy>]: Used on modules. Handles the module as part of the policy. This makes it mandatory that every declaration has a security type signature, since type inference is not used. Used for the library policy.
The syntax of security types is similar to F#'s own syntax for data types. Note the following important differences:
Base types are not distinguished and always written as _. Thus a function float -> int is written as _ -> _. A special case are WebSharper's Pagelet and Element types, which are also expressed as _.
Security levels can be actual levels (H, L) or variables ('a, 'foo etc.). They are written as raised expressions in the signature: _^H ->^L _^L. The syntax of the security type language (without variables) is presented in section 2 of the paper.
The use of security levels is optional. Unspecified levels result in an unconstrained fresh level variable. Thus _ -> _ is equivalent to _^'a -> _^'b.
The following example shows a simple declaration with security type annotation:
[<SecT("unit ->^L _^H)>]
let one () = 1
Note that unit does not support a level (since it does not contain any data) and how the low side effects for the function are expressed.