هل هناك مترجم Haskell أو Preprocessor الذي يستخدم تقييم صارم؟

Question

أبحث عن عبور Haskell يستخدم تقييم صارم افتراضيا بدلا من التقييم الكسول. أود فقط استخدام Ocaml، ولكن بناء جملة Haskell افضل بكثير من Ocaml's (و Haskell نقية، ولها ميزات رائعة مثل فصول النوع).

أنا حقا لا تضع باستمرار !رمل $!في جميع أنحاء البرنامج الخاص بي. سيكون مترجم مع رمز التبديل أو Preprocessor لوضع التعليقات التوضيحية الدقيقة لطيفة حقا. سيكون من المفيد أيضا أن تكون هناك طريقة لاستخدام التقييم الكسول في بعض الأماكن أيضا، فقط في حال أريد شيئا مثل قائمة لا حصر لها (ربما لن أكون أبدا).

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

Answer 1

إذا كان لديك مترجم Haskell يستخدم تقييم صارم، فإنه لا يترجم Haskell. الكسل غير الدقيقة هي جزء من مواصفات Haskell!

ومع ذلك، هناك بدائل.

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

• إنشاء Preprocessor، كما فعلت الآخرون.

• تعلم كيفية استخدام Haskell "الطريق الصحيح". إذا كنت تستطيع تبسيط حالة الاختبار الخاصة بك إلى شيء يتم عرضه علنا، فيمكنك نشره على القائمة البريدية Haskell-Café, ، حيث الناس مفيدة للغاية مع هذه الأنواع من الأسئلة المتعلقة بآثار عدم الصدحة.

Answer 2

أنا حقا لا أضع باستمرار! S و $! في جميع أنحاء البرنامج

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

Answer 3

كانت هناك محاولتان لتقييم هاسكل بدقة في الماضي:

• جان ويليم مايوسن حريصة haskell.
• روب انس رسالة الدكتوراه

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

عدل

Answer 4

أنظر أيضا GHC- صارم البرنامج المساعد, ، مثال ل إطار البرنامج المساعد GHC, ، موصوف في موناد قارئ 12..

Answer 5

أشعر بألمك. بلدي أكبر بيتا في برمجة يومية لي هو التعامل مع هؤلاء! @ # $٪ ^ & (تسرب الفضاء.

ومع ذلك، إذا كان ذلك يساعد، مع مرور الوقت الذي تتعلمه (بالطريقة الصعبة) حول كيفية التعامل مع هذا، فهي تتحسن. لكن ما زلت في انتظار أن يخرج Andy Gill مع Profiler تسرب الفضاء السحري لإصلاح كل مشاكلي. (أنا آخذ تعليقه خارجي بالنسبة لي في آخر برنامج عمل للمسافرين الذين يحلمون بهذه الفكرة الرائعة كوعد لتنفيذها.)

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

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

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

Answer 6

أعتقد أن جان ويليم ماسان محمول PH هو / كان صارما. الأقرب التالي هو شوكة تقييم المضاربة المضاربة روبرت آني ل GHC 5. شوكة Spece_eval ليست صارمة، ولكن بدلا من ذلك تقيم بشكل متفائل. لا أعرف ما إذا كان أي من هؤلاء لا يزالون حاليين / قابل للاستخدام / إلخ.

Answer 7

باستخدام NFDATA و RNF في كل مكان ليس حلا نظرا لأنه يعني عبء الهياكل الكبيرة مرارا وتكرارا تم تقييمها بالفعل.

يعد الفصل التمهيدي من أطروحة Ben Lippmeier الخاصة ب Tipmeier (حول DDC) حول أفضل نقد في Haskell الذي رأيته - إنه يناقش قضايا الكسل والتحديث المدمر ومحولات موناد، إلخ. DDC لديه كسل ولكن عليك أن تطلب ذلك صراحة ، ويعتبر تأثيرا، يتم تتبعه وإدارته بواسطة نظام DDC من النوع والتأثير.

Answer 8

رأيت مؤخرا بعض العمل في هذا المجال:

https://ghc.hashell.org/trac/ghc/wiki/strictpragma.

يمكنك سماع بت صغير حول هذا الموضوع في تحديث الحالة SPJ's GHC هنا:

http://youtu.be/ex79k4lvjno؟t=9m33s.(الرابط يبدأ في قطعة ذات صلة في الساعة 9:33)

Answer 9

أبحث عن عبور Haskell يستخدم تقييم صارم افتراضيا بدلا من التقييم الكسول.

لن يكون هذا التحويل البرمجي مترجم Haskell. اذا أنت هل حقا تريد، يمكنك التفكير في وضع {-# LANGUAGE Strict #-} البراغاس في ملفاتك. سيعمل ذلك مع GHC 8.0.2 و 8.2.2 و 8.4.1، المعروف أيضا باسم الإصدارات الثلاثة الأخيرة من المترجم.

سيكون من المفيد أيضا أن تكون هناك طريقة لاستخدام التقييم الكسول في أماكن معينة أيضا، فقط في حال أريد شيئا مثل قائمة لا حصر لها

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

(ربما لن أكون كذلك).

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

من فضلك لا تحاول إقناعي بأن التقييم الكسول هو أفضل، أحتاج حقا إلى الأداء.

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

IIRC، قال سايمون بيتون جونز إن التقييم الكسول لم يكن ضروريا حقا، كان هناك في الغالب لمنعهم من صنع اللغة.

هذا ليس صحيحا. يمكنك قراءة المزيد حول التاريخ الفعلي ل Haskell هنا

Answer 10

يوجد ايضا سكيد, ، الذي يهدف إلى منتصف الطيف الصارم كسول.

Seqaid هو البرنامج المساعد GGC يوفر الأجهزة التلقائية غير الغازية لمشاريع Haskell، والضبط الديناميكي (والتوازي) السيطرة. سيشمل ذلك قريبا التحسين لتخفيف تسرب الفضاء الآلي باستخدام التقليل الأدنى.

Answer 11

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