CSC302 2005S, Class 5: Language Design

Admin:
* Attendance (late): Brantley, Edwards, Rosenbluh
* Don't forget to send those questions!
* Reading for Friday: Gries 2
  * Submit questions by 8pm Thursday
* Please reboot this computer into Linux when you arrive
* Web pages not ready this morning.  Sorry.

Overview:
* Key language components
* Language design criteria
* Two competing mindsets
* Some particular details from Hoare
* Misc. Q and A

Reflections on Steele
* Made some good points, but OOP sucks
* Huge nerd
* Inventive way of making point
* Point: Should be possible for "users" to change the language
* Two ways to change
  * Change for yourself
    * Libraries
  * Get changes made for everyone
    * Bigger things, like overloading
* Alternate separation
  * Stuff that can be supplied as separate source code
  * Actual changes to the compiler
  * Preprocessing
* Hard for faculty to teach a moving target
* Should complaints be directed at library writers or at language designers?
  * Shift some burden away from base language
   
Some important terms:
* overloading:
  * Two (or more) operations can share the same name provided they have different parameter types
  * Traditionally: + can be applied to two integers or two reals
  * In Java, also foo(String s), foo(int x)a
* polymorphism:
  * One procedure can be applied to two (or more) similar kinds of values
    * In Java, the "similar" values must descend from the same specified ancestor or implement the same specified interface
  * foo(Object o) can be applied to String s and Integer i
* Similar:
  * Both involve applying the same function name to different kinds of values
* Difference:
  * Polymorphism requires only one definition ("more powerful")

Suppose the foolish designer of your language neglected to permit overloading.  What can you do?
* Whine
* Modify the compiler to permit overloading
* Write a preprocessor: Although we use the same name in the "source" code, that gets changed to different names in the revised source code
* Manually preprocesses

	x := y
	x := y + 1

Design Problem:
* What is involved in the design of a new programming language?
* Some basic design choices
* Some evaluative criteria that help us assess and improve those choices

Language design basics:
* An intent for the language
  * Pascal: Simple, clean, and good for teaching
  * Java: Good for building large systems and embedded systems
  * Perl: Easy to hack out system administration scripts
  * C: High-level assembly code, good for writing operating systems
  * Grep: Quickly identify matching text
* What paradigm or paradigms best support that intent
  * Imperative
  * Functional
  * Object-oriented
  * Declarative
* Pick feature set that match the first two
* Need a syntax for that feature set
* Need a semantics for that feature set
* Key questions: What kinds of things can you express and why?

Hoare and Steele both suggest one big design decision:
* Do you say "programmers know what they're doing" (trust the programmer)
* Do you limit what programmers can do because they commonly do things incorrectly? (Hoare)
  * As long as you preserve efficiency (Hoare)
* Steele may be more moderate
* However, Java reveals a lot of "mistrust" of the programmer

As an example of the danger of trusting the programmer, Hoare suggests that automatic type coercion is dangerous and uses Algol as an example

	float x;
	x := 1;

Algol introduced pointer (refernce) types and automatic coercion
For example, if you see

	y + 1

and y is a pointer to an integer, what do you expect?
* Could mean "the thing after the thing y points to"
* Could mean "one more than the thing y points to"
* If your language desicion is "you have pointer types, but you get no direct access to the memory locations" (e.g., Java);, you use the second

	x := y

can mean
	make x point to y (if y is an integer and x is an int ref)
	make x have the same value as y (if y is an integer and x is an integer)

	x := y + 1

CANNOT mean "make x point to that newly created integer"
Must therefore mean, "make the integer that x points to contain the value of that newly created intege"

Most programmers did not understand this subtlety.

--- 

The Fortan example comments on badly designed syntax: Whitespace
permitted in names

Loops in Fortran

	DO line variable = start , end
	DO 17 I = 1 , 10
		- Execute line 17 with I taking on values between 1 and 10 in sequence

	DO 17 I = 1 . 10