Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalize message types to an I18n type that works for all types #2

Draft
wants to merge 1 commit into
base: main
from

Conversation

@propensive
Copy link
Owner

@propensive propensive commented Feb 3, 2021

Cosmopolite currently only supports working with strings. This generalizes the Messages type to an I18n container type which can handle any type.

@propensive propensive marked this pull request as draft Feb 3, 2021
@landerlo
Copy link
Contributor

@landerlo landerlo commented Feb 3, 2021

This could be generalized even further as a product of Ts under a context/key K, without requiring to be <: String, so type I18n=SingletonMap[String, String].

I'll have to revisit my previous work that was working around not having NotGiven. Also using ValueOf as a constraint on the keys to distinguish between the singletons and a union or intersection.

@propensive
Copy link
Owner Author

@propensive propensive commented Feb 4, 2021

I think that for Cosmopolite that "context" would always be a language. But you're right, the data structure could be useful in other contexts, and maybe it could be abstracted into a separate library.

But I'd also be interested in representing the language as a type parameterized on a String singleton literal, rather than the String literal itself. This would tighten things up a little bit.

@landerlo
Copy link
Contributor

@landerlo landerlo commented Feb 4, 2021

Yes, it would rather be Language[String]. Union types outside a C[_] are less powerful and handled differently by the compiler, e.g. re inference.

Other than that there is the mainstream argument of strong typing, but with this type level encoding that falls apart because you can control if a String is a part of a Set of languages, so then just a type Language=String would suffice in terms of safety. Scala3 has moved a step in the right direction but not enough to enable this 'structuralist' thinking. Don't base your safety on sticking a name to the value, but base it on required structure and constraints that the value must satisfy, as in the string parameter belonging to the language set in the type parameter. Thank you for coming to my Fringe Type Theory TED talk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants