"유형화되지 않은"은 또한 학문적 CS 세계에서 "동적 유형화 된"을 의미합니까?

"자바 스크립트가 형식화되지 않았습니다."라는 슬라이드 데크를 읽습니다. 이것은 내가 진실이라고 생각한 것과 모순되어서 더 많은 것을 배우려고 노력하기 시작했습니다.

JavaScript에 대한 모든 대답 은 형식화되지 않은 언어입니까? JavaScript는 형식화되지 않았 으며 친숙하고 만족하는 다양한 형태의 정적, 동적, 강력하고 약한 유형의 예제를 제공했습니다. 그래서 그것은 갈 길이 없었습니다.

그래서 저는 JavaScript를 만든 Brendan Eich에게 물었습니다.

아카데믹 타입은 "untyped"를 사용하여 "정적 타입 없음"을 의미합니다. 그들은 가치가 유형을 가지고 있음을 알기에 충분히 영리합니다 (duh!). 상황이 중요합니다.

학문에 중점을 둔 컴퓨터 과학 사람들이 "유형화되지 않은"을 "동적 유형화 된"(그리고 이것이 유효합니까?)의 동의어로 사용합니까? 나는 Brendan에게 문맥이 중요하지만 나의 현재 "go to"책이이 주제에 대해 공을 가지고 있지 않기 때문에 설명에 대한 인용은 훌륭 할 것이라고 동의합니다.

나는 이것을 이해하고 이해력을 향상시킬 수 있으며 위키 백과 조차도이 대체 사용법 (어쨌든 찾을 수 있음)을 참조하지 않기 때문에 나는 틀린 용어를 사용하거나 나중에 용어의 사용에 대해 의문을 제기하고 싶지 않습니다 :-)

(나는 또한 스몰 토커가 스몰 토크도 "유형화되지 않았다"고 말한 것을 보았으므로 일회성으로 인해이 퀘스트에서 나를 화나게했습니다! :-)

예, 이것은 학술 문헌의 표준 관행입니다. 그것을 이해하기 위해, "유형"의 개념은 1930 년대 람다 미적분학 (실제로, 심지어는 이론의 맥락에서)에서 발명되었다는 것을 아는 데 도움이된다. 그 이후로, "유형 이론"으로 알려진 전체 계산 논리 분기가 등장했습니다. 프로그래밍 언어 이론은 이러한 기초를 기반으로합니다. 그리고이 모든 수학적 상황에서 "유형"은 구체적으로 확립 된 의미를 갖습니다.

"동적 타이핑"이라는 용어는 훨씬 후에 발명되었습니다. "type"이라는 단어의 일반적인 수학적 사용에 대한 용어의 모순입니다.

예를 들어, Benjamin Pierce가 표준 교과서 Types and Programming Languages 에서 사용하는 "type system"의 정의는 다음과 같습니다.

유형 시스템은 계산하는 값의 종류에 따라 구를 분류하여 특정 프로그램 동작이 없음을 증명하는 다루기 쉬운 구문 방법입니다.

그는 또한 다음과 같이 말합니다.

"정적"이라는 단어가 명시 적으로 추가되는 경우가 있습니다. 예를 들어 "정적 유형의 프로그래밍 언어"라고 말하면 여기에서 고려중인 컴파일 타임 분석의 종류를 Scheme (Sussman and Steele, 1975; Kelsey, Clinger, and Rees, 1998; Dybvig, 1996)-런타임 타입 태그는 힙에서 다양한 종류의 구조를 구별하는 데 사용됩니다. "동적 유형"과 같은 용어는 틀림없이 잘못된 것이며 아마도 "동적 확인"으로 대체되어야하지만 사용법은 표준입니다.

현장에서 일하는 대부분의 사람들은이 관점을 공유하는 것 같습니다.

이것은하지 않습니다 "유형화되지 않은"및 "동적으로 유형화 된"이 동의어라는 것을 의미 . 오히려 후자는 전자의 특정 사례에 대한 (기술적으로 오해의 소지가있는) 이름입니다.

추신 : 그리고 FWIW, 저는 유형 시스템의 학술 연구원이자 JavaScript의 비 학문적 구현 자이므로 Schisma와 함께 살아야합니다. :)

나는 프로그래밍 언어를 전문으로하는 학문적 컴퓨터 과학자이며, "비 유형"이라는 단어는 종종 이런 식으로 사용됩니다. Forth 및 어셈블리 코드와 같이 동적 유형 태그를 포함하지 않는 언어에 사용할 단어를 예약하는 것이 좋을 것입니다. 그러나 이러한 언어는 거의 사용되지 않고 거의 연구되지 않으며 "형식화되지 않은"이라고 말하는 것이 훨씬 쉽습니다. "동적 형식"보다.

Bob Harper는 Scheme, Javascript 등과 같은 언어는 단일 유형 인 value로 유형이 지정된 언어로 간주되어야한다는 것을 좋아합니다. 한 가지 형식 형식을 사용하여 일관된 세계관을 구성 할 수 있기 때문에이 견해에 의지합니다.

PS 순수한 람다 미적분학에서, 유일한 "값"은 정규형의 항이고, 정규형의 유일한 닫힌 항은 함수입니다. 그러나 람다 미적분학을 사용하는 대부분의 과학자는 기본 유형과 상수를 추가 한 다음 람다에 대한 정적 유형 시스템을 포함하거나 동적 유형 태그로 바로 돌아갑니다.

PPS 오리지널 포스터 : 프로그래밍 언어, 특히 타입 시스템에 관해서는 Wikipedia의 정보 품질이 좋지 않습니다. 그것을 믿지 마십시오.

나는 그것을 조사했고, 당신의 질문에 대한 대답은 간단하고 놀랍게도 "예"입니다. 학문적 인 CS 유형 또는 적어도 일부는 "유형화되지 않은"을 사용하여 "동적 유형화 됨"을 의미합니다. 예를 들어 Programming Languages ​​: Principles and Practices , Third Edition (Kenneth C. Louden 및 Kenneth A. Lambert, 2012 년 발행)은 다음과 같이 말합니다.

정적 유형 시스템이없는 언어를 일반적으로 유형이 지정되지 않은 언어 (또는 동적 유형 언어 )라고합니다. 이러한 언어에는 Scheme 및 기타 Lisp, Smalltalk 및 Perl, Python 및 Ruby와 같은 대부분의 스크립팅 언어 방언이 포함됩니다. 그러나 형식화되지 않은 언어는 프로그램이 데이터를 손상시킬 필요는 없습니다. 이는 모든 안전 검사가 실행 시간에 수행됨을 의미합니다. […]

[ 링크 ] (참고 : 굵은 체로 굵은 글씨로 표시)는 이런 식으로 "typed"를 사용합니다.

나는이 놀라운 것을 발견합니다 (afrischke와 Adam Mihalcin 이주는 것과 거의 같은 이유로). :-)

추가하도록 수정 :"untyped languages" Google 도서 검색 에 연결 하여 더 많은 예를 찾을 수 있습니다 . 예를 들면 다음과 같습니다.

[…] 주요 정보 숨기기 메커니즘은 많은 형식화되지 않은 언어입니다. 예를 들어 PLT Scheme [4]는 생성 식 struct[...]을 사용합니다.

— Jacob Matthews와 Amal Ahmed, 2008 [ link ]

[…], 형식화되지 않은 기능 언어 […]에 대한 바인딩 시간 분석을 제시합니다. […] Scheme의 부작용이없는 방언을 위해 부분 평가자에서 구현되어 사용되고 있습니다. 그러나 분석은 Haskell과 같이 엄격하지 않은 유형의 기능 언어에 유효 할 정도로 일반적입니다. […]

— Charles Consel, 1990 [ 링크 ]

그건 그렇고, 이러한 검색 결과를 살펴본 결과, 연구원이 "유형화되지 않은"기능 언어를 작성하면, 유형화되지 않은 람다와 같은 의미에서 "유형화되지 않은"것으로 간주 될 가능성이 높습니다. Adam Mihalcin이 언급 한 미적분학. 적어도 몇몇 연구자들은 같은 호흡에서 Scheme과 lambda 미적분학을 언급했습니다.

물론 검색에서 말하지 않은 것은이 식별을 거부하고 이러한 언어를 "유형화되지 않은"것으로 간주 하지 않는 연구원이 있는지 여부 입니다. 글쎄, 나는 이것을 찾았다.

그런 다음 동적 형식 언어는 형식이 지정되지 않은 언어가 아니기 때문에 실제로 원형이 없다는 것을 깨달았습니다. 단지 형식이 대개 프로그램 텍스트에서 즉시 명확하지 않다는 것입니다.

— 누군가 (누가 알 수 없음), 1998 [ link ]

그러나이 신분증을 거부하는 대부분의 사람들은 명시 적으로 그렇게 말할 필요가 없습니다.

형식화되지 않은 동적 형식은 동의어가 아닙니다. 가장 자주 "유형화되지 않은"언어는 Lambda 미적분학으로, 실제로 통일 된 언어입니다. 모든 것이 함수이므로 모든 유형이 함수임을 정적으로 증명할 수 있습니다. 동적으로 유형이 지정된 언어에는 여러 유형이 있지만 컴파일러가 정적으로이를 확인할 수있는 방법을 추가하지 않으므로 컴파일러가 변수 유형에 대한 런타임 확인을 삽입해야합니다.

그런 다음 JavaScript는 동적으로 유형이 지정된 언어입니다. 일부 변수 x는 숫자, 함수 또는 문자열 또는 기타가 될 수 있도록 JavaScript로 프로그램을 작성할 수 있습니다. 어려운 수학 문제), 그래서 당신은 x인수에 적용 할 수 있으며 브라우저는 런타임 x에 함수 인지 확인해야 합니다.

값이나 변수에 대해 이야기하고 있는지에 따라 두 문장 모두 정확합니다. JavaScript 변수는 형식이 지정되지 않았으며 JavaScript 값에는 형식이 있으며 런타임시 모든 값 형식에 대해 변수의 범위를 지정할 수 있습니다 (예 : '동적').

JavaScript 및 기타 여러 언어에서 변수가 아닌 값에는 유형이 있습니다. 모든 변수는 모든 유형의 값을 포괄 할 수 있으며 "동적 타입"또는 "타입이 지정되지 않은"것으로 간주 될 수 있습니다. 유형 확인 / 알 수없는 유형이있는 변수와 모든 유형을 취할 수있는 변수는 논리적으로 실질적으로 동일합니다. . 타입 이론가들이 언어와 타입에 대해 이야기 할 때, 그들은 보통 타입에 대한 변수를 가지고 있습니다. 타입 체커와 컴파일러 작성에 관심이 있기 때문에 프로그램 텍스트 (예 : 변수)에서 작동하고 메모리에서 실행중인 프로그램이 아닙니다. (즉 값).

C와 같은 다른 언어와 달리 변수에는 유형이 있지만 값은 없습니다. Java와 같은 언어에서 변수와 값은 모두 유형을 가지고 있습니다. C ++에서 일부 값 (가상 함수가있는 값)에는 유형이 있고 다른 값에는 없습니다. 일부 언어에서는 일반적으로 잘못된 디자인으로 간주되지만 값이 유형을 변경하는 것도 가능합니다.

이 질문은 의미론

이 데이터를 주면 12 유형은 무엇입니까? 당신은 확실하게 알 방법이 없습니다. 정수 일 수 있습니다-float 일 수 있습니다-문자열 일 수 있습니다. 그런 의미에서 그것은 매우 "유형화되지 않은"데이터입니다.

이 데이터와 "임의의 언어와는 다른"임의의 데이터에 "추가", "빼기"및 "연결"과 같은 연산자를 사용할 수있는 가상의 언어를 제공하는 경우 (예 : 가상의 언어와는) "유형"은 다소 관련이 없습니다 (예 : : 아마 add(12, a)수확량 109에 12더해a ).

C에 대해 잠시 이야기 해 봅시다. C를 사용하면 임의의 데이터로 원하는 것을 수행 할 수 있습니다. 두 개의 함수를 사용하는 경우 uint원하는 것을 캐스팅하고 전달할 수 있으며 값은 단순히 uints 로 해석됩니다 . 그런 의미에서 C는 "유형화되지 않은"것입니다 (그러한 방식으로 처리하는 경우).

그러나-그리고 Brendan의 요점에 도달 12- "내 나이가 " 라고 말하면 12유형이 있습니다-적어도 우리는 그것이 숫자라는 것을 압니다. 상황 에 따라 언어에 관계없이 모든 유형이 있습니다.

이것이 내가 처음에 말한 이유입니다. 귀하의 질문은 의미론 중 하나입니다. "untyped"의 의미는 무엇입니까? 브렌든은 "정적 유형 없음"이라고 말했을 때 머리에 못을 박았다고 생각합니다. 인간은 자연스럽게 사물을 유형으로 분류합니다. 우리는 자동차와 원숭이 사이에 근본적으로 다른 것이 있다는 것을 직관적으로 알고 있습니다.

처음에 나의 예제로 돌아 가기- "유형에 신경 쓰지 않는"언어는 구문 오류를 일으키지 않고 "연령"과 "이름"을 "추가"할 수 있지만 ... 논리적으로 건전한 작업을 의미하지는 않습니다.

자바 스크립트를 사용하면 "오류"를 고려하지 않고 모든 종류의 미친 일을 할 수 있습니다. 그렇다고해서 논리적으로 건전한 것은 아닙니다. 개발자가 해결해야 할 것입니다.

컴파일 / 빌드 / 통역 시간에 유형 안전을 강제하지 않는 시스템 / 언어가 "유형화되지 않은"또는 "동적 유형화 된"입니까?

의미론.

편집하다

어떤 사람들은 "예,하지만 자바 스크립트에는"유형 "이 있습니다.

다른 사람의 답변에 대한 나의 의견에서 나는 말했다 :

Javascript에서는 "Monkeys"로 구축 한 객체와 "Humans"로 구축 한 객체를 가질 수 있으며 일부 기능은 "Humans"에서만 작동하고 일부 기능은 "Monkeys"에서만 작동하도록 설계 할 수 있습니다. "팔을 가진 것"에 관한 다른 사람들. 언어에 대한 언급이 있든 없든, "팔이있는 것"과 같은 객체 범주는 Javascript ( "동적")와 마찬가지로 어셈블리 ( "유형화되지 않은")와 관련이 없습니다. 그것은 모두 논리적 무결성의 문제입니다. 유일한 오류는 그 방법에 적합하지 않은 것을 사용하는 것입니다.

따라서 Javascript가 내부적으로 "유형의 개념"을 가지고 있고 따라서 "동적 유형"이라고 생각하고 이것이 "유형화되지 않은 시스템과는 분명히 다르다"고 생각한다면-위의 예에서 유형 "내부적으로 실제로 관련이 없습니다.

예를 들어 C #으로 동일한 작업을 수행하려면 인터페이스라는 인터페이스가 필요합니다. ICreatureWithArms 또는 이와 유사한 . Javascript에서는 그렇지 않습니다. C 또는 ASM에서는 그렇지 않습니다.

자바 스크립트가 "유형"에 대해 전혀 이해하고 있는지의 여부는 관련이 없습니다.

유형에 대해 쓰는 대부분의 CS 연구원은 구문 적으로 파생 가능한 유형을 가진 언어 만 유형 언어로 간주한다는 것이 사실이지만, 그 사용법에 따라 엄청나게 동적 인 / 잠재적으로 유형이 지정된 언어를 사용하는 사람이 더 많습니다.

3 가지 유형의 언어 (SIC)가 있다고 생각합니다.

형식화되지 않음-운영자 만 값의 해석을 결정하며 일반적으로 모든 작업을 수행합니다. 예 : BCPL 어셈블러

정적으로 유형이 지정된 표현식 / 변수에는 연관된 유형이 있으며 해당 유형에 따라 컴파일시 연산자의 해석 / 유효성이 결정됩니다. 예 : C, Java, C ++, ML, Haskell

동적 유형-값에 연관된 유형이 있으며 해당 유형은 런타임시 연산자의 해석 / 유효성을 결정합니다. 예 : LISP, Scheme, Smalltalk, Ruby, Python, Javascript

내가 알기로는 동적으로 형식이 지정된 모든 언어는 형식이 안전합니다. 즉 유효한 연산자 만 값을 처리 할 수 ​​있습니다. 그러나 정적으로 유형이 지정된 언어의 경우에도 마찬가지입니다. 사용 된 유형 시스템의 성능에 따라 일부 작업자는 런타임시에만 검사하거나 전혀 검사하지 않을 수 있습니다. 예를 들어, 대부분의 정적으로 유형이 지정된 언어는 정수 오버플로를 올바르게 처리하지 않으며 (2 개의 양의 정수를 추가하면 음의 정수를 생성 할 수 있음) 범위를 벗어난 배열 참조는 전혀 확인되지 않거나 (C, C ++) 실행 시간. 또한 일부 유형 시스템은 너무 약하여 컴파일 타임 유형의 표현식을 변경하려면 유용한 프로그래밍에 이스케이프 해치 (C 및 패밀리의 캐스트)가 필요합니다.

이 모든 것은 (정적으로 형식화되어 있기 때문에) C ++가 Python보다 안전하다는 주장과 같은 터무니없는 주장으로 이어지며, 진실은 파이썬이 본질적으로 안전하고 C ++로 다리를 쏠 수 있다는 것입니다.

나는 컴퓨터 과학자는 아니지만, "비 유형"이 CS 커뮤니티 (적어도 과학 출판물)에서 "동적 유형"의 동의어로 사용되어이 두 용어가 다른 개념을 설명하는 것처럼 다소 놀랐을 것이다. 동적으로 형식이 지정된 언어에는 형식 개념이 있으며 런타임에 형식 제약 조건을 적용합니다 (예를 들어 오류없이 Lisp에서 문자열을 정수로 나눌 수 없음). 형식화되지 않은 언어에는 형식 개념이 없습니다. 모두 (예 : 어셈블러). 프로그래밍 언어 (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages)에 대한 Wikipedia 기사에서도 이러한 차이점을 확인했습니다.

업데이트 : 어쩌면 혼란은 일부 텍스트가 Javascript에서 "변수가 입력되지 않았다"는 사실 (실제)으로 말하는 것입니다. 그러나 이것이 언어가 타입이 지정되지 않았다는 것을 자동으로 의미하는 것은 아닙니다.

Brendan에 동의하십시오-문맥이 전부입니다.

나의 테이크 :

루비가 형식화되지 않았는지 동적으로 형식화되었는지에 대한 논쟁이 있었기 때문에 2004 년경 혼란 스러웠습니다. 구식 C / C ++ 사람들 (내가 한 사람)은 컴파일러에 대해 생각하고 루비가 형식화되지 않았다고 말하고있었습니다.

C에는 런타임 유형이 없으며 주소 만 있으며 실행중인 코드가 해당 주소에있는 것을 처리하지 않기로 결정한 경우를 기억하십시오. 확실히 형식화되지 않았으며 동적 형식화와는 매우 다릅니다.

그 세계에서 "타이핑"은 컴파일러에 관한 것입니다. 컴파일러의 검사가 더 엄격했기 때문에 C ++에는 "강력한 입력"이있었습니다. Java와 C는 더 "약한 유형"(자바 유형이 강하거나 약한 유형인지에 대한 논거도 있음)이었다. 그 연속체에서 동적 언어는 컴파일러 유형 검사가 없기 때문에 "유형화되지 않은"언어였습니다.

오늘날 프로그래머를 연습 할 때 우리는 동적 언어에 익숙해 져 있기 때문에 컴파일러 나 인터프리터 유형 검사를 의미하지 않는 유형화되지 않은 것으로 생각합니다. 그러나 분명하지 않은 시대가 있었고 더 이론적 인 CS 세계에서는 의미가 없을 수도 있습니다.

의미있는 알고리즘을 작성하기 위해 값을 조작하려는 의도가 있어야하기 때문에 어떤 의미에서든 형식화되지 않은 (또는 거의 아무것도) 아무것도 없습니다. 이것은 이론적 CS의 세계이며, 주어진 언어에 대해 컴파일러 또는 인터프리터가 어떻게 구현되는지에 대한 구체적인 내용은 다루지 않습니다. 따라서 "untyped"는 그 맥락에서 전혀 의미가 없습니다.