at the moment I am writing a scientific expose. A part of the content is about the definition of closures in our developed DSL. However, I was not able to find references of how to formally describe function closures in computer programming. I must admit I have searched in only a handful of programming books. Without any success.
What I really need is the formal, precise and maybe mathematical definition of the concept of function closure in computer programming. Using a formal definition we may find a way to define our special kind of closures in a convenient and precise way.
Is there any standard notation/description out there?
If not maybe one of you theorist can give me a hint, how to elegantly describe them ;)
So, since I already created a definition on my own, I want to share it with everyone, that is looking at this question.
The following definition is a short version and product of my own thoughts, so do not simply adopt it without thinking through it.
Closures are an implementation technique to implement lexically scoped name binding.
The operational view of a closure is the tuple of an environment E that binds free variables of the function f, and f itself: (E,f). Let E[in1] = x bind the value of in1 to an arbitrary x. The application foo(in2) of the closure (E, foo(in1, in2)) gets then evaluated to the same result, as foo(x, in2).
Other than partial evaluation, the functions source code is not duplicated. The environment is evaluated at run-time.
What do you think?
Related
I'm building a interpreter and i'm now at the point where I need to implement it to handle closures. I understand the concept pretty well but I have a question on why they're designed the way they are.
In terms of how a closure is designed/interpreted there needs to be 3 things:
variable
body of logic that variable is bound to
environment that is saved during the closure's instantiation, this is for free variables that exist within the body to be bound when the closure variable is evaluated.
I understand why all of these things are needed, i'm just wondering about why the 3rd item is needed at all when substitution at the moment of the closure's creation is doing the same thing? Is there anything i'm not accounting for?
Essentially what i'm asking is why not just substitute the free variables with the respective environment values at closure creation instead of passing the environment entirely?
I guess it's a little late, but oh well...
That depends on your computation model (evaluation strategy for example).
If all the data structures [which can get bound by a variable, and in effect enclosed] are immutable in your language your method should work.
It works with pure lexical lisp dialects (eg functional subset of scheme), nice and smooth.
It might not work if:
You pass arguments by reference, as was already mentioned in the comments. Call by value is fine. Also references to immutable object are fine.
Your environment binding and/or lookup causes some side effect. That would be rather exotic, but who knows?
Also, mind you don't have to enclose entire environment, just the free variables of your function's body (easy!).
The only reasons [I am aware of] for implementing closures as body+environment are:
you might want to pass references to mutable objects. This happens i.a. with dictionaries in js and python; it is a bit scary to have closure changing over time, but oh well.
you don't need to write substitution function. Mind it has to keep the scoping correct, so would have to resemble your evaluation function [if your computational model is substitutional] -- so why repeat yourself? Also there is this delicate nature of values: in case of applicative order ("eager evaluation") when you substitute the value in the body, you need it to be lifted to expression who's value is the thing (if by any chance you are implementing LISP variant, think about symbols -- you don't substitute the value HI!, but the expression (quote HI!). This does not apply to cases when all your datastructures evaluate to themselves, like numbers or truth values in most LISPs). These are not problems in general, but introduce some complexity to your interpreter, and simple is good.
the bound value might be something memory-consuming, and the variable you enclose occurs [as a free variable] more than once -- you body will be significantly larger (e.g. your value is a bitmap or sound sample or some enormous matrix or... you get the picture). It is similar problem to computation duplication with lazy evaluation, but wrt memory, not time. This is also usualy not a problem as computer memories are big.
I've ran out of ideas what else might break, but if you're not into checking your computation model "on paper" (by equational reasoning) you should implement it and try the trickiest cases [if any of these applies]: side effects, lazy evaluation, references, mutable objects, combinations of the above. They are definitely not obstacles, just places worth checking.
Hope that helps, good luck with your interpreter!
PS If you like to think about this kind of stuff, check out defunctionalization ("Defunctionalization at Work" by Danvy and Nielsen is a pretty accessible read, and you should be fine with first part to get some inspiration)
I was watching programming languages courses given by Prof. Shriram Krishnamurthi on youtube.
In this episode,
https://youtu.be/SUh7jhrtktk?t=1600
He said conflating environment and objects is the fundamental sin of Javascript. The environment is exposed to language users, and the users can manipulate the environment.
I don't quite understand what he means actually. Does he refer to how "this" works in Javascript?
Are there any code examples which can demonstrate this sin?
After a little bit of digging, I’ve found a paper from Professor Shriram’s group.
https://cs.brown.edu/research/plt/dl/jssem/v1/
In section 2.5, they pointed out that it is not clear whether JavaScript is lexically scoped because the scope chain in javascript is formed with ordinary objects, and with statement lets programmers add arbitrary objects to the scope chain.
I think I now fully understand what he means in the video.
I highly recommend this paper. It indeed catches all of the essence of javascript according to its title, not only the good part, but also the bad part.
I know that Module Pattern is very useful and powerful in Javascript programming.
I recognized that pattern in Eric Miraglia's blog for the first time , but I am wondering one thing.
In other blogs and articles that explain Module Pattern, I notice that their sample codes are slightly different from Eric's article, that is, they use function expression with parenthesis rather than function statement, for example, the article from ben cherry is one of them.
Is there any specific reason to use function expression rather than function statement?
Please explain with easy way, I just entered into Javascript Programming world :)
The Miraglia pattern is the same, defining an anonymous function and executing it. The difference is that in order to use the features of the module, you must have a reference to an instance somewhere. Assigning the module to a global variable (YAHOO.*) is a way to retain the reference at a globally known spot, especially important for frameworks (like YUI).
Sometimes you don't need that reference. For example, if you are writing JavaScript for a web page, you often bind events to functions using selectors (ids / types, etc.) That really removes the need for any global reference to your module function.
Hope that make sense...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
The more I delve into javascript, the more I think about the consequences of certain design decisions and encouraged practices. In this case, I am observing anonymous functions, a feature which is not only JavaScript-provided, but I see strongly used.
I think we can all agree on the following facts:
the human mind does not deal with more than 7 plus minus two entities (Miller's law)
deep indentation is considered bad programming practice, and generally points out at design issues if you indent more than three or four levels. This extends to nested entities, and it's well presented in the python Zen entry "Flat is better than nested."
the idea of having a function name is both for reference, and for easy documentation of the task it performs. We know, or can expect, what a function called removeListEntry() does. Self-documenting, clear code is important for debugging and readability.
While anonymous functions appears to be a very nice feature, its use leads to deeply nested code design. The code is quick to write, but difficult to read. Instead of being forced to invent a named context for a functionality, and flatten your hierarchy of callable objects, it encourages a "go deep one level", pushing your brain stack and quickly overflowing the 7 +/- 2 rule. A similar concept is expressed in Alan Cooper's "About Face", quoting loosely "people don't understand hierarchies". As programmers we do understand hierarchies, but our biology still limits our grasping of deep nesting.
I'd like to hear you on this point. Should anonymous functions be considered harmful, an apparent shiny syntactic sugar which we find later on to be salt, or even rat poison ?
CW as there's no correct answer.
As I see it, the problem you're facing is not anonymous functions, rather an unwillingness to factor out functionality into useful and reusable units. Which is interesting, because it's easier to reuse functionality in languages with first-class functions (and, necessarily, anonymous functions) than in languages without.
If you see a lot of deeply nested anonymous functions in your code, I would suggest that there may be a lot of common functionality that can be factored out into named higher-order functions (i.e. functions that take or return ("build") other functions). Even "simple" transformations of existing functions should be given names if they are used often. This is just the DRY principle.
Anonymous functions are more useful functionally than they are harmful legibly. I think that if you format your code well enough, you shouldn't have a problem. I don't have a problem with it, and I'm sure I can't handle 7 elements, let alone 7 + 2 :)
Actually, hierarchies help to overcome 7+/-2 rule the same way as OOP does. When you're writing or reading a class, you read its content and nothing of outside code so you are dealing with relatively small portion of entities. When you're looking at class hierarchies, you don't look inside them, meaning then again you are dealing with small number of entities.
The same if true for nested functions. By dividing your code into multiple levels of hierarchy, you keep each level small enough for human brain to comprehend.
Closures (or anonymous functions) just help to break your code into slightly different way than OOP does but they doesn't really create any hierarchies. They are here to help you to execute your code in context of other block of code. In C++ or Java you have to create a class for that, in JavaScript function is enough. Granted, standalone class is easier to understand as it is just easier for human to look at it as at standalone block. Function seems to be much smaller in size and brain sometimes think it can comprehend it AND code around it at the same time which is usually a bad idea. But you can train your brain not to do that :)
So no, I don't think anonymous functions are at all harmful, you just have to learn to deal with them, as you learnt to deal with classes.
Amusingly, JavaScript will let you name "anonymous" functions:
function f(x) {
return function add(y) {
return x+y;
};
}
I think closures have enormous benefits which should not be overlooked. For example, Apple leverages "blocks"(closures for C) with GCD to provide really easy multithreading - you don't need to setup context structs, and can just reference variables by name since they're in scope.
I think a bigger problem with Javascript is that it doesn't have block scope(blocks in this case referring to code in braces, like an if statement). This can lead to enormous complications, forcing programmers to use unnecessary closures to get around this Javascript design limitation.
I also think anonymous functions (in latest languages often referred as closures) have great benefits and make code often more readable and shorter. I sometimes am getting really nuts when I have to work with Java (where closures aren't first class language features).
If indentation and too many encapsulated function-variables are the problem then you should refactor the code to have it more modular and readable.
Regarding java-script I think that function-variables look quite ugly and make code cluttered (the encapsulated function(...){} string makes java-script code often less readable). As an example I much prefer the closure syntax of groovy ('{}' and '->' chars).
If a function is not understandable without a name, the name is probably too long.
Use comments to explain cryptic code, don't rely on names.
Who ever came up with the idea of requiring functions to be bound to identifiers did every programmer a disservice. If you've never done functional programming and you're not familiar with and comfortable with functions being first-class values, you're not a real programmer.
In fact, to counter your own argument, I would go so far as to consider functions bound to (global) names to be harmful! Check Crockford's article about private and public members and learn more.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm finding myself coding a big project in Javascript. I remember the last one was quite an adventure because hacky JS can quickly becomes unreadable and I want this code to be clean.
Well, I'm using objects to construct a lib, but there are several ways to define things in JS, implying important consequences in the scope, the memory management, the name space, etc. E.G :
using var or not;
defining things in the file, or in a (function(){...})(), jquery style;
using this, or not;
using function myname() or myname = function();
defining methods in the body of the object or using "prototype";
etc.
So what are really the best practices when coding in OO in JS ?
Academic explanations really expected here. Link to books warmly welcome, as long as they deal with quality and robustness.
EDIT :
Got some readings, but I'm still very interested in answers to the questions above and any best practices.
Using `var` or not
You should introduce any variable with the var statement, otherwise it gets to the global scope.
It's worth mentioning that in strict mode ("use strict";) undeclared variable assignments throws ReferenceError.
At present JavaScript does not have a block scope. The Crockford school teaches you to put var statements at the beginning of the function body, while Dojo's Style Guide reads that all variables should be declared in the smallest scope possible. (The let statement and definition introduced in JavaScript 1.7 is not part of the ECMAScript standard.)
It is good practice to bind regularly-used objects' properties to local variables as it is faster than looking up the whole scope chain. (See Optimizing JavaScript for extreme performance and low memory consumption.)
Defining things in the file, or in a `(function(){...})()`
If you don't need to reach your objects outside your code, you can wrap your whole code in a function expression—-it's called the module pattern. It has performance advantages, and also allows your code to be minified and obscured at a high level. You can also ensure it won't pollute the global namespace. Wrapping Functions in JavaScript also allows you to add aspect-oriented behaviour. Ben Cherry has an in-depth article on module pattern.
Using `this` or not
If you use pseudo-classical inheritance in JavaScript, you can hardly avoid using this. It's a matter of taste which inheritance pattern you use. For other cases, check Peter Michaux's article on JavaScript Widgets Without "this".
Using `function myname()` or `myname = function();`
function myname() is a function declaration and myname = function(); is a function expression assigned to variable myname. The latter form indicates that functions are first-class objects, and you can do anything with them, as with a variable. The only difference between them is that all function declarations are hoisted to the top of the scope, which may matter in certain cases. Otherwise they are equal. function foo() is a shorthand form. Further details on hoisting can be found in the JavaScript Scoping and Hoisting article.
Defining methods in the body of the object or using "prototype"
It's up to you. JavaScript has four object-creation patterns: pseudo-classical, prototypical, functional, and parts (Crockford, 2008). Each has its pros and cons, see Crockford in his video talks or get his book The Good Parts as Anon already suggested.
Frameworks
I suggest you pick up some JavaScript frameworks, study their conventions and style, and find those practices and patterns that best fit you. For instance, the Dojo Toolkit provides a robust framework to write object-oriented JavaScript code which even supports multiple inheritance.
Patterns
Lastly, there is a blog dedicated to explore common JavaScript patterns and anti-patterns. Also check out the question Are there any coding standards for JavaScript? in Stack Overflow.
I am going to write down some stuffs that I read or put in application since I asked this question. So people reading it won't get frustrated, as most of the answers are RTMF's in disguise (even if I must admit, suggested books ARE good).
Var usage
Any variable is supposed to be already declared at the higher scope in JS. So when ever you want a new variable, declare it to avoid bad surprises like manipulating a global var without noticing it. Therefore, always use the var keyword.
In an object make, var the variable private. If you want to just declare a public variable, use this.my_var = my_value to do so.
Declaring methods
In JS, they are numerous way of declaring methods. For an OO programmer, the most natural and yet efficient way is to use the following syntax:
Inside the object body
this.methodName = function(param) {
/* bla */
};
There is a drawback: inner functions won't be able to access "this" because of the funny JS scope. Douglas Crockford recommends to bypass this limitation using a conventional local variable named "that". So it becomes
function MyObject() {
var that = this;
this.myMethod = function() {
jQuery.doSomethingCrazy(that.callbackMethod);
};
};
Do not rely on automatic end of line
JS tries to automatically add ; at the end of the line if you forget it. Don't rely on this behavior, as you'll get errors that are a mess to debug.
First ought to read about the prototype-based programming so you know what kind of beast you're dealing with and then take a look at JavaScript style guide at MDC and JavaScript page at MDC. I also find best to force the code quality with a tool, ie. JavaScript Lint or other variants.
Best practices with OO sounds more like you want to find patterns than concentrate on code quality, so look at Google search: javascript patterns and jQuery patterns.
Speed up your JavaScript
You might want to check out Secrets of the JavaScript Ninja by John Resig (jQuery). "This book is intended to take an intermediate JavaScript developer and give him the knowledge he needs to create a cross-browser JavaScript library, from the ground, up."
The draft is available through the publisher:
http://www.manning.com/resig/
Douglas Crockford also has some nice JavaScript articles on his homepage:
http://www.crockford.com/
I often feel like the only guy here who uses MooTools for my javascript.
It stands for My Object Oriented Tools, mootools.
I really like their take on OOP in javascript. You can use their class implementation along with jquery too, so you don't have to ditch jquery (though mootools does it all just as well).
Anyway, give the first link a good read and see what you think, the second link is to the mootools docs.
MooTools & Inheritance
MooTools Classes
Here's a book that covers most of the bases:
Object Oriented Javascript for high quality applicatons and libraries