Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!usc!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: <CGIAHM.L7M@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: <)> <2bqtv5INN81f@life.ai.mit.edu> <CGAuqF.42C@cantua.canterbury.ac.nz>) <2bu79dINN5bc@life.ai.mit.edu>
Date: Sun, 14 Nov 1993 23:56:10 GMT
Lines: 57

In article <2bu79dINN5bc@life.ai.mit.edu>, dmb@min.ai.mit.edu (David
Baggett) writes:
|>  By all means, work on new
|> designs.  I just think that leaving out extensibilty would be a mistake.

Agreed! Many people seem to have got the impression that I am
considering a non-extensible system.

To make myself clearer: I agree that extensibility and
customisability are very desirable, even vital. 

But I don't want to lose those things about Alan which makes
it an adventure language, and not just an adventure library.

Somehow I want to steer a middle course between them.

|> - programmer-extensible parsing:

I have two mutually incompatible views in this area. If you
think that the player input language should be a natural-language
interface, then it makes sense to have the parser as flexible
as possible.

However, I'm not convinced that elaborate input languages are
a good idea, since they can lead to frustrating guess-the-verb
type puzzles. So the other half of my brain favours keeping the
parser as simple as possible, and not even assuming that there
will be a parser at all - a version of the run-time system
might present a menu-oriented interface instead, for example.

What do other people think?

|> Agreed.  But that said, I'm actually surprised at how few class modules
|> have been written for TADS.  Seems like everyone rolls their own stuff but
|> few people release their code.

Probably because most home-grown code is built to do the job at
hand, and isn't flexible or robust enough to be generally useful.

Another reason could be that the lack of documentation of adv.t
internals makes it impossible to write an extension with any
confidence that it won't break with the next release of Tads.

This seems to be a very serious problem which would severely
discourage anyone putting in the considerable effort needed
to create a general and useful extension.

|> 
|> Dave Baggett
|> __
|> dmb@ai.mit.edu            Boot up, log in, drop out.             MIT
AI Lab    

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