Re: [go-nuts] [ANN] Edit - Acme command language

[as . utf8]

Thanks for suggesting the Reader(q0, q1 int64) io.RuneReader. I accidentally 
replied off list. 

I wasn't aware of up to four horsemen being involved. The man pages didn't 
prepare me for this.

-- 
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: Go channels overused and hyped?

[as . utf8]

Author did a range over channel without select, making cancellation 
impossible without closing the channel or the process. However, author 
challenges user to solve cancellation problems with no selection, even 
saying he awaits for the user to accomplish this. So author will stop 
waiting when notified, or call them back, to say it's been done. Because it 
is not possible, we presume author is still blocked waiting on his 
completion signal, or worse, polling to see any completed the impossible.

In practice, the callback needs to live somewhere in memory. The select 
statement not so much; it could have provided cancellation by broadcasting 
through a "done" channel. For one reason or another, the author didn't do 
this and ranged through the channel instead.

On Monday, August 7, 2017 at 11:01:12 PM UTC-7, snmed wrote:
>
> Hi Gophers
>
> I stumbled over a nice and very interesting Blog entry "Go channels are 
> bad and you should feel bad 
> "
>  
> , I would like to hear some opinions about that article
> from seasoned go developers. Because I just used go for a couple of months 
> for my private web projects and rarely get in touch with channels.
>
> By the way, that article is not a rant and the author likes go very much 
> as far as I can conclude from the article.
>
> Cheers snmed
>

-- 
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] Edit - Acme command language

[as . utf8]

I'm sure this has been done already, but I thought I'd share my 
implementation of this here for anyone interested in using structural 
regular expressions in Go. It doesn't cover 100% of what Edit does in Acme, 
but its close enough that I can use the example program 
 as a substitute 
to sed on Windows.

github.com/as/edit

Reference

http://doc.cat-v.org/bell_labs/sam_lang_tutorial/

-- 
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: [Blog] Context should go away for Go 2

[as . utf8]

Threads are the structural and functional loci of execution on some operating 
systems, data stored in a box accessible to each thread makes sense when you 
obey the constraint that the things in that box are to be used for that thread 
exclusively. 

Goroutines are different, they function like threads but have different 
structure. Structurally, they are not intended to preserve state accessible to 
the user. Goroutines are light, and I suspect that the idiom of goroutine local 
storage is incompatible to the design of the language: anonymous loci of flow 
control communicating through channels as conduits. 

If I could wish for an idiom taken from operating systems, TLS/GLS wouldn't be 
my first choice. I see namespaces serving a similar role on Plan9. The ability 
to share a namespace with the child or parent process. Namespaces include the 
environment and allow the caller too configure what resources a process has 
access to upon execution. Such an addition would also violate the unwritten 
rule of anonymous processes, but context is already doing that. The difference 
is that context is based on what is being executed (what function is called) 
and not where (which goroutine). Contexts are like function namespaces. They 
even have a map of arbitrary key-values. 

The exercise is to find a way to make this feel natural to the language, and 
apply such an approach to functions instead of processes, threads, or 
goroutines.

-- 
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] [Blog] Context should go away for Go 2

[as . utf8]

I also dont want to see context everywhere. At the same time, I don't want it 
to be obfuscated in a confusing way. 

ctx is an unfortunate initialism and context.Context package stuttering doesn't 
help. 

I suppose you could stuff a pointer on the stack pointing to a potential 
context and then provide a built-in to access this structure. But that already 
sounds confusing and easy to ignore, and you've added a few bytes of overhead 
to each function call by providing an auxillary argument to every function and 
method.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Generics are overrated.

[as . utf8]

I'm hesitant to accept generics due to the fear of *overloaded operators *being 
the next big deal*. *C# even has *properties (user-defined methods 
dispatched upon an assignment operation)*. 

-- 
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: gitcreepy – get GitHub users' previous email addresses from all their historical commits!

[as . utf8]

This information is actually stored in the git commits themselves. There is 
a zlib'd field that contains the author's name and email address for each 
commit in the repo. A complete transcript for every commit can be 
reconstructed from a git repo in this manner.

On Saturday, July 15, 2017 at 5:58:59 PM UTC-7, nosequeldeebee wrote:
>
> https://github.com/nosequeldeebee/gitcreepy
>
> It's stunning how much personal information you can get from Github users 
> through its developer APIs. In addition to profile information, a list of 
> every email address they've used in historical public commits can be 
> extracted. Many users sign up for Github with their personal email 
> addresses and only obfuscate them after they've made public commits, 
> which imprints them in the public record!
>

-- 
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: Is x/exp/shiny dead?

[as . utf8]

It's not ready for general use, but it certainly isn't dead. I think a lack 
of examples for some of the more-complex widgets is probably where it needs 
the most help, but considering that only one person is working on it the 
result is a very impressive addition to the Go ecosystem. I've not used the 
widgets much, and ended up porting/reimplementing 
 Plan 9's libframe due to my inability to 
understand how to get editable text on the screen. This was over a year 
ago, so things may have changed. I agree with the general consensus, 
standard widgets are the biggest obstacle for exp/shiny, but those require 
effort to be ported, and maybe copying what already exists isn't the best 
approach either.

On Monday, July 31, 2017 at 1:25:02 PM UTC-7, fazal wrote:
>
> It was one of the things I was looking forward to, but I see almost no 
> activity there, which makes me sad. 
>
> Is it because it is mature enough for general use? There is a road-map for 
> widgets but non are complete. I really hope it is not abandoned because Go 
> really needs a GUI library that is idiomatic. 
>
> Regards,
>
>

-- 
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: shiny: get mouse position relative to window

[as . utf8]

I haven't seen this either, the solution depends on what platform you're 
trying to support. 

I have a package that does this, for Win32. If you're using Windows, you 
use the the Rect() or ClientAbs() in my package to get the position of the 
window (or the client area).

https://godoc.org/github.com/as/ms/win


On Saturday, January 14, 2017 at 8:47:17 AM UTC-8, kty...@gmail.com wrote:
>
> How do I get the position for a mouse.Event in shiny using 
> golang.org/x/mobile/event.mouse?
>
> The position returned is the global position on the screen, which changes 
> if I move the window.
> The comments in 
> https://github.com/golang/mobile/blob/master/event/mouse/mouse.go#L18 say 
> it's:
> "// X and Y are the mouse location, in pixels.". It doesn't mention if 
> they are relative to the screen or the window.
>
> How do I get the position relative to the window?
> Or is it an error of the driver (I'm using windows)?
> Neither shiny.Screen nor shiny.Window have methods to get the current 
> position of the window.
>
> Example:
> https://github.com/ktye/maps/blob/master/cmd/map/main.go#L101
>

-- 
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] Deleting the /r/golang subreddit

[as . utf8]

I don't use the site, nor understand how any immediate conflicts of interest 
can manifest based on the CEO's actions that justify removing the subreddit or 
locking it down.

Why not add a community to the official golang.org site and let the subreddit 
die of natural causes? It would be a favorable outcome if Reddit ever 
disappeared in the future to the hand of some other site: no content would need 
to be moved and the language's community posts would be self-contained.

-- 
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] Small complete examples which show the power of Go?

[as . utf8]

It's shorter, but it's harder for me to grasp what it does as easily as the 
first example.

On Wednesday, August 10, 2016 at 2:09:58 AM UTC-7, Anmol Sethi wrote:
>
> You can shorten that by 6 lines 
>
> package main 
>
> import "net/http" 
>
> func main() { 
> http.ListenAndServe(":8080", http.HandlerFunc(func(w 
> http.ResponseWriter, r *http.Request) { 
> w.Write([]byte("Hello World!")) 
> })) 
> } 
>
> A bare bones web server in just 9 lines! 
>
> > On Aug 10, 2016, at 3:53 AM, gary.wi...@victoriaplumb.com  
> wrote: 
> > 
> > Hi, 
> > 
> > I'm giving a talk at work introducing Go and I'm looking for small 
> examples to show Go's potential. For example, the following program 
> demonstrates a bare-bones webserver in 13 lines: 
> > 
> > import ( 
> > 
> > "fmt" 
> > "net/http" 
> > ) 
> >   
> > func home(w http.ResponseWriter, r *http.Request) { 
> > fmt.Fprintf(w, "Hello, world!") 
> > } 
> >   
> > func main() { 
> > http.HandleFunc("/", home) 
> > http.ListenAndServe(":8080", nil) 
> > } 
> > 
> > Has anyone here got any more little snippets like this to show the power 
> and potential of Go? It doesn't have to be in networking, just little a 
> little snippet to make people think "wow, that's cool!". 
> > 
> > Thanks. 
> > 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to golang-nuts...@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: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

I was being facetious. You have the right to opine, but elevating opinions 
to that of proofs doesn't give the discussion any utility. I think you 
should consider the underlying assumptions in some of your points: 

1. A slice is a descriptor of an aggregate
2. A struct can resemble a descriptor of an aggregate.
3. A struct can resemble a slice
4. If a slice can be compared as a struct holding a descriptor, then maps 
can have slices as keys
5. Because it benefits this use case, it is a good feature to add to the 
language

Enumerating the drawbacks of this feature is more useful than trying to 
justify its existence. The language authors omitted this functionality for 
a reason. One of the reasons is that arrays and slices are similar, and 
changing their comparison semantics seemed confusing.  

On Sunday, July 3, 2016 at 11:32:39 AM UTC-7, Chad wrote:
>
> Pardon?
>
> On Sunday, July 3, 2016 at 8:13:30 PM UTC+2, as@gmail.com wrote:
>>
>> Hardcoded proofs should be assigned well-named identifiers. If you ever 
>> have to alter them, you don't want to be rummaging around your lemmas and 
>> corollaries.
>>
>> On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>>>
>>> Ok. That "haha" was merely to show that no animosity was borne. And also 
>>> because you didn't really answer the question as I asked (by quoting the 
>>> spec) which I found funny.
>>>
>>> Alas, I guess we couldn't see eye to eye.
>>>
>>> But chill a little bit. I have given all the hardcoded proofs and people 
>>> have just given me *feelings* about what they thought should be right. 
>>> I think I have the right to disagree.
>>>
>>> Anyway, I can only wish you good continuation. :)
>>>
>>>
>>> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:

 I'm sorry but your attitude is counterproductive to the discussion.
 "haha" what? I told you I see your point, I think I know the specs very 
 well, thank you for the link.
 However, you seem incapable of accepting, despite an number of others 
 saying the contrary, despite, given a reasonable example where even the 
 standard library gets this "wrong" (according to you, according to me it's 
 exactly as it should be).
 You've been explained several times that both point of views hold valid 
 arguments so why do you insist your point of view is the only correct one 
 and everyone else is wrong?
 The authors of the language which have far more experience that me (I 
 can't speak for your experience or others), couldn't get to an agreement 
 on 
 how this should work so they took the best decision, let the user deal 
 with 
 this according to their individual needs.
 I'll stop following this thread / replying as it's pointless to do so 
 at this point.
 Good luck proving everyone else is wrong and you know better.

 On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>
> Ok, Let me help you out haha :)
>
> Here is the definition of a slice. It is not a container.
> https://golang.org/ref/spec#Slice_types
>
> I am not inventing things.
>
> I know what people on this thread said, but that's their misconception.
>
> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:
>>
>> As you pointed out, Printf() should follow the ref spec but that 
>> doesn't happen because some humans don't perceive this accuracy as 
>> necessary or maybe because the way to resonate about slices / arrays is 
>> as 
>> containers for the actual values.
>> Thus we have Printf working as it does (and %p will indeed print the 
>> memory address of the slice type).
>>
>> I would definitely want to be able to compare []int{1, 2, 3} with 
>> ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for 
>> example 
>> purposes but think of them as coming from different sources)
>> Apparently you don't, and that's fine.
>>
>> That's exactly why the compiler only allows comparison with nil, to 
>> force the user to think about that should be compared, not do it by 
>> default 
>> and have potential hidden issues that might be uncovered too late in the 
>> process.
>>
>> On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>>>
>>> In fact, that is somewhat my fault.
>>>
>>> I should ask:
>>>
>>> What is a slice?
>>> What is an array?
>>>
>>> Spoiler: a slice is a reference type in its "wikipedia-ish" 
>>> definition (auto-dereferencing) which is the reason you observe such a 
>>> result in the playground.
>>>
>>> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:

 No. You should not get it from here. You should get the answer from 
 the spec. Let alone the fact that the implementation should ideally 
 follow 
 the spec and not the reverse.

 On Sunday, July 

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

Hardcoded proofs should be assigned well-named identifiers. If you ever 
have to alter them, you don't want to be rummaging around your lemmas and 
corollaries.

On Sunday, July 3, 2016 at 5:32:26 AM UTC-7, Chad wrote:
>
> Ok. That "haha" was merely to show that no animosity was borne. And also 
> because you didn't really answer the question as I asked (by quoting the 
> spec) which I found funny.
>
> Alas, I guess we couldn't see eye to eye.
>
> But chill a little bit. I have given all the hardcoded proofs and people 
> have just given me *feelings* about what they thought should be right. I 
> think I have the right to disagree.
>
> Anyway, I can only wish you good continuation. :)
>
>
> On Sunday, July 3, 2016 at 2:04:47 PM UTC+2, Florin Pățan wrote:
>>
>> I'm sorry but your attitude is counterproductive to the discussion.
>> "haha" what? I told you I see your point, I think I know the specs very 
>> well, thank you for the link.
>> However, you seem incapable of accepting, despite an number of others 
>> saying the contrary, despite, given a reasonable example where even the 
>> standard library gets this "wrong" (according to you, according to me it's 
>> exactly as it should be).
>> You've been explained several times that both point of views hold valid 
>> arguments so why do you insist your point of view is the only correct one 
>> and everyone else is wrong?
>> The authors of the language which have far more experience that me (I 
>> can't speak for your experience or others), couldn't get to an agreement on 
>> how this should work so they took the best decision, let the user deal with 
>> this according to their individual needs.
>> I'll stop following this thread / replying as it's pointless to do so at 
>> this point.
>> Good luck proving everyone else is wrong and you know better.
>>
>> On Sunday, July 3, 2016 at 12:47:12 PM UTC+1, Chad wrote:
>>>
>>> Ok, Let me help you out haha :)
>>>
>>> Here is the definition of a slice. It is not a container.
>>> https://golang.org/ref/spec#Slice_types
>>>
>>> I am not inventing things.
>>>
>>> I know what people on this thread said, but that's their misconception.
>>>
>>> On Sunday, July 3, 2016 at 1:40:46 PM UTC+2, Florin Pățan wrote:

 As you pointed out, Printf() should follow the ref spec but that 
 doesn't happen because some humans don't perceive this accuracy as 
 necessary or maybe because the way to resonate about slices / arrays is as 
 containers for the actual values.
 Thus we have Printf working as it does (and %p will indeed print the 
 memory address of the slice type).

 I would definitely want to be able to compare []int{1, 2, 3} with 
 ([]int{1, 2, 3, 4, 5})[:3] and result in equality (given here for example 
 purposes but think of them as coming from different sources)
 Apparently you don't, and that's fine.

 That's exactly why the compiler only allows comparison with nil, to 
 force the user to think about that should be compared, not do it by 
 default 
 and have potential hidden issues that might be uncovered too late in the 
 process.

 On Sunday, July 3, 2016 at 12:20:17 PM UTC+1, Chad wrote:
>
> In fact, that is somewhat my fault.
>
> I should ask:
>
> What is a slice?
> What is an array?
>
> Spoiler: a slice is a reference type in its "wikipedia-ish" definition 
> (auto-dereferencing) which is the reason you observe such a result in the 
> playground.
>
> On Sunday, July 3, 2016 at 1:12:17 PM UTC+2, Chad wrote:
>>
>> No. You should not get it from here. You should get the answer from 
>> the spec. Let alone the fact that the implementation should ideally 
>> follow 
>> the spec and not the reverse.
>>
>> On Sunday, July 3, 2016 at 1:03:44 PM UTC+2, Florin Pățan wrote:
>>>
>>> If I look at what %v means, print out the values of various types in 
>>> Go, according to https://golang.org/pkg/fmt/ then I believe that 
>>> this holds the answer: https://play.golang.org/p/GiLckoBDxa
>>>
>>> On Sunday, July 3, 2016 at 11:33:01 AM UTC+1, Chad wrote:

 Not for comparison.

 I am just asking what is the value of a slice and what is the value 
 of an array.

 Remember that there is no slice comparison that has been spec'ed so 
 far.

 On Sunday, July 3, 2016 at 12:24:05 PM UTC+2, Florin Pățan wrote:
>
> For []T the value of a slice for the purpose of comparison would 
> be each individual value compared against each-other (ofc maybe 
> comparing 
> the length first as an optimization).
> Same goes for an array.
>
> And again, you are missing the whole point. Both me and you are 
> wrong in each-others points of view.
> Just accept this.
>
> On Sunday, July 3, 2016 at 11:19:48 AM 

Re: [go-nuts] Re: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

Relaxing unformalized behavior makes little sense to me. Explaining why 
equality is inconsistent between slices and arrays is not something I want 
to do either.


On Sunday, July 3, 2016 at 1:40:19 AM UTC-7, Chad wrote:
>
> Rob and Robert actually wrote that this area of the spec needs more work...
> Otherwise, the behaviour of maps, slices and funcs cannot be fully 
> explained.
>
> On Sunday, July 3, 2016 at 7:25:31 AM UTC+2, as@gmail.com wrote:
>>
>> Go does not have reference types. As far as I know, the word was 
>> purposefully removed from the spec to remove the ambiguity surrounding the 
>> word. 
>>
>> https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA
>
>
>
> @Martin
>
> As I've mentioned earlier, one ought to be careful about  false friends 
> from other languages. 
> I am not sure I understand what you mean by:
>
> if the name field is changed after the call
>
>
>

-- 
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: Relaxing rules on slice comparison: would it make sense?

[as . utf8]

Go does not have reference types. As far as I know, the word was purposefully 
removed from the spec to remove the ambiguity surrounding the word.

https://groups.google.com/forum/m/#!topic/golang-dev/926npffb6lA

-- 
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] Fedora and crypto/elliptic.P224

[as . utf8]

If the distribution builders can take it out, what is preventing them from 
adding their own documentation?

On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote:
>
> Yep, that's exactly what I'm saying.
>
>
> https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/
> https://bugzilla.redhat.com/show_bug.cgi?id=1038683
>
> Supposedly patent/legal reasons?
>
>
> On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor  > wrote:
>
>> On Mon, Jun 20, 2016 at 6:59 PM,   
>> wrote:
>> >
>> > Should there be a note in the documentation that this has been removed 
>> by
>> > the Fedora packagers?
>> >
>> > It would help assure developers that they're not insane when they get a
>> > compile error claiming that something that
>> > https://golang.org/pkg/crypto/elliptic says should be there, isn't 
>> there.
>>
>> I'm not sure I understand: are you saying that Fedora removed
>> crypto/elliptic.P224 when they packaged the Go distribution?  Why
>> would they do that?
>>
>> Ian
>>
>
>
>
> -- 
> -Josh
> (502) 209-9704
>

-- 
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] [ANN] Mirror of Go SSA

[as . utf8]

Have you tried to *go get golang.org/x/tools/go/ssa *?

On Wednesday, June 15, 2016 at 10:54:05 AM UTC-7, JW Bell wrote:
>
> >>I have to say that I don't see a big benefit to mirroring a github 
> repo on github itself. 
> There isn't another way to use the ssa package.
>
> On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>>
>> On Tue, Jun 14, 2016 at 7:07 PM,   wrote: 
>> > Mirror of the Go compiler SSA library -  https://github.com/bjwbell/ssa 
>> > The mirror is automatically updated daily. 
>> > 
>> > Any feedback is welcome. I'm unsure on the licensing requirements for 
>> > mirroring. 
>>
>> The license requirements in general are in the LICENSE file.  It's no 
>> different from mirroring than for any other use. 
>>
>> I have to say that I don't see a big benefit to mirroring a github 
>> repo on github itself. 
>>
>> 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: Better sum types for go

[as . utf8]

Thanks!

On Monday, June 13, 2016 at 3:27:51 AM UTC-7, Jesper Louis Andersen wrote:
>
>
> On Mon, Jun 13, 2016 at 1:58 AM,  wrote:
>
>> What research or other literature can you recommend on the topic of type 
>> theory?
>
>
> Benjamin C. Pierce's "Types and Programming Languages", often abbreviated 
> TAPL, is a classic text on type theory. Working from the semanticists 
> favorite toy language, the Lambda-calculus, Pierce proceeds to add 
> different type-theoretic constructs on top of it one at a time to explain 
> their concepts. Don't let the choice of the lambda-calculus fool you. Once 
> you add references into that language it essentially becomes a basis for 
> imperative programming.
>
>
> -- 
> J.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.