Groovy เรียกแอปพลิเคชั่นบางส่วนว่า 'currying' หรือไม่?

Groovy มีแนวคิดที่เรียกว่า 'currying' นี่คือตัวอย่างจากวิกิ:

def divide = { a, b -> a / b }

def halver = divide.rcurry(2)

assert halver(8) == 4

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

คำว่า currying มักจะใช้เพื่อหมายถึงการเปลี่ยนฟังก์ชั่นที่นำชุดของข้อโต้แย้งเป็นฟังก์ชั่นที่ใช้เพียงหนึ่งอาร์กิวเมนต์และส่งกลับฟังก์ชั่นอื่น ตัวอย่างเช่นนี่คือประเภทของcurryฟังก์ชั่นใน Haskell:

curry :: ((a, b) -> c) -> (a -> (b -> c))

สำหรับคนที่ไม่ได้ใช้ Haskell a, bและcพารามิเตอร์ทั่วไปทั้งหมด curryใช้เวลาฟังก์ชั่นที่มีสองข้อโต้แย้งและผลตอบแทนฟังก์ชั่นที่ใช้aและผลตอบแทนการทำงานจากการb cฉันได้เพิ่มวงเล็บพิเศษลงในประเภทเพื่อทำให้ชัดเจนยิ่งขึ้น

ฉันเข้าใจผิดหรือเปล่าว่าเกิดอะไรขึ้นในตัวอย่างของความแรงหรือเป็นเพียงบางส่วนที่ใช้ผิด? หรือทำทั้งสองอย่างในความเป็นจริง: กล่าวคือแปลงdivideเป็นฟังก์ชัน curried แล้วนำ2ไปใช้กับฟังก์ชันใหม่นี้บางส่วน

การนำไปใช้ของ Groovy curryไม่ได้เกิดขึ้นจริงในทุกช่วงเวลาแม้แต่หลังฉาก มันเป็นหลักเหมือนกับการประยุกต์ใช้บางส่วน

curry, rcurryและncurryวิธีการส่งคืนCurriedClosureวัตถุที่มีข้อโต้แย้งที่ถูกผูกไว้ นอกจากนี้ยังมีวิธีการgetUncurriedArguments(ฟังผิด - คุณแกงฟังก์ชั่นไม่ขัดแย้ง) ซึ่งส่งกลับองค์ประกอบของข้อโต้แย้งที่ส่งผ่านไปยังมันด้วยข้อโต้แย้งที่ถูกผูกไว้

เมื่อมีการปิดรับการเรียกว่าในท้ายที่สุดมันเรียกวิธีการที่ชัดเจนตรวจสอบเพื่อดูว่าวัตถุที่เรียกเป็นตัวอย่างของ ถ้าเป็นเช่นนั้นจะใช้การดังกล่าวข้างต้นเพื่อเขียนอาเรย์เต็มรูปแบบของการขัดแย้งที่จะนำไปใช้:invokeMethodMetaClassImplCurriedClosuregetUncurriedArguments

if (objectClass == CurriedClosure.class) {
    // ...
    final Object[] curriedArguments = cc.getUncurriedArguments(arguments);
    // [Ed: Yes, you read that right, curried = uncurried. :) ]
    // ...
    return ownerMetaClass.invokeMethod(owner, methodName, curriedArguments);
}

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

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

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

def add = { x, y -> x + y }
def addCurried = add.curry()   // should work like { x -> { y -> x + y } }
def add1 = addCurried(1)       // should work like { y -> 1 + y }
assert add1(1) == 2 

... และมันก็ใช้ได้เพราะaddCurriedควรทำเช่น{ x -> { y -> x + y } }นั้น แต่มันเป็นข้อยกเว้นรันไทม์และคุณตายภายในเล็กน้อย

ฉันคิดว่าเป็นที่ชัดเจนว่าจริง ๆ แล้วแกงกะหรี่ Groovy เป็นแอปพลิเคชั่นบางส่วนเมื่อพิจารณาฟังก์ชั่นที่มีข้อโต้แย้งมากกว่าสองข้อ พิจารณา

f :: (a,b,c) -> d

รูปแบบ curried ของมันจะเป็น

fcurried :: a -> b -> c -> d

แต่แกงกะหรี่ของ Groovy จะคืนสิ่งที่เทียบเท่า (สมมติว่ามี 1 อาร์กิวเมนต์ x)

fgroovy :: (b,c) -> d 

ซึ่งจะเรียก f ด้วยค่าคงที่ถึง x

เช่นในขณะที่แกงกะหรี่ของ Groovy สามารถส่งคืนฟังก์ชันด้วยอาร์กิวเมนต์ N-1 แต่ฟังก์ชัน curried อย่างถูกต้องมีอาร์กิวเมนต์ 1 เท่านั้นดังนั้น Groovy จึงไม่สามารถแกงด้วยแกง

Groovy ยืมการตั้งชื่อวิธีการแกงจากภาษา FP อื่น ๆ ที่ไม่บริสุทธิ์ซึ่งใช้การตั้งชื่อที่คล้ายกันสำหรับแอปพลิเคชันบางส่วน - อาจโชคร้ายสำหรับฟังก์ชันการทำงานที่เป็นศูนย์กลางของ FP มีการนำเสนอ currying "ของจริง" หลายอย่างเพื่อรวมไว้ใน Groovy กระทู้ที่ดีในการเริ่มอ่านเกี่ยวกับพวกเขาอยู่ที่นี่:

http://groovy.markmail.org/thread/c4ycxdzm3ack6xxb

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

สำหรับโปรแกรมเมอร์ OO ส่วนใหญ่ความแตกต่างระหว่างคำสองคำ (การสมัครใจและการสมัครบางส่วน) นั้นมีเนื้อหาเชิงวิชาการเป็นส่วนใหญ่ อย่างไรก็ตามเมื่อคุณคุ้นเคยกับพวกเขา (และใครก็ตามที่จะรักษารหัสของคุณได้รับการฝึกฝนให้อ่านสไตล์การเขียนโปรแกรมนี้) จากนั้นการเขียนโปรแกรมแบบไม่มีจุดหรือแบบโดยปริยาย และในบางกรณีอย่างหรูหรามากขึ้น เห็นได้ชัดว่ามี "ความงามอยู่ในสายตาของคนดู" ที่นี่ แต่การมีความสามารถในการรองรับสไตล์ทั้งสองนั้นสอดคล้องกับธรรมชาติของ Groovy (OO / FP, สเตติก / ไดนามิก, คลาส / สคริปต์ ฯลฯ )

รับข้อบกพร่องนี้พบได้ที่ IBM:

คำว่าแกงมาจาก Haskell Curry นักคณิตศาสตร์ผู้พัฒนาแนวคิดของฟังก์ชั่นบางส่วน การอ้างถึงหมายถึงการรับอาร์กิวเมนต์หลาย ๆ ตัวลงในฟังก์ชันที่รับอาร์กิวเมนต์จำนวนมากส่งผลให้เกิดฟังก์ชันใหม่ที่ใช้อาร์กิวเมนต์ที่เหลืออยู่และส่งกลับผลลัพธ์

halverเป็นฟังก์ชั่นใหม่ (curried) ของคุณ (หรือปิด) ซึ่งตอนนี้ใช้เพียงพารามิเตอร์เดียว การโทรhalver(10)จะส่งผลให้ 5

ดังนั้นจึงแปลงฟังก์ชันที่มีอาร์กิวเมนต์ n ในฟังก์ชันที่มีอาร์กิวเมนต์ n-1 เช่นเดียวกันได้ถูกกล่าวโดยตัวอย่างของคุณ haskell สิ่งที่แกงทำ