On Saturday, 1 September 2018 19:26:00 UTC+2, Scott Cotton wrote:
>
>
>
> 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> 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
>> }
>>
>
Forgot to give an example for unifying this:
contract Reader(r Reader, rs ...Reader) .....
which would allow heterogenous arguments.
This example is certainly not posed as a global solution to heterogenous
type arguments, but just to give another example
that it could work.
>
>> 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.
>>> 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.
