[논문 리뷰] An Architecture for Making Object-Oriented Systems Available from Prolog

Jan Wielemaker, Anjo Anjewierden|ArXiv.org|2002. 07. 12.

Logic, programming, and type systems참고 문헌 1인용 수 16

한 줄 요약

이 논문은 외부 객체 지향(OO) 시스템—특히 GUI 라이브러리—를 Prolog에 원활하게 통합할 수 있는 일반적인 아키텍처를 제안한다. 이 아키텍처는 OO 객체와 메서드를 Prolog 내의 일급 엔티티로 노출시켜, Prolog 내에서 객체 지향 프로그래밍을 가능하게 한다. 이 접근법은 경량이며 타입 안전한 인터페이스를 사용하여 Prolog term을 OO 객체로 매핑하고, 경계를 넘는 메서드 호출을 허용하며, 전체 디버깅과 점진적 개발을 지원한다. 이로써 메서드 호출당 1–5.2μs의 낮은 지연 시간을 달성하면서도 순수 Prolog로 응용 로직과 GUI 컴포넌트를 개발할 수 있다.

ABSTRACT

It is next to impossible to develop real-life applications in just pure Prolog. With XPCE we realised a mechanism for integrating Prolog with an external object-oriented system that turns this OO system into a natural extension to Prolog. We describe the design and how it can be applied to other external OO systems.

연구 동기 및 목표

• Prolog가 효율적인 GUI 개발을 위한 내장 지원을 하지 않기 때문에, 강력한 외부 객체 지향 GUI 시스템을 Prolog에 통합하는 데 도전하는 것.
• Prolog와 외부 GUI 코드 사이에 별도로 수동으로 유지 관리되는 다리가 필요 없도록 하여 Prolog에서 외부 OO 시스템에 직접적이고 투명한 접근을 가능하게 하는 것.
• Prolog 프로그래머가 응용 로직과 GUI 컴포넌트를 동일한 언어와 도구를 사용하여 전적으로 Prolog에서 개발할 수 있도록 하는 것.
• 런타임 시 동적 클래스 및 메서드 생성을 지원하여, Prolog 내에서의 빠른 프로토타ип링과 외부 OO 시스템의 원활한 확장이 가능하도록 하는 것.
• 외부 코드와 이벤트 기반 GUI 상호작용이 존재하더라도 Prolog의 전체 디버깅 및 점진적 개발 기능을 유지하는 것.

제안 방법

• 아키텍처는 네 가지 핵심 Prolog 술어를 정의한다: `new/2`는 객체 생성을 위해, `send/3`는 메서드 호출을 위해, `get/3`는 속성 접근을 위해, `is_a/2`는 타입 체크를 위해 사용되며, 모두 기반 OO 시스템을 추상화한다.
• Prolog 데이터 유형(원자, 정수, 복합 항목)을 대상 OO 시스템(예: XPCE)의 해당 유형으로 매핑하며, 자동 변환과 타입 안정성을 보장한다.
• 인터페이스는 C를 공통 언어 브리지로 사용하여, C 호환 함수 포인터를 활용해 외부 OO 시스템의 메서드를 호출함으로써 성능과 이식성을 확보한다.
• 시스템은 동적 메서드 디스패치와 런타임 클래스 생성을 지원하여, 재컴파일 없이도 Prolog 내에서 새로운 클래스와 메서드를 정의하고 사용할 수 있다.
• Prolog의 내장 디버거와 통합되어, 외부/Prolog 경계 전환 시 스택 컨텍스트를 유지하고, Prolog 및 외부 코드 양쪽에서 브레이크포인트 설정을 지원한다.
• 디자인은 모든 응용 로직이 Prolog에서 실행되도록 보장하여, 개발 생애주기 전반에 걸쳐 Prolog의 점진적 컴파일 및 디버깅 도구를 사용할 수 있도록 한다.

실험 결과

연구 질문

• RQ1 Prolog가 저수준 C 바인딩이나 별도의 GUI 코드 없이도, 외부 객체 지향 시스템(예: GUI 라이브러리)을 원천적으로 투명하게 접근할 수 있는 방법은 무엇인가?
• RQ2 Prolog에서 외부 OO 시스템으로의 인터페이스를 통해 발생하는 성능 오버헤드는 얼마나 되며, 이를 최소화하여 인터랙티브 GUI 애플리케이션을 지원할 수 있는가?
• RQ3 Prolog 코드와 외부 이벤트 기반 OO 시스템을 혼합할 경우, 전체 디버깅 및 점진적 개발 기능을 유지할 수 있는가?
• RQ4 상속, 동적 메서드 디스패치, 런타임 클래스 생성과 같은 객체 지향 프로그래밍 개념이 Prolog 내에서 얼마나 노출되고 사용될 수 있는가?
• RQ5 어떻게 하면 응용 로직과 GUI 컴포넌트가 모두 Prolog에서 작성되고 디버깅되는 통합 개발 환경을 지원할 수 있는가?

주요 결과

• Prolog에서 외부 OO 시스템으로의 인터페이스는 낮은 지연 시간의 메서드 호출을 달성하여, AMD 1600+ 프로세서에서 메서드 호출당 1.0~5.2 마이크로초의 실행 시간을 기록한다.
• C로 정의된 내장 메서드(예: `normalise`)를 호출할 경우 오직 1.0μs의 오버헤드만 발생하여, 인터랙티브 GUI에 적합한 높은 효율성을 입증한다.
• 시스템은 Prolog 및 외부 코드의 전체 디버깅을 지원하며, SWI-Prolog 디버거가 Prolog-외부 경계를 넘는 혼합 스택 트레이스를 표시할 수 있다.
• 브레이크포인트는 Prolog 및 외부 코드 양쪽에 설정할 수 있으며, 디버거는 실행 중에 갑작스러운 이벤트 기반 호출(예: 마우스 드래그)을 처리할 수 있다.
• 새로운 클래스와 메서드는 런타임 시 Prolog에서 동적으로 생성할 수 있으며, 재컴파일이나 소스 파일 생성 없이도 외부 OO 시스템을 원활하게 확장할 수 있다.
• 이 아키텍처는 Prolog 내에서 GUI와 응용 로직을 완전히 통합하여 개발할 수 있도록 하여, 복잡한 인터페이스 동기화가 필요한 별도의 GUI 및 Prolog 프로그램이 필요 없도록 한다.