Compile-time constraints for strings in F#, similar to Units of Measure - is it possible?

Question

I'm developing a Web application using F#. Thinking of protecting user input strings from SQL, XSS, and other vulnerabilities.

In two words, I need some compile-time constraints that would allow me discriminate plain strings from those representing SQL, URL, XSS, XHTML, etc.

Many languages have it, e.g. Ruby’s native string-interpolation feature #{...}.
With F#, it seems that Units of Measure do very well, but they are only available for numeric types.
There are several solutions employing runtime UoM (link), however I think it's an overhead for my goal.

I've looked into FSharpPowerPack, and it seems quite possible to come up with something similar for strings:

[<MeasureAnnotatedAbbreviation>] type string<[<Measure>] 'u> = string
// Similarly to Core.LanguagePrimitives.IntrinsicFunctions.retype
[<NoDynamicInvocation>]
let inline retype (x:'T) : 'U = (# "" x : 'U #)
let StringWithMeasure (s: string) : string<'u> = retype s

[<Measure>] type plain
let fromPlain (s: string<plain>) : string =
    // of course, this one should be implemented properly
    // by invalidating special characters and then assigning a proper UoM
    retype s

// Supposedly populated from user input
let userName:string<plain> = StringWithMeasure "John'); DROP TABLE Users; --"
// the following line does not compile
let sql1 = sprintf "SELECT * FROM Users WHERE name='%s';" userName
// the following line compiles fine
let sql2 = sprintf "SELECT * FROM Users WHERE name='%s';" (fromPlain userName)

Note: It's just a sample; don't suggest using SqlParameter. :-)

My questions are: Is there a decent library that does it? Is there any possibility to add syntax sugar?
Thanks.

Update 1: I need compile-time constraints, thanks Daniel.

Update 2: I'm trying to avoid any runtime overhead (tuples, structures, discriminated unions, etc).

Cassity

See blog.moertel.com/articles/2006/10/18/… for an interesting Haskell take on the problem. – Kero

Well, if you do try to implement this, I'd be interested to see it! – Pu

@kvb, your link seems to become dead... let me put a working link just for myself :) blog.moertel.com/posts/… – Mussel

Answer 1

A bit late (I'm sure there's a time format where there is only one bit different between February 23rd and November 30th), I believe these one-liners are compatible for your goal:

type string<[<Measure>] 'm> = string * int<'m>

type string<[<Measure>] 'm> = { Value : string }

type string<[<Measure>] 'm>(Value : string) = struct end

Warrin

Thank you for the answer, but the first one forces constructing a Tuple<_,_>, and the latter ones are actually struct's. I'm trying to avoid any runtime overhead. – Cassity

Answer 2

In theory it's possible to use 'units' to provide various kinds of compile-time checks on strings (is this string 'tainted' user input, or sanitized? is this filename relative or absolute? ...)

In practice, I've personally not found it to be too practical, as there are so many existing APIs that just use 'string' that you have to exercise a ton of care and manual conversions plumbing data from here to there.

I do think that 'strings' are a huge source of errors, and that type systems that deal with taintedness/canonicalization/etc on strings will be one of the next leaps in static typing for reducing errors, but I think that's like a 15-year horizon. I'd be interested in people trying an approach with F# UoM to see if they get any benefit, though!

Dahlberg

Maybe I don't fully understand it, but what would a UoM approach to this provide beyond wrapper classes with validation? The level of type safety seems the same but the latter is (currently) much easier to implement. – Worked

Daniel: The reasons are very similar to those for numeric types. UoM prevent accidental mixing variables having different purposes yet stored as same runtime type. There's a perfect explanation of "code smell" problem, written by Joel joelonsoftware.com/articles/Wrong.html – Cassity

I understand not wanting to mix different string types, but you could achieve that various ways (wrapper classes, etc). I'm just not clear on the advantage of the UoM approach to this. – Worked

UoM can be made generic in ways wrappers cannot. And they are erased, so no runtime cost. Do you see an advantage to UoM for numeric code? The same advantages apply; you could write struct wrappers around floats for kilograms and seconds, but UoM are superior. I think? Right? – Dahlberg

Answer 3

The simplest solution to not being able to do

"hello"<unsafe_user_input>

would be to write a type which had some numeric type to wrap the string like

type mystring<'t>(s:string) =
    let dummyint = 1<'t>

Then you have a compile time check on your strings

Swaine

I would suggest using a struct instead of a class, to avoid the (admittedly) small overhead of the wrapper. – Stratocracy

Answer 4

It's hard to tell what you're trying to do. You said you "need some runtime constraints" but you're hoping to solve this with units of measure, which are strictly compile-time. I think the easy solution is to create SafeXXXString classes (where XXX is Sql, Xml, etc.) that validate their input.

type SafeSqlString(sql) =
  do
    //check `sql` for injection, etc.
    //raise exception if validation fails
  member __.Sql = sql

It gives you run-time, not compile-time, safety. But it's simple, self-documenting, and doesn't require reading the F# compiler source to make it work.

But, to answer your question, I don't see any way to do this with units of measure. As far as syntactic sugar goes, you might be able to encapsulate it in a monad, but I think it will make it more clunky, not less.

Worked

But your question mentions needing run-time constraints--thus the confusion. However, I attempted to address both possibilities. – Worked

Answer 5

You can use discriminated unions:

type ValidatedString = ValidatedString of string
type SmellyString = SmellyString of string

let validate (SmellyString s) =
  if (* ... *) then Some(ValidatedString s) else None

You get a compile-time check, and adding two validated strings won't generate a validated string (which units of measure would allow).

If the added overhead of the reference types is too big, you can use structs instead.

Stratocracy

Thank you for the suggestion. The problem is that DU is a class, you cannot avoid constructing it. int<something> is actually an int at runtime, which makes no overhead at all. – Cassity