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

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

---

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

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

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

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

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

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

(나는 또한 스몰 토커가 스몰 토크가 "유형화되지 않았다"고 말하는 것을 보았으므로 일회성이 아니기 때문에이 퀘스트를 시작하게되었습니다! :-))

---

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

"동적 타이핑"이라는 용어는 훨씬 나중에 발명되었습니다. "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와 같은 대부분의 스크립팅 언어 방언이 포함됩니다. 그러나 형식화되지 않은 언어는 프로그램이 데이터를 손상시킬 필요는 없습니다. 이는 모든 안전 검사가 실행 시간에 수행됨을 의미합니다. […]

[ link ] (참고 : 굵은 체로 굵은 체로 표시됨), 이런 식으로 "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 미적분학으로, 실제로 통일 된 언어입니다. 모든 것이 함수이므로 모든 유형이 함수임을 정적으로 증명할 수 있습니다. 동적으로 유형이 지정된 언어에는 여러 유형이 있지만 컴파일러가 정적으로이를 확인할 수있는 방법을 추가하지 않으므로 컴파일러가 변수 유형에 대한 런타임 확인을 삽입해야합니다.

Then, JavaScript is a dynamically typed language: it is possible to write programs in JavaScript such that some variable x could be a number, or a function, or a string, or something else (and determining which one would require solving the Halting Problem or some hard mathematical problem), so you can apply x to an argument and the browser has to check at runtime that x is a function.

---

Both statements are correct, depending on whether you are talking about values or variables. JavaScript variables are untyped, JavaScript values have types, and variables can range over any value type at runtime (i.e. 'dynamically').

In JavaScript and many other languages, values and not variables carry types. All variables can range over all types of values and may be considered "dynamically typed" or "untyped" - from the perspective of type-checking a variable that has no/unknowable type and a variable that can take any type are logically and practically equivalent. When type theorists talk about languages and types, they are usually talking about this - variables carrying types - because they are interested in writing type checkers and compilers and so on, which operate on program text (i.e. variables) and not a running program in memory (i.e. values).

By contrast in other languages, like C, variables carry types but values do not. In languages like Java, variables and values both carry types. In C++, some values (those with virtual functions) carry types and others do not. In some languages it is even possible for values to change types, although this is usually considered bad design.

---

This question is all about Semantics

If I give you this data: 12 what is it's type? You have no way of knowing for sure. Could be an integer - could be a float - could be a string. In that sense it's very much "untyped" data.

If I give you an imaginary language which lets you use operators like "add", "subtract", and "concatenate" on this data and some other arbitrary piece of data the "type" is somewhat irrelevant (to my imaginary language) (example: perhaps add(12, a) yields 109 which is 12 plus the ascii value of a).

Let's talk C for a second. C pretty much lets you do whatever you want with any arbitrary piece of data. If you're using a function that takes two uints - you could cast and pass anything you want - and the values will simply be interpreted as uints. In that sense C is "untyped" (if you treat it in such a way).

However - and getting to Brendan's point - if I told you that "My age is 12" - then 12 has a type - at least we know it's numeric. With context everything has a type - regardless of the language.

This is why I said at the beginning - your question is one of semantics. What is the meaning of "untyped"? I think Brendan hit the nail on the head when he said "no static types" - because that's all it can possibly mean. Humans naturally classify things into types. We intuitively know that there is something fundamentally different between a car and a monkey - without ever being taught to make those distinctions.

Getting back to my example in the beginning - a language that "doesn't care about types" (per-se) may let you "add" an "age" and a "name" without producing a syntax error... but that doesn't mean it's a logically sound operation.

Javascript may let you do all sorts of crazy things without considering them "errors". That doesn't mean what you are doing is logically sound. Thats for the developer to work out.

Is a system/language which doesn't enforce type safety at compile/build/interpretation time "untyped" or "dynamically typed"?

Semantics.

EDIT

I wanted to add something here because some people seem to be getting caught up on "yeah, but Javascript does have some "types"".

In my comment on someone else's answer I said:

In Javascript I could have objects I've built up to be "Monkeys" and objects I've built up to be "Humans" and some functions could be designed to operate on only "Humans", others on only "Monkeys", and yet others on only "Things With Arms". Whether or not the language has ever been told there is such a category of objects as "things with arms" is as irrelevant to assembly ("untyped") as it is to Javascript ("dynamic"). It's all a matter of logical integrity - and the only error would be using something that didn't have arms with that method.

So, if you consider Javascript to have some "notion of types" internally - and, hence "dynamic types" - and think this is somehow "distinctly different from an untyped system" - you should see from the above example that any "notion of types" it has internally is really irrelevant.

To perform the same operation with C#, for example, I'd NEED an interface called ICreatureWithArms or something similar. Not so in Javascript - not so in C or ASM.

Clearly, whether or not Javascript has any understanding of "types" at all is irrelevant.

---

While it is true that most of the CS researchers that write about types essentially consider only languages with syntactically-derivable types as typed languages, there are lots more of us using dynamically/latently typed languages who take umbrage at that usage.

I consider there to be 3 types [SIC] of languages:

Untyped - only the operator determines the interpretation of the value - and it generally works on anything. Examples: Assembler, BCPL

Statically typed - expressions/variables have types associated with them, and that type determines the interpretation/validity of the operator at compile-time. Examples: C, Java, C++, ML, Haskell

Dynamically typed - values have types associated with them, and that type determines the interpretation/validity of the operator at run-time. Examples: LISP, Scheme, Smalltalk, Ruby, Python, Javascript

To my knowledge, all dynamically-typed languages are type-safe - i.e. only valid operators can operate on values. But the same is not true for statically-typed language. Depending on the power of the type system used, some operators may be checked only at run-time, or not at all. For example, most statically-typed languages do not handle integer overflow properly (adding 2 positive integers can produce a negative integer), and out-of-bound array references are either not checked at all (C, C++) or are checked only at run-time. Further, some type systems are so weak that useful programming requires escape hatches (casts in C and family) to change the compile-time type of expressions.

All of this leads to absurd claims, such as that C++ is safer than Python because it's (statically-typed), whereas the truth is that Python is intrinsically safe while you can shoot your leg off with C++.

---

I am not a computer scientist, but I would be rather surprised if "untyped" were really used as a synonym for "dynamically typed" in the CS community (at least in scientific publications) as imho those two terms describe different concepts. A dynamically typed language has a notion of types and it enforces the type constraints at runtime (you can't for example divide an integer by a string in Lisp without getting an error) while an untyped language doesn't have any notion of types at all (e.g. assembler). Even the Wikipedia article about programming languages (http://en.m.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages) makes this distinction.

Update: Maybe the confusion comes from the fact that some texts say something to the extent that "variables are not typed" in Javascript (which is true). But that doesn't automatically mean that the language is untyped (which would be false).

---

Agree with Brendan - context is everything.

My take:

I remember being confused, circa 2004, because there were arguments breaking out about whether Ruby was untyped or dynamically typed. Old school C/C++ people (of which I was one) were thinking about the compiler and saying Ruby was untyped.

Remember, in C, there are no runtime types, there are just addresses and if the code that's executing decides to treat whatever's at that address as something it isn't, whoops. That's definitely untyped and very different from dynamically typed.

In that world, "typing" is all about the compiler. C++ had "strong typing" because the compiler's checks were more stringent. Java and C were more "weakly typed" (there were even arguments about whether Java was strongly or weakly typed). Dynamic languages were, in that continuum, "untyped" because they had no compiler type checking.

Today, for practicing programmers, we're so used to dynamic languages, we obviously think of untyped to mean no compiler nor interpreter type-checking, which would be insanely hard to debug. But there was a period there where that wasn't obvious and in the more theoretical world of CS is may not even be meaningful.

In some deep sense, nothing can be untyped (or almost nothing, anyway) because you must have some intent in manipulating a value to write a meaningful algorithm. This is the world of theoretical CS, which isn't dealing with the specifics of how a compiler or interpreter is implemented for a given language. So "untyped" is (probably, I don't know) entirely meaningless in that context.

참고URL : https://stackoverflow.com/questions/9154388/does-untyped-also-mean-dynamically-typed-in-the-academic-cs-world