How To Code: Simple Data

Question 1

How to Design Functions (HtDF) recipe

Answer 1

Signature, purpose, stub
Examples (wrapped in check-expect)
Inventory - template and constants
Code body
Test and debug

Question 2

HtDF - Signature

Answer 2

Declares what type of data a function consumes and produces

Type … -> Type

Question 3

HtDF - Purpose

Answer 3

1 line description of what the function produces in terms of what it consumes
Example:
//produce 2 times the given number

Question 4

HtDF - Stub

Answer 4

A function definition that:
- Has correct name
- Has correct number of parameters
- Produces a dummy result of correct type
Example:
// Number -> Number (signature)
// (define (double_function n) 0)

Question 5

HtDF - Examples/Tests

Answer 5

Tests help us understand what a function must do
Multiple tests illustrate behaviour
Tests must be run to make sure the tests are well formed (tests should run but fail, thanks to the ‘stub’)

Question 6

HtDF - Template

Answer 6

A function with a ‘template’ for its behaviour. Think pseudo-code
Example:
(define (double_function n)
(… n))

Question 7

HtDF - Code Body

Answer 7

The function behaviour
Use everything written before to know how to complete the function body
Sometimes helps to elaborate the examples/tests to show how the expected value could have been produced

Question 8

HtDF - Test and Debug

Answer 8

Run the tests!

Question 9

True or False - The HtDF recipe should be followed in a waterfall style, strict order

Answer 9

False, the HtDF is a flexible process
Steps can be skipped if not sure which are the correct values/definitions
Also previous steps can be edited/ammended if we realize they were not correct when developing later steps

Question 10

HtDD Recipe

Answer 10

The first step of the recipe is to identify the INHERENT STRUCTURE of the information.

Once that is done, a data definition consists of four or five elements:

1 - A STRUCTURE DEFINITION (if needed)
2- A TYPE NAME DEFINITION, to describe how to form data of that type.
3- An INTERPRETATION that describes the correspondence between info and data.
4- EXAMPLES of the data.
5- A TEMPLATE for a 1 argument function operating on data of this type.

Question 11

Inherent Data Structure = Atomic

Answer 11

Data Definition = Simple Atomic Data

Question 12

Inherent Data Structure = numbers within a range

Answer 12

Data Definition = Interval

Question 13

Inherent Data Structure = fixed number of distinct items

Answer 13

Data Definition = Enumeration

Question 14

Inherent Data Strcture = 2 or more subclasses, at least 1 is not a distinct item

Answer 14

Data Definition = Itemization

Question 15

Inherent Data Structure = items that naturally belong together

Answer 15

Data Definition = Compound Data

Question 16

Inherent Data Structure = naturally composed of different parts

Answer 16

Data Definition = references to other defined type

Question 17

Inherent Data Structure = arbitrary/unknown size

Answer 17

Data Structure = self-referential or mutually referencial

Question 18

HtDD - Simple Atomic Data

Answer 18

the information to be represented is atomic (can’t be divided in more parts)

Example: time, names…

Question 19

HtDD - Intervals

Answer 19

Use an interval when the information to be represented is numbers within a certain range. ‘[’ and ‘]’ mean that the end of the interval includes the end point; ( and ) mean that the end of the interval does not include the end point.

Question 20

HtDD - Intervals: Tests

Answer 20

Be sure to test closed boundaries as well as midpoints.

Question 21

HtDD - Enumerations

Answer 21

The information to be represented consists of a fixed number of distinct items

Question 22

HtDD - Enumerations: Tests

Answer 22

At least as many tests as there are cases in the enumeration

Question 23

HtDD - Itemization

Answer 23

Data comprised of 2 or more subclasses, at least one of which is not a distinct item.

Question 24

HtDD - Itemization: Tests

Answer 24

At least as many tests as there are cases in the itemization.

Question 25

How important is designing data in designing programs?

Answer 25

Designing data is a very high point of leverage for designing programs.
There are some programs for which that’s less true.
But for a very many programs this approach

Question 26

What is the ‘!!!’ marker used for?

Answer 26

The ‘!!!’ marker in stubs makes it easy to find pending wishes

Question 27

What is a wishlist?

Answer 27

A signature comment, a purpose and a stub (marked with a ‘!!!’)

Question 28

HtDW - Domain Analysis

Answer 28

• Sketch program scenarios
• Identify constant information
• Identify changing information
• Identify big-bang options

Question 29

HtDW - Build the program

Answer 29

• Constants (based on domain constants)
• Data definitions using HtDD (based on
  domain ‘changing information’)
• Functions using HtDF
  
  • main first (based on ‘changing information’,
    big-bang options and data definitions)
  • wish lists entries for big-bang handlers
• Work through wish list until done

Question 30

HtDW - Recipe

Answer 30

Domain Analysis (best on paper)
Build the program (based on the analysis)

Question 31

HtDD - Compound

Answer 31

Consists of 2 or more items that naturally fit together

Question 32

HtDD - Compound: Test

Answer 32

All selectors -> (… (firework-X fw)
(firework-Y fw) )

Inside cond –> predicate (firework?)

Question 33

Well formed self-reference

Answer 33

At least one base case (with no self-reference)
At least one self reference case

(there can be more than one of each)

Question 34

Self-reference: Tests

Answer 34

Test should include all base and self-referencial cases

Question 35

Self-reference: When to use?

Answer 35

For arbitrary sized data