재귀와 반복 중 효과적인 것?

  • 메소드는 자신을 호출할 때 매개변수 리스트를 보관할 메모리 영역과, 메소드를 실행할 복사 공간이 필요하다.
  • 반복을 이용할 때는, 메소드 호출이 한번만 일어나기 때문에 메모리 성능 면에서는 반복이 효과적이다.
  • 재귀를 이용하면 계속해서 메소드 호출이 일어나서 메모리 비용이 더 크다.
  • 재귀는 적은 코드를 사용해 더 효율 적인 처리가 가능하고, 코드에 대한 이해가 더 쉬울 수 있지만 메모리 소모는 반복이 더 적기 때문에 상황에 따라서 다른 방법을 사용해야 한다.

token, lexer, parser

token, tokenizer

  • token은 의미가 있는 단위 중 가장 작은 단위이다.

    예약어, 상수, 연산자, 식별자, 구분자 등의 단위가 있다.

  • tokenizer는 어휘를 token을 기준으로 나누는 기능을 하는 메소드이다.
  • 흔히 문자열을 파싱할 때 쓰는 split()도 이 중의 하나이다.

lexer

  • 컴파일러 구조의 lexical analysis (어휘 분석)을 참고하자
  • token으로 나뉜 단위에 의미를 부여한 symbol table을 만드는 기능을 하는 메소드이다.

parser

  • symbol table을 통해 문법에 맞는지 검사하는 기능을 한다.
  • 주어진 문법에 맞게 구성되어있을 경우, parse tree를 출력한다.
  • 이 때 생성된 tree를 컴파일러 구조에서는 parse tree 또는 좀 더 자세한 버전인 Annotated parse tree라고 한다.

    Abstract tree(AST) parse tree를 축약한 버전. 프로그래밍 언어로 작성된 소스 코드의 추상적인 버전을 트리형태로 담은 구조이다.
    주로 컴파일러에서 널리 사용되는 자료 구조인데, 컴파일러가 요구하는 여러 단계를 통해 프로그램의 중간 표현 역할을 한다. 참고 링크

오늘 미션을 하면서 아쉬웠던 점

  • parser는 구조화 단계라고 생각해서 구조화만 담당하도록 작성했는데, 문법에 맞는지 검사하는 부분은 parser가 담당하는 것이었다. 나름대로 설계서를 작성해서 규칙을 정하고 구현하긴 했지만 원래 의미에 맞게 구현했다면 더 좋았을 것 같다.
  • tokenizer가 문자열의 경우에는 제대로 분리해내지 못하는 경우가 있다. 설계서에는 token이 문자열 중간에 끼면 제대로 동작하지 않는다고 명시하긴 했지만 집에가면서 생각해보니 그럼 제대로 된 tokenizer가 아니지 않나, 하는 생각이 들었다. 그 부분에 대한 처리가 생각해보니 어려운 과정도 아니었는데 좀 더 오래 생각해보고 결정하면 좋았을 걸 하는 생각이 들었다.