[plt-scheme] Question result is not true or false: (void)
Grem, you are jumping all over the place with your speculations and
comments.
PLT Scheme's _and_ (which isn't a function, not even in Ikarus)
supports the kind of sequencing that the OP requests. It's **other**
languages supported in DrScheme that don't.
The very fact that anyone starts with I/O for program design is
serious grounds for doubts. Nobody can truly succeed that way. So all
the other comments are right on.
-- Matthias
On Dec 29, 2009, at 10:53 AM, Gregory Marton wrote:
>> 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")
> (newline))
>
> 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!
>
> Grem
>
>
>> 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!
> ~~~~~~~~~~~~~~~~-~~~~~~~~_~~~_~~~~~v~~~~^^^^~~~~~--~~~~~~~~~~~~~~~+
> +~~~~~~~
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme