धाराप्रवाह एपीआई में प्राकृतिक भाषा व्याकरण का उपयोग करना

Question

मैं WebSQL / Phonegap डेटाबेस API पर एक क्वेरी एब्स्ट्रैक्शन के साथ छेड़छाड़ कर रहा हूं, और मैं अपने आप को दोनों को आकर्षित करता हूं, और संदेहजनक हूं, एक धाराप्रवाह एपीआई को परिभाषित करता हूं जो प्राकृतिक अंग्रेजी भाषा के व्याकरण के उपयोग की नकल करता है।

उदाहरणों के माध्यम से इसे समझाना सबसे आसान हो सकता है। मेरे व्याकरण में सभी मान्य प्रश्न निम्नलिखित हैं, और टिप्पणियाँ इच्छित शब्दार्थ को स्पष्ट करती हैं:

//find user where name equals "foo" or email starts with "foo@"
find("user").where("name").equals("foo").and("email").startsWith("foo@")

//find user where name equals "foo" or "bar"
find("user").where("name").equals("foo").or("bar");

//find user where name equals "foo" or ends with "bar"
find("user").where("name").equals("foo").or().endsWith("bar");

//find user where name equals or ends with "foo"
find("user").where("name").equals().or().endsWith("foo");

//find user where name equals "foo" and email is not like "%contoso.com"
find("user").where("name").equals("foo").and("email").is().not().like("%contoso.com");

//where name is not null
find("user").where("name").is().not().null();

//find post where author is "foo" and id is in (1,2,3)
find("post").where("author").is("foo").and("id").is().in(1, 2, 3);

//find post where id is between 1 and 100
find("post").where("id").is().between(1).and(100);

---

Quentin Pradet की प्रतिक्रिया के आधार पर संपादित करें : इसके अलावा ऐसा लगता है, API को बहुवचन और एकवचन दोनों रूपों का समर्थन करना होगा, इसलिए:

//a equals b
find("post").where("foo").equals(1);

//a and b (both) equal c
find("post").where("foo").and("bar").equal(2);

प्रश्न के लिए, आइए मान लें कि मैंने यहां सभी संभावित निर्माणों को समाप्त नहीं किया है। चलो यह भी मान लेते हैं कि मैं सबसे सही अंग्रेजी वाक्य कवर कर सकता हूं - आखिरकार, व्याकरण स्वयं SQL के साथ परिभाषित क्रियाओं और संयोजन तक सीमित है।

---

समूहीकरण के बारे में संपादित करें : एक "वाक्य" एक समूह है, और पूर्वता SQL में परिभाषित है: दाएं से बाएं। कई whereबयानों के साथ कई समूह व्यक्त किए जा सकते हैं :

//the conjunctive "and()" between where statements is optional
find("post")
  .where("foo").and("bar").equal(2).and()
  .where("baz").isLessThan(5);

---

जैसा कि आप देख सकते हैं, प्रत्येक विधि की परिभाषा उस व्याकरणिक संदर्भ पर निर्भर है जिसमें वह है। उदाहरण के लिए "संयोजन विधियों" का तर्क or()और and()या तो छोड़ दिया जा सकता है, या फ़ील्ड नाम या अपेक्षित मान का संदर्भ दे सकता है ।

मेरे लिए यह बहुत सहज महसूस करता है, लेकिन मैं चाहूंगा कि आप अपनी प्रतिक्रिया सुनें: क्या यह एक अच्छा, उपयोगी एपीआई है, या क्या मुझे और अधिक स्पष्ट कार्यान्वयन के लिए समर्थन करना चाहिए?

रिकॉर्ड के लिए: यह लाइब्रेरी कॉन्फ़िगरेशन ऑब्जेक्ट्स के आधार पर एक अधिक पारंपरिक, गैर-धाराप्रवाह एपीआई भी प्रदान करेगी।

Comments

चेनिंग भी यही है कि jQuery बहुत प्रसिद्ध है। बहुत सीधा, आगे, अनुक्रमिक और समझने योग्य।

— जोसेफ

यह दिलचस्प है! आपको शायद प्रोग्रामर्स पर यह पूछना चाहिए।

— बेंजामिन Gruenbaum

आप समूहन को कैसे संभालेंगे? के बराबर ... where foo = 1 or (bar = 2 and qux = 3):?

IMO इस तरह के धाराप्रवाह एपीआई भयानक है। उदाहरण के लिए ऑपरेटर पूर्वता की कमी कष्टप्रद है। मैं के where("name").equals("foo").or("bar")रूप में पार्स करेंगे (name=="foo")or bar। तब यह स्पष्ट नहीं होता है जब एक स्ट्रिंग एक शाब्दिक का प्रतिनिधित्व करता है, और जब यह एक स्तंभ नाम प्रस्तुत करता है, ...

— कोडइन्चोसोस

btw। यदि आप किसी डेटाबेस को क्वेरी करने के लिए डीएसएल का उपयोग करना चाहते हैं, तो आप पहले से मौजूद डीएसएल को एसक्यूएल कह सकते हैं।

— कोडइन्चौस

Answer 1

मुझे लगता है कि यह बहुत गलत है। मैं प्राकृतिक भाषा का अध्ययन करता हूं और यह अस्पष्टता से भरा है जिसे केवल संदर्भ और बहुत सारे मानव ज्ञान के साथ हल किया जा सकता है। तथ्य यह है कि प्रोग्रामिंग भाषा अस्पष्ट नहीं हैं एक बहुत अच्छी बात है! मुझे नहीं लगता कि आप संदर्भ के अनुसार बदलने के तरीकों का अर्थ चाहते हैं:

• अस्पष्टता लाने के बाद से यह और अधिक आश्चर्यचकित करता है
• आपके उपयोगकर्ता ऐसे निर्माणों का उपयोग करना चाहेंगे, जिन्हें आपने कवर नहीं किया होगा, जैसे। find("user").where("name").and("email").equals("foo");
• त्रुटियों की रिपोर्ट करना कठिन है: आप क्या कर सकते हैं find("user").where("name").not().is().null();?

---

चलो यह भी मान लेते हैं कि मैं सबसे सही अंग्रेजी वाक्य कवर कर सकता हूं - आखिरकार, व्याकरण स्वयं SQL के साथ परिभाषित क्रियाओं और संयोजन तक सीमित है।

नहीं, आप सबसे सही अंग्रेजी वाक्यों को कवर नहीं कर सकते। दूसरों ने पहले भी कोशिश की है, और यह बहुत जल्दी जटिल हो जाता है। इसे प्राकृतिक भाषा समझ कहा जाता है, लेकिन कोई भी वास्तव में यह कोशिश नहीं करता है: हम पहले छोटी समस्याओं को हल करने की कोशिश कर रहे हैं। अपनी लाइब्रेरी के लिए, आपके पास मूल रूप से दो विकल्प हैं:

• या तो आप खुद को अंग्रेजी के सबसेट तक सीमित कर लें: जो आपको एसक्यूएल देता है,
• या आप "अंग्रेजी" को कवर करने की कोशिश करते हैं और आपको पता चलता है कि भाषा की अस्पष्टता, जटिलता और विविधता के कारण यह संभव नहीं है।

Comments

आपके सहयोग के लिए धन्यवाद। आपके द्वारा सूचीबद्ध पहले मामले को कवर करने के लिए मेरे प्रश्न का संपादन किया और कुछ कैविएट जोड़े। मैं अस्पष्टता पर आपकी स्थिति से सहमत हूँ - यह मेरे प्रश्न का सार है। क्या प्रोग्रामिंग भाषाओं के लिए अच्छी तरह से परिभाषित संदर्भों में महत्वाकांक्षी होना स्वीकार्य है?

— फ़ेंसलिफ़

यदि यह अस्पष्ट है, तो यह अच्छी तरह से परिभाषित नहीं है। यदि यह अस्पष्ट है, तो एक से अधिक संभावित परिणाम हैं, और कुछ को उनमें से एक को चुनना होगा। या तो चुनाव अच्छी तरह से परिभाषित किया जाएगा, या भाषा पार्सर यादृच्छिक पर ले जाएगा। तो, एक प्रोग्रामिंग भाषा में अस्पष्टता ठीक है यदि आप स्टोचस्टिक भाषा चाहते हैं (1 + 1 बराबर 2 हो सकती है, और कभी-कभी 1 या 3 के बराबर हो सकती है) जैसा कि नियतात्मक के विपरीत (1 + 1 हमेशा 2 बराबर होती है)।

— माइकल पॉलुकोनिस

क्या आप उनके प्रस्ताव या अंग्रेजी के बारे में बात कर रहे हैं? ज्यादातर समय, अस्पष्टता को संदर्भ और / या ज्ञान (जो सामान्य ज्ञान का हिस्सा है) का उपयोग करके हल किया जा सकता है, कुछ ऐसा जो कंप्यूटर के लिए उपलब्ध नहीं है।

— क्वेंटिन Pradet

+1 धाराप्रवाह एपीआई के अपने विशेष कार्यान्वयन के संदर्भ संवेदनशीलता पर अच्छी पकड़। मुझे पहली नज़र में उसकी धाराप्रवाह एपीआई का विचार पसंद आया लेकिन इसे देखने के लिए इतनी बारीकी से नहीं देखा। निश्चित रूप से बहुत बड़ी समस्या है।

— जिमी हॉफ

यदि वह व्याकरण को अस्पष्ट और संदर्भ मुक्त बनाता है तो मुद्दा क्या है? सुनिश्चित करें कि वे बहुवचन छंदों को क्रियाओं और इस तरह की चीजों के विलक्षण रूपों से दूर करना चाहते हैं, लेकिन यह उन चीजों के मूल को नहीं बदलता है जो वे करने की कोशिश कर रहे थे। आपके पास is()या equal()केवल नहीं होगा equals()। इसके बाद रिपोर्टिंग समस्याओं के साथ अपना मुद्दा न देखें। null()सिंटेक्स फ़ंक्शन के बजाय, तुलना करने के लिए एक शाब्दिक बन जाएगा। find("user").where("name").is().not().null();बन जाता हैfind("user").where("name").not().equals(null);

— whn

Answer 2

मैं दूसरों के पदों से कुछ हद तक सहमत हूं कि यह एक महान डिजाइन नहीं है। हालांकि, मेरा मानना ​​है कि मेरे पास अलग-अलग कारण हैं।

आप प्रस्तुत कर रहे हैं कि मैं SQL प्रश्नों के लिए एक ठोस वाक्यविन्यास के रूप में क्या देखता हूं। मेरा दृढ़ विश्वास है कि ठोस वाक्यविन्यास कभी भी भाषा की मदद नहीं कर सकता है, केवल अगर यह बुरा है तो चोट लगी है।

हालांकि, अमूर्त वाक्यविन्यास एक अलग कहानी है। एब्सट्रैक्ट सिंटैक्स आपकी भाषा की संरचना को परिभाषित करता है और बड़े वाक्यांशों के निर्माण के लिए वाक्यांशों को कैसे जोड़ा जा सकता है। मुझे लगता है कि किसी भाषा की सफलता उसकी अमूर्त वाक्य रचना की गुणवत्ता पर निर्भर करती है।

धाराप्रवाह एपीआई के साथ मेरी समस्या यह नहीं है कि यह अस्पष्ट है, या अस्पष्ट है, या अभिव्यंजक नहीं है - यह है कि यह वास्तविक भाषा और इसकी संरचना को छुपाता है, और ऐसा करने में, चीजों को बहुत अधिक जटिल बना देता है, जो उन्हें होना चाहिए ( अस्पष्टताओं, गैर-स्पष्ट वाक्यविन्यास त्रुटियों, आदि को शुरू करने से)।

चूंकि आपने उल्लेख किया है कि आप "अधिक पारंपरिक एपीआई" भी प्रदान करेंगे, ऐसा लगता है कि आप पहले से ही यह सब जानते हैं। उस के लिए मैं कहता हूँ "अच्छा है!" लेकिन इसका मतलब यह नहीं है कि आप समानांतर में अपने धाराप्रवाह एपीआई को भी विकसित नहीं कर सकते हैं! एक एकल सार वाक्यविन्यास परिभाषा कई ठोस वाक्यविन्यास का समर्थन कर सकती है। जबकि आपको यह ध्यान रखना चाहिए कि अमूर्त वाक्यविन्यास वास्तविक सौदा है, एक ठोस वाक्यविन्यास भी बहुत सहायक हो सकता है।

Answer 3

क्वेंटिन प्रदीप के बहुत अच्छे बिंदुओं के अलावा, मुझे इस भाषा के कथित लाभों के बारे में संदेह है।

संभवत: प्राकृतिक भाषा के निकट एक व्याकरण की बात इसे सुलभ बनाने के लिए है। लेकिन SQL पहले से ही प्राकृतिक भाषा के काफी करीब है। क्या इनमें से एक वास्तव में अन्य की तुलना में अंग्रेजी के करीब है?

find("user").where("name").equals("foo")

select user from table where name = 'foo'

मैं वास्तव में आपके व्याकरण का लाभ नहीं देखता हूं, जो कि गहनता या पठनीयता के दृष्टिकोण से है। वास्तव में, SQL संस्करण अपने व्हाट्सएप के कारण अधिक पठनीय (और टाइप करने में आसान) लगता है।

Answer 4

की एक संख्या हैं बुरा आदर्श डिजाइन फैसले जिसका इस API पर विचार करने में किया गया है करने के लिए प्रकट की तुलना में कम।

पहली उपयोगिता का प्रश्न है - यह किस उद्देश्य से कार्य करता है? यह एक डेटा संरचना का निर्माण करता प्रतीत होता है जो SQL की बोली में संकलित होगा। संयोग से, व्याकरण SQL का एक सीमित सेट प्रतीत होता है। "एसक्यूएल का उपयोग करने से क्या फायदा होता है?" कुंजी बन जाता है। यदि यह धाराप्रवाह इंटरफ़ेस का उपयोग करके लिखने के लिए अधिक बोझिल है, तो इसमें उचित प्रक्षेप के साथ एक स्ट्रिंग लिखने से तो कोई इस एपीआई का उपयोग करके नहीं लिखेगा।

अंग्रेजी अस्पष्ट है। अंग्रेजी पर एक धाराप्रवाह मॉडल का प्रयास करना एक खराब विकल्प है (आप लैटिन का उपयोग करके बेहतर हैं )। जब कॉल की श्रृंखला के समान सेट के कई संभावित मान्य पार्सिंग होते हैं, तो इससे भ्रम और आश्चर्य होता है । इनमें से किसी भी एक एपीआई में होने के लिए अच्छी चीजें नहीं हैं।

इस API को उजागर करने की तुलना में SQL में और भी हिस्से हैं। सम्मिलित (उनके किसी भी असंख्य रूप में) विशेष रूप से अनुपस्थित हैं उदाहरण सेट। उपश्रेणियों ( foo in (select id from bar)), यूनियनों और समूह द्वारा कुछ चीजें हैं जो अक्सर उपयोग की जाती हैं। तर्क के जटिल समूह किसी भी सहज तरीके से उपस्थित नहीं होते हैं।

यदि कोई इस एपीआई का उपयोग कर लिख रहा था और तब पाया गया कि एपीआई वांछित क्वेरी को व्यक्त करने में सक्षम नहीं है, तो महत्वपूर्ण समय खो जाएगा। यह एक आवेदन में एक प्रश्न करने के लिए मिश्रित शैलियों का उपयोग करने के लिए एक खराब विकल्प है (इस एपीआई में सरल प्रश्न, कच्चे वर्ग में जटिल) - और अंततः जो अधिक अभिव्यंजक है उसका उपयोग किया जाएगा।

जबकि प्रोग्रामिंग व्यापक है, अंग्रेजी प्रवाह नहीं है। यहां तक ​​कि भाषा की एक सीमा के साथ "एसक्यूएल की तरह" इस बात की बारीकियां हैं कि कैसे एक देशी वक्ता कुछ पढ़ेगा और कोई है जो अंग्रेजी को दूसरी या तीसरी भाषा के रूप में पढ़ता है।

अंग्रेजी के लिए एपीआई में अनावश्यक अतिरेक है। विशेष रूप से equal()बनाम equals()एक ही काम कर रहा है। हालांकि मैं इसके बारे में निश्चित नहीं हूं, लेकिन मेरा मानना ​​है कि is()यह एक मैचिंग इंग्लिश के करीब के लिए एक नो-ऑप है। मैं चैट में रूबी में तरीकों के अतिरेक के बारे में मेरी शेख़ी सुनने के लिए किसी का भी स्वागत करता हूं - वही गलती मत करो।

बैठ जाओ और प्रश्नों का एक व्यापक उदाहरण सेट लिखो जिसका आप उपयोग करने में सक्षम होना चाहते हैं। निर्धारित करें कि आप उन सभी उदाहरणों को गैर-अस्पष्ट तरीके से कैसे संभालेंगे जो कि प्रश्नों से कम बोझिल हैं। यदि आप नहीं कर सकते, तो विचार करें कि क्या एपीआई लिखने के रास्ते पर चलना सार्थक है। एसक्यूएल वह जगह है जो आज है (यह बिल्कुल सही नहीं है, लेकिन मुझे शोधन के दशकों में कुछ भी बेहतर नहीं मिला है)।

RFC 1925 - बारह नेटवर्किंग सत्य

(१२) प्रोटोकॉल डिजाइन में, पूर्णता तब तक पहुंच गई है जब जोड़ने के लिए कुछ भी नहीं बचा है, लेकिन जब दूर ले जाने के लिए कुछ भी नहीं बचा है।