Jeong, YunWon
Jeong, YunWon
조금 오해가 있는 것 같아서 첨부합니다. 알파희는 제가 만든 구현체인데, 일단 언어의 역사에 비해 구현체의 역사가 매우 짧아서 (10년 vs 1년 미만) 구현체로서 대표성을 가지기 어렵습니다. 가장 대표적인 구현체를 꼽으라면...
공백에 관한 동작에는 표준 개정에는 조금 우려스러운 부분이 있습니다. 저는 이전의 구현체들의 동작과 일치하지 않는 동작에 따라 표준을 개정하는 것은 개정 이전의 구현체와 개정 이후의 구현체의 동작을 다르게 만들어서 구현체의...
아희 코드에 주석을 남기고 싶다면 현재의 상황에서 제가 권장하고 싶은 방법은 코드를 가급적 위-아래 경계를 넘을 때 2칸씩 이동하지 않도록 만들고, 코드 영역 밖의 아래쪽 등의 명백한 실행영역 밖에 주석을...
본래 이슈로 돌아가면, @xnuk 님이 질문하신 동작은 현재 아희 스펙으로는 명확히 설명되지 않는 부분입니다. "반대쪽 끝"에 대한 정의가 제대로 되어 있지 않거든요. 제가 선호하는 해석은 "이동을 처리한 후 코드 경계를...
아희 org에는 snippets라는 저장소가 있는데요. 여기에는 표준에서 불명확한 동작만을 모아놓은 디렉토리(undefined)가 있습니다. 다른 불명확한 표준에 관심이 있으면 이 디렉토리의 다른 파일을 좀 더 찾아보셔도 좋을 것 같습니다. 이 동작에 관련된...
미정의 디렉토리는 이해하기 쉬운 간단한 코드만 포함하기 때문에 그렇습니다. 콰인은 단지 모든 구현체를 커버하지 않는 코드일 뿐인거죠. 두 칸씩 한번 이동을 사실상 표준으로 삼고 있다는 얘기는 사실과 다릅니다. 두번째 얘기도...
비슷하게 보이기도 하고 호환되는 코드도 만들수 있지만 기본적으로는 양쪽이 서로 호환성을 갖지 않는다는 점에서 비슷한 관계겠네요.
@disjukr 공백 문제에 관해서는 대부분의 구현체가 공백도 하나의 무시할 문자로 취급합니다. 현재의 표준을 엄밀히 해석하면 공백은 "유니코드 hangul syllable area 영역 밖의 문자" 이외의 어떤 다른 해석도 불가능합니다. 물론 표준...
(ㄷ) 에 대해서는 공백이 호환 문제를 일으키는 원인이므로 현재 구현체들과 크게 엇나가지 않는 방법으로 정의하자면 - 방향에 관계 없이 각 줄의 끝을 (실제로 문자가 처음 나타나는 위치를) '반대쪽 끝'으로 해석...
@Sait2000 네 맞습니다. 그런데 퍼즐릿님 말에 의하면 그런 구현체는 거의 없는거 같네요. 위에 보면 가희라는 구현체는 한때 그랬던거같고요