Monthly Archives: December 2013

Misunderstanding Context

Over the last few days I’ve been involved in a discussion on LinkedIn[1]. It has been interesting as it shows how many people still misunderstand many of the intricacies of context and, in particular, how it ties in with the values returned from subroutines.

The original question asked why these two pieces of code acted differently:

my ($index) = grep {
  $array[$_] == $variable
} 0 .. $#array;
my $index = grep {
  $array[$_] == $variable
} 0 .. $#array;

The first one gives the first index where the element equals $variable, the second one gives the number of indexes where the element equals $variable.

The answer, of course, comes down to context.  And most people who answered seemed to understand that, but many of their explanations were still way off the mark. Here’s the first answer:

grep returns an array – so the first one will return the value of the first match, but 2nd one in scalar context will return the size of the array, the number of matches. I believe.

The first statement here – “grep returns an array” – is wrong, so any explanation built on that fact is going to be fundamentally flawed.

After a couple of similar answers, I jumped in and pointed out that the only way to know how grep will work in different contexts is to read the documentation; which says:

returns the list value consisting of those elements for which the expression evaluated to true. In scalar context, returns the number of times the expression was true.

At that point it got a bit weird. People started telling me all sorts of strange things in order to show that the earlier answers were better than mine. I was told that lists and arrays are the same thing, that there was something called “array context” and that it was possible for function to return arrays.

I think I’ve worked out what most of the misconceptions in the discussion were. Here’s a list.

1. Arrays are not lists

I know this is a very common misunderstanding. I come across it all the time. People use the terms “list” and “array” interchangeably and end up thinking that they are the same thing. They aren’t. A list is a data value and an array is a variable. They act the same way a lot of the time but unless you understand the difference, you will make mistakes.

Mike Friedman wrote a great blog post that explains the difference in considerable detail. But the core difference is this – arrays are persistent (at least while they are in scope) data structures; lists are ephemeral.

On training courses, I tell people that if they understand the difference between an array and a list they’ll be in the top 20% of Perl programmers. In my experience, that’s pretty close to the truth.

2. Subroutines return lists

A subroutine can only ever return a list. Never an array. It can be an empty list. It can be a list with only one item. But it’s always a list.

There’s one small “gotcha” here. I know this bit me a few times in the past. If you read the documentation for return, it says this:

Evaluation of EXPR may be in list, scalar, or void context, depending on how the return value will be used

This means that when you have code like return @array, it’s @array that is evaluated in the context of the subroutine call. So, depending on  the context of the call, this will return either a list consisting of all the elements in @array, or a list with one element which is the number of elements in @array.

3. There is no “array context”

When you confuse lists and arrays, then it’s not surprising that you might also decide that you can also invent a new context called “array context”. There are only list context, scalar context and void context. Ok, actually there are a few more specialised contexts that you can use (see the Want module for details) but most of the time you’ll only be dealing with those three.

Of course, the name of the wantarray function doesn’t help at all here. But it’s worth noting that the documentation for wantarray ends by saying:

This function should have been named wantlist() instead.

4. You  can’t guess contextual behaviour

One common argument I got when pointing this out on LinkedIn ran along the lines of “but grep acts like it returns an array, so it’s a useful mental model – it helps people to understand context”.

The first part of this is true – grep does act like it returns an array. It returns a list (which you might often store in an array) in list context and it returns the length of that list in scalar context. I can see how you would mistake that for returning an array. But  see my point 2 above. Subroutines do not ever return arrays.

But is it a useful mental model? Does it help people understand how subroutines work in different contexts?

No. It helps people to understand how this particular function works. And there are several other Perl functions that work the same way (keys is one example). But there are plenty of other functions  that don’t work that way. The canonical example is localtime. In list context, it returns a list of nine values; in scalar context it returns a single value (which isn’t the number 9).  Another good example is caller. In list context, it returns a list of items (which can contain either three or eleven elements); in scalar context it returns the first item of that list. There are many more examples.

So the problem with a mental model that assumes that functions work as though they return arrays is that it only works for a subset of functions. And you’d need to waste effort remembering which functions it works for and which ones it doesn’t work for. You’d be far better off (in my opinion) realising that there is no rule that works for all functions and just remembering how each function works (or, more practically, remembering to check the documentation whenever you need to know).

 

If you’ve seen me giving a lightning talk at a conference this  year, you’ll know that I’ve been encouraging more people from the Perl community to get involved in discussions in places outside the echo chamber, places like LinkedIn. It’s interesting because you see how people outside of the community see Perl. You see the misunderstandings that they work with and you might see how we can improve the Perl documentation to help them get around those misunderstandings.

This morning, this comment was posted to the LinkedIn discussion that I’ve been talking about:

This stuff should be included in a default perl tutorial to avoid common mistake.

And, you know, I think he’s probably right.

[1] Because of the way LinkedIn works, you won’t be able to see this discussion unless you’re a member of LinkedIn and, probably, a member of the Perl group as well.

Two Books

I’ve recently received review copies of a couple of new books. Here are the reviews of those books that I have submitted to Amazon.

Designing the Internet of Things – Adrian McEwen & Hakim Cassimally (Wiley)

I’ve been hearing people talking about “the internet of things” for a few years now. And I’ve always meant to find out what they meant by the term. Well now, thanks to this book, I have a really good idea. I might even think about building something for the internet of things myself (you know, in my copious free time!)

Adrian and Hakim obviously know what they are talking about. They both have experience of working on these kinds of projects. And, crucially, they also have the writing skills to pass their expertise on to the reader.

Some of the stuff in the earlier chapters, I already knew. But things like an introduction to TCP/IP and networking will be useful to many people who don’t have such a technical background. Software, I can do – it was the chapters about hardware that I found most useful. I now know far more than I did about the different toolkits that are available for building internet-connected devices.

Part I is about prototyping your device and part 2 is about building it. I’m sure that other books cover these topics – although, perhaps, not in the focussed way that this book does. But it’s part 3 where this book really shines. These three chapters cover business models, scaling your manufacturing process and some of the ethical issues that these devices raise. This section really makes the book a “one-stop shop” for finding all the information you’ll need to take your vague idea to a complete product and (hopefully) a profitable company.

Perl One-Liners – Peteris Krumins (No Starch)

Perl one-liners are an important part of its power and flexibility. The ability to process a file quickly without having to write a program is often really useful. Any Perl programmers should take the time to get to know the command like switches that make this possible. This book is a pretty good introduction to this way of using Perl.

So why only three stars? Well, I have a couple of reservations about the book. Firstly, there are a few technical errors which the editors should have caught. For example, a few times the author refers to “array context” where he means “list context”. The difference between arrays and lists is often difficult for beginners to master and it doesn’t help when books blur the distinction.

My other reservation is with the programs themselves. The book boasts “130 programs that get things done”. But I think they have had to stretch things a bit to get to that number. One program might be “print lines that match a pattern”. Then the next program will be “print lines that don’t match a pattern”. I’m not sure that inverting the logic in a one-liner is enough of a difference to justify counting it separately. Sometimes you’ll come across two or three pages of examples all of which are only tiny permutations of each other.

But it’s good to see publishers bringing out books on Perl. And this is certainly an area of Perl that hasn’t received much coverage before. I just think it’s a rather thin concept to spin out to a book. Even this stretched, it’s a rather thin book (140 pages – 50 of which are appendices). It might have been better as a cheap Kindle-only publication.