2011-01-07 69 views
3

我需要開發,將閱讀和理解的文本文件中,我會發現,說明操作的列表(即烹調菜單)的自定義語言的應用程序。這種語言尚未定義還,但它可能會採取以下形狀之一:解讀定製語言

  • C++等代碼

(該代碼被隨機產生的,只是舉例的目的):

begin 
repeat(10) 
{ 
    bar(toto, 10, 1999, xxx); 
} 
result = foo(xxxx, 10); 
if(foo == ok) 
{ 
    ... 
} 
else 
{ 
    ... 
} 
end 
  • XML代碼

(該代碼被隨機產生的,只是舉例的目的):

<recipe> 
    <action name="foo" argument"bar, toto, xxx" repeat=10/> 
    <action name="bar" argument"xxxxx;10" condition="foo == ok"> 
     <true>...</true> 
     <false>...</false> 
    </action> 
</recipe> 

無論哪種語言將被選擇,有將具有處理簡單的條件,循環。

我從來沒有這樣的事,但乍一看,它發生,我認爲描述這些操作轉換成XML將simplier又那麼強大。

瀏覽完StackOverFlow之後,我發現了一些名爲「ANTLR」的工具......我開始閱讀「The Definitive ANTLR Reference」,但由於我從來沒有做過這種東西,我很難知道是否它是真正的一種工具,我需要的...

換句話說,做什麼我需要閱讀的文本文件,正確解釋並執行我的C#代碼的行爲。這些操作將通過簡單條件進行相互作用,例如:

  • 如果operation1失敗,則執行operation2 else operation3。
  • 重複操作4 10次。

什麼是最好的語言來描述這些文本文件(XML,我自己的)?這些發展過程中的關鍵點是什麼?

我希望我是明確的:)

非常感謝您的幫助和建議!

+1

我不會說XML不那麼強大,只是更羅嗦。一旦C++語言被解析到表達式樹中,它可以很容易地轉換成XML而不會失去電源。 – MerickOWA 2011-01-07 15:22:29

+0

是的,我害怕遇到循環,條件等方面的困難......正如Moo-Juice所說,我很難將XML看作一種描述邏輯的語言......我認爲它更像是一種描述靜態structre ...我錯了嗎? – 2011-01-12 10:05:49

回答

3

XML是偉大的,在鬆散的方式存儲關係數據。然而,我認爲這是編寫諸如程序之類的邏輯的可怕候選者。

有你使用現有的語法/腳本語言,你可以嵌入,而不是寫你自己的考慮? E.g:

LUA

Python

+0

我可以使用Python創建DSL嗎?最終讀取代碼,解釋它並調用C#方法? – 2011-02-22 14:56:11

1

我建議寫在F#的應用程序。它具有很多用於解析字符串和xmls(如模式匹配和活動模式)的有用功能。

爲了解析類似C的代碼,我會推薦F#(只是做了一個解釋與F#,就像一個魅力)

解析XML的,我會建議C#/ F#+ XmlDocument類。

你基本上需要兩個文件的工作:

  • 操作字典
  • 代碼文件中YourLanguage

負載和解釋運營商,然後遞歸地將其應用到你的代碼文件。

2

在我的項目之一,我竟然開始喜歡語言中的XML,因爲我已經有了一個XML解析器和解析XML結構到內存中的表達式樹來解釋/運行。

這工作也很完美,以獲得通過搞清楚的文本文件標記化/解析,而是專注於你的「語言」和操作都必須在你的語言邏輯的問題。不好的一面是寫文本文件有點奇怪,很羅嗦。它對於程序員使用C/C++語法也非常不自然。

最終,您可以輕鬆地用全面掃描的掃描儀替換您的XML,解析更自然的C++文本格式到您的表達式樹中。

至於寫掃描儀&詞法分析器,我發現使用簡單的邏輯流/循環掃描儀和詞法分析器遞歸正確的分析器手動編寫這些文檔更容易。

也就是說,ANTLR非常擅長讓您爲您的語言編寫規則併爲您生成掃描儀&詞法分析器。這允許更加動態的語言,當添加新事物時,可以容易地改變而不必再次重構所有內容。所以,在學習時可能值得一看,因爲如果你手寫自己的東西,它會爲你節省大量重寫時間,因爲情況會發生改變。

1

最好的預製答案:S-expressions

C和XML是良好的第一步。他們有一些相反的缺點。類C語法不會添加大量額外字符,但由於含糊不清,各種令牌以及可能存在的一系列我無法想到的問題,因此很難解析。 XML相對容易解析,並且有大量的示例代碼,但它也會包含大量額外的文本。它可能會給你太多的選擇來粘住語言特徵 - 例如,重複循環屬性,元素或文本的次數是多少?

S-表達式比XML是肯定的,甚至C.同時更簡潔,他們是特定於應用操作數據的任務。他們不承認含糊不清。解析器是simple and easy to find example code for

在開始試驗之前,這可以使您不必學習太多理論。我會強調MerickOWA的觀點,即ANTLR和其他解析器生成器可能是比現在想要戰鬥的更大的戰鬥。關於這種類型的工具的完整通用性何時可以提供幫助的背景,請參見this discussion on programmers.stackexchange