Conversation

Yep, I've called them "lambda functions" and explicitly said they aren't closures. Does that sound fine?

David Smith

@Catfish_Man

tbh I don't remember, if I ever knew, what features the formalism that name got borrowed from requires for functions

eleanor

@zornsllama

To your mind, does a "lambda function" intuitively require the possibility of closure?

David Smith

@Catfish_Man

None of the languages I use day to day use that term, so I would mentally translate it into something more familiar like "closure" or "block" and then be a little startled when I couldn't capture anything. Swift calls these "thin closures", but I think that's one we made up.

many GC’d languages don’t make any distinction based on whether something closes over variables or not; Ruby’s distinctions are particularly weird; Haskell programmers only differentiate syntactically (top-level vs. where clause vs. lambda) and ghc does whatever it wants anyway

typically I’d say “lambda” to mean “function written inline in an expression” or even “function written with the \ syntax,” but I’d roughly consider “function” and “lambda” synonymous.

by contrast, I only ever say “closure” when referring to the runtime-extant value which the syntax generates, and I’d say that whether or not it actually closed over any variables.

eleanor

@zornsllama

so a lambda is a declaration, and a closure is an object?

a lambda is an expression rather than a declaration. e.g.: map (\ a -> a + 1) xs the first argument to map there is a lambda map f xs where f a = a + 1 f is a declaration the distinction being, declarations declare names (this isn’t set in stone, but it’s ~usual IME)