On Saturday, 1 September 2018 18:26:29 UTC+2, Axel Wagner wrote:
>
> On Fri, Aug 31, 2018 at 6:57 PM Scott Cotton <w...@iri-labs.com
> <javascript:>> wrote:
>
>> My intuition is that interfaces would be obsolete -- and that's a very
>> good thing.
>>
>
> They wouldn't. You can't have heterogeneous lists with contracts. For
> example, say you have a Reader contract:
>
> contract Reader(r R) {
> var (
> n int
> err error
> p []byte
> )
> n, err = r.Read(p)
> }
>
> You can't use that to implement, say, io.MultiReader:
>
> func MultiReader(type R Reader) (readers ...R) R {
> return &multiReader{readers} // Type error: Must return R, not
> *multiReader
> }
>
I don't think there would be a type error as follows:
fun MultiReader(type R Reader) (readers ...R) Reader {
return &multiReader{readers}
}
>
> func Foo() {
> r1 := bytes.NewReader([]byte("Hello "))
> r2 := strings.NewReader("world")
> r3 := MultiReader(r1, r2) // Type error: Uses different types in
> places of R
> }
>
> Saying that contracts subsume interface is a bit like saying that generic
> functions in Haskell subsume type classes. They are different things with
> different (but overlapping) uses.
>
They are different things so far as Haskell is concerned, and probably
traditionally w.r.t. type theory. But a little thinking outside the box
and a tweak of allowed syntax (together with whatever rabbit holes that
might force a type checker into) such as the above may unify them...
I don't think examples of it not working constitute valid arguments that
they aren't unifiable in a practical or theoretical way.
My type theory definitely could use a refresher for discussing this in
formal detail. As the idea of unifying interfaces and contracts is not
formalised, just some intuitions of at least one so far, I don't think one
could even legitimately arrive at a proof that they are not unifiable,
since there is no agreed upon a priori formal framework to arrive at such
conclusions.
Scott
>
> You could implement interface
>> in terms of contract as some sort of bridge for compatibility. But if
>> the proposal could come up with a way to extend the interface syntax with
>> contract-like semantics, perhaps the overlap between the two could just
>> disappear.
>>
>> As for the question in the proposal about implementation by interface or
>> not (compilation speed
>> vs execution speed), my own use cases often require re-thinking something
>> without interfaces
>> (like the heap in my sat solver) for performance. Here's a thumbs up for
>> execution speed and
>> hearty "go for it" for compiler writers to make it fast :)
>>
>> Nice work on the proposal.
>>
>> Scott
>>
>> On Friday, 31 August 2018 18:47:45 UTC+2, Daniela Petruzalek wrote:
>>>
>>> I agree with Tristan in regards to orthogonality.
>>>
>>> Seeing the draft with all those complexities added to the language made
>>> me quite uneasy about this proposal. When I first started learning Go I was
>>> one of the first people to raise a hand and complain about the lack of
>>> generics in the language. Now, a year later, after learning about Go proper
>>> idioms, I strongly regret my previous stance. I was trying to make Go
>>> another language that was not Go. I didn't want to learn to write idiomatic
>>> Go code, I wanted to write Go in the same way I used to write C++ (for
>>> instance). That was wrong on so many levels.
>>>
>>> I'm now sitting in the fence in regards to the generics addition to the
>>> language. My previous arguments don't hold anymore. I like how the current
>>> Go language forces our intentions to be explicit rather than hiding the
>>> real code under some clever abstractions that few people understand. I feel
>>> that I became a better programmer that way, thinking about the collective
>>> before trying to please myself showing how smart I am. I feel it also
>>> encourages collaboration since it's really easy to get an overall
>>> understanding of the language. It's accessible for junior developers and
>>> enthusiasts since there are fewer concepts to learn, yet they provide some
>>> powerful abstractions. Look at the things that were built with Go...
>>> Kubernetes, Docker... it's a really powerful language while still being
>>> truthful to its simplified flow control, simplified (yet verbose) error
>>> handling, simplified data structures...
>>>
>>> I strongly wish that a generics proposal would stay true to the Go's
>>> simplicity principle, but I somehow don't feel this proposal does meet that
>>> requirement at it's current state.
>>>
>>> Sorry to hijack the thread!
>>>
>>> Best,
>>>
>>> Dani
>>>
>>> Em sex, 31 de ago de 2018 às 10:54, Tristan Colgate <tcol...@gmail.com>
>>> escreveu:
>>>
>>>> Also, and I think this probably applies to the existing syntax in the
>>>> design.
>>>> This example seems like a pathological use of generics. What would be
>>>> the advantage over just declaring the function takes a Stringer? Am I
>>>> missing something (presumably this is potentially avoids the interface
>>>> call
>>>> allocation?).
>>>> This is a good example of my gut feeling about generics, I realise
>>>> they'll be valuable, but do they devalue interfaces? They do not seem like
>>>> an orthogonal feature. Of the two, interfaces feel like they encourage me
>>>> to write better structured code.
>>>> This could also just be fear of change.
>>>>
>>>>
>>>> On Fri, 31 Aug 2018 at 14:34 'Axel Wagner' via golang-nuts <
>>>> golan...@googlegroups.com> wrote:
>>>>
>>>>> A contract can include multiple type parameters:
>>>>> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#mutually-referential-type-parameters
>>>>> AIUI your syntax can't cover that. And FWIW, I find the syntax of
>>>>> contracts in the doc far less "magic" than yours, but YMMV of course.
>>>>>
>>>>> On Fri, Aug 31, 2018 at 6:43 AM Manlio Perillo <manlio....@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I just read the "official" proposal for Go2 generics and contracts.
>>>>>> The current proposal makes the function syntax more complex, and the
>>>>>> syntax for the contract is a bit magic.
>>>>>>
>>>>>> What about something like:
>>>>>>
>>>>>>
>>>>>> type stringer template
>>>>>>
>>>>>> contract (x stringer) {
>>>>>> var s string = x.String()
>>>>>> }
>>>>>>
>>>>>> func Stringify(s []stringer) (ret []string) {
>>>>>> for _, v := range s {
>>>>>> ret = append(ret, v.String())
>>>>>> }
>>>>>> return ret
>>>>>> }
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>>
>>>>>> contract stringer(x T) {
>>>>>> var s string = x.String()
>>>>>> }
>>>>>>
>>>>>> func Stringify(type T stringer)(s []T) (ret []string) {
>>>>>> for _, v := range s {
>>>>>> ret = append(ret, v.String())
>>>>>> }
>>>>>> return ret
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Manlio
>>>>>>
>>>>>> --
>>>>>> 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.
>>>> 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.
