تثمين كسول
في نظرية لغة البرمجة، إنَّ التثمين الكسول (بالإنجليزية: Lazy evaluation) أو الاستدعاء عند الحاجة (بالإنجليزية: call-by-need)[1]، هي استراتيجية تثمين تؤخِّر تثمين التعبير لحين احتياج قيمته (تثمين غير صارم) وَتتجنّب بذلك -مُشاركة- التَثمينات المُتكرِّرة.[2][3] يُمكن للمُشاركة إنقاص وقت تشغيل دوال مُعيَّنة بعاملٍ أُسِّي على استراتيجيَّات التثمين غير الصارم، مثل الاستدعاء بالاسم.[بحاجة لمصدر]
استرتيجية تثمين |
---|
|
تتضمَّن منافع التثمين الكسول:
- القدرة على تعريف بُنى تدفق السيطرة بتجريدٍ بدلًا من أن تكون مُدمجة.
- القدرة على تعريف بُنى بيانات مُمكنة الأزليَّة، يسمح هذا بتنفيذ دقيق للمزيد من الخوارزميَّات.
- زيادة الأداء بتجنُّب الحسابات غير الضروريَّة وَالأخطاء في حالة تثمين التعابير المُركَّبة.
غالبًا ما يُدمَج التثمين الكسول مع استحضار الذاكرة[4](memoization أو memoisation)، كما قد ذُكِر في «كتابة برامج كفء»(Writing Efficient Programs) لِـجون بينتلي، غالبًا ما يُدمَج التثمين الكسول مع التذكُّر.[5] بعد أن تُحوسب قيمة الدالَّة من أجل مُعطىً أو مجموعة من المُعطيات، فإنَّ النَّتيجة تُخَزَّن في جدول المُشاهدات المُفَهرَس وفق قيم المُعطيات؛ وفي المرَّة القادمة الَّتي سَتُستَدعى فيها الدالَّة سيتم تفقُّد الجدول لتحديد فيما إذا كانت نتيجة قيم المُعطيات متوفِّرةً بالفعل أم لا. عندها وببساطة سَتُعاد قيمة النتيجة المُخَزَّنة وَإن كان العكس فَسيتم تثمين الدالَّة وَيُضاف مُدخَل جديد إلى جدول المُشاهدات لِيُعاد استخدامه لاحقًا.
قد يؤدِّي التثمين الكسول إلى نقص في الذكرة اللّازمة للبرامج(المحجوزة لها)؛ لأنَّ القيم تُنسَئ عند الحاجة إليها.[6] ومن الصَّعب دمج التثمين الكسول مع المَزايا الأمريَّة مثل استيعاب الأخطاء وَالدخل/الخرج، لأنّ ترتيب العمليّات يصبح غيرَ مُحدَّدٍ. وَقد يسبّب التثمين الكسول تسرب الذاكرة.[7]
عكس التثمين الكسول هو «التثمين اللَّهوف»(eager evaluation)؛ وَأحيانًا يُعرَف باسم التثمين الصارم(strict evaluation). ولقد وظِّف التثمين اللَّهوف كاستراتيجيّة تثمين في أغلب لُغات البرمجة.
لمحة تاريخيّة
قُدِّمَ التثمين الكسول من أجل حسابات اللامدا من قِبَل كريستوفر وادز-ورث[8] وَباستقلالٍ من أجل لُغات البرمجة من قِبَل بيتر هيندرسن وَجيمس حيرم موريس[9] وَدانيال بول فريدمان وَديفيد س. وايز.[10][11]
التطبيقات
يُستخدم التثمين المؤجَّل(Delayed evaluation) تحديدًا في لُغات البرمجة الوظيفيَّة. فعند استخدام التثمين المؤجَّل، لا يتم تثمين التعبير عند إسناده إلى مُتَغَيِّر بل يُثَمَّن عند الحاجة لإنتاج قيمة التعبير. هذه إفادة كمثال، x:=expression;
(إسناد نتيجة التعبير إلى مُتَغَيِّر). بوضوحٍ، تَمَّ استدعاء التعبير بُغية تثمينه وَوُضِعَت النتيجة في x
، لكن يتم تعليق ما بداخل x
لِحين احتياج قيمته وذلك باستخدام فهرس يقود إلى x
في تعبيرٍ ما لاحِقٍ وقد يكون هذا التعبير أيضًا مؤجّلًا، وأخيرًا تُشَذَّب شجرة الاعتماديَّات النامية هذه لإنتاج بعض الرموز الّتي يُفَضَّل رؤيتها.[12]
من فوائد التثمين المؤجَّل قدرته على إنشاء قوائم لانهائيَّة قابلة للحِساب بدون تداخل الحلقات اللَّانهائيَّة أو الحجم في الحِساب. كمثال، يُمكن إنشاء دالَّة تُنشِئ قائمة لانهائيَّة (تُدعى غالبًا «جريان») من أعداد فيبوناتشي. إنَّ حِساب عدد فيبوناتشيّ ما -وليكن «ن»- سيكون بكلّ بساطة استخلاصًا لهذا العنصر -الّذي هو العدد «ن»- من القائمة اللَّانهائيَّة، مُجبرًا بذلك على تثمين أوَّل ن عنصر من القائمة.[13][14]
كمثال، يُمكن في لغة البرمجة هاسكل كتابة قائمة بكلّ أعداد فيبوناتشي كالتالي:[14]
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
في نحويَّة هاسكل، «:
» تُضيف عنصرًا إلى بداية القائمة وَ«tail
» تعود بالقائمة بدون عنصرها الأوَّل وَ«zipWith
» تَستَخدِم دالَّة مُعَيَّنة (في حالتنا هذه هي الجمع «+») لجمع العناصر المُتوافقة لِكلا القائمتين بهدف إنتاج قائمة ثالثة.[13]
يجب أن يكون المبرمج حذرًا وَدقيقًا؛ لأنّه يتم فقط تثمين القيم اللّازمة لإنتاج نتيجة معيّنة. ومع ذلك، قد تؤدّي بعض الحسابات إلى محاولة البرنامج لتثمين عدد لا حصر له من العناصر؛ على سبيل المثال، طلب طول القائمة أو محاولة جمع عناصر القائمة بعملية الطيّ يؤدي بالبرنامج إمَّا إلى فشل الإنهاء أو نفاد الذاكرة.
بُنى التحكّم
في كلّ اللّغات «اللّهوفة» تقريبًا، يتمّ تثمين الإفادة «if» بأسلوب كسولٍ.
if a then b else c
سيتمّ تثمين (a)، وَإذا وَفقط إذا ثُمِّنَت (a) لتكون صح «true» سيتمّ تثمين (b) وَإلّا سيتمّ تثمين (c). وبذلك لن يتمّ تثمين واحد من (b) وَ (c). بالمُقابِل، سيكون السلوك المُتَوَقَّع هو هذا:
define f(x, y) = 2 * x set k = f(d, e)
سيتمّ تثمين (e) عند حِساب قيمة f(d, e) وعلى الرُّغم من ذلك فقيمة (e) غير مُستخدمة في الدالَّة f. وبالتالي تعتمد بُنى التحكّم المُعرَّفة من قِبَل المُستَخدِم على النحويَّة المضبوطة، كمثال:
define g(a, b, c) = if a then b else c l = g(h, i, j)
سيتمّ تثمين كُلٍّ من (i) وَ (j) في اللُّغة اللَّهوفة. بينما في اللُّغة الكسولة،
l' = if h then i else j
سيتمّ تثمين إمَّا (i) أو (j)، ولن يتمّ تثمين كليهما معًا أبدًا.
يسمَح التثمين الكسول بتعريف بُنى التحكّم طبيعيًّا، وَلكن لا يسمح لها أن تكون مُدمَجة أو كتقنيّات وقت-التجميع. فإذا كان لِـ (i) أو (j) آثارًا جانبيّةً أو أثارت أخطاءً في وقت التشغيل، عنها ستكون الاختلافات غير الملحوظة بين (l) وَ (l') مُعَقَّدَةً. وَمن المُمكن عادةً إنشاء بُنى تحكّمٍ كسولة يُعرّفها المُستخدِم كَدوالٍّ في اللُّغات اللَّهوفة، لذلك قد تُزاح تلك الدَّوال من نحويَّة اللُّغة عند التثمين اللَّهوف: غالبًا ما يُحتَاج ادّثار جسد الشِفرة (مثل: (i) وَ (j)) ليصبح قيمة الدالَّة، ولذلك يتمّ فقط تنفيذها عند الاستدعاء.
يُدعى التثمين قصير الدوران (وَيُسمّى أيضًا: تثمين دُونيّ أو تثمين مَكارثي) لِبُنى التحكّم البوليانيّة(المنطقيّة) تثمينًا «كسولًا».
العمل مع بُنى بيانات أزليّة
توفّر العديد من اللُّغات مفهوم «بُنى-البيانات الأزليّة (لا محدودة)» (بالإنجليزية: infinite data-structures). ويسمح ذلك بتعريف البيانات كمجالات أزليّة أو كتعاوديّة غير منتهية (unending recursion)، لكن يتمّ حساب القيم الفعليّة عندما نحتاجها فحسب. تفقّد هذا المِثال المتواضع؛ وهو برنامج في لغة هاسكل:
numberFromInfiniteList :: Int -> Int
numberFromInfiniteList n = infinity !! n - 1
where infinity = [1..]
main = print $ numberFromInfiniteList 4
في الدالَّة numberFromInfiniteList، إنّ قيمة infinity هي مجال لا محدود، ولحين احتياجه يتمّ تثمين المجال وصولًا إلى المؤشِّر (index) المطلوب.
المراجع
- Hudak 1989، صفحة 384
- David Anthony Watt؛ William Findlay (2004)، Programming language design concepts، John Wiley and Sons، ص. 367–368، ISBN 978-0-470-85320-7، مؤرشف من الأصل في 12 مارس 2017، اطلع عليه بتاريخ 30 ديسمبر 2010.
- Reynolds 1998، صفحة 307
- مَجمع اللُّغة العربيَّة على الشَّبكة العالميَّة، الفتوى: 1120. نسخة محفوظة 05 مارس 2017 على موقع واي باك مشين.
- Bentley, Jon Louis. Writing Efficient Programs. Prentice-Hall, 1985. ISBN 978-0-13-970244-0
- Chris Smith (22 أكتوبر 2009)، Programming F#، O'Reilly Media, Inc.، ص. 79، ISBN 978-0-596-15364-9، مؤرشف من الأصل في 13 يناير 2020، اطلع عليه بتاريخ 31 ديسمبر 2010.
- Edward Z. Yang. "Space leak zoo". نسخة محفوظة 17 يناير 2018 على موقع واي باك مشين.
- (Wadsworth 1971)
- (Henderson & Morris 1976)
- (Friedman & Wise 1976)
- Reynolds 1998، صفحة 312
- Philip Wadler (2006)، Functional and logic programming: 8th international symposium, FLOPS 2006, Fuji-Susono, Japan, April 24-26, 2006 : proceedings، Springer، ص. 149، ISBN 978-3-540-33438-5، مؤرشف من الأصل في 14 يناير 2020، اطلع عليه بتاريخ 14 يناير 2011.
- Daniel Le Métayer (2002)، Programming languages and systems: 11th European Symposium on Programming, ESOP 2002, held as part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2002, Grenoble, France, April 8-12, 2002 : proceedings، Springer، ص. 129–132، ISBN 978-3-540-43363-7، مؤرشف من الأصل في 14 أبريل 2020، اطلع عليه بتاريخ 14 يناير 2011.
- Association for Computing Machinery؛ ACM Special Interest Group on Programming Languages (01 يناير 2002)، Proceedings of the 2002 ACM SIGPLAN Haskell Workshop (Haskell '02): Pittsburgh, Pennsylvania, USA ; October 3, 2002، Association for Computing Machinery، ص. 40، ISBN 978-1-58113-605-0، مؤرشف من الأصل في 12 مارس 2017، اطلع عليه بتاريخ 14 يناير 2011.
مصادر
- Hudak, Paul (سبتمبر 1989)، "Conception, Evolution, and Application of Functional Programming Languages"، ACM Computing Surveys، 21 (3): 383–385، doi:10.1145/72551.72554، مؤرشف من الأصل في 14 أبريل 2020.
{{استشهاد بدورية محكمة}}
: الوسيط|ref=harv
غير صالح (مساعدة) - Reynolds, John C. (1998)، Theories of programming languages، Cambridge University Press، ISBN 9780521594141، مؤرشف من الأصل في 14 أبريل 2020، اطلع عليه بتاريخ 23 فبراير 2016.
قراءة موسَّعة
- Wadsworth, Christopher P. (1971)، Semantics and Pragmatics of the Lambda Calculus.
{{استشهاد بكتاب}}
: الوسيط|ref=harv
غير صالح (مساعدة) PhD thesis, Oxford University - Henderson؛ Morris (يناير 1976)، "A Lazy Evaluator"، Conference Record of the Third ACM symposium on Principles of Programming Languages، مؤرشف من الأصل في 14 أبريل 2020.
{{استشهاد بدورية محكمة}}
: الوسيط|ref=harv
غير صالح (مساعدة) - Friedman؛ Wise (1976)، "Cons should not evaluate its arguments" (PDF)، Automata Languages and Programming Third International Colloquium، Edinburgh University Press.
{{استشهاد بدورية محكمة}}
: الوسيط|ref=harv
غير صالح (مساعدة) - Launchbury, John (1993)، "A Natural Semantics for Lazy Evaluation"، Proceedings of the 20th ACM SIGPLAN-SIGACT symposium on Principles of programming languages (POPL '93)، doi:10.1145/158511.158618، مؤرشف من الأصل في 07 فبراير 2019.
- أنماط التصميم
- John Hughes. "Why functional programming matters". مجلة الحاسوب - Special issue on lazy functional programming. Volume 32 Issue 2, April 1989.
- Philip Wadler. "How to replace failure by a list of successes a method for exception handling, backtracking, and pattern matching in lazy functional languages". Functional Programming Languages and Computer Architecture. Lecture Notes in Computer Science, 1985, Volume 201/1985, 113-128.
- الكسل في اللُّغات الصَّارمة
- Philip Wadler, Walid Taha, and David MacQueen. "How to add laziness to a strict language, without even being odd". Workshop on Standard ML, Baltimore, September 1998.
- تدوينات لعلماء الحاسوب
- روبرت هاربر . "The Point of Laziness"
- Lennart Augustsson. "More points for lazy evaluation"
روابط خارجيّة
- Lazy Evaluation at the Portland Pattern Repository
- Lazy evaluation at Haskell Wiki
- The Incomplete Guide to Lazy Evaluation (in Haskell) – A series of tutorials on lazy evaluation in Haskell: How it works, how it helps making code more modular, and other things.
- Functional programming in Python becomes lazy
- Lazy function argument evaluation in the D language
- Lazy evaluation macros in Nemerle
- Lambda calculus in Boost Libraries in C++ language
- Lazy Evaluation in Perl
- بوابة برمجة الحاسوب