What is the right way to propose changes for the manual? A PR on the trunk branch?
I’m seeing a lot of little bugs. Like the following from the section on value restriction: “…the type checker considers that any value returned by a function might rely on persistent mutable states behind the scene and should be given a weak type.” Any value?
I am not sure what is your issue with the wording in this specific case?
It would mean that the return type for every function is weak.
Here’s what I think the intended meaning is:
".type checker considers that any function return value that relies on persistent mutable states behind the scene should be given a weak type.”
I could be wrong but that’s my point, it needs clarification.
Which is indeed the case?
Now I’m totally flommoxed. What is the type of, say, let f x = 3
? Here 3 is a value returned by a function?
We may be misunderstanding each other? Are you saying that it is the case that every function return type is weak?
I confess I do not entirely grok the whole “weak” thing. I like to think that’s because it is poorly explained but it could be because I’m dense. Bear with me, please.
The return type of every function application is weak indeed, as illustrated by the type of
let add_parenlike left right show x =
String.concat "" [left; show x; right ]
let add_brace = add_parenlike "{" "}"
where there is no mutable states in sight (to change from the usual make_id
example).
When the return type of a function doesn’t contain type variables, this is an invisible detail.
Consequently, it might be better to avoid the shortcut weak
type. Maybe a type which is at most weakly polymorphic
?
To answer the original question, and avoid subconsciously gate-keeping since I wrote the extract currently under scrutiny, opening PRs on trunk is the right way to proceed for PRs on the manual.
1 Like
Thanks! As for the example (weak etc.): thank you very much. Gimme about 6 months…
(to try to understand, I mean)