Page History

...

If this is the first time you've run DrRacket, it will ask you your preferred language, and the Scheme language level; the latter should be "Beginning Student with List Abbreviations". This language level provides the expected set of primitive operations and enables DrRacket to reject "legal" Scheme constructions that are not part of our introductory dialect.  Read the DrRacket Tips and Traps  page for helpful information on common mistakes, error messages, etc.

...

The DrRacket window is divided into two halves. The lower half, or interaction window, is the Scheme "calculator". The top half, or definition window is just a text editor which is smart about indenting Scheme, and such. The execute button sends the contents of the definition window down to the interaction window, where they are actually evaluated.

...

DrRacket has lots of other features, including a complete manual. We'll explore more of DrRacket in later labs, and we encourage you to explore, but there's no need to learn all its features. Read the DrScheme Tips and Traps page for helpful information on common mistakes, error messages, etc. 

Enabling Linux to open .ss files with DrRacket: 

1. Right-click any .ss file and select "Properties".
2. Switch to the "Open With" tab.  If DrRacket already appears as a choice, be sure that it is selected,  otherwise
   1. Click the "Add" button.
   2. In the dialog box that appears, scroll down and select "DrRacket" and click "Add".
   3. DrRacket should now appear on the list of available programs. Be sure that the radio button for DrRcket is selected.
3. Click "Close".
4. Double-clicking any .ss file will now open it with DrRacket.   You will need to run it once to get the Interactions window to appear or click "Show Interactions Window" from the "View" menu.

...

Step-by-Step-by-step Evaluation

While DrRacket evaluates our Scheme programs for us, it is also important for us to understand the process of evaluation. The details of evaluation will be covered in class. Here in lab, we want to explore two useful tools to help us:

...

1. Write the function's contract, purpose, and header. The contract specifies the function name and what kind of values the function will use as input and output. The purpose is a short statement describing what (not how) the function will calculate. The header is the part of the function definition specifying the function and parameter names. Type these in the definition window. Put the contract and purpose in comments, as in the following examples:

   Code Block
   ;; contract: ;; owe : nat -> num ;; ;; purpose: ;; (owe n) returns how much money you owe for eating n pizza slices. ;; ;; header: ;; (define (owe slices) ...)

   We won't use DrRacketto verify that our contracts are correct, although that is a very useful thing to do. Look for that in COMP 212.
2. Make some examples of what the function should compute. You need to make sure you understand what the function is supposed to do before you define it. When applicable, use some of the example data. We recommend the following form for these examples:

   Code Block
   ;; Examples: ;; (owe 0) => 0 ;; (owe 10) => 15

   The first line provides an explanation of the following, making it more readable. (We haven't introduced symbols yet officially -- we will see them in class soon.) The next two lines each give an example, asking DrRacketto compare (with the numeric equality function =) the actual result with the expected result. You should pick enough examples to test the function adequately. We'll say more about that later, but this should include any interesting inputs like zero.
3. Test the function. i.e., make sure the previous examples really work. If you wrote the examples as suggested above, you can use them to test the function. Add a test section after your examples, like this:

   Code Block
   ;; Tests: (check-expect (owe 0) 0) (check-expect (owe 10) 15)

   All of these tests should pass , assuming that the code for owe is correct. The more elaborate your test, the more errors you'll catch sooner and the less time it will take to write a correct function. Note that at this point owe has not been written yet. Still we write the test code first! This is one of the key steps in modern software development: test before coding. It is called test-driven development. This is where we deviate from the design recipe describe in HTDP (the textbook). We write the test code first!
4. Write the function body. Soon, we will have lots to say about this step. For now, for programs on "unstructured" data, this is very straightforward, because we are typically given an equation like …

   Code Block
   ;; definition: (define (owe slices) (* (/ 12 8) slices))

   For sets of intervals or other conditional functions, there should be exactly one condition clause per option.

...