سؤال

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

هل كانت مفيدة؟

المحلول

XSLT تعريفي بدلاً من الحالة.

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

مثل اللغة الوظيفية، أعتقد أنه يمكن موازنتها بشكل جيد مع الترابط التلقائي الآمن المتعدد عبر العديد من المعالجات.

من ويكيبيديا على XSLT:

كلغة ، تتأثر XSLT باللغات الوظيفية ، ولغات مطابقة الأنماط المستندة إلى النص مثل Snobol و AWK.كان سابقتها الأكثر مباشرة هي DSSSL ، وهي لغة قامت بنفس الوظيفة لـ SGML التي يقوم بها XSLT لـ XML.يمكن أيضًا اعتبار XSLT معالج قالب.

إليك موقع رائع للاستخدام XSLT كلغة وظيفية بمساعدة FXSL.FXSL هي مكتبة تقدم الدعم للوظائف ذات الترتيب الأعلى.

بسبب FXSL، لا أعتقد أن XSLT بحاجة إلى أن يعمل بكامل طاقته.ربما سيتم إدراج FXSL كمعيار W3C في المستقبل، لكن ليس لدي أي دليل على ذلك.

نصائح أخرى

أنا متأكد من أنك وجدت هذا الرابط الآن :-) http://fxsl.sourceforge.net/articles/FuncProg/Functional%20Programming.html .

الوظائف الجيدة في XSLT هي مواطنون من الدرجة الأولى مع بعض الأعمال بعد كل شيء :-)

هذا هو ما أشعر به عندما أقوم ببرمجته.

يعتمد XSLT بالكامل على تحديد الوظائف وتطبيقها على الأحداث المحددة التي تأتي ضمن تدفق الإدخال.

يتيح لك XSLT تعيين متغير.البرمجة الوظيفية لا تسمح للوظائف بأن يكون لها آثار جانبية - وهذا أمر كبير.

ومع ذلك، عند الكتابة بلغة XSLT، يتمتع المرء بنفس "إحساس العمل بطريقة FP.أنت تعمل مع المدخلات - ولا تغيرها - لإنشاء المخرجات.

يعد هذا نموذج برمجة مختلفًا تمامًا عن ذلك المستخدم عند العمل مع DOM API.DOM لا يفصل بين المدخلات والمخرجات على الإطلاق.يتم تسليمك بنية بيانات - ويمكنك تشويهها بالطريقة التي تراها مناسبة - دون تردد أو قيود أو ندم.

يكفي أن نقول إذا كنت تحب FP والمبادئ التي تكمن وراءه، فمن المحتمل أن تشعر بالراحة في العمل فيه.تمامًا مثل تجربة البرمجة الموجهة بالأحداث - ولغة XML نفسها - ستجعلك مرتاحًا معها أيضًا.

إذا كانت تجربتك الوحيدة هي مع البرامج من أعلى إلى أسفل، والتي لا تعتمد على الأحداث - فسيكون XSLT مشهدًا غريبًا وغير مألوف للغاية بالفعل.على الأقل في البداية.اكتساب القليل من الخبرة ثم العودة إلى XSLT عندما تكون تعبيرات XPath والتعامل مع الأحداث مريحة لك حقًا، ستؤتي ثمارها بشكل رائع.

بالنسبة للجزء الأكبر، ما يجعل XSLT ليست لغة برمجة فعالة بنسبة 100% هو عدم قدرتها على التعامل مع الوظائف كنوع بيانات من الدرجة الأولى.

قد يكون هناك البعض الآخر - ولكن هذه هي الإجابة الواضحة.

حظ سعيد!

قدمت Saxon-SA بعض وظائف الامتداد التي تجعل XSLT وظيفية.يمكنك استخدام saxon:function() لإنشاء قيمة دالة (في الواقع a {http://net.sf.saxon/java-type}net.sf.saxon.expr.UserFunctionCall value) والتي تتصل بها بعد ذلك saxon:call().

يتمتع Saxon-B بوظيفة مماثلة مع الاقتران saxon:expression() و saxon:eval().الفرق هو ذلك saxon:expression() يأخذ أي تعبير XPath، و saxon:eval() يقيمها، في حين saxon:function() يأخذ اسم الدالة التي saxon:call() المكالمات.

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

تمكنك لغات البرمجة الوظيفية مثل Scheme أو Erlang من الإعلان عن المتغيرات أيضًا، وفي Haskell يمكنك أيضًا القيام بذلك:

-- الدالة "اختبار" تأخذ المتغير x وتضيفه إلى كل عنصر في القائمة xs

test :: [Int] -> [Int]
test xs = map (+ x) xs
where x = 2
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top