Group items tagged

There's much excitement about JDK 7 and in particular Lambdas! I've waded through the bloat to help you get an understanding of it. If you search for JDK 7 in your favourite search engine the chances are you'll hit the controversies surrounding lambadas in Java fairly early on in your hunt. It's a contentious subject, which means it's getting a lot of attention from a lot of clever people, but this in turn makes the process slow and adds difficulty in making decisions. My take is that lambdas will be in JDK 7 - you can see plenty of evidence of that around the web and in the snapshot builds. That said, no decision is concrete (which is a wise tip from The Pragmatic Programmer no less!). This article is aimed at those who don't know much about functional programming or what Lambdas, Closures or Currying are and want to get 'primed'.

ScalaModules is an open source project aimed at providing fluent support for OSGi to Scala developers. It takes advantage of Scala's infix operator notation, higher order functions, and implicit conversions. ScalaModules transparently uses the Scala compiler to wrap an OSGi BundleContext with its own RichBundleContext model. This general technique is not unusual for creating DSLs in mainstream languages. Sean McDirmid uses similar tricks for his C# Bling library for WPF, except that Bling must overcome the lack of C# offering comparable extensions to Scala.

In short, Joe argues, "Throughout, it became abundantly clear that TM, much like generics, was a systemic and platform-wide technology shift. It didn’t require type theory, but the road ahead sure wasn’t going to be easy." The whole blog post deals with how many implementation challenges platform-wide support for STM would be in .NET, including what options were considered. He does not mention Maurice Herlihy's SXM library approach, but refers to Tim Harris's work several times.

In functional programming, monadic characterizations of computational effects are normally understood denotationally: they describe how an effectful program can be systematically expanded or translated into a larger, pure program, which can then be evaluated according to an effect-free semantics. Any effect-specific operations expressible in the monad are also given purely functional definitions, but these definitions are only directly executable in the context of an already translated program. This approach thus takes an inherently Church-style view of effects: the nominal meaning of every effectful term in the program depends crucially on its type. We present here a complementary, operational view of monadic effects, in which an effect definition directly induces an imperative behavior of the new operations expressible in the monad. This behavior is formalized as additional operational rules for only the new constructs; it does not require any structural changes to the evaluation judgment. Specifically, we give a small-step operational semantics of a prototypical functional language supporting programmer-definable, layered effects, and show how this semantics naturally supports reasoning by familiar syntactic techniques, such as showing soundness of a Curry-style effect-type system by the progress+preservation method.

We consider the problem of specifying combinations of data structures with complex sharing in a manner that is both declarative and results in provably correct code. In our approach, abstract data types are specified using relational algebra and functional dependencies. We describe a language of decompositions that permit the user to specify different concrete representations for relations, and show that operations on concrete representations soundly implement their relational specification. It is easy to incorporate data representations synthesized by our compiler into existing systems, leading to code that is simpler, correct by construction, and comparable in performance to the code it replaces.

In ASP.NET development, F# also offers productivity advantages over VB and C#.  F# is different because it is statically checked and type-safe.  It addresses weaknesses in ASP.NET development like untyped values, complex form construction, and using strings for IDs and method names that connect markup with code-behind (class-files).  Writing a web application in F# on the WebSharper platform can be less-time consuming if a developer is not great at writing web apps in JavaScript.  Through WebSharper, developers can write a web app using a large subset of F# and .NET core libraries and then just let WebSharper map the code to JavaScript.  WebSharper can integrate with ASP.NET applications, but it is different from the standard approach because it builds applications from miniature web pages called "pagelets".  The pagelets correspond to functions on the client-side and they are automatically translated into JavaScript.   WebSharper supports a wide range of JavaScript libraries, making it easy for developers to optimize their code in whatever way they choose.  jQuery, qooxdoo, Flapjax, and Yahoo UI are all supported by WebSharper.  The leap from F# to JavaScript is manageable because both are functional languages that support lambda expressions and closures.  Another unique part of WebSharper is a "formlet".  A formlet is a special pagelet that provides form functionality.  Formlets in Web Sharper run and validate on the client, submitting their result to a either a client- or a server-side callback.