StricterLabelledFieldSyntax
Iavor Diatchki
iavor.diatchki at gmail.com
Sun Jul 26 14:57:56 EDT 2009
Hello,
I am strongly against this change. The record notation works just
fine and has been doing so for a long time. The notation is really
not that confusing and, given how records work in Haskell, makes
perfect sense (and the notation has nothing to do with the precedence
of application because there are no applications involved). In short,
I am not sure what problem is addressed by this change, while a very
real problem (backwards incompatibility) would be introduced.
-Iavor
On Sun, Jul 26, 2009 at 8:52 PM, Isaac
Dupree<ml at isaac.cedarswampstudios.org> wrote:
> Sean Leather wrote:
>>
>> To me, the syntax is not actually stricter, just that the precedence for
>> labeled field construction, update, & pattern is lower. What is the
>> effective new precedence with this change? Previously, it was 11 (or
>> simply
>> "higher than 10"). Is it now equivalent to function application (10)?
>
> maybe it's equivalent "infix 10" (not infixr/infixl) so that it doesn't
> associate with function application (or itself) at all, either left- or
> right- ly. I didn't understand by reading the patch to the report...
>
> Ian Lynagh wrote:
>>
>> I think that even an example of where parentheses are needed would be
>> noise in the report. I don't think the report generally gives examples
>> for this sort of thing, e.g. I don't think there's an example to
>> demonstrate that this is invalid without parentheses:
>> id if True then 'a' else 'b'
>
> Well that's also something that in my opinion there *should* be an example
> for, because IMHO there's no obvious reason why it's banned (whereas most of
> the Report's syntax repeats things that should be obvious and necessary to
> anyone who knows Haskell).
>
> -Isaac
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
More information about the Haskell-prime
mailing list