C＃语法问题 [英] C# Grammar issues
问题描述
你好......我正在使用语法：
http://msdn.microsoft.com/library/de...harpspec_c.asp
作为使用自定义框架创建我自己的C＃解析器的参考。
（如果有更好的组可以发布，请告诉我。）
>
一些问题：
（1）这个语法规范是否已知完整且正确？
（2）是否有适用的规范化LL语法for
（回溯）递归正常的系统？
（3）通过使用EBNF风格
规格，可以简化大部分语法 - 很高兴找到一个这样的方式
（5）是否有一个参数化的允许c＃2.0和c＃3.0的版本，
带有和不带托管扩展的
？
（6）是否有其他来源？ （我发现了一些不完整的语法和
一些已被重新定位到不可读的地方。）
（7）有语法中的简单和一些不那么简单的左递归。
简单的直接递归可以更改为EBNF样式的重复
没有左递归：
乘法表达式：
一元表达式
乘法表达式*一元表达式
乘法表达式/一元表达式
乘法表达式％一元表达式
变为（我认为）：
multiplicative_expression :: =
（unary_expression，" *"）*，unary_expression |
（unary_expression，" /"）*，unary_expression |
（unary_expression，"％"）*，unary_expression。
但也有一些非常深的递归，例如这个（很多
可以是det已经发布）：
类型 - >
| reference_type - >
| | array_type - >
| | | non_array_type - >
< < < <类型< - 递归
我想知道这是否有必要甚至是正确的。与直接的
递归不同，在某些情况下，很难说出含义是什么意思。制作
重写困难。
任何指针/建议表示赞赏...
谢谢，
mike
-
通过 http://www.teranews.com
Hello... I''m using the grammar at:
http://msdn.microsoft.com/library/de...harpspec_c.asp
as a reference in creating my own C# parser using a custom framework.
(Please let me know if there''s a better group to post in.)
Some questions:
(1) Is this grammar specification known to be complete and correct?
(2) Is there a normalized LL grammar available already suited for
(backtracking) recursive decent systems?
(3) Much of the grammar can be simplified by using EBNF-style
specifications -- it would be nice to find one this way already
(5) Is there a "parameterized" version that allows for c# 2.0 and c# 3.0,
with and without managed extensions?
(6) Are there alternate sources? (I''ve found some incomplete grammars and
some that are already re-purposed to the point of being unreadable.)
(7) There are simple and some not so simple left-recursions in the grammar.
The simple, direct recursions can be changed to EBNF-style repetitions
without left recursion:
multiplicative-expression:
unary-expression
multiplicative-expression * unary-expression
multiplicative-expression / unary-expression
multiplicative-expression % unary-expression
becomes (I think):
multiplicative_expression ::=
(unary_expression, "*" )* , unary_expression |
(unary_expression, "/" )* , unary_expression |
(unary_expression, "%" )* , unary_expression.
But there are also some very deep recursions such as this one (of many that
can be detected):
type -->
| reference_type -->
| | array_type -->
| | | non_array_type -->
< < < < type <-- Recursive
I''m wondering if this is necessary or even correct. Unlike the direct
recursions, in some of these cases it''s hard to tell what''s "meant" making
re-writes difficult.
Any pointers/advice appreciated...
thanks,
mike
--
Posted via a free Usenet account from http://www.teranews.com
推荐答案
这远远不够回答你的问题，但我很想知道为什么
你正在尝试编写自己的C＃解析器。
因为这是本质上是一种专有语言（尽管提交给ECMA
）MS的解析器的行为根据定义是官方的b $ b行为，以及不可避免的模糊细节从完全记录中实现远远超过
。因此，在没有内部MS代码的情况下尝试提供功能性的b $ b等效解析器是一个愚蠢的错误。
所以为什么浪费你的时间？而且，事实上，重点是什么？
但是，这是一个严肃的问题，而不是火焰，我希望你能够b / b
看看你明确回应的方式。
Tom Dacon
Dacon软件咨询
" MBR" < no *** @ nospam.com写信息
news：45 *********************** @ free.teranews .com ..
This is nowhere near an answer to your question, but I''m curious to know why
you''re trying to write your own C# parser.
Since this is essentially a proprietary language (submissions to ECMA
notwithstanding) the behavior of MS''s parser is by definition the "official"
behavior, and the inevitable ambiguous details of implementation are far
from completely documented. So trying to come up with a functionally
equivalent parser in the absence of the internal MS code is a fool''s errand.
So why waste your time? And, in fact, what''s the point?
But nevertheless, this is a serious question, not a flame, and I hope you
will see your way clear to respond.
Tom Dacon
Dacon Software Consulting
"MBR" <no***@nospam.comwrote in message
news:45***********************@free.teranews.com.. .
你好......我正在使用语法：
http://msdn.microsoft.com/library/de...harpspec_c。 asp
作为使用自定义框架创建我自己的C＃解析器的参考。
（如果有更好的团队发布，请告诉我。）
一些问题：
（1）这个语法规范是否完整正确？
（2）是否有一个标准化的LL语法已经适用于
（回溯）递归正常系统？
（3）通过使用EBNF样式可以简化大部分语法/>
规格 - 以这种方式找到它会很好
（5）是否有参数化允许c＃2.0和c＃3.0的版本，
带有和不带托管扩展的
？
（6）是否有其他来源？ （我发现了一些不完整的语法和
一些已被重新定位到不可读的地方。）
（7）有
语法中的简单和一些不那么简单的左递归。
简单的直接递归可以改为EBNF式重复
没有左递归：
乘法表达式：
一元表达式
multiplicative-expression *一元表达式
multiplicative-expression / unary-expression
multiplicative-expression％unary-expression
变为（我认为）：
multiplicative_expression :: =
（unary_expression，" *"）*，unary_expression |
（unary_expression，" /" ;）*，unary_expression |
（unary_expression，"％"）*，unary_expression。
但是也有一些非常深的递归，比如这个Ø ne（可以检测到许多
）：
类型 - >
| reference_type - >
| | array_type - >
| | | non_array_type - >
< < < <类型< - 递归
我想知道这是否有必要甚至是正确的。与直接的
递归不同，在某些情况下，很难说出含义是什么意思。制作
重写困难。
任何指针/建议表示赞赏...
谢谢，
mike
-
通过 http://www.teranews.com
" Tom Dacon" < td **** @ community.nospamwrote in message
news：e0 ************** @ TK2MSFTNGP05.phx.gbl ...
"Tom Dacon" <td****@community.nospamwrote in message
news:e0**************@TK2MSFTNGP05.phx.gbl...
这远不是你问题的答案，但我很想知道
为什么你要编写自己的C＃解析器。
因为这本质上是一种专有语言（尽管提交给ECMA
），MS的解析器的行为根据定义是
官方行为，以及
实施的不可避免的模糊细节远未完全记录。因此，在没有内部MS
代码的情况下尝试使用功能相当的解析器来提供
是一个愚蠢的错误。
This is nowhere near an answer to your question, but I''m curious to know
why you''re trying to write your own C# parser.
Since this is essentially a proprietary language (submissions to ECMA
notwithstanding) the behavior of MS''s parser is by definition the
"official" behavior, and the inevitable ambiguous details of
implementation are far from completely documented. So trying to come up
with a functionally equivalent parser in the absence of the internal MS
code is a fool''s errand.
你可能是对的，虽然我希望情况并非如此 - 考虑到你提到的ECMA
提交。 />
我知道
You may be right, although I hope it''s not the case - considering the ECMA
submission as you mentioned.
I knm
>
为什么要浪费你的时间？而且，事实上，重点是什么？
>
So why waste your time? And, in fact, what''s the point?
有很多原因可以让人们想做这样的事情：作为一般的
exersize，了解各种解析系统/权衡，有一个系统
存在于MS开发环境之外，有一个系统，即b
表示第三方系统不具备的特殊/特殊行为/>
支持等 - 我的答案是每个中的一部分。 C＃是一个
初始目标语言（我经常使用的一种语言），所以这就是为什么我用它开始
。
谢谢
m
There are many reasons why one would want to do such a thing: as a general
exersize, to understand various parsing systems/tradeoffs, to have a system
that exists outside of the MS development environment, to have a system that
exhibits specialized/particular behaviors that 3rd party systems don''t
support, etc. -- my answer is some percentage of each of these. C# is an
initial target language (and one I use often), so that''s why I''m starting
with it.
thanks
m
>
但是，这是一个严肃的问题，不是火焰，我希望你
会看到你清楚的回应。
Tom Dacon
Dacon Software Consulting
" MBR" < no *** @ nospam.com写信息
news：45 *********************** @ free.teranews .com ..
>
But nevertheless, this is a serious question, not a flame, and I hope you
will see your way clear to respond.
Tom Dacon
Dacon Software Consulting
"MBR" <no***@nospam.comwrote in message
news:45***********************@free.teranews.com.. .
>你好......我正在使用语法：
http://msdn.microsoft.com/library/de ... harpspec_c.asp
作为使用自定义框架创建自己的C＃解析器的参考。
（请告诉我是否有更好的团队发布。）
一些问题：
（1）这个语法规范是否已知完整且正确？
（2）是否存在已经适用于
（回溯）递归的规范化LL语法体面的系统？
（3）通过使用EBNF风格的规范可以简化大部分语法 - 以这种方式找到这种语法会很好
（5）是否有 ;参数"允许使用c＃2.0和c＃3.0，带有和不带托管扩展的版本？
（6）是否有其他来源？ （我发现了一些不完整的语法和一些已被重新定位到不可读的地方。）
（7）有一些简单而有些不那么简单的左 -
语法中的递归。
简单，直接的递归可以改为EBNF式重复
而无需左递归：
乘法表达式：
一元表达式
乘法表达式*一元表达式
乘法表达式/一元表达式
乘法表达式％一元表达式
变为（我认为）：
multiplicative_expression :: =
（unary_expression，" *"）*，unary_expression |
（unary_expression，" /"）*，unary_expression |
（unary_expression，"％"）*，unary_expression。
但也有一些非常深的递归，例如这个（可以检测到的很多
）：
类型 - >
| reference_type - >
| | array_type - >
| | | non_array_type - >
< < < < type< - Recursive
我想知道这是否有必要甚至是正确的。与直接递归不同，在某些情况下，很难说出重要意味着重写很难。
任何指针/建议赞赏...
谢谢，
mike
-
通过 http://www.teranews.com
-
通过 http：/的免费Usenet帐户发布/www.teranews.com
--
Posted via a free Usenet account from http://www.teranews.com
Tom Dacon< td **** @ community.nospamwrote：
Tom Dacon <td****@community.nospamwrote:
这远不是你问题的答案，但是我很想知道为什么你要尝试编写自己的C＃解析器。
因为这本质上是一种专有语言（尽管提交给ECMA
）MS的解析器的行为是d定义官方
的行为，以及实施的不可避免的模糊细节远远不是完全记录下来的。因此，在没有内部MS代码的情况下尝试提供功能性的b $ b等效解析器是一个愚蠢的错误。
所以为什么浪费你的时间？而且，事实上，重点是什么？
但是，这是一个严肃的问题，而不是火焰，我希望你能够b / b
看你的方式明确回应。
This is nowhere near an answer to your question, but I''m curious to know why
you''re trying to write your own C# parser.
Since this is essentially a proprietary language (submissions to ECMA
notwithstanding) the behavior of MS''s parser is by definition the "official"
behavior, and the inevitable ambiguous details of implementation are far
from completely documented. So trying to come up with a functionally
equivalent parser in the absence of the internal MS code is a fool''s errand.
So why waste your time? And, in fact, what''s the point?
But nevertheless, this is a serious question, not a flame, and I hope you
will see your way clear to respond.
你会问同样的Mono团队问题吗？就像
的一个例子，为什么有人可能想要这样做...
-
Jon Skeet - < sk***@pobox.com>
http：//www.pobox。 com / ~siget 博客： http://www.msmvps.com/ jon.skeet
如果回复小组，请不要给我发邮件
Would you ask the same question of the Mono team? Just as an example of
why someone might want to do it...
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
这篇关于C＃语法问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
