Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!midway!quads.uchicago.edu!goer
From: goer@quads.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.lang.icon
Subject: Re: Draw Poker Game
Message-ID: <1990Dec15.192120.1009@midway.uchicago.edu>
Date: 15 Dec 90 19:21:20 GMT
References: <67EEF267C0600950@mis.mcw.edu>
Sender: news@midway.uchicago.edu (News Administrator)
Distribution: inet
Organization: University of Chicago
Lines: 73

In article <67EEF267C0600950@mis.mcw.edu>
TENAGLIA@mis.mcw.edu (Chris Tenaglia - 257-8765) writes:

>global money, message
>procedure main(param)
>  money := integer(param[1]) | 3
>  write("\e[2J\e[2H          \e#3\e[1;7mDRAW : Nothing Wild\e[m")
          ^^^^^^^^^^          ^^^^^^^^^^^^                  ^^^^^

I love to try to port people's things to Unix, but it's sometimes
pretty hard.  The code above is part of a really neat game, and I
like it a lot.  But unless a person happens to know ANSI escape se-
quences like the back of his or her hand, it's kinda hard to know
what is going on.  It's also a fact that most ANSI terminals don't
really implement the full, exact ANSI standard, and in general peo-
ple (at least here at the U of Chicago) are using Wyse, Televideo,
or VT-100 terminals (or emulators).

It's hard to say this, especially when the code is otherwise so clear
and clean, but my own personal observation is that code which assumes
hard-coded screen control 1) is hard to read, 2) is harder to main-
tain, and 3) is very tedious to port.

One solution (the one used in the klondike game) is to make all the
screen control sequences into global variables, and put them together
in one place, so they can easily be altered.  If the global variables
are mnemonic, this solves 1 and 2, but leaves 3 still up in the air.
(I've written a lot of code that has all three problems, so don't
take this as a flame.)  The workability of the "klondike" solution is
evinced by the fact that I was able to port it to Unix in a very short
period of time and repost.  I admit that the repost was something of a
hack.  When the next klondike version comes out I'll do a more serious
job.  The mnemonic global variables really helped.

Another solution is to isolate screen control sequences in a single
procedure, which would be called mnemonically.  This solution is not
perfect, because it is not always as easy to read as the "klondike"
solution.  But is does make maintenance a snap, and leaves would-be
port-ers with very little work to do.  I'll give a little example
below that will show how things can be done this way, and yet kept
readable:

>  write("\e[2J\e[2H          \e#3\e[1;7mDRAW : Nothing Wild\e[m")

   output("clear")
   output("goto",1,2)
   writes("          ")
   output(whatever \e#3 does)
   output("bold-reverse")  # or output("bold"); output("reverse") ???
   write("DRAW : Nothing Wild")
   output("normal")

By doing things this way, even someone who doesn't know the least bit
about ANSI screen codes will be able to understand what is going on.
What is more, no changes will be required if, say, some escape sequence
needs to be changed.  In fact, one could insert codes for a _whole dif-
ferent terminal_ and it wouldn't require changing a single scratch of
the above code.  All changes would be isolated within the output pro-
cedure.

I admit that things are more bulky this way.  But you don't have to have
your ANSI chart out while programming.  And in fact, you don't even have
to think about what sort of terminal you're using.  Nor does anyone else
who reads your code.  The sequence output("clear") is infinitely more
clear, portable, and maintainable than "\e[2J"!

One more bit that might be useful to inject here:  Most terminals can han-
dle 24 lines of text.  Not all can handle 25.  To hit the majority of
users, keep screen I/O within a range of 24 lines.

I hope that this will help, and not seem like a gratuitous flame!

-Richard