Higher Order Programming on the Web is Alive

tademo1

A hard to read screenshot of HOPE (aka Semantic Computing) is now working on the web under the code name “Temporal Agency” (I love that name!), using:

  • Docker to isolate user projects and sessions
  • C# (Yay!)
  • DotNet Core 2.0 (Yay!)

Features:

  • IDE-style programming.
  • Syntax highlighting editor (courtesy of Ace).
  • Layout of results declared in XML.

This is very snazzy, in my humble opinion.  I have a couple demos working:

  • Weather forecast, tying in to UndergroundWeather, with summary (as shown above) and full forecast layouts.
  • Address verification using the USPS API’s.

More to come!

Advertisements

HOPE for the Web

hope-1

The above diagram is a high level view of what I’ve implemented with .NET Core 2.0 and Docker.  The idea is to take the work I’ve done with semantic types and allow users to create public or private repos of semantic types and microservices that operate on those types whenever they are “published” in the user’s environment.

With .NET Core 2.0, all the core pieces that I need (reflection, NewtonsoftJson, HttpListener, to name a few) are all fully usable with C# 7.  And while I’ll eventually return to supporting Python, it is a pleasure work with this concept in a strongly-typed language, as that’s a really key component to semantic processing (yes, of course it can be done in a dynamically-typed language with Python as well, as I’ve demonstrated in previous posts and an article.)

And the beauty of doing this with .NET Core is that it can run in a Linux container, which is so much faster than using Docker for Windows!

I’ll be posting more about the implementation details and writing some articles on Code Project on the subject.

Class-less Coding – Minimalist C# and Why F# and Function Programming Has Some Advantages

Summary

Can we use just the native .NET classes for developing code, rather than immediately writing an application specific class that often is little more than a container?  Can we do this using aliases, a fluent style, and extension methods?  If we’re going to just use .NET classes, we’re going to end up using generic dictionaries, tuples, and lists, which gets unwieldy very quickly.  We can alias these types with using statements, but this means copying these using statements into every .cs file where we want to use the alias.  A fluent (“dot-style”) notation reduces code lines by representing code in a “workflow-style” notation.  In C#, if we don’t write classes with member methods, then we have to implement behaviors as extensions methods.  Using aliases improves semantic readability at one level at the cost of confusing generic type nesting in the alias definition.  Extension methods can be taken too far, resulting in two  rules: write lower level functions for semantic expressiveness, and avoid nested parens that require the programmer to maintain a mental “stack” of the workflow.  In contrast to C#’s using aliases, F# type definitions are not aliases, they are concrete types.  New type definitions can be created from existing types.  Type definitions can also be used to specify a function’s parameters and return value.  The forward pipe operator |> is similar to the fluent “dot” notation in C#, but the value on the left of the |> operator “populates” the last parameter in the function’s parameter list.  When functions are written that return something, the last function must be piped to the ignore function, which is slightly awkward.  F# type dependencies are based on the order of the files in the project, so a type must be defined before you use it.  In C#, creating more complex aliases get messy real fast — this is an experiment, not a recommendation for coding practices!  In F#, we don’t need an Action or Func class for passing functions because F# inherently supports type definitions that declare a function’s parameters and return value — in other words, everything in functional programming is actually a function.  Tuples are a class in C# but native to functional programming, though C# 6.0 makes using tuples very similar to F#.  While C# allows function parameters to be null, in F#, you have to pass in an actual function, even if the function does nothing.  F# uses a nominal (“by name”) as opposed to structural inference engine, Giving types semantically meaningful names is very important so that the type inference engine can infer the correct type.  In C#, changing the members of class doesn’t affect the class type.  Not so with F# (at least with vanilla records) — changing the structure of a record changes the record’s type.  Changing the members of a C# class can, among other things, lead to incorrect initialization and usage.   Inheritance, particularly in conjunction with mutable fields, can result in behaviors with implicit understanding like “this will never happen” to suddenly break.  Extension methods and overloading creates semantic ambiguity.  Overloading is actually not supported in F# – functions must have semantically different names, not just different types or parameters lists.  Object oriented programming and functional programming both have their pros and cons, with some hopefully concrete discussion presented here.

Full article on Code Project here.

Migrating Higher Order Programming to the Web

My application, HOPE (Higher Order Programming Environment) is, in its simplest definition, a semantic publisher-subscriber application builder.  I’ve been wanting to move it to the web, but this is fraught with security concerns, hence my investigations into Docker technology and using a language like Python for the programming of “receptors” — the autonomous computational units that process semantic data.  Another stumbling block is my lack of experience with HTML5 canvas and graphics rendering.  Regardless though, there was no reason not to put together a proof of concept.

Here’s a quick walkthrough — no, this code is not yet publicly available.

Step 1: create a few receptors.

We’ll do some computations based on inputting a birth date.

Receptor #1: computing the age of a person in terms of years and days:

r1.png

Notice the class name computeAge.  We’ll talk about this later.

Receptor #2: compute the number of days to the birth day:

r2.png

Note the class name daysToBirthday.

Receptor #3: Get the interesting people born on the same month and day:

r3.png

Again, note the class name personsOfInterest.

Step 2: Add the Receptors to the Surface Membrane

r4.png

Step 3: Inject a semantic JSON object

Run the “membrane” and inject:

{"birthday": {"year": 1962, "month": 8, "day": 19}}

r5.png

And here’s the result:

r6.png

The full output being:

[
 {
 "age": {
 "years": 37,
 "days": 204
 }
 },
 {
 "daysToBirthday": 161
 },
 {
 "personsOfInterest": [
 "1724 Samuel Hood, 1st Viscount Hood, British admiral in the American Revolutionary War and the French Revolutionary Wars, born in Butleigh, England (d. 1816)",
 "1745 John Jay, American statesman, 1st US Chief Justice, born in New York City",
 "1863 Edvard Munch, Norwegian painter and print maker (The Scream), born in Ådalsbruk, Løten, Norway (d. 1944)",
 "1915 Frank Sinatra, American singer (Strangers in the Night, My Way) and actor (From Here to Eternity) known as 'old blue eyes', born in Hoboken, New Jersey (d. 1998)",
 "1932 robert pettit, American NBA star (St Louis Bombers/1959 MVP), born in Baton Rouge, Louisiana"
 ]
 }
]

What’s Going On?

Simply put, a preprocessor creates a mapping between semantic types and receptors (Python classes):

receptorMap = 
{
  'birthday':[computeAge(), personsOfInterest()],
  'age':[daysToBirthday()]
}

and the semantic processor engine routes the JSON semantic types to the Python class receptor’s process method.  When you inject “birthday”, it routes that type’s data to the computeAge and personOfInterest receptors.  The output of computeAge, which is of type “age”, is routed to the daysToBirthday receptor.

In this manner, one can create a library of small computational units (receptors) and build interesting “computational stories” by mixing and matching the desired computations.  Creating the receptors in Python makes this approach perfectly suited for running in Docker containers.  My ultimate vision is that people would start publishing interesting receptors in the open source community.

There’s still much more to go, but even as such, it’s a fun prototype to play with!  Some of the interesting problems that come out of this is, how do we let the end user create a visual interface (a UI, in other words) that facilitates both intuitive input of the semantic data as well as displaying real time output of the semantic computations.  Just the kind of challenging stuff I like!

Partial Application and Currying in C# – Clearing the Fog

Partial Application vs. Currying

Most of the examples you’ll see on the regarding partial application and currying (even in F#) often talk about simple functions that take two parameters.  This is sort of pointless because when you partially apply one parameter or curry one parameter, the call to resolve the operation is identical, so you really don’t get an appreciation of the syntactical difference.  I, however, will avoid that by demonstrating the differences between partial application and currying using three (wow!) parameters.

Partial Application

Very simply, partial application lets you assign the first n parameters, returning a function that takes the rest.  Given a function that returns the sum of three values:

Func<int, int, int, int> add = (a, b, c) => a + b + c;

You can partially apply one or two parameters:

Func<int, int, int> needsTwoMoreParams = (b, c) => add(3, b, c);
Func<int, int> needsOneMoreParam = (c) => add(3, 4, c);

Using these functions looks like this:

int twelve = needsTwoMoreParams(4, 5); 
twelve = needsOneMoreParam(5);

Notice we have to explicitly define the return type of the partial application function.  We cannot use var!

var needsOneParam = (b, c) => add(3, b, c);

Cannot assign lambda expression to an implicit-typed variable.

In a functional programming language like F#, the type is inferred:

> let add a b c = a + b + c;;
val add : a:int -> b:int -> c:int -> int

> let add3 = add 3;;
val add3 : (int -> int -> int)

> let add3and4 = add 3 4;;
val add3and4 : (int -> int)

The key thing to note with partial application in C# is the construct (b, c) for the remaining parameters in the needsTwoMoreParams function.  This is what tells you it’s a partial application rather than currying!

You can do the same thing with functions that are not C# Func types but Action types:

Action<int, int, int> xadd = (a, b, c) => Console.WriteLine(a + b + c);
Action<int, int> xoneParam = (b, c) => add(3, b, c);
Action<int> xtwoParams = (c) => add(3, 4, c);

Currying

As Jon Skeet so eloquently wrote: “currying effectively decomposes the function into functions taking a single parameter.”  Study this example carefully:

Func<int, Func<int, Func<int, int>>> curried = a => b => c => a + b + c;
int twelve = curried(3)(4)(5);
Func<int, Func<int, int>> oneParam = curried(3);
Func<int, int> twoParams = curried(3)(4);
twelve = twoParams(5);

Note how the parameters of the curried function are called as separate parameters: (3)(4)(5).  Also note that the function is defined with a => b
=> c=>
, which tells you this is a curried function!

Interestingly, we can use var in this case:

var oneParam = curried(3);
var twoParams = curried(3)(4);

Again however, the syntax in C# for defining the curried function must be explicit – “a function that takes an int that returns a function that takes an int and returns a function that takes an int and returns an int.”  This gets ugly real quick, and again, in F#, the inference engine knows you’re doing currying:

> add(3);;
val it : (int -> int -> int) = <fun:it@9>

> let add3 = add(3);;
val add3 : (int -> int -> int)

> let add3and4 = add(3)(4);;
val add3and4 : (int -> int)

> add3and4(5);;
val it : int = 12

Also notice this in F#:

add3(4, 5);;
add3(4, 5);;
-----^^^^

stdin(13,6): error FS0001: This expression was expected to have type
'int' 
but here has type
''a * 'b'

The correct syntax, in F# looks just like C# – one parameter per “function”:

> add3(4)(5);;
val it : int = 12

Again, once you create a curried function, you have to treat it like a curried function, same as in C#.

What about curried functions of an Action?  It would look like this:

Func<int, Func<int, Action<int>>> curried = a => b => c => Console.WriteLine(a + b + c);
var oneParam = curried(3);
var twoParams = curried(3)(4);
twoParams(5);  // prints 12

Note how the final result of last Func is an Action that takes the last value.

So now hopefully you have a clear understanding of the difference between partial application and currying.

FiddleDock – Creating a Dockerized Python Fiddle Web App

fiddledock.png

 

Using C#, a simple web server, and Docker, I’ve been putting together an example of one approach for how to create a “Fiddle” web app to run Python (or other script languages) in a Docker container.

The source code can be found on GitHub, but beware that at the time of this writing, the implementation isn’t complete (only “Run on Docker” and “Run on Host” buttons do anything) and I’m in the midst of writing the article on how I put this together (also in that repo – watch the progress as I write the article and finish the web app!)

FlowSharpCode Gets DRAKON Shapes

drakon1.png

I’ve added some select DRAKON shapes for creating flowcharts.  The Python code in the lower right editor is generated from the flowchart, and the output from the run is shown on the left.

PyLint is also now integrated into FlowSharpCode’s PythonCompilerService.  This really improves the development process as many syntactical errors are detected before even running the code.

Also, the code generator creates an execution tree which independent of the language syntax, which means that support for other languages is easily added.  Now granted, the code itself in each of the DRAKON shapes is Python code, but I have some ideas of how to make that code agnostic as well.