In user modeling, I usually come across actors, personas, and roles (user roles).  I thought it would be helpful to distinguish these so that I can use the right tool for the job, or at least understand their relationships, strengths and weaknesses.

Summary
Actor

• Defined - someone or something that "acts" on or with the system.
• Sample- customer, fulfillment, credit approval.

Roles

• Defined - a set of needs, behaviors, and expectations.
• Use - develop an initial task model.
• Keys - three Cs of context, characteristics, and criteria (i.e. overall responsibilities, patterns of interaction, and design objectives)
• Sample - regular buyer, incidental buyer, casual browser.

Personas

• Defined - fictitious characters that represent user types.
• Use - create familiar faces to help inspire and focus project teams.
• Sample - The Enterprise Architect is Art, and is a Programming/Platforms Expert who influences the technology direction, defines technology standards, and oversees (from a technology perspective, not a managerial perspective), the design of several applications in his business unit.

Analysis
Personas

• Pros - They can encourage empathy among technology-focused designers and developers. 
• Cons - They can encourage projection and overly concrete thinking.  They may not be truly representative.  It can be tricky for the engineer or designer to figure out what matters and what doesn't.

Roles

• Pros - they abstract the user roles efficiently and make them easy to work with.
• Cons - they can be abstract to the point where you lose empathy.

They All Have Their Place
At the end of the day, actors, roles and personas have their place.  I like the example from forUse: The Electronic Newsletter of Usage-Centered Design
#15, August 2001: http://www.foruse.com/newsletter/foruse15.htm

"For a simplified example, a business-to-business e-commerce application might be modeled with three actors: Customer, Fulfillment, and Credit Approval. The Customer might be differentiated into several roles: Regular Buying Role, Incidental Buying Role, and Casual Browsing Role. The latter might be described as: not necessarily in the industry and buying may not be sole or primary responsibility (CONTEXT), typically intermittent and unpredictable use, often merely for information regarding varied lines and products, driven by curiosity as much as need (CHARACTERISTICS); may need enticements to become customer, linkage to others from same account, access to retail sources and pricing (CRITERIA)."

What to Do
In practice, I've found the following guidance helpful: Create your full range of user roles, then create the personas for selected roles.

References
I've found the following references helpful on this topic 

• forUse: The Electronic Newsletter of Usage-Centered Design #15, August 2001: http://www.foruse.com/newsletter/foruse15.htm
• Use Case Fundamentals, by Alistair Cockburn: http://members.aol.com/acockburn/papers/AltIntro.htm
• Personas in Wikipedia: http://en.wikipedia.org/wiki/Personas
• Personas: Moving Beyond Role-Based Requirements Engineering, by Granville Miller and Laurie Williams:
  http://agile.csc.ncsu.edu/SEMaterials/Personas.pdf