On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote:
>
> On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam <jbams...@gmail.com
> <javascript:>> wrote:
>
>> FWIW, I think Ian's criticism of not wanting a list of new identifiers to
>>> express operator constraints is fair. It is a genuine roadblock to c) and
>>> if we're dead set of setting that as a baseline requirement, I agree that a
>>> declarative/interface-based approach won't work.
>>>
>>
>> I don't understand. Why are names so important? Why couldn't you use "T
>> == T" to mean "T is comparable"? Or "To(From)" to mean "From is convertible
>> to To"?
>>
>
> It's not the name that is important, it's the declarative nature. I and
> other people have already gone into detail with the problems we are having
> with using imperative constructs to define constraints (mainly that they
> are ambiguous and that it's hard both to enumerate the sets allowed by a
> contract and to define a suitable contract for an intended set of
> constraints).
>
I completely agree with you there (although I find the
declarative/imperative terminology confusing). I think that except for
interface-like constraints, we should be constraining by broad properties
of types like comparable, ordered and numeric, rather than specific
operations.
>
>
I don't care if the declarative instruction is called "flooglehorn" or
> "comparable". But I do care that it's an an actual declaration, mapping 1:1
> in a clear way to intent. Not an ambiguous statement from Go's current
> Grammar.
>
It wouldn't be ambiguous. The spec would say "in type constraints, `T == T`
means that T is comparable". I think people would learn to understand that,
just as they understand that for a type T, `*T` means "pointer to T," not
"dereference T".
>
>
> Personally, I don't think that should be a requirement. Personally I think
>>> it's worth adding extra identifiers, if we get declarative constraint-specs
>>> for that - but that's just my opinion and everyone has one of those.
>>>
>>> But the issues you are bringing up are IMO not "fundamental'. a) to c)
>>> from above aren't really touched by your criticism, AIUI. To me, they seem
>>> like issues of syntax and how to phrase the spec.
>>>
>>> But if generics are to have operator constraints like T == T, then
>>>> something in the language has to change. Either not all interfaces are
>>>> types, or some interfaces have methods that can't be called, or Go
>>>> operators can have operands of different types. These changes are not
>>>> minor
>>>> tweaks: they alter fundamental aspects of the language.
>>>>
>>>> Contracts, on the other hand, are purely additive. They only come into
>>>> play when writing generic code. If I'm not mistaken, the draft design
>>>> doesn't change or even add anything to non-generic Go. There is something
>>>> attractive about that orthogonality.
>>>>
>>>
>>> I agree. I think that's fair. I don't think for that they need to be
>>> imperative specifications though.
>>>
>>> (or, allow embedding interfaces into contract-declarations, remove the
>>>>> "type-checking function body" idea and instead define a set of
>>>>> base-contracts you can use for operators) and you'd end up with pretty
>>>>> much
>>>>> my design.
>>>>>
>>>>
>>>> That doesn't sound like your original design at all.
>>>>
>>>
>>> You need to squint harder :) From the rest of your mail, ISTM that we
>>> are putting emphasis on different aspects of my description and the
>>> contracts design. What I was trying to say is that IMO the things about my
>>> design I like and the things about the contract design you like can
>>> probably be reconciled.
>>>
>>> The first seems problematic, because for multi-parameter contracts you
>>>> wouldn't know which type the parameter referred to.
>>>>
>>>
>>> FWIW (we are now getting lost in ifs-and-buts and it's no longer clear
>>> what the specific ideas are we are talking about), in my original design as
>>> well as that ad-how handwaving you're quoting, constraints always apply to
>>> a single type and you'd use parametric interfaces (or… interfaces+) to
>>> express simultaneous restrictions.
>>>
>>> But FTR, I did not intend to start an actual discussion around that, its
>>> far too underspecified for that. I was sincere when I said your criticism
>>> is fair and that I had to think about it. My handwaving was just to explain
>>> why I don't think it can justifiable be called a *fundamental* issue.
>>>
>>>
>>>> The second seems reasonable to me. Now we can talk about issues like
>>>> whether this adds too many names to the language, or whether you've
>>>> described all the important constraints (I think conversion and
>>>> assignability are important, for instance).
>>>>
>>>
>>> Again, the caveat of handwaving still applies (IMO we should constrain
>>> ourselves to talk about sufficiently spelled out designs - Ian's contract
>>> design qualifies and I'd also feel fine with the thing I wrote down in my
>>> blog, as long as we agree that its conditional on polishing the "are
>>> pseudo-interfaces usable as types" question), but: Given that we have
>>> type-parameters, adding that is fairly straightforward in the form of (in
>>> the words of my blog post) parametric pseudo-interfaces
>>> "convertible{To,From}(T)" and "assignable{To,From}(T)".
>>>
>>> But yeah, talking about in too much depth here would IMO constitute
>>> high-jacking of threads about Ian's design. I'm also totally cool to start
>>> a new thread about this after I had time to incorporate your feedback.
>>> Unfortunately this isn't my job, so I have to find time between other
>>> things :)
>>>
>>> Anyway. I think I've been ranty enough for today :)
>>>
>>> On Sunday, September 9, 2018 at 5:21:28 PM UTC-4, Axel Wagner wrote:
>>>>>
>>>>> I don't think saying that is is productive. contracts are more than
>>>>> just "identifiers used as constraints", they are also a syntactic
>>>>> construct
>>>>> to specify those. I specifically don't allow that and that's the whole
>>>>> point I'm making. So this doesn't seem like a particularly nice way to
>>>>> have
>>>>> a discussion.
>>>>>
>>>>> But yes, if it makes you happier, we can call them "contracts", allow
>>>>> to embed them into interfaces and remove contract declarations from the
>>>>> design (or, allow embedding interfaces into contract-declarations, remove
>>>>> the "type-checking function body" idea and instead define a set of
>>>>> base-contracts you can use for operators) and you'd end up with pretty
>>>>> much
>>>>> my design.
>>>>>
>>>>> On Sun, Sep 9, 2018 at 11:17 PM Jonathan Amsterdam <jbams...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote:
>>>>>>>
>>>>>>> On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam <
>>>>>>> jbams...@gmail.com> wrote:
>>>>>>>
>>>>>>>> The problem is that this program seems to type-check, but it is
>>>>>>>> invalid. The == operator is specified to work on operands of the same
>>>>>>>> type,
>>>>>>>> and it is being used on operands of different types.
>>>>>>>>
>>>>>>>
>>>>>>> Good point. I have to think about it. An ad-hoc solution, FWIW,
>>>>>>> would be to only take into account (or allow) pseudo-interfaces for
>>>>>>> type-constraints.
>>>>>>>
>>>>>>
>>>>>> The draft design has a name for those: contracts.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "golang-nuts" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to golang-nuts...@googlegroups.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "golang-nuts" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to golang-nuts...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
