Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!caen!batcomputer!munnari.oz.au!bruce.cs.monash.edu.au!labtam!news
From: philip@labtam.oz.au (Philip Stephens)
Subject: Re: Design of a New Language: 2
Reply-To: philip@labtam.oz.au
Organization: Labtam Australia Pty. Ltd.
Date: Wed, 10 Nov 1993 03:57:23 GMT
Message-ID: <1993Nov10.035723.28537@labtam.labtam.oz.au>
References: <CG96Mq.1xs@cantua.canterbury.ac.nz>
Sender: news@labtam.labtam.oz.au (Net News Administrator)
Lines: 86

Greg Ewing writes:

>The first question I need to settle is: should it be Alan-like or Tads-like?
>I'm not talking about details of syntax here, but about what the underlying
>model is like. 

  Flexibility and extensibility is important; however, from what I've seen of
TADS, it relies far too much on library support to implement even the most
basic of IF concepts.  This is a disadvantage, IMHO, not so much because it
requires a large library to run, but because it forces programmers to extend
that library on a frequent basis in order to achieve what they want.  Witness
the continual stream of TADS related articles for improving on the standard
library.
  In comparison, Alan has quite a good range of inbuilt features, but as you
say it is too inflexible to be generally useful.  As I see it, there is a great
need for an IF language that can provide a balance between in-built features
and extensibility.

  I've been thinking about what ought to be present in an IF language myself
lately, and here's a few ideas I've come up with:

  1. Implement an improved parser that recognises more complex noun phrases,
     particularly in respect to specifying pluralism i.e. specifying exact
     and approximate quantities of things, with or without units of
     measurement. 

     e.g. take one of the matches.
          pour some water.
          pour 5 litres of water into the bucket.

     Also add support for multiple adverbial phrases.

     e.g. pour some water from the bucket into the sink.
          write my name in the book using the pencil.

  2. Provide in-built support for modelling different kinds of objects, such
     as solids, liquids, gases and particles.  In other words, while we need
     to be able to extend the properties of an object to implement unusual
     features, the more inbuilt properties that are recognised (such as size,
     weight, dimensionsi, quantity and so on), the better.

     This is particular relevant in combination with parser design: the parser
     should have enough intelligence to be able to determine the visibility
     and available of objects given in a sentence, for instance, which means
     that concepts such as visibility and availability should be in-built
     constructs of the language.

  3. Allow the definition of object classes, and the ability to create and
     destroy objects dynamically.

>Does anyone out there think that static type checking would be too severe a
>restriction on their creativity?

  As long as the syntax allows the casting of one type to another, as in C,
then I'd be in favour of some compile-time type checking.

>This is supposed to be a *language for writing adventures*, so it makes sense
>to include constructs designed specifically for adventures. At the same time,
>more general facilities need to be available.

  I agree 100%.

>Currently I seem to be favouring something rather more Alan-like than
>Tads-like. In fact I am thinking of starting with Alan and using it as
>a base to experiment with extensions and generalisations.

  Are you looking for partners to help you develop this system?  I've been
tossing up whether to embark on such a project, and your ideas seem to be
along the lines of what I was considering.

>Since the source of the Alan system is not available, this will require
>re-implementing it from scratch. Before I go to that much effort, I'd like
>to hear if anyone has any alternative suggestions.

  Even if you were to start with available source from such IF systems as
ADL, you wouldn't be able to use it in your own product without first getting
permission from the authors, I don't think.  But it may be worth contacting
the authors to find out.



--
| Philip Stephens, Systems Programmer. | "Many views yield the truth.         |
| Address:  43 Malcolm Road, Braeside, |  Therefore, be not alone."           |
|           Victoria, 3195, AUSTRALIA. |                                      |
| Internet: philip@labtam.labtam.oz.au |    -- Prime Song of the Viggies      | 
