Meaning relation and reversed relations

In 6M62, it doesn’t seem to be the case that a verb assigned to mean a reversed relation counts as meaning that relation. For example:

To lade is a verb. The verb to lade means the reversed carrying relation.

coupled with

showme the list of verbs that mean the carrying relation;

results in only

list of verbs: {verb carry}

which is built-in.

Some questions:

  1. Is the reversed R relation actually its own separate relation from the R relation internally?
  2. If so, is there any way to access a reversed relation (as a relation) in code?

If you look in the compiled I6, you’ll see a series of things like

Array Rel_Record8 --> [ 0; 101515264; RELATION_TY; MAX_POSITIVE_NUMBER; NULL; NULL; "containment relation"; abilities_U6; 0; DK6_relation_of_objects; call_U12; "contains"; ];
Array Rel_Record9 --> [ 0; 101515264; RELATION_TY; MAX_POSITIVE_NUMBER; NULL; NULL; "support relation"; abilities_U7; 0; DK7_relation_of_supporters_t; call_U13; "supports"; ];

(v10, but so far as I recall it was substantially similar in 6M62). There are verbs defined for the reversed support and reversed containment relations by default, but no corresponding Rel_Records. So I feel safe in concluding that reversed relations aren’t independent.

I7-2217 is a feature request I made wishing to be able to use reversed R as a relation value in general.

2 Likes

Good thinking to check the Rel_Record* arrays!

So… it looks like for whatever reason the meaning relation just doesn’t map a given verb to a relation if the verb specifies the reversed form of that relation?

It seems the conjugate_verbs shed more light…

[ ConjugateVerb92 fn vp t modal_to;
    switch (fn) {
        1:
            print "carry";
            ;
        2:
            print "carried";
            ;
        3:
            print "carrying";
[...]
        CV_MEANING:
            return Rel_Record12;
            ;
[ ConjugateVerb101 fn vp t modal_to;
    switch (fn) {
        1:
            print "lade";
            ;
        2:
            print "laden";
            ;
        3:
            print "lading";
[...]
        CV_MEANING:
            return Rel_Record18;
Array Rel_Record12 --> [ 0; 101515264; RELATION_TY; MAX_POSITIVE_NUMBER; NULL; NULL; "carrying relation"; abilities_U10; 0; DK9_relation_of_people_to_th; call\
_U16; "carries"; ];
[...]

Array Rel_Record18 --> [ 0; 101515264; RELATION_TY; MAX_POSITIVE_NUMBER; NULL; NULL; " relation"; abilities_U16; 0; DK10_relation_of_things_to_pe; call_U22; "\
is-carried-by"; ];

so it does get its own rel_record, but that rel_record doesn’t have a name. That’s probably a bug; I think it’d be ideal for it to be “reversed carrying relation”. (So it still wouldn’t show up as meaning the carrying relation, but you would be able to tell the difference between a verb that means R and one that means reversed R.)

3 Likes

Thanks, Zed – both questions answered!

I’m still not really understanding what’s going on under the hood, though… A “reversed” relation is created, but:

  • It doesn’t show up in >RELATIONS output.
  • Assertions using verbs associated with it affect the non-reversed version only.
  • The automatically-created “reversed verb” (i.e. to be Xed by) is not associated to the non-reversed verb relation via the meaning relation (though it is shown to be linked in the Index).

[EDIT: Oops, I meant “non-reversed relation” as the association target for the reversed verb in the last bullet point above. Corrected.]

The first two make sense to me because semantically the reversed version is “the same thing” from a certain perspective – but for the same reason I was half-expecting that a verb meaning the reversed relation in the source would at run-time count as meaning the non-reversed version.

This all came about due to playing with RB 250 Relevant Relations, trying to get “Clark is laden by…” to be a possible output for describing things being carried.

1 Like

There’s definitely only one relation in terms of one copy of the data. I think the compiler is pursuing a deliberate strategy of: “the game code doesn’t need this info; this is only useful for compiling”. It writes info to the Project Index that can’t be found in the I6.

This is what I think is going on (which goes into speculation):

The docs include the example of “to grace” meaning the reversed wearing relation: an active-voice verb meaning reversed relation is supported. But I think the implementation has some assumptions baked in that active-voice verbs are (forward) relations and that reversed relations begin with to be.

In the Standard Rules, all the verbs that mean reversed relations begin with to be. Other than to be, to be able to, to be able to see, to be able to touch, Inform doesn’t create values of kind verb for verbs beginning to be: it doesn’t have to, 'cause they can all be conjugated by conjugating to be and considering everything else to be a multi-word preposition trailing it.

So you create your to lade and Inform thinks: active-voice verb with a meaning: I have to make a rel_record. But then it doesn’t know what to call it 'cause the implementation doesn’t really know how to treat reversed relations as first class citizens. So it doesn’t get a name. As the code below shows, you can get to the relation via the result of the phrase the meaning of verb lade.

But there’s no real effort to provide the list of verbs meaning reversed R. The best thing to do would be to manually populate your own mapping.

But if you really wanted to do it dynamically (all pragmatism dropped as we enter the realm of mad science)… notice the last parameter of that rel_record:

Array Rel_Record18 --> [ 0; 101515264; RELATION_TY; MAX_POSITIVE_NUMBER; NULL; NULL; " relation"; abilities_U16; 0; DK10_relation_of_things_to_pe; call_U22; "is-carried-by"; ];

You could iterate through the relations in I6 looking for things matching “is-[verbed]-by” and then iterate through the verbs looking for the verb for which “verbed” is its third-person plural form, and then you’d know that that verb’s meaning is the forward relation of which the original verb was the reversed relation.

The verb to lug means the carrying relation.

The verb to lade means the reversed carrying relation.

lab is a room.
bob is a person.

Bob carries the spam.
the player carries the butter.

Section old meaningless (for use without Basic Inform by Graham Nelson)

meaningless-verb is always verb are.

Section new meaningless (for use with Basic Inform by Graham Nelson)

meaningless-verb is always verb achieve.

part the rest

when play begins:
let null-r be the meaning of meaningless-verb;
showme the list of verbs that mean the carrying relation;
repeat with v running through verbs begin;
say "[infinitive of v]";
unless the meaning of v is null-r, say "->  [meaning of v]";
say line break;
end repeat;
let R be the carrying relation;
let Rp be the list of people that R relates;
let Rt be the list of things that R relates to;
let RR be the meaning of verb lade;
let rrp be the list of people that rr relates;
let rrt be the list of things that rr relates to;
say "[R] | [ Rp ] | [Rt].";
say "[RR] | [ RRp ] | [RRt].";
1 Like

Oh, hey – a new-to-me “halting in abject failure” Problem Message!

Problem. An internal error has occurred: meaningless preposition. The current sentence is ‘To be laden by is a verb’ ; the error was detected at line 53 of “inform7/Chapter 11/Prepositions.w”. This should never happen, and I am now halting in abject failure.

I haven’t managed one of those in a while. Happens in 10.1, too. The cause was:

To be laden by is a verb.

The verb to be laden by means the carrying relation.

I thought I might be able to get around the barrier by specifying that the reversed verb means the forward relation. Either one of the above assertions is accepted, but not the pair. The first alone just makes the verb (with its ConjugateVerb*() routine) but assigns no meaning. The second assigns the meaning (without creating an internal reversed relation) but makes no verb.

Hats off to you on your snippet above – it wins this week’s Bubbling Beaker Award for sure!

It works in 6M62 if you omit the initial To be laden by is a verb.

Yes, but it does not make a verb (i.e. ConjugateVerb*() routine), so the (English) verb can only be used for making assertions in the source. There is no link between a verb routine and an associated relation at run-time, which is the basis for what RB 250 is doing.

Also, sadly, it looks like the RR_DESCRIPTION string of a relation doesn’t always follow the same format. For example, I added a few more variants for existing relations:

The verb to lade means the reversed carrying relation.

The verb to beset means the reversed support relation.

The verb to fill means the reversed containment relation.

but the relation description strings are unrelated to the forward relation’s verb (with the one for the lock-fitting relation being especially different):

have --> has
relate --> relates
mean --> means
provide --> provides
contain --> contains
support --> supports
incorporate --> incorporates
enclose --> encloses
carry --> carries
hold --> holds
wear --> wears
be able to see --> can-see
be able to touch --> can-touch
conceal --> conceals
unlock --> Lock-fitting relates one thing ( called the matching key ) to various things
lade --> is-carried-by
beset --> is-on
fill --> is-in

I haven’t even been able to locate where strings like "is-carried-by" or "is-on" originate – maybe compiler hardcoding?

Hard-coding for the built-in spatial relations can be seen here: Spatial Relations