Live data from Hacker News

Functional programming jargon in plain English

github.com

141–150 of 191 posts

Re: Functional programming jargon in plain English

#141
post #97

Earlier quoted context omitted.

I'm not trying to dodge your question, but the answer to your question is that until you work with it for a while you're not going to understand it. Any blog-sized, bite-sized snippet isn't impressive. You have to work with it for a while. I speak many computer languages, and one of the ways I measure them is, "what do I miss from X when using Y?" The answers will often surprise you; the thing you'd swear up and down…

Couldn't I "curry" a function f(x,y) to "partially apply" it on x=3 with just: function(y) { return f(3,y); } ? And then I've "partially applied" f. Is this what currying is? The syntax I posted is ambivalent about which arguments you're partially applying, isn't that superior to only being able to provide the first argument?

Currying is turning a function with arity n into a sequence of unary functions.

  f(x,y) = ... // arity 2
  f = \x -> \y -> ... // sequence of two unary functions
  f x y = ... // more compact representation of the above
Regarding partial application, your JS (?) example is basically what happens under the hood with Haskell, but without the ceremony:

  f x y = ...
  fByThree = f 3
  fByThree y = f 3 y
Those last two are equivalent, but you don't have to include the y parameter explicitly, because f 3 returns a function that expects another parameter (like the function you wrote out explicitly).

And the Haskell version is more general, since it doesn't require a unique function to be written for each possible partial application. Of course, you can do this in languages with closures:

  function fByX(x) {
    return y => f(x,y);
  }
  fByThree = fByX(3);
But in Haskell that extra function isn't needed, it's just already there and called f. Regarding your last statement, there are also combinators in Haskell that allow you to do things like this:

  fXbyThree = flip f 3
  // equivalent to:
  fXByThree x = f x 3
  // JS
  function fXByThree(x) { return f(x,3); }
  // or
  function fXByFixedY(y) { return x => f(x,y); }
  fXByThree = fXByFixedY(3);
So I'm not sure it's strictly superior, it is more explicit though.

Re: Functional programming jargon in plain English

#142
post #57

Earlier quoted context omitted.

Saying "it allows for very concise partial function application" does nothing but repeat the definition. It does not, in particular, offer any reason to want that. What is so special about the first argument, that I want to fix it? Why not the third? Why is what I do to fix the third not just as good for the first? Pattern matching is a good example of a language feature included because they could not figure out how…

In a language like Haskell, pattern matching was explicitly chosen to be a primitive operation. It's not that there's no way to put it in a library; it's that it was chosen to be one of the small set of ideas everything else is described in terms of. Along with allocation and function application, you've got the entirety of Haskell's evaluation model. (Note: not execution model. That needs a bit more.) Having such a…

> Note: not execution model. That needs a bit more.

Actually... not really? You need the foreign function interface to have anything useful to execute, but (unless you're talking about something else?) the execution model is basically just a State monad carrying a unique magic token, built on top of the same evaluation model as everything else.

Re: Functional programming jargon in plain English

#143

Constant Functor Object whose map doesn't transform the contents. See Functor Constant(1).map(n => n + 1) Ummm… how is this constant?

It ignores the mapping completely:

    constant.map(...) == constant
Constant functors are only ever useful if you need to thread a simple value through code that asks for an arbitrary functor. I'd say that's rare even for abstract, type-level heavy code.

Re: Functional programming jargon in plain English

#144
post #35

This is more helpful than anything I have ever encountered on the topic. Comments: 1. It should explain map somewhere before it is used. 2. For the more abstruse and abstract concepts, a comment suggesting why anybody should care about this idea at all would be helpful. E.g., "A is just a name for what [familiar things] X, Y, and Z have in common." 3. It goes off the rails halfway through. E.g. Lift.

Expanding on your #1, I think they could use some more definitions. As you say, they use "map" in its functional programming sense before defining it, but I think more confusing is this one: > A category in category theory is a collection of objects and morphisms between them. What is a "morphism"? I think this is a great starting point though, which could use some expansion.

Ja, that "morphism" bit matches my #3.

Re: Functional programming jargon in plain English

#146

Earlier quoted context omitted.

In a language like Haskell, pattern matching was explicitly chosen to be a primitive operation. It's not that there's no way to put it in a library; it's that it was chosen to be one of the small set of ideas everything else is described in terms of. Along with allocation and function application, you've got the entirety of Haskell's evaluation model. (Note: not execution model. That needs a bit more.) Having such a…

> Note: not execution model. That needs a bit more. Actually... not really? You need the foreign function interface to have anything useful to execute, but (unless you're talking about something else?) the execution model is basically just a State monad carrying a unique magic token, built on top of the same evaluation model as everything else.

The execution model needs something that actually drives execution. There needs to be something that explains how IO actions are actually run. The state approach kind of works until you need to explain multiple threads, then it falls over.

Edward Kmett did some work to describe IO as an external interpreter working through a free monad. That approach provides very neat semantics that include multiple threads and FFI easily.

But IO needs something to make it go, and that something needs capabilities that aren't necessary for the evaluation model.

Re: Functional programming jargon in plain English

#147

These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…

I find your list a lot more helpful (and succinct) than the linked repo in the thread topic. Kudos! Perhaps you should make your own repository -- I would upvote it!

Re: Functional programming jargon in plain English

#148
post #97

Earlier quoted context omitted.

I'm not trying to dodge your question, but the answer to your question is that until you work with it for a while you're not going to understand it. Any blog-sized, bite-sized snippet isn't impressive. You have to work with it for a while. I speak many computer languages, and one of the ways I measure them is, "what do I miss from X when using Y?" The answers will often surprise you; the thing you'd swear up and down…

That's an example of why Haskell code is often hard to read, and why I'm glad this isn't available in other languages. Why not write out the callback given to map using a let block? Then you can give meaningful names to intermediate values so it's easier to see how the pipeline works. (Though, functional programmers would probably pass up the opportunity and use one-letter variable names.)

The feature is not called currying but partial application, it is very nice and intuitive.

Re: Functional programming jargon in plain English

#149

Looked at first one (arity), saw "argument" when what was actually meant was "parameter", and therefore dismissed the document. If you want to make a glossary, at least try to be precise.

They said 'a function takes arguments', which is correct. The arguments are passed into the function, aligning to and being bound to the function's parameters. So arity applies both to arguments the function can take, and the parameters the function has.

The way it's phrased and the examples makes it clear whoever wrote this didn't understand the distinction.
Post reply on HN