[I7] Library messages

[Graham Nelson]

Dear David,

Thanks for the bug report form. I'll get to it before
the next public build. What I am, in fact, doing
now is going through the entire I7 code to try to
clarify, fix small problems and large anomalies,
and document what is going on.

In particular, I am working on a wholesale rewrite
of the Standard Rules. One of the anomalies I
want to remove is that the SR contain numerous
fixed-text messages, which is bad for three
reasons: it is difficult to users to influence such
messages, it is difficult for translators to cope
with them, and it is inconsistent with the existing
I6 library practice.

You've done more work in this area than anyone
else, and I'd like to keep in touch with you about
what we do about this. As you're a Windows
user it's slightly harder for us to give you
experimental builds (it all lives on Mac OS X
primarily), but we might be able to arrange
something with David. Anyway, in the mean
time, it would be good to discuss the possible
specifications. (I'm copying this email to the
other Inform insiders, too: anyone is invited
to comment if they'd like.)

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. Emily
says you've had to keep upgrading and
tweaking every time we release: where has
the bulk of the work come from?

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.

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.

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

(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. For all existing messages that
would be the Standard Rules: but this would allow
other extensions to use a similar system, and
be easy for translators to localise, too.

(4) Your current Custom Library Messages would
be divided in two (unequal) parts. Some of the
machinery would be built in to Inform: the rest
would become I7's equivalent of English.h, an
extension we could call "English Language by
David Fisher".

(5) In imitation of the current I6 system for language
definition files, an I7 translator would provide a
"language extension". This would be a new
category of extension such that every source
text is required to include exactly one of them:
the default being "English Language".
It would define text substitutions for inflections,
somewhat like those in your Section 3.5, and
set up a Table of standard values for all the
messages in the Standard Rules. It would also
use (- ... -) to include the non-LM part of the
I6 language definition file.

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

(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. (Arguably all
Tables could live in namespaces like this,
and only be visible across different extensions
if named like this, but that might be a rather
radical change.)

(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. Of course, NI couldn't easily police
this: it would be a matter of educating extension
writers to use the table of messages "properly"
if they want to use it at all.

Such are my thoughts, anyway. 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; and I should say also
that you'd have to give up copyright on it,
and accept that this mutated form of your
work was now part of the main trunk of Inform,
which I don't want to presume. (It's not public
news yet, but when my code review is complete,
I am changing the Inform licence to the free
open-source Artistic License 2.0, the same
one used for Perl: somebody needs to own the
copyright in Inform so that it can all be licenced
out like this, and that's me. But I don't want to
take your generosity for granted.) I also have
to say that a few of the hackier-looking syntaxes
might have to go: I understand why you've
done some of the syntactical things you've
done, but I'm really trying to avoid hybrids of
text and computery, regular-expression style
hieroglyphs. But in fact some of your hackier
things are only there to cover deficiencies in
my stuff, and those we can remedy.

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.

Best,

   Graham

--
Graham Nelson