Page MenuHomePhabricator

Support typed list of types with type converters
Open, MediumPublicBUG REPORT


Steps to replicate the issue (include links if applicable):

What happens?:
Result comes back empty. Test fails with time out.

What should have happened instead?:
Ideally should work (cannot avoid time outs in some cases, sure).

Software version (skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
Reported by GrounderUK via Telegram

Event Timeline

DVrandecic renamed this task from Typed list of natural number does not seem to work to Support typed list of types with with converters.Mar 7 2024, 4:03 AM

See also T359500. Untyped lists are converted to Typed list with Type Natural number.

IMG_0885.png (2×960 px, 221 KB)

Jdforrester-WMF renamed this task from Support typed list of types with with converters to Support typed list of types with type converters.Mar 7 2024, 5:47 PM
Jdforrester-WMF moved this task from To triage to Upcoming Epics on the Abstract Wikipedia team board.

Currently, this depends on re-entrancy. I wonder if that is a strict dependency: since typed list are handled in the orchestrator bespoke, could we also just call the converters in a bespoke way from the orchestrator for the individual values?

This doesn't necessarily depend on re-entrancy.

When we resolve the arguments and return type of a function call, before delegating to the evaluator, we can retrieve type converters for all participating types (including the types of members of other types).

Our type key logic is probably good enough to handle issues like recursively-defined types (typed lists are the obvious example here).

This does mean that we'll have to replicate the type key creation logic in every supported programming language. That is still probably better than depending on re-entrancy, which would make things prohibitively slow.