API는 언제 내장 DSL로 간주됩니까?

API와 임베디드 DSL (Domain Specific Language)의 차이점은 무엇입니까?

그냥 구문입니까?

OpenGL과 같은 API를 고려하십시오. 그래픽 DSL과 다른 점은 무엇입니까?

다시 말해, API가 충분히 복잡한 경우 임베디드 DSL로 간주 될 수 있습니까?

구별하기는 어렵고 사용 된 언어에 따라 다릅니다. 또한 주관적입니다.

clojure에서는 DSL처럼 보이는 API를 정의 할 수 있습니다. 예를 들어, hiccup을 사용하면 html을 생성 할 수 있습니다.

(html [:span {:class "foo"} "bar"])

이것은 lisp 구문이있는 DSL로 간주 될 수 있습니다. html매크로가 될 수 있다는 사실은 s-expressions로 html templating lib를 작성하는 것처럼 동일한 힘을 발휘 합니다 ( sxml 참조 )

파이썬에서 동일한 API는 다음과 같습니다.

html(["span", {"class" : "foo"}, "bar"])

html은 함수입니다. 인수가 먼저 평가 된 다음 함수 호출이 발생합니다. 파이썬 구문이 더 구체적이고 파이썬 의미가 더 엄격하다는 것은이 표현이 언어와 독립적 인 DSL로 해석하기가 더 어렵다는 것을 의미합니다.

고전적인 언어 표현은 데이터 구조와 같은 트리와 노드에서 재귀 적으로 호출되는 평가 함수입니다. LISP 언어는이 트리 구조를 매우 명확하게 만들어 주므로 중첩 함수 호출은 내장 언어 기능과 구별 할 수 없습니다. 이것이 LISP 커뮤니티가 거의 모든 것에 대한 DSL에 대해 말하는 이유입니다.

프로그래밍은 유용한 추상화를 제공하는 것입니다. 복잡한 문제를 해결하는 데 도움이되는 언어 요소로 빌드 한 모든 것 (응용 프로그램의 라이브러리 또는 UI)을 보는 것이 대부분의 것을 설계하는 효과적인 방법이라는 것을 알았습니다. 이 관점에서, 나는 모든 라이브러리가 DSL이라고 주장하지만 그중 일부는 제대로 설계되지 않았습니다 :-)

API와 DSL은 개념이 매우 다르며 겹치는 부분 만 있습니다.

모든 DSL은 컴퓨터 언어 입니다. API를 통해 전달 된 메시지에 사용될 수있는 데이터 언어로 해석, 컴파일, 마크 업, 쿼리 언어 (예 : SQL) 또는 (JSON 또는 XML 사용과 같은) 데이터 언어 일 수 있지만 언어 여야합니다 . 이 용어 는 목적이 아니라 본질을 설명합니다 .

API는 하나의 소프트웨어 구성 요소를 다른 구성 요소에서 사용할 수 있도록하는 인터페이스입니다. 이 용어 는 성격이 아니라 목적을 설명합니다 . API는 예를 들어 DSL 이 아닌 일련의 객체 메소드 일 수 있습니다 . 웹 API는 (가 편안 경우, 당신은 주장 수도, 또는 DSL을 사용할 수 있다 하지만, 공유, 도메인 특정 언어 정의의 일부가 아닌 DSL). 장치의 소프트웨어 드라이버는 C로 작성되고 API는 컴파일 된 라이브러리로 배포되며 프로토콜은 완전히 바이너리이며 라이브러리를 사용할 수있는 모든 언어는 클라이언트를 만드는 데 사용될 수 있습니다. 해당 API의 어떤 것도 DSL이라고 부를 수 없습니다 (API 함수의 기호 이름 목록은 잘라 내지 않습니다).

정의가 주어지면 왜 유사점 만 볼 수 있는지에 대해 약간 혼란 스럽습니다.

일반적으로 아닙니다. DSL은 일부 작업을보다 편리하게하기 위해 의도적으로 일반이 아닙니다 . HTML 또는 로고와 같은 것은 원래 도메인 별 언어였습니다.

일반적으로 가장 강력한 API를 사용하더라도 DSL을 다른 언어로 포함시킬 수 없습니다. 해당 API에 대해 프로그래밍하는 것은 호스트 언어의 일련의 표현식처럼 보이며 특수 언어를 사용하는 것만 큼 편리하지 않습니다.

예외적으로 라이브러리를 통해 구문을 왜곡 할 수있는 탁월한 기회를 제공하는 언어 (C ++와 같은 연산자 오버로드, 스칼라와 같은 새로운 연산자를 발명하거나 소스 필터를 사용하여 Perl과는 완전히 다른 읽기 구문을 미리 선언 함)는 예외입니다. 이러한 언어를 사용하고 제공하는 유연성을 최대한 활용하면 결과가 새로운 특수 목적 언어처럼 보일 수 있습니다 (그러나 의미가 언어가 실제로 발명 된 경우 예상했던 것과는 미묘하게 다를 수 있습니다) 처음부터 끝까지 봉사하십시오.

여기, Martin Fowler의 DslBoundary

이 기사에서 내 이해는 기본적으로 임베디드 DSL이며 API는 크게 다르지 않습니다. 그러나 여기에는 약간의 차이가 있습니다.

1. API 는 새로운 시설을 제공하는 것을 강조합니다.
2. DSL 은 새로운 시설을 제공 할뿐만 아니라 새로운 구문과 새로운 코딩 방법도 제공합니다.

그러나 외부 DSL 에 대해 이야기한다면 또 다른 이야기가 될 것입니다. 외부 DSL은 작은 프로그래밍 언어와 비슷하지만, 모든 문제를 해결할 수는 없지만 특정 문제를 해결할 수 없다는 의미의 범용 언어는 아닙니다.

모든 API가 임베디드 DSL이라고 생각하지만 그 반대는 아닙니다. 모든 임베디드 DSL이 API 인 것은 아닙니다. 언어를 구성 요소를 통합하는 수단으로 사용하는 경우에만 API라고 할 수 있습니다.

API를 임베디드 DSL로 간주 할 수있는 이유는 무엇입니까? 우선, 언어를 형성합니다. 호스트 언어를 통해 결합하여 추상화를 형성하고 복잡한 문제를 해결할 수있는 기본 요소 (유형 및 연산)를 갖습니다. 예를 들어 OpenGL API를 사용하여 3D 장면을 실시간으로 렌더링 할 수 있습니다. Collections API는 객체 집합 등에서 작동하는 알고리즘을 만드는 데 사용할 수 있습니다. 둘째, 분명히 도메인별로 다릅니다. 예를 들어 Collections API의 도메인은 객체 세트를 처리하고 있으며 OpenGL API의 도메인은 3D 렌더링입니다. 따라서 API는 도메인 별 언어입니다.

그러나 모든 DSL이 API 인 것은 아닙니다. 예를 들어, 일부 DSL은 지정된 구성 요소로 구현되지 않아야합니다. 모든 시스템은 일부 추상화를 정의하며, 특정 도메인을 다루는 추상화는 DSL로 간주 될 수 있지만, 이러한 추상화의 구현이 "스왑 가능"해야한다는 의미는 아닙니다. 즉, API를 형성 할 필요는 없습니다. . 그들은 할 수 있지만 항상 필요한 것은 아닙니다. 그러나 구현이 "컴포넌트 화"된 경우 (더 나은 용어가 없어서 유감스럽게도) DSL은 실제로 API가됩니다.