DSL에 구문 분석 도구가 필요한 이유는 무엇입니까?

DSL을 API처럼 단순하게 사용할 수 없으므로 파서가 필요하지 않습니까? 아니면 도메인 특정 언어가 실제로 무엇인지 오해하고 있습니까? 특정 도메인 문제를 해결하기위한 체계적인 정리 된 규칙을 언급했다고 생각했습니다. API가 그 정의에 맞는 것처럼 보입니다. 맞습니까?DSL에 구문 분석 도구가 필요한 이유는 무엇입니까?

출처

2009-02-01 Anonymous

보다 일반적인 프로그래밍 언어로 DSL을 내장 할 수 있습니다. 이것은 종종 좋은 해결책입니다. (이 DSL은 특정 API의 형태라고 말할 수 있습니다.)

도메인의 개념을 나타 내기 위해 자체 인터프리터를 사용하여 별도의 언어를 만들 수도 있습니다. 이것은 더 큰 사업이되는 경향이 있으며 종종 필요하지 않습니다.

출처

2009-02-01 23:17:17 yfeldblum

"DSL"로 API를 사용하는 근본적인 결함은 언어에서 구문 및 묵시적 의미에 대한 법적 명령이 있다는 것입니다. API를 사용할 때 컴파일하는 모든 API 호출 시퀀스를 작성할 수 있지만 임의의 순서는 적법하지 않습니다. * langauge *의 값은 어떤 시퀀스가 합법적인지 정의하고, 좋은 "파서"(예 : 구문을 검사하고 의미를 검사하는)가 무의미한 시퀀스를 실행하지 않고도이를 거부합니다. –

동의합니다. 외부 DSL을 작성해야하는 이유는 분명 있습니다. DSL이 신뢰할 수없는 사용자가 프로그램을 작성하도록 의도 된 경우, 이전 프로그래밍 언어 (예 : DSL이 포함될 수있는 언어)로 작성하는 것을 원하지 않습니다. 두 가지 접근법에 장단점이 있습니다. 제 견해로는 좋은 호스트 언어로 임베디드 DSL을 작성하는 것이 더 쉽습니다. 따라서 그렇게하는 것이 타당한 한도에서 그렇게하십시오. 그러나 임베디드 DSL이 부족한 경우 충분한 외부 DSL을 작성해야합니다. – yfeldblum

다음은 DSL 문서 http://www.robusthaven.com/blog/parsing-expression-grammar/npeg-dsl-documentation의 예입니다. C#에서 인라인으로 사용하거나 언어 작업대 http : //를 사용하여 파서를 내보낼 수 있습니다. /www.robusthaven.com/blog/parsing-expression-grammar/npeg-language-workbench –

당신은 여전히 호스트 언어의 의미만을 갖습니다.

예 : 명령형 언어의 함수 프로그래밍이 작동하지 않습니다. 따라서이 명령형 언어에 기능적 DSL이 추가되었습니다 ...

출처

2009-02-01 23:02:03 Leonidas

아. 따라서 DSL은 특정 언어의 의미 론적 한계를 확장함으로써 그것을 극복하기위한 것입니까? 그리고 파서가 필요합니다 - 파서가 사용자의 의미 론적 확장을 해석합니다 - 맞습니까? –

그건 내 DSL에 대한 해석이지만, 나는 단지 extern DSL에 대한 경험이있다. Say, SQL;) – Leonidas

개념을 구현과 혼동하고 있습니다. 도메인 특정 언어는 일반적으로 문제를 해결하기위한 설명을위한 일반 언어가 아닌 문제가있는 영역에 "가까운"것으로 간주되는 아이디어의 표현입니다.

예, DSL은 문제 도메인의 특정 개념을 참조하는 기능을 제공하는 API로 구현 될 수 있지만 DSL은 텍스트 파일로 표시 될 때도 똑같이 유효합니다.

실용적인 프로그래머 : 숙련공에서 주인에게에는 유용한 DSL 및 사례에 대한 설명과 예제가 들어 있습니다. 추천.

출처

2009-02-01 23:15:20 womble

예, 절대적으로 - 단순한 API는 호스트 언어가 호스트 언어를 지원할 수있는 충분한 유연성을 가지고 있으면 DSL로 잘 처리 할 것입니다.

루비는 선택 사항 인 괄호와 다른 유연성을 고려해 볼 때 매우 좋은 언어입니다.

레일은 종종 데이터베이스 기반 웹을 응용 프로그램을 작성하기위한 DSL 라고합니다.
레이크는 (더 똑똑한) 메이크 파일을위한 DSL이있는 빌드 시스템입니다.

내 자신의 OOFILE 당신이 C++에서 데이터베이스 응용 프로그램을 작성하기위한 DSL로 간주 할 수있는 프레임 워크입니다 - 그것은 디베이스에서 영감을했다 및 C++ 연산자 오버로딩, 로컬 객체 및 스트림 숙어 매우 많이 사용한다.

Forth는 전통적으로 DSL과 API 사이의 줄을 흐리게 만드는 언어로서, Forth 프로그램은 일련의 공백으로 구분 된 단어로 구성되어 있습니다. 아마도 DSL의 가장 인상적인 예는 Abundance - 입니다. 풍부는 BBL Forth로 작성된 Forth 기반 비즈니스 프로그래밍 언어입니다. BBL은 32 비트 DOS FORTH 컴파일러입니다. 있는 그대로 배포됩니다. 경고를 참조하십시오. 이것은 희미한 마음이 아닙니다. 오래된 Klunker XT 및 AT 컴퓨터에서 빠른 실행이 필요한 제 3 세계를위한 소프트웨어를 개발하는 사람이 주로 관심을 가질 것입니다. 현대의 데이터 입력 프로그램을 둘러싼 매우 정교한 데이터 입력 프로그램을 작성할 수 있습니다.

출처

2009-02-01 23:32:37

-2

물론 그래픽 DSL은 구문 분석이 필요하지 않습니다.

출처

2009-05-11 17:55:44

정말 오해의 소지가있는 답변입니다. 뭔가 DSL 프로그래머로부터 "DSL 조각을 받아 들여야"하고 무엇이 입력되었는지 확인해야합니다. 무언가가 문자열 기반 언어를위한 전통적인 파서 생성기이든, 또는 상자를 연결하는 상자와 화살표를 허용하는 임시 그래픽 UI 또는 그래프 문법에서 자동 생성 된 UI이든간에이 기계를 가지고 있어야합니다. 그리고 텍스트 기반 DSL을위한 기계는 현재 그래픽 언어를위한 것보다 함께 조립하는 것이 훨씬 쉽습니다. 돼지는 개라고 말할 수 있지만 여전히 돼지입니다. –

@Ira : 저는 Visual Studio SDK에서 DSL Toolkit을 살펴보아야한다고 생각합니다. 구문 분석이 없습니다. 파편을 받아 들일 수 없습니다. UI는 드래그 앤 드롭과 같은 GUI 동작을 메뉴 또는 키보드 명령과 함께 받아 들여 DSL 인스턴스의 메모리 내 표현을 작성합니다. _parsing_이 아닌 _buildding_입니다. –

불법 제스처가 있으면 "파싱"입니다. 문자열 파서는 메모리에도 데이터 구조를 "빌드"합니다. 파싱이 무엇인지에 대한 토론에서 어떤 차이가 있는지 확인하지 못했습니다. "하지만 파서를 쓸 필요가 없습니다."라고 말할 수 있습니다. 좋아, 거기에 동의할지 모르지만, 다시 Bison (당신이 쓸 필요가없는)과 그 차이점은별로 없다. 어딘가에 누군가 (당신?)은 합법적 인 구조가 무엇인지 말해야 만합니다. 무엇인가 "몸짓을하고있는"것이 그러한 법적 구조를 만들어 내는지 확인해야합니다. 당신은 * 파서를 가지고 있고 파싱하고 있습니다. –

DSL에 구문 분석 도구가 필요한 이유는 무엇입니까?

답변

관련 문제