These materials are part of a set concerning how exploratory labs can be used to support mutual discovery in computing. We've been bootstrapping this process over multiple quarters, classes and institutions. The black text in this topic reproduces the materials on Blackboard in an undergraduate programming languages course at Cal State, East Bay, Spring quarter, 2008. The text in green italics is commentary. See also PLCLabsSpring08Info.

Labs

Lab 4: More fun with Data Types!

• start to get a firm handle on data abstraction, and how programming language design addresses data abstraction
  • look at type systems rather than just data types
  • get a feeling for the four communities of practice in design of type systems: denotational, structural, implementor, abstraction
  • name equivalence/structural equivalence
  • type safety/strong typing
  • components of a data type: (esp signatures) - in my slides

References:

• The Python language reference manual, especially the data model chapter
• The Python library reference manual, especially the built-in types and data types chapters.
• the Python community tutorials
• Chapter 7 of Scott, especially sections 7.1 - 7.9 - especially also slides
• you may also find section 9.1 of Scott helpful
• My slides too - a new set on data abstraction posted (and updated on Monday) in "older slides you may find useful" folder of Course Materials, along with "elementary data types," "built-in data structure types," etc.
  • see esp. slide 7 of my old 'elementary data types' slides, concerning signatures as part of what defines an object to be of a particular data type
  • see esp. slide 20 of my old 'data abstraction' slides, concerning the role of signatures in safe expressions.
  • together these form the basis of type safety in dynamically typed languages.

('Data abstraction' as a concept is, in fact, the same thing as 'abstraction' in the four communities of practice listed above. When someone presents a discussion of data types that they label 'data abstraction', chances are that they are presenting an abstraction approach - unless they explicitly label it otherwise.)

What to do:

• Preliminary research:
  • looking at a more general model of what we've been doing this quarter, you would read about topics in the learning objectives in the references, as well as any other reference materials you wanted to use.
  • you would also explore the topics with sample code, to be sure you understood what you were reading about, both in the new language and possibly in one or more existing languages you know.
  • you'd keep notes as you go about your observations and insights
• in your report, make sure that you address all of the learning objectives, narrating what you tried, with code examples
• make sure that you cover:
  • The standard Python distribution ships with both built-in types and extension modules, which can lead to some confusion. For example, array is an extension module, which is why is allows such a limited set of component types (it is contributed code, intended for a specific purpose.)
    • Spend some time exploring this distinction (the library reference vs. language reference may help.) Convince yourself and me that you get the distinction.
    • How does Python's type system fit with the theoretical models that the book discusses? Is it trying to accommodate any one community of practice? More than one? Explain your answers - illustrate with code or examples.
• and an extra question to drive you nuts (I don't expect you to be able to answer this one, by the way, but I'm throwing it out there to make you think...)
  • why do you suppose that they have picked those particular extension data types for inclusion in the Python core?

Lab 3: Data Types through the lens of Python

Learning objectives:

• begin to think about data objects, data values and data types from a language feature point of view
• see how a modern programming language handles the traditional canon (there's a good vocabulary word) of built-in data types
• thoroughly explore a well-designed type system
• learn a bit more of Python
• begin to understand how Python works and is meant to be used
• understand types in your current programming languages a bit better

References:

• The Python reference manual, especially the data model chapter
• Chapter 7 of Scott, especially sections 7.1 - 7.9
• you may also find section 9.1 of Scott helpful
• you may find my "elementary data types" and "built-in data structure types" slides in the "older slides you may find useful" folder of Course Materials

What to do:

• Compare the data types Scott discusses in Chapter 7 to the data types Python provides (as discussed in the data model chapter of the Python reference manual listed above).
  • How do the Python types match up with the types Scott discusses?
  • Illustrate your answer with some examples Python code - it doesn't have to be original code, but if you use someone else's code, give credit.
  • Explain why Python provides the types it provides (Python does this for you - just put it in your own words, using your own experiences - try to make sense of it from your own level of understanding.)
• Look at the reflective questions, and keep notes related to those questions as you go.
• A core data type concept in Python is mutability vs. immutability of objects. Keep notes as you go relating to how mutability and immutability affect the design of Python's type system.

Reflective questions (answer in the lab report):

1. Another core concept in Python is that everything is an object. How do you think that affected the design Python's data type system as a whole?
2. Do you think mutability/immutability is really confusing? When does a new Python programmer need to know about the concept. How would you explain it?
3. What new information did you learn about types in the programming languages you already know? How will you use the information in your software practice in the future?

See sample lab report

Lab 2: Integrating scanners and parse trees

With this lab, we'll take another step towards a formal exploratory lab structure, by defining 'learning objectives', or what the lab is trying to help you explore -

learning objectives:

• explore perl syntax more deeply, especially string interpolation
• practice constructing FSAs in the context of a real programming language
• practice constructing parse trees in the context of a real programming language
• start to develop an intuitive understanding of the role of scanners in parsing programs
• start to develop an understanding, any understanding, intuitive or otherwise, of the role of CFGs in PL design
• integrate your possibly shaky understanding of bindings, scope, lifetime and referencing environments with your new knowledge of how programs are scanned and parsed to start to build an internal scaffold - an internal model of a parsed program

Methods:

1. Read Hilary's quick-and-dirty intro to string interpolation in perl (coming at 3pm-ish on Thursday)
2. Make a first pass at an FSA or multiple FSAs for the tokens involved in string interpolation
3. Don't forget to keep notes related to the learning objectives above
4. Modify your FSA(s) based on any insights from reflection
5. Read through the precendence and associativity information on perdoc as well as Hilary's quick-and-dirty intro to parse trees in perl (coming 3pm-ish)
6. Build some parse trees for some of the sentences they give in the perldoc section on string interpolation
7. Make some more notes related to the learning objectives above
8. Modify your FSA(s) and or parse trees based on the insights
9. Make up some sentences of your own, and build the parse trees for the sentences.
10. More notes, mods, etc., as necessary
11. Make up a whole string (yes, you may use the existing sentences that you made up). Tell me how the whole string would be parsed. If you are feeling really confident (and I think you will be, give me the parse tree for the whole string.)
12. Use your string in a perl assignment statement - you can make this up, or you are welcome to use one of the examples from the perldoc site.
    • as you work through these steps, keep notes related to the learning objectives, especially the integration objective
    1. Give me the parse tree for your statement (you do have to, but you don't have to break the string itself out - you may consider it a terminal node).
    2. Show how your FSA recognizes the name of any object in the assignment statement (in other words, run the FSA by hand, as it were...)
    3. Give a compile time binding for some object in your statement (you can change objects for each of these steps, or stay with the same one, whichever you find teaches you more, is more interesting, works better, makes you happy, ...)
    4. Give a run-time binding for some object in your statement
    5. What is the scope of your object?
    6. What is the lifetime of your object?
    7. What is the referencing environment for your object?

See sample lab report

Lab 1:Exploration 3.26

It turns out I really like exploration 3.26 from the book! So, find 2 or 3 lab partners, and do exploration 3.26 (page 157) from the book, following the lab format explained in info on labs. Some comments and hints to get you started:

• You and your lab partners can each work on the same language, or you can choose different languages - both approaches will work equally well (really!)
• Make sure you read the instructions in info on labs!
• Look up any terms you are unfamiliar with, and include the definitions in your lab report (make sure you credit the source of the definition.) If you add the vocabulary word to your vocabulary list, you'll make progress on the vocab extra credit assignment, as well!
• Record your observations and reactions at the moment you have them, otherwise you'll loose them. It takes training and practice to capture those and express them, and it's a valuable industrial skill.

The lab is due next Thursday, May 1st. I'll give you a bit of time to work on the lab in class on Tuesday.

Lab 0: Applying bindings

We'll do this assignment in stages:

• a first attempt before class on 4/17, during which time you are encourage to collaborate but do not have official teams, and have not had any orientation in perl.
• in class on 4/17, in teams, and during which time you'll have the opportunity to ask questions about perl
• finally, finishing up with your teams and turning it in before class on 4/22.

On my perl resources page, there are sections of links to information concerning how perl handles names and scope. Working through the documentation referenced in the links (which has lots of detailed examples), find and analyze at least one binding for each class of binding times listed in More on bindings with the exception of a language implementation time binding. Language implementation time bindings are hard (although far from impossible) to find in languages like perl. If you want to try to find a language implementation time binding, go ahead. If you are right, I'll give you extra credit.

You may find some of the material from Chapter 2 helpful in analyzing bindings, particularly 2.1 and 2.2. Students learn the material in 2.1 and 2.2 best when they can apply it, so we'll play with it in class on Thursday and start weaving it into our Chapter 3 material as we go.