Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!spool.mu.edu!umn.edu!news
From: TPro0001@tebbs.mn.org
Subject: Re: Let's design a better language
Message-ID: <CFspG2.Dss@news2.cis.umn.edu>
Sender: news@news2.cis.umn.edu (Usenet News Administration)
Nntp-Posting-Host: gold1.tc.umn.edu
Organization: University of Minnesota, Twin Cities
References:  <CFsCC6.39L@cantua.canterbury.ac.nz>
Date: Mon, 1 Nov 1993 04:17:44 GMT
Lines: 63

In article  <CFsCC6.39L@cantua.canterbury.ac.nz> 
greg@huia.canterbury.ac.nz (Greg Ewing) 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?
> 
Well, it's quite likely to change as it evolves.  As it stands now, I'm 
only in the early stages of writing it.  But for now it uses a LISP-ish 
syntax, supports object oriented programming using a "single-heirarchy" 
system (ie. it's classless: there are no classes, only objects, and any 
object can inherit (thru delegation) methods or properties from any 
other object or objects (for multiple inheritance)).

> |> 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?
> 
The user would type "attack orc 2" or "attack the second orc", whichever 
he or she prefers.  As it stands now, it supports adjectives "first",
"second", etc..., "twelfth".  I figure a dozen is as many identical 
objects as I'm likely to put in one place.

> 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;
Really?  I've never used TADS, but I can't imagine writing a game 
without dynamic creation of objects.  But them I'm looking at things 
from the point of view of the multi-user real time approach (ie. MUD 
like adventuring).  You NEED to be able to create and destroy things on 
the fly -- even write new scripts (methods) on the fly.

> (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
> 
Amen.  The script writer needs to be able to handle the user typing 
*anything* that he or she wants to handle.  If the language can't handle 
it, it should just pass what it can't handle to the script for any 
special programming you might want to include.  Nobody can think of 
everything in advance, and your script writing language must liberate 
you, not limit you.

> Greg Ewing, Computer Science Dept, > 
+--------------------------------------+
> University of Canterbury,          | A citizen of NewZealandCorp, a
> Christchurch, New Zealand          | wholly-owned subsidiary of Japan 
> greg@cosc.canterbury.ac.nz         > 
+--------------------------------------+
> 
------------------------------------------------------------------------
Guy T. Rice            |  "Out of every life a little blood must spill."
TPro0001@tebbs.mn.org  |     -- Prince Corwin of Amber

