[go-nuts] Re: do you use binary-only packages?
I'd say it's a useful feature, but not in it 's current form. I rather than dropping the featture I'd like to see it enhanced so so it works as well as a pascal .unit file does as a binary package for a high level language. This also points to a solution as well, have a .gobin file that is an archive that contains all the meta information and the compiled .a and/or .so file as well. -- 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: [gomobile] How to generate reverse-bindings for Java without the gradle-plugin?
I see. For Android API, you'll need to specify the bootstrap classpath by
setting the gomobile -bootclasspath flag to point to the android.jar from
the Android SDK that matches your platform version. For example:
$ gomobile bind -bootclasspath /platforms/android-27/android.jar
If you need access to your own Java classes, use the -classpath flag.
- elias
On Friday, October 19, 2018 at 8:49:50 AM UTC+2, Tim Cooijmans wrote:
>
> Simple example:
> package test
>
>
> import (
> "Java/android/content"
> "Java/android/content/pm"
> )
>
>
>
>
> func Test() string {
> return "Hello world"
> }
>
>
> returns
> $ gomobile bind -v git.xxx.com/test
> type-checking package "git.xxx.com/test" failed
> (/Users/xxx/Development/xxx/src/git.xxx.com/test/gobind.go:4:2: could not
> import Java/android/content (cannot find package "Java/android/content" in
> any of:
> /usr/local/Cellar/go/1.11.1/libexec/src/Java/android/content (from $GOROOT)
> /Users/xxx/Development/xxx/src/Java/android/content (from $GOPATH)))
>
> gomobile: /Users/xxx/Development/xxx/bin/gobind -lang=go,java
> -outdir=/var/folders/wz/4c7lp4w92y99_2bmpyx0j8smgn/T/gomobile-work-238062479
>
> git.xxx.com/test failed: exit status 1
>
>
> On Thursday, October 18, 2018 at 11:28:25 PM UTC+2, Elias Naur wrote:
>>
>> Does
>>
>> gomobile bind
>>
>> work? If not, what does it say?
>>
>> - elias
>>
>>
--
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: [gomobile] How to generate reverse-bindings for Java without the gradle-plugin?
Hi,
I just tried but it doesn't work:
$ ls
/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
$ gomobile bind -v -bootclasspath
/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
git.xxx.com/test
type-checking package "git.xxx.com/test" failed
(/Users/timcooijmans/Development/xxx/src/git.xxx.com/test/gobind.go:4:2:
could not import Java/android/content (cannot find package
"Java/android/content" in any of:
/usr/local/Cellar/go/1.11.1/libexec/src/Java/android/content (from $GOROOT)
/Users/timcooijmans/Development/xxx/src/Java/android/content (from
$GOPATH)))
gomobile: /Users/timcooijmans/Development/xxx/bin/gobind -lang=go,java
-outdir=/var/folders/wz/4c7lp4w92y99_2bmpyx0j8smgn/T/gomobile-work-615111792
-bootclasspath=/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
git.xxx.com/test failed: exit status 1
On Friday, October 19, 2018 at 9:30:04 AM UTC+2, Elias Naur wrote:
>
> I see. For Android API, you'll need to specify the bootstrap classpath by
> setting the gomobile -bootclasspath flag to point to the android.jar from
> the Android SDK that matches your platform version. For example:
>
> $ gomobile bind -bootclasspath /platforms/android-27/android.jar pkg>
>
> If you need access to your own Java classes, use the -classpath flag.
>
> - elias
>
> On Friday, October 19, 2018 at 8:49:50 AM UTC+2, Tim Cooijmans wrote:
>>
>> Simple example:
>> package test
>>
>>
>> import (
>> "Java/android/content"
>> "Java/android/content/pm"
>> )
>>
>>
>>
>>
>> func Test() string {
>> return "Hello world"
>> }
>>
>>
>> returns
>> $ gomobile bind -v git.xxx.com/test
>> type-checking package "git.xxx.com/test" failed
>> (/Users/xxx/Development/xxx/src/git.xxx.com/test/gobind.go:4:2: could
>> not import Java/android/content (cannot find package "Java/android/content"
>> in any of:
>> /usr/local/Cellar/go/1.11.1/libexec/src/Java/android/content (from
>> $GOROOT)
>> /Users/xxx/Development/xxx/src/Java/android/content (from $GOPATH)))
>>
>> gomobile: /Users/xxx/Development/xxx/bin/gobind -lang=go,java
>> -outdir=/var/folders/wz/4c7lp4w92y99_2bmpyx0j8smgn/T/gomobile-work-238062479
>>
>> git.xxx.com/test failed: exit status 1
>>
>>
>> On Thursday, October 18, 2018 at 11:28:25 PM UTC+2, Elias Naur wrote:
>>>
>>> Does
>>>
>>> gomobile bind
>>>
>>> work? If not, what does it say?
>>>
>>> - elias
>>>
>>>
--
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: [gomobile] How to generate reverse-bindings for Java without the gradle-plugin?
You're not using the imports. To avoid generating for the entire Android
API, the reverse generator only generates bindings referenced by your code.
For examples, see golang.org/x/mobile/bind/testdata/testpkg/javapkg. This
works for me:
$ gomobile bind golang.org/x/mobile/bind/testdata/testpkg/javapkg
I agree that the error message could be better, or that an empty packages
could be generated for your example. Reverse bindings are not of the same
quality as regular bindings, I'm sorry.
- elias
On Friday, October 19, 2018 at 9:38:33 AM UTC+2, Tim Cooijmans wrote:
>
> Hi,
>
> I just tried but it doesn't work:
> $ ls
> /Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
> /Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
> $ gomobile bind -v -bootclasspath
> /Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
> git.xxx.com/test
> type-checking package "git.xxx.com/test" failed
> (/Users/timcooijmans/Development/xxx/src/git.xxx.com/test/gobind.go:4:2:
> could not import Java/android/content (cannot find package
> "Java/android/content" in any of:
> /usr/local/Cellar/go/1.11.1/libexec/src/Java/android/content (from $GOROOT)
> /Users/timcooijmans/Development/xxx/src/Java/android/content (from
> $GOPATH)))
>
> gomobile: /Users/timcooijmans/Development/xxx/bin/gobind -lang=go,java
> -outdir=/var/folders/wz/4c7lp4w92y99_2bmpyx0j8smgn/T/gomobile-work-615111792
>
> -bootclasspath=/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
>
> git.xxx.com/test failed: exit status 1
>
>
> On Friday, October 19, 2018 at 9:30:04 AM UTC+2, Elias Naur wrote:
>>
>> I see. For Android API, you'll need to specify the bootstrap classpath by
>> setting the gomobile -bootclasspath flag to point to the android.jar from
>> the Android SDK that matches your platform version. For example:
>>
>> $ gomobile bind -bootclasspath /platforms/android-27/android.jar > pkg>
>>
>> If you need access to your own Java classes, use the -classpath flag.
>>
>> - elias
>>
>> On Friday, October 19, 2018 at 8:49:50 AM UTC+2, Tim Cooijmans wrote:
>>>
>>> Simple example:
>>> package test
>>>
>>>
>>> import (
>>> "Java/android/content"
>>> "Java/android/content/pm"
>>> )
>>>
>>>
>>>
>>>
>>> func Test() string {
>>> return "Hello world"
>>> }
>>>
>>>
>>> returns
>>> $ gomobile bind -v git.xxx.com/test
>>> type-checking package "git.xxx.com/test" failed
>>> (/Users/xxx/Development/xxx/src/git.xxx.com/test/gobind.go:4:2: could
>>> not import Java/android/content (cannot find package "Java/android/content"
>>> in any of:
>>> /usr/local/Cellar/go/1.11.1/libexec/src/Java/android/content (from
>>> $GOROOT)
>>> /Users/xxx/Development/xxx/src/Java/android/content (from $GOPATH)))
>>>
>>> gomobile: /Users/xxx/Development/xxx/bin/gobind -lang=go,java
>>> -outdir=/var/folders/wz/4c7lp4w92y99_2bmpyx0j8smgn/T/gomobile-work-238062479
>>>
>>> git.xxx.com/test failed: exit status 1
>>>
>>>
>>> On Thursday, October 18, 2018 at 11:28:25 PM UTC+2, Elias Naur wrote:
Does
gomobile bind
work? If not, what does it say?
- elias
--
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: [gomobile] How to generate reverse-bindings for Java without the gradle-plugin?
Thanks!
Not using the packages was the issue.
On Friday, October 19, 2018 at 10:10:25 AM UTC+2, Elias Naur wrote:
>
> You're not using the imports. To avoid generating for the entire Android
> API, the reverse generator only generates bindings referenced by your code.
> For examples, see golang.org/x/mobile/bind/testdata/testpkg/javapkg. This
> works for me:
>
> $ gomobile bind golang.org/x/mobile/bind/testdata/testpkg/javapkg
>
> I agree that the error message could be better, or that an empty packages
> could be generated for your example. Reverse bindings are not of the same
> quality as regular bindings, I'm sorry.
>
> - elias
>
> On Friday, October 19, 2018 at 9:38:33 AM UTC+2, Tim Cooijmans wrote:
>>
>> Hi,
>>
>> I just tried but it doesn't work:
>> $ ls
>> /Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
>>
>> /Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
>> $ gomobile bind -v -bootclasspath
>> /Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
>> git.xxx.com/test
>> type-checking package "git.xxx.com/test" failed
>> (/Users/timcooijmans/Development/xxx/src/git.xxx.com/test/gobind.go:4:2:
>> could not import Java/android/content (cannot find package
>> "Java/android/content" in any of:
>> /usr/local/Cellar/go/1.11.1/libexec/src/Java/android/content (from
>> $GOROOT)
>> /Users/timcooijmans/Development/xxx/src/Java/android/content (from
>> $GOPATH)))
>>
>> gomobile: /Users/timcooijmans/Development/xxx/bin/gobind -lang=go,java
>> -outdir=/var/folders/wz/4c7lp4w92y99_2bmpyx0j8smgn/T/gomobile-work-615111792
>>
>> -bootclasspath=/Users/timcooijmans/Development/AndroidSDK/platforms/android-27/android.jar
>>
>> git.xxx.com/test failed: exit status 1
>>
>>
>> On Friday, October 19, 2018 at 9:30:04 AM UTC+2, Elias Naur wrote:
>>>
>>> I see. For Android API, you'll need to specify the bootstrap classpath
>>> by setting the gomobile -bootclasspath flag to point to the android.jar
>>> from the Android SDK that matches your platform version. For example:
>>>
>>> $ gomobile bind -bootclasspath /platforms/android-27/android.jar
>>>
>>>
>>> If you need access to your own Java classes, use the -classpath flag.
>>>
>>> - elias
>>>
>>> On Friday, October 19, 2018 at 8:49:50 AM UTC+2, Tim Cooijmans wrote:
Simple example:
package test
import (
"Java/android/content"
"Java/android/content/pm"
)
func Test() string {
return "Hello world"
}
returns
$ gomobile bind -v git.xxx.com/test
type-checking package "git.xxx.com/test" failed
(/Users/xxx/Development/xxx/src/git.xxx.com/test/gobind.go:4:2: could
not import Java/android/content (cannot find package
"Java/android/content"
in any of:
/usr/local/Cellar/go/1.11.1/libexec/src/Java/android/content (from
$GOROOT)
/Users/xxx/Development/xxx/src/Java/android/content (from $GOPATH)))
gomobile: /Users/xxx/Development/xxx/bin/gobind -lang=go,java
-outdir=/var/folders/wz/4c7lp4w92y99_2bmpyx0j8smgn/T/gomobile-work-238062479
git.xxx.com/test failed: exit status 1
On Thursday, October 18, 2018 at 11:28:25 PM UTC+2, Elias Naur wrote:
>
> Does
>
> gomobile bind
>
> work? If not, what does it say?
>
> - elias
>
>
--
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] relaxing type conversions: an "almost possible" idea with Go generics
On Thu, 18 Oct 2018 at 13:41, Axel Wagner
wrote:
> On Thu, Oct 18, 2018 at 2:06 PM roger peppe wrote:
>
>> For generics, that analysis is trivial - there is no need to do any
>> control flow analysis to determine the set of possible generic type
>> parameters to a type or function (with the exception of recursive generic
>> functions, which can be disallowed).
>>
>> For interfaces, the job is much harder. Guru can do it, but only to a
>> limited extent. And in general it's not possible a) because the number of
>> possible types is not bounded (you can create new types with the reflect
>> package, or by dynamically loading modules) and b) because you'd need to
>> solve the halting problem.
>>
>
> I don't understand what you're trying to say. These two cases are not
> relevant here, because you can't actually do them with the contracts design
> - in fact, at least the reflection one is specifically called out in the
> "Dual implementation" section of the overview. I never claimed the analysis
> for interfaces is *easier*, I claimed that it's *exactly as hard.*
>
> Or, to put it another way: That "limited extend" you mention is exactly
> the extend to which the compiler can do that proof for generics. So doing
> it to that extend provides you with the same performance benefit.
>
> Or, if you prefer: The type-checker and/or heuristic for whether to
> specialize a function for generics provides a blue-print for how to do the
> equivalent analysis for interfaces.
>
It really doesn't, because interface values carry their types with them,
whereas type parameters always stay as type parameters and cannot be
directly stored in a value (unless you convert it to an interface value).
You cannot take the dynamic type of an interface value and turn it into a
type parameter unless you explicitly mention the type... at which point
it's no longer dynamic.
With type-parametric generics, you cannot return a value with a type that
uses a generic type that's not passed in the type parameters. With
interfaces, you can.
With type-parametrics generics, you can expand all possible type parameters
at compile time without needing to do any flow analysis. As an example:
https://play.golang.org/p/68eHo313LZI. It's easy to find out all the
possible types for the generic functions there. Here they are.
repeat(string)
repeat(int)
repeat([]string)
last([]string)
index([]string)
first(int)
index(int)
The algorithm to do it is quite straightforward:
https://play.golang.org/p/subnLkSSxdI
But in the case where your first paragraph applies - i.e. you can
>>> statically know the full set of types a generic function or type is
>>> instantiated with - the exact same analysis can also provide exactly the
>>> same results for interface-based polymorphism.
>>>
>>
>> It really can't. The analysis needed for parametric types need not look
>> at anything other than type parameters. The analysis needed for interfaces
>> needs to analyse the code itself. A few examples:
>> https://play.golang.org/p/CEzBpsRIVGQ
>>
>
> AFAICT none of these map to contracts either.
>
Actually they do - interface{} is equivalent to the contract(T){}. But I'm
not sure what you're getting at 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] relaxing type conversions: an "almost possible" idea with Go generics
On Fri, 19 Oct 2018 at 12:04, roger peppe wrote: > The algorithm to do it is quite straightforward: > https://play.golang.org/p/subnLkSSxdI > On reflection, that ParamType hack won't work correctly with types.Identical. This should work better: https://play.golang.org/p/iswgf7mr8ht > -- 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] Regarding contracts
On Thursday, 18 October 2018 21:51:35 UTC+2, robert engels wrote: > > I guess I don’t understand the problem with using “method names” e.g. > Less() in generic code - yes it is a little more verbose - but it avoids > the traditional problems with operator overloading leading to obtuse code. > > The issue that has not been raised yet, but is bound to come up, is that operators compose into expressions whereas methods have a much simpler, much more restrictive composition paradigm. Add operator precedence to the mix and stand well back. I frankly prefer methods to operators, but the need here is to retain the features of operators within generics and that means dealing with precedence as well as conversion, not just within the arithmetic realm, but specially across the operation, like when == transforms practically any compatible operands to a boolean result. Just adding my two cents of accelerant to a flammable mixture. Feel free to point out, if applicable, that I'm off topic and, specially instructive, why. But make it simple, there has been quite a bit written here I don't think I'll ever get my head around. 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] Regarding contracts
I don’t think it matters, since when writing the generic code using methods the
author has strict control over the precedence.
Also, for equality testing, the signature would be bool Equals(interface{})
with required casting. Without looking for flames, this is how Java does it and
it’s never been a problem. You could go farther and define bool T.Equality(T)
and have Equals defer to that when the type casts pass, or have the compiler
perform the check and make the call.
So I’m not sure of the problem.
> On Oct 19, 2018, at 7:59 AM, Lucio wrote:
>
>> On Thursday, 18 October 2018 21:51:35 UTC+2, robert engels wrote:
>> I guess I don’t understand the problem with using “method names” e.g. Less()
>> in generic code - yes it is a little more verbose - but it avoids the
>> traditional problems with operator overloading leading to obtuse code.
>>
> The issue that has not been raised yet, but is bound to come up, is that
> operators compose into expressions whereas methods have a much simpler, much
> more restrictive composition paradigm. Add operator precedence to the mix and
> stand well back.
>
> I frankly prefer methods to operators, but the need here is to retain the
> features of operators within generics and that means dealing with precedence
> as well as conversion, not just within the arithmetic realm, but specially
> across the operation, like when == transforms practically any compatible
> operands to a boolean result.
>
> Just adding my two cents of accelerant to a flammable mixture. Feel free to
> point out, if applicable, that I'm off topic and, specially instructive, why.
> But make it simple, there has been quite a bit written here I don't think
> I'll ever get my head around.
>
> 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.
--
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: do you use binary-only packages?
On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor wrote: > > The question is: is anybody actually doing this? Is anybody seriously > thinking about it? > > Ian > Unhelpfully, I imagine it unlikely that anyone distributing binary go packages reads golang-dev or golang-nuts. -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.
Re: [go-nuts] Regarding contracts
Beoran : > I think the idea we should focus on here is "The type is the contract". > Instead of specifying a contract though operations, just use concrete > types, including primitive types to specify the desired qualities of the > generic type. This is, of course, similar to my "implements" proposal in that it uses the semantic richness of primitive types to carve up contract space, rather than defining an extension language to describe contracts from the ground up. I still like "implements" better because it's simpler - just one new keyword. Also I think the granularity of "like this operator" is more appropriate than the granularity of "like this type". That said, I like Burak's design better than anything I've seen yet *except* "implements". -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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] Regarding contracts
Andy Balholm : > I don’t think that generic functions should have access to private > fields of their type parameters, regardless of what package they are > in. Agreed. Turns me off this proposal somewhat. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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] Regarding contracts
On Fri, Oct 19, 2018 at 7:13 AM Robert Engels wrote:
>
> I don’t think it matters, since when writing the generic code using methods
> the author has strict control over the precedence.
>
> Also, for equality testing, the signature would be bool Equals(interface{})
> with required casting. Without looking for flames, this is how Java does it
> and it’s never been a problem. You could go farther and define bool
> T.Equality(T) and have Equals defer to that when the type casts pass, or have
> the compiler perform the check and make the call.
>
> So I’m not sure of the problem.
I don't have strong opinions about operator overloading vs. using
methods for operators. The point of this thread was to offer an
alternative to contracts, and the alternative offered is still
valid with or without operator overloading.
Re: Ian Denhardt's proposal:
I agree that it handles all the cases in the official proposal,
but I think the syntax is too verbose and reminds me of
Java. For instance, the "sorting" example can be written using
the "like" keyword as:
Template:
type orderedSlice []like (int,string)
func (s orderedSlice) Len() int { return len(s) }
func (s orderedSlice) Less(i, j int) bool { return s[i]
> On Oct 19, 2018, at 7:59 AM, Lucio wrote:
>
> On Thursday, 18 October 2018 21:51:35 UTC+2, robert engels wrote:
>>
>> I guess I don’t understand the problem with using “method names” e.g. Less()
>> in generic code - yes it is a little more verbose - but it avoids the
>> traditional problems with operator overloading leading to obtuse code.
>>
> The issue that has not been raised yet, but is bound to come up, is that
> operators compose into expressions whereas methods have a much simpler, much
> more restrictive composition paradigm. Add operator precedence to the mix and
> stand well back.
>
> I frankly prefer methods to operators, but the need here is to retain the
> features of operators within generics and that means dealing with precedence
> as well as conversion, not just within the arithmetic realm, but specially
> across the operation, like when == transforms practically any compatible
> operands to a boolean result.
>
> Just adding my two cents of accelerant to a flammable mixture. Feel free to
> point out, if applicable, that I'm off topic and, specially instructive, why.
> But make it simple, there has been quite a bit written here I don't think
> I'll ever get my head around.
>
> 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.
>
> --
> 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] Regarding contracts
Ian Denhardt : > I feel like Burak's proposal is falling into the same trap as many others: > there is a common feeling that operator overloading is a Pandora's box, so > folks are trying to work around it by solving the problem without providing > operator overloading. But *the problem itself* is not being able to abstract > over operators, so this approach is doomed to failure. You just result in a > clumsy design that can't decide if it's trying to allow operators to be > abstracted over or not, since the whole point is to allow this, but the > particulars of the design are motivated by a fear of actually doing so. > > I there is a fundamental conflict here. You can express the same concepts > as with operator overloading if you're willing to wrap the basic types and use > methods like .Less() in generic code. But I think fundamentally folks have to > make choice: do we want to be able to write `<` for user defined types, or do > we want to be able to look at the `<` operator and know for certain that it's > not calling a method? You can't have both. Ian has just unpacked my "unwelcome conclusion" very nicely. This is *exactly* the insight that led me to design "implements". This is why I confidently predict that nobody will find a simpler way to approximate contracts than "implements". Ever. (In particular, Burak's way is, though clever and interesting, not simpler.) Because "implements" is the dead bare minimum expression of abstracting over operators; anything else you do to go near that has to be more complicated and roundabout. Of course "implements" is not an entire generic system; we need syntax and semantics for parametric polymorphism and parametric types, too. But it's a *good thing* that "implements" can be described without any reference to these concerns; it means we have *orthogonality*. I would go further than that and say any proposal that has to specify all three extensions (contracts, parametric polymorphism, parametric types) at once in order for any of it to work is too complex, fails orthogonality forever, and should be regarded with deep suspicion that it is overcommitting the language in a wrong direction. The "implements" proposal adds just one keyword. *One,* and the syntax is trivial. That's not just parsimony on the surface, it's a fundamental clue that we have found the simplest way possible to express what it gives us access to. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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] Regarding contracts
On Fri, Oct 19, 2018 at 10:38 AM Eric S. Raymond wrote: > > Ian Denhardt : > > I feel like Burak's proposal is falling into the same trap as many others: > > there is a common feeling that operator overloading is a Pandora's box, so > > folks are trying to work around it by solving the problem without providing > > operator overloading. But *the problem itself* is not being able to abstract > > over operators, so this approach is doomed to failure. You just result in a > > clumsy design that can't decide if it's trying to allow operators to be > > abstracted over or not, since the whole point is to allow this, but the > > particulars of the design are motivated by a fear of actually doing so. > > > > I there is a fundamental conflict here. You can express the same concepts > > as with operator overloading if you're willing to wrap the basic types and > > use > > methods like .Less() in generic code. But I think fundamentally folks have > > to > > make choice: do we want to be able to write `<` for user defined types, or > > do > > we want to be able to look at the `<` operator and know for certain that > > it's > > not calling a method? You can't have both. > > Ian has just unpacked my "unwelcome conclusion" very nicely. This is > *exactly* > the insight that led me to design "implements". > > This is why I confidently predict that nobody will find a simpler way > to approximate contracts than "implements". Ever. (In particular, > Burak's way is, though clever and interesting, not simpler.) Because > "implements" is the dead bare minimum expression of abstracting over > operators; anything else you do to go near that has to be more > complicated and roundabout. Where can I read about this "implements"? Link? -- 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] Proposed changes to the Go draft generics design in the light of feedback received
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: 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] Regarding contracts
Burak Serdar : > Where can I read about this "implements"? Link? https://groups.google.com/forum/#!topic/golang-nuts/pR5pmql5olM After subsequent discussion I would only add these points: * The "implements" construct is not a full generic-type system in itself, nor is it meant to be. It's meant to be an orthogonal piece that replaces heavyweight contracts proposals, and needs to be mated with a system ot parametric polymorphism and one of type composition. * To the compiler, the contract implied by each operator is just its type signature (e.g '<' has the signature a.(T).func(b T) bool) and precedence. The semantics of what each possible operator means (e.g. < is for sorting, + is a concatenation operator) is a social convention expressed by how the operator is used by the standard library and packages. * Other considerations in the language imply a rule that operators on pointer types cannot have implements methods (but non-pointer types can have implements methods with pointer receivers). * There is room for debate about which operators can be the subject of an implements clause. Everybody clearly wants < + - == | & (what you need to do set algebra) and I think ! is important. There is a general feeling that =+ =- and friends should not be overloadable but should be considered lexical abbreviations in the obvious way. * There is debate about whether there should be implied overloading - that is if a method foo(a T, b T) implements == should it be the case that not only a == b translates to foo(a, b) but a != b translates to !foo(a, b). I'm not strongly attached to a position on either of the debates. I note howvever that I do not want a < b to imply !(b > a) because I do things with graphs and lattice algebra and want to be able to express partial (not just total) ordering. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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: Proposed changes to the Go draft generics design in the light of feedback received
On Friday, October 19, 2018 at 1:48:36 PM UTC-4, 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. > Surface changes that don't tackle the fundamental unwieldiness and overcomplexity of the contracts extension. A good honest effort, Alan, but (with due respect to the people who put in cleverness and effort on the original overcomplication, I don't mean to insult them) this is lipstick on a pig. -- 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] Regarding contracts
Quoting Burak Serdar (2018-10-19 12:34:44)
> Re: Ian Denhardt's proposal:
>
> I agree that it handles all the cases in the official proposal,
> but I think the syntax is too verbose and reminds me of
> Java. For instance, the "sorting" example can be written using
> the "like" keyword as:
>
> Template:
>
> type orderedSlice []like (int,string)
>
> func (s orderedSlice) Len() int { return len(s) }
> func (s orderedSlice) Less(i, j int) bool { return s[i] func (s orderedSlice) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
>
> // There is no need for an OrderedSlice function
>
> Concerete use:
>
> type mySlice orderedSlice []int64
>
> v:=mySlice{1,2,3}
> sort.Slice(v)
This example in my proposal was intended to show the minimal change
needed from the draft design, but I also mentioned that you actually
didn't need `orderedSlice` at all to sort slices. If you combine it
with Eric's proposal for operator overloading, you can just write
v := []int64{1,2,3}
sort.Slice(v)
..with no boilerplate type/method definitions, or casts, at all.
> However, one limitation of using interfaces to specify contracts
> is that you can't use a struct type as a basis for your
> contract. For instance, going back to the linked list example:
>
> type Node like struct {
>next *Node
> }
>
> With interfaces as contracts, this becomes:
>
> type Node(type E) interface {
>GetNext()
>SetNext(*Node(E))
> }
This is true; exposing the next-pointer structure of a linked list
through an interface is more verbose. However I'm not convinced there
are good uses for this; Can you provide an example where such a template
would actually be useful?
--
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] Regarding contracts
Quoting Burak Serdar (2018-10-19 12:46:19) > Where can I read about this "implements"? Link? This is the thread: https://groups.google.com/forum/#!search/go-nuts/golang-nuts/pR5pmql5olM/RPDuL2BsCAAJ -- 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] Regarding contracts
On Fri, Oct 19, 2018 at 12:01 PM Ian Denhardt wrote:
>
> Quoting Burak Serdar (2018-10-19 12:34:44)
> > Re: Ian Denhardt's proposal:
> >
> > I agree that it handles all the cases in the official proposal,
> > but I think the syntax is too verbose and reminds me of
> > Java. For instance, the "sorting" example can be written using
> > the "like" keyword as:
> >
>
> > Template:
> >
> > type orderedSlice []like (int,string)
> >
> > func (s orderedSlice) Len() int { return len(s) }
> > func (s orderedSlice) Less(i, j int) bool { return s[i] > func (s orderedSlice) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
> >
> > // There is no need for an OrderedSlice function
> >
> > Concerete use:
> >
> > type mySlice orderedSlice []int64
> >
> > v:=mySlice{1,2,3}
> > sort.Slice(v)
>
> This example in my proposal was intended to show the minimal change
> needed from the draft design, but I also mentioned that you actually
> didn't need `orderedSlice` at all to sort slices. If you combine it
> with Eric's proposal for operator overloading, you can just write
>
> v := []int64{1,2,3}
> sort.Slice(v)
>
> ..with no boilerplate type/method definitions, or casts, at all.
>
> > However, one limitation of using interfaces to specify contracts
> > is that you can't use a struct type as a basis for your
> > contract. For instance, going back to the linked list example:
> >
> > type Node like struct {
> >next *Node
> > }
> >
> > With interfaces as contracts, this becomes:
> >
> > type Node(type E) interface {
> >GetNext()
> >SetNext(*Node(E))
> > }
>
> This is true; exposing the next-pointer structure of a linked list
> through an interface is more verbose. However I'm not convinced there
> are good uses for this; Can you provide an example where such a template
> would actually be useful?
It is useful in a linked list. You can instantiate a linked list
template in a package, and use that concrete type in another package
without access to the internals of the linked list.
--
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] Regarding contracts
On Thu, Oct 18, 2018 at 10:48 AM, Burak Serdar wrote:
> On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor wrote:
>>
>> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote:
>> >
>> > Instead of specifying the minimal set of operations a type should
>> > satisfy, why not describe what the type should look like:
>> >
>> > func f(in like T)
>>
>> I don't see how this approach can handle multiple types that need to
>> work together in some known way, like the Graph/Node/Edge case in the
>> design draft.
>
>
> Still discussing the details, but the graph case in the design draft
> can look like this:
>
> type Node like interface {
>Edges() []Edge
> }
>
> type Edge like interface {
>Nodes() (Node,Node)
> }
>
> type Graph like struct {
>Nodes []*Node
> }
>
> func New(nodes []*Node) *Graph {
> return &Graph{Nodes:nodes}
> }
>
>
> The instantiation:
>
> type MyNode struct {...}
>
> func (m MyNode) Edges() []MyEdge {...}
>
> type MyEdge struct { ...}
>
> func (e MyEdge) Nodes() (*MyNode,*MyNode) {...}
>
> type MyGraph graph.Graph {
> Nodes []*MyNodes
> }
>
> x:=graph.New(MyGraph)(myNodes)
Thanks. I note the subtlety whereby the name Edge in the generic code
gets attached to the name MyEdge in the non-generic code, although it
does not appear anywhere in the call to graph.New. There is a type
mapping happening somewhere.
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] Avoiding overloading
I think Ian Denhardt is right to argue that fear of operator overloading is driving people in the generics debate to complicated, ugly workarounds that should not be. I myself do not actually want overloading as a surface feature of the language. In my original "implements" proposal, I accepted it as an implication of using operators to define type classes, because I thought (and still think) it is the simplest possible way to declare contracts. I think the simplicity of having "implements" as the only contract declaration is too important a win to mortgage to a feature many - including myself - are not actually friendly to. Therefore, as the author of the "implements" proposal, I am declaring neutrality on whether an "implements" clause should declare an overload at all! That is, there is a possible future in which "implements <" on type T does not make a < b legal on non-primitive type T, but is solely a typeclass declaration associating T with all other types that implement <; semantically, a Sortable contract. I would be OK with that future, It keeps the important part of "implements" - simplest way to declare contracts - while tossing out the part that (not without reason) raise some hackles. My only caution here is on interface psychology. If we're going to go this route, users are, to be honest. probably going to bitch that not taking the tiny additional step to overloading is perverse. We'll need a good strong public argument to counter that. -- 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: do you use binary-only packages?
On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer wrote: > > On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor wrote: >> >> The question is: is anybody actually doing this? Is anybody seriously >> thinking about it? > > Unhelpfully, I imagine it unlikely that anyone distributing binary go > packages reads golang-dev or golang-nuts. Is there a more likely place to reach such people? 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: Proposed changes to the Go draft generics design in the light of feedback received
It is not at all obvious that you have sufficient experience of writing Go for anyone to take your, rather disrespectful, comments seriously. Ian has been working on finding a workable model for generic programming in Go for at least 5 years. To many of us, contracts look like a pragmatic solution. A little humility goes a long way. On Fri, 19 Oct 2018, 18:56 Eric Raymond, wrote: > > > On Friday, October 19, 2018 at 1:48:36 PM UTC-4, 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. >> > > Surface changes that don't tackle the fundamental unwieldiness and > overcomplexity of the contracts extension. > > A good honest effort, Alan, but (with due respect to the people who put in > cleverness and effort on the original overcomplication, I don't mean to > insult them) this is lipstick on a pig. > > -- > 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] Regarding contracts
I always assumed that there is no "private" in Go - it is either public or package level. So generic's being able to access same package level accessible things seems to be logical. Andrey On Thursday, October 18, 2018 at 10:21:15 AM UTC-6, Andy Balholm wrote: > > I don’t think that generic functions should have access to private fields > of their type parameters, regardless of what package they are in. > > Andy > > > -- 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] Regarding contracts
On Fri, Oct 19, 2018 at 12:36 PM Ian Lance Taylor wrote:
>
> On Thu, Oct 18, 2018 at 10:48 AM, Burak Serdar wrote:
> > On Thu, Oct 18, 2018 at 11:35 AM Ian Lance Taylor wrote:
> >>
> >> On Wed, Oct 17, 2018 at 11:58 AM, Burak Serdar wrote:
> >> >
> >> > Instead of specifying the minimal set of operations a type should
> >> > satisfy, why not describe what the type should look like:
> >> >
> >> > func f(in like T)
> >>
> >> I don't see how this approach can handle multiple types that need to
> >> work together in some known way, like the Graph/Node/Edge case in the
> >> design draft.
> >
> >
> > Still discussing the details, but the graph case in the design draft
> > can look like this:
> >
> > type Node like interface {
> >Edges() []Edge
> > }
> >
> > type Edge like interface {
> >Nodes() (Node,Node)
> > }
> >
> > type Graph like struct {
> >Nodes []*Node
> > }
> >
> > func New(nodes []*Node) *Graph {
> > return &Graph{Nodes:nodes}
> > }
> >
> >
> > The instantiation:
> >
> > type MyNode struct {...}
> >
> > func (m MyNode) Edges() []MyEdge {...}
> >
> > type MyEdge struct { ...}
> >
> > func (e MyEdge) Nodes() (*MyNode,*MyNode) {...}
> >
> > type MyGraph graph.Graph {
> > Nodes []*MyNodes
> > }
> >
> > x:=graph.New(MyGraph)(myNodes)
>
> Thanks. I note the subtlety whereby the name Edge in the generic code
> gets attached to the name MyEdge in the non-generic code, although it
> does not appear anywhere in the call to graph.New. There is a type
> mapping happening somewhere.
This is still work in progress, but:
graph.New(MyGraph)(myNodes) maps MyGraph to graph.Graph. From
MyGraph.Nodes, MyNode (not MyNodes, there is a typo in the example)
maps to graph.Node, and from MyNode.Edges(), MyEdge maps to
graph.Edge.
I wrote
type MyGraph graph.Graph {
}
for the declaration of the MyGraph type as an instantiation of the
template graph.Graph, and that also could be used for the same type
inference.
>
> 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] Regarding contracts
Quoting Burak Serdar (2018-10-19 14:09:46) > It is useful in a linked list. You can instantiate a linked list > template in a package, and use that concrete type in another package > without access to the internals of the linked list. Can you provide an example of what some code using this would look like? The discussion in the abstract just isn't sticking to my brain... -- 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] Regarding contracts
On Fri, Oct 19, 2018 at 11:48 AM Eric S. Raymond wrote:
>
> Burak Serdar :
> > Where can I read about this "implements"? Link?
>
> https://groups.google.com/forum/#!topic/golang-nuts/pR5pmql5olM
>
> After subsequent discussion I would only add these points:
>
> * The "implements" construct is not a full generic-type system in
> itself, nor is it meant to be. It's meant to be an orthogonal piece
> that replaces heavyweight contracts proposals, and needs to be mated
> with a system ot parametric polymorphism and one of type composition
I agree that "implements" construct solves a lot of problems.
However:
Without operator overloading:
type X interface {
implements <
}
means that you want a primitive numeric type or a string. So:
type Y like(int,string)
Even though it is not as precise as the interface with implements, it
means the same thing.
Assuming you have operator overloading, the X interface will
accept any primitive or struct type that implements <, whereas Y
won't. However, when you have operator overloading, you can still use:
type Y like(X)
So the question is: do we really need to declare exactly what the
implementation of a generic needs in the contract, or is it sufficient
to say "use this with values that are like type X"?
Another thing that motivated me to start this thread in the first
place was imagining myself sitting late at night trying to figure out
how to convert a huge chunk of code to a generic type, and reading
through to figure out exactly what the contract is. With the "like"
syntax, I could simply add "like X" to my arguments, and be done with
it. With interfaces containing "implements", I have to write those
interfaces and figure out exactly what I need. With contracts, I
imagine someone would come up with a tool to build that from the
source if it comes to that.
.
>
> * To the compiler, the contract implied by each operator is just its type
> signature (e.g '<' has the signature a.(T).func(b T) bool) and
> precedence. The semantics of what each possible operator means
> (e.g. < is for sorting, + is a concatenation operator) is a social
> convention expressed by how the operator is used by the standard
> library and packages.
>
> * Other considerations in the language imply a rule that operators on pointer
> types cannot have implements methods (but non-pointer types can have
> implements
> methods with pointer receivers).
>
> * There is room for debate about which operators can be the subject of
> an implements clause. Everybody clearly wants < + - == | & (what you
> need to do set algebra) and I think ! is important. There is a
> general feeling that =+ =- and friends should not be overloadable but
> should be considered lexical abbreviations in the obvious way.
>
> * There is debate about whether there should be implied overloading - that is
> if a method foo(a T, b T) implements == should it be the case that not
> only a == b translates to foo(a, b) but a != b translates to !foo(a, b).
>
> I'm not strongly attached to a position on either of the debates. I
> note howvever that I do not want a < b to imply !(b > a) because I do
> things with graphs and lattice algebra and want to be able to express
> partial (not just total) ordering.
> --
> http://www.catb.org/~esr/";>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be your
> own.
>
>
--
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] Regarding contracts
Burak Serdar : > So the question is: do we really need to declare exactly what the > implementation of a generic needs in the contract, or is it sufficient > to say "use this with values that are like type X"? I think the additional explicitness of "implements" is valuable. And my syntax is lighter-weight than yours - which in a language like Go that highly values parsimony has some significance. That said, the shared idea of defining contracts via implied typeclasses is, I think, more important than the ways in which our proposals differ. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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] Regarding contracts
On Fri, Oct 19, 2018 at 1:26 PM Eric S. Raymond wrote: > > Burak Serdar : > > So the question is: do we really need to declare exactly what the > > implementation of a generic needs in the contract, or is it sufficient > > to say "use this with values that are like type X"? > > I think the additional explicitness of "implements" is valuable. And > my syntax is lighter-weight than yours - which in a language like Go > that highly values parsimony has some significance. I don't agree. > > That said, the shared idea of defining contracts via implied typeclasses > is, I think, more important than the ways in which our proposals differ. I agree. One other difference between the two is the ability of the "like" syntax to use a struct as well as an interface for templates, so you can require concrete implementations to have certain fields, instead of getter/setters. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be your > own. > > -- 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: Proposed changes to the Go draft generics design in the light of feedback received
Tristan Colgate : > It is not at all obvious that you have sufficient experience of writing Go > for anyone to take your, rather disrespectful, comments seriously. Nor is it obvious that an elegant solution can be found by anyone who has been too close to the problem for too long and gotten stuck in a box the walls of which they have trouble noticing. > A little humility goes a long way. I agree. So does actually paying attention when I express respect and appreciation for the people who worked on the "pig". I wasn't kidding; I can tell they're very bright people who put in worthy effort just by reading the product. Getting stuck in an overcomplicated blind alley in design space is not a thing that happens because anyone is stupid or evil. It happens because these problems are *hard*. Often, just noticing that you're stuck is the hardest part. It's happened to me, too. I have developed enough humility to actually value people who can jolt me hard enough to notice how I'm stuck. Perhaps you should consider cultivating more of that yourself. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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
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 [2]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [3]https://groups.google.com/d/optout. > > Verweise > >1. https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87 >2. mailto:golang-nuts+unsubscr...@googlegroups.com >3. 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] Avoiding overloading
Quoting Eric Raymond (2018-10-19 14:43:51) >Therefore, as the author of the "implements" proposal, I am declaring >neutrality on whether an "implements" clause should declare an overload >at all! >That is, there is a possible future in which "implements <" on type T� >does not� make a < b legal on non-primitive type T, but is solely a >typeclass declaration associating� T with all other types that >implement <; semantically, a Sortable contract. What would code making use of a `Sortable` type look like? If you can't actually use "implements <" to overload `<`, it's not clear to me what it would actually do? -- 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] Regarding contracts
Burak Serdar : > One other difference between the two is the ability of the "like" > syntax to use a struct as well as an interface for templates, so you > can require concrete implementations to have certain fields, instead > of getter/setters. I'm puzzled that this is not already possible in interfaces. In the translation from Python I'm working on, I cave two different classes, One, VCS, represents an importer/exporter pair for a given version-control system that speaks the git import stram format. Another, Extractor, bundles methods for mining data from a repository by harnessing its native client tools. Both classes want to be selected by a field "name". It's annoying that I can't declare an interface that says "has a field 'name'" and instead have to declare a getter function with no other point besides sliding around that restriction. But precisely because this could easily be patched into interfaces, I think it's not much of an argument for your plan. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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
I think we need to focus this thread on comments just about alanfo's suggestion. Let's not start debating how to debate. And, of course, let's remember the code of conduct: https://golang.org/conduct . Thanks. 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] Regarding contracts
On Fri, Oct 19, 2018 at 1:03 PM, Eric S. Raymond wrote: > Burak Serdar : >> One other difference between the two is the ability of the "like" >> syntax to use a struct as well as an interface for templates, so you >> can require concrete implementations to have certain fields, instead >> of getter/setters. > > I'm puzzled that this is not already possible in interfaces. > > In the translation from Python I'm working on, I cave two different > classes, One, VCS, represents an importer/exporter pair for a given > version-control system that speaks the git import stram > format. Another, Extractor, bundles methods for mining data from a > repository by harnessing its native client tools. > > Both classes want to be selected by a field "name". It's annoying that > I can't declare an interface that says "has a field 'name'" and instead > have to declare a getter function with no other point besides sliding > around that restriction. > > But precisely because this could easily be patched into interfaces, > I think it's not much of an argument for your plan. I think you are talking about https://golang.org/issue/23796 (which was not accepted). 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] Avoiding overloading
Ian Denhardt : > What would code making use of a `Sortable` type look like? If you can't > actually use "implements <" to overload `<`, it's not clear to me what > it would actually do? Be available to a Sort function. That is, the requirement "Have a Less()" would be replaced by "Have an implements-< method". How this is specified at the callsite is a separate question. I can't see any simpler way to do it than writing '<', but if anyone hates overloading enough to invent a syntax they can do it ab nd I won't complain. I'm saying I'd prefer that future to heavyweight contracts. Surface overloading is *not* the important thing about "implements"; having a lightweight way to refer to typeclasses like "Sortable" is. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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
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
Ian Denhardt : > 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. I was serious when I said I meant no insult, and apologize to any who felt insulted. > 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. I will concur with that, too. I would prefer a better solution to the deep problems. Failing that I would prefer a solution syntactically marking the generic formals in the regular signature to a prefix clause. But yes, () to [] would be an improvement in the prefix-clause syntax - more visual distinctness. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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.f...@gmail.com : > 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 :) True dat! Your grasp of this nuance is appreciated. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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] Regarding contracts
Ian Lance Taylor : > > Both classes want to be selected by a field "name". It's annoying that > > I can't declare an interface that says "has a field 'name'" and instead > > have to declare a getter function with no other point besides sliding > > around that restriction. > > I think you are talking about https://golang.org/issue/23796 (which > was not accepted). Thank you, Ian, that explanation is very clarifying. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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] Regarding contracts
Quoting Burak Serdar (2018-10-19 15:13:20)
> Without operator overloading:
>
> type X interface {
>implements <
> }
>
> means that you want a primitive numeric type or a string. So:
This is not quite quite correct; in Eric's proposal, it is possible to
define (for example):
```
// A Version represents a semver-style version number
type Version struct {
Major, Minor, Micro int
}
// We define a custom definition of `<` that checks which version is
// older.
func (v Version) Less(other Version) bool implements < {
switch {
case v.Major < other.Major:
return true
case v.Major > other.Major:
return false
case v.Minor < other.Minor:
return true
case v.Minor > other.Minor:
return false
default:
return v.Micro < other.Micro
}
}
```
..and then use `<` to compare Versions. By contrast, your proposal does
not make it possible to define custom notions of `<` on user defined
types.
> Another thing that motivated me to start this thread in the first
> place was imagining myself sitting late at night trying to figure out
> how to convert a huge chunk of code to a generic type, and reading
> through to figure out exactly what the contract is. With the "like"
> syntax, I could simply add "like X" to my arguments, and be done with
> it. With interfaces containing "implements", I have to write those
> interfaces and figure out exactly what I need.
With interfaces using implements, you can start off just specifying no
constraints on your generic parameters, and then follow the type errors
until you've added all of the necessary methods.
While pinning down exactly what the contract needs to be is a bit of
extra up-front work, I think it is important to keep these contracts
clear; one of my biggest concerns with the draft design is that I do not
believe it encourages thinking about intent.
> With contracts, I imagine someone would come up with a tool to build
> that from the source if it comes to that.
This could also be built for the interface version; just see what
methods are called and put them in an interface that the parameter must
implement.
Quoting Eric S. Raymond (2018-10-19 16:03:02)
> Both classes want to be selected by a field "name". It's annoying that
> I can't declare an interface that says "has a field 'name'" and instead
> have to declare a getter function with no other point besides sliding
> around that restriction.
>
> But precisely because this could easily be patched into interfaces,
> I think it's not much of an argument for your plan.
To spell out how this would for anyone who doesn't immediately see the
design, you could e.g. extend interfaces to be able to have fields like
so:
type HasName interface {
Name string
}
To implement this, a type would have to have a field Name with the type
string.
I am neutral-to-against doing this, as normally when abstracting over
something, it is a behavior, not a field. But if being able to specify
"must have this field," is deemed necessary, I agree this is the way to
do it.
--
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] Regarding contracts
Quoting Ian Denhardt (2018-10-19 16:29:07) > > Quoting Burak Serdar (2018-10-19 15:13:20) > > Without operator overloading: > > Realized I missed this right after hitting send. Yes, without operator overloading you're restricted to built-in types that already support the operator. The original motivation for Eric's proposal was as a way to do operator overloading; I don't see that it achieves anything without that. -- 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 modules and replace
I have a simple demo application that wants to use a package that is on my
local file system.
The code for the package is in /Users/Mark/foo/bar.
This directory contains the file bar.go which contains:
package bar
import "fmt"
func Hello() {
fmt.Println("Hello from bar!")
}
It also contains the file go.mod which just contains:
module bar
The demo application in another directory imports this as "foo/bar" in the
file main.go.
It has a go.mod file that contains the following:
module demo
replace foo/bar => /Users/Mark/foo/bar
When I enter "go run main.go" in the directory of the demo code I get
build demo: cannot find module for path foo/bar
Is there something wrong with my use of the "replace" directive?
None of this code is under the directory pointed to by GOPATH because I'm
trying to use Go modules for everything in this demo.
--
R. Mark Volkmann
Object Computing, Inc.
--
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] Regarding contracts
Ian Denhardt :
> Quoting Eric S. Raymond (2018-10-19 16:03:02)
>
> > Both classes want to be selected by a field "name". It's annoying that
> > I can't declare an interface that says "has a field 'name'" and instead
> > have to declare a getter function with no other point besides sliding
> > around that restriction.
> >
> > But precisely because this could easily be patched into interfaces,
> > I think it's not much of an argument for your plan.
>
> To spell out how this would for anyone who doesn't immediately see the
> design, you could e.g. extend interfaces to be able to have fields like
> so:
>
> type HasName interface {
> Name string
> }
I think it could be simpler than that. The Name part isn't necessary;
anything that isn't a fieldname should be syntactically
distinguishable.
> I am neutral-to-against doing this, as normally when abstracting over
> something, it is a behavior, not a field. But if being able to specify
> "must have this field," is deemed necessary, I agree this is the way to
> do it.
Quite. Alas, ianlancetaylor's explanation of why this feature was rejected
is sufficient.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
--
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] Avoiding overloading
Quoting Eric S. Raymond (2018-10-19 16:15:25)
> Ian Denhardt :
> > What would code making use of a `Sortable` type look like? If you can't
> > actually use "implements <" to overload `<`, it's not clear to me what
> > it would actually do?
>
> Be available to a Sort function. That is, the requirement "Have a Less()"
> would be replaced by "Have an implements-< method".
>
> How this is specified at the callsite is a separate question. I can't
> see any simpler way to do it than writing '<', but if anyone hates
> overloading enough to invent a syntax they can do it ab nd
> I won't complain.
>
> I'm saying I'd prefer that future to heavyweight contracts. Surface
> overloading is *not* the important thing about "implements"; having a
> lightweight way to refer to typeclasses like "Sortable" is.
Ah, so are you just suggesting you'd be able to do (e.g.):
func SortSlice(type T implements <)(slice []T) {
// ...
}
..but not actually be able to redefine `<` for a user-defined type?
--
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] Regarding contracts
On Fri, Oct 19, 2018 at 1:09 PM Ian Denhardt wrote:
>
> Quoting Burak Serdar (2018-10-19 14:09:46)
>
> > It is useful in a linked list. You can instantiate a linked list
> > template in a package, and use that concrete type in another package
> > without access to the internals of the linked list.
>
> Can you provide an example of what some code using this would look like?
> The discussion in the abstract just isn't sticking to my brain...
I've been thinking about this for the last couple of hours, and I
have to admit, I got really close to giving up. Maybe a linked
list is not the best example to illustrate this. Anyway
You would normally implement a linked list like this using parameterized types:
package linkedlist
type Node(type T) struct {
next *Node(T)
Stuff T
}
type LinkedList(type T) struct {
head *Node(T)
}
func (l *LinkedList(T)) Add(n *Node(T)) {
n.next=nil
if l.head==nil {
l.head=n
} else {
l.head.next=n
}
}
func (l LinkedList(T)) Itr(f func(*Node(T))) {
for node:=l.head;node!=nil;node=node.next {
f(node)
}
}
Then use this as:
var myList linkedlist.LinkedList(int)
However, using the "like" keyword, the following should also
be possible, which I think is more interesting than the above. I
needed something like this more than once during my Java days:
(this is different from the linkedlist I had earlier in the thread)
package linkedlist
// Define Node as a template that should satisfy the given struct contract
type Node like struct {
next *Node
}
// LinkedList is a parameterized type, it will use nodes that look like a Node
type LinkedList(type T like(Node)) struct {
head *T
}
// Do we need LinkedList(T)? Maybe not..
func (l *LinkedList) Add(n *Node) {
n.next=nil
if l.head==nil {
l.head=n
} else {
l.head.next=n
}
}
func (l LinkedList) Itr(f func(n *Node)) {
for node:=l.head;node!=nil;node=node.next {
f(node)
}
}
package mypkg
type MyNode linkedList.Node {
next *MyNode
Stuff DataType
}
func f() {
var myList linkedlist.LinkedList(MyNode)
myList.Add(&MyNode{})
}
Let me know if this makes sense. There is still a lot that needs
to be figured out, and I wouldn't be surprised if the idea
collapses completely.
--
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] Avoiding overloading
It seems to me that what you are proposing with “implements” is not really a replacement for contracts. It would do something that contracts don’t (unify operators and methods), and it wouldn’t do nearly all of what contracts do (clearly define what is expected of type parameters across a wide range of possible operations). As I understand it, the most important function of contracts is to produce sensible error messages (as opposed to the ones that C++ templates have become infamous for). If it weren’t for that, we could just leave type parameters unconstrained, and let the generic function’s body be its own contract. If the function uses <, the types passed to it must support <… Andy > On Oct 19, 2018, at 1:15 PM, Eric S. Raymond wrote: > > Ian Denhardt : >> What would code making use of a `Sortable` type look like? If you can't >> actually use "implements <" to overload `<`, it's not clear to me what >> it would actually do? > > Be available to a Sort function. That is, the requirement "Have a Less()" > would be replaced by "Have an implements-< method". > > How this is specified at the callsite is a separate question. I can't > see any simpler way to do it than writing '<', but if anyone hates > overloading enough to invent a syntax they can do it ab nd > I won't complain. > > I'm saying I'd prefer that future to heavyweight contracts. Surface > overloading is *not* the important thing about "implements"; having a > lightweight way to refer to typeclasses like "Sortable" is. > -- > http://www.catb.org/~esr/";>Eric S. Raymond > > My work is funded by the Internet Civil Engineering Institute: > https://icei.org > Please visit their site and donate: the civilization you save might be your > own. > > > -- > 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] relaxing type conversions: an "almost possible" idea with Go generics
As I said, I don't really understand why we disagree here - or what we are
even disagreeing about. So let me make my claim as precise as possible, in
the hope that it at least helps me understand which particular part you are
disagreeing with. I claim:
a) w.l.o.g. we can ignore operators (including
index-expressions/range/select/…) for now, with the understanding that any
program using operators on a type-parameter to a generic function can be
transformed into an equivalent program using methods instead. In practice
this is a bit hairy and as discussed ad nausea the obvious
interface-definitions are not equivalent to the operators (given that they
allow different sets of types), but for the semantic of a specific program
that doesn't matter.
b) Any program using functions with type-parameters can be transformed into
an equivalent program without such functions. The simplest way to do that
transformation is to replace a generic function
func F(type A, R someContract) (a A) R { … }
by (assuming A, R are not used in the package - otherwise rename)
type A = interface { /* methods that someContract requires of A */ }
type R = interface { /* methods that someContract requires of R */ }
func F(a A) R { … }
and by replacing any concrete call
var a CA
var r CR = F(CA, CR)(a)
with
var a CA
var r CR = F(a).(CR)
(and similarly for passing around a fully instantiated version of F)
c) Given a function
func F(a A) R { … }
with A, R interface types and concrete types CA, CR implementing A and R
respectively and assuming every return statement of F can be proven to
return a value of dynamic type CR, we can create a devirtualized version of
F with the signature
func CF(CA) CR
such that for any a, the expression `F(a).(CR)` is equivalent to `CF(a)`
and the expression `F(a)` is equivalent to `R(CF(a))`.
(and similarly for the func value CF when passing it around)
d) Any replacement resulting from the transformation in b) fulfills the
requirement for c) - that is, the type-parameters get turned into
interface-types and it is provable that any return statement has a
consistent static (and hence dynamic) type CR. This is guaranteed by the
type-checker for generic functions.
e) Thus, following the transformation for b) with the transformation for c)
(restricted to the image of b) is equivalent to full template-style
expansion of all generic functions for all possible sets of static types
they are instantiated with in a given program.
Now, to me, all of a) to e) seem fairly clear. There are bits and pieces
that need to be expanded to work around details of scoping and naming and
everything and a full formal proof is hard, given a lack of a formal type
system for Go. But overall, this seems fair to me. If there is any specific
step you disagree with, that would be helpful to understand why we can't
agree.
Now, with that, we'd have a reduction proof that generics can't actually
perform better than the equivalent program using interfaces. The algorithm
to determine if devirtualization is possible (in c) is equivalent to the
type-checker of generic functions. And an algorithm that, given a list of
generic functions and a list of instantiations and calls to that function,
decides which of these should get a specialized version generated, can
*also* take a list of candidate-functions for devirtualization and calls to
those functions and decide which of these functions get devirtualized.
Note, that I'm not saying *any* function using interfaces can be
devirtualized - for my claim, it's only necessary that every function in
the image of transformation b) can be devirtualized. This is why I'm so
confused by your examples - you keep constructing functions with interface
arguments that are not in the image of b), saying that they can't be
devirtualized or that the question of whether they can is undecidable. But
that doesn't actually matter. Worst case, we have to be able to determine
whether a function taking interfaces is in the image of b), which I think
is pretty easy - we basically only need to determine whether, for any
interface-type returned, the static type in the return statement is
consistent (for arguments, we can get around that by renaming if need be).
However, I'm also saying that if we use this view and instead of
implementing a heuristic for "are parametric functions compiled
instantiated or generic" we view these steps separately and first implement
generics completely via virtual calls (interfaces) and then implement a
heuristic for devirtualization, we get a higher payoff. Because in practice
there *will* be some function that would benefit from that heuristic that
are *not* parametric functions. A good example is `fmt.Fprint*`, which
would definitely be considered a candidate for devirtualization, as it
*could* be in the image of b). i.e. by doing the two-step thing, we
essentially answer the question of "when to use contracts and when to use
interfaces": `func Fprint(io.Reader, ...interface{})` is equivalent
se
Re: [go-nuts] Go modules and replace
On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann
wrote:
> I have a simple demo application that wants to use a package that is on my
> local file system.
> The code for the package is in /Users/Mark/foo/bar.
> This directory contains the file bar.go which contains:
>
> package bar
> import "fmt"
> func Hello() {
> fmt.Println("Hello from bar!")
> }
>
> It also contains the file go.mod which just contains:
>
> module bar
>
> The demo application in another directory imports this as "foo/bar" in
> the file main.go.
> It has a go.mod file that contains the following:
>
> module demo
> replace foo/bar => /Users/Mark/foo/bar
>
> When I enter "go run main.go" in the directory of the demo code I get
> build demo: cannot find module for path foo/bar
>
> Is there something wrong with my use of the "replace" directive?
>
Base in this:
https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive
my understanding is that the path you are replacing has to first be
identified as a locatable import path, as opposed to being able to define
the location of a previously invalid path.
If your top level module is called "demo" and it contains a nested packed
"bar", then in the go.mod I would assume it to be called "demo/bar". If you
forget about it actually currently existing under the "demo" location on
disk, with the absence of GOPATH or a fully qualified vcs import path, how
else would the module system find "bar" if not relative to "demo"?
I'm still learning about Go modules so I could be totally wrong.
> None of this code is under the directory pointed to by GOPATH because I'm
> trying to use Go modules for everything in this demo.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> --
> 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] Go modules and replace
> On Oct 19, 2018, at 4:48 PM, Justin Israel wrote:
>
>
>
>> On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann
>> wrote:
>> I have a simple demo application that wants to use a package that is on my
>> local file system.
>> The code for the package is in /Users/Mark/foo/bar.
>> This directory contains the file bar.go which contains:
>>
>> package bar
>> import "fmt"
>> func Hello() {
>> fmt.Println("Hello from bar!")
>> }
>>
>> It also contains the file go.mod which just contains:
>>
>> module bar
>>
>> The demo application in another directory imports this as "foo/bar" in the
>> file main.go.
>> It has a go.mod file that contains the following:
>>
>> module demo
>> replace foo/bar => /Users/Mark/foo/bar
>>
>> When I enter "go run main.go" in the directory of the demo code I get
>> build demo: cannot find module for path foo/bar
>>
>> Is there something wrong with my use of the "replace" directive?
>
>
> Base in this:
> https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive
>
> my understanding is that the path you are replacing has to first be
> identified as a locatable import path, as opposed to being able to define the
> location of a previously invalid path.
What is a “locatable import path”?
> If your top level module is called "demo" and it contains a nested packed
> "bar",
bar is not a nested package. It’s in a completely different directory structure
from the demo app.
> then in the go.mod I would assume it to be called "demo/bar". If you forget
> about it actually currently existing under the "demo" location on disk, with
> the absence of GOPATH or a fully qualified vcs import path, how else would
> the module system find "bar" if not relative to "demo"?
That’s what I thought the “replace” directive could do. I supplied the full
path there.
> I'm still learning about Go modules so I could be totally wrong.
>>
>> None of this code is under the directory pointed to by GOPATH because I'm
>> trying to use Go modules for everything in this demo.
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>> --
>> 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] Go modules and replace
On Sat, Oct 20, 2018, 11:34 AM Mark Volkmann
wrote:
>
> On Oct 19, 2018, at 4:48 PM, Justin Israel wrote:
>
>
>
> On Sat, Oct 20, 2018, 9:42 AM Mark Volkmann
> wrote:
>
>> I have a simple demo application that wants to use a package that is on
>> my local file system.
>> The code for the package is in /Users/Mark/foo/bar.
>> This directory contains the file bar.go which contains:
>>
>> package bar
>> import "fmt"
>> func Hello() {
>> fmt.Println("Hello from bar!")
>> }
>>
>> It also contains the file go.mod which just contains:
>>
>> module bar
>>
>> The demo application in another directory imports this as "foo/bar" in
>> the file main.go.
>> It has a go.mod file that contains the following:
>>
>> module demo
>> replace foo/bar => /Users/Mark/foo/bar
>>
>> When I enter "go run main.go" in the directory of the demo code I get
>> build demo: cannot find module for path foo/bar
>>
>> Is there something wrong with my use of the "replace" directive?
>>
>
> Base in this:
>
> https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive
>
> my understanding is that the path you are replacing has to first be
> identified as a locatable import path, as opposed to being able to define
> the location of a previously invalid path.
>
>
> What is a “locatable import path”?
>
What I mean is an import path that the Go tool could locate. If you are
outside a GOPATH then that would mean either a vcs pattern, something
relative to the module, or something in the module cache (assumptions so
far).
> If your top level module is called "demo" and it contains a nested packed
> "bar",
>
>
> bar is not a nested package. It’s in a completely different directory
> structure from the demo app.
>
So then it's even more to my point, where on its own the go tool would have
no idea where to find "foo/bar"
> then in the go.mod I would assume it to be called "demo/bar". If you
> forget about it actually currently existing under the "demo" location on
> disk, with the absence of GOPATH or a fully qualified vcs import path, how
> else would the module system find "bar" if not relative to "demo"?
>
>
> That’s what I thought the “replace” directive could do. I supplied the
> full path there.
>
And that's the part where I am under the impression that the Go tool first
wants to know where it would find "foo/bar" before it will replace it with
another location. It's not a vcs and it's not relative to the module you
are building.
> I'm still learning about Go modules so I could be totally wrong.
>
>>
>> None of this code is under the directory pointed to by GOPATH because I'm
>> trying to use Go modules for everything in this demo.
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>> --
>> 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] Go modules and replace
Hi Mark, When importing a module package, the first element in the path must contain a ".". Hence "foo" is invalid. Here is a working example: $ cd $HOME $ mkdir bar $ cd bar $ go mod init example.com/bar go: creating new go.mod: module example.com/bar $ cat/root/bar $ go run . Hello from bar! On Fri, 19 Oct 2018 at 21:42, Mark Volkmann wrote: > > I have a simple demo application that wants to use a package that is on my > local file system. > The code for the package is in /Users/Mark/foo/bar. > This directory contains the file bar.go which contains: > > package bar > import "fmt" > func Hello() { > fmt.Println("Hello from bar!") > } > > It also contains the file go.mod which just contains: > > module bar > > The demo application in another directory imports this as "foo/bar" in the > file main.go. > It has a go.mod file that contains the following: > > module demo > replace foo/bar => /Users/Mark/foo/bar > > When I enter "go run main.go" in the directory of the demo code I get > build demo: cannot find module for path foo/bar > > Is there something wrong with my use of the "replace" directive? > > None of this code is under the directory pointed to by GOPATH because I'm > trying to use Go modules for everything in this demo. > > -- > R. Mark Volkmann > Object Computing, Inc. > > -- > 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] Go modules and replace
Thank you so much! I actually got it to work without having a dot in the first part of the import path. It seems the only thing I was missing was this line in mod.go for the demo code: require foo/bar v0.0.0 I just had the replace directive line without a corresponding require directive. On Fri, Oct 19, 2018 at 6:13 PM Paul Jolly wrote: > Hi Mark, > > When importing a module package, the first element in the path must > contain a ".". Hence "foo" is invalid. Here is a working example: > > $ cd $HOME > $ mkdir bar > $ cd bar > $ go mod init example.com/bar > go: creating new go.mod: module example.com/bar > $ catpackage bar > import "fmt" > func Hello() { > fmt.Println("Hello from bar!") > } > EOD > $ cd $HOME > $ mkdir foo > $ cd foo > $ go mod init example.com/foo > go: creating new go.mod: module example.com/foo > $ cat package main > > import "example.com/bar" > > func main() { > bar.Hello() > } > EOD > $ go mod edit -require=example.com/bar@v0.0.0 -replace= > example.com/bar=$HOME/bar > $ cat go.mod > module example.com/foo > > require example.com/bar v0.0.0 > > replace example.com/bar => /root/bar > $ go run . > Hello from bar! > On Fri, 19 Oct 2018 at 21:42, Mark Volkmann > wrote: > > > > I have a simple demo application that wants to use a package that is on > my local file system. > > The code for the package is in /Users/Mark/foo/bar. > > This directory contains the file bar.go which contains: > > > > package bar > > import "fmt" > > func Hello() { > > fmt.Println("Hello from bar!") > > } > > > > It also contains the file go.mod which just contains: > > > > module bar > > > > The demo application in another directory imports this as "foo/bar" in > the file main.go. > > It has a go.mod file that contains the following: > > > > module demo > > replace foo/bar => /Users/Mark/foo/bar > > > > When I enter "go run main.go" in the directory of the demo code I get > > build demo: cannot find module for path foo/bar > > > > Is there something wrong with my use of the "replace" directive? > > > > None of this code is under the directory pointed to by GOPATH because > I'm trying to use Go modules for everything in this demo. > > > > -- > > R. Mark Volkmann > > Object Computing, Inc. > > > > -- > > 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. > -- R. Mark Volkmann Object Computing, Inc. -- 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 modules and replace
I see though that "go mode edit" really wants there to be a dot in the first part of the import path. Where can I read about that requirement? On Fri, Oct 19, 2018 at 6:30 PM Mark Volkmann wrote: > Thank you so much! I actually got it to work without having a dot in the > first part of the import path. > It seems the only thing I was missing was this line in mod.go for the demo > code: > require foo/bar v0.0.0 > I just had the replace directive line without a corresponding require > directive. > > On Fri, Oct 19, 2018 at 6:13 PM Paul Jolly wrote: > >> Hi Mark, >> >> When importing a module package, the first element in the path must >> contain a ".". Hence "foo" is invalid. Here is a working example: >> >> $ cd $HOME >> $ mkdir bar >> $ cd bar >> $ go mod init example.com/bar >> go: creating new go.mod: module example.com/bar >> $ cat> package bar >> import "fmt" >> func Hello() { >> fmt.Println("Hello from bar!") >> } >> EOD >> $ cd $HOME >> $ mkdir foo >> $ cd foo >> $ go mod init example.com/foo >> go: creating new go.mod: module example.com/foo >> $ cat > package main >> >> import "example.com/bar" >> >> func main() { >> bar.Hello() >> } >> EOD >> $ go mod edit -require=example.com/bar@v0.0.0 -replace= >> example.com/bar=$HOME/bar >> $ cat go.mod >> module example.com/foo >> >> require example.com/bar v0.0.0 >> >> replace example.com/bar => /root/bar >> $ go run . >> Hello from bar! >> On Fri, 19 Oct 2018 at 21:42, Mark Volkmann >> wrote: >> > >> > I have a simple demo application that wants to use a package that is on >> my local file system. >> > The code for the package is in /Users/Mark/foo/bar. >> > This directory contains the file bar.go which contains: >> > >> > package bar >> > import "fmt" >> > func Hello() { >> > fmt.Println("Hello from bar!") >> > } >> > >> > It also contains the file go.mod which just contains: >> > >> > module bar >> > >> > The demo application in another directory imports this as "foo/bar" in >> the file main.go. >> > It has a go.mod file that contains the following: >> > >> > module demo >> > replace foo/bar => /Users/Mark/foo/bar >> > >> > When I enter "go run main.go" in the directory of the demo code I get >> > build demo: cannot find module for path foo/bar >> > >> > Is there something wrong with my use of the "replace" directive? >> > >> > None of this code is under the directory pointed to by GOPATH because >> I'm trying to use Go modules for everything in this demo. >> > >> > -- >> > R. Mark Volkmann >> > Object Computing, Inc. >> > >> > -- >> > 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. >> > > > -- > R. Mark Volkmann > Object Computing, Inc. > -- R. Mark Volkmann Object Computing, Inc. -- 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 modules and replace
Actually, now that I think about it, this restriction was relaxed. So the dot in the first part of the path is not a requirement. It appears however that go mod edit has partially regressed in this respect. Please can you raise an issue? That way we can have the behaviour confirmed one way or the other. Thanks On Sat, 20 Oct 2018 at 00:44, Mark Volkmann wrote: > > I see though that "go mode edit" really wants there to be a dot in the first > part of the import path. > Where can I read about that requirement? > > On Fri, Oct 19, 2018 at 6:30 PM Mark Volkmann > wrote: >> >> Thank you so much! I actually got it to work without having a dot in the >> first part of the import path. >> It seems the only thing I was missing was this line in mod.go for the demo >> code: >> require foo/bar v0.0.0 >> I just had the replace directive line without a corresponding require >> directive. >> >> On Fri, Oct 19, 2018 at 6:13 PM Paul Jolly wrote: >>> >>> Hi Mark, >>> >>> When importing a module package, the first element in the path must >>> contain a ".". Hence "foo" is invalid. Here is a working example: >>> >>> $ cd $HOME >>> $ mkdir bar >>> $ cd bar >>> $ go mod init example.com/bar >>> go: creating new go.mod: module example.com/bar >>> $ cat>> package bar >>> import "fmt" >>> func Hello() { >>> fmt.Println("Hello from bar!") >>> } >>> EOD >>> $ cd $HOME >>> $ mkdir foo >>> $ cd foo >>> $ go mod init example.com/foo >>> go: creating new go.mod: module example.com/foo >>> $ cat >> package main >>> >>> import "example.com/bar" >>> >>> func main() { >>> bar.Hello() >>> } >>> EOD >>> $ go mod edit -require=example.com/bar@v0.0.0 >>> -replace=example.com/bar=$HOME/bar >>> $ cat go.mod >>> module example.com/foo >>> >>> require example.com/bar v0.0.0 >>> >>> replace example.com/bar => /root/bar >>> $ go run . >>> Hello from bar! >>> On Fri, 19 Oct 2018 at 21:42, Mark Volkmann >>> wrote: >>> > >>> > I have a simple demo application that wants to use a package that is on >>> > my local file system. >>> > The code for the package is in /Users/Mark/foo/bar. >>> > This directory contains the file bar.go which contains: >>> > >>> > package bar >>> > import "fmt" >>> > func Hello() { >>> > fmt.Println("Hello from bar!") >>> > } >>> > >>> > It also contains the file go.mod which just contains: >>> > >>> > module bar >>> > >>> > The demo application in another directory imports this as "foo/bar" in >>> > the file main.go. >>> > It has a go.mod file that contains the following: >>> > >>> > module demo >>> > replace foo/bar => /Users/Mark/foo/bar >>> > >>> > When I enter "go run main.go" in the directory of the demo code I get >>> > build demo: cannot find module for path foo/bar >>> > >>> > Is there something wrong with my use of the "replace" directive? >>> > >>> > None of this code is under the directory pointed to by GOPATH because I'm >>> > trying to use Go modules for everything in this demo. >>> > >>> > -- >>> > R. Mark Volkmann >>> > Object Computing, Inc. >>> > >>> > -- >>> > 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. >> >> >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. > > > > -- > R. Mark Volkmann > Object Computing, Inc. -- 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 modules and replace
Hi all, See some related discussion here regarding dots in import paths and modules: https://github.com/golang/go/issues/27503 including this comment from bcmills: "Dotless paths in general are reserved for the standard library; go get has (to my knowledge) never worked with them, but go get is also the main entry point for working with versioned modules." Best, thepudds On Friday, October 19, 2018 at 7:59:58 PM UTC-4, Paul Jolly wrote: > > Actually, now that I think about it, this restriction was relaxed. So > the dot in the first part of the path is not a requirement. > > It appears however that go mod edit has partially regressed in this > respect. > > Please can you raise an issue? That way we can have the behaviour > confirmed one way or the other. > > Thanks > On Sat, 20 Oct 2018 at 00:44, Mark Volkmann > wrote: > > > > I see though that "go mode edit" really wants there to be a dot in the > first part of the import path. > > Where can I read about that requirement? > > > > On Fri, Oct 19, 2018 at 6:30 PM Mark Volkmann > wrote: > >> > >> Thank you so much! I actually got it to work without having a dot in > the first part of the import path. > >> It seems the only thing I was missing was this line in mod.go for the > demo code: > >> require foo/bar v0.0.0 > >> I just had the replace directive line without a corresponding require > directive. > >> > >> On Fri, Oct 19, 2018 at 6:13 PM Paul Jolly > wrote: > >>> > >>> Hi Mark, > >>> > >>> When importing a module package, the first element in the path must > >>> contain a ".". Hence "foo" is invalid. Here is a working example: > >>> > >>> $ cd $HOME > >>> $ mkdir bar > >>> $ cd bar > >>> $ go mod init example.com/bar > >>> go: creating new go.mod: module example.com/bar > >>> $ cat>>> package bar > >>> import "fmt" > >>> func Hello() { > >>> fmt.Println("Hello from bar!") > >>> } > >>> EOD > >>> $ cd $HOME > >>> $ mkdir foo > >>> $ cd foo > >>> $ go mod init example.com/foo > >>> go: creating new go.mod: module example.com/foo > >>> $ cat >>> package main > >>> > >>> import "example.com/bar" > >>> > >>> func main() { > >>> bar.Hello() > >>> } > >>> EOD > >>> $ go mod edit -require=example.com/bar@v0.0.0 -replace= > example.com/bar=$HOME/bar > >>> $ cat go.mod > >>> module example.com/foo > >>> > >>> require example.com/bar v0.0.0 > >>> > >>> replace example.com/bar => /root/bar > >>> $ go run . > >>> Hello from bar! > >>> On Fri, 19 Oct 2018 at 21:42, Mark Volkmann > wrote: > >>> > > >>> > I have a simple demo application that wants to use a package that is > on my local file system. > >>> > The code for the package is in /Users/Mark/foo/bar. > >>> > This directory contains the file bar.go which contains: > >>> > > >>> > package bar > >>> > import "fmt" > >>> > func Hello() { > >>> > fmt.Println("Hello from bar!") > >>> > } > >>> > > >>> > It also contains the file go.mod which just contains: > >>> > > >>> > module bar > >>> > > >>> > The demo application in another directory imports this as "foo/bar" > in the file main.go. > >>> > It has a go.mod file that contains the following: > >>> > > >>> > module demo > >>> > replace foo/bar => /Users/Mark/foo/bar > >>> > > >>> > When I enter "go run main.go" in the directory of the demo code I > get > >>> > build demo: cannot find module for path foo/bar > >>> > > >>> > Is there something wrong with my use of the "replace" directive? > >>> > > >>> > None of this code is under the directory pointed to by GOPATH > because I'm trying to use Go modules for everything in this demo. > >>> > > >>> > -- > >>> > R. Mark Volkmann > >>> > Object Computing, Inc. > >>> > > >>> > -- > >>> > 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. > >> > >> > >> > >> -- > >> R. Mark Volkmann > >> Object Computing, Inc. > > > > > > > > -- > > R. Mark Volkmann > > Object Computing, Inc. > -- 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: Safe to treat time.Local != time.LoadLocation("your current timezone")?
Tamas, that's checking if the offset at a particular instant was the same as the local zone - what OP cares about is that the caller is not using literally "time.Local" in their code. I recommend performing source analysis for this - it's a lot easier on you than runtime checks. -- 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] [ANN] pygor: yet another Python to Go regurgitator
Inspired by ESR pytogo (and tired of writing python code), I went the complete opposite way and came up with pygor: https://github.com/raff/pygor pygor is written in Go, using the Python parser and AST from https://github.com/go-python/gpython (so right now it only targets Python 3.4). The origin of this was actually a python implementation that I started a long time ago, using Python ast, but hat didn't go very far because it was hard to do Go things in python. It doesn't generate runnable code, but aspire to generate at least code that passes the smell test of "go fmt" (with the problem that if "go fmt" fails to correctly format the code, the translation fails). pygor also attempt to convert some of the python magic (list and dict comprehension, for example) to Go, again mainly in order to generate formatted code. And it also comes with a concept of "runtime" (automatically imported when needed) to implement a couple of things that are hard to do inline. Enjoy, Raffaele -- 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] Avoiding overloading
Ian Denhardt :
> Quoting Eric S. Raymond (2018-10-19 16:15:25)
> > Ian Denhardt :
> > > What would code making use of a `Sortable` type look like? If you can't
> > > actually use "implements <" to overload `<`, it's not clear to me what
> > > it would actually do?
> >
> > Be available to a Sort function. That is, the requirement "Have a Less()"
> > would be replaced by "Have an implements-< method".
> >
> > How this is specified at the callsite is a separate question. I can't
> > see any simpler way to do it than writing '<', but if anyone hates
> > overloading enough to invent a syntax they can do it ab nd
> > I won't complain.
> >
> > I'm saying I'd prefer that future to heavyweight contracts. Surface
> > overloading is *not* the important thing about "implements"; having a
> > lightweight way to refer to typeclasses like "Sortable" is.
>
> Ah, so are you just suggesting you'd be able to do (e.g.):
>
> func SortSlice(type T implements <)(slice []T) {
> // ...
> }
>
> ..but not actually be able to redefine `<` for a user-defined type?
Something like that. Only why require (type T implements <)? The compiler
can figure out whether T implements < or not and throw an error if it doesn't.
Somewhere inside the generic Sort we'd need a way to say "plug in T's
implementation of < here." That's the callsite I was thinking of. The
simplest and most obvuius way to do that is to bite the operator-overloading
bullet and say "<", but I'm saying I could live with some magic syntax to
avoid that if the allergy to operator overloading is insuperable.
I'm in kind of a weird position here, because I want us to do the simplest
possible thing but recognize that there's allergy to it going around.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
--
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] Avoiding overloading
Andy Balholm : > It seems to me that what you are proposing with “implements” is not really a > replacement for contracts. It would do something that contracts don’t (unify > operators and methods), and it wouldn’t do nearly all of what contracts do > (clearly define what is expected of type parameters across a wide range of > possible operations). I don't understand the the grounds of this objection. Can you pose some cases you think implements couldn't cover? -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. -- 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: [ANN] pygor: yet another Python to Go regurgitator
On Saturday, October 20, 2018 at 12:17:16 AM UTC-4, Raffaele Sena wrote: > > Inspired by ESR pytogo (and tired of writing python code), I went the > complete opposite way and came up with pygor: > Bravo. I am amused by the name - puts me in mind of Discworld Igors. And if my sadly departed friend Terry Pratchett were still alive so I could explain it to him I have no doubt he would be amused too. He would have made a fine upstanding hacker if his life had gone a bit differently. -- 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.
