مساحات أسماء منفصلة للوظائف والمتغيرات في اللثغة المشتركة مقابل المخطط

Question

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

(ملاحظة 1:وهذا السؤال يحتاج إلى مثال لما سبق؛لا تتردد في تعديله وإضافة واحد، أو إرسال بريد إلكتروني إلى المؤلف الأصلي معه وسأفعل ذلك.)

ومع ذلك، في بعض السياقات، مثل تمرير الوظائف كمعلمات إلى وظائف أخرى، يجب على المبرمج أن يميز بوضوح أنه يحدد متغير دالة، بدلاً من متغير غير دالة، باستخدام #', ، كما في:

(sort (list '(9 A) '(3 B) '(4 C)) #'< :key #'first)

لقد كنت أعتبر هذا دائمًا بمثابة ثؤلول إلى حد ما، لكنني واجهت مؤخرًا أحد هذه الثآليل دعوى أن هذه في الواقع ميزة:

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

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

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

data Point = Point { x, y :: Double {- lots of other fields as well --} }
isOrigin p = (x p == 0) && (y p == 0)

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

isOrigin2 Point{x,y} = (x == 0) && (y == 0)

لذلك، بالنسبة للسؤال، بعيدًا عن الاتساق، ما هي المزايا والعيوب، لكل من Common Lisp وCommon Lisp.مخطط وبشكل عام لمساحة اسم واحدة لجميع القيم مقابل القيم المنفصلة للوظائف والقيم غير الوظيفية؟

Answer 1

الطريقتان المختلفتان لهما أسماء:ليسب-1 و ليسب-2.يحتوي Lisp-1 على مساحة اسم واحدة لكل من المتغيرات والوظائف (كما في Scheme) بينما يحتوي Lisp-2 على مساحات أسماء منفصلة للمتغيرات والوظائف (كما في Common Lisp).أذكر هذا لأنك قد لا تكون على علم بالمصطلحات لأنك لم تشر إليها في سؤالك.

ويكيبيديا يشير إلى هذا النقاش:

ما إذا كانت مساحة الاسم المنفصلة للوظائف تعتبر ميزة أم لا، فهي مصدر خلاف في مجتمع Lisp.يشار إليه عادةً باسم Lisp-1 vs.مناقشة ليسب-2.يشير Lisp-1 إلى نموذج Scheme ويشير Lisp-2 إلى نموذج Common Lisp.تمت صياغة هذه الأسماء في ورقة بحثية عام 1988 بقلم ريتشارد ب.غابرييل وكينت بيتمان، الذي يقارن على نطاق واسع بين النهجين.

ورقة غابرييل وبيتمان بعنوان القضايا الفنية للفصل في الخلايا الوظيفية وخلايا القيمة يعالج هذه القضية بالذات.

Answer 2

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

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

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

وأنا أيضا أحب ما كان باسكال كونستانزا ل يقول حول هذا الموضوع.

Answer 3

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

وغير وظائف يمكن أن يسمى أيضا (إذا فصولهم الدراسية تحدد __call__، في حالة بيثون - حالة خاصة من "الحمولة الزائدة المشغل") وبالتالي فإن "التمييز السياقي" ليست بالضرورة واضحة، إما

ولكن، تجربتي "ثغة-OID" هو / كان في الغالب مع نظام بدلا من اللثغة المشتركة، لذلك قد يكون متحيزا لا شعوريا من قبل الألفة مع مساحة موحد في النهاية يأتي من تلك التجربة.

Answer 4

واسم وظيفة في مخطط هو مجرد متغير مع وظيفة كقيمة لها. اذا كنت تفعل (define x (y) (z y)) أو (let ((x (lambda (y) (z y))))، أنا تحديد الوظيفة التي يمكن أن أدعو. وبالتالي فإن فكرة أن "اسم متغير يريد نادرا ما تظهر هناك" هو نوع من خادع بقدر ما يتعلق الأمر مخطط.

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

Answer 5

والجانب السلبي أكبر أرى، على الأقل في اللثغة المشتركة، هو الفهم. يمكننا أن نتفق جميعا على أنه يستخدم بمساحات مختلفة للمتغيرات وظائف، ولكن كم أنها لا تملك؟ في PAIP، أظهرت نورفيج أن لديها "سبعة على الأقل" مساحة الأسماء.

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

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

Answer 6

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