ทำไมเราไม่ค้นคว้าเพิ่มเติมเกี่ยวกับการรับประกันเวลารวบรวม?

ฉันรักทุกสิ่งที่รวบรวมเวลาและฉันชอบความคิดที่ว่าเมื่อคุณรวบรวมโปรแกรมการรับประกันจำนวนมากเกี่ยวกับการดำเนินการของมัน โดยทั่วไปการพูดระบบประเภทคงที่ (Haskell, C ++, ... ) ดูเหมือนจะให้การรับประกันเวลาคอมไพล์ที่แข็งแกร่งกว่าระบบประเภทแบบไดนามิกใด ๆ

จากสิ่งที่ฉันเข้าใจ Ada ดำเนินการตรวจสอบเวลาให้ดียิ่งขึ้นไปอีกและสามารถตรวจจับช่วงของข้อผิดพลาดที่มากกว่าก่อนดำเนินการ มันยังถือว่าปลอดภัยพอสมควร ณ เวลาใดเวลาหนึ่งมันถูกเลือกสำหรับฟิลด์ที่ละเอียดอ่อน (เมื่อข้อผิดพลาดในการเขียนโปรแกรมอาจทำให้เสียชีวิต)

ตอนนี้ฉันสงสัยว่า: ถ้าการค้ำประกันแบบคงที่ที่ดีกว่านำไปสู่รหัสที่มีเอกสารและปลอดภัยกว่าแล้วทำไมเราไม่ค้นคว้าเพิ่มเติมในทิศทางนั้น

ตัวอย่างของสิ่งที่ดูเหมือนว่าจะหายไปจะเป็นภาษาที่แทนที่จะกำหนดintประเภททั่วไปที่มีช่วงที่กำหนดโดยจำนวนบิตของสถาปัตยกรรมพื้นฐานหนึ่งอาจมีช่วง (ในตัวอย่างต่อไปนี้Int [a..b]อธิบายถึงชนิดจำนวนเต็มระหว่าง รวม a และ b):

a : Int [1..24]
b : Int [1..12]
a + b : Int [2..36]
a - b : Int [-11..23]
b - a : Int [-23..11]

หรือ (นำสิ่งนี้มาจาก Ada):

a : Int [mod 24]
b : Int [mod 24]
a + b : Int [mod 24]

ภาษานี้จะเลือกประเภทพื้นฐานที่ดีที่สุดสำหรับช่วงและทำการตรวจสอบเวลาคอมไพล์ในนิพจน์ ตัวอย่างเช่นที่กำหนด:

a : Int [-3..24]
b : Int [3..10]

แล้ว:

a / b

จะไม่ถูกนิยาม

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

ผมไม่ได้อยู่ในฐานะที่จะบอกได้ว่ามากมากขึ้นการวิจัยควรจะทำในหัวข้อ แต่ผมสามารถบอกคุณได้ว่ามีเป็นงานวิจัยที่กำลังทำตัวอย่างเช่นVerisoft XTโปรแกรมได้รับทุนจากรัฐบาลเยอรมัน

แนวคิดที่ฉันคิดว่าคุณกำลังมองหาเรียกว่าการตรวจสอบอย่างเป็นทางการและการเขียนโปรแกรมตามสัญญาที่หลังเป็นวิธีที่เป็นมิตรกับโปรแกรมเมอร์ในการทำครั้งแรก ในการเขียนโปรแกรมตามสัญญาคุณต้องเขียนรหัสของคุณตามปกติแล้วใส่สัญญาที่เรียกว่าลงในรหัส ภาษาที่ใช้งานง่ายซึ่งตั้งอยู่บนพื้นฐานของกระบวนทัศน์นี้คือSpec #โดย Microsoft Research และส่วนขยายที่คล้ายกัน แต่มีฟังก์ชั่นสัญญารหัสสวยน้อยสำหรับ C # ซึ่งคุณทั้งสองสามารถลองออนไลน์ได้ (พวกเขายังมีเครื่องมือคล้ายกัน ) "int with range type" ที่คุณกล่าวถึงจะสะท้อนโดยสัญญาสองสัญญาในฟังก์ชัน:

Contract.Requires(-3 <= a && a <= 24);
Contract.Requires( 3 <= b && b <= 10);

ถ้าคุณต้องการเรียกใช้ฟังก์ชันนั้นคุณต้องใช้พารามิเตอร์ที่มั่นใจว่าตรงตามเกณฑ์เหล่านี้หรือคุณได้รับข้อผิดพลาดเวลารวบรวม ข้างต้นเป็นสัญญาที่ง่ายมากคุณสามารถแทรกข้อสันนิษฐานหรือความต้องการเกี่ยวกับตัวแปรหรือ exeptions และความสัมพันธ์ของพวกเขาที่คุณอาจนึกถึงและคอมไพเลอร์จะตรวจสอบว่าความต้องการทุกอย่างถูกครอบคลุมโดยสมมติฐานหรือสิ่งที่สามารถมั่นใจได้ จากสมมติฐาน นั่นคือสาเหตุที่ชื่อมาจาก: ผู้สร้างทำตามความต้องการผู้โทรทำให้แน่ใจได้ว่าสิ่งเหล่านี้เป็นไปตามสัญญาทางธุรกิจ

$P(x_1,x_2,...,x_n)$$n$$P$ถูกนำมาใช้. จากฝั่ง CS ทั้งสองเป็นส่วนสำคัญของกระบวนการ - การสร้างเงื่อนไขการตรวจสอบมีความยุ่งยากและ SMT เป็นปัญหาที่สมบูรณ์แบบหรือสมบูรณ์ไม่ได้ขึ้นอยู่กับทฤษฎีที่พิจารณา แม้จะมีการแข่งขันสำหรับนักแก้ปัญหา SMT ดังนั้นจึงมีการวิจัยในเรื่องนี้อย่างแน่นอน นอกจากนี้ยังมีวิธีการอื่นในการใช้ SMT สำหรับการตรวจสอบอย่างเป็นทางการเช่นการแจงนับพื้นที่ของรัฐการตรวจสอบแบบจำลองสัญลักษณ์การตรวจสอบแบบจำลองที่มีขอบเขตและอีกมากมายที่กำลังทำการวิจัยอยู่

เกี่ยวกับข้อ จำกัด ของแนวคิดทั่วไป:

• ดังที่ระบุไว้ก่อนหน้าการพิสูจน์ความถูกต้องของโปรแกรมนั้นเป็นปัญหาที่เกิดจากการคำนวณอย่างหนักดังนั้นจึงอาจเป็นไปได้ว่าการตรวจสอบเวลาคอมไพล์ของโปรแกรมที่มีสัญญา (หรือข้อกำหนดอื่น ๆ ) ใช้เวลานานมากหรืออาจเป็นไปไม่ได้ การใช้ฮิวริสติกซึ่งทำงานได้ดีเกือบตลอดเวลานั้นเป็นวิธีที่ดีที่สุดที่ทำได้
• ยิ่งคุณระบุเกี่ยวกับโปรแกรมของคุณมากเท่าใดความน่าจะเป็นที่จะมีข้อบกพร่องในสเปคนั้นยิ่งสูงขึ้น สิ่งนี้สามารถนำไปสู่ผลบวกที่ผิดพลาด (การตรวจสอบเวลาในการรวบรวมล้มเหลวแม้ว่าทุกอย่างจะปราศจากข้อผิดพลาด) หรือการแสดงผลที่ผิดพลาดของความปลอดภัยแม้ว่าโปรแกรมของคุณจะยังมีข้อบกพร่องก็ตาม
• การเขียนสัญญาหรือข้อกำหนดเป็นงานที่น่าเบื่อและโปรแกรมเมอร์ส่วนใหญ่ขี้เกียจเกินกว่าจะทำ ลองเขียนโปรแกรม C # ด้วยสัญญารหัสทุกแห่งหลังจากนั้นสักครู่คุณจะคิดว่า "เข้ามานี่เป็นสิ่งที่จำเป็นจริงๆเหรอ?" นั่นคือเหตุผลที่โดยปกติการตรวจสอบอย่างเป็นทางการมักใช้สำหรับการออกแบบฮาร์ดแวร์และระบบความปลอดภัยที่สำคัญเช่นซอฟต์แวร์ที่ควบคุมเครื่องบินหรือยานยนต์

สิ่งสุดท้ายที่ควรค่าแก่การกล่าวถึงซึ่งไม่เหมาะกับคำอธิบายข้างต้นคือฟิลด์ที่เรียกว่า "ทฤษฎีความซับซ้อนโดยปริยาย" ตัวอย่างเช่นบทความนี้ มันมีจุดมุ่งหมายในการกำหนดลักษณะการเขียนโปรแกรมภาษาซึ่งแต่ละโปรแกรมที่คุณสามารถเขียนลงในคลาสความซับซ้อนที่เฉพาะเจาะจงเช่น P ในภาษาดังกล่าวแต่ละโปรแกรมที่คุณเขียนจะ "มั่นใจ" โดยอัตโนมัติให้เป็นพหุนามซึ่งสามารถตรวจสอบได้ ในเวลารวบรวมโดยเพียงแค่รวบรวมโปรแกรม ฉันไม่ทราบถึงผลการใช้งานจริงของการวิจัยนี้ แต่ฉันก็ยังห่างไกลจากการเป็นผู้เชี่ยวชาญ