'번역'에 해당되는 글 7건

  1. 2009.02.14 Factor History & Features
  2. 2009.02.14 concatenative language? (1)
  3. 2009.02.13 FAQ/Vocabulary
  4. 2009.02.13 코딩스타일
  5. 2009.02.13 팩터를 어떻게 공부해야할까요?
  6. 2009.02.13 팩터는 어떤 언어임까?
  7. 2009.02.13 Why "Factor"?
posted by 아겔-_- 2009.02.14 19:13
Factor History&Features

Factor History&Features

  • 이 문서는
  • History
    • 2003년, 자바게임 프로젝트를 위한 스크립팅언어로 시작
    • 이후 general-purpose language로 급속성장
    • 2004년 중반, C로 최소한의 코어를 작성하여 native Factor을 구현하기로 결정
    • native구현은 Java Factor로부터 bootstrapped
    • 그리고 그후 native구현이 de facto구현이되었음
    • 2004년말 자바구현은 개발이 중단
    • Java Factor
      • ~ concatenative.org > Wiki > View > Factor > Java Factor
      • JFactor나 Java Factor
        • Java로 구현한 Factor구현
      • 이제는 obsolete
      • 0.68까지 릴리즈되었었음
      • 다음과 같은 이유로 중단
        • JVM은 효율적인 TailCalls나 Continuations을 지원하지않음. 덕분에 느린 성능으로 이를 구현해야했음
        • JVM은 효과적인 MultipleDispatch을 지원하지않음. generic-arithmetic에서 성능이 떨어짐
        • JVM에서 이미지를 덤프할 방법이 없었음
          • 많은 구현이 자바로 작성해야했음
            • 파서, 컴파일러...
            • 시작이 느릴수밖에 없고, 구현이 우아하지않고, 복잡해짐
        • 자바구현시 standalone으로 배치도 힘들고 크기도 커진다
        • 다른 이유도 많지만, 무엇보다 JVM은 자바를 중심으로 했지, dynamic language을 위한것이 아님
      • 최초의 Factor구현은 "CFactor"로 알려짐
        • 처음엔 JFactor처럼 컴파일러도 포함하지 않았고
        • 그저 interpreted기능만 갖고 있엇음
        • 그럼에도 JFactor보다 나았음
        • 처음부터 Factor을 중심으로 설계되었기 때문에
        • 그 이후에 native compiler을 보함하여 릴리즈
  • Implementation history
    • 첫번째 Java Factor 버젼

      • 인터프리터 전용으로 구현
      • quotation에 대해서 iterate
        • 리터럴은 스택에 쌓고
        • word을 실행
      • 인터프리터는 그 자신을 재귀적으로 호출
      • 다음에 대한 지원이 없음
        • 꼬리재귀호출 최적화
        • continuation
        • call-stack에 대한 reflection지원

      이후 JFactor은 stack-less로 다시 설계

      • 다음이 가능해졌음
        • continuation
        • tail call optimization
      • 하지만 성능이 좀

      Java bytecode 컴파일러가 인터프리터와 함께 JFactor에서 소개되었음

      • 오직 static stack effect인 워드만 컴파일이 가능했음
      • 또한 continuation을 사용하는 코드도 컴파일이 불가했음
      • Clojure에서와 유사한 self-tail-calls을 지원
        • general tail call optimization은 아님

      최초의 native 팩터는 JFactor와 같은 stack-less 인터프리터를 이용했음

      이후 간단한 컴파일러가 native 팩터에 추가됨

      • 몇가지 최적화만을 수행
        • inlining이나
        • defunctionalization같은

      최적화 컴파일러는 계속해서 성장하여 효율적으로 발전

      • 새로운 최적화가 추가되고
      • 추가적인 아키텍쳐가 추가됐다
      • 그리고 컴파일한 코드를 이미지에 저장하는 방식이 도입
        • 모든 코드를 시작시에 다시 컴파일할 필요가 없어짐

      quotation은 first class type이 되었다

      • cons cell의 리스트를 순환할 필요가 없어짐
      • 인터프리터는 배열에 대해서 iterate함

      이후 인터프리터는 최적화하지 않은 서브루틴 스레딩 컴파일러로 대체

      • 이후 stack checker가 continuation에 대해 처리가능
      • 이후 최적화컴파일러가 이를 이용하는 코드를 컴파일 가능
      • 효과적으로 stackless 철학이 컴파일된 코드에 적용이 가능해졌음
      • 이후 native call stack을 continuation object로 대체하게 되었음

      The Non-optimizing compiler subsequently went through several iterations. The latest improvement is that certain primitives are expanded inline. Since the only time when a large amount of non-optimized code runs is during bootstrap, further improvements to the non-optimizing compiler will be conservative and only considered if they improve bootstrap time. Almost all implementation effort can now be focused on the Optimizing compiler.

  • Features
    • the language
      • stack-based language
      • dynamic typing
      • extensible syntax
      • powerful collections library
      • higher-order functions
      • lisp-style macros
      • object system with...
        • inheritance
        • generic functions
        • predicate dispatch
        • mixins
      • homoiconic syntax
      • error handling with restarts
      • continuations
    • the implementation
      • generational garbage collector을 통한 자동메모리관리
      • word선언에 대한 최적화컴파일러
      • 대화식 평가와 top-level form을 위한 non-optimizing compiler
      • 모든 플랫폼에 대한 stand-alone 애플리케이션 배포
      • 쉬운 C library interface
      • OpenGL, X11, Cocoa, Win32, Windows COM 바인딩
      • 팩터는 vm디렉토리안에 작은 C코드로 구현
      • 그리고 많은 core와 basis안의 팩터코드
        • core안의 팩터코드는 부트이미지를 위한
        • 부트이미지는 팩터 인스턴스에 의해서 생성
          • 이 프로세스를 "stage 1 bootstrap"이라고 부름
          • USE: bootstrap.image
            "x86.32" make-image
        • 부트이미지가 생성되면 컴파일한 팩터VM에서 이를 실행가능
          • 이를 "stage 2 bootstrap"이라고 부름
          • ./factor -i=boot.x86.32.image
          • 이렇게 stage 2 bootstrap이 끝나면 "factor.image"가 저장됨
          • 이 이미지를 통해서 개발사이클을 진행할수있음
        • basis의 코드는 부트스트랩의 두번째 단계에서 로딩 & 최적화컴파일러를 통해 컴파일
          • 나머지 코드들은 개발중에 로딩됨
    • the environment
      • graphical listener with object editing inspector
      • 거꾸로 시간을 거슬러갈 수 있는 single-stepping debugger
      • extensive documentation
      • 선언에 대한 cross-referencing
      • 프로파일러
      • jEdit, VIM, Emacs, TextMate등의 편집기와의 연동
    • the library
      • 유니코드 5.0지원
        • 21비트 문자열
        • 대소문자 변환
        • 문자클래스
        • 기타
      • 공통된 인코딩에 따른 유니코드 입출력
      • advanced 입출력기능
        • process launcher
        • memory mapped files
        • file system change monitors
        • secure sockets
      • UI
      • 캘린더
      • 관계형 디비에 대한 접근
        • 디비에 대해 독립적인 O/R 매핑
        • PostgreSQL
        • SQLite
      • HTTP 클라이언트, 서버
      • 패턴매칭
      • lazy lists
      • PEG
        • Parsing Expression Grammars
      • 암호화 및 advanced math routines
      • unit conversion
      • XML파서, XML-RPC 클라이언트-서버
      • 바인딩
        • Cairo
        • PostgreSQL
        • SQLite
        • OpenSSL
        • Cryptlib
        • OpenLDAP
        • ...정말 다양
      • 그리고 기타 작은 예제들
        • raytracer
        • mandelbrot fractal viewer
        • IRC bot
신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

io.encodings.korean 커밋  (2) 2009.02.17
Factor에서 개발하기  (0) 2009.02.15
Factor History & Features  (0) 2009.02.14
concatenative language?  (1) 2009.02.14
FAQ/Vocabulary  (0) 2009.02.13
코딩스타일  (0) 2009.02.13
posted by 아겔-_- 2009.02.14 16:46
Concatenative Language

Concatenative Language

  • 이 문서는
  • ...
    • 프로그래밍 언어의 다양한 카테고리
    • 그중 하나로서 서로 대조
      • applicative
        • 함수에 인자로 적용(apply)함으로서 평가됨
        • C, Python, ML, Java등 거의 대부분의 언어
      • concatenative
        • 여러 함수의 조합이 하나의 데이터에 대해 작용(operate)하여 평가됨
        • 함수에서 함수로 넘어가며 하나의 데이터가 변화되어감
        • 이 데이터를 보통 '스택'으로
        • 이러한 함수의 조합을 'concatenating'
        • Forth, Joy, PostScript, Cat, Factor등의 언어
  • Concatenative, Stack-based language
    • 둘은 비슷하지만 같은 언어는 아님
    • 그럼에도 대부분의 경우 둘은 동일함
    • 스택은 CS에서 기본적인 개념
      • 많은 언어들이 내부적으로 스택을 이용하여 구현
      • 재귀호출을 지원하는 언어라면 call stack을 이용하거나 할거임
      • 이들은 어디까지나 내부적이고 구현에 관한 내용임
      • 프로그래머에게 직접적으로 노출된건 아니니까
        • 물론 first-class continuation을 지원하는 언어는 그렇게하지만
    • 스택기반언어를 차별화하는건 뭘까?
      • multiple stack
        • 모든 스택기반언어는 call stack을 통해 재귀호출을 지원
        • 그리고 data stack을 별도로 갖고 있음
          • 또는 operand stack
          • 함수간의 값을 전달하는데 이용하는 스택
        • data stack이 stack language programmer들이 말하는 'stack'임
    • 널리 쓰이는 applicative language
      • 언어의 중심개념은 함수호출
        • 인자들에 대해서 함수를 적용(apply)
        • 인자들은...
          • 상수이거나
          • 어떤 변수이거나
          • 또는 인자들이 어떤 함수의 결과이기도
    • stack language에서는
      • 함수호출은 단순히 함수의 이름을 통해서
        • 인자전달은 묵시적으로 이루어짐
          • 이들은 그전에 스택에 들어가 있어야함
        • 함수의 결과는 스택에 넣어짐
        • 그리고 다음 함수는 다시 이 스택에 넣어진 결과를 이용해 작동
        • ...그렇게 계속...
        • 함수는 추가적인 문법없이 그냥 이름만으로 호출
          • 그래서 "word"라고 불림
          • 그리고 문법적으로 정말로 "word"이기도 하고
  • 하나의 mutable 스택? 또는 functions from stacks to stacks?
    • 관점1

      • word은 스택에 push, pop한다
      • 직관적이고
      • 실제로 대부분의 구현이 이렇게

      관점2

      • ('concatenative language'을 선호하는 관점)
      • word은 스택을 입력으로해서, 스택을 출력으로 한다
      • 좀 더 일반화된 관점 (more amenable to formal reasoning)
      • function이 pure하다면 rule이나 type system을 재작성하기 쉽겠지

      However, these two points of view are equivalent: because in a given thread of execution, only one stack is "live" at any given point in time, updating the stack in-place has the same semantics as the purely functional world view. More details about this can be found in Manfred von Thun's paper Mathematical Foundations of Joy.

  • concatenative language의 기초
    • 코드에 이름을 붙이기 (값이 아니라)
      • 스택언어에서는 프로그램은 word와 literal의 조합
        • literal은 평가할때 바로 스택에 들어가는 값
        • word은 primitive이거나 다른 워드나 리터럴로 구성된 서브루틴
      • 값은 워드들간에 전달될때 이름을 갖지 않음
        • 또한 직접적인 참조도 없음 (기본적으로는)
      • 값은 원하는대로 복잡하고 다양할수있음
        • 팩터는 실제로 다양한 자료구조를 지원 (배열, 해쉬테이블 등등등)
        • 거기에 사용자정의 클래스라던지 뭐 그런것까지
        • 어쨌든 그럼에도 값은 LISP나 자바와 같은 형태의 이름을 갖지 않음
      • 팩터에서는 다음과 같은것들에 이름을 붙일수있음
        • word (functions)
        • 클래스
        • 슬롯(slots, 클래스의 인스턴스 변수)
        • 전역변수
        • 그리고 기타...
        • 그런데도 word에 전달한 인자에는 이름을 붙이지 않음
      • 왜냐하면 프로그램은 word와 리터럴들이기 때문에
        • 어떤 워드와 리터럴의 조합도
        • "factored out"하여 새로운 word로 쪼갤수있기때문
      • 어떠한 부분도 쪼개져서(factored out) 이름을 붙일수있기 때문에
      • applicative language에서는
        • 어떤 부분을 쪼개서 다른 함수로 만들기 어려울때가 많음
        • 가능한 경우라도 종속적인 변수들을 정리하는 작업이 필요
        • 또는 상태를 전달하거나 하는 복잡한 작업이 필요
        • 현대의 Java IDE에서는 이를 "extract method"와 같은것으로 지원
        • 그런데 stack-language에서는 단순히 cut-paste하면 됨
    • 다음과 같은 pseudo C코드를 보면
      • var x = ...;
        foo(x);
        bar(x);
      • 이런게 패턴이리라고는 생각도 하지 않았겠죠
      • 또 그래서 이게 추상화해야할 부분이고 이름을 주는게 귀찮다고 생각하진 않았겠죠
      • 팩터에서는 이러한것을 위한 combinator(higher-order function)이 있어요
        • bi라고 불리죠
        • 딱 그런 작업을 하는
        • 하나의 값을 받아서
        • 두개의 quotation(anonymous function)에 각각 전달해서
        • 그 두개의 결과를 스택에 쌓아요
      • [ foo ] [ bar ] bi
        • x을 foo에 적용하고
        • 똑같은 x을 bar에 적용하고
        • (x의 값은 스택에 이미 넣었다고 가정하고요.)
    • 또 다른 패턴을 보면...
      • var x = ...;
        bar(x,foo(x));
      • 팩터에서는 x의 값이 스택에 있다고 가정하면
      • dup foo bar
        • x을 foo에 적용하고, 그 결과랑 x을 bar에 적용
    • 이제 좀 더 복잡한 예를 들어봐요
      • infix "." 연산자

        • 보통 인스턴스 변수에 접근하거나 메서드 호출에 사용하죠

        var customer = ...;
        var price = customer.orders[0].price;

        팩터에서는 이런 표현은 정말 자연스럽게 이루어져요

        • 객체를 그냥 스택에 먼저 넣고서
        • 접근자를 통해서 하나씩 밟아 나가면 되니까요
        • customer객체가 스택에 있다고 가정하면
        • orders>> first price>>
          • 이렇게 간단히 표현할수있어요
          • 팩터에서 슬롯에 대한 접근자는 slot>> 처럼 이름지어요

        var customer = ...;
        var orders = (customer == null ? null : customer.orders);
        var order = (orders == null ? null : order[0]);
        var price = (order == null ? null : price);

        • 보통 이런코드로 null인 객체에 접근을 조심스럽게하죠
        • (foo == null ? null : foo.bar)
        • 위와 같은 패턴이 계속되고
        • 추상화하기 힘든 패턴이죠
        • 그루비 같은 언어에서는 이런걸 위한 별도의 문법이 따로 있기도 하죠

        팩터에서는 다음처럼 하면 되요

        • dup [ orders>> ] when dup [ first ] when dup [ price>> ] when
        • 스택의 값을 복사하고, 그 같이 null(f)이 아니면 [ ... ]의 quotation을 실행하고, 계속해서 그런 패턴인거죠

        또 이를 다음처럼 매크로로 만들수도 있겠죠

        • MACRO: maybe ( quots -- ) [ '[ dup _ when ] ] map [ ] join ;
        • 사용
          • { [ orders>> ] [ first ] [ price>> ] } maybe
    • 결론적으로
      • '디자인패턴' 따위가 필요없다는걸 알게되고
      • 새로운 문법을 설계할 필요가 없죠
      • 불필요한 코드를 작성할 필요가 없죠
      • 스택기반언어에서 언제나 나오는 일상적인 예제
      • 스택기반언어를 사용하면 불필요한 코드를 작성할 필요가 없어요
  • 여러값의 리턴
    • 스택기반언어에서는 multiple return values은 정말 간단
      • 그냥 스택에 여러개의 값을 넣으면 되니까
    • applicative language에서는 보통
      • 여러값을 튜플에 넣거나해서 되돌리죠
      • 스택기반에서도 이렇게 할수있긴해요
        • 하나의 단위로 여러개의 값을 취급하고 싶을때 좋죠
        • 그럼에도 그냥 스택에 값을 넣는게 더 쉽죠
    • 팩터의 대부분의 word들은 되돌림값이 없거나 하나
      • 여러개의 값을 되돌리는 word가 있기도 하고
      • 대부분 쉽게 사용할수있음
      • 예를 들어
        • 해쉬테이블에 접근하는 at word
        • 해쉬테이블과 키값을 인자로해서
          • 검색에 성공하면 키에 해당하는 값을
          • 없으면 f을 되돌림
        • 여기까진 자바나 파이썬이랑 유사
        • 팩터엔 at*이란 워드도 있음
          • 값이 있으면 값과 t을 되돌리고
          • 없으면 f f을 되돌림
          • 실제로 at word의 구현은 다음과 같음
          • : at ( key assoc -- value ) at* drop ;
        • 하스켈의 패턴매칭이나 커먼리습의 multiple values지원을 같은 방식으로 구현하기 쉬움
      • 더 흥미로운 예제는 조건문에서
        • 각각의 분기(branch)에서 2개의 출력값을 가질때
          • [ foo ] [ bar ] if +
          • foo, bar 모두 2개의 출력을 할때
          • +은 2개의 출력을 소비
          • applicative language에서는 좀 tricky하죠?
      • 그리고 약간 일반적이지 않은 예제는 'modifiers'
        • do-this, do-that, do-it과 같은 word을 갖고 있다고 가정
        • 그리고 모두 같은 x, y, z을 인자로 받는다고 가정
        • 그리고 3개의 x, y, z을 인자로 받고 이들을 조합해서 결과를 산출하는 frob
        • 결국 조합은 다음처럼
          • do-this
          • do-that
          • do-it
          • frob do-this
          • frob do-that
          • frob do-it
        • 실제로는 4개의 연산만을 정의했음에도
      • 실제적인 예를 들어보면
        • 팩터에는 subsequence을 추출하는 두개의 word
          • subseq
          • <slice>
          • 둘 다 인자는 똑같이
            • 시작 index
            • 끝 index
            • 그리고 sequence
          • 차이점은
            • subseq
              • subsequence을 '복사'해서 새로 생성
            • <slice>
              • subsequence에 대한 '가상 sequence'을 생성
              • '가상 sequence'에 변형을 가하면 원래의 시퀀스도 영향을 받겠지
              • 그리고 추가적인 메모리도 필요없고
          • (head), (tail)
            • 인자로는 시작 인덱스와 시퀀스를 인자로
            • 결과로는 시작 인덱스와 끝 인덱스, 그리고 같은 시퀀스
            • (head)
              • 언제나 결과 시작 인덱스는 0
            • (tail)
              • 언제나 결과 끝 인덱스는 sequence의 길이
          • from-end modifier
            • 끝으로부터 n개의 인자를 되돌리는

              이를 이용하여 다음과 같은 조합

              : head ( seq n -- subseq ) (head) subseq ;
              : tail ( seq n -- subseq ) (tail) subseq ;
              : head* ( seq n -- subseq ) from-end head ;
              : tail* ( seq n -- subseq ) from-end tail ;
              : head-slice ( seq n -- slice ) (head) <slice> ; inline
              : tail-slice ( seq n -- slice ) (tail) <slice> ; inline
              : head-slice* ( seq n -- slice ) from-end head-slice ; inline
              : tail-slice* ( seq n -- slice ) from-end tail-slice ; inline

        • short modifier
          • It implements the case where you want the first, say, 5 elements of a sequence, but if the sequence is shorter than 5 elements, you want the whole sequence, instead of an out of bounds error. It is implemented as follows; it is a modifier for the words above:

            : short ( seq n -- seq n' ) over length min ; inline

            short modifier까지 있으니 총 16개의 조합이 가능하고 실제로 구현한 연산은 6개

  • Concatenation은 조합
    • 스택언어의 기본적인 속성
      • 두개의 프로그램 X, Y을 조합
      • X의 결과를 Y에 전달해서 Y의 결과가 최종결과로
      • 결과적으로 공통적인 quoation 패턴은 명쾌하게 작성
    • 예를 들어
      • 팩터에서 시퀀스의 내용을 걸러내는 filter combinator
        • { 1 2 3 4 5 6 7 8 } [ even? ] filter .
        • 결과: { 2 4 6 8 }
      • 그 반대의 값들만을 원하면
        • { 1 2 3 4 5 6 7 8 } [ even? not ] filter .
        • 결과: { 1 3 5 7 }
      • 부분적용(partial application)도 간단히
        • { 1 2 3 4 5 6 7 8 } [ 4 > ] filter .
        • 결과: { 5 6 7 8 }
      • 위의 세개의 quotation을 비교해보면
        • [ even? ]
        • [ even? not ]
        • [ 4 > ]
        • 다른 applicative language의것들과 비교해봐도 간단
        • 커먼리습과 비교를 해봐도
          • (function evenp)
          • (lambda (x) (not (evenp x)))
          • (lambda (x) (> x 4))
        • concatenative language의 경우엔 인자에 이름을 붙일 필요가 없으니까
          • (locals vocabulary은 잠깐 접어두고)
    • 팩터에서 quotation은 객체의 sequence임
      • 예를 들어, [ 2 2 + ]은
        • 세개의 요소를 갖는다
        • integer, 2
        • integer, 2
        • word, +
        • 맨 마지막은 그 자체로 평가/introspected
      • sequence연산을 이용해서 quotation을 구성할수있음
    • 또 다른 quotation 기본적인 연산은 composition
      • 예를 들어 [ 2 + 0 > ]은
        • [ 2 + ]
        • [ 0 > ]
        • ...의 조합으로 구성할수있음
    • 기본적인 기초적인 연산
      • curry
        • ( scratchpad ) 5 [ + ] curry .
          결과: [ 5 + ]
        • 다른 언어였다면...
          * (let ((x 5)) (lambda (y) (+ x y)))
          #<FUNCTION (LAMBDA (Y)) {11682335}>
      • compose
        • ( scratchpad ) [ 3 = ] [ not ] compose .
          [ 3 = not ]

          * (let ((f (lambda (x) (= x 3)))) (lambda (y) (not (funcall f y))))
          #<FUNCTION (LAMBDA (Y)) {11680B3D}>

      • 바로 보이듯이 훨씬 자연스럽죠
  • Left->Right evaluation
    • concatenative language의 평가규칙은 단순
      • quotation에 대해서 왼쪽에서 오른쪽으로 읽어나가기
      • 리터럴은 스택에 쌓아넣고
      • 워드라면 그 선언을 실행
    • single-stepping debugger을 만들기 단순하게해줌
      • C++같은 언어와는 다르게
        • 모든 문장이 묵시적인 함수호출의 지뢰밭
        • 그리고 모두 명확한게 없죠
      • concatenative language에서 디버거는 단순히 왼쪽에서 오른쪽으로 스텝을 밟아나가면됨
    • 팩터의 'walker'툴
      • (ui-listener에서 Control-w을 눌러서 접근)
      • 이것도 그런 원리를 이용한
      • 간단히 continuation을 이용해 구현하였음
      • side-effects가 없다면 step backward도 가능하다는
  • Keyword parameters
    • 커먼리습, 스몰톡 같은 언어들은 이름 붙은 인자를 지원
      • (send-email
         :from "jack@aol.com"
         :to (list "jill@aol.com")
         :subject "Hello there"
         :body body)

    • 팩터에서 가장 비슷한것은 튜플과 슬롯을 선언해서 이를 다른 word에 전달하는것
      • 이는 정말 자연스러움

        slot setter은 그 값을 그대로 스택에 보존하기 때문

        이렇게 하여 chainning

        • jQuery나
        • Haskell의 모나드처럼

        stack-shuffling이 필요없이

        <email>
           "jack@aol.com" >>from
           { "jill@aol.com" } >>to
           "Hello there" >>subject
           body >>body
        send-email

    • 이렇게 하더라도 추가적인 언어적인 지원이나 기능이 필요없음
  • Rest parameters
    • 커먼리습등은 다음과 같은 다양한 수의 인자를 취할수있음
      • (+ a)
        (+ a b)
        (+ a b c)
        (apply #'+ list)
    • 그런데 스택의 인자가 몇개인지 알려줄 방법이 없음
      • 예를 들어, + 워드는 단 2개의 인자만을 스택에 취함
    • 이를 해결하려면
      • 새로운 워드를 만들거나
      • generailizations vocab을 이용하여 이를 해결
        • "a" 1 narray
          "a" "b" 2 narray
          "a" "b" "c" 3 narray
      • 또 다른 방법은 시퀀스를 이용해 다수의 값을 묶기
        • { 1 } sum
          { 1 2 } sum
          { 3 4 } sum
  • Pipeline style
    • A, B, C, D의 함수를 서로 연계하려면
      • concatenative language에서는
        • A B C D
      • applicative language에서는
        • (D (C (B (A x))))
        • 순서의 거꾸로로 보이죠?
        • 하스켈의 composition을 이용하더라도
        • D . C . B . A
      • 팩터 커뮤니티에서는 이런 코드를 pipeline code라고함
    • pipeline code은 스택언어에서 가장 단순한 idiom
      • word의 sequence은 스택으로부터 값을 취해서 결과를 다시 스택에 넣고, 그걸 또 연계하는 word가 취함
      • Unix shell의 명령들처럼 서로 chain
        • "/etc/passwd" ascii file-lines
          [ "#" head? not ] filter
          [ ":" split first ] map
        • cat /etc/passwd | grep -v '^#' | sed -e 's/:.*//'
    • 이러한 pipeline code은 ui framework에도 적용가능
  • Concision
    • concatenative language은 간결/명쾌하다
      • 왜냐하면 함수간 연계(glue)가 최소한만으로 이루어지니까
      • 그저 공백문자만으로
      • concatenative language의 6개 word을 호출하는 프로그램은
        • 다른 언어의 여섯줄의 코드정도일것
        • 파라메터 이름과 변수선언이 생략되니까
    • concatenative language은
      • 짧은 선언을 유도
      • 새로운 word을 만드는데 있어서 아주 적은 오버헤드만 있으니까
        • 어떤 word도 "factored out"하여 새로운 선언으로 분리가능
      • 주된 오해는
        • 짧은 선언을 만들도록 강제한다는것
          • 사실이 아님
        • 차라리 재사용 가능하도록 합니다
      • 실용적으로
        • 대부분의 프로그래머는 짧은 선언을 선택할것
        • 코드 재사용
        • 코드 문서화
        • 더 확실히 단위테스트 가능
    • 어쨌던 프로그램안에 중복된 코드가 있을 이유가 없음
      • 선언이 짧아져서
        • 높은 재가용성
        • 가독성이 높아지고
        • 괴상한 문법트릭을 쓸 필요가 없고
      • applicative language와 반대
        • 예를 들어, syntax-heavy한 perl같은 언어
    • 짧은 선언은
      • 더 효과적
      • concatenative language와 함께 더 많은 공통분모
        • 효과적인 코드
        • 간결/명벽한 코드
  • Simplicity
    • 좋은 concatenative code은 심플해요
    • 초보자가 처음 시작할때는 보통 stack-shuffler나 불필요하게 복잡한 코드에서 길을 잃죠
    • 팩터 커뮤니티는 초보자가 코드를 pastebin에 포스팅 하고 리뷰 받기를 권장합니다
      • ~ paste.factorcode.org
      • idioms
      • abstractions
      • library words
        • 더 짧은 코드
        • 더 단순한 코드
        • 더 가독성이 높은 코드
    • 팩터 소스코드에서 shuffle word, combinator의 빈도를 찾기
    • 복잡한 shuffler은 조금만 나타나야함
    • 좋은 코드는
      • 단순한 데이터 흐름
      • 괴상한 스택조작이 필요없음
    • 팩터의
      • 최적화컴파일러
      • 웹프레임웍
      • ui툴킷
      • 모두 복잡한 shuffler가 필요치 않음
      • 모두해도 (현재) 3만줄 정도의 코드
  • Meta-programming
    • Joy, Factor와 같은 언어
      • higher-order concatenative languages
    • quotation
      • anonymous function
      • 그저 list로 표현
        • 리스트 조작 연산을 통해 조작
        • 그렇게 조작하여 새로운 프로그램을 만들거나 실행할수도
    • 팩터에서
      • 컴파일러가 매크로를 통해 확장가능
      • 그를 통해 프로그램은 컴파일시간에 구성될수있음
      • LISP, Scheme에서의 매크로를 통한 메타프로그래밍과 유사
        • 강력한 매크로가 리습계열언어에서 괄호-문법의 존재이유(raison d'être)라고 알려져있기도
        • concatenative language은 이런 레벨의 표현력을
          • 더 평면적이고
          • 더 간단한 프로그램으로 성취
    • 쉽게 메타프로그래밍을 적용하는 덕분에
      • concatenative programming은 다양한 패러다임을 쉽게 수용/흡수
    • 그러한 예로서 팩터는 많은 패러다임을 포함
      • functional programming
      • object-oriented programming
      • dataflow programming
    • 명시적인 언어적인 지원이 없어도 고수준의 코드를 작성
      • 더 선언적인 코드
      • 언어가 더 fluid하니까
        • expression도 없고
        • statement도 없고
        • 프로그램은 그저 word의 순열
      • 프로그램의 모든 구조는
        • 컨벤션으로부터 오거나
        • word의 의미로부터
        • 언어의 문법으로부터가 아니라
        • 그러므로 프로그래머는 자유롭게 자신만의/원하는 수준의 추상화를 하는 convention을 만들수있음
  • Continuations
    • 원래는 Scheme으로 기원하는 기능
    • 이해하기 어렵고, 신비로운것으로 알려져있으나
    • concatenative language에서는 정말 단순
      • 단순히 스택의 snapshot
    • 팩터에서 continuation은
      • 각각의 스택을 나타내는 슬롯들을 갖는 튜플의 인스턴스
      • TUPLE: continuation data call retain name catch ;
      • continuation을 구체화하면
        • 스택의 복사본을 생성
        • 그리고 이를 다시 상태복원
      • 사실 다음과 같은것들을 구현하는데 필요한 유일한 primitive
        • exception handling
        • coroutines
        • co-operative threads
        • backtracking
  • Interactive development
    • 대화식개발/실험에 적합
    • 스택에 값들을 넣고 연산을 적용해보고
    • 단순히 listener에 정확한 입력을 주기만 한다면
    • 결과를 되돌려주니까
      • 그리고 그게 바로 프로그램이 되구요
    • 단위테스팅도 같은 패턴을 적용해볼수있심
      • 결과값과
      • 테스트할 quotation을 제공하면됨
      • 예를 들어 실제 팩터의 tools.test vocab의 예제는
        • [ "Hello world" ] [ "Hello " "world" append ] unit-test
신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

Factor에서 개발하기  (0) 2009.02.15
Factor History & Features  (0) 2009.02.14
concatenative language?  (1) 2009.02.14
FAQ/Vocabulary  (0) 2009.02.13
코딩스타일  (0) 2009.02.13
팩터를 어떻게 공부해야할까요?  (0) 2009.02.13
posted by 아겔-_- 2009.02.13 22:51
FAQ/Vocabulary

FAQ/Vocabulary

  • 이 문서는
  • word가 뭔가요?
    • (Forth로부터 유래)
    • named function을 지칭
  • concatenative가 의미하는게 뭔가요?
  • quotation은 뭔가요?
    • (Joy로부터 유래)
    • anonymous function을 지칭
    • 문법적으로는
      • [ ... ]으로 감싼 코드조각
    • 일반적인 데이터로 취급
    • 배열과 유사한 방식으로 취급
    • 역주) 보통 quot등으로 코드에 표기
  • combinator가 뭔가요?
    • higher-order function을 위한 워드를 지칭
      • quotation을 인자로 하는 word
      • 예를 들어, if나 map
  • vocabulary가 뭐임?
    • '모듈'을 지칭
    • 한때는 모듈과 vocabulary가 구분되기도했으나
    • 이제는 아님
    • 역주) 보통 vocab으로 코드에는 표현
  • parsing word가 뭐죠?
    • Forth의 'immediate word'의 사촌
    • Lisp의 reader macro와 유사
      • 팩터에선 일반적인 매크로처럼 쓰이긴 하지만
    • parsing word을 정의하여 파서를 확장
      • 새로운 선언문을 만들거나
      • 자료형의 literal을 만들때
  • generic word가 모죠?
    • Lisp의 'generic function'과 같은거
    • '클래스'를 그 인자로 취하는 word
      • 같은 이름의 word라도
      • '클래스'인자에 따라서 구현이 달라짐
      • 이를 통해서 객체에 메서드를 구현함
    • 팩터에서는 '객체'가 아니라 'word'가 dispatch을 handle
  • word property?
    • 각 word은 word properties라는 해쉬테이블과 연관됨
      • quotation은 아님
    • (abbrev. 'word props')
    • word의 metadata을 저장
      • word의 문서라던지...
      • 그런데 구현코드나 이름은 없음
    • 주의해서 접근해야함
    • 변수보다 더 전역적이므로
  • 팩터의 라이센스는?
    • 역주) 조낸 쌩뚱맞죠?;;;

      Factor is free software under a BSD-style license with no advertising clause. This means that you can do whatever you want with Factor, as long as you distribute the license and the copyright notice with Factor source or binaries. You are completely free to fork Factor or any code included with its distribution for a closed-source or GNU GPL-licensed project (unless otherwise noted). To signify this, at the beginning of each code file distributed with Factor, there should be lines of the form

      ! Copyright (C) 2007 Manuel Lopez Garcia.
      ! See http://factorcode.org/license.txt for BSD license.
      A BSD license was chosen rather than the GPL or LGPL because it allows for the most flexible reuse. However, as a result, we can accept no GPL or LGPL code for the Factor distribution itself.

신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

Factor History & Features  (0) 2009.02.14
concatenative language?  (1) 2009.02.14
FAQ/Vocabulary  (0) 2009.02.13
코딩스타일  (0) 2009.02.13
팩터를 어떻게 공부해야할까요?  (0) 2009.02.13
팩터는 어떤 언어임까?  (0) 2009.02.13
posted by 아겔-_- 2009.02.13 22:37
코딩스타일

코딩스타일

  • 이 문서는
  • 소스파일
    • 탭을 쓰지 않아요
      • 스페이스 4개를 대신써요
    • 한 행은 64문자를 넘지 않도록 해요
      • documentation은 예외
    • word 선언은 3~4줄안에 들도록 해요
    • 짧은 선언문은 한줄에, 긴 선언은 여러줄로 나눠서
    • word선언은 반드시 1~3줄안에 쇼부를 보도록해요
      • 'cond', 'case'을 쓰는 워드는 예외겠지만요
    • word선언이 짧고, 이름이 적절하면 코드 자체로서 문서가 되겠죠
    • 긴 주석대신에
      • 읽을 수 있는 이름을 쓰고요
      • 'help system'을 이용해서 문서화를해요
  • 코드
    • 오케이
      • named-with-dashes
    • 야메떼
      • instead_of_underscores
      • CamelCase
    • copy&paste은 반드시 re-factor해야함
    • control flow pattern을 추상화하는 combinators을 쓰세요
    • 가능하면 라이브러리에 있는 word을 쓰세요
    • 일반화된 코드가 파일의 위쪽에
    • 특화된 코드가 파일의 아래쪽에 위치하게
    • datastack을 자료구조로 쓰지 마세요
      • 역주) 후덜덜;
    • 의미있는 워드이름을 쓰세요
      • foo*
      • (foo)
      • 이딴걸 쓰지마세요-_-
    • 예를 들어 (foo)은 foo을 구현하는데 도움을 주는 word을
    • irc에 와서 코드 리뷰를 해보아요.
      • 역주) 거기 안가도 당해봤다-_-;
  • 기타
    • 역주) naming convetion이나 stack infer declaration등 봐야할게 아직 있는데, 그런것들은 쉽게 익숙해질만한것들이고 익숙해지면 팩터와 더 친해짐
신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

concatenative language?  (1) 2009.02.14
FAQ/Vocabulary  (0) 2009.02.13
코딩스타일  (0) 2009.02.13
팩터를 어떻게 공부해야할까요?  (0) 2009.02.13
팩터는 어떤 언어임까?  (0) 2009.02.13
Why "Factor"?  (0) 2009.02.13
posted by 아겔-_- 2009.02.13 22:27
팩터를 어떻게 공부해야할까요?

팩터를 어떻게 공부해야할까요?

  • 이 문서는
  • 어떻게 공부를 시작?
  • 팩터에 관한 좋은책이 있을까요?
    • 팩터는 정말 젊은 언어
      • 개발시작으로부터 5년정도
      • 그런데도 이정도의 완성도와 성능, 기능
    • 어쨌든 그래서 관련된 서적이 없음
    • Forth에 관한 시작문서들이 팩터에 도움이 되기도함
      • 역주) 가볍게 읽어보기는 좋은데, 사실 그렇게 좋지도 않음;
      • ~ Thinking Forth (PDF)
      • by Leo Brodie
    • 현대 concatenative language의 근간은
    • 인터넷에서는
    • 어쨌든 1.0이 나오기 전에는 책이 나오지 않을듯
  • 스택흐름을 어떻게 머릿속에 그려볼수있을까요?
    • 일단은 종이에 그림을 그려서 이해해 보세요
    • 그렇게 하다보면 자연스럽게되요
      • 원문) But eventually stack shufflers should fade away in your mind and become part of the data flow.
    • 만일 그래도 스택흐름을 따르기 어렵다면
      • 한번에 너무 많은걸 스택에서 조작하려고 하는건 아닌지 살펴보세요
        • 보통 팩터 word은 3개 이상의 인자를 받지 않아요
        • 그 이상이라면 그 word을 작게 "factor"-ing해야할듯
  • ~ 팩터 코딩스타일?
신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

FAQ/Vocabulary  (0) 2009.02.13
코딩스타일  (0) 2009.02.13
팩터를 어떻게 공부해야할까요?  (0) 2009.02.13
팩터는 어떤 언어임까?  (0) 2009.02.13
Why "Factor"?  (0) 2009.02.13
io.encodings.korean을 완성했습니다.  (2) 2009.02.12
posted by 아겔-_- 2009.02.13 22:16
팩터는 어떤 언어임까?

팩터는 어떤 언어임까?

  • 이 문서는
  • 'quotation'와 'word'은 왜 구분하나요?
    • quotaion와 word은 다른곳에 쓰임
    • 워드의 경우
      • 팩터 프로그램은 word로 쌓아올림
        • 또한 word도 word의 조합일뿐
      • word은 단순히 그 이름을 이용해 실행함
      • 워드는 메타정보를 포함
        • 어떤 모듈에 속하며
        • 소스의 위치
        • 그리고 코드에 대한 추가적인것들
      • 워드가 스택에 값으로 들어가 있으면
        • 'execute'을 통해 호출함
    • quotation의 경우
      • 데이터로서의 코드
        • coda-data
        • combinator와 같은곳에 적용함
        • 워드와 같이 메타정보를 포함하지 않음
        • 'call'을 통해 호출
  • 하스켈처럼 purely functional인가요?
    • 아니요
    • 부수효과(side-effects)을 허용
    • 표준라이브러리에 포함된것들만봐도
      • mutable 데이터구조
      • imperative I/O
  • 어째서 아닌가요? (purely functional이 왜 아닌지)
    • 훨씬 간단하니까
    • 부수효과가 하스켈에서처럼 순서대로 일어나지 않음
      • 역주) 무슨말이람;
      • 원문) Effects don't need to be sequenced explicitly, as in Haskell.
    • 많은 알고리즘이 mutability가 지원되야 구현가능하고
      • mutability: 자료구조나 변수가 똑같은걸 복사해서 변경되는게 아니라, inplace로 변형되는.
    • 그럼에도 팩터코드는 purely functional하게 작성할수도 있음
      • 그런 부분에서 재미난게 많이있을거고
    • 아직 purely functional한 metaprogramming system을 설계한 사람이 없으니까
      • 적어도 팩터만큼
  • 어째서 dynamically typed? (왜 statically typed가 아니라)
    • 위와 비슷한 이유
    • 높은 수준의 메타프로그래밍을 지원하기에
      • 훨씬 간단해지고
      • 유연하기 때문에
    • Additionally, a flexible enough type system for concatenative languages has not yet been designed.
      • (번역이 귀찮았;)
    • 팩터2.0은 선택적인 static typing을 지원할지도
      • 그런 타입시스템을 찾으면
      • 역주) 펄6?
  • 팩터엔 변수(variable)이 있어?
    • 예, 있습니다
    • dynamically scoped
      • 'namespaces' vocab.
      • 보통 word끼리의 연계/연동을 위함
    • statically scoped
      • 'locals' vocab.
      • word의 지역변수를 위해
  • 근데 dynamically scoped variables은 나쁜거 아냐?
    • 예, 그렇습니다.
      • 하지만, 만일 언제나 '디폴트'로 그렇게한다면 그렇습니다.
    • 하지만, 일반적으로 데이터는 '스택'을 이용해 전달
    • dynamically scoped variables은 넓은 부분에서 쓰임
      • 스택을 이용해 전달하기엔 좀 거시기할때
      • prettyprinter의 설정이나
      • XML 파서의 상태나
      • 또는 부분적으로 조합된 배열이나
  • 왜 스택조작 하는 애들은 이름이 그래요?
    • dup, swap, drop뭐 그런이름
    • 왜 그냥 x-xx나 xy-yx처럼 stack-infer을 그대로 쓰지 않고
      • 'shufflers' vocab.
        • 이제 안쓰이는듯? (현재버젼에서는)
      • 그걸 쓰면 이렇게도 쓸수있음
      • 이런 mnemonic이 대부분은 더 명확함
      • 바로 데이터가 어떻게 변형되는지 보이니까
      • 예) dup -> x-xx
    • 그런데 그냥 정말 복잡하게 스택을 조작할 경우엔
      • 'locals'을 이용해서 statically scoped하는게 바람직할듯
    • 간단한 경우엔 그냥 dup, drop, swap이 훨씬 간단
      • 물론 조금만 팩터에 더 익숙해져야겠지만
      • 그래봤자 몇개 안되는 stack shufflers니까
    • 복잡한 스택조작에
      • 'shuffle' vocab.
      • 주로 foreign functions인데 인자가 많거나할때에 유용
신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

코딩스타일  (0) 2009.02.13
팩터를 어떻게 공부해야할까요?  (0) 2009.02.13
팩터는 어떤 언어임까?  (0) 2009.02.13
Why "Factor"?  (0) 2009.02.13
io.encodings.korean을 완성했습니다.  (2) 2009.02.12
factor-kr을 시작했습니다.  (0) 2009.02.08
posted by 아겔-_- 2009.02.13 21:46
Why "Factor"?

Why "Factor"?

  • 이 문서는
  • 팩터의 무엇이 독특한걸까?
    • 팩터는 다음과 같은 여러 특징을 한 언어에서 구현
    • Concatenative Language
    • Dynamic Typing
    • 표현력 (Expressiveness)
    • 고성능 (Good Performance)
    • 배포성 (Application Deployment)
    • 풍부한/강력한 라이브러리 (Good Library)
  • 그럼 팩터는 어디에 쓰는게 적합함?
    • 어디에서(for anything)
    • 스크립팅
    • 웹개발 (furnace)
    • 게임작성
    • XML 파싱
    • ...그밖에도 정말 다양한 분야에 걸쳐 적용이 가능
    • 범용적인 프로그래밍 언어
  • 팩터의 목적이 뭐지?
    • 사실은 실험적인 구현이기도
      • 현대적이고
      • 실용적인(useful)
      • 강력한 추상화(strong abstraction capabilities)를 지원하는
      • Concatenative Language을 구현하려는 시도
    • 또 유난히 대화식개발(interactive development)에도 적합
  • 나의 "다음번 프로그램"에 팩터를 쓰는게 적합할까?
    • 어쩌면
    • 반대로 적합하지 않은 분야는 매우 적음
      • 실행화일의 크기가 중요한 경우
        • 부트로더
        • BIOS에 적재할 프로그램
        • 기타 모바일 장비에 올릴 프로그램
        • 그 이외에 일반적인 "애플리케이션" 개발에는 적합하겠죠?
      • 대상 기계가 정말 특별한 경우
        • 그나마도 거의 대부분의 플랫폼에서는 굴러간답니다
        • 특히, 일반적인 윈도기계에서도!
    • 그럼 나머지(대부분의 경우)는 적합한거군
  • 팩터는 cross-platform?
    • 같은 팩터 소스는 다른 플랫폼에서 별 수정없이 잘 돌아감
    • 그리고 native library을 이용하는 경우에 약간의 이슈가 되기도함
      • 그나마도 거의 대부분 문제가 없도록 계층적으로 구현해놓았음
    • 그런데 실제 native code을 담고 있는 factor image은 플랫폼간 호환이 안되요
      • 어차피 이미지는 팩터소스를 로드해서 생성하니까 문제가 안됨
  • Forth랑은 뭐가 다른거죠?
    • Forth은
      • 타입이 없고(untyped)
      • 쓰레기수집이 없고(not garbage collected)
      • 좀 더 저레벨(close to the machine)
      • 흐름제어에 있어서도 immediate word(팩터의 quotation와 대조되는)을 이용하고
      • 변수는 전역(global)이고
      • functional하게 프로그램을 작성하기 힘들다
    • 팩터는
      • dynamically typed
      • 고수준의 reflection
        • 프로그램 자신
        • 그리고 자신이 속한 환경
        • 그런것들을 프로그램이 살펴볼수있죠
      • 쓰레기수집기
        • generational garbage collector
      • 약간 더 고수준의 코드
        • C FFI을 통해서 malloc, mmap등의 저수준도 지원이 가능하면서
      • 흐름제어에서 quotation을 이용
        • higer-order function등을 적절히 적용
      • parsing word들은
        • 선언문(definitions)
        • literal을 표현하기 위해서 적절히 쓰고
      • 변수는
        • dynamically
        • 또는 statically scoped
        • 배열은 그냥 '객체'이고(특별히 취급할 필요없이!)
      • 또한 functional programming language!
  • 팩터 프로그램이 단순히 '워드'의 조합일뿐이라면, 다른 언어들 같이 쓸 수 있는거임?
    • 원문은
      • if Factor programs are just compositions of existing words
      • how is Factor as powerful as other programming languages?
    • turing complete
      • 다른 언어들이 할 수 있는건 팩터도 할 수 있음
    • applicative(일반적인) language 프로그램을 stack based로 전환하는건 어렵지않음
    • 단순히 얼마나 많은 'word'을 사용하는가에 달린 문제임
  • 왜 새로운 stack-based language가 필요하지?
    • 다른것들은 고수준의 개발에 적합하지 않으므로
    • Forth
      • 저수준 작업을 위해서는 좋다
      • 하지만
        • 타입시스템이 없고
        • 가비지컬렉션도 없음
      • 디버그하기 어려움
      • 거기에 functional programming을 하기엔 지저분
    • Joy
      • 매우 중요한 이론적 공헌을 했음
      • 하지만 효과적으로 컴파일하기 어려운 언어
      • 문법은 확장이 어렵고
      • 모듈시스템은 뭔가 부족하고
      • 또한 purely functional하기에 많은것들이 어렵게 진행됨
    • 팩터는 이들의 좋은면을 조합
    • 거기에 다른 언어들로부터도 많은것들을 빌려온 언어
신고

'삽질+돈되는짓 > FactorLanguage' 카테고리의 다른 글

팩터를 어떻게 공부해야할까요?  (0) 2009.02.13
팩터는 어떤 언어임까?  (0) 2009.02.13
Why "Factor"?  (0) 2009.02.13
io.encodings.korean을 완성했습니다.  (2) 2009.02.12
factor-kr을 시작했습니다.  (0) 2009.02.08
ProjectEuler 풀면서 한컷!  (0) 2009.02.01