You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could generate code that is easier to read if we use do notation.
This topic came up during implementation of the preprocessor backend, as an alternative to long infix operator chains that resulted in extremely long lines. We ended up implementing special-case formatting for these, however, so that particular issue is resolved.
>> Example
Using a do block would produce code that is more like what users would write by hand.
Applicative construction (pure MkCFoo <*> peekByteOff x0 0 <*> ...) is generally not good for maintenance because the constructor arguments are specified by order. When arguments are added/changed/deleted, it can be easy to make mistakes that lead to bugs. I generally write do blocks where each argument is bound to the field name, and RecordWildCards is used to return the constructed value. In our case, use of applicative construction is not an issue because the code is generated and such changes/maintenance is therefore automated. Binding to field names, however, makes it very easy for users to confirm offsets in the example below.
We could generate code that is easier to read if we use
do
notation.This topic came up during implementation of the preprocessor backend, as an alternative to long infix operator chains that resulted in extremely long lines. We ended up implementing special-case formatting for these, however, so that particular issue is resolved.
>>
ExampleUsing a
do
block would produce code that is more like what users would write by hand.Current
Suggestion
<*>
ExampleApplicative construction (
pure MkCFoo <*> peekByteOff x0 0 <*> ...
) is generally not good for maintenance because the constructor arguments are specified by order. When arguments are added/changed/deleted, it can be easy to make mistakes that lead to bugs. I generally writedo
blocks where each argument is bound to the field name, andRecordWildCards
is used to return the constructed value. In our case, use of applicative construction is not an issue because the code is generated and such changes/maintenance is therefore automated. Binding to field names, however, makes it very easy for users to confirm offsets in the example below.Current
Suggestion
The text was updated successfully, but these errors were encountered: