مفسّر Python يتّسع في 1024 بايت من لغة C

معظم مشاريع عطلة نهاية الأسبوع لدى أوستن هينلي ذريعة لكتابة الشيفرة يدويًا، وجاء آخرها بميزانية صارمة: مفسّر Python بلغة C يتّسع في 512 بايت من الشيفرة. تبيّن أن هذا الهدف بعيد المنال — إذ لم تكن مهاراته في code golf كافية على حد قوله — فاكتفى بـ1024 بايت، دون حيل الماكرو ودون مكتبات تؤدي العمل الثقيل.

كان برنامج الاختبار نسخة fizzbuzz تبدو بوضوح شبيهة بـPython: فيها def والنقطتان والإزاحة، ومن دون أقواس حول شرط if. لا يتّسع إلا لجزء من اللغة، والقواعد صارمة.

ما يفعله المفسّر وما يرفض فعله

لا توجد أي معالجة للأخطاء: يفترض المفسّر أن الكلمات المفتاحية مكتوبة بشكل صحيح وأن حدود الرموز دقيقة. وهو يحذف معظم الفراغات أثناء قراءة البرنامج، ولا يحتفظ إلا بالإضافة والمسافات داخل النصوص الحرفية. أسماء المتغيرات والدوال محدودة بحرف واحد صغير، ما يجعل البحث في جدول الرموز فهرسًا مباشرًا في مصفوفة لا مسحًا. وتُحفظ الحالة في عدد قليل من المتغيرات العامة: مخزن مصدر بحجم 999 بايت، وجدول رموز بـ256 خانة، وعدد من مؤشرات الموضع.

تنفيذ بلا شجرة نصية مجردة

لا يكاد التصميم يشترك مع CPython في شيء، فالأخير يجزّئ الشيفرة إلى رموز، ويبني شجرة نصية مجردة، ويحلّلها، ويترجمها إلى bytecode، ثم يفسّرها. أما نسخة هينلي فتستعمل التحليل التنازلي التكراري وتنفّذ التعابير أثناء التحليل؛ تعود الكتلة عندما تقل الإزاحة، فيتولى مكدس الاستدعاءات في C معالجة التداخل. لا شيء يُترجم، لذا تعمل الحلقات بالقفز إلى الخلف وإعادة تحليل المصدر في كل تكرار مع تذكّر موضع الشرط. وعند استدعاء دالة يُحفظ موضع المستدعي، ثم يُقفز إلى الجسم، ويُستعاد الموضع في النهاية.

كيف وصل إلى 1024 بايت

تطلّب الانتقال من نسخة مقروءة تتجاوز 4800 بايت إلى 1024 بايت جولف عاديًا: أسماء أقصر، وإسقاط الأقواس غير الضرورية، وحيل من موضوع قديم على Stack Overflow عن الجولف في C، بما يشمل خصائص GNU C89. تحوّلت دالة تحليل بأربع وسائط إلى سطر واحد يستخدم حساب ASCII لتحديد العامل المقروء؛ وتقلّصت دالة مساعدة تكرارية للتخطي إلى نهاية السطر إلى Y(){c&&c-10&&Y(G());}. وكانت عوامل المقارنة التالية في القائمة — فالقيم الصدقية تُبقي if n%15: عاملًا — ويقدّر هينلي أن نسخة مخصّصة لـfizzbuzz وحده قد تنزل تحت 800 بايت. النسختان متاحتان على GitHub.