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

عند استخدام المسجلات (_e.g._ للنوع int ) نحتاج إلى مُخصص لربط رقم التسجيل و cs التي نستخدمها للوصول. في المقابل ، ليست هناك حاجة للتخزين القائم على الماكرو. وبالتالي ، بينما يمكن استخدام \cs_set_eq:NN لإنشاء أسماء tl (على سبيل المثال) ، فإنها ستفشل مع أي شيء باستخدام المسجلات:

\int_set_eq:NN \l_undeclared_int \l_tmpa_in

سيرفع خطأ.

من الممكن إنشاء مخصص سجل محلي ، وقد جربنا ذلك في الماضي لـ _e.g._ \int_local_new:N . (انظر الحزمة etex لأحد هذه التطبيقات ، أو انظر إلى الوراء من خلال expl3 التاريخ.) قرر الفريق في النهاية ضد هذا لأنه لا يبدو أنه "مناسب" بشكل جيد مع نطاق TeX. المفتاح هنا هو أن تجميع TeX لا يعتمد على الإعلانات بل على مجموعات صريحة ، وأن هناك متغيرًا محليًا موجودًا داخل أي مجموعات متداخلة:

\begingroup
  \def\foo{}
  \begingroup
  \show\foo

عندما جربنا "الإنشاء" المحلي للمتغيرات ، بدا أن هناك خطر التعتيم على كيفية عمل مجموعة TeX ، ويمكن تضليل المبرمجين.

لذلك قررنا استخدام "إعلان_كل عام" للمتغيرات ، ولكن مع كل من الإعدادات المحلية والعالمية لهذه المتغيرات (اتفاقية \l_... _versus \g_... ). هذا يحدد الشيء المهم: القيمة. لذلك نوصي بأن تكون جميع الإعلانات في المستوى الأعلى

\tl_new:N \l_my_tl
\int_new:N \l_my_int

...
\cs_new_protected:Npn \my_func:nn #1#2
  {
    \group_begin:
      \tl_set:Nx \l_my_tl { \tl_lower_case:n {#1} }

حتى الآن ، يبدو أن هذا النمط يعمل جيدًا للمهام التي تم استخدام expl3 من أجلها.

في tex ، حتى المتغيرات المحددة محليًا لا يتم تدميرها بالكامل بعد نهاية المجموعة. ما زالوا يستخدمون بعض مساحة السلسلة: https://tex.stackexchange.com/questions/316999/release-space-in-the-string-pool. لذا فمن الأفضل أن تنظر إلى المتغيرات على أنها كائنات عالمية.

@ u - fischer نقطة جيدة: لم نعتبرها في الواقع واحدة في ذلك الوقت ولكن تستحق أن تؤخذ في الاعتبار.

في رأيي هذا النهج خاطئ. إنه يتعارض مع مبادئ البرمجة المهيكلة ، ويتعارض مع TeX ، مما يتيح إنشاء متغيرات محلية. كما أنه يجعل LaTeX3 غير متسق ، لأن بعض أنواع البيانات تتلاءم مع المتغيرات المحلية والبعض الآخر لا.

أود أن أطلب منكم إعادة إنشاء المتغيرات المحلية من جميع الأنواع. يمنح هذا المبرمجين خيارًا: أولئك الذين يفضلون تحديد جميع المتغيرات عالميًا يمكنهم القيام بذلك ، وأولئك الذين يرغبون في تحديد بعضها عالميًا وبعضها محليًا يمكنهم القيام بذلك أيضًا.

إذا كانت هناك محاذير ، تتعلق بالذاكرة أو غير ذلك ، فيمكن ذكرها في الوثائق.

في 18 أكتوبر 2017 الساعة 21:17 ، كتب EvanAad [email protected] :

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

بالنسبة للمتغيرات بناءً على نوع السجل ، فأنت تقوم بتخصيص الموارد من ملف
تجمع عالمي ثابت لذا فإن التخصيص العالمي للاسم هو في الواقع أكثر من ذلك بكثير
طبيعي >> صفة. بالنظر إلى أننا نفترض etex ، فهناك أكثر من 256 سجلًا من
لكل نوع ، ربما يمكن إخفاء سلوك التخصيص أكثر منه
يمكن باستخدام tex الكلاسيكي ولكنه لا يزال سمة أساسية من سمات
نظام TeX الأساسي. لا يمكن أن يكون expl3 برنامجًا عامًا تمامًا
اللغة: يجب أن تعمل مع نظام TeX الأساسي. يجب أن لا تكون
مقارنة بـ C # ولكن مع اللغات الأخرى المستندة إلى TeX وعلى وجه الخصوص مع
\ newcount والأصدقاء.

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

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

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

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

مناشدة اللغات ذات الأغراض العامة ليست حالة استخدام جيدة.

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

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

لنفترض أن متغير العدد الصحيح المحلي الخاص بك \x تم تعيينه لتسجيل 100 والذي تم أخذه بالفعل بواسطة المتغير \y في مستوى أعلى ؛ استخدام \y في نفس المستوى حيث يتم تعريف \x محليًا سيكون ببساطة كارثيًا. وبالتالي ، هناك حاجة إلى مسك الدفاتر العالمية للسجلات المخصصة ، مما يجعل من الصعب للغاية تحرير السجلات المخصصة محليًا. إن حجز مجموعة من السجلات للتعيينات المحلية ليس حلاً.

أنا لا أقول أنه لا يمكن فعل ذلك ، لكنني لا أعتقد أنه يستحق الألم.

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

في 18 أكتوبر 2017 الساعة 21:43 ، كتب EvanAad [email protected] :

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

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

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/latex3/latex3/issues/410#issuecomment-337721923 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/ABNcAimMfBDqA-e96Q7tkS-ERr5fv_2Mks5stmLqgaJpZM4P-Mpq
.

النقطة الحاسمة هي أنه ، كما ذكر جوزيف وديفيد ، السماح بتعريف int s محليًا يمكن ( وقد تم ). وأعتقد أنه يستحق الألم من أجل خلق لغة الهدايا طبقة تجريد تتفق التي هي في الاتفاق مع مبادئ البرمجة منظم.

ومع ذلك ، من السهل علي أن أقول إن الأمر يستحق الألم ، لأنني لست الشخص الذي أتعرض لألم تطبيق لغة LaTeX3. لذلك دعونا نتخذ نهجًا رحيمًا ، ونقول إنه في الواقع لا يستحق الألم. بخير. في هذه الحالة ، قسّم أنواع البيانات إلى فئتين: تلك التي تسمح بإنشاء متغيرات محلية ، وتلك التي لا تسمح بذلك. ووصف هذه الفئات في الكتيبات. لا تقل: يجب التصريح عن جميع المتغيرات قبل الاستخدام. قل: "هناك فئتان من أنواع البيانات. الأولى ، تتكون من cs ، tl ، clist ، ... تستوعب المتغيرات المحلية ، والثانية تتكون من int ... لا. " وشرح سبب وجود الفئة الثانية. بهذه الطريقة يكون التوثيق صحيحًا بالنسبة للحقائق ، والمبرمجون على دراية جيدة ولديهم خيار. لا تحتاج بعض البرامج إلى استخدام أنواع بيانات من الفئة الثانية على الإطلاق ، وفي هذه الحالات لماذا يتعين على المبرمج أن يعلن عن المتغيرات العامة؟

EvanAad أظن أن هذا لأنني \l_... / \g_... ). حقيقة أنها مخصصة / "محفوظة" على الصعيد العالمي لا تتعارض مع ذلك.

راجع للشغل ، لا نريد ربط الواجهات بالتنفيذ: على سبيل المثال ، يحتوي نوع البيانات prop على الأقل على تطبيقين مختلفين أعرفهما ، أحدهما يستخدم السجلات والتطبيق الحالي باستخدام وحدات الماكرو.

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

\group_begin:
  \int_new_local:N \l_tmpa_int
  \int_gset:Nn \l_tmpa_int {7}
\group_end:
% `\l_tmpa_int` undefined

ضد

\group_begin:
  \tl_new_local:N \l_tmpa_tl
  \tl_gset:Nn \l_tmpa_tl {7}
\group_end:
% `\l_tmpa_tl` defined as `7`

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

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

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

... هذا يتفق مع مبادئ البرمجة المهيكلة.

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

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

wspr : لماذا أغلقت هذه المشكلة مثل الفتوة؟ إنه أي شيء إلا أنه مستقر.

EvanAad - فقط أحاول إبقاء الأمور مرتبة. يمكن أن تستمر المناقشة بالتأكيد وسنعيد فتح إذا لزم الأمر.

أقفل هذه المشكلات مؤقتًا بسبب بعض التعليقات الساخنة.

أعتقد أن هذا سؤال وثيق الصلة. يجب أن تكون إحدى نتائج هذه المناقشة على الأقل أننا نصف بدقة أكبر في المستند سبب اختيارنا للإعلانات العالمية فقط. EvanAad لا أعتقد أنك تقدر تمامًا قيود نظام TeX ، لكن دعنا نتراجع ونتجاهل هذه المشكلة للحظة. هل يمكنك إعطاء مثال (من 10 إلى 20 سطرًا ، على سبيل المثال) باستخدام افتراضي \int_local_new:N أو نظام مختلف من اختيارك مع دلالات من اختيارك؟ سيساعد ذلك في تأطير المناقشة في إطار أكثر واقعية ، ويمكننا تفكيك الفوائد / العيوب.

من المفترض أن ننتظر حتى رفع القفل ، لا أعرف كيف أفعل ذلك. على أي حال ، سينام معظم الأشخاص في هذه المحادثة لبضع ساعات. (بالمناسبة ، لا أعتقد أن نسخ # 410 إلى # 411 كمناقشة مختلطة كان معقولاً للغاية).

بالنظر إلى حقيقة أن هذه مناقشة مفصلة تمامًا ، أعتقد أنه من المفيد تلخيص التاريخ التقني والاجتماعي الذي أوصلنا إلى ما نحن عليه الآن.

على المستوى التقني ، توفر TeX السجلات ووحدات الماكرو للتخزين. يمكن فقط "إنشاء" وحدات الماكرو باستخدام \def ، ولكن لاستخدام السجلات بالاسم ، نحتاج إلى بعض المخصص لربط رقم التسجيل العالمي ، _e.g._ \count40 ، إلى اسم ما ، على سبيل المثال \mycount . تم توفير ذلك من "اليوم الأول" ، مع تقديم TeX \newcount ، _etc._ النموذج. بشكل واضح ، يخصص \newcount عالميًا ، وعلى الرغم من الاسم ، لا يقوم بأي فحص. اعتمدت التنسيقات الأخرى ، وأبرزها LaTeX2e و ConTeXt ، هذا النهج بشكل عام. لقد تبنوا أيضًا بشكل عام فكرة أن السجلات الفردية يتم "تخصيصها" إما محليًا أو عالميًا ، لأن هذا يمنع تراكم مكدس الحفظ.

قدم TeX90 256 سجلاً فقط للأنواع الشائعة ، لذا فإن إعادة استخدام التسجيل في السياقات المحلية كان أمرًا حيويًا. يرى المرء أنه في _e.g._ graphics حيث يتم الاحتفاظ بالرمز "عاقلًا" ، يتم إعطاء عدد كبير من السجلات أسماء جديدة داخل مجموعة ، ويتم استخدامها محليًا بحت. مع e-TeX ، لدينا عدد أكبر من السجلات ، لذا فإن هذا الأسلوب أقل أهمية: يمكننا بحرية تخصيص المزيد من السجلات (ووحدات الماكرو) للأغراض المخصصة. على وجه الخصوص ، هذا يعني أننا لسنا مضطرين إلى "إعادة تدوير" السجلات تحت أسماء متعددة.

ظل الكود الأساسي expl3 قيد التطوير لفترة طويلة ، ولم يكن يتطلب في الأصل e-TeX. يتم تطوير expl3 أيضًا بشكل أساسي "على" LaTeX2e ، مع مبدأ عام أن expl3 لا يلوث مساحة اسم المستند ولا يغير سلوكيات LaTeX2e الأساسية.

على وجه الخصوص ، علينا أن نضع في اعتبارنا أن LaTeX2e \newcount لـ LaTeX2e يشبه العادي: يخصص عالميًا ولا يتحقق. وبالتالي على وجه الخصوص

\def\foo{%
  \begingroup
    \newcount\localfoocnt

هو "أسلوب سيء" كما لو أن \foo تم استدعاؤه عدة مرات ثم سنستخدم السجلات التي لم يتم إصدارها مطلقًا.

بالنسبة إلى expl3 ، حاول الفريق تجنب ربط السلوك الموثق للمتغيرات بتنفيذ وحدات الماكرو أو السجلات. (ألاحظ أننا نسمح باستخدام tl بدون ملحق ، والذي يعتمد في النهاية على كونهم وحدات ماكرو.) كما أننا ما زلنا نستخدم السجلات للأعداد الصحيحة ، والأبعاد ، وما إلى ذلك. أداء أفضل و "إنهاء ذاتي" من القيام بكل شيء في وحدات الماكرو. (سيكون ذلك ممكنًا باستخدام e-TeX والأساسيات المختلفة \<thing>expr .) على هذا النحو ، نحتاج إلى نظام مخصص ، ولكي نكون متسقين ، نخصص جميع أنواع المتغيرات ، وليس فقط تلك التي تستند إلى السجلات . كما لاحظ EvanAad ، عندما يكون التحقق غير نشط ، يمكن للمرء أن يفعل _ على سبيل المثال \tl_set_eq:NN \l_new_tl \l_existing_tl بدون خطأ ، لكن هذا ليس السلوك المدعوم (سيؤدي التحقق إلى تمييزه ، على سبيل المثال).

كجزء من مخصص expl3 ، تم اتخاذ القرار بأن يتحقق وجود new _ ، على عكس \newcount ، لذا

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_new:N \l_my_tl

سيؤدي إلى _الخطأ_ إذا تم استخدام \my_foo: بشكل متكرر. هذا يدفع المرء في الاتجاه الذي كان ممارسة TeX القياسية منذ الأيام الأولى من عادي: التخصيصات تذهب خارج الماكرو. (لاحظ أنه في الوضع العادي ، يكون \newcount هو \outer لذا فهو "ممنوع" داخل وحدات الماكرو.)

\tl_new:N \l_my_tl
\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_clear:N \l_my_tl

قدمت حزمة etex منذ سنوات عديدة مُخصص سجل يمكنه القيام بالتخصيص المحلي والعالمي للسجل ، \loccount _versus_ \globcount ، _etc. لبعض الوقت ، تم تحميل expl3 etex وتم استخدامه لتوفير وظائف مقابل \int_local_new:N وما شابه. بالنظر إلى حقيقة أن معظم مبرمجي TeX معتادون على القيام بالتخصيص العالمي ، فربما ليس من المستغرب أن هذا لم يتم تناوله على نطاق واسع. ومع ذلك ، كان الفريق قلقًا أيضًا بشأن سوء الفهم المحتمل. بشيء مثل

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_local_new:N \l_my_tl

لدينا سؤال حول ما يحدث للمكالمات المتداخلة إلى \my_foo: ، أو الأماكن الأكثر احتمالًا حيث يتم استخدام بعض الأسماء "البسيطة" مثل \l_my_tmp_tl . استنادًا إلى الفكرة العامة التي مفادها أننا نريد new لإجراء الشيكات ، يجب أن يكون هذا خطأ. قد يجد المبرمجون القادمون من العديد من اللغات الأخرى هذا غريبًا إلى حد ما. بالطبع ، إنه يتناسب مع قواعد نطاق TeX.

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

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

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

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

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

هنا ، في الوقت الحالي ، أعتقد أنني لا أرى الخطأ في النهج "المعتاد" لـ

\tl_new:N \l_my_tl
\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_clear:N \l_my_tl

على الأقل إلى النقطة التي يُطلب فيها العودة وتغيير الإعداد الحالي.

blefloch نعم ، أوافق على أن رد فعلي على إغلاق wspr للخيط كان غير معقول وأنا أعتذر له

josephwright شكرا لك على الرد المفصل. بعد التفكير في الأمر ، أدركت أنه إذا استخدمت \<module>_clear_new:N ، فعندئذٍ ستتصرف جميع المتغيرات الخاصة بي كما لو كانت محلية للمجموعة المحيطة ، طالما أنني أسندها باستخدام \<module>_set... بدلاً من \<module>_gset... . علاوة على ذلك ، أعتقد أن هذه الممارسة تتفق مع اتفاقية LaTeX3 للإعلان عن متغير قبل الاستخدام ، لذلك لن يتم وضع علامة علي إذا كانت عمليات التحقق قيد التشغيل.

باتباع هذه الممارسة ، سأعيد كتابة

\cs_new_protected:Npn \my_foo:
{
    \group_begin:
        \tl_clear_new:N \l_my_tl

نوع البيانات الوحيد الذي لا يتناسب مع هذا المخطط هو cs ، ولكن بقدر ما أعرف أنه من القانوني إنشاء متغيرات من هذا النوع باستخدام \cs_set:Npn et al. دون الإعلان عنها أولاً ، لأن LaTeX3 لا يتعامل مع cs كنوع بيانات عادي على قدم المساواة مع الآخرين (وهي مسألة منفصلة أود تناولها معكم يا رفاق ، لكنني سأغادر إلى موضوع آخر). باستخدام هذا الأسلوب ، يمكن أيضًا إنشاء متغيرات cs محليًا. إذا كنت أرغب في الحفاظ على اتساق البنية ، فيمكنني دائمًا كتابة غلافي \cs_clear_new:N .

لذا ، بقدر ما أشعر بالقلق ، يمكنك الآن إغلاق هذه المشكلة إذا أردت ، wspr .

EvanAad في \<thing>_clear_new:N ، لاحظ أن الإعلان _is_ global حيث لا يوجد المتغير بالفعل. وبالتالي

\cs_new_protected:Npn \my_foo:
{
    \group_begin:
        \tl_clear_new:N \l_my_tl
    \group_end:
}
\my_foo:
\tl_show:N \l_my_tl

سيظهر أن \l_my_tl معرف وفارغ ، بافتراض أنك لم تقم بتعيينه مسبقًا على شيء آخر.

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

1. هل سيكون سلوك اللغة غير محدد؟
2. هل عدم الالتزام مدعوم حاليًا ، ولكن قد لا يكون كذلك في الإصدارات المستقبلية؟
3. هل سيبلغ المحرك عن خطأ؟
4. هل سيبلغ المحرك عن خطأ ، ولكن فقط عند إجراء الفحوصات؟
5. هل سينتج عن ذلك بعض المضايقات البسيطة؟
6. هل سيتذمر فريق LaTeX3 في حالة من السخط ، ولكن لا ينتج عن ذلك خطأ أو فقدان للوظائف؟

كمثال لـ 5 ، خذ اصطلاح إلحاق مواصفات الوسيطة بنهاية اسم الوظيفة. بقدر ما أستطيع أن أقول ، فإن الوظيفة الوحيدة التي لن تعمل بشكل صحيح إذا لم يتم الالتزام بهذه الاتفاقية هي \cs_new:Nn ، لكن الباقي ، بما في ذلك "cs_ new: Npn " سيعمل بشكل جيد.

كمثال لـ 6 ، خذ اصطلاح تعليم المتغيرات المحلية والعالمية بـ \g_... و \l_... . وبقدر ما أعلم لن تكون هناك أي تداعيات على الإطلاق لعدم اتباع هذه الاتفاقية. كل شيء سيعمل بشكل صحيح.

EvanAad - تم قبول الاعتذار ، وأنا آسف من جانبي لإغلاق القضية قبل اكتمال المناقشة.

josephwright -

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_new_local:N \l_my_tl
      ...

ثم أعلم أن \l_my_tl ليس فقط خاليًا من التداخل من الخارج ، ولكن على عكس استخدام الدالة _clear فأنا أعلم أن كل آثار المتغير قد اختفت خارج نطاق استخدام الوظيفة. بعبارة أخرى ، بمجرد النظر إلى الكود ، أعلم أنه لا يمكن استخدامه كمتغير شبه عام أسفل السطر. (ويمكنني التحقق من عدم حدوث أي شيء غريب باستخدام \tl_if_exist_p:N .)

(يجب تشغيله ولكن يمكنك المتابعة لاحقًا إذا كان هناك أي سبب لمزيد من المناقشة.)

wspr نعم ولكن هذا يعود إلى حقيقة أنه يعتمد على نطاق مجموعة TeX. لذلك يمكن استخدامه "شبه عالمي" في بناء النموذج

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_new_local:N \l_my_tl
      \tl_set:Nn \l_my_tl { foo }
      \__my_foo:
     ..
  }
\cs_new_protected:Npn \__my_foo:
  {
    \group_begin:
        \tl_use:N \l_my_foo % Definition from \my_foo: => "foo"
...
  }

والذي كان على الأقل جزءًا من تفكيرنا.

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

josephwright - لم أر ذلك أبدًا كمثال محير ؛ في Matlab على سبيل المثال يميزون بين الوظائف الفرعية التي لا تشترك في النطاق ، والوظائف الفرعية المتداخلة التي تقوم بذلك. لذا ، حسب تفكيري ، كان هذا دائمًا ، حسنًا ، لماذا لا يرث \__my_foo: نطاق الوظيفة "الخارجية"؟ إنه متوافق تمامًا مع سلوك مجموعة TeX.

(آسف لاستمرار المناقشة. لقد مضى يوم طويل. هل هناك أي شخص مهتم بالمتابعة فعلاً؟)

صباحا 19.10.2017 أم 09:23 سكريب جوزيف رايت:

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

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

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

ومع ذلك ، فإننا نقدم وحدة فحص (تعمل كم مرة أبطأ)
التي تتأكد من إطاعة جميع هذه الاتفاقيات بالفعل.

لذا لنعد إلى المتغيرات العالمية / المحلية

المفهوم القياسي لـ expl3 هو

• أعلن عن اسم متغير مرة واحدة (عالميًا) - لأن العديد من المتغيرات في
  الأقل بعض الأنواع لديها صناديق تخزين عالمية فقط

• استخدم اصطلاح الاسم \ l_ \ g_ للدلالة على المتغيرات المحلية والعالمية

يمنحك كلًا من سكان الكرة الأرضية والسكان المحليين ولكن لديه قيود

• لا تعلن عن متغير محلي في بداية نطاقه ،
  بدلاً من ذلك ، يمكنك إما استخدام _set أو _clear_new في تلك المرحلة والأخيرة
  قد يعني أن اسم المتغير قد يأتي في تلك المرحلة عالميًا
  في الوجود

• خارج النطاق ، لا يزال المتغير موجودًا مع الإعداد الافتراضي
  قيمة من النوع (على سبيل المثال _int يساوي 0 وما إلى ذلك) حتى لا تحصل على مترجم
  خطأ إذا أشرت إلى مثل هذا المتغير "عن طريق الخطأ" خارج المقصود منه
  مجال

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

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

FrankMittelbach - الآن لديك فضولي ؛ هل نهج etex.sty للسجلات غير فعال حقًا؟ أو ربما تقصد المتغيرات tl ، وفي هذه الحالة أوافق!

FrankMittelbach في رأيي ، من المهم التمييز

القاعدتان اللتان ذكرتهما وهما:

• أعلن عن اسم متغير مرة واحدة (عموميًا)
• استخدم اصطلاح الاسم \l_ \g_ للإشارة إلى المتغيرات المحلية والعالمية

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

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

هذا يشبه إلى حد ما القول بأن علامة 50mh ليست قاعدة بل قيادة
اتفاقية وهي مسألة ذوق إذا التزم السائق بها (فقط
لأنه لا يتم فحصه على الفور في معظم الأوقات)

إذا كنت تستخدم متغير \ l_ مع _gset ، فلا يزال بإمكانك البرمجة في TeX ولكن
لقد توقفت عن الامتثال للقواعد النحوية للشرح 3
لغة. هل يكسر الرمز الخاص بك على الفور؟ ربما لا ، لكنك
إنشاء تراكم حفظ (انظر فهرس TeXbook)

هل تقول إنها قاعدة نحوية فقط إذا كنا نتحقق منها عند
وقت التشغيل ، قل ، كل ثلاثاء؟

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

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

أعتقد أن FrankMittelbach يبالغ في تقدير النفقات العامة للإعلانات المحلية ( \loccount يدير التهم محليًا ، لا شيء يفعله عالميًا ، لذلك يحافظ على النفقات العامة).

لا أرى مشكلة كبيرة في تقديم \int_local:N و \tl_local:N (= \tl_set_eq:NN #1 \c_empty_tl ) وما إلى ذلك من شأنه أن يكون مشابهًا جدًا لـ \int_zero_new:N و \tl_clear_new:N لكنها ستفعل فقط "الجديدة" محليًا. هذا يتطلب القليل من العمل للسجلات ولكن ليس بشكل مفرط.

EvanAad ، يجب أن تعلم أن عدم التصريح عن متغير قد

\documentclass{article}
\usepackage{expl3}
\begin{document}
\ExplSyntaxOn
\tl_put_left:cn { l_my_tl } { foobar \par }
\l_my_tl
\end{document}

blefloch ما أقوله هو أنه من الجيد تمامًا الإعلان عن متغير داخل ماكرو (باستخدام \<module>_clear_new ) ، وليس عليك تسميته \l_amount_paid_int ، يمكنك ببساطة الاتصال إنها \amount_paid أو \amountPaid ، كما تفعل في أي لغة برمجة أخرى. يعد \l_..._int وسيلة تذكيرية لطيفة لتذكيرك بأنه عدد صحيح وأنه من المفترض أن يتم استخدامه محليًا ، لكن لا يجب أن تضطر إلى استخدام هذا أو أي وسيلة أخرى للذاكرة.

لأنه لم يتم التحقق منه أبدًا ، وبسبب عدم الالتزام بهذه الاتفاقية
لا يتسبب في حد ذاته في حدوث خطأ أو فقدان للوظائف.

لكن هذا هو بيت القصيد

أ) يسبب ضررًا حسب الظروف - أي عند الاختلاط
التخصيصات العامة والمحلية لنفس المتغير

ب) نقوم بالتحقق عند الطلب (وفي الوقت الحالي قد لا يتم التحقق من هذا الرمز
وظيفية ولكنها كانت وربما ستعود مرة أخرى في النهاية بسبب أ))

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

(ما أشار إليه مثال الكود السابق الخاص بي هو أنه حتى بالنسبة لـ tl من الضروري التصريح عنها قبل الاستخدام. هناك خيار فحص يختبر الإعلانات ولكن في الاستخدام العادي لا نريد مثل هذه النفقات العامة.)

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

في "الاصطلاحات" ، \amountPaid هو أمر مستند بينما \l_amount_paid_int ليس أمرًا ، والأخير هو جزء من مساحة الاسم amount (حسب الاصطلاح ولكنها مهمة جدًا في TeX ). هذا لا ينطبق على \l_ / \g_ ، على الرغم من أنني أعتقد أن العديد من اللغات لديها "توجيه" قوي في التسمية دون أن يتم فرضها على المستوى الفني.

في 19 تشرين الأول (أكتوبر) 2017 ، الساعة 16:58 ، كتب Joseph Wright [email protected] :

في "الاصطلاحات" ، فإن مبلغ الدفع هو أمر مستند بينما \ l_amount_paid_int ليس كذلك ، والأخير جزء من مساحة اسم المبلغ (حسب الاصطلاح ولكنه أمر مهم جدًا في TeX). هذا لا ينطبق على \ l _ / \ g_ ، على الرغم من أنني أعتقد أن العديد من اللغات لها "توجيه" قوي في التسمية دون أن يتم فرضها على المستوى الفني.

إن أسوأ الكوابيس في برمجة LaTeX2e هي تحديد الأمر
في "مساحة مستوى المستخدم" ، على سبيل المثال \ foo ، لاكتشاف أنها تتعارض
مع أمر حزمة أخرى محددة للاستخدام الداخلي (لذلك
غير موثق في الدليل).

هل حدث ذلك بالفعل؟ نعم ، وليس مرة واحدة فقط. التمسك ب
\ساعد اصطلاح commandname كثيرًا في تجنبه
مثل هذه المشاكل.

بالطبع يمكن أن تحدث أيضًا اشتباكات على "مساحة مستوى المستخدم" ،
ولكن من السهل تحديدها وحلها. عندما يتعلق الأمر بـ
داخليًا ، غالبًا ما يكون من الضروري مطاردة التوسعات بسرعة
مستوى عميق.

بشكل مختلف عن المشرعين ، لا يمكننا فرض غرامات أو سجن
من لا يلتزم بقوانين برمجة LaTeX3. ولكن اين
يجب على المجتمع وعلى الجميع.

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

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

إذا كنت تريد تحديد المتغير محليًا \ f من أي نوع ،
يجب أن تكون قلقًا بشأن تحديد الأمر من قبل البعض
الحزمة ، ووفقًا لقانون مورفي ، تنتهي تمامًا بالجدال
إلى دالة باستخدام المتغير \ f. هل يمكنك تخيل بعض الأسوأ
سيناريو؟

تشاو
إنريكو

وليس عليك تسميته \ l_amount_paid_int ، يمكنك ببساطة تسميته المبلغ المدفوع كما تفعل في أي لغة برمجة أخرى. يعد \ l _... تذكارًا رائعًا لتذكيرك بأنه من المفترض استخدامه محليًا ، ولكن لا يتعين عليك استخدام هذا أو أي ذاكرة أخرى.

بالتأكيد. يمكنك أيضًا استخدام md5-fc693aa157832059d7daeeb61c55 cddb : مدفوع أو مبلغ مدفوع (هذه ليست مزحة ، أعرف حزمة تستخدم &) أو أيًا كان ما تفضله. ولكن حتى لو كانت الأسماء مجرد اصطلاح: فهي تجعل التواصل أسهل إذا التزم الناس بهذه الاصطلاحات. لقد كنت تطرح الكثير من الأسئلة على tex.sx. ماذا ستفعل إذا كانت لديك مشكلة في كودك المكتوب "بأسلوب شخصي"؟ ترجمتها إلى أسلوب قياسي ، اطرح سؤالاً وقم بترجمته مرة أخرى؟ أو تتوقع أن يتمكن الجميع من التعامل مع أسلوبك الشخصي؟

@ eg9

بالنسبة للرمز الشخصي ، يحق للفرد أن يفعل ما يريد

لن تعرف هذا من خلال قراءة الوثائق ، هذا كل ما أقوله.

إذا كنت تريد تحديد المتغير \f محليًا من أي نوع ، فيجب أن تكون قلقًا بشأن الأمر الذي يتم تحديده بواسطة بعض الحزم

أنا أعترض. إذا كان الكود الخاص بك داخل \group_begin: ... \group_end: ، وإذا قمت بتعريف جميع المتغيرات المحلية بـ \<module>_clear_new:N ، وإذا قمت بتعيين المتغيرات المحلية فقط باستخدام \<module>_set:N... ، فلا داعي للقلق بشأن تتعارض أسماء المتغيرات المحلية مع الحزم الأخرى ، ما لم تستخدم التعليمات البرمجية حزمة أخرى.

@ u- فيشر

ولكن حتى لو كانت الأسماء مجرد اصطلاح: فهي تجعل التواصل أسهل إذا التزم الناس بهذه الاصطلاحات.

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

EvanAad لا داعي للقلق بشأن

\cs_new_protected:Npn \evanaad_halve:n #1
  {
    \group_begin:
      \int_zero_new:N \f
      \int_set:Nn \f { (#1) / 2 }
      \iow_term:x { \int_use:N \f }
    \group_end:
  }

ثم مستخدم الحزمة الخاصة بك يفعل

 \int_const:Nn \f {123}
 \evenaad_halve:n { \f }

سوف يفاجأون برؤية 0 وليس 62.

من ناحية أخرى ، إذا التزمت بأسماء مثل \evanaad_f وما إلى ذلك (أو أقصر \@@_f إلخ باستخدام l3docstrip magic) يجب أن تكون آمنًا.

لن تعرف هذا من خلال قراءة الوثائق ، هذا كل ما أقوله.

آسف ولكن expl3.pdf يستخدم كلمة "اصطلاح" حوالي 20 مرة. في حالة الأمر العام مقابل الأمر الخاص ، هناك حتى الجملة "لا توجد طريقة (تقريبًا) لفرض ذلك دون الحاجة إلى حساب عبء شديد ، لذلك نحن نطبقها فقط من خلال اصطلاح تسمية".

blefloch نقطة جيدة.

@ u-fischer ، حسنًا ، عادل بما يكفي. ماذا عن الاصطلاح القائل بأن اسم الوظيفة يجب أن ينتهي بمحدد الوسيطة؟ هذا ليس اصطلاحًا تمامًا ، لأن وظائف القسم 3.3 تفحص محدد الوسيطة ، ولكن هذه الوظائف هي مجرد "سكر نحوي" ، وإذا لم تستخدمها ، فلا عائق لاستخدام أسماء الوظائف مثل \mymodule_myfunc ، لكنك لن تعرف ذلك من الدليل.

في 19 أكتوبر 2017 ، الساعة 17:52 ، كتب EvanAad [email protected] :

@ u-fischer ، حسنًا ، عادل بما يكفي. ماذا عن الاصطلاح القائل بأن أسماء الوظائف يجب أن تنتهي بمحدد وسيطة؟ هذا ليس اصطلاحًا تمامًا ، لأن وظائف القسم 3.3 تفحص محدد الوسيطة ، ولكن هذه الوظائف هي مجرد "سكر نحوي" ، وإذا لم تستخدمها ، فلا عائق لاستخدام أسماء الوظائف مثل \ mymodule_myfunc.

هذا ضروري لـ cs_generate_ variant: Nn ، بالطبع.

تشاو
إنريكو

مع \mymodule_myfunc لن تتمكن من استخدام أي وظيفة من
l3expan . وظائف التوسع هذه ، ومفهوم المتغيرات ، هي أ
الجزء الأساسي من expl3.

بينما أوافق على أنه يمكن جعل أسماء المتغيرات أقصر (إزالة
"l _" / "g_" و "_int" / ...) ، توقيع الوظيفة ليس في الحقيقة "مجرد ملف
اتفاقية. معاهدة".

blefloch أرى وجهة نظرك ، وهي فكرة جيدة ، ولكن مع ذلك ، في رأيي ، إذا كان كل ما تريده هو كتابة أمر مستند ، فيجب أن تعلم أنه يمكنك القيام بذلك عن طريق تحديد وظيفة مثل

\ExplSyntaxOn
\cs_new:Npn \MyDocumentCommand {Hello,~world!}
\ExplSyntaxOff

وليس عليك أولاً تحديد وظيفة "ظل" \mymodule_my_document_command: ، ثم نسخها باستخدام

\cs_new_eq:NN \MyDocumentCommand \mymodule_my_document_command:

blefloch وبالمناسبة ، بجانب \cs_generate_variant:Nn ، الذي ذكره @ eg9 ، هل تستخدم أي وظائف أخرى للوحدة النمطية l3expan جزء محدد الوسيطة من اسم الوظيفة؟

يبدو لي الآن أنك تتجادل إلى حد كبير من أجل الجدل

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

\ endlinechar-1 \ def ~ # 1 {\ catcode` # 113} ~ Q ~ S ~ U ~ _ ~ V ~ W ~ J ~ K ~ L ~ M ~ N ~ O ~ @ ~ X ~ Y ~ [~] ~ (
~ | ~ & ~ Z ~ '~ "~ ~ h ~ z ~: ~ q ~ j ~ k ~؛ ~ / ~) ~! ~، ~ $ ~ + \ let_ \ let_ ~ newcount ~ $$ - 1 ~ Q ~ J ~ V ~ S.~ K ~ W ~ U ~ L ~، ~ '' 1 ~ "" 2 ~ * 1 _ & \ count & 144 '& 155' & 145 "& 154" _ [\ ifnum _ (\ ifcase_O \ أو
_ | \ else _] \ fi_N \ number _ @ \adv_X \ expandafter_Z \ global_Y \ typeout_ ~ newif
~ \ ifG ~ \ if_ ~ \ def ~ j {[0 Q [0Jk | $] | $] | $] | $]} ~ k {& 1NQNJ} ~ \ 2 # 1 # 2 {} ~: # 1 {

11 # 12 # 13 # 14 # 15 # 16 # 17 # 18} ~ h # 1 # 2 {# 2: {~ \ q # 1} ~ # 2 ^^ J} ~ \ q # 1 # 2 {(& 1 # 1 # 2 ~~ OO $]}

~ / {Y {صف وعمود؟ على سبيل المثال E6} \ read $ toM \ ifcat ~ X \ 2M ~ $$ X \ jM |! input!]} ~! # 1! {
Y {غير صالح # 1.} /} ~ \ j # 1 # 2 {Q #1@Q- J #2@J- 0؛ (V! move!]} ~ ؛ {V0 (jS1z1z0z {$} س
0z1z {$} S $ z1z0z {$}]} ~ _ {@، \ ifodd '-]} ~ z # 1 {{\ trueK # 1 {\ falseq}}} ~ q {@ QS @ JK [j = "
\ ifZk'Z_2] @ V1q | [j = 'ZVV \ ifG \ if | \ aftergroupq]]]]} ~ \، # 1 {Q # 1:.} ~. # 1 {J # 1؛ [0
WWVUQLJ]]} ~ + # 1 {(# 1O2O-2O0O0O0O0O-2O2]} ~) {'X "X" N'Y {^^ J:
~ ^^ Jh1Ah2Bh3Ch4Dh5Eh6Fh7Gh8H: ~ ^^ J} \ GfalseW (W $ | 0] ~: \، \ Gtrue [0 /]؛ k'_1] [$ = WY {(، Tie | Player [0> ،. | $] ~ يفوز بـ N [0>، -]،].} X \ dump])} ~~ {})

وهو مستند TeX جميل (في الواقع مستند LaTeX جميل)
ولكن فيما يتعلق بالكود الخاص به ، فإنه ليس مفيدًا على الإطلاق. و
حقيقة أن برونو قادر على كتابة مثل هذا المستند لا يعني ذلك
يجب أن يصف دليل expl3 (أو في هذه الحالة دليل LaTeX) أيًا منه.

واجه كود LaTeX (2.09 و 2e أيضًا) المشكلة الكبيرة في الأيام الأولى
الكثير من الأشخاص الذين يبرمجون يفهمون الاختصارات منخفضة المستوى
في TeX واستخدموها وأساءوا استخدامها لأنهم اعتقدوا أنها ليست كذلك
ضار. نتيجة لذلك ، هناك كمية كبيرة من حزم 2e الحالية
غير متوافقة مع بعضها البعض أو بها مشكلات دقيقة في بعض الأماكن عند استخدامها
معًا وما إلى ذلك أو ينفصلان من حين لآخر لأنهم تجاوزوا واحدًا أو
واجهة المستخدم (لأنها تبدو تعمل بدونها).

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

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

بعد قولي هذا ، لا أريد أن أحبطك من تحدي المفاهيم ،
أوامر ، واجهات ، ماذا لديك. العديد من النقاط التي أثرت عليها
تم أخذ مناسبات أخرى بشكل جيد (أو على الأقل جعلتنا نعيد التفكير في واحدة
أو النقطة الأخرى).

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

أعتقد أننا تحدثنا عن هذا من خلال: سأغلق ولكن بالطبع سأعيد فتحه إذا طلب ذلك.