Programming Languages (CSC-302 98S)

[Instructions] [Search] [Current] [Changes] [Syllabus] [Handouts] [Outlines] [Assignments]


Assignment Three: Semantic Analysis and Types

Assigned: Friday, February 13, 1998
Due: 11am, Friday, February 20, 1998

1. A Typed Expression Grammar

Build an attribute grammar for expressions to determine the type of each expression. You may assume that each identifier has a type attribute. Your grammar should use the coercion rules of Java (you'll need to look them up) and support the types byte, short, int, long, float, double, boolean, and String. You may also want to add an error type to indicate that an expression cannot be typed.

Your grammar should support the operations +, -, *, /, <, >, == with appropriate associativity and precedence. Your grammar should also support parenthesization.

2. An Expression Compilation Grammar

Build an attribute grammar that translates arithmetic expressions over floating point variables to corresponding assembly code that, when executed, would evaluate those expressions. Expressions should be allowed to include +, -, *, /, and parentheses.

You should use the following operations for a single-register machine (in which that single register is called the accumulator).

set X
set the accumulator to the value stored in variable X.
sto X
store the accumulator in variable X.
add X
add the value stored in variable X to the accumulator.
subtract X
subtract the value stored in variable X from the accumulator.
multiply X
multiply the accumulator by the value stored in variable X.
divide X
divide the accumulator by the value stored in variable X.
label N
define a label (used for branches).
JMP N
jump/branch to the line labeled N.
JMZ N
jump to the line labeled N if the accumulator has value 0.
NOOP d
do nothing.

3. User Defined Types

Why might someone suggest that a programming language should not support user-definable types? How might you convince them that their reasoning is misguided?

Your answer to this question should be well-reasoned and should accomodate the statements and responses an opponent of user-definable types might give.

4. Describing Meta-Types

Some languages permit programmers to write their own type constructors. For example, one might be able to define List(x) where x is any type. Having done so, it then becomes possible to write things like

type
  intlist = List(integer);
var
  names = List(string);
These type constructors are often called meta-types.

Suppose you were required to extend Pascal so that it supported user-definable type constructors. What syntax would you use for such constructors (i.e., how does one define such a type constructor on par with record and array?) What other issues might one need to consider in adding such meta-types to Pascal?

If your answer is based on experience with user-definable type constructors in another language, note which language you've based your answer on.

5. Why Have Meta-Types

Why might a group of language designers decide to include meta-types in a programming language? How might you convince them that this is a bad idea?

Your answer to this question should be well-reasoned and should accomodate the statements and responses an opponent of user-definable types might give.

6. Type Coercion

Write a program that reads sequences of the form

type + type + type + ... + type
and reports on any type coercions that must occur for that sequence to be interpreted. You may decide which type coercion strategy to use, but it should be reasonable and well-documented. You should support integers, reals, and strings.

For example, your program might generate the following

int + int + real + int + string
^^^^^^^^^                       coerce to real
                   ^^^          coerce to real
^^^^^^^^^^^^^^^^^^^^^^          coerce to string

Your program need not generate output in this form. Your goal is to make it clear which coercions are necessary. This is simply an illustration of one way to do that.


[Instructions] [Search] [Current] [Changes] [Syllabus] [Handouts] [Outlines] [Assignments]

Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.

Source text last modified Thu Feb 19 10:59:59 1998.

This page generated on Thu Feb 19 11:03:12 1998 by SiteWeaver.

Contact our webmaster at rebelsky@math.grin.edu