Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!spool.mu.edu!olivea!decwrl!decwrl!waikato!canterbury.ac.nz!huia!greg
From: greg@huia.canterbury.ac.nz (Greg Ewing)
Subject: Re: Let's design a better language
Message-ID: <CFsCC6.39L@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:  <CFn0GA.GoA@cantua.canterbury.ac.nz> <CFn4HF.4wr@news.cis.umn.edu>
Date: Sun, 31 Oct 1993 23:38:30 GMT
Lines: 31

In article <CFn4HF.4wr@news.cis.umn.edu>, TPro0001@tebbs.mn.org writes:

|> <grin>  I'm using it.  I'm currently working on an adventure design
|> language.

Could you give us a glimpse of what your language looks like?

|> You refer to each one with array-like syntax, ie. 
|> "dungeon.orc[1], dungeon.orc[2]", etc.

Hmmm... how does the *player* refer to different instances of the
same object?

I have a friend who once wanted to implement a horse racing scenario
where you placed bets and got issued with tickets. To disambiguate
them I suggested that each ticket have a unique serial number.
There were two problems: (1) TADS has no way of dynamically
creating objects; (2) there's no obvious way of getting the parser to
understand things like "cash in ticket 1723".

So, two more things I want in my language are:

(a) Dynamic object creation

(b) A much more flexible parser

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	   +--------------------------------------+

