My experience immigrating to a foreign place is inextricable
from my experience growing up. Somewhere along the way I learned
the habit of recoiling from disappointment by lowering my
expectations to match. I shrunk myself in space and time, never
delaying others by holding the subway door open. As I practiced
attending to the present and the internal, I dissociated from
planning for the future and trusting the external. What’s beyond my
arm’s reach is not my home and I don’t belong there. If I don’t
have time to make a vegetable available by growing it myself, then
it doesn’t deserve to be my comfort food.

People say they don’t recognize their country anymore. I just
realized that in my case, it’s myself that I don’t recognize
anymore.

Whether and why and how to double-blind depends on what we’re
trying to do together, what’s just, and what’s humanly
achievable—all assumptions hard to pin down even if folks are
willing. But here’s how I think about it.

Suppose we want to estimate the effect of reading a given paper
on a person. Maybe this is because we want to decide whether to
publish a paper, to promote its authors, or whatever. In the first
sentence of this paragraph, I sneaked in the generic noun phrase “a
person” as if there is a given person, but in fact there is a
distribution over persons (possibly current and future, real and
fictional) that we care about. A typical approach to this
estimation task is to feed the paper to persons who we hope can
both represent the intended audience (by being a member, modeling
the members, or both) and report their experience (by writing a
review with evaluation, advice, or both).

The estimation cannot be perfect as long as the reviewing panel
is not exactly same as the audience. In fact, a reviewer may well
not be a typical audience member. For example, it is folklore that
a research paper should be written for a first-year graduate
student, but most reviewers are not first-year graduate students.
This can make sense because a skilled and knowledgable reviewer may
be able to model a typical audience member without being one.
Still, no reviewer or reviewing process is omniscient (or perfectly
rational (or perfectly altruistic)). Reviewers could use
help—perhaps in the form of oxygen, coffee, or double-blinding.

On this view, I expect (which is not to say that others should
expect) double-blinding to help if our intended audience contains
lots of people who don’t know the authors and their
research trajectories, so that a reviewer could better model how
those people would react to the paper. As I said above,
the precise audience is hard to pin down, but those people might
include first-year graduate students as well as the fictional
reader named “model-theoretic semantics” who evaluates a paper for
“truth”.

Did you know that all ACM-sponsored conferences have an
anti-harassment policy? I didn’t, until I chaired the Haskell
Symposium last year. The concise policy says, among other things,
that people shouldn’t use my family constitution to interfere with
my professional participation. And the policy has teeth. That’s
great.

My not knowing the policy and not seeing it publicized didn’t
make me go out of my way to harass anyone. But it did make me less
sure and less comfortable that I belonged at ICFP. Briefly, it’s
because I didn’t know if it would be common ground at the
conference that my actual self was fully human. That’s not
something I can take for granted in general society. Also, it’s
because I didn’t know whether my fellow conference attendees were
aware of the policy. We could all use a reminder, and a public
signal that we mean it.

For these reasons, I’m very happy that ICFP will start to
publicize ACM’s existing anti-harassment policy and make sure
everyone registered knows it. All ACM conferences should do it.
That’s why Tim
Chevalier,
Clement Delafargue, Adam Foltzer, Eric
Merritt, and I are doing two things. We ask you to join us:

Donate to the Ada Initiative. Our goal is for the functional
programming community to raise $8192 by the end of Friday (Sept 19)
UTC. To count toward this goal, please use this link: http://supportada.org/?campaign=lambda

(UPDATE: Wow! We reached our initial goal $4096
in just 5 hours! We increased the goal to $8192, thanks to your
generosity. And if we raise $16,384, we will sing “There’s no type class like Show type
class” and put a recording on the Internet.)

Thank you all for coming! There are about 160 people registered
for the symposium, which includes about 130 people registered per
day.

Thanks to everyone who submitted a paper! We received 37 papers
[UPDATE: I misspoke; the actual number is 33], of which we
accepted 13. Unfortunately, we could not accept the 2 of those
submissions that were functional pearls, or the 2 of those
submissions that were experience reports. I’m not sure what’s going
on or whether we should do anything about it.

We received 4 demo proposals, and accepted 3 of them. We
received 0 panel proposals, and accepted 3 of them. I mean, all the
panels were the results of direct soliciting. There were 2 panels
yesterday and 1 today. I don’t know if panels were a good idea;
more on that later.

Each paper received at least 3 reviews. Thanks to the 16 PC
members and 16 external reviewers who produced those thoughtful and
informative reviews on a very tight schedule. Please give them a
hand.

Here is a chart of the countries of authors of submitted papers
(at the top) and of accepted papers (at the bottom). You can see
the usual suspects to the left, and also to the right there were
authors from Chile, Denmark, Argentina, Austria, and China, but
only the papers from Denmark and China made it.

This year the symposium went to 2 days from 1 day, and the
panels are new, and the keynote is new. I have no idea what you
think of these format changes. I don’t even know many of you. So
please take this survey (just take the URL of the symposium and put
the word “survey” at the end) and let us know what you think!

Again, thanks to the program committee, especially to Norman
Ramsey for his sage advice.

Thanks also to the steering committee, especially to Jeremy and
Janis for their sage advice. Of course, this would not happen
without the local organizers, starting with Greg Morrisett, and the
workshop chairs, Patrik and Sam.

Thank you for coming, and thank you for caring so much about
Haskell that you even came to a PC chair report at 9am. Thank you
also for making the Haskell community such a welcoming place. Any
questions?

I want to talk about the pain and pleasure of the Haskell
community. The Haskell community is not such a welcoming place to a
significant number of people. Regarding this, let me recall
something Simon Peyton Jones said a long time ago. He was talking
about how to write papers and handle reviews, but I think his
advice applies just as well to personal interactions and the
difficult task of communication in general.

I want to remind ourselves, starting with myself, to be grateful
for criticism as well as praise. Because we are among
friends—friends who inspire us to do our better, to do our
best.

So I want to remember to interpret criticism as suggestions for
improvement. Let’s thank those friends warmly, because they have
given up their time. for us.

There are some specific ways in which the Haskell community has
not been welcoming. We have harmed people disproportionately—I
know; I have talked to them—due to how society is set up and their
gender. We have harmed people disproportionately due to how society
is set up and their race. Or their sexual orientation. Or
differences between their gender and assigned gender. Or maybe due
to the fact that not everyone grew up in their parents’ garage
hacking category theory at age 14.

So, if you see harm—if you feel unwelcome—you. are. not.
alone.

I showed you the country chart earlier. I didn’t show you the
gender chart or the race chart, because I can only do so many sad
things per day. There are horrible imbalances among the authors of
this symposium. I think there were like two women. Of course you
don’t have to write a paper to be a member of our community, but
this is a tip of an iceberg. And I’m sorry for the tip and I’m
sorry for the iceberg. I should have instituted double-blind
reviewing and I didn’t. I’m sorry for that.

So what should we do about it? What am I doing about it? I want
to tell you quickly about two things.

First, it’s high time we learned from those people who did not
find the Haskell community a welcoming place. If you were excluded,
or if you know someone who was, please share your stories. Of
course you don’t have any obligation to do anything, but out of the
goodness of your hearts, please be our teacher. Please contact me,
at ccshan@indiana.edu. I’m getting help from some cultural
anthropologists at Indiana University. If you know about
anthropology at Indiana, you’ll know that these are professionals
who really know how to learn from and respect your individual
experiences and perspectives. We’re going to conduct interviews and
anonymize them. Then, I’m not sure what we’ll do with the
interviews—maybe they’ll become a SIGPLAN Notices article, or a
theatrical play, or a shared resource if the interviewees are
willing. In any case, the goal is to strengthen our empathy for
each other, to understand our different perspectives on our shared
community, and to open conversations about this important
topic.

Second, as we have those conversations—indeed, whether we’re
having a technical conversation or a social conversation, and
whether it’s a communal discussion or a private one-on-one, let us:
Be friendly, and speak our minds with compassion. Let us be
charitable, and listen to others with compassion. Let us support
one another, whether by speaking up or stepping back. And let us
not burn out, and take care of ourselves, because this is hard,
worthwhile, work. Just like it’s worthwhile to hack GHC or to write
a clear paper or to give a sincere talk or to ask a helpful
question or to write a respectful message on haskell-cafe or to
glue together PHP and shell scripts to hold up our community
infrastructure. None of us signed up for this work when we were
born—I didn’t sign up for my native language to be the one not made
fun of at my elementary school—so thank you for doing it.

Thanks to three amazing women—Ava DuVernay, Lindsey Kuper, and
MrsB—for inspiring me to talk about this, and thanks to the SIGPLAN
executive committee for their support.

I want to discuss two moral aspects of how to talk about
borderline people (e.g., whether to say “MTF” or “female”, “smart”
or “good at math”).

The first aspect is what category of people we should be talking
about, never mind how we talk about it. Usually, for a given
category C, there are many ways to be borderline C: people can
be

borderline female due to a lack of chromosomes or a lack of
genitals;

borderline smart because they keep exchanging quantifiers or
because they keep estranging family;

borderline safe because they drive over the speed limit or roll
their bike past a stop sign;

borderline documented because they burned their passport,
overstayed their visa, or came from an unrecognized “country”.

Of course, it is easy enough to construct a category C’ that
firmly includes or excludes particular kinds of borderline Cs
(e.g., you are female’ iff you have XX chromosomes), if only to
leave unresolved lower-dimensional borderlines (e.g., what if only
half of your cells have XX chromosomes). So let’s ask not what
categories exist (because they all do) but what categories we
should talk about.

It might well be that we should talk about different versions of
C for different purposes (e.g., medicine, sports, identification,
love). It might also be that delineating categories at their edges
is not usually worth our collective cognitive trouble. Regardless,
sometimes in conversation or other collaboration I find that
multiple versions are actually relevant. For example, some people
wonder whether to call a transgender person “male” or “female”, and
I think a transgender person can firmly belong to a gender
category that we should talk about. Unfortunately, when I tried to
work with others to distinguish and choose among versions of
categories, I have often been frustrated.

When people in power to classify others don’t take the effort to
apply the right category version, the misclassified people can get
slighted. I empathize with the misclassified people because I have
been misclassified—for example, I don’t need a passport to travel
internationally, and I am a computer scientist.

The second aspect is how to name a given category (version).
Even in a context where we agree intellectually that there is
exactly one gender category we should talk about (say “female”) and
a transgender person belongs to it firmly, the term “female” still
takes many people today more thought to produce and comprehend when
applied to a person known to be transgender than when applied to a
person known to be cisgender. So, it is tempting for a well-meaning
speaker to avoid gender categories altogether by terming a
transgender person “female-presenting” instead. The
“female-presenting” characterization

is certainly true,

but may be a cop-out because it

perpetuates the implicature that the person doesn’t quite
belong

and increases their work to counter misclassification,

yet may be justifiable (perhaps in some strain of
utilitarianism), though a justification remains to be spelled out
and applied uniformly to all instances.

Many people are riledup
that Dart’s type system
proudly
features covariant generics and so “is unsound”. The
basic problem with covariant generics is that it lets you take
a bowl of apples and call it a bowl of fruit. That’s fine if you’re
just going to eat from the bowl and you like all fruits, but what
if you decide to contribute a banana to the fruit bowl? Someone
taking from the bowl expecting an apple might choke. And someone
else could call the same bowl a bowl of things then put a pencil in
it, just to spite you.

… because they are unsound?

We all seem to agree that it’s bad for an apple eater to choke
on a banana or a fruit eater to choke on a pencil. (Wittgenstein
and Turing similarly agreed that it’s bad for a bridge to fall
and kill people.) For example, Java seems to agree: it detects at
run time when such choking is about to occur and throws an
exception instead, so no immediate harm is done. There is less
agreement as to whether a static type system must prevent such
choking before run time. One
argument for early prevention is that it’s the whole point of
having a static type system—why even bother with a static type
system if it’s unsound?

But plenty of static type systems are unsound yet respectable.
For example, many dependent type systems are unsound, either
because their
term languages are blatantly non-terminating or because they
include the Type:Type rule. (I faintly recall that
Conor McBride calls Type:Type “radical
impredicativity”.) So it doesn’t seem that unsoundness per se
should rile people up about Dart in particular.

Perhaps it’s time to distinguish
different sorts of unsoundness: a type system can be unsound
because it fails normalization or because it fails subject
reduction. In the former case, a program (or the type checker)
might promise an apple but never produce one; in the latter case,
the program might promise an apple then produce a banana. The
unsoundness of a dependent type system tends to be of the former
sort, whereas the unsoundness of covariant generics seems
to be of the latter sort. And the former sort of unsoundness seems
more benign than the latter sort (and more deserving of the term
“radical impredicativity”). So, by calling for subject reduction
but not normalization, it seems we can drive a wedge between the
acceptable unsoundness of many dependent type systems and the
unacceptable unsoundness of Dart.

But it is very easy to turn a failure of subject reduction
detected at run time into a failure of normalization: just go into
an infinite loop whenever choking is about to occur! In Java, we
can write catch (Exception e) { for (;;) {} }. (In
math, we can restore subject reduction by letting an uncaught
exception take any type, as is standard.) Is that really better?
Does this move really answer the critics? I don’t feel so. For one
thing, this move makes it harder, not easier, to write better
programs: I want my program to stop and tell me
when it’s choking.

Just as it’s only
useful for type systems to allow a program if it’s something
good that a programmer might write, it’s only useful for type
systems to disallow a program if it’s something bad that a
programmer might write. In other words, both incompleteness and
unsoundness “may
appear to be a steep price to pay” yet “work well in practice”.
Does Type:Type abet many bad programs that people
produce? Perhaps not. Do covariant generics abet many bad programs
that people produce? Perhaps not. Are untyped bowls and naive set
theory terribly dangerous? Perhaps not. (Proof rules and
programming facilities that are unsound may even encourage useful
abstraction and reduce the proliferation of bugs by
copy-and-paste.)

… because they are meaningless?

To summarize so far, I don’t think we should dislike covariant
generics for its unsoundness in general or for its failure of
subject reduction in particular. Why do covariant generics bother
me, then? I think it’s because they dash my hope for types to have
crisp meanings.

When I write down an expression, whether it’s a term or a type,
I want it to refer to something else, whether in my mind
or in the world. When I write that a certain term has a certain
type (say, alice:person or 2+3:nat), I
want to write about some entity, to mean that it
has some property. That is not subject reduction, but to have a
subject and a predicate in the first place, which is prior to
subject reduction. I would be dissatisfied if there is no subject
and predicate to be found outside the syntax and operational
semantics of a formal language. After all, my desire to assert
that 2+3:nat is not fueled by any interest in the
curly symbols 2 and 3 or the binary node
label +. In short,
I want to denote.

Of course, it’s not entirely a formal language’s fault if I
can’t use it to denote, if it’s hard to program in. Syntax only
goes so far, and cognition must carry the rest of the way. But it
does get easier to denote and program if how expressions combine
inside the language matches how their referents tend to
interact outside the language. For example, FORTRAN made it easier
to denote numbers than in assembly language: having written
2+3 to denote a number, and knowing that numbers have
absolute values, I can write abs(2+3) to denote the
absolute value of the number denoted by 2+3. Numbers
are outside FORTRAN, yet FORTRAN matches my knowledge that numbers
have absolute values. In contrast, if you can hardly put a banana
in a bowl of apples in reality but you can easily put(banana,
bowl:Bowl<Apple>) in formality, or vice versa, then I
have trouble seeing what banana and bowlmean.

This match I want is a kind of modular reasoning. Now, the word
“modular”
has been used to mean many things, but what I mean here is
this. To combine two objects inside a language, I might need to
worry about whether their types match, whether they live on the
same machine, whether they use the same calling convention, etc. To
combine two objects outside a language, I might need to worry about
how big they are, whose kitchen it is, and whether fruit flies
would come. Ideally, my worries inside the language should match my
worries outside the language. Ideally, a combination should make
sense inside a language just in case the referents of the combined
expressions are compatible outside the language. If the language
implementation could keep track of my worries and discharge them as
early as possible for me, then so much the better, but that’s
secondary and orthogonal—I’d be plenty happy if I can just talk
about worrisome things without also worrying about the language at
the same time.

I feel it’s hopeless to match a language with covariant generics
against things we want to talk about. Why? I don’t have proof. For
all I can show, the worries of a Dart programmer inside and outside
the language will match perfectly, just as Java exceptions
precisely simulate the material effects of putting a pencil in a
bowl of apples. In the end, my feeling boils down to the
unreasonable and unusual effectiveness of
mathematics and logic.

Not only might this effectiveness be fallible, but it’s also
possible that my hopelessness is misplaced. I said I want
expressions to match their referents more closely so that denoting
and programming becomes easier. But maybe the match we have today
is the best we can do because the world has too many shades of gray
to be modeled in the black-and-white terms provided by mathematics
and logic. Maybe the world simply refuses to provide crisp
referents for any expression to mean. Maybe, when lexical
references slip and uncaught exceptions fire, it’s just collateral
damage from the fact that life is messy. After all, it is one thing
for a bridge engineer to leave gravity unquantified because
calculus is hard; it is another thing for a bridge architect to
leave beauty unquantified because psychology is hard. To avoid
variance rules just because they “fly in the face of programmer
intuition” feels like the former to me, but what do I know?

… because they are not even unsound?

Well, I do my best. I do my best to understand whether and how
reference and truth can help programming. I do my best to enlist
syntax and pragmatics. I’m not yet ready to
give up just because so many people are confused by noun-noun
compounds in English (what’s an “apple bowl”?) and by variance
rules in Java today. To me, the notion of being sound or unsound
only makes sense if expressions have meanings outside the language.
I do my best so that Bowl<Apple> means
something, so that when I claim “it is easy for tools to
provide a sound type analysis if they choose” I know what I
mean by “sound”. To not even worry about what expressions mean is
not even unsound.

“FREE BOOKS! by taking them away” I wrote on my office door. I
had an hour before my next appointment to reduce my life at Rutgers
to a carry-on suitcase. So I had to leave behind everything that I
can buy again, even those volumes soaked with memories: my first
linguistics class, my first book chapter, conferences where
colleagues blew me away with their wit and intellect. You know,
you’re all mentors to me.

This fall semester, I’m excited to be visiting Cornell
linguistics, home of Mats Rooth’s computational linguistics lab.
For excitement in the spring, I plan to visit Tsukuba computer
science, home of Yukiyoshi Kameyama’s programming logic group. For
both of these opportunities, I am grateful. After them, all bets
are off. I want to keep learning and teaching, whatever that means.
Maybe it’s time for me to work on a new citizenship.
I’m open to suggestions.

The sun is brilliant. I didn’t just run into an old friend
yesterday. I was also delighted to experience Bollywood for the
first time, to get a tooth crowned for the first time. I won’t just
meet up with an older and younger friend tomorrow. I will also be
delighted to hear a new talk, to find a new thought.

Zena Ariola, Hugo Herbelin, David Herman, and Dan Keith: Let’s
change the abort in Filinski’s implementation of shift/reset from
strict to lazy. (1) When a top-level reset is present as there
is supposed to be, the implementation still works as specified.
(2) Moreover, in the unspecified situation where there is no
top-level reset, the implementation behaves more consistently.

Pierre Boutillier and Hugo Herbelin: Types better not depend on
impure terms, so require reset around terms that occur in
types.

Noam Zeilberger: Presheaves are {a fancy name for, the
constructive content of, the result of categorifying} Kripke
semantics. Kripke’s worlds and their relationships are the objects
and morphisms of the category that the presheaf is a functor from.
Can we identify the dependency in dependent types with the
dependency in evaluation order?

Roshan James and I debated the computational content of the
movie Primer. The question boiled down to this: using the mechanism
in the movie, can you build (a la “Constraining Control”) a box
that reports how many times it has been used, total
(throughout all time)? My answer is no because I model the movie
using the following monad, which I should explain in writing some
day:

Moe Masuko and Kenichi Asai implemented shift/reset in Caml
Light. Their group is writing many interesting programs on top of
this platform (such as declarative game-strategy search with
alpha-beta pruning). Masuko’s and Herbelin’s presentations made me
think it might make more sense to put one big reset around the
entire REPL rather than one reset around each REPL interaction.
This way, in the typical REPL that allows creating new top-level
bindings using “let”, if we accidentally shadow a binding with
another of the same name, we could still get back the old binding
by invoking a previously captured REPL continuation.

Roshan P. James and Amr Sabry: yield is popular, and people even
speak of it as a “delimited I/O” facility. I wonder if the
popularity is because the type of yield is first-order?

General discussion

Christophe Calvès’s PhD thesis has a part about a hierarchy of
monad transformers. Filinski’s recent paper “Monads in Action”
presents an operational model of side effects in which monads are
dynamically layered. Implementing this model in terms of
shift/reset (with a proof of correctness and all that) would be
nice and is an open problem as far as we know! In particular, we’d
like dynamically layered regions of monadic effects.

Speaking of layering: The examples we currently have of using
cupto/set in practice all have the flavor of making one
present-stage (aka metalanguage) prompt/cell per future-stage (aka
object-language) binder:

Label every binder in a λ-term with how many times that bound
variable is used

Transform a λ-term to make contraction explicit, for example
turning “λx.xx” into “λx. let x₁=x and x₂=x in x₁x₂”

So, if we represent the input term by “de Bruijn Notation as a
Nested Datatype” (Bird and Paterson), can we write any of these
examples using a control hierarchy like Danvy and Filinski’s that
makes the absence of uncaught shifts patent to the type system? The
use of type-level functions and polymorphic recursion is
allowed.

What is the distinction between undelimited and delimited
continuations? Führmann’s thesis concerns the distinction? I feel
the important distinction is whether an expression is polymorphic
or not in the answer type.

What is a continuation, some reviewers ask? I take the
“continuation stance” (cf Dennett’s intentional stance) when
appropriate: something is a continuation when a direct-style
transformation that makes it implicit simplifies the program
overall. In the end the answer depends on what is
representation.

Conversations outside the workshop

Olivier Hermant explained deduction modulo to me: augment
first-order logic with equations or rewriting rules to capture
things hard to express in first-order logic such as transitivity or
arithmetic. Uniform metatheoretic results such as proof
normalization across many modulo. Is this tool good for natural
logic?

Peter Dybjer is hooking up Agda to first-order automatic theorem
provers. The idea is to describe the existence of an Agda proof as
a first-order formula, so if the theorem prover says yes then you
trust that there is an Agda proof. This way, hopefully the end user
of Agda only needs to give the broad outlines of a proof like what
induction or pattern matching to do.

There are two kinds of people, those whose utterances have truth
conditions and those whose utterances are jokes. (Thanks to David
Beaver.)

I was on the NJ Transit train from New York to SALT at Rutgers. A lady and a guy got
on at the airport.

Conductor to guy, punching his ticket:
This train doesn’t go to Foo. Get off at the next stop and change
to a North Jersey Coast train.

Guy to conductor:
Oh! They told me to go to Track 5. So this train doesn’t go to
Foo?

Conductor to guy:
No, change at Rahway, the next stop.

Guy to conductor:
Ok. Thanks.

Guy to lady:
Excuse me, do you know how I can find out which train goes to
Foo?

Lady to guy:
Sorry, I don’t know. I’m a visitor myself.

Me to guy:
Where are you going? Which train are you trying to take?

Guy to me:
I thought this train went to Foo. They told me to go to Track
5.

Me to guy:
Oh, you have a North Jersey Coast line schedule in your hand. Let’s
see. Which train are you trying to take?

Guy to me:
I want to go to Foo. (points index finger all over
schedule) How I can find out which train goes to Foo?

Me to guy:
You need to read the schedule. Let’s see… (realizes he needs to
get off at the next stop) Sorry, there’s no time for me to
tell you how to read the schedule. But in short, you need to read
the schedule. That’s how you find out which train goes to Foo. By
reading the schedule.

Guy to me:
Ok, thanks. The guy at the airport just told me to go to Track 5. I
thought this train goes to Foo.

Me to guy:
Every train to Foo is on Track 5. That doesn’t mean that every
train on Track 5 goes to Foo.

Guy to me:
Oh, but the guy told me to go to Track 5. Thanks.

Guy gets ready to exit the train and ponders schedule for a few
seconds.

Guy to me:
“Trains marked with Q are part of NJ Transit’s Quiet Commute
program.”

Me to guy:
Right. That’s the whole sentence.

Guy to me:
I thought my train is part of the Quiet Commute program.

Me to guy:(flabbergasted) … Why do you think that?

Lady to me:
Excuse me, why don’t you just help the poor guy. He’s just trying
to get somewhere. You’re trying to get him to read but it would be
so much more helpful if you tell him which train to take, how to
get to his destination. You’re not being helpful.

Guy to lady and me:
I don’t know what’s going on. I just came from Canada.

Lady to me:
Yeah, instead of being unhelpful, why don’t you answer his
question.

Me to lady:
What was his initial question to me?

Lady to me:
He asked how to get to Foo.

Me to lady:
That was not his question.

Guy to lady and me:
Sorry to bother you; thank you very much; bye.

Lady and me to guy:
Bye.

Guy exits.

Me to lady:
I’d love to talk about this over tea.

Lady to me:
I just don’t think it’s helpful to teach him to read the schedule
when he’s just trying to get some place. Why don’t you tell him
what to do.

Me to lady:
I’d love to talk about this, but it may take a while. I’m getting
off at New Brunswick. Do you want to talk for a few minutes?

Lady to me:(grin dismissal) No.

Me to lady:
Don’t start conversations that you don’t intend to continue.