Newsgroups: rec.arts.int-fiction
Path: gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!csulb.edu!csus.edu!netcom.com!whitten
From: whitten@netcom.com (David Whitten)
Subject: Re: syntax ideas for authoring system?
Message-ID: <whittenCLK7HL.IIL@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <DJOHNSON.94Feb19003402@arnold.ucsd.edu>
Date: Mon, 21 Feb 1994 05:34:32 GMT
Lines: 144

Darin Johnson (djohnson@arnold.ucsd.edu) wrote:
: I'm working, yet again, on an authoring system I've been thinking
: about for awhile.  Eventually, it may end up as a mud system, but
: for right now I'll work on a text adventure system instead.  So
: I wanted to pass this by the people who actually use these things
: the most for feedback.

: Anyway, I'm getting a headache thinking about how to do the syntax.
: I really don't want it to look too much like an existing system
: if it can be avoided.

: My basic model derives from from infocom, moo, seaslug (obscure),
: and other property based ideas, with multiple inheritance.  Objects
: are just a collection of properties and a list of parent objects.
: Expressing this in a simple, easy to understand, and not too verbose
: syntax ends up looking a lot like a massaged TADS, and for obvious
: reasons, I don't want to look too much like a copyrighted language.

: Anyway, here's some of the styles I've been poking at.  Goals
: are to reduce verbiage and have a coherent and consistent scheme
: for defining objects/functions/classes/variables/properties.

: 1) vaguely SML like

:   object thing =     	-- no parent classes
:      short : "a thing"	-- property 'short' set to "a thing"
:   end

:   object coat : wearable, container =	-- has 2 parent classes
:      short "an overcoat"
:   end

:   Trouble here is it's a bit verbose.  Using brackets is probably
:   nicer and improves readability/familiarity, and makes emacs happy.

: 2) revised - vaguely C++ like

:   object thing {
:      short : "a thing"
:   }

:   object coat : wearable, container {
:      short "an overcoat"
:   }

:   Advantage is you can replace 'object' with 'class', 'function',
:   'global', etc, giving everything an overall syntax of:
:   <category> <name> [ : <category-specifiers> ] <body>

:   global version : "1.1"       -- semicolon at end?

:   function moveit : src, dst {
:      src.loc = dst;
:   }

:   But, it would be more readable, IMHO, to have the thing being
:   defined as first to appear.

: 3)

:   coat : object wearable, container {
:     ...
:   }

:   or, perhaps

:   coat : object(wearable, container) {
:      ...
:   }

:   The first seems a bit odd, the second is nicer, but rubs me wrong.
:   If we want a class instead (I'm debating putting in differentiation
:   between classes/objects), we can put 'class' as the first word,
:   or other flags.

:   To reduce verbiage, getting rid of the 'object' is simple, but then
:   we end up looking like twisted TADS,

: 4)
:   
:   class thing {     -- defaults to object, but could perhaps require it
:   }

:   coat : wearable, container {
:      prop : val;
:      prop : val;
:   }  

:   Other ideas that have come up:

: 5) LISP syntax

:   (object coat (wearable container)
:      (prop val)
:      (prop val))

:   Advantage is that verbiage is low, cleans up syntax for expressions,
:   but could deceive people into thinking we have lisp like semantics,
:   or scare off novice programmers.

: 6)

:   object coat (wearable, container) {
:      blah : blah;
:   }

:   Deceptive in that it looks a lot like a C function definition.

: Anyway, comments/ideas?  Anything radically different?

: I was thinking of not using braces to combine statements, but I'm
: slowly changing my mind.  (I was going to have { ... } be similar
: to an executable block in Smalltalk, or a closure in Scheme, but
: I could use #{ ... } or something)
: --
: Darin Johnson
: djohnson@ucsd.edu  --  Toy cows in Africa


how about:

coat "an overcoat"
     isa object
     isa wearable
     isa container  
     with features
	color typeis colorlist
	color := red 
	state typeis (init,dropped,destroyed)
	state .= init
	location typeis room
	location := {if state == init then room bedroom
		    elseif state == dropped then THERE
		    else LIMBO }

     end features

I guess I'm saying, you may get further using more 'commandlike' keywords,
than just assuming the reader knows the grammar.
 
I'm intrigued by one thing though, I wonder what power you would get coding
I-F in a Mud-type language like MOO instead of an IF language like TADS...

Dave Whitten
