typing VS ghc-proposals

Iterable[str] is unfortunately evil as it matches str which is often unintended. (see: https://github.com/python/typing/issues/256) One would need both NOT-type and AND-type in order to properly handle these.

The basic motivation behind them is that functions can have arguments that can only take a specific set of values, and those functions return values/types change based on that input. Common examples are (you can find more here):

While yes 26 people liked the idea here: https://github.com/python/typing/issues/193

but looking at relevant issues on GitHub it seems this has been shot down repeatedly. python/typing#18, python/typing#213

See https://github.com/python/typing/issues/256 for a discussion.

Lower bounds are not supported for TypeVars, unfortunately.

Mypy allows that because initial versions of PEP-484 allowed that. This has changed; here's the current wording on the PEP:

> This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.

https://www.python.org/dev/peps/pep-0484/#id29

Dunno, other, larger projects than the one I'm working on seem to run up against this from time to time. (rasa_core, to pick one example from near the top of a Google search; also Telethon, Blender, TensorFlow, Pandas. Guido also filed a bug on the typing module in an early version of Python 3.5 because of unexpected implications of this particular issue, so the problem isn't exactly purely theoretical.) That's aside from the wish for conceptual purity in the call signatures of classes and their subclasses, which is not always and automatically a bad wish to have; and the notion that a language that prides itself on its introspective faculties might want to make introspection of classes from the top of a class hierarchy possible, at least in theory? Perhaps to facility learning about the language and/or visualizing large class hierarchies easily, for instance?

> I think Haskell needs a way to graduate (or retire) language extensions

https://github.com/ghc-proposals/ghc-proposals/pull/601

Additionally, while this proposal is focused on the simple implementation and so in the current proposal or patterns do not bind any variables as per #522, if we do get settled on syntax and then later wish to expand to allow binding variables as in #43, then the syntax is again clean and discoverable.

Yeah, a relatively natural thing would be to be able to opt-in to having the HasField instances be available in all contexts. The (not yet implemented, but accepted) "Modifiers" GHC proposal might be nice for that.

The local modules proposal imo is excellent as-is.

Why would you drop TypeFamilies? It seems fairly popular, given that it was just one vote short of getting added to GHC2021. Do you consider it a less-ideal compromise, that is subsumed by your second proposal (Core with GRTT)?

as syntax is contentious a topic as ever, David (the main proposal author) and I would like to invite you to give your input on https://github.com/ghc-proposals/ghc-proposals/pull/585, where we propose to change the syntax of the accepted proposal #522 introducing Or patterns. In particular, we'd like to know

This looks great, congratulations on completing it! I assume you didn’t get an opportunity to evaluate the delimited continuations based eff library? It would’ve been nice to see Cont included as one of the effects covered, though perhaps not available in all the systems you looked at? Maybe some future work.

I do hope qualified exports are available someday: https://github.com/ghc-proposals/ghc-proposals/pull/283

Right. Being able to disable "custom type warnings" at use sites was part of an earlier proposal (https://github.com/ghc-proposals/ghc-proposals/pull/454) but it ended up being shelved.