Skip to content

Allow type inference for list.pop() - #45

Closed
neilccbrown wants to merge 1 commit into
Tobias-Kohn:masterfrom
neilccbrown:type-inference-remove
Closed

neilccbrown wants to merge 1 commit into
Tobias-Kohn:masterfrom
neilccbrown:type-inference-remove

Conversation

@neilccbrown

Copy link
Copy Markdown
Contributor

pop() was hard-coded to return the list type itself instead of the item type. Several other list methods were also incorrectly returning the list type (unless I've misunderstood?). Most of them can be changed to returning None, but it would be nice for us if pop() had correct inference. To this end, added an ECHO_SELF_ITEM_TYPE marker so a method's return type can echo its receiver's item type (the existing ECHO_ITEM_TYPE only echoes an argument's item type, which methods don't have access to).

Also mirrored the fix into the equivalent (currently unreachable, according to the AI?) code in tigerpython.parser.types for consistency.

pop() was hard-coded to return the list type itself instead of the item
type, so e.g. get_actors().pop().remove() resolved .remove() against
list.remove(x) instead of the actual item class's remove(), leaking the
wrong signature into autocomplete. Added an ECHO_SELF_ITEM_TYPE marker
so a method's return type can echo its receiver's item type (existing
ECHO_ITEM_TYPE only echoes an argument's item type, which methods don't
have access to). Also fixed append/extend/insert/remove/reverse/sort,
which had the same hard-coded-to-self bug but should return None.

Mirrored the fix into the equivalent (currently unreachable) code in
tigerpython.parser.types for consistency. Regenerated release JS/mjs.
@Tobias-Kohn

Copy link
Copy Markdown
Owner

I am a bit unsure whether it makes sense to actually merge this in. Actually, I have been working on a more flexible solution recently, which solves the same problem.

My approach was to introduce a new class BuiltinMethod, which has an object associated with it, from which it will go and fetch the necessary information. This was necessary for dict.keys(), etc. I feel it would make more sense to use that here, too. What do you think?

On the other hand, you are absolutely correct that the return types of various methods are clearly wrong.

@neilccbrown

Copy link
Copy Markdown
Contributor Author

Is that the work on the "dev-tk" branch? I'm happy to try using that approach instead and see about adapting it for the list method here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants