Planet Haskell

Functional Jobs: Senior software developer/Functional programmer at Vector Fabrics (Full-time)

Tue, 18 Jun 2013 12:44:48 +0000

Vector Fabrics is hiring: we are looking for a top-notch programmer to extend our program-analysis and parallelization products. You design and implement algorithms to assist the programmer to create a parallel design from a sequential C or C++ program. You work with our international team of world-class computer scientists and experts in the Haskell / OCaml functional programming languages.

Your work is at the forefront of technology, giving you the opportunity to publish your work in major conferences and directly cooperate with processor design companies and domain-specific application vendors.

As we are a startup company, you will quickly have a major impact on our products and get to know all aspects of product creation. You will be part of a strongly committed development team and contribute to our agile development process and automated test suites. Interested? Send your CV, GitHub account or other proof of what you can do to jobs [at] vectorfabrics [dot] com.

Responsibilities

Design and implement software optimization (e.g. parallelization) algorithms for CPUs and GPUs;
Thoroughly test your code, create automated test suites;
Contribute to our agile development planning and process;
Analyze complex customer applications for optimization opportunities and translate this to new analysis algorithms.

Profile

Your friends and colleagues describe you as a superb programmer; your programming ability is way above average;
Demonstrable experience in design and implementation of complex software applications; prior experience in functional programming languages is preferred;
You continuously surprise us with your creative yet pragmatic solutions for complex software problems;
You are strongly committed to deliver working software as early as possible;
You work against very high quality standards. Refactoring is your bread and butter, pair-programming is how you prefer to review your code;
Whatever technologies, languages, or development environments you've been using, we expect you have mastered them in depth, and we expect that you will be able to master any technology, language, or development environment that we need in the future;
Excellent command of written and spoken English.

Education

MSc, MEng or PhD in Computer Science or significant relevant experience.

About Vector Fabrics

Vector Fabrics is a high-tech software company, developing tools for embedded multicore programming. Its technology and expertise is getting widespread recognition in the industry as being innovative and unique in their ability to address heterogeneous multicore application-specific silicon platforms. Due to the advanced nature of its tools, Vector Fabrics operates at the forefront of the next generation of embedded platforms for diverse markets ranging from supercomputers to automotive to cell phones.

Vector Fabrics puts absolute priority on hiring top class individuals in key positions. Vector Fabrics’ team profile is exceptional and its ambition is to hire only individuals that match or surpass that profile. The company pays top salary and offers a challenging, engaging and stimulating work environment with a high degree of responsibility.

Get information on how to apply for this position.

FP Complete: FP Haskell Center Beta Sign-Up

Mon, 17 Jun 2013 14:42:00 +0000

Beta sign-up Blog

It’s almost here! After months of hard work by our engineers, I am pleased to announce that we’ve opened up sign-up for beta of FP Haskell Center, the world's first commercial Haskell IDE and deployment platform. The beta will be released by the end of the month, and we are eager to have your active testing and feedback so we can deliver a great product that the market needs in early September. As an appreciation and reward for being in the beta program, we will offer special incentives to the finished product when available. Details of the offer will be announced in late July/early August.

The IDE includes a Haskell compiler and a continually updated set of vetted, tested and supported libraries and code templates. There is no need to run Cabal or other installers. The FP Haskell Application Server is used to deploy and run Haskell applications directly in the cloud with no additional effort. A free shared instance is included with every account. Larger and dedicated instances are available for active project deployments at a reasonable monthly charge.

FP Haskell Center’s key features and benefits are:

Simplifies the writing and deploying of Haskell applications from a single online dashboard.
Cloud-based development frees you to move among multiple devices without needing your own functioning Haskell environment.
Integrated deployment frees you from needing to run a specific OS to match build and production environments.
A hierarchical module tree for:
convenient management (renaming, moving, deleting modules or whole trees)
navigation (much easier to read, expand/collapse)
Regular, automatic parsing and type checking as feedback inside the editor and unobtrusive error output below.
Type and documentation inspection of names.
Integrated access to sample code, School of Haskell tutorials, Haddock documentation service, and Hoogle resource database.

Sign-up for beta of FP Haskell Center.

FP Complete: Interim Web Site

Mon, 17 Jun 2013 12:42:00 +0000

Interim Site blog

Welcome to our updated website! FP Complete is evolving into a full-fledged commercial developer of Haskell tools and services, as called for in our original plans. The previous site showcased the School of Haskell. We have been delighted to see it used by thousands of Haskell learners and teachers, including some authors who’ve taken advantage of its unique Active Code features to help people learn. Now that we are about to release the FP Haskell Center beta, the School remains an integral part of our offering as a place to teach and learn, but we are even more excited by the new full-powered commercial features.

This site is an interim redesign, and will be completed when we release FP Haskell Center, the world’s first commercial Haskell IDE and deployment platform, in early September. The site, and our strategy, are based on 3 pillars:

We must produce products and services needed by developers who are already using Haskell tools in their work. This is our base.
At the same time, we need to promote Haskell to the vastly larger non-Haskeller market which on the whole is unaware of Haskell’s existence. This is a long-term effort that’s absolutely necessary if Haskell is going to have meaningful adoption in the mainstream market. That’s why you see us putting a lot of effort into high-level discussions and information about what Haskell is, its feature advantages and strategic benefits. The target audience is business management, engineering management and developers who need to be converted into Haskell supporters and users.
In all our efforts, we are always working with the Haskell community. FP Complete was started in 2012 with the help of some of the leaders of the community and is committed to continue working with the entire community to advance the technology and expand Haskell adoption in the commercial market. This follows a well-proven model of success for companies commercializing open-source technologies starting with Red Hat.

In the coming months, we will be continually adding more content to fulfill our goal to be a major resource for all things Haskell. Things like more whitepapers, case studies, video testimonials, tutorials and sample codes. If you have any suggestions or things to contribute, be sure to let us know. As always, we welcome constructive comments from the community.

Douglas M. Auclair (geophf): Thoughts on Kleisli Arrows in Java (WIP)

noreply@blogger.com (geophf) — Mon, 17 Jun 2013 12:39:32 +0000

Here are some ramblings as I puzzle my way through on how to represent Kleisli arrows in Java (and why I would want to do that, anyway). This is very much a work in progress, so no solid conclusions from this posting.

Categories are abstractions. They have objects and morphisms. The thing of Category theory is that the objects can be anything, as they are atomic, and the morphisms aren't necessarily functions. So, the objects can be numbers, not that we care, or they could be arrows (another term for morphisms), or they could be categories themselves, so the morphisms become morphisms between categories. Or if the objects are arrows then the morphisms are higher-order functions.

Neat-o!

So, John Baez did some wonderful pieces on higher-order categories in the direction of physical math: topologies and groups and such, and this was replicated in Edward Kmett's work with ... what are they called? Ah, yes: semigroupoids (how could I forget), where the monoids have no zero bases and so identity functions aren't necessary, I suppose.

Interesting! Half-monoids!

But if we look at Categories as simply that: objects and morphisms, and we look at morphisms as simply arrows from a to b, then does that simplify my implementation of my categories library?

Monads no longer are generically typeful but now use inheritance to describe the type families:

Monad<a> is the interface and Maybe<a> extends Monad<a> instead of

Monad<M extends Monad, a> being the interface as Maybe<a> extends Monad<Maybe, a>.

The problem is in the generic functions, how does one grab the 'm' in the monadic type? Or is it as simple as using inheritance and forgetting the thorny problem of genericity, or passing that problem off to the inheritance structure?

Same thing for Arrow ...

instead of Arrow<a, b, c>

we have Arrow<b, c>

and then the Kleisli arrow becomes more simple, perhaps? Because

KleisliArrow<m, b, c> extends Arrow<b, m c>

... but how does that work? Can it work? I don't see how that works.

for first :: a b c -> a (b, d) (c, d)

how does that work for the KleisliArrow, and for chaining the monadic computation?

It appears further research is necessary for me to get a solid grasp of this to be able to implement this properly in Java (as opposed to writing a haskell parser on top of Java, which is also a viable way of going about it, except for the fact that there is political resistance to learning a domain-specific language from devs brought on to code 'only' in language-of-choice X).

So that's my problem, because in my 'Monads in Java' article I concluded with a:

So you see we can now do the following:

f.apply(m).bind(g).bind(h)

and I now know that f.apply(m) is a weakness in coding. This should all be strung together with Kleisli arrows and the resulting morphism be run through the Kleisli computer.

"The (explicit) use of apply considered harmful"?

I mean, Gah! How bold! How daring! How so against the grain!

And it isn't even really 'harmful' either. More like obtuse or obnoxious. And not even that, more like: inelegant. That's the word: inelegant. And we're not even 'using' apply in the above computation. I mean, we are, but we are always using apply. It's so inherent that now just juxtaposition is now apply, so it's not the '(explicit) use' of apply, it's the '(explicit) call' or '(explicit) invocation' of apply that's inelegant.

I mean, when I see the above formulation, I now shudder, whereas before I might've said, with a pause so slight it didn't even register, 'What do we do here? Oh, use apply!' knowing, at the back of my mind, that this didn't sit perfectly right, but what else was there to do?

Well, with Kleisli composition, there is nothing to do at all, but just do it

runKleisli (f <+> g <+> h) m

and we're done.

Now, how to represent that in Java, ... well, I do have a KleisliArrow type that does return the underlying arrow, but what about composition ... it probably has that, too:

f >>> g >>> h

But the gnawing problem there is that KleisliArrow is not related to Arrow, because, properly, it isn't: KleisliArrow on a specific monadic type m IS related to Arrow.

And I don't know how to represent that in Java.

Yet.

hyperq: Trading: a hacker approach?

Mon, 17 Jun 2013 08:19:00 +0000

You are startled by the sound of an alarm. It is followed by an urgent voice which warns that the Arcada has been boarded by unknown intruders. It ends abruptly.
>
start of Space Quest I

Most hackers involved in the world of trading enter from the technology side of the business. And there's two main gateways are via trader enhancement or trader replacement. Making traders smarter and faster using technology is one well worn road. There's lots of room to streamline the human trading process: automation of regular tasks, expansion of back-testing capabilities and easy gains to be had in better trader dashboards to get information when and where needed.

Trader replacement is a little harder but also hackable. There's plenty of tricks out there to shave a few msecs of computation and execution time, and bringing bigdata testing and conversion of a sometimes fuzzy human rule-set into a more rigorous computational exercise.

Either way, a trading runtime ends up paving the cow-paths of institutional finance which look somewhat like this:

Over at hyperq, we've been thinking about the above diagram and how to get together a decent trading runtime. Now when a wildly ambitious objective meets a meager resource base you have two options:

go on a kamikaze death march
take the team on a long lunch and redefine

Since this is all open source, our long lunch redefinitional musings led us to computer sciencing the bejesus out of the trading problem domain.

Here's the alternative design specification document we wrote on one of the drink coasters:

trade :: [MarketData a] -> Book b -> IO [Order b]
main = forever . do . trade

Having just cut 3 months out of our critical path we even had time for some Zork:

You are in an open field west of a big white house with a boarded front door. There is a small mailbox here.
>
Zork

Long lunch over and the new specs still seem sweet. Some immediate ideas:

the concept of market data becomes naturally abstractable. Data can include multiple sources, news flow or whatever universe observation you can think of. Do you need the Market prefix?
there is an immediate reminder of real world interaction with the IO monad.
subsequent functions scan more easily and can be categorized - often as a matter of taste. For example, a complex event process (CEP), a fashionable big deal in trading system circles, seems logically to have this type:
```
cep :: [MarketData a] -> MarketData a
```
Whether to put this prior to or inside the trade function then becomes a matter of taste.
Should the input be [Maybe MarketData a]? This puts the real world likelihood of the data feed being down front and center, rather than designing a system assuming an idealized world and then panicking when something breaks.

More generally, a more hacker approach leads you away from bigdata phd solutions that dominate hft and algorithmic trading and towards the important, small and obvious stuff (that may not lend themselves to a phd dissertation). The market is closed (unexpectedly) - I better not try and trade, or I had better try and trade elsewhere given the sorry state of Book a. Gee, there's a lot of volatility out and about today - is it a big news day? The last news piece of note was a facebook announcement. Wow, facebook really tanked but but zygna didn't - what gives there? Someone must have forgot to turn the market feed on. etc etc

And I suspect this approach leads further to a big, big gap in the market. Imagine on a busy day in the market you could slow down time. The e-mini suddenly drops by 1% in the space of a few heartbeats. What just happened? Rewind the video tape and look more carefully at the last few minutes. Look back at the news-flow over the last 10 minutes and look for keywords. Check other markets - are they all tanking or is it just a local event? Or did some human just enter an extra zero or three again?

If you can do all of that in a few seconds your process is way ahead of the competition. The HFT guys have already panicked and run away to hide behind their statistical order flow models. Algorithmic trades are pinging their stop loss instructions blindly creating what may be a forecastable trend. Meanwhile, discretionary day traders have just noticed a small section of one of their screen is flashing red…

In this zone, a hacker trader with a hacker-like trading process can find all sorts of edges and market tells.

So do we want our trading process to look and feel like a big finance organizational structure? Or should for hyperq to have a Roger Wilco attitude:

Anyway, I aborted the launch and jetted out of there in an escape pod. I crawled into the sleep chamber, and the next thing I knew, I woke up in a trash freighter! Yeah, things didn't look too good, but I blasted out of the freighter in an old jalopy I resurrected from the rubble. ~ Roger Wilco

Much more fun than a death march to pave the cow-paths.

Manuel M T Chakravarty: Data Flow Fusion with Series Expressions in Haskell

Mon, 17 Jun 2013 05:39:34 +0000

We are currently exploring flow fusion, a new fusion method for purely functional array code that overcomes the main limitation of stream fusion, namely stream fusion’s inability to fuse branching streams. Our current flow-fusion prototype in the Glasgow Haskell Compiler manages to achieve a twofold speedup over stream fusion for computing convex hulls of 2D points using the QuickHull algorithm. In fact, the code generated by flow fusion is only a few percent points away from hand-written C code. We have summarised all the details in a draft paper Data Flow Fusion with Series Expressions in Haskell.

Paul Potts: Objective-Dylan, or Perhaps Subjective-C?

noreply@blogger.com (Paul Potts) — Mon, 17 Jun 2013 01:09:00 +0000

Yesterday my wife took the kids with her on an overnight trip to Ann Arbor so I've had a bit of extra quiet time. How am I making use of this bounty? Getting on with some minor home repairs? Cleaning my office from top to bottom? Er, no... porting the game logic I've written so far in Objective-C back to Dylan, so that I can do some more thinking about it.

So after a phone job interview yesterday (which went well, I thought -- I'm optimistic about this possibility!) I started working on this task, and then about twelve hours later, around 2 a.m., I had the basic setup and population of the game board working. It's embarrassing to admit how long it took. I started on my Mac, and when I began encountering constant runtime errors switched over to my Ubuntu box, thinking that the Mac version of Open Dylan might just be broken (it isn't; I got the identical behavior on the Linux build). I finally figured out workarounds -- it's funny how taking a break clears my head far better than pressing on ever does -- then read a little Gene Wolfe (I'm working my way through In Green's Jungles, one of his books I've repeatedly tried and failed to finish), and fell asleep with no children in the bed to kick or otherwise interfere with a good night's sleep. I'm back up this morning, had a bath, and I'm drinking a large coffee with soy creamer and stevia and trying to hold off on a lunch break until I have some more done. It's about 10 a.m. and I'm expecting my family back in about six hours, so the race is on!

This has taken far longer than I hoped; I lost quite a bit of time stumbling across things in Open Dylan that still seem just plain broken. I had to start working on a smaller and smaller program to figure out exactly what was broken. These things I've flagged in comments, as places where, basically, I wish Dylan worked a certain way, and it doesn't. I may just be asking for something that doesn't quite match the original spec or isn't quite possible, but I'll share those with the Dylan Hackers team and see if it seems like I can help with them. The biggest thing that was broken, though, was me -- my brain, that is -- since it's been a long time since I've worked with Dylan's type-union and singleton pseudo-classes and I had forgotten the details. The compiler was not a big help with this, since it is such a dynamic language and leaves an awful lot of things to the runtime to figure out, which it does by throwing an error message that may or may not help much. The documentation is a bit scanty, but it does contain everything you need to know, if you re-read and squint at the scanty examples that are out there hard enough.

The good news is that the port is working and I'd like to share it. Dylan is still up there with Scheme (and now Haskell) as one of my favorite languages for designing programs -- yes, even though Dylan is quite old as languages go. I like to see what it can do especially with generic functions and its sophisticated model for object-oriented dispatch. I've been a little stymied as to how to express the design best in Objective-C. If it was a complicated game design, I wouldn't feel bad about having a program that looked complex. But it's really an elegantly simple game, and so I feel like the implementation should reflect that. My Objective-C implementation has been feeling more and more bloated and pointlessly complex, although it works, so my thought was to get it down to a simple implementation that takes full advantage of Dylan's object-oriented programming features, largely borrowed from CLOS, and then port that back to Objective-C, adding whatever minimalist support is needed to fake up some of the features that Dylan gives me that Objective-C doesn't have. This might be by way of also writing a Haskell or Scala implementation later, for yet more learning and language comparison, although really what I should focus on is getting the iOS GUI up and working so that I have something to show people.

Anyway, I've got a Dylan program that plays the Polar game, using singletons to represent tile types, and methods dispatched on singletons to handle specific kinds of collisions. The classes -- which are empty, pretty much used only for their usefulness as types, for driving dispatch -- are like so:

In Dylan you can create some instances, and create something called a type-union, which is something that is a type, I think, but not a class. You can use it to define a slot type or a parameter type. But you can't make one:

define constant $the-bomb = make(<bomb>);
define constant $the-empty = make(<empty>);
define constant $the-heart = make(<heart>);
define constant $the-house = make(<house>);
define constant $the-ice-block = make(<ice-block>);
define constant $the-mountain = make(<mountain>);
define constant $the-tree = make(<tree>);

define constant <tile-or-false> = type-union(
    singleton( $the-bomb ), singleton( $the-empty ),
    singleton( $the-heart ), singleton( $the-house ),
    singleton( $the-ice-block ), singleton( $the-mountain ),
    singleton( $the-tree ), singleton( #f ) );

And eventually dispatch on singletons -- meaning that a given method will be called with it is called with references to the exact objects that you specify:

define method collide( model :: <model>, dir :: <dir>,
    heart-pos :: <pos>, heart-tile == $the-heart,
    house-pos :: <pos>, house-tile == $the-house )
    format-out( "collide: $the-heart / $the-house\n" );
    setTileAtPos( model, heart-pos, $the-empty );
    model.decrementHeartCount();
end;

That gives you an idea of how some of the code in the Dylan program is organized. I have it mostly working, however, I'm not going to present the full code quite yet because I have a crashing bug, and I haven't yet been able to figure out if it is a dumb mistake on my part or a compiler or runtime bug in Open Dylan. I've also asked the Dylan hackers to take a look at my design and see what they think -- if they can find, as I put it, "a simpler design struggling to get out." Which is always the challenge, when trying to write not just functional, but model code, isn't it?

The Gentoo Haskell Team: Call for help: wiki.gentoo.org documentation

Sun, 16 Jun 2013 19:30:25 +0000

I’d like to ask gentoo-haskell community for help. We have a nice wiki and our project page have moved there. But it seems that we don’t have enough documentation quality for end-user application. As a developers we support proper builds and tests for that packages but we are not expert users for many of them. So I’d like to ask community to add some docs and tips for applications you use. This basically means installation, advanced config (examples), interesting use cases, links to external resources (blog posts/documentation) and so on. It can help a lot for new Gentoo users.

The most interesting projects are:

Thanks!

Jan Stolarek: Getting friendly with STG

Thu, 13 Jun 2013 20:45:46 +0000

I’ve been spending last months on developing GHC. No rocket science so far, just a bit of hacking here and there. The biggest thing I am working on is ticket #6135, which is about changing some of the existing PrimOps to return unboxed Int# instead of Bool. This means that the result of comparing two unboxed values will be either an unboxed 0# or unboxed 1#, instead of a tagged pointer to statically allocated object representing True or False. This modification will allow to write branchless algorithms in Haskell. I promise to write about this one day, but today I want to blog about a different topic.

It so happens that things I’ve been doing in GHC require me to make changes in the code generator. This is a bit challenging for me, because the code generator is something that didn’t interest me much when I started to learn about compilers. Probably the main reason for this is that code generation means dealing with assembly. I’ve been programming for about 16 years and only two languages caused me problems when I tried to learn them. Assembly is one of them¹. I have been learning it for one year during my studies and, although I had no problems with understanding the idea behind assembly and writing short snippets of code, writing a larger piece of code always ended up in a headache.

It looks that the time has come to overcome my fear. During last months I’ve been reading a lot of assembly generated by GHC and I even made some attempts at writing assembly code by myself (well, using intrinsics, but I guess that counts). But between Haskell source code and the generated executable there are many intermediate steps. From my observations it seems that many Haskellers have basic knowledge of Core – GHC’s intermediate language. Most have also heard about other two intermediate representations used by GHC – STG and Cmm – but it seems that few people know them, unless they hack the compiler. And since I’m hacking the compiler I should probably have more knowledge about these two representations, right?

There’s a classic paper by Simon Peyton-Jones “Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine”. It is quite long – 87 pages total – and, being published in 1992, it is mostly out of date. These two things kept me from reading it, although I think that being out of date was only a pretext for me to avoid reading almost 90 pages of text. But, since I need to learn about STG, I finally decided to give it a shot. Reading the paper took my four days. Paper is very well written and in general is an easy read. I was afraid that I might not understand formal description of operational semantics of STG, but it turned out to be well explained so I had no problem with that. The major problem turned out to be the amount of knowledge I had to learn while reading. This resulted in problems with fully understanding last sections of the paper. Not because they are more difficult than the initial ones, but because I didn’t fully remember all the details that were discussed earlier. An important question is which information is not up to date. I’m not yet familiar with the existing implementation, but it seems that many things have changed: the Spineless Tagless G-machine is not tagless any more since the introduction of pointer tagging; curried function are now evaluated using eval/apply convention, while the paper describes push/enter; the paper discusses only compilation to C, while currently C back-end is becoming deprecated in favour of native code generator and LLVM; and finally the layout of closures is now slightly different than the one presented in the paper. I am almost certain that garbage collection is also performed differently. These are the differences that I noticed, which means that really a lot has changed since the publication over 20 years ago. Surprisingly, this doesn’t seem like a big problem, because the most important thing is that the paper presents an idea of how STG works, while the mentioned changes are only not so important details.

So, now that I have a basic idea of how STG works, what comes next? There are a few follow up papers:

“The STG runtime system (revised)” – an updated description of STG written in 1999 by Simon Peyton Jones and Simon Marlow. I guess it’s also outdated, but still probably worth reading. It has only 65 pages :)
“Making a Fast Curry. Push-Enter vs. Eval-Apply for Higher-order Languages” – this described the mentioned eval/apply and push/enter strategies. Already read this one.
“Faster Laziness Using Dynamic Pointer Tagging” – this will tell you why STG is not tagless. Read this one also.

And once I’ll deal with STG I’ll have to learn about Cmm.

In case you’re interested, the other one is Io

Daniil Frumin: Building GHCJS

Thu, 13 Jun 2013 06:05:11 +0000

1 Intro

In this post I would like to talk about my experience with
bootstrapping GHCJS using the provided facilities ghcjs-build. I
never used tools like Vagrant or Puppet before so all of this was
kinda new to me.

2 Initial installation

GHCJS can’t actually work with vanilla GHC 7.* as it requires to
apply some patches (in order to get JS ffi to work, it adds
JavaScriptFFI language extension among other modifications).

ghcjs-build uses Vagrant (a tool for automatically building and
running work environments) to mange the work environment, so prior to
running GHCJS you need to install vagrant and VirtualBox. It’s actually
a sensible way to tackle a project like that: everyone has similar
work environments, you don’t have to mess with your local GHC
installation. It also make use of Puppet deployment system in
puppetlabs-vcsrepo module for cloning Git repositories.

Currently, there are two ways to start up GHCJS using ghcjs-build

2.1 Using the prebuilt version

git clone https://github.com/ghcjs/ghcjs-build.git
cd ghcjs-build
git checkout prebuilt
vagrant up

Using this configuration the following procedures are performed:

Vagrant sets up a 32-bit Ubuntu Precise system (/Note: if this is
your first time running Vagrant it downloads the 280Mb
precise32.box file from the Vagrant site/)
Vagrants does some provisioning using Puppet (downloads and
installs necessary packages)
A 1.4GB archive with ghcjs and other prebuilt tools are downloaded
and extracted.

2.2 Compiling from source

git clone https://github.com/ghcjs/ghcjs-build.git
cd ghcjs-build
vagrant up

Apart from setting up the box this will

Get the GHC sources from Git HEAD and applies the GHCJS patch.
Get all the necessary packages for ghcjs
Get the latest Cabal from Git HEAD, applies the GHCJS patch and
build it.
Compile the necessary libraries using ghcjs
Compile ghcjs-examples and its dependencies (it appears that it
can take a lot of time to compile gtk2hs and gtk2hs’s tools)

Please note, that depending on your computer, you might want to go for
a long walk, enjoy a small book or get a night sleep (assuming you are
not scared by the sound of computer fans).

Apart from being slow, the process of compiling everything from
source is error prone. To give you a taste, last night I was not able
to reproduce a working environment myself, because of some recent
changes in GHC HEAD. The prebuilt version on the other hand is
guaranteed to install correctly.

Hopefully, the GHCJS patches will be merged upstream before the GHC
7.8 is out. That way you won’t need to partake in building GHC from
the source in order to use GHCJS.

2.3 Communicating with the VM

After you’ve finished with the initial setup you should be able just
to

vagrant ssh

in your new vm and start messing around.

ghcjs command is available to you and Vagrant kindly forwards the
3000 port on the VM to the local 3030 port, allowing you to run web
servers like warp on the VM and accessing them locally.

You can access your local project directory under /vagrant in VM:

$ ls /vagrant
keys  manifests  modules  outputs  README.rst  Vagrantfile

However, copying file back-and-forth is not a perfect solution. I
recommend setting up a sshfs filesystem (Note: if you are on OSX,
don’t forget to install fuse4x kernel extension):

$ vagrant ssh-config
  Host default
    HostName 127.0.0.1
    User vagrant
    Port 2222
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking no
    PasswordAuthentication no
    IdentityFile "/Users/dan/.vagrant.d/insecure_private_key"
    IdentitiesOnly yes
    LogLevel FATAL
$ sshfs vagrant@localhost:/home/vagrant ../vm -p2222 -oreconnect,defer_permissions,negative_vncache,volname=ghcjs,IdentityFile=~/.vagrant.d/insecure_private_key 
$ ls ../vm

When you are done you can just umount ../vm

3 Compiling other packages

Since the diagrams package on Hackage depends on the older version
of base we are going to use the latest version from Git:

mkdir dia; cd dia
git clone git://github.com/diagrams/diagrams-core.git
cd diagram-core && cabal install && cd ..

cabal unpack active
cd active-0.1*
cat >version.patch <<EOF
--- active.cabal        2013-06-12 12:58:40.082914214 +0000
+++ active.cabal.new    2013-06-12 12:58:31.029465815 +0000
@@ -19,7 +19,7 @@

 library
   exposed-modules:     Data.Active
-  build-depends:       base >= 4.0 && < 4.7,
+  build-depends:       base >= 4.0 && < 4.8,
                        array >= 0.3 && < 0.5,
                        semigroups >= 0.1 && < 0.10,
                        semigroupoids >= 1.2 && < 3.1,
@@ -31,7 +31,7 @@
 test-suite active-tests
     type:              exitcode-stdio-1.0
     main-is:           active-tests.hs
-    build-depends:     base >= 4.0 && < 4.7,
+    build-depends:     base >= 4.0 && < 4.8,
                        array >= 0.3 && < 0.5,
                        semigroups >= 0.1 && < 0.10,
                        semigroupoids >= 1.2 && < 3.1,
EOF
patch active.cabal < version.patch
cabal install
cd ..

git clone git://github.com/diagrams/diagrams-lib.git
cd diagrams-lib && cabal install && cd ..

git clone git://github.com/diagrams/diagrams-svg.git
cd diagram-svg && cabal install && cd ..

Other packages I had to install already had their Hackage versions
updated.

Now you can try to build a test diagram to see that everything works

module Main where

import Diagrams.Prelude
import Diagrams.Backend.SVG.CmdLine

d :: Diagram SVG R2
d = square 20 # lw 0.5
              # fc black
              # lc green
              # dashing [0.2,0.2] 0

main = defaultMain (pad 1.1 d)

then you can compile and run it

ghc --make Test.hs 
./Test -w 400 -o /vagrant/test.svg

And that’s it!

4 Outro

I would also like to note that we are currently polishing the GHCJS
build process. Luite, especially is working on making ghcjs work (and
run tests) with Travis CI (it take quite a bit of time to build ghcjs
and sometimes travis is timeouting) and I am working on tidying up
the build config.

Stay tuned for more updates.

Tagged: diagrams, ghcjs, haskell, soc

Daniil Frumin: Summer of Code

Wed, 12 Jun 2013 14:17:57 +0000

Hello, everyone!

I’ve decided to reinstate this blog since I’ve got accepted to this year’s Google Summer of Code program. I’ll blog about my updates, stuff that I’ve been working on and bottlenecks and problems I’ve encountered.

My project is a pastebin site using diagrams and GHCJS to generate embeddable interactive widgets and static images/text in case when the pasted code does not require additional interaction. My mentor is Luite Stegeman, and Brent Yorgey and other nice people from the diagrams community has agreed to help.

I am very excited about this and happy that I’ve got a whole bunch of smart people to help me with this.

Unfortunately, as we haven’t sorted out a completely safe way to evaluate code coming from 3rd parties, there is no public version hosted anywhere yet. Meanwhile, there is a project on GitHub.

Hopefully, soon I’ll be able to publish a post about my experience with bootstrapping GHCJS.
Until then, stay tuned!

Tagged: diagrams, ghcjs, haskell, interactive-diagrams, soc

Tom Moertel: Tricks of the trade: Recursion to Iteration, Part 4: The Trampoline

Wed, 12 Jun 2013 00:00:00 +0000

Posted on June 12, 2013

Tags: programming, recursion, iteration, python, recursion-to-iteration series, tail calls, data structures, trampolines

This is the fourth article in a series on converting recursive algorithms into iterative algorithms. If you haven’t read the earlier articles first, you may want to do so before continuing.

In the first article of our series, we showed that if you can convert an algorithm’s recursive calls into tail calls, you can eliminate those tail calls to create an iterative version of the algorithm using The Simple Method. In this article, we’ll look at another way to eliminate tail calls: the trampoline.

The idea behind the trampoline is this: before making a tail call, manually remove the current execution frame from the stack, eliminating stack build-up.

Execution frames and the stack

To understand why we might want to manually remove an execution frame, let’s back up and think about what happens when we call a function. The language runtime needs some place to store housekeeping information and any local variables the function may use, so it allocates a new execution frame on the stack. Then it turns control over to the function. When the function is done, it executes a return statement. This statement tells the runtime to remove the execution frame from the stack and to give control (and any result) back to the caller.

But what if the function doesn’t return right away? What if it makes another function call instead? In that case, the runtime must create a new execution frame for that call and push it onto the stack, on top of the current frame. If the function ends up calling itself many times recursively, each call will add another frame to the stack, and pretty soon we will have eaten up a lot of stack space.

Eliminating stack build-up

To avoid this problem, some programming languages guarantee that they will recycle the current execution frame whenever a function makes a tail call. That is, if the function calls some other function (or itself recursively) and just returns that function’s result verbatim, that’s a tail call. In that case, the runtime will recycle the current function’s execution frame before transferring control to the other function, making it so that the other function will return its result directly to the original function’s caller. This process is called tail-call elimination.

But in languages like Python that don’t offer tail-call elimination, every call, even if it’s a tail call, pushes a new frame onto the stack. So if we want to prevent stack build-up, we must somehow eliminate the current frame from the stack ourselves, before making a tail call.

But how? The only obvious way to eliminate the current frame is to return to our caller. If we’re to make this work, then, the caller must be willing to help us out. That’s where the trampoline comes in. It’s our co-conspirator in the plot to eliminate stack build-up.

The trampoline

Here’s what the trampoline does:

It calls our function f, making itself the current caller.
When f wants to make a recursive tail call to itself, it returns the instruction call(f)(*args, **kwds). The language runtime dutifully removes the current execution frame from the stack and returns control to the trampoline, passing it the instruction.
The trampoline interprets the instruction and calls f back, giving it the supplied arguments, and again making itself the caller.
This process repeats until f wants to return a final result z; then it returns the new instruction result(z) instead. As before, the runtime removes the current execution frame from the stack and returns control to the trampoline.
But now when the trampoline interprets the new instruction it will return z to its caller, ending the trampoline dance.

Now you can see how the trampoline got its name. When our function uses a return statement to remove its own execution frame from the stack, the trampoline bounces control back to it with new arguments.

Here’s a simple implementation. First, we will encode our instructions to the trampoline as triples. We’ll let call(f)(*args, **kwds) be the triple (f, args, kwds), and result(z) be the triple (None, z, None):

def call(f):
    """Instruct trampoline to call f with the args that follow."""
    def g(*args, **kwds):
        return f, args, kwds
    return g

def result(value):
    """Instruct trampoline to stop iterating and return a value."""
    return None, value, None

Now we’ll create a decorator to wrap a function with a trampoline that will interpret the instructions that the function returns:

import functools

def with_trampoline(f):
    """Wrap a trampoline around a function that expects a trampoline."""
    @functools.wraps(f)
    def g(*args, **kwds):
        h = f
        # the trampoline
        while h is not None:
            h, args, kwds = h(*args, **kwds)
        return args
    return g

Note that the trampoline boils down to three lines:

while h is not None:
    h, args, kwds = h(*args, **kwds)
return args

Basically, the trampoline keeps calling whatever function is in h until that function returns a result(z) instruction, at which time the loop exits and z is returned. The original recursive tail calls have been boiled down to a while loop. Recursion has become iteration.

Example: factorial

To see how we might use this implementation, let’s return to the factorial example from the first article in our series:

def factorial(n):
    if n < 2:
        return 1
    return n * factorial(n - 1)

Step one, as before, is to tail-convert the lone recursive call:

 def factorial(n, acc=1):
     if n < 2:
         return acc
     return factorial(n - 1, acc * n)

Now we can create an equivalent function that uses trampoline idioms:

def trampoline_factorial(n, acc=1):
    if n < 2:
        return result(acc)
    return call(trampoline_factorial)(n - 1, n * acc)

Note how the return statements have been transformed.

Finally, we can wrap this function with a trampoline to get a callable version that we can use just like the original:

factorial = with_trampoline(trampoline_factorial)

Let’s take it for a spin:

>>> factorial(5)
120

To really see what’s going on, be sure to use the Online Python Tutor’s visualizer to step through the original, tail-recursive, and trampoline versions of the function. Just open this link: Visualize the execution. (ProTip: use a new tab.)

Why use the trampoline?

As I mentioned at the beginning of this article, if you can convert a function’s recursive calls into tail calls – which you must do to use a trampoline – you can also use the Simple Method on the function. For example, here’s what the Simple Method does to our original factorial function:

def factorial(n, acc=1):
    while n > 1:
        (n, acc) = (n - 1, acc * n)
    return acc

This version is simpler and more efficient than the trampoline version. So why not use the Simple Method always?

The answer is that the Simple Method is tricky to apply to functions that make tail calls from within loops. Recall that it introduces a loop around a function’s body and replaces recursive tail calls with continue statements. But if the function already has its own loops, replacing a tail call within one of them with a continue statement will restart that inner loop instead of the whole-body loop, as desired. In that case, you must add condition flags to make sure the right loop gets restarted, and that gets old fast. Then, using a trampoline may be a win.

That said, I almost never use trampolines. Getting a function into tail-call form is nine tenths of the battle. If I’ve gone that far already, I’ll usually go the rest of the way to get a tight, iterative version.

Why, then, did we make this effort to understand the trampoline? Two reasons. First, it’s semi-common in programming lore, so it’s best to know about it. Second, it’s a stepping stone to a more-general, more-powerful technique: continuation-passing-style expressions. That’s our subject for next time.

In the meantime, if you want another take on trampolines in Python, Kyle Miller wrote a nice article on the subject: Tail call recursion in Python.

Thanks for reading! As always, if you have questions or comments, please leave a comment on the blog or hit me at @tmoertel.

Mike Izbicki: HLearn’s code is shorter and clearer than Weka’s

Tue, 11 Jun 2013 17:50:09 +0000

Haskell code is expressive. The HLearn library uses 6 lines of Haskell to define a function for training a Bayesian classifier; the equivalent code in the Weka library uses over 100 lines of Java. That’s a big difference! In this post, we’ll look at the actual code and see why the Haskell is so much more concise.

But first, a disclaimer: It is really hard to fairly compare two code bases this way. In both libraries, there is a lot of supporting code that goes into defining each classifier, and it’s not obvious what code to include and not include. For example, both libraries implement interfaces to a number of probability distributions, and this code is not contained in the source count. The Haskell code takes more advantage of this abstraction, so this is one language-agnostic reason why the Haskell code is shorter. If you think I’m not doing a fair comparison, here’s some links to the full repositories so you can do it yourself:

HLearn’s bayesian classifier source code (74 lines of code)
Weka’s naive bayes source code (946 lines of code)

The HLearn code

HLearn implements training for a bayesian classifier with these six lines of Haskell:

newtype Bayes labelIndex dist = Bayes dist
    deriving (Read,Show,Eq,Ord,Monoid,Abelian,Group)

instance (Monoid dist, HomTrainer dist) => HomTrainer (Bayes labelIndex dist) where
    type Datapoint (Bayes labelIndex dist) = Datapoint dist
    train1dp dp = Bayes $ train1dp dp

This code elegantly captures how to train a Bayesian classifier—just train a probability distribution. Here’s an explanation:

The first two lines define the Bayes data type as a wrapper around a distribution.
The fourth line says that we’re implementing the Bayesian classifier using the HomTrainer type class. We do this because the Haskell compiler automatically generates a parallel batch training function, an online training function, and a fast cross-validation function for all HomTrainer instances.
The fifth line says that our data points have the same type as the underlying distribution.
The sixth line says that in order to train, just train the corresponding distribution.

We only get the benefits of the HomTrainer type class because the bayesian classifier is a monoid. But we didn’t even have to specify what the monoid instance for bayesian classifiers looks like! In this case, it’s automatically derived from the monoid instances for the base distributions using a language extension called GeneralizedNewtypeDeriving. For examples of these monoid structures, check out the algebraic structure of the normal and categorical distributions, or more complex distributions using Markov networks.

The Weka code

Look for these differences between the HLearn and Weka source:

In Weka we must separately define the online and batch trainers, whereas Haskell derived these for us automatically.
Weka must perform a variety of error handling that Haskell’s type system takes care of in HLearn.
The Weka code is tightly coupled to the underlying probability distribution, whereas the Haskell code was generic enough to handle any distribution. This means that while Weka must make the “naive bayes assumption” that all attributes are independent of each other, HLearn can support any dependence structure.
Weka’s code is made more verbose by for loops and if statements that aren’t necessary for HLearn.
The Java code requires extensive comments to maintain readability, but the Haskell code is simple enough to be self-documenting (at least once you know how to read Haskell).
Weka does not have parallel training, fast cross-validation, data point subtraction, or weighted data points, but HLearn does.

/**
   * Generates the classifier.
   *
   * @param instances set of instances serving as training data 
   * @exception Exception if the classifier has not been generated 
   * successfully
   */
  public void buildClassifier(Instances instances) throws Exception {

    // can classifier handle the data?
    getCapabilities().testWithFail(instances);

    // remove instances with missing class
    instances = new Instances(instances);
    instances.deleteWithMissingClass();

    m_NumClasses = instances.numClasses();

    // Copy the instances
    m_Instances = new Instances(instances);

    // Discretize instances if required
    if (m_UseDiscretization) {
      m_Disc = new weka.filters.supervised.attribute.Discretize();
      m_Disc.setInputFormat(m_Instances);
      m_Instances = weka.filters.Filter.useFilter(m_Instances, m_Disc);
    } else {
      m_Disc = null;
    }

    // Reserve space for the distributions
    m_Distributions = new Estimator[m_Instances.numAttributes() - 1]
      [m_Instances.numClasses()];
    m_ClassDistribution = new DiscreteEstimator(m_Instances.numClasses(), 
                                                true);
    int attIndex = 0;
    Enumeration enu = m_Instances.enumerateAttributes();
    while (enu.hasMoreElements()) {
      Attribute attribute = (Attribute) enu.nextElement();

      // If the attribute is numeric, determine the estimator 
      // numeric precision from differences between adjacent values
      double numPrecision = DEFAULT_NUM_PRECISION;
      if (attribute.type() == Attribute.NUMERIC) {
	m_Instances.sort(attribute);
	if ( (m_Instances.numInstances() > 0)
	    && !m_Instances.instance(0).isMissing(attribute)) {
	  double lastVal = m_Instances.instance(0).value(attribute);
	  double currentVal, deltaSum = 0;
	  int distinct = 0;
	  for (int i = 1; i < m_Instances.numInstances(); i++) { 	    
            Instance currentInst = m_Instances.instance(i); 	    
              if (currentInst.isMissing(attribute)) {
                break; 	    
              }
 	    currentVal = currentInst.value(attribute);
 	    if (currentVal != lastVal) {
 	      deltaSum += currentVal - lastVal;
 	      lastVal = currentVal;
 	      distinct++;
 	    }
 	  }
 	  if (distinct > 0) {
	    numPrecision = deltaSum / distinct;
	  }
	}
      }

      for (int j = 0; j < m_Instances.numClasses(); j++) {
	switch (attribute.type()) {
	case Attribute.NUMERIC: 
	  if (m_UseKernelEstimator) {
	    m_Distributions[attIndex][j] = 
	      new KernelEstimator(numPrecision);
	  } else {
	    m_Distributions[attIndex][j] = 
	      new NormalEstimator(numPrecision);
	  }
	  break;
	case Attribute.NOMINAL:
	  m_Distributions[attIndex][j] = 
	    new DiscreteEstimator(attribute.numValues(), true);
	  break;
	default:
	  throw new Exception("Attribute type unknown to NaiveBayes");
	}
      }
      attIndex++;
    }

    // Compute counts
    Enumeration enumInsts = m_Instances.enumerateInstances();
    while (enumInsts.hasMoreElements()) {
      Instance instance = 
	(Instance) enumInsts.nextElement();
      updateClassifier(instance);
    }

    // Save space
    m_Instances = new Instances(m_Instances, 0);
  }

And the code for online learning is:

/**
   * Updates the classifier with the given instance.
   *
   * @param instance the new training instance to include in the model 
   * @exception Exception if the instance could not be incorporated in
   * the model.
   */
  public void updateClassifier(Instance instance) throws Exception {

    if (!instance.classIsMissing()) {
      Enumeration enumAtts = m_Instances.enumerateAttributes();
      int attIndex = 0;
      while (enumAtts.hasMoreElements()) {
	Attribute attribute = (Attribute) enumAtts.nextElement();
	if (!instance.isMissing(attribute)) {
	  m_Distributions[attIndex][(int)instance.classValue()].
            addValue(instance.value(attribute), instance.weight());
	}
	attIndex++;
      }
      m_ClassDistribution.addValue(instance.classValue(),
                                   instance.weight());
    }
  }

Conclusion

Every algorithm implemented in HLearn uses similarly concise code. I invite you to browse the repository and see for yourself. The most complicated algorithm is for Markov chains which use only 6 lines for training, and about 20 for defining the Monoid.

You can expect lots of tutorials on how to incorporate the HLearn library into Haskell programs over the next few months.

Subscribe to the RSS feed to stay tuned!

Philip Wadler: Iain Banks

noreply@blogger.com (Philip Wadler) — Tue, 11 Jun 2013 08:24:56 +0000

In April, Iain Banks discovered he had cancer of the gall bladder, and proposed to his girl friend by requesting she `do me the honour of becoming my widow'. Yesterday his death was announced. In his honour, here is something he wrote for the Observer. See also this tribute from Ken McLeod.

These days, I support the idea of an independent Scotland. It's with a heavy heart in some ways; I think I'd still sacrifice an independent Scotland for a socialist UK, but… I can't really see that happening. What I can imagine is England continuing to turn to the right and eventually leaving the EU altogether.

Scotland, though, could have a viable future either as a completely independent country or – more likely – within Europe. The European ideal is taking a battering right now, certainly, and the gloss has come off comparing our prospects to Ireland's or Iceland's, but it remains both possible and plausible that Scotland could become a transparent, low-inequality society on the Scandinavian model, with fair, non-regressive taxes, strong unions, a nuclear-free policy, a non-punitive tertiary education system, enlightened social policies in general and long-term support for green energy programmes.

We'd need to make sure our banks were small enough to fail, and there are problems of poverty, ill health and religious tribalism that will take decades to overcome. But with the advantages and attractions that Scotland already has, and, more importantly, taking into account the morale boost, the sheer energisation of a whole people that would come about because we would finally have our destiny at least largely back in our own hands again – I think we could do it.

And that we should.

Theory Lunch (Institute of Cybernetics, Tallinn): When does an endofunctor derive from an adjunction?

Mon, 10 Jun 2013 11:27:39 +0000

This is the first of two talks based on Andrea Schalk’s very good introduction to monads, which can be retrieved HERE

In the following, if is a category, we indicate by the collection of objects of , and by the collection of morphisms in from to .

As we know, there are two basic ways of defining an adjunction:

Definition 1. Let and be categories; let and be functors. An adjunction from to , written , is a quadruple where (the unit of the adjunction) and (the counit) are natural transformations such that , for every and , and .

Definition 2. Let and be categories. We call adjunction quadruple a quadruple such that:

is a functor,
is a mapping, and
associates to every object a morphism so that
for every there exists a unique such that .

The two definitions above are equivalent in the following sense. If is an adjunction according to Definition 1, and , then is an adjunction quadruple according to Definition 2. On the other hand, if is an adjunction quadruple according to Definition 2, and is the inverse operation of —that is, if and only if —then necessarily , and by putting for and for we define an adjunction according to Definition 1.

If is an adjunction, then is an endofunctor.The first question that comes to our mind is:

when does an endofunctor derive from an adjunction?

Let us check some basic properties such an endofunctor must satisfy. First of all, defined by is a natural transformation and satisfies

Moreover, as is a natural transformation, by choosing we get , which after an application of yields

It will turn out that these two properties are precisely what we need.

Definition 3. A monad on a category is a triple where:

is an endofunctor,
and are natural transformations, and
for every we have and ,

As a very basic example, the free monoid construction is a monad on , where , , , and .

As a less basic example, suppose is a poset: what is a monad on ? First of all, an endofunctor on a poset is a monotone function; next, if there is , then ; finally, if there is , then , which together with the previous inequality yields . On the other hand, any nondecreasing idempotent is the endofunctor component of a monad: the monad equations are actually ensured by being a poset, so that any two maps with same domain and same codomain are equal.

We then restate our original problem as follows:

given a monad , find an adjunction such that and

If the adjunction solves the problem above, we say that it generates the monad .

The first solution to this problem was given by the Swiss mathematician Heinrich Kleisli, and is based on an alternative way of defining monads, as it is the case with adjunctions. Let us suppose with . If , then , so that : and we know from the definition of monad that . We can thus define an operator that takes into in a way such that whatever is. The simplest example is itself, so that , and by uniqueness in the definition of adjunction quadruple. Moreover, if and , then

which implies by uniqueness.

This is the base of Kleisli’s solution to our problem, which we will discuss in a future talk.

Theory Lunch (Institute of Cybernetics, Tallinn): An initial solution to the monad problem, and then some more

Mon, 10 Jun 2013 11:27:02 +0000

This is the second of two talks about monads, based on the very good notes by Andrea Schalk and continuing the one I gave on the 30th of May. Recall that we are trying to solve the following problem:

given a monad , find an adjunction such that and

If the adjunction solves the problem above, we say that it generates the monad .

The first solution to this problem was given by the Swiss mathematician Heinrich Kleisli, and is based on an alternative way of defining monads, as it is the case with adjunctions. Let us suppose with . If , then , so that : and we know from the definition of monad that . We can thus define an operator that takes into so that whatever is. The simplest example is itself, which yields , so that by uniqueness in the definition of adjunction quadruple, and . Moreover, if and , then , which implies by uniqueness.

Definition 4. A Kleisli triple on a category is a triple where:

is a function,
for every , and
for every

such that the following equations are satisfied:

for every ;
for every ;
for every , .

If is an adjunction quadruple then is a Kleisli triple.

Theorem 1. Let be a category.

If is a monad on , and if for every , then is a Kleisli triple on .
If is a Kleisli triple on , and if for every and for every , then is a monad on .
The two operations from the previous points are each other’s converse.

Proof: Point 1 follows from naturality of and and the three monad laws:

For point 2, functoriality of , naturality of and , and monad laws follow from Kleisli laws:

Point 3 is straightforward.

Considering again the free monoid example, the corresponding Kleisli triple has

Theorem 1 says that we can restate our problem as follows:

given a Kleisli triple , find an adjunction quadruple such that and

If with , then for every there is an isomorphism : this observation is at the base of Kleisli’s construction.

Definition 5. Let be a Kleisli triple on a category . The Kleisli category of is the category defined as follows:

;
;
, that is, the identity of in is ;
, that is, the composition of and in is the composition of and in .

Theorem 2. is a category.

Proof: If , then and by the Kleisli laws. If , , and , then

Our plan is to construct an adjunction quadruple , with and , such that and for every . We do this as follows:

for every ;
for every ;
for every ;
for every .

Let us quickly check that is indeed a functor. If then . If and , then . We are only left to determine, for every , a unique such that : but the entire construction leads to the choice ! Indeed, , and by the Kleisli laws. Observe that the functor is the one that does all the work, while the function is little more than a placeholder.

By our identification of adjunctions with adjunction quadruples (see the previous talk) we also get for every , and for every .

Kleisli’s solution is not the only one, but just one among many: and, in a sense that will be clear later, the “simplest” one. Another solution was constructed by Eilenberg and Moore, and is based on a completely different approach: instead of keeping the objects and specializing the morphisms, one expands the objects and redefines the morphisms.

Definition 6. Let be a category and let be a monad on .

A -algebra on is a pair where is an object in and is such that and .
A morphism of -algebras from a -algebra to a -algebra is an arrow such that .
The category of -algebras on is the category which has -algebras as objects, morphisms of -algebras as morphisms, and where identities and composition are defined as in .

If is the free monoid construction, then an -algebra is a function such that

for every , and
for every .

As is a monad, for every object of there is a free -algebra , and every arrow induces a morphism of free -algebras . Moreover, any is, by definition, also a morphism from to in .

This time, our plan is to construct an adjunction such that , , , and for every . We do this as follows:

;
;
if ;
;
for every .

Then clearly , while naturality of follows from the properties of free -algebras with respect to -algebra morphisms. In addition, if then , and if then . We thus have a full-featured adjunction: this time, is doing all the work, and is just a forgetful functor.

Theorem 3. Let be a monad on a . Identify the monad with the corresponding Kleisli triple . The Kleisli category is equivalent to the full subcategory of generated by the free -algebras.

Proof: Define a functor by setting for every , and for every . Then is a faithful functor, because if , then and similarly , so that if . But is also full, because if is a morphism of free -algebras, then from the laws of monads follows that .

But things get even more interesting than this! Let be a monad: let us consider all the adjunctions that generate . What can be a morphism of such adjunctions? First, if is a solution with , and is a solution with , we may consider a functor as a morphism from to . Next, we want that the equalities are not affected by mid-way application of : this translates into the two conditions and . Finally, as the previous point yields , we want that does not interfere with the counits: that is, .

Definition 7. Let be a monad on a category and let , be two adjunctions that generate , with and , respectively. A -preserving functor from to is a functor such that , , and .

It is straightforward to see that -generating adjunctions together with -preserving functors form a category : composition is provided by the usual composition of functors, while the identity of in is the identity functor of if .

To confirm that our intuition is correct, let us verify that satisfies the three given equations:

;
;
;
;
.

Theorem 4. Let be a monad. Then the Kleisli adjunction is the initial object of , the Eilenberg-Moore adjunction is the final object. In particular, is the only arrow in from the former to the latter.

Proof: If is the Kleisli adjunction, then the only choice for is and . If is the Eilenberg-Moore adjunction, then the only choice for is and .

Ken T Takusagawa: [sjhltpdo] Unscope symbol

noreply@blogger.com (Ken) — Mon, 10 Jun 2013 08:49:00 +0000

let { foo = ... } in let { hide foo } in foo

This should cause the compiler to signal an error. We wish to assert that a certain symbol is not used within an inner scope, perhaps to avoid programmer typos of similar symbols. "hide foo" can also be a statement in do notation.

If we have local imports, then perhaps syntax like let { import OUTER-SCOPE hiding (foo) }, where OUTER-SCOPE is a new keyword.

We could also hide everything in the outer scope except a few symbols. let { import OUTER-SCOPE(foo); import Prelude }.

wren ng thornton: Dungeon World: Assassin class

Sun, 09 Jun 2013 00:32:03 +0000

After far too long, I've finally found a new roleplaying group. We're using Dungeon World, a lightweight system I've never used before. It's a class-based system, which I've never been too fond of, but it does seem like it gets rid of most of the things I hate about class-based systems. The core book only gives the standard D&D-style classes, but they give some guidelines on making up your own classes. For my character I worked with the GM to come up with a new Assassin class which combines some of the traits of the Thief and the Fighter. I tried to make sure it's balanced against the other classes and doesn't obviate the Thief/Fighter, but not having used DW before it's hard to be sure. If you've used DW and have any comments, I'd be interested in hearing them.

Edit: I've posted a new version which adjusts the damage option for the Death Dealer and Assassin's Strike moves. Also included is a discussion about how different ways of doing DD/AS would affect DPS, which is necessary for doing a fair comparison against other classes. If you run a game with this class, let me know how it goes.

comments

Paul Potts: Objective-C, Day 5

noreply@blogger.com (Paul Potts) — Fri, 07 Jun 2013 23:17:00 +0000

(Warning: non-FP content). (I've been including this for the benefit of any "Planet X" aggregators who are including my feed, where X is a functional language like Haskell. I'm assuming you've got that by now and either don't care or are unsubscribing/ignoring this series if it bothers you. I expect to get back to more functional language code at some point, maybe even implementing the same problem. But I dabble in different languages and sometimes the digressions go on for a while...)

So, today's topic is dispatch. I'm starting to design and implement the logic for pieces interacting on the board. The key in object-oriented designs is always to determine who (which object) manages which state. The design I've come up with is a sort of hybrid design, where position on the board is not actually a property of the board tiles. Instead, there's a board which keeps track of them. The instances of, say, a tree on the board don't have any unique state, so I'm not instantiating different objects for each one; they all point to a singleton (which I should properly enforce with a singleton factory method at some point).

There are trade-offs. On paper, my design involved adding a "push" method to the classes for tile pieces. In a language like Dylan, this "push" method would be a generic function, and dispatch on multiple parameter types, so that I could write some very short methods and use the method dispatcher, instead of explicit if-then or switch logic to find the right bit of code at run-time according to the types of the interacting objects (either their literal types or an enum, or some such). I could even do this in C++ because it has method overloading based on the parameters -- as long as this is based on their static type known at compile-time. Which... isn't true in this case. I miss Dylan's generic function dispatch! Objective-C is a underpowered in this respect even compared to C++. For example, I'd like to be able to write methods like this for the bomb class (this is pseudocode):

bomb::push(mountain)
{
    // blow up the mountain
}

bomb::push(empty)
{
    // slide the bomb onto the tile
}

But I can't. I can't just use the class construct to organize methods to call without an instance -- there doesn't seem to be the equivalent of C++ static methods. There also is no equivalent of a pure virtual function; I can't declare the need for a push() method in the common base class of the tile pieces and have the compiler demand that I implement in any subclasses to make them instantiable. The closest I can come, I think, is to create a method that generates an error if it itself is called instead of being overridden in a subclass. That seems to lack semantic clarity. So maybe I could do this, with double dispatch, but it doesn't seem worth the trouble for a small number of collision behaviors, when the behavior isn't simply supported by the language. I keep telling myself "thin layer on top of C... thin layer on top of C..."

So last night I had my Mac running upstairs in the office, and I used my iPad downstairs to connect to it via VNC, and write some code, running it on the iPad simulator, which I then viewed and controlled with a real iPad (mad scientist laugh). It needs a little tweaking this morning but here's more-or-less what I came up with. Note that I have started using some different naming conventions for file-scope and local variables. I'm not sure they are very standard Objective-C but they are closer to what I've grown comfortable with over the years in C and C++.

typedef struct {
    int x_idx;
    int y_idx;
} pos_t;

typedef enum {
    dir_east,
    dir_west,
    dir_south,
    dir_north
} dir_e;

// A straight C function to return a pos_t updated with a dir_e;
// the result may be out of bounds
pos_t getUpdatedPos( pos_t original_pos, dir_e dir );
BOOL posValid( pos_t pos );

static const int board_width = 24, board_height = 4;
// The short board design is part of what makes it so
// easy to get sliding objects stuck against the edges
// of the world or in corners where you can't get the
// penguin avatar around to the other side to push them.
// We could consider a bigger board later and maybe
// implement the original puzzles surrounded by water,
// or something like that.

// Equivalent of C++ class forward declaration
@class ArcticSlideTile;
@class ArcticSlideBomb;
@class ArcticSlideEmpty;
@class ArcticSlideHeart;
@class ArcticSlideHouse;
@class ArcticSlideIceBlock;
@class ArcticSlideMountain;
@class ArcticSlideTree;

@interface ArcticSlideModel : NSObject
{
    ArcticSlideTile* board[board_height][board_width];
}

- (id)init;
- (id)initWithLevelIndex:(int)level_idx;
- (NSString*) description;
- (ArcticSlideTile*)getTileFromPosition:(pos_t)pos
                            inDirection:(dir_e)dir;
- (void)setTileAtPosition:(pos_t)pos
                       to:(ArcticSlideTile*)type;

@end

@interface ArcticSlideTile : NSObject

- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;

@end


@interface ArcticSlideBomb : ArcticSlideTile
// Bombs can be pushed and will slide until they hit an
// object and stop. If the object is a mountain, both bomb
// and mountain are destroyed. If another object hits a bomb
// it stops (I think -- I'm not sure it is possible to set 
// up a board such that you can slide something into a bomb).

// push is called when the penguin pushes against a tile.
// It returns YES if the penguin can move onto the tile with
// this action. This is only ever the case for a tree or empty
// tile.
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (NSString*) description;
@end

@interface ArcticSlideEmpty : ArcticSlideTile
// The penguin can always step onto an empty tile
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (BOOL)slideFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (NSString*) description;
@end

@interface ArcticSlideHeart : ArcticSlideTile
// When a heart hits a house the heart disappears (getting
// all the hearts into the house is how you win the game).
// Otherwise they cannot be destroyed, and slide like other
// slidable items.
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (NSString*) description;
@end

@interface ArcticSlideHouse : ArcticSlideTile
// Houses cannot be pushed and stop other objects except
// hearts. When a heart hits a house the heart disappears
// (getting the hearts into the house is how you win the game).
// So the model should keep track of the number of hearts
// on the board and trigger a "win the level" behavior when
// the last heart is removed.
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (NSString*) description;
@end

@interface ArcticSlideIceBlock : ArcticSlideTile
// Ice blocks can be pushed and will slide until they hit
// an object and stop. If they are pushed directly against
// an object they will be crushed (there should be an animation)
// and disappear.
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (NSString*) description;
@end

@interface ArcticSlideMountain : ArcticSlideTile
// Mountains cannot be moved and are destroyed by bombs.
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (NSString*) description;
@end

@interface ArcticSlideTree : ArcticSlideTile
// Trees cannot be pushed or destroyed and stop all sliding
// objects, but the penguin avatar character can walk through
// them.
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir;
- (NSString*) description;
@end

Here's part of the implementation. It seems way too wordy; I need to rethink the amount of code required for each step. At the least, some refactoring seems to be in order. As I mentioned earlier, I'm not sure the tile classes are really earning their keep. I got rid of the singleton instantiation machinery but now there are order of initialization dependencies. I'll need to do further thinking as I consider what communication needs to happen between the "model" part and "controller" part -- how to interact with the GUI, how to indicate that tiles need to be redrawn, or animated transitions should play, or sound effects should play, or that the score is changed, and what to do when a level is completed. There is lots more to think about for such a simple little game! And of course I haven't really even begun to implement the "view" parts.

static ArcticSlideEmpty* empty_p;
static ArcticSlideTree* tree_p;
static ArcticSlideMountain* mountain_p;
static ArcticSlideHouse* house_p;
static ArcticSlideIceBlock* ice_block_p;
static ArcticSlideHeart* heart_p;
static ArcticSlideBomb* bomb_p;

static ArcticSlideModel* model_p;

pos_t getUpdatedPos( pos_t original_pos, dir_e dir )
{
    pos_t updated_pos = original_pos;
    int x_offset = 0;
    int y_offset = 0;
    if ( dir_east == dir )
    {
        x_offset = 1;
        y_offset = 0;
    }
    else if ( dir_west == dir )
    {
        x_offset = -1;
        y_offset = 0;
    }
    else if ( dir_north == dir )
    {
        x_offset = 0;
        y_offset = -1;
    }
    else if ( dir_south == dir )
    {
        x_offset = 0;
        y_offset = +1;
    }
    updated_pos.x_idx += x_offset;;
    updated_pos.y_idx += y_offset;
    return updated_pos;
}

BOOL posValid( pos_t pos )
{
    return ( ( ( pos.x_idx >= 0 ) ||
               ( pos.x_idx < board_width  ) ) ||
             ( ( pos.y_idx >= 0 ) ||
               ( pos.y_idx < board_height ) ) );
}

@implementation ArcticSlideTile

- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir
{
    // Should be implemented in subclass
    return NO;
}

@end

@implementation ArcticSlideBomb

- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir
{
    // Penguin has pushed bomb in the given direction.
    // Get our own position:
    pos_t bomb_pos = getUpdatedPos( pos, dir );
    // What are we being pushed into?
    ArcticSlideTile *target_tile_p =
    [model_p getTileFromPosition:bomb_pos
                     inDirection:dir];
    
    if ( nil == target_tile_p )
    {
        // Edge of the world. TODO:
        // queue a "boop" sound effect
    }
    else if ( mountain_p == target_tile_p )
    {
        // bomb pushed into mountain
        // TODO: queue animation of bomb moving onto
        // mountain, animate explosion
        // remove bomb and mountain
        pos_t new_bomb_pos = getUpdatedPos( bomb_pos, dir );
        [model_p setTileAtPosition:new_bomb_pos
                                to:empty_p];
        new_bomb_pos = getUpdatedPos( new_bomb_pos, dir );
        [model_p setTileAtPosition:new_bomb_pos
                                to:empty_p];
    }
    else if ( empty_p == target_tile_p )
    {
        // TODO: queue bomb moving into space
        pos_t new_bomb_pos = getUpdatedPos( bomb_pos, dir );
        // Set bomb at new position
        [model_p setTileAtPosition:new_bomb_pos
                                to:bomb_p];
        // Remove bomb from old position
        [model_p setTileAtPosition:bomb_pos
                                to:empty_p];

        // Bombs will continue to slide until stopped
        ArcticSlideTile *target_tile_p =
        [model_p getTileFromPosition:new_bomb_pos
                         inDirection:dir];

        while ( empty_p == target_tile_p )
        {
            // TODO: animate bomb moving into space
            pos_t new_bomb_pos = getUpdatedPos( bomb_pos, dir );
            // set bomb at new position
            [model_p setTileAtPosition:new_bomb_pos
                                    to:bomb_p];
            // remove bomb from old position
            [model_p setTileAtPosition:bomb_pos
                                    to:empty_p];
        }

        if ( mountain_p == target_tile_p )
        {
            // bomb pushed into mountain
            // TODO: queue animation of bomb moving
            // onto mountain, animate explosion
            // remove bomb and mountain
            [model_p setTileAtPosition:new_bomb_pos
                                    to:empty_p];
            new_bomb_pos = getUpdatedPos( new_bomb_pos, dir );
            [model_p setTileAtPosition:new_bomb_pos
                                    to:empty_p];
        }
    }
    // The penguin cannot actually move in this turn
    return NO;
}

- (NSString*) description
{
    return @"Bomb  ";
}

@end

@implementation ArcticSlideEmpty
- (BOOL)pushFromPosition:(pos_t)pos inDirection:(dir_e)dir
{
    // If the penguin pushes onto an empty tile, he can always
    // move there
    return YES;
}

- (NSString*) description
{
    return @"      ";
}
@end

I'm leaving out unfinished tile classes for clarity, but here is the model implementation:

@implementation ArcticSlideModel

- (id)init
{
    // Initialize the global tile objects. I messed around
    // with singleton factory methods for creating a single
    // instance of each of these and accessing it everywhere
    // but the resulting code was too wordy to justify this.

    empty_p = [[ArcticSlideEmpty alloc] init];
    tree_p = [[ArcticSlideTree alloc] init];
    mountain_p = [[ArcticSlideMountain alloc] init];
    house_p = [[ArcticSlideHouse alloc] init];
    ice_block_p = [[ArcticSlideIceBlock alloc] init];
    heart_p = [[ArcticSlideHeart alloc] init];
    bomb_p = [[ArcticSlideBomb alloc] init];

    self = [super init];

    for ( unsigned int idx_y = 0;
         idx_y < board_height; idx_y++ )
    {
        for ( unsigned int idx_x = 0;
             idx_x < board_width; idx_x++ )
        {
            board[idx_y][idx_x] = empty_p;
        }
    }

    return self;
}

- (id)initWithLevelIndex:(int)level_idx
{
    self = [self init];

    // Lookup table to decode the original Polar resource
    // data as strings
    ArcticSlideTile *
        polar_data_tile_map[POLAR_DATA_NUM_TILE_VALS] =
    {
        empty_p, tree_p, mountain_p, house_p, ice_block_p,
        heart_p, bomb_p
    };

    if ( level_idx > ( num_polar_levels - 1) )
    {
        NSLog(@"initWithLevelIndex: bad level_idx %d!\n",
              level_idx);
    }
    else
    {
        unsigned int level_data_idx = 0;
        for ( unsigned int idx_y = 0;
             idx_y < board_height; idx_y++ )
        {
            for ( unsigned int idx_x = 0;
                 idx_x < board_width; idx_x++ )
            {
                int polar_data_tile_val =
                    polar_levels[level_idx]
                                [level_data_idx] - '0';
                if ( ( polar_data_tile_val < 0 ) ||
                     ( polar_data_tile_val > 
                       polar_data_max_tile_val ) )
                {
                    NSLog(@"tile value %d out of range!\n",
                          polar_data_tile_val );
                    self = nil;
                }
                else
                {
                    board[idx_y][idx_x] =
                        polar_data_tile_map[polar_data_tile_val];
                    level_data_idx++;
                }
            }
        }
    }

    return self;

}

- (ArcticSlideTile*)getTileFromPosition:(pos_t)pos 
                            inDirection:(dir_e)dir
{
    pos_t updated_pos = getUpdatedPos(pos, dir);
    if ( posValid( updated_pos ) )
    {
        return board[updated_pos.y_idx]
                    [updated_pos.x_idx];
    }
    else
    {
        return nil;
    }
}

- (NSString*)description
{
    NSMutableString *desc_str =[[NSMutableString alloc]init];
    
    [desc_str appendString:@"ArcticSlideModel board state:\n"];
    for ( unsigned int idx_y = 0;
         idx_y < board_height; idx_y++ )
    {
        for ( unsigned int idx_x = 0;
             idx_x < board_width; idx_x++ )
        {
            [desc_str appendString:[board[idx_y][idx_x] 
                                    description]];
        }
        [desc_str appendString:@"\n"];
    }
    return desc_str;
}

- (void)setTileAtPosition:(pos_t)pos to:(ArcticSlideTile*)type
{
    board[pos.y_idx][pos.x_idx] = type;
}

@end

It's not much yet, and it doesn't have any kind of user interface outside of NSLog, but my code will successfully respond to moving the penguin through trees, through open space, and pushing a bomb, which then moves into an open space, continues to slide until it comes up against a mountain, and destroys the mountain. I'm driving this with a test method like this:

NSLog(@"%@\n", model_p);
// Penguin starts at 0,0, on a tree tile
pos_t penguin_pos = { 0, 0 };

// Walk the penguin south onto another tree tile
ArcticSlideTile* tile_p =
[model_p getTileFromPosition:penguin_pos 
                 inDirection:dir_south];
NSLog(@"Penguin is facing: %@\n", tile_p);
BOOL allowed = [tile_p pushFromPosition:penguin_pos
                            inDirection:dir_south];
NSLog(@"Penguin allowed: %s\n", ( allowed ? "YES" : "NO" ) );
tile_p = [model_p getTileFromPosition:penguin_pos
                              inDirection:dir_south];
penguin_pos = getUpdatedPos(penguin_pos, dir_south);
NSLog(@"Penguin is facing: %@\n", tile_p);
    
// Walk the penguin east onto an empty space
tile_p = [model_p getTileFromPosition:penguin_pos
                              inDirection:dir_east];
NSLog(@"Penguin is facing: %@\n", tile_p);
allowed = [tile_p pushFromPosition:penguin_pos
                       inDirection:dir_east];
NSLog(@"Penguin allowed: %s\n", ( allowed ? "YES" : "NO" ) );
tile_p = [model_p getTileFromPosition:penguin_pos
                          inDirection:dir_east];
penguin_pos = getUpdatedPos(penguin_pos, dir_east);

// Try walking into a bomb, which should slide
// and blow up a mountain
tile_p = [model_p getTileFromPosition:penguin_pos
                          inDirection:dir_east];
NSLog(@"Penguin is facing: %@\n", tile_p);
allowed = [tile_p pushFromPosition:penguin_pos
                           inDirection:dir_east];
NSLog(@"Penguin allowed: %s\n", ( allowed ? "YES" : "NO" ) );

NSLog(@"%@\n", model_p);

I'll think on this whole model of updates some more. Maybe it can be even simpler. And I have to consider how the penguin state will be managed, including its orientation (in the original, the penguin can face in the cardinal directions). Should I preserve that in a touch-driven game user interface?

FP Complete: FP Complete Launches Haskell in Real World Competition

Fri, 07 Jun 2013 19:18:00 +0000

FP Complete Launches Haskell in Real World Competition with $1,000 Cash Prize Each Month

I’m very excited to announce our Haskell in Real World contest: a call out for sample Haskell code and tutorials of real-world engineering and business solutions. Each entry consists of a working solution to an applied problem, plus accompanying tutorial material to teach others how to build similar programs.

The winning entry each month will get $1,000 cash prize. There may be multiple prizes each month or none at all if none meet the winning criteria. There are no limits on how many prizes each individual, team or group can win in any month or the duration of the contest. In other words, you can make some serious play money here! Anyone not affiliated with FP Complete is eligible to enter.

Why are we doing this? Simple: because the Haskell community needs to vastly expand for Haskell to become a mainstream language. To do this we must show people how to use this amazing language in solving real-world business problems. People tell us they need to see running and documented examples of real-world problems and solutions, so they can quickly see how to design their own working solutions. They also want material to show their colleagues and bosses just how useful Haskell is today. In essence this contest intends to compile recipes which, taken together, could be seen as an applied Haskell cookbook.

The competition starts in July. Official Rules and sign-ups will be published on our website www.fpcomplete.com at the end of June / early July. So check back then and let the games begin!

Simon Michael: Blog tinkering, hledger.org

Fri, 07 Jun 2013 01:00:00 +0000

June 7, 2013

Blog tinkering, hledger.org

A better ghci fix

I forgot to commit last night’s ghci fix, which is good because I improved it today, fixing the code duplication.

Blog tinkering

Thanks to help from #hakyll, I spent some time figuring out how to safely update published blog posts without having them reappear as new on Planet Haskell. The problem seemed to be that I wasn’t setting a separate updated date, which caused the published date to change, which caused the post to reappear as new, at least in my feed reader.

Solution: Start blog posts with metadata like this:

---
title:     6/6
author:    Simon Michael
published: 2013-06-06 16:00:00PDT
updated:   2013-06-06 17:00:00PDT
---

hledger.org

Worked on the next hledger backlog item, improving the website update process. Did some file cleanup and testing.

I found that I had broken hledger.org several days ago, when I gratuitously enhanced:

RewriteRule ^/bugs?/?$   https://github.com/simonmichael/hledger/issues [L,NE]

to:

RewriteRule ^/(bugs|issues)?/?$   https://github.com/simonmichael/hledger/issues [L,NE]

Doh. Fixed it:

RewriteRule ^/(bugs?|issues)/?$   https://github.com/simonmichael/hledger/issues [L,NE]

Next: yes, the cron job for updating the site is reporting an error - though it seems to successfully update the site all the same:

From github.com:simonmichael/hledger
   47ebc21..e87f492  master     -> origin/master
Updating 47ebc21..e87f492
Fast-forward
 README.md |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
cd site; ghc site.hs -L/usr/lib -package-db ~/src/joyful.com/cabal-dev/packages-*.conf
cd site; ./site build
Initialising...
  Creating store...
  Creating provider...
  Running rules...
Checking for out-of-date items
Compiling
site: _site/README.html: commitBuffer: invalid argument (invalid character)
  updated README.md
make: *** [site] Error 1

Re-enabling export LANG=en_US.UTF-8 in the Makefile seems to have fixed it. I have a non-ascii character in the site footer. Setting the LANG environment variable is the quick way to configure a locale, which used to be very much required to avoid encoding errors with GHC 6, but which I thought was less necessary with GHC 7. Perhaps not.

Paul Potts: Objective-C, Day 4

noreply@blogger.com (Paul Potts) — Thu, 06 Jun 2013 19:06:00 +0000

(Warning: more non-FP content)

It's time to get the board representation filled out with a real board. I've only got a couple of hours left before I have to pack up my computer to leave my Undisclosed Location, but let's see if I can get a little more done. Let's review what level 1 looks like:

Level layouts are taken from the original Macintosh Polar game created by Go Endo. These were originally MacOS resources of type 'STGE.' Let's see if we can decode them. Using ResEdit, the raw data for 'STGE' resource ID -16000 looks like:

0x0000 0x0000 0x0003 0x0001
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0001 0x0000
0x0000 0x0000 0x0000 0x0000
0x0004 0x0000 0x0000 0x0001
0x0000 0x0006 0x0000 0x0002
0x0000 0x0005 0x0004 0x0005
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0001 0x0000 0x0000
0x0001 0x0000 0x0000 0x0001
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0005
0x0000 0x0000 0x0000 0x0002
0x0003 0x0000 0x0000 0x0001
0x0001 0x0000 0x0000 0x0000
0x0000 0x0001 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000 0x0000
0x0000 0x0000 0x0000

There are 99 16-bit values. My best guess is that this corresponds to the 24x4 grid (96 board positions) plus 3 extras for some kind of of header of footer data (maybe the total number of hearts is indicated, for example). There are 7 unique values, so it seems extremely likely that they correspond almost exactly to our eight different tile types, with zero representing a blank space. But the counts of each type don't _quite_ match up. The first board has 8 trees, 1 bomb, 2 hearts, 2 ice blocks, 2 mountains, 3 hearts, 1 house, and 1 penguin (there is always 1 penguin), while this 'STGE' resource has: 9 ones, 2 twos, 2 threes, 2 fours, 3 fives, and 1 six. The counts are very close, so this has to represent level 1, and the the 5 almost certainly represents a heart, but I'm not clearly seeing the layout. The first vertical column goes penguin, tree, tree, tree. I don't quite see a pattern that looks like that, but resources -1599 and -15996 give me a hint that the "extra" data is at the front: they contain 0x0007 and 0x0008 as their third values. Those don't appear anywhere else so they probably don't indicate tiles. So let's try rearranging resource -16000 without the first 6 bytes, remove redundant zeroes for clarity, and looking at the values aligned by groups of 24 instead of 4:

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 4 0 0
1 0 6 0 2 0 5 4 5 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 0 0 0 2 3 0 0
1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

There's the board. The left column is actually all trees -- when the board first appears, the penguin is hiding a tree. There are actually nine trees. So the encoding looks like so: empty space = 0, tree = 1, mountain = 2, home = 3, ice block = 4, heart = 5, and bomb = 6. The penguin doesn't have a value, but his starting position is probably represented by the first two values, (0,0), most likely encoded as row index, column index to correspond to row-major indexing, and there are 3 hearts to count down as the game is solved.

Can we validate this with the second board? Yes, it looks like there's a 4 indicating 4 hearts. In all the boards I've seen so far (the first four), the penguin is in the upper left. The fifth resource has 0, 1 for its first two values, so I'm guessing I can confirm the encoding of the penguin's position if and when I get to that stage.

And now to come up with a quick way to populate the board in my code. As I'm still a complete n00b in Objective-C, and on the general principle that there's no real need to make this any more clever or less obvious than it has to be, let's just use a string with the data from the resource. Let's add an init method to the interface for the model class:

- (id)initWithLevelIndex:(int)level_idx;

And here is some data, and an initializer method:

static const int num_polar_levels = 1;
static const int polar_data_len = 96;
static const int polar_data_num_tile_vals = 7; // 0-6 inclusive
static const int polar_data_max_tile_val = 6;
static const NSString *polar_levels[num_polar_levels] =
{
    @"100000000000000100000400" \
    @"106020545000000000100100" \
    @"100000000000000050002300" \
    @"110000100000000000000000"
};

- (id)initWithLevelIndex:(int)level_idx
{
    // Call our own basic initializer. This will 
    // result in redundant setting of board values,
    // but maybe I will clean that up later.
    self = [self init];

    // A simple lookup table to decode the original
    // Polar resource data as strings
    ArcticSlideTile 
        *polar_data_tile_map[polar_data_num_tile_vals] = {
        empty, tree, mountain, house,
        ice_block, heart, bomb };

    if ( level_idx > ( num_polar_levels - 1) )
    {
        NSLog( @"initWithLevelLayout: level %d out of range!\n",
               level_idx );
        self = nil;
    }
    else
    {
        const NSString* level_str = polar_levels[level_idx];
        unsigned int level_data_idx = 0;
        for ( unsigned int idx_y = 0;
             idx_y < board_height; idx_y++ )
        {
            for ( unsigned int idx_x = 0;
                 idx_x < board_width; idx_x++ )
            {
                NSRange range = NSMakeRange(level_data_idx, 1);
                const NSString * item_str =
                    [level_str substringWithRange: range];
                int polar_data_tile_val = [item_str intValue];
                if ( polar_data_tile_val >
                    polar_data_max_tile_val )
                {
                    NSLog(@"tile val %d out of range!\n",
                        polar_data_tile_val );
                    self = nil;
                }
                else
                {
                    board[idx_y][idx_x] =
                        polar_data_tile_map[polar_data_tile_val];
                    level_data_idx++;
                }
            }
        }
    }
    return self;
}

Hmmm, that seems overly complicated. There probably is a better, more idiomatic Objective-C way to use NSStrings for that, but I'm tempted to just write it with a basic C string. Using NSString objects in this context didn't even really help me catch bugs or avoid crashes, since I had forgotten to initialize a heart object and the result was hitting a nil object pointer at runtime and crashing, pretty much the same result as dereferencing a null pointer in straight C except with a better error logged. I'm a little disconcerted by Objective-C's inability to allocate objects on the stack, but that comes down to the aforementioned "thin veneer" over C. I don't really care about the overhead in using method dispatch in this simple piece of code operating on such a small amount of data, but I do care about simplicity. Just to compare, here's a more straightforward C implementation of that inner loop:

static const char *polar_levels[num_polar_levels] =
{
    "100000000000000100000400"
    "106020545000000000100100"
    "100000000000000050002300"
    "110000100000000000000000"
};

int polar_data_tile_val = level_str_p[level_data_idx] - '0';
if ( ( polar_data_tile_val < 0 ) || 
     ( polar_data_tile_val > 
       polar_data_max_tile_val ) )
{
    NSLog(@"polar data tile value %d out of range!\n",
          polar_data_tile_val );
    self = nil
}

Maybe the lesson here is "use Objective-C objects only when objects are a win."

I'm going to continue with this project, developing the code to handle the interactions of objects on the playing field and eventually the user interface. However, now that my week away from home is done, I might not be able to make progress very quickly. Stay tuned -- I'll post what I can, when I can. As always, if you have any comments or questions, I'm happy to have feedback.

Tom Schrijvers: PPDP '13: Last Call for Papers

noreply@blogger.com (Tom Schrijvers) — Thu, 06 Jun 2013 15:56:18 +0000

=====================================================================

Last Call for papers
15th International Symposium on
Principles and Practice of Declarative Programming
PPDP 2013

Special Issue of Science of Computer Programming (SCP)

Madrid, Spain, September 16-18, 2013
(co-located with LOPSTR 2013)

http://users.ugent.be/~tschrijv/PPDP2013/

======================================================================

PPDP 2013 is a forum that brings together researchers from the declarative
programming communities, including those working in the logic, constraint and
functional programming paradigms, but also embracing a variety of other
paradigms such as visual programming, executable specification languages,
database languages, and knowledge representation languages.

The goal is to stimulate research in the use of logical formalisms and methods
for specifying, performing, and analysing computations, including mechanisms
for mobility, modularity, concurrency, object-orientation, security,
verification and static analysis. Papers related to the use of declarative
paradigms and tools in industry and education are especially solicited. Topics
of interest include, but are not limited to:

* Functional programming
* Logic programming
* Answer-set programming
* Functional-logic programming
* Declarative visual languages
* Constraint Handling Rules
* Parallel implementation and concurrency
* Monads, type classes and dependent type systems
* Declarative domain-specific languages
* Termination, resource analysis and the verification of declarative programs
* Transformation and partial evaluation of declarative languages
* Language extensions for security and tabulation
* Probabilistic modelling in a declarative language and modelling reactivity
* Memory management and the implementation of declarative systems
* Practical experiences and industrial application

This year the conference will be co-located with the 23nd International
Symposium on Logic-Based Program Synthesis and Transformation (LOPSTR 2013) and
held in cooperation with ACM SIGPLAN. The conference will be held in Madrid,
Spain. Previous symposia were held at Leuven (Belgium), Odense (Denmark),
Hagenberg (Austria), Coimbra (Portugal), Valencia (Spain), Wroclaw (Poland),
Venice (Italy), Lisboa (Portugal), Verona (Italy), Uppsala (Sweden), Pittsburgh
(USA), Florence (Italy), Montreal (Canada), and Paris (France).

Papers must describe original work, be written and presented in English, and
must not substantially overlap with papers that have been published or that are
simultaneously submitted to a journal, conference, or workshop with refereed
proceedings. Work that already appeared in unpublished or informally published
workshop proceedings may be submitted (please contact the PC chair in case of
questions). Proceedings will be published in the ACM International Conference
Proceedings Series.

After the symposium, a selection of the best papers will be invited to extend
their submissions in the light of the feedback solicited at the symposium. The
papers are expected to include at least 30% extra material over and above the
PPDP version. Then, after another round of reviewing, these revised papers will
be published in a special issue of SCP with a target publication date by
Elsevier of 2014.

Important Dates

Abstract Submission: June 10, 2013
Paper submission: June 13, 2013
Notification: July 18, 2013
Camera-ready: August 4, 2013

Symposium: September 16-18, 2013

Invites for SCP: October 2, 2013
Submission of SCP: December 11, 2013
Notification from SCP: February 22, 2014
Camera-ready for SCP: March 14, 2014

Authors should submit an electronic copy of the paper (written in English) in
PDF. Each submission must include on its first page the paper title; authors
and their affiliations; abstract; and three to four keywords. The keywords will
be used to assist us in selecting appropriate reviewers for the paper. Papers
should consist of no more than 12 pages, formatted following the ACM SIG
proceedings template (option 1). The 12 page limit must include references but
excludes well-marked appendices not intended for publication. Referees are not
required to read the appendices, and thus papers should be intelligible without
them.

Program Committee

Sergio Antoy Portland State University, USA
Manuel Carro IMDEA Software Institute, Spain
Iliano Cervesato Carnegie Mellon University, Qatar
Agostino Dovier Universita degli Studi di Udine, Italy
Maria Garcia de la Banda Monash University, Australia
Ralf Hinze University of Oxford, UK
Yukiyoshi Kameyama University of Tsukuba, Japan
Oleg Kiselyov USA
Yanhong Annie Liu State University of New York at Stony Brook, USA
Stefan Monnier Universite de Montreal, Canada
Alan Mycroft University of Cambrige, UK
Bruno C. d. S. Oliveira National University of Singapore, Singapore
Alberto Pettorossi Universita di Roma Tor Vergata, Italy
Enrico Pontelli New Mexico State University, USA
Kristoffer Rose IBM Research, USA
Sukyoung Ryu KAIST, South Korea
Vitor Santos Costa University of Porto, Portugal
Torsten Schaub University Potsdam, Germany
Tom Schrijvers Ghent University, Belgium
Martin Sulzmann Hochschule Karlsruhe, Germany
Wouter Swierstra Universiteit Utrecht, The Netherlands
Tarmo Uustalu Institute of Cybernetics, Estonia
Janis Voigtlaender University of Bonn, Germany
Meng Wang Chalmers University of Technology, Sweden
Jan Wielemaker Universiteit van Amsterdam, The Netherlands

Program Chair

Tom Schrijvers
Department of Applied Mathematics and Computer Science
Ghent University
9000 Gent, Belgium

General Chair

Ricardo Pena
Facultad de Informatica
Universidad Complutense de Madrid
28040 Madrid, Spain

Simon Michael: GHCI fix

Thu, 06 Jun 2013 06:00:00 +0000

June 6, 2013

GHCI fix

Yesterday.

Today:

Next item on the 0.22 backlog: fix make ghci and make ghciweb.

The goal of these make rules is to bring up a GHCI prompt with as much as possible of the guts of hledger (or hledger-web) loaded, in scope, and visible. This can be really valuable for debugging, sanity-checking, and exploratory development, but it’s quite hard to set up by hand, as the necessary flags tend to proliferate. Hence these rules.

The latest breakage was due to my using cabal’s MIN_version_* macros (to make Hledger.Cli.Utils compatible with both the versions of directory currently found on user machines). It’s hard to ensure these macros are available in all circumstances (sp/ghc builds, haddock, ghci..) So I’ve made it work with or without them, with this not-very-pretty kludge:

#ifdef MIN_VERSION_directory
#if MIN_VERSION_directory(1,2,0)
        utc <- getModificationTime f
        let nom = utcTimeToPOSIXSeconds utc
        let clo = TOD (read $ takeWhile (`elem` "0123456789") $ show nom) 0 -- XXX read
#else
        clo <- getModificationTime f
#endif
#else
-- cabal macros aren't available, assume the new directory
        utc <- getModificationTime f
        let nom = utcTimeToPOSIXSeconds utc
        let clo = TOD (read $ takeWhile (`elem` "0123456789") $ show nom) 0 -- XXX read
#endif

And now I’ve got ghci prompts again. It looks like they could do some more importing though:

~/src/hledger$ make ghciweb
ghci -rtsopts -W -fwarn-tabs -fno-warn-unused-do-bind -fno-warn-name-shadowing  -ihledger-lib -ihledger -ihledger-web -ihledger-web/app -L/usr/lib  -optP-include -optPhledger/dist/build/autogen/cabal_macros.h -DPATCHLEVEL=0 -DDEVELOPMENT -DVERSION='"0.21.2dev"' -XCPP -XMultiParamTypeClasses -XOverloadedStrings -XQuasiQuotes -XRecordWildCards -XTemplateHaskell  hledger-web/app/main.hs
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[ 1 of 52] Compiling Settings.Development ( hledger-web/Settings/Development.hs, interpreted ) [flags changed]
[ 2 of 52] Compiling Settings         ( hledger-web/Settings.hs, interpreted ) [flags changed]
Loading package array-0.4.0.1 ... linking ... done.
...
[52 of 52] Compiling Main             ( hledger-web/app/main.hs, interpreted )
Ok, modules loaded: Hledger, Hledger.Data, Hledger.Data.Account, Hledger.Data.AccountName, Hledger.Data.Amount, Hledger.Data.Commodity, Hledger.Data.Dates, Hledger.Data.FormatStrings, Hledger.Data.Journal, Hledger.Data.Ledger, Hledger.Data.Posting, Hledger.Data.TimeLog, Hledger.Data.Transaction, Hledger.Data.Types, Hledger.Query, Hledger.Read, Hledger.Read.CsvReader, Hledger.Read.JournalReader, Hledger.Read.TimelogReader, Hledger.Reports, Hledger.Utils, Hledger.Utils.UTF8IOCompat, Hledger.Cli, Hledger.Cli.Options, Hledger.Cli.Utils, Hledger.Cli.Version, Hledger.Cli.Add, Hledger.Cli.Balance, Hledger.Cli.Balancesheet, Hledger.Cli.Cashflow, Hledger.Cli.Histogram, Hledger.Cli.Incomestatement, Hledger.Cli.Print, Hledger.Cli.Register, Hledger.Cli.Stats, Application, Foundation, Import, Settings, Settings.StaticFiles, Settings.Development, Handler.Common, Handler.JournalEditR, Handler.JournalEntriesR, Handler.JournalR, Handler.Post, Handler.RegisterR, Handler.RootR, Handler.Utils, Hledger.Web.Main, Hledger.Web.Options, Main.
>>> :t defbaseurl

<interactive>:1:1: Not in scope: `defbaseurl'
>>> import Settings
>>> :t defbaseurl
defbaseurl :: GHC.Types.Int -> GHC.Base.String
>>>

Paul Potts: Objective-C, Day 3

noreply@blogger.com (Paul Potts) — Wed, 05 Jun 2013 05:05:00 +0000

(Warning: non-FP content)

So, this is day 5 in my Undisclosed Location and I haven't gotten much done -- I'm still engaged in a job search, and spent about eight hours working on a "take-home test" for an employer (with a few interruptions), and I'm pursuing more leads, and I'm trying to socialize with my hosts occasionally, so there are some distractions. But I've got enough information to go on to start implementing something original.

What I want to implement is a small game. I'll get as far as I can in the back-end code today (the Model and Controller parts of the MVC "trinity") and we'll see just how productive I really am in Objective-C. I read most of Objective-C Programming by Aaron Hillegass last night -- it's a very quick read for someone well-versed in C, and it reiterates parts of the iOS Programming book. I haven't covered protocols, categories, blocks, or run loops, but I think I can get by without those things for now.

Many years ago there existed on old-school MacOS a small game called "Polar." It was a very simple game, written by a guy (Go Endo) who was probably a student at the time, but I was fond of it -- fond enough to save it for 23 years, with the intention of studying its design and re-implementing it in the future. (In fact, I've saved a lot of old bits and bobs like this). I made notes of how to beat the first 3 levels (it was one of those "incredibly simple game play, but maddeningly tricky" games), drew out the levels, made notes on how the objects behaved, etc. I haven't been able to run that game for a long time, but today I just got it working under SheepShaver. Here's what level 1 looks like (blown up a bit):

The penguin is your avatar. The rest of the objects are ice blocks, trees, hearts, bombs, mountains, and houses. The world is a sheet of ice. You can walk around on the ice. You can walk through trees. Some objects (trees, mountains, and houses) can't be moved. Bombs, hearts, and ice blocks move without friction -- if you push them, they will keep going until they hit the edge of the world or another object. If an sliding ice block hits another object, it stops. If you push it against another object, it crumbles and disappears. The penguin can walk through trees, but other objects can't. Bombs will blow up mountains when they slide into them. Everything else simply stops them. The goal of the game is to slide all the hearts into a house (cute, huh?) But because the ice is frictionless, it's incredibly easy to get objects stuck against walls or corners where you can no longer move them the way you need to. So you have to carefully plan out your moves, and if you get stuck, there's an option to start the level over.

I should mention that the original game had a copyright notice (1990), and was shareware ($2.00). I can't remember if I ever sent the author $2.00. I'm not sure how he would feel about me taking apart and trying to re-implement his game, or whether he'd try to assert that copyright prevented me from doing so, but I'll assume he's a nice guy and wouldn't care as long as I don't charge for it, and go ahead, on the theory that easier to ask forgiveness than permission. I was not able to find him online -- maybe "Go Endo" was a pseudonym?

Back in 1991 I came up with a C++ class design (actually, it doesn't quite look like C++; I think it was written using THINK C's object-oriented extensions, which are sort of lost in the mists of time to me -- what is that indirect keyword? What did #pragma options(virtual) do? I don't remember for sure, but let's see if we can come up with an Objective-C implementation. The objects, other than the penguin, which can face in different directions, don't seem to have any real distinct properties except for their locations in the board, so I'm tempted not to take the obvious route and implement a board full of instances of the objects. I'm more inclined to just define a class for the board, and let it encapsulate most of the game logic. For the objects themselves, I'd like to just make references (pointers) to their classes (the class object) rather than putting them in a container. That's apparently not really possible -- there are no predefined singletons for the class objects that are accessible at run-time the way there are for NSNull. So I have to make some (sort of) singletons.

Here's what I've got today:

@interface ArcticSlideTile : NSObject
// Not necessarily useful yet, but I am guessing it might
// be helpful to have a separate base class at some point.
@end

@interface ArcticSlideTileStateless : ArcticSlideTile
// In implementation, there will be a single shared instance.
@end

@interface ArcticSlideBomb : ArcticSlideTileStateless
// Bombs can be pushed and will slide until they
// hit an object and stop. If the object is a mountain,
// both bomb and mountain are destroyed and
// there should be an animation. If another object
// hits a bomb it stops (I'm not sure you can test this
// combination in the original game with the board layouts
// available
- (NSString*) description;
@end

@interface ArcticSlideEmpty : ArcticSlideTileStateless
// The penguin can walk on empty space. Pushable objects
// on empty space are on ice and they slide until something
// stops them.
- (NSString*) description;
@end

@interface ArcticSlideHeart : ArcticSlideTileStateless
// When a heart hits a house the heart disappears (getting
// all the hearts into the house is how you win the game).
// Otherwise they cannot be destroyed, and slide like other
// slidable items.
- (NSString*) description;
@end

@interface ArcticSlideHouse : ArcticSlideTileStateless
// Houses cannot be pushed and stop other objects
// except hearts. When a heart hits a house the heart
// disappears (getting the hearts into the house is
// how you win the game). So the model should keep track
// of the number of hearts on the board and trigger a
// "win the level" behavior when the last heart is 
// destroyed.
- (NSString*) description;
@end

@interface ArcticSlideIceBlock : ArcticSlideTileStateless
// Ice blocks can be pushed and will slide until they
// hit an object and stop. If they are pushed directly
// against an object they will be crushed (there should
// be an animation) and disappear.
- (NSString*) description;
@end

@interface ArcticSlideMountain : ArcticSlideTileStateless
// Mountains cannot be moved and are destroyed by bombs.
- (NSString*) description;
@end

@interface ArcticSlidePenguin : ArcticSlideTile
// The penguin is the avatar. It has the special
// quality of being able to face different directions
// in the original game, although that's because you 
// can click near him to turn him and make him walk in
// different directions. In a touchscreen implementation
// I'm not sure how this should be implemented -- maybe
// he can slide in discreet steps. The penguin has the
// ability to walk through trees. We might want to 
// implement this temporary state using using an
// "override" object reference in the model. Sliding
// objects might be implemented the same way.
typedef enum {
    north, south, east, west
}penguinDirection_e;

@property penguinDirection_e facing;
- (NSString*) description;
@end

@interface ArcticSlideTree : ArcticSlideTile
// Trees cannot be pushed or destroyed and stop
// all sliding objects, but the penguin avatar 
// character can walk through them.
- (NSString*) description;
@end

static const int board_width = 24, board_height = 4;
// The short board design is part of what makes it
// so easy to get sliding objects stuck against the
// edges of the world or in corners where you can no longer
// get around to the other side to push them. We could
// consider a bigger board later and maybe implement the
// original puzzles surrounded by impassible water.

@interface ArcticSlideModel : NSObject
{
    ArcticSlideTile* board[board_height][board_width];
}

- (id)init;
- (NSString*) description;

@end

@implementation ArcticSlideTile
{
}
@end

@implementation ArcticSlideTileStateless
{
}
@end

@implementation ArcticSlideBomb
- (NSString*) description
{
    return @"Bomb";
}
@end

@implementation ArcticSlideEmpty
- (NSString*) description
{
    return @"Empty";
}
@end

@implementation ArcticSlideHouse
- (NSString*) description
{
    return @"House";
}
@end

@implementation ArcticSlideIceBlock
- (NSString*) description
{
    return @"Ice Block";
}
@end

@implementation ArcticSlideMountain
- (NSString*) description
{
    return @"Mountain";
}
@end

@implementation ArcticSlidePenguin
- (NSString*) description
{
    return @"Mountain";
}
@end

@implementation ArcticSlideTree
- (NSString*) description
{
    return @"Tree";
}
@end

@implementation ArcticSlideModel
{
    ArcticSlideBomb *bomb;
    ArcticSlideEmpty *empty;
    ArcticSlideHeart *heart;
    ArcticSlideHouse *house;
    ArcticSlideIceBlock *ice_block;
    ArcticSlideMountain *mountain;
    ArcticSlidePenguin *penguin;
    ArcticSlideTree* tree;

}
- (id)init
{
    bomb = [[ArcticSlideBomb alloc] init];
    empty = [[ArcticSlideEmpty alloc] init];
    heart = [[ArcticSlideHeart alloc] init];
    house = [[ArcticSlideHouse alloc] init];
    ice_block = [[ArcticSlideIceBlock alloc] init];
    mountain = [[ArcticSlideMountain alloc] init];
    penguin = [[ArcticSlidePenguin alloc] init];
    tree = [[ArcticSlideTree alloc] init];

    for ( unsigned int idx_y = 0;
         idx_y < board_height; idx_y++ )
    {
        for ( unsigned int idx_x = 0;
             idx_x < board_width; idx_x++ )
        {
            board[idx_y][idx_x] = empty;
        }
    }
    return self;
}

- (NSString*)description
{
    NSMutableString *desc_str =
        [[NSMutableString alloc]init];
    
    [desc_str appendString:@"ArcticSlideModel board state:\n"];
    for ( unsigned int idx_y = 0;
         idx_y < board_height; idx_y++ )
    {
        for ( unsigned int idx_x = 0;
             idx_x < board_width; idx_x++ )
        {
            [desc_str
             appendString:[board[idx_y][idx_x] description]];
            [desc_str appendString:@" "];
        }
        [desc_str appendString:@"\n"];
    }
    return desc_str;
}

@end

My quiet time at my undisclosed location ends tomorrow. I'm not sure I'll be able to get back to this for a few days. I haven't gotten nearly as much done with this as I've hoped. I've been distracted by a lot of job-search things. But hey, it's a start!

Tim Docker: Data analysis with Monoids

Tue, 04 Jun 2013 22:05:36 +0000

This post expresses the key ideas of a talk I gave at FP-SYD this week.

Monoids are a pretty simple concept in haskell. Some years ago I learnt of them through the excellent Typeclassopedia, looked at the examples, and understood them quickly (which is more than can be said for many of the new ideas that one learns in haskell). However that was it. Having learnt the idea, I realised that monoids are everywhere in programming, but I’d not found much use for the Monoid typeclass abstraction itself. Recently, I’ve found they can be a useful tool for data analysis…

Monoids

First a quick recap. A monoid is a type with a binary operation, and an identity element:

class Monoid a where
  mempty :: a
  mappend :: a -> a -> a

It must satisfy a simple set of laws, specifically that the binary operation much be associative, and the identity element must actually be the identity for the given operation:

mappend a (mappend b c) = mappend (mappend a b) c
mappend mempty x = x
mappend x mempty = x

As is hinted by the names of the typeclass functions, lists are an obvious Monoid instance:

instance Monoid [a] where
  mempty  = []
  mappend = (++)

However, many types can be Monoids. In fact, often a type can be a monoid in multiple ways. Numbers are monoids under both addition and multiplication, with 0 and 1 as their respective identity elements. In the haskell standard libraries, rather than choose one kind of monoid for numbers, newtype declarations are used to given instances for both:

newtype Sum a = Sum { getSum :: a }
  deriving (Eq, Ord, Read, Show, Bounded)

instance Num a => Monoid (Sum a) where
  mempty = Sum 0
  Sum x `mappend` Sum y = Sum (x + y)

newtype Product a = Product { getProduct :: a }
  deriving (Eq, Ord, Read, Show, Bounded)

instance Num a => Monoid (Product a) where
  mempty = Product 1
  Product x `mappend` Product y = Product (x * y)

We’ve now established and codified the common structure for a few monoids, but it’s not yet clear what it has gained us. The Sum and Product instances are unwieldly – you are unlikely to want to use Sum directly to add two numbers:

Prelude> :m Data.Monoid
Prelude Data.Monoid> 5+4
9
Prelude Data.Monoid> getSum (mappend (Sum 5) (Sum 4))
9

Before we progress, however, let’s define a few more monoid instances, potentially useful for data analysis.

data Min a = Min a | MinEmpty deriving (Show)
           
data Max a = Max a | MaxEmpty deriving (Show)

newtype Count = Count Int deriving (Show)

instance (Ord a) => Monoid (Min a) where
  mempty = MinEmpty
  mappend MinEmpty m = m
  mappend m MinEmpty = m
  mappend (Min a) (Min b) = (Min (P.min a b))

instance (Ord a) => Monoid (Max a) where
  mempty = MaxEmpty
  mappend MaxEmpty m = m
  mappend m MaxEmpty = m
  mappend (Max a) (Max b) = (Max (P.max a b))

instance Monoid Count where
  mempty = Count 0
  mappend (Count n1) (Count n2) = Count (n1+n2)

Also some helper functions to construct values of all these monoid types:

sum :: (Num a) => a -> Sum a
sum = Sum

product :: (Num a) => a -> Product a
product = Product

min :: (Ord a) => a -> Min a
min = Min

max :: (Ord a) => a -> Max a
max = Max

count :: a -> Count
count _ = Count 1

These functions are trivial, but they put a consistent interface on creating monoid values. They all have a signature (a -> m) where m is some monoid. For lack of a better name, I’ll call functions with such signatures "monoid functions".

Foldable

It’s time to introduce another typeclass, Foldable. This class abstracts the classic foldr and foldl functions away from lists, making them applicable to arbitrary structures. (There’s a robust debate going on right now about the merits of replacing the list specific fold functions in the standard prelude with the more general versions from Foldable.) Foldable is a large typeclass – here’s the key function of interest to us:

class Foldable t where
  ...
  foldMap :: Monoid m => (a -> m) -> t a -> m
  ...

foldMap takes a monoid function and a Foldable structure, and reduces the structure down to a single value of the monoid. Lists are, of course, instances of foldable, so we can demo our helper functions:

*Examples> let as = [45,23,78,10,11,1]
*Examples> foldMap count as
Count 6
*Examples> foldMap sum as
Sum {getSum = 168}
*Examples> foldMap max as
Max 78

Notice how the results are all still wrapped with the newtype constructors. We’ll deal with this later.

Composition

As it turns out, tuples are already instances of Monoids:

instance (Monoid a,Monoid b) => Monoid (a,b) where
  mempty = (mempty,mempty)
  mappend (a1,b1) (a2,b2) = (mappend a1 a2,mappend b1 b2)

A pair is a monoid if it’s elements are monoids. There are similar instances for longer tuples. We need some helper monoid functions for tuples also:

a2 :: (a -> b) -> (a -> c) -> a -> (b,c)
a2 b c = (,) <$> b <*> c

a3 :: (a -> b) -> (a -> c) -> (a -> d) -> a -> (b,c,d)
a3 b c d = (,,) <$> b <*> c <*> d

These are implemented above using Applicative operators, though I’ve given them more restrictive types to make their intended use here clearer. Now I can compose monoid functions:

*Examples> let as = [45,23,78,10,11,1]
*Examples> :t (a2 min max)
(a2 min max) :: Ord a => a -> (Min a, Max a)
*Examples> foldMap (a2 min max) as
(Min 1,Max 78)
*Examples> :t (a3 count (a2 min max) (a2 sum product))
(a3 count (a2 min max) (a2 sum product))
  :: (Num a, Ord a) =>
     a -> (Count, (Min a, Max a), (Sum a, Product a))
*Examples> foldMap (a3 count (a2 min max) (a2 sum product)) as
(Count 6,(Min 1,Max 78),(Sum {getSum = 168},Product {getProduct = 8880300}))

It’s worth noting here that the composite computations are done in a single traversal of the input list.

More complex calculations

Happy with this, I decide to extend my set of basic computations with the arithmetic mean. There is a problem, however. The arithmetic mean doesn’t "fit" as a monoid – there’s no binary operation such that a mean for a combined set of data can be calculated from the mean of two subsets.

What to do? Well, the mean is the sum divided by the count, both of which are monoids:

newtype Mean a = Mean (Sum a,Count) deriving (Show)

instance (Num a) => Monoid (Mean a) where
  mempty = Mean mempty
  mappend (Mean m1) (Mean m2) = Mean (mappend m1 m2)

mean v = Mean (Sum v,Count 1)

So I can calculate the mean if I am prepared to do a calculation after the foldMap:

*Examples> let as = [45,23,78,10,11,1.5]
*Examples> foldMap mean as
Mean (Sum {getSum = 168.5},Count 6)
*Examples> let (Mean (Sum t,Count n)) = foldMap mean as in t / fromIntegral n
28.083333333333332

The Aggregation type class

For calculations like mean, I need something more than a monoid. I need a monoid for accumulating the values, and then, once the accumulation is complete, a postprocessing function to compute the final result. Hence a new typeclass to extend Monoid:

{-# LANGUAGE TypeFamilies #-}

class (Monoid a) => Aggregation a where
  type AggResult a :: *
  aggResult :: a -> AggResult a

This makes use of the type families ghc extension. We need this to express the fact that our postprocessing function aggResult has a different return type to the type of the monoid. In the above definition:

aggResult is a function that gives you the value of the final result from the value of the monoid
AggResult is a type function that gives you the type of the final result from the type of the monoid

We can write an instance of Aggregation for Mean:

instance (Fractional a) => Aggregation (Mean a) where
  type AggResult (Mean a) = a
  aggResult (Mean (Sum t,Count n)) = t/fromIntegral n

and test it out:

*Examples> let as = [45,23,78,10,11,1.5]
*Examples> aggResult (foldMap mean as)
28.083333333333332
*Examples>

Nice. Given that aggResult (foldMap ...) will be a common pattern, lets write a helper:

afoldMap :: (Foldable t, Aggregation a) => (v -> a) -> t v -> AggResult a
afoldMap f vs = aggResult (foldMap f vs)

In order to use the monoids we defined before (sum,product etc) we need to define Aggregation instances for them also. Even though they are trivial, it turns out to be useful, as we can make the aggResult function strip off the newtype constructors that were put there to enable the Monoid typeclass:

instance (Num a) => Aggregation (Sum a)  where
  type AggResult (Sum a) = a
  aggResult (Sum a) = a
    
instance (Num a) => Aggregation (Product a)  where
  type AggResult (Product a) = a
  aggResult (Product a) = a

instance (Ord a) => Aggregation (Min a)  where
  type AggResult (Min a) = a
  aggResult (Min a) = a

instance (Ord a) => Aggregation (Max a)  where
  type AggResult (Max a) = a
  aggResult (Max a) = a

instance Aggregation Count where
  type AggResult Count = Int
  aggResult (Count n) = n

instance (Aggregation a, Aggregation b) => Aggregation (a,b) where
  type AggResult (a,b) = (AggResult a, AggResult b)
  aggResult (a,b) = (aggResult a, aggResult b)

instance (Aggregation a, Aggregation b, Aggregation c) => Aggregation (a,b,c) where
  type AggResult (a,b,c) = (AggResult a, AggResult b, AggResult c)
  aggResult (a,b,c) = (aggResult a, aggResult b, aggResult c)

This is mostly boilerplate, though notice how the tuple instances delve into their components in order to postprocess the results. Now everything fits together cleanly:

*Examples> let as = [45,23,78,10,11,1.5]
*Examples> :t (a3 count (a2 min max) mean)
(a3 count (a2 min max) mean)
  :: Ord a => a -> (Count, (Min a, Max a), Mean a)
*Examples> afoldMap (a3 count (a2 min max) mean) as
(6,(1.5,78.0),28.083333333333332)
*Examples>

The 4 computations have been calculated all in a single pass over the input list, and the results are free of the type constructors that are no longer required once the aggregation is complete.

Another example of an Aggregation where we need to postprocess the result is counting the number of unique items. For this we will keep a set of the items seen, and then return the size of this set at the end:

newtype CountUnique a = CountUnique (Set.Set a)

instance Ord a => Monoid (CountUnique a) where
  mempty = CountUnique Set.empty
  mappend (CountUnique s1) (CountUnique s2) = CountUnique (Set.union s1 s2)

instance Ord a => Aggregation (CountUnique a) where
  type AggResult (CountUnique a) = Int
  aggResult (CountUnique s1) = Set.size s1

countUnique :: Ord a => a -> CountUnique a
countUnique a = CountUnique (Set.singleton a)

.. in use:

*Examples> let as = [5,7,8,7,11,10,11]
*Examples> afoldMap (a2 countUnique count) as
(5,7)

Higher order aggregation functions

All of the calculations seen so far have worked consistently across all values in the source data structure. We can make use of the mempty monoid value in order to filter our data set, and or aggregate in groups. Here’s a couple of higher order monoid functions for this:

afilter :: Aggregation m => (a -> Bool) -> (a -> m) -> (a -> m)
afilter match mf = \a -> if match a then mf a else mempty

newtype MMap k v = MMap (Map.Map k v)
  deriving Show

instance (Ord k, Monoid v) => Monoid (MMap k v) where
  mempty = MMap (Map.empty)
  mappend (MMap m1) (MMap m2) = MMap (Map.unionWith mappend m1 m2)

instance (Ord k, Aggregation v) => Aggregation (MMap k v) where
  type AggResult (MMap k v) = Map.Map k (AggResult v)
  aggResult (MMap m) = Map.map aggResult m

groupBy :: (Ord k, Aggregation m) => (a -> k) -> (a -> m) -> (a -> MMap k m)
groupBy keyf valuef = \a -> MMap (Map.singleton (keyf a) (valuef a))

afilter restricts the application of a monoid function to a subset of the input data. eg to calculate the sum of all the values, and the sum of values less than 20:

*Examples> let as = [5,10,20,45.4,35,1,3.4]
*Examples> afoldMap (a2 sum (afilter (<=20) sum)) as
(119.8,39.4)

groupBy takes a key function and a monoid function. It partitions the data set using the key function, and applies a monoid function to each subset, returning all of the results in a map. Non-numeric data works better as an example here. Let’s take a set of words as input, and for each starting letter, calculate the number of words with that letter, the length of the shortest word, and and the length of longest word:

*Examples> let as = words "monoids are a pretty simple concept in haskell some years ago i learnt of them through the excellent typeclassopedia looked at the examples and understood them straight away which is more than can be said for many of the new ideas that one learns in haskell"
*Examples> :t groupBy head (a3 count (min.length) (max.length))
groupBy head (a3 count (min.length) (max.length))
  :: Ord k => [k] -> MMap k (Count, Min Int, Max Int)
*Examples> afoldMap (groupBy head (a3 count (min.length) (max.length))) as
fromList [('a',(6,1,4)),('b',(1,2,2)),('c',(2,3,7)),('e',(2,8,9)),('f',(1,3,3)),('h',(2,7,7)),('i',(5,1,5)),('l',(3,6,6)),('m',(3,4,7)),('n',(1,3,3)),('o',(3,2,3)),('p',(1,6,6)),('s',(4,4,8)),('t',(9,3,15)),('u',(1,10,10)),('w',(1,5,5)),('y',(1,5,5))]

Many useful data analysis functions can be written through simple function application and composition using these primitive monoid functions, the product combinators a2 and a3 and these new filtering and grouping combinators.

Disk-based data

As pointed out before, regardless of the complexity of the computation, it’s done with a single traversal of the input data. This means that we don’t need to limit ourselves to lists and other in memory Foldable data structures. Here’s a function similar to foldMap, but that works over the lines in a file:

foldFile :: Monoid m => FilePath -> (BS.ByteString -> Maybe a) -> (a -> m) -> IO m
foldFile fpath pf mf = do
  h <- openFile fpath ReadMode
  m <- loop h mempty
  return m
  where
    loop h m = do
      eof <- hIsEOF h
      if eof
        then (return m)
        else do
          l <- BS.hGetLine h
          case pf l of
            Nothing -> loop h m
            (Just a) -> let m' = mappend m (mf a)
                        in loop h m'

afoldFile :: Aggregation m => FilePath -> (BS.ByteString -> Maybe a) -> (a -> m) -> IO (AggResult m)
afoldFile fpath pf mf = fmap aggResult (foldFile fpath pf mf)

foldFile take two parameters – a function to parse each line of the file, the other is the monoid function to do the aggregation. Lines that fail to parse are skipped. (I can here questions in the background "What about strictness and space leaks?? – I’ll come back to that). As an example usage of aFoldFile, I’ll analyse some stock data. Assume that I have it in a CSV file, and I’ve got a function to parse one CSV line into a sensible data value:

import qualified Data.ByteString.Char8 as BS
import Data.Time.Calendar

data Prices = Prices {
  pName :: String,          -- The stock code
  pDate :: Day,             -- The historic date
  pOpen :: Double,          -- The price at market open
  pHigh :: Double,          -- The highest price on the date
  pLow :: Double,           -- The lowest price on the date
  pClose :: Double,         -- The price at market close
  pVolume :: Double         -- How many shares were traded
  } deriving (Show)

  parsePrices :: BS.ByteString -> Maybe Prices
  parsePrices = ...

Now I can use my monoid functions to analyse the file based data. How many google prices do I have, over what date range:

*Examples> let stats =  afilter (("GOOG"==).pName) (a3 count (min.pDate) (max.pDate))
*Examples> :t stats
stats
  :: Prices
     -> (Count,
         Min time-1.4:Data.Time.Calendar.Days.Day,
         Max time-1.4:Data.Time.Calendar.Days.Day)
*Examples> afoldFile "prices.csv" parsePrices stats
(1257,2008-05-29,2013-05-24)
*Examples>

Perhaps I want to aggregate my data per month, getting traded price range and total volume. We need a helper function to work out the month of each date:

startOfMonth :: Day -> Day
startOfMonth t = let (y,m,d) = toGregorian t
                 in fromGregorian y m 1

And then we can use groupBy to collect data monthly:

:*Examples> let stats =  afilter (("GOOG"==).pName) (groupBy (startOfMonth.pDate) (a3 (min.pLow) (max.pHigh) (sum.pVolume)))
*Examples> :t stats
stats
  :: Prices
     -> MMap
          time-1.4:Data.Time.Calendar.Days.Day
          (Min Double, Max Double, Sum Double)
*Examples> results <- afoldFile "prices.csv" parsePrices stats
*Examples> mapM_ print (Map.toList results)
(2008-05-01,(573.2,589.92,8073107.0))
(2008-06-01,(515.09,588.04,9.3842716e7))
(2008-07-01,(465.6,555.68,1.04137619e8))
...
(2013-03-01,(793.3,844.0,4.2559856e7))
(2013-04-01,(761.26,827.64,5.3574633e7))
(2013-05-01,(816.36,920.6,4.1080028e7))

Conclusion

So, I hope I’ve shown that monoids are useful indeed. They can form the core of a framework for cleanly specifing quite complex data analysis tasks.

An additional typeclass which I called "Aggregation" extends Monoid and provides for a broader range of computations and also cleaner result types (thanks to type families). There was some discussion when I presented this talk as to whether a single method typeclass like Aggregation was a "true" abstraction, given it has no associated laws. This is a valid point, however using it simplifies the syntax and usage of monoidal calculations significantly, and for me, this makes it worth having.

There remains an elephant in the room, however, and this is space leakage. Lazy evalulation means that, as written, most of the calculations shown run in space proportional to the input data set. Appropriate strictness annotations and related modifications will fix this, but it turns out to be slightly irritating. This blog post is already long enough, so I’ll address space leaks in in a subsequent post…

Simon Michael: Bugfix, planning, autoweb

Tue, 04 Jun 2013 19:00:00 +0000

June 4, 2013

Bugfix, planning, autoweb

Yesterday.

Today:

Fixed a build failure from last night’s late session, caught by Peter’s build bot, which is being very helpful. It’s like having R2D2 at my back! I do worry a little about the gratuitous added carbon footprint from a bunch of builds on every github commit.

Loaded up the 0.22 release backlog with a bunch of items on the planning board. (Scroll over to the right).

Did the first backlog item, removing some troublesome friction in hledger-web development. When I’m working on hledger[-web] and need rapid compiler feedback, I use the “auto” rules - make auto, make auto-test, or make autoweb. These watch for file changes and recompile as needed, using searchpath. Searchpath is old, but still works well and can build from multiple packages, unlike cabal-based autobuilders. So it’s very useful when I’m tweaking things in hledger-lib for hledger-web. (I’d use yesod devel if I was just working just in hledger-web, and changing routes, templates, or the cabal file).

The problem: when compiling hledger-web, hledger and hledger-lib together, how to enable the hairy yesodish language extensions only for hledger-web code, and not for hledger-lib and hledger, which don’t compile with them (and seem to get obfuscated if I make them compile).

The solution: wrestle with ghc, sp, cabal; identify required and incompatible language extensions by trial and error; specify the compatible ones in the makefile, and add the rest as source file pragmas. Now my trusty autoweb runs again!

~/src/hledger$ make autoweb
sp --no-exts --no-default-map ghc  -O0  hledger-web/app/main.hs -o bin/hledger-webdev -rtsopts -W -fwarn-tabs -fno-warn-unused-do-bind -fno-warn-name-shadowing  -ihledger-lib -ihledger -ihledger-web -ihledger-web/app -L/usr/lib  -optP-include -optPhledger/dist/build/autogen/cabal_macros.h -DPATCHLEVEL=2 -DDEVELOPMENT -DVERSION='\"0.21.1dev\"'  -XCPP -XMultiParamTypeClasses -XOverloadedStrings -XQuasiQuotes -XRecordWildCards -XTemplateHaskell  --run -B --port 5001 --base-url http://localhost:5001 -f webtest.j
[ 1 of 52] Compiling Hledger.Data.Types ( hledger-lib/Hledger/Data/Types.hs, hledger-lib/Hledger/Data/Types.o )
[ 2 of 52] Compiling Hledger.Data.FormatStrings ( hledger-lib/Hledger/Data/FormatStrings.hs, hledger-lib/Hledger/Data/FormatStrings.o )
...
Loading package yesod-static-1.2.0 ... linking ... done.
[40 of 52] Compiling Foundation       ( hledger-web/Foundation.hs, hledger-web/Foundation.o )

hledger-web/Foundation.hs:106:37: Not in scope: `css_bootstrap_css'

Hmm. That didn’t happen on the other machine. Never mind, something for tomorrow.

Finally, realised I need to do yet another release including this morning’s build fix. This time I waited to see green lights on the buildbot before uploading.

JP Moresmau: Eclipse Hate and Haskell IDEs

noreply@blogger.com (JP Moresmau) — Tue, 04 Jun 2013 18:14:33 +0000

A few weeks ago I was reading the comments about the release of Android Studio on reddit. I was a bit shocked by all the Eclipse hate. But hey, I suppose I use Eclipse and not IntelliJ, so I don't know what I'm missing and how great it would be to work on IDEA. But then I was surprised to see that there has been no release of ideah, the Haskell plug-in for IDEA, for a year and a half. How come there isn't more momentum if IntelliJ is such a great IDE to build on and work with?

Maybe we're just suffering from too much dispersion in the Haskell IDE space. We have plug-ins for the major IDEs, but none of them can probably called great (I know, some people positively hate EclipseFP, but for my defence I'll say I get much more bug reports and feature requests than pull requests, I probably need a course on "building a passionate programming community around your open source project"). They however have the massive advantage of being able to reuse a wealth of existing code (I can use the Eclipse Git plugin to work with Github, I don't need somebody to write the Haskell version). An IDE in Haskell like Leksah or something built on top of Yi would be amazing to showcase that you can do real applications in Haskell (since you still get people saying that Haskell is only for toying with), but then you need to build everything, which requires people (see note above on building a community). Then we have web based editors like the offering from FPComplete, but for developers to use them on real projects we need to think on how to package a web based interface and what it means for a development work-flow: I'm not sure developers would embrace developing using a browser. Of course we have plug-ins for the Unixy editors, emacs and vim, but if we want to open up Haskell to non hackers, maybe we need something more...

So can we continue like that and hope to have a few decent environments? Or shall we all agree on a direction and unite to provide the one true development environment for Haskell? Sometimes people say "Haskell is so different and advanced as a programming language, it needs a new type of editor/IDE". I don't disagree with it, but who has the vision of what the Haskell IDE should be?

Simon Michael: Chart fix

Tue, 04 Jun 2013 05:30:00 +0000

June 4, 2013

Chart fix

Yesterday.

Here’s the developer diary entry for monday.

Peter Simons argued convincingly against depending on yesod-platform.

I released hledger 0.21.1, fixing a regression in hledger-web 0.21 where it showed the wrong chart Y-values when filtering by date. The chart appears at the top of the register view, and simply shows the register’s running total in graphical form. Here’s the report type which provides values for the chart:

-- | A transactions report includes a list of transactions
-- (posting-filtered and unfiltered variants), a running balance, and some
-- other information helpful for rendering a register view (a flag
-- indicating multiple other accounts and a display string describing
-- them) with or without a notion of current account(s).
type TransactionsReport = (String                   -- label for the balance column, eg "balance" or "total"
                          ,[TransactionsReportItem] -- line items, one per transaction
                          )
type TransactionsReportItem = (Transaction -- the corresponding transaction
                              ,Transaction -- the transaction with postings to the current account(s) removed
                              ,Bool        -- is this a split, ie more than one other account posting
                              ,String      -- a display string describing the other account(s), if any
                              ,MixedAmount -- the amount posted to the current account(s) (or total amount posted)
                              ,MixedAmount -- the running balance for the current account(s) after this transaction
                              )

triDate (t,_,_,_,_,_) = tdate t
triAmount (_,_,_,_,a,_) = a
triBalance (_,_,_,_,_,a) = a
triSimpleBalance (_,_,_,_,_,Mixed a) = case a of [] -> "0"
                                                 (Amount{aquantity=q}):_ -> show q

and here’s the slightly tricky new code to split it into separate reports, each covering one commodity:

-- Split a transactions report whose items may involve several commodities,
-- into one or more single-commodity transactions reports.
transactionsReportByCommodity :: TransactionsReport -> [TransactionsReport]
transactionsReportByCommodity tr =
  [filterTransactionsReportByCommodity c tr | c <- transactionsReportCommodities tr]
  where
    transactionsReportCommodities (_,items) =
      nub $ sort $ map acommodity $ concatMap (amounts . triAmount) items

-- Remove transaction report items and item amount (and running
-- balance amount) components that don't involve the specified
-- commodity. Other item fields such as the transaction are left unchanged.
filterTransactionsReportByCommodity :: Commodity -> TransactionsReport -> TransactionsReport
filterTransactionsReportByCommodity c (label,items) =
  (label, fixTransactionsReportItemBalances $ concat [filterTransactionsReportItemByCommodity c i | i <- items])
  where
    filterTransactionsReportItemByCommodity c (t,t2,s,o,a,bal)
      | c `elem` cs = [item']
      | otherwise   = []
      where
        cs = map acommodity as
        item' = (t,t2,s,o,a',bal)
        a' = filterMixedAmountByCommodity c a

    fixTransactionsReportItemBalances [] = []
    fixTransactionsReportItemBalances [i] = [i]
    fixTransactionsReportItemBalances items = reverse $ i:(go startbal is)
      where
        i:is = reverse items
        startbal = filterMixedAmountByCommodity c $ triBalance i
        go _ [] = []
        go bal ((t,t2,s,o,amt,_):is) = (t,t2,s,o,amt,bal'):go bal' is
          where bal' = bal + amt

-- | Filter out all but the specified commodity from this amount.
filterMixedAmountByCommodity :: Commodity -> MixedAmount -> MixedAmount
filterMixedAmountByCommodity c (Mixed as) = Mixed $ filter ((==c). acommodity) as

so that we can render one line for each commodity:

registerChartHtml :: [[TransactionsReportItem]] -> HtmlUrl AppRoute
registerChartHtml itemss =
...
     \$.plot(chartdiv,
             [
              $forall items <- itemss
               [
                $forall i <- reverse items
                 [#{dayToJsTimestamp $ triDate i}, #{triSimpleBalance i}],
                []
               ],
              []
             ],
             {
               xaxis: {
                mode: "time",
                timeformat: "%y/%m/%d"
               }
             }
             );
...

Paul Potts: Objective-C, Day 2

noreply@blogger.com (Paul Potts) — Tue, 04 Jun 2013 02:57:00 +0000

(Warning: non-FP content)

So today I'm working on chapter 3 in iOS Programming. This is about memory management. I have vague memories of manual reference-counting using retain and release in earlier experiments with Objective-C, but this book teaches ARM (Automatic Reference Counting). You enable ARM when you configure an XCode project of iOS.

The idea behind object references (well, pointers in iOS) and trees of objects and their owners is not new to me. And here they they still do not clarify whether a statement like items = nil actually invokes runtime behavior to destroy objects. I believe it does not. When I override a dealloc method to log, I see that the dealloc methods are called when the curly brace at the end of @autoreleasepool is reached. This makes sense, as in C it is the point where variables go out of scope. So reference-counting bookkeeping must be invoked then. It does not seem to be possible to step in with the debugger at this point to view what is happening, though -- Apple's Objective-C runtime is proprietary software.

We next get into weak references. There's a __weak specifier that can appear as part of an object pointer declaration, and iOS Programming says that "an interesting property of weak references is that they know when the object they reference is destroyed... the [parent object] automatically sets its [child object] instance variable to nil." I'm going to have to read more about that. I really wish this book were more precise in its language. There's another specifier, __unsafe_unretained, which is not set -- and so a pointer to a destroyed object could still be dereferenced. I suppose I should just be happy that this works and use it, but I'm the type to want to know what is going on at the register level. Apparently ARC (the "automatic" in reference-counting) is all due to some amazing work done in clang, where the static analysis actually figures out all the possible points of object creation and deletion and can wrap up your reference-counting for you. That seems like a great development -- because I've never quite liked how garbage collectors (at least, those without hardware support), no matter how efficient they are, had to actually be implemented, looking at dumb machine pointers. It seems to me that there could be room in purely-GC'ed languages for this kind of static analysis. But I haven't thought very hard about that yet.

Properties seem to be a shorthand, asking the compiler to provide getters and setters. There's a great example as to how much code this can eliminate. There's a strange wart in that we are asked to specify (nonatomic) in every property, because that is not the default setting. Presumably this is to support multiple threads accessing the object. Again, a dark corner to look into.

For a little refresher, I took a break by reading the first few chapters of Brad Cox's book. He outlines his vision of a software IC, along the lines of a hardware C, that would support reusability primarily through late binding, limited interfaces, and wrapping up functionality with data so that clients don't have to write the operations on an object's data type. It's an interesting vision.

Cox writes of early Objective-C:

Objective-C adds precisely one new data type, the object, to those C provides already, and precisely one new operation, the message expression.

Cox's book indicates that early versions of Objective-C used an intermediate preprocessor step, between the C macro-preprocessing step and the regular C compiler. If you are my age you might recall that, early on, C++ was treated similarly, with a program called CFront. This is no longer the case with either Objective-C or C++, although this approach lives on in tools like Qt, with its Meta Object Compiler, or moc).

Cox describes the pragmatic design of Objective-C:

One of Objective-C's key features is that it is always possible to bypass the object-oriented machinery to access an object's private information directly. This is one of a hybrid language's greatest theoretical weaknesses and one of its greatest pragmatic strengths. Low-level code is often best developed in a conventional manner, exploiting static binding to obtain high machine efficiency and strong type checking. Conversely, user-level code is often best written as objects. It is important that these levels interface smoothly and efficiently.

There is an interesting passage about object identifiers. In a slight muddling of his earlier statement he writes that "objects are identified by a new Objective-C data type called an id, or object identifier." In practice, though, this isn't really a new data type per se. The address (a pointer to) an object is this identifier. The veneer over C is so thin that, he writes, it would have been perfectly feasible to implement the dynamic message sends using straightforward C language calls like

reply = _msg_(aReceiver, "aMessage", argument1, ...)

(I assume he'd use C's variable-length argument list mechanism here), but for efficiency he wanted to avoid string comparison in the dispatch mechanism. Cox was quite aware of the reaction that messages like [anObject do:arg1 with:arg2] would inspire in C programmers, writing "the convention seems strange to those accustomed to conventional function call syntax, and frankly, I find it a mixed blessing."

In this formulation, Objective-C classes were still objects, and class methods were called "factory methods" (but I'm peeking ahead a number of pages, so there might be some differences from their current incarnation), as distinct from instance methods. Cox writes "...the programmer conceives the initial object... the loader gives it life by installing it in memory... this is done once for each class in the system. These primal objects are called factory objects... every factory's name is published in a global variable."

Cox is a very thoughtful writer and he presents a minimalist view of what an object-oriented language requires in order to provide the most basic advantage of OOP. He writes:

One last time: the only substantive difference between conventional programming and object-oriented programming is the selection mechanism. This is not to minimize its importance, but to demystify what is basically a very simple notion. Its significance is that it moves a single responsibility across the boundary between the consumer of a service and the supplier of that service. In conventional programming, the consumer is responsible for choosing functions that operate properly on the data managed by that service. The selection mechanism moves that single responsibility off the consumer and onto the supplier. In this small change lies all the power of the technique.

That really caused me to, as they say, nearly drop my monocle. Could this really be where most of the advantage, such as it is, imperfectly realized, understood, and applied, of OOP comes from?

The mainstream business world got C++ instead, a mash-up of C and Simula, and then Java instead, the Cobol of object-oriented programming languages. I was not pleased. As I consider my career I also consider which implementation languages I should focus my efforts on, for the next decade. After exposure to Haskell it's hard to believe that, ultimately, functions -- without explicit state -- won't prove to be a cleaner reusable element than classes, whatever kind of binding they use. And don't get me wrong -- I like classes. I'm pretty certain that I'll still be writing C code, at least occasionally, in ten years. I'd prefer to be writing less C++. But what I'd really like is to move on -- to pick a "last programming language." Objective-C isn't that, for me -- it's too imperative, and can't truly be made safe, just safer. I'm enjoying it in this context, but would Objective-C even be an viable option outside of the Apple ecosystem? It doesn't seem to have gained much adoption. The state of GnuStep doesn't seem terribly robust. And so my career-long quest for a Better Way continues, while at the same time trying to gain facility with all the Good Ways along the way.

Luke Palmer: The Plan

Mon, 03 Jun 2013 20:49:26 +0000

Last September, I decided that it was time to get a programming job again. After two months of trying to find paid work (of any kind, $10 would have been great!) as a composer, I realized that it’s really hard. There are a lot of people willing to work for free, and without much of a scoring portfolio (as opposed to the “pure music” I do) I have no way to distinguish myself to the studios that have a budget. Also, a lot of games want orchestral scores, and I don’t have the hardware and software I need to make convincing-sounding synthetic orchestral scores. Also, I’m sure once I get the necessary hardware and software, I will need time to practice with it. In short, I needed money and time. I am extremely fortunate to have, in my free-flowing way, stumbled onto a skill that is valued by the economy, and so I decided it was once again time to utilize that skill to achieve my other goals. I planned to live reasonably cheaply, save up money so that I can buy equipment and support myself for enough time to build up a portfolio by doing free projects.

Now I have been programming for Clozure for almost six months. As far as jobs go, it’s great. I get to work in my favorite language, Haskell, and they give me enough freedom to experiment with designs and come up with solutions that not only work, but that I would even consider good. My fear of programming jobs was based on having jobs where I constantly have to compromise my values, either by working in crappy languages or on startup-style timelines where there is no time to lose. With this job, I feel reunited with my love of software, and my inspirations for developer support tools have been once again ignited.

And so I have amended the plan: after I have saved enough money to support myself for several years, I will not only attempt to bootstrap a career composing, but dedicate my current work week to making a reality the software ideas which have been floating around in my head for half a decade. This prospect really excites me — the reason I have not been able to make my ideas is mostly the time pressure: there’s was always something else I should be doing, and so I always felt guilty working on my pet projects. I wonder, what am I capable of if my pet projects are the main thing?

I want to revive CodeCatalog. Max and I lost steam on that project for a number of reasons.

Due to family pressure, I returned to school.
I fell in love with a girl and got my heart all broken. That can be kind of a downer.
The priorities of the project compromised my vision. We were attempting to use modern wisdom to make the project successful: first impressions and intuitive usability came first. Our focus was on making it pretty and satisfying to use (which took a long time since neither of us were experienced web front-end developers), and that required me to strip off the most interesting parts of the project because noobs wouldn’t immediately understand it.

So I want to re-orient (3) to make it more satisfying for me. I want to allow myself to make the large strides that I envisage rather than baby-stepping toward success — to encourage myself to use my own talents in design and abstraction rather than trying to be a front-end person, to emphasize the exciting parts (what Audrey Tang calles -Ofun). By funding myself, I will not feel the guilt that comes with working on a project at the same time as (1). I can do no more than hope that something like (2) doesn’t happen. (I have a wonderful, stable and supportive relationship right now, so if that continues, that’d cover it :-)

I have many ideas; the reason I want to return to CodeCatalog in particular is mainly because I have identified most of my ideas as aspects of this project. My specific fancies change frequently (usually to things I have thought about before but never implemented), and so by focusing on this project in a researchy rather than producty way, I can entertain them while still working toward a larger goal and eventually benefitting the community.

Here is a summary of some ideas that fit in the CodeCatalog umbrella (just because I’m excited and want to remember):

Inter-project version control — I have always been frustrated by the inability of git and hg to merge two projects while still allowing interoperation with where they came from. The “project” quantum seems arbitrary, and I want to globalize it.
Package adapters — evolving the interface of a package without breaking users of the old interface by rewriting the old package in terms of the new one. There is a great deal that can be done automatically in this area with sufficient knowledge about the meaning of changes. I talked with Michael Sloan about this some, and some of the resulting ideas are contained in this writeup.
Informal checked documentation — documenting the assumptions of code in a machine-readable semi-formal language, to get the computer to pair-program with you (e.g. you write a division x/y and you have no y /= 0 assumption in scope, you’d get a “documentation obligation” to explain in english why y can’t be 0).
Structural editing — coding by transforming valid syntax trees. Yes it’d be cool, but the main reason it’s compelling to me is in its synergy with other features. Once you have the notion of focusing on expressions, holes with contextual information (a la Agda), semi-automatic creation of package and data-type adapters, smarter version control (e.g. a change might rename all references to an identifier, even the ones that weren’t there when the change was made) all come as natural extensions to the idea.

I think the challenge for me will be to focus on one of these for long enough to make it cool before getting distracted by another. My plan for that is to set short-term goals here on my blog and use it to keep myself in check. I am considering involving other people in my project as a way to keep myself focused (i.e. maybe I can make a little mini-kickstarter in which my devotees can pledge small amounts in exchange for me completing a specific goal on time).

This is all two years away or more, which feels like a long time, but in the grand scheme is not that long in exchange for what I see as the potential of this endeavor. I’m just excited and couldn’t help but to think about it and get pumped up. Thanks for reading!

Oh, despite the date, this is totally not an April Fools joke (as far as I know ;-).

Mike Izbicki: HLearn cross-validates >400x faster than Weka

Mon, 03 Jun 2013 15:33:16 +0000

Weka is one of the most popular tools for data analysis. But Weka takes 70 minutes to perform leave-one-out cross-validate using a simple naive bayes classifier on the census income data set, whereas Haskell’s HLearn library only takes 9 seconds. Weka is 465x slower!

Code and instructions for reproducing these experiments are available on github.

Why is HLearn so much faster?

Well, it turns out that the bayesian classifier has the algebraic structure of a monoid, a group, and a vector space. HLearn uses a new cross-validation algorithm that can exploit these algebraic structures. The standard algorithm runs in time , where is the number of “folds” and is the number of data points. The algebraic algorithms, however, run in time . In other words, it doesn’t matter how many folds we do, the run time is constant! And not only are we faster, but we get the exact same answer. Algebraic cross-validation is not an approximation, it’s just fast.

Here’s some run times for k-fold cross-validation on the census income data set. Notice that HLearn’s run time is constant as we add more folds.

And when we set k=n, we have leave-one-out cross-validation. Notice that Weka’s cross-validation has quadratic run time, whereas HLearn has linear run time.

HLearn certainly isn’t going to replace Weka any time soon, but it’s got a number of cool tricks like this going on inside. If you want to read more, you should check out these two recent papers:

(ICML13) Algebraic Classifiers: a generic approach to fast cross-validation, online training, and parallel training

(TFP13) HLearn: a machine learning library for Haskell

I’ll continue to write more about these tricks in future blog posts.

Subscribe to the RSS feed to stay tuned.

Simon Michael: Earth Nap

Mon, 03 Jun 2013 06:45:00 +0000

June 3, 2013

Earth Nap

Let’s take a break from all this hledger stuff. I’ve been programming for about 30 years, and I’ve acquired - often the hard way - some tricks, tools and habits helpful for balance and productivity as a working programmer. We are all different, but I bet some of you could also use these. Here’s one - I’ll call it Earth Nap. It’s very simple:

Find a patch of earth where you can lie down without being disturbed.
Lie down. If possible, cover your eyes or head.
Rest with eyes closed, doze, or nap for 5-30 minutes.
Reactivate gently. Stretch, rub your face/hands/feet, roll up, maybe sing, shake out the cobwebs or walk a little.

A good time is after lunch, or early/mid/late afternoon. Or any time you feel fatigued, over-pressured, or burnt out. There is always time for a 5m break.

Direct contact between your skin and the earth is ideal. Lately I’ve done it on the beach and under a tree in a nearby quiet park - perfect. At my last client gig, I was onsite all day and there was no park and no quiet.. but there was an unused stair leading up to a small concrete landing where no one went. A few minutes in my secret lair made a big difference!

If you’re likely to sleep longer than 30m, set a gentle alarm (a deeper sleep rhythm kicks in after about 45 minutes which would leave you feeling groggy). Or, just watch/trust your body/mind’s natural napping cycle. It’s not necessary to fall asleep. You may notice yourself sink into a dozing/free association/dreaming state, then return to wakefulness.

Each time you do this, observe the effects. You might notice:

more calmness/cheerfulness
less mental noise
better concentration
better coping skills and emotional resilience
slower, more powerful energy
less addiction/aversion to pleasant/unpleasant tasks
less vulnerability to “rabbit holes” (mentally enticing, demanding tasks which fan out endlessly and lead nowhere)
new ideas and solutions appearing effortlessly
more energy left over at end of day

Tom Moertel: Tricks of the trade: Recursion to Iteration, Part 3: Recursive Data Structures

Mon, 03 Jun 2013 00:00:00 +0000

Posted on June 3, 2013

Tags: programming, recursion, iteration, python, recursion-to-iteration series, tail calls, data structures

This is the third article in a series on converting recursive algorithms into iterative algorithms. If any of what follows seems confusing, you may want to read the earlier articles first.

This is an extra article that I hadn’t planned. I’m writing it because in a comment on the previous article a reader asked me to show a less mathematical example and suggested tree traversal. So that’s the subject of this article: We’ll take a binary tree and flatten it into a list, first recursively, then iteratively.

The challenge

First, let’s define a binary tree to be either empty or given by a node having three parts: (1) a value, (2) a left subtree, and (3) a right subtree, where both of the subtrees are themselves binary trees. In Haskell, we might define it like so:

data BinaryTree a = Empty | Node a (BinaryTree a) (BinaryTree a)

In Python, which we’ll use for the rest of this article, we’ll say that None represents an empty tree and that the following class represents a node:

import collections
Node = collections.namedtuple('Node', 'val left right')

# some sample trees having various node counts
tree0 = None  # empty tree
tree1 = Node(5, None, None)
tree2 = Node(7, tree1, None)
tree3 = Node(7, tree1, Node(9, None, None))
tree4 = Node(2, None, tree3)
tree5 = Node(2, Node(1, None, None), tree3)

Let us now define a function to flatten a tree using an in-order traversal. The recursive definition is absurdly simple, the data type having only two cases to consider:

def flatten(bst):
    # empty case
    if bst is None:
        return []
    # node case
    return flatten(bst.left) + [bst.val] + flatten(bst.right)

A few tests to check that it does what we expect:

def check_flattener(f):
    assert f(tree0) == []
    assert f(tree1) == [5]
    assert f(tree2) == [5, 7]
    assert f(tree3) == [5, 7, 9]
    assert f(tree4) == [2, 5, 7, 9]
    assert f(tree5) == [1, 2, 5, 7, 9]
    print 'ok'

check_flattener(flatten)  # ok

Our challenge for today is to convert flatten into an iterative version. Other than a new trick – partial evaluation – the transformation is straightforward, so I’ll move quickly.

Let’s do this!

Eliminating the first recursive call

First, let’s separate the base case from the incremental work:

def step(bst):
    return flatten(bst.left) + [bst.val] + flatten(bst.right)

def flatten(bst):
    if bst is None:
        return []
    return step(bst)

And let’s break the incremental work into smaller pieces to see what’s going on.

def step(bst):
    left = flatten(bst.left)
    left.append(bst.val)
    right = flatten(bst.right)
    left.extend(right)
    return left

def flatten(bst):
    if bst is None:
        return []
    return step(bst)

Let’s try to get rid of the first recursive call by assuming that somebody has passed us its result via a secret argument left:

def step(bst, left=None):
    if left is None:
        left = flatten(bst.left)
    left.append(bst.val)
    right = flatten(bst.right)
    left.extend(right)
    return left

def flatten(bst):
    if bst is None:
        return []
    return step(bst)

And now we’ll make step return values that parallel its input arguments:

def step(bst, left=None):
    if left is None:
        left = flatten(bst.left)
    left.append(bst.val)
    right = flatten(bst.right)
    left.extend(right)
    return bst, left  # <-- add bst

def flatten(bst):
    if bst is None:
        return []
    return step(bst)[-1]  # <-- note [-1]

In the first recursive call, the transformation applied to bst is .left, so we want to apply the opposite transformation to bst in the returned values. And what’s the opposite of descending to a node’s left subtree? It’s ascending to the node’s parent. So we want something like this:

# this code does not work!

def step(bst, left=None):
    if left is None:
        left = flatten(bst.left)
    left.append(bst.val)
    right = flatten(bst.right)
    left.extend(right)
    return get_parent(bst), left  # <-- need get_parent

But we’re stuck. We can’t define get_parent because our tree data structure doesn’t keep track of parents, only children.

New plan: Maybe we can assume that someone has passed us the node’s parent and go from there?

But this plan hits the same brick wall: If we add a new argument to accept the parent, we must for parallelism add a new return value to emit the transformed parent, which is the parent of the parent. But we can’t compute the parent of the parent because, as before, we have no way of implementing get_parent.

So we do what mathematicians do when their assumptions hit a brick wall: we strengthen our assumption! Now we assume that someone has passed us all of the parents, right up to the tree’s root. And that assumption gives us what we need:

def step(bst, parents, left=None):
    if left is None:
        left = flatten(bst.left)
    left.append(bst.val)
    right = flatten(bst.right)
    left.extend(right)
    return parents[-1], parents[:-1], left

Note that we’re using the Python stack convention for parents; thus the immediate parent of bst is given by the final element parents[-1].

As a simplification, we can eliminate the bst argument by considering it the final parent pushed onto the stack:

def step(parents, left=None):
    bst = parents.pop()  # <-- bst = top of parents stack
    if left is None:
        left = flatten(bst.left)
    left.append(bst.val)
    right = flatten(bst.right)
    left.extend(right)
    return parents, left

Now that step requires the parents stack as an argument, the base function must provide it:

def flatten(bst):
    if bst is None:
        return []
    parents = [bst]
    return step(parents)[-1]

But we still haven’t eliminated the first recursive call. To do that, we’ll need to pass the step function a value for its left argument, which will cause the recursive call to be skipped.

But we only know what that value should be for one case, the base case, when bst is None; then left must be []. To get to that case from the tree’s root, where bst is definitely not None, we must iteratively replicate the normal recursive calls on bst.left until we hit the leftmost leaf node. And then, to compute the desired result, we must reverse the trip, iterating the step function until we have returned to the tree’s root, where the parents stack must be empty:

def flatten(bst):
    # find initial conditions for secret-feature "left"
    left = []
    parents = []
    while bst is not None:
        parents.append(bst)
        bst = bst.left
    # iterate to compute the result
    while parents:
        parents, left = step(parents, left)
    return left

And just like that, one of the recursive calls has been transformed into iteration. We’re halfway to the finish line!

Eliminating the second recursive call

But we still have to eliminate that final recursive call to flatten, now sequestered in step. Let’s take a closer look at that function after we make its left argument required since it always gets called with a value now:

def step(parents, left):
    bst = parents.pop()
    left.append(bst.val)
    right = flatten(bst.right)
    left.extend(right)
    return parents, left

To get rid of the recursive call to flatten, we’re going to use a new trick: partial evaluation. Basically, we’re going to replace the call to flatten with the function body of flatten, after we rename all its variables to prevent conflicts. So let’s make a copy of flatten and suffix all its variables with 1:

def flatten1(bst1):
    left1 = []
    parents1 = []
    while bst1 is not None:
        parents1.append(bst1)
        bst1 = bst1.left
    while parents1:
        parents1, left1 = step(parents1, left1)
    return left1

And then let’s make its arguments and return values explicit:

    (bst1, ) = ARGUMENTS
    left1 = []
    parents1 = []
    while bst1 is not None:
        parents1.append(bst1)
        bst1 = bst1.left
    while parents1:
        parents1, left1 = step(parents1, left1)
    RETURNS = (left1, )

And then we’ll drop this expansion into step:

def step(parents, left):
    bst = parents.pop()
    left.append(bst.val)
    # -- begin partial evaluation --
    (bst1, ) = (bst.right, )
    left1 = []
    parents1 = []
    while bst1 is not None:
        parents1.append(bst1)
        bst1 = bst1.left
    while parents1:
        parents1, left1 = step(parents1, left1)
    (right, ) = (left1, )
    # -- end partial evaluation --
    left.extend(right)
    return parents, left

Now we can eliminate code by fusion across the partial-evaluation boundary.

First up: left1. We can now see that this variable accumulates values that, in the end, get appended to left (via the return variable right). But we can just as well append those values to left directly, eliminating left1 within the boundary and the call to left.extend(right) without:

def step(parents, left):
    bst = parents.pop()
    left.append(bst.val)
    # -- begin partial evaluation --
    (bst1, ) = (bst.right, )
    # left1 = []  # <-- eliminate and use left instead
    parents1 = []
    while bst1 is not None:
        parents1.append(bst1)
        bst1 = bst1.left
    while parents1:
        parents1, left = step(parents1, left)
    # (right, ) = (left, )  # <-- eliminated
    # -- end partial evaluation --
    # left.extend(right)  # <-- eliminated
    return parents, left

For this next fusion, we’re going to need to recall our base function to get the necessary outside scope:

def step(parents, left):
    bst = parents.pop()
    left.append(bst.val)
    # -- begin partial evaluation --
    (bst1, ) = (bst.right, )
    parents1 = []
    while bst1 is not None:
        parents1.append(bst1)
        bst1 = bst1.left
    while parents1:
        parents1, left = step(parents1, left)
    # -- end partial evaluation --
    return parents, left

def flatten(bst):
    left = []
    parents = []
    while bst is not None:
        parents.append(bst)
        bst = bst.left
    while parents:
        parents, left = step(parents, left)
    return left

When flatten calls step and the code within the partially evaluated region executes, it builds up a stack of nodes parents1 and then calls step iteratively to pop values off of that stack and process them. When it’s finished, control returns to step proper, which then returns to its caller, flatten, with the values (parents, left). But look at what flatten then does with parents: it calls step iteratively to pop values off of that stack and process them in exactly the same way.

So we can eliminate the while loop in step – and the recursive call! – by returning not parents but parents + parents1, which will make the while loop in flatten do the exact same work.

def step(parents, left):
    bst = parents.pop()
    left.append(bst.val)
    # -- begin partial evaluation --
    (bst1, ) = (bst.right, )
    parents1 = []
    while bst1 is not None:
        parents1.append(bst1)
        bst1 = bst1.left
    # while parents1:                            # <-- eliminated
    #     parents1, left = step(parents1, left)  #
    # -- end partial evaluation --
    return parents + parents1, left  # parents -> parents + parents1

And then we can eliminate parents1 completely by taking the values we would have appended to it and appending them directly to parents:

def step(parents, left):
    bst = parents.pop()
    left.append(bst.val)
    # -- begin partial evaluation --
    (bst1, ) = (bst.right, )
    # parents1 = []  # <-- eliminated
    while bst1 is not None:
        parents.append(bst1)  # parents1 -> parents
        bst1 = bst1.left
    # -- end partial evaluation --
    return parents, left  # parents + parents1 -> parents

And now, once we remove our partial-evaluation scaffolding, our step function is looking simple again:

def step(parents, left):
    bst = parents.pop()
    left.append(bst.val)
    bst1 = bst.right
    while bst1 is not None:
        parents.append(bst1)
        bst1 = bst1.left
    return parents, left

For the final leg of our journey – simplification – let’s inline the step logic back into the base function:

def flatten(bst):
    left = []
    parents = []
    while bst is not None:
        parents.append(bst)
        bst = bst.left
    while parents:
        parents, left = parents, left
        bst = parents.pop()
        left.append(bst.val)
        bst1 = bst.right
        while bst1 is not None:
            parents.append(bst1)
            bst1 = bst1.left
        parents, left = parents, left
    return left

Let’s eliminate the trivial argument-binding and return-value assignments:

def flatten(bst):
    left = []
    parents = []
    while bst is not None:
        parents.append(bst)
        bst = bst.left
    while parents:
        # parents, left = parents, left  # = no-op
        bst = parents.pop()
        left.append(bst.val)
        bst1 = bst.right
        while bst1 is not None:
            parents.append(bst1)
            bst1 = bst1.left
        # parents, left = parents, left  # = no-op
    return left

And, finally, factor out the duplicated while loop into a local function:

def flatten(bst):
    left = []
    parents = []
    def descend_left(bst):
        while bst is not None:
            parents.append(bst)
            bst = bst.left
    descend_left(bst)
    while parents:
        bst = parents.pop()
        left.append(bst.val)
        descend_left(bst.right)
    return left

And that’s it! We now have a tight, efficient, and iterative version of our original function. Further, the code is close to idiomatic.

That’s it for this time. If you have any questions or comments, just hit me at @tmoertel or use the comment form below.

Thanks for reading!

FP Complete: Haskell from C: Where are the for Loops?

Sun, 02 Jun 2013 18:00:00 +0000

This post contains fragments of active Haskell code, best viewed and executed at https://www.fpcomplete.com/blog/2013/06/haskell-from-c

If you're coming from a language like C, Haskell can take some getting used to. It's typical for a new language to feel a little different, but in Haskell the differences are more dramatic, and more fundamental. In particular...

Where are the `for` loops?

In most imperative languages, for loops are all over the place, and are used for a wide variety of different things. Whether you're squaring every value of an array or finding its sum, you're probably using a for loop.

In Haskell, control structures are more expressive. Sure, there's a counterpart to C's for (Haskell's forM_). But that's a discussion for another time. Today, we'll see some for loops in C that can be written very differently in Haskell, and why that's a good thing.

Consider the simple example of computing the norm of a vector. For a vector x∈ℝⁿ, this is just

\begin{matrix} | | x | | = \sqrt{\sum_{i = 0}^{n - 1} x_{i}^{2}} \end{matrix}

Conceptually, there are three stages to this computation:

mapSq: Square each element
sum: Compute the sum
sqrt: Compute the square root

We can think of the first step as building (at least abstractly) a new array whose ith element is y[i] = x[i] * x[i]. In functional programming, we refer to this as mapping the square function over the array.

Putting everything in terms of functions, we can write this (in Haskell-like pseudocode) as

norm(x) = sqrt(sum(mapSq(x))) ,

To clean up the syntax a bit, we can instead use the notation for function composition and write

norm(x) = (sqrt ○ sum ○ mapSq)(x) ,

or just

norm = sqrt ○ sum ○ mapSq .

Computing Norms in C

In C, this modular approach leads to something like

void mapSq(double *x, double *y, int n) {
  int i;
  for(i=0; i<n; i++) {
    y[i] = x[i] * x[i];
  }
}

double sum(double *x, int n) {
  double result = 0;
  int i;
  for(i=0; i<n; i++) {
    result += x[i];
  }
  return result;
}

double norm1(double *x, int n) {
  double *y = malloc(n * sizeof(double));
  mapSq(x, y, n);
  theSum = sum(y, n);
  free(y);
  return sqrt(theSum);
}

We'd probably never do it this way, for a few reasons:

For such a simple computation, it's way too verbose.
It uses two separate for loops, where only one is needed.
There's an unnecessary malloc that's unlikely to be removed by the compiler.

If it weren't for these issues, we probably would write code like the above. It has the advantage of being more modular and of faithfully representing the concepts. But the problems are too big to ignore, so we typically make some code transformations in our head, and instead write

double norm2(double *x, int n) {
  double theSum = 0.0;
  for (int i = 0; i < n; i++) { 
    theSum += x[i]*x[i]; }
  return sqrt(theSum);
}

This code is very clear, and performs well, but we've entirely lost modularity. In this case the code is very short, so we don't give the compromise a second thought. But at a larger scale, this kind of manual optimization reduces code reuse and makes components more complex. Code becomes harder to understand, and harder to test for correctness.

Computing Norms in Haskell

In Haskell, we could write norm as

import Prelude hiding (sum)
import Data.List (foldl')

-- show
mapSq x = map sq x
  where
  sq xi = xi * xi

sum x = foldl' (+) 0.0 x

norm x = (sqrt . sum . mapSq) x

main = print (norm [1,2,3,4,5])

While the C example is in terms of arrays, this Haskell example instead uses lazy linked lists. We'll change this in a bit.

Let's step through this code. The first function, mapSq, is defined in terms of the map function, and produces a new list by squaring every element of the original list. The squaring function sq can also be written as (\x -> x*x), allowing us to write the function as

mapSq x = map (\x -> x*x) x

or simply

mapSq = map (\x -> x*x)

Next, the sum function is defined in terms of foldl'. Before you worry too much about the name, you should know that a fold is just a function that traverses some data structure, using a given function to update some accumulator as it goes. In the current case, the accumulator is the counterpart of "theSum" in the C version. Accumulation is via addition, and starts at 0.0.

Lists can be folded from either side. In our case, we're using foldl'. The "l" in this function name is for "left", the side we're starting on, and the "'" indicates that this fold is strict. Haskell is lazy by default, but for numeric there's no point in delaying evaluation of the accumulator (and for large lists it can lead to a stack overflow), so in this case we prefer to evaluate it at every step.

As it turns out, our sum function is common enough that it's included in Haskell's Prelude; we can use it exactly as described with no need to define it.¹ Our norm function is now simple:

norm = sqrt . sum . map (\x -> x*x)

main = print (norm [1,2,3,4,5])

This looks remarkably like the mathematical specification; some have affectionately refered to Haskell as an executable specification language.

But what about performance?

Let's compare performance with C. In order to measure easily across languages, we'll make the vector much bigger - lets say a billion elements. We'll start with a standard list implementation in Haskell and compare this to an implementation in C using arrays. Then we'll make a couple of minor changes in Haskell that allow us to use unboxed vectors.

We'll test using an AMD A6-3670 APU running Ubuntu 13.04. For compilation, we'll use GHC 7.6.3 (with -O2) and GCC 4.7.3 (with -O3).

Haskell - Lists

Our Haskell version is certainly elegant, but using linked lists in this way is not the best approach for performance. For a billion elements, the running time is over 2 minutes. What's going on here?

Haskell lists are lazy (only those elements required by later calculations are computed) and polymorphic (you can have a list of elements of any type, even if elements of that type don't take up a fixed number of bytes). In order to implement this, a list in Haskell is really a list of pointers to elements. In cases like this, all that pointer chasing adds up.

We'll soon see an easy way to improve this and get Haskell running really fast.

C - Arrays

Before we get Haskell zipping along, let's look at how we would do this in C. We'll use the faster version of our norm in C (norm2 above). Here's the plan:

malloc an array of a billion elements
Fill the array so that x[i] = i
Find the norm of the vector
Free the array and print the result

We'll use the OS to measure the time of the whole process, and insert some code to measure step (3) alone. So all together we have this:

#include <time.h>
#include <math.h>
#include <stdio.h>
#include <stdlib.h>
#define x_size 1000000000

double norm(double *x, int n) {
  double theSum = 0.0;
  int i;
  for (i=0; i<n; i++) { 
    theSum += x[i]*x[i]; 
  }
  return sqrt(theSum);
}

int main() {
  double *x = malloc(x_size * sizeof(double));
  int i;
  for(i=0; i<x_size; i++) {
    x[i] = (double) i;
  }
  clock_t start = clock();
  double result = norm(x, x_size);
  clock_t end = clock();
  printf("%3.2f\n", result);
  printf("%3.2f sec\n", (end-start)/(double)CLOCKS_PER_SEC);
  free(x);
  return 0;
}

The whole thing takes about 7 seconds to run, with the norm function itself taking 1.9 seconds.

Haskell - Unboxed Vectors

To close in on C, let's make some minor changes. Instead of using lists, we'll use unboxed vectors. The "unboxed" qualifier just means that the elements are available directly, without the need to follow a pointer.

From a data structure standpoint, Haskell's vectors are a lot like C's arrays. There is an important difference, though; many operations on vectors (even boxed ones) are subject to fusion. A map followed by a sum will be represented as a tight loop, but the code can remain modular. Remember the malloc in our original C code? Through fusion, it's eliminated entirely.

Updating the original code to operate on vectors is straightforward. And To stay entirely outside the realm of lists, we can generate our vector using iterateN, which plays the role of our data-filling loop in C.

[EDIT: Because School of Haskell compilation does not use -O2, there is no fusion, so we'll need to keep the values a bit smaller. In this case, I'll use an unusually small value for oneBillion, though for benchmarking I still use 10⁹]

import Data.Vector.Unboxed as V

norm ::  Vector Double -> Double
norm = sqrt . V.sum . V.map (\x -> x*x)

oneBillion = 100

main = print $ norm $ V.iterateN oneBillion (+1) 0.0

This code runs in about 2.5 seconds. It's just a bit longer than C's inner loop alone, but much less than the 7 seconds if the malloc is included.

EDIT: As Pedro Vasconcelos points out, tight numerical loops like this can often benefit from using the LLVM back-end, via -fllvm. This brings the time for the entire Haskell run down to 1.9 seconds, the same as the inner loop alone in C!

Conclusion

Haskell's control structures express that a reduction (a fold in Haskell) is very different than a map.² Libraries like vector implement powerful fusion techniques to combine loops and eliminate intermediate data structures. And unboxing elminates excessive pointer chasing required by built-in lists.

All in all, this lets us write high-level code without sacrificing high performance. The need for any compromise between the two is becoming more rare every day.

¹ The Prelude's sum function is not defined in terms of foldl', but instead relies on GHC's strictness analysis. In GHC 7.6.3 there's a regression, as described in this ticket. Because of this, we stuck with foldl' (+) 0.0 in timing our Haskell version using lists.

² EDIT: Michael Sloan has pointed out that the difference is not so fundamental, since `map f = foldr ((:) . f) []`.

language-puppet: Hruby package released

Sat, 01 Jun 2013 06:42:00 +0000

I finally released the hruby package, along with an updated version of the language-puppet package. It is very unfortunate this package will never get proper haddocks on Hackage, as the documentation is quite useful. If someone has a suggestion for getting haddocks without having the ruby1.8 library installed, I am interested. Also the path to the Ruby include files is hardcoded, meaning it might require manual tweaking to get it right.

Both libraries now have build flags :

Hruby has a flag for ruby1.9. This flag is mostly cosmetic as I didn’t even test it, and just copied the files for ruby1.8.
Language-puppet now has a -fhruby option, to build with this library.

The immediate result is a two-fold speed increase for single runs of puppetresource, and a six-time speed-up for scripts computing several catalogs. The reason is that the parser is not too fast, but its results get cached. Also, the language-puppet daemon infrastructure still let you define the number of threads that should be spawned to compute templates. This should be set to 1. The ruby interpreter cannot be used in a thread-safe way.

There are still several issues to address. The first is related to the multiple variable assignment problem. In Puppet all variables are immutable, and can’t be reassigned. Well, except when overwriting variables belonging to an inherited class. I wish they never introduced inheritance, as it introduces all kind of special rules, and seems generally fragile. Moreover, given how I (have not) implemented scopes, it is not trivial to have a robust way to check if the overwrite is valid or not.

The second most important issue is the fact that the dependency system isn’t working as it should be. I still get dependency loops in Puppet that are not catched by language-puppet. This is a show-stopper, and must be fixed soon. It is however a big challenge.

Finally, as language-puppet is Linux only for now, I would like to start using the inotify feature. The current caching mechanism works by issuing stat system calls on all files that might have changed. Inotify would greatly reduce the number of system calls, which is always a good thing. I am not sure this would lead to a big speed increase however.

Ken T Takusagawa: [spovtkwt] Equiangular pentagon

noreply@blogger.com (Ken) — Fri, 31 May 2013 17:56:36 +0000

Finding not many good pictures of a pentagon with equal angles but unequal sides, I drew one. For reference, inside it is a regular pentagon; corresponding sides are parallel.

Haskell source code is here.

And in Scalable Vector Graphics (SVG) format:

Equiangular Pentagon in SVG

Someday, an amoeba-like animation which explores possible shapes of an equiangular pentagon of a constant area.

Philip Wadler: The EFF, Oracle, Google, and me

noreply@blogger.com (Philip Wadler) — Fri, 31 May 2013 15:39:13 +0000

The Electronic Frontier Foundation has submitted an amicus brief for the case of Oracle vs. Google, arguing that copyright should apply to code that implements an API, but not to the API itself, which anyone should be free to implement. The brief details a number of cases where the freedom to implement an API has led to social benefits. I am pleased to be a signatory of the brief, in the company of luminaries including John Parry Barlow, Jon Bentley, Frederick Brooks, David Dill, Les Earnest, Doug Lea, Martin Odersky, Bruce Schneier, Bjarne Stoustroup, and others.

Dominic Steinitz: Neural Networks and Automated Differentiation

Fri, 31 May 2013 14:30:22 +0000

Introduction

Neural networks are a method for classifying data based on a theory of how biological systems operate. They can also be viewed as a generalization of logistic regression. A method for determining the coefficients of a given model, backpropagation, was developed in the 1970’s and rediscovered in the 1980’s.

The article “A Functional Approach to Neural Networks” in the Monad Reader shows how to use a neural network to classify handwritten digits in the MNIST database using backpropagation.

The reader is struck by how similar backpropagation is to automatic differentiation. The reader may not therefore be surprised to find that this observation had been made before: Domke2009a. Indeed as Dan Piponi observes: “the grandaddy machine-learning algorithm of them all, back-propagation, is nothing but steepest descent with reverse mode automatic differentiation”.

Neural Networks

We can view neural nets or at least a multi layer perceptron as a generalisation of (multivariate) linear logistic regression.

We follow (Rojas 1996; Bishop 2006). We are given a training set:

of pairs of -dimensional and -dimensional vectors called the input and output patterns in Machine Learning parlance. We wish to build a neural network model using this training set.

A neural network model (or at least the specific model we discuss: the multi-layer perceptron) consists of a sequence of transformations. The first transformation creates weighted sums of the inputs.

where is the size of the input vector and there are neurons in the so called first hidden layer of the network. The weights are unknown.

The second transformation then applies a non-linear activation function to each to give the output from the -th neuron in the first hidden layer.

Typically, is chosen to be or the logistic function. Note that if it were chosen to be the identity then our neural network would be the same as a multivariate linear logistic regression.

We now repeat these steps for the second hidden layer:

Ultimately after we applied transformations (through hidden layers) we produce some output:

We show an example neural in the diagram below.

The input layer has 7 nodes. There are 2 hidden layers, the first has 3 nodes and the second has 5. The output layer has 3 nodes.

We are also given a cost function:

where is the predicted output of the neural net and is the observed output.

As with logistic regression, our goal is to find weights for the neural network which minimises this cost function. We initialise the weights to some small non-zero amount and then use the method of steepest descent (aka gradient descent). The idea is that if is a function of several variables then to find its minimum value, one ought to take a small step in the direction in which it is decreasing most quickly and repeat until no step in any direction results in a decrease. The analogy is that if one is walking in the mountains then the quickest way down is to walk in the direction which goes down most steeply. Of course one get stuck at a local minimum rather than the global minimum but from a machine learning point of view this may be acceptable; alternatively one may start at random points in the search space and check they all give the same minimum.

We therefore need calculate the gradient of the loss function with respect to the weights (since we need to minimise the cost function). In other words we need to find:

Once we have this we can take our random starting position and move down the steepest gradient:

where is the step length known in machine learning parlance as the learning rate.

Haskell Foreword

Some pragmas and imports required for the example code.

> {-# LANGUAGE RankNTypes                #-}
> {-# LANGUAGE DeriveFunctor             #-}
> {-# LANGUAGE DeriveFoldable            #-}
> {-# LANGUAGE DeriveTraversable         #-}
> {-# LANGUAGE ScopedTypeVariables       #-}
> {-# LANGUAGE TupleSections             #-}
> {-# LANGUAGE NoMonomorphismRestriction #-}

> {-# OPTIONS_GHC -Wall                     #-}
> {-# OPTIONS_GHC -fno-warn-name-shadowing  #-}
> {-# OPTIONS_GHC -fno-warn-type-defaults   #-}
> {-# OPTIONS_GHC -fno-warn-unused-do-bind  #-}
> {-# OPTIONS_GHC -fno-warn-missing-methods #-}

> module NeuralNet
>        ( test1
>        , test2
>        , test3
>        ) where

> import Numeric.AD
> import Numeric.AD.Types

> import Data.Traversable (Traversable)
> import Data.Foldable (Foldable)
> import Data.List
> import Data.List.Split
> import System.Random
> import qualified Data.Vector as V

> import Control.Monad
> import Control.Monad.State

> import Data.Random ()
> import Data.Random.Distribution.Beta
> import Data.Random.Distribution.Uniform
> import Data.RVar

> import Text.Printf

Logistic Regression Redux

Let us first implement logistic regression. This will give us a reference against which to compare the equivalent solution expressed as a neural network.

Instead of maximimizing the log likelihood, we will minimize a cost function.

> cost :: Floating a => V.Vector a -> a -> V.Vector a -> a
> cost theta y x = 0.5 * (y - yhat)^2
>   where
>     yhat = logit $ V.sum $ V.zipWith (*) theta x

> logit :: Floating a =>
>          a -> a
> logit x = 1 / (1 + exp (negate x))

We add a regularization term into the total cost so that the parameters do not grow too large. Note that we do not regularize over the bias.

> delta :: Floating a => a
> delta = 0.01

> totalCost :: Floating a =>
>              V.Vector a ->
>              V.Vector a ->
>              V.Vector (V.Vector a) ->
>              a
> totalCost theta y x = (a + delta * b) / l
>   where
>     l = fromIntegral $ V.length y
>     a = V.sum $ V.zipWith (cost theta) y x
>     b = (/2) $ V.sum $ V.map (^2) $ V.drop 1 theta

We determine the gradient of the regularized cost function.

> delTotalCost :: Floating a =>
>                 V.Vector a ->
>                 V.Vector (V.Vector a) ->
>                 V.Vector a ->
>                 V.Vector a
> delTotalCost y x = grad f
>   where
>     f theta = totalCost theta (V.map auto y) (V.map (V.map auto) x)

And finally we can apply gradient descent.

> gamma :: Double
> gamma = 0.4

> stepOnceCost :: Floating a =>
>                  a ->
>                  V.Vector a ->
>                  V.Vector (V.Vector a) ->
>                  V.Vector a ->
>                  V.Vector a
> stepOnceCost gamma y x theta =
>   V.zipWith (-) theta (V.map (* gamma) $ del theta)
>     where
>       del = delTotalCost y x

Neural Network Representation

Let us borrow, generalize and prune the data structures used in “A Functional Approach to Neural Networks”. Some of the fields in the borrowed data structures are probably no longer necessary given that we are going to use automated differentiation rather than backpropagation. Caveat lector!

The activation function itself is a function which takes any type in the Floating class to the same type in the Floating class e.g. Double.

> newtype ActivationFunction =
>   ActivationFunction
>   {
>     activationFunction :: Floating a => a -> a
>   }

A neural network is a collection of layers.

> data Layer a =
>   Layer
>   {
>     layerWeights  :: [[a]],
>     layerFunction :: ActivationFunction
>   } deriving (Functor, Foldable, Traversable)

> data BackpropNet a = BackpropNet
>     {
>       layers       :: [Layer a],
>       learningRate :: Double
>     } deriving (Functor, Foldable, Traversable)

We need some helper functions to build our neural network and to extract information from it.

> buildBackpropNet ::
>   Double ->
>   [[[a]]] ->
>   ActivationFunction ->
>   BackpropNet a
> buildBackpropNet learningRate ws f =
>   BackpropNet {
>       layers       = map buildLayer checkedWeights
>     , learningRate = learningRate
>     }
>   where checkedWeights = scanl1 checkDimensions ws
>         buildLayer w   = Layer { layerWeights  = w
>                                 , layerFunction = f
>                                 }
>         checkDimensions :: [[a]] -> [[a]] -> [[a]]
>         checkDimensions w1 w2 =
>           if 1 + length w1 == length (head w2)
>           then w2
>           else error $ "Inconsistent dimensions in weight matrix\n" ++
>                         show (length w1)        ++ "\n" ++
>                         show (length w2)        ++ "\n" ++
>                         show (length $ head w1) ++ "\n" ++
>                         show (length $ head w2)

> extractWeights :: BackpropNet a -> [[[a]]]
> extractWeights x = map layerWeights $ layers x

In order to undertake gradient descent on the data structure in which we store a neural network, BackpropNet, it will be convenient to be able to add such structures together point-wise.

> instance Num a => Num (Layer a) where
>   (+) = addLayer
> 
> addLayer :: Num a => Layer a -> Layer a -> Layer a
> addLayer x y =
>   Layer { layerWeights  = zipWith (zipWith (+))
>                                   (layerWeights x)
>                                   (layerWeights y)
>         , layerFunction = layerFunction x
>         }

> instance Num a => Num (BackpropNet a) where
>   (+) = addBPN

> addBPN :: Num a => BackpropNet a -> BackpropNet a -> BackpropNet a
> addBPN x y = BackpropNet { layers = zipWith (+) (layers x) (layers y)
>                           , learningRate = learningRate x
>                           }

We store information about updating of output values in each layer in the neural network as we move forward through the network (aka forward propagation).

> data PropagatedLayer a
>     = PropagatedLayer
>         {
>           propLayerIn         :: [a],
>           propLayerOut        :: [a],
>           propLayerWeights    :: [[a]],
>           propLayerActFun     :: ActivationFunction
>         }
>     | PropagatedSensorLayer
>         {
>           propLayerOut :: [a]
>         } deriving (Functor, Foldable, Traversable)

Sadly we have to use an inefficient calculation to multiply matrices; see this email for further details.

> matMult :: Num a => [[a]] -> [a] -> [a]
> matMult m v = result
>   where
>     lrs = map length m
>     l   = length v
>     result = if all (== l) lrs
>              then map (\r -> sum $ zipWith (*) r v) m
>              else error $ "Matrix has rows of length " ++ show lrs ++
>                           " but vector is of length " ++ show l

Now we can propagate forwards. Note that the code from which this is borrowed assumes that the inputs are images which are pixels each encoded using a grayscale, hence the references to bits and the check that values lie in the range .

> propagateNet :: (Floating a, Ord a, Show a) =>
>                 [a] ->
>                 BackpropNet a ->
>                 [PropagatedLayer a]
> propagateNet input net = tail calcs
>   where calcs = scanl propagate layer0 (layers net)
>         layer0 = PropagatedSensorLayer $ validateInput net input
> 
>         validateInput net = validateInputValues .
>                             validateInputDimensions net
> 
>         validateInputDimensions net input =
>           if got == expected
>           then input
>           else error ("Input pattern has " ++ show got ++
>                       " bits, but " ++
>                       show expected ++ " were expected")
>           where got      = length input
>                 expected = (+(negate 1)) $
>                            length $
>                            head $
>                            layerWeights $
>                            head $
>                            layers net
> 
>         validateInputValues input =
>           if (minimum input >= 0) && (maximum input <= 1)
>           then input
>           else error "Input bits outside of range [0,1]"

Note that we add a 1 to the inputs to each layer to give the bias.

> propagate :: (Floating a, Show a) =>
>              PropagatedLayer a ->
>              Layer a ->
>              PropagatedLayer a
> propagate layerJ layerK = result
>   where
>     result =
>       PropagatedLayer
>         {
>           propLayerIn         = layerJOut,
>           propLayerOut        = map f a,
>           propLayerWeights    = weights,
>           propLayerActFun     = layerFunction layerK
>         }
>     layerJOut = propLayerOut layerJ
>     weights   = layerWeights layerK
>     a = weights `matMult` (1:layerJOut)
>     f :: Floating a => a -> a
>     f = activationFunction $ layerFunction layerK

> evalNeuralNet :: (Floating a, Ord a, Show a) =>
>                  BackpropNet a -> [a] -> [a]
> evalNeuralNet net input = propLayerOut $ last calcs
>   where calcs = propagateNet input net

We define a cost function.

> costFn :: (Floating a, Ord a, Show a) =>
>           Int ->
>           Int ->
>           [a] ->
>           BackpropNet a ->
>           a
> costFn nDigits expectedDigit input net = 0.5 * sum (map (^2) diffs)
>   where
>     predicted = evalNeuralNet net input
>     diffs = zipWith (-) ((targets nDigits)!!expectedDigit) predicted

> targets :: Floating a => Int -> [[a]]
> targets nDigits = map row [0 .. nDigits - 1]
>   where
>     row m = concat [x, 1.0 : y]
>       where
>         (x, y) = splitAt m (take (nDigits - 1) $ repeat 0.0)

If instead we would rather perform gradient descent over the whole training set (rather than stochastically) then we can do so. Note that we do not regularize the weights for the biases.

> totalCostNN :: (Floating a, Ord a, Show a) =>
>                Int ->
>                V.Vector Int ->
>                V.Vector [a] ->
>                BackpropNet a ->
>                a
> totalCostNN nDigits expectedDigits inputs net = cost
>   where
>     cost = (a + delta * b) / l
> 
>     l = fromIntegral $ V.length expectedDigits
> 
>     a = V.sum $ V.zipWith (\expectedDigit input ->
>                             costFn nDigits expectedDigit input net)
>                           expectedDigits inputs
> 
>     b = (/(2 * m)) $ sum $ map (^2) ws
> 
>     m = fromIntegral $ length ws
> 
>     ws = concat $ concat $
>          map stripBias $
>          extractWeights net
> 
>     stripBias xss = map (drop 1) xss

> delTotalCostNN :: (Floating a, Ord a, Show a) =>
>                   Int ->
>                   V.Vector Int ->
>                   V.Vector [a] ->
>                   BackpropNet a ->
>                   BackpropNet a
> delTotalCostNN nDigits expectedDigits inputs = grad f
>   where
>     f net = totalCostNN nDigits expectedDigits
>                         (V.map (map auto) inputs) net

> stepOnceTotal :: Int ->
>                  Double ->
>                  V.Vector Int ->
>                  V.Vector [Double] ->
>                  BackpropNet Double ->
>                  BackpropNet Double
> stepOnceTotal nDigits gamma y x net =
>   net + fmap (* (negate gamma)) (delTotalCostNN nDigits y x net)

Example I

Let’s try it out. First we need to generate some data. Rather arbitrarily let us create some populations from the beta distribution.

> betas :: Int -> Double -> Double -> [Double]
> betas n a b =
>   fst $ runState (replicateM n (sampleRVar (beta a b))) (mkStdGen seed)
>     where
>       seed = 0

We can plot the populations we wish to distinguish by sampling.

> a, b :: Double
> a          = 15
> b          = 6
> nSamples :: Int
> nSamples   = 100000
> 
> sample0, sample1 :: [Double]
> sample0 = betas nSamples a b
> sample1 = betas nSamples b a

> mixSamples :: [Double] -> [Double] -> [(Double, Double)]
> mixSamples xs ys = unfoldr g ((map (0,) xs), (map (1,) ys))
>   where
>     g ([], [])         = Nothing
>     g ([],  _)         = Nothing
>     g ( _, [])         = Nothing
>     g ((x:xs), (y:ys)) = Just $ (x, (y:ys, xs))

> createSample :: V.Vector (Double, Double)
> createSample = V.fromList $ take 100 $ mixSamples sample1 sample0

> lRate :: Double
> lRate = 0.01
> actualTheta :: V.Vector Double
> actualTheta = V.fromList [0.0, 1.0]
> initTheta :: V.Vector Double
> initTheta = V.replicate (V.length actualTheta) 0.1

> logitAF :: ActivationFunction
> logitAF = ActivationFunction logit

> test1 :: IO ()
> test1 = do
> 
>   let testNet = buildBackpropNet lRate [[[0.1, 0.1], [0.1, 0.1]]] logitAF

>   let vals :: V.Vector (Double, V.Vector Double)
>       vals = V.map (\(y, x) -> (y, V.fromList [1.0, x])) $ createSample
> 
>   let gs = iterate (stepOnceCost gamma (V.map fst vals) (V.map snd vals))
>                    initTheta
>       theta = head $ drop 1000 gs
>   printf "Logistic regression: theta_0 = %5.3f, theta_1 = %5.3f\n"
>          (theta V.! 0) (theta V.! 1)
> 
>   let us = V.map (round . fst) createSample
>   let vs = V.map snd createSample
>   let fs = iterate (stepOnceTotal 2 gamma us (V.map return vs)) testNet
>       phi = extractWeights $ head $ drop 1000 fs
>   printf "Neural network: theta_00 = %5.3f, theta_01 = %5.3f\n"
>          (((phi!!0)!!0)!!0) (((phi!!0)!!0)!!1)
>   printf "Neural network: theta_10 = %5.3f, theta_11 = %5.3f\n"
>          (((phi!!0)!!1)!!0) (((phi!!0)!!1)!!1)

ghci> test1
  Logistic regression: theta_0 = -2.383, theta_1 = 4.852
  Neural network: theta_00 = 2.386, theta_01 = -4.861
  Neural network: theta_10 = -2.398, theta_11 = 4.886

Example II

Now let’s try a neural net with 1 hidden layer using the data we prepared earlier.

We seed the weights in the neural with small random values; if we set all the weights to 0 then the gradient descent algorithm might get stuck.

> uniforms :: Int -> [Double]
> uniforms n =
>   fst $ runState (replicateM n (sampleRVar stdUniform)) (mkStdGen seed)
>     where
>       seed = 0

> randomWeightMatrix :: Int -> Int -> [[Double]]
> randomWeightMatrix numInputs numOutputs = y
>   where
>     y = chunksOf numInputs weights
>     weights = map (/ 100.0) $ uniforms (numOutputs * numInputs)

> w1, w2 :: [[Double]]
> w1  = randomWeightMatrix 2 2
> w2  = randomWeightMatrix 3 2

> initNet2 :: BackpropNet Double
> initNet2 = buildBackpropNet lRate [w1, w2] logitAF
> 
> labels :: V.Vector Int
> labels = V.map (round . fst) createSample

> inputs :: V.Vector [Double]
> inputs = V.map (return . snd) createSample

Instead of hand-crafting gradient descent, let us use the library function as it performs better and is easier to implement.

> estimates :: (Floating a, Ord a, Show a) =>
>              V.Vector Int ->
>              V.Vector [a] ->
>              BackpropNet a ->
>              [BackpropNet a]
> estimates y x = gradientDescent $
>                 \theta -> totalCostNN 2 y (V.map (map auto) x) theta

Now we can examine the weights of our fitted neural net and apply it to some test data.

> test2 :: IO ()
> test2 = do
> 
>   let fs = estimates labels inputs initNet2
>   mapM_ putStrLn $ map (take 60) $
>                    map show $ extractWeights $
>                    head $ drop 1000 fs
>   putStrLn $ show $ evalNeuralNet (head $ drop 1000 fs) [0.1]
>   putStrLn $ show $ evalNeuralNet (head $ drop 1000 fs) [0.9]

ghci> test2
  [[3.3809809537916933,-6.778365921046131],[-5.157492699008754
  [[1.2771246165025043,5.294090869351353,-8.264801192310706],[
  [0.997782987249909,2.216698813392053e-3]
  [1.4853346509852003e-3,0.9985148392767443]

Example III

Let’s try a more sophisticated example and create a population of 4 groups which we measure with 2 variables.

> c, d :: Double
> c          = 15
> d          = 8
> sample2, sample3 :: [Double]
> sample2 = betas nSamples c d
> sample3 = betas nSamples d c

> mixSamples3 :: Num t => [[a]] -> [(t, a)]
> mixSamples3 xss = concat $ transpose $
>                   zipWith (\n xs -> map (n,) xs)
>                           (map fromIntegral [0..])
>                           xss
> sample02, sample03, sample12, sample13 :: [(Double, Double)]
> sample02 = [(x, y) | x <- sample0, y <- sample2]
> sample03 = [(x, y) | x <- sample0, y <- sample3]
> sample12 = [(x, y) | x <- sample1, y <- sample2]
> sample13 = [(x, y) | x <- sample1, y <- sample3]

> createSample3 :: forall t. Num t => V.Vector (t, (Double, Double))
> createSample3 = V.fromList $ take 512 $ mixSamples3 [ sample02
>                                                     , sample03
>                                                     , sample12
>                                                     , sample13
>                                                     ]

Rather annoyingly picking random weights seemed to give a local but not global minimum. This may be a feature of having more nodes in the hidden layer than in the input layer. By fitting a neural net with no hidden layers to the data and using the outputs as inputs to fit another neural net with no hidden layers, we can get a starting point from which we can converge to the global minimum.

> w31, w32 :: [[Double]]
> w31 = [[-1.795626449637491,1.0687662199549477,0.6780994566671094],
>        [-0.8953174631646047,1.536931540024011,-1.7631220370122578],
>        [-0.4762453998497917,-2.005243268058972,1.2945899127545906],
>        [0.43019763097582875,-1.5711869072989957,-1.187180183656747]]
> w32 = [[-0.65116209142284,0.4837310591797774,-0.17870333721054968,
>         -0.6692619856605464,-1.062292154441557],
>        [-0.7521274440366631,-1.2071835415415136e-2,1.0078929981538551,
>         -1.3144243587577473,-0.5102027925579049],
>        [-0.7545728756863981,-0.4830112128458844,-1.2901624541811962,
>         1.0487049495446408,9.746209726152217e-3],
>        [-0.8576212271328413,-0.9035219951783956,-0.4034500456652809,
>         0.10091187689838758,0.781835908789879]]
> 
> testNet3 :: BackpropNet Double
> testNet3 = buildBackpropNet lRate [w31, w32] logitAF

> labels3 :: V.Vector Int
> labels3 = V.map (round . fst) createSample3
> inputs3 :: V.Vector [Double]
> inputs3 = V.map ((\(x, y) -> [x, y]) . snd) createSample3

Now we use the library gradientDescent function to generate neural nets which ever better fit the data.

> estimates3 :: (Floating a, Ord a, Show a) =>
>               V.Vector Int ->
>               V.Vector [a] ->
>               BackpropNet a ->
>               [BackpropNet a]
> estimates3 y x = gradientDescent $
>                  \theta -> totalCostNN 4 y (V.map (map auto) x) theta

Finally we can fit a neural net and check that it correctly classifies some data.

> test3 :: IO ()
> test3 = do
>   let fs = drop 100 $ estimates3 labels3 inputs3 testNet3
>   mapM_ putStrLn $ map (take 60) $ map show $ extractWeights $ head fs
>   putStrLn $ take 60 $ show $ evalNeuralNet (head fs) [0.1, 0.1]
>   putStrLn $ take 60 $ show $ evalNeuralNet (head fs) [0.1, 0.9]
>   putStrLn $ take 60 $ show $ evalNeuralNet (head fs) [0.9, 0.1]
>   putStrLn $ take 60 $ show $ evalNeuralNet (head fs) [0.9, 0.9]

ghci> test3
  [[-2.295896239599931,2.705409060274802,2.1377566388724047],[
  [[-0.6169787627963551,2.5369568963968256,-0.3515306366626614
  [2.638026636449198e-2,9.091308688841797e-2,0.373349222824566
  [0.13674565454319784,1.128123133092104e-2,0.8525700090804755
  [0.30731134024095474,0.8197492648500939,1.3704140162804749e-
  [0.6773814649389487,0.22533958204471505,0.1957913744022863,4

References

Bishop, Christopher M. 2006. Pattern Recognition and Machine Learning (Information Science and Statistics). Secaucus, NJ, USA: Springer-Verlag New York, Inc.

Rojas, R. 1996. Neural networks: a systematic introduction. Springer-Verlag New York Incorporated. http://books.google.co.uk/books?id=txsjjYzFJS4C.

Tom Schrijvers: Ghent FP meeting on June 26

noreply@blogger.com (Tom Schrijvers) — Fri, 31 May 2013 09:36:41 +0000

The "Functional Programming Group Ghent" (GhentFPG) [1] is a friendly group for
all people interested in functional programming, with a tendency towards Haskell.
It is organised as part of Zeus WPI [2].

We are pleased to announce that we will hold a next meeting on Wednesday, 26th
of June, starting at 19h00! There will be three talks.

The main presentation, by Adam Bergmark from Silk [3] is about Fay [4]:

Fay is a proper subset of Haskell that compiles to JavaScript. There is a compiler with the same name written in Haskell. Web browsers only speak JavaScript but more and more people find that they want to compile to JavaScript instead.
Why do we want to compile Haskell to JavaScript, and what advantages does Fay have compared to other compilers?
What are the challenges in compiling Haskell and supporting a language ecosystem, and how do we do it?
What can Fay currently do, and what is planned for the future?
This will be a broad overview about Fay for prospective users, followed by an in-depth look at interesting parts of the compiler internals.

Additionally, there will be two short talks by two students who did an Msc. Thesis
about functional programming languages:

Genetic Algorithms in Haskell
Matthias Delbar
Automatic Detection of Recursion PatternsJasper Van der Jeugt

The meeting will take place in the Jozef Plateauzaal at the following address,

Faculteit IngenieurswetenschappenUniversiteit GentPlateaustraat 229000 Gent

As mentioned above, we aim to start at 19:00. After the meeting we can go
for drinks in a nearby pub (this latter part is, of course, completely optional)

We hope to see you all there!

Regards,
On behalf of the GhentFPG organising committee.

[1]: http://groups.google.com/<wbr></wbr>group/ghent-fpg
[2]: http://zeus.ugent.be/
[3]: http://www.silkapp.com/
[4]: http://www.fay-lang.org/

wren ng thornton: ANN: prelude-safeenum

Thu, 30 May 2013 00:05:57 +0000

prelude-safeenum 0.1.0

The prelude-safeenum package offers a safe alternative to the Prelude's Enum class in order to render it safe. While we're at it, we also generalize the notion of enumeration to support types which can only be enumerated in one direction.

Description

The prelude-safeenum package offers an alternative to the notion of enumeration provided by the Prelude. For now it is just a package, but the eventual goal is to be incorporated into haskell prime. Some salient characteristics of the new type-class hierarchy are:

Removes partial functions: The Haskell Language Report section 6.3.4 defines pred, succ, fromEnum, and toEnum to be partial functions when the type is Bounded, but this is unacceptable. The new classes remove this problem by correcting the type signatures for these functions.
Generalizes the notion of enumeration: Rather than requiring that the type is linearly enumerable, we distinguish between forward enumeration (which allows for multiple predecessors) and backward enumeration (which allows for multiple successors).
Adds new functions: enumDownFrom, enumDownFromTo: One of the big problems with the partiality of pred is that there is no safe way to enumerate downwards since in the border case enumFromThen x (pred x) will throw an error rather than evaluating to [x] as desired. These new functions remove this problem.
Removes the requirement...: ...that the enumeration order coincides with the Ord ordering (if one exists). Though, of course, it's advisable to keep them in sync if possible, for your sanity.
Ensures that the notion of enumeration is well-defined: This much-needed rigor clarifies the meaning of enumeration. In addition, it rules out instances for Float and Double which are highly problematic and often confuse newcomers to Haskell. Unfortunately, this rigor does render the instance for Ratio problematic. However, Ratio instances can be provided so long as the base type is enumerable (and Integral, naturally); but they must be done in an obscure order that does not coincide with Ord.
The obscure order required for well-defined enumeration of Ratio is provided.

Edward Z. Yang: The AST Typing Problem

Tue, 28 May 2013 11:25:03 +0000

This Lambda the Ultimate post (dated 2010) describes a rather universal problem faced by compiler writers: how does one go about adding “extra information” (e.g. types) to an AST? (The post itself divides the problem into three components: adding the information to the data types, using the information to inform the construction of the node, and using the information to inform the destruction of a node—but I’m really only interested in the question of how you define your data type, not do things to it.) In this post, I want to sum up ways of solving the problem which were described in this post, and also take a look at what some real world compilers do. The running example lambda calculus looks like the following:

data Exp = Num Int
         | Bool Bool
         | Var Var
         | If Exp Exp Exp
         | Lambda Var Exp
         | App Exp Exp
data Type = TyInt | TyBool | TyArrow Type Type

Separate IR where nodes are decorated with types

The low-tech solution: if you need a new version of the IR with more information, just define a new IR type where each node can also carry the information. A trick to make these definitions more concise is to make a mutually recursive data structure. [1]

type TExp = (TExp', Type)
data TExp' = TNum Int
           | TBool Bool
           | TVar Var
           | TIf TExp TExp TExp
           | TLambda Var TExp
           | TApp TExp TExp

Despite (or perhaps because of) it’s simplicity, this approach is extremely popular among many compilers, especially in the ML community. A few examples include OCaml (parsetree/typedtree), MLton (AST/CoreML) and Ikarus Scheme. Part of the reason for this is that the transition from frontend language to typed language also comes with some other changes, and when a new AST is defined those changes can be combined in too.

Nullable field

The unprincipled solution: use one AST, but have an optional field in which you can slot in the information. [2]

type TExp = (TExp', Maybe Type)
data TExp' = TNum Int
           | TBool Bool
           | TVar Var
           | TIf TExp TExp TExp
           | TLambda Var TExp
           | TApp TExp TExp

Presented without further comment.

Explicit typing

While closely related to the separate IR solution, an explicitly typed IR takes the approach of not decorating each node with a type, but arranging that the type of any given node can be quickly computed using only local information. [3]

data TExp = TNum Int
          | TBool Bool
          | TVar Var
          | TIf TExp TExp TExp
          | TLambda Var Type TExp
          | TApp TExp TExp

Here, the difference between TExp and Exp is very slight; the TLambda is annotated with an explicit type for the binder. As far as type-checking is concerned, this makes a world of difference: we no longer need to look outside a lambda to figure out what the binder could be.

Forcing your IR to be explicitly typed is often a good idea for metatheoretic reasons, as complicated type systems often don’t have decidable inference algorithms. Both GHC’s core IR, Ur/Web's core and Coq are explicitly typed in this way.

Two-level types

By deferring when you tie the knot of a recursive data-structure, you can arrange for the base functor to do double-duty for the untyped and typed representations. [4]

data ExpF a = Num Int
            | Bool Bool
            | Var Var
            | If a a a
            | Lambda Var a
            | App a a
newtype Exp = Exp (ExpF Exp)
newtype TExp = TExp (ExpF TExp, Type)

The Coq kernel uses this to define its expression type, although it doesn’t use it to define an untyped variant.

(Lazy) Attribute grammars

I don’t claim to understand this approach too well, but essentially it is a programming model distinct from usual algebraic data types which associates attributes over nodes of a tree. In some sense, it can be thought as a memoized function from AST nodes to the attributes. Many compilers do utlize maps, but only for top-level declarations. [5]

Closing remarks

There were a few things that I did not mention here which came up in the discussion. One participant suggested using polymorphic variants to define the data type; this doesn’t help much with adding extra information but allows for different ways of writing traversal functions. Indeed, traversal is one of the big concerns, and the mention of generic programming also is targeted at this problem.

As for my preference? It’s hard to say. I’ve worked with compilers mostly written in the “define a new IR style”, and while the initial outlay of defining two data structures is quite annoying, it is mostly a fixed cost. What’s yours?

Also, a question. Is there a presentation of the conventional set of annotations needed to get explicitly typed System F?

Lee Pike: Book Review: Automate This

Tue, 28 May 2013 01:00:03 +0000

A family member gave me a copy of Automate This by Christopher Steiner as a gift a few months ago. The subtitle of the book is “How algorithms came to rule our world.” The book is a non-technical, fast, and easy read. I did read a few interesting stories, such as NASA’s use of personality categorization algorithms in the 70s to predict which potential astronauts would work well together, or a math professor’s algorithmic dissection of Beatles songs. The book particularly emphasizes algorithmic trading on Wall Street. The somewhat non sequitur conclusion is that we need more science, engineering, and math graduates.

The main point of the book is that algorithms are pervasive and will become more so. Toward this point, I think the author could have cast an even wider net, mentioning that algorithms are implemented in everything from elevator controllers to autopilots. There is a cursory pre-computing history of algorithms at the beginning of the book that is (tenuously) tied to a Wall Street trading.

Rather than focus on algorithms broadly, the focus is patchy, hitting on machine learning, high-speed trading, and game theory. Some mention of algorithms as might be taught in a “Analysis of Algorithms” course, covering basic topics like time-space complexity and decidability, would help prevent the general public from having a narrow-minded interpretation of algorithms. Computer scientists invent, analyze, and implement algorithms every day, but much of that work is perhaps not sexy enough for a popular science book.

Incidentally, for the topics Steiner does cover, an excellent companion treating similar topics, but with a different focus, is Nate Silver’s (of 538 fame) book, The Signal and the Noise.

Philip Wadler: How to reject a paper

noreply@blogger.com (Philip Wadler) — Mon, 27 May 2013 09:24:19 +0000

How NOT to review a paper: the tools and techniques of the adversarial reviewer and How to reject any scientific manuscript. Photo from Academic Negativity.

Ken T Takusagawa: [ryvpijhs] Code reflection at compile time

noreply@blogger.com (Ken) — Mon, 27 May 2013 08:29:01 +0000

Consider a Haskell extension providing this function:

compileTimeAnalyze :: (Code -> IO ()) -> a -> a

"compileTypeAnalyze f e" passes to user-defined function "f" the parse tree (and any other useful information such as types and symbol table) of the expression "e" and evaluates "f" at compile time. At run time, it simply evaluates "e".

The likely use is to emit warnings or errors if there is something domain-specifically wrong with the code that the compiler might not detect.

Inspired by debugging 2D graphics code. We often want the number of references to some X coordinate be the same as the number to the corresponding Y coordinate, or else there is likely a typo where we typed X instead of Y or vice versa.

We probably also want the user to be able to define

compileTimeAnalyzeModule :: Code -> IO()

which gets the entire contents of the module for static analysis. What about static analysis across many modules?

Template Haskell can probably do most of this.

Neil Mitchell: Three types of build-system dependency

noreply@blogger.com (Neil Mitchell) — Sun, 26 May 2013 19:58:13 +0000

Summary: There are three types of dependencies you might want to express in a build system, all of which are supported by Shake.

A build system, at its heart, is a system which runs commands in an order satisfying user-specified dependencies. But what kind of dependencies can be expressed? This post describes three different types of dependency, only one of which is available in Make, but all of which are available in both Shake and Ninja.

Feature 1: Static dependencies (available in every build system)

The most basic form of dependency is a static dependency, where a rule produces an output from some inputs:

-- In Make --
result.tar : file1 file2
    tar -cf result.tar file1 file2

-- In Shake --
"result.tar" *> \out -> do
    let deps = ["file1","file2"]
    need deps
    cmd "tar -cf" [out] deps

This rule says that the file result.tar depends on the inputs file1 and file2, and provides a command to build result.tar. Whenever file1 or file2 change, the command will be run, and result.tar will be built.

Static dependencies occur in almost every build rule, and are supported by all build tools, including Make and Shake.

Feature 2: Dynamic dependencies (available in Shake, Ninja and Redo)

A more advanced dependency is where the list of dependencies itself depends on the results of previous dependencies. Imagine we want to build result.tar from the list of files stored in list.txt. The dependencies of result.tar cannot be specified statically, but depend on the contents of list.txt. In Shake we can write:

"result.tar" *> \out -> do
    need ["list.txt"]
    contents <- readFileLines "list.txt"
    need contents
    cmd "tar -cf" [out] contents

This rule describes how to build result.tar. We depend on (need) the file list.txt. We read each line from list.txt into the variable contents - being a list of the files that should go into result.tar. Next, we depend on all the files in contents, and finally call the tar program. If either list.txt changes, or any of the files listed by list.txt change, then result.tar will be rebuilt.

This feature is necessary in almost every build system, yet is shockingly lacking from most build tools - I am only aware of it being available in Shake, Ninja and Redo. As a common example, in Make you might write:

result.o : result.c result_header1.h result_header2.h
    gcc ...

The file result.o depends on both the C source file result.c and all headers that file includes. But listing the headers both in result.c with #include directives, and in the Makefile, is a brittle form of duplication. A better approach is for the build system to run gcc -M result.c and extract the includes from there. In Shake we can write:

"result.o" *> \out -> do
    let src = "result.c"
    Stdout stdout <- cmd "gcc -MM" [src]
    need $ src : drop 2 (words stdout)
    cmd "gcc -o" [out] "-c" [src]

My experience is that about a quarter of rules require some kind of additional dependency based on previous dependencies. While you can hack round some of the issues in Make, and people have become disturbingly adept at doing so, the result often only approximates the dependencies - building either too much or too little.

Feature 3: Multiple outputs from one rule (available in Shake and Ninja)

The final feature is producing multiple outputs from one command, and is used far more rarely (perhaps one or two rules in a complex build system) - but when needed, is essential. Some programs, such as GHC, can produce two outputs with one command - compiling Foo.hs produces both Foo.o and Foo.hi. As a first approximation, the .o file depends on the entire contents of the source file, while the .hi file depends only on the type signatures. A single ghc invocation needs to do all the work to produce both, but often the .hi file will be left unchanged. In Shake we can write:

["Foo.hi","Foo.o"] *>> \_ -> do
    need ["Foo.hs"]
    cmd "gcc -c Foo.hs"

While it is often possible to construct a series of dependencies to approximate a single rule producing multiple outputs, it only works in some cases, and is brittle. The only build systems I am aware of which support multiple outputs are Shake and Ninja.

Essential features

My standard advice when people ask about writing a build system is "don't". If some existing build system (e.g. ghc --make or Cabal) is capable of building your project, use that instead. Custom build systems are necessary for many complex projects, but many projects are not complex. If you have decided your project is complex, you should use a build tool that can express complex dependencies, both for writing the initial system and to provide the flexibility to make the inevitable changes required.

Looking only at dependency features, I would consider it unwise to start a complex build system using a tool other than Shake or Ninja, or perhaps Redo (if you accept the absence of multiple outputs from one rule).

Weak dependency specification in build tools, particularly Make, has left its mark on many programs. I recently talked to some OCaml hackers complaining that their tools were not "Make friendly" because they produced multiple output files. I wonder what lengths other tools have gone to in order to cope with weak dependency specification...

Tom Moertel: Lazy merging in Python using streams

Sun, 26 May 2013 00:00:00 +0000

Posted on May 26, 2013

Tags: programming, python, iterators, streams, SICP, functional programming

Recently while solving a programming puzzle in Python, I needed to merge a series of N iterators, each yielding values in sorted order, into a single iterator over the sorted values. The trick is that, when asked for a value from the merged series, to determine which iterator should contribute that value, you must extract all N iterators’ next values. And then, of course, you can emit only one. So what do you do with the remaining N – 1 values you’ve extracted?

Rather than think about that question too hard, I just converted the iterators into an equivalent form in which the next value was always exposed and hence available for making decisions before extraction. This form is basically the stream of SICP fame.

The idea is to convert each Python iterator into either None (representing an empty stream) or a pair containing the iterator’s next value and the iterator itself:

def iterator_to_stream(iterator):
    """Convert an iterator into a stream (None if the iterator is empty)."""
    try:
        return iterator.next(), iterator
    except StopIteration:
        return None

Then to extract values from the stream, you just apply stream_next to it, and it will hand you back the next value and the updated state of the stream:

def stream_next(stream):
    """Get (next_value, next_stream) from a stream."""
    val, iterator = stream
    return val, iterator_to_stream(iterator)

Since streams expose their next value, they can be ordered by that value. And for my task that was the property that made all the difference:

import heapq

def merge(iterators):
    """Make a lazy sorted iterator that merges lazy sorted iterators."""
    streams = map(iterator_to_stream, map(iter, iterators))
    heapq.heapify(streams)
    while streams:
        stream = heapq.heappop(streams)
        if stream is not None:
            val, stream = stream_next(stream)
            heapq.heappush(streams, stream)
            yield val

An example use:

>>> xs = merge([xrange(3), xrange(2, 9), xrange(5)])
>>> xs
<generator object merge at 0x7fea07c9d320>

>>> list(xs)
[0, 0, 1, 1, 2, 2, 2, 3, 3, 4, 4, 5, 6, 7, 8]

Joachim Breitner: My first CTAN package: Typesetting Continued Equalities

mail@joachim-breitner.de (nomeata) — Sat, 25 May 2013 14:05:10 +0000

I recently had a TeX itch to scratch: I am working on a paper that has several multi-line continued equalities¹ where, depending on the size of the expressions and the explanations of each step, I chose among a few layouts. But implementing the layout together with the actual code was inefficient, as switching the layout involved changing every line.

So I came up with the package conteq which allows you to typeset continued equations in a simple declarative manner, e.g.

\begin{conteq}
  e^{\pi\cdot i} \\
= -1               & Euler's formula \\
< 0                & this is an inequality \\ 
< \sqrt 3 \\
= \int e^{-x^2} dx & this is due to Gauss.
\end{conteq}

and allows you to select the layout via an parameter to the environment, or globally, or either. Also, the styling of the explanations (italics? wrapped in {...}?) can be configured simply by redefining a macro. For more details and an overview of the various styles, check out the package documentation.

If this sounds useful to you, fetch the conteq package from CTAN. But beware: It uses quite current features of the expl3 package, so you need at least the version from 2012/07/02 (TeXLive 2013 is good). You can file bug reports at the GitHub mirror of my git repository.

I’d like to thank Bruno Le Floch and Joseph Wright, who made me aware of expl3 on various TeX Exchange questions.

¹ I haven’t heard of this term before, but supposedly it is the right translation for the German word „Gleichungskette“.

language-puppet: Embedded ruby interpreter and performance increase

Fri, 24 May 2013 17:38:00 +0000

Despite hitting a nasty (but obvious) bug involving Ruby’s GC, it seems that the feature is now stable.

I have been using a script for a while that computes catalogs for 30 nodes, taking into account exported resources, and runs some tests on the results. This script used to run in around 50 seconds. On my puppet master, the combined catalog generation time for those hosts is around 10 minutes¹.

Language-puppet was about ten times faster than the original implementation, but was wasting a significant amount of time spawning Ruby processes, rendering gobs of data (the list of all known variables and their values), and feeding them to said process, for each template evaluation. On the Ruby side, the data was interpreted (with eval), the templates were loaded and interpolated, and the response spit back to the Haskell executable. For this reason I wrote a minimalist template parser that is capable of interpolating the simplest ones while staring in Haskell land.

Now the Ruby process is embedded, and variable resolution happens only when needed, by providing a callback Haskell function to the Ruby runtime.

The whole script now runs in less than 10 seconds (six if you omit the tunnelled accesses to PuppetDB). This is now acceptable to run it before almost all commits, which was the goal. It will help making sure nothing got (too) broken, especially with regards to exported resources.

The software is now stable enough, and I will probably prepare a new binary release soon, along with a Debian-style repository.

¹ This is not a fair comparison however. My script queries the PuppetDB for facts using a SSH tunnel, whereas the puppet master is local. On the other hand the puppet master does stuff my script doesn’t, such as updating facts and reporting data into PuppetDB (in all fairness my script updates a local PuppetDB-like database). I do not believe this accounts for an important fraction of those ten minutes, but might be wrong. Also, the puppet master has a faster CPU, and does not run unit tests on the catalogs.

Paul Johnson: Elevator pitch for Haskell short enough for an elevator ride

noreply@blogger.com (Paul Johnson) — Fri, 24 May 2013 15:08:27 +0000

Greg Hale has written an "elevator pitch" for Haskell. While it is certainly a good piece of advocacy, it is quite long, and therefore not an elevator pitch. The idea of an elevator pitch is something you can deliver in the 30 seconds or so that you find yourself sharing an elevator with a potential investor.

I've been looking for an effective Haskell elevator pitch for some years now, but the only thing I was able to come up with was just that you can deliver software better, faster and cheaper because you need fewer lines of code. This just sounds like hype.

However I think I've now got something better. Here it is:

Conventional languages make the programmer construct both a control flow and a data flow for the program. There is no way to check they are consistent, and anytime they are inconsistent you get a bug. In Haskell the programmer just specifies the data flow: the control flow is up to the compiler. That simplifies the program, cutting down the work and completely preventing a big class of errors.

Twan van Laarhoven: The complete correctness of sorting

Thu, 23 May 2013 12:43:33 +0000

A while ago I set out to prove the correctness of merge sort in Agda. Of course this has been done before. But most proofs you find are far from complete. All they prove is a lemma such as

is-sorted : ∀ (xs : List A) → IsSortedList (sort xs)

Maybe even restricted to lists of natural numbers. While it is nice that a sort function indeed produces a sorted output, that is only half of the story. Consider this function:

cheat-sort : List A → List A
cheat-sort _ = []

Clearly the empty list is sorted. So we are done. What is missing is the second half of correctness of sorting: that the output is a permutation of the input. You want something like:

sort : (xs : List A) → Sorted' A
record Sorted' (xs : List A) : Set where
  field
    ys       : List A
    isSorted : IsSorted ys
    isPerm   : IsPermutation ys xs

While I was at it, I decided to add the third half of correctness: a bound on the runtime or computational complexity. In the end I was able to define:

insertion-sort : ∀ xs → (Sorted xs) in-time (length xs * length xs)
selection-sort : ∀ xs → (Sorted xs) in-time (length xs * length xs)
merge-sort : ∀ xs → (Sorted xs) in-time (length xs * ⌈log₂ length xs ⌉)

This was not as easy as I would have hoped. In this post I will not bore you with all the details, I'll just go over some of the highlights. The full code is on github.

What it means to be sorted

There are roughly two ways to define sorted lists that I know of:

Parametrize the sorted list by a lower bound on the values it contains. For a cons cell the head should be smaller than the lower bound, and the tail should be larger than the head. This requires the type to have a smallest element, but you can adjoin -∞ with a new datatype.
Parametrize the sorted list by a list of all values in it. For a cons cell require that the head is smaller than all the values in the tail.

Since I already need to parametrize by all values in the list to show that the sorted list contains a permutation of them, I went with the second approach:

-- A proof that x is less than all values in xs
data _≤*_ (x : A) : List A → Set where
  []  : x ≤* []
  _∷_ : ∀ {y ys} → (x ≤ y) → x ≤* ys → x ≤* (y ∷ ys)

-- Proof that a list is sorted
data IsSorted : List A → Set where
  []  : IsSorted []
  _∷_ : ∀ {x xs} → x ≤* xs → IsSorted xs → IsSorted (x ∷ xs)

What it means to be a permutation

To show that one list is a permutation of another I again used two data types. Suppose that we know that xs is a permutation of ys. Then when is x ∷ xs a permutation of some list xys? Well, we can permute xs to ys, and insert x anywhere. I used ◂ to denote this insertion,

-- x ◂ xs ≡ xys means that xys is equal to xs with x inserted somewhere
data _◂_≡_ (x : A) : List A → List A → Set a where
  here  : ∀ {xs}           → x ◂ xs ≡ (x ∷ xs)
  there : ∀ {y} {xs} {xys} → (p : x ◂ xs ≡ xys) → x ◂ (y ∷ xs) ≡ (y ∷ xys)

-- Proof that a list is a permutation of another one
data IsPermutation : List A → List A → Set a where
  []  : IsPermutation [] []
  _∷_ : ∀ {x xs ys xys}
      → (p : x ◂ ys ≡ xys)
      → (ps : IsPermutation xs ys)
      → IsPermutation (x ∷ xs) xys

Now the Sorted data type has three components: the sorted list, a proof that it is sorted, and a proof that it is a permutation of the input. These parts are either all [], or they are all _∷_. It turns out to be much nicer to combine the parts together,

-- Sorted permutations of a list
data Sorted : List A → Set  where
  []   : Sorted []
  cons : ∀ x {xs xxs}
       → (p : x ◂ xs ≡ xxs) -- inserting x somewhere into xs gives xxs
       → (least : x ≤* xs)  -- x is the smallest element of the list
       → (rest : Sorted xs) -- and we have also sorted xs
       → Sorted xxs

Of course Sorted and Sorted' are equivalent.

As an aside, these are all the ingredients necessary for proving

sorted-unique : ∀ {xs} → (ys zs : Sorted xs)
              → sorted-to-List ys ≡ sorted-to-List zs

A monad for keeping track of the runtime

To be able to reason about the runtime, as measured in the number of comparisons performed, I decided to use a monad. The type is simply

data _in-time_ (A : Set) (n : ℕ) : Set a where
  box : A → C A n

the constructor box is private, and it can only be accessed through the standard monad operations,

return : ∀ {A n} → A → A in-time n

_>>=_ : ∀ {A B} {m n} → A in-time n → (A → B in-time m) → B in-time (n + m)

Then the sorting functions will be parametrized by a function that for some partial order decides between x ≤ y and y ≤ x in one step, using the monad we defined above:

module Sorting
    {A : Set} {l} {_≤_ : Rel A l}
    (isPartialOrder : IsPartialOrder _≡_ _≤_) 
    (_≤?_ : (x y : A) → (x ≤ y ⊎ y ≤ x) in-time 1)
  where ...

Note that I specify that _≤_ is a partial order, because the Agda standard library definition of a total order actually comes with a function

total : ∀ x y → (x ≤ y) ⊎ (y ≤ x)

which would defeat the whole prupose of _≤?_. In fact, the standard TotalOrders are decidable up to base equality, and if the base equality is propositional equality, then they are decidable. I.e.

total-decidable : ∀ {a r} {A : Set a} → (_≤_ : Rel A r)
                → IsTotalOrder _≡_ _≤_
                → IsDecTotalOrder _≡_ _≤_

See the source for the proof of this side theorem. It relies on a trick to show that total x y can only be different from total y x if x ≢ y. Which holds for propositional equality, but not in general.

Logarithms

To be able to complete the specification of merge sort, we still need to add some missing functions on natural numbers. In particular, we need a logarithm. This logarithm turns out to be surprisingly tricky to define in Agda. Why? Because the usual definition uses non-structural recursion. In haskell you would write

-- @log n@ calculates ⌊log₂ (n+1)⌋
log 0 = 0
log n = 1 + log (n `div` 2)

But Agda is not able to see that n `div` 2 (or in agda notation, ⌊ n /2⌋) is smaller than n. There are two approaches to circumvent this problem:

Use a different algorithm: Convert n to a binary representation, and count the number of digits.
Use well-founded recursion, manually supplying a proof that ⌊ n /2⌋ < n.

I went with the second option, because I will also be using the same shape of recursion inside merge sort itself. The standard way to use well-founded recursion is through the function <-rec, which works a bit like fix in haskell, except that you need to pass in a proof that the argument is smaller. The code would look like this:

log = <-rec log'
  where
  log′ self 0 = 0
  log′ self (suc n) = 1 + self ⌊ suc n /2⌋ ({-proof ommitted-})

But this leads to a problem as soon as you want to prove a property of logarithms. For example, you would think that log (suc n) ≡ 1 + (log ⌊ suc n /2⌋). But that is not definitionally true, since one <-rec is not like another. I found that the well-founded recursion library was in general a pain to work with, especially because it uses so many type synonyms. My solution was to use the slightly lower level accessibility relation. A value of type Acc _<′_ n allows you to do recursion with any m <′ n. Now I can use actual recursion:

log-acc : ∀ n → Acc _<′_ n → ℕ
log-acc 0 _ = 0
log-acc (suc n) (acc more) = 1 + log-acc ⌊ suc n /2⌋ (more _ {-proof ommitted-})

And use the well-foundedness of ℕ to get an Acc for any number:

log : ℕ → ℕ
log n = log-acc n (<-well-founded n)

⌈log₂_⌉ : ℕ → ℕ
⌈log₂ n ⌉ = log (pred n)

There is still a snag when proving properties of log or log-acc, namely that you need to prove that (more n ...) ≡ <-well-founded n. But the accessibility relation doesn't actually matter for the computation, so I decided to just postulate

postulate acc-irrelevance : ∀ {n : ℕ} → {a b : Acc _<′_ n} → a ≡ b
 -- this also follows from function extensionality

If anyone knows a better way to prove properties of functions defined with well-founded recursion, I am open to suggestions.

Vectors versus lists

While working on the proofs I had to choose: Do I use fixed length Vecs or variable length Lists? Both have their pros and cons.

On the one hand, the sorting functions with vectors look a bit nicer, because we can use n instead of length xs:

merge-sort : ∀ {n} (xs : Vec A n) → Sorted xs in-time (n * ⌈log₂ n ⌉)

Additionally, with lists we can only do recursion on the input list, with vectors we can do recursion on the length of the list. The former works fine for insertion sort, where in each step you do something with the head element of the list; but it fails for selection and merge sort.

On the other hand, with vectors you sometimes can't even state the property that one vector is equal to another. For the term xs ≡ ys ++ zs to be well-typed, xs must have the type Vec A (m + n).

I went back and forth a couple of times between vectors and lists. In the end I settled for using vectors only when needed, and specifying properties in terms of lists. For example the split function for merge sort has the type

splitHalf : ∀ {n} → (xs : Vec A n)
          → ∃₂ \(ys : Vec A ⌈ n /2⌉) (zs : Vec A ⌊ n /2⌋)
               → toList ys ++ toList zs ≡ toList xs

So instead of using Vec._++_, I use List._++_. In this style 'select' from selection sort looks like

select : ∀ {n} (xs : Vec A (suc n))
       → (∃₂ \y ys → (y ◂ toList ys ≡ toList xs) × (y ≤* toList ys)) in-time n

I.e. given a vector xs with n+1 elements, return a vector ys with n elements, such that inserting y into it gives us back xs. And this item y should be the smallest one.

Extension: expected runtime

An extension of this post would be to look at randomized sorting algorithms. In particular, quick sort with a randomly chosen pivot has expected runtime O(n * log n). At first I thought that all that would be needed is a function

expected : ∀ {P}
         → (ns : List ℕ)             -- A list of numbers
         → All (\n → P in-time n) ns -- for each n we have P in-time n
         → P in-time ⌈mean ns ⌉      -- then expect time is mean of ns

But that is not quite right, since if we actually knew the runtimes ns we could just pick the fastest one. With the randomized quicksort you will end up in a situation where you have two or more computations to choose from, and you know that some are faster than the others, but you don't yet know which one. That sounds a bit classical. A second idea is to return the runtimes at a later time, something like

expected : ∀ {P} {long-time}
         → (xs : List (\ex n P in-time n) in-time long-time)
         → P in-time ⌈mean map proj1 xs ⌉

But this is not quite right either, since after long-time computing P (i.e. a sorting) can be done in 0 time. Rather, we need to decouple the proof about the runtime from the computation. This is not possible with the _in-time_ monad. We would need to get rid of the runtime from the type, and store it as a value instead.

I have tried redoing the proofs in this post with the monad

data Timed (A : Set) : Set a where
  _in-time_ : A → ℕ → Timed A
runtime : Timed A → ℕ

But I didn't succeed; I ended up with the baffling error message

runtime (big-lambda-term (unbox (x ≤? u)))
!=
runtime (big-lambda-term (unbox (x ≤? u)))

Another extension: lower bound on runtime

So far I have proved that you can sort a list in time n * log n. It would also be interesting to look at the well known lower bound on the runtime of sorting, and prove a theorem such as

can't-sort-in-linear-time : ¬ ∃ \k → ∀ xs → Sorted xs in-time k * length xs

unfortunately this statement is not actually true for all types. For finite sets you actually can sort in linear time with counting sort. It also fails if we happen to have some decidable total order for that type lying around. But it might be possible to prove

can't-sort-in-linear-time
  : (no-fast-compare : ∀ x y → (x ≤ y ⊎ y ≤ x) in-time 0 → x ≡ y)
  → ¬ ∃ \k → ∀ xs → Sorted xs in-time k * length xs

But you have to be really careful with a term like no-fast-compare, because inside the runtime monad we do have values of type (x ≤ y ⊎ y ≤ x). And so you can derive ∀ x y → x ≡ y in-time 1, and therefore also ⊥ in-time 1 for non trivial types. Which certainly looks wrong to me.

I don't know a way around this problem, but it might be related to the same issue as expected runtime. I.e. the problem is that all information about the runtime is bundled together with the return value. The lower bound proof essentially asks to sort a 'random' list, and by a counting argument shows that at least a certain number of comparisons are needed to be able to produce all outputs.

wren ng thornton: Upcoming talk

Mon, 20 May 2013 22:11:45 +0000

Next month I'll be giving a talk at the NLCS workshop, on the chiastic lambda-calculi I first presented at NASSLLI 2010 (slides[1]). After working out some of the metatheory for one of my quals, I gave more recent talks at our local PL Wonks and CLingDing seminars (slides). The NASSLLI talk was more about the linguistic motivations and the general idea, whereas the PLWonks/CLingDing talks were more about the formal properties of the calculus itself. For NLCS I hope to combine these threads a bit better— which has always been the challenge with this work.

NLCS is collocated with this year's LICS (and MFPS and CSF). I'll also be around for LICS itself, and in town for MFPS though probably not attending. So if you're around, feel free to stop by and chat.

[1] N.B., the NASSLLI syntax is a bit different than the newer version: square brackets were used instead of angle brackets (the latter were chosen because they typeset better in general); juxtaposition was just juxtaposition rather than being made explicit; and the left- vs right-chiastic distinction was called chi vs ksi (however, it turns out that ksi already has an important meaning in type theory).

comments

language-puppet: Incoming: Ruby bridge

Mon, 20 May 2013 09:35:00 +0000

I am working on a quick and dirty Ruby bridge library, that I hope will yield a huge performance gain with template interpolation in the language-puppet library. Right now, it is capable of:

Initializing a Ruby interpreter from libruby
Calling Ruby methods and functions
Registering methods or functions that will be called from Ruby code
Converting data between the two Worlds (right now the most complex instance is the JSON one, which means that many complex Ruby types can’t be converted, but it is more than enough for passing data)
Embedding native Haskell values that can be passed around in Ruby to the Haskell-provided external functions (I will use this for passing the Puppet catalog state around)

There are still a few things to do before releasing it :

Making compilation a bit less dependant on the system. This will probably require quite a few flags in the cabal definition …
Hunting for memory leaks. I am not sure how to do this with the GHC Runtime in the middle, and I do hope that ruby_finalize frees everything that is managed by the Ruby runtime. After all, restarting processes seems to be the only working garbage collection method for Ruby daemons …
Writing stubs for the Puppet library methods that might be needed by templates. I would like to be able to support custom types and functions directly written in Ruby instead of Lua, but this will probably turn into a nightmare …
Cleaning things up !

Here is a quick code preview :

{-# LANGUAGE OverloadedStrings, OverloadedStrings #-}
module Main where

import Foreign.Ruby.Bindings
import Data.Aeson
import Data.Attoparsec.Number

-- this is an external function that will be executed from the Ruby interpreter
-- the first parameter to the function is probably some reference to some top object
-- my knowledge of ruby is close to nonexistent, so I can't say for sure ...
extfunc :: RValue -> RValue -> IO RValue
extfunc _ v = do
    -- deserialize the Ruby value into some JSON Value
    onv <- fromRuby v :: IO (Maybe Value)
    -- and display it
    print onv
    -- now let's create a JSON object containing all kind of data types
    let nv = object [ ("bigint" , Number (I 16518656116889898998656112323135664684684))
                    , ("int", Number (I 12))
                    , ("double", Number (D 0.123))
                    , ("null", "Null")
                    , ("string", String "string")
                    , ("true", Bool True)
                    , ("false", Bool False)
                    , ("array", toJSON ([1,2,3,4,5] :: [Int]))
                    , ("object", object [ ("k", String "v") ] )
                    ]
    -- turn it into Ruby values, and return this
    toRuby nv

-- this is the function that is called if everything was loaded properly
nextThings :: IO ()
nextThings = do
    -- turn the extfunc function into something that can be called by the Ruby interpreter
    myfunc <- mkRegistered2 extfunc
    -- and bind it to the global 'hsfunction' function
    rb_define_global_function "hsfunction" myfunc 1
    -- now call a method in the Ruby interpreter
    o <- safeMethodCall "MyClass" "testfunc" []
    case o of
        Right v -> (fromRuby v :: IO (Maybe Value)) >>= print
        Left r -> putStrLn r

main :: IO ()
main = do
    -- initialize stuff
    ruby_init
    ruby_init_loadpath
    -- and load "test.rb"
    s <- rb_load_protect "test.rb" 0
    if s == 0
        then nextThings
        else showError >>= putStrLn

</figure>

And here is the ruby program, that calls our external function :

class MyClass
    def self.testfunc
        hsfunction( [16588,
                    "qsqsd",
                    true,
                    { 'a' => 'b' },
                    :symbol,
                    0.432,
                    5611561561186918918918618789115616591891198189123165165889 ]
                ).each do |k,v|
            puts "#{k} => #{v} [#{v.class}]"
        end
        12
    end
end

</figure>

And the output, showing that data is properly converted from either sides :

Just (Array (fromList [Number 16588,String "qsqsd",Bool True,Object fromList [("a",String "b")],String "symbol",Number 0.432,Number 5611561561186918918918618789115616591891198189123165165889]))
bigint => 16518656116889898998656112323135664684684 [Bignum]
int => 12 [Fixnum]
double => 0.123 [Float]
array => 12345 [Array]
true => true [TrueClass]
null => Null [String]
string => string [String]
object => kv [Hash]
false => false [FalseClass]
Just (Number 12)

</figure>

EDIT: added link to the code.

Kevin Reid (kpreid): Game idea: reverse bullet hell

kpreid@switchb.org (Kevin Reid (kpreid)) — Mon, 20 May 2013 04:56:02 +0000

I have come to realize that I have more ideas for programs than I'll ever have time to write. (This means they're not actually all that significant, on average — see all that's been said on ‘ideas vs. execution’.) But maybe I have the time to scribble a blog post about them, and that's stuff to blog about, if nothing else.

So, a video game idea I had today: reverse bullet-hell shooter.

A regular bullet-hell shooter is a game where you move in a 2D space dodging an immense number of mostly dumb instant-death projectiles launched in mostly predefined patterns, and trying to shoot back with dinkier, but better aimed, weapons. Instead, here you design the bullet pattern so as to trap and kill AI enemies doing the dodging.

The roles seem a bit similar to tower defense, but the space of strategies would be considerably more, ah, bumpy, since you're not doing a little bit of damage at a time and how it plays out depends strongly on the AI's choices.

That's probably the downfall of this idea: either the outcome is basically butterfly effect random due to enemy AI decisions and you mostly lose, or there are trivial ways to design undodgeable bullet patterns and you mostly win. I don't immediately see how to make the space of inputs and outcomes “smooth” enough.

Edward Z. Yang: Anatomy of an MVar operation

Mon, 20 May 2013 00:00:37 +0000

Adam Belay (of Dune fame) was recently wondering why Haskell’s MVars are so slow. “Slow?” I thought, “aren’t Haskell’s MVars supposed to be really fast?” So I did some digging around how MVars worked, to see if I could explain.

Let’s consider the operation of the function takeMVar in Control.Concurrent.MVar. This function is very simple, it unpacks MVar to get the underlying MVar# primitive value, and then calls the primop takeMVar#:

takeMVar :: MVar a -> IO a
takeMVar (MVar mvar#) = IO $ \ s# -> takeMVar# mvar# s#

Primops result in the invocation of stg_takeMVarzh in PrimOps.cmm, which is where the magic happens. For simplicity, we consider only the multithreaded case.

The first step is to lock the closure:

("ptr" info) = ccall lockClosure(mvar "ptr");

Objects on the GHC heap have an info table header which indicates what kind of object they are, by pointing to the relevant info table for the object. These headers are also used for synchronization: since they are word-sized, they can be atomically swapped for other values. lockClosure is in fact a spin-lock on the info table header:

EXTERN_INLINE StgInfoTable *lockClosure(StgClosure *p)
{
    StgWord info;
    do {
        nat i = 0;
        do {
            info = xchg((P_)(void *)&p->header.info, (W_)&stg_WHITEHOLE_info);
            if (info != (W_)&stg_WHITEHOLE_info) return (StgInfoTable *)info;
        } while (++i < SPIN_COUNT);
        yieldThread();
    } while (1);
}

lockClosure is used for some other objects, namely thread state objects (stg_TSO_info, via lockTSO) and thread messages i.e. exceptions (stg_MSG_THROWTO_info, stg_MSG_NULL_info).

The next step is to apply a GC write barrier on the MVar:

if (info == stg_MVAR_CLEAN_info) {
    ccall dirty_MVAR(BaseReg "ptr", mvar "ptr");
}

As I’ve written before, as the MVar is a mutable object, it can be mutated to point to objects in generation 0; thus, when a mutation happens, it has to be added to the root set via the mutable list. Since mutable is per capability, this boils down into a bunch of pointer modifications, and does not require any synchronizations. Note that we will need to add the MVar to the mutable list, even if we end up blocking on it, because the MVar is a retainer of the thread (TSO) which is blocked on it! (However, I suspect in some cases we can get away with not doing this.)

Next, we case split depending on whether or not the MVar is full or empty. If the MVar is empty, we need to block the thread until the MVar is full:

/* If the MVar is empty, put ourselves on its blocking queue,
 * and wait until we're woken up.
 */
if (StgMVar_value(mvar) == stg_END_TSO_QUEUE_closure) {

    // We want to put the heap check down here in the slow path,
    // but be careful to unlock the closure before returning to
    // the RTS if the check fails.
    ALLOC_PRIM_WITH_CUSTOM_FAILURE
        (SIZEOF_StgMVarTSOQueue,
         unlockClosure(mvar, stg_MVAR_DIRTY_info);
         GC_PRIM_P(stg_takeMVarzh, mvar));

    q = Hp - SIZEOF_StgMVarTSOQueue + WDS(1);

    SET_HDR(q, stg_MVAR_TSO_QUEUE_info, CCS_SYSTEM);
    StgMVarTSOQueue_link(q) = END_TSO_QUEUE;
    StgMVarTSOQueue_tso(q)  = CurrentTSO;

    if (StgMVar_head(mvar) == stg_END_TSO_QUEUE_closure) {
        StgMVar_head(mvar) = q;
    } else {
        StgMVarTSOQueue_link(StgMVar_tail(mvar)) = q;
        ccall recordClosureMutated(MyCapability() "ptr",
                                         StgMVar_tail(mvar));
    }
    StgTSO__link(CurrentTSO)       = q;
    StgTSO_block_info(CurrentTSO)  = mvar;
    StgTSO_why_blocked(CurrentTSO) = BlockedOnMVar::I16;
    StgMVar_tail(mvar)             = q;

    jump stg_block_takemvar(mvar);
}

A useful thing to know when decoding C-- primop code is that StgTSO_block_info(...) and its kin are how we spell field access on objects. C-- doesn’t know anything about C struct layout, and so these “functions” are actually macros generated by utils/deriveConstants. Blocking a thread consists of three steps:

We have to add the thread to the blocked queue attached to the MVar (that’s why blocking on an MVar mutates the MVar!) This involves performing a heap allocation for the linked list node as well as mutating the tail of the old linked list.
We have to mark the thread as blocked (the StgTSO modifications).
We need to setup a stack frame for the thread so that when the thread wakes up, it performs the correct action (the invocation to stg_block_takemvar). This invocation is also responsible for unlocking the closure. While the machinery here is pretty intricate, it’s not really in scope for this blog post.

If the MVar is full, then we can go ahead and take the value from the MVar.

/* we got the value... */
val = StgMVar_value(mvar);

But that’s not all. If there are other blocked putMVars on the MVar (remember, when a thread attempts to put an MVar that is already full, it blocks until the MVar empties out), then we should immediately unblock one of these threads so that the MVar can always be left in a full state:

    q = StgMVar_head(mvar);
loop:
    if (q == stg_END_TSO_QUEUE_closure) {
        /* No further putMVars, MVar is now empty */
        StgMVar_value(mvar) = stg_END_TSO_QUEUE_closure;
        unlockClosure(mvar, stg_MVAR_DIRTY_info);
        return (val);
    }
    if (StgHeader_info(q) == stg_IND_info ||
        StgHeader_info(q) == stg_MSG_NULL_info) {
        q = StgInd_indirectee(q);
        goto loop;
    }

There is one interesting thing about the code that checks for blocked threads, and that is the check for indirectees (stg_IND_info). Under what circumstances would a queue object be stubbed out with an indirection? As it turns out, this occurs when we delete an item from the linked list. This is quite nice, because on a singly-linked list, we don't have an easy way to delete items unless we also have a pointer to the previous item. With this scheme, we just overwrite out the current item with an indirection, to be cleaned up next GC. (This, by the way, is why we can't just chain up the TSOs directly, without the extra linked list nodes. [1])

When we find some other threads, we immediately run them, so that the MVar never becomes empty:

// There are putMVar(s) waiting... wake up the first thread on the queue

tso = StgMVarTSOQueue_tso(q);
StgMVar_head(mvar) = StgMVarTSOQueue_link(q);
if (StgMVar_head(mvar) == stg_END_TSO_QUEUE_closure) {
    StgMVar_tail(mvar) = stg_END_TSO_QUEUE_closure;
}

ASSERT(StgTSO_why_blocked(tso) == BlockedOnMVar::I16); // note: I16 means this is a 16-bit integer
ASSERT(StgTSO_block_info(tso) == mvar);

// actually perform the putMVar for the thread that we just woke up
W_ stack;
stack = StgTSO_stackobj(tso);
PerformPut(stack, StgMVar_value(mvar));

There is one detail here: PerformPut doesn’t actually run the thread, it just looks at the thread’s stack to figure out what it was going to put. Once the MVar is put, we then wake up the thread, so it can go on its merry way:

// indicate that the MVar operation has now completed.
StgTSO__link(tso) = stg_END_TSO_QUEUE_closure;

// no need to mark the TSO dirty, we have only written END_TSO_QUEUE.

ccall tryWakeupThread(MyCapability() "ptr", tso);

unlockClosure(mvar, stg_MVAR_DIRTY_info);
return (val);

To sum up, when you takeMVar, you pay the costs of:

one spinlock,
on order of several dozen memory operations (write barriers, queue twiddling), and
when the MVar is empty, a (small) heap allocation and stack write.

Adam and I puzzled about this a bit, and then realized the reason why the number of cycles was so large: our numbers are for roundtrips, and even with such lightweight synchronization (and lack of syscalls), you still have to go through the scheduler when all is said and done, and that blows up the number of cycles.

[1] It wasn’t always this way, see:

commit f4692220c7cbdadaa633f50eb2b30b59edb30183
Author: Simon Marlow <marlowsd@gmail.com>
Date:   Thu Apr 1 09:16:05 2010 +0000

    Change the representation of the MVar blocked queue

    The list of threads blocked on an MVar is now represented as a list of
    separately allocated objects rather than being linked through the TSOs
    themselves.  This lets us remove a TSO from the list in O(1) time
    rather than O(n) time, by marking the list object.  Removing this
    linear component fixes some pathalogical performance cases where many
    threads were blocked on an MVar and became unreachable simultaneously
    (nofib/smp/threads007), or when sending an asynchronous exception to a
    TSO in a long list of thread blocked on an MVar.

    MVar performance has actually improved by a few percent as a result of
    this change, slightly to my surprise.

    This is the final cleanup in the sequence, which let me remove the old
    way of waking up threads (unblockOne(), MSG_WAKEUP) in favour of the
    new way (tryWakeupThread and MSG_TRY_WAKEUP, which is idempotent).  It
    is now the case that only the Capability that owns a TSO may modify
    its state (well, almost), and this simplifies various things.  More of
    the RTS is based on message-passing between Capabilities now.

Alessandro Vermeulen: Why you should switch to declarative programming

Sun, 19 May 2013 10:52:00 +0000

We are reaching limits of what is feasible with imperative languages and we should move to declarative languages.

When applications written in imperative languages grow, the code becomes convoluted. Why? Imperatively programmed applications contain statements such as if X do Y else do Z. As Y and Z contain invisible side-effects the correctness of the program relies on some implicit invariant. This invariant has to be maintained by the programmer or else the code will break. Thus each time a new feature is added to an application or a bug is fixed the code for the application gets more complex as keeping the invariant intact becomes harder. After a while the code becomes spaghetti-code and bugs are introduced as the programmer fails to maintain the invariant. This is going to happen despite the best intentions of the programmer to keep things clean. Why is this?

An imperative language is a type of language that tells the computer what to do and in which order. However, most, if not all, applications are nothing but a translation of some business domain into a computer program. In order to get the imperative code the programmer has to translate the business model to a set of imperative instructions, the business logic. The imperative instructions bear little resemblance to the original description of the business model. When the business model changes the imperative counterpart could change entirely but what happens is that programmers make incremental updates to the code. This is done because either they do not see that a more drastic change is necessary or because they are under pressure to deliver results. Over time this leads to bugs and unmaintainable code. Summarized, bugs are introduced because there is a manual translation step between the business model and the program code.

Imagine a system for calculating whether a person should receive a certain allowance. To receive the allowance a person has to meet several criteria such as age > 18 and income < 2400. We can denote this in the following way:

def receives_allowance?(age, income)
  age > 18 && income < 2400
end

</figure></notextile>

There are several remarks to be made for this code. Adding a criteria such as marital status would involve adding a parameter to the function and changing the boolean expression. We could already avoid having to change parameters when we had chosen a parameter of type Person that contains the information about a person. But what if we would introduce time as an aspect in our criteria? We need to change the function again. And what if the age criteria changed? If the programmer erroneously codes something like age > 18 && age < 18 into the condition we would only find the bug during testing, if we are lucky. Additionally when our criteria become more complex we would like to extract criteria to their own functions. In short, it is easy to make mistakes this way.

A solution to this is to avoid the translation process by using a declarative language. A declarative language is a language that describes what is to be computed but not how it should be computed.¹ In essence: it omits control-flow. By encoding and thereby recording the business model into a set of declarative statements it becomes easier to spot irregularities in the business logic as the business logic reads more like the description of the business model and all invariants are visible. In this manner the programmer no longer tells the computer how to perform a computation but rather what the computation should be. This makes it easier to maintain

However, we take it even to an higher level entirely. By just using the declarative language, such as Haskell or Prolog, you are still using a general-purpose language and are thus lacking domain specific checks. It would be advantageous to devise a Domain Specific Language (DSL) instead. This would be a language specifically geared towards your business domain and can be done easily in a language such as Haskell. Creating a DSL has a great benefit: Because the business domain is written down in code the responsibility of translating the business domain into a program shifts from the programmer to the interpreter of the DSL. This has two benefits: the translation is consolidated in one single point (the interpreter) and can be verified or even proven to be correct. It could be checked that no contradicting statements are present. In this sense we can compare the validation to a spell-checker or JSLint but for our specific domain. Secondly the programmer cannot make mistakes in the translation of the business logic to imperative code.

A simple DSL embedding the idea of the allowance could look like the text in the examples below. The interpreter / compiler is able to inspect the separate rules and check whether they would cause a tautology or contradiction.

We will illustrate this with some examples. Consider the following text below, it is easy to read and it is clear what it means. Each line is a condition that has to hold, so we could read an “AND” at eacht line end. (Whether Income is monthly or annually or weekly is not taken into account here but you get the picture.)

A person is an adult when his Age is GREATER THAN OR EQUAL TO 18
A person is allegeable for an allowance IF
  he is an adult
A person is allegeable for an allowance IF
  his Income is NOT GREATER THAN €2400

</figure></notextile>

When we would add a rule as shown below, we could get a warning or error from the interpreter telling us that we have two different conditions on a person’s age.

A person is an adult when his Age is GREATER THAN OR EQUAL TO 18
A person is allegeable for an allowance IF
  he is an adult
A person is allegeable for an allowance IF
  his Income is NOT GREATER THAN €2400
A person is allegeable for an allowance IF
  his Age is GREATER THAN 21

</figure></notextile>

And when we would add a rule as this it could warn us that no-one will ever get an allowance.

A person is an adult when his Age is GREATER THAN OR EQUAL TO 18
A person is allegeable for an allowance IF
  he is an adult
A person is allegeable for an allowance IF
  his Income is NOT GREATER THAN €2400
A person is allegeable for an allowance IF
  his Age is LESS THAN 12

</figure></notextile>

Not only would the interpreter be able to spot these kinds of errors but it would also be easier for the writer of these rules to spot whether there is a mistake. The astute reader will have noticed than we have not included any control flow into our language making it a declarative language.

Because the business-logic is now represented by the DSL it can be written by domain experts instead of the programmers of the application itself. The compiler can provide feedback when something is wrong in the DSL and there is less chance for errors in the implementation of the business logic. Additionally this frees the programmes for implementing better translations of the DSL or other projects saving time and other resources.

To summarise 4 reasons why you should switch to declarative languages:

Direct translation of the business model into business logic
Better readability of the business logic
Better scalability for the program in terms of functionality
Less bugs

And 3 reasons why you should use DSLs to boot:

Free up programmers to do important stuff
Let the domain-experts handle the business logic and have it machine-checked!
It is just awesome

Lloyd, J.W., Practical Advantages of Declarative Programming ↩

language-puppet: language-puppet v0.4.0

Thu, 16 May 2013 18:32:00 +0000

I just released the latest language-puppet version. For the full list of changes, please take a look at the changelog. Here are the highlights.

PuppetDB code reworked

The PuppetDB code and API has been completely overhauled. It is now more generic : the resource collection and puppet query functions now work the same. Additionally, a PuppetDB stub has been created for testing use.

Better diagnostic facilities

As the main use of this library is to test stuff, the following features were added:

Several error messages have been reworked so that they are more informative.
A dumpvariables built-in function has been added. It just prints all known variables (and facts) to stdout, and can be quite handy.
The “scope stack” description is stored with the resources. This turned out to be extremely useful when debugging resource names colisions or to find out where some resource is defined.

Here is an example, let’s say you do not remember which package installs the collectd package. Just run this :

» puppetresources . default.domain 'Package[collectd]'

package {
    "collectd": #"./modules/collectd/manifests/base.pp" (line 4, column 9) ["::","site::baseconfig","collectd","collectd::client","collectd::base"]
        ensure          => "installed",
        require         => [Class["collectd"], Class["collectd::base"], Class["collectd::client"], Class["site::baseconfig"]];
}

</figure>

You now know exactly where the package resource is declared, and the list of “scopes” that have been traversed in order to do so. Note that this information is displayed when resources names collide.

Easier to setup

This library doesn’t depend from a newish bytestring anymore, and should build with the package provided with a GHC compiler of the 7.6.x serie.

This is not yet done, but I will certainly soon publish a debian-style repository of the compiled puppetresources binary. I am interested in suggestions for an automated building system.

Better testing

The testing API seems sufficient to write pretty strong tests, but would still benefit from a few more helper functions. The testing “daemon” has been reworked to use the new PuppetDB stub. It makes it possible to test complex interactions between hosts using the exported resource or PuppetDB query features.

Work in progress

I will probably lensify the code until I get a descent understanding of it.

I do not intend to work on Hiera emulation just yet, as I am probably the only user of this library for now and I do not use this feature.

One area of improvement would be to embed the ruby interpreter in the library. I am not sure how to do this, but as there are quite a few projects of lightweight interpreters sprouting from the earth, it might be possible in the near future. The only problem would be figuring out how to build a large C project with cabal.

Some other considerations

I recently ported the code from random.c to Haskell (here). This has been quite tedious, and is quite hard to read. This is an almost naive port of the code found in the Ruby interpreter, without the useless loop variables. For some reason, there are many loops like this :

i=1; j=0;
k = (N>key_length ? N : key_length);
for (; k; k--) {
    mt->state[i] = (mt->state[i] ^ ((mt->state[i-1] ^ (mt->state[i-1] >> 30)) * 1664525U))
        + init_key[j] + j; /* non linear */
    mt->state[i] &= 0xffffffffU; /* for WORDSIZE > 32 machines */
    i++; j++;
    if (i>=N) { mt->state[0] = mt->state[N-1]; i=1; }
    if (j>=key_length) j=0;
}

</figure>

As you can see, the value of k is never used in the loop. I am not sure why the author didn’t go for something like :

for(i=1;i<k;i++) {

</figure>

Anyway, the Haskell code is pretty bad, and will certainly only work for 64-bit builds. I am not sure how I should have written it. I suppose staying in the ST monad would have lead to nicer code, and I am open to suggestions.

Philip Wadler: From Session Types to Data Types: RA posts and PhD studentships

noreply@blogger.com (Philip Wadler) — Thu, 16 May 2013 13:39:54 +0000

I've posted this elsewhere, but neglected to blog before now.

We are recruiting for research associate positions in design and implementation of programming languages, and also may have PhD studentships available this year and next. The posts are on the project "From Data Types to Session Types: A Basis for Concurrency and Distribution" which is a programme grant funded by EPSRC for five years from 20 May 2013, joint with Simon Gay at the University of Glasgow and Nobuko Yoshida at Imperial College London.

The RA post at Edinburgh for an initial period of 24 months, with possibility of extension, and is on the UE07 scale (£30,424 - £36,298). Deadline for applications for the RA post is Monday 20 May 2013, anyone interested in a PhD studentship should apply as soon as possible. Glasgow and Imperial are also recruiting.

Please contact me if you are interested in either the RA post or a PhD studentship. Further description of the Edinburgh RA post is below.

Project Description

Just as data types describe the structure of data, session types describe the structure of communication between concurrent and distributed processes. Our project has particular emphasis on putting theory into practice, by embedding session types in a range of programming languages and applying them to realistic case studies. The research programme is joint between the University of Edinburgh, University of Glasgow, and Imperial College London, and includes collaboration with Amazon, Cognizant, Red Hat, VMware, and the Ocean Observatories Initiative.

Principal Duties

The successful candidate will join a team responsible for extending the functional web programming language Links with session types to support concurrency and distribution. We will test our techniques by providing a library to access Amazon Web Services (AWS) cloud computing infrastructure, and perform empirical experiments to assess how our language design impacts the performance of programmers.

You should possess a PhD in a relevant area, or be nearing completion of same, or have comparable experience. You should have a track-record of publication, or other evidence of ability to undertake research and communicate well. You should have a strong background in programming languages, including type systems, and strong programming and software engineering skills.

It is desirable for candidates to also have one or more of the following: a combination of theoretical and practical skills; experience of web programming or cloud programming; knowledge of the theory or practice of concurrent and distributed systems; knowledge of linear logic; or training in empirical measurement of programming tasks.

We seek applicants at an international level of excellence. The Laboratory for Foundations of Computer Science is internationally renowned, the School of Informatics at Edinburgh is among the strongest in the world, and Edinburgh is known as a cultural centre providing a high quality of life.

Further details of the RA post, including how to apply, are here.

Bryn Keller: Hot Towel SPA Is a Great Starter

Thu, 16 May 2013 10:30:00 +0000

A few months ago, John Papa released a Visual Studio template called Hot Towel SPA, which Scott Hanselman kindly pointed out to me. SPA, as all the hip kids will tell you, stands for Single Page Application. That is, the kind of application that you start by visiting a web page, and you stay on that same page for as long as you use the application. As opposed to most web applications, where you skip from page to page as you interact with the site.

People have been doing this for a long time, of course, but the Hot Towel SPA starter really is a nice introduction to the style. In a SPA, you really need to think of the browser as “the client,” a standalone entity that communicates with your server via (web) API calls. Once you get used to it, it’s really rather refreshing, and it allows you to take advantage of all the computing power on the client machine in a way that can be quite liberating.

Hot Towel uses a JavaScript application framework called Durandal to structure the client side code. It divides the world up into services (JavaScript modules, basically), views, and view models. All of this is just for the JavaScript side of things, remember – you may also have views and view models and so on on the server side, but that’s a different thing – you’ll interact with those via AJAX calls, usually using JSON to encode the data.

Hot Towel uses HTML for the views and lets Knockout do the view composition and data binding, which makes it a good source of examples for learning Knockout as well.

The JavaScript code is nicely modular, in the style of require.js. If you’ve not seen this style, it’s worth checking out. Basically, you declare all your dependencies for your JavaScript module, and the framework asynchronously loads them as necessary, as passes them to your module. It’s great documentation, great for structuring the code so you don’t get circular dependencies, and makes for easier unit testing too, since can easily supply alternative (mock) implementations of your module’s dependencies.

On the server, the MVC code is well organized as well, and it’s straightforward to plug in your new Web API controllers and start coding.

I’ve been playing with this starter for a while, working on a proof of concept for a new series of articles on my blog. I found Hot Towel to be a great starting point, and it opened my eyes to some interesting new techniques on the client side. Give Hot Towel a try for your next project, it’ll be fun.

Philip Wadler: Aleph Cloud

noreply@blogger.com (Philip Wadler) — Thu, 16 May 2013 09:36:14 +0000

Aleph Cloud is looking to hire Haskell programmers.

Planet Haskell

Functional Jobs: Senior software developer/Functional programmer at Vector Fabrics (Full-time)

Responsibilities

Profile

Education

About Vector Fabrics

FP Complete: FP Haskell Center Beta Sign-Up

Beta sign-up Blog

FP Haskell Center’s key features and benefits are:

FP Complete: Interim Web Site

Interim Site blog

Douglas M. Auclair (geophf): Thoughts on Kleisli Arrows in Java (WIP)

hyperq: Trading: a hacker approach?

Manuel M T Chakravarty: Data Flow Fusion with Series Expressions in Haskell

Paul Potts: Objective-Dylan, or Perhaps Subjective-C?

The Gentoo Haskell Team: Call for help: wiki.gentoo.org documentation

Jan Stolarek: Getting friendly with STG

Daniil Frumin: Building GHCJS

1 Intro

2 Initial installation

2.1 Using the prebuilt version

2.2 Compiling from source

2.3 Communicating with the VM

3 Compiling other packages

4 Outro

Daniil Frumin: Summer of Code

Tom Moertel: Tricks of the trade: Recursion to Iteration, Part 4: The Trampoline

Execution frames and the stack

Eliminating stack build-up

The trampoline

Example: factorial

Why use the trampoline?

Mike Izbicki: HLearn’s code is shorter and clearer than Weka’s

The HLearn code

The Weka code

Conclusion

Philip Wadler: Iain Banks

Theory Lunch (Institute of Cybernetics, Tallinn): When does an endofunctor derive from an adjunction?

Theory Lunch (Institute of Cybernetics, Tallinn): An initial solution to the monad problem, and then some more

Ken T Takusagawa: [sjhltpdo] Unscope symbol

wren ng thornton: Dungeon World: Assassin class

Paul Potts: Objective-C, Day 5

FP Complete: FP Complete Launches Haskell in Real World Competition

FP Complete Launches Haskell in Real World Competition with $1,000 Cash Prize Each Month

Simon Michael: Blog tinkering, hledger.org

Blog tinkering, hledger.org

A better ghci fix

Blog tinkering

hledger.org

Paul Potts: Objective-C, Day 4

Tom Schrijvers: PPDP '13: Last Call for Papers

Simon Michael: GHCI fix

GHCI fix

Paul Potts: Objective-C, Day 3

Tim Docker: Data analysis with Monoids

Monoids

Foldable

Composition

More complex calculations

The Aggregation type class

Higher order aggregation functions

Disk-based data

Conclusion

Simon Michael: Bugfix, planning, autoweb

Bugfix, planning, autoweb

JP Moresmau: Eclipse Hate and Haskell IDEs

Simon Michael: Chart fix

Chart fix

Paul Potts: Objective-C, Day 2

Luke Palmer: The Plan

Mike Izbicki: HLearn cross-validates >400x faster than Weka

Simon Michael: Earth Nap

Earth Nap

Tom Moertel: Tricks of the trade: Recursion to Iteration, Part 3: Recursive Data Structures

The challenge

Eliminating the first recursive call

Eliminating the second recursive call

FP Complete: Haskell from C: Where are the for Loops?

Where are the for loops?

Computing Norms in C

Where are the `for` loops?