[프로그래밍언어론] 프로그래밍 언어 설계

 

 

이 글은 국민대학교 강승식 교수님의 '프로그래밍언어론' 수업을 토대로
개인적으로 학습한 내용입니다.

 

 

3.1 설계 기준의 역사적 변천

 

주요 언어의 성공 요인을 보면

 

• Fortran – 컴퓨터 제조회사 후원
  
  => 실행의 효율성
  
  
• Cobol – 미 국방성 지원
  
  => 영어와 유사한 문법 구조로 프로그램 판독성이 용이해서 비즈니스 영역이 넓음
  
  
• Lisp – 인공지능 분야에서 사용
  
  
• Pascal – 교육용, 마이크로컴퓨터 표준언어 역할
  
  => 간단한 명령형 언어, 하향식 설계 증진
  
  
• PL/I – IBM의 적극 후원
  
  
• C – UNIX 운영체제의 성공
  
  
• Ada – 미 국방성 지원
  
  
• Algol 60 
  
  => 알고리즘 작성이 용이하도록 설계를 하였는데 블록 구조를 제공하기에 디버깅이 용이하고 recursion이 가능하며 개발 속도가 빨라짐

 

언어 자체의 성공 요인 보다는 대부분 외적 요인으로 성공하였음

 

1950년대

 

초기에는 실행 속도가 빠른 어셈블리어와 경쟁해야했음

=> Fortran 처럼 실행의 효율성을 중시함

 

이후 Cobol과 Algol 60의 등장으로 효율성보다 일반적인 원칙을 중시하였음

 

• Algol 60 : 블록 구조, 재귀 함수, 논리적으로 간결 명료한 알고리즘 표현
  
  
• Cobol : 프로그램 판독성 증가 (move a to b 처럼 영어와 유사한 syntax)

 

1960년대

 

CPU와 같은 컴퓨터 하드웨어가 점차 빨라졌음

 

=> 복잡성 제어의 필요성을 인식하게됨

(추상화 기법, 언어 규칙과 제한의 감소 필요성)

 

 

• Simula 67 : 강력한 추상화 기법을 제공
  
  
• Algol 68 : 일반성, 직교성을 제공하여 언어의 복잡성이 감소됨

 

1970년대 ~ 1980년대 초

 

simplicity(간결성)과 abstraction(추상화)를 강조함

 

=> Pascal, C, Euclid, Modula-2, Ada 등

 

언어 구성에 "수학적 정의"를 도입하였고 프로그램의 정확성 증명 기법을 갖춘 언어를 제공

 

=> 프로그램 신뢰성 증가

 

1980년대

 

언어에 "논리 또는 수학 개념"을 삽입하였고 논리를 프로그래밍 언어 자체에 포함

 

함수형 언어에 관심을 갖고 ML, Miranda, Scheme 같은 언어들이 탄생하게됨

 

객체 지향 언어에 관심 또한 증가하여 C++이 나오게됨

 

 

 

 

3.2 효율성

 

효율성의 기존에 따른 분류

 

• 목적 코드의 효율성
  
  번역기의 효율적 실행 코드 생성 -> 최적화
  
  => Pascal에서 상수는 수식으로 표현되지 않음
  (상수 식별자는 번역 과정에서 계산된 값으로 대체)

const size = 2 * 3 + 1; 

Pascal에서는 이걸 그대로 수식으로 들고 가는 게 아니라, 컴파일(번역)할 때 2 * 3 + 1을 미리 계산해서 코드 상에 그냥 size = 7처럼 숫자 값으로 바꿔버림

 

• 번역의 효율성 
  
  => 컴파일러의 속도 측면
  
  적절한 크기의 번역기로 빠르게 번역할 수 있는 것으로 언어 번역의 단계 구성 문제를 보면
  
  Pascal은 단일 패스로 코드 한 번 훑으면서 기계어로 바꾸고 Modula-2는 2패스로 2번째에서 기계어로 바뀜
  
  
  
• 구현의 효율성
  
  => 컴파일러를 만들기 쉬우면 구현의 효율성이 좋은거임
  (번역기의 효율적인 구현 문제)
  
  Algol 60의 경우 번역기 구현이 어렵거나 번역 수행 알고리즘이 충분이 이해되지 않아 성공하지 못했음
  
  
  

Lisp, Pascal  ->  쉬움

PL/I, Ada, Algol  -> 어려움

 

• 프로그래밍 효율성
  
  => "어떤 언어를 사용해야 더 빠르게 개발할 수 있을까?" 에 대한 내용
  
  (프로그램 작성의 단순성, 용이성 문제로 언어의 표현성, 추상화와 관련됨)
  
  Lisp, Prolog 등이 이상적인 언어임

 

비용 문제

 

• 개발 비용
  
  => switch 문이 있고 없고 등의 문제 (if문 노가다)
  
  
• 디버깅/유지보수 비용
  
  => 기능 수정/추가 할 때의 비용으로 이게 중요한 문제가 되어서 객체지향언어가 탄생하게 됨
• 구현 및 실행 비용

 

3.3 일반성, 직교성, 획일성

 

일반성 (generality)

 

특별한 경우를 피하고, 밀접하게 관련 있는 여러 개념들을 일반적인 하나의 개념으로 통합하여 얻는 성질

 

일반성이 부족한 예

 

함수, 프로시저, 서브루틴을 부 프로그램이라고 하는데 (언어마다 정의가 다름)

서브루틴의 경우는 return 값이 없음 
=> C언어에서는 그냥 함수라고 함 (void)

 

• 프로시저
  
  => 함수도 하나의 타입 (class도 타입임) 으로 일반성에 충실한 언어는 함수의 매개변수로 함수의 이름을 전달할 수 있음
  
  
  • Pascal : 프로시저 선언과 매개변수 허용, 프로시저형 변수 불허
    
    
  • Modula-2 : 일반성에 충실한 언어
    
    
  • Ada : 매개 변수에 프로시저 사용 못함
    
    
• 배열
  
  => 일반성에 충실한 언어는 가변배열을 허용함
  
  
  • Pascal : 가변 배열 불허
    
    
  • C, Ada : 가변 배열 허용
    
    
  • Modula-2, Fortran : 가변 배열 전달 능력, 가변 배열 선언 불허
    
    
• 동등 연산자, 배정 연산자(=, :=)
  
  
  • 대부분 언어 : 배열, 레코드에 적용 불허
    
    
  • Ada : 배열, 레코드에 적용 허용
    
    
• 매개 변수
  
  
  • Fortran : call by reference(주소 전달 기법) 만 허용 
    
    
  • Algol68, C, Java : call by value 기반이지만 객체에 대한 포인터를 값으로 전달하여 call by reference를 우회적으로 제공함
    (Java는 진짜 포인터는 없지만 객체를 참조로 넘김)
    
    => 일반성 제공
    
    
  • Ada : 일반성 제공
    
    
• 상수
  
  
  • Fortran : 상수 이름 부재
    
    => 어떤 의미 있는 값인데도 이름 없이 숫자 그대로 코드에 박아 넣는 매직 넘버가 많음
    
    
  • Pascal : 상수 표현에 수식 사용 불가 
    
    (int a [100] 과 int a [2 * 50] 을 생각해보면 됨)
    
    
  • Ada : 일반성 갖춘 상수 제공

 

일반성이 갖는 문제점

 

• 언어의 간결성 저하
  
  
• 언어의 판독성 저하
  
  
• 언어의 신뢰성 저하
  
  

C언어의 포인터(일반성 제공) - 문제점 제기

 

Java는 포인터 불허해서 신뢰성과 판독성 문제를 해결함

Pascal은 포인터를 제한적으로 사용하여 aliasing(이명)과 위험을 줄임

=> aliasing이란 같은 메모리 주소를 서로 다른 변수로 접근할 수 있는 상황임
(2개 이상의 포인터가 같은 메모리 위치를 가리키는 것)

포인터로 할 수 있는 것들이 많지만 권한을 너무 많이 줘서 악용되는 경우가 있음
(원래 OS가 프로그램이 돌아가는 공간 말고 다른곳에 접근하면 막거나 프로그램이 죽어버리는데 C는 그게 가능함)

=> 운영체제에서 할당 받은 주소 말고 그냥 특정 주소를 건드릴 수 있기에 다른 언어들부터는 그 기능을 막음

 

직교성 (orthogonality)

 

언어의 구성자들이 각각의 의미를 가진 채 결합하는 성질

 

=> 구성자간의 상호작용 또는 문맥의 사용이 예상 밖의 행위를 야기하지 않아야함

비직교성 : 문맥에 의존하는 제한

비일반성 : 문맥과 관계없는 제한

 

 

직교성이 부족한 예

 

• 함수 반환값
  
  자료형에 따른 허용 여부임
  
  
  • Pascal : 스칼라형, 포인터형만 허용
    
    
  • C : 배열형만 제외
    
    
  • Ada : 완벽한 직교성 제공 (모든 자료형 허용)
    
    => 컴파일러 사이즈와 실행 속도가 증가하여 만들기 어려워짐
    
    
• 화일
  
  
  • Pascal : 화일형은 특별한 상태 취급
    
    => 화일을 프로시저 매개 변수로 전달 금지, 화일 변수는 배정 금지
    
    
  • 대부분 언어 : 화일을 라이브러리로 취급 (비직교성 탈피)
    
    => C언어는 파일 타입이 있음 (간결한 언어로 볼 수 있음)
    
    
• 문자열
  
  
  • Modula-2 :  문자열 assignment (작은 문자열 -> 더 큰 문자열 로 배정 가능함)
    
    => 크기가 다른 객체에 대한 유일한 배정
    (일반적으로 다른 타입이나 크기의 객체 간에는 배정이 안되는데 Modula-2에서 문자열에만 특별히 허용함)
    
    => 대부분 객체끼리는 크기가 다르면 배정 안되는데, 문자열만 예외로 허용하니까 비직교적임 
    
    
    
• 매개변수 전달 기법
  
  
  • C : 배열은 call by reference, 기타 자료형은 call by value
    
    => 비직교성
    
    
  • Ada : 모든 자료형에 call by value, result, value-result 허용
    
    => 직교성 (타입에 관계없이 기능 일관 적용)
    
    

Algol 68의 중요 설계 목표가 직교성 보장이었음

 

획일성 (uniformity)

 

언어 구조들의 외형과 행동에서의 조화에 중점을 두는 것으로 유사한 것들은 유사하게 보이고 유사한 의미를 갖게 함

=> 상이한 것들은 서로 다르게 보이고 서로 다르게 행동하는 성질
(문장 여러개를 하나로 간주할 때)

C언어에서 곱셈 * 과 포인터 * 이 획일성에 어긋난다고 볼 수 있음

 

획일성이 부족한 비조화의 예 (Pascal)

 

 

 

• if문, while문 : begin-end 구조 요구
  
  repeat 문 : begin-end 구조 비요구
  
  
  
• 가변 레코드에서 case문, case 제어문
  
  가변 레코드 안에서 조건에 따라 다른 필드 집합을 가질 수 있게 만드는 case문과 일반적인 분기문인 case 제어문이 있는데
  같은 case 키워드를 사용하지만 구문이 상이함 (용도도 다르고 문법도 다름)
  
  => Modula-2에서 해결함
  
  
  
• 함수 값의 반환 방법

배정문 vs return문

 

=> 함수 값을 반환할 때 return이 아닌 배정문으로 반환하는데, 일반적인 변수 대입과 형태는 같지만 의미가 전혀 다르기에 의미 전달이 불명확함

 

• ^ : 포인터 선언 (^integer)과 포인터 값(x^)에 공용
  
  => 획일성 X
  
  (Modula-2는 POINTER TO로 해결)
  
  
  

 

• 세미콜론(;) : Modula-2, Pascal 에서 문장 구분자와 선언 종결자로 사용
  (C언어는 종결자로만 사용)

 

비획일성은 특별한 문맥에서만 발생되고 구성자들간의 상호작용으로 볼 수 있으므로 비직교성으로 간주될 수 도 있음!

 

 

3.4 프로그래밍 언어의 기타 설계 원칙

 

 

간결성 (simplicity)

• Pascal의 주된 설계 원칙은 간결성
  
  
• 직교성, 일반성, 획일성 -> 간결성 보장 못함
  
  ex. Algol 68
  
  
• 구성자의 수가 적다고 언어가 간결한 것은 아님
  
  ex. Lisp, Prolog
  
  => 적은 수의 구성자를 가지나 복잡한 실행시간과 시스템에 의존적
  
  
• 과다한 단순성은 알고리즘 작성을 방해하고 표현력이 부족하다는 단점이 있음

 

표현력 (expressiveness)

 

• 복잡한 과정이나 구조를 표현하는데 용이함을 의미
  
  => C언어 반복문(for, while, do~while), 조건문(if~else문, switch문)
  
  
• 표현력은 강하나 단순하지 않은 언어들로는 Lisp, Prolog, Algol 68이 있음
  
  
• 간결한 표현력
  
  => C언어에서의 while(*s++ == *t++); 과 같은 문자열 복사

 

정확성 (preciseness)

 

• 언어에 대한 정확한 정의
  
  => 언어의 행위가 예측 가능해지므로 언어의 신뢰도, 번역기의 신뢰도에 영향을 미침
  
  (C언어의 if문에서 else 모호성 문제 -> else는 가장 가까운 이전의 if에 묶인다고 명시적으로 규정)
  
  
  

기계 독립성 (machine independence)

 

• 기계 독립적인 언어 정의 (호환성 제공)
  
  
• 기억장소 할당과 기계 구조와 별개로 정의된 자료형
  
  => Pascal의 MAXINT, Go의 int8/int16/int32 는 어떤 기계에서나 항상 같은 값임
  
  (C에서는 기계구조에 따라 int형의 bit가 다름 -> 기계 의존적)

 

안전성 (security, reliability)

 

• 프로그래밍 오류 최소화, 오류 발견 용이한 언어
  
  
• 언어의 신뢰성과 정확성에 밀접한 관계
  
  
• 언어 설계 시 자료형, 형 검사, 변수 선언을 도입
  
  

C언어는 weakly typed language

 

• Strong-typed language (강 타입 언어)
  
  => Java 이후로 대부분 언어가 이에 속하는데 컴파일러가 타입을 엄격하게 검사함

 

기존 표기나 규칙과의 일관성

 

• 언어 설계 시 표준화된 특성과 개념을 갖도록 해야 함
  
  
• Algol 68은 표준화된 표기를 잘 따르지 않은 언어임
  
  ex. type 대신 mode 사용

 

Fortran은 공백에 민감하지 않은 언어라 버그 유발 가능성이 매우 컸음

 

 

확장성 (extensibility)

 

• 사용자가 언어의 특성을 쉽게 부가하도록 허용하는 기법
  
  
• Lisp은 확장성을 가진 언어임 (함수형 언어)
  
  
• 명령형 언어는 함수형 언어보다 언어 확장이 어려움
  
  
• 추상화 개념 (자료 추상화, 제어 추상화)은 확장성 지원

 

Go, Rust, Scala 등의 최신 언어는 고차원함수를 지원함

 

 

제약성 (restrictability), 부분성 (subset)

 

• 일부의 언어 지식과 언어 구조만 가지고도 효과적인 프로그램 작성 가능
  
  
• 언어 제한성의 장점
  
  
  • 프로그래머는 언어의 효과적인 사용을 위해 언어 전체를 배울 필요 업음
    
    
  • 번역기 작성자가 언어 일부분 만을 선택하여 구현, 사용 가능 (부분 언어 지원)
    
    => SP/1, SP/2 ... SP/k : PL/I의 부분 언어들
    
    

PL/I는 IBM에서 만든 강력하지만 너무 방대한 언어임

그래서 IBM은 PL/I 전체를 바로 다 구현하지 않고, SP/1 → SP/2 → ... → SP/k로 나눠서

SP/1: 기본적인 문법, 간단한 자료형만 지원
SP/2: 조건문, 반복문 추가
SP/3: 파일 입출력, 포인터 등 추가

이런 구조를 통해 컴파일러나 번역기를 단계적으로 개발하고 실험할 수 있었음

 

3.5 문제점과 해결책들

 

신뢰성 문제

 

• 프로그램 신뢰성 위해 진단 컴퍼일러(점검 컴파일러)
  
  => Cornell(대학)의 PL/I diagnostic, C 언어 환경 (debugger 포함)
  
  

효율성 문제 - 분리 컴파일

 

• 초기 고급 언어 (Fortran, Cobol ...)
  
  
  • 분리 컴파일 제공 -> 효율적 번역 가능, 오류 유발
    
    (하나의 프로그램을 여러 독립된 모듈(파일)로 나눠서 각각 따로 컴파일할 수 있게 하는 방식)
    
    => 수정한 부분만 다시 컴파일할 수 있기에 개발 속도 빠르고 라이브러리 관리가 편함
    
    => 각 모듈이 서로 어떤 타입/변수를 사용하고 있는지 컴파일 타임에 완벽히 알기 어려워서 오류가 런타임에서 발생할 수 있음
    
    
• Algol 68, Pascal은 신뢰성을 강조하며 통합 컴파일러를 사용함
  
  
  • Ada : 조화 (분리 컴파일의 장점 + 통합 컴파일의 장점)
    
    => specification part, body part 제공으로 해결
    
    (모듈을 분리하면서도, 각 모듈의 명세(spec)와 구현(body)를 구분)
    
    => spec만 보고 다른 모듈에서 사용할 수 있어서 분리 컴파일이 가능하고 spec을 기준으로 타입 검사를 하니까 신뢰성도 확보
    
    
    

최적화 컴파일러 (optimizing compiler)

 

• 효율적인 목적 코드를 위해서는 컴파일링 비용이 증가함
  
  
• 반복 수행부 등 일부분만 최적화해도 성능 향상 효과가 큼
  
  => 실제 컴파일러에서는 여러 최적화 단계를 제공함
  (결국 목적은 비효율적인 코드 없애는 것)

 

신뢰성

 

• 언어 구문의 과다한 간결성과 생략은 프로그램 판독성을 저하시킴
  
  
• 적절한 수준의 간결성은 프로그래머에게 좋은 훈련(코드 작성 능력)과 프로그램의 신뢰성을 증가
  
  =>APL, 4세대 언어(SQL, MATLAB 등)은 짧고 선언적으로 원하는 작업을 표현할 수 있음
  
  

SELECT name FROM users WHERE age > 20;

 

이런 4세대 언어인 SQL만 봐도 직접 반복문을 쓰고 조건문을 쓰지 않아도 됨

=> 코드가 짧고 추상화가 높기 때문에 실수가 줄고 정형화된 문법만 알면 안정적으로 사용할 수 있음

 

 

C.A.R Hoare의 성공적인 프로그래밍 언어 설계를 위한 충고