[I7] Library messages

[Graham Nelson]

[Adam: could we add David to the mailing list, please?]

Dear David,

Thanks indeed for this. I'm still experimenting, but here
are some further thoughts.

On 19 Jan 2008, at 00:52, David Fisher wrote:
> I'd be interested to see what kinds of new syntax you're thinking  
> of. For some things, a wordier version could affect readability (eg.  
> replacing "[get*]" with "['get' with the appropriate tense and  
> number]").

I am somewhat torn on these things. I tend to think that
typewriter-art syntaxes are a snare: they often make
perfect sense for an individual need, but can weaken
the whole. If the principle is that a naive reader should
be able to guess what the code does, then regexp-like
asterisks are mysterious. And in general, the more
of these things that are created, the less it becomes
true any longer that the whole thing is a natural
language design.

I think "[is/are]" is a good name for a text substitution,
because it looks like what somebody might write in
a "delete as applicable" form. On the whole I'd
like it if we could go down that road, for all that
"[get/gets]" is more characters than "[get*]".

I'm fairly unworried about annoying your existing
users, I'm afraid, because it's better to try to make
a new-deal sort of settlement. If there's one thing
of which reading the history of programming
languages has convinced me, it's that the point
where the designers persist with designs they
don't really like "because of all the code already
out there" is almost always far too early. (The
classic case is "make", where the author disliked
his own syntax at the point where he had 12
users, all at Bell Labs and within earshot, but
thought it would be too much disruption to
make any changes. "make" remains a mess.)

> Something that would be great is a built-in way to make the first  
> letter of a word upper case; the extension uses "[^You]", which  
> looks icky. Would it go against any other design decision to make  
> "to say" rules print the first letter in upper case if the first  
> letter after "[" is upper case? I am thinking along the lines of  
> having a flag built in to I7 that says, "make the next non-space  
> character print in upper case".

I agree that the "^" looks icky.

The unfortunate fact is that it's not a design decision:
it's a weakness of the underlying virtual machines.
On the Z-machine, the only way to treat the first
character is to store all the text in a memory buffer,
then alter the first cell, then print the contents.
That sounds reasonable, but the process of writing
to the buffer is dangerous because completely
open to overruns if the text exceeds a certain length.
The only sensible defence is to have a large buffer
to write into and keep one's fingers crossed, but
the Z-machine is also so short of memory that we
can't easily afford another such buffer.

However, I can offer a better way. I7 already
distinguishes between

    [The ....]
    [the ...]

and so on for A and An, but in the builds published
so far, not for any other cases: those were wired
in to the compiler. I've generalised this so that
the first word of any text substitution is parsed
case sensitively, provided the upper case form
has been declared. Thus declaring both

    To say You: ...
    To say you: ...

causes these to be distinguished in parsing, so
people can then write "[You] eat the food: it doesn't
do much for [you]." and so forth. While you end
up having to define both versions, at least there
are no typewriter symbols, and no buffer
problems.

> There are lots of "fiddly" bits of text; single words and small  
> phrases that are assembled into a longer message. I think it's  
> important for these to be grouped together rather than kept as  
> individual strings, otherwise it makes it very hard to rephrase the  
> messages (especially when translating to other languages).

I agree.

> This is a small fault I can see in some of the original I6 messages  
> (ListMiscellany, for example).

Yes. Some of these are worth looking into again, I think.

>> (7) Each extension would be allowed to have
>> one special table, called just Table of Messages,
>> providing its own library-message-like
>> messages. This could have rows overridden
>> (as in (6)) from any other extension, or from
>> the main source text: it would be called Table
>> of Messages in Grand Plans by Graham Nelson,
>> or whatever, from elsewhere.
>
> How would you resolve conflicts where two extensions are included  
> that both override the same message? My ultimate preference would be  
> for the compiler to flag it as an error, and require the author to  
> explicitly choose which message has priority (or to override them  
> both with a new message).

This is a good point: I hadn't thought of it.

> There are lots of common English phrases an extension writer might  
> want to use that don't necessarily occur in the standard messages,  
> too. Maybe it would worth attempting to identify these and add them  
> as well?

Could you give some examples?

> With regard to translations -- wouldn't a translator need to replace  
> the entire text of every message anyway? I can't see a way to  
> translate individual parts of a message and assemble them properly  
> again (because of language word order, etc.) I may not be totally  
> following what you are saying, though.

All I was saying was that entries in a Table of
Messages ought to be such that they could all
be translated by someone not knowing how the
extension actually worked: the process of
naively changing the text and swapping one
linguistic text substitution ("[votre]" for "[your]",
etc.) would be sufficient.

> If you are thinking of changing the underlying I6 library code  
> anyway, would it be worth removing the unused actions (Swim, etc.)  
> at the same time for the sake of clarity? (These should really be  
> removed from the extension as well; right now, if an author goes  
> through and customises every message, ones like these will never be  
> printed).

Yes, I'm gradually moving away from the position
that the I6 library in I7 needs to be viable as an
I6 library for general I6 use too.

> It could potentially be integrated with the "Plurality" extension as  
> well; there are quite a few overlaps. At the moment it deliberately  
> uses different conventions to that extension to avoid clashes (a|b  
> instead of a-b in the "to say" rules).
>
> And it could really do with a proper set of regression tests. :-)

Oh yes indeed. We can supply you with intest, which
is a Perl script for batch-testing Inform, but I think
you need Cygwin and so on to do all this under
Windows: David could probably help with that?

   Graham

--
Graham Nelson