Get ebook downloads in full at ebookmeta.

com

TypeScript Handbook TypeScript 4 7 Typescriptlang

Org

https://ebookmeta.com/product/typescript-handbook-
typescript-4-7-typescriptlang-org/

OR CLICK BUTTON

DOWNLOAD NOW

Explore and download more ebook at https://ebookmeta.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

TypeScript Handbook TypeScript 4 8 Typescriptlang Org

https://ebookmeta.com/product/typescript-handbook-
typescript-4-8-typescriptlang-org/

ebookmeta.com

TypeScript Handbook TypeScript 4 8 Typescriptlang Org

https://ebookmeta.com/product/typescript-handbook-
typescript-4-8-typescriptlang-org-2/

ebookmeta.com

Essential TypeScript 4 2nd Edition Adam Freeman

https://ebookmeta.com/product/essential-typescript-4-2nd-edition-adam-
freeman/

ebookmeta.com

Education Policy Research Epistemological and Theoretical

Issues 1st Edition Mainardes

https://ebookmeta.com/product/education-policy-research-
epistemological-and-theoretical-issues-1st-edition-mainardes/

ebookmeta.com
Reconceptualizing Schizophrenia The Phenomenology of
Urhomelessness 1st Edition Edited By Sarah R Kamens

https://ebookmeta.com/product/reconceptualizing-schizophrenia-the-
phenomenology-of-urhomelessness-1st-edition-edited-by-sarah-r-kamens/

ebookmeta.com

The Cambridge Companion to Rabindranath Tagore Cambridge

Companions to Literature Sukanta Chaudhuri (Editor)

https://ebookmeta.com/product/the-cambridge-companion-to-rabindranath-
tagore-cambridge-companions-to-literature-sukanta-chaudhuri-editor/

ebookmeta.com

An Introductory Course to Philosophy of Language Ufuk Azen

Baykent

https://ebookmeta.com/product/an-introductory-course-to-philosophy-of-
language-ufuk-azen-baykent/

ebookmeta.com

The Healing Energy of Your Hands Michael Bradford

https://ebookmeta.com/product/the-healing-energy-of-your-hands-
michael-bradford/

ebookmeta.com

The Dynamics of Right Wing Extremism Within German Society

1st Edition Oliver Decker

https://ebookmeta.com/product/the-dynamics-of-right-wing-extremism-
within-german-society-1st-edition-oliver-decker/

ebookmeta.com
A Clinician's Guide to Statistics in Mental Health S.
Nassir Ghaemi

https://ebookmeta.com/product/a-clinicians-guide-to-statistics-in-
mental-health-s-nassir-ghaemi/

ebookmeta.com
 This copy of the TypeScript handbook was
created on Friday, June 24, 2022 against commit
e538f6 with TypeScript 4.7.
Table of Contents

The TypeScript Handbook Your first step to learn TypeScript

The Basics Step one in learning TypeScript: The basic types.
Everyday Types The language primitives.
Understand how TypeScript uses JavaScript knowledge
Narrowing
to reduce the amount of type syntax in your projects.
More on Functions Learn about how Functions work in TypeScript.
How TypeScript describes the shapes of JavaScript
Object Types
objects.
An overview of the ways in which you can create more
Creating Types from Types
types from existing types.
Generics Types which take parameters
Keyof Type Operator Using the keyof operator in type contexts.
Typeof Type Operator Using the typeof operator in type contexts.
Indexed Access Types Using Type['a'] syntax to access a subset of a type.
Create types which act like if statements in the type
Conditional Types
system.
Mapped Types Generating types by re-using an existing type.
Generating mapping types which change properties via
Template Literal Types
template literal strings.
Classes How classes work in TypeScript
How JavaScript handles communicating across file
Modules
boundaries.
The TypeScript Handbook

About this Handbook

Over 20 years after its introduction to the programming community, JavaScript is now one of the
most widespread cross-platform languages ever created. Starting as a small scripting language for
adding trivial interactivity to webpages, JavaScript has grown to be a language of choice for both
frontend and backend applications of every size. While the size, scope, and complexity of programs
written in JavaScript has grown exponentially, the ability of the JavaScript language to express the
relationships between different units of code has not. Combined with JavaScript's rather peculiar
runtime semantics, this mismatch between language and program complexity has made JavaScript
development a difficult task to manage at scale.

The most common kinds of errors that programmers write can be described as type errors: a
certain kind of value was used where a different kind of value was expected. This could be due to
simple typos, a failure to understand the API surface of a library, incorrect assumptions about
runtime behavior, or other errors. The goal of TypeScript is to be a static typechecker for JavaScript
programs - in other words, a tool that runs before your code runs (static) and ensures that the types
of the program are correct (typechecked).

If you are coming to TypeScript without a JavaScript background, with the intention of TypeScript
being your first language, we recommend you first start reading the documentation on either the
Microsoft Learn JavaScript tutorial or read JavaScript at the Mozilla Web Docs. If you have
experience in other languages, you should be able to pick up JavaScript syntax quite quickly by
reading the handbook.

How is this Handbook Structured

The handbook is split into two sections:

The Handbook

The TypeScript Handbook is intended to be a comprehensive document that explains TypeScript

to everyday programmers. You can read the handbook by going from top to bottom in the left-
hand navigation.

You should expect each chapter or page to provide you with a strong understanding of the given
concepts. The TypeScript Handbook is not a complete language specification, but it is intended to
be a comprehensive guide to all of the language's features and behaviors.
 A reader who completes the walkthrough should be able to:

Read and understand commonly-used TypeScript syntax and patterns

Explain the effects of important compiler options

Correctly predict type system behavior in most cases

In the interests of clarity and brevity, the main content of the Handbook will not explore every
edge case or minutiae of the features being covered. You can find more details on particular
concepts in the reference articles.

Reference Files

The reference section below the handbook in the navigation is built to provide a richer
understanding of how a particular part of TypeScript works. You can read it top-to-bottom, but
each section aims to provide a deeper explanation of a single concept - meaning there is no aim
for continuity.

Non-Goals

The Handbook is also intended to be a concise document that can be comfortably read in a few
hours. Certain topics won't be covered in order to keep things short.

Specifically, the Handbook does not fully introduce core JavaScript basics like functions, classes, and
closures. Where appropriate, we'll include links to background reading that you can use to read up
on those concepts.

The Handbook also isn't intended to be a replacement for a language specification. In some cases,
edge cases or formal descriptions of behavior will be skipped in favor of high-level, easier-to-
understand explanations. Instead, there are separate reference pages that more precisely and
formally describe many aspects of TypeScript's behavior. The reference pages are not intended for
readers unfamiliar with TypeScript, so they may use advanced terminology or reference topics you
haven't read about yet.

Finally, the Handbook won't cover how TypeScript interacts with other tools, except where
necessary. Topics like how to configure TypeScript with webpack, rollup, parcel, react, babel, closure,
lerna, rush, bazel, preact, vue, angular, svelte, jquery, yarn, or npm are out of scope - you can find
these resources elsewhere on the web.

Get Started
Before getting started with The Basics, we recommend reading one of the following introductory
pages. These introductions are intended to highlight key similarities and differences between
TypeScript and your favored programming language, and clear up common misconceptions
specific to those languages.

TypeScript for New Programmers

TypeScript for JavaScript Programmers

TypeScript for OOP Programmers

TypeScript for Functional Programmers

Otherwise, jump to The Basics or grab a copy in Epub or PDF form.

The Basics
Each and every value in JavaScript has a set of behaviors you can observe from running different
operations. That sounds abstract, but as a quick example, consider some operations we might run
on a variable named message .

// Accessing the property 'toLowerCase'

// on 'message' and then calling it
message.toLowerCase();

// Calling 'message'
message();

If we break this down, the first runnable line of code accesses a property called toLowerCase and
then calls it. The second one tries to call message directly.

But assuming we don't know the value of message - and that's pretty common - we can't reliably
say what results we'll get from trying to run any of this code. The behavior of each operation
depends entirely on what value we had in the first place.

Is message callable?

Does it have a property called toLowerCase on it?

If it does, is toLowerCase even callable?

If both of these values are callable, what do they return?

The answers to these questions are usually things we keep in our heads when we write JavaScript,
and we have to hope we got all the details right.

Let's say message was defined in the following way.

const message = "Hello World!";

As you can probably guess, if we try to run message.toLowerCase() , we'll get the same string
only in lower-case.
What about that second line of code? If you're familiar with JavaScript, you'll know this fails with an
exception:

TypeError: message is not a function

It'd be great if we could avoid mistakes like this.

When we run our code, the way that our JavaScript runtime chooses what to do is by figuring out
the type of the value - what sorts of behaviors and capabilities it has. That's part of what that
TypeError is alluding to - it's saying that the string "Hello World!" cannot be called as a
function.

For some values, such as the primitives string and number , we can identify their type at runtime
using the typeof operator. But for other things like functions, there's no corresponding runtime
mechanism to identify their types. For example, consider this function:

function fn(x) {
return x.flip();
}

We can observe by reading the code that this function will only work if given an object with a
callable flip property, but JavaScript doesn't surface this information in a way that we can check
while the code is running. The only way in pure JavaScript to tell what fn does with a particular
value is to call it and see what happens. This kind of behavior makes it hard to predict what code
will do before it runs, which means it's harder to know what your code is going to do while you're
writing it.

Seen in this way, a type is the concept of describing which values can be passed to fn and which
will crash. JavaScript only truly provides dynamic typing - running the code to see what happens.

The alternative is to use a static type system to make predictions about what code is expected
before it runs.

Static type-checking
Think back to that TypeError we got earlier from trying to call a string as a function. Most
people don't like to get any sorts of errors when running their code - those are considered bugs!
And when we write new code, we try our best to avoid introducing new bugs.
If we add just a bit of code, save our file, re-run the code, and immediately see the error, we might
be able to isolate the problem quickly; but that's not always the case. We might not have tested the
feature thoroughly enough, so we might never actually run into a potential error that would be
thrown! Or if we were lucky enough to witness the error, we might have ended up doing large
refactorings and adding a lot of different code that we're forced to dig through.

Ideally, we could have a tool that helps us find these bugs before our code runs. That's what a static
type-checker like TypeScript does. Static types systems describe the shapes and behaviors of what
our values will be when we run our programs. A type-checker like TypeScript uses that information
and tells us when things might be going off the rails.

const message = "hello!";

message();

This
This expression
expression is
is not
not callable.
callable.
Type
Type 'String'
'String' has
has no
no call
call signatures.
signatures.

Running that last sample with TypeScript will give us an error message before we run the code in
the first place.

Non-exception Failures
So far we've been discussing certain things like runtime errors - cases where the JavaScript runtime
tells us that it thinks something is nonsensical. Those cases come up because the ECMAScript
specification has explicit instructions on how the language should behave when it runs into
something unexpected.

For example, the specification says that trying to call something that isn't callable should throw an
error. Maybe that sounds like "obvious behavior", but you could imagine that accessing a property
that doesn't exist on an object should throw an error too. Instead, JavaScript gives us different
behavior and returns the value undefined :

const user = {
name: "Daniel",
age: 26,
};

user.location; // returns undefined

Ultimately, a static type system has to make the call over what code should be flagged as an error in
its system, even if it's "valid" JavaScript that won't immediately throw an error. In TypeScript, the
following code produces an error about location not being defined:

const user = {
name: "Daniel",
age: 26,
};

user.location;

Property
Property 'location'
'location' does
does not
not exist
exist on
on type
type '{
'{ name:
name: string;
string; age:
age: number;
number;
}'. }'.

While sometimes that implies a trade-off in what you can express, the intent is to catch legitimate
bugs in our programs. And TypeScript catches a lot of legitimate bugs.

For example: typos,

const announcement = "Hello World!";

// How quickly can you spot the typos?

announcement.toLocaleLowercase();
announcement.toLocalLowerCase();

// We probably meant to write this...

announcement.toLocaleLowerCase();

uncalled functions,

function flipCoin() {
// Meant to be Math.random()
return Math.random < 0.5;

Operator
Operator '<'
'<' cannot
cannot be
be applied
applied to
to types
types '()
'() =>
=> number'
number' and
and 'number'.
'number'.

or basic logic errors.

 const value = Math.random() < 0.5 ? "a" : "b";
if (value !== "a") {
// ...
} else if (value === "b") {

This
This condition
condition will
will always
always return
return 'false'
'false' since
since the
the types
types '"a"'
'"a"' and
and '"b"'
'"b"'
have nohave
overlap.
no overlap.

// Oops, unreachable
}

Types for Tooling

TypeScript can catch bugs when we make mistakes in our code. That's great, but TypeScript can
also prevent us from making those mistakes in the first place.

The type-checker has information to check things like whether we're accessing the right properties
on variables and other properties. Once it has that information, it can also start suggesting which
properties you might want to use.

That means TypeScript can be leveraged for editing code too, and the core type-checker can
provide error messages and code completion as you type in the editor. That's part of what people
often refer to when they talk about tooling in TypeScript.

import express from "express";

const app = express();

app.get("/", function (req, res) {

res.sen
send
}); sendDate

sendfile
app.listen(3000);
sendFile

TypeScript takes tooling seriously, and that goes beyond completions and errors as you type. An
editor that supports TypeScript can deliver "quick fixes" to automatically fix errors, refactorings to
easily re-organize code, and useful navigation features for jumping to definitions of a variable, or
finding all references to a given variable. All of this is built on top of the type-checker and is fully
cross-platform, so it's likely that your favorite editor has TypeScript support available.
 tsc , the TypeScript compiler
We've been talking about type-checking, but we haven't yet used our type-checker. Let's get
acquainted with our new friend tsc , the TypeScript compiler. First we'll need to grab it via npm.

npm install -g typescript

This installs the TypeScript Compiler tsc globally. You can use npx or similar tools if you'd prefer to
run tsc from a local node_modules package instead.

Now let's move to an empty folder and try writing our first TypeScript program: hello.ts :

// Greets the world.

console.log("Hello world!");

Notice there are no frills here; this "hello world" program looks identical to what you'd write for a
"hello world" program in JavaScript. And now let's type-check it by running the command tsc
which was installed for us by the typescript package.

tsc hello.ts

Tada!

Wait, "tada" what exactly? We ran tsc and nothing happened! Well, there were no type errors, so
we didn't get any output in our console since there was nothing to report.

But check again - we got some file output instead. If we look in our current directory, we'll see a
hello.js file next to hello.ts . That's the output from our hello.ts file after tsc compiles
or transforms it into a plain JavaScript file. And if we check the contents, we'll see what TypeScript
spits out after it processes a .ts file:

// Greets the world.

console.log("Hello world!");
In this case, there was very little for TypeScript to transform, so it looks identical to what we wrote.
The compiler tries to emit clean readable code that looks like something a person would write.
While that's not always so easy, TypeScript indents consistently, is mindful of when our code spans
across different lines of code, and tries to keep comments around.

What about if we did introduce a type-checking error? Let's rewrite hello.ts :

// This is an industrial-grade general-purpose greeter function:

function greet(person, date) {
console.log(`Hello ${person}, today is ${date}!`);
}

greet("Brendan");

If we run tsc hello.ts again, notice that we get an error on the command line!

Expected 2 arguments, but got 1.

TypeScript is telling us we forgot to pass an argument to the greet function, and rightfully so. So
far we've only written standard JavaScript, and yet type-checking was still able to find problems
with our code. Thanks TypeScript!

Emitting with Errors

One thing you might not have noticed from the last example was that our hello.js file changed
again. If we open that file up then we'll see that the contents still basically look the same as our
input file. That might be a bit surprising given the fact that tsc reported an error about our code,
but this is based on one of TypeScript's core values: much of the time, you will know better than
TypeScript.

To reiterate from earlier, type-checking code limits the sorts of programs you can run, and so there's
a tradeoff on what sorts of things a type-checker finds acceptable. Most of the time that's okay, but
there are scenarios where those checks get in the way. For example, imagine yourself migrating
JavaScript code over to TypeScript and introducing type-checking errors. Eventually you'll get
around to cleaning things up for the type-checker, but that original JavaScript code was already
working! Why should converting it over to TypeScript stop you from running it?

So TypeScript doesn't get in your way. Of course, over time, you may want to be a bit more
defensive against mistakes, and make TypeScript act a bit more strictly. In that case, you can use the
noEmitOnError compiler option. Try changing your hello.ts file and running tsc with that
flag:

tsc --noEmitOnError hello.ts

You'll notice that hello.js never gets updated.

Explicit Types
Up until now, we haven't told TypeScript what person or date are. Let's edit the code to tell
TypeScript that person is a string , and that date should be a Date object. We'll also use the
toDateString() method on date .

function greet(person: string, date: Date) {

console.log(`Hello ${person}, today is ${date.toDateString()}!`);
}

What we did was add type annotations on person and date to describe what types of values
greet can be called with. You can read that signature as " greet takes a person of type
string , and a date of type Date ".

With this, TypeScript can tell us about other cases where greet might have been called incorrectly.
For example...

function greet(person: string, date: Date) {

console.log(`Hello ${person}, today is ${date.toDateString()}!`);
}

greet("Maddison", Date());

Argument
Argument of
of type
type 'string'
'string' is
is not
not assignable
assignable to
to parameter
parameter of
of type
type 'Date'.
'Date'.

Huh? TypeScript reported an error on our second argument, but why?

Perhaps surprisingly, calling Date() in JavaScript returns a string . On the other hand,
constructing a Date with new Date() actually gives us what we were expecting.

Anyway, we can quickly fix up the error:

function greet(person: string, date: Date) {

console.log(`Hello ${person}, today is ${date.toDateString()}!`);
}

greet("Maddison", new Date());

Keep in mind, we don't always have to write explicit type annotations. In many cases, TypeScript can
even just infer (or "figure out") the types for us even if we omit them.

let msg = "hello there!";

let msg: string

Even though we didn't tell TypeScript that msg had the type string it was able to figure that out.
That's a feature, and it's best not to add annotations when the type system would end up inferring
the same type anyway.

Note: The message bubble inside the previous code sample is what your editor would show if you had
hovered over the word.

Erased Types
Let's take a look at what happens when we compile the above function greet with tsc to output
JavaScript:

"use strict";
function greet(person, date) {
console.log("Hello ".concat(person, ", today is ").concat(date.toDateS
}
greet("Maddison", new Date());
Notice two things here:

1. Our person and date parameters no longer have type annotations.

2. Our "template string" - that string that used backticks (the ` character) - was converted to
plain strings with concatenations.

More on that second point later, but let's now focus on that first point. Type annotations aren't part
of JavaScript (or ECMAScript to be pedantic), so there really aren't any browsers or other runtimes
that can just run TypeScript unmodified. That's why TypeScript needs a compiler in the first place -
it needs some way to strip out or transform any TypeScript-specific code so that you can run it.
Most TypeScript-specific code gets erased away, and likewise, here our type annotations were
completely erased.

Remember: Type annotations never change the runtime behavior of your program.

Downleveling
One other difference from the above was that our template string was rewritten from

`Hello ${person}, today is ${date.toDateString()}!`;

to

"Hello " + person + ", today is " + date.toDateString() + "!";

Why did this happen?

Template strings are a feature from a version of ECMAScript called ECMAScript 2015 (a.k.a.
ECMAScript 6, ES2015, ES6, etc. - don't ask). TypeScript has the ability to rewrite code from newer
versions of ECMAScript to older ones such as ECMAScript 3 or ECMAScript 5 (a.k.a. ES3 and ES5).
This process of moving from a newer or "higher" version of ECMAScript down to an older or
"lower" one is sometimes called downleveling.

By default TypeScript targets ES3, an extremely old version of ECMAScript. We could have chosen
something a little bit more recent by using the target option. Running with --target es2015
changes TypeScript to target ECMAScript 2015, meaning code should be able to run wherever
ECMAScript 2015 is supported. So running tsc --target es2015 hello.ts gives us the
following output:
Other documents randomly have
different content
The Project Gutenberg eBook of Old Indian
trails
 This ebook is for the use of anyone anywhere in the United States
and most other parts of the world at no cost and with almost no
restrictions whatsoever. You may copy it, give it away or re-use it
under the terms of the Project Gutenberg License included with
this ebook or online at www.gutenberg.org. If you are not located
in the United States, you will have to check the laws of the
country where you are located before using this eBook.

Title: Old Indian trails

Author: Walter McClintock

Release date: May 14, 2022 [eBook #68074]

Language: English

Original publication: United States: Houghton Mifflin Company,

1923

Credits: Jeroen Hellingman, Jude Eylander, and the Online

Distributed Proofreading Team at https://www.pgdp.net
(This file was produced from images generously made
available by The Internet Archive/American Libraries.)

*** START OF THE PROJECT GUTENBERG EBOOK OLD INDIAN

TRAILS ***
[Contents]

[Contents]

OLD INDIAN TRAILS

[Contents]
sunset from lookout butte (page 197)
[Contents]
 OLD INDIAN TRAILS

BY
WALTER McCLINTOCK, M.A.
WITH ILLUSTRATIONS
FROM PHOTOGRAPHS BY THE
AUTHOR

BOSTON AND NEW YORK

HOUGHTON MIFFLIN COMPANY
 The Riverside Press Cambridge
1923

[Contents]

COPYRIGHT, 1923, BY WALTER McCLINTOCK

ALL RIGHTS RESERVED

The Riverside Press

CAMBRIDGE · MASSACHUSETTS
PRINTED IN THE U.S.A.

[Contents]

TO MY MOTHER

CLARA CHILDS McCLINTOCK [vi]

[Contents]
 PREFACE

In the spring of 1896 I went into northwestern Montana as a member

of a Government expedition which was appointed by President
Cleveland to recommend a national policy for the United States Forest
Reserves and to advise the Secretary of the Interior as to the
reserving of certain other forests.

Our expedition, which went in advance of the main Commission, was

composed of Gifford Pinchot, Chief of the Forest Service (now
Governor of Pennsylvania), and Henry S. Graves, later Chief Forester
and Dean of the Yale School of Forestry; I went as photographer and
to help in the forest surveys. We had two guides, William Jackson, an
Indian scout of the Blackfoot tribe, and Jack Munroe, a white man who
was married into that tribe.

We examined the forests in northwestern Montana, both on the

eastern and western slopes of the Rocky Mountains. We came into
contact with the natives of the region, both white men and Indians. We
made surveys in the country where the Flathead Forest Reserve was
later established, and in the region now known as Glacier National
Park. Then it was a paradise for hunting and fishing, a wild and
unfrequented country, visited only by Indians, trappers, and a few
hunters of big game.

We made our last survey in the heavy forest on the western side of
the Rocky Mountains. Then Graves set out for Kalispell and
civilization; Pinchot, with Jack Munroe and our bear dogs, started
south for Fort Missoula; I was left alone with the Indian scout. [viii]

We crossed the mountains together and joined the tribal camp of the
Blackfoot Indians on the plains. There I met many of their leading
men; among them Chief Mad Wolf, who adopted me as his son, in
ceremonies lasting through two days, and made me a member of his
tribe.

I maintained intimate associations with my Indian father and his tribe

through many years, keeping records of everything that I saw and
heard—their customs and legends and religious beliefs, our hunting
trips, and the flora and wild life of their country.

But into the region where we wandered civilization came with its
automobile highways and great modern hotels. The old generation of
Indians have died and their children are civilized. The Blackfoot are no
longer nomads and hunters, following the great herds of buffalo and
other game; they till the soil and live in houses like white men. Their
ancient customs and tribal life have passed away forever.

My purpose, therefore, in writing this book, is to record the results of

fifteen years’ close association with the old Blackfoot chiefs, medicine
men, and common people. I have retained the narrative form of my
original notes, in order to give as faithful a record as possible of their
character, environment, and family life.

W. McC. [ix]

[Contents]
 CONTENTS

I. My Indian Guide 3
II. Crossing the Rocky Mountains 8
III. Our Camp near the Summit 15
IV. Home of the Scout 21
V. Stories by the Scout’s Mother-in-Law 32
VI. My Adoption by Mad Wolf 35
VII. Mad Wolf tells the Legend of the Beaver Bundle 42
VIII. I am given an Indian Name and made a Member of
the Blackfoot Tribe 54
IX. Home of Mad Wolf 68
X. Marriage Customs 80
XI. The Head-Chief and his Wife 85
XII. Legend of the Smoking Star 92
XIII. My Night Experience with a Grizzly Bear 100
XIV. Indian Summer 109
XV. A Frontier Dance 119
XVI. Hunting Rocky Mountain Goats 124
XVII. The Blizzard 130
XVIII. Snow-Bound 139
XIX. The Mad Indian 144
XX. Coming of the Chinook 149
XXI. Beginning of Spring 153
XXII. Our Camp in the Mountains [x] 158
XXIII. Our North Expedition 166
XXIV. Onesta and his Sacred Bear Spear 174
XXV. Camp of the Blood Indians 179
XXVI. Country of the North Piegans 184
 XXVII. Camp of Brings-Down-the-Sun 191
XXVIII. Onesta gives his Crow Water Ceremony 199
XXIX. The Rival Medicine Men 206
XXX. Brings-Down-the-Sun tells about his Father 210
XXXI. Brings-Down-the-Sun tells about Men’s
Societies 219
XXXII. Brings-Down-the-Sun tells about the Birds and
the Stars 226
XXXIII. Legends of Star Boy and Scarface 232
XXXIV. Beginning of the Sun Dance 241
XXXV. Forming the Great Circle Camp 247
XXXVI. Life in the Circle Camp 253
XXXVII. Painted Tepees and Picture Writing 258
XXXVIII. A Native Doctor and his Patient 267
XXXIX. Dance of the Hair-Parters (Grass Dance) 274
XL. Society of Brave Dogs 284
XLI. A Medicine-Pipe Ceremony 289
XLII. A Sacred Ceremony in Mad Wolf’s Tepee 298
XLIII. The Tribal Dancing-Lodge 304
XLIV. End of the Sun Dance and Farewell of my Indian
Father 310
Appendix: Medicinal and Useful Plants of the
Blackfoot Indians 319
Index 327

[xi]

[Contents]
 ILLUSTRATIONS

Sunset from Lookout Butte Colored frontispiece

A Small Lake on the Western Slope of the
Rockies 4
Our Indian Tepee 4
An Old Indian Trail 16
Tribal Camp of Blackfoot on the Prairie 20
Mad Wolf 36
Mad Wolf praying 40
Mad Wolf’s Sacred Beaver Bundle 40
Woman under a Sun-Shelter: Bead and
Quill Work; Meat drying on Poles 70
Woman repairing a Tepee-Cover 70
Scaffold Burial 78
A Grave on a Hilltop 78
White Grass, the Medicine Man
Showing Interior Arrangement of his Tepee 92
Sunrise at our Hunting Camp in the
Rockies (in color) 112
Onesta 154
Nitana 174
The Country of the North Piegans 186
Onesta entering the Thunder Tepee with
his Sacred Bundles 200
The Crow Water Ceremony of Onesta in
the Thunder Tepee 200
Brings-Down-the-Sun and the Author [xii] 210
Three Chiefs, Followers of Mad Wolf 250
A Line of Warriors with War Bonnets 250
 Drying and Softening a Skin 256
Fleshing a Hide 256
Circle Camp of the Blackfoot 260
Inner Circle of the Tribal Camp, with
Crow Tepee in Foreground (in color) 264
Rattler doctoring Stuyimi 272
Elk Horn, Herald of the Brave Dog
Society 280
Society of Brave Dogs marching through
the Camp 284
Characteristic Costumes of Brave Dogs 284
Brave Dogs giving their Society Dance 286
Mountain Chief 292
Wolf Plume 292
A Blackfoot Camp on the Prairie (in color) 296
Ceremony of the Sun Dance inside the
Sacred Tepee 302
Raising the Center Pole for the Sun
Lodge 308
The Sun Lodge Finished and Ready for the
Tribe 308
Twilight in the Circle Camp: Tepees
illuminated by Inside Fires 314

[1]

[3]
[Contents]
OLD INDIAN TRAILS
CHAPTER I