پیشگفتار
"pawn" زبان "اسکریپت‌نویسی" ساده، بدون نوع، 32-بیتی با نحو شبیه C است. سرعت اجرا، پایداری، سادگی و حجم کم معیارهای طراحی اساسی برای زبان و مفسر/ماشین انتزاعی که برنامه pawn روی آن اجرا می‌شود بودند.
یک برنامه کاربردی یا ابزار نمی‌تواند همه کار را برای همه کاربران انجام دهد یا باشد. این نه
سایر سیستم‌های نرم‌افزاری، حضور گزینه‌های پیکربندی گسترده و زبان‌های ماکرو یا اسکریپت‌نویسی در برنامه‌های کاربردی را نیز توضیح می‌دهد. برنامه‌های کاربردی خودم حاوی انواع مختلفی از زبان‌های کوچک بوده‌اند؛ بیشتر بسیار ساده بودند، برخی گسترده بودند. . . و بیشتر نیازها می‌توانست با زبان عمومی منظوره با کتابخانه‌ای با منظور خاص حل شود. از این رو، pawn.
زبان pawn به عنوان زبانی انعطاف‌پذیر برای دستکاری اشیاء در برنامه میزبان طراحی شد. مجموعه ابزارها (کامپایلر، ماشین انتزاعی) طوری نوشته شدند که به راحتی قابل گسترش باشند و روی معماری‌های مختلف نرم‌افزار/سخت‌افزار اجرا شوند.
♦
pawn نسلی از Small C اصلی توسط Ron Cain و James Hendrix است، که به نوبه خود زیرمجموعه‌ای از C بود. برخی از اصلاحاتی که من روی Small C انجام دادم، مثلاً حذف سیستم نوع و جایگزینی اشاره‌گرها با مراجع، آنقدر بنیادی بود که به سختی می‌توانستم زبانم را "زیرمجموعه
C" یا "گویش C" بنامم. بنابراین، "C" را از عنوان حذف کردم و از نام "Small" برای نام زبان در انتشارم در Dr. Dobb's Journal و سال‌هایی که از آن گذشته استفاده کردم. در طول توسعه و نگهداری محصول، درخواست‌های زیادی برای تغییرات دریافت کردم. یکی از تغییرات مکرر درخواستی استفاده از نام متفاوت برای زبان بود —جستجو برای اطلاعات در مورد زبان اسکریپت‌نویسی Small در اینترنت به دلیل "small" بودن کلمه‌ای رایج مانع می‌شد. تغییر نام همزمان با تغییر مهمی در زبان رخ داد: پشتیبانی از "state" ها (و ماشین‌های state).
من مدیون Ron Cain و James Hendrix (و اخیراً، Andy Yuen) و Dr. Dobb's Journal برای شروع این توپ هستم. اگرچه باید تقریباً هر خط کد اصلی را بارها لمس کرده باشم، منشاء Small C همچنان به وضوح قابل مشاهده است.
♦
بحث مفصلی از اهداف و مصالحات طراحی در ضمیمه C است؛ اینجا می‌خواهم چند نکته کلیدی را خلاصه کنم. همان‌طور که در پاراگراف‌های قبلی نوشته شد، pawn برای سفارشی کردن برنامه‌های کاربردی (با نوشتن اسکریپت) است، نه برای نوشتن برنامه‌های کاربردی. pawn در ساختار داده ضعیف است چون برنامه‌های pawn برای دستکاری اشیاء (متن، sprite ها، stream ها، کوئری‌ها، . . . ) در برنامه میزبان در نظر گرفته شده‌اند، اما برنامه pawn، عمداً، دسترسی مستقیم به هر داده‌ای خارج از ماشین انتزاعی‌اش ممنوع است. تنها ابزاری که برنامه pawn برای دستکاری اشیاء در برنامه میزبان دارد فراخوانی زیربرنامه‌هاست، به اصطلاح "توابع native"، که برنامه میزبان ارائه می‌دهد.
pawn در آن حوزه کلیدی انعطاف‌پذیر است: فراخوانی توابع. pawn مقدارهای پیش‌فرض برای هر یک از آرگومان‌های تابع پشتیبانی می‌کند (نه فقط آخری)، فراخوانی با مرجع و همچنین فراخوانی با مقدار، و آرگومان‌های تابع "نام‌دار" و همچنین "موقعیتی". pawn مکانیزم "بررسی نوع" ندارد، به واسطه زبان بدون نوع بودن، اما در عوض مکانیزم "بررسی طبقه‌بندی" ارائه می‌دهد که "tag" نامیده می‌شود. سیستم tag مخصوصاً برای آرگومان‌های تابع راحت است چون هر آرگومان می‌تواند چندین tag قابل قبول مشخص کند.
اما در ترکیبشان. برای pawn، احساس می‌کنم که ترکیب آرگومان‌های نام‌دار —که به شما اجازه می‌دهد آرگومان‌های تابع را به هر ترتیبی مشخص کنید، و مقدارهای پیش‌فرض —که به شما اجازه می‌دهد مشخص کردن آرگومان‌هایی که علاقه‌ای به آن‌ها ندارید را رد کنید، با هم ترکیب شده و راه راحت و "توصیفی" برای فراخوانی توابع (native) برای دستکاری اشیاء در برنامه میزبان ایجاد می‌کنند.