Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000753Core InformKinds and type checkingpublic2011-09-20 17:102014-05-07 07:33
ReporterRon Newcomb 
Assigned Tograham 
PlatformPPCOSMac OS XOS Version10.4
Product Version6G60 
Target VersionFixed in Version6L02 
Summary0000753: I6 substitution returning a value can be used for any kind
DescriptionIn the attached source, foo is invoked with bar as a parameter, even though a value is not necessarily a device.
Minimal Source Text To Reproduce
There is a room.
To decide what value is bar: (- 0 -).
To foo (X - a device):
	foo bar.
TagsNo tags attached.
Effect(mild) Compiler accepts invalid code
Attached Files

- Relationships
related to 0000648closedgraham Property names typecast to a number and back again can not be typed 

-  Notes
Ron Newcomb (reporter)
2011-09-20 17:13

Test me with "examine me".
EmacsUser (manager)
2011-09-20 22:05

The source code is in fact invalid when those bits are uncommented.

If ``[arithmetic]'' is uncommented, the parsed player's command will have kind ``relation of 1-based indices to (relations of arithmetic values to word values),'' but the argument arr to the #-of substitution will expect type ``relation of 1-based indices to (relations of numbers to word values).'' Number is more specific than arithmetic value, but Inform relations are covariant, not contravariant, in their keys. So the code should read ``... (arr - a relation of 1-based indices to relations of arithmetic values to word values) ...'' instead.

If ``[K]'' is uncommented and ``word value'' is commented, K becomes the kind ``understood word'' according to the definition of ``the word.'' But then the parsed player's command has kind ``relation of 1-based indices to (relations of numbers [arithmetic values] to word values),'' instead of the expected ``relation of 1-based indices to (relations of numbers [arithmetic values] to understood words).'' Again, understood word is more specific than a word value, and Inform relations are covariant in their values too.

Hidden behind all of this is the issue that ``arithmetic value'' and ``word value'' aren't really kinds, but kinds of kinds, and therefore ``number'' and ``understood word'' aren't more specific in the same way that, say, ``person'' is more specific than ``thing.'' Also, something like ``relation of 1-based indices to (relations of arithmetic values to word values)'' is a kind of kind, meaning that its dangerous (and arguably invalid) to declare a phrase with such a return value (cf. 0000648:0001158).

Now Inform is still failing to give a helpful error message, but I traced that back, and it looks like the underlying cause is the same as for 0000739. I will leave a note with a reduced test case there, just in case the issues turn out to be separate.

The last question then, is why Inform accepts the source with no commenting changes. The same problem seems to come up whenever ``value'' is used in a return kind:

- - - -
There is a room.
To decide what value is bar: (- 0 -).
To foo (X - a device):
    foo bar.
- - - -

This case probably constitutes a distinct, accepts-invalid bug, albeit a non-issue if 0000648 is resolved by forbidding ambiguous return kinds. But I'll ask for other opinions before I reduce the report.
Ron Newcomb (reporter)
2011-09-21 12:25

Doh, I did forget about the covariant / contravariant "direction".

Normally I'd just expose an array to I7 multiple times under different, specific types. "Pattern", for instance, has 4 different I7 names according to its return type. But I can't do that with Parse because the type depends on the VM, which means the I7 source code using it would need to use different names depending upon VM... ugh. I'm trying to hide these small differences so my readers can concentrate on how the algorithm works, hence the partially-vague return type.

I'll see if I can re-work things somehow.
Ron Newcomb (reporter)
2011-09-21 15:22

Oh, and to answer the question about why Inform accepts the source with no commenting changes, I believe it's because I didn't actually try to use "the parsed player's command" in an I7 phrase, only in I6 phrases. I do get a Problem message when trying to do so:

>> I can't allow 'MoveWord' , because the phrase it gives a name to is generic, that is, it has a kind which is too vague. That means there isn't any single phrase which 'MoveWord' could refer to - there would have to be different versions for every setting where it might be needed, and we can't predict in advance which one 'MoveWord' might need to be.<<

So I believe your foo bar example is a separate issue.
EmacsUser (manager)
2011-09-21 17:07

Hmm. But that looks like the error one gets when naming a generic phrase, whether or not the phrase or the name is used.

Regardless, the foo bar bug isn't already on Mantis, so I've reduced and confirmed the report.
graham (administrator)
2014-02-01 08:06

Inform now rejects "To decide what value is bar:" as being too vague about the return kind. Return kinds have to involve either definite kinds, or kind variables decided by the usage, or else be decided by the rules of arithmetic/dimensions.

- Issue History
Date Modified Username Field Change
2011-09-20 17:10 Ron Newcomb New Issue
2011-09-20 17:13 Ron Newcomb Note Added: 0001280
2011-09-20 22:05 EmacsUser Note Added: 0001282
2011-09-20 22:13 EmacsUser Relationship added related to 0000648
2011-09-21 12:25 Ron Newcomb Note Added: 0001284
2011-09-21 15:22 Ron Newcomb Note Added: 0001286
2011-09-21 17:07 EmacsUser Effect (serious) Compiler rejects valid code => (mild) Compiler accepts invalid code
2011-09-21 17:07 EmacsUser Note Added: 0001290
2011-09-21 17:07 EmacsUser Severity serious => mild
2011-09-21 17:07 EmacsUser Status new => confirmed
2011-09-21 17:07 EmacsUser Summary the type "relation of X to Y" cannot take "an arithmetic/enumerated value" or a kind variable K as subtype => I6 substitution returning a value can be used for any kind
2011-09-21 17:07 EmacsUser Description Updated View Revisions
2011-09-21 17:07 EmacsUser Steps to Reproduce Updated View Revisions
2014-02-01 08:06 graham Note Added: 0002422
2014-02-01 08:06 graham Status confirmed => resolved
2014-02-01 08:06 graham Resolution open => fixed
2014-02-01 08:06 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