Remove as many uses of Sized Types as possible #3051
Replies: 3 comments 1 reply
-
|
Thankfully, #3025 was relatively 'easy' because the explicit mutual recursion needed to side-step the original use of sized types was fairly orthodox, and moreover could be encapsulated (largely) to avoid having to be mutual; subsidiary auxiliary recursions sufficed. I'm not across what's needed for the two other candidates you identify, though. But the general message is clear and correct! Modulo: in the absence of any settled story about all the various approaches to
I think it should nevertheless also retain material which shows a range of 'ways you could tackle implementing something' for external projects/users. Otherwise, such 'failed'/'unsafe' experiments get lost in the history? Unless we take care to carefully document a summary |
Beta Was this translation helpful? Give feedback.
-
|
I agree with James; the guardedness method forces us to use a deeply embedded DSL to build I believe they're also just more pleasant to use for programming in anger in which case the |
Beta Was this translation helpful? Give feedback.
-
|
Great, we seem to have reached a conclusion: let's not do this! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
As we know this is unsound, we should not be using that feature. The uses that are most worthy of adapting (after #3025 's fix of
Data.Tree.Rose) would beData.TrieData.ContainerData.Nat.PseudoRandom.LCG.Unsafealso uses these, but since it's unsafe, I am less concerned. I would want to remove all ofCodata.Sized.*.The reasoning is simple: we should not use known unsound features, especially some where there are no known plans to fix them.
Beta Was this translation helpful? Give feedback.
All reactions