[go-nuts] Curious about fixed heap mappings

[Shawn Webb]

Hey All,

I've read through a previous discussion in 2012 about golang's use of
deterministic memory allocations here:
https://groups.google.com/forum/#!msg/golang-nuts/Jd9tlNc6jUE/qp2oyfEEfjQJ

Back then, -buildmode=pie didn't exist back then, so I figured a
revisit of the topic might be warranted.

Go 1.11 introduced -buildmode=pie for FreeBSD, which HardenedBSD is
able to take advantage of, given HBSD's PaX ASLR implementation.
HardenedBSD is a hardened derivative of FreeBSD.

When applying -buildmode=pie with gitea, I wanted to verify that
golang was able to take full advantage of HardenedBSD's robust ASLR
implementation. I noticed a fixed mapping at 0xc0. I restarted
the process, looked at the memory mappings again (`procstat -v $PID`)
and saw 0xc0 again. Grepping through the golang 1.11 codebase
revealed that Go allocates its heap at a fixed address, starting at
0xc0.

With the heap being allocated at a fixed mapping, golang applications
are still not able to really utilize ASLR. Thus, -buildmode=pie is
ineffectual.

Given that the reason to implement PIE support is to take advantage of
ASLR, I'm curious if perhaps updating the heap management code for
ASLR support was overlooked. Or perhaps it wasn't, and this is
deliberate. Or perhaps a totally different reason. Either way, could
someone shed some light on this?

Thanks,

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE

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


signature.asc
Description: PGP signature

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

[Lucio]

Method overloading opens the kind of can of worms Go has been very good at 
avoiding. Once the compiler needs to recognise the applicable instance of a 
method or function by its signature or even worse by parts of its 
signature, a lot of guarantees fly out of the window. I don't think I would 
like that.

Lucio.

On Sunday, 9 September 2018 07:58:14 UTC+2, Rick wrote:
>
> 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 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: Operator Overloading Implies Generics?

[Rick]

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 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] A "not-so-alien" syntax for error check.

[nvcnvn]

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 form, for example the one that using boolean like checking if 
an key exist in map or type assertion successful.

How about a new keyword but using normal function as condition for return? 
Example:

func errorWrap(src, dst string, err error) (wrappedErr error, shouldReturn 
bool) {
if err != nil {
return fmt.Errorf("copy %s %s: %v", src, dst, err), true
}

return nil, false
}

func CopyFile(src, dst string) error {
r, err := os.Open(src)
checkReturn errorWrap(src, dst, err)
defer r.Close()

w, err := os.Create(dst)
checkReturn errorWrap(src, dst, err)

handingError := func(err error) (error, bool) {
if err == nil {
return nil, false
}

w.Close()
os.Remove(dst)
return errorWrap(src, dst, err)
} 
_, err = io.Copy(w, r)
checkReturn handingError(err)
checkReturn handingError(w.Close())
}


"checkReturn" function returns values must match the caller return values 
with an additional boolean check for caller.
The return values that match the caller then will be use as return values 
for the caller.
In the example, CopyFile return 1 error, so the "checkReturn" function must 
return (error, bool).
"checkReturn" will act like "return" if the final boolean value is true.

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

[Lucio]

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" supplied by the compile *by 
construction*, operators would be terribly onerous to define and the 
language much less familiar. My point, leaning on Ignazio's lucid 
presentation, is to strip out the syntactic sugar provided by the compiler, 
then list each of the distinguishable operators (numeric conversions come 
into that, too, which almost certainly have a role to play in the final 
shape this exercise will take) and try to fathom how the compiler gets to 
summarise these, then attempt to formalise the process so a programmer can 
express it without losing Go's many assets (succinctness, readability, type 
safety, etc.).

My own question: it is already there by convention (call it "common law"), 
how do we turn it into "written statute"? It looks a lot like operator 
overloading, but any APL user will know that isn't what it is, it is just 
"analogy" by convention. The neatest example in APL is the division 
operator, it does not become matrix division, when applied to matrices, for 
good reason.

Angle brackets, incidentally, jar: I really, really dislike them used in 
this context - my extremely strong prejudice in this respect may well taint 
everything I say here :-).
 

> As I pointed out in the sample code in another thread, Java is type-safe 
> but still allows you to encounter a runtime type exception - so not fully 
> type safe, and it hasn’t stopped its adoption or success.
>
> Java isn't anything to be copied here, as I perhaps unkindly mentioned 
elsewhere: this is the wrong choir.
 

> I’ll say it again, focus on the 90% most useful/helpful constructs, maybe 
> with some limitations, and be done with it.
>
> I think the current proposal attempts that, as elegantly as current 
consensus permits and in general I've found that the Go developers have a 
keen sense of elegance I have occasionally had to admit is both more astute 
and more pragmatic than anything I could muster up. But generics and Go as 
we know it are in conflict except where intrinsic generics are concerned 
and my perception is that we need to look there for the answer if only 
because we've swallowed that bitter pill, so an additional dose isn't 
really going to make anything worse. The pressure to add generics to Go 2 
to address some perceived "need" is both good and bad, I'm hoping the Go 
developers will pull a rabbit out of that hat.
 

> You can already shoot yourself in the foot with unsafe or CGO, why does 
> the generics support need to be any different...
>
> I do neither, perhaps out of necessity or lack of imagination, and I guess 
I could manage as I have until now without generics, too. But I think Go 2 
deserves the fine analysis that stops it from being a second-generation 
committee product (SSH-2 comes to mind, I'm hoping one of those is enough 
deterrent).

Lucio.

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

[robert engels]

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 struct {
}
func (MyStruct) Plus(other MyStruct) MyStruct {
   …
}

The the + sign is just syntactic sugar. The compiler could easily determine and 
call these methods as needed. It would be limited, but still very useful for 
numeric programming. But then you probably want other math operators, like sum, 
etc. and then it starts getting really complex if you want to define them all.

The map/indexing operators don’t matter, because they can only work on the 
built in slice and maps.

I admit that this is not my area of expertise, but I’ve used Go enough now to 
like it, barring some limitations. At this point I am not sure it needs a full 
blown generics system, maybe a simple built-in temple code generator like I 
proposed, or just some additional “built-in” interfaces you can implement with 
special support from the compiler to make most of generics possible without all 
of the fuss.

As I pointed out in the sample code in another thread, Java is type-safe but 
still allows you to encounter a runtime type exception - so not fully type 
safe, and it hasn’t stopped its adoption or success.

I’ll say it again, focus on the 90% most useful/helpful constructs, maybe with 
some limitations, and be done with it.

You can already shoot yourself in the foot with unsafe or CGO, why does the 
generics support need to be any different...


> On Sep 8, 2018, at 10:36 PM, Lucio  wrote:
> 
> 
> 
> 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 make sense for an algorithm, not just which operations.
> 
> I'm not exactly sure why. It could be because Go doesn't support operator 
> overloading. In C++ with concepts, maybe the concept for writing some generic 
> math function wants operator+ and operator/, and no one cares that that may 
> result in nonsense for some implementations of those operators.
> 
>  In Go 1, we write numeric code with specific types: float64 and not int64, 
> for instance. Go  insists on conversions between numeric types to keep us out 
> of trouble: you can't call func Average(a, b float64) on ints without 
> explicitly converting them. It seems natural to want to keep that precision 
> and safety, but generalize it.
> 
> I really feel out of place making suggestions here, my foundations are old 
> and crumbly for this type of intellectual exercise and I don't want to make 
> assertions that would be laughable when looked at  under a microscope I 
> simply don't own.
> 
> That said, I want to  thank Ignazio for outlining my thoughts so clearly, at 
> least I know I did not fail to get the point across as I feared I may have.
> 
> At the same time, purely on a philosophical (for want of a better adjective) 
> level, it is important to keep in mind that a pragmatic solution to the 
> problem of generics is far more useful than a purely theoretical one and that 
> the Go  developers have tasked themselves to address a *real* problem and 
> arrive at a *real* solution, without knowing that such a solution exists in 
> the space defined by the many constraints involved.
> 
> On the pragmatic side, we know that the Go compiler has little difficulty 
> applying the Go discipline regarding numeric (more generic than other) types, 
> it therefore is possible to instruct the compiler to apply analogous 
> capabilities to arbitrary types, if we give the code writer (me and you) 
> access to the decisions making applied within the compiler. That may be very 
> hard to express, but there is definite, readily accessed, prior art.
> 
> On the other extreme, as I have expressed in private correspondence with Ian, 
> one could at least theoretically remove all aspects of expression evaluation 
> out of Go (that is what, in my ignorance, I just realised functional 
> languages do) and leave merely the language constructs in place (assignment, 
> decision making, loops, function invocations, goroutines, channel operations) 
> and allow modular interpreters to play arbitrarily fast and loose in the 
> expression space, as long as they interface correctly with the compiler's 
> expectations.Therein remains the type-checking strength of Go and I don't 
> expect anyone to argue that it is valuable.
> 
> But the essence then becomes the ability to define the interface to such an 
> interpreter (imagine the target being APL, a long-lost relative returning) at 
> a higher (?) level than types, the way functions presently do, because, as 
> numeric constants already do, we know we can leave the 

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

[Lucio]

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 make sense for an algorithm, not just which operations.
>
> I'm not exactly sure why. It could be because Go doesn't support operator 
> overloading. In C++ with concepts, maybe the concept for writing some 
> generic math function wants operator+ and operator/, and no one cares that 
> that may result in nonsense for some implementations of those operators.
>
>  In Go 1, we write numeric code with specific types: float64 and not 
> int64, for instance. Go  insists on conversions between numeric types to 
> keep us out of trouble: you can't call func Average(a, b float64) on ints 
> without explicitly converting them. It seems natural to want to keep that 
> precision and safety, but generalize it.
>
> I really feel out of place making suggestions here, my foundations are old 
and crumbly for this type of intellectual exercise and I don't want to make 
assertions that would be laughable when looked at  under a microscope I 
simply don't own.

That said, I want to  thank Ignazio for outlining my thoughts so clearly, 
at least I know I did not fail to get the point across as I feared I may 
have.

At the same time, purely on a philosophical (for want of a better 
adjective) level, it is important to keep in mind that a pragmatic solution 
to the problem of generics is far more useful than a purely theoretical one 
and that the Go  developers have tasked themselves to address a *real* 
problem and arrive at a *real* solution, without knowing that such a 
solution exists in the space defined by the many constraints involved.

On the pragmatic side, we know that the Go compiler has little difficulty 
applying the Go discipline regarding numeric (more generic than other) 
types, it therefore is possible to instruct the compiler to apply analogous 
capabilities to arbitrary types, if we give the code writer (me and you) 
access to the decisions making applied within the compiler. That may be 
very hard to express, but there is definite, readily accessed, prior art.

On the other extreme, as I have expressed in private correspondence with 
Ian, one could at least theoretically remove all aspects of expression 
evaluation out of Go (that is what, in my ignorance, I just realised 
functional languages do) and leave merely the language constructs in place 
(assignment, decision making, loops, function invocations, goroutines, 
channel operations) and allow modular interpreters to play arbitrarily fast 
and loose in the expression space, as long as they interface correctly with 
the compiler's expectations.Therein remains the type-checking strength of 
Go and I don't expect anyone to argue that it is valuable.

But the essence then becomes the ability to define the interface to such an 
interpreter (imagine the target being APL, a long-lost relative returning) 
at a higher (?) level than types, the way functions presently do, because, 
as numeric constants already do, we know we can leave the business of 
dealing with that to the interpreter.

So, like it or not, we then need to be able to describe types, not 
operators, in terms of groups of the subtypes we enjoy now; the operators, 
as Ignazio so clearly describes, are just syntactic sugar we use out of 
tradition, not part of the essence.

Of course, I do take Ian's point that generics should not force us to adopt 
a language readily distinguishable from Go, as what is described above is 
not the Go we know and love, but perhaps there is a middle ground that will 
prepare us for the next step (ten years, they blew over very quickly, 
didn't they?) for the next generation.

My own habits encourage me to open rather than close doors, but I 
understand Ian's position well, we "need" an answer to the perennial 
questions raised in this forum and others; but if the present solutions 
shuts the doors to a Go 3 that could be a much better answer to the needs 
of developers who, like me, have not been able to get a full education in 
the subtleties of compiler designing and writing, then I would be 
disappointed to see that Go 2.

Still, the nag remains: what formal mechanism can we define that describes 
how the Go 1 compiler already deals with numerics (keep  in mind the 
breadth of scope of numeric constants already embraced by it) and how do we 
offer that to the average Go developer in a form that is not just a 
complexity trap?

Lucio.


-- 
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] Operator Overloading Implies Generics?

[Tyler Compton]

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

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

[Jonathan Amsterdam]

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.) 
This principle makes Go extremely readable, and relatively easy to debug.

Even if Go had operator overloading, there's more to do. You talk about 
"slightly extended interfaces," but what are those? Your example

  type comparer(type T) interface {
  Less(other T)
  }

interpreted according to the current design, only describes some type U 
that has a method with signature Less(T). It doesn't say U and T are 
identical. You need to be more clear about what changes to interfaces are 
necessary.

Lastly, there's the problem of contracts with multiple type parameters, 
like the Graph example in the design draft. Operator overloading doesn't 
help with that.
 
On Saturday, September 8, 2018 at 6:47:30 PM UTC-4, Ignazio Di Napoli wrote:
>
> I'd really like to read a reply to Lucio's argument about operator 
> overloading.
>  
> Once we define that:
> 1. a type);
> 2. a==b is the same as a.Equals(b);
> 3. the other comparaison operators are defined using these two (e.g.: a>b 
> 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 this case? 
> Shouldn't slightly extended interfaces suffice?
>
> E.g.:
>
> type comparer(type T) interface {
> Less(other T)
> }
>
> func min(type T comparer)(a, b T) {
> if a < b {
> return a;
> }
> return b;
> }
>
>

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

[Jonathan Amsterdam]

>
>  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 why. It could be because Go doesn't support operator 
overloading. In C++ with concepts, maybe the concept for writing some 
generic math function wants operator+ and operator/, and no one cares that 
that may result in nonsense for some implementations of those operators.

 In Go 1, we write numeric code with specific types: float64 and not int64, 
for instance. Go  insists on conversions between numeric types to keep us 
out of trouble: you can't call func Average(a, b float64) on ints without 
explicitly converting them. It seems natural to want to keep that precision 
and safety, but generalize it.

In Go 1, if we wanted to write a numeric algorithm that worked on, say, two 
slices of floating-point numbers, we'd give it the signature func(x, y 
[]float64). If later we wanted to support float32, we'd have to copy the 
code, or make the caller do an expensive conversion. The same problem would 
happen if the caller defined their own floating-point type (e.g. type 
MyFloat float64).

I think I should be able to say, simply and clearly, that the slice element 
can be any type whose underlying type is float32 or float64. Furthermore, I 
don't want to specify the exact operations my implementation currently 
uses. I may want to change the code to use "-" instead of "+" later, for 
reasons of clarity or numerical stability. I shouldn't have to update the 
contract for that.

contract(t T) { t = 0.0 } might seem to restrict to the types I want, but 
it doesn't; you can assign 0.0 to an integer type. 

contract(t T) { t = 0.5 } is wrong too. It includes complex types.

contract(t T) { float64(t) } also works for ints, so no good.

I believe the answer is 

   contract(t T) { t = 0.5; float64(t) }

but I'm not positive about that. Certainly, very few people who read that 
will immediately understand that T is a type whose underlying type is a 
float.

(And I haven't done the second part, where I add all the valid operators 
for floats.)

Earlier you wrote

> [T]o me it always seems quite clear which type arguments a contract 
allows 
and excludes.  It's exactly the set of types that type check 
successfully.  It's true that sometimes this can be a surprising type, 
but to me that seems just like the fact that it can be surprising 
which types implement an interface. 

I think this example, and the other ones given in this thread, demonstrate 
that this is not "just like" the surprise of which types implement an 
interface. It's more like solving a puzzle, as someone (Axel?) has said.

-- 
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] Operator Overloading Implies Generics?

[Rick]

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.

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

[Rob Pike]

"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 rules for cases that are hard to
handle that way. It's more of an illustration, an example, than a
description. It's implicit, roundabout, a little magical.

I'm not criticizing the design, although it might sound like that, but
there is a certain lack of precision, of indirection, that makes this
harder than I hope it might be. And the first place to be precise is in the
language that defines what these new concepts are.

-rob

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

[Ignazio Di Napoli]

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

[Ignazio Di Napoli]

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 this case? 
Shouldn't slightly extended interfaces suffice?

E.g.:

type comparer(type T) interface {
Less(other T)
}

func min(type T comparer)(a, b T) {
if a < b {
return a;
}
return b;
}

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

[jimmy frasche]

"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 code
that takes a string but I also want it to work on types like
  type String string
the contact for that has to be
  contract stringy(s T) {
string(s)
len(s)
  }
to avoid allowing rune and byte. This is necessary because my code
also has to satisfy the contract. This also accepts []rune and []byte
and that's fine in this case since the code will be using immutable
values. Here it's kind of a nice bonus.

It does seem like writing contracts from scratch will be difficult. If
I want something that works on slice-y things I might attempt:
  contract slicey(s T) {
s[0]
  }
  func rest(type S slicey)(sliceable S) S {
return sliceable[1:]
  }
But that will fail to compile because that contract isn't equivalent
to sliceable things: it's equivalent to
  for _, _ = range s {}
which is things that can be iterated over that are not channels.

The contract should have been
  s[:0]
which is limited to arrays, slices, and strings.

But then the contract accepts [0]T but the code requires at least [1]T
so either the final contract is
  s[1:]
or the minimum array size has to be inferred contradicting the premise
of the contract to specify all the constraints on both the acceptable
types and the implementation. The contract could be changed to
  make(T, 0)[:0]
which disallow arrays but that also disallows strings.

At that point, it would be simpler to just do
  func rest(type T)(slice []T) T {
return slice[1:]
  }

While I don't see a way to express that contract, I can see how to
enforce that a struct type has fields A, B, and C in alphabetical
order:
  contract superUseful(t T) {
[unsafe.Offsetof(t.C) - unsafe.Offsetof(t.B)]struct{}
[unsafe.Offsetof(t.B) - unsafe.Offsetof(t.A)]struct{}
  }
(Assuming the size of each fields is greater than 0; based on
https://twitter.com/lukechampine/status/1013635527801786369 )

No one would write that, except in a "guess what this does!" format, of course.

If there's a contracts package, it would be easier to use contracts.
But my guess then is that a lot of the nonempty contracts in the wild
would match one of these patterns:
  contract simple(t T) {
someInterface(t)
  }

  contract simple2(t T) {
contracts.Comparable(t)
someInterface(t)
  }

  contract complex(t T) {
contracts.PropertyA(t)
contracts.PropertyB(t)
contracts.PropertyC(t)
contracts.PropertyD(t)
contracts.PropertyE(t)
contracts.PropertyF(t)
  }

I get that it avoids introducing those properties directly into the
language but it also locks the language into those properties. You can
never change https://github.com/golang/go/issues/19113 after
introducing contracts because there could be a contract somewhere that
uses 1 << u instead of contracts.Unsigned.

> >   struct{ io.Reader; T}{}.Read
>
> Just to make it worse, T would be permitted if T is a struct with an
> embedded field that has a Read method.

That extra level of nesting would still result in the selector Read
being ambiguous causing the contract to reject T.

> It's not clear to me why anybody would write a contract like this.

If you allow embedding a type parameter in a generic struct, you need
that contract to assert that the embedded type parameter does not
conflict with an embedded regular type's selectors or you can't use
them in the methods of the type since they're not always present. You
only need that for selectors you use but any you don't assert like
that can disappear depending on the parameterization so you can have
weird cases where a generic type satisfies an interface unless
instantiated with a type that also satisfies that interface.
On Sat, Sep 8, 2018 at 7:06 AM alanfo  wrote:
>
> 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 built-in type (or 
> group of such types) would be completely defined in this way or whether it 
> would matter if it wasn't.
>
> Anyway, it's an idea to work on.
>
> 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.

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

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

[Larry Clapp]

>
> 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 type."  It'd be nice if you could define 
said interface type in the same file, and not inline with the contract.

— L

On Saturday, September 8, 2018 at 4:42:34 PM UTC-4, Ian Lance Taylor wrote:
>
> 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 counters(T1, T2) { // as with a func, parameter names may be 
> > omitted. 
> >  // Use contract embedding to say that both types must have a 
> >  // Count field of type int. 
> >  counter(T1) 
> >  counter(T2) 
> > } 
> > 
> > counters refers to counter. 
> > 
> > So no names except other contracts? 
>
> Yes, I suppose so. 
>
> Probably we should just drop the restriction until we see from 
> experience whether it seems to be necessary.  My concern was that 
> referring to a name defined the same package would make those names 
> part of the contract, perhaps surprisingly.  That is, it would mean 
> that changes the definition of those names would change the contract. 
> But likely it's not worth worrying about. 
>
> Ian 
>
> 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] contracts referring to other contracts defined in the same package

[Ian Lance Taylor]

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 counters(T1, T2) { // as with a func, parameter names may be
> omitted.
>  // Use contract embedding to say that both types must have a
>  // Count field of type int.
>  counter(T1)
>  counter(T2)
> }
>
> counters refers to counter.
>
> So no names except other contracts?

Yes, I suppose so.

Probably we should just drop the restriction until we see from
experience whether it seems to be necessary.  My concern was that
referring to a name defined the same package would make those names
part of the contract, perhaps surprisingly.  That is, it would mean
that changes the definition of those names would change the contract.
But likely it's not worth worrying about.

Ian

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] contracts referring to other contracts defined in the same package

[Larry Clapp]

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 contract embedding to say that both types must have a
 // Count field of type int.
 counter(T1)
 counter(T2)
}

counters refers to counter.

So no names except other contracts?

— Larry

-- 
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: Opening brace can't be placed on a separate line killing the language for me

[Lucio]

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, but this happens frequently and I always ask myself 
why.

Lucio. 

-- 
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 2 Draft Design Question : Error Handling

[Sam Whited]

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 string) throws error {
> r := os.Open(src)
> defer r.Close()
> 
> w := os.Create(dst)
> io.Copy(w, r)
> w.Close()
> }

You may need to go back and read that page again; this example is from the 
problem statement of the overview document. The actual draft design does not 
include any such syntax.

The document you want to read can be found here: 
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

—Sam

-- 
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] Go 2 Draft Design Question : Error Handling

[Henry]

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)
defer r.Close()

w := os.Create(dst)
io.Copy(w, r)
w.Close()
}


I don't have any opinion on the subject yet. I am still exploring the idea. 
I have several questions about it though.

1. How do you treat multiple return values? Let's say I have a function 
that queries data from the database and returns the data (if it succeeds) 
and an error (if it fails).
2. I usually use my own error library because I find the standard error 
inadequate for my need. Unfortunately, this means I need to wrap any error 
generated from outside my own code. With the new syntax, how can I wrap 
errors with my own custom error implementation?
3. The proposal assumes that automatic error bubbling is all you need to 
deal with errors. The problem is that automatic error bubbling alone is not 
sufficient. You may have the need to do some additional processing before 
passing the error to the caller. Often, you may want to handle some of the 
errors yourself, and pass the rest that you can't handle to the caller. In 
other languages, they have the try-catch-finally. The catch block deals 
with alternate processing when an error occurs, while the finally block 
deals with the common processing for all the possible paths of execution. 
How does the new syntax cater with this need?

Thanks.

Henry

-- 
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: Opening brace can't be placed on a separate line killing the language for me

[Michael Jones]

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 '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 someCondition { break }
>
> it always rewrites it as:
>
> if someCondition {
> break
> }
>
> This means that you tend to need more lines to write your code in Go than
> you would in other C-family languages.
>
> However, it's only a minor irritation and, as Dave said, a price worth
> paying for having a consistent coding style.
>
> Don't get me started though on 8 space tabs :(
>
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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: Opening brace can't be placed on a separate line killing the language for me

[alanfo]

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 someCondition { break }

it always rewrites it as:

if someCondition {
break
}

This means that you tend to need more lines to write your code in Go than 
you would in other C-family languages.

However, it's only a minor irritation and, as Dave said, a price worth 
paying for having a consistent coding style.

Don't get me started though on 8 space tabs :(

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 as builtin typeclasses

[alanfo]

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 
built-in type (or group of such types) would be completely defined in this 
way or whether it would matter if it wasn't.

Anyway, it's an idea to work on.

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 as builtin typeclasses

[Ian Lance Taylor]

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 draft for the umpteenth time, one point that
> particularly struck me was that expressions such as:
>
> 1. ' t == t  ' implies that both == and != are valid operations i.e. type is
> comparable.
>
> 2  ' t * t  ' implies both * and *= are valid.
>
> 3. ' t < t  ' implies that <, >, <=, >= , == and != are all valid i.e. type
> is ordered.
>
> Suppose this idea were taken to its logical conclusion.

I want to say that In my opinion we should not take this to its
logical conclusion.  Quite the contrary, I think we should have the
absolute minimum of these kinds of inferences.  I'm completely open to
removing the ones you list above.


> Now let's further suppose that the standard library contained a contracts
> package (with a nice short name such as 'ct') containing contracts for each
> of these expressions. Let's give them some shortish names such as (in the
> same order):
>
>Eq, Num, Ord, Int, Uns, Sgnd, Float, Cmplx, Bool, Str, Bytes, Runes, Add
>
> So, for the first one, the actual code would be:
>
> contract Eq(t T) {
> t == t
> }
>
> Of course, as the code is not going to be executed, all that matters is that
> these expressions survive the type checker for the actual type used.
>
> The advantage of doing something like this is that where you only need a
> single type parameter and are happy to constrain it to one of these
> 'type-classes', you could do so straight 'out of the box' with a contract
> such as ct.Int, ct.Str or whatever. I suspect that this would cover a large
> percentage of use cases in practice and so would be a worthwhile feature.
>
> It might also satisfy those of us who favored a 'type-class' based solution,
> particularly as it doesn't require any more built-ins or other syntactic
> overhead compared to the original proposal.

I agree that we should do this, for the reasons you state.

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] Re: Generics as builtin typeclasses

[alanfo]

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 
particularly struck me was that expressions such as:

1. ' t == t  ' implies that both == and != are valid operations i.e. type 
is comparable.

2  ' t * t  ' implies both * and *= are valid.

3. ' t < t  ' implies that <, >, <=, >= , == and != are all valid i.e. type 
is ordered.

Suppose this idea were taken to its logical conclusion.

So in the case of #2 the compiler could further imply that it must be 
dealing with an integer, floating point or complex type (as only those 
types support the multiplication operator) and that consequently ALL the 
operations, conversions, assignments etc. which those types had in common 
could be used by a generic function/type that was constrained by a contract 
containing that expression.

Similarly, #3 would tell the compiler that it must be dealing with an 
integer, floating point or string type as only those types are ordered.

It's easy to think of a number of other simple expressions where the 
compiler could imply the allowable types:

4. ' t % t  ' implies any integer type.

5. ' 1 << t ' implies an unsigned integer type.

6. ' -1 ^ t ' implies a signed integer type.

7. ' t == 1.1 ' implies a floating point or complex type.

8. ' imag(t) ' implies a complex type.

9. ' !a ' implies a boolean type.

10. ' t  == "" ' implies a string type.

11. ' []byte(a) ' implies a string type or byte slice.

12. ' []rune(a) ' implies a string type or rune slice.

13. ' a + a ' implies an integer, floating point, complex or string type.

Now let's further suppose that the standard library contained a contracts 
package (with a nice short name such as 'ct') containing contracts for each 
of these expressions. Let's give them some shortish names such as (in the 
same order):
 
   Eq, Num, Ord, Int, Uns, Sgnd, Float, Cmplx, Bool, Str, Bytes, Runes, Add 

So, for the first one, the actual code would be:

contract Eq(t T) {
t == t
}

Of course, as the code is not going to be executed, all that matters is 
that these expressions survive the type checker for the actual type used.

The advantage of doing something like this is that where you only need a 
single type parameter and are happy to constrain it to one of these 
'type-classes', you could do so straight 'out of the box' with a contract 
such as ct.Int, ct.Str or whatever. I suspect that this would cover a large 
percentage of use cases in practice and so would be a worthwhile feature.

It might also satisfy those of us who favored a 'type-class' based 
solution, particularly as it doesn't require any more built-ins or other 
syntactic overhead compared to the original proposal.

It's giving the compiler more to do in one way but less to do in another as 
it should solve nearly all operator/conversion problems without further 
ado. It should also solve the problems we currently have with untyped 
constants.

For more complicated cases, the full power of user defined contracts would 
still be available.

Does anyone else think there's any mileage in this idea or am I just 
whistling in the dark?
  
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 as builtin typeclasses

[Ian Lance Taylor]

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, but, in general the Go type system is not very complex.  There are
many algorithms we write in Go today that have constraints on their
types that we can not implement.  For example, it is well known and
accepted that an interface type may permit a type that will not work
for the algorithm.  So perhaps I should say it this way: how much
complexity are we willing to tolerate to permit a polymorphic function
to forbid some type arguments?

To expand on that, I believe that we need a mechanism to set a lower
bound, if you will, on the type arguments: they have to implement
certain operations.  The question is whether we need a mechanism to
set an upper bound on type arguments, or whether it is sufficient to
rely on documentation.

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] Re: Generics as builtin typeclasses

[Wojciech S. Czarnecki]

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.

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

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

[Ian Lance Taylor]

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" nature of operators on intrinsic types lies at the core
> of the problem contracts are trying to solve? To some degree, restricting
> the use of such generic operators (and Stroustrup also foresaw that indexing
> is one such operator, despite its use of two, separate characters, give him
> some credit) is the final purpose, much more so than the "extension" of
> functions to some concept of "compatibility" between functions.

I think it's difficult to say.  I think most generic functions and
types will be written without any contracts at all.  I think there are
clear needs for generic functions that require operators, but I also
think it's likely that all such functions will be written fairly
quickly.  Once we move past a set of standard generic functions, I
think that functions that require operators will be relatively rare
special cases.  On the other hand, I think that there will always be a
need for generic types that are slices/maps/chans of types that
support specific methods, where people want to, in effect, use
interface types without requiring boxing.

But I'm just guessing.  Only time and experience will tell.

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] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

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).  But this is a game of
code golf.  Why is it useful to say "this polymorphic function may
only be instantiated with unsigned integer types?"  Conversely, should
we be looking for ways to remove this kind of generality from
contracts?  As you know, we had an earlier system for that, but it
required adding a number of new concepts to the language; the current
design draft adds very few concepts, but has the disadvantage of
possibly excessive generality.

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] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

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, not to mention unsafe, which raises the issue of
> whether a contract must be written in pure Go without imports. I'm not sure,
> but I do think it might be good that it does.

In general I think it can be quite useful to refer to imported names.
For example,

contract Stringable(x T) {
var _ fmt.Stringer = x
}

is a simple and clear way to require a type that provides a String method.


> Even then, saying v%1 is the way to ask for an integer is infelicitous at
> best.

Yes.  As I alluded to before, I think it's worth asking: why does it
matter?  When is it important to not just express what operations are
required for a type, but also to try to rule out some types?


> To my mind this general area is the least clear part of the contracts
> design: what _is_ a contract?

A contract is a compile-time description of which types are permitted
for a polymorphic function or type.

There are two sides to a contract.  I continue to hope and believe
that one side is fairly clear: a contract indicates which type
arguments are acceptable, namely those that permit the contract to
type-check successfully.  The other side I agree is less clear: what
operations does a contract permit in the generic code?

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] Re: Opening brace can't be placed on a separate line killing the language for me

[Jan Mercl]

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 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: Opening brace can't be placed on a separate line killing the language for me

[Mark Volkmann]

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

-- 
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] Opening brace can't be placed on a separate line killing the language for me

[Jan Mercl]

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 flexibility is important, if not essential. Not being able to
cope with such minor detail as code formatting does not fit that well.

I hope you can reconsider and still turn your "wasted time" into a personal
gain to your advantage.

-- 

-j

-- 
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: Opening brace can't be placed on a separate line killing the language for me

[Jan Mercl]

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.

-- 

-j

-- 
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: Opening brace can't be placed on a separate line killing the language for me

[Dave Cheney]

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 aside because of the 
wider benefits of having a _single_ coding style that is enforced across 
all Go code (even if someone doesn't use it, I can pass their code though 
gofmt before reading it) which makes, to some degree, the syntax melt into 
the background.

I'd encourage you to persist with Go beyond the minor syntactic issues.

Dave

On Saturday, 8 September 2018 18:09:31 UTC+10, Mohamed yousry wrote:
>
> 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 tried to Google the error andd I was shocked when I found out that I 
> can't style my code the way I want. 
> Is it that hard for them to add some kind of exception for that kind of 
> problem. 
> I wish they really fix it or if there any fix please point it out . 
>  For me the language is Dead now it was a wasted time 
>

-- 
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] Opening brace can't be placed on a separate line killing the language for me

[odsh97]

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 tried to Google the error 
andd I was shocked when I found out that I can't style my code the way I want.
Is it that hard for them to add some kind of exception for that kind of problem.
I wish they really fix it or if there any fix please point it out .
 For me the language is Dead now it was a wasted time 

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