I'm curious if there is an elegant way to deal with backward compatibility when adding another case to a widely used sum type? Is it just a matter of fixing all the compile errors immediately?
I think the limitation you are describing is one of the two aspects of the expression problem[0]:
- with objects you can easily add new types, but it's difficult to add functions (methods) dealing with these types
- with sum types you can easily add new functions, but it's hard to add new variants in the sum type
Is it possible to overcome these limitations? I first read about the expression problem in the excellent post "The Expression Problem and its solutions"[1] on Eli Bendersky's blog (discussed here[2] on HN); as the title suggests it does present interesting ways to "solve" the expression problem.
However he also points out that the chosen solution in a a typical programming language (visitor pattern) quickly becomes unwieldy. The second solution (multimethods) is much nicer to deal with, but requires support from the language.
It seems like these treatments tend not to get to the heart of the expression problem as seen in actual language tools, which is migration between language versions. Let's say you're on version 5 of a language and you want to migrate all your tools to support version 6 where there is a new expression type. Can your codebase clearly represent a situation where some tools have been migrated to support version 6 and others aren't done yet? Can you easily figure out what remains to be done? And once the migration is done, can we remove any traces of the previous version that we don't want anymore?
And how do we approach this if the AST is published as a library and each tool is a package written by a different team?
There might be other usages of sum types that are simpler, though.
