مواصفات لغة البرمجة

في برمجة الحاسوب ، تُعدّ مواصفات لغة البرمجة (أو معيارها أو تعريفها ) وثيقةً أو مرجعًا يُعرّف لغة البرمجة بحيث يتفق المستخدمون والمطورون على معنى البرامج المكتوبة بتلك اللغة. عادةً ما تكون المواصفات مفصلة ورسمية، ويستخدمها المطورون بشكل أساسي، بينما يلجأ إليها المستخدمون في حال وجود أي لبس؛ فمثلاً، تُستشهد بمواصفات لغة C ++ بشكل متكرر من قِبل المستخدمين نظرًا لتعقيدها. تشمل الوثائق ذات الصلة مرجع لغة البرمجة ، المُخصّص للمستخدمين، وشرحًا لمنطق لغة البرمجة، الذي يوضح سبب كتابة المواصفات على النحو الذي هي عليه؛ وعادةً ما تكون هذه الوثائق أقل رسمية من المواصفات نفسها.

التقييس

لا تمتلك جميع لغات البرمجة الرئيسية مواصفات، وقد توجد لغات وتحظى بشعبية لعقود دون مواصفات. قد يكون للغة تطبيق واحد أو أكثر، يعمل سلوكها كمعيار فعلي ، دون توثيق هذا السلوك في مواصفات. تُعد لغة بيرل (حتى بيرل 5 ) مثالًا بارزًا على لغة بدون مواصفات، بينما لم تُحدد مواصفات لغة PHP إلا في عام 2014، بعد استخدامها لمدة 20 عامًا. [ 1 ] يمكن تطبيق اللغة ثم تحديد مواصفاتها، أو تحديد مواصفاتها ثم تطبيقها، أو قد يتطوران معًا، وهو ما يُعد ممارسة شائعة اليوم. يعود ذلك إلى أن التطبيقات والمواصفات توفر آليات للتحقق من بعضها البعض: تتطلب كتابة المواصفات تحديد سلوك التطبيق بدقة، ويتحقق التطبيق من إمكانية تطبيق المواصفات وجدواها واتساقها. وقد تم تجنب كتابة المواصفات قبل التطبيق إلى حد كبير منذ ALGOL 68 (1968)، نظرًا للصعوبات غير المتوقعة في التطبيق عند تأجيله. ومع ذلك، لا تزال اللغات تُنفذ أحيانًا وتكتسب شعبية دون مواصفات رسمية : فالتنفيذ ضروري للاستخدام، بينما المواصفات مرغوبة ولكنها ليست ضرورية (بشكل غير رسمي، "يتحدث الكود").

كانت لغة ALGOL 68 أول لغة رئيسية (وربما واحدة من آخر اللغات الرئيسية) التي تم وضع تعريف رسمي كامل لها قبل تنفيذها.

النماذج

يمكن أن تتخذ مواصفات لغة البرمجة عدة أشكال، بما في ذلك:

بناء الجملة

يمثل بناء جملة لغة البرمجة تعريف الكلمات المقبولة، أي المعايير والقواعد الرسمية التي يُبنى عليها تحديد ما إذا كان الكود المُعطى صالحًا بالنسبة للغة. وبناءً على ذلك، يتكون بناء جملة اللغة عادةً من مزيج من المكونات الثلاثة التالية:

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

علم الدلالة

يُعدّ وضع دلالات دقيقة للغة برمجة كبيرة ومعقدة وعملية مهمة شاقة حتى بالنسبة للمتخصصين ذوي الخبرة، وقد يصعب على أي شخص غير الخبراء فهم المواصفات الناتجة. فيما يلي بعض الطرق التي يمكن من خلالها وصف دلالات لغات البرمجة؛ تستخدم جميع اللغات طريقة وصف واحدة على الأقل من هذه الطرق، وتجمع بعض اللغات بين أكثر من طريقة. [ 5 ]

اللغة الطبيعية

تُحدد معظم اللغات الأكثر استخدامًا باستخدام أوصاف لغوية طبيعية لدلالاتها. وعادةً ما يأخذ هذا الوصف شكل دليل مرجعي للغة. وقد يصل عدد صفحات هذه الأدلة إلى مئات الصفحات؛ فعلى سبيل المثال، يبلغ عدد صفحات النسخة المطبوعة من " مواصفات لغة جافا، الطبعة الثالثة" 596 صفحة. [ 6 ]

قد يؤدي عدم دقة اللغة الطبيعية كوسيلة لوصف دلالات لغات البرمجة إلى مشاكل في تفسير المواصفات. على سبيل المثال، تم تحديد دلالات سلاسل جافا باللغة الإنجليزية، ثم تبين لاحقًا أن المواصفات لم تقدم إرشادات كافية للمطورين. [ 7 ]

الدلالات الرسمية

تستند الدلالات الرسمية إلى الرياضيات، ولذلك فهي أكثر دقةً وأقل غموضًا من الدلالات المُعبر عنها باللغة الطبيعية. مع ذلك، غالبًا ما تُضاف أوصافٌ إضافية باللغة الطبيعية للدلالات لتسهيل فهم التعريفات الرسمية. على سبيل المثال، يحتوي معيار ISO الخاص بـ Modula-2 على تعريف رسمي وآخر باللغة الطبيعية في صفحتين متقابلتين.

يمكن للغات البرمجة التي تُوصف دلالاتها بشكل رسمي أن تجلب فوائد عديدة. على سبيل المثال:

  • تُمكّن الدلالات الرسمية من تقديم براهين رياضية على صحة البرنامج؛
  • تسهل الدلالات الرسمية تصميم أنظمة الأنواع ، والبراهين المتعلقة بسلامة أنظمة الأنواع تلك؛
  • يمكن للدلالات الرسمية أن تضع معايير غير مبهمة وموحدة لتطبيقات اللغة.

يمكن أن يُسهم دعم الأدوات الآلية في تحقيق بعض هذه الفوائد. فعلى سبيل المثال، يُمكن لبرنامج إثبات النظريات أو مدقق النظريات الآلي أن يزيد من ثقة المبرمج (أو مصمم اللغة) في صحة البراهين المتعلقة بالبرامج (أو اللغة نفسها). وتختلف قوة هذه الأدوات وقابليتها للتوسع اختلافًا كبيرًا: فالتحقق الرسمي الكامل يتطلب موارد حاسوبية هائلة، ونادرًا ما يتجاوز البرامج التي تحتوي على بضع مئات من الأسطر ، وقد يتطلب مساعدة يدوية كبيرة من المبرمج؛ أما الأدوات الأخف وزنًا، مثل مدققي النماذج، فتتطلب موارد أقل، وقد استُخدمت في برامج تحتوي على عشرات الآلاف من الأسطر؛ كما تُطبق العديد من المترجمات فحوصات النوع الثابتة على أي برنامج تُترجمه.

التنفيذ المرجعي

التنفيذ المرجعي هو تطبيق وحيد للغة برمجة يُعتبر مرجعياً. ويُعتبر سلوك هذا التطبيق هو المعيار الذي يُحدد السلوك الصحيح لأي برنامج مكتوب بتلك اللغة. يتميز هذا النهج بعدة خصائص جذابة. أولاً، هو دقيق، ولا يتطلب أي تفسير بشري: إذ يُمكن حسم أي خلافات حول معنى البرنامج ببساطة عن طريق تنفيذه على التنفيذ المرجعي (شريطة أن يتصرف هذا التنفيذ بشكل حتمي مع ذلك البرنامج).

من جهة أخرى، ينطوي تعريف دلالات اللغة من خلال تطبيق مرجعي على عدة عيوب محتملة. أبرزها أنه يخلط بين قيود التطبيق المرجعي وخصائص اللغة. على سبيل المثال، إذا احتوى التطبيق المرجعي على خطأ برمجي، فيجب اعتبار هذا الخطأ سلوكًا أساسيًا. ومن العيوب الأخرى أن البرامج المكتوبة بهذه اللغة قد تعتمد على خصائص غير متوقعة في التطبيق المرجعي، مما يعيق قابلية نقلها بين التطبيقات المختلفة.

مع ذلك، نجحت عدة لغات في استخدام أسلوب التنفيذ المرجعي. على سبيل المثال، يُعتبر مترجم لغة بيرل مرجعًا أساسيًا لتحديد سلوك برامج بيرل. في حالة بيرل، ساهم نموذج المصادر المفتوحة لتوزيع البرمجيات في عدم وجود أي تطبيق بديل للغة، مما يجعل المسائل المتعلقة باستخدام تطبيق مرجعي لتحديد دلالات اللغة غير ذات جدوى.

مجموعة الاختبارات

يتضمن تعريف دلالات لغة برمجة من خلال مجموعة اختبارات كتابة عدد من البرامج النموذجية بتلك اللغة، ثم وصف كيفية عمل هذه البرامج - ربما عن طريق كتابة مخرجاتها الصحيحة. تُسمى هذه البرامج، بالإضافة إلى مخرجاتها، "مجموعة الاختبارات" الخاصة باللغة. يجب على أي تطبيق صحيح للغة أن يُنتج مخرجات صحيحة تمامًا على برامج مجموعة الاختبارات.

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

لذلك، في الممارسة الشائعة، لا تُستخدم مجموعات الاختبار إلا بالاشتراك مع إحدى تقنيات تحديد اللغة الأخرى، مثل وصف اللغة الطبيعية أو التنفيذ المرجعي.

انظر أيضاً

مواصفات اللغة

بعض الأمثلة على المواصفات اللغوية الرسمية أو المسودة:

ملحوظات

  1. إعلان عن مواصفات لغة PHP ، 30 يوليو 2014، بقلم جويل مارسي
  2. "تاريخ مختصر لبرنامج Algol68" . مؤرشف من الأصل في 10 أغسطس 2006. تم الاطلاع عليه في 15 سبتمبر 2006 .
  3. ميلنر، رم. توفت ؛ ر. هاربر ؛ د. ماكوين (1997). تعريف لغة ML القياسية (مراجعة) . مطبعة معهد ماساتشوستس للتكنولوجيا. ISBN 0-262-63181-4.
  4. كيلسي، ريتشارد؛ ويليام كلينجر؛ جوناثان ريس (فبراير 1998). "القسم 7.2 الدلالات الرسمية" . التقرير الخامس المنقح حول مخطط لغة الخوارزميات . تم الاطلاع عليه بتاريخ 9 يونيو 2006 .
  5. جونز، د. (2008). أشكال تحديد اللغة (ملف PDF) . تم الاسترجاع في 23-06-2012 .
  6. جوسلينج، جيمس؛ جوي، بيل؛ ستيل، جاي؛ براخا، جلعاد (يونيو 2005). "مواصفات لغة جافا، الطبعة الثالثة" . أديسون-ويسلي لونجمان.
  7. ويليام بو. نموذج ذاكرة جافا معيب بشكل خطير. التزامن: الممارسة والتجربة 12(6):445-455، أغسطس 2000