Welcome to Atalasoft Community Sign in | Join | Help

Almost too much to keep up with this week.  Most notably, Roger Castillo gave a fantastic talk on F#’s Language Oriented Programming features.  Also interesting, the Microsoft Research F7 project, Symbolic Differentiation, and tail call optimized corecursion.

 

Roger Castillo’s Language Oriented Programming in F#

Roger will present one approach to Language Oriented Programming in F#, a technique in which software designers borrow techniques from language design to organize software architectures.

The most advanced F# talk I’ve seen to date.  In this talk, Roger examines some of F#’s LOP features and discusses a methodology for leveraging said features to build DSLs.

 

F7: Refinement Types for F#

F7 is an enhanced typechecker for the F# programming language. F7 supports static checking of properties expressed with refinement types. Our motivation is to check various security properties of F# implementation code by typing.

A very exciting Microsoft Research project.  Static checking of cryptographic protocols and access control mechanisms could do much for safety if used generally.

 

Symbolic Differentiation in C#/F#

[A] simple C#/F# library for Symbolic Differentiation and whatever else comes to mind.

Some features, such as parallel computation of expressions, are only supported in F#.

 

Jomo Fisher’s Adventures in F# – Corecursion

Mutual recursion is a useful feature and I was sure F# must have a way to support it. I searched around quite a bit, but I didn't know the right question to ask the search engines. Eventually, I got some help from my friend  Luke Hoban.

I was interested to find out that tail recursion optimization works with corecursion as well.

 

F# Cheat Sheet

This sheet glances over some of the common syntax of the F# language. It is designed to be kept close for those times when you need to jog your memory on something like loops or object expressions.

Very useful to have on hand when teaching F#.

Another great week in F#.  Most importantly, it is now known that the language will continue to be available for free, despite productization.  Also, the F# PowerPack is now available for VS2010 beta and the MSDN documentation is up.

 

Tore Green asks Don Syme “will F# continue to be freely available?”

Free options will continue to exist, most likely through the VS shell. For example, we'll be continuing with our VS2008 plugin until the plans around a VS2010 shell finalize.

It is very good to hear that the productization of F# won’t stop it from continuing to be available for free.

 

Tomas Petricek’s WebCast – Using Asynchronous Workflows

Now that Visual Studio 2010 Beta 1 is out, it is finally a good time to take a look at one of the (in my opinion) most interesting new features in the new release - the F# language.

In this Webcast, Tomas shows how simple it is to add asynchronous operation to an application via the F# asynchronous workflow feature.

 

F# PowerPack Beta 1 for .NET 4.0/Visual Studio 2010 is Available.

F# PowerPack is now available for download for the latest Beta development milestones of the next generation of Microsoft's development platform and tools.

I know a great many people (not to mention myself) were disappointed that the VS 2010 beta did not ship with this.  I for one am in love with it’s Math and Charting features.

 

Visual F# MSDN Documentation

The Visual F# product provides support for developing F# applications or extending other .NET applications with F# code.

We now have official documentation in the MSDN style we all know and love.

 

F# – You can overload operators, but you can’t use them.

^ (op_Concatenate): Compiler error in F#. Apparently only strings can be concatenated.

> (op_GreaterThan): Runtime Error – Failure during generic comparison: the type Program+OppTest4 does not implement the System.IComparable interface.

It’s not what you say but how you say it, and while I feel the reaction of the author was way over the top, his concerns seem justified.  I’m hoping it’s just a bug and, now being identified, will be resolved.

I will be speaking at tomorrow’s Code Camp Hartford 2 on the topic of using F# for the Testing and Analysis of existing code. This talk will be composed of much of the same material I used at Code Camp Waltham 11, although I will be preparing additional introductory material as many of my Waltham attendees had no prior exposure to F#. 

I hope the audience will find this new introduction short and sweet.  In this case my goal will not be to teach F# per se, instead I would like to impress upon the audience the power of using functional programming constructs.

 

Presentation Details

F# for Testing and Analytics will be held in Room E-Echo at 10:30am.

As I often like to make changes up to the last minute, this post will be updated with my slides after the presentation. Slides are now available here.

 

The Plan

For more information, see my post on the Code Camp Waltham 11 Presentation.  I wrote quite extensively in that post on most of the things I will be discussing in this talk.

Recently, I was reading David R. Tribble’s annotated version of Dijkstra’s famous letter “Go To Statement Considered Harmful”.  While in the process of reading, it occurred to me that I did not really understand the history of language abstraction.  To remedy this I’ve done some research and put together the following post.  I hope you find it as educational to read as I found to write.

Programming languages are often spoken of in terms of their level of abstraction.  To this end there is a somewhat official classification system.  In said system, each generation in the hierarchy represents another level of abstraction away from the machine hardware. 

 

First-generation programming language (1GL) – Binary

I think there is a world market for maybe five computers.
-Thomas Watson

It makes sense Watson would say this seeing as how the earliest computers were programmed entirely in binary.  These computers were programmed with no abstraction at all.  I, for one, do not envy our forefathers in regard to this task.  While the programs were small, all operations, data and memory had to be managed by hand in binary.

  • Introduced in the 1940s
  • Instructions/Data entered directly in binary
  • Memory must be manually moved around
  • Very difficult to edit/debug
  • Simple programs only

Examples:

Architecture specific binary delivered on Switches, Patch Panels and/or Tape.

 

Second-generation programming language (2GL) – Assembly

He who hasn't hacked assembly language as a youth has no heart. He who does as an adult has no brain.
-John Moore

Assembly languages were introduced to mitigate the error prone and excessively difficult nature of binary programming.  While still used today for embedded systems and optimization, they have mostly been supplanted by 3GL languages due to the difficulties in controlling program flow.

  • Introduced in the 1950s
  • Written by a programmer in an intermediate instruction language which is later compiled into binary instructions
  • Specific to platform architecture
  • Designed to support logical structure, debugging
  • Defined by three language elements: Opcodes (CPU Instructions), Data Sections (Variable Definitions) and Directive (Macros)

Examples: 

Almost every CPU architecture has a companion assembly language.  Most commonly in use today are RISC, CISC and x86 as that is what our embedded systems and desktop computers use.

 

Third-generation programming language (3GL) – Modern

“Real programmers can write assembly code in any language.”
-
Larry Wall

Third generation languages are the primary languages used in general purpose programming today.  They each vary quite widely in terms of their particular abstractions and syntax.  However, they all share great enhancements in logical structure over assembly language.

  • Introduced in the 1950s
  • Designed around ease of use for the programmer
  • Driven by desire for reduction in bugs, increases in code reuse
  • Based on natural language
  • Often designed with structured programming in mind

Examples:

Most Modern General Purpose Languages such as C, C++, C#, Java, Basic, COBOL, Lisp and ML. 

 

Fourth-generation programming language (4GL) – Application Specific

"A programming language is low level when its programs require attention to the irrelevant."
-Alan J. Perlis

A fourth generation language is designed with making problems in a specific domain simple to implement.  This has the advantage of greatly reducing development time cost.  At the same time there is the disadvantage of increasing developer learning cost.

  • Introduced in the 1970s, Term coined by Jim Martin
  • Driven by the need to enhance developer productivity
  • Further from the machine
  • Closer to the domain

Some examples: SQL, SAS, R, MATLAB's GUIDE, ColdFusion, CSS

 

Fifth-generation programming language (5GL) – Constraint Oriented

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
- Tony Hoare

It has been argued that there is no such thing as a 5GL language.  This seems to me ridiculous as working with domain specific syntax is hardly an abstractional dead end.  This cynicism is likely a result of the many false claims of 5GL for the sake of marketing.

Many researchers speak of 5GL languages as constraint systems.  The programmer inputs a set of logical constraints, with no specified algorithm, and the AI-based compiler builds the program based on these constraints.

  • Introduced in the 1990s
  • Constraint-based instead of algorithmic
  • Used for AI Research, Proof solving, Logical Inference
  • Not in common use

Some examples: Prolog, Mercury

 

Conclusion

An interesting history lesson, although, I can’t help but feel that categories beyond 3GL are somewhat arbitrarily defined.  I do agree that 4GL is an abstraction on 3GL.  Perhaps however, there are other directions which are equally abstract in relation to 3GL.  Perhaps after concrete logic based systems, free form natural language should have been fourth.  This could be followed by thought based, which I feel would be the ultimate level of abstraction for human interaction.

Also, to my great disappointment, I was unable to find out who coined most of the “# generation language” etymologies.  As usually in computer science it is possible to gain insight on a concept by examining the author’s other works, in this case that option seems unavailable. 

 

Other References:

Introduction to Assembly Language
Generations of Programming Languages

There has been a huge spike in the number of F# posts over this past couple of weeks.  For this post I have chosen those I think are most important for the experienced F# programmer to read.  This week we have Common mistakes, the inner workings of Printf, the dangers of null types, and my personal favorite: a Lisp compiler in F#.

 

Tim Robinson’s Lisp compiler in F#: IL generation

In this post I'm going to cover the final step in the compilation process, the generation of the IL itself. By IL, I'm referring to the Common Intermediate Language, the low-level machine-independent opcodes that the .NET JIT compiler turns into native machine code at runtime.

Tim’s series is one of the best I’ve seen on IL generation in F# and the only I’ve seen on writing a Lisp interpreter.  Very cool.

 

Chance Coble’s F# - Some Common Mistakes

I really love introducing new people to functional programming. At some point they get a kind of light bulb moment and start to feel really empowered by it. However, up until that time, there is some work and frustration in switching from an old comfortable paradigm to a new one.

A great post for both beginners and teachers.  I’ll be mentioning some of these points in my upcoming Code Camp Hartford 2 talk.

 

Jonathan Allen’s The Many Types of Null in F#

F# was supposed to free us of the tyranny of the unchecked null. Alas not only does it not do that, it introduces several more kinds of null. First consider this all too common problem in C# code.

Jonathan makes a good point here.  I wish it were possible to have all F# calls which return null to be automatically converted into option types.  However, if programmers are careful with post conditions on calls into the .NET framework, and so avoid null in F#, it won’t be a significant problem. 

 

Don Syme’s HubFS post on How Printf Typing Works

Hello, I've been loving F# so far, but I've run into something I'm quite puzzled over. My goal is to bind a function to write to a specific text writer. In the following code, test1 compiles, but both test2 and 3 fail with the same error (on pn "test"): "This expression has type  unit but is here used with type  string -> unit".

After much discussion it’s interesting to see Don finally weigh in on the subject.  I must say that I’m disappointed that Printf uses compile time code generation and so I wouldn’t be able to implement the same kind of thing myself.

I’ve recently been building an ActiveX Control in .NET 2.0 and thought I would share some of the problems I’ve run into, as well as their solutions.  I hope that in reading this you can avoid a few of the timesinks I fell into. 

 

Safe for Scripting

image

By default, ActiveX controls are not marked as safe for scripting.  This means that Internet Explorer will refuse to run a control given it’s default settings, even for sites in it’s Trusted security zone.  Thankfully, this is an easy problem to correct.

 

The Wrong Way

image

It’s possible to hide this issue on the client machine by setting “Initialize and script ActiveX controls not marked safe for scripting.” to true or prompt.  This, of course, is not an acceptable solution as it will require all clients to do the same and in so doing potentially open them to malicious controls.

 

The Correct Solution

There are two ways to mark an ActiveX control as safe for scripting.  The first, and easiest in the context of .NET, is to implement the IObjectSafety interface.  The only caveat to this method is that it requires that you can modify the ActiveX control’s source code. 

The second, more complex option, is to use COM Component Categories Manager.  While not requiring source changes and recompilation, this method requires a rather large amount of registry editing.  As I did not take this approach, I won’t delve into it further.  Additional .NET implementation information is available in this CodeProject article.  

 

IObjectSafety

Implementation requires first importing the IObjectSafety interface.  This is a simply a matter of declaring a interface with the ComImport attribute.

While in most cases it is extremely important to ensure the Guid tags on your interface declarations are unique, in this case it equally important not to change it.  This is because the GUID attribute here is that of the IObjectSafety interface.  To put it plainly, changing the Guid in the following example will cause it to not work.

  1: [Flags]
  2: public enum IObjectSafetyOpts : int //DWORD
  3: {
  4:     // Object is safe for untrusted callers.
  5:     INTERFACESAFE_FOR_UNTRUSTED_CALLER  = 0x00000001,
  6:     // Object is safe for untrusted data.
  7:     INTERFACESAFE_FOR_UNTRUSTED_DATA    = 0x00000002,
  8:     // Object uses IDispatchEx.
  9:     INTERFACE_USES_DISPEX               = 0x00000004,
 10:     // Object uses IInternetHostSecurityManager.
 11:     INTERFACE_USES_SECURITY_MANAGER     = 0x00000008
 12: }
 13: 
 14: public enum IObjectSafetyRetVals : uint //HRESULT
 15: {
 16:     //The object is safe for loading.
 17:     S_OK            = 0x0,
 18:     //The riid parameter specifies an interface that is unknown to the object.
 19:     E_NOINTERFACE   = 0x80000004
 20: }
 21: 
 22: [ComImport()]
 23: //This GUID is that of IObjectSafety. Do not replace!
 24: [Guid("CB5BDC81-93C1-11CF-8F20-00805F2CD064")] 
 25: [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
 26: public interface IObjectSafety
 27: {
 28:     [PreserveSig()]
 29:     IObjectSafetyRetVals GetInterfaceSafetyOptions(ref Guid riid, out IObjectSafetyOpts supportedOpts, out IObjectSafetyOpts enabledOpts);
 30:     [PreserveSig()]
 31:     IObjectSafetyRetVals SetInterfaceSafetyOptions(ref Guid riid, IObjectSafetyOpts optsMask, IObjectSafetyOpts enabledOpts);
 32: }
 33: 

You then need only implement this interface in your ActiveX control as follows.

  1: ...
  2: public partial class ExampleControl : IObjectSafety
  3: {
  4:     public IObjectSafetyRetVals GetInterfaceSafetyOptions(ref Guid riid, out IObjectSafetyOpts supportedOpts, out IObjectSafetyOpts enabledOpts)
  5:     {
  6:         supportedOpts = IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_CALLER | IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_DATA;
  7:         enabledOpts = IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_CALLER | IObjectSafetyOpts.INTERFACESAFE_FOR_UNTRUSTED_DATA;
  8:         return IObjectSafetyRetVals.S_OK;
  9:     }
 10: 
 11:     public IObjectSafetyRetVals SetInterfaceSafetyOptions(ref Guid riid, IObjectSafetyOpts optsMask, IObjectSafetyOpts enabledOpts)
 12:     {
 13:         return IObjectSafetyRetVals.S_OK;
 14:     }
 15:     ...
 16: }
 17: 

With the IObjectSafety interface implemented to return INTERFACESAFE_FOR_UNTRUSTED_CALLER and INTERFACESAFE_FOR_UNTRUSTED_DATA, your object is considered scripting safe for use by Internet Explorer.  Your control should no longer require any non-default ActiveX related settings to run.

INTERFACE_USES_DISPEX and INTERFACE_USES_SECURITY_MANAGER are mainly used for scripting engines and can be safely ignored.

 

 

Hooking into Events

Working on my current project, I spent a not insignificant amount of time working to make events fire correctly.  I started with a simple implementation, similar to what is discussed in this article.

  1: <object id="ActiveXExample" name="ActiveXExample" 
  2:   classid="clsid:21192EDE-868C-4b94-9D20-B822C42EA9D2" 
  3:   codebase="ActiveX.cab#version=1,0,0,0" VIEWASTEXT>
  4: </object>
  1: [Guid("C07F993D-242D-4c1e-AF1B-B77CAE5FD088")]
  2: [InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
  3: public interface IExposedComEvents
  4: {
  5:     [DispIdAttribute(0x60020001)]
  6:     void ExampleEvent(string text);
  7: }
  8: 
  9: [Guid("21192EDE-868C-4b94-9D20-B822C42EA9D2")]
 10: [ClassInterface(ClassInterfaceType.None),
 11:  ComSourceInterfaces(typeof(IExposedComEvents))]
 12: [ComVisible(true)]
 13: public partial class ActiveXExample
 14: {
 15:     public event ExampleEventHandler ExampleEvent;
 16:     ...
 17: }
 18: 
  1: <script language="javascript">
  2: function ActiveXExample::ExampleEvent(text)
  3:     try {
  4:         elem = document.getElementById("status");
  5:         elem.innerHTML = text;
  6:     } catch(exception) {
  7:         alert("Exception Thrown in Event: " + exception);
  8:     }
  9: </script>

However, I found that my javascript events were not being registered.  After some fiddling, I discovered that I was able to capture the event by instead using the “for-object event” script tag.

  1: <script for="ActiveXExample" event="ExampleEvent(text)">
  2: try {
  3:     elem = document.getElementById("status");
  4:     elem.innerHTML = text;
  5: } catch(exception) {
  6:     alert("Exception Thrown in Event: " + exception);
  7: }
  8: </script>
  9: 

I’m still not quite sure why the Object::Event syntax didn’t work, as it is shown often in ActiveX sample code.  Still, if you find you are having issues getting events to fire correctly, this alternate syntax may be worth trying.

 

Additional Resources

MSDN: Safe Initialization and Scripting for ActiveX Controls

Eric Lippert's Fantastic Eight Part Series: Script and IE Security 
     One, Two, Three, Four, Five, Six, Seven and Eight

An exciting week with the release of Visual Studio 2010 Beta 1 and F# 1.9.6.16.  This week we have John Backus’s classic FP manifesto,  Luke Hoban speaks on F# in VS2010 beta 1, Django for ASP.NET, and an article on breaking changes in the latest F# release.

 

John Backus – Can Programming Be Liberated from the von Neumann Style?

Functional programs deal with structured data, are often nonrepetitive and nonrecursive, are hierarchically constructed, do not name their arguments, and do not require the complex machinery of procedure declarations to become generally applicable.

The functional programming manifesto.  Well worth the time to read for anyone serious about functional programming.

 

Luke Hoban on Channel9 – What’s the Story? What’s Next?

Here, F# Program Manager Luke Hoban talks with me about F#, generally and what people have been doing with it, the current state of the technology, what F# enables

The most interesting thing I gleamed from the talk is that F# Powerpack will not be included with Visual Studio 2010.  Luke hopes that this will allow faster development cycles.

 

Alex Pedenko’s Project, NDjango - Django templates in .NET

The current version is being released as a beta. It has full django tag support, and most of the default filters.

I’ve heard many great things about Django from my web developer friends.  I’m sure many will be happy to see ASP.NET support.  It can be used stand-alone or in conjunction with the Bistro Framework.  Best of all, NDjango is built on F# and Bistro has full F# support.

 

Abel Avram on InfoQ - Latest F# Breaks Binary Compatibility

Microsoft has included F# in VS 2010 Beta 1 and has released a corresponding CTP update for VS 2008. The latest binaries, version 1.9.6.16, are not compatible with previous ones, v. 1.9.6.2, meaning all previous code needs to be recompiled.

Also important to note, the #light syntax is now on by default.

 

I understand it is exceedingly painful to sign up for an account to leave a comment.  That given, I am still trying to figure out a solution to my spam problem.  For now, if you would like to comment and don’t wish to set up an account, please email me your comment and I will manually post it.

A bit of a slow week.  Perhaps some are out playing in the recently fantastic weather instead of blogging about functional programming.  My favorites this week were Paul Hudak’s talk on Haskell, Jason Olson’s Channel9 discussion, Niklas Gustafssons’s Actors in F# and Kurt Schelfthout’s Testing DSLs with FsCheck.

 

Paul Hudak on InfoQ - Haskell

An interview that begins with a discussion of when to introduce difficult Haskell concepts like monads, moves to a discussion of the philosophy of higher order programming.

Paul Hudak, as a principal designer of Haskell, explains FP topics with a passion few others could.  Also, I’m curious about this idea of arrows (Freyd-categories) as opposed to monads.

 

Jason Olson’s on Channel9 - Composing Programming Languages

We talk about his [Lang.NET F# and OO] presentations and his perspectives on object orientation, F# and his own language.

As it seems impossible to pin down exactly what OO is, perhaps we should try to categorize it’s subcomponents across different languages.

 

Niklas Gustafsson on Actors in F#

One of the advantages of this model over the Axum model is that any number of clients can communicate with an actor, all that is needed is access to the mailbox reference.

I must beg to differ with Niklas on one of his stated disadvantages of the Actor model.  It would be easy enough to include a “closing down state” in your Actor FSA.  The inability to statically check your agreements is correct though.  I’d be interested in seeing a simple Axum sample which could handle N clients and still be statically checked.

 

Kurt Schelfthout on How to test DSLs (and: FsChecking FsCheck)

It occurred to me that (domain specific) languages seem difficult to test using traditional unit tests: after all, the usage possibilities are far greater for a language than for, say, a typical user interface.

An extremely clever way to test DSLs.

 

I understand it is exceedingly painful to sign up for an account to leave a simple comment.  That given, I am still trying to figure out a solution to my spam problem.  For now, if you would like to comment and don’t wish to set up an account, please email me your comment and I will manually post it here.

1 Comments
Filed under: , , , ,

More links this week with alternatives to if-else logic, Algebraic Data Types, and rumors of F# beta 1. I’ve also included a roundup of known F# User Groups.  With the number of groups going from 0 to 3 in only two months, it’s easy to see the amount of excitement that F# is generating in the .NET community.

 

Alex P’s “Back to basics - F# (and currying) as a time saver for the everyday programmer”

Let me give you a simple example of how functional programming can save time in a scenario that happens in any kind of development.

Using choose for branching is quite a clever way to deal with messy if-else logic.  Be sure to scroll down and see Jarle Stabell’s use of Seq.first in the same way.  I had never previously considered using sequences in this way and I love how concise it is.  An additional benefit in using this technique is that it would be trivial to inject additional branches.

 

Kalani Thielen’s “The Algebra of Data, and the Calculus of Mutation”

With the spreading popularity of languages like F# and Haskell, many people are encountering the concept of an algebraic data type for the first time.  When that term is produced without explanation, it almost invariably becomes a source of confusion.

I learned much about the nature of Abstract Data Types from this article.  Over the next week I hope to find the time to read some of the additional links Kalani provides in the comments section.

 

(Rumor?) Flying Frog Consultancy Ltd on F# News: F# Beta 1 is due Sometime This Month

The next release, beta 1, is due out this month and a beta 2 is scheduled for release before the full 2010 release next year.

Obviously, news of F#’s demise has been greatly exaggerated (I hadn't even heard the rumor).  I know I’m not the only one who can’t wait to get their hands on beta 1.

 

F# Related Gatherings Roundup

 

I apologize that I’ve had to disable anonymous comments.  Given the amount of spam I was receiving, I had no alternative.  If you would like to leave a comment, or think you might in the future, I encourage you to take the one time step of creating an account.

A few weeks off left me with renewed vigor.  This week we have some very interesting posts on reflective and reactive programming, enhancing F# by adding additional operators, IL analysis via simulation and finally, observations on the productization of F#.

 

Luke Hoban’s Lang.NET presentation on the productization of F#

A set of interesting observations from our experience taking F# over the last 18 months or so […] from a relatively mature research project […] into something that’s going to be a part of the next version of visual studio.

I’ve just begun to watch the Lang.NET videos.  While I haven’t had a chance to watch them yet, I’ve heard from others in the community that Amanda Laucher, Jason Olson and Tomas Petricek all had fantastic presentations.

 

 

Alex P’s Thoughts on reflective programming with F#

Let's take a different approach. I'm going to bring back a piece of functionality i talked about in earlier articles - quotations, and using quotations to determine function signatures.

The most interesting idea from this post was that of stacking discriminated unions to attach meta information to parameters.  This meta information then can be used when reflecting to determine the scope of parameter inputs.

 

Jason Kikel on Adding Ruby and C# Operators to F#

Ruby (and in many ways Perl) has a bunch of really succinct, elegant operators that contribute to the satisfaction of using the language. […] Since F# doesn’t implement many of my favorite Ruby operators, we’ll put together some implementations here.

Quite a few useful set operators are defined in this post.  Many I feel should be included in the language.

 

Ian Voyce on IL analysis using F#

I recently needed to determine which functions were called by some of our F# code. Naively, you can use existing tools like ildasm, to disassemble a .NET DLL and then search the resulting IL source code for references. The obvious problem here though, is that you’re going to include all references whether or not they’re actually called.

I found Ian’s method of using discriminated unions to represent IL very clever.  Also, the possibilities in directly using the AbstractIL API seem interesting.  I may have to explore this myself.

 

J-C on Functional Reactive Programming in F# Parts 1, 2 and 3

A functional, reactive program is a program written in a functional language (where side effects are inexistent (sic) or at least limited to a minimum) and producing results that depend on time, in a continuous manner on one hand and on discrete events on the other hand.

I had not heard of Functional Reactive Programming previously.  It seems particularly useful for time sensitive domains such as robotics or game AI.

 

 

I apologize for the fact that I’ve disabled anonymous comments.  Given the amount of spam I was receiving I had no choice.  If you would like to leave a comment, or think you might in the future, I encourage you to take the one time step of creating an account.

In the image processing world, like most computational problems, we often think our work is composed of only two basic ideas: representation and transformation.  Of course, one may have many layers of both representations of transformations and transformations of representations which can make things appear quite complex at times.

However,  the problem is much more simple than it appears.  This is because a representation can be considered as a transformation from a zero or identity state.  Thus, in writing a symbolic language for image processing, we are left with only a single idea to consider:  transformations.  By composting layers of transformations we can apply image processing techniques in way which is not only bidirectional and platform agnostic but also comes along with a host of other benefits.

 

Let us consider a simplified example of processing an image:

1) We read in a file (representation) and use a codec (transformation) to convert it into a format understood by our API (representation).

2) We then perform some type of algorithm on that data (transformation) which results in some type of output (representation).

3) Finally, via another codec (transformation), another file is saved to disk (representation).

 

In most cases there are a great number of intermediate representations.  Each is a full copy of the previous iteration with whatever changes have been so far applied.  Essentially, the same information is copied over and over again in memory.  We do allow for some kinds of in-place processing, however, this is bad as when the operation has been completed, the previous representation has been destroyed.

 

Instead, what if we batched up sets of transformations?  This could have many benefits:

1) The most obvious benefit is that of parallelization.  Even at the simplest level of functional composition, these transformations could be handed off to a cluster for asynchronous processing or saved for a later batch processing job.

2) With an intermediate symbolic transformation language, processing algorithms could potentially be combined and reduced to produce a single transformation out of many.  This would significantly reduce the processing overhead as well as the number of intermediate memory representations.

3) An intermediate symbolic language which encompassed both codec and processing may make it possible to push the processing transformation through the codec transformation and in so doing no longer need to have any intermediate memory representation.  This could provide significant memory and processing speed time benefit. 

4) The intermediate symbolic language could be saved into the files themselves thus removing the need for the codec to be present on the end machine.  Admittedly, the user would also need the image language interpreter.

5) Instead of applying simple image processing algorithms to an image, the symbolic representation could be appended to the end of the file.  This would be quite similar to layers in practice.  In this way it would be possible to view the image at all stages of transformation.

6) For large or proprietary transformations, the representation could be kept on the internet and either be downloaded or, in the case where the owner did not want to expose their algorithm, a flattened representation could be sent out and a processing delta could be sent back.

 

Conclusion

Of course, when I speak of data I don’t only mean the image itself.  This technique could also be applied to many classes of data or algorithm.  Most notably for us, image metadata.

My initial goal is to build a basic codec representation along with some simple transformations.  Currently, I am researching bidirectional, reversible and declarative languages as examples.  With F# as a base language I believe it will be possible to build something portable to other ML variants.

I’ve been hit pretty hard by the spam bots over this past weekend.  It’s been getting worse at an exponential rate over the last few weeks.  If this keeps up I’ll be spending all my time weeding out spam and will have no time to continue maintaining this blog.

As to stem the tide I’ve temporarily made it necessary to create an account to be able to post comments.  Of course, long term I hope to find something better.  If you know of something I can drop into Community Server 2.0 please send me an email.

Thanks,
-Rick

0 Comments
Filed under: , ,

With the start of our F# User’s Group this next Monday and New England Code Camp 11 last weekend, things have been extremely busy this past week.  Meanwhile, the F# sociocosm is growing at a rapid pace.  This week we have a talk by Don Syme, a look at F# quotations, and finally, some discussion on Seq.unfold.

 

Chris Bowen’s Post, Announcing F# User Group in Cambridge - April 6

A shameless plug here for our new user group.  A big thanks to Chris for helping us find the resources we needed to start out.  Without him this might never have come together.

 

Don Syme’s Talk, F# and functional programming in .NET

As Don Syme is the father of F#, when he speaks the community listens.  In this talk Don focuses on the pleasure and speed inherent in using FP and F#.  He does this by describing the functional methodology and constructs which provide a simpler and more elegant model for building programs.

 

Alex P’s Post, F# quotations at their simplest

A simple example on the surface for sure.  However, if you haven’t seen the power of F#’s language oriented programming features this is sure to be of interest.

For a deeper look at the power of quotations check out Tomáš Petříček’s F# quotations visualizer.  If his past projects are any indication Tom’s upcoming book is a must have for any F# enthusiast.  I preordered a copy just today.

 

Martin Peck’s Post, Solving Problems in C# and F# - Part 2 
(and update)

One of the most fantastic things F# has to offer is the rich functional programming heritage of sequence operations.  To demonstrate how elegant they can make your code, I would like to offer the following alternative F# solution:

let fibs = 
  Seq.unfold (fun (a, b) -> Some( a, (b, a+b) )) (0I, 1I)
Seq.find (fun n -> n >= 10I ** 999I ) fibs

I’m going to take this opportunity to point out the obvious: we have here two lines of F# which does almost exactly the same thing as thirty six of C#.   Now that’s what I call power and elegance.  The unfold function pretty much does exactly what yield was doing before, but implicitly in terms of the unfold function.  The idea of unfold can be confounding at first and so here is a breakdown of how it works:

let fibs =
  Seq.unfold 
    (fun (a, b) -> //generator function, 
//
(a, b) is the previous state Some //Option monad, needed for unfold (a, (b, a + b))) //returned tuple: (value, state)
//or (
first, (second, third)) (0I, 1I) //Initial function state (first, second)

Note that in this version the state of the next two values in the sequence are always pre-calculated.  However, it is easy to avoid this if you instead consider the state in terms of the previous two values: 

let fibs = 
  Seq.unfold (fun (l, l2) -> 
    let n = l + l2 in Some( n, ( n, l ) ))
    (0I, 1I) //(previous, second previous)

If you want to learn more about unfold I recommend checking out:

 

Dustin Campell’s Post, Apples and Oranges

This is the best description of how unfold works I’ve seen to date. 

 
 

At this Saturday’s Code Camp I’ll be giving a brand new presentation on using F#.  The goal of this presentation is to have those attending leave with an idea of what F# can help them achieve today as well as instill a desire to know more.  This post contains my presentation materials as well as links to additional information on the topics covered.

 

Presentation Details

F# for Testing and Analytics will be held in the TBC (Technical Briefing Center) at 10:30am.

New England Code Camp 11 Information

Download Presentation Slides: F# for Testing and Analysis.pdf

I’ve been thinking quite a lot lately on the best way to get developers excited about F#.  By focusing less on the language’s details and more on what the language can help achieve I hope to impress upon those attending why F# is worth the effort.  The preliminary structure of the talk is as follows::

  • Introduction
    • Announcing the New England F# User Group 
  • Why F#?
    • Time Savings
    • Readability
    • Code Exploration
    • Robust Software
    • Power
  • F# Testing Toolbox
    • xUnit.NET
    • TestDriven.NET and NCover
    • NaturalSpec
    • FsCheck
  • A Real World Example
    • Exploring the Problem Space
    • Collect, Analyze, Report
    • Visualizing Data

Presentation Influences
John Hughes’s Paper: Why Functional Programming Matters
John Hughes’s Talk: FP – A Secret Weapon for Software Testing
Matthew Podwysocki’s 7 Part Series: Functional Programming Unit Testing

 

Announcing the New England F# User Group 

I’m proud to announce that we will be holding our first New England F# User Group meeting on Monday April 6th, from 6:30pm to 8:30pm.  It will be held at the aptly named Microsoft NERD center.  I hope to see you there.

Visit the F# User Group Homepage for more information.

 

xUnit.NET

“About a year ago it became clear to myself and Brad Wilson that there were some very clear patterns of success (and failure) with the tools we were using for writing tests. Rather than repeating guidance about "do X" or "don't do Y", it seemed like it was the right time to reconsider the framework itself and see if we could codify some of those rules.”

xUnit.NET Homepage

Learn More about xUnit.NET
Matthew Podwysocki’s The Unit Testing Story in F# Revisited
Jim Burger’s Unit testing in F# with xUnit.NET
Harry Pierson’s Practical F# Parsing: Unit Testing

 

TestDriven.NET and NCover

“TestDriven.NET is a zero friction unit testing add-in for Microsoft Visual Studio .NET. The current release of TestDriven.NET supports multiple unit testing frameworks including NUnit, MbUnit and MS Team System and is fully compatible with all versions of the .NET Framework.”

TestDriven.NET Homepage (Includes a free version of NCover)
NCover Homepage

Learn More about TestDriven.NET and NCover
Matthew Podwysocki’s F# + TestDriven.NET + xUnit = Win 
Matthew Podwysocki’s FP Unit Testing Part 4 – Code Coverage

 

NaturalSpec

“The idea of NaturalSpec is to give domain experts the possibility to express their scenarios directly in compilable Unit Test scenarios by using a Domain-specific language (DSL) for Unit Tests. NaturalSpec is completely written in F# – but you don’t have to learn F# to use it. You don’t even have to learn programming at all.”

NaturalSpec Homepage

Learn More about NaturalSpec
Steffen Forkmann’s “Getting Started” with NaturalSpec
Steffen Forkmann’s Testing QuickSort with NaturalSpec
Steffen Forkmann’s Using NaturalSpec to create a spec for C# projects

 

FsCheck

“FsCheck is a tool for testing .NET programs automatically. The programmer provides a specification of the program, in the form of properties which functions, methods or objects should satisfy, and FsCheck then tests that the properties hold in a large number of randomly generated cases.”

FsCheck Homepage

Learn More about FsCheck
Claudio Cherubino’s Random testing in F# with FsCheck
Matthew Podwysocki’s FP Unit Testing Part 2 – QuickCheck and FsCheck
Kurt Schelfthout’s FsChecking dnAnalytics Part 1, Part 2 and Part 3

 

FsStory

“FsStory is a library for writing executable user stories in F#. FsStory enables the developer to write user story scenarios (in Given/When/Then form) in F# code.”

FsStory Homepage

Learn More about FsStory
Gustaf Nilsson Kotte’s Fluent language in FsStory
Gustaf Nilsson Kotte’s FsStory, executable stories in F#

This week there seems to be quite a bit of video and audio content to share.  We have a dramatic depiction of the benefits of Units of Measure, Luke Hoban on F#’s feature, Ted Neward talks about F# under the hood and finally a discussion on operator type inference.

 

Video Blog – Could F# have saved the Mars Climate Orbiter?

A fantastic example of how static dimensional analysis of scalar values could prevent an entire class of bugs.   In the past, I’ve talked about what a huge fan I am of the Units of Measure package for F#.  I’m glad that others also see how revolutionary units of measure are. 

Would you want to work in a building or live in a house in which the engineers who built it did not keep track of units?  I don’t think anyone would answer yes.  Similarly, we should not entrust our lives or livelihoods to software in which these very same things are not kept track of.

 

Podcast – SER Episode 129 - F# with Luke Hoban

In this podcast Luke Hoban, the F# program manager, discusses about various aspects of F#. 

Some highlights:

  • Mutability comes along with .NET Framework support.
  • Statically Typed means strong guarantees and so robust systems.
  • FP design in the small for concurrency
  • OO design in the large for scalability
  • Explorative programming via interactive window
  • Influenced heavily by Haskell
  • FP as a technique, not a class of languages

 

Video Blog – dnrTV Show #136: Ted Neward Introduces F#

Ted Neward gives an in-depth presentation on both how F# works under the hood and the general benefits that stem from FP in general.  The examples used are simple but Ted covers them in a very exhaustive way.

Beyond the language and concepts therein, he also has a number of insightful comments about teaching people to use F#.  In particular the idea that F# syntax will be easy to teach but functional programming technique will take years really struck home with me. 

 

Blog – Kalani Thielen’s The F# overload-o-phone

In his post Kalani points out a small but significant logical inconsistency in F#’s type inference system.  The issue seems to stem from the way type inference is handled for basic operators.  Instead of working generically, they each have default types.

From his post:

> (+);;
val it : (int -> int -> int)
> 3.2 + 5.4;;
val it : float = 8.6
> let twice x = x + x;;
> twice 9.4;;
stdin(2,5): error FS0001: This expression has type
    float but is here used with type int.

To get around this, he then goes on to build a function which takes an operator and both arguments.  However, this workaround is completely unnecessary.  You need only to annotate the function’s input and it works without issue.

> let twice (x: double) = x + x
val twice : double –> double
> twice 9.4;;
val it : double = 18.8

Now, it’s important to note that this version of the twice function won’t accept an integer.  In fact, it was a conscious design decision to disallow function overloading in F#.  In both F# and C# all kinds of overloading must be qualified by type.  That is, type methods support argument overloading but free floating functions do not.

More Posts Next page »