코드의 한 쪽 끝에서 두 칸 이동할 경우의 동작에 대해서

[xnuk]

* 커서가 코드 공간의 한 쪽 끝에 다다르면 커서는 반대편 끝으로 이동합니다.
  * 반대편 끝은 코드 텍스트에서 진행방향 반대편에 존재하는 첫 문자를 가리킵니다. 첫 문자는 줄바꿈 문자를 제외한 어떤 문자도 될 수 있습니다.

스펙에 서술된 부분입니다. 이 경우

우
유분
받망희
아유

이 코드는 4행 2열의 유에 해당하는 "반대편 끝"은 분을 가르켜서 2가 출력된다고 보는데, 의도한 부분이 맞나요?

[disjukr]

두 칸 옮긴다의 해석이 커서를 두 칸씩 한 번 이동하느냐, 한 칸씩 두 번 이동하느냐,
반대편 끝의 해석이 코드 공간의 bounding rect에서 첫 칸(공백)인가, 해당 열에서 처음으로 공백이 아닌 칸(분)인가에 따라서 다르겠죠?

[xnuk]

공백은 "문자" 취급을 받으니까, 문자가 없다고 표현하는 게 더 나을 거 같네요.

[disjukr]

그렇다면 없음정도로 부르는 걸로..=3

[minacle]

그렇다면 저 위치는 문자가 없는 칸일 뿐이지, 문자가 될 수는 없으니까 분을 가리키는 구현이 올바른 게 되는 걸까요?

[minacle]

또, @disjukr 님께서 말씀하셨듯, 한쪽 끝에 다다르면 반대쪽 끝으로 이동한다는 설명도 약간 모호한데,
여희멍번볃이라는 코드가 있다고 하면 여가 한 칸씩 두 번 이동하는지, 두 칸을 한 번에 이동하는지에 따라 결과가 달라지게 돼요.
알파희가 사실상 표준으로 취급되고 있는 점을 생각한다면 두 칸을 한 번에 이동하는 게 맞겠지만, 이 부분도 확실히 해주면 좋겠어요.

[disjukr]

지금은 스펙을 어떻게 해석하느냐에 따라 다른 구현이 나올 수 있으니 어떤것을 하나 집어서 "올바른" 구현이라고 부르긴 어렵겠죠.

제가 이해하기로 현재 대부분의 구현체는 두 칸씩 한 번 이동하며, 상하이동에 대해서는 bounding rect에서 첫 칸(없음)으로 이동하고, 좌우이동에 대해서는 처음으로 없음이 아닌 칸으로 이동하는 걸로 알고있어요.

개인적으로 상하이동과 좌우이동에서 반대쪽 끝의 해석은 일관성을 맞추는 것이 좋을 거라고 보고있구요. 구현의 용이성에 초점을 맞춘다면 bounding rect의 첫 칸으로 보내는 것이 좋겠고 사람의 직관에 초점을 맞춘다면 처음으로 없음이 아닌 칸으로 이동하는 것이 좋겠죠.

[minacle]

사람의 직관에 초점을 맞춘다면 처음으로 없음이 아닌 칸으로 이동하는 것이 좋겠죠.

@xnuk 님께서 제시하신 코드

우
유분
받망희
아유

라면, 사람의 직관에 초점을 맞추어 분으로 이동하게 되겠지요.

그런데 만약, 오른쪽에 주석이 있으면요?

우　　　　-- 우—☆
유분　　　-- [명사] 죽은 사람의 뼈를 빻은 가루.
받망희　　-- 왜 밯망히가 아니죠?
아유　　　-- 츠키미야 아유는 귀여워요!

사람의 직관에 초점을 맞춘다면 분으로 가야 하겠지만, 저 경우에는 분명히 　라는 공백 문자가 존재하기 때문에, 3이 출력되게 돼요.

[tirr-c]

• 주석을 정의하고
• (#12와 함께) 공백 문자를 정의하고
• 공백 문자와 주석을 무시하도록

하면 대부분의 모호함은 해결할 수 있을 것 같습니다. 근데 좀 복잡해지려나요...?

[minacle]

개인적으로 주석을 따로 정의하는 것은 좋은 방향이 아니라고 생각합니다만 공백 문자를 무시하도록 하는 안은 찬성입니다. 유니코드에 존재하는 모든 공백 문자는 명시되어 있습니다.

[youknowone]

조금 오해가 있는 것 같아서 첨부합니다.

알파희는 제가 만든 구현체인데, 일단 언어의 역사에 비해 구현체의 역사가 매우 짧아서 (10년 vs 1년 미만) 구현체로서 대표성을 가지기 어렵습니다. 가장 대표적인 구현체를 꼽으라면 최초의 구현체인 js 구현체가 가장 대표성을 띌 것이고, 이것을 제외하고도 그 이후에 나온 오랫동안 합법적인 구현체 가운데 하나로 인정받아 온 여러 구현체가 더 중요할 것입니다.
아희아희와의 관계는 조금 특수한데, 알파희는 아희아희의 개발에 필요한 기능 일부를 직접적으로 구현해 오면서 지원을 조금 했기 때문에, 아희아희가 알파희의 특수한 비표준 동작(표준에 어긋나지 않지만 명시되지도 않은 동작)에 의존하기 때문이고, 이 기능은 아희아희의 개발에 필요하지 않았으면 추가되지 않았을 기능입니다.

개인적으로는 다른 구현체 몇 개의 동작을 참고해서(일부러 참고하려고 고른건 아니고 그동안 써 본 것 위주로), 많은 구현체가 같은 동작을 하는 경우는 가급적 동일한 동작을 하도록 만들고, 구현이 서로 불일치하는 경우에는 제가 선호하는(제가 표준을 임의로 해석한) 동작을 따랐습니다. 따라서 알파희의 동작은 제 선호를 반영한 것이기 때문에 구현체간의 차이에서 특별히 대표성을 가진다고 말하기 더 어렵습니다.

[youknowone]

공백에 관한 동작에는 표준 개정에는 조금 우려스러운 부분이 있습니다. 저는 이전의 구현체들의 동작과 일치하지 않는 동작에 따라 표준을 개정하는 것은 개정 이전의 구현체와 개정 이후의 구현체의 동작을 다르게 만들어서 구현체의 동작을 신뢰할 수 없게 만들거나, 반대로 개정된 표준을 무시하게 만들어서 표준의 가치를 떨어뜨리게 된다고 생각합니다.

현재 널리 알려진 구현체들 가운데 공백문자나 주석을 특별하게 취급하는 구현체는 하나도 없습니다. 사실 있다면 표준을 준수하지 않는 구현체들이겠지요. 이걸 "아희"의 이름으로 스펙으로 채택하는건 대단히 곤란한 일이라고 생각합니다.

[youknowone]

아희 코드에 주석을 남기고 싶다면 현재의 상황에서 제가 권장하고 싶은 방법은 코드를 가급적 위-아래 경계를 넘을 때 2칸씩 이동하지 않도록 만들고, 코드 영역 밖의 아래쪽 등의 명백한 실행영역 밖에 주석을 남기는 것입니다. 코드가 위-아래 경계를 자주 넘나든다면 쉽지 않은 일일 수 있지요.

하지만 아희를 보통 난해한 프로그래밍 언어로 취급한다는 점을 고려하면 이정도의 난점은 괜찮다고 생각합니다. 난해한 프로그래밍언어들은 대개 한 가지의 목표에 집착하기 마련이고, 아희의 경우에는 이동 경로가 한글의 모음에 의존하는 것입니다. 따라서 아희의 아희의 특징을 오히려 무시하는 기능인 주석을 위해 복잡한 스펙을 추가하는건 (제 생각에는) 언어의 정체성에 반하는 일이 아닌가 생각됩니다.

[youknowone]

본래 이슈로 돌아가면, @xnuk 님이 질문하신 동작은 현재 아희 스펙으로는 명확히 설명되지 않는 부분입니다. "반대쪽 끝"에 대한 정의가 제대로 되어 있지 않거든요. 제가 선호하는 해석은 "이동을 처리한 후 코드 경계를 넘어가면 반드시 반대편의 문자가 있는 첫 칸으로 도달한다" 입니다. 하지만 구현체 중에는 1칸씩 두번 이동하는 것처럼 간주해서 2칸 이동 중 첫번째에 반대편 끝으로 넘어가고 한번 더 이동하는 경우(망)도 있습니다. 둘다 표준과 딱히 부합하지 않는다고 말하기 어려운 동작이죠. 심지어는 빈 칸을 실제로는 존재하는 빈 문자가 가득 찬 영역으로 여기고 첫 이동에는 분 위의 공간에, 두번째 이동에는 분에 도달하는 경우도 있고, 저는 이 경우도 현재의 스펙에는 일치하는 동작이라고 생각합니다.

[youknowone]

아희 org에는 snippets라는 저장소가 있는데요. 여기에는 표준에서 불명확한 동작만을 모아놓은 디렉토리(undefined)가 있습니다.
다른 불명확한 표준에 관심이 있으면 이 디렉토리의 다른 파일을 좀 더 찾아보셔도 좋을 것 같습니다.
이 동작에 관련된 파일 링크도 같이 남길게요.

https://github.com/aheui/snippets/blob/master/undefined/boundary.aheui

[disjukr]

일단 주석이 아희에 어울리지 않는다는 의견에는 공감하지만 반대쪽 끝으로 이동 시에 공백문자를 특별하게 취급하는 것을 스펙으로 채택하는 것은 저는 문제되지 않는 부분이라고 생각합니다.
저는 '처음으로 나오는 공백이 아닌 문자'를 반대쪽 끝으로 정의하는 것이 합리적이라고 생각합니다.

기존에 아희 스펙으로 명확하게 정의되지 않은 동작에 의존하는 코드가 있다면 그 것은 스펙이 명확해지기 전까지는 아희 방언으로 작성된 코드라고 봐야 한다고 생각합니다. 그런 코드들은 모든 기존 스펙을 준수하는 아희 구현체에서 동일하게 돌아간다는 보장을 할 수가 없을 테니까요.

스펙에서 정의를 명확하게 만든 다음 기존 구현체들을 그에 맞도록 개선하는 쪽이 옳다고 생각합니다.