نگاهی به پیاده‌سازی Union Types و Option Types در زبان برنامه‌نویسی Copper

طراحی یک زبان برنامه‌نویسی سطح پایین اما امن، چالش‌های ظریفی دارد. مقاله جدید طراح زبان Copper نگاهی عمیق دارد به تجربه پیاده‌سازی Union Types و در نهایت عقب‌نشینی به سمت استفاده از Option Types ساده‌تر. در این مطلب قصد داریم به جزئیات فنی این تصمیم، مزایا و معایب آن بپردازیم.

مفهوم Union Types و چالش‌های آن در Copper

نوع اجتماع یا Union Type به مقداری اشاره دارد که می‌تواند یکی از چندین نوع مختلف باشد؛ مثلاً Int | String. در زبان Copper (یک زبان با هدف جایگزینی بهتر با C)، نویسنده تلاش کرد تا حالت عمومی T1 | T2 | ... | Tn را با استفاده از تگ‌ها پیاده‌سازی کند. همچنین حالت خاص Pointer | Nothing بدون تگ اضافی و با تکیه بر مقدار NULL مدیریت می‌شد تا همگام با کتابخانه‌های خارجی سریع و کارآمد بماند.

با این حال، پیچیدگی کامپایلر به شدت افزایش یافت. محدودیت‌هایی مانند عدم اجازه دادن به انواع تو در تو (T1|T2)|T3 یا ترتیب مهم بودن انواع (T1|T2 با T2|T1 فرق دارد) برای ساده‌سازی کامپایلر اعمال شد. نتیجه این شد که پیاده‌سازی عمومی بیش از حد برای یک زبان سطح پایین پیچیده بود و توسعه‌دهنده تصمیم گرفت به گزینه محدودتر یعنی Option Types روی بیاورد.

گذر به Option Types و مدیریت Nil

نوع اختیاری یا Option Type در واقع حالت خاصی از Union است که به شکل T | Nothing تعریف می‌شود و نشان‌دهنده عبرداری است که ممکن است مقداری نداشته باشد (T?). رویکرد پیاده‌سازی در Copper هوشمندانه است: رزرو کردن یکی از مقادیر موجود در نوع اصلی بدون نیاز به تگ اضافه.

• برای پوینترها: آدرس 0 به عنوان nil.
• برای اعداد صحیح علامت‌دار: مقدار -1 به عنوان مقدار نامعتبر.
• برای داده‌های دیگر: رزرو مقادیری خاص (مانند رنگ‌های RGB).

این روش کاملاً با APIهای بومی C سازگار است، کارایی بالایی دارد و هیچ سرباری بابت تگ تحمیل نمی‌کند.

پالایش نوع (Type Refinement) و عملگر as

برای استفاده از مقدار درون یک Option، ابتدا باید بررسی شود که nil نباشد. نویسنده برای حل این مسئله از عملگر as استفاده کرده است تا متغیر محرمی در یک اسکوپ پنهان ایجاد شود:

if expr as x
    // متغیر x در اینجا از نوع T است و قابل دسترس
end

برای جلوگیری از الگوی ضدالگوی پیکان (Arrow Anti-Pattern) در بازگشت‌های زودهنگام، ساختارهایی مثل or else معرفی شدند تا بلوک در صورت nil بودن اجرا شود:

var v1 = expr1 or else return err1 end

مقایسه با تحلیل‌گر Nil (مشابه TypeScript و Kotlin)

در رویکرد جایگزین، کامپایلر بر اساس بررسی‌های درون کد (مانند بررسی v1 <> nil) به صورت خودکار نوع متغیر را پالایش می‌کند. اگرچه این روش برای خواننده کد بسیار تمیز و بدون دردسر است، اما در عمل مشکلاتی ایجاد می‌کند:

• نیاز به تحلیل چندمرحله‌ای (Two-pass analysis) روی حلقه‌ها دارد.
• در کدهای جنریک (Generics) به خوبی کار نمی‌کند زیرا نوع متغیر تغییر نمی‌کند.
• به نوعی «جادوی سیاه» تبدیل می‌شود که درک عملکرد کامپایلر را دشوار می‌کند.

به همین دلیل، نویسنده در نهایت ترجیح داد روش مبتنی بر بررسی صریح را حفظ کند و متدهای کمکی مانند notNil را برای مواردی که توسعه‌دهنده از وجود مقدار مطمئن است، ارائه دهد.

چرا این مباحث برای مهندسان نرم‌افزار مهم است؟

اشتباهات ناشی از مقادیر تهی (Null References) که از آن با عنوان «اشتباه یک میلیارد دلاری» یاد می‌شود، همواره منشاء باگ‌های خطرناک در سیستم‌های نرم‌افزاری بوده‌اند. استفاده از Option Types به جای پوینترهای خام ناامن، نیت توسعه‌دهنده را واضح‌تر می‌کند، از دره‌رفتن تصادفی جلوگیری می‌نماید و با ماهیت زبان‌های ایستا (Statically Typed) کاملاً همخوانی دارد.

در بحث‌های وب‌سایت Hacker News نیز کاربران به نکات جالبی اشاره کردند؛ از جمله ترفند قرار دادن تگ Union در انتهای ساختار داده برای جلوگیری از نیاز به تغییر آدرس پوینتر، و همچنین چالش‌های طراحی ویژگی‌های بین زبانی (Cross-language features) که نشان می‌دهد انتخاب این الگوها چقدر در مهندسی کامپایلر حساس است.