[racket] Is this a good design

From: David Van Horn (dvanhorn at ccs.neu.edu)
Date: Wed Feb 29 15:10:28 EST 2012

On 2/29/12 2:42 PM, Roelof Wobben wrote:
>  >> A couple of comments:
>  >>
>  >> * `string-first` (- instead of the _) is a more idiomatic naming
> Oke, changed that.
>  >> * (eq? (string? s) true) is >> verbose. (string? s) already returns
> a boolean.
> I changed that , thanks for the tip.
> * Generally, when writing programs using the design recipe you don't
> need to think of the error cases (e.g., when the contract is violated)
> like `s` not being a string. You may want to think of some edge cases
> though (how long can a string be?).
> I know I can check on empty strings but the exercise says that I don't
> have to consider empty strings.
> That's why I did not check on that.
> With all the remarks I changed the function to this :
> ;String -> String
> ;This function takes out the first character of a given string with the
> name s
> ; given "roelof" expect "r"
> ; given "example" expect "e"
> (define (string-first s)
> (if (string? s)
> (string-ith s 0 )
> "You have not entered a string"))

You ignored part of what Asumu said, which (to paraphrase) is that your 
program should live and die by its contract.  When you write down:

    String -> String

you're saying this program consumes a String and produces a String.  If 
somebody applies your program to something that is *not* a string, they 
(not you) messed up by not using your program according to the contract 
you wrote down.  When somebody misuses the program, who knows what 
happens.  Maybe it signals an error, maybe it produces 7, maybe it melts 
your computer.  So don't bother checking that the input is a String; 
assume it is.  Let bad stuff happen if it isn't.

On the other hand, if somebody applies your program to a string and you 
produce something other than a string, well that's your fault; you 
messed up.  So make sure you produce strings (on the assumption you're 
given a string).

Asumu also pointed out the corner case of the empty string, which you 
responded to by saying you can assume the string is not empty.  That's 
fine, but *write it down*.  How are we to know, as reader's of your 
contract and purpose statements, that we have to provide non-empty strings?


Posted on the users mailing list.