It's always seemed to me that field labels in records are more constructor-like than term-like. And pattern-matching on them is more like using them as (de-)constructors. But H98 records create a selector function named for the field; and because it's a function it must be term-like. TRex field labels don't suffer this restriction: you don't get a selector function; if you want a select by label from a TRex row, use the `#label row` syntax. Then I wondered: TRex labels appear only in a handful of syntax productions. How hard would it be to allow them to look like constructors? The answer is it's dead easy; you need only to change the syntax (in yacc plus a tweak to the lexer); you don't need to change any of the code for building/matching/typing rows. For now, I'm allowing labels to start either upper or lower case. Some example code here https://github.com/ghc-proposals/ghc-proposals/pull/160#issuecomment-4202721... In particular, there's an example defining a Lens `bar` over any Trex row containing a label `Bar`. (The main purpose of that definition is to demonstrate every syntactic construct in which TRex allows labels, so it could be terser.) Note that unlike Lenses over H98 style records, this doesn't need an overloading for each different datatype containing a label of some name. My jazzy name for such Lense is 'OpTRex', as imagined here https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-4140604... AntC