PYFL: Putting the fun back in functional programming

Haskell has been both a blessing and a curse for Functional Programming (FP.)

A blessing because it has allowed many thousands to experience FP firsthand – by writing functional programs. They’ve discovered that it’s not that hard, that you can do useful projects in FP, and (thanks to the cleverness stuffed into Glasgow Haskell) the performance is comparable if not superior to that of conventional languages like Java,

So what is the curse? The curse is that Haskell dominates FP like Tyrannosaurus Rex dominated the dinosaurs (and like LISP used to dominate FP). Any discussion of FP becomes a discussion of Haskell, any proposed feature becomes a proposal for extending Haskell, and any problems with Haskell seem inherent in FP. The FP ecosystem seriously lacks diversity

I’m going to fix that with PYFL (PYthon based Functional Language), designed and implemented from scratch, as you watch

Dimensionality Analysis: multiple dimensions

[This reports on research carried out in collaboration with my PhD student Monem Shennat and former student Omar Alaqeeli]

In a previous post I showed how to find identify variables in a classic (time only) Lucid program that are constant – do not change with time. This information proves vital for output and for efficient caching.

Now we consider two dimensional Lucid, like pyLucid, in which variables can vary in two independent dimensions, time t and space s.

Dimensionality – time sensitivity

[This reports on research carried out in collaboration with my PhD student Monem Shennat and former student Omar Alaqeeli]

Dimensionality is a big issue with multidimensional Lucid – it means figuring out which dimensions are relevant to calculating the values of a variable.

It’s a simple idea but surprisingly subtle. In this post I’ll deal with the simplest case, time sensistivity in ‘classical’ time-only Lucid. Calculating which variables need to know the value of the time parameter t.

Intensional Logic in Context – from philosophy to technology

The most pervasive fallacy of philosophic thinking goes back to neglect of context.

Jon Dewey

What exactly is “intensional programming?” The easy answer is, programming in a language based on intensional logic. But that raises another, more important question, namely what is intensional logic? Logicians have been working on the answer for more than 2500 years.

The short answer is, logic in which the truth-value and more generally the meaning of an expression depends on an implicit context. Let me attempt to give you the full answer.

Just Funnin’ – the infamous “Cowboys” section of the Lucid book

[This is the infamous section of the book Lucid the Dataflow Programming Language where I make fun of everyone working on imperative languages. It was very popular but many people hated it even though no individual is named. In a companion post I cite it as an example of a Career Limiting Move. It didn’t quite kill my career though it didn’t help. I’m sure there were a number of meetings I wasn’t invited to and program committees I was left out of because of it. Hmmm … was that really a bad thing?]

Plotting Propositions – the Mathematics of Persuasion

Sha la la la la la la
La la la
La di da
La di da

Van Morrison (Brown Eyed Girl)

A lot of people have to write as part of their jobs – grant proposals, progress reports, specifications. And there are endless verbal communications – defending code, disputes over features, justifying organization changes, technology explanations, and so on forever.

Well, the good news is that Hollywood can help!

Wadge Degrees – the origin story

I’m fortunate enough to have a mathematical concept named after me. And not just Wadge degrees. There’s also the Wadge hierarchy, Wadge reducibility, and the Wadge game. In fact I’ve seen people say they’re interested in “Wadge theory”. A whole theory!

I’ve posted about this before but that was mainly technical and for most readers not all that accessible. It left out the human element, the passion, the drama, the thrill of victory etc. So here’s the real story.

I/O Without Side Effects – the Lucid experience

Everything you know is wrong.
— Firesign Theater

Everybody knows that output requires side effects.

The logic is irrefutable. When an output occurs, something changes. There is a number on the terminal screen, there is a sheet of printed paper in the printer output tray. Surely the source program, even in a functional language, must contain a command, like print(N), which can’t be understood as a pure data-to-data function.

Everybody is  wrong. Wrongity wrong wrong wrong.

Well, maybe not that wrong. But the experience of Lucid shows that nontrivial I/O  does not necessarily require side effects. Instead, we can have programs that output (pure) data which we send to an output device. This is how Lucid (e.g. pyLucid) works. Not an IO monad in sight.

Lucid – the origin story

I’ve already written about the origins of Lucid but that was a dry, technical, and incomplete post. Here is the real story, with all the drama and passion, the thrill of victory, the agony of defeat.

Well maybe not quite. But with the human element.

Monads and Intensionality – Lucid is not an aberration

Be ahead of your time, but only a little.
– Mason Cooley

Do you understand  monads? I don’t, so I  thought I’d explain them to you.

Then, once you’ve got it, I’ll re-explain Lucid. No Haskell, optional category theory, gluten free.