Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001079Core InformPhrases and functional programmingpublic2013-02-13 03:502014-05-07 07:34
Reportercuriousdannii 
Assigned Tograham 
PrioritynormalSeverityseriousReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version6L02 
Summary0001079: Phrase overloading doesn't support different "decide what" kinds
DescriptionIf you overload phrases with different decide what kinds, the compiler will assume that the last phrase is the one which you want, rather than the phrase which matches the kind of the variable it is being assigned to.
Minimal Source Text To Reproduce
There is a room.
To decide what number is my special value: decide on 4.
To decide what person is my special value: decide on the player.
When play begins:
	let x be a number;
	now x is my special value.
TagsNo tags attached.
Effect(serious) Compiler rejects valid code
Attached Files

- Relationships
related to 0001080closedgraham General phrase overrides specific one if it appears later in the source text 

-  Notes
(0001970)
NYKevin (reporter)
2013-02-13 16:16

Is it legal to overload by return type? Should it be?
(0001971)
EmacsUser (manager)
2013-02-13 20:17

On one hand, there's no documented support for dispatch by return type, but on the other, suitable resolution of the umbrella issues would introduce such support. I'm going to confirm this as a case of 0000905 for now, but if that's declared a non-bug or a won't-fix, then the code is invalid and we have a badly worded error message instead.
(0001972)
curiousdannii (developer)
2013-02-14 01:34

I wouldn't consider it ambiguous, but rather that the compiler ignores information that is available to it.

Graham might decide that overloading by return type might not be supported, but I hope he will. Semantically there's no difference between this and other types of overloads.
(0001973)
EmacsUser (manager)
2013-02-14 09:32

Thanks for the comment, since, looking at this again, I don't know what I was thinking. The umbrella issue I was meaning is 0000686, not 0000905, because both phrases lead to valid parses, one of which ni chooses, the other of which would typecheck.
(0001974)
zarf (developer)
2013-02-14 11:04

"Semantically there's no difference between this and other types of overloads."

Is that true? Interpreting expressions from the inside out is part of I7's semantics, as I see it.

Obviously this pair of phrase declarations is *sometimes* ambiguous, as here:

say "I like [my special value]."

(Both numbers and persons are sayables.) Having a phrase whose base behavior depends on the context it's used in seems like a big shift.
(0001975)
EmacsUser (manager)
2013-02-15 10:37

Further experimentation shows my second diagnosis to also be wrong. Here are my notes:

There are currently two possibilities when a phrase is defined: either (1) the definition specializes (or shadows) an earlier one per WI 21.9, and although no productions are added to the grammar, the meaning of existing productions changes, or (2) the definition does not combine with earlier ones, and productions are added (which could make the grammar ambiguous).

Once Inform has decided when (1) applies and when (2) does, it seems clear that it should accept all phrase invocations that have a unique typechecking parse* and complain with a type error if there is none or an ambiguity error if there are several. That's what 0000686, 0000898, and 0000905 are getting at. If we assume that (2) applies to the attached source, since (1) wouldn't make sense, we have a case of 0000686, like I had thought. But, in fact, that assumption is false.

It looks like Inform chooses (1) whenever two phrases' wordings match exactly and, comparing corresponding argument descriptions by the most specific kinds they imply, the kinds from the new phrase are subkinds of those from the old one. I think that's the test that has to come under scrutiny here. Making return-type-based dispatch work is a matter of conditioning (1) on a supertype relation between return types—in that sense, Dannii's right that there's little difference between the two sorts of overloads.

In fact, it would be rather contrived not to treat return types symmetrically, because the author can always add throwaway wordings to force (2), which demonstrates that Inform is already capable of the expected behavior and gives a workaround for the bug:

- - - -
To decide what number is my special value/asdf: decide on 4.
To decide what person is my special value/jkl: decide on the player.
- - - -

* Actually ``description-checking'', since Inform can also test some non-kind conditions at compile time.
(0001976)
EmacsUser (manager)
2013-02-15 10:54

Well this is certainly a bug of false starts for me. My previous suggestion is not actually a workaround, I believe because of the umbrella issues. Inform is always opting for the asdf phrase over the jkl phrase, regardless of which is which.
(0002328)
graham (administrator)
2014-01-19 10:26

This now produces an explanatory problem message, rejecting the conflict between the definitions. (Zarf is right that the semantics don't lend themselves to overloading the return kind.)

- Issue History
Date Modified Username Field Change
2013-02-13 03:50 curiousdannii New Issue
2013-02-13 16:16 NYKevin Note Added: 0001970
2013-02-13 20:17 EmacsUser Note Added: 0001971
2013-02-13 20:17 EmacsUser Severity mild => serious
2013-02-13 20:17 EmacsUser Status new => confirmed
2013-02-13 20:18 EmacsUser Relationship added child of 0000905
2013-02-14 01:34 curiousdannii Note Added: 0001972
2013-02-14 09:32 EmacsUser Note Added: 0001973
2013-02-14 09:32 EmacsUser Relationship added child of 0000686
2013-02-14 09:33 EmacsUser Relationship deleted child of 0000905
2013-02-14 11:04 zarf Note Added: 0001974
2013-02-15 10:36 EmacsUser Relationship deleted child of 0000686
2013-02-15 10:37 EmacsUser Note Added: 0001975
2013-02-15 10:44 EmacsUser Relationship added related to 0001080
2013-02-15 10:54 EmacsUser Note Added: 0001976
2014-01-19 10:26 graham Note Added: 0002328
2014-01-19 10:26 graham Status confirmed => resolved
2014-01-19 10:26 graham Resolution open => fixed
2014-01-19 10:26 graham Assigned To => graham
2014-05-07 07:34 jmcgrew Fixed in Version => 6L02
2014-05-07 07:34 jmcgrew Status resolved => closed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker