all: fix broken links and typos

9 files changed, 30 insertions, 23 deletions

diff --git a/README.md b/README.md
index 1d2278a..4240692 100644
--- a/README.md
+++ b/README.md
@@ -200,7 +200,8 @@ to be moved to Active.
 Holding proposals in Incoming until attention can be devoted to them
 (at which they move to Active, and then onward) ensures that
 progress is made moving active proposals out to Accepted or Declined,
-so we avoid [receive livelock](https://www.news.cs.nyu.edu/~jinyang/sp09/readings/mogul96usenix.pdf),
+so we avoid
+[receive livelock](https://pdos.csail.mit.edu/6.828/2020/readings/mogul96usenix.pdf),
 in which accepting new work prevents finishing old work.
 
 #### Active
diff --git a/design/15292-generics.md b/design/15292-generics.md
index db8bae0..9f907e5 100644
--- a/design/15292-generics.md
+++ b/design/15292-generics.md
@@ -1,6 +1,6 @@
 # Proposal: Go should have generics
 
-Author: [Ian Lance Taylor](iant@golang.org)
+Author: [Ian Lance Taylor](mailto:iant@golang.org)
 
 Created: January 2011
 
diff --git a/design/16085-conversions-ignore-tags.md b/design/16085-conversions-ignore-tags.md
index 78840f6..2f2ecd3 100644
--- a/design/16085-conversions-ignore-tags.md
+++ b/design/16085-conversions-ignore-tags.md
@@ -1,6 +1,6 @@
 # Proposal: Ignore tags in struct type conversions
 
-Author: [Robert Griesemer](gri@golang.org)
+Author: [Robert Griesemer](mailto:gri@golang.org)
 
 Created: June 16, 2016
 
diff --git a/design/17280-profile-labels.md b/design/17280-profile-labels.md
index a307995..c1460a8 100644
--- a/design/17280-profile-labels.md
+++ b/design/17280-profile-labels.md
@@ -14,7 +14,7 @@ function in different contexts when looking at profiles.
 
 ## Background
 
-[Proposal #16093](golang.org/issue/16093) proposes to generate profiles in the
+[Proposal #16093](https://golang.org/issue/16093) proposes to generate profiles in the
 gzipped profile proto format that's now the standard format pprof expects
 profiles to be in.
 This format supports adding labels to profile records, but currently the Go
@@ -55,7 +55,7 @@ That's why it's possible to set profile labels but not retrieve them.
 ## API
 
 The following types and functions will be added to the
-[runtime/pprof](golang.org/pkg/runtime/pprof) package.
+[runtime/pprof](https://pkg.go.dev/runtime/pprof) package.
 
     package pprof
 
@@ -149,7 +149,7 @@ New goroutines inherit the labels set on their creator.
 
 There are no compatibility issues with this change. The compressed binary format
 emitted by the profiler already records labels (see
-[proposal 16093](golang.org/issue/16093)), but the profiler does not populate
+[proposal 16093](https://golang.org/issue/16093)), but the profiler does not populate
 them.
 
 ## Implementation
diff --git a/design/19308-number-literals.md b/design/19308-number-literals.md
index ff33655..639fae3 100644
--- a/design/19308-number-literals.md
+++ b/design/19308-number-literals.md
@@ -48,7 +48,8 @@ In C’s lineage,
 [CPL (1966)](http://www.ancientgeek.org.uk/CPL/CPL_Elementary_Programming_Manual.pdf)
 supported decimal, binary, and octal integers.
 Binary and octal were introduced by an underlined 2 or 8 prefix.
-[BCPL (1967)](http://web.eah-jena.de/~kleine/history/languages/Richards-BCPL-ReferenceManual.pdf) removed binary but retained octal,
+[BCPL (1967)](https://softwarepreservation.computerhistory.org/BCPL/project_mac/Richards-BCPL-ReferenceManual.pdf)
+removed binary but retained octal,
 still introduced by an 8 (it’s unclear whether the 8 was underlined or followed by a space).
 [B (1972)](https://www.bell-labs.com/usr/dmr/www/kbman.html)
 introduced the leading zero syntax for octal, as in `0377`.
@@ -128,13 +129,14 @@ other C-numbered languages.
 The exact decimal floating-point literal syntax of C and its successors (`1.23e4`)
 appears to have originated at IBM in
 [Fortran (1956)](https://archive.computerhistory.org/resources/text/Fortran/102649787.05.01.acc.pdf),
-some time after the 
+some time after the
 [1954 draft](https://archive.computerhistory.org/resources/text/Fortran/102679231.05.01.acc.pdf).
 The syntax was not used in
-[Algol 60 (1960)](http://web.eah-jena.de/~kleine/history/languages/Algol60-Naur.pdf)
+[Algol 60 (1960)](https://softwarepreservation.computerhistory.org/ALGOL/report/Algol60_report_CACM_1960_June.pdf)
 but was adopted by [PL/I (1964)](http://www.bitsavers.org/pdf/ibm/npl/320-0908_NPL_Technical_Report_Dec64.pdf)
 and
-[Algol 68 (1968)](http://web.eah-jena.de/~kleine/history/languages/Algol68-Report.pdf),
+[Algol 68 (1968)](https://softwarepreservation.computerhistory.org/ALGOL/report/Algol68_revised_report-AB.pdf)
+(http://web.eah-jena.de/~kleine/history/languages/Algol68-Report.pdf),
 and it spread from those into many other languages.
 
 Hexadecimal floating-point literals appear to have originated in
diff --git a/design/19348-midstack-inlining.md b/design/19348-midstack-inlining.md
index b983998..5a86f47 100644
--- a/design/19348-midstack-inlining.md
+++ b/design/19348-midstack-inlining.md
@@ -465,14 +465,14 @@ Prior to this work, Go had the `-l=4` flag to turn on mid-stack inlining,
 but this mode had issues beyond incomplete stack traces.
 
 For example, before we could run experiments with `-l=4`, we had to fix
-inlining of variadic functions ([CL 33671](golang.org/cl/33671)),
-mark certain cgo functions as uninlineable ([CL 33722](golang.org/cl/33722)),
-and include linknames in export data ([CL 33911](golang.org/cl/33911)).
+inlining of variadic functions ([CL 33671](https://golang.org/cl/33671)),
+mark certain cgo functions as uninlineable ([CL 33722](https://golang.org/cl/33722)),
+and include linknames in export data ([CL 33911](https://golang.org/cl/33911)).
 
 Before we turn on mid-stack inlining, we will have to update uses
 of runtime.Callers in the runtime to use runtime.CallersFrames.
 We will also have to make tests independent of inlining
-(e.g., [CL 37237](golang.org/cl/37237)).
+(e.g., [CL 37237](https://golang.org/cl/37237)).
 
 
 # Preliminary Results
diff --git a/design/24301-versioned-go.md b/design/24301-versioned-go.md
index 7b3ee49..31271c5 100644
--- a/design/24301-versioned-go.md
+++ b/design/24301-versioned-go.md
@@ -94,7 +94,7 @@ I propose to add versioning to Go using the following approach.
    unless the module's documentation clearly states exceptions.
    
 5. Record each module's path and dependency requirements in a
-   [`go.mod` file](XXX) stored in the root of the module's file tree.
+   `go.mod` file stored in the root of the module's file tree.
 
 6. To decide which module versions to use in a given build,
    apply [minimal version selection](https://research.swtch.com/vgo-mvs):
@@ -108,7 +108,7 @@ I propose to add versioning to Go using the following approach.
    Second, it never chooses a module version not listed in some `go.mod` file
    involved in the build: new versions are not incorporated
    simply because they have been published.
-   The second property produces [high-fidelity builds](XXX)
+   The second property produces high-fidelity builds
    and makes sure that upgrades only happen when 
    developers request them, never unexpectedly.
 
diff --git a/design/55022-pgo.md b/design/55022-pgo.md
index 0b1508f..75181fd 100644
--- a/design/55022-pgo.md
+++ b/design/55022-pgo.md
@@ -12,7 +12,7 @@ Previous discussion at https://golang.org/issue/28262.
 
 We propose adding support for profile-guided optimization (PGO) to the Go gc toolchain. PGO will enable the toolchain to perform application- and workload-specific optimizations based on run-time information. Unlike many compiler optimizations, PGO requires user involvement to collect profiles and feed them back into the build process. Hence, we propose a design that centers user experience and ease of deployment and fits naturally into the broader Go build ecosystem.
 
-Our proposed approach uses low-overhead sample-based profiles collected directly from production deployments. This ensures profile data is representative of an application’s real workload, but requires the Go toolchain to cope with stale profiles and profiles from already-optimized binaries. We propose to use the standard and widely-deployed [`runtime/pprof`](https://pkg.go/dev/runtime/pprof) profiler, so users can take advantage of robust tooling for profile collection, processing, and visualization. Pprof is also supported on nearly every operating system, architecture, and deployment environment, unlike hardware-based profiling, which is higher fidelity but generally not available in cloud environments. Users will check in profiles to source control alongside source code, where the `go` tool can transparently supply them to the build and they naturally become part of reproducible builds and the SBOM. Altogether, Go’s vertical integration from build system to toolchain to run-time profiling creates a unique opportunity for a streamlined PGO user experience.
+Our proposed approach uses low-overhead sample-based profiles collected directly from production deployments. This ensures profile data is representative of an application’s real workload, but requires the Go toolchain to cope with stale profiles and profiles from already-optimized binaries. We propose to use the standard and widely-deployed [`runtime/pprof`](https://pkg.go.dev/runtime/pprof) profiler, so users can take advantage of robust tooling for profile collection, processing, and visualization. Pprof is also supported on nearly every operating system, architecture, and deployment environment, unlike hardware-based profiling, which is higher fidelity but generally not available in cloud environments. Users will check in profiles to source control alongside source code, where the `go` tool can transparently supply them to the build and they naturally become part of reproducible builds and the SBOM. Altogether, Go’s vertical integration from build system to toolchain to run-time profiling creates a unique opportunity for a streamlined PGO user experience.
 
 
 ## Background
@@ -102,7 +102,7 @@ We propose to add profile-guided optimization to Go.
 
 ### Profile sources and formats
 
-We will initially support pprof CPU profiles. Developers can collect profiles through usual means, such as the the `runtime/pprof` or `net/http/pprof` packages. The compiler will directly read pprof CPU profiles.
+We will initially support pprof CPU profiles. Developers can collect profiles through usual means, such as the `runtime/pprof` or `net/http/pprof` packages. The compiler will directly read pprof CPU profiles.
 
 In the future we may support more types of profiles (see below).
 
diff --git a/design/go2draft-generics-overview.md b/design/go2draft-generics-overview.md
index cad240d..d6148a2 100644
--- a/design/go2draft-generics-overview.md
+++ b/design/go2draft-generics-overview.md
@@ -50,7 +50,7 @@ flexibility and power with as little added complexity as possible.
 
 _Note on terminology_: Generalization based on type parameters was
 called parametric polymorphism when it was
-[first identified in 1967](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.332.3161&rep=rep1&type=pdf)
+[first identified in 1967](https://reed.cs.depaul.edu/jriely/447/assets/articles/strachey-fundamental-concepts-in-programming-languages.pdf)
 and for decades thereafter in the functional programming community.
 The [GJ proposal](http://homepages.inf.ed.ac.uk/wadler/papers/gj-oopsla/gj-oopsla-letter.pdf),
 which led to adding parametric polymorphism in Java 5, changed the
@@ -393,7 +393,7 @@ We’ll use the `Set`, `Sum`, and `ShortestPath` examples above as points of com
 
 ML was the first typed language to incorporate polymorphism.
 
-Christopher Strachey is usually given credit for introducing the term parametric polymorphism in his 1967 survey, "[Fundamental Concepts in Programming Languages](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.332.3161&rep=rep1&type=pdf)."
+Christopher Strachey is usually given credit for introducing the term parametric polymorphism in his 1967 survey, "[Fundamental Concepts in Programming Languages](https://reed.cs.depaul.edu/jriely/447/assets/articles/strachey-fundamental-concepts-in-programming-languages.pdf)."
 
 Robin Milner’s 1978 paper "[A Theory of Type Polymorphism in Programming](https://courses.engr.illinois.edu/cs421/sp2013/project/milner-polymorphism.pdf)" introduced an algorithm to infer the most general types of polymorphic function bodies, instead of forcing the use of concrete types.
 Milner had already implemented his algorithm for the ML language as part of the Edinburgh LCF system.
@@ -441,14 +441,18 @@ The more complex graph example is still simple in CLU:
 	    ...
 	end shortestpath
 
-The 1978 paper "[Aspects of Implementing CLU](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.3516&rep=rep1&type=pdf)" discusses the compile-time versus run-time implementations of parameterized generics and details CLU's run-time-only approach.
+The 1978 paper
+"[Aspects of Implementing CLU](https://csg.csail.mit.edu/pubs/memos/Memo-167/Memo-167.pdf)"
+discusses the compile-time versus run-time implementations of parameterized generics and details CLU's run-time-only approach.
 The "BigArray" function shown earlier is also taken from this paper (translated to Go, of course).
 
 All the ingredients for modern generics are here: syntax for declaring generalized types and functions, syntax for invoking them, a simple constraint syntax, and a well thought-out implementation.
 There was no inference of type parameters.
 The CLU designers found it helpful to see all substitutions made explicitly.
 
-In her 1992 retrospective  "[A History of CLU](http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=F5D7C821199F22C5D30A51F155DB9D23?doi=10.1.1.46.9499&rep=rep1&type=pdf)," Liskov observed, "CLU was way ahead of its time in its solution for parameterized modules.
+In her 1992 retrospective
+"[A History of CLU](https://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-561.pdf),"
+Liskov observed, "CLU was way ahead of its time in its solution for parameterized modules.
 Even today, most languages do not support parametric polymorphism, although there is growing recognition of the need for it."
 
 ### Ada, 1983
@@ -550,7 +554,7 @@ Of course, nothing checked that other templates used only the features of T illu
 In 2003, Stroustrup proposed formalizing this convention as
 [C++ concepts](http://www.stroustrup.com/N1522-concept-criteria.pdf).
 The feature was intended for C++0x (eventually C++11 (2011)) but
-[removed in 2009](http://www.drdobbs.com/cpp/the-c0x-remove-concepts-decision/218600111).
+[removed in 2009](https://jacobfilipp.com/DrDobbs/articles/DDJ/2009/0908/0908bs01/0908bs01.html)
 Concepts were published as a
 [separate ISO standard in 2015](https://www.iso.org/standard/64031.html), shipped in GCC, and were intended for C++17 (2017)
 [but removed in 2016](http://honermann.net/blog/2016/03/06/why-concepts-didnt-make-cxx17/).