Assignment #10: (Not for submission) Slug

Same pairs.

Update the course plugin for the language level for this assignment.

In this homework you are given an extended version of the SLOTH evaluator, which you will extend. To keep things in the world of slow animals, the new language is called SLUG. Begin your work with the slug.scm source. The extensions to SLOTH that makes it SLUG are described below, make sure you understand the code before you modify it.

Don't panic! This homework requires understanding of a few lectures, and reading through some code. Make sure you understand the material, and go through this work according to the specified steps.

Your first job is to implement an I/O side effects layer for the SLUG language, following the principle that we have seen in class. We begin with implementing output, and then continue to implement sequencing and input.

The idea is simple: in a lazy language, expressions are always delayed as promises, so we're dealing with computations rather than values. This makes it really convenient in some situations, but it is an obstacle when we want to deal with side-effects. So, to implement I/O, we use descriptions of input/output operations rather than the operations themselves. For example, instead of a statement that prints a string, we use a value that denotes a string printout.

SLUG extensions for I/O

SLUG is extended in several ways to support I/O. Make sure you understand these changes before you begin your work.

• First, SLUG has string values in addition to other types — which affects both parsing and evaluation. In SLUG code, you use '...' for strings, for example:

  (run "{list 1 'foo'}")

  To include a quote in a SLUG string, repeat it twice. (Scheme escapes like “\n” are also supported.)
• Second, it has a new kind of values: IOV, which stand for I/O values. These values are used for descriptions of I/O operations, which is what the IO type they hold (see below) is used for.
• The IO type is the actual description for I/O operations. It has cases for the three building blocks of I/O side effects — output, input, and sequencing of two I/O operations. These correspond to a Scheme function call for display, read-line, and a begin expression respectively.
• The global environment has new bindings for print, read, and begin2, which are built-in functions that construct these IOV values. Note that begin2 is also a function (in SLUG), since it only constructs a description of two operations. Also note that all of these are non-strict (since they are all constructors).
  (scheme-func->prim-val has been generalized to scheme-func->prim, which can use any wrapper for the resulting value: it is used with either ScmV or IOV).
• There is a section that is labeled as “I/O Execution”, which is in charge of “translating” I/O descriptions into actual actions. This is where you will do your work.
• Finally, in addition to the main run function, there is a new toplevel entry point — run-io. This one expects an IOV result, and uses perform-i/o (from the above section) to execute the actions that are described in this result.

The “I/O Execution” section is incomplete. The perform-i/o function expects an IO value and acts accordingly, but the core parts of this function are missing (marked by ???). Your task is now to fill in these three blanks.

Output

The case for output is the simplest: it is getting a Print description, and expects it to hold a string value:

When you've done this, you will be able to test your code, for example:

Sequencing

Next, we move to sequencing which is also easy. The case for this:

Again, testing this should be easy.

An interesting thing to see here is the correlation between values and computations. For example, translate this infinitely-looping Scheme code to SLUG:

Input

Finally, dealing with input is a little more complicated. The idea is that when the program reads a value, it needs to continue its computation with the result — but this result is only available when we execute the resulting I/O descriptions. The solution is to plant functions in the stream of descriptions: to read some input, you construct a ReadLine description (specified by the read function in SLUG programs), and hand it a function of one argument, which specifies what to do with the input.

For example, to prompt and read a name, and then print it, you build a read-description that contains a function and does the printout:

The ReadLine case already ensures that it is used with a closure of one argument:

The above code should work as expected when you're done with this.

Another extension to SLUG is that it has a generic macro preprocessor. An additional input syntax — with-stx — specifies macro transformers in a way that is similar to Scheme's syntax-rules. The syntax of with-stx is:

• The first identifier names the new syntax. (with-stx is limited to a single (local) syntax definition.)
• Then there is a list of identifiers that are literal keywords that are expected to appear in code that uses this macro. (Enclosed in braces.)
• Then there is a sequence of pattern pairs, each has an input pattern and an output pattern. These specify the rewrite rules that make the actual transformation.
• Finally, there is an expression which is subject to rewrites using this macro.

Macro expansion is implemented during parse, which now carries around an environment-like argument holding bindings for syntax transformers. Whenever parse encounters a with-stx input, it builds a transformer and adds it to the recursive call. All Call application forms are first checked — if their first expression is an identifier, and this identifier is a currently-known macro name, then the transformer is applied and parsing continues with the result.

For example, see the last test in the file: it implements a let macro that is equivalent to bind, except that it is translated to function calls, and then it implements a let* form as shown in class.

Your task

As seen above, you can now do I/O in your lazy language, but the syntax for doing this is much too verbose. Your job is to write a do macro that will make things easier to write. For example, the new syntax will allow running this:

For this question, all you need to do is to fill in the macro body which is marked by ??? in the above code. To make things easier, here is a bit more from this macro — you have three cases to complete:

The same approach can be used to deal with mutation: we can add boxes to the language, and handle them through operation descriptions in the same way that we handled I/O — in fact, we can extend IO with new descriptions. Do this in steps:

1. Add three cases to the IO type definition:

   ;; I/O descriptions (define-type IO [Print (string VAL?)] [ReadLine (receiver VAL?)] [Begin2 (l VAL?) (r VAL?)] ;; mutation [NewBox (init VAL?) (receiver VAL?)] [UnBox (boxed VAL?) (receiver VAL?)] [SetBox (boxed VAL?) (newval VAL?)])

2. Add bindings for the new operations: newbox unbox, set-box!,
3. Update strict-IO,
4. Extend perform-i/o with the required functionality.

Finally, use the same approach as above — extend the previous macro so the new constructs can also be used in a do context. You should be able to get to the following code:

Why is macro expansion mixed with parsing?
(Only an exact answer will count.)

It is nice to have with-stx in the language so that users can extend their own set of syntactic constructs. However, this is a difficult job, and we want to give them some pre-defined syntaxes. Do this by implementing a global-transformers which is provided as the initial argument to parse-sexpr. Populate this with a few useful syntax transformers, like the above do (you will need to write Scheme code that generates the same transformer). Also, for fun, add a prog syntax that makes it possible to write definitions followed by a body expression — which is being translated to a sequence of nested bind expressions. It should be used like this: