2016-03-18 28 views
2

請參閱標題。對於我正在編寫的一個小工具,我想介紹一個簡單的布爾過濾器語言,並決定做到「正確」並使用解析器生成器。在用grako玩了一下後,我發現我很喜歡它,並且過濾語言做得相當快(這也很好:))是否可以使用grako生成的解析器而不使用grako?

現在的問題是,如果我想在其他計算機上使用該工具或給對於其他人我首先必須以某種方式使grako在那裏可用,這有點麻煩,因爲其他一切都是標準的python3東西。

我想通過聯合包裝必要的grako-class是可能的,但這似乎有點混亂(許可證會以任何方式提及)。也許我忽略了一些內置的方法。

+0

有時,解析器生成器是矯枉過正的。如果你只想寫一個簡單的布爾表達式語言,你可以用一個手寫的遞歸下降解析器很有效地完成這個任務,並且不需要外部的包依賴。請參閱http://stackoverflow.com/questions/2245962/is-there-an-alternative-for-flex-bison-that-is-usable-on-8-bit-embedded-systems/2336769#2336769 –

+0

Thx for the暗示。我同意,使用發生器可能有點過於頂級,但它只是一個「爲了好玩」 - 而且我確實使用了一個,因爲我在一段時間內還沒有玩過任何東西;-)。 – mageta

回答

1

簡短的回答是

Grako生成的解析器確實需要grako庫。

例如:

with self._group(): 
    with self._choice(): 
     with self._option(): 
      self._token('nameguard') 
     with self._option(): 
      self._token('ignorecase') 
     with self._option(): 
      self._token('left_recursion') 
     self._error('expecting one of: ignorecase left_recursion nameguard') 

所有self._xyz()來自任一grako.contexts.ParseContextgrako.parsing.Parser。所需的回溯,緩存和簿記都隱藏在上下文管理器和裝飾器之後。

生成的解析器依賴於grako是一種設計選擇,旨在使解析器更小,更易於理解,這是該項目的主要目標之一(因爲還有許多其他很棒的生成混淆代碼的解析器生成器) 。

另一種選擇是將生成的解析器可以依賴的代碼複製到每個解析器上,但看起來有點不合理。

+1

澄清:不需要學習Grako庫來構建解析器或翻譯器:README就足夠了。但是......要處理複雜的源語言或目標語言,最好是使用者要麼研究Grako庫在這方面提供的內容,要麼找到等價或更好的其他來源。 – Apalala

相關問題