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

Thanks folks... s/operator/method/ On Saturday, 8 September 2018 18:58:24 UTC-7, 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

[go-nuts] A "not-so-alien" syntax for error check.

With the current proposal we will need to introduce two new definitions: the handler block and check keyword. One thing, I still not sure how "check" will handle the repetition of other failure check

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

On Sunday, 9 September 2018 05:58:46 UTC+2, Robert Engels wrote: > > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as > methods, e.g. operator + is > > The point is that without "intrinsic generics"

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

For the math operator, since Go already doesn’t do automatic numeric conversions, all of the operators are almost trivially implemented as methods, e.g. operator + is pseudo generic interface - not really required type PlusOperator interface { Plus(A) A } and given type MyStruct

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

On Sunday, 9 September 2018 04:53:00 UTC+2, Jonathan Amsterdam wrote: > > When is it important to not just express what operations are >> required for a type, but also to try to rule out some types? >> > > I think the short answer is: numeric code. That's when one thinks about > which types

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

I believe what you're discussing in this case is function or method overloading. Operator overloading refers to the ability to specify custom behavior for operators like +, -, etc. On Sat, Sep 8, 2018 at 6:58 PM Rick wrote: > With recent discussion concerning the possible introduction of

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

I don't think Go will add operator overloading, even if it simplifies generics. Go has a core principle that doesn't get written down very much: syntax is hard-coded. If you see a piece of syntax in Go, it will never execute user code. (The obvious exception, of course, is a function call.)

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

> > When is it important to not just express what operations are > required for a type, but also to try to rule out some types? > I think the short answer is: numeric code. That's when one thinks about which types make sense for an algorithm, not just which operations. I'm not exactly sure

[go-nuts] Operator Overloading Implies Generics?

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

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

"A contract is a compile-time description of which types are permitted for a polymorphic function or type." No, it's not. It's a collection of statement-like operations that must be legally compilable, under restricted circumstances, by the type at the point of instantiation, plus some special

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

Ps: as for point 4, we'd maybe need b and c to be integers, and also a SetIndex method. We'd also need a Key, SetKey and DeleteKey to mimic map operators. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

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

I'd really like to read a reply to Lucio's argument about operator overloading. Once we define that: 1. ab is !a.Less(b) && !a.Equals(b)); 4. a.Index(b) is the same as a[b] and a.Index2(b, c) is the same as a[b:c]; 5. maybe some more? Would we really need contracts and the added complexity in

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

"Any unsigned number" would allow generic versions of the math/bits functions, though they'd have to dispatch on unsafe.Sizeof internally, as a type switch would miss type Uint uint But that would presumably be DCE'd if specialized. Allowing more types than intended isn't always bad. If I have

Re: [go-nuts] contracts referring to other contracts defined in the same package

> > Probably we should just drop the restriction until we see from experience > whether it seems to be necessary. I think that's probably a good idea. The draft proposal also says things like "When a contract needs to describe one of these cases, it can use a type conversion to an interface

Re: [go-nuts] contracts referring to other contracts defined in the same package

On Sat, Sep 8, 2018 at 1:16 PM, Larry Clapp wrote: > > The draft proposal says > > "The body of a contract may not refer to any name defined in the current > package" > > but then later has this example > > package move > > contract counter(x T) { > var _ int = x.Count > } > > contract

[go-nuts] contracts referring to other contracts defined in the same package

The draft proposal says "The body of a contract may not refer to any name defined in the current package" but then later has this example package move contract counter(x T) { var _ int = x.Count } contract counters(T1, T2) { // as with a func, parameter names may be omitted. // Use

[go-nuts] Re: Opening brace can't be placed on a separate line killing the language for me

On Saturday, 8 September 2018 10:09:31 UTC+2, Mohamed yousry wrote: > > [ ... ] For me the language is Dead now it was a wasted time I understand how you feel, but are we the ones who need to hear this? Surely you realise we are precisely the wrong choir to preach to? No offence intended,

Re: [go-nuts] Go 2 Draft Design Question : Error Handling

On Sat, Sep 8, 2018, at 12:41, Henry wrote: > I have read the Go 2 Draft Design about Error Handling. You can read about > it here Go 2 Draft Designs > . The > draft suggested something like this: > > func CopyFile(src, dst

[go-nuts] Go 2 Draft Design Question : Error Handling

I have read the Go 2 Draft Design about Error Handling. You can read about it here Go 2 Draft Designs . The draft suggested something like this: func CopyFile(src, dst string) throws error { r := os.Open(src)

Re: [go-nuts] Re: Opening brace can't be placed on a separate line killing the language for me

odsh97, More than a million Go programmers agree with you that format and readability is everything. We have a standard tool, go fmt, to ensure it. All Go code conforms. You'll like the uniformity. Michael On Sat, Sep 8, 2018 at 7:50 AM alanfo wrote: > I've never been able to understand why

Re: [go-nuts] Re: Opening brace can't be placed on a separate line killing the language for me

I've never been able to understand why 'go fmt' allows you to add the function body (apparently of any length) on the same line as its declaration but doesn't allow a one line 'if' or 'for' statement even if the body consists of a single short statement. So, if you write this: if

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

OK, fair enough, but the only way you could have a standard package on those lines without the compiler doing more inference would be to list expressions for every single operator or conversion that the relevant types support. That should be doable but I'm not sure whether a particular

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

On Sat, Sep 8, 2018 at 6:29 AM, alanfo wrote: > > As it's clear now that Ian wants to stick with 'full-blooded' contracts if > it can be made to work, I've been trying to think of ways to make them > easier to work with and to solve some of the issues they currently have. > > Reading through the

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

As it's clear now that Ian wants to stick with 'full-blooded' contracts if it can be made to work, I've been trying to think of ways to make them easier to work with and to solve some of the issues they currently have. Reading through the draft for the umpteenth time, one point that

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

On Sat, Sep 8, 2018 at 5:54 AM, Wojciech S. Czarnecki wrote: > On Sat, 8 Sep 2018 03:59:45 -0700 > Ian Lance Taylor wrote: > >> Why is it useful to say "this polymorphic function may >> only be instantiated with unsigned integer types?" > > E.g. because an algorithm needs this constraint. OK,

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

On Fri, Sep 7, 2018 at 9:19 PM, Lucio wrote: > > PS: Maybe I should add a thought to clarify what I'm imagining. Am I > mistaken in my belief that user-defined methods and functions are much less > likely to appear within contracts than operators on intrinsic types? And > that the "generic"

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

On Fri, Sep 7, 2018 at 5:29 PM, Rob Pike wrote: > > Would this work? > > contract unsigned(u T) { > 1 << u > } > > It's another infelicitous horror, but I believe it exploits the only place > in the language where an unsigned integer is required. Yes, that would also work (pace issue #19113).

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

On Fri, Sep 7, 2018 at 5:28 PM, Rob Pike wrote: > > contract unsigned(v T) { > // Require T to be an integer type. > v % 1 > // This is satisfied by any unsigned integer type, but not by a > signed integer type. > v = 1<<(unsafe.Sizeof(v) * 8 - 1) > } > > That requires an import,

Re: [go-nuts] Re: Opening brace can't be placed on a separate line killing the language for me

On Sat, Sep 8, 2018 at 12:01 PM Mark Volkmann wrote: > How did you do that? I don’t see any formatting configuration. Correct, there's none. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Re: Opening brace can't be placed on a separate line killing the language for me

How did you do that? I don’t see any formatting configuration. --- R. Mark Volkmann Object Computing, Inc. > On Sep 8, 2018, at 3:48 AM, Jan Mercl <0xj...@gmail.com> wrote: > > On Sat, Sep 8, 2018 at 10:14 AM Dave Cheney wrote: > > > I personally don't like that I cannot write one liner

Re: [go-nuts] Opening brace can't be placed on a separate line killing the language for me

On Sat, Sep 8, 2018 at 10:09 AM wrote: > For me the language is Dead now it was a wasted time Don't blame the language. It's used by many programmers in many companies. Even big ones. Like Google, for example. Programming is one of the professions where continuous learning of new things and

Re: [go-nuts] Re: Opening brace can't be placed on a separate line killing the language for me

On Sat, Sep 8, 2018 at 10:14 AM Dave Cheney wrote: > I personally don't like that I cannot write one liner functions on one line because of gofmt's preference for reformatting the same function over three lines ... Please navigate to https://play.golang.org/p/VPfFLIyhUqp and click format. --

[go-nuts] Re: Opening brace can't be placed on a separate line killing the language for me

I'm sorry you feel this way. The reality is that the format of the language is not something that is going to change. I personally don't like that I cannot write one liner functions on one line because of gofmt's preference for reformatting the same function over three lines -- but, I put this

[go-nuts] Opening brace can't be placed on a separate line killing the language for me

I don't know about you guys but for me format and readability is everything so when I first heard about the language that Care about that ,I was interested in it , after spending 2 days learning the language I decided that I have to put my new skill under the test to only find out I can't

Re: [go-nuts] how to convert big.Float to big.Int

s := "12938219483923483000" bigFloatS,_ := common.StringToBigfloat(bigFloatS) bigIntS, accuracy := bigFloatS.Int(nil) fmt.Printf("bigIntS:%v, accuracy:%v",bigIntF,accuracy) // bigIntF:12938219483923483000, accuracy:Exact On Saturday, September 8, 2018 at 2:16:53 PM UTC+8, Shiming Liu wrote:

Re: [go-nuts] how to convert big.Float to big.Int

thank you, I have work it out: s := "12938219483923483000" bigFloatS,_ := common.StringToBigfloat(bigFloatS) bigIntS, accuracy := f.Int(nil) fmt.Printf("bigIntS:%v, accuracy:%v",bigIntF,accuracy) // bigIntF:12938219483923483000, accuracy:Exact On Friday, September 7, 2018 at 7:00:20 PM