لماذا يبدو أن هياكل التحكم في باسكال غير متناسقة؟

Question

معظم هياكل التحكم في باسكال منطقية بالنسبة لي ، مثل:

for ... do {statement};

if (condition) then {statement};

while (condition) do {statement};

حيث {العبارة} إما عبارة واحدة ، أو أ يبدأ ... نهاية الكتلة. لدي مشكلة مع:

repeat {statement-list} until (expression);

try {statement-list} except {statement-list} end;

ألن يكون ذلك أفضل من ذلك كرر و محاولة احصل على نفس الهيكل العام ، وقبول بيان واحد فقط أو أ يبدأ ... نهاية الكتلة ، بدلاً من وجود قائمة بيانات لم يتم حظرها رسميًا مع أ يبدأ و نهاية?

Answer 1

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

Answer 2

قام نيكلاوس ويرث (مصمم باسكال) بتصحيح هذه التناقضات في لغته القادمة ، Modula-2. في Modula-2 ، مثل البيانات المركبة مثل IF لا يملك BEGIN وإلزامي END:

IF {condition} THEN
    {statement-list}
END;

هياكل التحكم الأخرى مثل WHILE متشابهة ومتسقة مع REPEAT.

Answer 3

السؤال هو: ألا يكون ذلك أفضل؟

الجواب هو: هذا يعتمد ، لأن هذا النوع من الأشياء شخصي تمامًا. ما لم تكن ، أو تفكر في آلة.

نعم ، من شأنه أن يرضي بعض الألم لتطبيق التناسق/النهاية لجميع عبارات المركب ، ولكن عندما توفر عناصر اللغة المحيطة بالفعل حاوية طبيعية ، من الضروري تمامًا أن تتطلب ذلك.

النظر في بيان الحالة:

// "Sensible" syntax

  case VALUE of
    1: DoSomething;
    2: begin
         DoSomethingElse;
         DoMore;
       end;
  else
    DoForAllOtherValues;
    DoMore;
  end;

مقابل أقل عقلانية ولكن أكثر اتساقًا و "منطقية":

  case VALUE of
    1: DoSomething;
    2: begin
         DoSomethingElse;
         DoMore;
       end;
  else
    begin
      DoForAllOtherValues;
      DoMore;
    end;
  end;

لاحظ أن "النهاية" النهائية هي جزء من "الحالة". لا يمكنك الاستغناء عن ذلك.

أنا متأكد تمامًا من أنه في إصدار مبكر من Chrome (الذي أصبح الأكسجين ثم المنشور لاحقًا) ، كان هذا مطلوبًا بالفعل بناء جملة لبيان الحالة. إذا كان الأمر كذلك ، لم يعد الأمر كذلك. من المفترض أن الفطرة السليمة ساد.

في رأيي الشخصي ، فإن إرضاء OGOSC (الآلهة الموضوعية للاتساق النحوي) يغني ربما أقل ، ولكن في الواقع أكثر صلة بك وأنا ، sgohrac (آلهة ذاتية القراءة والفهم).

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

كما في هذه الحالة.

إذا ارتكبت خطأً لا يمكن للمترجم تفسيره ، فسيخبرك ذلك ، في كل مرة تقوم فيها بتجميع. لكن المترجم لن يشكرك على جعل الرمز "أسهل" "للقراءة" (المترجم يتبع ببساطة القواعد التي يتم تقديمها - لا يجعله "أسهل" للمترجم "قراءة" الكود عن طريق تغيير القواعد التي يمكن أن تتبع بالفعل بسعادة مثالية).

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

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

لجعل هذا المركب Bething/End منطقيًا ، يجب أن ندخل "حالة" بيان مستقل ، وليس جزءًا من الزوج/النهاية ، وبالتالي يجب أن تكون كل هذه الجملة صالحة:

  case VALUE of
    1: DoSomething;
    2: DoSomethingElse;


  case VALUE of
    1: DoSomething;
    2: DoSomethingElse;
  else
    DoOther;


  case VALUE of
    1: DoSomething;
    2: begin
         DoSomethingElse;
         DoMore;
       end;
  else
    DoOther;


  case VALUE of
    1: DoSomething;
    2: begin
         DoSomethingElse;
         DoMore;
       end;
  else
  begin
    DoOther;
    DoMoreOther;
  end;


  case VALUE of
    1: DoSomething;
    2: begin
         DoSomethingElse;
         DoMore;
       end;

قد لا توافق ، لكن يبدو لي أن هذا الجملة الأكثر اتساقًا فجأة في الواقع في تناسق أقل في الكود الفعلي ، على الرغم من أن هناك اتساقًا أكبر في القواعد التي يتم كتابة الكود لتتوافق معها.

Answer 4

المحتمل. لكن تصميم اللغة ، وخاصة اللغات مع القليل من التاريخ ، نادراً ما يكون واضحًا أو مثاليًا.

يمكنك رؤية أشياء مماثلة بلغات أخرى. جافا ، على سبيل المثال ، يستوجب كتلة بعد try ولن تسمح ببيان واحد ، على الرغم من أن بيانًا واحدًا قد يعمل أيضًا إذا نظرت إلى هياكل التحكم الأخرى.

لماذا switch في C واللغات المشتقة كتلة واحدة والحالات الفردية لا؟

Answer 5

يتعلق الأمر بالطريقة التي يعمل بها المحلل. ابدأ/نهاية ، حاول/باستثناء وكرر/حتى تحتوي جميعها على كتل من العبارات. يبدو رمز المحلل اللغوي شيء من هذا القبيل ، بالنسبة إلى كتلة البداية (رمز الكاذب):

procedure ReadBlock;
begin
  Match('begin');
  while CurrentToken <> 'end' do
    ReadStatement;
  Match('end');
end;

وهذا يعمل بشكل جيد لهذا النوع من الكتلة. ولكن عندما تحتاج إلى معلومات إضافية في خط نهاية الكتلة (شرطية للتكرار/حتى ، وكتلة معالجة الاستثناء للمحاولة ،) فأنت لا تريد تشغيلها حتى نهاية, ، والتي تتوقع قواعد اللغة أن لا تحتوي على أي شيء بعد ذلك. يمكنك تعديل القواعد ، لكن ذلك من شأنه أن يضيف الكثير من التعقيد إلى المحلل. لذا بدلاً من ذلك ، يمكنك اختيار كلمة رئيسية مختلفة.

Answer 6

أعتقد أنك تطرح السؤال الخطأ. أعني ، قد تكون لا ترى الفرق بين IF/then/for Group and the REFENT/Try Group.

تحتاج المجموعة الأولى إلى شيء (حالة أو حجج) لبدء شيء ما. الثاني ، بدلاً من ذلك ، يعني أن تبدأ شيئًا ما. فقط اقرأ الكلمات: كرر (ما يلي) وجرب (ما يلي).

Pascal نظيف وبسيط وأنيق لأنه مصمم للقراء البشريين العاديين ، وكان البروفيسور ويرث في الاعتبار الأشخاص الذين يتعلمون البرمجة عندما صممها.

Answer 7

أنت محق جزئيًا - على repeat <stmts> until <expr> بيان.

إنه شعور قليلاً من الغش الذي لا تحتاجه إلى بدء تناسق بيان المركب ولكن هذا لتجنب المعاناة التي لا مبرر لها. نظرًا لأنك ترى في جميع الحالات الأخرى ، فأنت بحاجة إلى تأثير قوس البداية لإظهار مكان الجزء من الكود الذي then أو else أو الحلقات do تنطبق على. التكرار حتى هو بيان Pascal الوحيد الذي يمكنني التفكير فيه أنه يستلزم الجزء الثاني الذي تم تجديده بعيدًا -لأنه من المنطقي أن يكون شرط خروج الحلقة نصيًا حيث سيتم فحصه - بعد، بعدما جسم الحلقة. يمكن أن يكون شكل بديل

UNTIL <condition> DO <statement>

UNTIL <condition> DO
  BEGIN
    <statements>
  END

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

في ما يخص try <stmts> except <stmts> end - هذا ليس من تصميم لغة Pascal الأصلية ومواصفاتها ، وقد تم صفع هذا بعد أن قام بعض المنفذ (Borland؟ Freepascal؟) ، لذلك فلا عجب أن يكون غير متناسق - كان الفكر أكثر على خطوط " هل يمكنني القيام بذلك دون كسر البرامج الحالية "من تصميم المواصفات الشاملة. تم تقديم مثال آخر لتمديد اللغة في الإجابة أعلاه - البند الافتراضي else في ال case التبديل - وبينما أجد هذا مفيدًا للغاية واستخدمته مرة أخرى في الأيام في Turbo Pascal - هذا لا يتماشى بشكل فظيع مع استخدامه else في ال if بناء. وهكذا أجد تطبيقًا آخر رأيته واستخدمته بشكل أفضل - otherwise: تليها بيان واحد كما في كل منهما <value>: قضية.