6.S050 Problem Set 3: Functional languages & Naming

You will receive one of your classmates' semantics for parallel IMP. Answer the following questions about their submission and post your response as a note on Canvas.

1. Pick one aspect of their formalism that you think is particularly clear or elegant, and explain why.
2. Pick one aspect of their formalism (e.g. use/lack of reduction contexts, structure of configuration, etc.) that you found confusing or verbose, and suggest an improvement. Feel free to share what you chose to do in your formalism.

You are presented with the following language design.

J is a scripting language with a lightweight object system (it's JavaScript, but we want you to ignore the class system, arrow functions, prototypes, etc—treat this as a new language that only has objects and functions). Rather than creating objects using classes, J has first-class functions and object literals: Here's a J program that creates a counter object and increments it:

let counter = {
  count: 0,
  incr: function () {this.count = this.count + 1}
};
counter.incr();
console.log(counter);

{ count: 1, incr: [Function: incr] }

J has an unusual design feature: the this keyword. this can refer to several things, according to the following rules:

• When this is accessed inside a function:
  • If the function was called by accessing it from an object o, then this refers to o.
  • If the function is called directly, then this has the value undefined.
• When this is accessed outside a function (this includes accesses inside an object, but outside a function), it refers to the "global object"—a singleton object created at the start of execution.

You can see why the designers of J added this to the language; it makes object-oriented programming simpler, which makes J more familiar to programmers coming from Java or C++. However, the semantics of this are generally considered unnatural.

We can demonstrate the strange semantics of this with two examples:

1. The scoping rule for this is dynamic, not lexical. The following creates a counter that behaves identically to the code above:

   let counter = {
     count: 0
   };
   counter.incr = function () {this.count = this.count + 1};
   counter.incr();
   console.log(counter);
   

   { count: 1, incr: [Function (anonymous)] }
   

   If this were lexically scoped to the body of the object literal, this code would not work. Instead, the value of this depends on the way that incr is called.

   To make this point clearer, if we take the incr method out of the object and call it directly, the counter does not increment (and in fact the function call will throw an exception), because this is now undefined.

   Example A: Object method reference

   let counter = {
     count: 0,
     incr: function () {this.count = this.count + 1},
   };
   let incr = counter.incr;
   incr();
   

   This is a reasonable thing to do in real code (maybe you want to make many calls to a method on an object with a long name), so we'd like this idiom to be easy to express in your revised version of J.

2. Moving this between nested scopes is problematic: The following code works:

   let counter = {
       count: 0,
       print: function () { console.log(this.count); }
   };
   counter.print();
   

   0
   

   But what if we want to print output after a delay? We can use the setTimeout function, which takes a callback and a time to wait:

   let counter = {
       count: 0,
       print: function () {
   	setTimeout(function() {
   	    console.log(this.count);
   	}, 100);
       }
   };
   counter.print();
   

   undefined
   

   That broke our printing function! Why?

   this is now inside another function, and that function is not being called as a method on counter. The correct version does something like this:

   Example B: reference to this in a nested scope

   let counter = {
       count: 0,
       print: function () {
   	let this_ = this;
   	setTimeout(function() {
   	    console.log(this_.count);
   	}, 100);
       }
   };
   counter.print();
   

   0
   

   Functions that take a callback are common in J, and this workaround is clumsy. We'd like to modify the rules for this so that refactoring by moving code in or out of a function is safer. Your revised version of J should make it easy to express code like this.

3. J is still a dynamic language, and programmers should be able to create objects dynamically. Your modifications to J should allow programmers a reasonable way to write the following code, which implements a generic object cloning function. Note that the semantics of this means that objects that are written in the standard way will be correctly cloned.

   Example C: dynamic object construction

   function clone(obj) {
       let rv = {};
       for (let x in obj){
   	rv[x] = obj[x];
       }
       return rv;
   }
   

Propose an alternative design for J that either improves the semantics of this or replaces it with a better mechanism.

Write an explanation of your new design and justify your design choices (2-3 paragraphs). The following questions are good starting points:

• Is your new design simpler than the original? Easier to understand? Why?
• Are there potential programming errors that your design avoids?
• Is your design more/less expressive than the original? If less, can you still write normal object-oriented programs?

Explain how examples A, B, and C would be written in your new design and why your design is an improvement over the original J.

You do not need to formalize your design.