TDNR without new operators or syntax changes
Jeremy
voldermort at hotmail.com
Sun May 22 15:01:07 UTC 2016
Bertram Felgenhauer-2 wrote
>> 1. If the compiler encounters a term f a, and there is more than one
>> definition for f in scope (after following all of the usual rules for
>> qualified imports);
>>
>> 2. And exactly one of these definitions matches the type of a (or the
>> expected type of f if given);
>>
>> 3. Then this is the definition to use.
>
> I now find that Anthony's concerns are justified. The question is, what
> exactly does the type matching in step 2 involve? If it is a recursive
> call to the type-checker then you'll have a huge performance problem.
I was concerned about this, but not knowing anything about how
type-checking/inference is implemented, I wouldn't know if this is actually
a problem or not.
> If, on the other hand, you only take into account what is known about
> the type of a at a given time, then you need special treatment for
> unambiguous names or even trivial programs will fail to type-check, just
> as Anthony said.
Why special treatment for unambiguous names? They shouldn't be effected at
all by this.
--
View this message in context: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-changes-tp5835927p5836393.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.
More information about the Glasgow-haskell-users
mailing list