📩 💐 🖖🏾 स्क्रैच से एक पार्सर लिखना: क्या शैतान इतना भयानक है? 👨🏻‍🔬 😃 👨🏽‍✈️

आखिरी विषय में, मैंने इस बारे में बात की कि कैसे मेरे दोस्त और मैंने मनोरंजन के लिए .NET प्लेटफॉर्म के लिए अपनी खुद की एम्बेडेड प्रोग्रामिंग भाषा लिखने का फैसला किया। पहले संस्करण में एक गंभीर खामी थी - तीसरे पक्ष के पुस्तकालय का उपयोग करके एफ # पर पार्सर लागू किया गया था। इस वजह से, बहुत अधिक निर्भरता की आवश्यकता थी, पार्सर ने धीरे-धीरे काम किया, और इसका समर्थन एक अत्यंत नीरस व्यवसाय था।

जाहिर है, Parser को C # में फिर से लिखने की आवश्यकता थी, लेकिन जब आपने Parser को खरोंच से लिखने के बारे में सोचा, तो एक दर्जन अन्य जरूरी चीजें थीं। इस प्रकार, कार्य को लगभग छह महीने के लिए फेंक दिया गया और स्थगित कर दिया गया और भारी लग रहा था, लेकिन अंत में यह 4 दिनों में किया गया था। कटौती के तहत, मैं तीसरे पक्ष के पुस्तकालयों का उपयोग किए बिना एक जटिल जटिल व्याकरण के पार्सर को लागू करने के लिए एक सुविधाजनक तरीके के बारे में बात करूंगा और इसे मन से नहीं छुआ जा सकता है, साथ ही साथ इसने LENS भाषा को कैसे बेहतर बनाया।

लेकिन सबसे पहली बात।

पहला पैनकेक

जैसा कि ऊपर उल्लेख किया गया है, हमने पार्सर कोर के रूप में FParsec लाइब्रेरी का उपयोग किया। इस विकल्प के कारण उद्देश्य से अधिक ऐतिहासिक हैं: मुझे हल्के वाक्यविन्यास पसंद थे, मैं एफ # का उपयोग करके अभ्यास करना चाहता था, और लाइब्रेरी के लेखक ने बहुत तेज़ी से ईमेल के माध्यम से कई सवालों के जवाब दिए।

हमारी परियोजना के लिए इस पुस्तकालय का मुख्य दोष बाहरी निर्भरताएं थीं:

लगभग दस मेगाबाइट एफ # रनटाइम
FParsec का 450 kb बनाता है

इसके अलावा, कंपाइलर 3 असेंबलियों में टूट गया: एक पार्सर, एक सिंटैक्स ट्री और एक प्रवेश बिंदु। पार्सर असेंबली ने प्रभावशाली 130 kb लिया। एक एम्बेडेड भाषा के लिए, यह बिल्कुल अशोभनीय है।

एक अन्य समस्या त्रुटियों को प्रदर्शित कर रही थी। स्थानीय DSL पर एक गलत तरीके से दर्ज कार्यक्रम के साथ संक्षिप्त व्याकरण रिकॉर्ड एक अपेक्षित त्रुटि उत्पन्न करता है जो अपेक्षित टोकन सूचीबद्ध करता है:

> let x = > :           'new'  ...

यद्यपि कस्टम त्रुटि हैंडलिंग संभव है, लेकिन DSL स्पष्ट रूप से इसके लिए अभिप्रेत नहीं है। एक व्याकरण विवरण बदसूरत हो जाता है और पूरी तरह से असमर्थित हो जाता है।

एक और अप्रिय क्षण काम की गति थी। किसी भी "यहां तक कि सबसे सरल लिपि" के "कोल्ड स्टार्ट" संकलन के साथ, मेरी मशीन पर लगभग 350-380 मिलीसेकंड लिया गया। इस तथ्य को देखते हुए कि एक ही स्क्रिप्ट को फिर से शुरू करने में केवल 5-10 मिली सेकेंड लगते हैं, देरी जेआईटी संकलन के कारण हुई थी।

मैं एकदम से आरक्षण कर दूंगा - अधिकांश वास्तविक कार्यों के लिए, विकास का समय अतिरिक्त पुस्तकालयों या कुछ मिलीसेकंड के एक जोड़े की तुलना में अधिक महत्वपूर्ण है जो पार्सिंग पर खर्च किए जाते हैं। इस दृष्टिकोण से, एक हाथ से लिखने वाले पार्सर लिखना एक शैक्षिक या गूढ़ व्यायाम है।

सिद्धांत की बिट

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

पेड़ की संरचना विशेष रूप से अच्छी है कि यह कई आधुनिक आभासी मशीनों (उदाहरण के लिए, JVM / .NET) में उपयोग किए गए स्टैक संगठन के साथ गहराई में जाती है। इस लेख में कोड पीढ़ी पर विचार नहीं किया जाएगा, हालांकि, वाक्यविन्यास पेड़ के तत्व, पार्सर के परिणामस्वरूप, समय-समय पर उल्लेख किया जाएगा।

तो, इनपुट पर हमारे पास एक पंक्ति है। चरित्र सेट। सीधे इस रूप में इसके साथ काम करना बहुत सुविधाजनक नहीं है - आपको रिक्त स्थान, लाइन ब्रेक और टिप्पणियों पर विचार करना होगा। अपने जीवन को सरल बनाने के लिए, पार्सर डेवलपर्स आमतौर पर विश्लेषण को कई पासों में विभाजित करते हैं, जिनमें से प्रत्येक एक सरल कार्य करता है और इसके काम का परिणाम निम्न करता है:

लेक्सिकल विश्लेषक: string -> IEnumerable<Lexem>
पार्सर: IEnumerable<Lexem> -> IEnumerable<Node>
शब्दार्थ विश्लेषक: IEnumerable<Node> -> ?

चूंकि सिमेंटिक एनालाइजर विशुद्ध रूप से व्यक्तिगत चीज है, इसलिए इसका विवरण इस लेख में शामिल नहीं है। फिर भी, मैं पहले दो विश्लेषणकर्ताओं के लिए कुछ उपयोगी तरकीबें साझा करूँगा।

लेक्सिकल विश्लेषक

आवश्यकताएँ:

काम की गति
विस्तार में आसानी
कार्यान्वयन में आसानी
स्रोत ट्रैकिंग

लेक्सर एल्गोरिथ्म सरल है: यह लाइन को बाएं से दाएं स्कैन करता है, जो प्रत्येक ज्ञात टोकन के साथ लाइन में वर्तमान स्थिति से मेल खाने की कोशिश करता है। यदि मैच सफल होता है, तो लेक्सर लाइन में ठीक उसी तरह से चलता है जैसे कि पिछले टोकन में कई अक्षर होते हैं, और लाइन के अंत में एक नए के लिए खोज जारी रखते हैं। अधिकांश व्याकरणों के लिए रिक्तियाँ, टैब और लाइन ब्रेक को केवल अनदेखा किया जा सकता है।

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

स्टैटिक टोकन, बदले में, ऑपरेटरों और कीवर्ड में विभाजित करने का एक कारण है। खोजशब्दों का मिलान तभी किया जाता है जब उनका अनुसरण करने वाला वर्ण पहचानकर्ता (या आगे - पंक्ति के अंत) के लिए मान्य नहीं होता है। अन्यथा, पहचानकर्ताओं के साथ समस्याएं होंगी जिनकी शुरुआत कीवर्ड से मेल खाती है: उदाहरण के लिए, "information" -> keyword(in), keyword(for), identifier(mation) ।

कार्यान्वयन का उदाहरण

 enum LexemKind { Var, Print, Plus, Minus, Multiply, Divide, Assign, Semicolon, Identifier, Number } class LocationEntity { public int Offset; public int Length; } class Lexem : LocationEntity { public LexemKind Kind; public string Value; } class LexemDefinition<T> { public LexemKind Kind { get; protected set; } public T Representation { get; protected set; } } class StaticLexemDefinition : LexemDefinition<string> { public bool IsKeyword; public StaticLexemDefinition(string rep, LexemKind kind, bool isKeyword = false) { Representation = rep; Kind = kind; IsKeyword = isKeyword; } } class DynamicLexemDefinition : LexemDefinition<Regex> { public DynamicLexemDefinition(string rep, LexemKind kind) { Representation = new Regex(@"\G" + rep, RegexOptions.Compiled); Kind = kind; } } static class LexemDefinitions { public static StaticLexemDefinition[] Statics = new [] { new StaticLexemDefinition("var", LexemKind.Var, true), new StaticLexemDefinition("print", LexemKind.Print, true), new StaticLexemDefinition("=", LexemKind.Assign), new StaticLexemDefinition("+", LexemKind.Plus), new StaticLexemDefinition("-", LexemKind.Minus), new StaticLexemDefinition("*", LexemKind.Multiply), new StaticLexemDefinition("/", LexemKind.Divide), new StaticLexemDefinition(";", LexemKind.Semicolon), }; public static DynamicLexemDefinition[] Dynamics = new [] { new DynamicLexemDefinition("[a-zA-Z_][a-zA-Z0-9_]*", LexemKind.Identifier), new DynamicLexemDefinition("(0|[1-9][0-9]*)", LexemKind.Number), }; } class Lexer { private char[] SpaceChars = new [] { ' ', '\n', '\r', '\t' }; private string Source; private int Offset; public IEnumerable<Lexem> Lexems { get; private set; } public Lexer(string src) { Source = src; Parse(); } private void Parse() { var lexems = new List<Lexem>(); while(InBounds()) { SkipSpaces(); if(!InBounds()) break; var lex = ProcessStatic() ?? ProcessDynamic(); if(lex == null) throw new Exception(string.Format("Unknown lexem at {0}", Offset)); lexems.Add(lex); } Lexems = lexems; } private void SkipSpaces() { while(InBounds() && Source[Offset].IsAnyOf(SpaceChars)) Offset++; } private Lexem ProcessStatic() { foreach(var def in LexemDefinitions.Statics) { var rep = def.Representation; var len = rep.Length; if(Offset + len > Source.Length || Source.Substring(Offset, len) != rep) continue; if(Offset + len < Source.Length && def.IsKeyword) { var nextChar = Source[Offset + len]; if(nextChar == '_' || char.IsLetterOrDigit(nextChar)) continue; } Offset += len; return new Lexem { Kind = def.Kind, Offset = Offset, Length = len }; } return null; } private Lexem ProcessDynamic() { foreach(var def in LexemDefinitions.Dynamics) { var match = def.Representation.Match(Source, Offset); if(!match.Success) continue; Offset += match.Length; return new Lexem { Kind = def.Kind, Offset = Offset, Length = match.Length, Value = match.Value }; } return null; } private bool InBounds() { return Offset < Source.Length; } }

फायदे:

तेजी से काम करता है
एक प्राथमिक उपकरण, आप आधे घंटे में लिख सकते हैं
नए टोकन बहुत सरलता से जोड़े जाते हैं
विधि कई व्याकरणों के लिए उपयुक्त है

नुकसान:

महत्वपूर्ण रिक्त स्थान के साथ जीभ को पार्स करते समय एक नखरे के साथ नृत्य
टोकन घोषित करने का क्रम महत्वपूर्ण है: लंबाई के अनुसार क्रमबद्ध करना वांछनीय है

पार्सर

आवश्यकताएँ:

व्याकरण बदलते समय आसान विस्तार
विस्तृत त्रुटि संदेशों का वर्णन करने की क्षमता
असीमित संख्या में पदों पर आगे देखने की क्षमता
स्रोत कोड में स्थिति का स्वचालित ट्रैकिंग
अनुरूपता, मूल व्याकरण से निकटता

पार्सर लिखते समय अपने जीवन को सरल बनाने के लिए, आपको विशेष रूप से व्याकरण की व्यवस्था करनी चाहिए। कोई जटिल डिजाइन! सभी नियमों को 3 प्रकारों में विभाजित किया जा सकता है:

विवरण - एक विशिष्ट नोड:
(var_expr = "var" identifier "=" expr)
पुनरावृत्ति - एक विशेष नोड को कई बार दोहराया जाता है, संभवतः एक विभाजक के साथ:
main = { stmt ";" }
वैकल्पिक - कई नोड चयन
(stmt = var_expr | print_expr | assign_expr | other)

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

एक गणना नियम एक लूप है। मूल्यों के अनुक्रम को वापस करने के लिए, C # में yield return का उपयोग करके जनरेटर बनाने के लिए बहुत सुविधाजनक कार्यक्षमता है।

बदले में एक वैकल्पिक नियम एक विशेष आवरण का उपयोग करके भिन्न नियमों को लागू करता है जो आपको इसकी मूल स्थिति में वापस लाने की अनुमति देता है। नियमों को केवल तब तक कहा जाता है जब तक कि उनमें से कम से कम एक मेल नहीं खाता हो, कोलेसस ( ?? ) ऑपरेटर से जुड़ा हुआ हो।

फिर एक जिज्ञासु पाठक पूछेगा:
- यह कैसा है, वे सिर्फ क्रम में बुलाए जाते हैं? लेकिन प्रमुख जाँच के बारे में क्या? उदाहरण के लिए, इस तरह:

 if(CurrentLexem.Type == LexemType.Var) return parseVar(); if(CurrentLexem.Type == LexemType.For) return parseFor(); ...

मैं मानता हूं, मैंने अपना पहला गंभीर पार्सर उस तरह से लिखा। हालाँकि, यह एक बुरा विचार है!

सबसे पहले, आप केवल निश्चित संख्या में वर्ण देख सकते हैं। किसी भी या var , ज़ाहिर है, उपयुक्त है। लेकिन मान लें कि व्याकरण में हमारे पास ये नियम हैं:

 assign = id_assign | member_assign | index_assign id_assign = identifier "=" expr member_assign = lvalue "." identifier "=" expr index_assign = lvalue "[" expr "]" "=" expr

यदि id_assign साथ सब कुछ स्पष्ट है, तो दोनों अन्य नियम id_assign शुरू होते हैं, जिसके तहत किलोमीटर की अभिव्यक्ति छिपाई जा सकती है। जाहिर है, आप यहां किसी भी अग्रणी जांच में नहीं आएंगे।

एक और समस्या जिम्मेदारी के क्षेत्रों का भ्रम है। व्याकरण के एक्स्टेंसिबल होने के लिए, नियमों को यथासंभव एक दूसरे से स्वतंत्र होना चाहिए। इस दृष्टिकोण को बाहरी नियम की आंतरिक लोगों की संरचना के बारे में पता होना चाहिए, जिससे कनेक्टिविटी बढ़ती है और व्याकरण परिवर्तनों के लिए समर्थन को जटिल करता है।

तो हमें उन्नत जांच की भी आवश्यकता क्यों है? प्रत्येक नियम को स्वयं के लिए बताएं कि यह सुनिश्चित करने के लिए कि यह सबसे उपयुक्त है, आगे देखना कितना आवश्यक है।

ऊपर के उदाहरण पर विचार करें। मान लीजिए हमारे पास पाठ है: a.1 = 2 :

id_assign विकल्प को id_assign कहा जाता है।
a मैच को सफलतापूर्वक पहचानता a ।
अगली अवधि है, लेकिन बराबरी के संकेत की उम्मीद है। हालांकि, अन्य नियम पहचानकर्ता के साथ शुरू हो सकते हैं, इसलिए त्रुटि नहीं डाली गई है।
असाइन किया गया नियम राज्य को वापस रोल करता है और आगे की कोशिश करता है।
member_assign विकल्प member_assign ।
पहचानकर्ता और अवधि सफलतापूर्वक मेल खाते हैं। व्याकरण में कोई अन्य नियम नहीं हैं जो एक पहचानकर्ता और एक डॉट के साथ शुरू होते हैं, इसलिए यह राज्य को वापस रोल करके आगे की त्रुटियों को संभालने की कोशिश करने का कोई मतलब नहीं है।
नंबर 1 एक पहचानकर्ता नहीं है, इसलिए एक त्रुटि डाली गई है।

सबसे पहले, हम कुछ उपयोगी तरीके लिखेंगे:

छिपा हुआ पाठ

 partial class Parser { private List<Lexem> Lexems; private int LexemId; #region Lexem handlers [DebuggerStepThrough] private bool Peek(params LexemType[] types) { var id = Math.Min(LexemId, Lexems.Length - 1); var lex = Lexems[id]; return lex.Type.IsAnyOf(types); } [DebuggerStepThrough] private Lexem Ensure(LexemType type, string msg, params object[] args) { var lex = Lexems[LexemId]; if(lex.Type != type) error(msg, args); Skip(); return lex; } [DebuggerStepThrough] private bool Check(LexemType lexem) { var lex = Lexems[LexemId]; if (lex.Type != lexem) return false; Skip(); return true; } [DebuggerStepThrough] private void Skip(int count = 1) { LexemId = Math.Min(LexemId + count, Lexems.Length - 1); } #endregion #region Node handlers [DebuggerStepThrough] private T Attempt<T>(Func<T> getter) where T : LocationEntity { var backup = LexemId; var result = Bind(getter); if (result == null) LexemId = backup; return result; } [DebuggerStepThrough] private T Ensure<T>(Func<T> getter, string msg) where T : LocationEntity { var result = Bind(getter); if (result == null) throw new Exception(msg); return result; } [DebuggerStepThrough] private T Bind<T>(Func<T> getter) where T : LocationEntity { var startId = LexemId; var start = Lexems[LexemId]; var result = getter(); if (result != null) { result.StartLocation = start.StartLocation; var endId = LexemId; if (endId > startId && endId > 0) result.EndLocation = Lexems[LexemId - 1].EndLocation; } return result; } #endregion }

उनकी मदद से, उपरोक्त व्याकरण का कार्यान्वयन लगभग तुच्छ हो जाता है:

 partial class Parser { public Node ParseAssign() { return Attempt(ParseIdAssign) ?? Attempt(ParseMemberAssign) ?? Ensure(ParseIndexAssign, "  !"); } public Node ParseIdAssign() { var id = TryGetValue(LexemType.Identifier); if (id == null) return null; if (!Check(LexemType.Assign)) return null; var expr = Ensure(ParseExpr, "  !"); return new IdAssignNode { Identifier = id, Expression = expr }; } public Node ParseMemberAssign() { var lvalue = Attempt(ParseLvalue); if (lvalue == null) return null; if (!Check(LexemType.Dot)) return null; var member = TryGetValue(LexemType.Identifier); if (member == null) return null; if (!Check(LexemType.Assign)) return null; var expr = Ensure(ParseExpr, "  !"); return new MemberAssignNode { Lvalue = lvalue, MemberName = member, Expression = expr }; } public Node ParseIndexAssign() { var lvalue = Attempt(ParseLvalue); if (lvalue == null) return null; if (!Check(LexemType.SquareBraceOpen)) return null; var index = Ensure(ParseExpr, "  !"); Ensure(LexemType.SquareBraceClose, "  !"); Ensure(LexemType.Assign, "  !"); var expr = Ensure(ParseExpr, "  !"); return new IndexAssignNode { Lvalue = lvalue, Index = index, Expression = expr }; } }

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

इस विधि के फायदे:

स्टेटस रोलबैक एक बहुत ही सस्ता ऑपरेशन है
यह नियंत्रित करना आसान है कि आप कहां वापस आ सकते हैं
आसानी से विस्तृत त्रुटि संदेश प्रदर्शित करें
किसी बाहरी पुस्तकालय की आवश्यकता नहीं है
उत्पन्न कोड की छोटी राशि

नुकसान:

पार्सर को मैन्युअल रूप से लागू करने में समय लगता है
लेखन की कठिनाई और इष्टतम प्रदर्शन व्याकरण की गुणवत्ता पर निर्भर करता है
वाम पुनरावर्ती व्याकरणों को स्वतंत्र रूप से हल किया जाना चाहिए

संचालक और प्राथमिकताएँ

बार-बार, मैंने व्याकरण वर्णन में निम्नलिखित नियमों के बारे में देखा, जो संचालन की प्राथमिकता दर्शाते हैं:

 expr = expr_1 { op_1 expr_1 } expr_1 = exp2_2 { op_2 expr_2 } expr_2 = exp2_3 { op_3 expr_3 } expr_3 = int | float | identifier op_1 = "+" | "-" op_2 = "*" | "/" | "%" op_3 = "**"

अब कल्पना करें कि हमारे पास अभी भी बूलियन ऑपरेटर, तुलना ऑपरेटर, शिफ्ट ऑपरेटर, बाइनरी ऑपरेटर या कुछ उचित हैं। आपको कितने नियम मिलते हैं, और यदि आपको बीच में कहीं प्राथमिकता के साथ अचानक नया ऑपरेटर जोड़ना है तो आपको कितना बदलना होगा?

इसके बजाय, आप व्याकरण से प्राथमिकताओं के पूरे विवरण को सामान्य रूप से हटा सकते हैं और इसे घोषित रूप से एनकोड कर सकते हैं।

कार्यान्वयन का उदाहरण

 expr = sub_expr { op sub_expr } sub_expr = int | float | identifier

 partial class Parser { private static List<Dictionary<LexemType, Func<Node, Node, Node>>> Priorities = new List<Dictionary<LexemType, Func<Node, Node, Node>>> { new Dictionary<LexemType, Func<Node, Node, Node>> { { LexemType.Plus, (a, b) => new AddNode(a, b) }, { LexemType.Minus, (a, b) => new SubtractNode(a, b) } }, new Dictionary<LexemType, Func<Node, Node, Node>> { { LexemType.Divide, (a, b) => new DivideNode(a, b) }, { LexemType.Multiply, (a, b) => new MultiplyNode(a, b) }, { LexemType.Remainder, (a, b) => new RemainderNode(a, b) } }, new Dictionary<LexemType, Func<Node, Node, Node>> { { LexemType.Power, (a, b) => new PowerNode(a, b) } }, }; public NodeBase ProcessOperators(Func<Node> next, int priority = 0) { if (priority == Priorities.Count) return getter(); var node = ProcessOperators(next, priority + 1); var ops = Priorities[priority]; while (Lexems[LexemId].IsAnyOf(ops.Keys)) { foreach (var curr in ops) { if (check(curr.Key)) { node = curr.Value( node, ensure(() => ProcessOperators(next, priority + 1), " !") ); } } } return node; } }

अब, एक नया ऑपरेटर जोड़ने के लिए, आपको प्राथमिकता सूची के प्रारंभ में संबंधित लाइन जोड़ने की आवश्यकता है।

अनुपस्थित उपसर्ग ऑपरेटरों के लिए समर्थन जोड़ना जिज्ञासु के लिए एक कसरत के रूप में छोड़ दिया जाता है।

इसने हमें क्या दिया?

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

परिणामों की कुल, तुलनात्मक तालिका:

पैरामीटर	FParsec पार्सर	शुद्ध c #
1 रन के लिए पारसिंग टाइम	220 मि	90 मि
आगे के रन के लिए पारसिंग टाइम	5 मि	6 मि
लाइब्रेरी आवश्यक आकार	800 केबी + एफ # रनटाइम	260 केबी

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

व्याकरण में बदलाव के साथ सिरदर्द से छुटकारा पाने के बाद, हम LENS में कुछ सुखद चीजों को प्राप्त करने में सक्षम थे:

पाश के लिए

इसका उपयोग दृश्यों को दरकिनार करने और सीमाओं के लिए दोनों के लिए किया जाता है:

 var data = new [1; 2; 3; 4; 5] for x in data do println "value = {0}" x for x in 1..5 do println "square = {0}" x

समारोह रचना

ऑपरेटर का उपयोग करना :> आप नए कार्य बना सकते हैं, मौजूदा लोगों को "स्ट्रिंग" कर सकते हैं:

 let invConcat = (a:string b:string) -> b + a let invParse = incConcat :> int::Parse invParse "37" "13" // 1337

अनाम कार्यों का उपयोग करके आंशिक उपयोग संभव है:

 fun add:int (x:int y:int) -> x + y let addTwo = int::TryParse<string> :> (x:int -> add 2 x) addTwo "40" // 42

सिंटेक्स एन्हांसमेंट्स

एकल पंक्ति टिप्पणियाँ:
```
 somecode () // comment 
```
Uninitialized चर:
```
 var x : int 
```
एकल लैम्ब्डा तर्क के आसपास के ब्रैकेट वैकल्पिक हैं:
```
 var inc = x:int -> x + 1 
```
नियंत्रण संरचनाओं में ब्रैकेट हटा दिए गए:
```
 if x then a () else b () while a < b do println "a = {0}" a a = a + 1 
```
try/finally ब्लॉक दिखाई दिया
एक समारोह में एक सूचकांक या फ़ील्ड पास करते समय ब्रैकेट वैकल्पिक होते हैं:
```
 print "{0} = {1}" a[1] SomeType::b 
```

हालांकि, यह परियोजना धीरे-धीरे विकसित हो रही है। अभी भी कई दिलचस्प कार्य हैं। अगले संस्करण की योजना बनाई गई है:

जेनेरिक प्रकार और कार्यों की घोषणा
विशेषताओं के साथ कार्यों या प्रकारों को टैग करने की क्षमता
घटना का समर्थन

आप विंडोज के लिए एकत्रित डेमो भी डाउनलोड कर सकते हैं।

स्क्रैच से एक पार्सर लिखना: क्या शैतान इतना भयानक है?