Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000648Core InformPropertiespublic2011-05-01 07:252014-05-07 07:33
Reporterektemple 
Assigned Tograham 
PrioritynormalSeveritymildReproducibilityalways
StatusclosedResolutionfixed 
Platformx86OSMac OS XOS Version10.6
Product Version 
Target VersionFixed in Version6L02 
Summary0000648: Property names typecast to a number and back again can not be typed
DescriptionTypecasting a property to a number is necessary in order to store it for later use without specifying a type. In other words, if I want to act on a property w/o knowing in advance what property it is, it needs to be of the type "property", but that type is not specific enough to be stored in an I7 variable.

The only available solution is to typecast to a number, store the number in a variable, and then typecast back again when the value is needed. However, after typecasting back to "property" using a phrase like this:

To decide what property is (N - a number) as a property: (- {N} -)

...Inform can no longer tell what type the property is. The retyped property is still recognized as a property in phrases, but cannot be used to distinguish by type.
Minimal Source Text To Reproduce
An animation track is a kind of object.
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 texts called the color-reel. 
An animation track has a list of numbers called the numerical-reel. 

A thing has a text called the tint.
A thing has a number called the numerical-value.

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

The animatee is a thing. The tint is "white". The numerical-value is 5.

To animate (track - an animation track) targeting (P - a property) of (targ - an object):
	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 texts is the reel-list appropriate to (P - a texts 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 numbers 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.
TagsNo tags attached.
Effect(serious/mild) Game compiles but misbehaves
Attached Files

- Relationships
related to 0000453closedgraham Activities on values do not work like activities on objects 
related to 0000650closedgraham Impossible to test the type of a property from within a code block 
related to 0000753closedgraham I6 substitution returning a value can be used for any kind 
related to 0000873closedgraham Default case of a generic phrase's resolver specializes to one kind 
related to 0000904closedgraham Generic phrases can be instantiated with indefinite kinds 

-  Notes
(0001158)
EmacsUser (manager)
2011-05-02 08:51

Note that this case is distinct from, say, the case where the author tests whether an object parameter is of kind room: ``object'' is a definite kind, whereas ``property'' is a kind of kind (I believe; someone correct me if I'm wrong). It might be possible to support this sort of code for properties or table columns, but other kinds of kinds will present trouble. Take this code for instance:

- - - -
There is a room.
To decide what sayable value is bar: (- "bar" -).
To decide what sayable value is baz: (- 219725 -).
To foo (X - some text):
    say "The object called [X]."
To foo (X - a sayable value):
    say "Just [X]."
When play begins:
    foo bar;
    foo baz.
- - - -

In both cases the foo phrase is being applied to an I6 variable with value 219725 (under 6G60 anyway), which could be either a plain number or the address of some compressed text; both possibilities jive with the kind of kind ``sayable value.'' Currently there's no way to know which interpretation the author intended, so the best Inform could do is what it does now: just pick one.
(0001162)
Ron Newcomb (reporter)
2011-05-02 16:00

> whereas ``property'' is a kind of kind (I believe; someone correct me if I'm wrong)


"Property" is a 'constructed kind', per 21.1 "A review of Kinds". Comp Sci knows them as aggregate data types.

"Sayable Value" is a kind of kind, per the same.

And yes: if a storage spot is typed simply as "property" or "list" then you're missing half the type information to use the thing later. Theoretically, you'd need another storage spot to remember if the property in the first spot is "of text" or "of number" or whatever.
(0001166)
EmacsUser (manager)
2011-05-04 11:21

Actually, the same problem presents itself for I7 properties because they can map to either I6 properties or I6 attributes:

- - - -
There is a room.
To decide what property is bar: (- description -).
To decide what property is baz: (- locked -).
To foo (X - an either/or property):
    say "Either/or."
To foo (X - a text valued property):
    say " Text-valued."
When play begins:
    foo bar;
    foo baz.
- - - -
(0002458)
graham (administrator)
2014-02-09 08:23

This is not legal Inform, but previous builds weren't able to spot why. A problem message now rejects

To decide what property is (N - a number) as a property: ...

because it is indefinite about the return kind (exactly because it doesn't say what the kind of the property is). Sorry, but the kinds system is meant to defend against this sort of (void *)-esque trickery.

- Issue History
Date Modified Username Field Change
2011-05-01 07:25 ektemple New Issue
2011-05-02 08:51 EmacsUser Note Added: 0001158
2011-05-02 08:54 EmacsUser Relationship added related to 0000650
2011-05-02 16:00 Ron Newcomb Note Added: 0001162
2011-05-04 11:21 EmacsUser Note Added: 0001166
2011-05-22 12:49 jmcgrew Status new => acknowledged
2011-05-24 10:53 EmacsUser Relationship added related to 0000453
2011-05-24 10:53 EmacsUser Status acknowledged => confirmed
2011-09-20 22:13 EmacsUser Relationship added related to 0000753
2012-02-29 09:04 EmacsUser Relationship added related to 0000873
2012-04-12 13:50 EmacsUser Relationship added related to 0000904
2014-02-09 08:23 graham Note Added: 0002458
2014-02-09 08:23 graham Status confirmed => resolved
2014-02-09 08:23 graham Resolution open => fixed
2014-02-09 08:23 graham Assigned To => graham
2014-05-07 07:32 jmcgrew Fixed in Version => 6L02
2014-05-07 07:33 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker