support type aliases

[aryairani]

This has been suggested a number of times, so I'm creating this to track it.

[pragdave]

This is something I sorely miss, and would be willing to try to work on, given some guidance.

[pchiusano]

Just recording some notes here.

1. To do this properly, you'd need to modify the type ABT to explicitly note type aliases. Type aliases would have to be a new kind of thing in the code database. They'd be expanded by the typechecker. It's kind of a big effort.
2. Another option that I think is unworkable is to have them be a codebase-only thing, with the type signatures actually not mentioning the aliases once they're slurped into the codebase. Then somehow, the pretty-printer opportunistically uses type aliases. This is no good, because a) it's actually hard/impossible in general, requires higher order unification or something and b) what you come up with might not be what the user even typed.
3. Could quite easily be done with a parser-only change, but then the alias is only local to the scratch file. Question is whether this is useful enough to implement as a short term thing.

[pragdave]

Looking through FileParser.hs, I think this is likely above my pay grade for now. :)

[alvaroc1]

I would REALLY like option 2. Could it be done by storing a rendering "suggestion/hint" as additional meta data on the node that references it? (i might not know what i'm talking about, i just really want this 😅 ... maybe what i'm describing is actually option 1?)

[sellout]

I don’t think option 3 is a good idea. I don’t think it’s particularly helpful if scratch files are used as intended, and it encourages people to hold onto scratch files, rather than working from the codebase. It’s already a hard-enough habit to break for some of us coming from old-fashioned file-based languages 😅

What if option 2 was one-way? I.e., I can write aliases in my scratch files, but they’re never used by the pretty printer. I think this would be a better alternative to option 3.

[aryairani]

I wonder if option 1 would really be so bad?

[ceedubs]

I'm curious about what sort of type aliases people have wanted to be able to declare. A generalized type alias solution could get pretty complicated. But if mostly they want an abbreviation for a concrete ability union like ability alias DefaultPool = {Remote, Scratch, Storage, Blobs, Http, HttpWebSockets} so they can write program: '{DefaultPool} Foo then that might be an easier change. But it would still involve tough decisions about whether this is just for writing/parsing or also for rendering, etc.

I think that type aliases can make code look cleaner, but that it can come at the cost of extra layers for readers to click through and understand. So I personally am not especially interested in this feature. But the DefaultPool example from above in the Unison Cloud client is the one case where I have liked the idea of this. Admittedly that might just be to brush some API smell under the rug.

[alvaroc1]

I want type aliases for writing/parsing AND rendering. I understand the readability concern, but i think that should be left to the author's discretion (like many things already)... though it would be pretty easy (?) to have a share/editor configuration that just expands all aliases.

My experience with aliases in typescript (every type is structural, so they are all aliases) has been mostly good.

At times, the lack of aliases leads to wrapping things with my own custom types just for the benefit of readability, which is sometimes a strictly worse outcome.

[aryairani]

Maybe I'm just not familiar enough with how it could get too complicated; it doesn't sound too complicated to me? Though I'm not clear on whether type alias would include or be separate from ability set aliases. (The former goes between arrows, where the latter applies on the arrows.)

I do think it's important to be able to round-trip what the author writes; thinking both in terms of type aliases and also imports and name suffixes.

I'm for taking a look at this.