Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!waikato!canterbury.ac.nz!huia!greg
From: greg@huia.canterbury.ac.nz (Greg Ewing)
Subject: Re: Design of a New Language: 2
Message-ID: <CGAst4.13s@cantua.canterbury.ac.nz>
Nntp-Posting-Host: huia.canterbury.ac.nz
Reply-To: greg@huia.canterbury.ac.nz (Greg Ewing)
Organization: University of Canterbury, Christchurch, New Zealand
References: <CG96Mq.1xs@cantua.canterbury.ac.nz> <2bpjfd$6t8@agate.berkeley.edu>
Date: Wed, 10 Nov 1993 22:51:03 GMT
Lines: 58

In article <2bpjfd$6t8@agate.berkeley.edu>, whizzard@uclink.berkeley.edu
(Gerry Kevin Wilson) writes:
|>  Your program
|> should be more of a programming language than a game.

We seem to have differing tastes here. I would like writing an IF game to
be more like writing a story than writing a program. I want to be able
to program when necessary, but I don't want to have to think in programming
mode all the time.

|> I really enjoy TADS for its flexibility and pseudo-C code.  I don't have to
|> learn a new language to use it.

Well, seems to me that Tads is sufficiently un-C-like that you *do* have to
learn a new language to use it. I suppose it depends on how many languages
you've had prior exposure to. If you've only ever seen C before, it would
be easier to get into Tads than, say, AdvSys. Lisp, vice versa. Cobol
would prepare you for Alan, etc.

If you're like me and you've used every language ever invented, it won't
matter much.

But all this is largely irrelevant. I want to design a language for writing
adventures, without any bias towards existing programming languages.
The language should be designed for its purpose.

|> Also, sound.  Support sound as much as will port from machine to machine.

Which is probably none :-(. Reasonable idea, though.

|> Make a gif-title loader that can be easily ported from machine to machine.

This too. Things to file away for later - not really fundamental.

|> And finally, don't muck around with
|> too many verification calls.  Let the user put it into the verb or what have
|> you.

The idea of separating them is so that *all* the verification is done before
*any* of the actions occur. It seems to be a good design to me. I don't much
like the way it's implemented it Tads, either, but that doesn't mean it's
a bad idea. In Alan you say things like:

	VERB take DOES
		CHECK object IS NOT hot
			ELSE "It's so hot that you drop it."
		DOES
			LOCATE object IN inventory.

which seems perfectly clear and straightforward to me. Would you like to
see it done differently? I'm open to suggestions.

|> *===                              whizzard@uclink.berkeley.edu        ===*

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of Japan Inc.|
greg@cosc.canterbury.ac.nz	   +--------------------------------------+
