[C++] C와 C++는 모두 강타입(strong typing)언어가 아니다..

gyxor의 이미지

프로그래밍언어론 책에서..

"프로그래밍 언어에서 타입 오류가 항상 탐지될 수 있다면,
그 언어를 강타입 언어라고 정의한다"

"C와 C++는 모두 타입검사가 되지 않는 공용체 타입을 포함하기
때문에 강 타입 언어가 아니다."

라고 나와있습니다.

지역변수도

#include<iostream>
using namespace std;

int main() 
{
	float a = 32767;
	char b = a;

return 0; 
} 

타입검사는 이뤄지지 않습니다.
파라미터로 전달될때에도 마찬가지입니다.

특별히 공용체 타입을 쓸때에만 타입검사가 안 이뤄지는것도
아닌데 왜 하필이면 공용체타입만을 예로 든 것인지 모르겠습니다.
설명부탁드립니다.

댓글

doldori의 이미지

gyxor wrote:
#include<iostream>
using namespace std;

int main() 
{
	float a = 32767;
	char b = a;

return 0; 
} 

타입검사는 이뤄지지 않습니다.
파라미터로 전달될때에도 마찬가지입니다.


아니오, 이때에도 형검사는 합니다. 이 문장이 허용되는 이유는 형검사를 하지 않기
때문이 아니라 이들 형 사이의 변환이 정의되기 때문입니다.

강타입 언어를 위처럼 정의한다면 C와 C++은 강타입 언어가 아니지요. 공용체는
현재 값의 형을 항상 추적해야 하기 때문에 저도 그 위험성에 대해서는 동의합니다만,
공용체의 경우에도 형검사는 한다는 점은 말씀드리고 싶습니다.

union U { };
union V { };

U u1, u2;
V v;
u1 = u2; // ok
v = u1;  // error. conversion of U to V not defined
익명 사용자의 이미지

gyxor wrote:
프로그래밍언어론 책에서..

"프로그래밍 언어에서 타입 오류가 항상 탐지될 수 있다면,
그 언어를 강타입 언어라고 정의한다"

"C와 C++는 모두 타입검사가 되지 않는 공용체 타입을 포함하기
때문에 강 타입 언어가 아니다."

라고 나와있습니다.

지역변수도

#include<iostream>
using namespace std;

int main() 
{
	float a = 32767;
	char b = a;

return 0; 
} 

타입검사는 이뤄지지 않습니다.
파라미터로 전달될때에도 마찬가지입니다.

특별히 공용체 타입을 쓸때에만 타입검사가 안 이뤄지는것도
아닌데 왜 하필이면 공용체타입만을 예로 든 것인지 모르겠습니다.
설명부탁드립니다.

참고.
http://en.wikipedia.org/wiki/Strongly-typed_programming_language

익명 사용자의 이미지

대체로 동감하지만, c와 c++을 통으로 얘기하면 안될것같고,
c보다는 c++이 아주 타입 검사가 강한편이라고 먼저 얘기해야 할듯합니다.

그래서, c++도 강한 타입은 아니다.. 정도가 맞는 제목같습니다.

lovewar의 이미지

영어에 대한 독해력 미비로 C, C++이 강타입(strongly-typed)언어에 속하지(?) 않다는 점을 이해하지 못했습니다.

강타입언어가 되기위해
C, C++ 언어가 갖는 부족한 점들에 대한 설명좀 부탁 드립니다.

-- 덧붙이는 글--

강타입(strongly-typed)을 쉽게 와닿게 할 수 있는 용어가 없을까요?
익숙하지 않아서 일까요...

lifthrasiir의 이미지

lovewar wrote:
영어에 대한 독해력 미비로 C, C++이 강타입(strongly-typed)언어에 속하지(?) 않다는 점을 이해하지 못했습니다.

강타입언어가 되기위해
C, C++ 언어가 갖는 부족한 점들에 대한 설명좀 부탁 드립니다.

-- 덧붙이는 글--

강타입(strongly-typed)을 쉽게 와닿게 할 수 있는 용어가 없을까요?
익숙하지 않아서 일까요...

위키백과의 글들을 대충 번역한다면 다음과 같습니다. (저는 번역된 내용에 대해 보장하지 않습니다. 보시다시피 그리 품질이 좋진 않거든요. 틀린 번역 있으면 지적해 주시면 감사하겠습니다.)

  1. 만약 어떤 언어에서 형 선언이 값 혼자가 아닌 변수에 선언되어 있으면 강형 언어이고, 값에만 형이 연결되어 있으면 약형 언어이다. (정확한 용어는 정적 형 선언과 동적 형 선언이다.)
  2. 만약 어떤 언어가 컴파일 시간에 형 제한 위반에 대한 체크를 한다면 강형 언어이고, 모든 체크가 실행 시간에 이루어지면 약형 언어이다.
  3. 만약 어떤 언어가 컴파일 시간 또는 실행 시간에 형 제한 위반에 대한 체크를 한다면 강형 언어이고, 아무 체크도 하지 않는다면 약형 언어이다.
  4. 만약 어떤 언어에서 서로 다른 형 사이의 변환이 금지되어 있으면 강형 언어이고, 그러한 변환이 허용되면 약형 언어이다.
  5. 만약 어떤 언어에서 서로 다른 형 사이의 변환이 항상 명시적으로 지정되어 있어야 한다면 강형 언어이고, 묵시적인 변환이 허용된다면 약형 언어이다.
  6. 만약 어떤 언어에서 형 체계를 비활성시키거나 피해 가는 언어 수준에서의 방법이 존재하지 않으면 강형 언어이고, C 스타일의 캐스팅이나 다른 방법들이 존재하면 약형 언어이다.
  7. 만약 어떤 언어가 복합 형에 대해서 복합적이고 잘 정의된 형 체계를 갖추고 있다면 강형 언어이고, 적은 수의 형이나 스칼라 형만이 존재할 경우 약형 언어이다.
  8. 만약 어떤 언어에서 어떤 객체의 형이 고정되어 있고 객체의 생존 시간 동안에 변하지 않는다면 (보통 "정적 형 선언"이라 부름) 강형 언어이고, 그 형이 변할 수 있다면 약형 언어이다.
  9. 만약 어떤 언어의 형 체계가 실행 시간에서의 행동에 대해 강한 보장을 한다면 강형 언어이고, 그러한 보장을 하지 않는다면 약형 언어일 가능성이 높다.
위의 정의들은 strongly-typed라는 말을 정의하기 위한 서로 다른 방법이고 동치는 아닙니다. 즉, C나 C++는 어떤 정의(예를 들어서 6번)에 따르면 강형이 아닙니다만 어떤 정의(예를 들어 1번)에 따르면 강형이 될 수 있습니다. 이런 문제 때문에 개인적으로는 강형이라는 말을 상대적으로 정의해야 한다고 생각합니다 -- 예를 들어서, C나 C++는 아주 강형인 건 아니지만 파이썬 같은 언어에 비해서는 강형입니다.

그리고... strongly-typed language의 번역은 저도 잘 모르겄습니다. 그냥 "강형 언어"라고 쓰고는 있는데 영 마음에 들진 않네요.

- 토끼군

[/]
gyxor의 이미지

"C와 C++는 모두 타입검사가 되지 않는 공용체 타입을 포함하기
때문에 강 타입 언어가 아니다."
책에나온 위 말은.. 공용체는 동적으로 타입검사가 이뤄지고,,,
정적으로는 타입검사가 안되기 때문에.. 2번항목에 의해서
C와 C++은 강타입언어가 아니다.. 라고 이야기 하는거였군요..

Programming Languages (written by Sebesta) 207p의 내용입니다.

C and C++ are not strongly typed languages because both include
union types, which are not type checked.

statically를 생략을 해놔서 헷갈리는..내용이 됐습니다.

wiki 사전에 나온 마지막 부분에..

I spent a few weeks . . . trying to sort out the terminology of "strongly typed," "statically typed," "safe," etc., and found it amazingly difficult. . . . The usage of these terms is so various as to render them almost useless.

정말... 힘빠지는 내용이네요..

violino의 이미지

Assignment 문장등의 표현식(expression)에서 서로 다른 type 을 매개변수(parameter)로 쓸 수 있다고 해서 type checking 이 이루어지지 않는다고 간주하는 건 좀 혼동의 여지가 있을듯 합니다.
C, C++에서 기본형(primitive types)만으로 연산할때 float, int 를 혼합해서 쓸 수 있는건 operator overloading (또는 coercion에 관련될까요)에 의한 것이니까요.
C, C++ 이 완전히 strong typed 라고 할 수 없는건 이해를 하는데, 예가 조금 적절하지 않은 듯 합니다. 차라리, void 형(type)이나 형변환(type casting;dynamic/static) 등을 예로 들어 설명해야 하지 않을까 하는 생각이 드네요.

vio:

익명 사용자의 이미지

* 타입(자료형) 검사를 엄격하게 하는 언어....
이를테면,
C언어
int i;

i = 3.14; // 별 무리없지요. 대충 돌아줍니다....

Fortran언어(C언어에 비해 매우 엄격한....)
INTEGER I
I = 3.14

컴파일 타임에 에러입니다.

lovewar의 이미지

강형인지 약형인지의 정의 자체가 상대적이군요.

이런 것들에 대한 예제를 하나씩 만들수 있다면,
이해하기 쉬울것인데, 글로만 볼려니 이해하기가 쉽지 않네요.

공용체의 문제도 공용체 내부의 문제인가요 아니면 공용체와 다른 자료형간의 문제인가요? 궁금증이 도발하는군요. 혹시 죄송한데, 이런 것에 대한 예제를 볼수 있을까요?

Quote:

violino 씀:
C, C++에서 기본형(primitive types)만으로 연산할때 float, int 를 혼합해서 쓸 수 있는건 operator overloading (또는 coercion에 관련될까요)에 의한 것이니까요.

위 문제는 묵시적 변환(conversion)에 대한 것으로 생각하고, 연산자 오버로딩과는 별개라고 생각합니다.

-- 덧붙이는글 ---
감사합니다...

violino의 이미지

void type 을 예로 들었던건 다음과 같은 이유 때문입니다.

예를 들어 smalltalk 이나 perl 같은 언어들을 보면 변수를 정의할 때에 특별하게 type 선언을 하지 않습니다.
심지어는 collection 안에서 각각의 element 들이 전혀 다른 클래스(또는 type)의 인스턴스여도 상관이 없지요.
이런 경우는 완벽하게 weak typed 언어라고 할 수 있을겁니다.
예를들어, Smalltalk 에서

aObj := FooClass new.
aObj doSomething: paramObj.
aObj := 'Foobar'.

이런다고 해서 전혀 문제가 안되거든요.

C/C++ 에서 이렇게 때에 따라 맘대로 전용할 수 있는 대표적인 type 이 void 입니다.

예를 들어서,

void foo;
int bar=10;
foo=(void)bar;

하는것은 전혀 문제를 일으키지 않습니다. 물론 이 경우 type casting 이 사용되었지요. 좀더 일반적인 예를 들면,

void* foo;
int x=10;
float y=1.1;
MyOwnStruct z;
foo=(void*)(&x);
foo=(void*)(&y);
foo=(void*)&z;

같은 경우를 볼 수 있겠죠.
그럼, 조금이나마 도움이 되셨길 빕니다.

vio:

myueho의 이미지

violino wrote:

C/C++ 에서 이렇게 때에 따라 맘대로 전용할 수 있는 대표적인 type 이 void 입니다.

예를 들어서,

void foo;
int bar=10;
foo=(void)bar;

하는것은 전혀 문제를 일으키지 않습니다. 물론 이 경우 type casting 이 사용되었지요.

전혀 문제를 일으킵니다.
void 는 타입이 아닙니다.
void *는 타입으로 사용하지만요..

lifthrasiir의 이미지

void는 거기에 대응하는 내용이 없다는 걸 나타내기 위해서만 사용합니다. void로 identifier를 선언할 수는 있지만 void 형으로 캐스팅한다거나 값을 집어 넣는 것 뿐만 아니라 sizeof조차도 불가능합니다. void가 실제로 형으로 사용되는 경우는 void*, void** 같이 포인터로 쓰일 경우 뿐이며 이 때의 뜻은 type*, type** 등의 포인터를 대표하는 의미를 가집니다.

- 토끼군

doldori의 이미지

myueho wrote:
violino wrote:

C/C++ 에서 이렇게 때에 따라 맘대로 전용할 수 있는 대표적인 type 이 void 입니다.

예를 들어서,

void foo;
int bar=10;
foo=(void)bar;

하는것은 전혀 문제를 일으키지 않습니다. 물론 이 경우 type casting 이 사용되었지요.

전혀 문제를 일으킵니다.
void 는 타입이 아닙니다.
void *는 타입으로 사용하지만요..


잘못된 코드이긴 하지만 void도 타입입니다. 자세한 얘기는 아래에...

tokigun wrote:
void는 거기에 대응하는 내용이 없다는 걸 나타내기 위해서만 사용합니다. void로 identifier를 선언할 수는 있지만 void 형으로 캐스팅한다거나 값을 집어 넣는 것 뿐만 아니라 sizeof조차도 불가능합니다. void가 실제로 형으로 사용되는 경우는 void*, void** 같이 포인터로 쓰일 경우 뿐이며 이 때의 뜻은 type*, type** 등의 포인터를 대표하는 의미를 가집니다.

- 토끼군


void는 그 크기가 알려지지 않은 불완전형(incomplete type)입니다.
class C;       // C is an incomplete type
C* pc;
++pc;          // illegal
class C { };   // C is a complete type now
++pc;          // ok

void* pv;
++pv;          // illegal. void is never a complete type

void로 identifier를 선언할 수 있는 경우는 반환값이 없는 함수를 선언할 때뿐입니다.
(위 코드에서 void foo; 같은 선언은 할 수 없지요.)
그리고 식(expression)을 void형으로 캐스팅하는 것은 가능합니다. 예를 들어
assert는 보통 다음과 같이 정의하죠.
#ifdef NDEBUG
#define assert(exp)  ((void)0)
#else
#define assert(exp)  /* ... */
#endif
서지원의 이미지

개인적으로는 runtime에 어떤 variable에 대한 type을 알 수 있으면 strongly-typed이고 그렇지 않다면 weakly-typed라는 정의를 가장 좋아합니다. 즉, python이나, Java, lisp, ruby 등은 runtime에 어떤 variable의 type이 뭔지를 알 수 있으므로 strongly-typed이고, c의 경우는 type을 알 수 없으므로 weakly-typed이라는 거죠.

위키 백과에 나와 있는 다른 정의들중 일부 (예를 들면 형 사이의 변환이 금지되었으면 strongly-typed이다, 혹은 형 사이의 변환이 명시적으로 있어야만 strongly-typed이다 등)는 strictly-typed라고 부르는게 좀 더 자연스럽지 않나 생각합니다. (strictly-typed vs loosely-typed) 그리고 그 나머지는 statically-typed vs dynamically-typed 이거나 strictly와 statically의 mix-in인 것 같네요.

절대적인 정의는 아니지만, 저도 예전에 궁금해서 알아보고 나름대로 정리해 봤던 적이 있어서 포스팅 합니다. strongly-typed, strictly-typed에 대한 내용은 확실히 사람들마다 의견이 다르더군요. dynamic vs static은 거의 의견이 일치하지만...

p.s) python의 경우에는 strongly-typed, loosely-typed, dynamically-typed language이겠죠.

익명 사용자의 이미지

이 세상에 어떤 사람이 자신이 만든 창조물이 결점이 있다고 말하겠습니까?

"C, C++언어 모두 Strong typing 언어가 아니다."라는 주제는 토론할 의미가 없는것 같네요.

현재 과학적으로 증명된 Strong typing언어는 ML 밖에 없습니다.

그 외 다른 언어들은 모두 하나같이 Strong typing 언어라고 주장을 하고 있죠.

여기서 이런 토론을 해봤자 과학적으로 증명을 하지 않는 이상은 뭐라 할 수 없는 문제입니다.

그리고 컴파일러 자체를 분석해 본 사람이 아니라면 이런 문제에 말을 던져서도 안된다고 생각합니다.

저 역시 분석을 해본 적은 없습니다. 그래서 본질적인 문제에 관해서는 언급을 하지 않겠습니다.

다만, 이런 주제가 토론할 가치가 있는지를 생각해봤으면 하는 생각입니다.

doldori의 이미지

어줍짢은 프로그래머 wrote:
현재 과학적으로 증명된 Strong typing언어는 ML 밖에 없습니다.

strongly-typed냐 아니냐는 정의(definition)의 문제로 보이는데요.
정의를 증명하는 것이 가능한가요?

어줍짢은 프로그래머 wrote:
다만, 이런 주제가 토론할 가치가 있는지를 생각해봤으면 하는 생각입니다.

자신에게 가치가 없다고 해서 다른 사람에게도 가치가 없으리라고 생각하는 것은
성급한 판단입니다.
pool007의 이미지

어줍짢은 프로그래머 wrote:

현재 과학적으로 증명된 Strong typing언어는 ML 밖에 없습니다.

음.. SEBESTA 아저씨가 틀렸다에 한표 던지시는건가요?
그러기엔 그 책이 너무 유명하죠...
가령, SEBESTA책에서 자바가 강타입이라고 설명되고 있고,
강타입에 대한 정의를 "실행시간에 타입을 알 수 있다/타입 에러를 잡을 수 있다"정도로 하고 있죠.. 제 기억이 맞다면.

과학적으로 증명 -_-;;; 은 ML 을 위키에서 찾아보면 "ML is often referred to as an impure functional language, because it permits imperative programming, and therefore, side-effects, unlike purely functional programming languages such as Haskell." 이라고되어있는데, ML 이 함수형 언어인 이상 강타입이냐 아니냐를 제대로 한번 따질 필요가 있었겠죠.

그러나 자바의 경우엔 imperative language 로, 변수나 반복문이 언어의 근간이자 핵심이므로 굳이 증명 어쩌구 할 필요도 없었을텐데요...

더구나 최근에 jdk 1.5 이후엔 ArrayList 에 아무거나 넣다 뺄려고만 해도 경고나오는걸요. 자바에서 실행시간에 타입 에러가 안잡힐까요? -_-;;;

"To authors' best knowledge, ML이 강타입이다" 라고 말씀하신걸로 이해하겠습니다.

--
Passion is like genius; a miracle.

notpig의 이미지

doldori wrote:

strongly-typed냐 아니냐는 정의(definition)의 문제로 보이는데요.
정의를 증명하는 것이 가능한가요?

일단 이거에 대해서만 답변하면...가능합니다...

대학원 수준의 컴파일러 혹은 프로그래밍 언어 수업을 들으면
이런 증명하는거 합니다.

그리고 정의의 문제라고 하셨는데....정의를 수학적으로 표현해야 인정 받습니다...
그런데~~~현재 프로그래밍 언어중 완전히 수학적으로
정의를 한언어는 ML등의 몇몇 언어만 있는걸로 알고 있습니다. 이런 프로그래밍 언어는 모든 타입 오류를 찾을수 있습니다.
(잘은 몰라요~)

그런데 일반적으로 많이 사용되는 C C++ Java 는 수학적으로 표현이 안되어 있고 모든 타입 오류를 찾아준다고 증명을 못합니다. 그래서 Strong Typed System 이 아니라고 들었습니다.

약간 따른 이야기를 하면 지금 여러분들이 이야기하는 언어는
static typed system 입니다.
http://en.wikipedia.org/wiki/Datatype#Static_and_dynamic_typing

컴파일 시점에 타입이 결정 됩니다.

따라서 타입 오류를 컴파일 타입에 잡아낼수 있어야 합니다.
하지만...ML 을 제외한 지금 이야기한 어떤 언어도
모든 타입 에러를 컴파일 타임에 잡아낼수 없습니다.
그래서 대체적으로 강타입으로 보질 않는거 같습니다.

제가 이쪽 전공이 아니라서 어디서 주어들은 이야기라서 틀린 부분 있을수 있습니다.

추가로 한가지더...
http://en.wikipedia.org/wiki/Datatype#Static_and_dynamic_typing

Advocates of strongly typed languages such as ML and Haskell have suggested that almost all bugs can be considered type errors, if the types used in a program are sufficiently well declared by the programmer or inferred by the compiler

익명 사용자의 이미지

pool007 wrote:
어줍짢은 프로그래머 wrote:

현재 과학적으로 증명된 Strong typing언어는 ML 밖에 없습니다.

음.. SEBESTA 아저씨가 틀렸다에 한표 던지시는건가요?
그러기엔 그 책이 너무 유명하죠...
가령, SEBESTA책에서 자바가 강타입이라고 설명되고 있고,
강타입에 대한 정의를 "실행시간에 타입을 알 수 있다/타입 에러를 잡을 수 있다"정도로 하고 있죠.. 제 기억이 맞다면.

과학적으로 증명 -_-;;; 은 ML 을 위키에서 찾아보면 "ML is often referred to as an impure functional language, because it permits imperative programming, and therefore, side-effects, unlike purely functional programming languages such as Haskell." 이라고되어있는데, ML 이 함수형 언어인 이상 강타입이냐 아니냐를 제대로 한번 따질 필요가 있었겠죠.

그러나 자바의 경우엔 imperative language 로, 변수나 반복문이 언어의 근간이자 핵심이므로 굳이 증명 어쩌구 할 필요도 없었을텐데요...


왜 imperative language에서는 functional language와는 달리 증명같은 것이 필요없다고 생각하시는지 궁금하네요.
violino의 이미지

아, 지적해주셔서 감사합니다.
암튼 의미는 전달되었죠? ^^

myueho wrote:
violino wrote:

C/C++ 에서 이렇게 때에 따라 맘대로 전용할 수 있는 대표적인 type 이 void 입니다.

예를 들어서,

void foo;
int bar=10;
foo=(void)bar;

하는것은 전혀 문제를 일으키지 않습니다. 물론 이 경우 type casting 이 사용되었지요.

전혀 문제를 일으킵니다.
void 는 타입이 아닙니다.
void *는 타입으로 사용하지만요..

htna의 이미지

'강제타입언어'
라고 하면 어떨까요..
솔직히 '강타입언어'맘에 안듭니다.
차라리 strongly-typed language 라고 하거나 static typed language라고 보는게 더 편하죠..
가독성이 떨어진다고나 할까...
ㅋㅋ
올만에 낙서해봅니다.

WOW Wow!!!
Computer Science is no more about computers than astronomy is about telescopes.
-- E. W. Dijkstra

pool007의 이미지

Anonymous wrote:
pool007 wrote:
어줍짢은 프로그래머 wrote:

현재 과학적으로 증명된 Strong typing언어는 ML 밖에 없습니다.

음.. SEBESTA 아저씨가 틀렸다에 한표 던지시는건가요?
그러기엔 그 책이 너무 유명하죠...
가령, SEBESTA책에서 자바가 강타입이라고 설명되고 있고,
강타입에 대한 정의를 "실행시간에 타입을 알 수 있다/타입 에러를 잡을 수 있다"정도로 하고 있죠.. 제 기억이 맞다면.

과학적으로 증명 -_-;;; 은 ML 을 위키에서 찾아보면 "ML is often referred to as an impure functional language, because it permits imperative programming, and therefore, side-effects, unlike purely functional programming languages such as Haskell." 이라고되어있는데, ML 이 함수형 언어인 이상 강타입이냐 아니냐를 제대로 한번 따질 필요가 있었겠죠.

그러나 자바의 경우엔 imperative language 로, 변수나 반복문이 언어의 근간이자 핵심이므로 굳이 증명 어쩌구 할 필요도 없었을텐데요...


왜 imperative language에서는 functional language와는 달리 증명같은 것이 필요없다고 생각하시는지 궁금하네요.

음.. 말을 좀 바꾸겠습니다.
증명이 필요없다는 의미가 아니라,
증명에 관심없다로.

예를들어 함수형 언어의 대표주자중 하나인 LISP은 타입을 골치아프게 생각하는 언어가 아니죠.. 이런 상태에서 만약 "xxx 라는 functional language가 있는데 강타입이다" 라고 말하면 이건 하나의 특징적인 점이 됩니다. functional language 라는 것의 본래적인 특징은 imperative language가 가진 변수/반복문을 없애보자..라는 것이죠. 그런데 거기에 side effect 등이 첨가된 상태에서는 그 특징이 보다 온전하게 보이게 하기 위해서 '강타입이다'라고 증명하는게 의미가 있을 수 있겠죠.

하지만, imperative language에서 강타입이다라고 주장한다면, 요즘 같은 세상에선 "so what?' 이라는 반응이 나올 거라고 생각되는군요.

imperative language에서 강타입 언어중 하나인 Java의 예를들자면, 최근에 generics 기능이 추가되면서 ArrayList에 Stirng을 넣으려고하면 unsafe operation이라고 까지 경고해주죠. ArrayList말고 ArrayList<String> 쓰라면서. 하지만 이렇게까지 일일히 타입을 챙겨준다고해서 별다른 사용자들의 주목을 받지는 않고 있습니다. 굉장히 신경써주는덕에 굉장히 귀찮아졌음에도 불구하고.

JAVA spec에 보면 '이것이 어찌어찌해서 강타입이다'의 증명은 없죠. (VM 스펙은 본적이 없습니다. 거기엔 나와있을지도.) 반면 java.util.concurrency에서 바뀌게 된 메모리 모델의 스펙에 대한 모델 설명은 정말 길게도 늘어놓았죠. 이런 것이 현실적인 듯 하네요. 분명 타입 에러를 제대로 잡겠다는건 컴파일러와 VM을 구현하는 사람에게는 중요한 문제이고, 누군가는 이것이 제대로 돌아간다고 증명을 한번 해보고 검증도 했겠지만 아무의 주목도 받지 않게되는거죠.

플레임 워 일으킬 생각은 없지만 ML만이 강타입이라 -_-;; 는 건 참 .. 듣기 거북한 말이군요. 함수형 언어의 갈길은 '제가 강타입인데요' 라고 말하는게 아니라 그 느리고 느린 속력을 극복해서 다른 언어만큼의 인기를 누리는데 있을텐데 곁다리 친걸로 자랑하다니 -_;;

--
Passion is like genius; a miracle.

pool007의 이미지

notpig wrote:

약간 따른 이야기를 하면 지금 여러분들이 이야기하는 언어는
static typed system 입니다.
http://en.wikipedia.org/wiki/Datatype#Static_and_dynamic_typing

컴파일 시점에 타입이 결정 됩니다.

따라서 타입 오류를 컴파일 타입에 잡아낼수 있어야 합니다.

자바의 예를들죠.

Class.forName("abc.def");
이 클래스의 타입은 뭐죠? 타입이 "abc.def"라는 문자열은 아닐테니, 제 생각엔 타입이 실행시간에 결정되는듯 한데요.

Object o = Factory.getInstance(user_input);
String s = (String) o; // (1)

이 경우 o 의 타입은 뭔가요?
컴파일 시간에 정말로 (1)에서의 에러를 검출할 수 있을까요?

다음학기 PL수업도 없고, 있어도 사실 더 듣고 싶진 않지만,
아무래도 아는게 적어서인지 잘 이해는 안가는군요..
그냥 그렇다시니까 그런가보다는 하지만.. ;;

--
Passion is like genius; a miracle.

pcpenpal의 이미지

struct type1 { int x; };
struct type2 { long y; };

int main()
{
    struct type1 var1;
    struct type2 var2;
    var1 = *((struct type1 *)&var2);
    int var3;
    double var4;
    var3 = *((int *)&var4);
    return 0;
}

위에서 void와 casting을 섞어서 이것저것 나오길래...
이런 코드는 어떨까요? 이 코드도 C가 Strong-type 하지 않다는 것을 보여주는 예가 될 수 있을까요?
PL쪽 지식이 부족해서... 저 스스로는 예가 되는지 안 되는지를 잘 모르겠네요.

아, 위 코드를 컴파일해서 실행했더니 오류는 없었습니다. gcc -Wall -ansi로 컴파일 했을 때 Warning도 없었구요.

nohmad의 이미지

프로그램 언어의 타입이 강하냐 약하냐의 문제는 실제 프로그래밍을 하는 데 있어서는 그다지 유용하지 못한 논점 같습니다. 제 경험으로는 '정적'이냐 '동적'이냐가 훨씬 유용한 논점이라고 생각합니다.

C, C++, Java 같은 언어들에서 타입 정보는 변수에 정적으로 선언(하드코딩)되어 있고, 이것은 보통 컴파일 타임에 의미를 갖습니다. C의 경우를 보면 C 프로그램이 실행 중에 데이터의 타입에 기반해서 어떤 일을 하는 인터페이스가 없기 때문에 보통의 컴파일러는 최종 실행 코드를 만들 때 불필요한 타입 정보를 유지하지 않고 버려버립니다. C++ 런타임이나 JVM의 경우에는 제한적으로 실행 코드내에 런타임쪽에서 데이터의 타입을 추적할 수 있는 약간의 여지를 남겨두는 것 같습니다.

여기서 질문을 하겠습니다. C++에선 어떤 종류의 RTTI(Run Time Type Information)가 가능한가요? 그리고 위에 서지원님이 자바에서 객체의 클래스를 알고자 할 때, instanceOf(?) 같은 키워드를 통해 정적으로 비교하는 것이 아니라, 직접 클래스 이름을 알 수 있다고 하셨는데, 혹시 어렵지 않다면 예제를 보여주실 수 있나요?

Ruby나 Python 같은 언어에서는 변수가 아닌 객체, 즉 데이터 자체에 타입 정보가 들어있습니다. Ruby의 예를 들면 프로그램 상의 변수는 어떤 객체 혹은 데이터라도 담을 수 있으며, 객체의 타입 정보를 알고 싶다면 단지 class라는 메시지를 보내보면 알 수 있습니다. foo.class 또는 foo.send(:class). 프로그램이 실행 중에 CPU에게는 아무 의미가 없는 타입 정보를 들고 있어야 한다는 것은 때론 낭비일 수도 있습니다. 공간과 성능을 희생하는 대신, 프로그램을 훨씬 유연하게 할 수 있다는 장점은 있지만요. ;-)

성능 저하 외에 동적 타입 언어의 또다른 단점으로는 컴파일 타임에 발견할 수 있는 아주 기초적인 에러, 예를 들면 오타로 인한 NameError 같은 것이 실행 중에 나타나는 것을 막기 힘들다는 점입니다. 그러나 최근에는 테스트 코드를 많이 작성해서 커버리지를 높이면 어느 정도 극복가능한 문제가 되었다고 생각합니다. 테스트 주도 개발 같은 것을 보면, 확실히 동적 타입 언어와 궁합이 잘 맞는 것 같습니다.

happibum의 이미지

pool007 wrote:
Anonymous wrote:
pool007 wrote:
어줍짢은 프로그래머 wrote:

현재 과학적으로 증명된 Strong typing언어는 ML 밖에 없습니다.

음.. SEBESTA 아저씨가 틀렸다에 한표 던지시는건가요?
그러기엔 그 책이 너무 유명하죠...
가령, SEBESTA책에서 자바가 강타입이라고 설명되고 있고,
강타입에 대한 정의를 "실행시간에 타입을 알 수 있다/타입 에러를 잡을 수 있다"정도로 하고 있죠.. 제 기억이 맞다면.

과학적으로 증명 -_-;;; 은 ML 을 위키에서 찾아보면 "ML is often referred to as an impure functional language, because it permits imperative programming, and therefore, side-effects, unlike purely functional programming languages such as Haskell." 이라고되어있는데, ML 이 함수형 언어인 이상 강타입이냐 아니냐를 제대로 한번 따질 필요가 있었겠죠.

그러나 자바의 경우엔 imperative language 로, 변수나 반복문이 언어의 근간이자 핵심이므로 굳이 증명 어쩌구 할 필요도 없었을텐데요...


왜 imperative language에서는 functional language와는 달리 증명같은 것이 필요없다고 생각하시는지 궁금하네요.

음.. 말을 좀 바꾸겠습니다.
증명이 필요없다는 의미가 아니라,
증명에 관심없다로.

예를들어 함수형 언어의 대표주자중 하나인 LISP은 타입을 골치아프게 생각하는 언어가 아니죠.. 이런 상태에서 만약 "xxx 라는 functional language가 있는데 강타입이다" 라고 말하면 이건 하나의 특징적인 점이 됩니다. functional language 라는 것의 본래적인 특징은 imperative language가 가진 변수/반복문을 없애보자..라는 것이죠. 그런데 거기에 side effect 등이 첨가된 상태에서는 그 특징이 보다 온전하게 보이게 하기 위해서 '강타입이다'라고 증명하는게 의미가 있을 수 있겠죠.

하지만, imperative language에서 강타입이다라고 주장한다면, 요즘 같은 세상에선 "so what?' 이라는 반응이 나올 거라고 생각되는군요.

imperative language에서 강타입 언어중 하나인 Java의 예를들자면, 최근에 generics 기능이 추가되면서 ArrayList에 Stirng을 넣으려고하면 unsafe operation이라고 까지 경고해주죠. ArrayList말고 ArrayList<String> 쓰라면서. 하지만 이렇게까지 일일히 타입을 챙겨준다고해서 별다른 사용자들의 주목을 받지는 않고 있습니다. 굉장히 신경써주는덕에 굉장히 귀찮아졌음에도 불구하고.

JAVA spec에 보면 '이것이 어찌어찌해서 강타입이다'의 증명은 없죠. (VM 스펙은 본적이 없습니다. 거기엔 나와있을지도.) 반면 java.util.concurrency에서 바뀌게 된 메모리 모델의 스펙에 대한 모델 설명은 정말 길게도 늘어놓았죠. 이런 것이 현실적인 듯 하네요. 분명 타입 에러를 제대로 잡겠다는건 컴파일러와 VM을 구현하는 사람에게는 중요한 문제이고, 누군가는 이것이 제대로 돌아간다고 증명을 한번 해보고 검증도 했겠지만 아무의 주목도 받지 않게되는거죠.

플레임 워 일으킬 생각은 없지만 ML만이 강타입이라 -_-;; 는 건 참 .. 듣기 거북한 말이군요. 함수형 언어의 갈길은 '제가 강타입인데요' 라고 말하는게 아니라 그 느리고 느린 속력을 극복해서 다른 언어만큼의 인기를 누리는데 있을텐데 곁다리 친걸로 자랑하다니 -_;;

1. java generics에 관해,

generics가 귀찮아지기만 한것은 아니지요;;

casting을 안써도 되니까요.

그에 따라 type 안전성에 문제를 일으킬 소지가 있는 downcasting도 덜 일어나겠지요.

java가 strongly typed라지만 downcasting을 할수 있는 이상 안전성을 보장할수 없습니다.

문제가 일어날수 있는 코드를 줄일수 있다는 점만으로도 충분히 의미가 있다고 생각합니다.

2. imperative language에서의 증명

관심없으신 분들도 많지만 관심많은 사람도 있습니다.

다익스트라, 호어 등이 선구자입니다.

단지 imperative language쪽에서는 type으로 할수있는게 별로 없어서,

다른 방법(정적 분석, theorem proving 등등)으로 접근하는 경우가 많습니다.

아직 널리 쓰이고 있지는 못하지요.;;;

3. 타입 안전성 증명은 아무도 신경쓰지 않는다.

사실 증명이 스펙에 나올 필요는 없지요;;; type system rule은 나올수도 있겠지만요.

그리고 문서양이 많다고 꼭 좋은 것도 아닙니다. 자동화가 잘 된 부분일수록 문서가 적습니다.

대신 자동화 된 부분 또는 증명은 spec문서가 아니라 논문이 되겠지요.

반면 자세한 스펙 문서는 그부분이 아직 자동화되지 못해 프로그래머가 신경써줘야할 부분이라는 반증이기도 합니다.

Glasgow Haskell compiler가 곧 SMP 지원을 한다는 이야기가 나돌고 있는데, 아마 그쪽에서는 자바만큼의 동시성에 관한 문서를 제공하지 않을것입니다. 프로그래머는 예전과 다름없는 프로그래밍을 하게 될테니까요.

4. functional 언어의 성능

별로 안느리거덩요;;;;

Haskell은 솔직히 느려터졌지만 OCaml은 Java랑 비교할만합니다.

notpig의 이미지

pool007 wrote:
자바의 예를들죠.

Class.forName("abc.def");
이 클래스의 타입은 뭐죠? 타입이 "abc.def"라는 문자열은 아닐테니, 제 생각엔 타입이 실행시간에 결정되는듯 한데요.

Object o = Factory.getInstance(user_input);
String s = (String) o; // (1)

이 경우 o 의 타입은 뭔가요?
컴파일 시간에 정말로 (1)에서의 에러를 검출할 수 있을까요?

다음학기 PL수업도 없고, 있어도 사실 더 듣고 싶진 않지만,
아무래도 아는게 적어서인지 잘 이해는 안가는군요..
그냥 그렇다시니까 그런가보다는 하지만.. ;;

제가 잘못알고 있는걸수도 있지만
Object 와 String 는 같은 타입입니다...

다만. Object 를 String 에서 상속받은 상속 관계가 있을뿐이지요.

Class.forName("abc.def");

의 결과값의 타입은 Class 입니다.
String 은 Object 를 상속받은 다른 클래스일뿐 다른 타입은 아닌걸로 알고 있습니다.

제가 알고 있는게 틀릴수도 있으니 좀더 자세한건 주말쯤에 자료를 살펴보고 다시 글을 올리죠~

pool007의 이미지

notpig wrote:
pool007 wrote:
자바의 예를들죠.

Class.forName("abc.def");
이 클래스의 타입은 뭐죠? 타입이 "abc.def"라는 문자열은 아닐테니, 제 생각엔 타입이 실행시간에 결정되는듯 한데요.

Object o = Factory.getInstance(user_input);
String s = (String) o; // (1)

이 경우 o 의 타입은 뭔가요?
컴파일 시간에 정말로 (1)에서의 에러를 검출할 수 있을까요?

다음학기 PL수업도 없고, 있어도 사실 더 듣고 싶진 않지만,
아무래도 아는게 적어서인지 잘 이해는 안가는군요..
그냥 그렇다시니까 그런가보다는 하지만.. ;;

제가 잘못알고 있는걸수도 있지만
Object 와 String 는 같은 타입입니다...

다만. Object 를 String 에서 상속받은 상속 관계가 있을뿐이지요.

Class.forName("abc.def");

의 결과값의 타입은 Class 입니다.
String 은 Object 를 상속받은 다른 클래스일뿐 다른 타입은 아닌걸로 알고 있습니다.

제가 알고 있는게 틀릴수도 있으니 좀더 자세한건 주말쯤에 자료를 살펴보고 다시 글을 올리죠~

죄송. Class.forName("abc.def").newInstance() 를 하려고 했었는데 실수했네요.
그러나 이 코드를 썼어도 Object 라고 답하실 듯.. (맞는지요?)

그러나 제겐 그냥 모든 것의 타입이 Object라고 말해버리는건 웬지 정당하지 않아보이네요...;; 각자의 타입이 별개고 Object를 상속했다고 말하는 것과는 다르니까요..

--
Passion is like genius; a miracle.

익명 사용자의 이미지

"자신에게 가치가 없다고 해서 다른 사람에게도 가치가 없으리라고 생각하는 것은 성급한 판단입니다."

제 글을 어떻게 이해를 하셨는지는 모르겠지만, 가치가 없다는 말은 한마디도 하지 않았습니다.

다만 생각을 해보자는 얘기였지요......

이 주제는 프로그래밍 언어론에 관한 책이라면 거의 다루고 있는 문제입니다.

그만큼, 오랫동안 거론이 되어왔고 연구가 되어온 주제입니다.

그리고 여기에 글을 쓰시는 분 중에 이 주제에 관한 심도있는 연구를 하신 분이 있으신지 궁금하군요.

그냥 책 몇자 읽고 토의를 할 문제는 아니라고 생각합니다.

저 역시 심도있는 연구를 해 본 적은 없습니다.

다만 이런 문제를 토의거리로 삼고자 한다면 좀 더 전문적인 내용을 올리시는게 좋지 않을까 합니다.

impactbar의 이미지

nohmad wrote:

여기서 질문을 하겠습니다. C++에선 어떤 종류의 RTTI(Run Time Type Information)가 가능한가요? 그리고 위에 서지원님이 자바에서 객체의 클래스를 알고자 할 때, instanceOf(?) 같은 키워드를 통해 정적으로 비교하는 것이 아니라, 직접 클래스 이름을 알 수 있다고 하셨는데, 혹시 어렵지 않다면 예제를 보여주실 수 있나요?

public class CheckType
{
	public String returnClassName()
	{
		return this.getClass().getName();
	}
	static public void main(String[] args)
	{
		CheckType ct = new CheckType();
		System.out.println(ct.returnClassName());
	}
}

동적 바인딩 즉 리플렉션을 사용하면 실행시간 단계에서 객체의 정의 부터 사용까지 모두 가능합니다.

xster의 이미지

어줍짢은 프로그래머 wrote:
그리고 여기에 글을 쓰시는 분 중에 이 주제에 관한 심도있는 연구를 하신 분이 있으신지 궁금하군요.

그냥 책 몇자 읽고 토의를 할 문제는 아니라고 생각합니다.

저 역시 심도있는 연구를 해 본 적은 없습니다.

다만 이런 문제를 토의거리로 삼고자 한다면 좀 더 전문적인 내용을 올리시는게 좋지 않을까 합니다.

전문적인 내용을 모르는 상태에서의 토의라고 해서 토의할 필요가 없다고 생각하지 않습니다.
비록 무지하고 단편적인 지식밖에 가지고 있지 않지만
토의를 하는 동안 다른 사람들의 지식을 습득하여 자신의 지식을 조금이라도 늘릴 수 있겠죠.
또 각자의 생각이 다른만큼 비전문가들의 토의도 의미가 있다고 생각합니다.
초등학생들, 중학생들, 고등학생들이 학교에서 토의하는 것을 모두 다 어린 것들의 흉내내기라고 무시할 수만은 없지 않겠습니까?

doldori의 이미지

nohmad wrote:
여기서 질문을 하겠습니다. C++에선 어떤 종류의 RTTI(Run Time Type Information)가 가능한가요?

어떤 종류라고 말씀드려야 할지는 모르겠지만 크게 2가지가 있습니다.

1. typeid 연산자와 type_info 클래스
typeid는 type_info 개체를 반환하고, type_info::name()은 피연산자의 이름을
반환합니다. (구체적인 이름은 구현체에 따라 달라질 수 있습니다.)

#include <typeinfo>

const char* typeName = typeid(typeName).name();

2. dynamic_cast
다형적인 클래스 사이의 downcasting에 주로 씁니다.

doldori의 이미지

어줍짢은 프로그래머 wrote:
제 글을 어떻게 이해를 하셨는지는 모르겠지만, 가치가 없다는 말은 한마디도 하지 않았습니다.

다만 생각을 해보자는 얘기였지요......


그렇군요. 토론할 의미가 없다는 말씀과 헷갈렸습니다.
아니, 정확히 말하면 "의미가 없는 것 같다"로군요. :?

어줍짢은 프로그래머 wrote:
"C, C++언어 모두 Strong typing 언어가 아니다."라는 주제는 토론할 의미가 없는것 같네요.
nohmad의 이미지

impactbar wrote:
public class CheckType
{
	public String returnClassName()
	{
		return this.getClass().getName();
	}
	static public void main(String[] args)
	{
		CheckType ct = new CheckType();
		System.out.println(ct.returnClassName());
	}
}

제가 생각한 건 이런 거였는데, 잘 되는군요.

class RunTimeTypeInfo
{
    public static void printClassName(Object instance)
    {
        System.out.println(instance.getClass().getName());
    }
    public static void main(String[] args)
    {
        RunTimeTypeInfo rtti = new RunTimeTypeInfo();
        printClassName(rtti);
    }
}
차리서의 이미지

어줍짢은 프로그래머 wrote:
그리고 여기에 글을 쓰시는 분 중에 이 주제에 관한 심도있는 연구를 하신 분이 있으신지 궁금하군요.

찔끄음! :shock: (그나마 조용히 숨어있던) 사람 가슴에 대못을 아주 제대로 박으시는군요. :cry:

“글타래의 원래 주제어인 C와 C++을 너무 몰라서”라는 구차한 핑계로 글타래에 끼어들지 않고 그저 잠자코 읽기만 했었는데, 정직하게 실토하자면, 제가 내걸은 간판이 간판인지라 오히려 섣불리 끼어들기가 두려워서 숨죽이고 있었던게 사실입니다. 명색이 타입 이론 연구한다는 사람이 쥐뿔도 모른다는게 뽀록날까봐 숨어있었던거죠. (PL 쪽 기반 위에서 진행하는 연구가 아니라 증명 이론 쪽을 공부하다가 넘어온거라서 더더욱 모르는 것만 잔뜩 널려있습니다.)

심도있는 연구를 ‘하분’에는 아직 해당되지 않지만 ‘하분’에는 해당되고 싶군요. :)

PS: 저로서는 이 글타래를 흥미롭게 잘 읽고있고 나름대로 여러가지 얻어가고 있습니다. 꼭 100% 정확한 정보와 올바른 논증만이 오가야만 의미있는 토론인 것은 아닙니다. 단편적인 미확인 정보와 편향된 주장이 종종 섞여있다고 해도, 읽는 방법에 따라서는 얼마든지 여러가지를 배울 수 있거든요.

--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!

sequoia의 이미지

강한 타입 언어는 말 그대로 타입 체크를 컴파일 타임에 엄격하게 하여 대부분의 오류를 컴파일 타임에 잡아내자는 의도로 설계된 언어이지요. ML은 강한 타입 언어의 가능성을 타진하기 위해 만들어진 연구용 언어이므로 강한 타입 언어의 정의를 거의 완벽하게 지키려고 노력하고 있는 언어입니다.

반면, 써보시면 알겠지만 강한 타입 언어는 가끔 타입 체크의 제약때문에 코딩이 길어지거나 귀찮아지는 경우가 많이 있지요. (그런 부분에서의 고민이 코드에서의 오류를 현저하게 줄여주긴 합니다만.) 자바나 C/C++은 강한 타입 언어를 표방하고 만들어진 언어이지만, 어디까지나 연구용이 아니라 필드에서 활용하기 위해 만들어진 실용 언어이므로 강한 타입 언어의 제약이 지나치게 생산성을 저하시킨다고 생각되는 부분에 암묵적인 형변환이나 런타임 타입 체크와 같은 타입 체크를 약하게 만드는 스펙을 도입했다고 보면 됩니다.

누군가 C/C++은 강한 타입 언어가 아니라고 말한다면, 그저 강한 타입 언어의 엄격한 정의에는 정합하지 않는 스펙이 몇 개 있을 뿐인 것이죠. 이건 완전히 이론적인 문제고 실용적인 것과는 거리가 먼 이야기인데요. -_-; C/C++은 강한 타입 언어로 설계되었지만 실용성을 위해 강한 타입 언어의 특징을 스스로 포기한 부분이 많이 있으니까요. 이건 Java도 마찬가지고..

그리고 위에 누군가 '런타임에 타입 체크를 할 수 있으면 강한 타입 언어이다'라고 말씀하셨는데 그건 완전히 틀린 정의가 아닌가요? 인터프리터 방식의 스크립트 언어는 빠르고 간편한 구현을 목표로 하기 때문에 컴파일 타임부터 사소한걸로 딴지거는 강한 타입 언어보다는 처음부터 약한 타입 언어로 설계되는 경우가 많지요.

lovewar의 이미지

Quote:

tokigun 씀:

1. 만약 어떤 언어에서 형 선언이 값 혼자가 아닌 변수에 선언되어 있으면 강형 언어이고, 값에만 형이 연결되어 있으면 약형 언어이다. (정확한 용어는 정적 형 선언과 동적 형 선언이다.)
2. 만약 어떤 언어가 컴파일 시간에 형 제한 위반에 대한 체크를 한다면 강형 언어이고, 모든 체크가 실행 시간에 이루어지면 약형 언어이다.
3. 만약 어떤 언어가 컴파일 시간 또는 실행 시간에 형 제한 위반에 대한 체크를 한다면 강형 언어이고, 아무 체크도 하지 않는다면 약형 언어이다.
4. 만약 어떤 언어에서 서로 다른 형 사이의 변환이 금지되어 있으면 강형 언어이고, 그러한 변환이 허용되면 약형 언어이다.
5. 만약 어떤 언어에서 서로 다른 형 사이의 변환이 항상 명시적으로 지정되어 있어야 한다면 강형 언어이고, 묵시적인 변환이 허용된다면 약형 언어이다.
6. 만약 어떤 언어에서 형 체계를 비활성시키거나 피해 가는 언어 수준에서의 방법이 존재하지 않으면 강형 언어이고, C 스타일의 캐스팅이나 다른 방법들이 존재하면 약형 언어이다.
7. 만약 어떤 언어가 복합 형에 대해서 복합적이고 잘 정의된 형 체계를 갖추고 있다면 강형 언어이고, 적은 수의 형이나 스칼라 형만이 존재할 경우 약형 언어이다.
8. 만약 어떤 언어에서 어떤 객체의 형이 고정되어 있고 객체의 생존 시간 동안에 변하지 않는다면 (보통 "정적 형 선언"이라 부름) 강형 언어이고, 그 형이 변할 수 있다면 약형 언어이다.
9. 만약 어떤 언어의 형 체계가 실행 시간에서의 행동에 대해 강한 보장을 한다면 강형 언어이고, 그러한 보장을 하지 않는다면 약형 언어일 가능성이 높다.

위 정의를 기반으로 각 언어의 성격을 정리하는 것이 이해(증명)시키는데 도움이 될 것이며 심도있는 토론 또한 이루어질 것입니다.

-- 덧붙이는 글 --

아래 참고의 일부를 번역하였습니다.

예를 들면, 정의 1,7 그리고 8하에서는 C 언어는 strongly-typed language 이며, 정의 4, 5 그리고 6번하에서는 weakly-typed language 이다.

참고 : http://www.absoluteastronomy.com/encyclopedia/S/St/Strongly-typed_programming_language.htm

차리서의 이미지

이 글타래에서 자주 등장하는 ‘증명’의 목적어가 조금 이상해서 확인하고 싶습니다. 제가 주로 접해온 증명은 대개 세 가지였습니다:

  1. (임의의 언어로 작성한) 이 프로그램은 명세한 설계 대로 동작함을 이렇게 증명합니다.
  2. 이 프로그래밍 언어로 (임의의) 프로그램을 작성하면 어떤 경우에도 타입 오류가 없음을 이렇게 증명합니다.
  3. 이 프로그래밍 언어에 적용된 타입 시스템, 즉 타이핑 룰들이 sound함을 이렇게 증명합니다.
이 글타래에서 “이 프로그래밍 언어는 강타입 언어임을 이렇게 증명합니다”라는건 어떤 의미인가요? 타입 시스템의 엄격함을 논한다는 차원에서 보자면 아마도 위 3번과 2번을 연이어 증명하는 행위와 가장 비슷하지 않을까 생각됩니다만…….

pool007 wrote:
음.. 말을 좀 바꾸겠습니다.
증명이 필요없다는 의미가 아니라,
증명에 관심없다로.

예를들어 함수형 언어의 대표주자중 하나인 LISP은 타입을 골치아프게 생각하는 언어가 아니죠.. 이런 상태에서 만약 "xxx 라는 functional language가 있는데 강타입이다" 라고 말하면 이건 하나의 특징적인 점이 됩니다. functional language 라는 것의 본래적인 특징은 imperative language가 가진 변수/반복문을 없애보자..라는 것이죠. 그런데 거기에 side effect 등이 첨가된 상태에서는 그 특징이 보다 온전하게 보이게 하기 위해서 '강타입이다'라고 증명하는게 의미가 있을 수 있겠죠.

하지만, imperative language에서 강타입이다라고 주장한다면, 요즘 같은 세상에선 "so what?' 이라는 반응이 나올 거라고 생각되는군요.


공교롭게도 유독 함수형 언어 중에 강타입 (혹은 type-safe한) 언어가 많은 이유는 (즉, type-safe한 언어의 대부분이 함수형 언어인 이유는) 단지 함수형 언어의 근간을 이루는 ‘함수형 계산모델’의 특성 상 타입 이론을 적용하기가 무척 용이했기 때문이었을 뿐이라고 알고있습니다. λ-calculus의 코어를 해치지 않으면서도 아주 우아하게 typed λ-calculus를 논할 수 있으니까요.

반대로 말하자면, 절차형 언어 중에 type-safe한 언어가 드문 것은 절차형 언어에 타입을 적용하기가 여러모로 껄끄러웠기 때문일 뿐, 결코 절차형 언어의 type safety를 논할 필요가 없어서가 아니었다는 뜻입니다. 실제로 적지 않은 사람들이 지금도 절차형 언어에 타입 이론을 적용하려고 노력하고 있습니다. 특히, 물리적인 기계의 작동이 여전히 절차형 계산 모델에만 의존하고 있는 현재로서는 함수형 언어로 프로그램을 작성해도 결국 극단적인 절차형 언어인 기계어로 번역(컴파일)해야하기 때문에, 기계어로 컴파일하는 동안 소중한 타입 정보를 놓치지 않고 간직하기 위한 연구도 큰 이슈입니다. 예를 들어 아쯔시 오호리가 기계어에 대한 증명 이론에 관해 쓴 글은 아주 흥미롭습니다. (읽어보시면 제목과 내용의 연결이 조금 이상하다는 느낌이 드실텐데, 정확히는 type-safe한 컴파일레이션 이론입니다. 결국 그 말이 그 말이긴 합니다만…….)

pool007 wrote:
플레임 워 일으킬 생각은 없지만 ML만이 강타입이라 -_-;; 는 건 참 .. 듣기 거북한 말이군요. 함수형 언어의 갈길은 '제가 강타입인데요' 라고 말하는게 아니라 그 느리고 느린 속력을 극복해서 다른 언어만큼의 인기를 누리는데 있을텐데 곁다리 친걸로 자랑하다니 -_;;

실험실 언어나 논문 레벨의 언어까지 따지면 세상에 언어가 얼마나 많은데 설마 ML 하나 뿐이겠습니까? 게다가 ML의 짧지 않은 역사와 그간의 파생력으로 미루어보아 아무래도 ML만이 강타입일 것 같지는 않습니다만, 정직하게 말하자면 ML만일지 아닐지 확인해본 적이 없어서 전혀 모르겠습니다.

그보다는 오히려, 저로서는 ‘곁다리’라는 표현이 거북스럽습니다.

함수형 언어의 속도나 메모리 소모를 개선하는 문제도 물론 큰 이슈이고 실제로 많은 곳에서 활발히 연구되고 있습니다만, 그렇다고 해서 그것만이 함수형 언어 세계의 핵심 사안이라는 발언에 대해서는 오히려 이를 연구하고 있는 학자들조차도 동의해주지 않을겁니다. (학자들은 대단히 공정한 사람들이랍니다.) 비록 순수성은 떨어진다고 하지만 흔히 함수형 언어의 모태격으로 인정되는 LISP의 시대부터, 이미 함수형 언어의 기본적인 비전은 다분히 고수준 언어를 지향하는 것이었습니다. 오히려, 고수준 언어로서의 장점과 함수형 계산모델의 특징을 일부 버리면서까지 절차형 기계 위에서의 효율을 높이는 것과, 효율을 일부 포기해서라도 고수준 언어로서의 장점과 함수형 계산모델의 특징을 유지하는 것 중 하나를 택하라면, 적지 않은 사람들이 후자를 택할겁니다. 정 고효율이 필요한 계산을 프로그래밍해야할 경우라면, 그저 절차형 기계의 인스트럭션 셋으로 쉽고 군더더기 없이 변환(컴파일)되는 절차형 언어 중에서도 기계어에 적당히 근접한 중저수준 언어를 선택하면 그만이니까요.

많은 인기를 얻어 실세계에 다양하게 쓰이는 것도 당연히 중요하겠지만, 이 역시 함수형 언어의 유일한 비전이라는 데에는 동의할 사람이 거의 없을겁니다. 애초에 함수형 언어는 전통적인 수학의 계산 모델(즉, 함수형 계산 모델)을 그대로 사용해서 계산을 명령하자(프로그래밍하자)는 취지였기 때문에, 그것이 필요한 곳에서 적절하게 쓰이면 그만입니다. 그리고 절차형 언어의 type safety가 난관에 봉착한 채 더딘 발걸음을 보이고 있는 현재로서는, type safety를 보증받기에 태생적으로 매우 적절한 함수형 언어가 자신이 잘하는 영역에 치중하고 있는 현상을 ‘곁다리 친 것’으로 보기는 더더욱 어렵습니다.

[/]

--
자본주의, 자유민주주의 사회에서는 결국 자유마저 돈으로 사야하나보다.
사줄테니 제발 팔기나 해다오. 아직 내가 "사겠다"고 말하는 동안에 말이다!

sequoia의 이미지

ML은 현존하는 언어중에서 가장 강한 타입 언어입니다. (아 강하다.. -_-)

컴파일 에러만 잡으면 런타임 에러는 물론 로직 에러가 거의 사라져버리는 언어였죠.. -_-;

익명 사용자의 이미지

pool007 wrote:

플레임 워 일으킬 생각은 없지만 ML만이 강타입이라 -_-;; 는 건 참 .. 듣기 거북한 말이군요. 함수형 언어의 갈길은 '제가 강타입인데요' 라고 말하는게 아니라 그 느리고 느린 속력을 극복해서 다른 언어만큼의 인기를 누리는데 있을텐데 곁다리 친걸로 자랑하다니 -_;;

어떤 기준으로 함수형언어가 느려 터졌다고 생각하나요?
ocaml, sml(mlton컴파일러에서), clean같은 언어는 결코
느리지 않습니다. 메모리사용도 생각보다는 꽤 효율적입니다.
물론 님이 c도 너무 느리다고 하신다면 별로 할말이 없지만.....

익명 사용자의 이미지

참고.

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=clean&sort=fullcpu

http://shootout.alioth.debian.org/benchmark.php?test=all&lang=mlton&sort=fullcpu

summary부분을 참고하세요.

물론 이런벤치마킹이 어떤 큰의미는 가지지 못할지라도.....

creativeidler의 이미지

strong typing vs weak typing이 아니기에 약간 논외이긴 하나 이 문제에 관심 있는 분이 많이 모여든 것 같기에-_- 질문 하나 던져 봅니다.

혹시 strong typing이 실질적인 버그 발생율을 감소시킨다거나 생산성을 향상시킨다는 연구 자료를 갖고 있으신 분이 있나요? 아시는 분 있으면 링크 걸어주시면 감사하겠습니다.

knight2000의 이미지

strong typing...

굳이 해석한다면... 엄격한 형검사...이네요.

strong-typed : 형검사가 엄격한... 정도 되고요.
type이 '형'이 아니라 '형식을 검사하다'라는 동사였네요.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

kyagrd의 이미지

하지만 C의 대부분을 포함하기 때문에 C에서 하던 모든 뻘짓이 다 된다는 큰 단점인 동시에 장점이 있지요.

--
There's nothing so practical as a good theory. - Kurt Lewin

--
There's nothing so practical as a good theory. - Kurt Lewin
"하스켈로 배우는 프로그래밍" http://pl.pusan.ac.kr/~haskell/

cup의 이미지

ㅎㄷㄷㄷㄷㄷ

roth2520의 이미지

C언어에서 bool이랑 int는 서로 통용가능하지 않나요

java

cppig1995의 이미지

C에는 bool이라는 자료형 자체가 없어요. (다만 C99에 _Bool이 있을 뿐.)
혹시 while(a) 같은 거 가지고 말씀하시는 거라면, while(a == 1)에서 "a == 1"도 자료형이 int라고 말씀드립니다.
(C가 무슨 C++인 줄 아십니까?)

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.