hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
펄
펄(영어: Perl)은 고급, 범용, 인터프리트, 동적 프로그래밍 언어이다. 펄은 공식적으로는 약어가 아니지만, "Practical Extraction and Reporting Language"를 포함하여 다양한 역두문자어가 사용된다.
펄은 1987년 래리 월이 보고서 처리를 쉽게 하기 위한 유닉스용 스크립트 언어로 개발했다. 그 이후로 많은 변경과 수정이 이루어졌다. 펄은 원래 대문자로 시작하지 않았지만, 펄 4가 출시될 무렵에는 대문자로 변경되었다. 가장 최신 버전은 1994년에 처음 출시된 펄 5이다. 2000년부터 2019년 10월까지 펄의 여섯 번째 버전이 개발 중이었고, 여섯 번째 버전의 이름은 라쿠로 변경되었다. 두 언어는 서로 아이디어를 자유롭게 빌려 오며 다른 개발 팀에 의해 독립적으로 계속 개발되고 있다.
펄은 C, sh, AWK, sed를 포함한 다른 프로그래밍 언어의 기능을 차용한다. 이는 많은 현대 유닉스 명령줄 도구의 임의적인 데이터 길이 제한 없이 텍스트 처리 기능을 제공한다. 펄은 고도로 표현력이 뛰어난 프로그래밍 언어이다. 주어진 알고리즘의 소스 코드는 짧고 압축률이 높을 수 있다.
펄
펄은 1990년대 중반 강력한 정규 표현식과 문자열 파싱 능력 덕분에 CGI 스크립팅 언어로 널리 인기를 얻었다. CGI 외에도 펄 5는 시스템 관리, 네트워크 프로그래밍, 금융, 생물정보학, 그리고 GUI와 같은 다른 응용 프로그램에도 사용된다. 유연성과 강력함 때문에 "스크립트 언어의 스위스 군용 전기톱"이라는 별명을 얻었다. 1998년에는 인터넷을 한데 묶는 덕트 테이프로도 불렸는데, 이는 글루 언어로서의 유비쿼터스 사용과 인지된 비우아함 모두를 가리킨다.
펄 이름과 로고
펄은 원래 "Pearl"이라는 이름이었다. 월은 언어에 긍정적인 의미를 가진 짧은 이름을 부여하고 싶어했다. 이는 또한 마태복음의 진주의 비유에 대한 기독교적 참조이기도 하다. 그러나 월은 펄 공식 출시 이전에 이미 PEARL이라는 언어가 존재한다는 것을 발견하고 이름에서 "a"를 뺐다.
이 이름은 때때로 역두문자어로 확장되기도 한다. Practical Extraction and Report Language와 월 자신의 Pathologically Eclectic Rubbish Lister가 펄의 매뉴얼 페이지에 있다.
펄 이름과 로고
오라일리 미디어에서 출판한 프로그래밍 펄(Programming Perl)은 표지에 단봉낙타 그림이 그려져 있어 흔히 "Camel Book"이라고 불린다. 이 이미지는 펄의 비공식적인 상징이 되었다. 오라일리는 이 이미지를 상표로 소유하고 있지만, 비상업적 사용을 허가하며, 단지 www.perl.com에 대한 승인과 링크만 요구한다. 상업적 사용에 대한 허가는 개별 사례별로 결정된다. 오라일리는 또한 비상업적 사이트를 위한 "Programming Republic of Perl" 로고와 펄을 사용하는 모든 사이트를 위한 "Powered by Perl" 버튼을 제공한다.
펄 재단은 자회사인 펄 몬저스, PerlMonks, Perl.org 등에 라이선스를 부여하는 대안적인 상징인 양파를 소유하고 있다. 이 상징은 구슬양파에 대한 비주얼 펀이다.
2024년, 새로운 낙타 로고가 언어를 위해 크리에이티브 커먼즈 라이선스와 함께 공개되었는데, 이는 책에서 파생된 마스코트와 관련된 오랜 문제를 해결한다.
펄 역사
래리 월은 1987년 유니시스의 프로그래머로 재직하면서 펄 작업을 시작했다. 1987년 12월 18일 버전 1.0을 출시했다. 월은 초기 펄을 텍스트 조작에 사용되는 기존 언어의 일부 방법에 기반을 두었다.
1988년 6월에 출시된 Perl 2는 개선된 정규 표현식 엔진을 특징으로 했다. 1989년 10월에 출시된 Perl 3은 이진 데이터 스트림 지원을 추가했다.
원래 펄에 대한 유일한 문서는 하나의 긴 매뉴얼 페이지였다. 1991년, 많은 펄 프로그래머들에게 표지 때문에 "낙타 책"으로 알려진 프로그래밍 펄(Programming Perl)이 출판되었고, 이 언어의 사실상의 참고서가 되었다. 동시에 펄 버전 번호는 4로 올라갔는데, 이는 언어의 큰 변화를 표시하기 위한 것이 아니라 책에 잘 문서화된 버전을 식별하기 위한 것이었다. Perl 4는 1991년 3월에 출시되었다.
펄 역사
펄 4는 일련의 유지보수 릴리스를 거쳤고, 1993년 Perl 4.036으로 정점에 달했으며, 이후 월은 펄 5 작업을 시작하기 위해 Perl 4를 포기했다. 펄 5의 초기 설계는 1994년까지 계속되었다. perl5-porters 메일링 리스트는 1994년 5월에 펄 5를 다른 플랫폼으로 이식하는 작업을 조율하기 위해 설립되었다. 이는 펄 5의 개발, 유지보수 및 이식을 위한 주요 포럼으로 남아 있다.
펄 5.000은 1994년 10월 17일에 출시되었다. 이는 인터프리터의 거의 완전한 재작성이었고, 객체, 참조, 렉시컬(my) 변수, 모듈을 포함한 많은 새로운 기능을 언어에 추가했다. 중요하게도, 모듈은 인터프리터를 수정하지 않고도 언어를 확장할 수 있는 메커니즘을 제공했다. 이는 일반적인 펄 프로그래머들이 새로운 언어 기능을 추가할 수 있도록 하면서도 핵심 인터프리터가 안정화될 수 있도록 했다. 펄 5는 그 이후로 활발하게 개발되고 있다.
펄 역사
펄 5.001은 1995년 3월 13일에 출시되었다. 펄 5.002는 1996년 2월 29일에 새로운 프로토타입 기능과 함께 출시되었다. 이를 통해 모듈 작성자는 펄 내장 함수처럼 작동하는 서브루틴을 만들 수 있었다. 펄 5.003은 1996년 6월 25일에 보안 릴리스로 출시되었다.
펄 5 역사에서 가장 중요한 사건 중 하나는 언어 자체 밖에서 일어났으며, 그 모듈 지원의 결과였다. 1995년 10월 26일, 종합 펄 아카이브 네트워크(CPAN)는 펄 언어 및 펄 모듈을 위한 소프트웨어 저장소로 설립되었다. 2022년 12월 기준으로, CPAN은 14,324명 이상의 저자가 작성한 43,865개 배포판에 211,850개 이상의 모듈을 포함하고 있으며, 전 세계 245개 이상의 위치에 미러링되어 있다.
펄 5.004는 1997년 5월 15일에 출시되었으며, 특히 UNIVERSAL 패키지를 포함하여 모든 클래스가 자동으로 파생되는 펄의 기본 객체와 모듈 버전을 요구하는 기능을 제공했다. 또 다른 중요한 개발은 CGI.pm 모듈의 포함이었다. 이는 펄의 CGI 스크립팅 언어로서의 인기에 기여했다.
펄 역사
펄 5.004는 마이크로소프트 윈도우, 플랜 9, QNX, 아미가OS를 지원했다.
펄 5.005는 1998년 7월 22일에 출시되었다. 이 릴리스에는 정규식 엔진에 대한 몇 가지 개선 사항, B::* 모듈을 통한 백엔드에 대한 새로운 훅, qr// 정규식 인용 연산자, 다른 새로운 핵심 모듈의 큰 선택, 그리고 BeOS를 포함한 몇 가지 운영 체제에 대한 지원이 추가되었다.
펄 5.6은 2000년 3월 22일에 출시되었다. 주요 변경 사항에는 64비트 지원, 유니코드 문자열 표현, 2GiB 이상의 파일 지원, 그리고 "our" 키워드가 포함되었다. 펄 5.6 개발 시, 다른 오픈 소스 프로젝트와 더 유사한 버전 관리 체계로 전환하기로 결정되었다. 5.005_63 이후, 다음 버전은 5.5.640이 되었으며, 개발 버전은 홀수, 안정 버전은 짝수를 가질 계획이었다.
펄 역사
2000년, 월은 커뮤니티로부터 펄의 새 버전에 대한 제안을 요청했다. 이 과정에서 361개의 RFC(Request for Comments) 문서가 생성되었고, 이는 펄 6 개발을 안내하는 데 사용될 예정이었다. 2001년에 펄 6를 위한 "Apocalypses" 작업이 시작되었는데, 이는 변경 요청을 요약하고 다음 세대 펄의 설계를 제시하기 위한 일련의 문서였다. 이 문서들은 공식 문서라기보다는 RFC의 요약본으로 제시되었다. 이때 펄 6는 언어의 설명으로만 존재했다.
펄 5.8은 2002년 7월 18일에 처음 출시되었으며, 그 이후로 매년 약 5.X 버전이 출시되었다. 펄 5.8은 유니코드 지원을 개선하고, 새로운 I/O 구현을 추가하고, 새로운 스레드 구현을 추가하고, 숫자 정확도를 개선하고, 몇 가지 새로운 모듈을 추가했다. 2013년 현재, 이 버전은 여전히 가장 인기 있는 펄 버전이었고, 레드햇 리눅스 5, 수세 리눅스 10, 솔라리스 10, HP-UX 11.31, AIX 5에서 사용되었다.
펄 역사
2004년에 "시놉시스(Synopses)" 작업이 시작되었다. 이 문서들은 원래 Apocalypses를 요약한 것이었지만, 펄 6 언어의 사양이 되었다. 2005년 2월, 탕펑은 하스켈로 작성된 펄 6 인터프리터인 Pugs 작업을 시작했다. 이는 펄 6를 현실화하려는 최초의 concerted 노력으로, 2006년에 중단되었다.
PONIE (Perl On New Internal Engine) 프로젝트는 2003년부터 2006년까지 존재했다. 이는 펄 5와 6 사이의 다리 역할을 하며, 펄 5 인터프리터를 펄 6 패럿 가상 머신에서 실행되도록 재작성하려는 노력이었다. 목표는 전 세계 수천 개 회사에 있는 수백만 줄의 펄 5 코드의 미래를 보장하는 것이었다. PONIE 프로젝트는 2006년에 종료되었으며 더 이상 활발하게 개발되지 않는다. PONIE의 일부로 펄 5 인터프리터에 대한 개선 사항 중 일부는 해당 프로젝트에 통합되었다.
펄 역사
2007년 12월 18일, 펄 1.0의 20주년에 펄 5.10.0이 출시되었다. 펄 5.10.0에는 펄 6에 더 가까워진 주목할 만한 새로운 기능들이 포함되었다. 여기에는 Switch 문(“given”/“when”으로 불림), 정규 표현식 업데이트, 스마트 매치 연산자(~~)가 포함되었다.
이 무렵, 라쿠도 펄(Rakudo Perl)이라는 또 다른 펄 6 구현 개발이 패럿 가상 머신과 함께 본격적으로 시작되었다. 2009년 11월 현재, 라쿠도 펄은 매달 정기적으로 릴리스되고 있으며, 현재는 가장 완전한 펄 6 구현이다.
펄 5 개발 프로세스의 주요 변화는 펄 5.11에서 발생했다. 개발 커뮤니티는 개발 릴리스의 월별 릴리스 주기와 안정 릴리스의 연간 일정으로 전환했다. 이 계획에 따라 버그 수정 포인트 릴리스는 3개월마다 안정 릴리스를 따르게 된다.
펄 역사
2010년 4월 12일, 펄 5.12.0이 출시되었다. 주목할 만한 핵심 개선 사항으로는 새로운 package NAME VERSION 구문, 야다 야다 연산자(아직 구현되지 않은 플레이스홀더 코드를 표시하기 위한 목적), 암묵적 엄격성, 완전한 Y2038 준수, 정규식 변환 오버로딩, DTrace 지원, 유니코드 5.2가 있다.
2011년 5월 14일, 펄 5.14가 JSON 지원을 내장하여 출시되었다.
2012년 5월 20일, 펄 5.16이 출시되었다. 주목할 만한 새로운 기능으로는 에뮬레이션할 펄 버전을 지정하는 기능이 포함되어, 사용자가 펄 버전을 업그레이드하더라도 일반적으로 호환되지 않는 이전 스크립트를 계속 실행할 수 있도록 한다. 펄 5.16은 또한 코어를 업데이트하여 유니코드 6.1을 지원한다.
2013년 5월 18일, 펄 5.18이 출시되었다. 주목할 만한 새로운 기능으로는 새로운 dtrace 훅, 렉시컬 서브, 더 많은 CORE:: 서브, 보안상의 이유로 해시의 전면적인 개편, 유니코드 6.2 지원 등이 있다.
펄 역사
2014년 5월 27일, 펄 5.20이 출시되었다. 주목할 만한 새로운 기능으로는 서브루틴 시그니처, 해시 슬라이스/새로운 슬라이스 구문, 접미사 역참조(실험적), 유니코드 6.3, 일관된 난수 생성기를 사용하는 rand() 함수 등이 있다.
일부 관찰자들은 펄 5.10의 출시를 모던 펄(Modern Perl) 운동의 시작으로 본다. 특히, 이 문구는 CPAN의 사용을 수용하고, 언어의 최근 발전을 활용하며, 고품질 코드를 생성하는 데 엄격한 개발 스타일을 설명한다. 비록 모던 펄 책이 이 아이디어의 가장 눈에 띄는 선두 주자일 수 있지만, Enlightened Perl Organization과 같은 다른 그룹들도 이 운동을 지지했다.
2012년 말과 2013년에 펄 5의 대체 구현을 위한 여러 프로젝트가 시작되었다. 라쿠도 펄(Rakudo Perl) 팀의 Perl6의 Perl5, Stevan Little 등이 만든 moe, Reini Urban의 Perl11 팀의 p2, goccy의 gperl, 그리고 윌 브래스웰(Will Braswell)이 주도하고 펄11(Perl11) 프로젝트와 제휴한 킥스타터 프로젝트인 rperl이 있었다.
펄 역사
2000년 펄 콘퍼런스에서 존 오완트(Jon Orwant)는 새로운 언어 이니셔티브의 필요성을 제기했다. 이는 펄 6라고 불릴 언어의 재설계 작업을 시작하기로 결정하는 계기가 되었다. 펄 커뮤니티 전체로부터 새로운 언어 기능에 대한 제안이 요청되었고, 300개 이상의 RFC가 제출되었다.
월은 다음 몇 년 동안 RFC를 소화하고 펄 6의 일관된 프레임워크로 통합하는 데 시간을 보냈다. 그는 프로그래밍 펄(Programming Perl)의 장에 해당하는 "아포칼립스(apocalypses)"라는 일련의 문서에서 펄 6의 설계를 제시했다. 2011년 1월 기준, 펄 6의 개발 사양은 아포칼립스에 해당하는 번호가 매겨진 "시놉시스(Synopses)"라는 설계 문서에 요약되어 있다.
브래들리 M. 쿤의 논문은 월의 감독 아래 펄의 런타임으로 자바 가상 머신을 사용할 가능성을 고려했다. 쿤의 논문은 이 접근 방식이 문제가 있음을 보여주었다. 2001년, 펄 6는 패럿이라는 크로스 언어 가상 머신에서 실행될 것이 결정되었다.
2005년, 탕펑은 하스켈로 구현된 펄 6의 Pugs 프로젝트를 만들었다. 이는 펄 6 언어의 테스트 플랫폼 역할을 했고, 계속하고 있으며(실제 구현 개발과는 별개로), 언어 설계자들이 탐구할 수 있도록 했다. Pugs 프로젝트는 리베라 챗 #raku IRC 채널을 중심으로 활발한 펄/하스켈 크로스 언어 커뮤니티를 탄생시켰다. 많은 함수형 프로그래밍적 영향이 펄 6 설계 팀에 흡수되었다.
2012년에 펄 6 개발은 주로 두 컴파일러에 집중되었다.
2013년, 주로 라쿠도를 위해 설계된 C 언어 기반 가상 머신인 MoarVM("Metamodel On A Runtime")이 발표되었다.
2019년 10월, 펄 6는 라쿠로 이름이 변경되었다.
2017년 기준 라쿠도 구현과 MoarVM만이 활발히 개발 중이며, 자바 가상 머신과 자바스크립트와 같은 다른 가상 머신도 지원된다.
2020년 6월, 펄 7이 펄 5의 후속작으로 발표되었다. Perl 7은 초기에는 펄 5.32를 기반으로 하며, 2021년 상반기에 출시될 예정이었고, 릴리스 후보는 더 빨리 출시될 예정이었다.
이 계획은 2021년 5월에 수정되었고, 출시 시기나 기반으로 사용할 펄 5 버전은 지정되지 않았다. Perl 7이 출시되면 펄 5는 장기 유지보수로 전환될 예정이었다. 그러나 지원되는 펄 5 버전은 계속해서 중요한 보안 및 버그 수정이 이루어질 것이다.
펄 7은 2020년 6월 24일 "The Perl Conference in the Cloud"에서 펄 5의 후속작으로 발표되었다. 펄 5.32를 기반으로 하는 Perl 7은 현대 펄 5 코드와 하위 호환되도록 계획되었다. 상용구(프라그마) 헤더가 없는 펄 5 코드는 호환성을 유지하기 위해 use compat::perl5;를 추가해야 하지만, 현대 코드는 일부 상용구를 생략할 수 있다.
펄 7으로 전환하려는 계획은 더 많은 논의를 불러일으켰고, 펄 운영 위원회는 Perl 7에서 기본이 될 프라그마와 모듈에 따라 작성되지 않은 스크립트와의 하위 호환성 문제를 피하기 위해 이를 취소했다. Perl 7은 개발자들이 주요 릴리스 업그레이드를 정당화할 만큼 충분한 기능을 추가할 때만 출시될 것이다.
펄 설계
월에 따르면 펄에는 두 가지 슬로건이 있다. 첫 번째는 "There's more than one way to do it(어떤 일을 하는 데는 한 가지 이상의 방법이 있다)"으로, 흔히 TMTOWTDI(팀 토디(Tim Toady)라고 발음한다)로 알려져 있다. 이 모토의 지지자들은 이 철학이 간결한 문장을 쉽게 작성할 수 있도록 한다고 주장한다.
두 번째 슬로건은 "쉬운 일은 쉬워야 하고 어려운 일은 가능해야 한다"이다.
펄의 디자인은 컴퓨터 산업의 세 가지 광범위한 트렌드에 대한 반응으로 이해될 수 있다: 하드웨어 비용 하락, 인건비 상승, 그리고 컴파일러 기술 개선. 포트란이나 C와 같은 많은 초기 컴퓨터 언어는 비싼 컴퓨터 하드웨어를 효율적으로 사용하도록 목표로 했다. 반대로, 펄은 컴퓨터 프로그래머가 프로그램을 더 빠르고 쉽게 작성할 수 있도록 설계되었다.
펄 설계
펄은 더 많은 CPU 및 메모리 요구 사항을 희생하여 프로그래머의 작업을 쉽게 해주는 많은 기능을 가지고 있다. 여기에는 자동 메모리 관리, 동적 자료형, 문자열, 리스트, 해시, 정규 표현식, 인트로스펙션, 그리고 `eval()` 함수가 포함된다. 펄은 "내장된 제한 없음" 이론을 따르는데, 이는 제로 원 무한 규칙과 유사한 아이디어이다.
월은 언어학자 출신이며, 펄의 디자인은 언어학적 원리에 크게 영향을 받았다. 예를 들어 허프먼 부호화(흔히 사용되는 구조는 짧아야 한다), 좋은 후위 중점화(중요한 정보가 먼저 와야 한다), 그리고 방대한 언어 기본 구성 요소 모음이 있다. 펄은 펄 인터프리터를 복잡하게 만들더라도 사람이 작성하기에 간결하고 자연스러운 언어 구조를 선호한다.
펄의 구문은 "다른 것은 다르게 보여야 한다"는 사상을 반영한다. 예를 들어, 스칼라, 배열, 해시는 다른 선행 시길을 갖는다. 배열 인덱스와 해시 키는 다른 종류의 괄호를 사용한다. 문자열과 정규 표현식은 다른 표준 구분자를 갖는다.
펄 설계
펄 언어와 이를 둘러싼 커뮤니티 및 문화에는 광범위한 실용적인 경향이 있다. 프로그래밍 펄(Programming Perl)의 서문은 "펄은 당신의 일을 완수하기 위한 언어이다."로 시작한다. 이의 한 결과는 펄이 깔끔한 언어가 아니라는 점이다. 이는 많은 기능을 포함하고, 규칙의 예외를 허용하며, 구문적 모호성을 해결하기 위해 휴리스틱을 사용한다. 컴파일러의 관대한 특성 때문에 버그를 찾기 어려울 때가 있다. 펄의 함수 문서는 리스트 및 스칼라 컨텍스트에서 내장 함수의 변형된 동작에 대해 "일반적으로 일관성을 원하지 않는 한, 원하는 대로 작동한다"고 언급한다.
펄의 전반적인 구조는 C에서 광범위하게 파생되었다. 펄은 본질적으로 절차적이며, 변수, 표현식, 할당문, 중괄호로 구분된 블록, 제어 구조, 서브루틴을 갖는다.
펄 설계
펄은 셸 프로그래밍의 기능도 가져왔다. 모든 변수는 선행 시길로 표시되어, 변수가 문자열에 직접 삽입될 수 있도록 한다. 그러나 셸과 달리 펄은 모든 변수 접근에 시길을 사용하며, 시길을 사용하는 대부분의 다른 프로그래밍 언어와 달리 시길은 변수의 타입을 나타내는 것이 아니라 표현식의 타입을 나타낸다. 따라서 예를 들어 배열은 시길 "@"(예: @arrayname)로 표시되지만, 배열의 개별 구성원은 스칼라 시길 "$"(예: $arrayname[3])로 표시된다. 펄에는 또한 셸 프로그래밍에서 자주 사용되는 도구(비록 이러한 도구 중 다수는 셸 외부에 있는 프로그램에 의해 구현되지만)를 제공하는 많은 내장 함수가 있다. 예를 들어 정렬 및 운영체제 기능 호출 등이 있다.
펄은 AWK에서 해시("연관 배열")를, sed에서 정규 표현식을 가져온다. 이는 많은 구문 분석, 텍스트 처리 및 데이터 관리 작업을 단순화한다. 리스프와 공유하는 특징은 블록의 마지막 값을 암시적으로 반환한다는 점이며, 모든 문은 그 자체로 더 큰 표현식에 사용될 수 있는 표현식이다.
펄 설계
펄 5는 복잡한 자료 구조, 일급 함수(즉, 값으로서의 클로저), 그리고 객체 지향 프로그래밍 모델을 지원하는 기능을 추가했다. 여기에는 참조, 패키지, 클래스 기반 메서드 디스패치, 그리고 렉시컬 스코프 변수가 포함되며, 컴파일러 지시자(예: strict 프라그마)도 함께 제공된다. 펄 5에서 도입된 주요 추가 기능은 코드를 재사용 가능한 모듈로 패키징할 수 있는 기능이었다. 월은 나중에 "펄 5 모듈 시스템의 전체 의도는 펄 코어보다는 펄 문화의 성장을 장려하는 것이었다"고 말했다.
모든 버전의 펄은 자동 데이터 형식 지정 및 자동 메모리 관리를 수행한다. 인터프리터는 프로그램의 모든 데이터 객체의 형식과 저장 요구 사항을 알고 있으며, 참조 카운팅을 사용하여 필요에 따라 저장 공간을 할당하고 해제한다(따라서 수동 개입 없이는 순환 데이터 구조를 할당 해제할 수 없다). 합법적인 형 변환—예를 들어 숫자에서 문자열로의 변환—은 런타임에 자동으로 수행되며, 불법적인 형식 변환은 치명적인 오류이다.
펄 설계
펄은 비평가들로부터 "시끄러운 코드"이자 "쓰기 전용 언어"로 불려왔다. 랜들 L. 슈왈츠는 책 러닝 펄(Learning Perl)의 초판 첫 장에서 다음과 같이 말한다. 그렇다, 때로는 펄이 초심자에게는 시끄러운 코드로 보일 수 있지만, 노련한 펄 프로그래머에게는 삶의 사명을 가진 체크섬된 시끄러운 코드로 보인다. 그는 또한 펄이 쓰기 전용 언어라는 비난은 "적절한 주의"를 기울여 코딩하면 피할 수 있다고 말했다. 펄 개요 문서 perlintro는 내장 "마법" 스칼라 변수의 이름이 "구두점 또는 시끄러운 코드처럼 보인다"고 명시한다. 그러나 English 모듈은 길고 짧은 영어 대안을 모두 제공한다. perlstyle 문서는 정규 표현식에서 시끄러운 코드를 완화하기 위해 /x 수정자를 사용하여 공백을 추가할 수 있다고 명시한다.
펄 설계
펄 6 FAQ에 따르면, 펄 6는 펄 5 비평가들로부터 "시끄러운 코드" 주장을 이끌어내는 "일반적인 용의자"들을 완화하기 위해 설계되었는데, 여기에는 "대부분의 구두점 변수" 제거와 정규식 구문의 정제가 포함된다. 펄 6 FAQ는 또한 때때로 펄의 시끄러운 코드로 언급되는 것이 영어의 동명사나 전치사처럼 "언어의 실제 구문"이라고 명시한다. 2012년 12월 블로그 게시물에서 "라쿠도 펄 6는 실패했고, 성인의 감독을 받지 않으면 계속 실패할 것"이라고 주장했음에도 불구하고, 크로매틱은 펄 6의 디자인이 "잘 정의된 문법", 개선된 타입 시스템, 지능적인 메타모델을 가진 통합 객체 시스템, 메타연산자, 그리고 광범위한 지연 평가와 같은 세부적인 사항을 제공하는 더 명확한 컨텍스트 시스템을 가지고 있다고 말했다. 그는 또한 펄 6는 펄 5에 없는 일관성과 통일성을 가지고 있다고 언급했다.
펄에서는 "Hello, World!" 프로그램을 다음과 같이 작성할 수 있다.
다음은 주어진 시작 값에서 초를 카운트다운하는 더 복잡한 펄 프로그램이다.
펄 설계
펄 인터프리터는 단발성 스크립트를 명령줄에서 실행하는 데도 사용할 수 있다. 다음 예시(sh 호환 셸, 예를 들어 배시에서 호출)는 현재 디렉터리의 .txt로 끝나는 모든 파일에서 "Bob" 문자열을 "Robert"로 번역한다.
펄 5를 포함한 펄 버전에는 명시적인 사양이나 표준이 존재하지 않으며, 현재 버전의 펄에 대해서도 그러한 계획은 없다. 인터프리터는 단 한 번만 구현되었고, 언어는 그와 함께 진화해왔다. 이 인터프리터는 기능 테스트와 함께 언어의 사실상 사양으로 존재한다. 그러나 펄 6는 사양과 함께 시작되었으며, 여러 프로젝트가 사양의 일부 또는 전체를 구현하는 것을 목표로 한다.
펄은 C로 작성된 핵심 인터프리터와 펄 및 C로 작성된 방대한 모듈 컬렉션으로 구현된다. 2010년 기준, 인터프리터는 15만 줄의 C 코드이며, 일반적인 머신 아키텍처에서 1MB 실행 파일로 컴파일된다. 또는 인터프리터를 링크 라이브러리로 컴파일하여 다른 프로그램에 임베드할 수 있다. 배포판에는 거의 500개의 모듈이 있으며, 20만 줄의 펄 코드와 추가로 35만 줄의 C 코드(모듈의 C 코드 대부분은 문자 인코딩 테이블로 구성됨)로 이루어져 있다.
펄 설계
인터프리터는 객체 지향 아키텍처를 가지고 있다. 펄 언어의 모든 요소—스칼라, 배열, 해시, 코드 참조, 파일 핸들—는 인터프리터에서 C 구조체로 표현된다. 이러한 구조체에 대한 연산은 방대한 매크로, Typedef, 함수 컬렉션으로 정의된다. 이들은 펄 C API를 구성한다. 펄 API는 초보자에게는 혼란스러울 수 있지만, 그 진입점들은 일관된 명명 규칙을 따르므로, 사용하는 사람들에게 지침을 제공한다.
펄 인터프리터의 수명은 크게 컴파일 단계와 실행 단계로 나뉜다. Abuin 외에 따르면, "펄은 단순한 렉스/야크 렉서/파서 조합으로 구문 분석될 수 없다. 대신, 인터프리터는 언어의 모호성을 해결하기 위해 수정된 GNU bison 파서와 협력하는 자체 렉서를 구현한다."
펄 설계
펄의 컴파일 단계에서 발생하는 대부분은 컴파일이며, 펄의 실행 단계에서 발생하는 대부분은 실행이지만, 상당한 예외가 있다. 펄은 컴파일 단계 동안 펄 코드를 실행하는 기능을 중요하게 사용한다. 펄은 또한 컴파일을 실행 단계로 지연시킨다. 특정 순간에 실제로 발생하는 처리 유형을 나타내는 용어는 컴파일 타임과 런타임이다. 펄은 컴파일 단계의 대부분 시점에서 컴파일 타임에 있지만, 컴파일 타임은 실행 단계에서도 진입할 수 있다. eval 내장 함수에 전달되는 문자열 인수의 코드에 대한 컴파일 타임은 실행 단계 중에 발생한다. 펄은 컴파일 단계 동안 자주 런타임에 있으며, 실행 단계의 대부분을 런타임에 보낸다. BEGIN 블록의 코드는 런타임에 실행되지만 컴파일 단계에 있다.
컴파일 시에 인터프리터는 펄 코드를 구문 트리로 구문 분석한다. 런타임 시에는 트리를 순회하여 프로그램을 실행한다. 텍스트는 한 번만 구문 분석되며, 구문 트리는 실행 전에 최적화되므로 실행이 상대적으로 효율적이다. 구문 트리에 대한 컴파일 시 최적화에는 상수 폴딩 및 컨텍스트 전파가 포함되지만, 피홀 최적화도 수행된다.
펄은 튜링 완전 문법을 가지는데, 구문 분석이 컴파일 단계에서 실행되는 런타임 코드의 영향을 받을 수 있기 때문이다. 코드는 단순한 Lex/Yacc 렉서/파서로 구문 분석될 수 없다. 언어의 모호성을 해결하기 위해 인터프리터는 수정된 GNU bison 파서와 협력하기 위해 자체 렉서를 구현해야 한다.
"오직 펄만이 펄을 구문 분석할 수 있다"는 말이 흔히 사용되지만, 이는 일반적으로 사실이 아니다. 펄 인터프리터는 컴파일 단계에서 튜링 기계를 시뮬레이션할 수 있기 때문에, 모든 경우에 구문 분석을 완료하려면 정지 문제를 결정해야 한다. 정지 문제는 결정 불가능하다는 것이 오랫동안 알려진 결과이며, 따라서 펄조차도 항상 펄을 구문 분석할 수는 없다. 펄은 컴파일 단계에서 사용자에게 전체 프로그래밍 능력을 제공하는 특이한 선택을 한다. 이론적 순수성 측면에서 비용이 많이 들지만, 실제적인 불편함은 드물어 보인다.
소스 코드 분석기 및 자동 들여쓰기 도구와 같이 펄을 구문 분석하려는 다른 프로그램은 모호한 구문 구성뿐만 아니라 일반적인 경우에 펄 구문 분석의 결정 불가능성과도 씨름해야 한다. 애덤 케네디의 PPI 프로젝트는 펄 코드를 실행 가능한 코드로 구문 분석하는 대신(이는 펄 자신조차 항상 할 수 없다), 문서로서 펄 코드를 구문 분석하는 데 중점을 두었다(문서로서의 무결성을 유지하면서). "펄 구문 분석은 '정지 문제'를 겪는다"는 가설을 처음 제기한 것은 케네디였고, 이는 나중에 증명되었다.
펄은 핵심 펄 언어에 대한 25만 개 이상의 기능 테스트와 핵심 모듈에 대한 25만 개 이상의 기능 테스트와 함께 배포된다. 이 테스트들은 일반적인 빌드 프로세스의 일부로 실행되며 인터프리터와 핵심 모듈을 광범위하게 시험한다. 펄 개발자들은 기능 테스트를 통해 인터프리터 변경이 소프트웨어 버그를 유발하지 않도록 보장한다. 또한, 시스템에서 인터프리터가 기능 테스트를 통과하는 것을 본 펄 사용자들은 제대로 작동하고 있다고 높은 수준의 확신을 가질 수 있다.
펄 포팅
펄은 아티스틱 라이선스 1.0와 GNU 일반 공중 사용 허가서에 따라 이중 라이선스를 받는다. 대부분의 운영체제에 대한 배포판이 제공된다. 특히 유닉스 및 유닉스 계열 시스템에서 널리 사용되지만, 대부분의 현대(및 많은 구식) 플랫폼으로 포팅되었다. 6가지 예외를 제외하고, 펄은 모든 POSIX 호환 또는 기타 유닉스 호환 플랫폼에서 소스 코드로부터 컴파일될 수 있다.
클래식 맥 OS 환경에 필요한 특이한 변경으로 인해, MacPerl이라는 특수 포팅이 독립적으로 배포되었다.
종합 펄 아카이브 네트워크는 각 플랫폼에서 사용 가능한 배포판 링크와 함께 지원되는 플랫폼의 전체 목록을 제공한다. CPAN은 또한 핵심 펄 배포판의 일부가 아닌 공개적으로 사용 가능한 펄 모듈의 소스이기도 하다.
펄 포팅
액티브펄(ActivePerl)은 액티브스테이트의 클로즈드 소스 배포판으로, 핵심 펄 릴리스를 추적하는 정기적인 릴리스를 제공한다. 이 배포판은 이전에 펄 패키지 관리자(PPM)를 포함했는데, 이는 일반적인 펄 모듈의 설치, 제거, 업그레이드 및 사용 관리를 위한 인기 있는 도구였다. 그러나 이 도구는 액티브펄 5.28부터 중단되었다. 또한 펄 언어를 구현하는 윈도우 스크립트 호스트(WSH) 엔진인 PerlScript도 포함되어 있다. Visual Perl은 펄을 비주얼 스튜디오 닷넷 개발 스위트에 추가하는 액티브스테이트 도구이다. 이 회사에서는 VB스크립트에서 펄로의 변환기, 윈도우용 펄 컴파일러, 그리고 AWK 및 sed에서 펄로의 변환기도 생산하여 2002년 이후 윈도우용 액티브스테이트 CD에 포함시켰으며, 이는 모든 배포판과 Komodo IDE를 포함하고 유닉스-리눅스-POSIX 변형에는 첫 번째를 제외한 모든 것이 포함된다.
펄 성능
The Computer Language Benchmarks Game은 여러 프로그래밍 언어로 된 일반적인 프로그래밍 문제 구현의 성능을 비교한다. 제출된 펄 구현은 일반적으로 메모리 사용량 측면에서 상위권에 속하며, 속도 결과는 다양하다. 벤치마크 게임에서 펄의 성능은 인터프리터 언어의 일반적인 수준이다.
큰 펄 프로그램은 컴파일된 언어의 유사한 프로그램보다 시작 속도가 느린데, 펄은 실행할 때마다 소스를 컴파일해야 하기 때문이다. YAPC::Europe 2005 콘퍼런스에서의 강연과 그 후속 기사 "A Timely Start"에서 Jean-Louis Leroy는 자신의 펄 프로그램이 예상보다 훨씬 오래 걸린다는 것을 발견했는데, 이는 펄 인터프리터가 지나치게 큰 포함 경로에서 모듈을 찾는 데 상당한 시간을 보냈기 때문이었다. 자바, 파이썬, 루비와 달리 펄은 사전 컴파일에 대한 실험적인 지원만 제공한다. 따라서 펄 프로그램은 실행할 때마다 이 오버헤드 비용을 지불한다. 일반적인 프로그램의 실행 단계는 충분히 길어서 상각 시작 시간이 상당하지 않지만, 매우 짧은 실행 시간을 측정하는 벤치마크는 이 오버헤드로 인해 왜곡될 가능성이 높다.
펄 성능
이 상황을 개선하기 위해 여러 도구가 도입되었다. 첫 번째 도구는 아파치의 mod_perl로, 작은 펄 프로그램이 빠르게 호출되는 가장 흔한 이유 중 하나인 CGI 웹 개발 문제를 해결하고자 했다. ActivePerl은 마이크로소프트 ISAPI를 통해 유사한 성능 개선을 제공한다.
펄 코드가 컴파일되면 실행 단계에서 추가적인 오버헤드가 발생하는데, 이는 일반적으로 C나 C++와 같은 컴파일된 언어로 작성된 프로그램에는 없는 것이다. 이러한 오버헤드의 예로는 바이트코드 해석, 참조 카운팅 메모리 관리, 동적 타입 검사가 있다.
가장 중요한 루틴은 다른 언어(예: C)로 작성할 수 있으며, 간단한 Inline 모듈이나 더 복잡하지만 유연한 XS 메커니즘을 통해 펄에 연결할 수 있다.
펄 응용 프로그램
펄은 다양한 응용 프로그램을 가지고 있으며, 많은 표준 및 타사 모듈의 가용성에 의해 더욱 다양해진다.
펄은 주로 CGI 스크립트를 작성하는 데 사용되었다. 펄로 작성된 대규모 프로젝트로는 CPanel, Slash, 버그질라, RT, 트위키, 무버블 타입이 있다. 펄을 광범위하게 사용하는 고트래픽 웹사이트에는 Priceline.com, 크레이그리스트, IMDb, 라이브저널, 덕덕고, 슬래시닷 및 티켓마스터가 있다. 
또한 PHP나 파이썬 대신 LAMP 기술 스택의 선택적 구성 요소이다. 펄은 데비안 리눅스 배포판에서 시스템 프로그래밍 언어로 광범위하게 사용된다.
펄은 종종 글루 언어로 사용되어, 원래 상호 운용하도록 설계되지 않은 시스템과 인터페이스를 연결하고, 데이터 정렬, 즉 보고서 작성과 같은 작업을 위해 대량의 데이터를 변환하거나 처리하는 데 사용된다. 이러한 강점은 밀접하게 연결되어 있다. 이러한 조합은 펄을 시스템 관리자를 위한 인기 있는 범용 언어로 만들며, 특히 종종 "원라이너 프로그램"이라고 불리는 짧은 프로그램을 단일 명령줄에서 입력하고 실행할 수 있기 때문이다.
펄 응용 프로그램
펄 코드는 윈도우와 유닉스 간에 이식 가능하게 만들 수 있다. 이러한 코드는 소프트웨어 공급업체(상업용 기성품(COTS) 및 맞춤형 소프트웨어 모두)가 소프트웨어 빌드 및 배포 스크립트의 패키징 및 유지보수를 단순화하는 데 자주 사용된다.
Perl/Tk 및 WxPerl은 펄 스크립트에 그래픽 사용자 인터페이스를 추가하는 데 일반적으로 사용된다.
펄 응용 프로그램
펄의 텍스트 처리 기능은 SQL 쿼리를 생성하는 데 사용될 수 있다. 배열, 해시, 자동 메모리 관리는 반환된 데이터를 수집하고 처리하는 것을 쉽게 만든다. 예를 들어, Tim Bunce의 펄 DBI API에서 API에 대한 인수는 SQL 쿼리 텍스트가 될 수 있다. 따라서 동시에 여러 언어로 프로그래밍하는 것이 가능하다(예: 히어 도큐먼트에서 HTML, 자바스크립트, SQL을 사용하여 웹 페이지를 생성하는 경우). 펄의 변수 삽입을 사용하여 각 SQL 쿼리를 프로그래밍 방식으로 사용자 정의하고, 각 SQL 쿼리에서 결과 자료 집합을 프로그래밍 방식으로 담을 구조로 펄 배열 또는 해시를 지정함으로써, 펄 서브프로그램에 의한 후처리용으로 대량의 데이터를 처리할 수 있는 고급 메커니즘을 제공한다.
펄의 초기 버전에서는 클라이언트 사이드 데이터베이스 라이브러리와 인터프리터를 다시 연결하여 데이터베이스 인터페이스를 만들었다. 이는 충분히 어려웠기 때문에 가장 중요하고 널리 사용되는 몇몇 데이터베이스에 대해서만 수행되었으며, 결과적으로 perl 실행 파일이 한 번에 하나의 데이터베이스 인터페이스만 사용하도록 제한되었다.
펄 응용 프로그램
펄 5에서 데이터베이스 인터페이스는 펄 DBI 모듈에 의해 구현된다. DBI (데이터베이스 인터페이스) 모듈은 펄 애플리케이션에 단일하고 데이터베이스 독립적인 인터페이스를 제공하는 반면, DBD (데이터베이스 드라이버) 모듈은 약 50개의 다른 데이터베이스에 접근하는 세부 사항을 처리한다. 대부분의 ANSI SQL 데이터베이스에 대한 DBD 드라이버가 있다.
DBI는 데이터베이스 핸들 및 쿼리에 대한 캐싱을 제공하여 mod_perl과 같은 장기 실행 환경에서 성능을 크게 향상시킬 수 있으며, 슬래시닷 효과와 같은 고용량 시스템이 부하 급증을 피하는 데 도움을 준다.
현대 펄 응용 프로그램, 특히 카탈리스트와 같은 웹 프레임워크를 사용하여 작성된 응용 프로그램에서는 DBI 모듈이 SQL 쿼리를 생성하고 애플리케이션 작성자에게 투명하게 데이터를 처리하는 객체 관계형 매퍼인 DBIx::Class, Class::DBI 또는 Rose::DB::Object를 통해 간접적으로 사용되는 경우가 많다.
펄 커뮤니티
펄의 문화와 커뮤니티는 언어와 함께 발전해왔다. 유즈넷은 펄이 처음 공개적으로 소개된 장소였지만, 진화 과정에서 펄 커뮤니티는 월드 와이드 웹 도입을 포함한 인터넷 기반 서비스 확장의 성장에 의해 형성되었다. 실제로 펄을 둘러싼 커뮤니티는 월의 첫 번째 "스테이트 오브 디 어니언"(State of the Onion) 연설의 주제였다.
스테이트 오브 디 어니언은 펄과 그 커뮤니티의 발전에 대한 월의 연례 기조연설 스타일 요약을 말한다. 이는 펄 문화, 더 넓은 해커 문화, 월의 언어학적 배경, 때로는 그의 가족 생활, 그리고 가끔 그의 기독교적 배경에 대한 언급을 사용하는 그의 특징적인 유머로 특징지어진다. 각 연설은 다양한 펄 콘퍼런스에서 먼저 발표된 후 온라인에도 게시된다.
펄 커뮤니티
이메일, 유즈넷, 메시지 보드 게시물에서 "Just another Perl hacker"(JAPH) 프로그램은 펄 초기 전문 트레이너 중 한 명인 랜들 L. 슈왈츠에 의해 시작된 흔한 경향이다. 펄 문화에서 펄 프로그래머는 펄 해커로 알려져 있으며, 여기서 "Just another Perl hacker, [sic]"라는 문구를 출력하는 짧은 프로그램을 작성하는 관행이 파생되었다. 원래 개념의 정신에 따라, 이 프로그램들은 적당히 난독화되어 있으며 이메일이나 유즈넷 메시지의 서명에 들어갈 만큼 짧다. 슈왈츠가 개발한 "표준" JAPH는 끝에 쉼표를 포함하지만, 이는 종종 생략되기도 한다.
펄 커뮤니티
펄 "골프"는 펄 프로그램에서 사용되는 문자(키 "스트로크")의 수를 최소한으로 줄이는 취미 활동으로, 골프 선수들이 라운드에서 가능한 한 적은 샷을 치려고 하는 것과 비슷하다. 이 용어의 첫 사용은 초보자를 가르치기 위한 평범한 코드와 숙련된 펄 프로그래머를 즐겁게 할 수 있는 간결한 해킹(예: 유즈넷 게시물 등의 서명에 이미 사용된 JAPH) 사이의 차이를 강조했다. 유사한 묘기는 이전 수십 년 동안 APL 언어에서 이름 없는 취미 활동이었다. RSA 암호화를 수행하는 프로그램을 작성하는 데 펄을 사용하면서 이 취미에 대한 광범위하고 실용적인 관심이 촉발되었다. 이후 몇 년 동안 "코드 골프"라는 용어는 다른 언어에서도 이 취미에 적용되었다. 2000년 7월 몬테레이, 캘리포니아에서 열린 Perl Conference 4.0에서 Perl Golf Apocalypse가 개최되었다.
C와 마찬가지로, 1990년대 후반에는 난독화된 코드 대회가 잘 알려진 취미 활동이었다. 난독화된 펄 대회는 1996년부터 2000년까지 더 펄 저널(The Perl Journal)이 주최한 대회로, 펄의 구문 유연성을 높이 평가했다. 상은 "가장 강력한"—공간을 효율적으로 사용하는 프로그램—과 유즈넷 서명 블록 스타일로 76자 네 줄에 맞는 프로그램에 대한 "최고의 네 줄 서명"과 같은 부문에서 수여되었다.
펄 시(Perl poetry)는 블랙 펄(Black Perl)이라는 작품처럼 합법적인 펄 코드로 컴파일될 수 있는 시를 쓰는 관행이다. 펄 시는 펄 언어에 사용되는 많은 영어 단어 덕분에 가능하다. 새로운 시는 정기적으로 PerlMonks의 커뮤니티에 제출된다.
펄 펄 디버거
2025년 기준 설치 용이성에 따른 펄 IDE/디버거 순위.
펄
펄의 다른 뜻은 다음과 같다.
영어 펄(pearl)은 진주라는 뜻이다.
사고 펄
타피오카 펄
‘펄’은 개펄의 준말이다.
김포공항역
김포공항역(金浦空港驛, Gimpo International Airport station)은 대한민국 서울특별시 강서구 방화동, 공항동에 있는 수도권 전철 5호선, 서울 지하철 9호선, 인천국제공항철도, 김포 도시철도, 수도권 전철 서해선의 환승역이다. 서울 지하철 9호선은 이 역부터 중앙보훈병원역까지 지하 구간이다. 인천국제공항철도는 굴포천 하저터널로 계양역과 연결된다. 인천국제공항철도는 이 역부터 마곡나루역까지 지하 구간이다. 김포 도시철도는 이 역부터 구래역까지 지하 구간이다. 김포 도시철도는 심야에 3편성이 주박한다. 김포 도시철도는 동부간선수로, 서부간선수로, 경인아라뱃길 하저터널로 고촌역과 연결된다. 수도권 전철 서해선은 이 역부터 신현역까지 지하 구간이다. 인천국제공항철도는 이 역부터 서울역까지 서울특별시 구간이다. 김포 도시철도는 이 역에만 서울특별시 구간이다. 수도권 전철 서해선은 이 역에만 서울특별시 구간이다.
김포국제공항의 국내선 청사와 국제선 청사의 사이에 위치한다.
김포공항역 역 구조
수도권 전철 5호선 역사는 지하 3층, 김포 도시철도와 서울 지하철 9호선, 인천국제공항철도 역사는 지하 4층 규모 지하역이다. 출구는 총 4개가 있다.
두 역사간 구조 차이로 수도권 전철 5호선 역사의 지하2층, 서울 지하철 9호선·인천국제공항철도 역사의 지하 2층이 동일 평면에 위치한다. 연결 통로는 운임 지역 밖에서 수도권 전철 5호선 지하 2층, 서울 지하철 9호선·인천국제공항철도 지하 1층을 잇는 한 곳, 운임 지역 내에서는 수도권 전철 5호선 상하행선 승강장과 서울 지하철 9호선·인천국제공항철도 지하 2층 대합실, 지하 3층 승강장을 잇는 두 곳으로 총 세 곳이 있다.
2면 2선의 곡선 상대식 승강장이 있는 지하역이며, 스크린도어가 노후화로 인하여 2018년 1월 29일부터 교체공사를 개시, 같은 해 4월 15일에 새로운 스크린도어 설치가 완료되었다. 곡선으로 휘었기 때문에, 열차와 승강장 사이가 넓으므로 승, 하차시 발이 빠지지 않도록 주의하여야 한다.
김포공항역 역 구조
두 노선은 역사 및 승강장을 공유하며, 선로가 방향별 입체교차되어 입선하기 때문에 평면 환승이 가능하다. 환승 게이트 없이 요금 정산 게이트가 붙어 있으며, 승강장에서 나갈 때를 기준으로 좌측은 인천국제공항철도, 우측은 서울 지하철 9호선의 게이트이다.
현재는 지하 3층 승강장을 중앙보훈병원·서울역 방면(상행) 승강장으로 운영하고, 지하 4층 승강장을 개화·인천공항2터미널 방면(하행) 승강장으로 운영한다.
인천국제공항철도의 경우 2단계 구간 개통 전에는 지하 3층 승강장을 일반열차 승강장으로, 지하 4층 승강장을 직통열차 승강장으로 사용하였으며, 2단계 구간 시운전 개시 이후 일반열차와 직통열차의 구분 없이 방향 별로 승강장을 사용한다.
지하 3층이 2면 3선 규모 혼합식 승강장, 지하 4층은 1면 2선 섬식 승강장이다. 지하 3층 북쪽에 위치한 9호선 승강장은 현재 사용하지 않으며, 남쪽에 있는 1면만을 9호선, 인천국제공항철도가 같이 사용한다. 9호선 급행열차는 이 역에서 시·종착한다. 두 노선 모두 스크린도어가 설치되어 있다.
2면 2선 상대식 승강장이다.승강장에는 스크린도어가 설치되어 있다.
2면 2선의 상대식 승강장이므로, 통근형 전동차를 비롯해서, KTX-이음 열차도 정차할 수 있도록 다중 슬라이드형 안전문이 설치되었다.
김포공항역 영어 역명
1996년 3월 20일 개통 당시에는 로마자 표기법 개정 전이었기 때문에 Kimp'o Int'l Airport였다. 그 후 2000년에 로마자 표기법이 개정되면서 Gimpo Int'l Airport로 바뀌었다. 그 후 2001년 3월 29일에 인천국제공항이 개항되면서 김포공항이 국내선 전용 공항으로 바뀌어 Gimpo Airport로 변경되었으나, 비즈니스를 목적으로 김포공항이 2003년 11월 30일 도쿄 하네다 국제공항 간의 국제선 업무를 다시 시작하게 되어 Gimpo Int'l Airport로 환원되었다.
김포공항역 사건 사고
2016년 10월 19일 이 역 5호선 승강장에서 하차하던 승객이 열차와 스크린도어 사이에 끼어 사망하는 사고가 발생하였다.
김포공항역 이용객 변동
9호선의 2009년 자료는 개통일인 2009년 7월 24일부터 12월 31일까지인 161일치만이, 공항철도의 2007년 자료는 개통일인 2007년 3월 23일부터 12월 31일까지인 284일치만이 반영된 것이다.
응암역
응암역(鷹岩驛, Eungam Station)은 서울특별시 은평구 역촌동과 신사동에 걸쳐 있는 서울 지하철 6호선의 지하철역이다.
신내역이나 봉화산역을 출발하여 이 역에 진입한 응암순환행 열차는 이 역에 도착하여 행선지를 신내행이나 봉화산행으로 바꾸고 단선 구간인 응암 순환 구간을 역촌역 방향으로 편도 운행하며, 이 때문에 구산동에서 불광동 방향으로 갈 때 환승역의 역할을 하고 있다. 일부 열차는 응암 순환 구간을 거친 후 이 역에 종착하기도 한다. 심야에 1편성이 주박한다.
응암역 역 구조
1면 2선의 섬식 승강장이며, 역촌역 방향 승강장은 곡선, 새절역 방향 승강장은 직선이다. 역촌동과 신사동에 걸쳐 있으며, 스크린도어가 설치되어 있다. 응암 순환 구간의 시작점으로, 역사의 형태는 전체적으로 Y자 형태를 이룬다. 출구는 4개가 있는데, 1·4번 출구는 신사동에 있고, 2·3번 출구는 역촌동에 있다.
응암역 이용객 변동
2000년 자료는 개통일인 2000년 12월 15일부터 12월 31일까지 총 17일간의 집계를 반영한 것이다.
유럽 석탄 철강 공동체
유럽 석탄 철강 공동체(-石炭鐵鋼共同體, European Coal and Steel Community, ECSC)는 6개 유럽 국가들로 이루어진 기구이며, 제2차 세계대전 이후 그들의 산업 생산을 하나의 중앙화된 기구 하에서 조절하기 위해 만들어졌다. 파리 조약 (1951년)에 의해 공식적으로 수립되었으며, 벨기에, 프랑스, 이탈리아, 룩셈부르크, 네덜란드, 서독이 체결하였다. 유럽 석탄 철강 공동체(ECSC)는 초국가주의(supranationalsim) 원리들에 기반한 최초의 국제기구였으며, 궁극적으로는 유럽 연합(EU)으로 이어지는 공식적인 통합 과정을 시작한 것이었다.
유럽 석탄 철강 공동체
유럽 석탄 철강 공동체(ECSC)는 프랑스와 독일 간의 추가 전쟁을 막기 위한 방법으로 1950년 5월 9일 프랑스의 외무장관인 로베르 쉬망에 의해 처음으로 제안되었다. 그의 목표는 "전쟁을 생각조차 할 수 없는 것일 뿐 아니라 실제로도 불가능한 것으로 만드는 것"이라고 선언했는데, 그것은 지역의 융합(regional integration)에 의해 달성되며, ECSC는 그 첫걸음이었다. 이 조약이 회원국들 간의 석탄·철강 공동 시장을 만들어내고, 특히 루르(Ruhr) 지방에서 천연 자원들에 대한 유럽 국가들 간의 경합을 상쇄하였다.
유럽 석탄 철강 공동체
네 가지 기구들이 유럽 석탄 철강 공동체(ECSC)를 감독한다: 독립적 임명자들로 구성된 고등 행정기관(High Authority), 국가의 국회의원들로 구성된 공동 의회(Common Assembly), 국가의 장관들로 구성된 특별 위원회(Special Council), 그리고 사법 재판소(Court of Justice). 이것들은 궁극적으로 오늘날의 유럽 연합 집행위원회(European Commission), 유럽의회(European Parliament), 유럽 연합 이사회(the Council of the European Union), 유럽 사법재판소(the European Court of Justice)의 윤곽을 형성할 것들이었다.
유럽 석탄 철강 공동체(ECSC)는 1957년 로마 조약 이후 설치된 공동체들, 유럽 경제 공동체(European Economic Community: EEC) 및 유럽 원자력 공동체(European Atomic Energy Community: EAEC)의 모델이 되었으며, 이 기구들과 구성원 및 일부 제도들을 공유했다. 1967년 메르거(브뤼셀) 조약은 ECSC의 모든 기관들이 유럽 경제 공동체(EEC)로 합병되도록 유도하였지만, ECSC는 자체적인 독립적인 법적 성격을 유지했다. 2002년 파리 조약이 만료되어  기구가 소멸되고, ECSC의 활동은 암스테르담과 니스 조약 체제 하에 유럽 공동체(the European Community)에 의해 완전히 흡수되었다.
유럽 석탄 철강 공동체 역사
쉬망은 총리와 외무장관으로서 프랑스 정책이 루르(Ruhr)나 사르(Saar)와 같은 독일 영토의 일부를 영구적으로 점령하거나 통제하는 드골주의(Gaullist) 정책에서 벗어나게 하는 데 중요한 역할을 했다. 극렬 과격 민족주의인 드골주의 및 공산주의의 반대에도 불구하고, 프랑스 의회는 독일을 공동체에 융합하는 새로운 정책에 찬성하는 여러 가지 결의안을 표결했다. 그 결과 루르에 대한 국제 기관(International Authority for the Ruhr: IAR)은 경질되었다.
유럽 석탄 철강 공동체 역사
ECSC의 가장 큰 업적 중에는 복지 문제에 관한 것들도 있다. 예를 들어, 일부 광산은 정부 보조금 없이는 확실히 지속될 수 없었다. 일부 광부들은 매우 열악한 주택을 가지고 있었다. 15년 동안, 노동자를 위해 아파트 당 1,770달러, 112,500개의 아파트에 자금을 지원하여,  보조금이 없었다면 구입할 수 없는 주택을 구입할 수 있게 했다. 석탄 및 철강 시설이 폐쇄되기 시작함에 따라, ECSC는 일자리를 잃은 노동자의 직업 재배치를 위한 비용의 절반을 지불했다. ECSC는 지역 재개발 원조와 합해 10만 개의 일자리를 창출하는데 1억 5천만 달러를 지출했는데, 그 중 3분의 1은 실업 석탄 및 철강 노동자를 위한 것이었다. ECSC에 의해 고안된 복지 보장은 일부 회원국들에 의해 석탄 및 철강 부문 밖의 노동자들에게도 확대되었다.