Julia: الاقتراح: قم بإيقاف وظيفة الأنابيب ثم إزالتها

توفر وظيفة الأنابيب تركيبًا لما بعد الإصلاح لاستدعاء الوظائف ، وهو أمر ملائم في REPL لتوليد البيانات التفاعلية والمزيد من التصور / التلخيص.

حالة الاستخدام التي رأيت العديد من الأشخاص يكتبونها هي

julia> somecomplicatedthingproducingarray
...

<ARROW UP>

julia> somecomplicatedthingproducingarray |> summarize

حيث تكون الوظيفة summarize شيئًا مثل الرسم البياني أو المدرج التكراري

jiahao أنا لا أجادل في أنه ليس مفيدًا ، ولكن يجب أن نكون متسقين داخل Base ونترك الحزم توفر أشياء مثل هذه.

هناك أيضًا ans للاستخدام البديل

في هذا الاقتراح ، هل سيستمر تحليل |> كعامل infix؟

@ ajkeller34 : بالتأكيد ، ستكون الحزم مجانية في فعل ما تريد به (على الرغم من أنه سيتعين عليها اللعب بشكل جيد مع بعضها البعض من حيث نوع القرصنة والتعايش) ، دون وجود الكثير من القيود التي تجعلها متوافقة لغويًا مع القديم التعريف الأساسي.

إزالة استخدامات بناء الجملة داخل Base ، إن وجدت

هذه محاولة قديمة جدًا قمت بها للقيام بذلك: https://github.com/tkelman/julia/commit/212727cdc4aaa3221763580f15d42cfe198bcc1c
في ذلك الوقت ، كانت معظم الاستخدامات الأساسية بسيطة جدًا. قد تكون بعض استخدامات "توصيل هذا الشيء إلى هذه الوظيفة المجهولة" أفضل في استخدامات الأنابيب ، ولكن نظرًا لأن معظم هؤلاء كانوا يعيدون استخدام نفس الوظيفة المجهولة عدة مرات ، فمن المحتمل أن يكون من المفيد إعطائها اسمًا وتسميتها مثل وظيفة طبيعية في تلك المرحلة.

في حال كان أي شخص فضوليًا ، لدي الآن ChainRecursive.jl . سأضع إعلانًا عن الخطاب حول تفكك ChainMap.jl وأطفاله المختلفين بمجرد اكتماله.

اسمحوا لي أن أقدم بعض المقاومة هنا لأن لدي بعض المصالح الخاصة |> خاص بما يجعله ممكنًا.

أنا ثاني مع jiahao أن |> مفيد جدًا عندما تريد تجربة الأشياء بسرعة في REPL. علاوة على ذلك ، أجده مفيدًا أيضًا عندما تكون حجتك كبيرة جدًا أو تستحق بعض الاتزان (نعم ، لقد قلت ذلك) . في حالة المثال المرتبط ، من الأفضل في الواقع أن تكون الحجة أكثر بروزًا من الوظيفة التي يتم استدعاؤها. sum(x) مثال بسيط للغاية ، ويجب بالفعل كتابته كـ sum(x) ). في Escher.jl ، جميع الوظائف التي تضيف خصائص إلى العناصر لها طريقة معالجة. يتوافق هذا جيدًا مع |> (الذي تم التخطيط له ، إنه يعمل أيضًا بشكل رائع مع map ) ومن دواعي سروري أن تكون قادرًا على تجربة الأشياء في نهاية السطر ومشاهدة تحديث واجهة المستخدم فورا. لست مضطرًا لأن أجد طريقي إلى بداية التعبير وأستمتع به. للاستخدام مع Escher على الأقل ، فإن البديل المقترح هو تعيين تعبيرات كبيرة لمتغيرات من الأسماء المكونة مثل padded_box_contents_aligned_right_tomato_background (أو أسوأ box34 ) ثم استدعاء دالة عليها. على عكس القراءة الجميلة <big UI expression> |> aligncontents(right) |> pad(1em) |> fillcolor("tomato")

أعلم أنه بعد ذلك يمكنني تحديد |> داخل Escher وربما سأفعل ذلك ، لكنه سيقتل عقلي لرؤية WARNING: using Escher.|> in module YourPackage conflicts with an existing identifier. ستعطي الحزم بالتأكيد معاني مختلفة لهذا الأمر ، وهو أمر شديد الأهمية بالنسبة لي ينذر بالخطر!

قدم لنا StefanKarpinski و Andyferris تكوينًا تعسفيًا للوظيفة في رقم 17155 ، والذي يمكن أن يخدم غرضًا مشابهًا في العديد من المواقف.

البديل لـ box |> fill("orange") |> pad(2em) سيكون (fill("orange") ∘ pad(2em))(box) مقابل box |> fill("orange") ∘ pad(2em) ؟ يبدو هذان الشخصان متعامدين.

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

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

shashi أنا أفهم نقاطك ، لكنك ستتمكن من الحصول على نفس السلوك باستخدام إحدى الحزم التي ذكرتها في الإصدار ، أليس كذلك؟ على سبيل المثال ، في مثال Escher الخاص بك ، يمكنك استخدام FunctionalData للقيام بـ <strong i="6">@p</strong> vbox(<really big thing>) | pad(2em) أو Lazy للقيام بـ @> vbox(...) pad(2em) .

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

باستثناء أنه لن يكون قابلاً للاستخدام ، لأن الطريقة الآمنة الوحيدة لاستخدامه ستكون Escher.|>(...) أو Lazy.|>(...) .

افتراضيًا ، كيف يمكن للمرء استخدام |> كمعامل infix إذا كنت تستخدم حزمتين مختلفتين تقومان بتعريفه وتصديره ، على افتراض أنه لم يتم تعريفه في Base ؟

kmsquire يعتمد ذلك على حالة الاستخدام. لا يزال يتم تحليل |> كعامل infix كما هو الحال الآن ، فلن يكون له قيمة في Base. إذا كنت تستخدمها في ماكرو ، فلا يهم كيف تحددها أي حزمة معينة ، لأنها تصبح ببساطة الوسيطة الأولى في تعبير الاستدعاء.

خذ على سبيل المثال <| ، والذي تم تحليله كعامل infix ولكن ليس له قيمة. على الرغم من أنه غير محدد ، لا يزال لدينا

julia> dump(:(a <| b))
Expr
  head: Symbol call
  args: Array{Any}((3,))
    1: Symbol <|
    2: Symbol a
    3: Symbol b
  typ: Any

يمكن للحزم تحديد طرق وتصديرها لـ Base.:(<|) والتي تعني أشياء مختلفة ، تمامًا كما يمكن للمرء أن يفعل مع + .

لكن الحزم التي توفر أنابيب وظيفية لطيفة تفعل ذلك في وحدات الماكرو ، أفترض لهذا السبب تحديدًا.

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

إذا قمنا بإيقاف هذا ، فهل يجب علينا أيضًا إيقاف * لسلسلة السلسلة؟ هذا له مشكلات مماثلة كما هو الحال مع الفائض مع string(a, b) ، وينتهك مبدأ المفاجأة الأقل نظرًا لأن a و b ليسا أرقامًا.

بشكل عام ، ربما يجب علينا إهمال جميع تدوينات اللاحق ، لأنه من المربك أن يكون لديك اصطلاحات استدعاء متعددة مثل *(a, b) مقابل a * b - يمكننا تقليص 3 تركيباتنا المتباينة الحالية إلى واحدة والحصول على تناسق كامل. لتجنب القبح ، قد نفكر في نقل استدعاء الوظيفة داخل الأقواس ، وربما التخلص من الفواصل الزائدة أيضًا.

لا يزال يتم تحليل |> كعامل infix كما هو الحال الآن ، فلن يكون له قيمة في Base. إذا كنت تستخدمه في ماكرو ، فلا يهم كيف تحدده أي حزمة معينة

ما زلت غير متأكد من سبب حاجتنا إلى إزالته من Base.

يشيرbramtayl إلى نقطة جيدة:

أتخيل ما إذا كانت الحزم تحدد |> سيكون التعريف هو الأساس بالضبط.

ولا تزال الطريقة الوحيدة لاستخدام أكثر من حزمة واحدة والتي تحدد هذا هو عدم استخدامها infix.

لا أرى سبب ضرورة إزالة التعريف في Base لاستخدام |> داخل وحدات الماكرو.

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

ararslan صحيح ، لم يكن هذا ما قصدت أن أسأله ، لقد قمت بتحديث تعليقي بعد ذلك مباشرة ، آسف.

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

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

"أنا لا أزعم أنه ليس مفيدًا ، ولكن يجب أن نكون متسقين"

في بعض الأحيان فائدة تتفوق على الاتساق؟ لم أكن على علم بالتناقض ، لكنني وجدت أن بناء الجملة |> مفيد. إذا تمت إزالته ، فلن أشعر أنني ربحت أي شيء ملموس.

تفسيراً لتصويتي بعلامة الموافقة ، إذا جاز لي:

يمكن أن يحدث الكثير مما يوجد حاليًا في Base في حزم بدلاً من ذلك. هل يجب أن ننقل القواميس إلى حزمة؟ ربما قائمة العمليات مثل الفرز والخلط؟ عمليات التحصيل ، وما إلى ذلك؟ أنا متأكد من أنه كانت هناك مناقشات طويلة ومفصلة بشأن ما يجب وما لا يجب تضمينه في Base ، لكنني أفترض أن هناك ثلاثة أسباب لإدراج بعض الوظائف في القاعدة:
1) هذه الوظيفة ضرورية لتمكين الميزات الأخرى في القاعدة.
2) هذه الوظيفة هي جزء أساسي من اللغة ، سيستخدمها العديد من مبرمجي وحزم جوليا ، وبالتالي من المستحسن أن يكون لديك تطبيق / بناء واحد يتفق عليه الجميع ، بدلاً من تجزئة الكثير من الأشخاص الذين يتداولون بأنفسهم.
3) تضمين هذه الوظيفة في القاعدة يجعل استخدام جوليا "الخام" أكثر متعة أو يجعلها تشعر بمزيد من الميزات الكاملة ، مما يساعد في التبشير باللغة واعتمادها.

شيء من هذا القبيل sum المحتمل أن يصل إلى جميع النقاط الثلاث ، وأنا أزعم أن وظيفة الأنابيب تصل إلى النقطة الثانية والثالثة:

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

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

أنا أزعم أيضًا أن إزالة الأنابيب من Base مع ترك عامل infix موجودًا أمرًا مفاجئًا إلى حد ما: في Julia لا يمكنك تحديد مشغلي infix الخاصين بك ، ولكن هناك مشغل infix غير مستخدم |> معلق حوله يمكنك تعريفه من فضلك؟ إذا كانت هذه وظيفة جيدة ، فلماذا لا تعطينا 10 أو 20 مشغلًا قويًا لتحديد ما نشاء؟

أخيرًا ، أعتقد أنه من الطبيعي الحفاظ على الأنابيب تمامًا لأنها تختلف عن التطبيقات الوظيفية الأخرى. إنها ميزة ، وليست خطأ ، أنها تختلف عن الاصطلاحات الأخرى لتطبيق الوظائف ؛ هذا الاختلاف هو ما يجعله يتألق في بعض حالات الاستخدام. وهناك حالات أخرى حيث (التلويح باليد قليلاً) يأتي الاسم قبل الفعل ، والعديد من هذه الحالات عبارة عن سكر نحوي تمامًا في الحالات التي يكون فيها تطبيق الوظيفة الأولية غير عملي. خارج الجزء العلوي من رأسي ، تقوم المهمة x = 5 بوضع الاسم (الرمز x ) قبل الفعل (ربط بقيمة). وبالمثل للوصول إلى الحقول من الأنواع t.a بدلاً من getfield . والأهم من ذلك ، أن فهرسة المصفوفة z[5] تقرأ مثل "من z تأخذ العنصر الخامس" وهي طبيعية بشكل عام أكثر من getindex(z, 5) .

إذا كانت هذه وظيفة جيدة ، فلماذا لا تعطينا 10 أو 20 مشغلًا قويًا لتحديد ما نشاء؟

من المحتمل أن يكون هناك أكثر من ذلك إذا تضمن أحدهم جميع رموز unicode بالإضافة إلى ASCII غير المطالب به مثل <| ، ++ ، ...

لا تقرأ الموضوع بأكمله - ولكن أردت فقط أن أقول
أحب أن أكون قادرًا على توجيهها. سأصوت مفيدا
الاتساق في أي يوم.

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

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

لا يقرأ الموضوع كله

😕

أنا أحب أن أكون قادرة على الأنابيب

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

في Julia ، لا يمكنك تحديد عوامل التشغيل الخاصة بك

هذا ليس صحيحا؛ يمكن تعريف أو إعادة تعريف أي شيء يتم تحليله كعامل infix. كما أشار Martinholters ، <| و ++ متاحان بالمثل ، من بين أمور أخرى.

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

أرغب في أن يكون |> أكثر قوة ، على سبيل المثال السماح x |> f(_) + 2g(_) |> h وما إلى ذلك ، ولكي لا يكون مجرد عامل. في كل مرة يعرّف فيها أي شخص x |> f على أنه يعني شيئًا ما إلى جانب f(x) ، فإن ذلك يزعجني حقًا لأن النقطة الكاملة للمشغل كما استخدمناها هي أنه بناء جملة استدعاء مختلف الترتيب. نظرًا لأنه يمكننا زيادة تحميل المكالمة ، لا يمكنني رؤية سبب وجيه لوجود x |> f يعني شيئًا آخر.

StefanKarpinski يمكن بالفعل الحصول على أنابيب أكثر قوة باستخدام وحدات الماكرو. انظر على سبيل المثال ، Pipe.jl ، الذي يوفر بالضبط بناء الجملة الذي تصفه. طالما أن |> عامل تشغيل (أنا شخصياً لا أرى أن |> يستحق حالة خاصة) ، يمكن لوحدات الماكرو استخدام أي محدد أنابيب يوزع اللاحمة ، حتى لو لم يكن :call . كمثال ، يمكن للمرء بالمثل استخدام @~ للتوجيه (على الأقل حتى كتابة هذه السطور). يعد هذا المستوى من المرونة أحد مزايا استخدام وحدات الماكرو في Julia.

يمكننا إضافة وظيفة Pipe.jl إلى اللغة ، ومن ثم ستحصل عليها دون الحاجة إلى كتابة @pipe .

السبب الرئيسي لإهمال |> سيكون إذا أردنا استعادة بناء الجملة لغرض آخر يفضله الناس بشكل أفضل.

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

ولكن إذا لم يكن هناك شيء آخر نريده |> أجله ، فأنا لا أرى ضررًا كبيرًا في ترك تعريفه (التافه) بمفرده.

لا أعتقد أن هناك حاليًا أي مقترحات لإعادة تعيين الغرض من |> في الأساس. حجتي لعدم تحديده في Base هي أنه يمنحنا المزيد من الاتساق دون فقدان الوظيفة.

هل يمكن جعل أي مقترحات "أكثر قوة" أو تطبيقات للحزمة أكثر بساطة من خلال عدم وجود هذا التعريف الحالي للقلق بشأنه أو التغلب عليه؟

ararslan "هذا ليس صحيحًا ؛ يمكن تعريف أو إعادة تعريف أي شيء يتم تحليله كعامل infix."

من الدليل "&& and || العوامل" ، يتم تحليلها ولكن لا يمكن إعادة تعريفها (هذا شيء جيد). أعتقد أن الاستثناءات الوحيدة.

ما يسمى ب "العوامل المنطقية" && و || هي infix. [علاقة ثنائية أحادية] "عامل" هو IMHO المصطلح غير الصحيح بالنسبة لهم لأنها ليست كذلك. ليست طريقة مشابهة لمنطقتي & و | التي تسمح بالحمل الزائد (شيء لست متأكدًا من أنه اختيار جيد).

PallHaraldsson هذه عبارة عن تدفق تحكم ، وليست عوامل تشغيل بنفس المعنى مثل & ، | ، + ، إلخ.

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

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

هناك مشكلة أخرى: لجعل |> يعمل مع الكائن الخاص بك ، هل تحدد |> أو "عامل استدعاء الوظيفة" (أي إضافة طرق إليه)؟ قد يكون من الأنظف إذا كان |> عبارة عن بناء جملة مضمّن لاستدعاء الوظيفة ، للتأكد من أن f(x) و x |> f متماثلان دائمًا.

من الواضح أن الإجماع هنا ضد ، لذا سأمضي قدمًا وأغلق القضية. أنا أقدر المناقشة ، الجميع.

أعلم أن هذه القضية مغلقة. أردت فقط أن أقول "شكرًا لك" على إبقاء عامل التشغيل.