是否存在[詞法分析器]的目的的正式定義?
不是。詞法分析器是實際編程世界的一部分,對此正式模型是有用的,但不是確定性的。一個聲稱做某事的程序當然應該做那件事,但是「詞法分析我的編程語言」並不是一個足夠精確的需求陳述。
…或明確的最佳使用做法
如上所述,詞法分析器應該按照它的意圖去做。它也不應該試圖做其他事情。應避免代碼重複。理想情況下,代碼應該是可驗證的。
這些最佳實踐激發了一個成熟的文檔良好的掃描程序框架的使用,該框架的輸入語言翻譯爲要分析的詞法語法的描述。但是,基於特定編程語言特性的實際考慮通常會導致與這種理想的偏差。
有一個詞法分析器可以將每個輸入字符轉換成一個令牌似乎沒有什麼明顯的錯誤,
在這種情況下,詞法分析器將是多餘的;解析器可以簡單地使用輸入流。這被稱爲「無掃描儀解析」,它有其倡導者。我不是其中之一,所以我不會討論利弊。如果你有興趣,你可以從Wikipedia article開始,並按照其鏈接。如果這種風格適合你的問題領域,那就去做吧。
在某些(上下文無關)語言中,不可能發生這樣的情況:「令牌」的預期概念可能依賴於上下文嗎?
當然。一個典型的例子是在EcmaScript正則表達式「文字」中找到的,它需要用完全不同的掃描儀進行詞法分析。 EcmaScript 6還定義了需要單獨掃描環境的字符串模板文字。這可以激發無掃描處理,但它也可以用帶詞彙反饋的LR(1)解析器來實現,其中特定標記非終端的縮小動作導致切換到不同的掃描器。
但是,如果讓一個詞法分析器區分(例如,「一元減法」和通常的二進制減法之間),而不是將其留給解析器,是否可以接受?
任何東西都可以接受,但這個特殊的例子讓我覺得不是特別有用。 LR(甚至LL)表達式解析器不需要任何詞法掃描程序的幫助來顯示減號的上下文。 (樸素運算符優先級語法確實需要這樣的幫助,但更深思熟慮的運算PREC架構不會。但是,LALR解析器生成的存在或多或少地避免了對運算PREC解析器的需要。)
一般發言,對詞法分析器能夠識別語法情況下,它需要複製解析器所做的分析,從而違反了代碼開發的基本最佳實踐(「不重複的功能」)之一。儘管如此,它可能偶爾有用,所以我不會主張絕對禁止。例如,對於YACC /野牛狀生產規則許多解析器補償這樣一個事實:幼稚語法是LALR(2)由專門標記ID的令牌被緊跟一個冒號。
又如,再次從EcmaScript的拉伸,是自動的分號插入(ASI),其可以使用查找表,其鍵是連續的令牌的2元組來完成的高效處理。同樣,Python的空白感知語法可以方便地通過詞法掃描程序的幫助來處理,這些掃描程序必須能夠理解縮進是否相關(例如,不在括號或大括號內)。
如何對這條規則:「一個詞法分析器必須線性時間和數空間的工作」? – Alexey
另一個可能的規則:「一個詞法分析器消除源代碼格式」 ...... – Alexey