โดยนัยกับการพิมพ์ย่อยที่ชัดเจน


18

หน้านี้อ้างว่า

หลายภาษาไม่ได้ใช้การพิมพ์ย่อยโดยนัย (ความเท่าเทียมกันเชิงโครงสร้าง), การเลือกพิมพ์ย่อยที่ชัดเจน / ประกาศ (การประกาศความเท่าเทียมกัน)

ผมเคยใช้ส่วนใหญ่เป็นภาษาโปรแกรมที่ใช้อย่างชัดเจนsubtyping อะไรคือข้อดีของการพิมพ์ย่อยโดยนัยตามที่อธิบายไว้ในหมายเหตุข้างต้น


1
จากคำถามที่พบบ่อยในขอบเขตของการแลกเปลี่ยนนี้: "งานในสาขานี้มักจะโดดเด่นด้วยการเน้นเทคนิคและความแม่นยำทางคณิตศาสตร์" ฉันกำลังลงเนื่องจากฉันไม่เห็นขอบเขตของความแม่นยำในการตอบคำถามนี้
David Eppstein

6
น่าเศร้าที่มีขอบเขตความเข้มงวดในการตอบคำถามนี้มากกว่าที่คุณคาดหวังในตอนแรก ผู้คนที่โด่งดังจำนวนมากได้เผาผลาญมวยปล้ำ 90 ครั้งด้วยคำถามที่ไม่สำคัญเกี่ยวกับการพิมพ์ย่อย เป็นพื้นที่ที่มีอัตราส่วนความพยายามในการให้รางวัลต่ำมากโชคไม่ดี
Neel Krishnaswami

6
ใช่มีพื้นที่มากมายสำหรับคณิตศาสตร์และความแม่นยำในการตอบคำถามนี้หรืออย่างน้อยก็เพื่ออธิบายทางคณิตศาสตร์ว่าการพิมพ์ย่อยโดยนัยคืออะไร ฉันไม่แน่ใจเกี่ยวกับอัตราส่วนความพยายามในการให้รางวัล
Noam Zeilberger

1
ฉันอาจจะต้องบอกว่ามันเป็น "ยากมาก" เนื่องจากเมื่อไตร่ตรองแล้วฉันก็รู้ว่าฉันสนใจคำตอบ
Neel Krishnaswami

1
ตกลงฉันมั่นใจ ฉันจะลบ downvote ของฉัน แต่ระบบจะไม่ยอมให้ฉัน
David Eppstein

คำตอบ:


19

คำตอบสั้น ๆ คือ "เพื่อตรวจสอบคุณสมบัติเพิ่มเติมของรหัสที่มีอยู่" คำตอบอีกต่อไปนี้

ฉันไม่แน่ใจว่า "นัย" กับ "ชัดเจน" เป็นคำศัพท์ที่ดี ความแตกต่างนี้บางครั้งเรียกว่า subtyping "โครงสร้าง" กับ "เล็กน้อย" จากนั้นยังมีความแตกต่างที่สองในการตีความที่เป็นไปได้ของการพิมพ์ย่อยโครงสร้าง (อธิบายสั้น ๆ ) โปรดทราบว่าการตีความ subtyping ทั้งสามนั้นเป็น orthogonal ดังนั้นจึงไม่สมเหตุสมผลที่จะเปรียบเทียบมันกับแต่ละอื่น ๆ แทนที่จะเข้าใจการใช้ของแต่ละคน

ความแตกต่างในการปฏิบัติงานหลักในการตีความความสัมพันธ์ของประเภทย่อยของโครงสร้าง A <: B คือไม่ว่าจะมีการข่มขู่จริงด้วยเนื้อหาการคำนวณ (รันไทม์ / คอมไพล์ไทม์) หรือไม่หรือสามารถเห็นได้ด้วยการบังคับตัวตน ถ้าในอดีตคุณสมบัติทางทฤษฎีที่สำคัญที่ต้องเก็บไว้คือ "การเชื่อมโยงกัน" เช่นถ้ามีหลายวิธีที่จะแสดงว่า A เป็นชนิดย่อย substructural ของ B, coercions ประกอบแต่ละคนจะต้องมีเนื้อหาการคำนวณเดียวกัน

ดูเหมือนว่าลิงก์ที่คุณให้จะมีการตีความที่สองเกี่ยวกับประเภทย่อยของโครงสร้างซึ่ง A <: B สามารถเห็นได้จากการข่มขู่ตัวตน บางครั้งสิ่งนี้เรียกว่า "การตีความชุดย่อย" ของการพิมพ์ย่อยการรับมุมมองที่ไร้เดียงสาว่าประเภทแสดงถึงชุดของค่าและดังนั้น A <: B ในกรณีที่ค่าทุกประเภทของ A เป็นค่าของประเภท B ด้วยเช่นกัน บางครั้งเรียกว่า "การปรับแต่งการพิมพ์" และกระดาษที่ดีในการอ่านสำหรับแรงจูงใจเดิมเป็นอิสระและ Pfenning ของประเภทการปรับแต่งสำหรับ ML สำหรับการจุติใหม่ ๆ ใน F # คุณสามารถอ่าน Bengston et al, ประเภทการปรับแต่งสำหรับการปรับใช้ที่ปลอดภัย. แนวคิดพื้นฐานคือการใช้ภาษาการเขียนโปรแกรมที่มีอยู่แล้วซึ่งอาจ (หรืออาจจะไม่) มีประเภทอยู่แล้ว แต่ในประเภทที่ไม่รับประกันว่ามาก (เช่นความปลอดภัยของหน่วยความจำเท่านั้น) และพิจารณาชั้นที่สองของประเภทย่อยเลือกโปรแกรมด้วย คุณสมบัติเพิ่มเติมที่แม่นยำยิ่งขึ้น

(ตอนนี้ฉันจะยืนยันว่าทฤษฎีทางคณิตศาสตร์ที่อยู่เบื้องหลังการตีความ subtyping นี้ยังไม่เข้าใจเท่าที่ควรและอาจเป็นเพราะการใช้งานของมันไม่ได้รับการยอมรับอย่างกว้างขวางเท่าที่ควรจะเป็นปัญหาหนึ่งคือ "ชุด ของค่า "การตีความประเภทไร้เดียงสาเกินไปและบางครั้งมันก็ถูกทอดทิ้งแทนที่จะขัดเกลาสำหรับเหตุผลอื่นที่การตีความ subtyping นี้สมควรได้รับความสนใจทางคณิตศาสตร์มากขึ้นอ่านคำแนะนำเกี่ยวกับSubspacesของ Paul Taylor ใน Abstract Stone Duality )


A×B×<:A×BAB

1
มันเป็นหน้าที่ของเครื่องมือเพิ่มประสิทธิภาพในการหาเลย์เอาต์ของหน่วยความจำที่ดีที่สุดดังนั้นการข่มขู่ซึ่งเป็นข้อมูลเฉพาะตัวควรเป็นผลมาจากการปรับให้เหมาะสม
Andrej Bauer

2
ดังนั้นเพียงเพื่อชี้แจงความคิดเห็นของ Andrej เกี่ยวกับคำตอบของฉันในการตีความการพิมพ์การปรับแต่งความสัมพันธ์ subtyping มักจะเห็นโดยการข่มขู่ตัวตนตามคำนิยามเพราะประเภทการปรับแต่งไม่มีเนื้อหาการคำนวณพิเศษ กล่าวอีกนัยหนึ่งถ้า A และ B เป็นสองการปรับแต่ง ("คุณสมบัติย่อย" / "คุณสมบัติ") ของประเภทของค่า X, A <: B ยืนยันว่าสำหรับทุกค่า x ใน X ถ้า X: A แล้วยัง x: B คำสั่งดังกล่าวสามารถตรวจสอบหรือปลอมแปลงได้ แต่จะไม่มีผลกระทบที่รันไทม์เนื่องจากการพิสูจน์ว่า x: A และ x: B ไม่มีอยู่ที่รันไทม์
Noam Zeilberger

1
ยังไม่มีข้อความ{x:ยังไม่มีข้อความ|x<232}

3
ยังไม่มีข้อความ{x:ยังไม่มีข้อความ|x<232}ยังไม่มีข้อความ{x:ยังไม่มีข้อความ|x<232}
Noam Zeilberger

4

คำตอบนี้เป็นส่วนเสริมขั้นต่ำสำหรับคำตอบที่ยอดเยี่ยมของ Noam จุดข้อมูลหนึ่งที่น่าสนใจคือชะตากรรมของแนวคิด C ++ ซึ่งก่อตั้งขึ้นเมื่อมีความพยายามที่จะรวมความคิดที่ระบุและโครงสร้างของประเภท

มีการเขียนที่ยอดเยี่ยมที่นี่พร้อมลิงก์ไปยังการอภิปรายที่เกี่ยวข้องมาก: http://bartoszmilewski.wordpress.com/2010/06/24/c-concepts-a-postmortem/

อย่างไรก็ตามการเขียนข้างต้นไม่ได้กล่าวถึงปัญหาเล็กน้อยกับโครงสร้างในเชิงลึกใด ๆ มีการเขียนอีกที่นี่ซึ่งทำ: http://nerdland.net/2009/07/alas-concepts-we-hardly-knew-ye/

ประเด็นสำคัญทั้งสองข้อคือ Bjarne Stroustrup เรื่อง“ การลดความซับซ้อนของการใช้แนวคิด”: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdfซึ่งนำไปใช้งานได้จริง ปัญหาที่พบในบางส่วน

โดยรวมแล้วการสนทนาในทางปฏิบัติมีความเข้มงวดมากกว่าในทางปฏิบัติ อย่างไรก็ตามมันให้ความเข้าใจที่ดีเกี่ยวกับประเภทของการแลกเปลี่ยนที่เกี่ยวข้องกับปัญหาเหล่านี้โดยเฉพาะอย่างยิ่งในบริบทของภาษาที่มีขนาดใหญ่

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.