Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!news.ruhr-uni-bochum.de!news.rwth-aachen.de!uni-paderborn.de!fu-berlin.de!main.Germany.EU.net!mcsun!EU.net!howland.erols.net!netcom.com!erkyrath
From: erkyrath@netcom.com (Andrew Plotkin)
Subject: Re: [Inform 5.5] <BIG> What's the story with parse_name?
Message-ID: <erkyrathDx6G4n.n2n@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
X-Newsreader: TIN [version 1.2 PL1]
References: <50i1sn$4k@news.dx.net>
Date: Tue, 3 Sep 1996 22:07:34 GMT
Lines: 39
Sender: erkyrath@netcom14.netcom.com

Greg Falcon (professor.falken@pnx.com) wrote:
> Could anyone help me figure out what's going on here?

> I have found parse_name to be a very useful property on objects.  I
> was worried about a conflict in definition, though.  The Designers
> Manual (2nd edition) clams that parse_name

>  ...returns:  0 if the text didn't make any sense at all, 1 to make
>     the parser resume its usual course..., or the number of words in
>     a row succesfully matched.

> Which made perfect sense to me, except that I didn't understand what
> to return if only one word is successfully matched, the return code of
> "1" being already reserved for telling the parser to revert to looking
> at the name property.

> I have come to find out, however, that Inform 5.5 (with library
> version 5/12) doesn't work like this at all; the definition given
> above is wrong.

When in doubt, meditate upon the source code.

From the Parser library file: (5/12)

       k=RunRoutines(obj,parse_name);
       if (k>0)
           ! advance wn by k, use object
       if (k==0) 
           jump NoWordsMatch;

So if (k<0) it falls through to the normal algorithm. The mention of "1" 
in the manual is probably a typo for "-1".

--Z

-- 

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
