@Bakul - is your approach documented in Egon's collection? I think it is
essentially the same as Egon's at
https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J
Perhaps your syntax is cleaner, simpler. I also like this general approach.
In Egon's document, this approach has nearly no downsides. Sounds like
@Michael Jones also would be happy this.
Cheers...
On Sunday, March 26, 2017 at 5:02:20 AM UTC-4, Egon wrote:
>
>
>
> On Sunday, 26 March 2017 05:15:10 UTC+3, Bakul Shah wrote:
>>
>> The simplest design I can think of (that does what you seem to
>> want) is to add parameterized packages. Here's a
>> stereotypical example:
>>
>> ========
>> package stack(T) // parameterized on stack element type
>> import "fmt"
>> type Type struct { rep []T
>> func New() *Type { &T{} }
>> func (stk *Type)Push(t T) { stk.rep = append(stk.rep, t) }
>> func (stk *Type)Pop()(T, error) {
>> var t T
>> ln := len(stk.rep)
>> if ln = 0 { return t, fmt.Errorf("Empty stack") }
>> t = stk.rep[ln-1]
>> stk.rep = st.rep[:ln-2]
>> return t, nil
>> }
>> ========
>> package foo
>>
>> import intstack "stack"(int) // stack of ints
>> import intstackstack "stack"(intstack.Type) // stack of stack of
>> ints
>>
>> var istk intstack.Type
>> var istkstk intstackstack.Type
>> ...
>> istk.Push(5)
>> x, err := istk.Pop()
>> istkstk.Push(istk)
>> =========
>>
>> Note that
>> - This adds only two syntax rules.
>> 1. In the package header, its name can be followed by a
>> parenthesized list of names.
>> 2. A package import must provide a complete list of types,
>> which are concrete or its own parameter types. And such
>> instantiated package must be given a local name.
>> - *All* we are doing is saving some typing.
>> - Given this, this feature can be expanded out via a preprocessor.
>> - Given this, no new semantics need be defined!
>> - Only one instance of a given type of package need be
>> generated and compiled.
>> - The intstackstack example is to show composability.
>> - This actually makes interface types more useful than now.
>>
>> The last point is worth elaborating on. Currently the "io"
>> package defines a bunch of interface types such as Reader,
>> Writer and so on. These interface types allow you to use
>> objects of a variety of other types so as as they implement
>> relevant functions. But "io" interface types are primarily for
>> byte slices. If "io" was defined as a parameterized package,
>> one can have similar choices for other slice types. Currently
>> to provide similar set of useful interface types for other
>> slice types you would have to replicate a whole bunch of
>> packages.
>>
>> Avoiding duplication of code should not be taken lightly.
>> Copies can diverge, bug fixes or peroformance improvements may
>> not be made consistently across all copies, newer copies may
>> not have as much testing, and as different copies may have
>> different bugs (and written by different people) each has to
>> be independently and thoroughly reviewed etc.
>>
>> Go may not impress lanuage designers but it is a practical
>> language. IMHO the above has a similar feel for "generics" --
>> it is simple, very easy to teach, it is not turing complete or
>> anything fancy but takes care of most of the common use cases.
>>
>> I had looked at previous formal proposals but none seemed
>> as simple as this.
>>
>
>
> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.wko1dvdznk4y
>
> Bakul
>>
>> On Sat, 25 Mar 2017 20:57:51 EDT David Collier-Brown <dave...@gmail.com>
>> wrote:
>> > Hmmn, we may be thinking different things... I *think* I'm looking for
>> a
>> > way to say "an X of Y", and see composition as a possible approach.
>> > I just don't know if it will be a, the, or not the answer (;-))
>> >
>> > --dave
>> >
>> >
>> > On 24/03/17 11:21 PM, Michael Jones wrote:
>> > > I think I was saying that what I seem to want personally is the
>> "simple,
>> > > weak, slight" thing that you likely see as failure.
>> > >
>> > > The opposite end of that--where everything is a list and can be
>> composed
>> > > without special regard (lisp) or everything is an object that can
>> > > receive any message (smalltalk) are comfortable for me, but just not
>> > > what I find myself wanting very often.
>> > >
>> > > My own view is not important in the sense that a broad survey would
>> be,
>> > > but since it seems much less than what people seem to dream of, I
>> wanted
>> > > to share that maybe people could be happy with less than they seek.
>> > >
>> > > Or maybe that ultimate typeless generality is what others really need
>> > > somehow. I would not know.
>> > >
>> > > On Fri, Mar 24, 2017 at 6:13 PM David Collier-Brown <
>> dave...@gmail.com
>> > > <mailto:dave...@gmail.com>> wrote:
>> > >
>> > > We still don't understand genrality: the current generics are
>> > > unimpressive. The proposals for Go are typically "let's do
>> something
>> > > that has failed already, in hopes that trying it agin will have a
>> > > different result". That, alas, is one of the definitions of
>> insanity.
>> > >
>> > > Due caution is advised!
>>
>>
--
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.
