Add more context to wildcard type (*) explanation
#6805
Conversation
ElrohirGT
changed the title
**) explanation
devtools/flake.nix
Outdated
| { | ||
| name = "roc-lang-unofficial"; | ||
| publisher = "IvanDemchenko"; | ||
| version = "1.2.0"; | ||
| sha256 = "sha256-lMN6GlUM20ptg1c6fNp8jwSzlCzE1U0ugRyhRLYGPGE="; | ||
| } |
There was a problem hiding this comment.
Were these spaces removed by a formatter?
There was a problem hiding this comment.
Yep! I ran:
nix fmtAnd it formatted flake.nix and a file under de tools directory.
|
I think the wording addition looks good. Just not 100% on the nix addition. |
|
This PR no longer modifies the flake.nix file, only the tutorial.md file |
Signed-off-by: Anton-4 <[email protected]>
|
@ElrohirGT it"s hard to explain this really well, so I tried to make some improvements and asked Richard for help to perfect this. |
|
|
||
| - The function could only return `[]`. Remember, the wildcard type means **any** type, so our function `List * -> List *` **must** return a list that can contain **any** type. The only specific list that would fit the description is the empty list. | ||
| - Note the function would not only accept `[]` as argument, but any list! | ||
| Function arguments are allowed to be broad/general but the values you return must be specific. |
There was a problem hiding this comment.
@rtfeldman I feel like this last sentence is important but I"m not sure this is the best way to put it. I"m also not sure why precisely this is the case. It seems like we could arbitrarily allow (in type checking) to return e.g ["abc"] here as well, and it"s not obvious to me what problems that would create.
There was a problem hiding this comment.
It seems * has caused a good bit of confusion throughout the years. Are we sure we want to keep it? Especially because it is just syntactic suger.
There was a problem hiding this comment.
From what I can understand returning [ "abc" ] would make the "real" function signature List * -> List Str.
A List * as a return type would mean a List that can contain any type, since the moment you add an element you make that List a List (type of element you added) the only List capable of holding * typed items would be an empty one.
For the input type the interpretation changes to a List of elements of some type. So for the input, you don"t really care which type of elements you have on the List.
Maybe it"s a little confusing having the wording of "any type" and suddenly you have flashbacks as to how generics work in other languages.
There was a problem hiding this comment.
I"m also not sure why precisely this is the case. It seems like we could arbitrarily allow (in type checking) to return e.g ["abc"] here as well, and it"s not obvious to me what problems that would create.
I recall reading about this, I think it was in C# In Depth. Here"s Wikipedia on invariance instead, given that I don"t expect anyone to having a copy sitting around: [[Covariance and contravariance (computer science)]]1
If you read it: good for for you. If not: the list might be appended to, but if both the caller and receiver can choose what it is, they might choose differently and that"s a runtime error becuase lists can only contain one type (otherwise, you"d need unsoundness in the form of dynamic + casting or type unions. Either way is bad for performance, becuase you can"t allocate it up front if I understand correctly). Additionally, roc monomorphizes, so it picks the type at compile time, but it can"t do that if you"ve picked a type for it. The star is saying that it can fulfill whatever the caller wants, not the receiver.
Footnotes
-
Yes, that was for OOP languages, but it still applies. There"s no subtyping, but imagine a type of
Object(*) with a "subtype" ofStr(Do abilities allow emulating hierarchies? You might be able to get into this situation.). Additionally, while this is an issue for "mutable state,"Lists can "change," it"s just hidden from the user, particularly with opportunistic mutation. ↩
There was a problem hiding this comment.
It seems * has caused a good bit of confusion throughout the years. Are we sure we want to keep it? Especially because it is just syntactic suger.
It"s a reasonable question. Can you start a thread in #ideas? I"d like to hear what different people think!
There was a problem hiding this comment.
It seems * has caused a good bit of confusion throughout the years. Are we sure we want to keep it? Especially because it is just syntactic suger.
It"s a reasonable question. Can you start a thread in
#ideas? I"d like to hear what different people think!
As someone not on Zulip, I"ll just give my 2¢: It"s confusing. It makes sense, but it takes time to figure out. The second-to-last time I tried to use Roc, I gave up because the interplay between * and type aliases were annoying. It makes sense, just annoying. The learning curve (and the prohibition on them in type aliases) wouldn"t be there if they were gone 🤷♂️
There was a problem hiding this comment.
Thanks for sharing!
I know it"s a separate topic, but what was annoying about type aliases?
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
There was a problem hiding this comment.
It"s a reasonable question. Can you start a thread in #ideas?
|
Thank you for your contribution! Sometimes PRs end up staying open for a long time without activity, which can make the list of open PRs get long and time-consuming to review. To keep things manageable for reviewers, this bot automatically closes PRs that haven’t had activity in 60 days. This PR hasn’t had activity in 30 days, so it will be automatically closed if there is no more activity in the next 30 days. Keep in mind that PRs marked |
Fixes #5038
This PR adds a little bit more context to the wildcard type as discussed in the zullip chat.
It also adds the roc-cli package to the
devShellin theflake.nix. This was done because thewww/build-dev-local.shbash script needs roc to run.