Share via

Stop dysfunctional programming – Go for functional OO programming

  • Article

Greetings from POPL in Nice. J

Years back, I had to convince one of my previous bosses that the attendance of an ICFP conference can be reimbursed from the department’s budget. Despite his formal background and earlier activity in the programming-language arena he had meanwhile arrived at software architecture, and wasn’t too interested in programming languages, in general, not to mention functional programming, in particular, with Haskell certainly not showing up on his scale of interest. At some point in this conversation, I think, he was realizing that the natural opposite of ‘functional’ could be ‘dysfunctional’, and we therefore, kiddingly, decided that languages like Cobol, C++ and Java are dysfunctional. (I got reimbursed.)

In the past, I haven’t suffered, when I was occasionally exercising dysfunctional programming; Cobol is my favorite language of this kind, but that does not belong here. (I am not kidding BTW.) Then I joined Microsoft like 2 years back, perfectly willing to try out C#. In its recent addition, C# 3.0, one can engage in a good deal of non-dysfunctional programming. I have managed to apply C# 3.0-style functional programming to all kinds of different problems. 40 years after the invention of OO, I am ready to appreciate objects quite a bit because I can use them in combination with functional programming. Naturally, I call this mix functional OO programming. (I don’t quite count functional objects in C++ or ‘functors’ in Java, a misnomer BTW, as functional programming.)

Here is a bunch of related papers, that I have published very recently.

All of them exercise functional OO programming in one way or another.

· Functional OO Programming with Triangular Circles; presented at XML 2006: This paper is about the “XML objects” approach to XML-data binding or canonical X-to-O mappings. XML schemas are mapped to object models that provide typed views on objects for untyped XML trees. Then, LINQ-like functional OO programming can commence on the typed views. LINQ to XSD implements all these ideas, where typed views use LINQ to XML trees underneath.

· Style normalization for canonical X-to-O mappings; presented at PEPM 2007: This paper deals with some aspect of the provision of X-to-O mappings, i.e., normalization of schema-organization styles and its support by automated transformations. The actual implementation relies on the .NET Schema-Object Model (SOM), which, as described in the paper, can be spiced up by using generics and LINQ, thereby lifting levels of type safety and abstraction. Being a transformation adict, it is rewarding to see that functional OO programming applies to software transformations.

· API-based XML streaming with FLWOR power and functional updates; presented at XML 2006: This paper systematically develops the idea of enabling an in-memory XML API for streaming such that the streaming mode operates on serialized trees. Here we assume that the baseline API is declarative and convenient (such as LINQ to XML) while the streaming capability preserves this status. As a case study, we enable streaming for LINQ to XML. The normal FLWOR power of LINQ to XML is preserved. As an important byproduct, functional updates are introduced. This part really intriguied me because it helped me to understand that XQuery’s (complicated) Update facility is not the only way to go about XML transformations in a FLWOR setup.

· Scrap your boilerplate with XPath-like combinators; presented at POPL 2007: This is more of a Haskell paper continuing the theme “Scrap your boilerplate” (btw, also touched upon in the previous paper). However, the paper (and even more the slides that are also linked) touch upon XML programming in different setups (XSLT, DOM, LINQ to XML, Haskell, Prolog). My overall hope is that, some day, functional OO programming is ready to “scrap some boilerplate” in a mainstream language like Java or C#. See this paper as a recess if you got bored by the somewhat verbose C# notation for functional programming.

 

In the process of playing with C# 3.0 so much, I also realized that it will still take (quite) some time until a Haskell geek would be totally happy with C#. In fact, there is not just Haskell-like expressivity missing; the feature interaction with OO programming and LINQ’s focus on sequences (IEnumerables) makes you ask for unprecedented expressivity. Some of the items in the wish list below would be easy to add to C# 3.0; others are so demanding that you better do not hold your breath.

 

Ralf’s wish list for C# n.m with n >= 3

1. We really need a way (the VB way) of bringing static methods into scope.

2. Often LINQ could/should use function substitution rather than method chaining.

3. Coming from Haskell, I very much miss higher-kinded generics.

4. Not having a proper expression-level “let” is a pain in the neck.

5. LINQ syntax would also need to admit a “void” action for compositionality.

6. More “power in the dot”: members could be lifted implicitly to sequences.

7. We need extension properties (in addition to the existing extension methods).

8. The status of extension methods to be non-virtual is quite limiting.

9. Of course, eventually I would love to get all of the generallized interfaces.

10. Some confusing naming in System.Linq; for instance, “map” is called “Select”.

11. Can’t scrap boilerplate (because rank-2 polymorphism is missing).

12. Allow constructors for interfaces (deferring to implementing class in scope).

Regards,

Ralf Lämmel

Comments