Richard, could you consider making a playlist of your videos that are aimed more at beginners, like this and the one on explaining GHC error messages from last year? I'm just getting into Haskell and finding your vids really engaging, but some of the go quite a bit over my head!
There's now a pretty heinous record update dark corner due to a simplification in 9.4 with DuplicateRecordFields, which is that it's impossible to have two records with the same field name in scope and use the record update syntax to update that field. This will fail because it's allegedly ambiguous: only sets of fields uniquely matching one type are acceptable. No such problem with construction because unlike update, you name the constructor. It was removed per a ghc proposal to get rid of bidirectional typechecking it caused, but there is no clear way to do this in the OverloadedRecordDot kind of way. Thus we get functions like updateF SomeRec{..} field = SomeRec{..}
Just a thought (which I haven't tested): does desugaring all record updates like you have on line 17, basically eliminating the record update entirely and instead just creating a new record afresh by copying all the fields solve the problem in all cases, or does it still leave or create new dark corners? Or are there some cases where such a desugaring can't be applied?
We need a LambdaRecordUpdate extension to match LambdaCase: f = \{ foo = 5 } or f = \.{ foo = 5} -- read as 'f passes its argument with the foo field set to 5'
Richard, could you consider making a playlist of your videos that are aimed more at beginners, like this and the one on explaining GHC error messages from last year? I'm just getting into Haskell and finding your vids really engaging, but some of the go quite a bit over my head!
There's now a pretty heinous record update dark corner due to a simplification in 9.4 with DuplicateRecordFields, which is that it's impossible to have two records with the same field name in scope and use the record update syntax to update that field. This will fail because it's allegedly ambiguous: only sets of fields uniquely matching one type are acceptable. No such problem with construction because unlike update, you name the constructor.
It was removed per a ghc proposal to get rid of bidirectional typechecking it caused, but there is no clear way to do this in the OverloadedRecordDot kind of way. Thus we get functions like
updateF SomeRec{..} field = SomeRec{..}
7:40 imagine some record update changing your safe-money Dense "USD" to some Dense "RUB", that'd be a pain to debug
Will the GHC updates you mention be an enabler for updates with record.dot.syntax?
Just a thought (which I haven't tested): does desugaring all record updates like you have on line 17, basically eliminating the record update entirely and instead just creating a new record afresh by copying all the fields solve the problem in all cases, or does it still leave or create new dark corners? Or are there some cases where such a desugaring can't be applied?
We need a LambdaRecordUpdate extension to match LambdaCase: f = \{ foo = 5 } or f = \.{ foo = 5} -- read as 'f passes its argument with the foo field set to 5'