|Anonymous | Login | Signup for a new account||2018-04-24 01:30 PDT|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001079||Core Inform||Phrases and functional programming||public||2013-02-13 03:50||2014-05-07 07:34|
|Target Version||Fixed in Version||6L02|
|Summary||0001079: Phrase overloading doesn't support different "decide what" kinds|
|Description||If 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.
|Tags||No tags attached.|
|Effect||(serious) Compiler rejects valid code|
|Is it legal to overload by return type? Should it be?|
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.
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.
|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.|
"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.
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.
|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.|
|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.)|
|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|