Hacker News new | ask | show | jobs
by svieira 866 days ago
Is the term merely the hash of its contents, or does it also include the module space? If it's just the hash of its contents, how do you deal with functions which have the same implementation now but shouldn't always - e. g.:

    serviceA.requiredHeaders key = Dictionary.of "X-API-KEY" key

    serviceB.apiKeyHeader apiKey = Dictionary.of "X-API-KEY" apiKey
If they hash to the same thing and I update `serviceA.requiredHeaders` (because the vendor changed from `X-API-KEY` to `X-VENDOR-API-KEY`) do I have to know that these are two different services in order to review the change and untangle these two methods or is there a way to mark these as "structurally equivalent but semantically distinct"?
1 comments
stewoconnor 866 days ago
Yes this is unfortunately a problem that comes up with our current system. We had to solve this early on by distinguishing "unique" types form "structural" types. For types it is obvious that you want to make sure that these types generate a unique hash, even if they are the same structure:

type UserName = UserName Text type Password = Password Text

since the entire point in introducing types here is to actually declare them as different from one another.

But for other it might actually be beneficial to recognize that they are the same type, for example:

type Optional a = None | Some a type Maybe a = Nothing | Just a

To allow for both, you can prefix type with either "structural" or "unique" depending on what behavior you want (unique is the default). We have tossed around the idea of also introducing unique terms which would let you terms like yours as unique terms that should be salted, and let the current behavior of "structural"? terms be the default. The reality is that this hasn't been such a big problem that it has made it to the top of our list yet ;)

link