[I7] Library messages

[Graham Nelson]

[David's original reply to me, copied to the list.]

Graham,

First of all, thanks for involving me! I'm certainly interested in  
this area.

> Of course the likelihood is that quite a
> lot of the patient labour you've already
> put in would disappear or be so heavily
> reworked that the original is hardly
> recognisable any more

I have no problem with that at all. I'm not too attached to the  
current code, and I would be happy with whatever rewrites are needed.

> and I should say also that you'd have
> to give up copyright on it

No probem. I hereby give up all claims to copyright on the Inform 7  
extensions Custom Library Messages and Default Messages. :-)

> I also have to say that a few of the
> hackier-looking syntaxes might have to go

That's fine ...

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]").

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".

(A more verbose alternative might be: [upper][you]; [lower][you]; and  
something meaning "forget the flag, just print what you would normally  
print without changing it to lower or upper case").

> Fundamentally, I think there are two options:
>
> (a) Rip out the whole existing Library Messages
> system from I6 and replace it with something
> more I7esque.
>
> (b) Retain the existing LibraryMessages system
> but interface with it in a more I7 way.
>
> Broadly speaking, (b) is what your extensions
> currently do, and on the whole I think it's
> probably the better choice because it makes
> the work of non-English Inform users a little
> easier. But I am open to (a) if your experience
> suggests that the better course is simply to
> abandon existing methods entirely.

(b) sounds OK to me.

I don't have any real objection to (a), though. (Maybe Andrew Plotkin  
has an opinion on this one? He seems to be interested in this area).

> Emily says you've had to keep upgrading and
> tweaking every time we release: where has
> the bulk of the work come from?

Yes, I'm always slightly nervous when there is a new release of I7,  
just in case it subtly breaks something in the extension.

It's a bit hard to say where the bulk has come from; I guess it mostly  
happens whenever the handling for a particular action changes (eg.  
adding the action variable "container exited from" to the Exiting  
action caused some problems).

I also worry that the extension overrides something in the Standard  
Rules which has been changed in the mean time (eg. it completely  
overrides "report an actor going" at the moment, because of the string  
literals it contains).

> My current idea is this.
>
> (1) The existing Standard Rules use the phrase:
>
> To issue library message (AN - an action-name) number
> (N - a number) for (H - an object):
> (- GL__M({AN},{N},{H}); -).
>
> along with variations. I propose to redefine this so
> that it instead starts an activity, with the number and
> parameter as activity variables: this immediately
> allows people to intervene in a rule-based way.
> The last "for" rule for the activity would then call
> GL__M to issue the message if nobody had
> intervened. Ultimately, this would go through the
> same Library Messages system as always.

Sounds good.

> Your scheme of providing I7 names for the message
> numbers, or a scheme like it, would be adopted:
> this would improve the legibility of the Standard
> Rules considerably, too.

Feel free to rename everything; my only concern is that authors who  
are already using the extension might need to do a lot of work to  
upgrade.

> (2) The remaining static textual messages in the
> SR would all be assigned new message numbers
> and thus join the same system as everything else.

That would be excellent. A thought --

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).

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

> (3) The system would, however, be extended so
> that messages would be identified not only by
> number and action, but also by the extension
> which owns them.
...
> (4) Your current Custom Library Messages would
> be divided in two (unequal) parts.
...
> (5) In imitation of the current I6 system for language
> definition files, an I7 translator would provide a
> "language extension".
...
> (6) NI (the I7 compiler) would be extended so
> that it is possible for someone to supply a table
> which overrides selected rows in a given
> existing table. This seems like a nice ability
> for other purposes, too.

Sounds good.

> (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).

> (8) The text in such a table would have to use
> only text substitutions which could be translated
> or replaced: that is, it would have to use a
> mix of
>
> - static text;
> - substitutions built into Inform, e.g. for printing
> numbers;
> - substitutions from the corresponding language
> extension;
> - or substitutions from the extension itself, but
> which expand only into combinations of the
> previous three possibilities.
>
> Thus a translator could render the result in any
> language by changing only the static text and
> using language-specific text substitutions such
> as "his/her" from his own language instead of
> the original.

One problem for extension writers is introducing new irregular verbs  
that are unknown to the standard rules (suffixed with "*" in the  
extension).

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?

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.

> This plan can't be achieved overnight, and I don't
> want to start without gathering views, especially
> yours and Emily's. But if it broadly sounds
> sensible then I would begin by converting
> the remaining static text in the Standard Rules
> to library messages with new numbers, to get
> everything on a consistent footing.

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).

General comments:

The extension does have various hacks that were either to get around  
things in the existing system, or are no longer necessary because of  
advances in Inform 7. So it would be good to revise the code anyway.

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. :-)

David Fisher