I7: Typecasting and phrases

I’m trying to define a single phrase that allows one to pass in the name of a property, associate that property with a specific list property of a different object, and then update the first property with values from the second. I’m almost there, but I’m stymied by what may be a bug in the treatment of type-casting (or just something I’m overlooking). Here’s a mini version of the set-up:

[code]Glulx color value is a kind of value. Some glulx color values are defined by the Table of Common Color Values.

Table of Common Color Values
glulx color value assigned number
g-black 0
g-white 16777215

An animation track is a kind of object.
An animation track has an object called the animation-target.
An animation track has a number called animation-length.
An animation track has a number called the property-storage.
An animation track has a list of glulx color values called the color-reel.
An animation track has a list of numbers called the numerical-reel.

A g-element is a kind of object.
A g-element has a glulx color value called the tint.
A g-element has a number called the numerical-value.

The default track is an animation track. The color-reel is {g-black, g-white, g-black, g-white}. The numerical-reel is {12, 6, 8, 10, 7, 3}.

The animatee is a g-element. The tint is g-white. The numerical-value is 5.

To animate (track - an animation track) targeting (P - a property) of (targ - an object):
now the animation-target of the track is targ;
let P1 be P converted to a number;
now the property-storage of the track is P1;
now the animation-length of the track is the number of entries in the reel-list appropriate to P of the track;[works, but can’t be printed–notice that the list-length is correct, however.]
say “The chosen list (length: [animation-length of the track]) is [the reel-list appropriate to (P1 as a property) of the track].”

To decide what number is (P - a property) converted to a number: (- {P} -).
To decide what property is (N - a number) as a property: (- {N} -).

To decide what list of glulx color values is the reel-list appropriate to (P - a glulx color value valued property) of (track - an animation track):
decide on the color-reel of the track.

To decide what list of numbers is the reel-list appropriate to (P - a number valued property) of (track - an animation track):
decide on the numerical-reel of the track.

There is a room.

When play begins:
animate the default track targeting the numerical-value of the animatee.[/code]

The problem is with the “reel-list appropriate to…” phrases. The intention is to have a stack of these phrases that can filter properties of different types to select the appropriate list property for that type. This works just fine if you pass in the property name directly (using the P variable in the “to animate…” block above): the stacked phrases pick out the right type. But if, as in the example above, you typecast the property to a number so you can store it for later use (P1 in the “to animate” block) and then try to typecast back to a property again, using “To decide what property is (N - a number) as a property: (- {N} -)”, Inform always matches to the first-defined phrase in that stack. What that means for the present example is that the color-reel is chosen instead of the numerical-reel.

In other words, when the property is typecast to a number and back again, Inform allows it to match as a specific “x valued property” in a phrase regardless of whether the property actually is of that type. Is there a way around this? Am I naively assuming that you can just typecast back to a property without some other bookkeeping?

I hope this is clear–it’s when writing up questions like these that I feel my lack of programming background most acutely… Thanks for any help!

–Erik

I’m pretty sure that this is a bug. When Inform sees a phrase likeTo animate (track - an animation track) targeting (P - a property) of (targ - an object): ....it normally identifies all of the possible kinds of properties that could be referenced by P and then clones the routine, specializing lines like now the animation-length of the track is the number of entries in the reel-list appropriate to P of the track; so that they invoke the right to-decide phrase. But if a macro like To decide what property is (N - a number) as a property: (- {N} -). is to be supported, Inform needs to (1) write any phrase that uses the macro so that it can handle any kind of property in the story, and (2) have a way to determine a property’s kind at runtime. Neither happens: like you say, it’s just matching against the first likely phrase, and, even if it weren’t, the only place I see with centralized kind information for properties is ShowMeSub.

You could report this as ``story compiles but misbehaves,’’ but my gut feeling is that To decide what property is (N - a number) as a property: (- {N} -). will be ruled invalid.

Thanks, EmacsUser. My own feeling is that the support for types ought to be as uniform as possible: if I can typecast an object in that way and find its kind, I ought to be able to the same with properties. On the other hand, I can see why the developers wouldn’t want to encourage greater proliferation of all this curly braces stuff!

So, plan B is to try to look at the value held in the property and select the type based on that, accessing it with a property name that has been typecast as described above, e.g. given this:

[code]To decide what property is (N - a number) as a property: (- {N} -).

To decide what list of glulx color values is the reel-list appropriate to (P - a glulx color value) of (track - an animation track):
decide on the color-reel of the track.

To decide what list of numbers is the reel-list appropriate to (P - a number) of (track - an animation track):
decide on the numerical-reel of the track.[/code]

…writing something like:

let V be the value of [number]property-storage of the track [typecast to a property]as a property of the [object]animation-target of the track.

But I can’t get this kind of thing to work; I’m having a hard time figuring out how to get at the value of the property starting from the typecast property name. Any suggestions?

–Erik

OK, I’ve taken a bit of a cop-out route. Inform just doesn’t seem to be able to deal well with this kind of thing, so I’m resigned to doing this with spaghetti. Luckily, Inform does have some nice ways of managing spaghetti. For example, passing a text instead of the actual property name:

[code]To decide which list of glulx color values is the reel-list appropriate to (“tint” or “background tint” - a text) for (track - an animation track):
decide on the color-reel of the track.

To decide which list of real numbers is the reel-list appropriate to (“scaling factor” or “x-scaling factor” or “y-scaling factor” or “arbitrary scaling factor” - a text) for (track - an animation track):
decide on the scaling-reel of the track.[/code]

So at least the spaghetti can be moved into individual decision phrases instead of being handled using switch statements in a single phrase. This makes it more easily extensible. If I add a new color property, for example, I just need to add a new phrase:

To decide which list of glulx color values is the reel-list appropriate to ("hue" - a text) for (track - an animation track): decide on the color-reel of the track.

–Erik

Like Plan A, Plan C (spaghetti!) has been stymied by a bug–a pretty massively bad one. Inform is misinterpreting type designations like this one:

To decide which text is the text version of (P - lists of lists of numbers valued property)

to mean

list of lists of numbers valued properties

…which of course is a totally different thing. I’ve reported this, but I’m posting here as a desperate attempt to find a workaround for this problem (or any of the others described above, really)!

–Erik

EDITED TO ADD: What an exercise in frustration. Here are the bug reports associated with my attempts to code this up–almost every potential solution is defeated by a bug…

inform7.com/mantis/view.php?id=648
inform7.com/mantis/view.php?id=649
inform7.com/mantis/view.php?id=650

I’m resigned to just requiring authors to do their own bookkeeping, until a new version of Inform fixes this train-wreck.

For the benefit of anyone who runs across this page in the future, EmacsUser points out in a comment on the Mantis report page that brackets can be used in this case to work around the mis-parsing:

To decide which text is the text version of (P - (lists of lists of numbers) valued property)

–Erik

Just out of curiosity, what is the difference between “lists of lists of numbers valued property” and “list of lists of numbers valued properties”? I’m having trouble parsing either of them.

This is well within the zone where natural language no longer has any advantage over standard computer-language notation!

A list of lists of numbers valued property is a property that contains a value that is a list of lists of numbers, e.g. {{1, 2, 3}, {4, 5, 6}}.
A list of lists of numbers valued properties is a list that contains lists of number-valued properties, e.g. {{weight, speed}, {mass, energy}}, if we have previously declared such things as “A thing has a number called the weight” etc.

–Erik

What got me was that you said “which of course is a totally different thing.” (Emph. added.)

In this case, if the parentheses work, I wouldn’t want Inform trying to puzzle things out by which plurals you’re using (as suggested in the bug report) – it’s convoluted enough that it would be hard for me to predict what would happen.

Hm, I don’t think I agree. On any noun in those phrases except for “property/ies”, I concur that the plurality is just style, and Inform rightly ignores it. But the plurality of property/properties is absolutely necessary to parsing the phrase in English, at least in the absence of hyphens or en dashes. I don’t think that mathematical grouping parentheses should be the only way to express this sort of concept when it can be done in natural language.

–Erik

Well, my argument would be that the plurality isn’t actually helpful in parsing it in English; I can’t make head or tail of these constructions in English, even with the plurality. Part of it may be that I really want those en dashes to be there; I used to have a copyediting job where most of my responsibilities consisted of making sure those dashes were in the right place. (Though in this case the dashes will be de trop; we’re talking the difference between a list of lists of numbers-valued properties and a lists-of-lists-of-numbers—valued property, right?) When the parentheses are easier to follow than the natural language, I think it’s OK to enforce the parentheses.

It’s always bugged me that we don’t hyphenate “number-valued property” or “text-valued table column” because it reads much better that way to my eye. OTOH, I can see how that would be a pain for the compiler, since a hyphen is treated like a letter. (A *-valued kind-of-value could help solve that.)

I guess I just don’t find it that hard to parse. It’s work to think through what “list of list of list of…kind that not’s quite a kind” means, but actually parsing what the phrases says I don’t find hard. You would never say in English that you have a “list of number”, since by general rules of English implicature, a list suggests more than one. The same plurality flag serves to provide a marker of the kind of thing that composes the list in the examples we were discussing–properties in the one example, and numbers in the other. If you don’t make use of the plural, I’m not sure even hyphenation would help; this is hard to parse:

list of list of number-valued property
list of list of number valued-property

…though I agree with both you and Ron that it’s too bad that the decision was made to rescind hyphenated compounds from the language, because they would help.

Again, in all honesty, I think the language is clearer than the parentheses. It never occurred to me to use mathematical grouping in that context, and (as I said) I think the difference between the two constructions is clear enough when plurality is employed as a marker.

But then, none of us will be making this decision, so all of this is really more academic than anything…

–Erik

I think it’s actually a syntactic requirement rather than an implicature. Compare: “This command prints out a list of the objects the player can pick up. Since this is Dual Transform, there’s only one.” Though I suppose you could say that that’s a canceled implicature. [/pedant who sometimes works on implicature]

Anyway, on the comprehensibility question I can offer it up as a datum that I just find the strings in question hard to parse. Part of it is the dashes (and also perhaps that I’ve never had to use “number valued property” in Inform), but also I don’t think “numbers-valued property” is quite correct English; you’d usually say “number-valued property,” wouldn’t you? So we should really be trying to distinguish “list of lists of numbers valued property” and “list of lists of number valued properties.” And then there’s “list of list of numbers valued properties,” which is a list of properties whose values are lists of numbers. I’d hate to have to write a compiler that got the right answer here.

(Similarly I don’t really have a problem with the hyphen thing, though I often do manage to goof myself up by forgetting that I defined a variable with a hyphen in its name.)

Yeah, I agree. I was hedging against the argument that “a list of one number” is arguably sane usage, and therefore the more general “list of numbers” rests logically on a mere assumption that a “list” would have multiple items…

“Number-valued property” sounds right to my ear too, but Inform has actually adopted the plural as conventional. While the user is free to type “number valued property”, the name Inform uses internally is “numbers valued property”. So, while “number” vs. “numbers” could be useful to parsing the kind of thing we’ve been discussing, Inform instead prefers the latter form in all cases.

On the other hand, the names of the two lists we’ve been talking about are distinguished internally by Inform, as “lists of lists of numbers valued property” and “lists of lists of numbers valued properties” respectively. It’s just that it’s impossible to type the former because the compiler erroneously reads it as the latter.

–Erik