설계 기준의 중요성
•설계 목적과 사용자편의성을 확보 해야 함
•설계 목적
•어느 분야에 사용할 것인가?
•범용? DB? 그래픽? 실시간?
•사용자 편의성
•이 언어만의 문법 , 또는 같은 내용이지만 복잡하게 작성하면 안됨.
•주요 언어 성공 요인 (언어 자체보다 외적 요인)
•Fortran
•컴퓨터 제조회사 후원
•Cobol
•미 국방성 지원
•Lisp
•인공지능 분야에서 사용
•Pascal
•교육용, 마이크로컴퓨터 표준언어 역할
•PL/I
•IBM의 적극 후원
•C
•UNIX 운영체제의 성공
•Ada
•미국방성 지원
•주요 언어 설계 목적
•Fortran
•실행의 효율성
•Cobol
•기업에서의 사용이 목표
•영어와 유사한 문법 구조로 제작 -> 그냥 복잡만 해짐.
•인간의 판독성(readability)를 목표로 한 첫 언어.
•Algol 60
•블록 구조 제공으로 알고리즘 작성 용이
•Pascal
•간단한 명령형 언어, 하향식 설계(Top-Down Development)
•단계적으로 상세하게 해 나가는 설계 기법
•처음에는 시스템 전체를 고려
•이 시점에서는 각 부분의 세부사항을 고려하지 않음
•이후 각 부분들을 상세화 함
•블랙 박스와 유사함.
•내부 구조에 들어가지 않고 각 부분을 블랙 박스로서 취급함
•1950년대
•초기에는 실행의 효율성 중시
•사용자 편의성 및 범용성이 무시됨
•사용자도 한정적
•Fortran
•Cobol과 Algol 60의 등장으로 효율성보다 일반적인 원칙 중시
•Algol 60 : 블록구조, 재귀적 용법으로 논리적으로 간결 명료한 알고리즘 재현
•Cobol : 프로그램 판독성 증가(영어 유사 문법 구조)
•1960년대
•복잡성 제어(complexity control) 필요성 인식
•추상화 기법, 언어 규칙과 제한의 감소 필요성
•Simula 67 : 강력한 추상화 기법 제공
•Algol 68 : 일반성, 직교성 제공으로 언어의 복잡성 감소
•1970년대 – 80년대 초
•간결성(simplicity)과 추상화(abstraction)를 강조
•Pascal, C, Euclid, Modula-2, Ada
•언어 구성에 수학적 정의 도입
•프로그램의 정확성 증명 기법을 갖춘 언어 제공
•프로그램 신뢰성 증진
•1980년대
•언어에 논리 또는 수학 개념의 삽입 증진
•논리를 프로그래밍 언어 자체에 포함
•함수형 언어에 관심
•ML, Miranda, Scheme
•객체 지향 언어에 관심 증가
•C++
•언어 설계의 기본 원칙
•효율성 (efficiency)
•일반성 (generality)
•직교성 (orthogonality)
•획일성 (uniformity)
•기타 설계 원칙
•간결성 (simplicity)
•안전성 (security)
•표현력 (expressiveness)
•기존 표기나 규칙과의 일관성
•정확성 (preciseness)
•확장성 (extensibility)
•기계 독립성 (machine independence)
•제약성 (restrictability)
•부분성 (subset)
•효율성의 기준에 따른 분류
•목적 코드의 효율성
•실행 속도
•번역기의 효율적 실행 코드 생성 -> 최적화
•Pascal에서 상수는 수식으로 표현되지 않음
•상수 식별자는 번역 과정에서 배정된 값으로 대체
•번역의 효율성
•컴파일 속도
•적절한 크기의 번역기로 빠르게 번역할 수 있는 것
•언어 번역의 단계 구성 문제
•Pascal : 단일 패스, Modula-2 : 2 패스
•구현의 효율성
•알고리즘 구현하기 얼마나 편한가
•번역기의 효율적인 구현 문제
•Algol 60
•번역기 구현이 어렵고
•번역 수행 알고리즘이 충분히 이해되지 않아 언어가 성공하지 못함
•프로그래밍 효율성
•프로그램 작성이 얼마나 쉬운가
•프로그램 작성의 단순성, 용이성 문제
•언어의 표현성
•반복문 for문, while 문, do-while 문 등등
•추상화 메커니즘과 관련
•이상적인 언어
•Lisp, Prolog
•비용(돈) 문제
•개발비 / 디버깅 유지보수 / 구현 및 실행 비용 등
•일반성, 직교성, 획일성은 매우 밀접한 관계
•일반성
•관련 있는 여러 개념들을 일반적인 하나의 개념으로 통합하여 얻는 성질
•예외 없이!
•프로시저
•Pascal : 프로시저 선언과 매개 변수 허용, 프로시저형(type) 변수 불허
•Modula-2 : 일반성에 매우 충실함
•Ada : 매개 변수에 프로시저 사용 못함
•Int char 는 인자로 사용 가능, 근데 함수는 인자로 사용 불가능
•배열
•Pascal : 가변 배열 불허
•C, Ada : 가변 배열 허용
•Modula-2, Fortran : 가변 배열 전달능력, 가변배열 선언 불허
•동등 연산자 , 배정 연산자의 허용여부 (=, :=)
•대부분 언어 : 배열, 레코드에 적용 불허
•Ada : 배열, 레코드에 적용 허용
• 매개 변수의 전달방식
•Fortran : call by reference 만 허용
•Algol 68, C, Java : call by value, 객체에 대한 포인터를 값으로 전달 가능 -> 일반성제공
•Ada : 일반성 제공
•상수
•Fortran : 상수 이름 부재
•Pascal : 상수 표현에 수식 사용 불가 (3.14는 ok, 3+0.14 는 불가능)
•Ada : 일반성 갖춘 상수 제공
•일반성이 갖는 문제점
•언어의 간결성 저하
•언어의 판독성 저하
•언어의 신뢰성 저하
•C 언어의 포인터 일반성은 제공하지만…
•Java는 포인터 불허 : 신뢰성과 판독성 문제 해결
•Pascal에서는 이명(aliasing)과 위험을 줄이기 위해 포인터가 본질적으로 제한
•직교성
•직교 : 서로간에 독립적인 개념
•언어의 구성자들이 각각의 의미를 가진 채 조합하는 성질
•데이터 형 / 배열 /포인터 등-> 각각의 데이터 형을 써서 배열/포인터를 구축 가능
•함수 반환 값 자료형
•Pascal : 스칼라형, 포인터형만 허용
•C : 배열형만 제외
•Ada : 완벽한 직교성 제공 (모든 자료형 허용)
•파일
•파일을 데이터 타입 으로 간주하는지(파일 타입의 선언) 아니면 특별한 상태/라이브러리 간주하는지
•Pascal : 파일형은 특별한 상태 취급
•(화일을 프로시저 매개 변수로 전달 금지, 화일 변수는 배정 금지)
•기존 대부분 언어는 파일을 라이브러리로 취급 (비직교성 탈피)
•상대적으로 최신 언어들은 타입으로 간주
•문자열
•Modula-2 : 문자열 배정 (작은 문자열 -> 더 큰 문자열)
•크기가 다른 객체에 대한 유일한 배정
•매개변수 전달 기법
•C : 배열 - call by reference, 이외 모든 자료형 - call by value 방식
•Ada : 모든 자료형 - call by value, result, value-result 허용(직교성 보장)
•Algol 68의 중요 설계 목표 - 직교성 보장
•획일성
•문법 적인 부분
•유사한 것들은 유사하게 보이고
•상이한 것들은 서로 다르게 보이고 서로 다르게 행동해야 함
•if문, while 문 : begin-end 구조 요구
•repeat 문 : begin-end 구조 비 요구
•가변 레코드에서 case 문, case 제어문 : 구문 상이 (Modula-2에서 해결)
•함수 값의 반환 방법 - 배정문과 유사 (타 언어 return문 사용으로 해결)
•T/F 를 리턴하는데 함수 이름을 변수처럼 사용
•^ : 포인터 선언용 표현(C 언어에서는 *) (^integer 로 선언 )과 값을 가져올 때는 포인터 값(x^)에 로 사용
•위치가 바뀌어져 있음
•(Modula-2는 POINTER TO로 해결)
•세미콜론(;) : Modula-2, Pascal에서 문장 구분자와 선언 종결자로 사용
•C 언어에서는 종결자(마침표 역활)로만 사용
•문장의 구분자로 쓸거냐
•종결자로 쓸거냐
•비획일성은 특별한 문맥에서만 발생되고 구성자들간의 상호작용으로 볼 수 있으므로 비직교성으로 간주될 수도 있다.
•간결성 (simplicity)
•Pascal의 주된 설계 원칙은 간결성
•직교성, 일반성, 획일성 : 간결성 보장 못함
•Algol 68
•구성자의 수가 적다고 언어가 간결한 것은 아님
•Lisp, Prolog
•적은 수의 구성자를 가지나 복잡한 실행시간과 시스템에 의존적
•과다한 단순성
•언어 사용에 방해, 표현력이 부족, 많은 제한 발생
•표현력 (expressiveness)
•복잡한 과정이나 구조를 표현하는데 용이함을 의미
•C 언어의 반복문은 3 가지 형태, 조건문도 다수의 형태
•표현력은 강하나 단순하지 않은 언어 - Lisp, Prolog, Algol 68
•표현력이 강하면서 단순한 언어 - C 언어
•while ( * s++ == * t++) ;
•정확성 (preciseness)
•언어에 대한 정확한 정의 -> 언어의 행위가 예측 가능한 정의의 존재 여부
•정확한 언어 정의 -> 언어의 신뢰도, 번역기의 신뢰도에 영향
•기계 독립성 (machine independence)
•기계 독립적인 언어 정의를 통하여 보장 (호환성 제공)
•기억 장소 할당과 기계 구조와 별개로 정의된 자료형 사용
•32bit / 64bit 냐 등
•안전성 (security)
•프로그래밍 오류를 줄이고, 오류 발견 용이한 언어 목표
•언어의 신뢰성과 정확성에 밀접한 관계
•언어 설계 시 자료형, 형 검사, 변수 선언을 도입
•유사한 변수형을 혼용하게 두는가? (int 와 float 타입 덧셈을 지원하는가?)
•N : 강타입언어
•Y : 약타입 언어
•기존 표기나 규칙과의 일관성
•언어 설계 시 표준화된 특성과 개념을 갖도록 해야 함
•Algol 68 - 표준화된 표기를 잘 따르지 않은 언어
• type 대신 mode 사용
•Fortran
• "," 를 쓰면 문장 종료로 간주
• "." 를 쓰면 실수 표현으로 간주
•확장성 (extensibility)
•사용자가 언어의 특성을 쉽게 부가하도록 허용하는 기법
•확장성을 가진 언어의 예 - Lisp
•명령형 언어는 함수형 언어보다 언어 확장이 어려움
•추상화 개념(자료 추상화, 제어 추상화)은 확장성 지원
•제약성 (restrictability), 부분성 (subset)
•일부의 언어 지식과 언어 구조만 가지고도 프로그램 작성 가능한가?
•언어 제한성의 장점
•프로그래머는 언어의 효과적인 사용을 위해 언어 전체를 배울 필요 없음
•번역기 작성자가 언어 일부분 만을 선택하여 구현, 사용 가능 (부분언어 지원)
•SP/1, SP/2 … SP/k : PL/I의 부분 언어들
•신뢰성
•프로그램의 신뢰성 위해 진단 컴파일러 또는 점검 컴파일러 사용
•Cornell : PL/I diagnostic, C 언어 환경(debugger 포함)
•효율적인 번역 – 분리 컴파일
•초기 고급 언어 (Fortran, Cobol ...)
•분리 컴파일 제공 -> 효율적 번역 가능, 오류 유발
•Algol 68, Pascal(70년대 초반) : 신뢰성 강조 -> 통합 컴파일러
•Ada : 조화 (분리 컴파일의 장점 + 통합 컴파일의 장점)
•specification part, body part 제공으로 해결
•코드 최적화 (optimization)
•효율적인 목적 코드
•컴파일링 비용 증가
•반복 수행부 등 일부분만 최적화 -> 효과 큼
•실제 컴파일러 : 여러 최적화 단계 제공
•신뢰성
•언어 구문의 과다한 간결성과 생략은 프로그램 판독성을 저하
•적절한 수준의 간결성은 프로그래머에게 좋은 훈련과 프로그램의 신뢰성을 증가
•짧은 프로그램 신뢰성 증진 (APL, 4세대 언어)
•C. A. R Hoare 의 성공적인 프로그래밍 언어 설계를 위한 충고
•언어 설계
•언어의 특정한 특성(feature) 고안
•새로운 언어 설계 (기존 특성들을 선택 조합)
(1) 언어의 특정한 특성 고안
• 새 특성의 설계자는 한번에 한가지 특성에만 집중
• 잘 알려진 언어에 특성 구현
• 이미 존재하는 언어의 장점은 유지하고, 단점과 불완전성 해결, 완화
• 이 특성들이 어떻게 단순하고, 효율적으로 구현되는지 보여야 함
• 사용자 지침서 작성
• 많은 예제 프로그램들 작성 (다른 방법들과 비교 평가)
(2) 새로운 언어 설계
• 기존의 많은 특성들 : 숙지, 선택, 판단력 구비
• 특성들 사이의 불일치 제거, 중첩부분 조정 능력 요구
• 새 언어의 영역, 목적, 범위, 복잡성, 확장성에 대한 명확한 개념
• 실제 구현과 사용자 지침서(초보자용, 고급용) 제공
★ 새 언어 설계 작업은 단지 기존의 개념을 통합하는 것이다.
프로그래밍 언어에게 있어서 중요한 것
1) Readability (가독성)
2) Writability (쓰기 가능성)
3) Reliability (신뢰성)
4) Cost (비용)
728x90
'CS(Computer Science) > 프로그래밍언어' 카테고리의 다른 글
2. Algol 60 , Algol 68 (0) | 2023.04.19 |
---|---|
1. Fortran (0) | 2023.04.19 |
4. 프로그래밍 언어 구문과 구현 기법 (0) | 2023.04.07 |
2. 언어의 변천 (0) | 2023.04.07 |
1. 프로그래밍 언어론 소개 (0) | 2023.04.07 |