8주차 - 7장. 식과 배정문 Expressions and Assignment Statements

---

0427

7장

제7장 식과 배정문

7.1 서론 = 342

7.2 진술식 = 343

7.3 중복 연산자 = 352

7.4 타입 변환 = 354

7.5 관계식과 불리안 식 = 357

7.6 단락회로 평가 = 360

7.7 배정문 = 362

7.8 혼합형 배정문 = 367

>💡 정리

expression에서 고려해야 할 사항 6가지

1. 연산자 우선순위 : 연산자가 여러개 나왔을떄 어떤 연산자를 먼저 처리할 것인지
2. operator Associativity(연산자 결합성) : 동일한 우선순위를 가지는 연산자들이 나왔을때, 어떤 연산을 먼저 수행할 것인지
3. operand evaluation order : 피연산자 수식에 여러개의 피연산자(operand)들이 존재할때, 피연산자에 대한 값을 내가 어떤 순서대로 평가할것인지

   1. 피연산자로 function call이 주어졌을떄,

      1. 글로벌 변수
      2. 2way 파라미터

      를 사용했을때, callbyvalue 1way 파라미터/ callbyreference 2way 파라미터
      수식에 있는 변수가 함수 호출로 인해 직접적으로 변경이 될때, 어떠한 순서로 처리할 것이냐!

• 컴퓨테이션

• Expressions

  • 산술 연산 Arithmetic Expressions
  • 비교연산 R
  • 논리연산 불리언(로직 익스플로션)

• 수식

  • 산술 수식
  • 비교 수식

익스프레션을 정확히 평가해야지만 컴퓨테이션이 올바르게 수행된다.

우선순위를 명확하게 문법으로 정해져야함

변수의 값이 얼마인지가 컴퓨터의 상태임

산술 수식 Arithmetic Expressions

operators,operands, parentheses, and function calls

Operaator

• 단항연산자
• 이항연산자
• 삼항연산자

미리 정해져야하는 것

프로그래밍언어를 만드는 사람이 이걸 정의해놔야지만 expression의 값이 모호하지 않게 항상 일관된 값을 뽑아낼수가 있다.

1. Operator precedence rules? 연산자 우선 순위 규칙?
   하나의 expression 안에 여러개 쓰였을떄 뭘 먼저

2. Operator associativity rules? – 연산자 연관성 규칙?
   같은 우선순위를 가지는 연산자가 하나의 expression에서 쓰일때?
   Associativity (오→ 왼, 왼→ 오)

3. Order of operand evaluation? – 피연산자 및 평가 순서?
   피연산자 operand에 대한 평가

4. Operand evaluation side effects? – 피연산자 평가 부작용?
   –

5. Operator overloading? – 연산자 오버로드?
   연산자 오버로딩 허용함?

   | C | X |
   | --- | --- |
   | C++ | O |
   | JAVA | X → 자바를 설계한 사람의 의도인거죠~
   대신 메소드 오버로딩이 있음
   사실은 세모임 ㅋ
   숫자에 대해서는 덧셈, string은 concat으로 자동으로 됨. 하지만 사용자가 정의해서 사용하는게 불가능하다~ |
   | PY | O |

6. Type mixing in expressions? – 식에 혼합을 입력하시겠습니까?

APL 초기에는 연산자 우선순위가 없었음!

1. 연산자 우선순위

: 연산자를 실행하는 순서

→ 우선순위가 높은 연산자가 먼저 실행됨

2. 연산자 결합성 (Associativity rules)

• 좌결합 Left to right 보편적
  left recursive rule : E → E-T | T
  
• 우결합 Right to left

비교연산 Conditional Expressions (조건문)

3. Operand evaluation order

1. Variables: fetch the value from memory
   1. 변수: 메모리에서 값 가져오기
2. Constants: sometimes fetch from memory;
   sometimes the constant is in the machine language
   instruction
3. Parenthesized expressions: evaluate all operands
   and operators first
4. The most interesting case is when an operand is a
   function call

   연산 하기 전에 반영할 것인지, 연산 수행한 다음에 반영할 것 인지
   
   1. 피연산자로 function call이 주어졌을떄, 
       1. 글로벌 변수
       2. 2way 파라미터
       
       를 사용했을때, callbyvalue 1way 파라미터/ callbyreference 2way 파라미터
       수식에 있는 변수가 함수 호출로 인해 직접적으로 변경이 될때, 어떠한 순서로 처리할 것이냐!
       

4. function side effect

1. 아예 못하게 하는 방법
   function call 로 인해 피연산자의 값이 안바뀌게 함
   → 전역 변수 못쓰게 하고 2way 파라미터 못쓰게 함.

   syntax error!
   
   1. 장점 : 고민할 필요가 없다 리더빌리티 올라감
   2. 단점 : 플랙서 빌리티 낮아짐 콜바이 레퍼런스 지원 안함 (제약조건을 강하게 걸어서 side effect를 없애기) , 라이터빌리티도 떨어짐.
   → 해결책이 못됨!!!

2. 명확하게 정하는 방법

   1. 허용을 하되, 명확하게 지정하는 것이다.
   2. ex 무조건 왼쪽부터 계산하라고 정의할 수 있다.
   3. 제일 늦게 끝나는거에 맞춰서 끝나게됨.
      → 컴파일러 optimization이 거의 무효화됨.
   4. 단점 : optimization할때 순서가 정해짐

   ⇒그래서 메이저 언어들은 두 방법 다 안하고, 프로그래머들이 인지하고 side effect 나지 않게 코딩 해라. 밖에서 빼서 미리 계산하라. 파라미터를 같은 수식에 있는 애를 쓰지 말던지.

referential transparency(참조 투명성)

: 똑같은 함수에 대해서 같은 파라미터를 줬을때는 리턴값을 같게 만드는것

(당연히, 파라미터(아규먼트의 값)이 다를떄는 상관 없음)

똑같은 함수를 호출하면서 똑같은 파라미터를 줬지만 다른 결과가 나올때,

• 같지 않게 만드는 요소
  1. 글로벌 변수(non local 변수)가 썼을 때
  2. 2way 파라미터를 썼을 때
  3. static으로 지정한 local 변수를 썼을 때

⇒referential transparency를 갖추고 있지 않다.

똑같은 이름으로 assign이 되어 있는 두가지 요소가 있을떄, 똑같이 주어졌으면 각각 쓰였을때 동일한 값을 보장한다면 그것을 referential transparency라고 한다.

referential transparency = 같은 함수에 같은 파라미터 값을 줫을떄는 리턴값이 같다.

참조의 투명성이 보장되면 장점

1. Readability 올라감

100%보장 언어 → 변수를 안쓰는 언어. funtional PL

5. 연산자 오버로딩 operator overloading

연산자 오버로딩으로 인해 라이터빌리티가 올라갈 수 있지만

특정상황에서는 오히려 Readability 낮아질 수 있다.

• 연산자 오버로딩 가능 여부

C	X
C++	O → user defined 연산자 오버로딩 지원
JAVA	X → 자바를 설계한 사람의 의도인거죠~

대신 메소드 오버로딩이 있음
사실은 세모임 ㅋ
(예외상황) 숫자에 대해서는 덧셈, string은 concat으로 자동으로 됨.

하지만 (user defined) 사용자가 정의해서 사용하는게 불가능하다~ |
| PY | O → user defined 연산자 오버로딩 지원 |

• C에서의 예시 & : 주소값 & : and 연산
  

6. Type Conversion

1. emplicit 명시적인 타입변환 : casting → 프로그래머가 의도한것, 모든언어가 100% 지원
2. implicit 암묵적인 타입 변환 : coercion → 플랙서빌리티는 올라가지만, 릴라이어빌리티는 떨어질 수 있음. PL 자체적으로 해주니까 술술 실행은 될테지만, 프로그래머가 의도하지 않은 일이 발생할 수도 있음.

• 임페라티브 PL은 모두 지원 O
• functional PL은 지원 X (side effect도 허용 X) | java | 작은 → 큰 O
  큰 →작은 X |
  | --- | --- |
  | py | O |
  • narrowing conversion 큰 → 작은
  • widening conversion 작은 → 큰 _문제 X

  mixed mode

  mixed mode 지원 → implicit type conversion O
  즉, coercion 지원되야지만, mixed mode expression이 가능하다.
  functional PL X
  

(그외) Error in expression

에러가 발생하는 경우

syntax error!!

1. 수학적으로 잘못된 경우
2. underflow or overflow