On 12/02/2012, at 02:39, Greg Weber wrote:

> This proposal stands on its own
> * the dot operator is inconsistent with Module function selection.
> * we are allowed the option of expanding the usage of the dot without
> spaces if this proposal goes forward.
> 
> The point is that we will decide whether or not to expand the usage of
> the dot in the *future*. We could decide on a completely different
> usage than record field selection.

Then we will have broken a lot of code just to remove a tiny inconsistency from 
the language. That really doesn't sound like a good idea to me.

> If this proposal is not compelling enough on its own we should merge
> it with other proposals and discuss them together as a single new
> concrete proposal.

Personally, I would much prefer this.

BTW, after looking through the relevant Wiki pages I think the proposal is 
actually underspecified. The TDNR page introduces a new lexeme for .var_id. 
This is quite easy to integrate into the grammar and to parse but it means that 
(f).(g) and (f. g) still both parse as function composition applied to f and g. 
The DotOperator page, however, seems to require that neither of these parse as 
function composition. But in that case, what does the grammar look like for 
'.'? More specifically, what does Text.Read.lex return for the two examples?

Roman



_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Reply via email to