Lin Descriptor File parser

Question

Lin Descriptor File을 구문 분석하는 데 사용할 수있는 PC 응용 프로그램을 개발할 때 가능한 파서를 연구하려고합니다. 현재 파서 응용 프로그램은 flex-bison 파싱 접근 방식을 기반으로합니다. 이제 현재 파서가 특정 오류를 감지 할 수 없기 때문에 파서를 다시 디자인해야합니다.

정규 표현식 (Regex : https://en.wikipedia.org/wiki/Regular_expression) 구문 분석을 위해 Ragel 파서 (https://en.wikipedia.org/wiki/Ragel)를 사용했으며 매우 유용했습니다.

그러나 현재 복잡도가 LDF-file 인 경우 Ragel (호스트 언어로 C++ 사용)이 LDF-file을 구문 분석하기위한 최선의 방법인지 확신 할 수 없습니다. 그 이유는 LDF-file에 고정되거나 일정하지 않은 많은 데이터가 있지만 공급 업체마다 다릅니다. 또한 LDF 필드는 파일의 오류를 감지하기 위해 다른 필드에 대한 참조를 보유해야합니다. 구문 분석에 대한 구조가 고정 될 때 Ragel가 더 적합하다 (내가 찾은 이잖아 정규식 파서를 개발하는 동안)

이미 프로젝트에 근무하고있다 사람은 린 설명자에 대한 적절한 파서를 선택하는 몇 가지 팁을 제공 할 수있다 파일. 린 설명자 파일에 대한

예 : http://microchipdeveloper.com/lin:protocol-app-ldf 당신은 LALR (1) 파서가 파싱 문제에 적합하지 않다고 생각되면

Answer 1

, 유한 자동 장치가 더 좋을 것이라고 할 수 없습니다. FA는 엄격하게 덜 강력합니다.

그러나 구현하려는 검사의 특성에 대해 잘 모르는 상태에서 파일을 간단한 계층 적 데이터 구조 (예 : 일종의 형태의 트리)로 파싱하는 것이 적절한 전략이라고 확신합니다. AST에서 문법 분석에 사용), 결과 데이터 구조를 따라 어떤 의미 론적 검사가 필요한지를 수행합니다.

구문 분석 중에 의미 검사를 시도하면 일반적으로 지나치게 복잡하고 심하게 분해되고 확장 불가능한 솔루션이 생성됩니다. 그것은 bison 도구에 문제가 아니라 사용의 특정 스타일로 우려 사항 분리의 중요성에 대해 배운 것을 고려하지 않았습니다.

기존의 문법을 리팩토링하여 "단지 문법"즉 필요한 의미 론적 표현을 생성하도록 리팩토링하는 것은 다른 파서 생성기를 사용하여 재 구현하는 것보다 훨씬 간단합니다. 어떠한 경우에도 실질적인 이점을 제공합니다).

파서 생성기를 버리려는 유혹에 좀더 모듈화 된 솔루션을 선호하여 분명히 저항해야합니다. 무언가를 구축하는 데 성공할 수도 있지만 결과가 현재 가지고있는 것보다 유지 보수가 쉽고 확장 성이 떨어질 가능성이 있습니다. .