Also, I did read what you wrote. I questioned “what happens when you have N
different generic types in the call signature. The select type statement has
N*N cases. “. You did not respond.
On Sep 19, 2018, at 4:26 AM, Wojciech S. Czarnecki <o...@fairbe.org> wrote:
>> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT) mhhc...@gmail.com wrote:
>
> The **stated** goal for adding some kind of generics to Go is
> and always was "how to not repeat writing same code just for a type".
>
> Now above practical goal, in minds of many, somewhat morphed
> to "Yeah, lets have real true generics so we can write/reuse
> smart and clever code we once upon a time wrote for c++/java".
> "So we need a way of expressing generic data in terms of other
> generic data then use abstract alghoritm on that".
> (Yep, team's proposal use: "in terms of operations")
>
> It now poisons all the proposals I've seen with syntax that
> forces **user** of the code to **repeat** at the **call site**
> type identifier for the sake of "code instantiation".
>
> Why? I think that's a mark of "one proper way for doing generics" burnt
> on the popular mindset. As hard to overcome as notion that one needs
> 'implements/implementing' to use interfaces.
>
> Does Go2 should have "implements" keyword added too?
> `type mytype struct{...} : implements io.Writer, ..., ...`
>
> What?! "Compiler knows whether your type satisfies an interface"
>
> Yeah, and at the call site compiler **does know** the parameter
> type too. This is the CGG basis.
>
>
> 1. Find a way to write "some Go code" that is suitable for set of
> types that have "something" in common.
>
> 2. Find a way to describe the set via the "something common"
> that implementation for said set will use on objects of matching types.
>
> 3. It **MUST** read as Go: no instantiation at call site.
>
>
> On Tue, 18 Sep 2018 15:22:01 -0700 (PDT)
> mhhc...@gmail.com wrote:
>
>> I was referring to this code
>>
>> func (x type []K) Sum() (r type K) {
>> }
>>
>
>> I did not understand how "// For var x []AnyType. ANY. " relates to
>> previous code.
>
> Previous code example was specific to `big.Int` type. Next I gave
> a really generic usage example via the constraint that already is
> described in CGG proposal: "type with given method implemented".
>
> With that constraint func Sum can be called on _any_ type that has
> a method (*T) Add(T,T). And someone writing new code needs not to
> change generic lib (as imputed), but she needs to provide for her
> non-numeric or peculiar type a method (*T) Add(T,T). Then Sum works.
>
>> for your question about the rune, i guess it d be like this
> [...]
>> Consider Z,K as virtual types to be inferred from the call site.
> Progress! As to inferred :)
>
> But I wanted return to be a string with sum of runes from all
> input strings :) Leave it.
>
> In CGG such specialization takes place in a single to find and simple
> to **read** 'case' code. The proposal's example Sum already has a single
> piece of code that will be **reused** for all numerical types that user
> **might** declare off builtin. With only two for type cases CGG's generic
> Sum spans all types with numerical base and all types that provide their own
> "me plus operator". With one case more it allows for set of types that have
> "plus me operator". Code that can and will run for multitude of user types.
>
> Yet I still hear stubborn "not reusable!, not reusable! not generic!".
>
>> In regards to Russ Cox proposal this code is missing
>> their explicitly declared contracts and the function instances declaration.
>> On the other hand, this is so much more readable *to me*.
>
> The "real true generics" proposals are readable to people who took the
> time and the training to accommodate to such List<Map<Hashable,Tuple>>
> syntactical mess. But it is **against** Go philosophy of "readability first".
> It excludes the legion who finds mental instantiations cumbersome at
> reading time. It shifts their thought from "what this will do" to "in what
> shape it will be".
>
>
>> maybe it looks likes c++, i did not think it was a concern
>> as long as it respected desired behaviors of good error reporting,
>
> It IS a MAIN concern. In fact it is a concern that the Go
> team explicitly stated as a reason why Go1 is generics free.
>
>> good readability,
> It has **no** readability for all but c++/java conditioned
> and is an inexhaustible source of confusion in other languages
>
>> ease of usage.
> leading to ubiquitous C&P in java/c++ application of generic libs.
>
>> speed of compilation,
> [I assume it was not about c++ compiling]
>
> With CGG a single significant change to current gc parsing will
> be in marking 'func' node so parser could swap the subtree when
> it will see 'for type' while in declaration body.
>
> The only bigger chunk of new code in gc will be for contract
> parsing and matching. Everything else needed for fast CGG
> implementation already is working in the current gc.
>
> [ c++ and like approach ]
>> proven useful
> Proven as a source of confusion and bugs in analysis
> linked above in thread (thanks for the link, Robert :).
>
>> and workable etc
> Workable and ubiquitous. Like 'implements' before Go.
>
>> Anyways, I am polluting the thread against this proposal, sorry for that.
>
> It is not a pollution, really. I am glad I can discuss both "we need no
> generics" and "we need practical approach" topics with avid users of
> c++/java style generics. It may show me how to simplify and specify
> my description of "craftsman's ways" to all c++<enslaved> :)
>
> P.S. (All) Take my apologies for "javish and cpluplusish" sarcasm.
> I just am a bit resentful when I am pushed to fight strawmen about
> CGG possibilities. Described, tabularized even, but not read. Not
> to mention understood.
>
> I am patiently waiting for someone who at last will use the slider
> and will read CGG proposal past the top example. Someone
> leaving "it's not about generics I know" impulses aside.
>
> CGG is not about known, CGG proposal is about reusable code
> written "in Go I know" hence easy to read and understand.
>
>
> Peace,
>
> --
> Wojciech S. Czarnecki
> << ^oo^ >> OHIR-RIPE
>
> --
> 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.
