In a continuous effort to enhance your experience using FPish, we recently rolled out a few changes to the website. Here is a change list:

• Blog comments. You can now add comments to blog entries, both entries hosted on FPish (like this one!) and aggregated from users' personal blogs.
  
  Since we received very positive feedback on the hierarchical format used in the Question and Answers section, we decided to use the same system for blog comments. Replies are nested in nice, foldable boxes that make it easy to follow the flow of a discussion.
  
  You can also note that comments on your blog entries and responses to your blog comments are notified next to the "Blogs" menu entry.


• Tweet buttons. You have probably noticed it being here since last week: just about every relevant item on FPish now has a "Tweet" button: blog entries, questions, answers, events, courses.


• Minor fixes:
  
  • Grab the correct URL for some blog feeds where the url of the feed was used instead of the actual article URL.
  • No course outline was saved when a talk proposal was accepted (reported by Ryan Riley).

Don't hesitate to give feedback in the comments here or report bugs in the issue tracker.

Since the beginning FPish has allowed Authors to aggregate their blogs. This functionality is an excellent way for us to provide all users with a feed of quality articles about the functional world.

We are now going one step further by providing Authors with the capability to write blog articles directly on FPish. And what better way to announce this functionality than with a short blog post on FPish? :)

In order to write a new blog post, you can go to your dashboard. Under the "Blog entries" tab, you now have a "Write a new article" link. The FPish blogs use the same HTML-like markup language as the FPish Questions and Answers.

Remember that in order to use the blog functionality, you need to be registered as a FPish Author. You can register for such an account on the FPish homepage.

Note that this functionality is still in its infancy, and extra features such as commenting are scheduled.

The WebSharper Extensions for Bing Maps has been updated to reflect the last changes in the 7.0 API. Here is a list of additions:

• A new "modules" API which allows you to create extension modules for Bing Maps. This also comes with the three following built-in modules.
  
  • Directions: This is a simplified API to access the Routes REST API. It provides a very convenient interface, with attractive features such as draggable waypoints which trigger a recalculation of the route, and clickable instructions which causes the map to zoom on the corresponding location.
  • We advise you to only use our previously existing interface to the Routes REST API if you want to use it without displaying a map.
    Traffic: This simple class allows you to display traffic information as a layer on the map.
  • VenueMaps: This API provides precise information about buildings surrounding an area, and draws their ground footprint on the map.
• A new "strokeDashArray" property for polylines and polygons which allows you to use dashed lines. The WebSharper extension use an array of integers to represent the list of dash lengths more safely than the string used by the JavaScript API.

To demonstrate the simplicity of these new APIs, here is the code for a map allowing the user to search for a route between two locations.

open IntelliFactory.WebSharper.Bing
open IntelliFactory.WebSharper.Bing.Directions

[<JavaScript>]
let MapWithRouteRequest () =
    let origin = Input []
    let destination = Input []
    let button = Input [Attr.Type "button"; Attr.Value "Request route"]
    let answer = Div [Id "answer"]
    let mapContainer =
        Div []
        |>! OnAfterRender (fun el ->
            let opts = MapOptions(Credentials = "Your Bing maps developer key",
                                  Width = 600,
                                  Height = 500)
            let map = Map(el.Body, opts)
            map.SetMapType(MapTypeId.Road)
            let onDirsLoaded() =
                let dirman = DirectionsManager(map)
                let request (_:Element) (_:Events.MouseEvent) =
                    dirman.ResetDirections()
                    dirman.AddWaypoint
			<| Waypoint(WaypointOptions(Address = origin.Value))
                    dirman.AddWaypoint
			<| Waypoint(WaypointOptions(Address = destination.Value))
                    dirman.SetRenderOptions
			<| DirectionsRenderOptions(ItineraryContainer = answer.Body)
                    dirman.SetRequestOptions
			<| DirectionsRequestOptions(DistanceUnit = DistanceUnit.Kilometers)
                    dirman.CalculateDirections()
                button |>! OnClick request |> ignore
            Maps.LoadModule("Microsoft.Maps.Directions", LoadModuleArgs(onDirsLoaded))
        )
    Div [mapContainer
         Span[Text "From:"]; origin
         Span[Text "To:"]; destination
         button
         answer]

The updated extension for Bing Maps can be downloaded at this address.

The demoscene is a computer subculture focused on the creation of demos: short real-time animations showcasing a wide variety of technologies. Among these, web technologies have been getting increasing interest during the last months. DemoJS is an example of this interest: it is a demoparty (a demoscene meeting and competition) that was co-organized by Mozilla Labs in Paris on the 2nd and 3rd of July.

Color the Wind is a demo that was developed with WebSharper and presented at DemoJS. It uses the HTML5 Canvas element with a 2D context.



Color the Wind was created in just a few hours, and took the sixth place in the competition. You can have a look at the F# source code at this address.

We are happy to present to you the first game coded using WebSharper. It is a translation from one of O3D's biggest samples: the snooker.



This WebSharper snooker is on par with its JavaScript counterpart in terms of game speed, showing the performance of our generated code. But the source code is actually about 25% shorter than the original. Moreover, the extra safety brought by F# and WebSharper would have made its development easier and faster.

Why is it safer?

When we developed the WebSharper bindings to O3D, we brought a few modifications which added some extra safety.

First, mathematical operations on vectors, matrices and quaternions are more strongly typed. Indeed, while the JavaScript API uses arrays to represent these data types, we use tuples. Therefore the number of elements is always known. For example, if you try to compute the dot product of two vector of different sizes (using o3djs.math.dot) in JavaScript, it will silently return an erroneous value. However, in WebSharper, the error is detected at compile time by the type system, because there is no overload on O3DJS.Math.Dot taking two tuples of different sizes.

Another element that makes O3D in JavaScript unsafe is its use of methods whose return type depends on the arguments. An example is Pack.createObject. It takes a string designating a type, and returns an object of the given type. In WebSharper, there is an appropriately typed version of this method for each possible return type. So instead of:

var material = pack.createObject('o3d.Material');

You would write:

let material = pack.CreateMaterial()

This makes its use a lot safer, and eliminates the risk for hard-to-find bugs due to typos in the string.

Why is it shorter?

When we translated the snooker to WebSharper, we modified it to a more idiomatic functional style. For example, a loop like the following in JavaScript:

for (i = 0; i < arr.length; ++i)
{
  var element = arr[i];
  // do things with element
}

is written in F# as:

arr |> Array.iter (fun element ->
  // do things with element
)

This style makes it more immediately apparent that we are actually iterating over the elements of arr, and that no other criterion interferes with the control flow. As an appreciable extra, it makes the code shorter by several lines.



So, go ahead, try it and don't hesitate to have a look at the source!