DEMO
Rendering a fractal using Fable

Rendering a fractal using Fable

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 
11: 
12: 
13: 
14: 
15: 
16: 
17: 

let render (canv:HTMLCanvasElement) = async {
  let ctx = canv.getContext_2d()
  let img = ctx.createImageData(U2.Case1 width, height)

  for x in 0 .. int width - 1 do
    for y in 0 .. int height - 1 do
      let x' = (float x / width * (snd w - fst w)) + fst w
      let y' = (float y / height * (snd h - fst h)) + fst h
      let it = countIterations palette.Length x' y'
      setPixel img x y width palette.[it]

    do! Async.Sleep(1)
    ctx.putImageData(img, 0.0, 0.0) }

match unbox (document.getElementById("go")) with 
| Some canv -> render canv
| None -> ()

Interesting aspects

Using nice F# features

• Async for background processing
• Option to handle missing element
• Integer and float numeric types

Interesting aspects

They behave in JavaScript way

• Async doesn't use background threads
• Option types are erased using nulls
• Computation uses JavaScript numbers

Option types

F# on .NET
An instance of Option<T> class

F# on JavaScript
Valid object or null value

Option types

Benefits
Can use pattern matching on JavaScript values!

Drawbacks
At runtime None == Some(null)

Numerical types

F# on .NET
A range of float, int, uint, etc.

F# on JavaScript
JavaScript numerical type

Numerical types

Benefits
Simulating full .NET behavior is hard!
Fable simulates integer / and %

Drawbacks
Numerical computations will differ

Asynchronous workflows

F# on .NET
Runs work items using thread pool

F# on JavaScript
Cooperative multi-tasking on single thread

Asynchronous workflows

Benefits
Can reuse code using familiar library
Strictly speaking satisfies the spec

Drawbacks
Lack of threads might cause deadlocks
Async.RunSynchronously unsupported

Unsafe downcasts

F# on .NET
Object type checked at cast point

F# on JavaScript
All checks delayed to member access

Unsafe downcasts

Benefits
Keep runtime manageable
Interop with native JS objects

Drawbacks
JavaScript-style error behaviour

Further semantic challenges

DEMO
Visualizing Whitehouse salaries

Visualizing Whitehouse salaries

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 
11: 
12: 
13: 
14: 
15: 
16: 
17: 
18: 

let enigma = "https://api.enigma.io/v2/data/<key>"
let whitehouse = enigma + "/us.gov.whitehouse.salaries.2016"
let schema = "https://vega.github.io/schema/vega-lite/v2.0.json"

let work () = async {
  let! res = Http.Request("GET", whitehouse + "/sort/name+/limit/20")
  let people = jsonParse(res)?result
  let spec = 
    { ``$schema`` = schema
      width = Some 800; height = Some 800
      data = { values = unbox people }
      mark = "bar"
      encoding = 
        { y = { field = "name"; ``type`` = "ordinal"}
          x = { field = "salary"; ``type`` = "quantitative"} } }
  vega.embed("#chart", spec, {actions = false}) }

work () |> Async.StartImmediate

Interesting aspects

Using nice F# features

• Asynchronous workflows for REST calls
• F# records and types calling Vega
• Dynamic operator for member lookup

Interesting aspects

They behave in JavaScript way

• Cannot wait and block an async
• Types serve merely as a façade
• Unchecked member lookup can fail

Façade F# records and interfaces

Importing the Vega library API

 1: 
 2: 
 3: 
 4: 
 5: 
 6: 
 7: 
 8: 
 9: 
10: 
11: 
12: 
13: 

type VegaData = 
  { values : obj[] }

type VegaSpec = 
  { ``$schema`` : string
    width : int option
    height : int option
    mark : string
    data : VegaData
    encoding : VegaEncoding }

type Vega =
  abstract embed : string * VegaSpec -> unit

Façade F# records and interfaces

Shallow targetting
.NET member calls compile as JS member calls

Deep targetting
Members could be compiled as lookup table

Inline JavaScript annotations

Defining global values and functions

1: 
2: 
3: 
4: 
5: 

[<Emit("vega")>]
let vega : Vega = failwith "JS only"

[<Emit("JSON.parse($0)")>]
let jsonParse<'R> (str:string) : 'R = failwith "JS Only"

Inline JavaScript annotations

Shallow targetting
Direct mapping to JS functionality

Deep targetting
Leads to unportable libraries

Dynamic object access and creation

Access any member dynamicaly

1: 
2: 

chart?size(768,480)?on("renderlet", fun chart ->
    (* do something *) )

Create empty object dynamically

1: 
2: 

let x = createEmpty<Size>
x.width <- 800

Dynamic object access and creation

Shallow targetting
Special handling of dynamic constructs

Deep targetting
Cannot create empty object

Undefined behaviour in C

Behaviour is left undefined not to allow optimisation, but as an inevitable consequence of two things. Firstly, the program containing it is an error—the language implementation is not required to support it. Secondly, no behaviour for detecting or handling the error can be prescribed in all cases.

Stephen Kell (2017)
Some Were Meant for C

Undefined behaviour

Leaves room for platform-specific implementation

• Fine properties of primitive types
• Anything involving null value
• "Unsafe" operations like casts
• What erroneous member access does

What is a language?

F# compiled to JavaScript breaks the spec!

• ... but not the spirit!
• It is safe thanks to JavaScript
• Well-behaved core code works
• Useful spec should be runtime-neutral

How can we compile one language to JVM, SQL, .NET, LLVM,
JavaScript, Squeak, GPUs, Arduino and other IoT platforms?

Allow some under-defined behavior

• Minimum for portability ("deep")
• A lot for integration ("shallow")

Escape hatches for good integration

• Explicit encoding of escape hatches ("deep")
• Dynamic language features ("shallow")
• Flexible or misusable object model ("shallow")
• Allow arbitrary unchecked effects ("shallow")

Discussion! & Questions?

Tomas Petricek, The Alan Turing Institute
tomasp.net | tomas@tomasp.net | @tomaspetricek