TypeDirectedNameResolution: Difference between revisions
Benmachine (talk | contribs) m (hask not haskell) |
No edit summary |
||
| Line 11: | Line 11: | ||
Names of people who would positively like to see TDNR happen (say briefly why) | Names of people who would positively like to see TDNR happen (say briefly why) | ||
* Simon PJ (I wrote the proposal) | * 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 | Names of people who think that on balance it's a bad idea | ||
| Line 18: | Line 19: | ||
* A lot of people have commented that using <hask>.</hask> for this as well as composition and qualification is going to start getting confusing. One alternative suggestion was <hask>-></hask> but this would conflict with case branches and lambda syntax. Similar things like <hask>~></hask> or <hask>--></hask> could work too, but look a little uglier. | * A lot of people have commented that using <hask>.</hask> for this as well as composition and qualification is going to start getting confusing. One alternative suggestion was <hask>-></hask> but this would conflict with case branches and lambda syntax. Similar things like <hask>~></hask> or <hask>--></hask> 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 <hask>a#f</hask> be an option?).[[User:Daniel.is.fischer|Daniel.is.fischer]] 21:06, 17 November 2009 (UTC) | |||
Revision as of 21:06, 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).
- The TDNR proposal
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
- fill in here
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)