이전 주제 보기 :: 다음 주제 보기 |
글쓴이 |
메시지 |
윤상필
가입: 2005년 9월 25일 올린 글: 14 위치: 아스트랄계
|
올려짐: 2005년10월1일 22:46 주제: semantics가 정의되지 않은 부분이 많습니다. |
|
|
강의시간에 점차로 새 개념들을 도입하면서 진행해 왔기 때문에 구현해야 할 정확한 semantics를 알 수 없는부분들이 많습니다. 예를 들자면
- ASSIGN의 값이 UNIT인지 아니면 대입되고 있는 값인지
- SEQ의 값이 UNIT인지 아니면 맨 마지막 exp의 값인지
- IF1의 경우 조건이 거짓일 때는 UNIT타입이 되는 걸 상식적으로 알 수 있겠지만 조건이 참일 때도 UNIT을 가지는지 아니면 then 절의 evaluate된 결과를 가지는지 여부.
- IF2의 값이 UNIT인지 아닌지
- IF1, IF2의 경우 조건절에서 변화시킨 메모리가 then 절에도 영향을 미치는지 여부
- WHILE의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
- FOR의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
- FOR의 경우 C++처럼 루프 변수의 바인딩이 새로 정의되는지, 아니면 기존에 있는 바인딩을 사용하게 되는지 여부
- READ의 경우 어떤 소스에서 값을 읽어들이는지
등이 있습니다. 각각의 경우 어떻게 구현해야 할지 알려 주셨으면 합니다. |
|
위로 |
|
|
김덕환
가입: 2005년 8월 29일 올린 글: 190
|
올려짐: 2005년10월1일 23:32 주제: Re: semantics가 정의되지 않은 부분이 많습니다. |
|
|
윤상필 씀: | 강의시간에 점차로 새 개념들을 도입하면서 진행해 왔기 때문에 구현해야 할 정확한 semantics를 알 수 없는부분들이 많습니다. |
EQUAL의 경우처럼 의미를 어떻게 정의하는 게 좋을지 토론이 이루어졌으면 좋겠습니다. 어떤 방안들이 있을지, 각 방안의 장점과 단점은 무엇인지, 결과적으로 가장 합리적인 방안은 무엇인지 얘기해 봅니다. 제가 수업을 들었을 때, 이 숙제가 좋은 언어 디자인이란 무엇인지 고민해볼 수 있는 좋은 기회가 되었습니다. 조교는 가능하면 조정자의 역할만 하려고 하지만, 재미있는 논의를 지켜보게 되면 참지 못하고 불쑥 끼어들지도 모릅니다.
꼭 얽매일 필요는 없지만, 앞으로 이 언어에 타입 시스템과 가비지 컬렉션 등이 추가될 것이라는 염두에 두시면 좀더 재미있는 토론이 될 거라고 봅니다. _________________ TheyAreAsSmartAsYouAre |
|
위로 |
|
|
윤상필
가입: 2005년 9월 25일 올린 글: 14 위치: 아스트랄계
|
올려짐: 2005년10월2일 0:24 주제: |
|
|
음.. 토론은 토론이고 채점은 하셔야 할텐데(그것도 심지어 기계로) 설마 스펙을 토론 결과로 정하는 건 아니겠죠? ㅡ_ㅡ |
|
위로 |
|
|
윤상필
가입: 2005년 9월 25일 올린 글: 14 위치: 아스트랄계
|
올려짐: 2005년10월2일 0:36 주제: |
|
|
스태틱 타입 체크 상황을 가정할때 3번의 경우 조건이 참이든 아니든 타입이 같아야 하므로 UNIT이 맞을 것 같습니다.
4번의 경우 then절과 else절의 타입이 다를 경우 (exp; ()) 형식으로 UNIT 으로 바꿔 줄 수 있기 때문에 상황에 따라 then절 또는 else절의 값을 가지는 게 맞을 것 같습니다. 이 경우 3번을 고려할 때 같은(실제로는 다르지만) if문인데 일관되지 못하다고 볼 여지가 있군요.
5번은 가만 생각해보니 영향을 안 미치는 게 더 이상할 듯합니다. |
|
위로 |
|
|
윤상필
가입: 2005년 9월 25일 올린 글: 14 위치: 아스트랄계
|
올려짐: 2005년10월2일 0:37 주제: |
|
|
또 하나 애매한 것이 있습니다.
10. READ의 대상 변수가 unbound일 경우 입력을 받은 다음 raise Error하는지 아니면 받은 후에 하는지 |
|
위로 |
|
|
김덕환
가입: 2005년 8월 29일 올린 글: 190
|
올려짐: 2005년10월2일 0:45 주제: |
|
|
윤상필 씀: | 음.. 토론은 토론이고 채점은 하셔야 할텐데(그것도 심지어 기계로) 설마 스펙을 토론 결과로 정하는 건 아니겠죠? ㅡ_ㅡ |
토론이 이상한 결론으로 흘러가는 경우를 걱정하고 계신 건지, 조교가 어떻게 채점을 할 것인지를 걱정해주시는 건지 잘 파악되지 않아 둘 다에 대해 답변 드립니다.
스펙은 기본적으로 토론 결과를 따를 겁니다. 토론이 대부분 올바른 결론에 도달할 거라고 믿으며, 그렇지 못하다고 판단되면 말씀드린 대로 토론에 끼어들어 조정하겠습니다. 그리고, 어느 정도 토론이 수렴되었다고 판단되면 혼란이 없도록 의미 정의를 정식으로 공표하도록 하겠습니다.
그리고, 기계 채점은 토론을 통해 의미 정의가 명확하게 정해지면 전혀 문제가 없다고 생각하고 있습니다. 제가 놓치고 있는 부분이 있나요? _________________ TheyAreAsSmartAsYouAre |
|
위로 |
|
|
서상원
가입: 2005년 9월 27일 올린 글: 33
|
올려짐: 2005년10월2일 1:15 주제: Re: semantics가 정의되지 않은 부분이 많습니다. |
|
|
지금 생각나는 것들만 nML 스타일로 정의해보면
윤상필 씀: |
- SEQ의 값이 UNIT인지 아니면 맨 마지막 exp의 값인지
|
마지막 exp
윤상필 씀: |
- IF1의 경우 조건이 거짓일 때는 UNIT타입이 되는 걸 상식적으로 알 수 있겠지만 조건이 참일 때도 UNIT을 가지는지 아니면 then 절의 evaluate된 결과를 가지는지 여부.
- IF2의 값이 UNIT인지 아닌지
|
e1과 e2의 타입을 같게.
즉 IF1은 UNIT 타입, IF2는 같은 타입이고 그 값을 반환.
윤상필 씀: |
- WHILE의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
- FOR의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
|
마지막 계산된 값.
이 정도로군요. nML과 정확히 동일하지는 않을 수 있습니다. 그냥 지금 제가 보기에 그럴싸해 보이도록 적은 거니까요.
좀 더 정확한 사항들은 앞으로 토론 과정에서 정해지겠지요. |
|
위로 |
|
|
윤상필
가입: 2005년 9월 25일 올린 글: 14 위치: 아스트랄계
|
올려짐: 2005년10월2일 1:16 주제: |
|
|
김덕환 씀: | 스펙은 기본적으로 토론 결과를 따를 겁니다. 토론이 대부분 올바른 결론에 도달할 거라고 믿으며, 그렇지 못하다고 판단되면 말씀드린 대로 토론에 끼어들어 조정하겠습니다. 그리고, 어느 정도 토론이 수렴되었다고 판단되면 혼란이 없도록 의미 정의를 정식으로 공표하도록 하겠습니다. |
스펙을 토론 결과로 정하는 거였군요. 기본적으로 어느정도 가이드라인이 있고 세부 사항은 논의 결과에 따라 변할 수 있다는 뜻으로 이해하겠습니다.
김덕환 씀: | 그리고, 기계 채점은 토론을 통해 의미 정의가 명확하게 정해지면 전혀 문제가 없다고 생각하고 있습니다. 제가 놓치고 있는 부분이 있나요? |
의미가 안 명확해서 채점 기준이 모호해지는 사태를 걱정하고 있었던 겁니다. |
|
위로 |
|
|
김덕환
가입: 2005년 8월 29일 올린 글: 190
|
올려짐: 2005년10월2일 2:03 주제: |
|
|
윤상필 씀: |
스펙을 토론 결과로 정하는 거였군요. 기본적으로 어느정도 가이드라인이 있고 세부 사항은 논의 결과에 따라 변할 수 있다는 뜻으로 이해하겠습니다.
|
예, 정확히 그렇습니다. 교수님께서 숙제를 내주시면 조교는 짧은 기간에 문제의 대부분을 풀어 교수님께 확인을 받습니다. 답안을 만들기 위해서이기도 하고, 학생들 질문에 제대로 답할 준비가 되었나 검증하기 위해서이기도 하지요. 따라서, 이번 숙제의 경우에도 어떻게 되어야 할 거라는 구상은 충분히 하고 있으니 크게 걱정하지 않으셔도 되겠습니다. _________________ TheyAreAsSmartAsYouAre |
|
위로 |
|
|
김덕환
가입: 2005년 8월 29일 올린 글: 190
|
올려짐: 2005년10월2일 9:43 주제: Re: semantics가 정의되지 않은 부분이 많습니다. |
|
|
윤상필 씀: |
9. READ의 경우 어떤 소스에서 값을 읽어들이는지
|
표준 입력에서 읽어들입니다. 논의가 필요한 부분이 아니므로 조교가 답합니다. _________________ TheyAreAsSmartAsYouAre |
|
위로 |
|
|
김덕환
가입: 2005년 8월 29일 올린 글: 190
|
올려짐: 2005년10월2일 21:01 주제: Re: semantics가 정의되지 않은 부분이 많습니다. |
|
|
서상원 씀: |
윤상필 씀: |
- WHILE의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
- FOR의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
|
마지막 계산된 값.
|
마지막 계산된 값이라면 몸체를 한 번도 실행하지 않고 통과하는 경우에는 어떻게 해야 할까요? _________________ TheyAreAsSmartAsYouAre |
|
위로 |
|
|
김남중 손님
|
올려짐: 2005년10월2일 23:49 주제: re : semantics가 정의되지 않은 부분이 많습니다. |
|
|
일단 while이나 for loop, 그밖의 if else 등의 구문에서 nML의 경우 마지막 exp의 결과값이 반환이 되는데요.
그렇다면 저도 마지막 계산 결과가 기본적으로 반환되고, 반환값이 없는 경우 UNIT이 반환되는 것이 맞다고 봅니다. |
|
위로 |
|
|
서상원
가입: 2005년 9월 27일 올린 글: 33
|
올려짐: 2005년10월3일 0:04 주제: Re: semantics가 정의되지 않은 부분이 많습니다. |
|
|
김덕환 씀: | 서상원 씀: |
윤상필 씀: |
- WHILE의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
- FOR의 경우 결과값은 UNIT인지, 아니라면 어떤 값인지
|
마지막 계산된 값.
|
마지막 계산된 값이라면 몸체를 한 번도 실행하지 않고 통과하는 경우에는 어떻게 해야 할까요? |
공수 숙제를 하고 가벼운 마음으로 놀러왔는데, 허를 찔렸군요.
말씀하신 것 같은 상황때문에 unit이 되야겠군요.
윤상필 씀: | FOR의 경우 C++처럼 루프 변수의 바인딩이 새로 정의되는지, 아니면 기존에 있는 바인딩을 사용하게 되는지 여부 |
새로운 바인딩을 쓰는게 이름 재사용 측면에서 더 낫다고 봅니다.
기존 바인딩을 사용해서 얻는 이득이 어떤게 있을지 잘 모르겠군요. 메모리 절약 정도?
추가로 문제 제기하고 싶은 건,
1. 종료 조건(두번째 exp)을 처음에 한번만 계산할 것인가, 매번 계산할 것인가
2. FOR 문 내부에서 인덱스 변수(id)에 값을 할당하면 종료조건에 영향을 미치도록 할 것인가
저는
1. 처음에 한번만
2. 생각중 |
|
위로 |
|
|
서상원
가입: 2005년 9월 27일 올린 글: 33
|
올려짐: 2005년10월3일 0:13 주제: Re: re : semantics가 정의되지 않은 부분이 많습니다. |
|
|
김남중 씀: | 일단 while이나 for loop, 그밖의 if else 등의 구문에서 nML의 경우 마지막 exp의 결과값이 반환이 되는데요.
그렇다면 저도 마지막 계산 결과가 기본적으로 반환되고, 반환값이 없는 경우 UNIT이 반환되는 것이 맞다고 봅니다. |
if 문은 else가 있을 경우만 값을 반환합니다. else가 없을 경우에는 unit이어야하죠.
그리고 while의 경우 unit을 반환하는 걸로 알고있습니다. (문서의 어딘가에. 실험은 안해봤습니다.)
if에서 else가 없을 경우 unit 만을 허용하는 이유는, 조건을 만족하지 못하면 unit이 되기 때문에 타입을 맞추기 위한 것으로 보입니다. 이런 제약이 없으면 어느 타입이 될지 알 수 없다는 거겠죠. 따라서 동일한 이유로 while, for도 unit을 반환하는게 일관성있어 보입니다.
조건에 따라 타입이 변하는 식을 허용하지 않아야 타입 검사하기 좋을 것 같습니다. (필요조건인지는 모르겠습니다. 타입 시스템에 대해 아는 바가 없어서.. ㅠㅠ) |
|
위로 |
|
|
서상원
가입: 2005년 9월 27일 올린 글: 33
|
올려짐: 2005년10월3일 11:55 주제: |
|
|
윤상필 씀: | ASSIGN의 값이 UNIT인지 아니면 대입되고 있는 값인지 |
덧붙여서 "이미 값이 할당된 변수에 타입이 다른 값이 새로 할당되면 어떻게 할 것인지"
예를 들자면
코드: | for x := 1 to 10 in
...
x := "X-man"
...
end |
|
|
위로 |
|
|
|