เหตุใดแนวคิดของการประเมินแบบขี้เกียจจึงมีประโยชน์

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

กระบวนทัศน์นี้สามารถใช้เพื่อสร้างซอฟต์แวร์ที่สามารถคาดการณ์ได้ซึ่งทำงานได้ตามที่ตั้งใจไว้เมื่อเราไม่รับประกันว่าจะให้มีการประเมินการแสดงออกเมื่อใดและที่ไหน

คำตอบจำนวนมากกำลังเข้าสู่รายการต่าง ๆ เช่นรายการที่ไม่มีที่สิ้นสุดและประสิทธิภาพที่เพิ่มขึ้นจากการคำนวณที่ไม่ได้ประเมินค่า แต่สิ่งนี้ขาดแรงจูงใจที่ยิ่งใหญ่กว่าสำหรับความขี้เกียจนั่นคือต้นแบบ

ข้อโต้แย้งคลาสสิกวางอยู่ในเอกสารที่มีการอ้างถึงมาก"Why Functional Programming Matters" (ลิงค์ PDF)โดย John Hughes ตัวอย่างคีย์ในกระดาษนั้น (ตอนที่ 5) กำลังเล่น Tic-Tac-Toe โดยใช้อัลกอริทึมการค้นหาอัลฟาเบต้า จุดสำคัญคือ (หน้า 9):

[การประเมิน Lazy] ทำให้เป็นประโยชน์ในการทำให้โมดูลเป็นโปรแกรมที่สร้างคำตอบที่เป็นไปได้จำนวนมากและตัวเลือกที่เลือกคำตอบที่เหมาะสม

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

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

1. การรวมการสร้างและการบริโภคเข้ากับฟังก์ชั่นเดียวกัน;
2. การเขียนผู้ผลิตที่ทำงานได้ดีที่สุดสำหรับผู้บริโภคบางรายเท่านั้น
3. ใช้ความเกียจคร้านของคุณเอง

กระบวนทัศน์นี้สามารถใช้เพื่อสร้างซอฟต์แวร์ที่สามารถคาดการณ์ได้ซึ่งทำงานได้ตามที่ตั้งใจไว้เมื่อเราไม่รับประกันว่าจะให้มีการประเมินการแสดงออกเมื่อใดและที่ไหน

เมื่อนิพจน์ไม่มีผลข้างเคียงลำดับของนิพจน์ที่ถูกประเมินจะไม่ส่งผลกระทบต่อค่าของมันดังนั้นพฤติกรรมของโปรแกรมจะไม่ได้รับผลกระทบจากคำสั่งนั้น ดังนั้นพฤติกรรมสามารถทำนายได้อย่างสมบูรณ์แบบ

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

หากคุณคุ้นเคยกับฐานข้อมูลวิธีการประมวลผลข้อมูลที่พบบ่อยคือ:

• ถามคำถามเช่น select * from foobar
• ในขณะที่มีข้อมูลมากขึ้นให้ทำ: รับผลการค้นหาแถวถัดไปแล้วประมวลผล

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

การประเมินผลขี้เกียจค่อนข้างใกล้เคียงกับสิ่งเดียวกัน สมมติว่าคุณมีรายการที่ไม่สิ้นสุดกำหนดไว้เช่น ลำดับฟีโบนักชี - หากคุณต้องการตัวเลขห้าตัวคุณจะได้รับการคำนวณตัวเลขห้าตัว ถ้าคุณต้องการ 1,000 คุณจะได้ 1,000 เคล็ดลับคือรันไทม์รู้ว่าจะต้องจัดหาที่ไหนและเมื่อไหร่ มันมีประโยชน์มาก ๆ

(โปรแกรมเมอร์ Java สามารถเลียนแบบพฤติกรรมนี้ด้วย Iterators - ภาษาอื่นอาจมีบางสิ่งที่คล้ายกัน)

ลองถามฐานข้อมูลของคุณเพื่อหารายชื่อผู้ใช้ 2,000 คนแรกที่มีชื่อขึ้นต้นด้วย "Ab" และมีอายุมากกว่า 20 ปี พวกเขาจะต้องเป็นผู้ชาย

นี่คือแผนภาพเล็ก ๆ

You                                            Program Processor
------------------------------------------------------------------------------
Get the first 2000 users ---------->---------- OK!
                         --------------------- So I'll go get those records...
WAIT! Also, they have to ---------->---------- Gotcha!
start with "Ab"
                         --------------------- NOW I'll get them...
WAIT! Make sure they're  ---------->---------- Good idea Boss!
over 20!
                         --------------------- Let's go then...
And one more thing! Make ---------->---------- Anything else? Ugh!
sure they're male!

No that is all. :(       ---------->---------- FINE! Getting records!

                         --------------------- Here you go. 
Thanks Postgres, you're  ---------->----------  ...
my only friend.

อย่างที่คุณเห็นจากการมีปฏิสัมพันธ์อันน่ากลัวนี้ "ฐานข้อมูล" ไม่ได้ทำอะไรเลยจนกระทั่งพร้อมที่จะรับมือกับทุกเงื่อนไข มันเป็นผลลัพธ์ที่ขี้เกียจในแต่ละขั้นตอนและใช้เงื่อนไขใหม่ทุกครั้ง

ตรงกันข้ามกับการรับผู้ใช้ 2,000 คนแรกคืนพวกเขากรองพวกเขาสำหรับ "Ab" คืนพวกเขากรองพวกเขานานกว่า 20 คืนพวกเขากลับและกรองตัวผู้และสุดท้ายก็ส่งคืนพวกเขา

ขี้เกียจโหลดสั้น ๆ

การประเมินค่านิพจน์ที่ขี้เกียจจะทำให้ผู้ออกแบบโค้ดที่กำหนดสูญเสียการควบคุมลำดับที่โค้ดถูกเรียกใช้

ผู้ออกแบบไม่ควรสนใจเกี่ยวกับลำดับที่นิพจน์ได้รับการประเมินหากผลลัพธ์นั้นเหมือนกัน โดยการชะลอการประเมินอาจเป็นไปได้ที่จะหลีกเลี่ยงการประเมินนิพจน์ทั้งหมดซึ่งช่วยประหยัดเวลา

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

มีข้อโต้แย้งหลายประการสำหรับการประเมินแบบขี้เกียจฉันคิดว่าน่าสนใจ

1. Modularityด้วยการประเมินผลที่ขี้เกียจคุณสามารถแยกรหัสออกเป็นส่วนต่างๆ ตัวอย่างเช่นสมมติว่าคุณมีปัญหาในการ "ค้นหา 10 หลักแรกขององค์ประกอบในรายการที่มีค่าน้อยกว่า 1 ซึ่งกันและกัน" ในบางอย่างเช่น Haskell คุณสามารถเขียนได้

   take 10 . filter (<1) . map (1/)
   

   แต่นี่เป็นเพียงภาษาที่ไม่ถูกต้องเนื่องจากถ้าคุณให้[2,3,4,5,6,7,8,9,10,11,12,0]คุณคุณจะถูกหารด้วยศูนย์ ดูคำตอบของ sacundim สำหรับสาเหตุที่สิ่งนี้ยอดเยี่ยมในทางปฏิบัติ

2. สิ่งต่าง ๆ ทำงานได้อย่างเคร่งครัด (ตั้งใจให้ใช้) โปรแกรมจำนวนมากสิ้นสุดด้วยการประเมินที่ไม่เข้มงวดกว่าการประเมินที่เข้มงวด หากโปรแกรมของคุณสิ้นสุดด้วยกลยุทธ์การประเมิน "กระตือรือร้น" โปรแกรมจะยุติการใช้งานด้วย "ขี้เกียจ" แต่ oposite นั้นไม่เป็นความจริง คุณได้รับสิ่งต่าง ๆ เช่นโครงสร้างข้อมูลที่ไม่มีที่สิ้นสุด (ซึ่งจริงๆแล้วก็แค่ค่อนข้างเย็น) เป็นตัวอย่างเฉพาะของปรากฏการณ์นี้ โปรแกรมอื่น ๆ ใช้ภาษาขี้เกียจ

3. Optimality การประเมินความต้องการการโทรตามความต้องการนั้นเหมาะสมที่สุดแบบ asymptotically ตามเวลา แม้ว่าภาษาสันหลังยาวที่สำคัญ (ซึ่งโดยหลักคือ Haskell และ Haskell) ไม่ได้สัญญาว่าจะโทรตามความต้องการ แต่คุณสามารถคาดหวังได้ว่าแบบจำลองราคาที่เหมาะสมที่สุด เครื่องวิเคราะห์ความเข้มงวด (และการประเมินผลเก็งกำไร) ทำให้ค่าใช้จ่ายลดลงในทางปฏิบัติ อวกาศเป็นเรื่องที่ซับซ้อนมากขึ้น

4. บังคับให้ความบริสุทธิ์โดยใช้การประเมินที่ขี้เกียจทำให้การรับมือกับผลข้างเคียงในลักษณะที่ไม่ได้รับความเจ็บปวดโดยรวมเนื่องจากเมื่อคุณวางไว้โปรแกรมเมอร์ก็สูญเสียการควบคุม นี่เป็นสิ่งที่ดี ความโปร่งใสอ้างอิงทำให้การเขียนโปรแกรมการหักเหและเหตุผลเกี่ยวกับโปรแกรมง่ายขึ้นมาก ภาษาที่เข้มงวดอย่างหลีกเลี่ยงไม่ได้กับความกดดันของการมีบิตที่ไม่บริสุทธิ์ - สิ่งที่ Haskell และ Clean ได้ต่อต้านอย่างสวยงาม นี่ไม่ได้เป็นการบอกว่าผลข้างเคียงเป็นสิ่งชั่วร้ายเสมอไป แต่การควบคุมพวกมันมีประโยชน์มากด้วยเหตุผลนี้เพียงอย่างเดียวก็เพียงพอที่จะใช้ภาษาที่ขี้เกียจ

สมมติว่าคุณมีข้อเสนอการคำนวณราคาแพงจำนวนมาก แต่ไม่ทราบว่าจะต้องใช้การคำนวณแบบใดหรือแบบใด คุณสามารถเพิ่มโปรโตคอล Mother-May-i ที่ซับซ้อนเพื่อบังคับให้ผู้บริโภคเข้าใจว่ามีอะไรให้บ้างและทริกเกอร์การคำนวณที่ยังไม่เสร็จ หรือคุณสามารถให้อินเทอร์เฟซที่ทำหน้าที่เหมือนกับการคำนวณเสร็จสิ้นทั้งหมด

นอกจากนี้สมมติว่าคุณมีผลลัพธ์ที่ไม่สิ้นสุด ชุดของช่วงเวลาทั้งหมดเช่น เห็นได้ชัดว่าคุณไม่สามารถคำนวณชุดล่วงหน้าได้ดังนั้นการดำเนินการใด ๆ ในโดเมนของช่วงเวลาจำเป็นต้องขี้เกียจ

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

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