A very long time ago I had an interesting if flawed idea. The idea was to (optionally) replace instances of expression constructs with equations defining or referring to components of conventional compound structures. The special variables defined or used I called “pronouns” but now I prefer “parameters”.
I fixed the flaw … and in so doing discovered a promising new equational programming paradigm.
Recently my friend Michael Levy had a very clever idea. It was to publish cheaper versions of well-known books, the idea being that they would be basically the same but slightly altered to avoid copyright problems. For example, Ray Bradbury’s Fahrenheit 451 would be re-published as Fahrenheit 350 – who needs the extra heat?
In the same way F Scott Fitzgerald’s The Great Gatsby would reappear as The Mediocre Gatsby but it had a much cheaper price. And finally, Virginia Woolf’s To the Lighthouse could be obtained under the title To the Outhouse at a bargain price.
As I’ve explained I invented and implemented a small functional language (PYFL) to test out some ideas. In particular one idea is the (oxymoronic) functional while loop.
A while loop? In a functional language? “Impossible!” you snort.
Well you’re wrong. Let me explain.
As I’ve already explained I’ve invented and implemented an experimental functional language – PYFL (PYthon based Functional Language) – to try out some ideas.
For example, PYFL has a full set of Variable Binding Operators (VBOs) that use a linear ASCII form to represent the constructs like sigma notation of conventional mathematics. For example the following adds up the first 20 squares
sumfor i in range(1,20) all i*i endand the following tests if N is prime
forall d in range(2,sqrt(N)): N mod d != 0 endIn the previous post I described the PYFL approach to input, which is (arguably) purely functional, drastically simpler, and trivial to implement, as compared to Haskell’s cumbersome IO monad. (Btw I have nothing against monads or Haskell in general, I’m just not impressed by the Haskell IO monad).
This time I’ll talk about PYFL’s output scheme. It ticks two of the three boxes just mentioned – it’s simple and easily implemented. Here’s some output (yep, Pascal’s triangle). I’ll show the program at the end of this post.
As I already explained, I’ve invented and implemented a simple functional language (PYFL) with a few interesting twists. Including a promising but simple approach to input.
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
[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.
[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.
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.
[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?]
