| 이전 주제 보기 :: 다음 주제 보기 |
| 글쓴이 |
메시지 |
박성희
가입: 2025년 3월 13일
올린 글: 11
|
 올려짐: 2025년6월13일 20:02 주제: [숙제 8] Exercise 1 관련 질문입니다. |
 |
|
안녕하세요, 프로그래밍언어 수강중인 2021-15632 박성희입니다.
8-1을 검토해보던 중 아래와 같은 프로그램을 생각해 보았습니다.
| 코드: | let val f = (malloc 44; fn x=>x) in
(f 1, f false)
end |
강의 자료에 따르면 이 프로그램은 f를 실행할 때 메모리 주소를 할당받게 될 것입니다. 따라서 다형 타입을 따를 수 없고 타입 체크 에러를 발생시켜야 할 것 같다고 생각하였습니다. 그런데, VSIX 상에는 이 타입이 (int, bool)로 결정이 되는 것으로 보입니다.
물론 이 코드를 Dynamic type checking을 통해 타입을 판단하면 명백히 (int, bool)임을 생각할 수 있지만 지금 배운 Static type checking에서의 안전한 추론 방식으로는 이러한 부분을 설명할 수 없을 것 같은데, 혹시 이러한 논리에 오류가 있을까요?
감사합니다. |
|
| 위로 |
|
 |
정원준
가입: 2025년 3월 5일
올린 글: 13
|
| 올려짐: 2025년6월14일 14:28 주제: |
|
|
안녕하세요, 수강생 정원준입니다.
malloc이 반환한 loc이 어디에도 할당되지 않아 이후 사용될 가능성이 없기 때문이 아닐까요?
이렇게 되면 결과가 다르지 않을까요? |
|
| 위로 |
|
|
박성희
가입: 2025년 3월 13일
올린 글: 11
|
| 올려짐: 2025년6월14일 16:25 주제: |
|
|
안녕하세요, 일단은 과제의 공식 제출 시점은 지나긴 했지만...
물론 저러한 코드가 malloc의 loc가 어디에도 할당되지 않기 때문에 말씀해 주신 부분이 맞긴 합니다만... (당연히 '코드'의 내용은 다형 타입 추론을 하면 안 될 것 같긴 한데)
Static Type Checking에서 "이후 사용될 가능성을" 확인할 방법이 딱히 있나 싶습니다.
일단 let에서 id를 지정하고 그게 호출되었을 때 malloc을 쓰는 것은 사실이니까요. 세미콜론이 조금 걸리긴 하는데 꼭 세미콜론 앞에 있는 내용물들을 아예 안 쓴다는 보장(?)도 없지 않나요? (저런 걸 다형추론한다고 했을 때 안전성이 깨지지 않을 까 하는 생각이 들긴 합니다.)
일단 강의 자료에는
| 인용: | | 식 E가 실행 중에 메모리 주소를 새롭게 할당받는 일이 없는 경우에만 안전하다 |
고 되어 있어서 저 E는 일단 실행 중에 메모리 주소를 할당받으니까 안전하지는 않다라고 판단을 내렸었는데요.
일단 메모리 반응식이 들어가거나 돌아간다고 의심되는 것 (?)을 거르는 현 상황의 문제에서는 이러한 프로그램을 걸러야 하지 않을까 싶습니다...
expansive에서 apply에 대해 항상 true인 것도 apply 했을 때 그 함수 안에 있는 메모리할당이 갑자기 튀어나올 가능성을 배제하기 위함인 것과 비슷하다고도 생각이 듭니다.
비슷한 맥락인 거 같은데 아래 코드도 malloc 1은 실제로 binding은 되지 않지만 M Extension(다형타입추론기)상에서는 오류를 발생시킵니다.
| 코드: | let val r = malloc(malloc (fn x => x))
val id = ((malloc 1, fn x=>x).2) in
(id 1, id false)
end
|
|
|
| 위로 |
|
|
오규혁
Site Admin
가입: 2022년 3월 15일
올린 글: 88
|
| 올려짐: 2025년6월14일 17:26 주제: |
|
|
안녕하세요,
말씀하신 방식으로 타입 추론을 하면 안정성을 해치는 것은 아니지만 타입 추론의 정확성이 떨어지게 됩니다.
메모리 할당이 있는 경우에 let식의 타입 추론에서 다형 타입이 어떻게 타입 추론의 안정성을 해칠 수 있는지 생각해보는 것이 좋을 것 같습니다.
+ 주어진 프로그램은 int, bool이라고 안전하게 타입 추론할 수 있습니다
조교드림
_________________
TA 오규혁
e-mail: ghoh@ropas.snu.ac.kr |
|
| 위로 |
|
|
정원준
가입: 2025년 3월 5일
올린 글: 13
|
| 올려짐: 2025년6월14일 19:25 주제: |
|
|
"이후 사용될 가능성을" 확인하기 어렵기 때문에
의 경우는 expansive = true이고,
의 경우는 expansive = false라고 생각합니다. 바깥에서 어떤 행동을 하더라도 안쪽의 malloc으로 생긴 loc을 참조할 방법이 없으니까요.
| 코드: |
let val r = malloc(malloc (fn x=>x))
val id = (r := malloc (fn x=>x+1); fn x=>x) in
(!!r) true
end
|
이런 경우는 (r := malloc (fn x=>x+1); fn x=>x)에서 생긴 malloc이 바깥에서 참조될 가능성이 있긴 한데.. 이건 r의 polyporphism이지 id의 generalization을 결정하는 것과 상관이 없어 괜찮을 것 같습니다. |
|
| 위로 |
|
|
오규혁
Site Admin
가입: 2022년 3월 15일
올린 글: 88
|
| 올려짐: 2025년6월14일 22:05 주제: |
|
|
좋은 예시인 것 같습니다.
안쪽의 malloc으로 생긴 loc이 참조되는 여부보다 후자 예시처럼 메모리 할당과 그 메모리 할당이 어떤 영향을 줄 수 있는지 생각하시면 좋을 것 같습니다.
_________________
TA 오규혁
e-mail: ghoh@ropas.snu.ac.kr |
|
| 위로 |
|
|
박성희
가입: 2025년 3월 13일
올린 글: 11
|
| 올려짐: 2025년6월14일 23:27 주제: |
|
|
두 분이 말씀하시는 부분에 따라 '그냥 버려기는 malloc'을 상관하지 않고 다형으로 인식하게 하여 Static type checker 안전하게 체킹을 하려면
M언어의 E1;E2에서 E1에서 메모리가 할당된 부분은 let에서 새로 정의하는 "id에 대해서 참조할 방법이 없다"는 것이 엄밀하게 증명된다는 전제 하에 좀 더 안전하지만 유연한 추론 규칙을 완성할 수 있을 것 같네요.
과제 할 때도 이 부분에 대해서 고민해 본 거 같긴 한데, function으로 따로 바인딩이 안된 malloc이 들어가는 경우 언제나 위험성이 있어서 안전성을 우선적으로 확보하기 위해서 expansive를 true로 잡긴 했는데 항상 그런 건 아닌가 봅니다.
(여전히, 앞선 계열의 E1;E2의 E1부분에 malloc이 들어가는 메모리 할당구문으로 인해 문제를 일으킬 여지가 있지는 않을 지 의심스러운 부분이 있긴 합니다. 없다는 것을 증명하면 참 좋을 텐데 좀 더 생각해 보겠습니다.)
여튼, 답변을 통해 다형 타입에 대해서 좀 더 깊이 생각할 수 있었던 것 같습니다. 한 학기 동안 수고하셨고, 두 분 모두 감사드립니다! |
|
| 위로 |
|
|
오규혁
Site Admin
가입: 2022년 3월 15일
올린 글: 88
|
| 올려짐: 2025년6월14일 23:47 주제: |
|
|
부연 설명을 조금 더 해보자면 let x = E in E' 일 때 x가 다형 타입이 가능한지 확인하는 것 입니다.
그것에 영향을 줄 수 있는지 생각해보시면 될 것 같습니다.
_________________
TA 오규혁
e-mail: ghoh@ropas.snu.ac.kr |
|
| 위로 |
|
|
|
FAQ
검색
멤버리스트
사용자 그룹
사용자 등록하기
개인 정보
비공개 메시지를 확인하려면 로그인하십시오
로그인
