On Mon, Sep 10, 2018 at 2:03 PM Jonathan Amsterdam <jbamster...@gmail.com>
wrote:
> You and many others have tried to replace contracts with interfaces.
>
Almost, but not quite. I and others have tried to replace contracts with
*something*. Preferably something declarative. ISMT interfaces fit the
bill *pretty
well*. In terms of formal properties (type-safety, static dispatch…) they
have, used as constraints, the same power that contracts have, while being
completely declarative.
You (and Ian) bring up valid points against the extensions in regards to
attempts to also fit operators into that. I think that's fine. But to me,
it seems to be mostly semantics. I was being sincere, when I said that, as
far as I'm concerned, we could also, e.g. introduce
ContractDecl = "contract" ContractName "{" { TypeName | InterfaceType |
ContractName } "}"
ContractName = Identifier
TypeParameters = "(" "type" [ TypeParameterList [ "," ] ] ")" .
TypeParameterList = TypeParameterDecl { "," TypeParameterDecl } .
TypeParameterDecl = [ IdentifierList ] ContractName .
and define a list of predeclared "ContractName" identifiers expressing the
capability to do certain builtin operations. To me, that's mostly
equivalent to what I described.
I'm just trying to create clarity around some things I consider technical
baseline facts:
a) That a interface-based approach to constraints isn't inherently less
powerful than contracts - there e.g. was the argument that it can't express
interdependence between types, which I consider false, as parametric
interfaces can do that.
b) that contracts - as designed - in terms of expressive powers only bring
the use of operators (without) wrapping with them over an interface-based
approach to constraints
And c) that an interface-based approach can be amended with a declarative
way to also bring in operators - let's call that "interfaces+".
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. 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
