[Inform] Parsing Ambiguity???
Paul Harker
>Paul Harker (PaulH...@gnn.com) wrote:
>> I've started my first experimental foray into Inform, and have come up
>>with something I don't quite understand. I have defined a car and it's
>>door as two separate objects.
>
>[From your example, you mean the car and its *window* are separate
> objects?]
>
Yep...sorry...make that window.
>The answer, at this point, is "don't have ambiguous names." That is, if
>one object is generally called "car" (with no adjectives), don't have
>another object called "car door" or "car window". One object's name
>should never be a strict subset of another's.
>
>It would be possible to make a more clever disambiguator, with some
>library hacking. I don't know if anyone's done it yet.
>
Mike Phillips led me to an #include class definition (adname.h) that handles
this problem and retains my original concept of retaining a 'natural'
(rather than stilted) description of items. (thanks Mike!)
But my original question remains:
Why do some verbs, like "take" and "push" understand both "car" and "car
window", while others, such as "eat" or "wear", can't tell them apart?
>> Why do some
>> verbs parse right and other not-quite-right? And how can I correct this?
>
>Probably because the car door is contained inside the car. The different
>parsing tokens behave slightly differently.
The car door is not contained in the car. (nor is the window) For the
intended actions in the car door and the car are synonomous.
>
>Oh, you also have the window "concealed". That's probably wrong.
>Concealed objects are ones the player doesn't know about.
>
My assumption here is that most folks know the basic parts of a car, and I
wanted to handle those who choose to be more specific than just "examine
car". I also didn't want a message "There is a car window here." To me that
would sound like an item separate from the car.
Paul
Andrew Plotkin
Paul Harker (PaulH...@gnn.com) wrote:
> I've started my first experimental foray into Inform, and have come up with
> something I don't quite understand. I have defined a car and it's door as two
> separate objects.
[From your example, you mean the car and its *window* are separate objects?]
The answer, at this point, is "don't have ambiguous names." That is, if
one object is generally called "car" (with no adjectives), don't have
another object called "car door" or "car window". One object's name
should never be a strict subset of another's.
It would be possible to make a more clever disambiguator, with some
library hacking. I don't know if anyone's done it yet.
> Why do some
> verbs parse right and other not-quite-right? And how can I correct this?
Probably because the car door is contained inside the car. The different
parsing tokens behave slightly differently.
Oh, you also have the window "concealed". That's probably wrong.
Concealed objects are ones the player doesn't know about.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Paul Harker
I've started my first experimental foray into Inform, and have come up with
something I don't quite understand. I have defined a car and it's door as two
parsing of the commands:
>push car
(the car)
It is fixed in place.
>push car door
It is fixed in place.
However, if I try to do some other actions such as "wear" or "eat" the car
(Silly? Yes) I get the following:
>eat car
Which do you mean, the car or the car window?
>car
Which do you mean, the car or the car window?
Thus leading into a frustrating endless loop. I'd rather continue to call the
car a car, and not an "automobile" which sounds somewhat stilted. Why do some
verbs parse right and other not-quite-right? And how can I correct this?
My code for the car and door objects follow in case I'm overlooking
something basic:
(note: the car will never be opened)
Nearby Car "car"
has static openable lockable locked
with name "car" "dodge" "auto" "automobile" "door",
initial
"Your car is parked here.",
before [;
Search:
"Looking in the car window you see that you did indeed \
lock the garage door opener, and the car keys, inside.";
Examine:
"You look at your car, and are nearly overwhelmed with \
the embarrassment of owning a Dodge product.";
LookUnder:
"Damn! Still leaking oil."; ];
Nearby car_window "car window"
has static concealed
with name "window" "windows" "windshield" "window" "car",
before [;
Search:
"You see through the car's window that you did indeed \
lock the garage door opener, and your keys, inside.";
Examine:
"Luckily your car is safe in case of rain; the \
windows are all tightly closed.";
Attack:
"Remembering that your insurance doesn't cover such acts \
of wanton violence, you reconcider your action.";
];
Paul Harker
>> Mike Phillips led me to an #include class definition (adname.h) that
>> handles this problem and retains my original concept of retaining a
>> 'natural' (rather than stilted) description of items. (thanks Mike!)
> (and me. ;-) )
You BET! Thanks for a great solution!
>> Why do some verbs, like "take" and "push" understand both "car" and "car
>> window", while others, such as "eat" or "wear", can't tell them apart?
> Your 'car window' object is concealed, which disadvantages it in noun
>resolution for Take and Push. 'Eat' and 'Wear' require that the object
>described is also held, so both are disadvantaged; it thus has to ask
>you which your mean.
>> I also didn't want a message "There is a car window here." To me that
>> would sound like an item separate from the car.
> Don't use concealed for this; try scenery.
Thanks Andrew...this clears LOTS of things up in my mind. I have a feeling I
may get a handle on this language before version 7 is done!
Paul
Andrew Clover
PaulH...@gnn.com (Paul Harker) wrote:
> Thus leading into a frustrating endless loop. I'd rather continue to
> call the car a car, and not an "automobile" which sounds somewhat
> stilted. Why do some verbs parse right and other not-quite-right? And
> how can I correct this?
If you're going to be using names like 'car door' and 'car window' in the
same room as a 'car', you're going to need some special parsing routines.
I've done this for you - try downloading the 'adname.h' library from
the inform library contributions directory at GMD (also indexed from the
Inform programming page, http://www.cl.cam.ac.uk/users/gdr11/inform/).
Then your objects would go something like:
nearby car "car"
class adnc
with
name "car" "dodge" "auto" "automobile" door",
adname 'red',
initial
[...];
nearby car_window "car window"
class adnc
with
name "window" "windows" "windshield",
adname 'car' 'auto' 'automobile' 'dodge' 'glass' 'side',
[...];
(Typing 'car' then is valid for the car window but does not imply it.)
BCNU, AjC
Russell Wain Glasser
Paul Harker (PaulH...@gnn.com) wrote:
> I've started my first experimental foray into Inform, and have come
up
>with something I don't quite understand. I have defined a car and it's
>door as two separate objects.
>
...And the reply was...
>The answer, at this point, is "don't have ambiguous names." That is,
if
>one object is generally called "car" (with no adjectives), don't have
>another object called "car door" or "car window".
[snip]
>It would be possible to make a more clever disambiguator, with some
>library hacking. I don't know if anyone's done it yet.
Wrong. Copout solution.
I've wrestled with the same problem in my desperate attempt to
finish "Reverberations" in time for the IF competition. In the game, I
had both a "pizza" and a "pizza BOX". My dilemma was this: I wanted to
be able to refer to the pizza box as "pizza box", and even just "pizza"
when the pizza itself was not present; but when the pizza itself was
visible, I wanted "pizza" by itself to refer ONLY to the pizza.
The solution I found in the designer manual was to create a
parse_name for the box. It worked like this.
Object pizzabox "pizza box" counter
has container,
with parse_name
[;
switch (NextWord())
{
'box', 'pizzabox': return 1;
! calling it "box" or "pizzabox" alone is always ok
'pizza':
{
if (NextWord()=='box') { return 2; }
! "pizza box" is always ok
else
{
if (TestScope(pizza,player) == 0) { return 1; }
!"Testscope (pizza,player)" checks to see
!whether the player can see the pizza.
else { return 0;
}
}
}
],
etc.
This code enables stuff like this:
>EXAMINE PIZZA
It's a flat greasy cardboard box.
>OPEN IT
You open the box, revealing a pepperoni pizza.
>EXAMINE PIZZA
It's a large pepperoni pizza. It looks delicious.
>TAKE PIZZA
And get it all over your hands? No, better leave it in the box.
>TAKE PIZZA BOX
Taken.
>CLOSE IT
You close the box.
>EXAMINE PIZZA
It's a flat greasy cardboard box.
I believe this code would do the trick for your car and car door.
Later you wrote...
>Why do some verbs, like "take" and "push" understand both "car" and
"car
>window", while others, such as "eat" or "wear", can't tell them apart?
I'm not sure why, but here's a big clue. "Eat" and "wear" both
require a "held" noun as direct objects. In other words, typing "eat
car" will AUTOMATICALLY generate the verb <take car>, then attempt to
eat it. That may be a potential reason. (Read the verblib.h code if
you're confused.)
I replaced the "eat" verb to accept regular unheld nouns, because I
didn't want to deal with...
>EAT PIZZA
(First taking the large pizza)
And get it all over your hands? No, better leave it in the box.
Hope I helped! Good luck.
Russell
Andrew Clover
PaulH...@gnn.com (Paul Harker) wrote:
> Mike Phillips led me to an #include class definition (adname.h) that
> handles this problem and retains my original concept of retaining a
> 'natural' (rather than stilted) description of items. (thanks Mike!)
(and me. ;-) )
> Why do some verbs, like "take" and "push" understand both "car" and "car
> window", while others, such as "eat" or "wear", can't tell them apart?
Your 'car window' object is concealed, which disadvantages it in noun
resolution for Take and Push. 'Eat' and 'Wear' require that the object
described is also held, so both are disadvantaged; it thus has to ask
you which your mean.
> I also didn't want a message "There is a car window here." To me that
> would sound like an item separate from the car.
Don't use concealed for this; try scenery.
BCNU, AjC
Mark J Tilford
On Wed, 21 Aug 1996, Andrew Plotkin wrote:
> [From your example, you mean the car and its *window* are separate objects?]
>
> The answer, at this point, is "don't have ambiguous names." That is, if
> one object is generally called "car" (with no adjectives), don't have
> another object called "car door" or "car window". One object's name
> should never be a strict subset of another's.
>
> It would be possible to make a more clever disambiguator, with some
> library hacking. I don't know if anyone's done it yet.
>
I remember seeing a TADS game which would allow you to use 'first',
'second' to choose which object to use, but I can't remember which.
Perhaps somebody could write a routine to do this for Inform?
[Of course, that would cause problems if any of the objects had first,
second, third, etc. in their names.]
>
> --Z
>
> --
>
> "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
> borogoves..."
>
>
Mark J. Tilford
mjti...@artsci.wustl.edu
Greg Ewing
Andrew Plotkin wrote:
>
> It would be possible to make a more clever disambiguator, with some
> library hacking. I don't know if anyone's done it yet.
It would be nice if the parser understood the notion of
referring to an object which is a part of another object,
so that you could just call the parts "window" or "door" and
be able to say
open window of car
Even better if it would also accept
open car window
as meaning the same thing.
This would entail making two attempts at finding an object
to match each noun phrase, the first time looking for a
single object matching all the words, and if that fails,
looking for a hierarchical match.
Greg
Andrew Plotkin
Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:
> It would be nice if the parser understood the notion of
> referring to an object which is a part of another object,
> so that you could just call the parts "window" or "door" and
> be able to say
> open window of car
> Even better if it would also accept
> open car window
> as meaning the same thing.
> This would entail making two attempts at finding an object
> to match each noun phrase, the first time looking for a
> single object matching all the words, and if that fails,
> looking for a hierarchical match.
Well, if you name the window "window of car" you get that effect (since
the Inform parser ignores the order of nouns in an object's name.)
To set it up automatically (for certain objects) would be pretty easy;
adjust the Refers procedure to scan the parents of an object as well as
the object itself for names. You would not want this to happen in most
cases, though. Hm. Maybe.
Mike Phillips
On Tue, 27 Aug 1996 04:22:09 GMT, Andrew Plotkin <erky...@netcom.com> wrote:
>Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:
>> It would be nice if the parser understood the notion of
>> referring to an object which is a part of another object,
>> so that you could just call the parts "window" or "door" and
>> be able to say
>
>> open window of car
>
>> Even better if it would also accept
>
>> open car window
>
>> as meaning the same thing.
>
>> This would entail making two attempts at finding an object
>> to match each noun phrase, the first time looking for a
>> single object matching all the words, and if that fails,
>> looking for a hierarchical match.
>
>Well, if you name the window "window of car" you get that effect (since
>the Inform parser ignores the order of nouns in an object's name.)
Or you can use adname.h (my favorite of the Inform add-on libraries :-) )
and give an adname of 'of' to each item which could be referred like
so. That way it's harmlessly discarded (more or less), and doesn't
confuse things.
Mike Phillips, mi...@lawlib.wm.edu
mag...@news.the-wire.com
Mark J Tilford (mjti...@artsci.wustl.edu) wrote:
: On Wed, 21 Aug 1996, Andrew Plotkin wrote:
: > [From your example, you mean the car and its *window* are separate objects?]
: >
: > The answer, at this point, is "don't have ambiguous names." That is, if
: > one object is generally called "car" (with no adjectives), don't have
: > another object called "car door" or "car window". One object's name
: > should never be a strict subset of another's.
: >
: > It would be possible to make a more clever disambiguator, with some
: > library hacking. I don't know if anyone's done it yet.
: >
: I remember seeing a TADS game which would allow you to use 'first',
: 'second' to choose which object to use, but I can't remember which.
: Perhaps somebody could write a routine to do this for Inform?
: [Of course, that would cause problems if any of the objects had first,
: second, third, etc. in their names.]
I may be entirely out of my tree here, but it seems to me that (in Inform)
you could the ChooseObjects entry point to distinguish between similarly
named nouns. Since the test will only be run when the input is ambiguous,
you just automatically score 'car' above 'window' (or 'pizza' above
'box'). Example (untested):
[ ChooseObjects obj code;
if (code < 2) rfalse; ! Ignore other uses of ChooseObjects
if (obj==The_Car) return 5; ! higher score is better.
if (obj==Car_Window) return 3;
if (obj==Pizza_Slice) return 5;
if (obj==Pizza_box) return 3;
];
The theory is that if there's no ambiguity (either there's only one of the
objects in scope, or the player was suffiently specific in the input) the
parser won't ask ChooseObjects to disambiguate at all. Otherwise, you
always want ambiguity to be resolved in favour of the 'main' object ("car",
"pizza").
Mind you, this approach is not even remotely object-oriented, and I do
seem to vaguely recall encountering some complications with it when I
tried it in my own game.
--
Michael Graham |
Toronto, Ontario | Take me to your duck.
ma...@the-wire.com |
Steven Howard
In <322105...@cosc.canterbury.ac.nz>, Greg Ewing <gr...@cosc.canterbury.ac.nz> writes:
>It would be nice if the parser understood the notion of
>referring to an object which is a part of another object,
>so that you could just call the parts "window" or "door" and
>be able to say
>
> open window of car
>
>Even better if it would also accept
>
> open car window
>
>as meaning the same thing.
>
Inform can do this now. This example uses Andrew Clover's
adname.h, so that I don't have to write a parse_name routine.
Object car_window "car window"
class adnc
with name "window",
adname 'of' 'car',
. . .
and so on. You can call this "window" or "car window" or "window of
car". Of course, you can also call it "car of window", "window of of of",
or any number of ridiculous things. To restrict it to meaningful names,
you'd need to write a parse_name routine for the object.
========
Steven Howard
bl...@ibm.net
What's a nice word for "euphemism"?
Paul Francis Gilbert
erky...@netcom.com (Andrew Plotkin) writes:
>Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:
>> It would be nice if the parser understood the notion of
>> referring to an object which is a part of another object,
>> so that you could just call the parts "window" or "door" and
>> be able to say
>> open window of car
>> Even better if it would also accept
>> open car window
>> as meaning the same thing.
>> This would entail making two attempts at finding an object
>> to match each noun phrase, the first time looking for a
>> single object matching all the words, and if that fails,
>> looking for a hierarchical match.
>Well, if you name the window "window of car" you get that effect (since
>the Inform parser ignores the order of nouns in an object's name.)
>To set it up automatically (for certain objects) would be pretty easy;
>adjust the Refers procedure to scan the parents of an object as well as
>the object itself for names. You would not want this to happen in most
>cases, though. Hm. Maybe.
Agreed. It would be possible, though to implement a new standard attribute,
say "partof". If set, the parser would know the object is "part of" it's
parent, and be able to handle the "xxx of xxx" type.
>--Z
>--
>"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
>borogoves..."
--
Paul Gilbert | p...@yallara.cs.rmit.edu.au
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 3, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
Greg Ewing
Paul Francis Gilbert wrote:
>
> >Well, if you name the window "window of car" you get that effect (since
> >the Inform parser ignores the order of nouns in an object's name.)
But you wouldn't get the effect of "car" on its own referring
to the car but *not* the window, which is what the original
problem was.
> It would be possible, though to implement a new standard attribute,
> say "partof". If set, the parser would know the object is "part of" it's
> parent, and be able to handle the "xxx of xxx" type.
While we're at it, we could get it to understand "x in y" or
"x from y", which would apply to anything inside a container.
Greg
Don Blaheta
Quoth Greg Ewing:
> Paul Francis Gilbert wrote:
> >
> > >Well, if you name the window "window of car" you get that effect (since
> > >the Inform parser ignores the order of nouns in an object's name.)
>
> But you wouldn't get the effect of "car" on its own referring
> to the car but *not* the window, which is what the original
> problem was.
I was just thinking... isn't there a property in which you can put a
function to "rank" the object for disambiguation? You might be able to
use that somehow...
Don
-=-=-=-Don Blaheta-=-=-=-bla...@quincy.edu-=-=-=-dbl...@aol.com-=-=-=-
Excess on occasion is exhilarating. It prevents moderation from
acquiring the deadening effect of a habit.
-- W. Somerset Maugham
Robin Lionheart
Don Blaheta wrote:
> Quoth Greg Ewing:
> > Paul Francis Gilbert wrote:
> > > >Well, if you name the window "window of car" you get that effect (since
> > > >the Inform parser ignores the order of nouns in an object's name.)
> > But you wouldn't get the effect of "car" on its own referring
> > to the car but *not* the window, which is what the original
> > problem was.
> I was just thinking... isn't there a property in which you can put a
> function to "rank" the object for disambiguation? You might be able to
> use that somehow...
It's not the OBJECT you want to rank, it's the WORDS.
The real problem is that all names attached to an Inform object are
"nouns". So with at object named "window of car", "window" and "car"
have equal weight, which will produce this frustrating sequence:
> open car
Which do you mean, the car or the window of car?
> car
Which do you mean, the car or the window of car?
The textbook example of this parsing problem, in my opinion, is the
starting room of Wishbringer. If you were to implement this in Inform,
with its "signpost", "Post Office", and "Post Office door", you would
get the following result:
>look post
Which do you mean, the signpost, the Post Office or the Post Office
door?
>office
Which do you mean, the Post Office or the Post Office door?
You could not refer to the post office in this case, because it will
always match the same two words as "Post Office door". Some parse_name
routines could resolve situations like these on a case by case basis,
but that is a clumsy workaround for a problem intrinsic to the parser
itself.
Instead, the "name" property should be divided into "name" and
"adjective", and the matching routine should give noun matches
greater weight than adjective matches:
sign post Post Office Post Office door
"x post" 1 noun 1 adj 1 adj
"x office" - 1 noun 1 adj
"x post office" 1 noun 1 adj + 1 noun 2 adj
"x post office door" 1 noun 1 adj + 1 noun 2 adj + 1 noun
I hope Inform 6 will add a proper adjective property so we can all
rid our parsers of this annoying bug.
To implement an Encyclopedia Frobizzica with many ambiguous
entries (ex. "Frigid River" vs. "Frigid River Valley"), I once
patched Inform to add an "adjective" property, then changed the library
to score noun matches 10 but adjective matches only 1. It's a kludge,
but it works.
Mike Phillips
On Thu, 12 Sep 1996 23:10:51 -0400, Robin Lionheart <sxl...@hertz.njit.edu> wrote:
>Don Blaheta wrote:
>> Quoth Greg Ewing:
>> > Paul Francis Gilbert wrote:
>> > > >Well, if you name the window "window of car" you get that effect (since
>> > > >the Inform parser ignores the order of nouns in an object's name.)
>
>> > But you wouldn't get the effect of "car" on its own referring
>> > to the car but *not* the window, which is what the original
>> > problem was.
>
>> I was just thinking... isn't there a property in which you can put a
>> function to "rank" the object for disambiguation? You might be able to
>> use that somehow...
>
>It's not the OBJECT you want to rank, it's the WORDS.
>
[snip]
>The textbook example of this parsing problem, in my opinion, is the
>starting room of Wishbringer. If you were to implement this in Inform,
>with its "signpost", "Post Office", and "Post Office door", you would
>get the following result:
>
>>look post
>Which do you mean, the signpost, the Post Office or the Post Office
>door?
>
>>office
>Which do you mean, the Post Office or the Post Office door?
>
>You could not refer to the post office in this case, because it will
>always match the same two words as "Post Office door". Some parse_name
>routines could resolve situations like these on a case by case basis,
>but that is a clumsy workaround for a problem intrinsic to the parser
>itself.
>
>Instead, the "name" property should be divided into "name" and
>"adjective", and the matching routine should give noun matches
>greater weight than adjective matches:
The (wonderful) adname.h library inclusion handles this problem
very well! Anything declared as an adname (instead of a name) can be
used to match, but won't produce a match on its own if there is a match
to something contained in another object's name property. The example
used in the file is 'toilet' and 'toilet paper'. "X TOILET" would
always reach the toilet, and "X TOILET PAPER" (or "X PAPER") would
always reach the paper, and no disambiguation is necessary.
>I hope Inform 6 will add a proper adjective property so we can all
>rid our parsers of this annoying bug.
I think it has been suggested as a standard part of the library.
Mike Phillips, mi...@lawlib.wm.edu
Andrew Plotkin
Robin Lionheart (sxl...@hertz.njit.edu) wrote:
> The real problem is that all names attached to an Inform object are
> "nouns". So with at object named "window of car", "window" and "car"
> Instead, the "name" property should be divided into "name" and
> "adjective", and the matching routine should give noun matches
> greater weight than adjective matches:
> I hope Inform 6 will add a proper adjective property so we can all
> rid our parsers of this annoying bug.
This is a library issue, not a compiler issue. The compiler does no
parsing. The compiler doesn't know that the "name" property is used for
matching text descriptions to objects; the only special thing about it is
that it take double-quoted dictionary words instead of single-quoted.
> To implement an Encyclopedia Frobizzica with many ambiguous
> entries (ex. "Frigid River" vs. "Frigid River Valley"), I once
> patched Inform to add an "adjective" property, then changed the library
> to score noun matches 10 but adjective matches only 1. It's a kludge,
> but it works.
If the Inform parser is capable of behaving as you want it to -- and I
suspect it is -- nothing is stopping you from writing the code.
Andrew Clover
erky...@netcom.com (Andrew Plotkin) wrote:
> The compiler doesn't know that the "name" property is used for matching
> text descriptions to objects; the only special thing about it is that
> it take double-quoted dictionary words instead of single-quoted.
Does it yet allow double-quoted names to be used as well? I'm sure I've
written code that uses double quotes here, and I'd be annoyed if it didn't
work, because forcing single-quotes when everything else is double is just
bobbins and cornish.
If double ain't allowed... it should be! (ISTR pestering Graham to do it
some time ago, but who knows if he did...)
> If the Inform parser is capable of behaving as you want it to -- and I
> suspect it is -- nothing is stopping you from writing the code.
Been there, done that. (Oh, hello our Andrew!)
BCNU, AjC
Andrew Plotkin
> > The compiler doesn't know that the "name" property is used for matching
> > text descriptions to objects; the only special thing about it is that
> > it take double-quoted dictionary words instead of single-quoted.
> Does it yet allow double-quoted names to be used as well?
What, where? Are you talking about Inform 6? I haven't used it, but I
haven't heard that it treats single/double-quoting any different from
Inform 5.
> I'm sure I've
> written code that uses double quotes here, and I'd be annoyed if it didn't
> work, because forcing single-quotes when everything else is double is just
> bobbins and cornish.
> If double ain't allowed... it should be! (ISTR pestering Graham to do it
> some time ago, but who knows if he did...)
Again, where? Are you saying that the difference between single and
double-quotes should be removed from Inform? It can't be (without some
alternative); the difference between dictionary words and compressed
strings is important.
Andrew Clover
erky...@netcom.com (Andrew Plotkin) wrote:
>> Does it yet allow double-quoted names to be used as well?
> What, where? Are you talking about Inform 6? I haven't used it, but I
> haven't heard that it treats single/double-quoting any different from
> Inform 5.
I was lying. :-)
I meant, "does it allow single quotes in the name property", which would
allow you to write code that looked nicer.
I had a read of the new Inform Designers' Manual last night (under the
pretext of reformatting it to plain text) and discovered lots of nice things
I hadn't heard about, having not read it since Inform 5.deadold. It says
that one can indeed use single-quoted names. Other things I didn't know
about include the nice "Object -->" notation, and random(val1, val2, val3).
These are nice.
BCNU, AjC
Gord Jeoffroy
a...@puppy.demon.co.uk (Andrew Clover) wrote:
> I had a read of the new Inform Designers' Manual last night (under the
>pretext of reformatting it to plain text)
Oh, please do!
--Gord, not really up for searching for Tex to txt utilities...
Andrew Clover
crs...@inforamp.net (Gord Jeoffroy) wrote:
>> (under the pretext of reformatting it to plain text)
> Oh, please do!
I'm up to Book two, Chapter three, Section eight, so far. Don't hold your
breath! :-)
> Gord, not really up for searching for Tex to txt utilities...
They never seem to work anyway, judging by some of the plain-text versions
that've been uploaded before.
I'd like to HTMLise it for the new Inform programming pages, too, but this
is a bit much work to do by hand. :-(
BCNU, AjC
Gord Jeoffroy
a...@puppy.demon.co.uk (Andrew Clover) wrote:
> They never seem to work anyway, judging by some of the plain-text versions
>that've been uploaded before.
> I'd like to HTMLise it for the new Inform programming pages, too, but this
>is a bit much work to do by hand. :-(
This just occurred to me: what about a release in Adobe Acrobat
format? I'd hate to install Acrobat just for one manual, but I imagine
if one could produce a PostScript file from a Tex file, one could
produce an Acrobat file from said PostScript file. This would at least
make it accessible to a lot of people with a (relative) minimum of
effort on your part.
--Gord, great ideas with no skill to back them up...
Andrew Clover
crs...@inforamp.net (Gord Jeoffroy) wrote:
>> I'd like to HTMLise it for the new Inform programming pages, too, but
>> this is a bit much work to do by hand. :-(
> This just occurred to me: what about a release in Adobe Acrobat format?
Well, I won't be doing it. I can't run Acrobat on my platform, and there's
no Amiga port either (it is not *very* portable, is it?). I do despise PDF,
more generally.
> I imagine if one could produce a PostScript file from a Tex file, one
> could produce an Acrobat file from said PostScript file. This would at
> least make it accessible to a lot of people
Possibly, but they're generally the same people who can read Postscript and
TeX anyway. (I can /read/ Postscript and TeX - they're just not very
convenient, that's all.)
BCNU, AjC
George Caswell
On Thu, 19 Sep 1996, Andrew Clover wrote:
> crs...@inforamp.net (Gord Jeoffroy) wrote:
>
> >> I'd like to HTMLise it for the new Inform programming pages, too, but
> >> this is a bit much work to do by hand. :-(
>
> > This just occurred to me: what about a release in Adobe Acrobat format?
>
> Well, I won't be doing it. I can't run Acrobat on my platform, and there's
> no Amiga port either (it is not *very* portable, is it?). I do despise PDF,
> more generally.
>
Is there at least an Amiga port of Ghost(script|view)?
> > I imagine if one could produce a PostScript file from a Tex file, one
> > could produce an Acrobat file from said PostScript file. This would at
> > least make it accessible to a lot of people
>
> Possibly, but they're generally the same people who can read Postscript and
> TeX anyway. (I can /read/ Postscript and TeX - they're just not very
> convenient, that's all.)
>
I generally don't like -viewing- Postscript because it's somewhat slow
and the page size is already determined... but if it's set up to the
right page size, it's really simple for me to print... TeX, or (if you're
willing to sacrifice some flexibility) HTML are IMHO two of the better
ways to distribute docs, because they get formatted appropriately...
....T...I...M...B...U...K...T...U... ____________________________________
.________________ _/>_ _______......[George Caswell, CS '99. 4 more info ]
<___ ___________// __/<___ /......[ http://www.wpi.edu/~timbuktu ]
...//.<>._____..<_ >./ ____/.......[ Member LnL+SOMA, sometimes artist, ]
..//./>./ /.__/ /./ <___________.[writer, builder. Sysadmin of adamant]
.//.</.</</</.<_ _/.<_____________/.[____________________________________]
</.............</...................