Difference between revisions of "TypeDirectedNameResolution"

From HaskellWiki
Jump to: navigation, search
(add my dislike)
Line 14: Line 14:
Names of people who think that on balance it's a bad idea
Names of people who think that on balance it's a bad idea
* '''fill in here'''
* Ganesh Sittampalam (see http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723 ; I think that having constraints you can't quantify over is a bad idea. However if that is fixable I'd be generally in favour.)
= Other comments =
= Other comments =

Revision as of 22:08, 17 November 2009

Type directed name resolution

This publicly editable page is a place to summarise comments on the Haskell Prime proposal for Type Directed Name Resolution (TDNR).

Straw poll

It's hard to gauge how much people like proposals like this, so let's try the experiment of collecting votes here:

Names of people who would positively like to see TDNR happen (say briefly why)

  • Simon PJ (I wrote the proposal)
  • Daniel Fischer (I think it would be an improvement to the language. I have not much missed it yet, so I don't feel strongly about it, though.)

Names of people who think that on balance it's a bad idea

Other comments

  • A lot of people have commented that using . for this as well as composition and qualification is going to start getting confusing. One alternative suggestion was -> but this would conflict with case branches and lambda syntax. Similar things like ~> or --> could work too, but look a little uglier.

However, I think a little ugly is preferable to confusing or conflicting with syntax. I think using '.' won't be too confusing (we all separate the composition operator from the functions by a space anyway, don't we?), so I'd go with that. But rater than letting it die over '.'-ambiguity, I'd choose a different notation (would a#f be an option?).Daniel.is.fischer 21:06, 17 November 2009 (UTC)