I would also require types for polymorphism. All inferred types should be
monomorphic, bar top level functions (and maybe let's).

I like Mark Jones' FCP, where first class polymorphism uses data types, so
you don't have to have any type annotations in function definitions. This
is nice if we consider records to be modules.

If you then allow implicits, records can become type - classes too, along
with type families providing associated types you get:

modules = records = type-classes

But thats just my preference.

Keean.
 On 12 Feb 2015 15:26, "Jonathan S. Shapiro" <[email protected]> wrote:

> On Thu, Feb 12, 2015 at 1:21 AM, William ML Leslie <
> [email protected]> wrote:
>
>> BitC's intended audience has additional bearing on this, and that is what
>> we're trying to discuss.  BitC cannot entertain the same level of magic as
>> other languages might be able to get away with.  We want native performance
>> out of what may be generic or higher-order calls.
>>
>
> That's very well said.
>
> But Keean is aware that we have done at least a day or two of work on type
> systems. I think that he is wrestling with an un-voiced distaste, and I
> think his distaste is well-founded. I have been wrestling similarly, and it
> is only this morning that I can put words on the issue (I hope):
>
>   If function types carry arities, we lose both principal types and most
> general types
>
> I'm not that worried about principal typings. GADTs are good things, and
> once we admit them there isn't a principal type anymore.
>
> The loss of "most general type" is more serious. If we then go ahead and
> adopt Option 3 (implicit lambdas), then this *particular* loss of most
> general types has no impact on program behavior. But it is definitely true
> that we will have cases that can validly be inferred with two different
> interpretations, and this is generally a bad thing from a type
> reconstruction perspective. At the very least, it will mean that there are
> places where we will require annotations that would otherwise be
> unnecessary. No often, but sometimes.
>
> Note, however, that I'm not convinced we should still be doing global
> inference (for several reasons). If we are only doing local inference, this
> whole problem ceases to be a concern at all.
>
> I'd kind of like not to back off that far. I'm presently considering
> whether the combination of declared types at module boundaries plus
> whole-module compilation is "local enough" to keep inference decidable in
> the presence of polymorphic recursion and certain kinds of overloading.
>
>
> shap
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to