shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
기체 매질에서는 광선이 거의 평면파가 아니고 추가 강도를 위해 종종 초점이 맞춰지기 때문에 종종 간과되는 합병증이 있는데, 이는 위상 정합 조건에서 각 k-벡터에 추가 파이 위상 변화를 더할 수 있다. 합 주파수 구성에서는 이를 만족시키기가 매우 어렵지만 차 주파수 구성에서는 더 쉽게 만족된다(여기서 파이 위상 변화는 상쇄된다). 결과적으로 차 주파수 생성은 일반적으로 합 주파수 생성보다 더 넓은 범위에서 조정 가능하고 설정하기 쉬워, 합 주파수 생성보다 양자효율이 낮더라도 광원으로 선호된다.
모든 입력 광자가 동일한 주파수(및 파장)를 가지는 합 주파수 생성의 특수한 경우는 3차 고조파 생성(THG)이다.
축퇴 사광파 혼합.
두 구성요소만 상호작용하는 경우에도 사광파 혼합이 존재한다. 이 경우 다음 항
는 세 구성요소를 결합하여 소위 축퇴 사광파 혼합을 생성하며, 세 파동이 상호작용하는 경우와 동일한 특성을 보인다.
광섬유 통신에서 FWM의 부작용.
FWM은 파장 분할 다중 (WDM) 시스템에 영향을 미치는 광섬유 특성으로, 여러 광학 파장이 동일한 간격 또는 채널 간격으로 배치된다. FWM의 효과는 파장 채널 간격이 감소할수록 (밀집 WDM 시스템과 같이) 그리고 높은 신호 전력 수준에서 두드러진다. 높은 색 분산은 FWM 효과를 감소시키는데, 신호가 결맞음을 잃거나, 다시 말해 신호 간의 위상 불일치가 증가하기 때문이다. WDM 시스템에서 FWM이 유발하는 간섭은 채널 간 누화로 알려져 있다. FWM은 고르지 않은 채널 간격 또는 분산을 증가시키는 광섬유를 사용하여 완화할 수 있다. 세 주파수가 축퇴에 가까운 특수한 경우, 차이 주파수의 광학적 분리는 기술적으로 어려울 수 있다.
FWM은 광 위상 공액, 매개변수 증폭, 초연속체 생성, 진공 자외선 생성, 변조 전송 분광법, 및 미세 공진기 기반 주파수 빗 생성에 응용된다. 사광파 혼합 기반 매개변수 증폭기 및 발진기는 대부분의 일반적인 매개변수 발진기가 2차 비선형성을 사용하는 것과 달리 3차 비선형성을 사용한다. 이러한 고전적 응용 외에도 사광파 혼합은 양자광학 영역에서 단일 광자, 상관 광자 쌍, 짜내기 광 및 얽힌 광자 생성에 유망한 것으로 나타났다.
OTDR(optical time-domain reflectometer)은 광섬유의 특성을 파악하는 데 사용되는 광전자 장비이다. 이는 테스트 중인 케이블 또는 전송선로의 온저항을 측정하는 전자 시간 영역 반사 측정기의 광학적 등가물이다. OTDR은 일련의 광학 펄스를 테스트 중인 광섬유에 주입하고, 광섬유의 동일한 끝에서 광섬유를 따라 산란(레일리 역산란)되거나 반사되어 돌아오는 빛을 추출한다. 다시 모인 산란되거나 반사된 빛은 광섬유의 특성을 파악하는 데 사용된다. 반사 펄스의 강도는 시간의 함수로 측정되고 통합되며, 광섬유 길이의 함수로 플로팅된다.
OTDR 장비의 신뢰성 및 품질.
OTDR의 신뢰성 및 품질은 정확도, 측정 범위, 근접한 이벤트를 분해하고 측정하는 능력, 측정 속도, 다양한 환경적 극한 상황 및 다양한 유형의 물리적 남용 후에도 만족스럽게 작동하는 능력에 기반을 둔다. 이 장비는 또한 비용, 제공되는 기능, 크기, 무게 및 사용 편의성을 기준으로 평가된다.
OTDR의 품질을 명시할 때 자주 사용되는 용어 중 일부는 다음과 같다:
OTDR의 신뢰성 및 품질에 대한 산업 요구사항은 OTDR 유형 장비에 대한 일반 요구사항에 명시되어 있다.
OTDR 유사 시험 장비 유형.
일반적인 OTDR 유사 시험 장비 유형은 다음과 같다:
OTDR 데이터 형식.
1990년대 후반, OTDR 산업 대표자와 OTDR 사용자 커뮤니티는 OTDR 광섬유 데이터를 저장하고 분석하기 위한 고유한 데이터 형식을 개발했다. 이 데이터는 OTDR 유형 장비에 대한 일반 요구사항인 GR-196의 사양을 기반으로 했다. 목표는 모든 OTDR 제조업체가 구현할 수 있도록 데이터 형식이 진정으로 보편적이 되도록 하는 것이었다. OTDR 공급업체는 데이터 형식을 구현하기 위한 소프트웨어를 개발했다. 진행하면서 그들은 형식의 불일치와 사용자들 간의 오해 영역을 식별했다.
1997년부터 2000년까지 OTDR 공급업체 소프트웨어 전문가 그룹은 당시 "Bellcore" OTDR 데이터 형식이라고 불리던 문제와 불일치를 해결하려고 시도했다. OTDR 데이터 형식 사용자 그룹 (ODFUG)이라고 불리는 이 그룹은 진전을 이루었다. 그 이후로 많은 OTDR 개발자들은 다른 개발자들과 협력하여 개별 상호 작용 문제를 해결하고 제조업체 간의 교차 사용을 가능하게 했다.
2011년, Telcordia는 이 데이터 형식에 대한 산업 의견을 "OTDR 데이터 형식"이라는 단일 문서로 정리하기로 결정했다. 이 특별 보고서 (SR)는 Bellcore OTDR 데이터 형식의 상태를 요약하고, 이를 Telcordia OTDR 데이터 형식으로 이름을 변경했다.
이 데이터 형식은 추적 데이터 및 분석 정보를 저장하도록 설계된 모든 OTDR 관련 장비용이다. 초기 구현에는 기존 OTDR 추적 파일을 SR-4731 데이터 형식으로 변환하고, 이 범용 형식의 파일을 기존 OTDR에서 사용할 수 있는 형식으로 변환하기 위해 OTDR 공급업체가 제공하는 독립형 소프트웨어가 필요하다. 이 파일 변환 소프트웨어는 하드웨어 공급업체, 최종 사용자 또는 제3자가 개발할 수 있다. 이 소프트웨어는 또한 기존 장비와의 OTDR 데이터 형식의 하위 호환성을 제공한다.
SR-4731 형식은 이진 데이터를 설명한다. 여러 필드에 텍스트 정보가 포함되어 있지만, 대부분의 숫자는 16비트 (2바이트) 또는 32비트 (4바이트) 부호 있는 또는 부호 없는 정수로 이진 이미지로 저장된다. 이 파일 형식의 바이트 순서는 인텔 프로세서 기반 기기에서 흔히 볼 수 있는 명시적인 낮은 바이트 순서이다. 문자열 필드는 0바이트 “\0”으로 종료된다. OTDR 파형 데이터는 최대 전력 수준을 기준으로 1000배 한 데시벨 (dB) 단위로 시간적으로 균일하게 간격을 둔 짧고 부호 없는 정수 데이터로 표현된다. 최대 전력 수준은 0으로 설정되며, 모든 파형 데이터 포인트는 0 또는 음수(부호 비트가 암시됨)로 가정되므로, 이 형식의 최소 전력 수준은 -65.535 dB이고, 전력 수준 단계 간의 최소 해상도는 0.001 dB이다. 경우에 따라 이는 모든 파형 포인트를 나타내기에 충분한 전력 범위를 제공하지 못할 것이다. 이러한 이유로 데이터 포인트 전력 범위를 확장하기 위해 스케일 팩터 사용이 도입되었다.
해로동혈(Venus' flower basket, Euplectella aspergillum, '금성 꽃바구니')은 태평양 심해, 보통 아래 깊이에서 발견되는 유리해면의 일종이다. 다른 유리해면과 마찬가지로, 이들은 규산으로 골격을 만들며, 이 골격은 골편으로 구성된 독특한 격자 구조를 형성한다. 이 신체 구조는 광학적, 기계적 특성이 일부 면에서 인공 재료보다 우수하여 재료과학에서 큰 관심을 받고 있다. 다른 해면동물처럼, 이들은 해수를 여과하여 플랑크톤과 바다눈을 포획하여 먹이를 섭취한다. 이들의 번식 습관에 대해서는 알려진 바가 거의 없지만, 신체 구조의 유체 역학이 번식에 영향을 미칠 가능성이 있으며, 자웅동체일 수 있다는 가설이 제기되었다.
해로동혈은 1841년 리처드 오언 경에 의해 기재되었다. Euplectella 속은 이 종을 수용하기 위해 명명되었으므로, 이 종은 해당 속의 모식종이다. 오언은 이 종을 "...해양 생산물 중 가장 특이하고 아름다울 뿐만 아니라 가장 희귀한 것 중 하나..."라고 묘사했지만, 동물이 될 수 있는지조차 의문시하며 "동물계의 가장 낮은 분류"에 배치하고 알키오노이드 과로 분류했다. 그가 검토한 표본은 길이가 , 밑부분이 , 골격의 정점이 였다. 4개의 아종이 인정된다.
몸은 관 모양으로 구부러져 있으며 바구니나 꽃병 모양이다. 몸은 전적으로 규산 (유리의 주요 구성 요소)으로 구성되어 있어 일반적으로 유리해면으로 알려져 있다. 규산은 세 개의 수직 광선으로 구성되어 여섯 개의 점을 가진 육각 규질 골편 형태로 이루어져 있다. 유리해면의 경우, 골편들이 서로 "엮여" 매우 가는 그물을 형성하며, 이는 다른 해면동물 종에서는 찾아볼 수 없는 몸체의 견고성을 부여하고 유리해면이 깊은 수심에서 생존할 수 있게 한다. 몸체에는 수많은 구멍(몸체 안으로 이어지는 많은 구멍)이 뚫려 있는데, 이는 진정한 입수공이 아니라 단순한 벽의 틈이다. 해면의 구조는 사이콘형이다. 입수공은 유입관으로 연결되고, 다시 방사관을 거쳐 전입수공으로 들어가 중앙 "심방"인 해면강으로 열리며, 출수공을 통해 외부로 연결된다. 해면은 보통 에서 높이이다.
E. aspergillum은 6개의 이빨이 있는 앵커형 기부골편과 이축골편을 가지고 있는 것이 특징이다.
이 해면의 골격은 다른 생체 재료와 함께 규산 나노입자를 포함한다.
해로동혈은 필리핀 제도 근처 서태평양에서 발견된다. 이 속의 다른 종들은 일본 근처와 인도양을 포함하여 전 세계 해양에서 서식한다.
이 해면은 해저의 암석 지역에 서식하며, 평생 동안 단단한 기질에 부착되어 살고 자란다. 해수면 아래 에서 발견되며, 보다 깊은 수심에서 가장 흔하다. 더 구체적으로, 이들은 골편의 특성상 부드러운 퇴적물에 고정되는 경향이 있다.
이 해면은 종종 느슨하고 진흙 투성이의 퇴적물에 서식하는 것이 발견되며, 이로 인해 해저에 뿌리내리는 구조를 발달시킨다.
해면이 생물발광을 이용하여 플랑크톤을 유인할 것으로 추측된다.
태평양의 육방해면류는 산호초를 형성하며, 이는 심해 환경에서 탄소를 축적할 수 있다.
이 해면의 번식에 대해서는 거의 알려져 있지 않다. E. aspergillum의 한 표본에서 결합 조직 내에서 정자가 발견되었으며, 매우 가는 실 같은 부속지 내에서 응집된 덩어리로 묘사되었다. 이는 이 종이 자웅동체일 것이라는 생각에 기여할 것이다. 이 해면은 고착성이지만, 정자는 해류에 의해 운반될 수 있으며, 다른 유기체가 보유한 난자는 수정될 수 있다.
이들의 독특한 골격 구조는 해면이 겪는 항력을 줄이고 체강 내에서 일관된 소용돌이 운동을 촉진하는 데 중요한 유체 역학적 효과를 가지는 것으로 밝혀졌으며, 이는 선택적 여과 섭식과 유성 번식을 촉진하는 것으로 추정된다. 이탈리아 연구자 그룹이 수행한 연구에서, 해로동혈의 3차원 모델을 이용하여 격자 내부와 외부로의 물 분자 흐름을 시뮬레이션했다. 연구자들은 이 구조가 해면의 항력을 줄이는 동시에 해면 내부에서 미세한 소용돌이를 생성하여 정자와 난자의 혼합을 촉진한다는 것을 발견했다.
이 해면은 종종 해로새우과|유리해면 새우를 숙주로 삼는데, 보통 한 쌍이 번식하며 크기 때문에 해면 격자를 벗어날 수 없는 경우가 많다. 유리해면의 구조는 격자 안에 사는 새우에게 유리하다고 여겨지는데, 새우가 해면이 모으는 입자를 먹고 살기 때문이다. 결과적으로, 새우는 이 해면 안팎에서 살며, 죽을 때까지 해면과 상리 공생 관계를 맺는다. 새우는 해면이 제공하는 피난처에서 살고 짝짓기를 하며, 그 대가로 해면 내부를 청소하기도 한다. 이는 일본에서 이 해면의 골격이 결혼 선물로 주어지면서 해면이 변치 않는 사랑의 상징으로 채택되는 데 영향을 미쳤을 수 있다.
인류학적 응용.
해면을 해저에 부착시키는, 길이가 이고 사람의 머리카락처럼 가는 유리 섬유는 광섬유 연구자들의 관심을 끌고 있다. 해면은 해수에서 규산을 추출하여 실리카로 변환한 다음, 이를 정교한 유리 섬유 골격으로 형성한다. 주황색 공 모양 해면 (Tethya aurantium, 보통해면)과 같은 다른 종류의 해면도 생물학적으로 유리를 생산할 수 있다. 현재 광섬유 제조 공정은 고온을 필요로 하며 부서지기 쉬운 섬유를 생산한다. 해면에서 영감을 받아 이러한 섬유를 만들고 배열하는 저온 공정은 섬유의 광학적 특성에 대한 더 많은 제어를 제공할 수 있다. 이러한 나노 구조는 또한 보다 효율적이고 저렴한 태양 전지를 만드는 데 잠재적으로 유용하다. 또한, 그 골격 구조는 공학 응용 분야에서 사용되는 다른 대각선으로 보강된 정사각형 격자보다 더 높은 강도 대 중량비를 가진 새로운 유형의 구조 격자에 영감을 주었다.
이 해면의 골격은 복잡한 기하학적 구성을 가지고 있으며, 강성, 항복 강도, 최소한의 균열 전파에 대해 광범위하게 연구되어 왔다. 동일한 길이, 유효 두께 및 반경을 가지지만 균일하게 분포된 알루미늄 튜브(알루미늄과 유리는 유사한 탄성률을 가짐)는 강성이 1/100에 불과하다.
다양한 유리 해면을 대상으로 한 연구에서, 해로동혈은 접근하기 어렵기 때문에 추가 정보를 얻기 어렵다는 점이 언급되었다. 그러나 알칼리와 접촉했을 때 이 해면은 높은 저항성을 보였으며, 이는 연구자들이 이 종의 구조적 구성 요소로 작용할 수 있는 키틴과 같은 생체 재료를 잠재적으로 포함하고 있다고 믿게 만들었다. 이 연구는 E. aspergillum 및 유사 종들이 귀중한 생체 재료를 포함하는 천연 복합 재료인 한, 생체의학 및 미래 생명공학에서 중요할 수 있음을 시사한다.
라오의 생체모방 건축 연구는 해로동혈 구조에서 얻은 건축적 영감에 대해 설명하며, 특히 노먼 포스터의 런던 거킨 타워 디자인과 관련이 있다.
매체 접근 장치(MAU, media access unit) 또는 다중 스테이션 접근 장치(MAU 또는 MSAU, multistation access unit)는 토큰링 네트워크에서 스타 토폴로지로 케이블링될 때 여러 네트워크 스테이션을 링 토폴로지에 연결하는 장치로, 스테이션을 논리적 링으로 연결하기 위해 내부적으로 배선된다(일반적으로 수동, 즉 비스위치 및 비관리형, 그러나 CAU(제어형 접근 장치) 형태의 관리형 토큰링 MAU도 존재한다).
수동형 토큰링은 1997년경 IBM의 활발한 네트워킹 제품이었으나, 이후 스위치드 네트워크로 빠르게 대체되었다.
전원 없이 수동 네트워킹.
대부분의 IBM이 구현한 (실제) 수동형 토큰링 MAU는 전원 공급 없이 작동했다. 대신 수동형 MAU는 데이터가 전달될 때 자체적으로 조정되는 일련의 릴레이를 사용했다. 이것이 토큰링이 일반적으로 연결 해제되거나 고장난 포트를 종료하기 위해 릴레이를 사용한 이유이기도 하다. 전원이 필요 없는 IBM 8228 다중 스테이션 액세스 장치는 장치가 이동하여 릴레이가 잘못된 상태가 된 후 이를 재정렬하기 위해 특별한 '설정 지원' 도구가 필요하다. 이는 9V 배터리가 릴레이를 적절한 상태로 되돌리기 위해 전하를 보내는 방식으로 이루어진다. MAU가 전원 없이 작동하는 장점은 콘센트가 없는 곳에 배치할 수 있다는 점이고, 단점은 내부 릴레이가 과도한 힘을 받을 때마다 매번 초기화해야 한다는 점이다. IBM 8226 MAU는 전원 잭을 포함하고 있지만 주로 LED에 사용한다. 릴레이는 장치 내부에 여전히 사용되지만 초기화할 필요는 없다.
이 네트워킹 기술은 이론적으로 넓은 지리적 영역(총 링 둘레가 수 킬로미터)을 지원했다. 그러나 모든 스테이션이 대역폭을 공유했기 때문에 실제로는 더 작은 영역에 걸쳐 있는 개별 네트워크가 브리지를 사용하여 연결되었다. 이 브리지드 네트워크 기술은 곧 고대역폭 스위치드 네트워크로 대체되었다.
내결함성.
다중 스테이션 액세스 장치는 작동하지 않는 스테이션을 단락시키는 릴레이를 포함한다. 여러 MAU는 링 입력/링 출력 커넥터를 통해 더 큰 링으로 연결될 수 있다.
MAU는 "상자 안의 링"이라고도 불린다. 토큰링의 링을 구성했던 루프는 이제 이 장치에 통합되었다. 토큰링에서는 링의 링크가 끊어지면 전체 네트워크가 중단되지만, MAU를 사용하면 끊어진 회로가 1ms 이내에 닫히므로 링의 스테이션이 전체 네트워크를 비활성화하지 않고도 코드를 뽑을 수 있다.
카테고리 2 케이블(Category 2 cable), 또는 Cat 2는 전화 및 데이터 통신을 위해 설계된 비차폐 연선 케이블링 등급이다. Cat 2 케이블을 통한 전송에 적합한 최대 주파수는 4MHz이며, 최대 대역폭 (컴퓨팅)은 4Mbit/s이다. Cat 2 케이블은 4쌍의 전선, 즉 총 8개의 전선을 포함한다.
공식 TIA/EIA-568 표준은 Cat 3 등급 이상의 케이블에 대해서만 설정되었다. TIA/EIA가 설정한 공식 카테고리 표준은 아니지만, 카테고리 2는 원래 유통업체인 애닉스터 인터내셔널이 정의한 레벨 2 케이블에 부여된 사실상의 이름이 되었다.
애닉스터 레벨 2 케이블은 ARCnet 및 4Mbit/s 토큰링 네트워크에 자주 사용되었으며, 전화 네트워크에서도 사용되었지만 더 이상 일반적으로 사용되지 않는다.
270x는 IBM의 비프로그래밍 방식 통신 컨트롤러 제품군의 일반적인 이름으로, System/360 및 System/370 컴퓨터와 함께 사용되었다.
이 제품군은 다음 장치들로 구성되었다.
2701과 2702는 1964년 System/360과 동시에 발표되었고, 2703은 1년 뒤에 발표되었다.
270x 시리즈는 1972년 IBM 3704 및 3705 통신 컨트롤러로 대체되었다.
2701.
2701은 최대 4개의 시작-정지 또는 동기 통신 라인을 지원했다. 하나 또는 두 개의 호스트 컴퓨터에 연결하기 위한 두 개의 멀티플렉서 채널 인터페이스를 가지고 있었다. 동기 어댑터는 원래 STR(Synchronous Transmit-Receive) 프로토콜을 지원했으며, 1967년 출시된 이후에는 이진 동기 통신 (BISYNC)를 지원했다. 반이중 통신 모드에서 최대 40,800비트/초(bit/s)의 속도를 지원했다. 2701은 외부 장비를 직접 제어하기 위한 "데이터 획득 및 제어 어댑터"도 가질 수 있었다.
처음에 2701은 다음 장치들을 지원했다.
나중에 IBM 2740 및 IBM 2741 통신 터미널과 IBM 2260/2848이 추가되었다.
2702.
2702는 최대 31개의 통신 라인을 수용할 수 있었지만 2701보다 느린 속도였다. System/360 구성기에는 2702가 시작-정지 라인만 지원한다고 명시되어 있다.
처음에 2702는 다음 터미널을 지원했다.
나중에 IBM 2740 및 IBM 2741 통신 터미널, IBM 1032 디지털 시간 장치, 그리고 두 번째 채널 인터페이스가 추가되었다.
2703.
2703은 최대 176개의 반이중 시작-정지 또는 이진 동기 통신 라인을 지원했다. 한 라인의 최대 속도는 2400비트/초였지만, 총 집계 라인 속도는 제한되었다. 1970년까지 최대 라인 속도는 4800비트/초로 증가했다. 2703은 단일 멀티플렉서 채널에 연결되었으며, 각 통신 라인은 서브채널을 차지했다. 호스트 컴퓨터와의 데이터 전송을 줄이기 위해 라인당 4바이트 또는 8바이트 버퍼를 가지고 있었다. IBM 2712 원격 멀티플렉서는 최대 14개의 저속 장치를 하나의 고속 라인을 통해 2703으로 멀티플렉싱할 수 있게 했다.
1967년 기준 2703은 다음 장치들을 지원했다.
많은 회사들이 Memorex 1270(1970년 출시)과 NCR-Comten의 장치처럼 270x 컨트롤러의 클론을 생산했다.
베이스밴드 프로세서(baseband processor) 또는 베이스밴드 라디오 프로세서, BP 또는 BBP는 네트워크 인터페이스 컨트롤러 내의 장치 (칩 또는 칩의 일부)로, 모든 라디오 기능(안테나가 필요한 모든 기능)을 관리한다. 그러나 이 용어는 일반적으로 와이파이 및 블루투스 라디오를 지칭할 때 사용되지 않는다. 베이스밴드 프로세서는 일반적으로 자체 RAM 및 펌웨어를 사용한다. 베이스밴드 프로세서는 일반적으로 CMOS (상보형 금속-산화물-반도체) 또는 RF CMOS 기술을 사용하여 제조되며, 무선 주파수(RF) 및 무선 통신에서 널리 사용된다.
베이스밴드 프로세서는 일반적으로 펌웨어로 실시간 운영체제(RTOS)를 실행하며, 예를 들어 ENEA의 OSE, Nucleus RTOS (iPhone 3G/3GS/iPad), ThreadX (iPhone 4), Versatile Real-Time Executive 등이 있다. 베이스밴드 프로세서의 주요 제조업체로는 Broadcom, Icera, 인텔 모바일 커뮤니케이션즈(구 인피니언 무선 사업부), MediaTek, Qualcomm, 스프레드트럼, 그리고 ST-에릭손 등이 있다.
베이스밴드 프로세서를 메인 프로세서(애플리케이션 프로세서 또는 AP로 알려져 있음)와 분리하는 이유는 세 가지이다.
베이스밴드 프로세서에서 실행되는 소프트웨어는 일반적으로 독점적이므로 독립적인 코드 감사를 수행하는 것은 불가능하다. 일부 베이스밴드 칩을 역설계하여, 연구자들은 원격으로 휴대폰의 데이터에 접근하고 수정하는 데 사용될 수 있는 보안 취약점을 발견했다. 2014년 3월, 안드로이드 파생 운영체제인 Replicant 개발자들은 삼성 갤럭시 폰의 베이스밴드 소프트웨어에서 휴대폰에 저장된 사용자 데이터에 원격으로 접근할 수 있는 백도어 (컴퓨팅)를 발견했다고 발표했다.
리눅스 시스템에서 `initrd` (initial ramdisk, 초기 램디스크)는 임시 파일 시스템을 메모리에 로드하여 리눅스 시작 프로세스의 일부로 사용하는 방식이다. `initrd`와 `initramfs` (초기 RAM 파일 시스템에서 유래)는 이를 달성하기 위한 두 가지 다른 방법을 가리킨다. 둘 다 실제 루트 파일 시스템을 마운트하기 전에 준비 작업을 수행하는 데 일반적으로 사용된다.
많은 리눅스 배포판은 단일의 일반적인 리눅스 커널 이미지를 제공한다. 이 이미지는 배포판 개발자가 다양한 하드웨어에서 부팅되도록 특별히 생성한 것이다. 이 일반 커널 이미지의 장치 드라이버는 적재 가능 커널 모듈로 포함되는데, 많은 드라이버를 하나의 커널에 정적으로 컴파일하면 커널 이미지가 훨씬 커져서 메모리가 제한된 컴퓨터에서는 부팅하기에 너무 커질 수 있거나, 경우에 따라 존재하지 않거나 충돌하는 하드웨어를 검색하여 부팅 시 충돌 또는 기타 문제가 발생할 수 있기 때문이다. 이 정적 컴파일된 커널 방식은 또한 더 이상 사용되지 않거나 필요 없는 모듈을 커널 메모리에 남기고, 부팅 시 루트 파일 시스템을 마운트하는 데 필요한 모듈을 감지하고 로드하는 문제 또는 루트 파일 시스템이 어디에 있고 무엇인지 추론하는 문제를 발생시킨다.
더 복잡한 문제로, 루트 파일 시스템은 소프트웨어 RAID 볼륨, 논리 볼륨 관리자, 네트워크 파일 시스템 (디스크 없는 워크스테이션에서), 또는 암호화된 파티션에 있을 수 있다. 이 모든 것은 마운트하기 위해 특별한 준비가 필요하다.
또 다른 복잡한 문제는 하이버네이션에 대한 커널 지원인데, 이는 컴퓨터의 모든 메모리 내용을 스왑 파티션이나 일반 파일로 덤프한 다음 전원을 끄는 방식으로 컴퓨터를 디스크에 일시 중단시킨다. 다음 부팅 시에는 이 이미지를 메모리로 다시 로드하기 전에 액세스 가능하게 만들어야 한다.
커널에 너무 많은 특수 사례를 하드코딩하는 것을 피하기 위해, 임시 루트 파일 시스템현재는 초기 사용자 공간이라고 불리는을 사용하는 초기 부팅 단계가 사용된다. 이 루트 파일 시스템은 실제 파일 시스템을 마운트하는 데 필요한 하드웨어 감지, 모듈 로딩 및 장치 검색을 수행하는 사용자 공간 도우미를 포함할 수 있다.
이 초기 루트 파일 시스템의 디스크 이미지는 (커널 이미지와 함께) 부트로더 또는 컴퓨터의 부팅 펌웨어가 액세스할 수 있는 어딘가에 저장되어야 한다. 이것은 루트 파일 시스템 자체, 광 디스크의 부팅 이미지, 로컬 디스크의 작은 파티션(부팅 파티션, 일반적으로 ext2 또는 파일 할당 테이블 파일 시스템 사용), 또는 TFTP 서버( 이더넷에서 부팅할 수 있는 시스템에서)일 수 있다.
부트로더는 커널과 초기 루트 파일 시스템 이미지를 메모리로 로드한 다음 커널을 시작하고 이미지의 메모리 주소를 전달한다. 부팅 시퀀스 끝에서 커널은 데이터의 처음 몇 블록에서 이미지의 형식을 결정하려고 시도하며, 이는 initrd 또는 initramfs 방식으로 이어질 수 있다.
initrd 방식에서 이미지는 파일 시스템 이미지(선택적으로 압축됨)일 수 있으며, 이는 특별한 블록 장치()에서 사용할 수 있게 되어 초기 루트 파일 시스템으로 마운트된다. 해당 파일 시스템의 드라이버는 커널에 정적으로 컴파일되어야 한다. 많은 배포판은 원래 압축된 ext2 파일 시스템 이미지를 사용했지만, 다른 배포판(데비안 3.1 포함)은 cramfs 이미지가 압축 해제를 위한 추가 공간을 필요로 하지 않고 제자리에서 마운트될 수 있기 때문에 메모리가 제한된 시스템에서 부팅하기 위해 cramfs를 사용했다. 초기 루트 파일 시스템이 실행되면 커널은 를 첫 번째 프로세스로 실행한다. 종료되면 커널은 실제 루트 파일 시스템이 마운트되었다고 가정하고 를 실행하여 일반 사용자 공간 부팅 프로세스를 시작한다.
initramfs 방식(리눅스 커널 2.6.13부터 사용 가능)에서는 이미지가 cpio 아카이브(선택적으로 압축됨) 또는 그러한 아카이브의 연결일 수 있다. 아카이브는 커널에 의해 특별한 tmpfs 인스턴스로 압축 해제되어 초기 루트 파일 시스템이 된다. 이 방식은 중간 파일 시스템이나 블록 드라이버가 커널에 컴파일될 필요가 없다는 장점이 있다. 일부 시스템은 dracut 패키지를 사용하여 initramfs 이미지를 생성한다. initramfs 방식에서는 커널이 를 종료되지 않을 것으로 예상되는 첫 번째 프로세스로 실행한다. 일부 응용 프로그램의 경우 initramfs는 'casper' 유틸리티를 사용하여 unionfs를 활용하여 읽기 전용 루트 파일 시스템 이미지 위에 지속성 계층을 오버레이하는 쓰기 가능한 환경을 생성할 수 있다. 예를 들어, 오버레이 데이터는 USB 플래시 드라이브에 저장되고, 압축된 SquashFS 읽기 전용 이미지는 라이브 CD에 저장되어 루트 파일 시스템 역할을 한다.
커널에 정적으로 컴파일된 알고리즘에 따라 커널은 gzip, bzip2, LZMA, XZ, LZO, LZ4, 및 zstd로 압축된 initrd/initramfs 이미지를 압축 해제할 수 있다.
마운트 준비.
데비안과 같은 일부 리눅스 배포판은 ATA, SCSI 및 파일 시스템 커널 모듈과 같이 특정 컴퓨터를 부팅하는 데 필요한 것만 포함하는 맞춤형 initrd 이미지를 생성한다. 이러한 이미지에는 일반적으로 루트 파일 시스템의 위치와 유형이 포함되어 있다.
다른 리눅스 배포판(페도라 및 우분투 등)은 보다 일반적인 initrd 이미지를 생성한다. 이들은 루트 파일 시스템의 장치 이름(UUID 포함)으로만 시작하며 부팅 시 다른 모든 것을 찾아야 한다. 이 경우 소프트웨어는 루트 파일 시스템을 마운트하기 위해 복잡한 일련의 작업을 수행해야 한다.
일부 배포판은 이벤트 기반 핫플러그 에이전트인 udev를 사용하는데, 이는 특정 규칙과 일치하는 하드웨어 장치, 디스크 파티션 및 스토리지 볼륨이 온라인 상태가 될 때 도우미 프로그램을 호출한다. 이를 통해 검색이 병렬로 실행되고 LVM, RAID 또는 암호화의 임의 중첩으로 점진적으로 이어져 루트 파일 시스템에 도달할 수 있다.
루트 파일 시스템이 마침내 보이게 되면, 마운트된 루트 파일 시스템에서 실행할 수 없는 유지 보수 작업이 수행되고, 루트 파일 시스템은 읽기 전용으로 마운트되며, 계속 실행되어야 하는 모든 프로세스(예: 스플래시 스크린 도우미 및 해당 명령 FIFO)는 새로 마운트된 루트 파일 시스템으로 이동된다.
최종 루트 파일 시스템은 단순히 에 마운트될 수 없다. 그렇게 하면 초기 루트 파일 시스템의 스크립트와 도구가 최종 정리 작업을 위해 접근할 수 없게 되기 때문이다.
대부분의 초기 루트 파일 시스템은 또는 를 셸 스크립트로 구현하므로 최소한의 셸(일반적으로 /bin/ash)과 일부 필수 사용자 공간 유틸리티(일반적으로 비지박스 툴킷)를 포함한다. 공간을 더욱 절약하기 위해 셸, 유틸리티 및 해당 지원 라이브러리는 일반적으로 공간 최적화가 활성화된 상태(예: gcc의 "-Os" 플래그 사용)로 컴파일되고, 이 목적을 위해 특별히 작성된 최소 버전의 C 라이브러리인 klibc에 링크된다.
리눅스 배포판 설치 프로그램은 일반적으로 initramfs에서 전적으로 실행되는데, 영구 저장소가 설정되기 전에 설치 프로그램 인터페이스와 지원 도구를 호스팅할 수 있어야 하기 때문이다.
타이니 코어 리눅스 및 퍼피 리눅스는 initrd에서 전적으로 실행될 수 있다.
다른 운영 체제에서의 유사점.
Windows Vista 이후로 Windows는 WIM 디스크 이미지 파일에서 부팅할 수 있으며, 이 파일 형식은 공개되어 있다. 이는 하드 링크, 중복 제거된 청크를 지원하고 청크별 압축을 사용한다는 점을 제외하면 ZIP 형식과 유사하다. 이 경우 전체 WIM이 초기에는 RAM으로 로드된 다음 커널 초기화가 이어진다. 다음으로 로드된 WIM은 할당된 드라이브 문자와 함께 SystemRoot로 사용할 수 있다. Windows 설치 프로그램은 이를 사용하여 BOOT.WIM에서 부팅한 다음 INSTALL.WIM을 설치할 Windows 파일 모음으로 사용한다.
또한 윈도우 사전 설치 환경 (Windows PE)도 동일한 방식을 사용하며, 일부 안티바이러스 및 백업/재해 복구 소프트웨어의 별도 부팅 버전의 기반이 된다.
물리적 드라이브에 있는 WIM 또는 VHD 파일에서 항상 부팅하도록 Windows를 설치하는 것도 가능하다. 그러나 Windows 부트로더는 부팅 시 커널 모듈에 대한 .sys 파일을 직접 로드할 수 있으므로 Linux에서 initrd가 필요한 작업은 거의 사용되지 않는다.
함수형 프로그래밍에서 모나드(monad)는 계산을 일련의 단계로 구성하는 방법으로, 각 단계는 값뿐만 아니라 잠재적 실패, 비결정성 또는 부작용과 같은 계산에 대한 추가 정보를 생성한다. 더 형식적으로, 모나드는 두 가지 연산을 갖춘 형식 생성자 M이다. 는 값을 모나드 문맥으로 올리고, 는 모나드 계산을 연결한다. 간단히 말해, 모나드는 모나드를 구현하는 다양한 형식 생성자 변형(예: , 등)에 대해 함수가 추상화할 수 있도록 하는 인터페이스로 생각할 수 있다.
모나드의 개념과 용어는 원래 범주론에서 유래했으며, 여기서 모나드는 추가 구조를 갖춘 자기 함자로 정의된다. 1980년대 후반과 1990년대 초반에 시작된 연구는 모나드가 겉보기에는 서로 다른 컴퓨터 과학 문제를 통일된 함수형 모델로 통합할 수 있음을 입증했다. 범주론은 또한 모나드 법칙으로 알려진 몇 가지 형식적 요구 사항을 제공하며, 이는 모든 모나드에 의해 충족되어야 하며 모나드 코드를 검증하는 데 사용될 수 있다.
모나드는 특정 종류의 계산에 대한 의미론을 명시적으로 만들기 때문에 편리한 언어 기능을 구현하는 데 사용될 수도 있다. 하스켈과 같은 일부 언어는 일반적인 모나드 구조와 공통 인스턴스를 위한 사전 빌드된 정의를 핵심 라이브러리에 제공하기도 한다.
"모나드 codice_1의 경우, 타입 codice_2의 값은 모나드의 맥락 내에서 타입 codice_3의 값에 접근할 수 있음을 나타낸다." — C. A. McCann
더 정확히 말하면, 모나드는 시나리오에 특정한 이유로 값에 대한 무제한적인 접근이 부적절한 곳에서 사용될 수 있다. Maybe 모나드의 경우, 값이 존재하지 않을 수 있기 때문이다. IO 모나드의 경우, 값이 아직 알려지지 않았을 수 있기 때문인데, 예를 들어 모나드가 프롬프트가 표시된 후에만 제공될 사용자 입력을 나타낼 때 그렇다. 모든 경우에 접근이 의미 있는 시나리오는 모나드에 대해 정의된 bind 연산에 의해 포착된다. Maybe 모나드의 경우 값이 존재할 때만 바인딩되고, IO 모나드의 경우 시퀀스의 이전 연산이 수행된 후에만 바인딩된다.
모나드는 형식 생성자 M과 두 가지 연산을 정의하여 생성할 수 있다.
이러한 요소들을 사용하여 프로그래머는 여러 bind 연산자를 식으로 연결하여 함수 호출 시퀀스("파이프라인")를 구성한다. 각 함수 호출은 입력 일반형 값을 변환하고, bind 연산자는 반환된 모나드 값을 처리하여 시퀀스의 다음 단계로 공급한다.
일반적으로 바인드 연산자 codice_8는 매개변수로 받은 함수에는 없는 추가 계산 단계를 수행하는 모나드 고유의 코드를 포함할 수 있다. 구성된 함수 호출 쌍 사이에서 바인드 연산자는 함수 codice_11 내에서 접근할 수 없는 추가 정보를 모나드 값 codice_2에 주입하고 파이프라인을 따라 전달할 수 있다. 또한 함수를 특정 조건에서만 호출하거나 함수 호출을 특정 순서로 실행하는 등 실행 흐름을 더욱 세밀하게 제어할 수도 있다.
예시: Maybe.
모나드의 한 가지 예는 codice_21 타입이다. 정의되지 않은 null 결과는 많은 절차적 언어가 특별한 도구를 제공하지 않는 특정 문제점으로, 널 오브젝트 패턴을 사용하거나 각 연산에서 유효하지 않은 값에 대한 검사를 통해 정의되지 않은 값을 처리해야 한다. 이로 인해 버그가 발생하고 오류를 우아하게 처리하는 견고한 소프트웨어를 구축하기가 더 어려워진다. codice_21 타입은 프로그래머가 결과의 두 상태를 명시적으로 정의하여 이러한 잠재적으로 정의되지 않은 결과를 처리하도록 강제한다. 즉, codice_23 또는 codice_24이다. 예를 들어, 프로그래머는 중간 결과를 반환하거나, 파서가 감지한 조건을 알리고 프로그래머가 처리해야 하는 파서를 구축할 수 있다. 약간의 함수적 양념을 추가하면 이 codice_21 타입은 완전한 기능을 갖춘 모나드로 변환된다.
대부분의 언어에서 Maybe 모나드는 옵션 타입으로도 알려져 있는데, 이는 값이 포함되어 있는지 여부를 표시하는 타입일 뿐이다. 일반적으로 열거형의 한 형태로 표현된다. 러스트 프로그래밍 언어에서는 codice_26라고 불리며, 이 타입의 변형은 제네릭 타입 codice_27의 값이거나 빈 변형인 codice_28일 수 있다.
// &lt;T&gt;는 제네릭 타입 "T"를 나타낸다.
enum Option&lt;T&gt; {
Some(T),
None,
codice_26는 "래핑" 타입으로도 이해될 수 있으며, 이것이 모나드와의 연관성이 나타나는 지점이다. Maybe 타입을 사용하는 언어에서는 모나드 함수를 서로 구성하고 Maybe가 값을 포함하는지 여부를 테스트하는 데 도움이 되는 함수가 있다.
다음 하드코딩된 예제에서는 Maybe 타입이 실패할 수 있는 함수의 결과로 사용된다. 이 경우 0으로 나누기가 있으면 아무것도 반환하지 않는다.fn divide(x: Decimal, y: Decimal) -&gt; Option&lt;Decimal&gt; {
// divide(1.0, 4.0) -&gt; Some(0.25)를 반환
// divide(3.0, 0.0) -&gt; None을 반환Maybe가 값을 포함하는지 여부를 테스트하는 한 가지 방법은 codice_30 문을 사용하는 것이다.
let m_x = divide(3.14, 0.0); // 위에 divide 함수를 참조
// m_x가 Maybe의 Just 변형이면 if 문이 m_x에서 x를 추출한다.
if let Some(x) = m_x {
println!("answer: ", x)
println!("division failed, divide by zero error...")
다른 언어는 패턴 매칭을 가질 수 있다.
let result = divide(3.0, 2.0);
match result {
Some(x) =&gt; println!("Answer: ", x),
None =&gt; println!("division failed; we'll get 'em next time."),
모나드는 Maybe를 반환하는 함수들을 결합하여 함께 사용할 수 있다. 구체적인 예시에서는 여러 Maybe 매개변수를 받아서, 다음 예시와 같이 어떤 매개변수라도 Nothing일 경우 그 값이 Nothing인 단일 Maybe를 반환하는 함수를 가질 수 있다.
fn chainable_division(maybe_x: Option&lt;Decimal&gt;, maybe_y: Option&lt;Decimal&gt;) -&gt; Option&lt;Decimal&gt; {
match (maybe_x, maybe_y) {
(Some(x), Some(y)) =&gt; { // 두 입력 모두 Some이면 0으로 나누는지 확인하고 그에 따라 나눈다.
_ =&gt; return None // 그렇지 않으면 None을 반환
chainable_division(chainable_division(Some(2.0), Some(0.0)), Some(1.0)); // 내부 chainable_division 실패, 외부 chainable_division None 반환
codice_31 표현식을 반복하는 대신 바인드 연산자라고 불리는 것을 사용할 수 있다. (또한 "map", "flatmap", 또는 "shove"라고도 알려져 있다.). 이 연산은 모나드와 모나드를 반환하는 함수를 받아서, 전달된 모나드의 내부 값에 함수를 실행하고, 함수에서 모나드를 반환한다.
// ".map"을 사용하는 러스트 예시. maybe_x는 각각 Decimal 및 String을 반환하는 2개의 함수를 통해 전달된다.
// 일반적인 함수 합성에서와 같이 서로에게 공급되는 함수의 입력과 출력은 래핑된 타입과 일치해야 한다. (즉, add_one 함수는 Decimal을 반환해야 하며, 이는 decimal_to_string 함수로 전달될 수 있다.)
let maybe_x: Option&lt;Decimal&gt; = Some(1.0)
let maybe_result = maybe_x.map(add_one).map(decimal_to_string)
하스켈에서는 바인드 연산자 또는 (codice_8)가 함수의 합성과 유사한 보다 우아한 형태로 이러한 모나드 합성을 가능하게 한다.
halve :: Int -&gt; Maybe Int
halve x
| even x = Just (x `div` 2)
| odd x = Nothing
-- 이 코드는 x를 두 번 나눈다. x가 4의 배수가 아니면 Nothing으로 평가된다.
halve x »= halve
codice_8를 사용할 수 있게 되면서, codice_34은 익명 함수(즉, 람다)의 도움으로 훨씬 더 간결하게 표현될 수 있다. 아래 표현식에서 두 개의 중첩된 람다가 바인드 연산자를 사용하여 전달된 codice_21 모나드 안의 래핑된 값에서 각각 어떻게 작동하는지 주목하라.
chainable_division(mx,my) = mx »= ( λx -&gt; my »= (λy -&gt; Just (x / y)) )
지금까지 보여준 것은 기본적으로 모나드이지만, 더 간결하게 말하면, 다음은 다음 섹션에서 정의된 모나드에 필요한 엄격한 속성 목록이다.
이것들이 모나드를 구성하는 데 필요한 세 가지 요소이다. 다른 모나드는 다른 논리적 프로세스를 구현할 수 있으며, 일부는 추가 속성을 가질 수도 있지만, 이 세 가지 유사한 구성 요소를 모두 가질 것이다.
위 예제에서 사용된 함수형 프로그래밍에서의 모나드에 대한 보다 일반적인 정의는 사실 범주론의 표준 정의가 아닌 클라이슬리 삼중체 ⟨T, η, μ⟩에 기반한다. 그러나 두 구성은 수학적으로 동등한 것으로 판명되었으므로 어떤 정의든 유효한 모나드를 산출할 것이다. 모든 잘 정의된 기본 타입 와 가 주어졌을 때, 모나드는 세 부분으로 구성된다.
그러나 모나드로 완전히 자격을 갖추려면 이 세 부분이 몇 가지 법칙을 준수해야 한다.
대수적으로, 이는 모든 모나드가 클라이슬리 범주라고 불리는 범주와 함자(값에서 계산으로) 범주의 모노이드를 생성하며, 모나드 합성이 모노이드의 이항 연산자이고 이 모노이드의 항등원임을 의미한다.
모나드 패턴의 가치는 단순히 코드를 압축하고 수학적 추론에 대한 링크를 제공하는 것을 넘어선다.
개발자가 어떤 언어나 기본 프로그래밍 패러다임을 사용하든, 모나드 패턴을 따르면 순수 함수형 프로그래밍의 많은 이점을 얻을 수 있다.
특정 종류의 계산을 재화함으로써, 모나드는 그 계산 패턴의 지루한 세부 사항을 캡슐화할 뿐만 아니라, 선언적 방식으로 이를 수행하여 코드의 명확성을 향상시킨다.
모나드 값은 계산된 값뿐만 아니라 계산된 효과도 명시적으로 나타내기 때문에, 순수 표현식처럼 모나드 표현식은 참조 투명한 위치에서 그 값으로 대체될 수 있으며, 재작성에 기반한 많은 기술과 최적화를 가능하게 한다.
일반적으로 프로그래머는 를 사용하여 모나드 함수를 시퀀스로 연결하며, 이로 인해 일부는 모나드를 "프로그래밍 가능한 세미콜론"이라고 묘사하기도 하는데, 이는 많은 명령형 프로그래밍 언어가 세미콜론을 사용하여 명령문을 구분하는 방식을 참조한다.
그러나 모나드는 실제로 계산 순서를 정하지 않는다. 심지어 모나드를 핵심 기능으로 사용하는 언어에서도 더 간단한 함수 합성을 통해 프로그램 내의 단계를 정렬할 수 있다.
모나드의 일반적인 유용성은 추상화를 통해 프로그램의 구조를 단순화하고 관심사 분리를 개선하는 데 있다.
모나드 구조는 또한 컴파일 타임에 데코레이터 패턴에 대한 고유한 수학적 변형으로 볼 수 있다.
일부 모나드는 함수에 접근할 수 없는 추가 데이터를 전달할 수 있으며, 일부는 특정 조건에서만 함수를 호출하는 등 실행에 대한 더 세밀한 제어를 행사하기도 한다.
애플리케이션 프로그래머가 도메인 논리를 구현하면서 상용구 코드를 미리 개발된 모듈로 오프로드할 수 있게 해주기 때문에, 모나드는 관점 지향 프로그래밍을 위한 도구로도 간주될 수 있다.
모나드의 또 다른 주목할 만한 용도는 입출력 또는 가변 상태와 같은 부작용을 순수 함수형 코드에서 격리하는 것이다.
순수 함수형 언어도 모나드 없이도 이러한 "불순한" 계산을 구현할 수 있는데, 특히 복잡한 함수 합성 및 연속 전달 스타일 (CPS)의 조합을 통해서 가능하다.
그러나 모나드를 사용하면 이러한 많은 스캐폴딩을 추상화할 수 있으며, 본질적으로 CPS 코드의 각 반복 패턴을 별개의 모나드로 묶는 방식이다.
언어가 기본적으로 모나드를 지원하지 않더라도 패턴을 구현하는 것은 여전히 가능하며, 종종 큰 어려움 없이 구현할 수 있다.
범주론에서 프로그래밍 용어로 번역될 때, 모나드 구조는 제네릭 개념이며 제한된 다형성에 상응하는 기능을 지원하는 모든 언어에서 직접 정의할 수 있다.
개념이 기본 타입에서 작동하면서도 운영 세부 사항에 대해 불가지론적일 수 있는 능력은 강력하지만, 모나드의 고유한 기능과 엄격한 동작은 다른 개념과 구별된다.
특정 모나드에 대한 논의는 주어진 모나드가 특정 계산 형식을 나타내므로 좁은 구현 문제를 해결하는 데 중점을 둔다.
그러나 일부 상황에서는 애플리케이션이 핵심 논리 내에서 적절한 모나드를 사용하여 고수준 목표를 달성할 수도 있다.
다음은 디자인의 핵심에 모나드를 사용하는 몇 가지 응용 프로그램이다.
프로그래밍에서 "모나드"라는 용어는 순수 함수형 경향이 있는 APL 및 J 프로그래밍 언어에서 유래했다. 그러나 이들 언어에서 "모나드"는 단일 매개변수를 취하는 함수(두 매개변수를 취하는 함수는 "다이어드" 등으로 불림)의 약어일 뿐이다.
수학자 로제 고드망은 1950년대 후반에 모나드 개념(이를 "표준 구성"이라고 명명)을 처음으로 정립했지만, 널리 퍼지게 된 "모나드"라는 용어는 범주론자인 손더스 매클레인에 의해 대중화되었다. 그러나 위에서 를 사용하여 정의된 형태는 원래 1965년 수학자 하인리히 클라이슬리가 모든 모나드가 두 (공변) 함자 사이의 수반으로 특징지어질 수 있음을 증명하기 위해 기술했다.
1980년대부터 모나드 패턴에 대한 모호한 개념이 컴퓨터 과학 커뮤니티에서 나타나기 시작했다.
프로그래밍 언어 연구원인 필립 와들러에 따르면, 컴퓨터 과학자 존 C. 레이놀즈는 1970년대와 1980년대 초반에 연속 전달 스타일의 가치, 형식 의미론의 풍부한 원천으로서의 범주론, 그리고 값과 계산 사이의 타입 구별에 대해 논하면서 모나드의 여러 측면을 예상했다.
1990년까지 활발히 설계되었던 연구 언어 오팔도 I/O를 모나드 타입에 효과적으로 기반했지만, 당시에는 그 연결이 인식되지 않았다.
컴퓨터 과학자 유제니오 모지는 1989년 컨퍼런스 논문에서 범주론의 모나드를 함수형 프로그래밍에 명시적으로 연결한 최초의 인물이었고, 이어서 1991년에는 더욱 정교한 저널 논문을 발표했다. 이전 연구에서 여러 컴퓨터 과학자들은 람다 대수에 대한 의미론을 제공하기 위해 범주론을 사용하는 것을 발전시켰다. 모지의 핵심 통찰력은 실제 프로그램이 단순히 값에서 다른 값으로의 함수가 아니라, 그 값에 대한 계산을 형성하는 변환이라는 것이었다. 이를 범주론적 용어로 형식화하면 모나드가 이러한 계산을 나타내는 구조라는 결론에 이르게 된다.
필립 와들러와 사이먼 페이튼 존스를 포함한 다른 여러 사람들이 이 아이디어를 대중화하고 발전시켰으며, 이들 모두는 하스켈의 사양에 참여했다. 특히 하스켈은 v1.2까지 I/O를 느긋한 계산법과 조화시키기 위해 문제가 있는 "느긋한 스트림" 모델을 사용하다가, 더 유연한 모나드 인터페이스로 전환했다. 하스켈 커뮤니티는 함수형 프로그래밍의 많은 문제에 모나드를 적용했으며, 2010년대에 하스켈을 연구하는 학자들은 결국 모나드가 어플리커티브 함자라는 것을 인식했다. 그리고 모나드와 화살 모두 모노이드이다.
처음에는 모나드를 사용한 프로그래밍이 주로 하스켈과 그 파생 언어에 국한되었지만, 함수형 프로그래밍이 다른 패러다임에 영향을 미치면서 많은 언어가 모나드 패턴(이름은 아닐지라도 정신적으로)을 통합했다. 현재 스킴, 펄, 파이썬, 래킷, 클로저, 스칼라, F#에서 형식화가 존재하며, 새로운 ML 표준에 대해서도 고려되었다.
모나드 패턴의 한 가지 이점은 계산 합성에 대한 수학적 정밀성을 제공한다는 것이다.
모나드 법칙을 사용하여 인스턴스의 유효성을 확인할 수 있을 뿐만 아니라, (함자와 같은) 관련 구조의 기능도 서브타이핑을 통해 사용할 수 있다.
모나드 법칙 검증.
codice_21 예제로 돌아가서, 그 구성 요소들은 모나드를 구성한다고 선언되었지만, 모나드 법칙을 만족한다는 증명은 주어지지 않았다.
이것은 일반 법칙의 한쪽에 codice_21의 세부 사항을 대입한 다음, 대수적으로 등식의 사슬을 구성하여 다른 쪽에 도달함으로써 해결될 수 있다.
법칙 1: eta(a) »= f(x) ⇔ (Just a) »= f(x) ⇔ f(a)
법칙 2: ma »= eta(x) ⇔ ma
if ma is (Just a) then
eta(a) ⇔ Just a
else or
Nothing ⇔ Nothing
법칙 3: (ma »= f(x)) »= g(y) ⇔ ma »= (f(x) »= g(y))
if (ma »= f(x)) is (Just b) then if ma is (Just a) then
g(ma »= f(x)) (f(x) »= g(y)) a
else else
Nothing Nothing
end if end if
⇔ if ma is (Just a) and f(a) is (Just b) then
(g ∘ f) a
else if ma is (Just a) and f(a) is Nothing then
함자에서 파생.
컴퓨터 과학에서는 더 드물지만, 함자와 두 가지 추가적인 자연 변환을 가진 모나드를 직접적으로 범주론에서 정의할 수 있다.
따라서 시작하려면 구조가 map이라는 고차 함수 (또는 "함수형")를 가져야 함자의 자격을 갖춘다.
그러나 이것이 항상 큰 문제는 아니다. 특히 모나드가 기존 함자에서 파생될 경우 모나드는 을 자동으로 상속받기 때문이다. (역사적인 이유로, 이 codice_43은 하스켈에서 codice_44이라고 불린다.)
모나드의 첫 번째 변환은 사실 클라이슬리 삼중체와 동일한 이지만, 구조의 계층을 면밀히 따르면 은 모나드와 기본 함자 사이의 중간 구조인 어플리커티브 함자를 특징짓는 것으로 밝혀진다. 어플리커티브 컨텍스트에서 은 때때로 pure라고 불리지만 여전히 동일한 함수이다. 이 구성에서 다른 점은 이 만족해야 하는 법칙이다. 가 정의되지 않았으므로 제약 조건은 의 관점에서 주어진다.
어플리커티브 함자에서 모나드로의 마지막 도약은 두 번째 변환인 join 함수(범주론에서는 일반적으로 라고 불리는 자연 변환)와 함께 이루어지며, 이는 중첩된 모나드 적용을 "평탄화"한다.
특성 함수로서 또한 모나드 법칙에 대한 세 가지 변형을 만족해야 한다.
개발자가 직접 모나드를 정의하든 클라이슬리 삼중체를 정의하든, 기본 구조는 동일하며 형식은 서로 쉽게 파생될 수 있다.
또 다른 예시: List.
리스트 모나드는 더 간단한 함자에서 모나드를 파생시키는 것이 얼마나 유용한지를 자연스럽게 보여준다.
많은 언어에서 리스트 구조는 일부 기본 기능과 함께 미리 정의되어 있으므로, codice_45 형식 생성자와 연산자(중위 표기법의 경우 codice_46로 표시됨)는 여기에서 이미 주어진 것으로 가정한다.
일반 값을 리스트에 임베딩하는 것은 대부분의 언어에서 사소하다.
unit(x) = [x]
여기서부터 리스트 캄프리헨션을 사용하여 함수를 반복적으로 적용하는 것이 및 리스트를 완전한 모나드로 변환하는 쉬운 선택처럼 보일 수 있다.
이 접근 방식의 어려움은 가 모나드 함수를 기대하며, 이 경우 자체가 리스트를 출력한다는 것이다.
더 많은 함수가 적용될수록 중첩된 리스트 레이어가 축적되어 기본적인 컴프리헨션 이상이 필요하다.
그러나 전체 리스트에 간단한 함수를 적용하는 절차, 즉 은 간단하다.
(map φ) xlist = [ φ(x1), φ(x2), ..., φ(xn) ]
이제 이 두 절차는 이미 codice_45를 어플리커티브 함자로 승격시킨다.
모나드로 완전히 자격을 갖추려면 반복되는 구조를 평탄화하는 올바른 개념만 필요하지만, 리스트의 경우 이는 외부 리스트를 풀어서 값을 포함하는 내부 리스트를 추가하는 것을 의미한다.
join(xlistlist) = join([xlist1, xlist2, ..., xlistn])
= xlist1 ++ xlist2 ++ ... ++ xlistn