defconfaq - Q&A on arguments against the hypothetical ?? operator


This document attempts to distill thousands of acrimonious exchanges that have plagued the Perl developers' mailing list for years. Rather than ever descend once again into a rathole of furious, fractious, and fruitless debate on well-trodden territory, please refer to this FAQ when someone next asks ``Why don't some people want to see a new `??' operator added to Perl?''

The ?? operator (more easily pronounced ``hookhook'' than ``question mark, question mark'' or ``interrogation point, interrogation point'') would be an alternate form of the existing || operator that cared about definedness, not truth. It would also have an assignment version of ??= that worked mostly like ||=. Examples can be found below.

Who invented it?

The concept has been batted about--and battered about--for several years now. The notion has been separately suggested by various parties. The name itself was suggested as less annoying than ||| by Larry, and that nomenclature has stuck.

Where would it come in handy?

Often you want to select the first true value, as in:

    $a = $b || $c;
    $a ||= $b;

But if you want to distinguish between ``false and defined'' and ``false and undefined'' values, you have to use the defined() function:

    $a = defined ($b) ? $b : $c;
    $a = $b unless defined $a;

The proposed ?? operator is supposed to allow you to write those two statements more analogously to how you would write the ``||'' versions.

    $a = $b ?? $c;
    $a ??= $b;

You could also use ?? for a different variety of truth test, so instead of writing,

    defined($pid = fork()) || die "cannot fork: $!";

You would just write:

    $pid = fork() ?? die "cannot fork: $!";

There are at least two places where this might appear attractive. The first is for a series of many choices. Trying to write this using defined instead is little fun:

    $a ??= $b ?? $c ?? $d ?? $e ?? $f ?? $g;

ends up looking like

    $a = $b unless defined $a;
    $a = $c unless defined $a;
    $a = $d unless defined $a;
    $a = $e unless defined $a;
    $a = $f unless defined $a;

A more readable and less repetitive way to write that would be:

       or defined($a = $b)
       or defined($a = $c)
       or defined($a = $d)
       or defined($a = $e)
       or defined($a = $f)
       or        ($a = $g);

Proponents of hookhook point out that when you have very long expressions, this is unpleasant to write:

    $settings->{Style}{Font}{Weight} = "bold"
        unless defined $settings->{Style}{Font}{Weight};

And show that the hookhook could provide a short-cut:

    $settings->{Style}{Font}{Weight} ??= "bold";

What's the real difference between a setting of false-and-defined and false-and-undefined here? Should that be tested against a defined setting, or a simpler true-false setting? In the latter case, the existing ||= would suffice. In the former case, you then have to ask yourself whether you should be using a defined() test, or whether an exists() test would be more appropriate. It's simpler to set up your data so that Perl built-in notion of true and false suffices. This is often desirable, but isn't always feasible; for example, distinguishing a numeric 0 from a missing value in the case of string data, or a "" from a missing value in the case of numeric data.

Even in these cases, though, you could use the foreach loop's property of creating a convenient alias to simplify typing and avoid potentially error-prone repetition:

    for $it ($settings->{Style}{Font}{Weight}) {
        $it = "fold" unless defined $it;


    for ($settings->{Style}{Font}{Weight}) {
        $_ = "fold" unless defined;

Which can be written

    defined or $_ = "fold" for $settings->{Style}{Font}{Weight};

This approach has the advantage of being useful in situations other than just defined tests. You can choose your own abbreviation, and because many Perl operations let you use $_ implicitly, substantial savings in typing can be effected. It doesn't deal with the issue that a hash element has four different states:

  1. true

  2. false and defined

  3. false and not defined

  4. false and not existent

But then, neither would hookhook.

The second place where the ?? operator might prove appealing would be when you absolutely must use short-circuiting. Suppose you want $a to get the return value of f() if that value is defined, but the return value of g() otherwise. You don't even want g() evaluated if f()'s return value is true. Instead of writing

    $a = f();
    $a = g() unless defined $a;

You could write

    $a = defined($a = f()) ? $a : g();

or perhaps

     defined( $a = f() )
          or  $a = g();

or maybe

     defined( $a = f() )
          or( $a = g() );

Proponents of hookhook want to to write that assignment in this way:

    $a = f() ?? g();

What are current or suggested alternatives?

As demonstrated above, current alternatives to ?? and =?? are to use ||, ||=, ?:, unless defined, or unless exists, depending on your needs. These suffice to get the job done, and we have lived with them for a long, long time. Proponents of hookhook feel that these are not always optimally short nor optimally convenient. Opponents of hookhook are not convinced that enough such places exist to justify a new operator, nor are they convinced that the promises of brevity and convenience are all that they're cracked up to be.

Another suggestion is to make a first_defined() function, as in

    sub first_defined {
        defined && return $_ for @_;
        return undef;

That would let the somewhat awkward multiple assignment become:

    $a = first_defined $b, $c, $d, $e, $f, $g;

One suggestion is to use a more generic first() function:

    sub first(&@) {
        my $code = shift;
        &$code && return $_ for @_;
        return undef;

    $a = first { defined } $b, $c, $d, $e, $f, $g;

And then the ``??='' operator would be

    $a = first { defined } $a, $b;

These are perfectly usable today. The first() or first_defined() functions could be written in C to make them faster, and available via a module. They're attractive because of their clarity. And first() in particular is powerful and flexible.

The sole remaining issue with first() or first_defined() is that as shown above, they don't make use of short-circuiting. Opponents feel those cases are too rare to justify a new operator, and that programmers should use existing short-circuit mechanisms for those cases.

A sidenote: Larry once suggested that perhaps defined() should return the thing itself, allowing us to write:

    $a = defined($b) || $c;

Rather than

    $a = defined($b) ? $b : $c;

But not many seemed enthralled with this notion, because they were afraid that this would break in

    $b = 0;
    if (defined($b)) { ... }

But that was never going to happen. Along with the idea of defined() returning its value would also come the idea that in a appropriate context, it would still return a true value, not the number 0. Lest you think this utterly bizarre and novel, consider Dennis's writings of a slightly similar consideration, which can be found in its entirety at

Rapid changes continued after the language had been named, for example the introduction of the && and || operators. In BCPL and B, the evaluation of expressions depends on context: within if and other conditional statements that compare an expression's value with zero, these languages place a special interpretation on the and (&) and or (|) operators. In ordinary contexts, they operate bitwise, but in the B statement
	if (e1 & e2) ...  
the compiler must evaluate e1 and if it is non-zero, evaluate e2, and if it too is non-zero, elaborate the statement dependent on the if. The requirement descends recursively on & and | operators within e1 and e2. The short-circuit semantics of the Boolean operators in such `truth-value' context seemed desirable, but the overloading of the operators was difficult to explain and use. At the suggestion of Alan Snyder, I introduced the && and || operators to make the mechanism more explicit.

Their tardy introduction explains an infelicity of C's precedence rules. In B one writes

	if (a==b & c) ...  
to check whether a equals b and c is non-zero; in such a conditional expression it is better that & have lower precedence than ==. In converting from B to C, one wants to replace & by && in such a statement; to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and ==, and thereby simplify a common C idiom: to test a masked value against another value, one must write
        if ((a&mask) == b) ...  
where the inner parentheses are required but easily forgotten.

Larry was thinking of doing something similar with defined() in the right sort of context.

How would a general-purpose macro facility help?

The short-circuiting aspect of the operator is the only part that can't be implemented simply with a standard Perl subroutine. With an appropriate macro facility, the short-circuiting nature could also be implemented, thereby reducing the entire question simply to whether the concept of ?? merits a full-blown infix operator instead of a more readable function or macro implementation.

Larry has on occasion mused whether a general-purpose macro facility might not be of benefit to Perl. C's version of macros via the C preprocessor as a way of creating your own syntax has been severely admonished by the creator of C++ as a nastiness to be strenuously avoided. But it's not just C that has macros, and other implementations are not so frequently denigrated--nor if truth be told, so well known. For example, the Franz Lisp dialect had macros.

One suggestion is that a subroutine attribute of :lazy be invented to help provide this. However, details are murky, and no work has been done on it, so it's hard to know what this would entail and whether it would suffice.

A controversial and unincorporated patch for user-definable operators exists, one which would seem to allow ?? to be implemented using that mechanism. Nevertheless, this patch does not allow one to write these special operators in Perl, forcing you instead to write a C-based extension to the Perl run-time system. Aesthetics and other issues with that patch aside, making programmers write in C is far from convenient.

This all seems great; why would anyone disagree with it?

You might be unpleasantly surprised at how much disagreement exists. The debates are fierce and never-ending. Arguments opposing a ?? operator include ugliness, obscurity, redundancy, potential for misuse, lack of generality, avoidance of new operators, aversion to change, and questionable choice of name. See below.

Why does ugliness matter?

Ugliness matters because people have to read your code, and you should be kind to them. Perl is already painfully subject to legibility criticisms because of its high density of nonalphabetic characters. The observation that this predicament already exists does not justify making it worse. Larry tried to make perl5 more legible by adding spelled-out logicals and by making the ampersand and parentheses on function calls optional. Introducing extra punctuation marks back into the language would seem to be swimming against the legibility current.

This proposed hookhook operator is ugly (nonalphabetic) and non-intuitive (non-derivative). To many opponents of hookhook, something like this is crystal clear to all concerned:

    $a = 42 unless defined $a;

Whereas the hookhook proponents' alternative carries no such clear and obvious benefit of understandability:

    $a ??= 42;

But ?? would be shorter to type, so wouldn't that be better?

Proponents of hookhook feel that the brevity this operator appears to provide to be of great benefit to legibility, whereas its opponents feel exactly the opposite.

Down this path may lie the unnatural vice known as false laziness, sometimes difficult to discern from the virtue that laziness can be to a programmer. The goal of the programmer writing maintainable production code should never be to winnow down the program to its smallest of all possible encodings. Life is not a JAPH contest.

Many seasoned programmers (especially but not only those more accustomed to Python, Pascal, or Basic) have upon reading a bit of ``clever'' Perl code thrown up their hands in annoyance and frustration, thinking they had stumbled upon a contest entry of some Obfuscated Perl Programming Contest. But in fact all that's happened is they've come across someone who decided that curt code was cool, someone who chose to avoid as many temporary variables, self-explanatory identifiers, separate statements, and braced blocks as they can could away with. And maybe then some.

There is no virtue in pursuing brevity too far, for doing so can lead to ugliness, confusion, and error. If you think that Perl is about typing as little as possible, good luck finding someone to support your code.

In the ``or''-cache example elsewhere in this document, the ultratight code using ||= for the cache leads to an error that would never have happened had its author merely written out what was meant using a longer, clearer, and less ugly form. And ??= doesn't help this problem at all--well, not without the exists() kludge, which is moderately unsettling to consider.

Isn't making another way to do something the essence of TMTOWTDI?

TMTOWTDI (``There's more than one way to do it'', the Perl Motto) is not a justification for forever adding yet-another-way to do something. Larry once said, ``Although the Perl Slogan is `There's More Than One Way to Do It', I hesitate to make 10 ways to do something.'' There's a critical misunderstanding about where one might apply TMTOWTDI, and where one should not.

The principle has been used to justify doing whatever one feels like, but that doesn't work. Good taste matters. Sometimes Perl language development seems afflicted by a strange form of cultural relativism that says, ``All things are good. That's just one opinion and all opinions are good. None are bad''. Nothing could be further from the truth! If all things were good, and all should be included, then Larry would not have picked and chosen from amongst the many features of Perl's ancestral tongues; he would have just thrown everything in. But he didn't do that.

As far as ``operators'' that are slightly ``or''-ish go, we already have ||, or, |, ^, and xor, some of which behave differently on string operands than they do on those that are purely numeric. For tests, we start with Perl's natural Boolean sense used in if, unless, while, until, ||, &&, ?:, etc. The standard Perl truth test counts as true anything that doesn't evaluate to 0, "", "0", or undef. And one mustn't forget that we also have defined, which adjudges true the first three of the previous four false values, but the fourth is still false. Then we have exists, which must be used on a hash element when we wish to distinguish between a missing key and a missing value.

As you see, we already have many ways to select one of several choices or to check for truth, some only differing from one another only subtly. To the opponents of hookhook, adding more subtle nuances to the language does not seem a better approach than simply writing out what you mean for everyone to see.

How might the operator be used incorrectly?

This is being touted as a ``safer'' or ``improved'' alternative to ||. We've seen this before. Although we can demonstrate other ``improvements'' that haven't in the end worked out so well as hoped, the most obvious example case is when folks learn about the or operator, and hear it is ``safer'' than the old C version. Instead of writing:

    $a = $b || $c;   # set to whichever's true, in that order

They now try to write:

    $a = $b or $c;

That doesn't work, because the precedence is wrong. But some places it's ok, as in

    if ($a or $b) { } # if either is true

You can be certain that the semantic similarity of ?? to || (in some situations) combined its proponents' support of the former being better than the latter (in some situations) will cause programmers to forget the parenthetical ``in some situations'' caveats and produce code like this:

    if    ($a ?? $b) { }    # if either is defined
    while ($a ?? $b) { }    # so long as either is defined

The comments and the code disagree with one another. Imagine if $a contains one of the three defined but false values. The operator returns that false but defined value. This then fails the if or while statement's more conventional Boolean test. This is because the ?? operator would have its own notion of yes or no, one quite apart from the rest of Perl.

You might think that this would never happen, because people will know that ?? is not for all the same things as || is. But if that were so, then why do the errors with or occur so frequently? This is a serious accident just waiting to happen. Just because they already have more than enough rope to hang themselves doesn't mean you need to also provide them an extra chair, a stepping stool, and a polite hand up.

Some proponents of hookhook have suggested that you just write all of those this way:

    if ($a ?? $b ?? 1) { }

They'd also modify the operator to detect whether it's in a Boolean context and not short-circuit if it were about to cause the test to fail, and instead go on to the next portion, which in this case would be the 1. They would also have the compiler to warn you if you don't write it this way. This notion seems unsavory at best, moreso even than Larry's idea to extend defined's return value to detect its context, since that wouldn't alter whether an operator would short-circuit or not.

Another suggestion is just to tell users to make sure to use an explicit defined test in a Boolean context, as in:

    if (defined($a ?? $b)) { }

But that's silly, confusing, or both: there is no difference between ?? and || there once you do that.

($a ?? $b)
($a || $b)
Col3 ^ Col4

So where else might ?? or ??= be used incorrectly? Proponents explain that apart from initializations, the next best place for the ?? operator is the occasionally used ``or''-cache, a bit of tight but arguably idiomatic code like the following:

    my %cache;
    sub fn_with_cache {
        my $arg = shift;
        $cache{$arg} ||= fn($arg);

They point out, correctly, that this needlessly recomputes the function's return value if that return value was false. So they suggest that assignment expression above be replaced with

        $cache{$arg} ??= fn($arg);

to solve that problem. But it still doesn't solve the problem! The correct code is really:

    return exists $cache{$arg}
        ?  $cache{$arg}
        : ($cache{$arg} = fn());

Why? Because ?? would test only for definedness, not existence, which is the more proper test. After all, the function might have returned the undefined value, which you then cached.

Some have suggested that if the operand of ?? is a hash element, that exists() rather than defined() be implicitly used. Talk about magic! This and the fix for the Boolean problem both seem like hack piled upon hack. It's better to write what you really mean. This just doesn't come up often enough for the extra semantic space it would have to occupy in your skull to remember, nor in the manual to document and read.

Another potential problem with the operator is that it's of use only with scalars, because aggregates do not have a valid defined() test. That means that for

    $a = defined($b) ? $b : $c;

you can rewrite as

    $a = $b ?? $c;

But for

    @a = @b ? @b : @c;

you can't rewrite as

    @a = @b ?? @c;

or else you end up making an invalid definedness test. The same thing is true with hashes. List returns from functions would end up being called in scalar context. You couldn't write:

    @a = f() ?? g();

but will have to write

    @a = f()  or  @a = g();

That's not too bad though, because it's more legible, at least in some senses to some people.

To allow hookhook for scalars but still require the ternary hook-colon for aggregates just introduces a new bit of needlessly confusing inconsistency that wasn't there before.

Could this operator break anything, and if so, is this important?

Keep in mind that you break not only those users who try to run these scripts on older versions of Perl. You also break the increasingly nontrivial number of third-party code development tools such as debuggers, profilers, syntax-directed editors, and diverse sorts of analysers such as cross referencers, class browsers, text coverage analysis tools. Some of them are commercial ventures, people we don't want to scare away from producing these Perl-based add-ons.

But how bad is this, really?

The code development tools included in the Perl release would either would get fixed automatically (like the code generator), or else already have someone who's spoken up to fix them if needed (like the debugger). Mostly all that would slightly break would be third-party tools, such as those advertised in the Perl Journal, which have to know quite a bit about Perl syntax. But they have to track development releases in any event. For example, the new subroutine attributes for methods or for threading will already affect them, as would most of the proposed prototype extensions. So one more change doesn't seem unduly onerous. Change happens.

So the code development tool issue does not after all appear to be a catastrophic one.

This may come as a surprise to most readers, but it turns out that ?? already has a meaning in Perl, albeit a remarkably recondite one. It's like the empty // pattern match, that is, repeat the last successful match. But with ??, it would do so the first time only. There may be an infinitesimal chance that this would interfere with the proposed binary use of ??, but this does not seem terribly important.

We've never actually seen anyone actually write the perfectly valid:

    if (??) {  # repeat last matched pattern, first time only

or code to that effect. Should you ever encounter anyone doing this, please send mail.

What's wrong with the name?

Apart from the ugliness factor, the biggest problem with the name is that there's no existing precedent for it to draw upon for understanding. You can't find someone who knows any combination of C, shell, awk, sed, or the Unix tools--Perl's ancestor tongues--and have them guess what hookhook means when they first look at it. Well, you can, but they'll guess it wrong. A real language lawyer might guess that it means something related to the current meaning of ??, but of course it doesn't.

Other proposals for a name have included ||| and //. Both have their attendant problems. The first is not visually distinctive, and leads to an abhorrent tetragraph as its assignment operator. The second also lacks visual distinction, and has a much greater chance of inspiring notions of pattern matching than would the more esoteric first-time-only version that the current interpretation of ?? provides.

Remember that both these are possible:

    $a = $b || $c;
    $a = $b && $c;

It's true that // would have look analogous for the first case, but what would you use for the second one? Perhaps %%? Certainly ||| would imply &&&, but again, these don't escape the other woes discussed for ??.

Many opponents of hookhook find first() or first_defined() to be the most attractive alternate names. Larry himself remains undecided on the name, and he ends up arguing both sides of the matter. See below.

We've added new operators before, so why not do it again now?

Perl has scant few operators that don't at some level derive their appearance from somewhere else. The only ones that come to mind are . for catenation, x for repetition, the spaceship operator for tri-valued numeric comparison, the comma-arrow (aka fat-arrow) for a comma that does autoquoting of barewords, and the backslash operator to creating a reference. But apart form the possible exception of catenation, these are all reasonably intuitive once you think about them.

The last operator added to Perl was the dereferencing arrow for method calls on objects for when you aren't using the dubious indirect object notation. But that operator was added six long years ago now. Perl hasn't been around twice that long, which means we haven't added a new operator during the entire latter half of Perl's life.

The introduction of the method-call arrow had these attractive properties:

  1. It already existed in other languages and was therefore entirely obvious to Perl converts coming from those languages.

  2. It provided something that could not be done otherwise.

  3. We were on the cusp of the only rewrite Perl has ever had--the one from perl4 to perl5.

Although you might argue that you could do the second task by hand, no one wants to make recursive @ISA traversals and AUTOLOAD checks by hand. If you had to, you'd never use inheritance. Or they'd only use indirect objects, which are fraught with peril and generally avoided.

The ?? operator does not satisfy any of these properties. It does not exist in any other languages, it does not provide anything we can't do already, and we are not on the cusp of a major rewrite.

Perl did not as Athena from Zeus, spring from Larry's skull wholly made. It's an organic thing that reacts to its changing environment. So it's not completely unthinkable that a new operator might someday be needed in Perl. But if so, it should be to satisfy an incontrovertible need with overwhelming consensus and little dispute or reservation, much as the method-call arrow enjoyed. We're not anywhere near that point with the hookhook operator. It's already easy to accomplish what hookhook would be used for, and existing mechanisms are more legible and flexible than it would prove.

Won't opposing all change per se cause Perl to stagnate and die?

It might, but that's not what's going on here.

The misapprehended application of TMTOWTDI coupled with an unmitigated ``grow or die'' instinct--a property shared also by malignant tumors and urban sprawl, where as here it becomes ``grow until you kill yourself''--lead perhaps inevitably to positions that fail to account satisfactorily for the underlying historical structure, current and anticipated user base, or anything even vaguely resembling a unified vision of purpose and design when it comes time to construct a coherent path into the future sufficiently free of broken and mislaid cobblestone so as to be nonchalantly trodden upon by those with tender feet but distracted eye.

In other words, change for its own sake is a self-destructive idea. It must be carefully considered. Some of the respect that Perl has recently won stems in part from the way its change rate has been slowing down to something more manageable than the patch-of-the-week chaos. A frequent frustration and impediment to acceptance is Perl's historically volatile syntax. It's bad enough--albeit admittedly occasionally necessary--when rather than new modules, completely new functions are added to the core of the language. Many shops to this day still use perl4, because they find perl5 to be too volatile for production work. You can argue with them about this as I have, but that's their position. Business ventures are sensitive to code that won't compile between releases, and changes that cause are especially suspect. Admittedly, backwards compatibility is more important than forwards compatibility, but that doesn't mean the latter is not to be approached gingerly.

When Larry rewrote Perl for the 5.0 release, he intentionally provided a way for Perl to grow: libraries and extensions. The idea was that it was hoped that most of Perl's future growth could occur outside the core. If you plot the rate of new features in Perl against time, you'll find that the rate itself has slowed down tremendously. In the first three releases, a lot of new syntax and operators happened, but since the version 5 release, little of that has occurred. There's been some, but it's been gradual and not dramatic. Examples included threading, the compiler, Unicode support, and regular expression extensions.

New built-ins are very rare, but include sysseek() and qr//. Constrast these two constructs with the proposed hookhook operators. They provided functionality that was virtually impossible to achieve in any other way.

A first() or a first_defined() function could be easily implemented in a library or extension module--at least, for the cases where you don't absolutely have to have short-circuit evaluation. If this existed, we could see in real code whether this would be so common and useful as to merit inclusion in the core. And then we could figure out how important short-circuiting might be. But no one has done even that yet, so we just don't know.

If we ask often enough, doesn't that mean we need this?

No, it means you want it. The argument that the ?? operator should be implemented simply because it happens to be a periodically recurring issue is a specious one. Repetition is never an element of logic, and seldom one of aesthetics. Obviously we can get by without hookhook, because we don't have it now and currently seem to getting by despite its absence. Are our lives less fun this way than they might otherwise be? That's very hard to judge. But continued asking isn't enough. Technical matters must be judged upon technical merit. Proof-by-repetition is not admissible. We have to use sound judgment, not merely acquiesce to insistence. And as Dennis has remarked, ``A language that doesn't have everything is actually easier to program than some that do.'' Larry didn't put everything in Perl, and for good reason.

What do Larry and Sarathy think? Where can I read originals?

Sarathy recently wrote:

In summary, I deem:
        EXPR1 ??= EXPR2 ?? EXPR3 ?? EXPR4; 
is written best in crystal clear Perl:
           or defined(EXPR1 = EXPR2)
           or defined(EXPR1 = EXPR3)
           or defined(EXPR1 = EXPR4);

Larry has not spoken on this matter in about a year. Some quotes of his from back then are from[ST_rn=ps]/getdoc.xp?AN=393749501&fmt=text

I'd much rather see something on the grep/sort/map pattern:
	first {defined} $foo, $bar, $baz 
That's much more readable to me, and doesn't lose the really important bit of information down at the end of a block that might be arbitrarily long.

In[ST_rn=ps]/getdoc.xp?AN=393496733&fmt=text Larry also said:

If we decide to use ??, it'll be after we're quite sure that we want that shortcut, and none of the others. And that is something I haven't come to any decision about yet.
If we put in ??, it'd be strictly defined as a rewrite of ?: (though not necessarily with that precedence). No need to redefine truth.
That being said, I'm not yet convinced that ?? is the right way to go, either.


Does anyone have any real examples of wanting this sort of operator other than to set a default? There's little point in putting in sidewalks where nobody's gonna walk (unless, of course, you sell concrete).

To read more on this, see either DejaNews or the p5p archives at the site. Subjects to search for include:

Here are canned URLs that will get you started on your research:


Tom Christiansen. Editing, suggestions, and invaluable input were provided by Gurusamy Sarathy, Nathan Torkington, Tuomas Lukka, Chip Turner, Jon Orwant, and Alan Burlison.