ดูเหมือนว่าในภาษาสงครามศักดิ์สิทธิ์ผู้คนมักจะลบล้างคุณลักษณะใด ๆ ที่พวกเขาไม่พบว่ามีประโยชน์โดยเฉพาะอย่างยิ่งในฐานะที่เป็น "แค่น้ำตาลประโยค" เส้นแบ่งระหว่าง "คุณสมบัติจริง" และ "น้ำตาลเชิงเส้น" มีแนวโน้มที่จะไม่ชัดเจนในการโต้วาทีเหล่านี้ สิ่งใดที่คุณเชื่อว่าเป็นคำจำกัดความที่สมเหตุสมผลและไม่น่าสงสัยของน้ำตาลซินแทคติคที่หลีกเลี่ยงการถูกนิยามว่าเป็นคุณสมบัติใด ๆ ที่ผู้พูด / ผู้เขียนไม่พบว่ามีประโยชน์?
คำตอบ:
เกี่ยวกับสิ่งนี้: "น้ำตาล syntactic เป็นชวเลขที่สะดวกสบายสำหรับฟังก์ชั่นบางอย่างที่ไม่แนะนำเลเยอร์ที่มีความหมายของนามธรรม"
ใช้ซึ่งในขณะที่คุณชี้เทียบเท่ากับa->b (*a).bสัญกรณ์นี้อนุญาตให้คุณพิจารณาโค้ดที่เป็นประโยชน์หรือซ่อนอยู่ในลักษณะอื่นได้หรือไม่? ไม่เลยมันเป็นน้ำตาลทราย
a[i] == *(a + i)ตอนนี้พิจารณา คิดเกี่ยวกับโปรแกรม C ใด ๆ ที่ใช้อาร์เรย์ด้วยวิธีการที่สำคัญ คุณลองจินตนาการถึงความพยายามที่จะเข้าใจโดยไม่ต้องใช้[]สัญลักษณ์หรือไม่ ด้วยอาร์เรย์หลายมิติ? มันมีความหมายที่จะต้องพิจารณาอาร์เรย์เป็นหน่วยทั้งหมดไม่ใช่เป็นการอ้างอิงถึงจุดเริ่มต้นของบล็อกหน่วยความจำที่ต่อเนื่องกัน ในขณะที่มันจะช่วยให้ทราบว่าอาร์เรย์ทำงานอย่างไรใน C หากคุณวางแผนที่จะทำสิ่งที่ซับซ้อนกับพวกมันมันไม่เกิดผลเลยที่จะต้องคิดเสมอว่า "ฉันต้องเก็บหน่วยความจำสองบิต 2 * i ไบต์ไปทางขวาของ ตำแหน่งหน่วยความจำที่อ้างอิงโดยa". จุดรวมของอาเรย์คือความสามารถในการแยกกระบวนการจัดลำดับออกเป็นหน่วยที่เชื่อมโยงกัน []สัญกรณ์อำนวยความสะดวกในสิ่งที่เป็นนามธรรมนี้ มันไม่ใช่น้ำตาลทราย
นี่ไม่ใช่การบอกเป็นนัยว่าน้ำตาลซินแทคติคเป็นสิ่งที่ไม่ดีอยู่เสมอ เช่นเดียวกับการเขียนเรียงความจำนวนมากมันได้กลายเป็นฉายาและฉายาต่อต้าน "คุณสมบัติที่แท้จริง" ตัวอย่างเช่น LISP และ Scheme จะไม่สามารถอ่านได้ถ้าไม่ใช่สำหรับการletจดชวเลข (และอื่น ๆ )
ผู้ประกอบการที่ประกอบไปด้วย<pred> ? <cnsq> : <alt>, เป็นอีกตัวอย่างหนึ่ง น้ำตาลซินแทคติคสามารถช่วยจัดระเบียบโปรแกรมและลบรหัสซ้ำซ้อนซึ่งอาจช่วยในการบำรุงรักษา บางครั้งน้ำตาลซินแทคติคน่าจะดีกว่าที่จะซ้อนกับ "คุณสมบัติจริง" หากช่วยขจัดอุปสรรคในการเขียนโปรแกรม
ในการอ้างอิงR ^ 5RS "ภาษาการเขียนโปรแกรมควรได้รับการออกแบบไม่ใช่โดยการซ้อนคุณลักษณะด้านบนของคุณสมบัติ แต่โดยการลบจุดอ่อนและข้อ จำกัด ที่ทำให้คุณสมบัติเพิ่มเติมปรากฏขึ้นจำเป็น" IMHO ไวยากรณ์สามารถมีคุณสมบัติเป็นจุดอ่อนและข้อ จำกัด และเพื่อให้โปรแกรมเมอร์ได้รับจากไวยากรณ์สามารถเพิ่มการแสดงออกของภาษา
IMHO ฉันไม่คิดว่าคุณจะมีคำจำกัดความเกี่ยวกับ syntactic sugar เนื่องจากวลีนี้เป็น BS และน่าจะถูกใช้โดยผู้ที่พูดถึง "โปรแกรมเมอร์จริง" โดยใช้ "เครื่องมือจริง" ใน "ระบบปฏิบัติการจริง"
BS เพราะความคิดของ "คุณลักษณะของจริง" หรือ "น้ำตาลประโยค" เป็นเช่นไม่มีการเข้าใจผิดสกอตที่แท้จริง ในวลีที่ว่า "เฉพาะกิจพยายามที่จะรักษาคำยืนยันที่ไม่มีเหตุผล" การยืนยันที่นี่คือคุณลักษณะที่นี่เล็กน้อยเพราะคุณสามารถใช้ "คุณสมบัติจริง" แทน
มันเป็นเพราะบางคนโต้แย้งการใช้น้ำตาลควรหลีกเลี่ยงเพราะคุณสามารถเขียนข้อผิดพลาด แต่คุณควรติดมันเพราะมันยากที่จะเขียนข้อบกพร่อง ไม่น่ากลัวขนาดนั้น วลีเดียวกันนำไปสู่ข้อสรุปที่ตรงกันข้ามโดยใช้ตรรกะเดียวกัน
BS ของมันเพราะไม่มีใครอ้างถึงการศึกษาการใช้งานหรือการศึกษาการนับจำนวนข้อบกพร่องเพื่อสำรองความสามารถในการอ่านหรือการบำรุงรักษาหรือข้อโต้แย้งที่อาจเกิดข้อบกพร่อง
มันเป็นเพราะคนมักจะผิดหรือกลายเป็นผิดเกี่ยวกับความเท่าเทียม ตัวอย่างเช่นคำถามนี้ยืนยันว่าสตริง C # เป็นน้ำตาลสำหรับอาร์เรย์ถ่าน พวกเขาจะไม่
อย่างไรก็ตามถ้าคุณต้องการบอกว่ามีสองสิ่งที่เป็นน้ำตาลถ้าพวกมันมีความหมายเทียบเท่ากันและนั่นช่วยให้คุณสามารถกำหนดมันต่อไปได้
หากคุณต้องการที่จะยกฟ้องใครบางคนคุณสามารถใช้วลี
นี่คือคำจำกัดความที่เข้มงวดมากสำหรับแนวคิดที่เกี่ยวข้อง: การแสดงออกโดย
Matthias Felleisen:
ในพลังการแสดงออกของภาษาโปรแกรม [Postscript เป็นรูปแบบอิสระเดียวที่ฉันหาได้]
ยังเห็นรายการนี้ในภาษา Java และฝาปิด
อย่างมีประสิทธิภาพบางสิ่งบางอย่างคือน้ำตาล syntactic ถ้ามันสามารถเปลี่ยนเป็นแบบฟอร์มโดยไม่มีไวยากรณ์โดยทำการเปลี่ยนแปลงเฉพาะ ตัวอย่างเช่นหากไม่มีรูปแบบประโยคคุณจะต้องเปลี่ยนตำแหน่งรหัสที่แตกต่างกันหลายแห่งหรือย้ายชิ้นส่วนไปยังตำแหน่งอื่นนั่นไม่ใช่น้ำตาล
ที่กล่าวว่าน้ำตาล syntactic นั้นดีเมื่อใช้อย่างเหมาะสม ฉันคิดว่าโปรแกรมเมอร์ Scheme คนใดอยากจะมีletรูปแบบพิเศษมากกว่าที่จะต้องสร้างฟังก์ชั่นนิรนามใหม่แล้วใช้มันซึ่งจะทำสิ่งเดียวกัน จุดประสงค์คือการทำให้รหัสชัดเจนยิ่งขึ้น
ฉันคิดว่าคำวากยสัมพันธ์น้ำตาลบ่งบอกถึงไวยากรณ์ทางเลือกเพื่อแสดงความหมายพื้นฐานเดียวกัน
ยกตัวอย่างภาษาการเขียนโปรแกรม A ที่มีการดำเนินการsumที่สามารถเพิ่มรายการจำนวนเต็มของความยาวโดยพลการ ในภาษานี้เราสามารถเขียนสำนวน
sum []
sum [3, 4, 5, 1]
sum [2, 7]
ผลลัพธ์ของมันคือ 0, 13, และ 9 ตามลำดับ
ทีนี้สมมติว่าเราตระหนักว่า 90% ของเวลาที่เราใช้sumกับสองข้อโต้แย้งและดังนั้นเราจึงแนะนำเพื่อความสะดวกและสัญกรณ์ใหม่
2 + 7
ซึ่งเป็นเพียงน้ำตาลประโยคsum [2, 7]สำหรับ
ตอนนี้ใช้ภาษา B ที่สองที่ไม่มีการดำเนินการเพิ่มเติมใด ๆ เราอาจจะมีผู้ประกอบการที่ต้องการ<, =ช่วยให้เราเพื่อเปรียบเทียบตัวเลข แต่ไม่มีทางที่จะเพิ่มตัวเลข ในรีลีส 2 ของภาษา B เราแนะนำการเพิ่มใหม่ด้วยไวยากรณ์
2 + 7
ซึ่งจะเพิ่มตัวเลขตามปกติ
ในบริบทของภาษา A, +สัญกรณ์คือน้ำตาลซินแทคติค (เป็นสัญกรณ์ที่สลับกันง่าย ๆ และมีความสามารถที่สามารถนำมาใช้แทนsum [...]สัญกรณ์ได้) ในทำนองเดียวกันตามที่ได้รับการชี้ให้เห็นในคำตอบ Hoa ยาวต๋ำใน C สัญกรณ์เป็นน้ำตาลประโยคสำหรับp->field(*p).field
ในบริบทของภาษา B +สัญกรณ์ไม่ใช่วากยสัมพันธ์น้ำตาล (เป็นไวยากรณ์ที่ถูกต้องเท่านั้นที่ใช้สำหรับการดำเนินการรวม) ในทำนองเดียวกันถ้า C สามารถเข้าถึงสมาชิกโครงสร้างผ่านพอยน์เตอร์และหากไม่มีสัญกรณ์(*p).fieldแล้วสัญกรณ์p->fieldก็จะไม่เป็นน้ำตาลซินแทคติค
ในความคิดของฉันมีบางความเข้าใจผิดเกี่ยวกับวากยสัมพันธ์น้ำตาลที่สามารถย้อนกลับไปเป็นความสับสนเกี่ยวกับความหมายภาษาการเขียนโปรแกรม การให้เหตุผลเป็นไปดังนี้:
บรรทัดด้านบนของการให้เหตุผลที่นำไปสู่การยืนยันทั่วไปเช่น "น้ำตาล syntactic ไม่สามารถกำหนดได้อย่างถูกต้อง" มันเป็น "เรื่องของรสนิยม" หรือ "ทุกคุณสมบัติการเขียนโปรแกรมภาษาคือหลังจากทั้งหมดเพียงน้ำตาลประโยค"
ฉันคิดว่าปัญหาหลักในอาร์กิวเมนต์ข้างต้นคือซีแมนทิกส์ไม่เพียงเกี่ยวกับสิ่งที่โปรแกรมสามารถคำนวณได้แต่ยังเกี่ยวกับวิธีการคำนวณเช่นการใช้โครงสร้างแบบดั้งเดิมและวิธีการรวมกัน
ตัวอย่างเช่นวัตถุไม่ได้เป็นน้ำตาล syntactic สำหรับการกำหนดค่าบิตพื้นฐานและการแปลงบิตพวกเขาเป็นโครงสร้างที่ช่วยให้รูปแบบข้อมูลและการดำเนินงานและเพื่ออธิบายการคำนวณ การคำนวณด้วยวัตถุวิธีการการเรียกใช้เมธอดนั้นไม่เหมือนกับการคำนวณด้วยไบต์การลงทะเบียนตัวประมวลผลที่อยู่หน่วยความจำ (แม้ว่าการคำนวณทั้งสองจะมีผลลัพธ์เหมือนกันและแม้ว่าจะใช้การคำนวณครั้งที่สองในการดำเนินการครั้งแรก)
ฉันทำให้คำอธิบายนี้ยาวไปหน่อย แต่ฉันคิดว่ามันเป็นสิ่งสำคัญที่ฉันไม่ได้เห็นในคำตอบอื่น ๆ
Bottom line: น้ำตาล syntactic เป็นไวยากรณ์ทางเลือก (อาจจะสะดวกกว่า) สำหรับการสร้างที่มีอยู่แล้วในภาษาและมีไวยากรณ์ที่กำหนดไว้อย่างดีและความหมาย ไวยากรณ์ใหม่ (น้ำตาลประโยค) แตกต่างจากที่มีอยู่หนึ่ง แต่มีความหมายเดียวกัน หากคุณแนะนำการสร้างใหม่ในภาษาและไวยากรณ์ใหม่สำหรับมันคุณจะไม่มีน้ำตาลในประโยค
น้ำตาล syntactic เป็นคุณสมบัติที่ไม่ขยายการแสดงออกทางภาษาของตัวเองดังนั้นจึงซ้ำซ้อนและบางครั้งการละเมิดของสัญกรณ์ แต่ทั้งสองช่วยลดความซับซ้อนของชีวิตของนักเขียนและให้ผู้อ่านเข้าใจ
เพื่อตอบคำถามของตัวเองฟีเจอร์นี้คือน้ำตาลซินแทคติคถ้าหากมันถูกรวมไว้เพื่อเพิ่มความสวยงามและความสามารถในการอ่านและสามารถแปลได้เล็กน้อยในรูปแบบหนึ่งต่อหนึ่งในเวอร์ชั่นที่ไม่เหมาะสม (โดยประมาณแบบหนึ่งต่อหนึ่งฉันหมายถึงสิ่งเล็กน้อยโมดูโลเช่นคำสั่งของการปฏิบัติการสับเปลี่ยนชื่อตัวแปรและช่องว่าง)
คุณลักษณะใด ๆ ที่สามารถลดระดับน้ำตาลลงได้ด้วยการกำหนดจำนวนโปรแกรมเมอร์อย่างมากไม่ใช่น้ำตาลซินแทคติค ในฐานะส่วนหนึ่งของคุณลักษณะนี้ที่เพิ่มความปลอดภัยให้กับประเภทนั้นไม่ใช่น้ำตาล syntactic เนื่องจากการบังคับใช้ความปลอดภัยของประเภทด้วยตนเองผ่านระเบียบวินัยของโปรแกรมเมอร์นั้นไม่ใช่เรื่องเล็กน้อย ตัวอย่างเช่นระบบวัตถุของ C ++ นั้นเป็นมากกว่าน้ำตาลซินแทคติคที่อยู่ด้านบนของ C พอยน์คาสต์โพลีมอร์ฟิซึม
คุณลักษณะใด ๆ ที่จะต้องใช้รหัสซ้ำอย่างมีนัยสำคัญหรือการออกแบบที่สำคัญหากลบออกไม่ได้เป็นน้ำตาล syntactic เพราะทั้งสองสิ่งเหล่านี้เป็นงานเล็กน้อย ตัวอย่างเช่นเทมเพลตไม่ได้เป็นเพียงแค่วากยสัมพันธ์น้ำตาลเพราะได้รับฟังก์ชั่นเทียบเท่าโดยไม่ต้องพวกเขาจะต้องตันโคลนและแก้ไข
ตัวอย่างของสิ่งต่าง ๆ ที่เป็นน้ำตาล syntactic:
a[i] แทน *(a + i)
a -> b แทน (*a).b
foreach ไวยากรณ์แทนการพิมพ์ไวยากรณ์ตัววนซ้ำด้วยตนเอง
การบรรทุกเกินพิกัดทั้งหมดนั้นเป็นน้ำตาลทรายบริสุทธิ์
เสียงนี้เป็นคำนิยามที่ยุติธรรมและไร้เหตุผลหรือไม่?
"น้ำตาลซินแทคติค" ไม่ใช่คำที่กำหนดอย่างเข้มงวด คุณอาจได้คำจำกัดความต่อไปนี้ขึ้นอยู่กับว่าคุณถามใคร
ฉันไม่แน่ใจเกี่ยวกับในสาขาวิทยาศาสตร์คอมพิวเตอร์ แต่ด้วยตรรกะมีแนวคิดของการอนุรักษ์และกำจัดได้ของคำจำกัดความ [ 1 ] ดูเหมือนจะอยู่ในหลอดเลือดดำเดียวกัน
การประยุกต์ใช้การติดต่อกับ Curry-Howard หนึ่งอาจจะเกิดขึ้นกับแนวคิดแบบขนานเกี่ยวกับ "น้ำตาลน้ำตาล"