[go-nuts] Re: Generics as builtin typeclasses

[alan . fox6]

As I wasn't happy with some aspects of it, I've rewritten my feedback on 
the Go 2 Generics draft and deleted the original gist. Here's the link to 
the new gist for anybody who's interested: 
https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251

This is still based on the type-class idea though I'm now proposing a 
simplified contracts approach to go with it rather than trying to make 
interfaces fit. It seems to deal easily now with all the examples in the 
draft paper though no doubt there will be stuff that it can't do or that 
I've overlooked. 

The more I look at this, the more complicated it seems to get :(

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

Re: [go-nuts] Re: Generics as builtin typeclasses

[alan . fox6]

Ian,

Here's a few points which I noticed when reading through the draft design 
which I thought people might have trouble getting their heads around:

1. The use of untyped numeric constants where you might need to specify the 
exact value needed to get the thing to work. I don't think anyone could 
describe that as obvious.

2. The inability to specify in a simple way that a method doesn't have a 
return value, can take a variable number of arguments or (a particularly 
nasty one) to distinguish a method call from a struct field of function 
type. I thought folks might thrash around quite a bit trying to figure 
these out before they released they'd have to use a conversion to a 
suitable interface type.

3. The difficulty of distinguishing between methods which take a value and 
a pointer receiver.

4. The 'nil' value problem. In C# they overload the 'default' keyword (i.e. 
default(T)) to produce the default value (all bits set to zero) for a type 
T. Maybe we could do something like this?


On Thursday, September 6, 2018 at 8:52:03 PM UTC+1, Ian Lance Taylor wrote:
>
> On Thu, Sep 6, 2018 at 12:05 PM, alanfo > 
> wrote: 
> > 
> > So, yes, there'd be a lot to learn but there'd also be a lot to learn to 
> > write 'full-blooded' contracts effectively some aspects of which are 
> quite 
> > subtle. 
>
> I would like to more clearly understand which aspects seem subtle when 
> reading the code.  Where does it become confusing? 
>
>
> > I suspect that, if you can make contracts work in the way the draft 
> > envisages, then folks will write the function first and then write the 
> > contract afterwards to try and fit in with what they've done. Tooling 
> would, 
> > of course, help though I wonder whether it will be able to deal with all 
> the 
> > subtleties? 
>
> My sense is that *if* we can write a compiler that is able to type 
> check a contract, which is unproven, then it will automatically follow 
> that we can write a tool that deals with all subtleties. 
>
> Ian 
>

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

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[alan . fox6]

Whilst I could live with square brackets, I prefer round brackets too and 
still would do even if angle brackets were available.

This is because when I see different types of brackets following an 
identifier, I (and probably many others) tend to associate them as follows:

1. square brackets  ->  arrays/slices/maps

2. curly brackets ->  function bodies, struct/interface declarations

3. angle brackets->  ordering operators

4. round brackets->  function declarations, function invocations, type 
conversions, grouping stuff together

So I agree with rog that #4 best fits the existing Go ethos.

On Friday, September 7, 2018 at 12:47:59 PM UTC+1, rog wrote:
>
> Personally, I'm happy with the choice to use round brackets. 
>
> Go started down this road a long time ago, in my view, by making type 
> conversions look like function calls. 
>
> When `typename(x)` is qualitatively different from `value(x)`, I think 
> it's quite reasonable that `x(typename)` is qualitatively different 
> from `x(value)` too. 
>
> In other words, I think it's nicely regular and fits Go's aesthetic well. 
>
>
> On 7 September 2018 at 09:05, Sebastien Binet  > wrote: 
> > Bikesheding mode on... 
> > 
> > On Fri, Sep 7, 2018, 00:06 jimmy frasche  > wrote: 
> >> 
> >> I'd quite prefer [] over (). It would make F[t](v) distinct from 
> >> F(x)(y) even if it's not distinct from m[x](y). 
> > 
> > 
> > One could add a dot, like for type checking: 
> > F.[T](y) 
> > 
> > Yet another rule to learn... :) 
> > 
> > -s 
> > 
> > 
> >> On Thu, Sep 6, 2018 at 3:02 PM Ian Lance Taylor  > wrote: 
> >> > 
> >> > On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche  > 
> >> > wrote: 
> >> > > 
> >> > > Wouldn't there be an issue with fp := AFunc[int] ? 
> >> > 
> >> > I don't think so.  AFunc[int] would be parsed as an index operation, 
> >> > and after name lookup it would resolve into either an array lookup or 
> >> > a function instantiation, depending on the meaning of `int` in the 
> >> > current scope.  This is not very different from the way that t(v) 
> >> > resolves to either a function call or a type conversion after name 
> >> > lookup.  It's quite different from using <>, which has to be parsed 
> >> > quite differently depending on whether it is an instantiation or a 
> >> > comparison. 
> >> > 
> >> > 
> >> > > Though for that matter I wouldn't mind if the type part were 
> repeated 
> >> > > for instantiations like AFunc[type int] or even AFunc(type int) 
> >> > 
> >> > That would be possible but seems unnecessary.  I personally would 
> >> > prefer to avoid it. 
> >> > 
> >> > 
> >> > > For that matter, always writing type would let you use < > since 
> the 
> >> > > parser could plausibly enter a separate mode when it hit the < 
> token 
> >> > > followed by type. 
> >> > > 
> >> > > Noisy but obvious at a glance what's happening. 
> >> > 
> >> > Yes, that is true except for the >> issue. 
> >> > 
> >> > Ian 
> >> 
> >> -- 
> >> 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.

[go-nuts] Re: Operator Overloading Implies Generics?

[alan . fox6]

One of the things that attracted me to Go in the first place was its lack 
of function/method overloading!

Having programmed for many years in other languages that had this feature, 
I'd concluded that it was both confusing and difficult to compile because 
of potential ambiguities in deciding which overload should be called, 
particularly where literals were being passed as arguments. This required 
the compiler to follow very complex rules to determine 'the best fit' and 
the user needed to have at least some knowledge of these rules to avoid 
falling into the trap of calling the wrong overload.

Most of the reasons why people want function overloading at all can be 
satisfied by the simple expedient of allowing optional parameters and, as 
long as these always occur at the end of the parameter listing, they're not 
particularly confusing or difficult to compile. However, even optional 
parameters have their problems. For example if you've written a library for 
other people to use and you decide to change the default value of an 
optional parameter, then this may break their code.

So on balance I think it's best to be explicit and not allow even optional 
parameters. If you're designing a function which will need to take a lot of 
parameters, then you can use a struct for some of them which can of course 
be initialized by setting only a few of its fields and leaving the others 
with their 'zero' values.

If you think of an operator ('+' for example) as being shorthand for a 
system defined method (say _plus), then what we currently have in Go is 
basically a form of generic programming where the type parameter represents 
one of the built-in types which supports that particular operator. So you 
can add two ints, two float64s and so forth. So operator overloading is not 
really the same as function overloading at all

However, sometimes a bit of function overloading creeps in as '+' can be 
used not only as a binary operator but also as a unary operator (i.e. a == 
+a).

Now this is both convenient and unsurprising for the built-in types but it 
can be confusing if you allow people to define operators for their 
user-defined types where their use may be surprising and unintuitive for 
other people reading or maintaining the code. In my experience with other 
languages, operator overloading is best restricted to mathematical objects 
where those operators are in common use and therefore unsurprising to 
programmers in such disciplines.

The trouble is, of course, that once you allow operator overloading, you've 
let the cat out of the bag and folks will use it for all kinds of stuff for 
which it's not really suitable. I'm not therefore surprised that the Go 
designers decided to disallow it. 

I'm not even sure that it would help all that much with the Go 2 generics 
design as there are some aspects even with the use of operators for the 
built-ins which are difficult or tedious to express in any generic 
constraint system.

Alan


On Sunday, September 9, 2018 at 2:58:24 AM UTC+1, Rick wrote:
>
> With recent discussion concerning the possible introduction of generics in 
> Go 2, it occurs to me to ask about support for operator overloading in Go 
> 2. By this I mean support for functions having the same name but different 
> signature:
>
> func foo(x int) int ...
>
> func foo(x string) bool ...
>
> func foo(x int, y string) ...
>
> etc.
>
> Is support for operator overloading implied by support for generics? Is it 
> possible to have one with the other? To be honest, I've been more bothered 
> by the lack of operator overloading than by the absence of generics. And (I 
> assume) no new syntax would be required to support overloading. Or would 
> there?
>
>
>

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

[go-nuts] Re: Generics as builtin typeclasses

[alan . fox6]

In the draft design paper it says:

"There are a few aspects to a method call that can not be shown in a simple 
assignment statement like the ones shown above.

There is no way to specify that a method does not return any values.
There is no way to specify that a method takes variadic arguments.
There is no way to distinguish a method call from a call of a struct 
field with function type.

When a contract needs to describe one of these cases, it can use a type 
conversion to an interface type. The interface type permits the method to 
be precisely described. If the conversion to the interface type passes the 
type checker, then the type argument must have a method of that exact type."
 
I don't know whether anyone has suggested this before but why not disallow 
direct method calls on a contract's type arguments altogether and force 
people to use interfaces instead?

If there were no suitable pre-existing interface, one could simply nest an 
anonymous interface within the contract itself and use that for the 
conversion.

The advantages would be:

1. It would always be clear to someone reading the contract what the 
method's precise signature was.

2. A contract writer wouldn't need to think up an arbitrary expression or 
statement to describe a method's signature (sometimes imperfectly). There'd 
only be one way to do it which he/she would already know about.

3. The compiler wouldn't need to make any inferences from the way a method 
was used what it's signature was.

The disadvantages would be:

1. It would be slightly more verbose to wrap the allowable methods in an 
interface.

2. The compiler would need to check that there were no direct method 
invocations on the type parameters within the contract body and flag an 
error if there was.

IMO the advantages easily outweigh the disadvantages.

What has become the "hello world" of generic contract programming would now 
become:

contract Graph(n Node, e Edge) {
interface {
Edges() []Edge
}(n)
interface() {
Nodes() (Node, Node)
}(e)
}

Now it's true that you'd still not be able to distinguish a pointer method 
from a value method using this approach. However, this probably wouldn't 
matter in the majority of cases and, if it did, then you could use a 
similar trick to that used in the draft to specify a value method.



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

Re: [go-nuts] Re: Generics as builtin typeclasses

[alan . fox6]

Under the latest version of my own proposal, you'd do it something like 
this:

contract mycont(T) {
// ensure T has a field F of whatever type is required (FieldType say)
typecheck(T, "struct{F FieldType}")
} 

// sample generic function which takes one parameter and has no return 
type, say
func myfunc(type T mycont)(t T) {
// do something with t.F
}

type S struct {F FieldType; I int}  // struct can have other fields as well

s := S{*new(FieldType), 42}  // or whatever

myfunc(s)   // type parameter inferred to be S which satisfies mycont

Alan


On Tuesday, September 11, 2018 at 2:45:12 AM UTC+1, Larry Clapp wrote:
>
> The conversation here is deep, and I haven't followed all of it.  I 
> *think* y'all are discussing some different contract system than the 
> actual draft proposal?
>
> If that's the case:
>
> You can't express field-accessors, which is an actual, inarguable 
>> reduction in power that I'm perfectly fine with
>
>
> How would you instantiate a generic function that wanted to access field F 
> of a generic type T?
>
> if you can't do that, well, I'm not fine with that.
>
> But I may have misunderstood.
>
> — L
>
> On Monday, September 10, 2018 at 7:45:04 PM UTC-4, Axel Wagner wrote:
>>
>> The unambiguous cases aren't ambiguous of course. It's the ambiguous 
>> cases I'm concerned about :) My post and this thread contain a bunch of 
>> those. They are mostly growing out of builtin functions and things like 
>> `range` statements and index-expressions.
>>
>> You can translate all of my "pseudo-interfaces" into a clear and short 
>> contract
>>
>> contract comparable (v T) { v == v } // also allows !=
>> contract ordered (v T) { v < v } // also allows <=, >, >=
>> contract boolean (v T) { v || v } // also allows &&, !
>> contract bitwise (v T) { v & v } // also allows |, ^, <<, >>
>> contract arith (v T) { v * v } // also allows +, -, /
>> // well, this one's a bit harder…
>> contract concat (v T) { v + v; v == "" } // also allows range, 
>> index[int], copy
>> contract complex (v T) { real(v) } // also allows imag(v)
>> contract nilable (v T) { v == nil } // also allows != nil
>>
>> There is some discussion about maps, slices and channels to be had - but 
>> I think the vast majority of interesting cases can be covered by taking 
>> e.g. a `chan T`. A defined type with underlying type `chan T` is assignable 
>> to that, so it would appear a perfectly fine way to express this contract
>> contract Chan (ch C, el T) { var x T = <-ch; ch <- x }
>> (and correspondingly for send/recv-only channels).
>>
>> You can't express field-accessors, which is an actual, inarguable 
>> reduction in power that I'm perfectly fine with (similarly to how we're 
>> fine with interfaces not being able to express that).
>>
>> Which IMO brings up the question: If we can express the vast majority (or 
>> even all) of the needed contracts as combinations of this handful of 
>> base-cases, why would we need to allow the full power of Go syntax, which 
>> enables to write all the less than obvious ones too?
>>
>> (to re-emphasize: All of this isn't polished. I did sanity-check against 
>> the examples in the contract design doc, but I have not put enough thought 
>> into it that there might not be a couple nooks and crannies I haven't 
>> thought of, as you've proven before :) )
>>
>> On Tue, Sep 11, 2018 at 1:21 AM Jonathan Amsterdam  
>> wrote:
>>
>>>
>>>
>>> On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote:

 On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam  
 wrote:

> FWIW, I think Ian's criticism of not wanting a list of new identifiers 
>> to express operator constraints is fair. It is a genuine roadblock to c) 
>> and if we're dead set of setting that as a baseline requirement, I agree 
>> that a declarative/interface-based approach won't work. 
>>
>
> I don't understand. Why are names so important? Why couldn't you use 
> "T == T" to mean "T is comparable"? Or "To(From)" to mean "From is 
> convertible to To"?
>

 It's not the name that is important, it's the declarative nature. I and 
 other people have already gone into detail with the problems we are having 
 with using imperative constructs to define constraints (mainly that they 
 are ambiguous and that it's hard both to enumerate the sets allowed by a 
 contract and to define a suitable contract for an intended set of 
 constraints).

>>>
>>> I completely agree with you there (although I find the 
>>> declarative/imperative terminology confusing). I think that except for 
>>> interface-like constraints, we should be constraining by broad properties 
>>> of types like comparable, ordered and numeric, rather than specific 
>>> operations.
>>>
  

>>> I don't care if the declarative instruction is called "flooglehorn" or 
 "comparable". But I do care that it's an an actual declaration, mapping 
 1:1 
 in a clear way to

[go-nuts] Re: Generic types - functions and methods on instantions

[alan . fox6]

I'm not sure whether this:

   type Foo(type T) struct{}

would be allowed or not - the compiler might say "type parameter T is not 
used".

Anyway, if it were allowed, then it would follow that these should also be 
allowed:

   func f(x Foo(int)) {}

   func (x Foo(int)) Bar() {}

and that Foo(int) would implement Barrable but Foo(float64) would not.

My understanding of the draft design is that the following wouldn't be 
allowed unless V were a 'concrete' type:

   func (x Foo([]V)) Bar() {}

So you'd need to write something like this for it to compile:

   type V int // or whatever

Alan

On Monday, September 10, 2018 at 9:02:40 PM UTC+1, Patrick Smith wrote:
>
> Under the generics draft, would this be allowed?
>
> type Foo(type T) struct{}
>
> func f(x Foo(int)) {}
>
>
> I assume the answer is yes; I can't see any good reason to disallow it.
>
> What about this?
>
> func (x Foo(int)) Bar() {}
>
>
> If this is allowed, does this now mean that Foo(int) implements
>
> type Barrable interface {
>
> Bar()
>
> }
>
>
> but that Foo(float64) does not implement Barrable?
>
> What about this, where V is meant to be a type parameter, not a specific 
> type that was defined earlier in the code? (If allowed, it probably needs a 
> 'type V' in it somewhere, but I'm not sure where to put that.)
>
> func (x Foo([]V)) Bar() {}
>
>

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

Re: [go-nuts] Re: Generic types - functions and methods on instantions

[alan . fox6]

I've been thinking some more about this and, assuming that Patrick and I 
are right that an instantiated type can have its own method set, there are 
going to be some severe ambiguities when defining generic functions i.e. 
it's not always going to be clear whether T is a type parameter or an 
actual type!

Two possible solutions spring to mind:

1. Methods of a parameterized type should repeat the 'type' keyword:

func (type x Foo(int)) Bar() {}  // `int' is a type parameter in 
relation to Foo(type T)

func(x Foo(int)) Bar() {} // `int` is an actual type and Foo(int) is an 
initialized type


2. An initialized type cannot be used directly as a method receiver, it 
must be type-aliased first:

func (x Foo(int)) Bar() {}  // `int' is a type parameter in relation to 
Foo(type T)

type FooInt = Foo(int)

func (fi FooInt) Bar() {} // no type parameters now so clearly a method 
of FooInt


Of these I think I prefer #2 on clarity grounds.

Another problem is whether FooInt will include in its method set not just 
its own (non-generic) methods but the methods of Foo(type T) where T is an 
int. My answer to that is yes, I think it will need to do so. What do you 
guys think?

Generics really is a can of worms!






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

Re: [go-nuts] Re: Generic types - functions and methods on instantions

[alan . fox6]

Generics itself is a form of overloading, albeit in a very narrow sense. A 
generic function is in effect a set of functions (often infinite) where all 
the type parameters are replaced by those types which can conceivably 
satisfy any constraints placed upon them.

Anyway, assuming for the moment that I agreed with you that it was a bad 
thing for initialized types to have their own (non-generic) method set, the 
next question is how can you stop it?

I suppose with solution #2 in my previous post, the compiler could 'look 
through' any type alias and disallow it when an attempt was made to declare 
a function with the type alias as receiver.

You could still create a defined type rather than an alias:

type FooInt Foo(int) 

but, presumably, there would be no problem in FooInt now having its own 
methods as they would be quite distinct from those of Foo(int).


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

Re: [go-nuts] Generics - Why contracts?

[alan . fox6]

There is one thing which I think is quite clear from all the discussions 
that have taken place on this topic.

Having withstood years of criticism for the lack of generics in Go, the 
team are not going to be satisfied now with some under-powered or 
half-baked solution. They want to have as much power as possible within a 
coherent and (hopefully) easy to understand design.

Now, it says in the draft design paper, that they considered using 
interfaces but couldn't find a clear way to represent operators using 
interface methods. Having tried to do that myself, I have a lot of sympathy 
with that position!

So instead they came up with the idea of the type parameter(s) having to 
satisfy a number of requirements which could be expressed in 'normal' code 
and embodied in a new construct called a 'contract'. This idea is somewhat 
similar to 'concepts' in C++ as Ian has already pointed out.

The problem is that many of us don't find the sort of code used in 
contracts (as currently envisaged) to be 'normal' at all and we're worried 
that the Go community at large will find them difficult to write (though a 
tool may help), understand or use. What you've just said, Jeff,enforces 
that view.

So we've put forward some alternative proposals under the feedback system 
to try and address the perceived shortcomings of the present system, though 
it's not easy.

I do however have faith that the Go team will eventually come up with 
something that will be reasonably powerful, understandable and consistent 
with the 'soul' of the language. Let's hope my faith is not misplaced.



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

Re: [go-nuts] Re: Generic types - functions and methods on instantions

[alan . fox6]

Can't say I've a strong feeling one way or another on that though there'd 
be an awful lot of brackets if it were allowed!

You can, of course, always work around it with a top level function:

func foo(type S, T)(a A(T), s S, t T) 


On Tuesday, September 11, 2018 at 9:39:23 PM UTC+1, rog wrote:
>
> On 11 September 2018 at 18:04, roger peppe  > wrote: 
> > If it were not explicitly prohibited by the draft proposal, we could 
> > also imagine this, a definition of a method foo on the type A that's 
> > parameterised with type T; the method itself has a type parameter S: 
> > 
> > func (a A(T)) foo(type S)(s S, t T) 
>
> With respect to this, I wonder if the draft proposal isn't being a bit 
> more restrictive than necessary. 
>
> I suspect that type parameters on methods might turn out to be very 
> nice to have (it's very useful to keep within a type's namespace) even 
> if we can't use them in interfaces or in reflect. 
>
> How about allowing them, but say that methods with type parameters 
> never appear in any interface and cannot be accessed with reflect? 
>

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

Re: [go-nuts] Generics - Why contracts?

[alan . fox6]

Correction: you'd only need 3 additional built-ins as 'real' is already 
used to find the real part of a complex number.

Although it would be used differently here, you might want to use 'numeric' 
instead to avoid confusion.

Alan

On Tuesday, September 11, 2018 at 11:31:03 PM UTC+1, alanfo wrote:
>
> Robert,
>
> I suspect that you could achieve 90% coverage with just 4 built-in 
> contracts: 
>
>
> 1. integer (any integer type) 
>
> 2. real (any integer or floating point type)
>
> 3. ordered (any integer, floating point or string type)
>
> 4. comparable (any type which supports == and !=)
>
>
> If you had just one type parameter, a built-in contract could be applied 
> directly to it where appropriate. For example:
>
> func FormatUnsigned(type T real)(v T) string {
> return strconv.FormatUint(uint64(v), 10)
> }
>
> Otherwise, you'd need to create a user defined contract whose constituents 
> could be restricted to the following:
>
>
> 1. Other embedded contracts (including the built-ins)
>
> 2. Interface conversions.
>
>
> This would still allow you to do some quite complicated things. For 
> example:
> 
> contract Graph(n Node, e Edge) {
> interface {
> Edges() []Edge
> }(n)
>
> interface() {
> Nodes() (Node, Node)
> }(e)
> }
>
> func ShortestPath(type N, E Graph)(src, dst N) []E { ... }
>
>
> However, you wouldn't be able to specify that structs contain specific 
> named fields, that a type parameter must either be a string or a byte slice 
> and many other things. 
>
> From my own perspective I think I'd be happy with a relatively simple 
> constraint system such as this but, as I said earlier, I don't think it'll 
> be enough for the Go team who (within reason) are looking for something 
> more comprehensive.
>
> Alan
>
> On Tuesday, September 11, 2018 at 5:27:38 PM UTC+1, Robert Engels wrote:
>>
>> As I’ve said elsewhere, a SIMPLE to use and understand solution that 
>> covers 90% is better than a complex one to cover 100% IMO, and fits in well 
>> with the rest of Go design. Go leaves out a lot - intentionally - and it’s 
>> a good choice. 
>>
>> On Sep 11, 2018, at 11:22 AM, alan...@gmail.com wrote:
>>
>> There is one thing which I think is quite clear from all the discussions 
>> that have taken place on this topic.
>>
>> Having withstood years of criticism for the lack of generics in Go, the 
>> team are not going to be satisfied now with some under-powered or 
>> half-baked solution. They want to have as much power as possible within a 
>> coherent and (hopefully) easy to understand design.
>>
>> Now, it says in the draft design paper, that they considered using 
>> interfaces but couldn't find a clear way to represent operators using 
>> interface methods. Having tried to do that myself, I have a lot of sympathy 
>> with that position!
>>
>> So instead they came up with the idea of the type parameter(s) having to 
>> satisfy a number of requirements which could be expressed in 'normal' code 
>> and embodied in a new construct called a 'contract'. This idea is somewhat 
>> similar to 'concepts' in C++ as Ian has already pointed out.
>>
>> The problem is that many of us don't find the sort of code used in 
>> contracts (as currently envisaged) to be 'normal' at all and we're worried 
>> that the Go community at large will find them difficult to write (though a 
>> tool may help), understand or use. What you've just said, Jeff,enforces 
>> that view.
>>
>> So we've put forward some alternative proposals under the feedback system 
>> to try and address the perceived shortcomings of the present system, though 
>> it's not easy.
>>
>> I do however have faith that the Go team will eventually come up with 
>> something that will be reasonably powerful, understandable and consistent 
>> with the 'soul' of the language. Let's hope my faith is not misplaced.
>>
>>
>>
>> -- 
>> 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.

Re: [go-nuts] A simplified generics constraint system.

[alan . fox6]

Well, it's easy enough if you check that it's a non-negative integer to 
start with :)

If it's negative, you'd have to decide what to do - return an error, panic 
or circumvent the problem in some other way.

Alan

On Friday, September 14, 2018 at 1:40:41 PM UTC+1, ohir wrote:
>
> On Fri, 14 Sep 2018 03:32:09 -0700 (PDT) 
> alanfo > wrote: 
>   
> > https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab 
> > 
> > Any comments or constructive criticism are of course welcome. 
>
> > https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab 
> > " it is easy enough to convert between signed and unsigned integers so I 
> > don't think this is an important enough use case to justify its 
> inclusion." 
>
> Easy? 
>
> https://wiki.sei.cmu.edu/confluence/display/c/INT02-C.+Understand+integer+conversion+rules
>  
> https://play.golang.org/p/wZh8gv47wjz Play with sized ;) 
>
> CGG: https://github.com/ohir/gonerics 
>
> -- 
> 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.

[go-nuts] Re: A simplified generics constraint system.

[alan . fox6]

Thanks for those comments, guys.

I've responded to them in the same place.

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

Re: [go-nuts] A simplified generics constraint system.

[alan . fox6]

Ian,

Ian,

Well, if a simple comprehensive solution can be found, then I'm sure we'll 
all be in favor of it.

The problem is that many people think the current draft design is too 
complex and I haven't seen a plausible suggestion from anyone (myself 
included) which would be appreciably simpler but as comprehensive, or 
nearly so. 

This is why I'd concluded that, if a system could be devised which was 
simple but nonetheless addressed 90% of the use cases for generics, it 
might be good enough.

Even simpler solutions are better than some languages have. Having 
programmed in C# for many years, I was frustrated that you couldn't write 
useful generic functions for numerics at all and, even though they've added 
a lot of stuff lately, you still can't. As Robert has just mentioned, Java 
generics are far from perfect also.

Alan


On Friday, September 14, 2018 at 6:16:47 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Sep 14, 2018 at 3:32 AM, alanfo > 
> wrote: 
> > 
> > I was then brought back to reality by this post by Robert Engels in the 
> > 'Generics - Why contracts?' thread: 
> > 
> > "As I’ve said elsewhere, a SIMPLE to use and understand solution that 
> covers 
> > 90% is better than a complex one to cover 100% IMO, and fits in well 
> with 
> > the rest of Go design. Go leaves out a lot - and it's a good choice." 
>
> I've seen several people express this idea in different ways.  I want 
> to challenge it. 
>
> I agree that simple is essential.  That is not in dispute.  If the 
> current design draft is too complex, we can not adopt it as is. 
>
> However, it does not follow that a 90% solution, whatever that is 
> taken to mean, is acceptable. 
>
> A 90% solution is frustrating, in exactly the same way that some 
> people find the fact that Go currently lacks generics to be 
> frustrating.  That is, for generic programming, Go is already a 90% 
> solution.  Some people find the missing 10% to be annoying, 
> frustrating, and confusing.  This will continue to happen if we add 
> another 90% solution to the problem. 
>
> A 90% solution is complex, because by definition it means that there 
> are special cases, complex cases, that do not work as expected. 
> Everybody who learns Go has to learn not only how to implement the 
> 90%, they also have to learn where that 90% stops. 
>
> A 90% solution is not orthogonal, by definition.  Go is in some ways 
> not very orthogonal, but it is orthogonal in this way: all concepts in 
> Go that can be meaningfully used together, work together as one would 
> expect them to.  There are no missing elements. 
>
> When considering changes to the Go language, please do not settle for 
> a 90% solution. 
>
> Ian 
>

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

Re: [go-nuts] A simplified generics constraint system.

[alan . fox6]

Well, I can't speak for the other simpler proposals but for my own there's 
very little to learn - just six built-ins where it's pretty obvious what 
they mean from their names and the rest is (in effect) just checking that a 
type satisfies a certain interface or, if it's a struct, has certain 
fields. If this can't express what you need, then you can't do it.

There was only one example in the draft design and overview papers which it 
couldn't cope with - the one which required the type to be either a string 
or a byte slice. All the rest could be dealt with as easily or more easily.

Having read all your past papers, I realize of course how long you've been 
working on this and wouldn't have come up now with the design you have if 
you didn't believe it was the best one for taking generics forward. 

So I really hope you can get the draft design to work since I, for one, 
would love to have generics even if the constraint system is more 
complicated than I would like. If you can't get it to work, then a simpler 
design would still be comprehensive enough for many of us.

Alan

On Friday, September 14, 2018 at 9:24:20 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Sep 14, 2018 at 10:47 AM,  > 
> wrote: 
> > 
> > The problem is that many people think the current draft design is too 
> > complex and I haven't seen a plausible suggestion from anyone (myself 
> > included) which would be appreciably simpler but as comprehensive, or 
> nearly 
> > so. 
> > 
> > This is why I'd concluded that, if a system could be devised which was 
> > simple but nonetheless addressed 90% of the use cases for generics, it 
> might 
> > be good enough. 
>
> We've been working on this for years.  It's far too soon to give up on 
> a reasonably complete solution. 
>
> And, as I tried to say earlier, a 90% solution has its own 
> complexities.  If the only reason to reject the design draft is 
> complexity, then it's not obvious that a 90% solution is really 
> simpler. 
>
> And, of course, we're only really going to understand the complexity 
> of the design draft when we can try writing real code that uses it. 
>
> Ian 
>

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

Re: [go-nuts] A simplified generics constraint system.

[alan . fox6]

Jonathan,

The problem with just 'OR'ing complex64 and complex128 together is that the 
resulting contract wouldn't encompass any defined types with the same 
underlying types. So 'mycomplex' wouldn't be included:

type mycomplex complex64

However, I'm pleased you mentioned it as it's given me an idea. Maybe my 
'fuller' proposal was on the right lines after all, it just needed 
simplifying :)

Suppose (with the sole exception of Comparable) we get rid of the built-ins 
altogether and instead add two new assertions to the four that are already 
permitted within a contract body:

union{...}(T)
except{...}(T)

These would assert that a type parameter must represent a type within the 
'union' body but NOT represent a type within the 'except' body. The 
following could go within the body:

1. Any non-generic type.

2. Any contract requiring exactly one type parameter (inferred to be T).

Other rules would be:

3. There could be any number of constituent types/contracts with a minimum 
of one.

4. Any type specified under #1 would be deemed to include any defined type 
with the same underlying type (IMPORTANT POINT!).

5. Any contract could contain at most one 'union' or 'except' assertion.

6. 'union' and 'except' would only be keywords within this context. Other 
uses would be unaffected and so the proposal would still be backwards 
compatible with Go 1.

Incidentally, I'm NOT suggesting that we should add union types to the 
language itself; these constructs would only apply within a contract body. 

It would now be a simple matter to build up a standard contracts package 
("ct" say) which included those originally envisaged: Integer, Signed, 
Unsigned, Float, Complex, Boolean, String, Real, Numeric, Ordered, Addable, 
Bytes and Runes. For example:

contract Signed(T) {
union{ int8, int16, int32, int64, int }(T)
}

contract Unsigned(T) {
union{ uint8, uint16, uint32, uint64, uint, uintptr }(T)
}

contract Float(T) {
union{ float32, float64 }(T)
}

contract Complex(T) {
union{ complex64, complex128 }(T)
}

contract Integer(T) {
union{ ct.Signed, ct.Unsigned }(T)
}

contract Numeric(T) {
union{ ct.Integer, ct.Float, ct.Complex }(T)
}

contract String(T) {
union{ string }(T)  // includes any defined type based on string
}

contract Bytes(T) {
union{ string, []byte }(T)  // includes defined types based on string 
or []byte
}

The Add1K example could now by made to work properly with this contract 
which disallows 8 bit integers:

contract BiggerInts(T) {
ct.Integer(T)
except{ int8, uint8 }(T)
}

Incidentally, any one who dislikes having to qualify stuff with "ct" could 
get rid of it in the 'import' declaration as long as they were confident 
they wouldn't reuse the names of the standard contracts in the current 
source file:

import . "ct"
   
So what do you think of this idea?

It's certainly more expressive than the simplified proposal as it stands 
and (apart from stuff like a totally generic Min() function which would 
require contract adaptors) I'm struggling to think of anything it couldn't 
do that I'd want it to do.

Alan 

On Sunday, September 16, 2018 at 11:22:35 PM UTC+1, Jonathan Amsterdam 
wrote:
>
>
>
> On Friday, September 14, 2018 at 8:06:31 PM UTC-4, alanfo wrote:
>>
>> Thanks for your comments, Jonathan.
>>
>> I did in fact deal with all the cases you mention in my 'fuller' proposal:
>>
>> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
>>
>> where I'd used a device to restrict the built-ins to just one following 
>> criticism by Ian that an earlier proposal I'd made had too many of them (it 
>> had 14). 
>>
>> However, I decided instead to restrict the built-ins to a reasonable 
>> number (6) in the simplified proposal which meant that many of them had to 
>> go.
>>
>
> Your 'fuller' proposal says that you can "or" the builtins together. But 
> if you have that, you can get rid of many of them. For instance, "complex" 
> is just "complex64 or complex128".
>
>>
>> The example you mentioned was taken from the draft design paper and 
>> didn't compile for int8 there either. 
>>
>
> Sorry, I shouldn't have used the word "compile" because it's ambiguous. 
> Neither your Add1K nor the draft design's can be instantiated for int8. 
> However, the draft design Add1K is valid with respect to its contract. 
> Yours isn't, because the contract admits int8 but the function doesn't.
>

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

Re: [go-nuts] A simplified generics constraint system.

[alan . fox6]

Small, but important, correction re #5:

5.  Any contract could contain at most one 'union' or 'except' assertion *for 
each type parameter*.

Alan

On Monday, September 17, 2018 at 11:07:26 AM UTC+1, alan...@gmail.com wrote:
>
> Jonathan,
>
> The problem with just 'OR'ing complex64 and complex128 together is that 
> the resulting contract wouldn't encompass any defined types with the same 
> underlying types. So 'mycomplex' wouldn't be included:
>
> type mycomplex complex64
>
> However, I'm pleased you mentioned it as it's given me an idea. Maybe my 
> 'fuller' proposal was on the right lines after all, it just needed 
> simplifying :)
>
> Suppose (with the sole exception of Comparable) we get rid of the 
> built-ins altogether and instead add two new assertions to the four that 
> are already permitted within a contract body:
>
> union{...}(T)
> except{...}(T)
>
> These would assert that a type parameter must represent a type within the 
> 'union' body but NOT represent a type within the 'except' body. The 
> following could go within the body:
>
> 1. Any non-generic type.
>
> 2. Any contract requiring exactly one type parameter (inferred to be T).
>
> Other rules would be:
>
> 3. There could be any number of constituent types/contracts with a minimum 
> of one.
>
> 4. Any type specified under #1 would be deemed to include any defined type 
> with the same underlying type (IMPORTANT POINT!).
>
> 5. Any contract could contain at most one 'union' or 'except' assertion.
>
> 6. 'union' and 'except' would only be keywords within this context. Other 
> uses would be unaffected and so the proposal would still be backwards 
> compatible with Go 1.
>
> Incidentally, I'm NOT suggesting that we should add union types to the 
> language itself; these constructs would only apply within a contract body. 
>
> It would now be a simple matter to build up a standard contracts package 
> ("ct" say) which included those originally envisaged: Integer, Signed, 
> Unsigned, Float, Complex, Boolean, String, Real, Numeric, Ordered, Addable, 
> Bytes and Runes. For example:
>
> contract Signed(T) {
> union{ int8, int16, int32, int64, int }(T)
> }
>
> contract Unsigned(T) {
> union{ uint8, uint16, uint32, uint64, uint, uintptr }(T)
> }
>
> contract Float(T) {
> union{ float32, float64 }(T)
> }
>
> contract Complex(T) {
> union{ complex64, complex128 }(T)
> }
>
> contract Integer(T) {
> union{ ct.Signed, ct.Unsigned }(T)
> }
>
> contract Numeric(T) {
> union{ ct.Integer, ct.Float, ct.Complex }(T)
> }
>
> contract String(T) {
> union{ string }(T)  // includes any defined type based on string
> }
>
> contract Bytes(T) {
> union{ string, []byte }(T)  // includes defined types based on string 
> or []byte
> }
>
> The Add1K example could now by made to work properly with this contract 
> which disallows 8 bit integers:
>
> contract BiggerInts(T) {
> ct.Integer(T)
> except{ int8, uint8 }(T)
> }
>
> Incidentally, any one who dislikes having to qualify stuff with "ct" could 
> get rid of it in the 'import' declaration as long as they were confident 
> they wouldn't reuse the names of the standard contracts in the current 
> source file:
>
> import . "ct"
>
> So what do you think of this idea?
>
> It's certainly more expressive than the simplified proposal as it stands 
> and (apart from stuff like a totally generic Min() function which would 
> require contract adaptors) I'm struggling to think of anything it couldn't 
> do that I'd want it to do.
>
> Alan 
>
> On Sunday, September 16, 2018 at 11:22:35 PM UTC+1, Jonathan Amsterdam 
> wrote:
>>
>>
>>
>> On Friday, September 14, 2018 at 8:06:31 PM UTC-4, alanfo wrote:
>>>
>>> Thanks for your comments, Jonathan.
>>>
>>> I did in fact deal with all the cases you mention in my 'fuller' 
>>> proposal:
>>>
>>> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
>>>
>>> where I'd used a device to restrict the built-ins to just one following 
>>> criticism by Ian that an earlier proposal I'd made had too many of them (it 
>>> had 14). 
>>>
>>> However, I decided instead to restrict the built-ins to a reasonable 
>>> number (6) in the simplified proposal which meant that many of them had to 
>>> go.
>>>
>>
>> Your 'fuller' proposal says that you can "or" the builtins together. But 
>> if you have that, you can get rid of many of them. For instance, "complex" 
>> is just "complex64 or complex128".
>>
>>>
>>> The example you mentioned was taken from the draft design paper and 
>>> didn't compile for int8 there either. 
>>>
>>
>> Sorry, I shouldn't have used the word "compile" because it's ambiguous. 
>> Neither your Add1K nor the draft design's can be instantiated for int8. 
>> However, the draft design Add1K is valid with respect to its contract. 
>> Yours isn't, because the contract admits int8 but the function doesn't.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.

[go-nuts] Re: I am not in favor of generics.

[alan . fox6]

Although I respect the opinions expressed here, I think you might be 
pleasantly surprised by how the proposed design would dovetail with the 
rest of Go and make a number of things much more convenient than they are 
at present.

It would be nice, for example, to have a full range of collection types in 
the standard library without the need to use interface{}, type assertions 
and the performance overhead of 'boxing'. 

It's not an ugly design with angle brackets all over the place and most of 
the time you'd hardly notice you were using a generic function as the type 
parameter(s) would be automatically inferred from usage.

Better still it would be compatible with Go 1.

Admittedly, there's a lot of discussion over the design at present though 
that's mainly about the constraint system. Everybody agrees that this needs 
to be both simple and  expressive though opinions differ over the best way 
to achieve that.

Anyway, as I said in another thread, the important thing is that the 
existing built-in generic stuff is not interfered with, so those who prefer 
to avoid generics may do so and carry on as they are. That way everybody 
will be happy :)

Alan

On Monday, September 17, 2018 at 5:04:26 PM UTC+1, jucie@zanthus.com.br 
wrote:
>
> Go core team is working hard to bring generics to the language because 
> several people asked for it. With all due respect for those users and for 
> people working hard to make generics a reality, I feel that a greater 
> number of people would suffer after generics adoption. So, I feel compeled 
> to manifest my opinion: sorry guys, Go with generics will be worse than Go 
> without generics.
>
> The language strives for simplicity since its inception and that is what 
> attracted a large part of its user base. We must think about who we will 
> want to have in our community 10 years from now. Supporting generics would 
> please a minority to the detriment of a large number of potential users.
>
> Today Go is easy to learn and tools are easy to implement. Please keep it 
> that way.
>
> Thanks.
>

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

[go-nuts] Re: I am not in favor of generics.

[alan . fox6]

One thing I've always liked about Go is the ability to define your own 
types based on the built-in ones. Although the built-ins don't have methods 
themselves, you can still add them to your own types and satisfy interfaces 
in that way.

This enables us to define simple collection types such as stacks and queues 
whose underlying type is a slice of values and give them methods such as 
Push, Peek and Pop. We then no longer need to think about how to achieve 
these operations by operating on the slice directly.

The trouble at the moment is that if you want, say, a stack of ints or a 
stack of  strings, you either have to copy what is essentially the same 
code for each type or use interface{}.

If generics is added, you'd just need to declare your variable to be a 
stack(int), stack(string) or stack(whatever) and you'd then have a 
type-safe, performant container without further ado. 

Now, even if there was only one constraint - declaring that a type was 
'Comparable' i.e. supported the == and != operators, I still think that 
generics would be worth adding for all the scenarios which that would 
enable.

You only need to look at the standard libraries of other popular statically 
typed languages such as Java and C# to see what can be achieved with little 
or no constraints. 

However, in an ideal world, there's lots of other stuff you'd like to do as 
well and this is where the problems start. To take a very simple example, 
if you want to write a generic Sum function which can sum the values of a 
slice of any numeric type, then you need to use the '+' operator and you 
therefore need some way of telling the compiler that you only want to use 
types which support that operator.

Now (ignoring 'string') the only types which do support '+' are the 
built-in numeric types (integer, floating point, complex) and any types you 
define yourself based on them.

There's no way that your generic Sum function can deal with big.Int because 
it doesn't have a '+' operator and Go doesn't support operator overloading. 
Using an 'Add' method instead won't work as int, float64 etc. don't have 
methods.

So, when Thomas says in his post that numbers are a problem - he's right, 
they are - and, in particular there's a dichotomy between the built-in and 
user-defined numeric types.

However, I don't think this is a reason for giving up altogether on this - 
it's still useful to have generics for the built-ins only. But you do need 
to come up with a constraint system which is simple enough for everybody to 
understand but expressive enough to do what you want and I have faith that 
the Go team will eventually converge on such a system even if the initial 
draft (IMO) falls short on the simplicity front.

In response to worries that a large Go team won't be able to work together 
if some use generics and some don't, I would make these points:

1. In my experience of various other languages, most folks don't write 
their own generic types/functions - they just use a library. I don't 
necessarily see it as a problem if one programmer prefers to use a generic 
library and another uses a non-generic library and, as I said earlier, I 
suspect the latter might be less adverse to generics when they see how 
convenient they are to use.

2. There is no way that the Go team are going to adopt generics in such a 
way that it is not a good fit with the rest of the language. So any worries 
that Go is going to end up like C++ (with everybody using a different 
subset of the language) or Python (with the version 2/3 split) are 
unfounded in my opinion. 

Alan

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

Re: [go-nuts] A simplified generics constraint system.

[alan . fox6]

Just going through how xingtao zhao's examples would look under my own 
proposal:

The first one would be:

contract Foo(T) {
union{ int, float64, complex128 }(T)
interfaceA(T)
}

Note though that this could only be satisfied by defined types based on 
int, float64 or complex128 as those types don't have methods themselves and 
so couldn't satisfy interfaceA. 


The second one would be approached in a different way which doesn't require 
the slice element type to be deduced or a contract to be written:

func slicer(type T Foo)(s []T, ...) ... {
// do something with s
}

or even non-generically:

func slicer2(s []Foo, ...) ... { ... }


The third one would also be approached in a different way but still 
requires a contract:

contract Map(K, V) {
Comparable(K)
Foo(V)
}
 
func mapper(type K, V Map)(m map[K]V, ...) ... {
// do something with m
}

Finally, a struct type with a field f (say of type int) could be expressed 
like this:

contract Struct(T) {
struct{ f int }(T)
}

Alan

On Tuesday, September 18, 2018 at 5:51:03 PM UTC+1, xingtao zhao wrote:
>
> I have the similar thought as the thread. In terms of a contract, it is 
> mainly to express these:
>
>1. Methods set: this could be easily expressed by interface
>2. Operators set: In go, we could not add or remove the existing 
>operator set for a given type, which is completely inherited from its 
>underlying type. So it is equivalent to explicitly express operation set 
> vs 
>to express the union of underlying types.
>3. Type conversion:
>   1. conversion between types with the same underlying type
>   2. conversion between numeric types
>   3. conversion from concrete types to interface
>
> So it is obviously that what we are lacking is: expressing underlying 
> types and expressing the combination of them, i.e. union type. So maybe a 
> contract could be written like this:
>
> contract Foo(T) {
>   int(T) || float64(T) || complex128(T)  // underlying type: int, float64, 
> complex128
>   InterfaceA(T)// at the same time, it 
> should satisfy InterfaceA
> }
>
> contract Slice(S) {
>   []T(S) && Foo(T)// S is a slice, and retrieve the element type to T, 
> and T should match contract Foo
> }
>
> contract Map(M) {
>   (map[K]V)(M) && Foo(V)  // M is a map, whose value type match contract 
> Foo.
> }
>
> There is still no way to express that a type should have a field "f" - But 
> maybe we can accept this?
>
> In this case, contract is more orthogonal to the existing concepts in go - 
> we already have the way to express the method set of a type (interface), it 
> is no needed to be able to express it in contract again. 
>
>
> On Monday, September 17, 2018 at 4:54:04 PM UTC-7, alanfo wrote:
>
>> Thanks for your comment, Patrick.
>>
>> Although I've relied on compiler magic for my previous proposals, I 
>> believe we should keep it to a minimum if we can, The 'union' and 'except' 
>> idea would allow us to compose any group of types we want from the basic 
>> built-ins and, even within the standard library, it would always be clear 
>> from looking at the underlying code exactly what those groups comprised. 
>>
>> For me that would be a valuable feature and would still be significantly 
>> less complex than the draft generics design where every operator used has 
>> to be spelled out. Under this proposal, the allowable operators/conversions 
>> etc. are implicit from the types used.
>>
>> Alan
>>
>> On Monday, September 17, 2018 at 8:16:38 PM UTC+1, Patrick Smith wrote:
>>>
>>> I think your idea of creating standard contracts to represent similar 
>>> types is a good one. However, you don't have to say how those contracts are 
>>> written, just what they do. No need for typecheck, union, except, etc. For 
>>> example,
>>>
>>> Integer(T) - T is an integer type
>>> Float(T) - T is a floating point type
>>> Complex(T) - T is a complex type
>>>
>>> For contracts in the standard library, we can just invoke "compiler 
>>> magic" to explain how they work. Trying to explain the mechanism merely 
>>> adds complexity.
>>>
>>

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

Re: [go-nuts] Re: I am not in favor of generics.

[alan . fox6]

Eric,

This is the sort of situation where a tool could help.

If the tool detects that you've written a generic type/function but only 
then instantiated it once, that could lead you to rewrite the type/function 
non-generically for the type(s) actually used in the instantiation.

Alan

On Tuesday, September 18, 2018 at 6:38:34 PM UTC+1, Eric Johnson wrote:
>
>
>
> On Tue, Sep 18, 2018 at 6:21 AM Robert Engels  > wrote:
>
>> I am going to refer everyone involved in this discussion on generics to 
>> this once again. I know it is long, read the summary... but it’s important:
>>
>>
>> https://www.researchgate.net/publication/236644412_Adoption_and_Use_of_Java_Generics
>>
>
> I'm skimming that paper. Thanks for sharing. Paper definitely identifies 
> benefits for adding generics.
>
> This quote jumped out at me for its relevance to this discussion:
> "We observed parameterization of 1152 types, but actually found about 46 % 
> of these types (532) only had exactly one type argument ever used 
> throughout the project’s history, suggesting that needless or premature 
> generification of objects occurs fairly frequently.We observed 
> parameterization of 1152 types, but actually found about 46 % of these 
> types (532) only had exactly one type argument ever used throughout the 
> project’s history, suggesting that needless or premature generification of 
> objects occurs fairly frequently."
>
> Put in the term of this discussion thread, the study notes that about 45% 
> of the time (for the Java projects studied), portions of the code get 
> harder to read, with little or no clear benefit. There's no basis for 
> thinking that the same problems will or won't occur with any generics added 
> to Go, but it seems like a reasonable place to point to for concerns 
> driving this thread.
>
> Eric.
>  
>
>>
>> On Sep 18, 2018, at 7:52 AM, Wojciech S. Czarnecki > > wrote:
>>
>> On Tue, 18 Sep 2018 04:38:55 -0700 (PDT)
>> ffm...@web.de  wrote:
>>
>> Every average Joe Java boilerplate coder gets along with generics.
>>
>> Barely, if at all, understanding whats under.
>>
>> "Smart Copy Paste ... A book for normal programmers"
>>
>> https://www.amazon.com/Smart-Paste-Stack-Overflow-other-ebook/dp/B01EHI5RQM
>>
>> But even there you can manage without thinking and just doing 
>>
>> trial and error if you wanted to.
>>
>>
>> OP, I and many others want to defend Gol off this very attitude.
>> Go is among few contemporary languages that allows me to fully
>> understand what my resulting binary will do, down to the syscall
>> level. Thats precious.
>>
>>
>> I think it will neither be tricky to make use of nor to read the code. 
>>
>>
>> I claim opposite. All and any Gopher will be expected to cope with hard to
>> read and yet harder to understand generic code. Even if she herself will
>> vowed not to use it. In a short while we all will be obeying first Java's
>> commandment "thou shalt not peek under".
>>
>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/3ia8XrUgqOg/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.

Re: [go-nuts] A simplified generics constraint system.

[alan . fox6]

Sorry, I was thinking that Foo was an interface (rather than an existing 
contract), so the second example couldn't be written non-generically.

In the third example you could also merge the two contracts into one:

 contract MapFoo(K, V) {
  Comparable(K)
  union{ int, float64, complex128 }(V)
  interfaceA(V)
 }

 func mapper(type K, V MapFoo)(m map[K]V, ...) ... {
 // do something with m
 }

Alan

On Tuesday, September 18, 2018 at 7:42:06 PM UTC+1, alan...@gmail.com wrote:
>
> Just going through how xingtao zhao's examples would look under my own 
> proposal:
>
> The first one would be:
>
> contract Foo(T) {
> union{ int, float64, complex128 }(T)
> interfaceA(T)
> }
>
> Note though that this could only be satisfied by defined types based on 
> int, float64 or complex128 as those types don't have methods themselves and 
> so couldn't satisfy interfaceA. 
>
>
> The second one would be approached in a different way which doesn't 
> require the slice element type to be deduced or a contract to be written:
>
> func slicer(type T Foo)(s []T, ...) ... {
> // do something with s
> }
>
> or even non-generically:
>
> func slicer2(s []Foo, ...) ... { ... }
>
>
> The third one would also be approached in a different way but still 
> requires a contract:
>
> contract Map(K, V) {
> Comparable(K)
> Foo(V)
> }
>  
> func mapper(type K, V Map)(m map[K]V, ...) ... {
> // do something with m
> }
>
> Finally, a struct type with a field f (say of type int) could be expressed 
> like this:
>
> contract Struct(T) {
> struct{ f int }(T)
> }
>
> Alan
>
> On Tuesday, September 18, 2018 at 5:51:03 PM UTC+1, xingtao zhao wrote:
>>
>> I have the similar thought as the thread. In terms of a contract, it is 
>> mainly to express these:
>>
>>1. Methods set: this could be easily expressed by interface
>>2. Operators set: In go, we could not add or remove the existing 
>>operator set for a given type, which is completely inherited from its 
>>underlying type. So it is equivalent to explicitly express operation set 
>> vs 
>>to express the union of underlying types.
>>3. Type conversion:
>>   1. conversion between types with the same underlying type
>>   2. conversion between numeric types
>>   3. conversion from concrete types to interface
>>
>> So it is obviously that what we are lacking is: expressing underlying 
>> types and expressing the combination of them, i.e. union type. So maybe a 
>> contract could be written like this:
>>
>> contract Foo(T) {
>>   int(T) || float64(T) || complex128(T)  // underlying type: int, 
>> float64, complex128
>>   InterfaceA(T)// at the same time, 
>> it should satisfy InterfaceA
>> }
>>
>> contract Slice(S) {
>>   []T(S) && Foo(T)// S is a slice, and retrieve the element type to 
>> T, and T should match contract Foo
>> }
>>
>> contract Map(M) {
>>   (map[K]V)(M) && Foo(V)  // M is a map, whose value type match contract 
>> Foo.
>> }
>>
>> There is still no way to express that a type should have a field "f" - 
>> But maybe we can accept this?
>>
>> In this case, contract is more orthogonal to the existing concepts in go 
>> - we already have the way to express the method set of a type (interface), 
>> it is no needed to be able to express it in contract again. 
>>
>>
>> On Monday, September 17, 2018 at 4:54:04 PM UTC-7, alanfo wrote:
>>
>>> Thanks for your comment, Patrick.
>>>
>>> Although I've relied on compiler magic for my previous proposals, I 
>>> believe we should keep it to a minimum if we can, The 'union' and 'except' 
>>> idea would allow us to compose any group of types we want from the basic 
>>> built-ins and, even within the standard library, it would always be clear 
>>> from looking at the underlying code exactly what those groups comprised. 
>>>
>>> For me that would be a valuable feature and would still be significantly 
>>> less complex than the draft generics design where every operator used has 
>>> to be spelled out. Under this proposal, the allowable operators/conversions 
>>> etc. are implicit from the types used.
>>>
>>> Alan
>>>
>>> On Monday, September 17, 2018 at 8:16:38 PM UTC+1, Patrick Smith wrote:

 I think your idea of creating standard contracts to represent similar 
 types is a good one. However, you don't have to say how those contracts 
 are 
 written, just what they do. No need for typecheck, union, except, etc. For 
 example,

 Integer(T) - T is an integer type
 Float(T) - T is a floating point type
 Complex(T) - T is a complex type

 For contracts in the standard library, we can just invoke "compiler 
 magic" to explain how they work. Trying to explain the mechanism merely 
 adds complexity.

>>>

-- 
You received this message because you are subscribed to the Google Groups 

[go-nuts] Re: proposal: generic generics proposal

[alan . fox6]

Not really, TBH, though I'll soon be posting a link to my new treatise: "De 
rebus genericis golangi dvo" to the feedback page. 

I thought it might gain more attention if the title were written in Latin .

Alan  

On Thursday, September 20, 2018 at 12:59:27 AM UTC+1, kortschak wrote:
>
> It's pretty clear for the flood of emails to golang-nuts and golang-dev 
> regarding the recent generics/contracts proposal that there are many 
> ways to implement generics proposals. 
>
> Because of this and risks associated with copy pasting generics 
> proposals to modify and re-propose, I would like to propose a mechanism 
> for implementing generics proposals generically — that is a parametric 
> proposal proposal (possibly with either metacontracts or nested 
> boxing). 
>
> Is anyone adequately versed in metaphysics and the philosophy of self- 
> reference to help me out with this? 
>
> thanks 
> Dan 
>

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

Re: [go-nuts] Re: proposal: generic generics proposal

[alan . fox6]

On Thursday, September 20, 2018 at 9:02:36 AM UTC+1, Eric Raymond wrote:
>
>
> Maybe *that's* what the Mysterious Stranger gave me.  I couldn't 
> understand 
> his description - I think he was speaching Enochian. And a timestamp in 
> the... 
> future? On a thumb drive that glows faintly in a disquieting shade of 
> green? 
>
>
Wow, and I thought Go was the language of angels :)

Alan

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

[go-nuts] Re: A simplified generics constraint system.

[alan . fox6]

For those who don't agree that complex numbers should be segregated from 
the other numeric types, I'll briefly suspend my vow of silence to say that 
I've found a way to do this which doesn't involve adding more built-in 
contracts or fancy syntax to the contract body. In fact, it's as simple as 
this:

contract Numeric(T) {
Real(T)
Complex(T)
}

How this would work is described in the gist.

Alan

On Friday, September 21, 2018 at 5:51:37 PM UTC+1, alanfo wrote:
>
> Thanks to all those who have had the patience to read this proposal and 
> made comments on, or criticisms of, it.
>
> Having carefully considered the points made, I have concluded that the 
> current proposal falls short in two important respects:
>
> 1. It doesn't deal adequately with numeric precision and/or signed-ness.
>
> 2. It's incomplete in that it doesn't deal with types based on string or 
> bool. Nor does it deal with the inter-convertible types: string/[]bool or 
> string/[]rune which would be useful in practice.
>
> Now a combination of my 'union' and 'except' assertions would address both 
> of these criticisms. However, I have decided that these are too complicated 
> and could lead to some difficult scenarios for the compiler or human reader 
> to sort out. 
>
> Although I still subscribe to the view that: "a simple to use and 
> understand solution that covers 90% is better than a complex one to cover 
> 100%", I think this proposal can (and should) do much better than that - 
> close to full coverage of *realistic* scenarios - while retaining its 
> essential simplicity.
>
> I have therefore decided to make the following changes to the proposal:
>
> 1. The 'union' assertion idea has been dropped completely.
>
> 2. Instead, the number of built-in contracts has been augmented by the 
> following:
>
>* Boolean - any boolean type
>* String - any string type
>* Bytes - any string type or byte slice.
>* Runes - any string type or rune slice
>
> This brings the number of built-in contracts up to 10 which is a lot but 
> worthwhile, IMO, because of the extra expressiveness it will bring.
>
> I continue to take the view that complex types are best segregated from 
> the other numeric types for the reasons I originally gave in the proposal 
> and also because to do otherwise would require, for completeness, the 
> addition of 3 more built-in contracts (Numeric, NonInteger and Addable).
>  
> 3. The 'except' constraint idea has been adopted but in a much restricted 
> form: it will only be able to list built-in numeric types which are to be 
> excluded from the contract. 
>
> To be consistent with the built-in contracts, excluded types will be 
> deemed to include defined types with the same underlying type.
>
> The name will be changed to 'omit' which I think expresses its intent more 
> clearly.
>
> 'omit' will enable us to deal properly with numeric types and, in 
> particular, it will now be possible to build both 'Unsigned' and 'Signed' 
> contracts from the Integer contract and also to disallow smaller integer 
> types (such as int8 and uint8) where necessary. 
>
> So that's a summary of what's changed and the revised proposal is still 
> available at the same link:
> https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab
>
> As I said earlier, I hope Ian can make the draft design work (possibly 
> with some simplifications in the light of feedback) but, if he can't, then 
> I believe this proposal - which addresses the problem of 
> operators/conversions in a different way - would be a plausible alternative.
>
> I'll shut up now (where have I heard that before)!
>
> Alan
>
>  On Friday, September 14, 2018 at 11:32:29 AM UTC+1, alanfo wrote:
>>
>> It's now more than a fortnight since the Go 2 Draft Generics Design was 
>> published and, like many others, I have spent considerable time:
>>
>> 1. Steeped in discussions about the draft.
>>
>> 2. Reading feedback papers by others (Roger Peppe's are particularly 
>> illuminating) most of whom share my opinion that 'contracts' are 
>> unsatisfactory and should be replaced, amended or simplified in various 
>> ways.
>>
>> 3. Attempting to devise a workable alternative to contracts (as envisaged 
>> in the draft) myself.
>>
>> I was then brought back to reality by this post by Robert Engels in the 
>> 'Generics - Why contracts?' thread:
>>  
>> "As I’ve said elsewhere, a SIMPLE to use and understand solution that 
>> covers 90% is better than a complex one to cover 100% IMO, and fits in well 
>> with the rest of Go design. Go leaves out a lot - and it's a good choice."
>>
>> This convinced me that the draft design itself and many third party 
>> proposals (including my own) were too ambitious and what we needed was 
>> something much simpler that gave us 90% coverage and which everybody could 
>> understand. 
>>
>> So I've added a simplified proposal to the feedback page which I feel 
>> meets this more limited aim. For anyone interested, here's the link:

Re: [go-nuts] Unifying the sort functions

[alan . fox6]

Thanks for your comments, Ian.

Unfortunately, no approach is immune to silly mistakes by yours truly but, 
as it's an area where "Effective Go" could offer some pointers, it need not 
be unduly error prone in practice.

The problem with associating operators with named methods is that there 
will be a lot of names for people to remember (or to list in the spec) and, 
given that the built-ins don't have methods, it is unclear what mechanism 
could be used to achieve this association.

With this approach you just have to write one additional method for any 
type which you may need to sort and the standard operators will do the 
rest. Using the 'official' draft design a contract for a sorting function 
could be as simple as this:

contract ordered(x T) {
   x < x
}

and would encompass not just the built-in ordered types (or types with such 
an underlying type) but any other type with an OrderString() method.

I accept, of course, that efficiency may be a concern for large collections 
given the relative slowness of string operations and generation of garbage. 
However, you could always use a custom approach for these cases.

As you say the wiki feedback page could benefit from some organization 
though, if Ian and Robert are planning a second draft in the not too 
distinct future, a lot of the feedback may prove obsolete (or in need of 
substantial revision) in any case.

Alan

On Saturday, October 13, 2018 at 7:14:10 PM UTC+1, Ian Denhardt wrote:
>
> Quoting alanfo (2018-10-13 13:26:18) 
>
> >Suppose we turn this strategy on its head and instead allow types 
>  which 
> >wouldn't otherwise do so support the ordering operators provided they 
> >satisfy a simple interface. This interface would have a single method 
> >which returned a string representation of an object of that type and 
> >the compiler would use this string to implement the ordering 
> operators. 
> >which would enable us to do this: 
> >p1 := Person{"Donald", 1, 20}� �  // stringifies as Donald180 
> >p2 := Person{"Donald", 2, 72}� �  // stringifies as Donald128 
> >b := p1 < p2�  // false because p2 is older and therefore sorts first 
>
> ..but you end up with `Person{"Donald", 3, 101}` < Person{"Donald", 2, 
> 72}` being true, because the 101-year-old overflows the two digit space 
> you've allocated. 
>
> You can make this work by padding out to enough digits to be able to 
> represent any `uint`, but this example suggests to me that the approach 
> is likely to be error-prone in practice. My other immediate reaction is 
> the efficiency concerns, which you bring up yourself. 
>
> What is the advantage of the OrderString() approach over e.g. just 
> having `x < y` desugar to `x.Less(y)` (if a method `Less` is defined on 
> the type of x)?  It is not clear to me what you suggest buys us over 
> this. 
>
> >I apologize if it's already been 
> >suggested by someone else but I'm losing track of what has been 
> >suggested in this area. 
>
> ..it's probably getting to be time to add some organization to the wiki 
> feedback page. 
>

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

Re: [go-nuts] Go language should become an ANSI and ISO standard.

[alan . fox6]

Thanks for posting that very interesting link, Robert.

I'd remembered that Sun originally attempted to standardize Java in the 
late 1990s but later withdrew it. However, I didn't know their reasons for 
this until now.

Alan

On Saturday, October 13, 2018 at 7:10:42 PM UTC+1, robert engels wrote:
>
> This may be of interest 
> https://www.computer.org/csdl/proceedings/hicss/2001/0981/05/09815015.pdf
>
> On Oct 13, 2018, at 12:18 PM, alanfo > 
> wrote:
>
> May I remind those who are in favor of Go standardization that Java and 
> Python have never been standardized by ISO/ANSI/ECMA but that hasn't 
> prevented them from becoming extremely successful languages.
>
> I find it hard to believe that there are large organizations in this day 
> and age who eschew the use of these languages solely because they're not 
> standardized.
>
> Their reference implementations are in effect 'de facto' standards and I 
> don't see why Go, which has a complete and very clear specification, can't 
> become the same. 
>
> Alan
>
> On Wednesday, October 10, 2018 at 5:48:57 PM UTC+1, Michael Jones wrote:
>>
>> I was the engineering director for OpenGL’s birth and growth at SGI and 
>> have perspective on that process, and was for a long time a board member of 
>> the Open Geospatial Consortium (OGC) and have views from those ISO-related 
>> adventures. 
>>
>> I’m with Ian on this—I quite deeply respect standards but see them best 
>> as “recognition of standard practice” rather than “political arena to fight 
>> out new ideas.” The political aspect is not evil, it is simply 
>> acknowledgement of the need to respect diverse stakeholders; but what is 
>> bad about it, technically, is that the path finding of a small inspired 
>> team easily gets lost in the chorus of multitudes wanting everything.
>>
>> In UNIX you had a small inspired team. In almost every really great, 
>> lasting technology you have <= 20 people, often <= 2, who are making the 
>> contentious decisions. That is a critical number. The smallness allows a 
>> cohesive thought process, which allows spirit and flow. Big groupthink 
>> tends the other way, often with better individual decisions but with ideas 
>> that seem almost randomly distributed across the design space.  
>>
>> I would vote to standardize Go 1 when Go 2 is out. 
>>
>> On Wed, Oct 10, 2018 at 8:16 AM Ian Lance Taylor  
>> wrote:
>>
>>> On Wed, Oct 10, 2018 at 7:55 AM, Beoran  wrote:
>>> >
>>> > In certain environments, such as for government contracting in certain 
>>> countries, or for certain large corporations, or for developing safety 
>>> critical applications using certain international standards, only 
>>> programming languages that are officially standardized may be used. While 
>>> Go would be an excellent language for such government or safety critical 
>>> applications, it's acceptance is hampered due to the lack of an official 
>>> standard.
>>> >
>>> > While this is in essence a formality, which would entail submitting 
>>> the current Go language specification with the ANSI, and then have it 
>>> propagate to the ISO, I do appreciate that will take quite some time and 
>>> effort. But to further the acceptance of Go language, I would propose that 
>>> Google invests the necessary resources to make this happen, with support 
>>> from the community to edit the standard document if needed.
>>> >
>>> > The standard should probably be based on Go 1, since Go 2 is still 
>>> largely undecided and probably 5 years in the future.
>>> >
>>> > If you are worried about using Go for safety critical applications 
>>> consider this: it is rare that the compiler builder gives any safety 
>>> warranty, although there are some safety certified C compilers. But for 
>>> similar certified Go compilers to be developed, we need an official 
>>> standard first.
>>> >
>>> > Even if the compiler is not certified, you can still use it if you 
>>> validate it yourself. This implementation of go has extensive unit tests 
>>> which simplifies such validation a lot.
>>> >
>>> > I know of some safety critical software that is implemented in C and 
>>> compiled with GCC. As a language, Go is far safer than that, and that is 
>>> also why we need a standard, to be able to get away from C for some safety 
>>> applications.
>>>
>>> There are significant disadvantages to the standardization process.
>>>
>>> It is slow.
>>>
>>> It is easily politicized, with the possibility that changes to the
>>> language twill be determined by those with the patience and
>>> wherewithal to work through the standardization process, rather than
>>> those with a clear understanding of how the language will work best.
>>> This is not an inevitable result, but it is a risk.
>>>
>>> A likely approach to Go 2 is to roll out changes over time through a
>>> series of releases.  That would be inhibited by a standardization
>>> process.
>>>
>>> The advantages that you describe for standardization are essentially
>>> bureaucratic: some orga

Re: [go-nuts] Unifying the sort functions

[alan . fox6]

What you've just suggested there has the makings of a decent proposal in 
itself :) 

But I think it would inevitably mean that the built-in types would need to 
have methods or at least pseudo-methods for special purposes.

Of course, it may that this is a problem which isn't really worth solving 
by introducing a language change and we should simply accept that the 
built-ins can't be married to other types and therefore we'll always need 
two sets of functions to deal with them both. 

In my own proposal on generic constraints, I started from this premise 
though, when I saw that some folks were attaching importance to a unified 
approach, I began wondering about whether there was a plausible way to 
achieve this - hence this proposal.

Alan

On Saturday, October 13, 2018 at 9:08:34 PM UTC+1, Ian Denhardt wrote:
>
> Quoting alan...@gmail.com  (2018-10-13 15:39:46) 
>
> >Unfortunately, no approach is immune to silly mistakes by yours truly 
> >but, as it's an area where "Effective Go" could offer some pointers, 
> it 
> >need not be unduly error prone in practice. 
>
> Still, some approaches are more error prone than others. It's hard to 
> make a compelling argument without data, but it seems like directly 
> defining Less() would be easier to get right than having to come up with 
> some encoding that preserves your intended notion of equality. 
>
> >The problem with associating operators with named methods is that 
> there 
> >will be a lot of names for people to remember (or to list in the 
> spec) 
>
> I think you could take an approach where you only have one method per 
> "category" of operators. So for example, rather than having separate 
> methods for each of <, >, <=, and >=, you could just have: 
>
> x < y desugars to x.Less(y) 
> x > y desugars to y.Less(x) 
> x >= y desugars to !x.Less(y) 
> x <= y desugars to !y.Less(x) 
>
> Similarly, for == and != you could just define a method `Equal`, and 
> have: 
>
> x == y desugars to x.Equal(y) 
> x != y desugars to !x.Equal(y) 
>
> There are some deeper problems with overloading == with a method, 
> namely that right now == does different things for Foo and *Foo, which 
> is not something that is generally possible for methods, but your 
> proposal has the same problem. 
>
> > and, given that the built-ins don't have methods, it is unclear 
> > what mechanism could be used to achieve this association. 
>
> My first thought is that we could just change the language such that 
> built-in types *do* have methods. 
>

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

Re: [go-nuts] Go language should become an ANSI and ISO standard.

[alan . fox6]

I don't whether establishing a community based workgroup would help Go to 
gain wider acceptance or not. Java has its JCP program and Python has PEP 
which seem to work in a fashion. 

However, I certainly think that this sort of approach would be preferable 
to formal standardization which I am completely opposed to. 

Alan

On Saturday, October 13, 2018 at 10:51:46 PM UTC+1, Björn De Meyer wrote:
>
> I can assure you that my concern is not theoretical but based on real life 
> experience. Unfortunately I am not at liberty to discuss in detail... 
>
> As for the approach, a community based workgroup with backing from Google 
> may be a more viable idea.

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

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

[alan . fox6]

On Tuesday, October 16, 2018 at 6:05:56 PM UTC+1, Eric Raymond wrote:
>
>
>
> On Tuesday, October 16, 2018 at 12:24:59 PM UTC-4, alanfo wrote:
>>
>> With regard to your reply to Ian, I'm afraid I can't agree with you that 
>> the type parameters shouldn't be specified 'up front'. That's just too 
>> 'dynamic' for me and not very go-like. I'd imagine it would give the 
>> compiler all sorts of problems and anyone reading the code would wonder 
>> whether T, Node, Edge etc. were concrete types defined elsewhere in the 
>> package or type parameters of a generic function.
>>
>
> So now we get to the philosophical issue.  Why and when do I *care* 
> whether  I'm looking at a concrete type or type parameter? 
>
> I maintain that normally I don't - it only matters to me what contract the 
> type is expected to satisfy, and that should be clear from looking at its 
> callsites.  If it isn't clear, that's a problem that heavier notation won't 
> solve.
>
> I've already thought of a compilation strategy for this. It's not a new 
> problem; I had to think about a closely parallel case in Lisp around 1980.
>

 I don't think you can disregard philosophical aspects in language design. 
Whatever proposal for generics is finally settled on needs to be a good fit 
for the language, consistent with its ethos and not impact too adversely on 
compilation time which has always been one of Go's strengths.

At the end of the day Go is a statically typed C-family language and is 
nothing like either Lisp or Python. As such Go users have different 
expectations to users of a dynamically typed language. 

Perhaps I'm wrong about this (as ILT didn't rule it out as I expected him 
to) but when I see a function definition I want to know immediately about 
its return type, the types of its parameters and, if it involves 
parameterized types, I want to know about them too. I don't want to search 
for an instantiation of the function to figure out which is which.

Now you've said that you dislike the syntax which Ian and Robert came up 
with for defining type parameters which is fair enough (though personally I 
did like it) and it may be that there are simpler ways of differentiating 
type parameters from normal parameters (such as preceding the former with a 
tick or something) which would fit this proposal better. All I'm saying is 
that I'd like to know which is which when the function is defined and I'd 
have thought that most other Go users would say the same.

Alan

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

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

[alan . fox6]

Yes, that's a fair point.

As I was wobbling anyway, I'll give way on that one :)

Alan

On Wednesday, October 17, 2018 at 6:47:25 PM UTC+1, Patrick Smith wrote:
>
> On Wed, Oct 17, 2018 at 3:13 AM alanfo > 
> wrote:
>
>> On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote:
>>>
>>> If overloading [] were disallowed, how would one write a generic 
>>> function taking a single argument of type either []int or a user-defined 
>>> type with similar behavior, and returning the sum of the elements? Sort of 
>>> the marriage of these two functions:
>>>
>>
>>  I'm wobbling a bit on disallowing the overloading of the indexation 
>> operator following something Eric said in response to that.
>>
>> However, as long as the proposal includes the ability to overload 
>> conversions as well as operators (another point I made earlier), the 
>> example you gave could be dealt with by implementing a conversion to []int 
>> so you could then use all the latter's properties to code a common function.
>>
>
> If I understand correctly, you would make a copy of the entire list in 
> order to be able to iterate over it? This seems inefficient.
>

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

Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received

[alan . fox6]

Ian D,

The introduction is certainly not intended to be insulting to those who 
have put serious thought into the problem. If it were, then I'd be 
insulting myself as I've put serious thought into at least two other 
proposals which are nothing like the current one!

It's simply a realization I've come to that there's a lot of mileage in the 
original draft which is the culmination of what two very smart people have 
been working on for years and should not therefore be dismissed too readily.

Sure, it's not perfect and that's why I have suggested some changes which 
no doubt are still far from perfect!

I don't think I have dismissed anything without providing some 
justification for it. FWIW I personally would like to see some form of 
operator overloading even though I acknowledge it has a lot of problems and 
we're unlikely to see it.

I also don't think that Eric was being disrespectful to Ian LT and Robert. 
He simply has a profound dislike for the draft generics design and believes 
in expressing himself forcibly and at times, comically :)

Alan


On Friday, October 19, 2018 at 8:49:31 PM UTC+1, Ian Denhardt wrote:

> First, I find the introduction to this condescending; it amounts to "the 
> Go developers know what they're doing, stop questioning them plebians!" 
> It is phrased more politely, but the content is basically there. This 
> is: 
>
> 1. Insulting to those of us who also have put serious thought 
>into the problem, and perhaps also have knowledge and experience 
>in this area of programming language design. 
> 2. Largely missing the point of the draft designs, which were meant 
>as a starting point for discussion; the Go developers were 
>explicitly soliciting feedback. 
> 3. Ignores the fact that most of us have been raising specific 
>critiques of the design. While our criticisms are based on 
>substance, you dismiss them entirely without providing a 
>justification other than "Ian and Robert know what they're 
>doing." 
>
> Second, I agree with Tristan that Eric's sibling comment is a bit sharp; 
> let's be careful to keep this civil, as it's clear that some of us are 
> feeling a bit tense. 
>
> Ultimately however I agree with Eric that the proposal focuses on 
> relatively superficial issues. 
>
> That said I do like the idea of using [type T]; while my own focus has 
> been on semantics, like many I agree the existing syntax is not very 
> ergonomic. 
>
> Quoting alanfo (2018-10-19 13:48:20) 
> >My head has been spinning lately after reading the various generic 
> >counter-proposals and suddenly the original draft design seems a lot 
> >more attractive than it did :) 
> >In the light of all the feedback there's been, I've put together a 
> >proposal which sticks closely to the original design and only changes 
> >what most people consider needs to be changed in some way. Some 
> recent 
> >ideas which seemed plausible but which I felt had little chance of 
> >adoption have been rejected. 
> >It's not too long so give it a read and see what you think. 
> >Here's the link: 
> >[1]https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87 
> >Alan 
>
 

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

Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received

[alan . fox6]

Ian D,

I'm sorry that we had a mis-understanding regarding the introduction to my 
paper but I hope you now understand why I made the remarks I did.

To turn to the technical issues.

I haven't checked them all but I did notice one example which your paper 
doesn't appear to cover, namely the add1K example which has been a 
stumbling block for a lot of proposals including my own though I did 
eventually find a way of dealing with it. 

Perhaps I could go through the reasons why I have concluded that it is 
better to stick with contracts rather than interfaces even though the two 
approaches are not completely orthogonal:

1. If interfaces were used, a way would need to be devised to express that 
a type supports a particular operator or operators. To be compatible with 
methods something like the following seems best:

+(T, T) T

However, this would mean that someone writing an interface to be used for 
generic constraint purposes would have to know and write out the signature 
for each operator used.

In contrast, when writing a contract, it doesn't matter whether the syntax 
we use is compatible with methods or not as it's a new concept. So writing 
something like T + T is fine and the writer doesn't even need to know what 
the signature of '+' is.

How to express operators was, of course, identified in the draft design 
paper itself as a difficulty with interfaces and it was mentioned that 
there was a subtlety with the == operator which returns an untyped bool 
rather than a typed bool.

2. As your own paper clearly shows, it is possible to deal with multiple 
type parameters which refer to each other using an interface based approach 
and even the draft design paper itself admits this is possible. However, it 
seems to me to be less elegant than a contract based approach. 

An interface can only express the methods which a single type needs to 
satisfy and so a separate interface is needed for each mutually referential 
type parameter. A contract on the other hand doesn't have this constraint 
and, indeed, the type parameters as a group have to satisfy a single 
contract which, to my mind, ties the whole thing together in a much nicer 
way.

3. Interfaces don't deal with fields at all and so would need to be 
extended to cope with a struct constraint. To be fair, some people have 
questioned whether such constraints are important enough to be catered for 
at all but the draft design does nevertheless deal with them and so does my 
own paper.

4. There are a number of minor (though tricky) issues which interfaces 
can't currently deal with but contracts can and which I listed in my paper. 
To take one in particular - excluded types - it is difficult to see how 
interfaces could deal with something like that though, as it's a novel idea 
anyway, perhaps some other way could be found to achieve the same result.

5. Finally - and you might think this is a bit silly - but there are a lot 
of people who don't like the idea of generics at all and will probably try 
to avoid them if they can. Now, hopefully they will change their minds when 
they see how convenient generics can be to use. Nevertheless, I still think 
it's important to cater for such people and leaving interfaces as they are 
and confining the generic stuff to contracts should help here.

On your last point about unification of generic methods (or the lack of it 
without operator overloading), I suspect that the Go team will prefer your 
option 1 (two generic methods, one for the built-ins and the other for 
types which satisfy an equivalent interface) as far as the standard library 
is concerned - at least where slices and maps are concerned.

Option 3 (operator version only) is clearly an incomplete solution and I 
doubt whether they'd be keen on option 2 either (method based version 
only)  because wrapping and unwrapping non-scalar types is such a pain.

Alan

On Saturday, October 20, 2018 at 4:31:09 PM UTC+1, Ian Denhardt wrote:
>
> Quoting alan...@gmail.com  (2018-10-19 16:19:36) 
> >Ian D, 
> >The introduction is certainly not intended to be insulting to those 
> who 
> >have put serious thought into the problem. If it were, then I'd be 
> >insulting myself as I've put serious thought into at least two other 
> >proposals which are nothing like the current one! 
>
> I apologize if I've interpreted things less charitably that I should 
> have. 
>
> >It's simply a realization I've come to that there's a lot of mileage 
> in 
> >the original draft which is the culmination of what two very smart 
> >people have been working on for years and should not therefore be 
> >dismissed too readily. 
>
> I certainly agree with this. My own proposal left type parameters 
> basically untouched, though I have specific criticisms I and many others 
> have made elsewhere regarding contracts. 
>
> The original draft was indeed *very* thorough, and provided many useful 
> motivating examples that act as some tests f

Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received

[alan . fox6]

I've thought of some other ways of excluding 'string' so that one could 
restrict an 'exclude' constraint to just numeric types.

At the expense of adding another line, you could do:
   int(T)

or if (say) T * T implied T + T, T - T and T / T (which would certainly be 
true) then you could use that instead of T + T.

However, if stuff were used in the contract for which there was no analog 
in the function code itself, it would inevitably introduce some opacity and 
anyone comparing the contract with the function, who was unaware of such 
hacks, might wonder why on earth that had been done.

On the other hand, it would provide some future-proofing as one might later 
introduce a function which did use the * operator and could then reuse the 
same contract rather than writing another one.

Alan

On Sunday, October 21, 2018 at 12:21:46 AM UTC+1, alanfo wrote:
>
> I think it's fair to say that dealing with untyped numeric constants is 
> one of the most opaque areas of the draft design and I remember thinking 
> when I first read it that a clearer and more intuitive solution would have 
> to be found.
>
> As far as the 'excluded types' idea is concerned, I can't really think of 
> any other use cases apart from numeric ranges though it's worth noting in 
> my paper I had this example:
>
> contract add1K(T) {
> T + T
> T(unsigned int)
> exclude{string, int8, uint8}(T)  // can't add a thousand to these 
> }
>
> where I had to explicitly exclude 'string' because it supports both the + 
> operator and a conversion from any integer value.
>
> Alan
>
> On Saturday, October 20, 2018 at 11:36:02 PM UTC+1, Ian Denhardt wrote:
>>
>> Quoting alan...@gmail.com (2018-10-20 16:59:52) 
>>
>> >I haven't checked them all but I did notice one example which your 
>> >paper doesn't appear to cover, namely the add1K example which has 
>> been 
>> >a stumbling block for a lot of proposals including my own though I 
>> did 
>> >eventually find a way of dealing with it. 
>>
>> This is a fair point. I have a couple of initial thoughts, but will 
>> think about it. The contract there actually brings up my other big 
>> complaint about contracts besides non-orthogonality; they are not a good 
>> expression of intent. For reference: 
>>
>> contract add1K(x T) { 
>> x = 1000 
>> x + x 
>> } 
>>
>> While it's possible to piece together what has to be true about a type 
>> to satisfy this contract, it's really not obvious at the outset what the 
>> point of it is. Looking at the contracts in the draft design, I feel 
>> like I would generally speaking have to jump through mental hoops to 
>> understand what concepts were being expressed by a given contract. 
>>
>> >1. If interfaces were used, a way would need to be devised to 
>> express 
>> >that a type supports a particular operator or operators. To be 
>> >compatible with methods something like the following seems best: 
>> >� � �  +(T, T) T 
>> >However, this would mean that someone writing an interface to be 
>> used 
>> >for generic constraint purposes would have to know and write out the 
>> >signature for each operator used. 
>>
>> This seems like a relatively minor problem. Eric sketched out a possible 
>> syntax, here is another: 
>>
>> type Ordered[type T] interface { 
>> operator < (other T) bool 
>> } 
>>
>> func (MyType) operator < (other T) bool { ... } 
>>
>> (where `operator` becomes a keyword) 
>>
>> I'm not convinced having to remember the type signatures is a 
>> problem -- for most operators they are fairly self-evident, and we 
>> already have to do this for a wide range of interfaces in the standard 
>> library. I think adding a whole new concept to the language is a much 
>> bigger cognitive load. 
>>
>> >2. As your own paper clearly shows, it is possible to deal with 
>> >multiple type parameters which refer to each other using an 
>> interface 
>> >based approach and even the draft design paper itself admits this is 
>> >possible. However, it seems to me to be less elegant than a contract 
>> >based approach. 
>> >An interface can only express the methods which a single type needs 
>> to 
>> >satisfy and so a separate interface is needed for each mutually 
>> >referential type parameter. A contract on the other hand doesn't 
>> have 
>> >this constraint and, indeed, the type parameters as a group have to 
>> >satisfy a single contract which, to my mind, ties the whole thing 
>> >together in a much nicer way. 
>>
>> I actually have a fairly clear design in my head for adding associated 
>> types to interfaces, which my current design generalizes to cleanly, but 
>> I left it out because I'm not convinced that this kind of thing is 
>> common enough to be worth optimizing for. My gut is that this kind of 
>> contract will be the exception, rather than the rule, and I would err on 
>> the side of leaving things out. I think i

Re: [go-nuts] Proposed changes to the Go draft generics design in the light of feedback received

[alan . fox6]

Hi Patrick,

I guess it's largely a matter of taste but one of the reasons why I prefer 
contracts to interfaces is precisely because you only need one contract for 
the type parameters as a whole.

This keeps the type parameter section of the generic function/type 
relatively brief when you have more than one parameter as well as tying 
things together when you have mutually referential parameters.

Even if a contract could only refer to a single parameter, I'm also not 
keen on using the contract name for that parameter which I think would be 
relatively verbose. This is because the contract could have a longish name 
whereas type parameters typically have short names, often a single upper 
case letter.

I'm pleased you liked the simplified syntax for the contract body though :)

Alan

On Monday, October 22, 2018 at 9:16:22 PM UTC+1, Patrick Smith wrote:
>
> On Fri, Oct 19, 2018 at 10:48 AM alanfo > 
> wrote:
>
>> In the light of all the feedback there's been, I've put together a 
>> proposal which sticks closely to the original design and only changes what 
>> most people consider needs to be changed in some way. Some recent ideas 
>> which seemed plausible but which I felt had little chance of adoption have 
>> been rejected.
>>
>> https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87
>>
>
> I like your simplified syntax for contracts, but I would prefer to see 
> contracts specify one type at a time, rather than several. I think this 
> will be easier for people to understand when type parameters are 
> independent or have only one-way dependencies, and that this case will be 
> much more command than the case of mutual dependencies. A suitable syntax 
> might be something like
>
> contract Addable {
>
> // Note: using the contract name to represent the type being described
>
> Addable + Addable
>
> } 
>
> func SliceSum[type T](s []T) T {
>
> var sum T
>
> for _, t := range s {
>
> sum = sum + t
>
> }
>
> }
>
> contract List[type T] {
>
> func (List) Len() int
>
> func (List) At(int) T
>
> }
>
> func ListSum[type L List[T], T Addable](l L) T {
>
> var sum T
>
> for n := 0; n < l.Len(); n++ {
>
> sum = sum + l.At(n)
>
> }
>
> }
>
> contract Comparable {
>
> func (Comparable) Equal(Comparable) bool
>
> }
>
> contract Hashable {
>
> Comparable   // embedding
>
> func (Comparable) Hash() uint64
>
> }
>
> // An associative array using user-defined notions of equality and hashing
> type Map[type K Hashable, V] struct { ... }
>
> contract NodeType[type E] {
>
> func (NodeType) Edges() []E
>
> }
>
> contract EdgeType[type N] {
>
> func (EdgeType) Nodes() (N, N)
>
> }
>
> type Graph[type N NodeType[E], type E EdgeType[N]] struct { ... }
>
> This is somewhat like the "interfaces instead of contracts" proposals, but 
> without trying to force everything into interfaces. To enforce one type per 
> contract, we could have a rule that every line in a contract that is not an 
> embedding of another contract must explicitly use the contract name, and 
> the receiver type of a method must be either ContractName or *ContractName.
>

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

[go-nuts] Re: invalid months and years in time package

[alan . fox6]

If you check the source code for the time.Date() function, you'll find that 
it does indeed normalize the date by calling a private 'norm' function.

So, if you enter a month of 13, it will overflow into January of the 
following year.

My guess is that they thought this was a better solution than returning an 
error. It's also a convenient way to adjust a date (forwards or backwards) 
at the same time as you initialize it.

Alan

On Tuesday, October 23, 2018 at 9:20:29 PM UTC+1, Taras D wrote:
>
> Yes sorry -1 is a valid year.
>
> An invalid month is any integer outside of [1,12]. We can always define 
> month 13 as January if we adopt Z_12, but I expected an error to occur. 
> Accepting months outside of [1,12] violates the Principle of least 
> astonishment.
>
> For comparison, python verifies the month integer:
>
> > 1 datetime.date(2000, 13, 1)
> ValueError: month must be in 1..12
>
>
> So does golang accept these values because:
> - a sensible definition exists for values outside of [1,12]?
> - for performance reasons?
>
> Taras
>
> On Wednesday, 24 October 2018 01:23:35 UTC+11, Volker Dobler wrote:
>>
>> Why is year -1 invalid and what is an "invalid" month
>> given that 13==1 in Z_12?
>>
>> V.
>>
>>
>>
>> On Tuesday, 23 October 2018 16:01:00 UTC+2, Taras D wrote:
>>>
>>> Hi,
>>>
>>> I was surprised to find the following worked without any reported errors:
>>>
>>> t1 := time.Date(-1, 1, 10, 23, 0, 0, 0, time.UTC) // invalid year
>>> t2 := time.Date(2000, 13, 10, 23, 0, 0, 0, time.UTC) // invalid month
>>> m := time.Month(13) // invalid month
>>>
>>> What is the rationale in accepting invalid month/year values?
>>>
>>

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

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alan . fox6]

Hmm, interesting idea!

Presumably, that would still work if 'check' were declared as a local 
variable within the same function *after* all the error handling stuff, as 
the compiler would detect it on first pass.

I wondered myself about having some sort of pragma or pseudo-import (say: 
import . "E") at top level within the package to turn the new error 
handling on but as that would be a new feature in itself perhaps it's not 
such a good idea.

Alan

On Wednesday, October 24, 2018 at 3:22:03 PM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Oct 24, 2018 at 3:49 AM, alanfo > 
> wrote: 
> > 
> > I quite like the draft error handling design and haven't (so far) 
> suggested 
> > that any changes be made. 
> > 
> > However, one aspect I don't like is 'check' and 'handle' having to be 
> > keywords which means that the design is not Go 1 compatible. Also, 
> whilst I 
> > agree that these words are probably the best ones for the job (and I 
> would 
> > hate to see them replaced by obscure symbols) it seems a pity that such 
> > commonly used words will no longer be available as ordinary identifiers. 
> > 
> > So all I'm asking here is whether - if the design were adopted as it 
> stands 
> > - they could be 'contextual' rather than 'full' keywords? I couldn't 
> find 
> > any mention of this in the draft papers but apologize in advance if it's 
> > been addressed and I've missed it. 
> > 
> > As far as this thread is concerned, I'm only interested in this question 
> and 
> > not what people think of the design generally. 
> > 
> > It seems to me that they probably could be 'contextual' keywords i.e. 
> they 
> > could still be used as ordinary identifiers in the same package or even 
> > within the same function (though the latter wouldn't be a great idea 
> from a 
> > readability perspective). 
> > 
> > Considering first 'handle' which must be the first word in a line and 
> then 
> > be followed by an identifier. It cannot be any of the following: 
> > 
> > 1. A function call because its not followed by (. 
> > 
> > 2. An assignment because it's not followed by an =, :=  or , token. 
> > 
> > 3. An indexation expression because it's not followed by [. 
> > 
> > 4. A struct literal because it's not (directly) followed by {. 
> > 
> > 5. Any other expression because it's not followed by an operator. 
> > 
> > So can anyone think of anything else it could be? 
> > 
> > However, 'check' is more awkward because it's followed by an expression 
> (not 
> > an identifier) and need not be the first word in the line. If the 
> expression 
> > were bracketed or preceded by a unary operator then there would be a 
> > potential ambiguity with #1 or #5 respectively. 
> > 
> > So would it suffice for the compiler to try and interpret 'check' in 
> these 
> > situations as a 'normal' identifier and issue an error if it couldn't 
> but 
> > otherwise to interpret it as a error handling keyword? 
> > 
> > The error would of course be easy enough to fix but, even if there are 
> no 
> > other ambiguities, would it just be too confusing and should we simply 
> > accept that 'check' has to be a 'full' keyword as the design stands? 
>
> I think that if a package does define `check` as a local function, 
> then making contextual choices about whether `check` in an expression 
> refers to the function or to the error checking behavior can only be 
> confusing. 
>
> One approach that could perhaps work--and I'm not at all endorsing 
> this, just pointing it out--is that if a package defines `check` as a 
> local name of any sort, the compiler could simply disable the error 
> checking behavior of `check`.  That is, `check` would only be a 
> keyword if there were no local definition of `check`. 
>
> Ian 
>

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

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alan . fox6]

Inspired to some extent by Ian's idea, I've had another idea which could 
rid us of the *new keyword problem* not just for Go 1.xx or Go 2 but for 
ever. We wouldn't even have to worry about whether a new keyword could be 
restricted to *contextual* use or not.

Suppose any new keyword introduced from Go 1.xx onwards could only begin 
with a lower case letter and could *optionally* be followed by the *!* 
symbol for disambiguation purposes. So, one could potentially have check!, 
handle!, contract! and so on.

Suppose further that:

1. If you didn't use *!* and there was some local entity in an *encompassing 
scope* with the same name as the keyword, the compiler flagged it as an 
error.

2. If you did use *!* unnecessarily, the compiler would also flag that as 
an error.

Now in the first case, you'd have the choice of either changing the name of 
the local entity to a non-keyword or adding *!* to the keyword usage(s). In 
practice, most people would probably choose the former.

In the second case, you'd simply remove the *!* and that would be the end 
of the matter.

Technically, an *encompassing scope* would be any scope which was or 
included the scope in which the new keyword were being used. It would 
therefore always include package scope as a minimum.

The advantages of this approach would be:

1. *!* would probably be seldom needed and so shouldn't impact too 
adversely on the *look* of the code. Over time, people might simply learn 
to avoid using the new keywords as normal identifiers at least at top level 
within the package. 

2. Existing code or new code using the *old* approach would continue to 
compile without problem.

3. Any function or method which didn't use any new keywords as such could 
still freely use them as identifiers for parameters, local variables or 
local constants. Disambiguation (or the lack of it) with similarly named 
top level entities (including new keywords) would be the same as it is 
today - the latter would simply be hidden.

4. Basically, you could just program normally (without *!*) knowing that 
the compiler would flag up any clashes.

5. Clashes with imported names would never be a problem because they'd 
usually be qualified by their package name and would begin with an upper 
case letter anyway.

Although other symbols such as $, %, @ or ? could be used in place of* !*, 
I think the latter is probably the best choice as (to me at least) it looks 
less intrusive than the others and doesn't have any other connotation. It's 
also used (for different disambiguation purposes) in other modern languages 
such as Rust and Swift.

As far as the generics proposal is concerned, the use of the contract 
keyword (which always appears at top level within the package) would only 
be flagged as ambiguous if there were another similarly named top level 
entity. Any use of *contract* within a function or method would not be a 
problem because of #3 above  

So what do you think, a viable idea or not?

Alan

On Wednesday, October 24, 2018 at 3:22:03 PM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Oct 24, 2018 at 3:49 AM, alanfo > 
> wrote: 
> > 
> > I quite like the draft error handling design and haven't (so far) 
> suggested 
> > that any changes be made. 
> > 
> > However, one aspect I don't like is 'check' and 'handle' having to be 
> > keywords which means that the design is not Go 1 compatible. Also, 
> whilst I 
> > agree that these words are probably the best ones for the job (and I 
> would 
> > hate to see them replaced by obscure symbols) it seems a pity that such 
> > commonly used words will no longer be available as ordinary identifiers. 
> > 
> > So all I'm asking here is whether - if the design were adopted as it 
> stands 
> > - they could be 'contextual' rather than 'full' keywords? I couldn't 
> find 
> > any mention of this in the draft papers but apologize in advance if it's 
> > been addressed and I've missed it. 
> > 
> > As far as this thread is concerned, I'm only interested in this question 
> and 
> > not what people think of the design generally. 
> > 
> > It seems to me that they probably could be 'contextual' keywords i.e. 
> they 
> > could still be used as ordinary identifiers in the same package or even 
> > within the same function (though the latter wouldn't be a great idea 
> from a 
> > readability perspective). 
> > 
> > Considering first 'handle' which must be the first word in a line and 
> then 
> > be followed by an identifier. It cannot be any of the following: 
> > 
> > 1. A function call because its not followed by (. 
> > 
> > 2. An assignment because it's not followed by an =, :=  or , token. 
> > 
> > 3. An indexation expression because it's not followed by [. 
> > 
> > 4. A struct literal because it's not (directly) followed by {. 
> > 
> > 5. Any other expression because it's not followed by an operator. 
> > 
> > So can anyone think of anything else it could be? 
> > 
> > However, 'check' is more awkward because it's followed by

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alan . fox6]

Well, FWIW, I'm not a fan of sigils either though, in this particular case, 
it did seem to me to be a convenient way of solving a thorny problem given 
that* ! *wouldn't be needed much anyway.

So what would you suggest then?

I think Ian's suggestion would work but, as a general approach, seems 
rather drastic.

A pseudo-import would also work but to retain any granularity you might end 
up needing a long list of these as the years go by. 

Both the above are also 'take it or leave it' approaches. Either you can 
use the new keywords as such or you can use them as ordinary identifiers - 
you can't do both in the same package which my suggestion would allow.

Alan

On Saturday, October 27, 2018 at 3:49:24 AM UTC+1, kortschak wrote:
>
> Please no. The absence of sigils in Go is one of the syntactic features 
> of the language that make it light to read. 
>
> I don't want a symbol that, even if only due to external cultural 
> context, suggests that the code is trying to say something exciting. 
>
> On Fri, 2018-10-26 at 03:22 -0700, alan...@gmail.com  wrote: 
> > Inspired to some extent by Ian's idea, I've had another idea which 
> > could 
> > rid us of the *new keyword problem* not just for Go 1.xx or Go 2 but 
> > for 
> > ever. We wouldn't even have to worry about whether a new keyword 
> > could be 
> > restricted to *contextual* use or not. 
> > 
> > Suppose any new keyword introduced from Go 1.xx onwards could only 
> > begin 
> > with a lower case letter and could *optionally* be followed by the 
> > *!* 
> > symbol for disambiguation purposes. So, one could potentially have 
> > check!, 
> > handle!, contract! and so on. 
> > 
> > Suppose further that: 
> > 
> > 1. If you didn't use *!* and there was some local entity in an 
> > *encompassing 
> > scope* with the same name as the keyword, the compiler flagged it as 
> > an 
> > error. 
> > 
> > 2. If you did use *!* unnecessarily, the compiler would also flag 
> > that as 
> > an error. 
> > 
> > Now in the first case, you'd have the choice of either changing the 
> > name of 
> > the local entity to a non-keyword or adding *!* to the keyword 
> > usage(s). In 
> > practice, most people would probably choose the former. 
> > 
> > In the second case, you'd simply remove the *!* and that would be the 
> > end 
> > of the matter. 
> > 
> > Technically, an *encompassing scope* would be any scope which was or 
> > included the scope in which the new keyword were being used. It 
> > would 
> > therefore always include package scope as a minimum. 
> > 
> > The advantages of this approach would be: 
> > 
> > 1. *!* would probably be seldom needed and so shouldn't impact too 
> > adversely on the *look* of the code. Over time, people might simply 
> > learn 
> > to avoid using the new keywords as normal identifiers at least at top 
> > level 
> > within the package. 
> > 
> > 2. Existing code or new code using the *old* approach would continue 
> > to 
> > compile without problem. 
> > 
> > 3. Any function or method which didn't use any new keywords as such 
> > could 
> > still freely use them as identifiers for parameters, local variables 
> > or 
> > local constants. Disambiguation (or the lack of it) with similarly 
> > named 
> > top level entities (including new keywords) would be the same as it 
> > is 
> > today - the latter would simply be hidden. 
> > 
> > 4. Basically, you could just program normally (without *!*) knowing 
> > that 
> > the compiler would flag up any clashes. 
> > 
> > 5. Clashes with imported names would never be a problem because 
> > they'd 
> > usually be qualified by their package name and would begin with an 
> > upper 
> > case letter anyway. 
> > 
> > Although other symbols such as $, %, @ or ? could be used in place 
> > of* !*, 
> > I think the latter is probably the best choice as (to me at least) it 
> > looks 
> > less intrusive than the others and doesn't have any other 
> > connotation. It's 
> > also used (for different disambiguation purposes) in other modern 
> > languages 
> > such as Rust and Swift. 
> > 
> > As far as the generics proposal is concerned, the use of the 
> > contract 
> > keyword (which always appears at top level within the package) would 
> > only 
> > be flagged as ambiguous if there were another similarly named top 
> > level 
> > entity. Any use of *contract* within a function or method would not 
> > be a 
> > problem because of #3 above 
> > 
> > So what do you think, a viable idea or not? 
> > 
> > Alan 
> > 
> > On Wednesday, October 24, 2018 at 3:22:03 PM UTC+1, Ian Lance Taylor 
> > wrote: 
> > > 
> > > 
> > > On Wed, Oct 24, 2018 at 3:49 AM, alanfo  > > > 
> > > wrote: 
> > > > 
> > > > 
> > > > I quite like the draft error handling design and haven't (so 
> > > > far) 
> > > suggested 
> > > > 
> > > > that any changes be made. 
> > > > 
> > > > However, one aspect I don't like is 'check' and 'handle' having 
> > > > to be 
> > > > keywords which means that the design is not Go 1 

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alan . fox6]

So you're basically saying that an identifier should either be reserved or 
not and that there should be no *contextual* keywords at all, not even 
*contract*.

Well, it's a clear and simple stance to take but it inevitably means that 
adding any new keyword will not be backwards compatible and I'm not sure 
the Go team will be happy with it because of that.

Alan

On Saturday, October 27, 2018 at 1:31:49 PM UTC+1, rog wrote:
>
> I'm not keen on this idea (including Ian's idea too). It makes parsing 
> context-sensitive because the set of syntactic tokens varies would depend 
> on the names declared in the package. That is, you can't parse a file in 
> isolation because without reading all the files in a package, you don't 
> know which of the keywords have been defined as local names. It would mean 
> that you couldn't just pipe an arbitrary Go file to gofmt, for example.
>
> The context-insensitive grammar is one of Go's great strengths. Let's not 
> lose that, please.
>
>
>
>
>
> On Fri, 26 Oct 2018 at 11:22, > wrote:
>
>> Inspired to some extent by Ian's idea, I've had another idea which could 
>> rid us of the *new keyword problem* not just for Go 1.xx or Go 2 but for 
>> ever. We wouldn't even have to worry about whether a new keyword could be 
>> restricted to *contextual* use or not.
>>
>> Suppose any new keyword introduced from Go 1.xx onwards could only begin 
>> with a lower case letter and could *optionally* be followed by the *!* 
>> symbol for disambiguation purposes. So, one could potentially have check!, 
>> handle!, contract! and so on.
>>
>> Suppose further that:
>>
>> 1. If you didn't use *!* and there was some local entity in an *encompassing 
>> scope* with the same name as the keyword, the compiler flagged it as an 
>> error.
>>
>> 2. If you did use *!* unnecessarily, the compiler would also flag that 
>> as an error.
>>
>> Now in the first case, you'd have the choice of either changing the name 
>> of the local entity to a non-keyword or adding *!* to the keyword 
>> usage(s). In practice, most people would probably choose the former.
>>
>> In the second case, you'd simply remove the *!* and that would be the 
>> end of the matter.
>>
>> Technically, an *encompassing scope* would be any scope which was or 
>> included the scope in which the new keyword were being used. It would 
>> therefore always include package scope as a minimum.
>>
>> The advantages of this approach would be:
>>
>> 1. *!* would probably be seldom needed and so shouldn't impact too 
>> adversely on the *look* of the code. Over time, people might simply 
>> learn to avoid using the new keywords as normal identifiers at least at top 
>> level within the package. 
>>
>> 2. Existing code or new code using the *old* approach would continue to 
>> compile without problem.
>>
>> 3. Any function or method which didn't use any new keywords as such could 
>> still freely use them as identifiers for parameters, local variables or 
>> local constants. Disambiguation (or the lack of it) with similarly named 
>> top level entities (including new keywords) would be the same as it is 
>> today - the latter would simply be hidden.
>>
>> 4. Basically, you could just program normally (without *!*) knowing that 
>> the compiler would flag up any clashes.
>>
>> 5. Clashes with imported names would never be a problem because they'd 
>> usually be qualified by their package name and would begin with an upper 
>> case letter anyway.
>>
>> Although other symbols such as $, %, @ or ? could be used in place of* !*, 
>> I think the latter is probably the best choice as (to me at least) it looks 
>> less intrusive than the others and doesn't have any other connotation. It's 
>> also used (for different disambiguation purposes) in other modern languages 
>> such as Rust and Swift.
>>
>> As far as the generics proposal is concerned, the use of the contract 
>> keyword (which always appears at top level within the package) would only 
>> be flagged as ambiguous if there were another similarly named top level 
>> entity. Any use of *contract* within a function or method would not be a 
>> problem because of #3 above  
>>
>> So what do you think, a viable idea or not?
>>
>> Alan
>>
>> On Wednesday, October 24, 2018 at 3:22:03 PM UTC+1, Ian Lance Taylor 
>> wrote:
>>>
>>> On Wed, Oct 24, 2018 at 3:49 AM, alanfo  wrote: 
>>> > 
>>> > I quite like the draft error handling design and haven't (so far) 
>>> suggested 
>>> > that any changes be made. 
>>> > 
>>> > However, one aspect I don't like is 'check' and 'handle' having to be 
>>> > keywords which means that the design is not Go 1 compatible. Also, 
>>> whilst I 
>>> > agree that these words are probably the best ones for the job (and I 
>>> would 
>>> > hate to see them replaced by obscure symbols) it seems a pity that 
>>> such 
>>> > commonly used words will no longer be available as ordinary 
>>> identifiers. 
>>> > 
>>> > So all I'm asking here is whether - if the design were adopted as it 

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alan . fox6]

That's a sensible suggestion, Burak, but I wanted to restrict this thread 
to how we would deal with any new keywords rather than the merits of the 
draft error handling design itself. 

Of course, it may be that the potential answers to the first problem will 
influence the design that is eventually settled upon. We'll have to wait 
and see.

Alan

On Saturday, October 27, 2018 at 7:48:41 PM UTC+1, Burak Serdar wrote:
>
> On Sat, Oct 27, 2018 at 11:26 AM roger peppe  > wrote: 
> > 
> > 
> > 
> > On Sat, 27 Oct 2018, 5:46 pm  wrote: 
> >> 
> >> So you're basically saying that an identifier should either be reserved 
> or not and that there should be no contextual keywords at all, not even 
> contract. 
> > 
> > 
> > Yes, I agree with this. FWIW the generics draft proposal has at least 
> one suggestion for avoiding "contract" as a context-sensitive token: 
> > 
> > We could make contract be a keyword only at the start of a top-level 
> declaration, and otherwise be a normal identifier. 
> > 
> > That's easy to implement in a tokenizer, at least, and it probably 
> doesn't matter too much if gofmt barfs on in-function Go code that uses 
> "contract" as an identifier. 
> > 
> > For keywords like "check" I think my preference is to state up front 
> which version of the language is being parsed. The default could come from 
> the local go.mod file. 
>
> There is a way to do error checking without 'check'. Keep the existing 
> syntax, but call error handler if declared and if error variable is 
> assigned a non-nil value: 
>
> handler err {...} 
>
> v, err:=someFunction() 
>
> This would call the handler for err if it is assigned non-nil value. 
>
> The idea is explained at the end of 
> https://gist.github.com/bserdar/4c728f85ca30de25a433e84ad5a065a1 
>
> 'handler' still needs to be handled though. 
>
>
> > 
> >> 
> >> Well, it's a clear and simple stance to take but it inevitably means 
> that adding any new keyword will not be backwards compatible and I'm not 
> sure the Go team will be happy with it because of that. 
> >> 
> >> Alan 
> >> 
> >> On Saturday, October 27, 2018 at 1:31:49 PM UTC+1, rog wrote: 
> >>> 
> >>> I'm not keen on this idea (including Ian's idea too). It makes parsing 
> context-sensitive because the set of syntactic tokens varies would depend 
> on the names declared in the package. That is, you can't parse a file in 
> isolation because without reading all the files in a package, you don't 
> know which of the keywords have been defined as local names. It would mean 
> that you couldn't just pipe an arbitrary Go file to gofmt, for example. 
> >>> 
> >>> The context-insensitive grammar is one of Go's great strengths. Let's 
> not lose that, please. 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> On Fri, 26 Oct 2018 at 11:22,  wrote: 
>  
>  Inspired to some extent by Ian's idea, I've had another idea which 
> could rid us of the new keyword problem not just for Go 1.xx or Go 2 but 
> for ever. We wouldn't even have to worry about whether a new keyword could 
> be restricted to contextual use or not. 
>  
>  Suppose any new keyword introduced from Go 1.xx onwards could only 
> begin with a lower case letter and could optionally be followed by the ! 
> symbol for disambiguation purposes. So, one could potentially have check!, 
> handle!, contract! and so on. 
>  
>  Suppose further that: 
>  
>  1. If you didn't use ! and there was some local entity in an 
> encompassing scope with the same name as the keyword, the compiler flagged 
> it as an error. 
>  
>  2. If you did use ! unnecessarily, the compiler would also flag that 
> as an error. 
>  
>  Now in the first case, you'd have the choice of either changing the 
> name of the local entity to a non-keyword or adding ! to the keyword 
> usage(s). In practice, most people would probably choose the former. 
>  
>  In the second case, you'd simply remove the ! and that would be the 
> end of the matter. 
>  
>  Technically, an encompassing scope would be any scope which was or 
> included the scope in which the new keyword were being used. It would 
> therefore always include package scope as a minimum. 
>  
>  The advantages of this approach would be: 
>  
>  1. ! would probably be seldom needed and so shouldn't impact too 
> adversely on the look of the code. Over time, people might simply learn to 
> avoid using the new keywords as normal identifiers at least at top level 
> within the package. 
>  
>  2. Existing code or new code using the old approach would continue to 
> compile without problem. 
>  
>  3. Any function or method which didn't use any new keywords as such 
> could still freely use them as identifiers for parameters, local variables 
> or local constants. Disambiguation (or the lack of it) with similarly named 
> top level entities (including new keywords) would be the same as it is 
> today - the latter would simply be hidden. 

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alan . fox6]

OK, that's a fair point.

So how about this then. The default (no tag) would be determined by the 
compiler depending on what major version was being used to build the 
application. If you were using Go 2.0, 2.1 etc, then the absence of the tag 
would mean that new keywords would be treated as such and couldn't 
therefore be used as ordinary identifiers.

However, you could still build code which didn't use the new features with 
version 2.x of the compiler by adding a "go 1" tag to the package clause.

By the time Go 3.0 came along, you'd have the choice of building 'old' code 
with the new compiler by including either the "go 1" or "go 2" tag. New 
code wouldn't need any tag but wouldn't be able to use new keywords as 
ordinary identifiers.

TBH I don't know of any other language that has used this approach. They've 
either said: hey, it's a new keyword - get used to it - or matters have 
been arranged so that new keywords are always contextual and can therefore 
be used as ordinary identifiers outside that context. The latter approach 
has had some success (take C# for example) but can distort the language 
somewhat if a non-optimal approach is used for new features just to fit in 
with this philosophy.

Alan 


On Sunday, October 28, 2018 at 3:44:09 AM UTC, Ian Lance Taylor wrote:
>
> On Sat, Oct 27, 2018 at 4:52 PM, alanfo > 
> wrote: 
> > 
> > As it's a package (rather than a file) level aspect, I propose adding an 
> > optional tag to the package clause. 
> > 
> > If there were no tag, then the compiler would  only recognize version 1 
> > keywords and newer ones would be treated as ordinary identifiers. 
> > 
> > If there were a tag such as: 
> > 
> >package whatever  "go 2" 
> > 
> > then all keywords introduced up to version 2 would be recognized as such 
> and 
> > their use as ordinary identifiers outlawed. 
> > 
> > Assuming new keywords would only appear in new major versions of the 
> > language, we could then carry on with tags of "go 3", "go 4" etc. 
>
> The problem I see with that approach is that people new to Go will 
> read about the current language, and will try to use features from the 
> current language, but those features will not work if they forgot to 
> add "go 2".  Adding a "go 2" tag makes sense today, but it doesn't 
> make sense tomorrow.  I'm not aware of any language that uses an 
> approach like that. 
>
> Ian 
>

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

[go-nuts] In go, which are punctuations?

[alan . fox6]

The ten tokens in the last two columns plus ... are definitely punctuation.

I'd have thought that := would be an assignment operator but it appears that, 
strictly according to the spec, it's punctuation as well.

Alan

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

[go-nuts] Type inference

[alan . fox6]

All four use type inference because the types of the constants or variables are 
not specified to the left of the assignment operator. They are instead inferred 
from the types of the expressions on the RHS.

Alan

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

[go-nuts] Re: Type inference

[alan . fox6]

Yes, I should perhaps have prefaced my previous post by saying it depends 
what you mean by 'type inference' :)

Rightly or wrongly, I think of it as either inferring the type of a 
variable or constant from its initialization expression or, in the case of 
a constant, inferring that it is an untyped constant of a certain kind - 
boolean, rune, integer, floating-point, complex or string.

There is, of course, no* explicit* way to specify that a constant is of an 
untyped kind in any case.

However, if you take the stricter view that type inference can only apply 
to typed constants, then I'd agree with you that (a) doesn't use type 
inference.

Alan

On Monday, February 4, 2019 at 6:17:05 PM UTC, 伊藤和也 wrote:
>
> I agree that (b), (c), (d) use type inference but not (a) because in (a), 
> both "num1" and "100" are untyped constants so they don't have types so 
> there is no need to use type inference.
>
> (a) const num1 = 100
> (b) var num2 = num1
>
> (c) const num1 = int(100)
> (d) num2 := num1
>
> However, if type inference is used to infer that "num1" is untyped from 
> untyped "100", I agree that (a) also uses type inference.
> (a) const num1 = 100
> 2019年2月4日月曜日 2時43分45秒 UTC+9 伊藤和也:
>>
>> In all the constant and variable declarations below, is type inference 
>> used? If not, which declarations use type inference?
>> (a) const num1 = 100
>> (b) var num2 = num1
>>
>> (c) const num1 = int(100)
>> (d) num2 := num1
>>
>

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

[go-nuts] Re: Contracts Draft: why are method pointers allowed

[alan . fox6]

One way of avoiding this muddle between pointer and value methods would be 
to require that any type parameter (T say) which is subject to a contract 
cannot be replaced by a pointer type.

The contract could then be absolutely explicit about whether a method's 
receiver were T or *T and any generic function using this contract wouldn't 
compile if the method were called inappropriately.

This,of course, wouldn't prevent you from using ordinary/return parameters 
of type *T or some aggregate type based on *T. Nor would it prevent type 
parameters which were not subject to a contract from being replaced by 
pointer types.

Alan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f953cf6b-dcb3-4d9f-9c4f-6b38990b74e5%40googlegroups.com.

[go-nuts] Re: Contracts Draft: unsatisfiable contracts

[alan . fox6]

I suspect they won't want to make this a compiler error because of other 
possible conflicts that may arise when one contract is embedded within 
another.

A vet warning should be feasible though.

Alan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ff76acb2-9e03-482f-9731-f730737ed0bd%40googlegroups.com.

Re: [go-nuts] Quick question about the new Contracts Draft Proposal

[alan . fox6]

Yes, it should.

Alan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/556bf9b8-1e12-4459-a7b3-77925eb7d9ee%40googlegroups.com.

Re: [go-nuts] Re: Contracts Draft: why are method pointers allowed

[alan . fox6]

My suggestion was that you can't use a pointer type as a type parameter if 
the latter is subject to a contract.

In the case you mention, the contract could be expressed as a disjunction 
of value and pointer methods:

contract stringer(T) {
   T String() string, *T String() string
}

However, if T were used as an ordinary/return parameter type, you would 
need two functions - one for T and one for *T - and so may be it is too 
restrictive.

On the other hand and more generally, not knowing whether the type 
parameter represented a pointer or a value might lead to some awkward 
coding. For example, you wouldn't be able to de-reference the type argument 
as it might not be a pointer.

It's clearly an area where some more thought is needed as Ian intimated 
earlier.

Alan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/302c6d33-a8ea-4e8a-b02b-7cff1b3de1c5%40googlegroups.com.

Re: [go-nuts] Re: Contracts Draft: why are method pointers allowed

[alan . fox6]

 
On Tuesday, July 30, 2019 at 7:47:05 PM UTC+1, Axel Wagner wrote:
>
> On Tue, Jul 30, 2019 at 8:31 PM > wrote:
>
>> My suggestion was that you can't use a pointer type as a type parameter 
>> if the latter is subject to a contract.
>>
>
> I'm not sure I understand you. Wouldn't that preclude using a generic map 
> with pointers as keys?
>

No, it wouldn't preclude that but the key would need to expressed as a *K 
rather than a K, if K were subject to a contract. As a pointer type it 
would automatically follow that *K was comparable.

>  
>
>> In the case you mention, the contract could be expressed as a disjunction 
>> of value and pointer methods:
>>
>> contract stringer(T) {
>>T String() string, *T String() string
>> }
>>
>
> Currently, Disjunctions only apply to a single type. You can't form 
> expressions like this.
> IMO that's a good restriction to maintain. Because the more powerful the 
> contract language becomes, the harder it'll be to make it useful.
>

Well, currently you can't use *T as a method receiver type in a contract so 
this would be a necessary exception to that rule if my suggestion were 
adopted.

However, I agree with your general point that the restriction should be 
maintained in all other circumstances.

>  
>
>> On the other hand and more generally, not knowing whether the type 
>> parameter represented a pointer or a value might lead to some awkward 
>> coding. For example, you wouldn't be able to de-reference the type argument 
>> as it might not be a pointer.
>>
>
> If a generic function wants to de-reference an argument, it should specify 
> that as a pointer: func f(type T) (p *T)
> This is the same as with slices, maps, channels, functions or any 
> composite type - you can't express "type parameter T should be a slice of 
> some kind", because you are instead expected to just specify []T if you 
> want a slice.
>

Yes, but if T happened to be a pointer to some type, then *T would be a 
double pointer to that type. As the design currently stands, you'd have no 
way of knowing whether T was a pointer or not unless the contract specified 
that it was one of the predefined types.

What I was trying to suggest here is that it would be helpful in some 
circumstances to know whether T was or was not a pointer type which would 
be a by-product of my suggestion.

Alan
 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cb9b37fc-19d4-4d25-bac8-72da1ade20a5%40googlegroups.com.

[go-nuts] Re: Contracts Draft: why are method pointers allowed

[alan . fox6]

For those who haven't already noticed, I thought I'd point out that the 
draft design has now been changed (as Ian intimated it might be) so that 
contracts may now require a pointer method in some cases i.e. if the type 
parameter is T one can now specify that *T has a certain method.

In particular, this will be needed if an implementing function is declaring 
a variable of type T but you then need to invoke a method on it where the 
receiver type is *T. To understand why this is so, one needs to re-read the 
design paper which has some examples of why the previous situation didn't 
work.

Looked at overall I think this is a better idea than what I was proposing 
earlier, though it might be difficult for folks to get their heads around 
the circumstances when and why a pointer method is needed. However, as it's 
probably a situation which will arise infrequently in practice, it should 
not be a major concern.

Alan

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/64567134-2fec-423c-8828-fed14f392fc7%40googlegroups.com.

[go-nuts] Re: regexp syntax and named Unicode character classes

[alan . fox6]

As Go's regular expressions are based on RE2, I always use the latter's 
documentation 
page  to check what is and isn't 
allowed.

Note though that: \C, which RE2 normally allows, isn't allowed in Go.

Alan

On Tuesday, January 7, 2020 at 6:21:58 PM UTC, Tom Payne wrote:
>
> Hi,
>
> tl;dr How should I use named Unicode character classes in regexps?
>
> I'm trying to write a regular expression that matches Go identifiers 
> , which start with a Unicode 
> letter or underscore followed by zero or more Unicode letters, decimal 
> digits, and/or underscores.
>
> Based on the regexp syntax , and the 
> variables 
> in the unicode package  which 
> mention the classes "Letter" and "Number, decimal digit", I was expecting 
> to write something like:
>
>   identiferRegexp := 
> regexp.MustCompile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`)
>
> However, this pattern does not compile, giving the error:
>
>   regexp: Compile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`): error parsing regexp: invalid character class range: 
> `\p{Letter}`
>
> Using the short name for character classes (L for Letter, Nd for Number, 
> decimal digit) does work however:
>
>   identiferRegexp := regexp.MustCompile(`\A[\pL_][\pL\p{Nd}_]*\z`)
>
> You can play with these regexps on play.golang.org 
> .
>
> Is this simply an oversight that Unicode character classes like "Letter" 
> and "Number, decimal digit" are not available for use in regexps, or should 
> I be using them differently?
>
> Many thanks,
> Tom
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e6307afc-889c-46de-87b0-6f9a06620421%40googlegroups.com.