Yes, that's essentially it – except that since we haven't converged on a
particular design, it's hard to say exactly what interfaces are at this
point. But yes, it's something that provides a first class representation
of some protocol/interface.
On Mon, Oct 17, 2016 at 11:33 AM, Brian Rogoff wro
On Thursday, October 13, 2016 at 1:00:21 PM UTC-7, Stefan Karpinski wrote:
>
> No, Function doesn't have signatures, arity or return type as part of its
> type. The signature of a function is the union of its method signatures,
> which is potentially very complicated. Type parameters are not
> c
On Thu, Oct 13, 2016 at 12:26 PM, Brian Rogoff wrote:
> Great summary, thanks so much!
>
> Being a fan of typeful functional programming, I really like the return
> type annotations and FP performance improvements. Is there a way to
> describe a precise return type for a higher order function? Th
On Wednesday, October 12, 2016 at 9:40:27 PM UTC-4, Steven G. Johnson wrote:
>
>
>
> On Wednesday, October 12, 2016 at 9:26:54 PM UTC-4, Stefan Karpinski wrote:
>>
>> That's a fair point. It seems like it could/should be handled by the same
>> (not-yet-implemented) mechanism that ensures that `c
On Wednesday, October 12, 2016 at 9:26:54 PM UTC-4, Stefan Karpinski wrote:
>
> That's a fair point. It seems like it could/should be handled by the same
> (not-yet-implemented) mechanism that ensures that `convert(T,x)::T` is
> true. Of course, we could choose to enforce this fact via lowering
That's a fair point. It seems like it could/should be handled by the same
(not-yet-implemented) mechanism that ensures that `convert(T,x)::T` is
true. Of course, we could choose to enforce this fact via lowering in this
case, independent of enforcing it for convert.
On Wed, Oct 12, 2016 at 7:40 PM