Re: [GitHub] dylex sent you a message
Geoffrey Irving
>
>
> dylex wants you to pull from dylex/duck at 1e90426
>
> Body: If you're okay with "TypeSet", we can go with this. I couldn't think of anything better... Unify, TypeOps...
>
> View repository: http://github.com/dylex/duck/tree/1e90426eadf7ecc8a6e247186cb3a111dfed0040
We should definitely rename either TypeSet or TypeSet. Calling the
operations module TypeSet seems reasonable if we're documenting and
thinking about it in terms of set operations. For the same reason,
calling the type TypeSet is confusing, since Type also represents a
set. I think renaming the type is better.
How about "Types"?
Geoffrey
Dylan Alex Simon
> operations module TypeSet seems reasonable if we're documenting and
> thinking about it in terms of set operations. For the same reason,
> calling the type TypeSet is confusing, since Type also represents a
> set. I think renaming the type is better.
>
> How about "Types"?
That could be okay. The critical difference is that it can by polymorphic,
though, not plural, yes? So what about PolyType or TypeMono sorts of things?
> Therefore, this might be something we want to do. Let's leave it as a
> proposal for a while and see if we like it later. In particular, it'd be
> good to know how hard it is to improve the error messages resulting from
> backtracking in the case we already have before adding another source of
> backtracking.
Right, this is what I'm working on now. It came up because of the question:
is the error "ambiguous overload" ever recoverable. That is, if we do decide,
through whatever resolution method we're using, that a particular overload
call is ambiguous, is this an error that should be caught by applyTry? I can
think of convoluted cases where it might work to then find a different
resolution, but it doesn't seem like we should necessarily, since an ambiguous
overload is never good.
:-Dylan
Geoffrey Irving
>
>> We should definitely rename either TypeSet or TypeSet. Calling the
>> operations module TypeSet seems reasonable if we're documenting and
>> thinking about it in terms of set operations. For the same reason,
>> calling the type TypeSet is confusing, since Type also represents a
>> set. I think renaming the type is better.
>>
>> How about "Types"?
>
> That could be okay. The critical difference is that it can by polymorphic,
> though, not plural, yes? So what about PolyType or TypeMono sorts of things?
Actually, I think TypePat or TypePattern is best, since it's the same
as a pattern match in spirit.
>> Therefore, this might be something we want to do. Let's leave it as a
>> proposal for a while and see if we like it later. In particular, it'd be
>> good to know how hard it is to improve the error messages resulting from
>> backtracking in the case we already have before adding another source of
>> backtracking.
>
> Right, this is what I'm working on now. It came up because of the question:
> is the error "ambiguous overload" ever recoverable. That is, if we do decide,
> through whatever resolution method we're using, that a particular overload
> call is ambiguous, is this an error that should be caught by applyTry? I can
> think of convoluted cases where it might work to then find a different
> resolution, but it doesn't seem like we should necessarily, since an ambiguous
> overload is never good.
If it takes very little code for applyTry to not catch ambiguity
errors, it seems like it's best to not catch them for now. That way
we'll learn whether not catching them is a nuisance. If we go the
other way, we'll probably never learn.
Geoffrey
Dylan Alex Simon
> >> operations module TypeSet seems reasonable if we're documenting and
> >> calling the type TypeSet is confusing, since Type also represents a
> >>
> >> How about "Types"?
> >
> > That could be okay. ?The critical difference is that it can by polymorphic,
> > though, not plural, yes? ?So what about PolyType or TypeMono sorts of things?
>
> Actually, I think TypePat or TypePattern is best, since it's the same
> as a pattern match in spirit.
TypePat it is. Pull at your leisure.
:-Dylan
Geoffrey Irving
>
>
> dylex wants you to pull from dylex/duck at master
>
> Body: Big enough change that I'll let you sign off.
> You'll probably think the error messages are ugly, but they are efficient.
All good. Generally, going overboard with cleanup means that you do a
lot of cleanup, and things get a lot cleaner. :)
I like the error messages. However, typeMismatch needs to needs to
say whether it was trying union, equal, or intersect. For equal we
could do
type mismatch: 'List Int' != 'IO a'
but I don't know how to generalize that to union or intersect. !<=
probably isn't a good choice.
Geoffrey