[질문] 제가 컴파일러책을 보는데요...

오호라의 이미지

집에 쌓여있는 책들도 있고, 정기적으로 구입하는 책들도 있습니다.

보통때 독서를 하는 성격도 못되어서 회사에서 화장실갈때마다 책을 가지고 들어갑니다.

전공책들이죠.(^^;)

전 회사업무 혹은 업무랑 컴파일러책이랑 어느 정도 부합한다고 생각하는데요.

다른 분들은 책상위 책을 보면 다들 비슷한 말을 하더라구요.

"컴파일러 만들게?~", "오~ 컴파일러~"

뭐. 컴파일러책을 보고 그런 말을 하는게 어찌보면 당연하지만 전 반신반의란 생각이 들더군요.

DBMS 회사분들이나 학교에서 공부 혹은 지도하시는 전공자분들의 생각이 궁금하네요.

DBMS 와 compiler 어느정도 부합할까요? 여러분은 어떻게 생각하세요? 좀 쌩뚱맞은 생각인가요?

바라미의 이미지

이번학기 컴파일러 수업을 들으면서 느겼는데...

어느정도에 따라 다르겠지만, 학부에서 배우는 정도라면..
컴파일러하고 DBMS하고 관련이 있는 부분은.. 오직 SQL문을 받아들여 처리해하는것 그부분 밖에 없을겁니다..
그 외는 형식언어 이론이랑, 오토마타, 그리고 그것들을 이용해서 만들어진 의미적 트리를 순환하면서 어셈블리나 아니면 중간 언어들로 출력을 내면 그걸 가지고 머신코드나 어셈블리 코드를 내는거.. 그런 부분이거든요...

DBMS는 데이터를 가지고 여러가지 자료구조, 특히 효율적인 트리 구현 등이 주 관건일텐데..
컴파일러는, 의미분석은 단순히 문자 하나하나에 따라 상태 변화 테이블만 쓰고, 구문분석은.. 파싱 테이블 외엔 스택, 많아봐야 2개 정도 밖에 없안쓰니까요.(LR파서의 경우.)

유일하게 트리를 쓰는 부분은 AST를 내고, 운용하는 부분일텐데, 그부분 외에는 디비하고는 그닥 연관성이 없다고 보셔야 할겁니다.

오호라의 이미지

Quote:
오직 SQL문을 받아들여 처리해하는것 그부분 밖에 없을겁니다..

"오직 SQL문을"까지는 아닌 것같고요. "많은 부분이라고"하면 맞을 것 같습니다. ^^;

Quote:
구문분석은.. 파싱 테이블 외엔 스택, 많아봐야 2개 정도 밖에 없안쓰니까요.(LR파서의 경우.)

책을 잘 보시면 "해쉬"란 단어도 찾아보실수 있을 것같습니다. ^^;

컴파일러 교수님께 물어보시는 것도 좋은 배움일 것 같습니다. 학생때는 이쪽분야로 갈지 상상도 못했어서 물어볼 생각도 못했었네요.

Hello World.

sloth_의 이미지

어떤분은 훈민정음해제나 농사책을보고서도 배울게있다던데 꼭 직격타로 연관있는책들만 볼 필요있나요^^ 소신대로 즐거운생활(?) 하세요,,,,,

lacovnk의 이미지

크게 보면, 맥락을 어떻게 파악하고 저장해야 좋은 결과를 낼수 있는지를 배운다는 점에서 도움이 될껍니다.
자세히는 모릅니다만, query optimizing 같은 부분에서 도움이 될 수도 있지 않을까 조심스럽게 생각해봅니다. ㅎㅎ

그리고 저 역시 다 도움이 된다..라는 주의라 더 격려해드리고 싶네요 ^^

neogeo의 이미지

제가 프로그래머의 능력을 나누는 기준중에 하나가

컴파일러를 작게라도 스스로 전부 구현해본 프로그래머 / 아닌 프로그래머 입니다.

학부생으로써의 마지막 레벨이 컴파일러가 아닌가 생각합니다. ( 물론 저도 학부만 나왔지만.. )

보이는 것 보다 더 많은 내용을 배우실 수 있으리라 믿습니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

gurugio의 이미지


전 커널을 구현해본 프로그래머/아닌 프로그래머로 생각했었다지요...
컴파일러도 언젠가 도전해보겠습니다. ;-)

----
세상을 바꾸는 것은 단 한 사람. 오직 하나님의 사람뿐이다.
개인 홈페이지가 생겼습니다 http://caoskernel.org
어셈러브를 개편중입니다 http://www.asmlove.co.kr

jj의 이미지

큰 의미에서 질의문 최적화에 적용가능하겠네요.

컴파일러 기술이 직접적으로 쓰이지 않더라도, 알고 모르고는 neogeo님 말처럼 크게 다르죠. 언제 어떤일을 하더라도, 코드 생성기를 짤 수 있다면 크게 편해지는 경우도 종종 있구요.

--
Life is short. damn short...

--
Life is short. damn short...

prio의 이미지

뭐 연관은 없는 얘기지만요..
컴파일러 교재로 유명한 공룡책을 쓴 Jeffrey D. Ullman도 요즘엔 DB theory, mining 등을 한다지요. :)

살다보면 언젠가 CS 전체를 조망하는 관점이 필요한 순간이 올 겁니다.
그 순간이 오기 전까지는 괜한 짓을 했다고 생각하실 것이고,
그 순간이 지난 후에는 읽어두어 다행이라고 생각하시겠지요.

서지원의 이미지

Jeffrey D. Ullman 은 원래 DB하시는 분인데 컴파일러 책도 쓴 겁니다.
(책 쓰는거에 관심이 많은지 자기 분야 아닌 쪽으로도 책을 많이 썼습니다)

오호라의 이미지

Quote:
Jeffrey D. Ullman 은 원래 DB하시는 분인데 컴파일러 책도 쓴 겁니다.

CS 달인들에게 과연 전공이 있을지도 의심스럽습니다.

"DB하시는 분이 쓴 컴파일러 책"이라고 하기에는 너무 바이블격이라...

Bell labs 은 외국인 연구소란 소문도 있던데, 그곳 출신자들은 왠지 의심스러운듯...ㅋㅋㅋ

Hello World.

prio의 이미지

Jeff. Ullman님의 나이와 공룡책 초판 인쇄 시점을 고려해 볼 때..
DB를 먼저할 수는 없습니다. ^^;
publication list를 확인해 보시면 아실 듯.

뭐, 자기의 원래 분야랄 것도 없이
Jeff. Ullman이 컴파일러도 만들고 DB도 만들었다고 하면 되겠지요 ㅋㅋ

오호라의 이미지

compilers principles, Tech.., and Tools 는 드래곤북(Dragon book) 또는 나이트북(knight book) 것 같습니다.

보통 공룡책( OS Concept | Appl... )은 OS 책을 말하는 것같습니다. ^^;

그리고, 요즘은 타이거북이 더 유명해진것 같네요. 역시 동물선정이 매우 중요한듯... ㅋㅋㅋ

Hello World.

prio의 이미지

두 책 사이의 구분을 '공룡'과 '드래곤'으로 하나요?
영어로는 구분이 안되는 방법이군요 ㅎㅎ

@ 제 주변에서는 노란 공룡과 빨간 공룡으로 구분했었다능 -_-

오호라의 이미지

이런 스타일은 드래곤이라고 부르죠.

이런 스타일은 공룡이라고 부르죠.

이런 스타일은 타이거라고 부르죠.

가끔 해외사이트를 보면 미국 애들도 똑같이 부르는 것같습니다. 약어로 부르기도 하고요.

댓글 첨부 파일: 
첨부파일 크기
Image icon compiler.jpg13.97 KB
Image icon cover2.jpg53.26 KB
Image icon cover100.jpg247.42 KB
Image icon cover.jpg231.38 KB

Hello World.

prio의 이미지

오호.
dragon과 dinosaur의 차이군요.
오히려 한글로 구분이 안되는건가;;

오랜만에 보는 책표지가 반갑네요.
새로 나온 dragon book은 아예 표지에서 사라졌던데.
요즘도 dinosaur는 표지로 구분이 가능한가요? ㅎㅎ

@ 쓰고 나서 사전 찾아보니 한글에서도 '용'과 '공룡'으로 구분을 하는군요! 제 짧은 어휘력을 탓해야겠는데요 ㅋㅋ

오호라의 이미지

사라지지 않았고, 3D로 바꿨습니다.

OS 책은 위의 7판이 가장 최신판입니다. (ㅡㅡ;)

댓글 첨부 파일: 
첨부파일 크기
Image icon 2e.jpg42.21 KB

Hello World.

prio의 이미지

더헛.
그렇다면 연구실 책장에 꽂혀 있는 밋밋한 표지의 저 녀석은 어디서 온 거지? -_-;;

OS는 올리신 표지가 최신판이군요. ㅎㅎ
예전에 5판도 보고 6판도 보고 했던 기억이 나서 더 많이 바뀌었을거라 생각했습니다.

@ 자문자답인데.. 찾아보니 인터내셔널 에디션이라 그렇군요;;

@ 쓸데없는 책 표지 얘기로 샜네요;; 쟤 뭐야? 하는 분들께는 죄송.

tomahawk28의 이미지

화장실 갈때 신문도 가져가지 말라고 하던데 컴파일러 책이면 아주 난감하지 말입니다..


Can't stop watching this;;

오호라의 이미지

화장실에서 본건 오래 기억된다고 해서리...^^;

Hello World.

blkstorm의 이미지

오래 기억되는 지는 몰라도 변기에 오래 앉아있는 버릇은

별로 안좋은 거라고 합니다. 싹수(?)가 안보이면 그냥 정리하고 일어나서 일상생활을 하다가,

신호가 오면 다시 화장실을 가는게 바람직하다고 합니다.

양변기라고 할지라도 오래 앉아있으면 '학문'에 무리가 간다고 하더군요.

(갑자기 '카지노 로얄'의 밑뚫린 의자 고문 씬이 떠오르는군요 -_-;;)

jungho_gun의 이미지

저도 군대가기전 그런 버릇이 있었는데, 군대 갔다오니 없어졌더군요;;
===========================================
누구나 실수는 한다. 나도 예외는 아니다.

===========================================
누구나 실수는 한다. 나도 예외는 아니다.

whitenoise의 이미지

사용자가 DB에 있는 정보를 조회하는 방식이 고정되지 않고 파라미터의 종류, 갯수 및 조건의 경우의 수가 많아 static한 화면으로 만들기가 쉽지 않을 때, 사용자에게 좀더 친숙한 문법과 용어로 구성된 language를 하나 고안해서 제공해주면 좋겠다 싶을 때가 생기더군요.
컴파일러 쪽 지식이 있다면 dynamic sql하고 짜집기 해서 하나 만들어 볼수도 있을거 같은데, 컴파일로 쪽 공부해야지 하고 생각만 하고 다른 급한것들 먼저 공부하다 보니 좀체 진도가 안나가네요.

오호라의 이미지

해당 DBMS의 Stored Procedure 와 User Defined Functon, Trigger 사용법을 찾아보세요.

엔드유저가 개발자라면 모를까. 일반사용자에게 4G, 5G.. 등을 제공해도 결국 도무묵일듯 싶네요.

SP, UDF, Trigger 로 충분히 커버될 듯싶네요. 이놈들이 위의 목적을 위해서 제공되는 놈들입니다. ^^;

Hello World.

whitenoise의 이미지

Stored Procedure하고 Trigger는 언급한 문제와 직접적인 관련이 없어보이는데, 어떤 구현방법을 얘기하시는 건지 간단하게라도 설명 좀 부탁드리겠습니다.

그리고, 제가 만들려고했던 프로그램의 사용자는 전문가 집단이긴 하지만 컴퓨터 개발 지식과는 상관없는 집단이며, 단지 많은 종류의 데이터를 다양한 관점에서 분석하는게 주 역할인 집단입니다. 실제로 그들이 사용하고 있는 프로그램에 이런 식으로 간단한 형태의 cli가 이미 구현되어 있기도 하며, 검색 조건을 자유롭게 서술할 수 있는 기능은 효율면에서 사용자 측에서 필요로 하고 있는 부분이구요. 개발자 입장에서도 일단 구현만 되면 코드 관리 비용이 줄어드니 능력만 되면 마다할 이유가 없죠.

오호라의 이미지

Quote:
사용자가 DB에 있는 정보를 조회하는 방식이 고정되지 않고 파라미터의 종류, 갯수 및 조건의 경우의 수가 많아 static한 화면으로 만들기가 쉽지 않을 때,

Quote:
Stored Procedure하고 Trigger는 언급한 문제와 직접적인 관련이 없어보이는데,

위 내용으로 보아도 제가 생각하기에는 DBMS 에서는 SP, TR 기능을 이용하는게 맞을 것같아서 그렇게 말씀드린거고요.

아래와 같이 <cond_list> 가 사용자의 요구가 다양하고, 직접적인 조건문을 제시하기를 원할 경우에 SP를 저런 식으로 만들어서 호출하면 편리하고 저런 함수군을 다양하게 만들어서 관리하는게 좋지 않을까해서 드린 말씀이었습니다.그리고, CLI 를 제공하고 있다고 하시는데, CLI 가 command line interface 인지, common language interface 인지, call level interface 인지 모르겠네요. 말씀 하신 내용이 3가지의 전부 부합하는거라서요.
 
<span>ex) SELECT day, week, month, quarter, year FROM stock_list WHERE <cond_list> GROUP BY <group_list>;
    -> CREATE PROCEDURE DWM_stock_list( <args_list> ) BEGIN SELECT... END;</span>
    -> CALL DWM_stock_list( <args_list> );

Hello World.

kalstein의 이미지

2가지를 배울만하죠.

첫번째는 구문분석 그 자체죠.
이걸 이용해서는 DSL(Domain Specific Language)를 제작이 가능합니다. 특징적으로 만든 간단한 언어 개발이 가능해지는거지요. 그 외에도, 문서파싱 관련해서 많은걸 해볼 수 있습니다.

두번째는 자원 최적화 입니다. 구문분석 이후에 이루어지는 과정인데요...예를 들어 적은 레지스터에 어떻게 그 많은 변수들을 설정하는지를 공부할 수 있는거죠. 이부분은...좀 깊은 공부가 필요한 부분이죠.

대부분은 첫번째 단계만 해도 충분하지요. text를 다룬다는 측면에서 의외로 많은 부분에 적용이 가능합니다. DB와 연동부분이라면 2번째에 설명한 최적화까지 동원이 가능하겠지요.

------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/