[plt-scheme] Question result is not true or false: (void)

From: Gregory Marton (gremio at acm.org)
Date: Tue Dec 29 10:53:14 EST 2009

> In answer to your specific question, "question result is not true or false" 
> is because you're using "and" or "cond" on the result of "display", which HAS 
> no result.

Good, but it doesn't look at why he was trying to do that.

> The fact that you're asking questions about the result of "display" indicates 
> a more fundamental issue: how do you represent a Sudoku board?

That's a pretty big leap.

He said (and (display stuff) (newline)) to indicate that he wanted both of 
these to get done.  They both have side effects and no return value, and let's 
give him the benefit of the doubt on understanding that.

The and function could do this.  It could be a fine way to do things for and to 
try to evaluate both of its arguments, try to coerce their non-existant results 
to a boolean, and keep going happily along.  I'm glad PLT doesn't do this, but 
it's a possible way to proceed.

What this reader doesn't know is the right word in the PLT vocabulary for "do 
this thing first, then do this other thing, and I don't care about the results 
because they don't exist anyway".  He's probably coming from an imperative 
language, and grasping for something like
   (begin (display "foo")

You all are quite right, of course, that thinking about representation will 
help him eventually, but it'll never get and to do begin's job, and whatever 
other problems you may see with his code, he's not to be faulted
for not knowing enough of PLT's vocabulary, or for presuming that and might do 
the trick: in other Schemes, (e.g., Guile, Ikarus) it does!


> On Dec 27, 2009, at 12:51 PM, Jayto wrote:
>> I am trying to design a sudokku game in dr scheme, but it is proving
>> difficult.
>> First what I did was draw out the game with this code:
> There's your problem: you started thinking about I/O FIRST, rather than LAST.
> What are the important questions to ask about a Sudoku board?  "What, if 
> anything, is in this position?"  "Does this board violate any constraints?" 
> "Could I put this value into this position without violating any 
> constraints?"  Things like that.  Oh, and "draw the board" too -- but that's 
> probably the least-interesting one.
> Next, you need to choose an internal representation, from which it should be 
> reasonably easy to answer all of the above questions.  Test your 
> representation and the basic functions that operate on it.  Note that in 
> Scheme, you CAN test these functions without worrying about I/O first, 
> because whatever you choose as an internal representation, Scheme will 
> probably have SOME readable representation for it -- not spiffy graphics, but 
> enough that you can tell whether the answers are right.
> Then figure out how to identify legal vs. illegal moves, fill in a number, 
> and all that stuff.  Test these functions, again without worrying about 
> visual formatting.
> Once you have all this stuff working, THEN you can write a "draw" function 
> that converts an internal representation into an attractive graphical 
> representation.  And you can write functions to handle user input, and all 
> that stuff.  But the user interface really should be separate from the rules 
> of the game (go look up "model-view separation", which governs how almost all 
> modern GUI-based programs are written).
> Stephen Bloch
> sbloch at adelphi.edu_________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

------ __@   Gregory A. Marton                 http://csail.mit.edu/~gremio
--- _`\<,_                                                     617-775-3005
-- (*)/ (*)        Basically it's hopeless, but there's always hope!

Posted on the users mailing list.