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
> <javascript:>> 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
> <javascript:>
> > > <mailto:dave...@gmail.com <javascript:>>> 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.
