> a non-Haskell (or Haskell-like) PFP I'd immediately suggest that Haskell is not a particularly pure language itself and that you should take a look at { Coq,

> a non-Haskell (or Haskell-like) PFP I'd immediately suggest that Haskell is not a particularly pure language itself and that you should take a look at { Coq, Agda, Idris } for far more ideas about where PFP ought to go. You can also without too much difficulty imagine an ML derivative which is pure although they are historically not. In all of these cases, laziness is not a component and many of your "the lack of clear execution models, the lack of clear thread context (which is, of course, related), the difficulty in analyzing computational complexity, in debugging and profiling, and implementing many simple algorithms" arise directly out of laziness alone. > you're not advocating 100% abstraction explicitness To put my cards on the table, I am advocating for this at least some of the time. :) I'm interested in the idea of there being a tension between favoring abstractions versus favoring algorithms. I understand what you mean anecdotally, but am not sure how to put it into a larger context. In many ways I feel abstractions create the hard outlines of algorithms and are indispensable. This I feel is true even if you're, e.g., programming in Forth. The difference is not a lack of (even higher order) abstraction but merely a difference in how much of that structure you communicate to your compiler. Re: continuations. Having access to arbitrary continuation semantics is equally powerful to "all monads combined together" in the sense of "what you can encode" but, then, simultaneously, ultimately weak in the sense of "how many ways can you interpret this". On the other hand, restricting the set of continuations you have access to is completely identical to choosing a monad. You say that the only difference is whether you pick things at the top or bottom. I say that this isn't even an actual difference. In both cases you're effecting the exact same thing and, if you like, it would be fair to analyze it as a monad. Monads aren't equivalent to Haskell's encoding of them. Even Haskell admits many encodings. The first-order ones like we're used to seeing are popular because they're simple to understand and implement not because they're the only way. As an example, here's the monad stack at the core of Attoparsec, a fast parser combinator library Parser a ~ forall r. (Buffer, Int, Bool) -> ((Buffer, Int, Bool) -> ([String], String) -> Result r) -> ((Buffer, Int, Bool) -> a -> Result r) -> Result r Result r ~ Fail Text [String] String | Partial (Text -> Result r) | Done Text r This is unapologetically a monad based on 2 continuations, the second and third arguments to the Parser function are the success and failure continuations which respond to being threaded on a continuation state and either `([String], String)`, a bundle of error messages or `a` a final result. Re: lamppost I agree a lot with what you're saying here. In particular, I think there are two ways to attempt to answer the (silly, but then you take it seriously) question "what is the greatest programming language possible?" First, you can ask for power measured in "How completely does this language serve to articulate and circumscribe any thought which I might, as a human, want to have?". Following this line necessitates following logic carefully not because it's magically better but because mathematicians have spent many centuries delimiting interesting, complex ideas and at least 1 century working dedicatedly on a language for describing them. It's silly not to crib off this effort... or to think any other field is going to surpass it. Second, you can ask for whatever language best fits the human mind with all of its quirks. This is a question of psychology, of course, and design and I would never claim that it's not incredibly important... although I do often give it short shrift. The reason being that I have some personal chips on the idea that these two goals actually will wind up in the same place more-or-less. This isn't to claim that mathematics doesn't have massive ergonomics issues today... but instead to claim that it is in many ways an ultimate distillation of the logic all of our minds are marinating in... just as a consequence of living in this universe and partaking in this shared experience. I feel like Mathematics took on the challenge of mapping out the entire human headspace from the inside out and psychology took on the same challenge but working from the outside in. I have to believe they'll converge someday. And then, maybe finally, someone will write a language with good error messages.