> 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.
