Earlier quoted context omitted.
The two are pretty much the same when you get down to it
Who told you that?
Don't think anybody told me that, but I do believe it to be the case
Dualities in functional programming
21–28 of 28 posts
Re: Dualities in functional programming
#22Re: Dualities in functional programming
#23Re: Dualities in functional programming
#24Besides those mentioned in the article, most everything in functional programming has a dual, usually by prefixing "co-". Cofunctor, coapplicative, comonoid, comonad, &c. All things with reversed arrows and varying degrees of usefulness.
That looks like category theory rather than functional programming.
That's just another path to understanding and gaining practical insights about things.
While these mathematical concepts can provide rigorous foundations for understanding software patterns, they're not really essential for applying the practical knowledge of:
- How to handle failures (null vs defaults)
- How to structure APIs (separated vs combined)
- How to organize services (monolith vs microservices)
Most developers already using those category theory concepts without even realizing:
Functor patter - is just mapping over sequences; Applicatives - sequence operations; Monads - promise chaining in JS; Comonads for context management (e.g., with-open db-connection), etc.
Re: Dualities in functional programming
#25I like this and have a similar frame of mind. I wish more languages would make their sum types true duals of their structs (with a single payload datum - instead we have tuple variants and structure variants and so-on complicating matters for at best a character of syntax (but careful design could eliminate even that). The author may be interested in coeffects as the dual of effects. They are pretty much as stated: c…
The best practical understanding of Petricek's work I gained from using Clojurescript's Re-frame library. In re-frame, coeffects represent the data that an event handler needs from the outside world to do its job (like current time, random numbers, or local storage values). This aligns with the academic concept of tracking contextual dependencies, just applied practically in a front-end framework context.
The main difference is that re-frame uses a more pragmatic, simplified version focused specifically on event handling in web applications, rather than the full mathematical formalism of the academic work.
Learning re-frame was a light-bulb moment for me. I highly recommend giving it a try, even if there's never a plan to use Clojure or Clojurescript in practice.
Re: Dualities in functional programming
#26There exists a rich theory about duality in computation, a forgotten twin of lambda calculus: sequent calculus https://ps.cs.uni-tuebingen.de/publications/ostermann22intro... I recommend you check it out if you are at least a little curious about duality in programming. I've been thinking about duality at the core of programming language design for a while now. Motivated by asynchronous computation and mainly focused…
That author has a bit of a misunderstanding about Lisp: "Lisp evaluation works by mutual recursion of eval and apply. Eval looks at an expression and if it is a function application it calls apply. Apply in turn calls eval on the arguments and invokes its function on them. This is call-by-value." In classical Lisp and its descendants, apply is a function. Indeed, the paradigm is call by value, and therefore that func…
I tried digging through both the article, SICP and your comment, and here are my thoughts: I think both statements are correct in their context.
The perma-curious.eu article is right about the eval-apply cycle as presented in SICP. The SICP metacircular evaluator presents eval and apply as two mutually recursive procedures that form the core of a Lisp interpreter. In this implementation, apply does evaluate arguments indirectly through eval. The mutual recursion between eval and apply is indeed fundamental to Lisp, and it's clearly explained in the "wizard book". The call-by-value evaluation strategy is also correctly described - arguments are evaluated before being passed to functions. This eval-apply cycle forms the essence of Lisp's execution model.
But your comment is also valid, your correction is more precise:
- apply is indeed a function that takes already-evaluated arguments
- eval does the evaluation of arguments before calling apply
- apply simply binds and executes the function with its arguments
- The relationship isn't truly dual - apply depends on eval, but not vice versa
I think the confusion came from conflating the built-in apply function with the apply procedure used in implementing an interpreter.
Re: Dualities in functional programming
#27Earlier quoted context omitted.
Why?
Category theory is equivalent to type theory.
It's probably more accurate to say that they are complementary rather than equivalent.
- Category theory emphasizes morphisms and composition
- Type theory emphasizes terms and computation
There are important correspondences between them (like the Curry-Howard-Lambek correspondence), but they have different strengths and different ways of expressing concepts.
Sorry, I couldn't resist the temptation of being a pedantic formalist.
Re: Dualities in functional programming
#28Earlier quoted context omitted.
That author has a bit of a misunderstanding about Lisp: "Lisp evaluation works by mutual recursion of eval and apply. Eval looks at an expression and if it is a function application it calls apply. Apply in turn calls eval on the arguments and invokes its function on them. This is call-by-value." In classical Lisp and its descendants, apply is a function. Indeed, the paradigm is call by value, and therefore that func…
I tried digging through both the article, SICP and your comment, and here are my thoughts: I think both statements are correct in their context. The perma-curious.eu article is right about the eval-apply cycle as presented in SICP. The SICP metacircular evaluator presents eval and apply as two mutually recursive procedures that form the core of a Lisp interpreter. In this implementation, apply does evaluate arguments…
SICP is not the horse's mouth in this matter, and doesn't purport to be. It's presentations are designed to suit its pedagogical aims, not to build up a historically accurate Lisp.
Last I heard, they supposedly rendered the book and course into Python.