현재 위치는 expl3 지원하는 TeX 기본 사항과 함께 작동하는 패턴을 설정하기 위한 팀의 여러 실험을 따릅니다. 특히 변수는 매크로를 사용하거나 레지스터를 사용하여 구현될 수 있다는 점과 TeX 그룹화가 작동하는 방식을 염두에 두는 것이 중요합니다.

레지스터를 사용할 때(_e.g._ int 유형) 레지스터 번호와 액세스에 사용하는 cs를 연결하기 위한 할당자가 필요합니다. 대조적으로, 필요하지 않은 매크로 기반 스토리지의 경우. 따라서 \cs_set_eq:NN 를 사용하여 새 tl 이름을 생성할 수 있지만(예:) 레지스터를 사용하는 모든 항목에서는 실패합니다.

\int_set_eq:NN \l_undeclared_int \l_tmpa_in

오류가 발생합니다.

로컬 레지스터 할당자를 만드는 것이 가능하며 과거에 _e.g._ \int_local_new:N 대해 시도했습니다. (이러한 구현 중 하나에 대해서는 etex 패키지를 참조하거나 expl3 기록을 다시 살펴보십시오.) 팀은 결국 TeX 범위 지정에 '적합'하지 않은 것 같아 이에 반대하기로 결정했습니다. 여기서 핵심은 TeX 그룹화가 선언에 기반하지 않고 오히려 명시적 그룹에 기반하고 지역 변수가 중첩된 그룹 내에 존재한다는 것입니다.

\begingroup
  \def\foo{}
  \begingroup
  \show\foo

변수의 로컬 _생성_을 시도했을 때 TeX 그룹화가 작동하는 방식을 모호하게 하고 프로그래머를 오도할 수 있는 위험이 있는 것처럼 보였습니다.

따라서 우리는 변수의 '모든 전역' _선언_을 사용하지만 이러한 변수의 로컬 및 전역 _설정_을 사용하기로 결정했습니다( \l_... _대 \g_... 규칙). 이것은 중요한 것, 즉 가치를 지역화합니다. 따라서 모든 선언이 최상위 수준에 있는 것이 좋습니다.

\tl_new:N \l_my_tl
\int_new:N \l_my_int

...
\cs_new_protected:Npn \my_func:nn #1#2
  {
    \group_begin:
      \tl_set:Nx \l_my_tl { \tl_lower_case:n {#1} }

현재까지 이 패턴은 expl3 가 사용된 작업에 대해 잘 작동하는 것으로 보입니다.

tex에서는 지역적으로 정의된 변수라도 그룹이 끝난 후에 완전히 소멸되지 않습니다. 그들은 여전히 ​​약간의 문자열 공간을 사용합니다: https://tex.stackexchange.com/questions/316999/release-space-in-the-string-pool. 따라서 변수를 전역 개체로 보는 것이 좋습니다.

@u-fischer 좋은 점: 당시에 실제로 고려한 것은 아니지만 염두에 둘 가치가 있습니다.

제 생각에는 이 접근 방식이 잘못되었습니다. 이는 구조적 프로그래밍 원칙에 위배되며 지역 변수 생성을 가능하게 하는 TeX에도 위배됩니다. 또한 일부 데이터 유형은 지역 변수를 수용하고 일부는 그렇지 않기 때문에 LaTeX3를 일관성이 없게 만듭니다.

모든 유형의 변수에 대한 로컬 생성을 다시 시작하도록 요청하고 싶습니다. 이것은 프로그래머에게 선택권을 줍니다. 모든 변수를 전역적으로 정의하는 것을 선호하는 사람은 그렇게 할 수 있고 일부는 전역적으로, 일부는 지역적으로 정의하려는 사람도 그렇게 할 수 있습니다.

메모리 관련 또는 기타 주의 사항이 있는 경우 설명서에서 언급할 수 있습니다.

2017년 10월 18일 21:17 EvanAad [email protected]에서 다음과 같이 썼습니다.

내 생각에 이것은 잘못된 접근 방식이며 다음을 요청하고 싶습니다.
변수의 로컬 생성을 다시 시작합니다. 이것은 프로그래머에게
선택: 모든 변수를 전역적으로 정의하는 것을 선호하는 사람들은 그렇게 할 수 있습니다.
일부는 전역적으로 정의하고 일부는 로컬로 정의하려는 사람들도 그렇게 할 수 있습니다.

레지스터 유형을 기반으로 하는 변수의 경우 다음에서 리소스를 할당합니다.
고정된 전역 풀이므로 이름의 전역 할당은 실제로 훨씬 더 많습니다.
자연스러운. 우리가 etex를 가정하면 256개 이상의 레지스터가 있습니다.
각 유형에 따라 할당 동작은 아마도 그것보다 더 많이 숨겨질 수 있습니다.
클래식 텍스로 할 수 있지만 여전히 기본적인 기능입니다.
기본 TeX 시스템. expl3은 결코 완전히 일반적인 프로그래밍이 될 수 없습니다.
언어: 기본 TeX 시스템과 함께 작동해야 합니다. 당신은 안된다
C#과 비교하지만 다른 TeX 기반 언어와 특히
\newcount와 친구들.

다른 모든 언어가 변수를 허용한다고 말하는 것도 사실이 아닙니다.
예를 들어 fortran은 지역 범위에서 선언된 변수만 허용합니다.
함수/서브루틴의 시작 부분에 선언됩니다.

위의 어느 것도 지역 선언을 추가하지 않을 것임을 의미합니다.
그러나 범용 언어에 호소하는 것은 좋은 사용 사례가 아닙니다.
tex 조판 내에서 합리적인 사용 사례가 필요합니다.
전역 선언 시스템을 사용하는 것이 문제였습니다.

Fortran에서 함수/서브루틴 시작 시 변수를 선언해야 한다는 사실이 해당 변수가 전역 변수임을 의미하지는 않습니다. 모든 변수를 선언해야 하는 프로그래밍 스타일을 고집한다면 그렇게 하되 전역 변수 선언에 해당하는 지역 변수 선언 기능을 제공하십시오.

범위 지정 및 지역 변수에 대한 근거는 무엇보다도 개념적입니다. 기본 TeX 엔진이 지역 변수와 관련된 일부 리소스를 해제하지 않는다는 사실은 무시할 수 없지만 제 생각에는 이것이 범위 지정 및 지역 변수의 개념을 없애는 이유가 될 수 없습니다. 파워 프로그래머를 제외하고 기본 구현은 문제가 되지 않습니다. 그리고 파워 프로그래머의 경우 문서에서 팁과 주의 사항을 제공할 수 있습니다.

범용 언어에 호소하는 것은 좋은 사용 사례가 아닙니다.

TeX를 포함하여 1960년대부터 오늘날까지 거의 모든 프로그래밍 언어에서 구현된 구조적 프로그래밍의 원칙에서 벗어나는 것은 LaTeX3 팀이 해야 할 매우 강력한 이유가 있어야 합니다. 입증 책임은 어디에서나 좋은 프로그래밍 관행으로 간주되는 것과 TeX에 이미 존재하는 것을 폐지하려는 사람들에게 있습니다. 그것을 보존하고자 하는 사람들에게는 아닙니다.

@EvanAad 토큰 목록, 쉼표 목록 시퀀스 및 속성 목록 변수는 실제로 TeX 매크로이지만 다른 종류의 변수는 그렇지 않습니다. 정수 변수를 로컬로 선언하는 것이 허용된다고 가정해 보겠습니다. 이것은 레지스터를 소모하며 할당이 이미 할당된 레지스터를 건드리지 않도록 전역적으로 처리해야 합니다.

로컬 정수 변수 \x 에 상위 레벨의 \y 변수가 이미 사용하고 있는 레지스터 100이 할당되었다고 가정해 보겠습니다. 사용 \y 같은 수준에서 \x 로컬로 정의하는 것은 단순히 재앙이 될 것입니다. 따라서 할당된 레지스터의 글로벌 부기가 필요하므로 로컬 할당 레지스터를 해제하기가 ​​매우 어렵습니다. 로컬 할당을 위해 레지스터 블록을 예약하는 것은 솔루션이 아닙니다.

할 수 없다는 말은 아니지만 고통을 겪을 가치는 없다고 생각합니다.

\newcount가 단순히 로컬(또는 전역)이 아니라는 사실을 놓치고 있습니다.
이름을 선언하면 이름을 외부에서 정의된 고정 이름과 연결합니다.
자원. 하나의 카운트 레지스터 42와 모든 이름이 있습니다.
count42가 동일한 레지스터를 참조하는지 여부를 의미하는 것으로 선언되었습니다.
이름 할당은 로컬 또는 글로벌입니다. 다른곳과의 비교를 말씀드렸듯이
언어는 그다지 유용하지 않지만 비교를 원하면
할당 파일 스트림 또는 일부 비교: 항상 격리할 수는 없습니다.
외부에서 정의된 것과 인터페이스할 때 로컬 선언
자원.

2017년 10월 18일 21시 43분에 EvanAad [email protected]에서 다음과 같이 썼습니다.

Fortran은 시작 시 변수를 선언해야 한다는 사실
함수/서브루틴은 해당 변수가 전역적임을 의미하지 않습니다. 내가
모든 변수가 있는 프로그래밍 스타일을 권장하는 경우
반드시 선언되어야 하지만 로컬 선언을 위한 함수를 제공해야 합니다.
전역 변수를 선언하는 변수에 해당하는 변수입니다.

범위 지정 및 지역 변수에 대한 근거는 무엇보다 중요합니다.
개념적. 기본 TeX 엔진이 일부를 릴리스하지 않는다는 사실
지역 변수와 관련된 리소스는 무시할 수 없습니다.
그러나 내 생각에는 이것이 개념을 없애는 이유가 될 수는 없습니다.
범위 및 지역 변수. 파워 프로그래머를 제외하고,
기본 구현은 문제가 되지 않습니다. 그리고 파워 프로그래머를 위한 팁
설명서에서 주의 사항을 제공할 수 있습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/latex3/latex3/issues/410#issuecomment-337721923 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ABNcAimMfBDqA-e96Q7tkS-ERr5fv_2Mks5stmLqgaJpZM4P-Mpq
.

중요한 점은 요셉과 다윗이 언급 한 바와 같이, 수 있다는 것입니다 int 의가 될 수 로컬로 정의 될 (그리고있다) 수행합니다. 나는 그것이 언어를 만들기 위해 고통을 가치가있다 생각 선물 구조화 프로그래밍의 원리와 일치한다 일관성있는 추상화 계층.

그러나 나는 LaTeX3 언어를 구현하는 고통을 겪은 사람이 아니기 때문에 고통의 가치가 있다고 말하기는 쉽습니다. 그러니 자비로운 접근을 하고 실제로 고통받을 가치가 없다고 말합시다. 괜찮은. 이 경우 데이터 유형을 지역 변수 생성을 허용하는 유형과 허용하지 않는 유형의 두 가지 범주로 나눕니다. 그리고 매뉴얼에서 이러한 범주를 설명하십시오. 말하지 마세요: 모든 변수는 사용 전에 선언해야 합니다. "데이터 유형에는 두 가지 범주가 있습니다. 첫 번째는 cs , tl , clist , ...로 구성되며 두 번째는 지역 변수를 수용합니다. int , ... 그렇지 않습니다." 그리고 두 번째 범주가 존재하는 이유를 설명하십시오. 이런 식으로 문서는 사실에 충실하며 프로그래머는 정보를 잘 알고 선택할 수 있습니다. 일부 프로그램은 두 번째 범주의 데이터 유형을 전혀 사용할 필요가 없으며 이러한 경우 프로그래머가 전역 변수를 선언해야 하는 이유는 무엇입니까?

@EvanAad 내가 TeX 프로그래밍(TeX90의 '전통적인' 제한 사항 포함)에 익숙하기 때문이라고 생각하지만 현재로서는 현재 접근 방식의 문제가 무엇인지 잘 모르겠습니다. 우리는 로컬 할당 변수를 지원하고 실제로 권장합니다. 이는 매우 일반적이며 실제로 변수 이름 지정에 대한 구문의 일부입니다( \l_... / \g_... ). 그들이 전역적으로 할당/'예약'된다는 사실은 그것을 방해하지 않습니다.

BTW, 우리는 구현에 인터페이스를 묶고 싶지 않습니다. 예를 들어, prop 데이터 유형에는 제가 아는 최소한 몇 가지 다른 구현이 있습니다. 그 중 하나는 레지스터를 사용하고 현재 하나는 매크로를 사용합니다.

여기에 한 가지 더 덧붙이자면, 낙타의 등뼈를 부러뜨린 지푸라기(내 기억에)는 지역 레지스터/변수 할당 시스템이 무너진 것은 불일치 때문이었습니다. 매크로와 레지스터가 다르게 동작하기 때문에 작성할 때 다른 동작으로 끝났습니다.

\group_begin:
  \int_new_local:N \l_tmpa_int
  \int_gset:Nn \l_tmpa_int {7}
\group_end:
% `\l_tmpa_int` undefined

대

\group_begin:
  \tl_new_local:N \l_tmpa_tl
  \tl_gset:Nn \l_tmpa_tl {7}
\group_end:
% `\l_tmpa_tl` defined as `7`

그리고 이 문제를 해결하는 유일한 방법은 오버헤드로 인해 심각하게 고려되지 않은 매크로에 대한 할당 시스템을 작성하는 것입니다. (TeX는 더 많은 변수가 정의되는 속도를 늦추므로 토큰 목록의 수를 두 배로 늘리면 성능에 눈에 띄게 영향을 줄 수 있습니다.)

나는 여전히 expl3 가 매크로와 레지스터를 동일한 모양과 느낌을 주는 함수로 추상화하여 옳은 일을 했다고 생각합니다. 그리고 단점은 구문이 자연스럽게 진정한 지역 변수와 레지스터를 지원하지 않는다는 것입니다. 위에서 설명한 이유 때문에 TeX에서 사용이 극히 제한적이지만 내 관점에서 이는 허용 가능한 절충안입니다.

@wspr 하지만 낙타의 등뼈가 부러진 것으로 인용한 예는 프로그래머가 지역 변수에 전역적으로 할당하여 언어를 남용한 예입니다. 이것은 프로그래머에 있습니다. 프로그래머가 전역 변수인 것처럼 여전히 \l_... 변수를 사용할 수 있기 때문에 현재 시스템은 언어 남용 문제를 해결하지 못합니다.

... 그것은 구조적 프로그래밍 원칙과 일치합니다.

하나 이상의 세트가 있다는 점을 감안할 때 매우 대담한 진술입니다.
원칙과 다른 원칙을 통합하려는 시도를 감안할 때
상위 집합은 일반적으로 과거에 크지만 쓸모없는 언어를 만들었습니다.

중요한 점은 반드시 무언가를 할 수 있다는 것이 아닙니다(
Turing 완전한 기반 내에서는 모든 것이 해당 수준에서 동일합니다)
무언가를 효율적이고 일관되게 수행할 수 있는지 여부 등

@wspr : 왜 이 문제를 깡패처럼 닫았나요? 그것은 아무것도 해결되지 않습니다.

@EvanAad — 그냥 깔끔하게 정리하려고 합니다. 논의는 확실히 계속될 수 있으며 정당한 경우 다시 열 것입니다.

일부 뜨거운 댓글로 인해 이러한 문제를 일시적으로 잠그고 있습니다.

나는 이것이 관련 질문이라고 생각합니다. 이 토론의 결과 중 하나는 적어도 문서에서 전역 선언만 선택한 이유를 더 자세히 설명해야 한다는 것입니다. @EvanAad 나는 당신이 TeX 시스템의 한계를 잘 이해하지 못한다고 생각하지만, 잠시 뒤로 물러서서 그 문제를 무시하도록 하겠습니다. 가상의 \int_local_new:N 또는 선택한 의미 체계와 함께 선택한 다른 시스템을 사용하는 예(예: 10-20줄)를 제공할 수 있습니까? 보다 구체적인 설정에서 토론을 구성하는 데 도움이 되며 이점/단점을 해시할 수 있습니다.

자물쇠가 풀릴 때까지 기다려야 할 것 같은데 어떻게 해야 할지 모르겠습니다. 어쨌든 이 대화에 참여하는 대부분의 사람들은 몇 시간 동안 잠을 자게 될 것입니다. (참고로 410번을 411번으로 복사해서 토론이 뒤죽박죽이 된 것은 그다지 합리적이지 않다고 생각합니다.)

이것이 매우 상세한 논의라는 사실을 돌이켜보면, 우리를 여기까지 오게 한 기술적, 사회적 역사를 요약할 가치가 있다고 생각합니다.

기술 수준에서 TeX는 저장을 위한 레지스터와 매크로를 제공합니다. 매크로는 \def 사용하여 '생성'할 수 있지만 레지스터를 이름으로 사용하려면 전역 레지스터 번호 _e.g._ \count40 를 일부 이름(예: \mycount 에 연결하는 할당자가 필요합니다. \newcount , _etc._ 모델을 제공합니다. 일반적으로 \newcount 전역적으로 할당하며 이름에도 불구하고 검사를 수행하지 않습니다. 다른 형식, 특히 LaTeX2e 및 ConTeXt는 모두 일반적으로 이 접근 방식을 채택했습니다. 그들은 또한 일반적으로 개별 레지스터가 로컬 또는 전역적으로 _할당_된다는 아이디어를 채택했습니다. 이렇게 하면 스택 축적이 방지되기 때문입니다.

TeX90은 공통 유형의 레지스터를 256개만 제공했기 때문에 로컬 컨텍스트에서 레지스터를 재사용하는 것이 중요했습니다. _e.g._ graphics 에서 코드를 '정상'으로 유지하기 위해 많은 수의 레지스터에 그룹 내에서 새 이름이 지정되고 순전히 로컬에서 사용됩니다. e-TeX를 사용하면 _lot_ 더 많은 레지스터가 있으므로 이 접근 방식은 덜 필요합니다. 전용 목적을 위해 더 많은 레지스터(및 매크로)를 자유롭게 할당할 수 있습니다. 특히, 그것은 우리가 여러 이름으로 레지스터를 '재활용'하라는 압박을 받는 것과 같지 않다는 것을 의미합니다.

expl3 의 코드 기반은 _long_ 시간 동안 개발되었으며 원래 e-TeX가 필요하지 않았습니다. expl3 개발은 주로 LaTeX2e의 '상단'에서 이루어지며 expl3 는 문서 이름 공간을 오염시키지 않고 핵심 LaTeX2e 동작을 변경하지 않습니다.

특히 LaTeX2e의 \newcount 는 일반의

\def\foo{%
  \begingroup
    \newcount\localfoocnt

\foo 가 여러 번 호출되는 것처럼 '나쁜 스타일'입니다. 그러면 해제되지 않는 레지스터를 모두 사용하게 됩니다.

expl3 의 경우 팀은 문서화된 변수 동작을 매크로 또는 레지스터 구현에 묶는 것을 피하려고 했습니다. (접근자 없이 tl 를 사용할 수 있다는 점에 유의합니다. 이는 궁극적으로 매크로에 의존합니다.) 또한 정수, 차원, _etc._에 대한 레지스터를 사용 가능하고 제공합니다. 매크로에서 모든 작업을 수행하는 것보다 더 나은 성능과 '자체 종료'. (e-TeX와 다양한 \<thing>expr 프리미티브를 사용하면 가능합니다.) 따라서 할당자 시스템이 필요하고 일관성을 유지하기 위해 레지스터 기반 변수뿐만 아니라 모든 변수 유형을 할당해야 합니다. . @EvanAad 가 관찰한 것처럼 검사가 활성화되지 않은 경우 오류 없이 _e.g._ \tl_set_eq:NN \l_new_tl \l_existing_tl 를 수행할 수 있지만 이것은 지원되는 동작이 아닙니다(예를 들어 검사를 통해 플래그가 표시됨).

expl3 할당자의 일부로 \newcount 와 달리 new 가 존재를 확인하도록 결정되었습니다.

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_new:N \l_my_tl

\my_foo: 가 반복적으로 사용되면 _error_가 발생합니다. 이것은 일반 TeX의 첫 번째 날부터 표준 TeX 관행이었던 방향으로 밀어 넣습니다. 할당은 매크로 외부로 이동합니다. (참고로 \newcount 는 \outer 이므로 매크로 내에서 '금지'됩니다.)

\tl_new:N \l_my_tl
\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_clear:N \l_my_tl

etex 패키지는 수년 전에 \loccount _versus_ \globcount , _etc와 같이 로컬 및 글로벌 레지스터 할당을 수행할 수 있는 레지스터 할당자를 도입했습니다. 꽤 많은 시간 동안, expl3 로드 etex 하고 그것을위한 기능을 제공하는 데 사용 된 \int_local_new:N 과 유사합니다. 대부분의 TeX 프로그래머가 전역 할당을 수행하는 데 익숙하다는 사실을 감안할 때 이것이 그렇게 널리 채택되지 않은 것은 아마도 놀라운 일이 아닙니다. 그러나 팀은 오해의 소지가 있다는 점도 우려했다. 같은 것으로

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_local_new:N \l_my_tl

\my_foo: 에 대한 중첩 호출 또는 \l_my_tmp_tl 와 같은 '간단한' 이름이 사용될 가능성이 더 높은 곳에서 어떤 일이 발생하는지에 대한 질문이 있습니다. new 가 검사를 수행하기를 원한다는 일반적인 생각에 따르면 이는 오류입니다. 다른 많은 언어에서 온 프로그래머는 이것이 다소 이상하다고 생각할 수 있습니다. 물론 TeX의 범위 지정 규칙에 맞습니다.

특히 최근 몇 년 동안 LaTe2e 커널이 변경되어 더 이상 etex 를 로드하고 싶지 않습니다(사실, 우리는 expl3 '자체 포함'으로 만들기 위해 열심히 노력했습니다). 따라서 새로운 로컬 할당자는 expl3 사용하지 않는 사람들을 위한 '방해' 동작 없이 LaTeX2e와 함께 작동하도록 작성되어야 합니다.

\l_my_tmp_tl 와 같은 경우에는 물론 여전히 전역 할당을 수행할 수 있지만 현재 그룹에서 어떤 \l_... 변수가 로컬로 할당되고 어떤 것이 전역적으로 할당되지만 로컬로 할당되는지 알아야 합니다.

테스트 데이터를 가지고 있지는 않지만 변수를 할당하는 것이 단순히 설정하는 것보다 더 많은 작업이 되므로(확실히 검사가 활성화되지 않은 경우) 로컬 할당자를 사용하는 것이 전역 할당자 플러스보다 약간 느릴 것입니다. 지역 과제.

따라서 기술적인 이유와 '역사에 맞는' 이유로 우리는 엄격하게 글로벌 _할당_을 고수하기로 결정했습니다. 이것은 권장되고 매우 널리 사용되는 변수의 로컬 _할당을 어떤 식으로든 방지하지 않습니다.

그것은 우리를 '사회적' 요소로 이끕니다. 최근 몇 년 동안 expl3 비중은 부품을 '광범위하게' 안정적으로 만드는 데 크게 도움이 되었습니다. 어떤 단계에서 팀은 물건에 대한 결정을 내려야 합니다. 부분적으로는 사람들이 그것을 사용할 수 있도록 하고 부분적으로는 우리가 다른 작업으로 넘어갈 수 있도록 해야 합니다. 그렇다고 해서 우리가 물건을 다시 방문하는 것을 막을 수는 없지만 더 확립된 관습에는 변경해야 할 합당한 이유가 필요합니다.

여기에서 현재로서는 '일반적인' 접근 방식이 무엇이 잘못되었는지 알지 못하는 것 같습니다.

\tl_new:N \l_my_tl
\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_clear:N \l_my_tl

적어도 돌아가서 현재 설정을 변경해야 하는 지점까지는.

@blefloch 예, @wspr 이 스레드를 닫는 것에 대한 제 반응이

@josephwright 자세한 답변 감사합니다. 문제에 대해 생각한 후 \<module>_clear_new:N 만 사용하면 실제로 모든 변수가 \<module>_set... 사용하여 할당하는 한 주변 그룹에 로컬인 것처럼 작동한다는 것을 깨달았습니다 \<module>_clear_new:N \<module>_set... 대신 \<module>_gset... . 게다가 이 관행은 사용 전에 변수를 선언하는 LaTeX3 규칙과 일치한다고 생각하므로 확인이 켜져 있으면 플래그가 지정되지 않습니다.

이 연습에 따라 @josephwright 마지막 예제를 다음과 같이 다시 작성합니다.

\cs_new_protected:Npn \my_foo:
{
    \group_begin:
        \tl_clear_new:N \l_my_tl

이 스키마에 맞지 않는 유일한 데이터 유형은 cs 이지만 내가 아는 한 \cs_set:Npn 등을 사용하여 이 유형의 변수를 만드는 것이 합법적입니다. LaTeX3는 cs 를 다른 것과 동등하게 일반 데이터 유형으로 취급하지 않기 때문에 먼저 선언하지 않고 다른 스레드로). 이 접근 방식을 사용하면 cs 변수도 로컬에서 생성할 수 있습니다. 구문 일관성을 유지하려면 항상 나만의 \cs_clear_new:N 래퍼를 작성할 수 있습니다.

따라서 내가 염려하는 한 이제 원하는 경우 이 문제를 닫을 수 있습니다. @wspr .

@EvanAad \<thing>_clear_new:N 에서 선언은 변수가 이미 존재하지 않는 _is_ global입니다. 그래서

\cs_new_protected:Npn \my_foo:
{
    \group_begin:
        \tl_clear_new:N \l_my_tl
    \group_end:
}
\my_foo:
\tl_show:N \l_my_tl

이전에 다른 것으로 설정하지 않았다고 가정하면 \l_my_tl 가 정의되고 비어 있음을 보여줍니다.

이 토론이 더 나은 문서로 이어지기를 바라며 @blefloch 에 합류하고 싶습니다. 특히, 내 원래 게시물에서 인용한 문장에서와 같이 프로그래머가 특정 코딩 패턴을 "반드시" 따라야 한다고 작성할 때 문서에서 이 "반드시"가 의미하는 바를 설명해야 한다고 생각합니다. 패턴을 준수하지 않으면 어떻게 됩니까?

1. 언어의 동작이 정의되지 않습니까?
2. 비준수는 현재 지원되지만 향후 버전에서는 지원되지 않을 수 있습니까?
3. 엔진이 오류를 보고합니까?
4. 엔진이 오류를 보고하지만 검사가 켜져 있을 때만 발생합니까?
5. 약간의 불편이 발생합니까?
6. LaTeX3 팀이 불만을 토로하지만 오류나 기능 손실이 발생하지 않습니까?

5의 예로서, 함수 이름 끝에 인수 사양을 추가하는 규칙을 취하십시오. 내가 말할 수 있는 한, 이 규칙을 준수하지 않으면 제대로 작동하지 않는 유일한 기능은 \cs_new:Nn 이지만 `cs_ new:Npn '을 포함한 나머지 기능은 완벽하게 작동합니다.

6에 대한 예를 들면 \g_... 및 \l_... 지역 및 전역 변수를 표시하는 규칙을 따르십시오. 내가 아는 한, 이 협약을 따르지 않는 것에 대한 영향은 전혀 없을 것입니다. 모든 것이 제대로 작동합니다.

@EvanAad — 사과를 수락했으며 토론이 완료되기 전에 문제를 종료한 것에 대해 제 입장에서는 유감입니다.

@josephwright — 지역 할당에 대한 작은 이점 중 하나로서,

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_new_local:N \l_my_tl
      ...

그러면 \l_my_tl 가 외부로부터의 간섭으로부터 자유로울 뿐만 아니라 _clear 함수를 사용하는 것과 달리 변수의 모든 자취가 함수를 사용하지 않고 사라진다는 것을 알고 있습니다. 즉, 코드 만 봐도 반 전역 변수로 사용할 수 없다는 것을 알 수 있습니다. (그리고 \tl_if_exist_p:N 를 사용하여 이상한 일이 일어나지 않는지 확인할 수 있습니다.)

(실행해야 하지만 더 논의할 사항이 있으면 나중에 계속할 수 있습니다.)

@wspr 예, 하지만 이것은 TeX 그룹 범위를 기반으로 한다는 사실과 함께 돌아왔습니다. 따라서 다음 형식의 구성에서 '반 전역적으로' 사용할 수 있습니다.

\cs_new_protected:Npn \my_foo:
  {
    \group_begin:
      \tl_new_local:N \l_my_tl
      \tl_set:Nn \l_my_tl { foo }
      \__my_foo:
     ..
  }
\cs_new_protected:Npn \__my_foo:
  {
    \group_begin:
        \tl_use:N \l_my_foo % Definition from \my_foo: => "foo"
...
  }

그것은 적어도 우리 생각의 일부였습니다.

이 글을 떠나기 전에 기술 수준에서 로컬 레지스터 할당자를 설정하는 여러 가지 방법이 있음을 강조하고 싶습니다.

@josephwright — 나는 그것을 혼란스러운 예로 본 적이 없습니다. 예를 들어 Matlab에서는 범위를 공유하지 않는 하위 함수와 범위를 공유하는 중첩된 하위 함수를 구분합니다. 그래서 내 생각에는 항상 \__my_foo: 가 "외부" 기능의 범위를 상속 하지 않는 이유

(토론을 계속해서 죄송합니다. 긴 하루였습니다. 실제로 계속하고 싶은 사람이 있습니까?)

Am 19.10.2017 um 09:23 schrieb Joseph Wright:

나는 우리가 이것을 떠나기 전에 그것을 강조하고 싶다고 생각한다.
기술 수준 로컬 레지스터를 설정하는 방법에는 여러 가지가 있습니다.
할당자.

예, 그러나 Turing 인수에 상당히 가깝습니다. 즉, 그러한 구현
기본 엔진 때문에 런타임에 매우 비효율적일 것입니다.
레지스터 저장소를 전역적으로 관리하고 있습니다. 그리고 expl3(해당 수준에서)
"합리적으로 효율적이어야 합니다.

예를 들어 전역 및 지역 변수와 그 mutator와 같습니다. 꽤
전역 작업을 수행하는 경우 각 기능에서 테스트하는 것보다
지역 변수, 개념은 기본적으로 이름에만 존재합니다.
예를 들어 \l_...은 지역 변수로 간주되며 사용해서는 안 됩니다.
..._ gset:Nn 과 같은 전역 함수를 사용하지만 우리는 그것을 테스트하지 않습니다.
실행 시간

그러나 우리는 검사 모듈을 제공합니다(몇 배 더 느리게 실행됨)
이는 이러한 모든 규칙이 실제로 준수되는지 확인합니다.

전역/로컬 변수로 돌아가려면

expl3의 표준 개념은

• 변수 이름을 한 번(전역적으로) 선언합니다.
  적어도 일부 유형에는 전역 저장 저장소만 있습니다.

• 지역 및 전역 변수를 나타내기 위해 이름 규칙 \l_ \g_ 사용

전역 및 지역을 모두 제공하지만 다음과 같은 제한 사항이 있습니다.

• 범위 시작 부분에 지역 변수를 선언하지 않습니다.
  대신 그 시점에서 _set 또는 _clear_new를 사용하고 후자는
  변수의 이름이 그 지점에 전역적으로 올 수 있음을 의미할 수 있습니다.
  존재하는

• 범위 외부에 변수가 여전히 기본값과 함께 존재합니다.
  유형의 값(예: _int가 0 등)이므로 컴파일러를 얻지 못합니다.
  의도하지 않은 "실수로" 그러한 변수를 참조하는 경우 오류가 발생합니다.
  범위

따라서 기본적으로 얻을 수 없는 유일한 것은 다음을 선언할 수 있다는 것입니다.
이름이 범위 밖에서 사라지도록 지역 변수(그리고
외부에서 참조되는 경우 런타임 시 어떤 종류의 정의되지 않은 오류
선언된 범위).

그렇게하려면 (예 가능합니다) expl3은 자체 유지 관리가 필요합니다.
전역 이름 간의 단순한 연결을 훨씬 뛰어 넘는 리소스 풀
엔진에서 제공하는 풀이며 이는 모든 액세스가
매우 현저하게 느려진 작업 - 이는 expl3의 설계 기준에 위배됩니다.

@FrankMittelbach — 이제 당신은 나를 궁금해합니다. 레지스터에 대한 etex.sty 접근 방식이 실제로 그렇게 비효율적입니까? 또는 tl 변수를 의미할 수도 있습니다. 이 경우에는 동의합니다!

@FrankMittelbach 내 의견으로는 LaTeX3 팀에 따른 모범 사례와 LaTeX3 언어 규칙의 문법적 또는 의미적 형식 요구 사항을 구별하고 문서에서 명확히 하는 것이 중요합니다.

귀하가 인용한 두 가지 규칙, 즉:

• 변수 이름을 한 번 선언합니다(전역적으로).
• 이름 규칙 \l_ \g_ 를 사용하여 지역 및 전역 변수를 나타냅니다.

LaTeX3 팀이 권장하는 이 코딩 규칙 루브릭에 속하지만 둘 중 어느 것도 언어의 문법 규칙에 의해 강제되지 않으며 이러한 규칙을 준수하지 않아도 오류나 기능 손실이 발생하지 않습니다.

즉, 이러한 규칙을 따르는 것은 개인의 취향과 코딩 스타일의 문제이며, 내 생각에는 문서에서 이를 명확히 해야 합니다.

50mh라는 표시는 규칙이 아니라 운전이라고 말하는 것과 같습니다.
규약이며 운전자가 그것을 준수하는지 여부는 취향의 문제입니다(단지
대부분 즉시 확인되지 않기 때문에)

_gset과 함께 \l_ 변수를 사용하면 여전히 TeX에서 프로그래밍하지만
당신은 expl3의 문법 규칙에 순종하는 것을 중단했습니다
언어. 코드가 즉시 손상됩니까? 아마 아닐지 모르지만 당신은
저장 스택 빌드업 생성(TeXbook 색인 참조)

당신은 우리가 그것을 확인하는 경우에만 문법 규칙을 말하고 있습니까?
런타임, 예를 들어 매주 화요일?

@FrankMittelbach 물론, 당신은, 그것은 정의에 너무이지만 확인되지 않습니다 때문에 내 요점은,이 언어의 규칙의 일부로 정의되어서는 안된다는 것보다이 언어의 규칙의 일부로 정의 경우 이 규칙을 준수하지 않는다고 해서 그 자체로 오류나 기능 손실이 발생하지는 않기 때문입니다.

"영어를 쓸 때 잉크가 번지는 것을 방지하기 위해 펜을 오른손에 잡는 것이 가장 좋습니다"라는 말의 차이입니다. 영어는 오른손에 펜을 잡고 써야 한다는 법을 통과시켰습니다. 물론, 그런 법을 통과 시킬 수 있고 그것을 정당화하는 건전한 근거가 있지만, 결국 펜을 잡을 손은 개별 작가에게 맡겨야 합니다. 그리고 이 규칙을 따르지 않기로 선택하고 여전히 그것을 준수하는 사람들만큼 깔끔하게 글을 쓰는 사람들이 있을 것입니다.

@FrankMittelbach 는 로컬 선언의 오버헤드를 과장한다고 생각합니다( \loccount 는 로컬에서 카운트를 관리하고 전역적으로 수행하지 않으므로 오버헤드를 잘 유지합니다).

\int_zero_new:N 및 \tl_clear_new:N 와 매우 유사한 \int_local:N 및 \tl_local:N (= \tl_set_eq:NN #1 \c_empty_tl ) 등을 제공하는 데 큰 문제가 없습니다

@EvanAad 변수를 선언하지 않으면 어느 시점에서

\documentclass{article}
\usepackage{expl3}
\begin{document}
\ExplSyntaxOn
\tl_put_left:cn { l_my_tl } { foobar \par }
\l_my_tl
\end{document}

@blefloch 내가 \<module>_clear_new ), 이름을 \l_amount_paid_int 지정할 필요가 없습니다. 다른 프로그래밍 언어에서와 마찬가지로 \amount_paid 또는 \amountPaid 입니다. \l_..._int 는 정수이고 로컬에서 사용되어야 함을 상기시켜주는 멋진 니모닉이지만 강제로 사용해서는 안 됩니다.

확인되지 않고 이 규칙을 준수하지 않기 때문에
그 자체로는 오류나 기능 손실이 발생하지 않습니다.

하지만 그게 요점이야

) 상황에 따라 해를 끼칩니다. 즉, 혼합할 때
동일한 변수에 대한 전역 및 지역 할당

b) 요청 시 확인합니다(현재 해당 코드는
기능적이지만)))

ps 예 펜을 잡는 것(왼손잡이)에 대한 당신의 요점을 알겠습니다.
(내 자전거에서) 제한 속도를 초과했지만 여전히 이것을 고려합니다.
교통 규칙은 교통 규약이 아니며 예를 들 수 있습니다.
해를 끼치 지 않지만 그로 인해 죽거나 적어도 벌금으로 끝날 수도 있습니다.

(이전 코드 예제에서 지적한 것은 tl의 경우에도 사용 전에 선언하는 것이 필수적이라는 것입니다. 선언을 테스트하는 검사 옵션이 있지만 일반적인 사용에서는 그러한 오버헤드를 원하지 않습니다.)

나는 이름이 단지 관례 라는

'관례'에서 \amountPaid 는 문서 명령이지만 \l_amount_paid_int 는 그렇지 않으며 후자는 amount 네임스페이스의 일부입니다(관례에 따라 TeX에서 꽤 중요한 것입니다. ). \l_ / \g_ 에는 적용되지 않지만 많은 언어가 기술 수준에서 적용되지 않고 명명에 강력한 '조종'이 있다고 생각합니다.

2017년 10월 19일 16:58에 Joseph Wright [email protected] 은 다음과 같이 썼습니다.

'관례'에서 amountPaid는 문서 명령인 반면 \l_amount_paid_int는 그렇지 않으며 후자는 amount 네임스페이스의 일부입니다(관례상 그러나 TeX에서 매우 중요한 것입니다). 그것은 \l_/\g_에 적용되지 않지만 많은 언어가 기술 수준에서 시행되지 않고 명명에 강력한 '조정'이 있다고 생각합니다.

LaTeX2e 프로그래밍에서 최악의 악몽은 명령을 정의하는 것입니다.
"사용자 수준 공간"에서 \foo라고 말하여 충돌을 발견합니다.
명령으로 _internal_ 사용을 위해 정의된 다른 패키지(그래서
설명서에 문서화되어 있지 않음).

정말 일어난 일입니까? 네, 한 번만은 아닙니다. 에 집착
\@commandname 규칙은 피하는 데 매우 도움이 되었습니다.
그런 문제들.

물론 "사용자 수준 공간"에서 충돌도 발생할 수 있습니다.
그러나 그들은 발견하고 해결하기가 훨씬 쉽습니다. 그것이 올 때
내부적으로는 매우 빠른 속도로 확장을 추구해야 하는 경우가 많습니다.
깊은 수준.

의원과 달리 벌금이나 징역형을 선고할 수 없다.
LaTeX3 프로그래밍의 법칙을 따르지 않는 사람. 하지만 우리는
커뮤니티와 모든 사람이 해야 합니다.

명명 규칙에 대한 지침은 다음을 찾는 데 도움이 됩니다.
다른 사람과 충돌하는 패키지의 내부 명령'.

개인 코드의 경우 원하는 모든 작업을 수행할 수 있습니다.
사유지에서 속도를 내는 것을 금지하는 법은 없지만,
공공 도로에서 하는 방법이 있습니다.

모든 유형의 변수 \f를 로컬로 정의하려면,
당신은 일부에 의해 정의되는 명령에 대해 걱정해야합니다
패키지 및 Murphy의 법칙에 따라 인수에서 정확히 끝납니다.
변수 \f를 사용하여 함수에. 더 나쁜 것을 상상할 수 있습니까?
대본?

차오
엔리코

이름을 \l_amount_paid_int로 지정할 필요가 없습니다. 다른 프로그래밍 언어에서처럼 단순히 amount_paid라고 부를 수 있습니다. \l_... 은 로컬에서 사용되어야 함을 상기시켜주는 멋진 니모닉이지만 이 니모닉이나 다른 니모닉을 사용할 필요는 없습니다.

확신하는. md5-fc693aa157832059d7daeeb61c55 cddb:paid 또는 amount&paid(농담이 아니라 &를 사용하는 패키지를 알고 있음) 또는 원하는 대로 사용할 수도 있습니다. 그러나 이름이 단지 관례일지라도 사람들이 그러한 관례를 고수하면 의사 소통이 더 쉬워집니다. tex.sx에서 꽤 많은 질문을 하셨습니다. "개인 스타일"로 작성된 코드에 문제가 있으면 어떻게 하시겠습니까? 표준 스타일로 번역하고 질문하고 다시 번역하시겠습니까? 아니면 모두가 당신의 개인적인 스타일을 다룰 수 있기를 기대하십니까?

@eg9

개인 코드의 경우 원하는 모든 작업을 수행할 수 있습니다.

문서를 읽음으로써 이것을 알지 못할 것입니다. 내가 말하는 전부입니다.

모든 유형의 변수 \f 를 로컬로 정의하려면 일부 패키지에 의해 정의되는 명령에 대해 걱정해야 합니다.

나는 동의하지 않는다. 코드가 \group_begin: ... \group_end: 안에 있고 모든 지역 변수를 \<module>_clear_new:N 정의하고 \<module>_set:N... 를 사용하여 지역 변수에만 할당한다면 걱정할 필요가 없습니다. 코드가 다른 패키지를 사용하지 않는 한 로컬 변수가 다른 패키지와 이름 충돌합니다.

@u-피셔

그러나 이름이 단지 관례일지라도 사람들이 그러한 관례를 고수하면 의사 소통이 더 쉬워집니다.

나는 관습을 고수해야 할 좋은 이유가 없다고 말하는 것이 아닙니다. 내가 말하고자 하는 것은 이러한 규약이 언어 규칙이 되어서는 안 되며, 문서는 근거가 명시되어야 하는 규약과 규칙을 명확하게 구분해야 한다는 것입니다. 그리고 관례를 따를 것인지 여부는 궁극적으로 프로그래머에게 달려 있습니다.

@EvanAad 설명하는 경우에도 이름 충돌에 대해 걱정할 필요가 있습니다. 당신이 쓰는 말

\cs_new_protected:Npn \evanaad_halve:n #1
  {
    \group_begin:
      \int_zero_new:N \f
      \int_set:Nn \f { (#1) / 2 }
      \iow_term:x { \int_use:N \f }
    \group_end:
  }

그러면 패키지 사용자가

 \int_const:Nn \f {123}
 \evenaad_halve:n { \f }

그들은 62가 아니라 0을 보고 놀랄 것입니다.

반면에 \evanaad_f 등(또는 l3docstrip 마법을 사용하여 더 짧은 \@@_f 등)과 같은 이름을 고수한다면 안전해야 합니다.

문서를 읽음으로써 이것을 알지 못할 것입니다. 내가 말하는 전부입니다.

죄송하지만 expl3.pdf는 "convention"이라는 단어를 약 20번 사용합니다. public 대 private 명령의 경우 "심각한 컴퓨팅 오버헤드 없이 이를 강제할 방법이 (거의) 없으므로 명명 규칙을 통해서만 구현합니다."라는 문장도 있습니다.

@blefloch 좋은 지적입니다.

@u-fischer 네, 충분히 공정합니다. 함수 이름이 인수 지정자로 끝나야 한다는 규칙은 어떻습니까? 이것은 3.3절의 함수가 인수 지정자를 검사하기 때문에 완전히 규칙은 아니지만 이러한 함수는 단지 "구문 설탕"이며 사용하지 않으면 \mymodule_myfunc 와 같은 함수 이름을 사용하는 데 지장이 없습니다. , 그러나 당신은 설명서에서 그것을 알지 못할 것입니다.

2017년 10월 19일 17:52 EvanAad [email protected]에서 다음과 같이 썼습니다.

@u-fischer 네, 충분히 공정합니다. 함수의 이름이 인수 지정자로 끝나야 한다는 규칙은 어떻습니까? 이것은 3.3절의 함수가 인수 지정자를 검사하기 때문에 완전히 규칙은 아니지만 이러한 함수는 단지 "구문 설탕"일 뿐이며 사용하지 않으면 \mymodule_myfunc와 같은 함수 이름을 사용하는 데 지장이 없습니다.

물론 cs_generate_variant :Nn에 필요합니다.

차오
엔리코

\mymodule_myfunc 를 사용하면 다음에서 어떤 기능도 사용할 수 없습니다.
l3expan . 이러한 확장 기능과 변형의 개념은 다음과 같습니다.
expl3의 핵심 부분.

변수 이름을 더 짧게 만들 수 있다는 데 동의하지만(
"l_"/"g_" 및 "_int"/...), 함수 서명은 실제로 "단지 a가 아닙니다.
협약".

@blefloch 나는 당신의 요점을

\ExplSyntaxOn
\cs_new:Npn \MyDocumentCommand {Hello,~world!}
\ExplSyntaxOff

먼저 "그림자" 함수 \mymodule_my_document_command: 정의한 다음 다음으로 복사할 필요가 없습니다.

\cs_new_eq:NN \MyDocumentCommand \mymodule_my_document_command:

@blefloch 그런데 @eg9가 언급한 \cs_generate_variant:Nn 옆에 l3expan 모듈의 다른 함수가 함수 이름의 인수 지정자 부분을 사용합니까?

지금쯤이면 당신이 논쟁을 위해 크게 논쟁하고 있는 것 같습니다.

예, 당신은 이 모든 것을 할 수 있고 하루가 끝날 때까지 유일한 어려운 언어
규칙은 TeX 엔진이 원시적으로 고정하는 것입니다. 그리고 주어진
TeX는 기본적으로 어디에서나 사용할 수 있는 자체 수정 언어입니다.
거기 예

\endlinechar-1\def~#1{\catcode`#113}~Q~S~U~_~V~W~J~K~L~M~N~O~@~X~Y~[~] ~(
~|~&~Z~'~"~ ~h~z~:~q~j~k~;~/~)~!~,~$~+\let_\let_~newcount~$$-1~Q ~J~V~S~K~W~U~L~,~''1~""2~ *1_&\count&144'&155'&145"&154"_[\ifnum_(\ifcase_O\or
__|\else_]\fi_N\number_@\advance_X\expandafter_Z\global_Y\typeout_~newif
~\ifG~\if_~\def~j{[0 Q[0Jk|$]|$]|$]|$]}~k{&1NQNJ}~\2#1#2{}~:#1{

11#12#13#14#15#16#17#18}~h#1#2{#2:{~\q#1}~#2^^J}~\q#1#2{(&1 #1#2~~OO$]}

~/{Y{행과 열? 예: E6}\read$toM\ifcat~X\2M~$$X\jM|!input!]}~!#1!{
Y{잘못된 #1.}/}~\j#1#2{Q #1@Q- @J #2@J- 0;(V!move!]}~;{V0(jS1z1z0z{$} NS
0z1z{$}S$z1z0z{$}]}~_{@,\ifodd'-]}~z#1{{\trueK#1{\falseq}}}~q{@ QS@JK [j="
\ifZk'Z_2]@V1q|[j='ZVV\ifG\if|\aftergroupq]]]]}~\,#1{Q#1:.}~.#1{J#1;[0
WWVUQLJ]]}~+#1{(#1O2O-2O0O0O0O0O-2O2]}~){'X"X"N'Y{^^J :
~^^Jh1Ah2Bh3Ch4Dh5Eh6Fh7Gh8H :~^^J}\GfalseW(W$|0]~:\,\Gtrue[0 /];k'_1][$=WY{(,동점|플레이어 [0>,.|$]~N[0>,-],].}X\dump]로 승리)}~~{ })

이것은 아름다운 TeX 문서입니다(사실 아름다운 LaTeX 문서)
그러나 코드에 관한 한 그다지 유용하지 않습니다. 그리고
Bruno가 그러한 문서를 작성할 수 있다는 사실이
expl3 매뉴얼(또는 이 경우 LaTeX 매뉴얼)은 이에 대해 설명해야 합니다.

LaTeX(2.09 및 2e) 코드에는 초기에 다음과 같은 큰 문제가 있었습니다.
너무 많은 사람들이 낮은 수준의 단축키에 대해 이해했습니다.
TeX에서는 그렇지 않다고 생각했기 때문에 사용하고 오용했습니다.
해로운. 그 결과 엄청난 양의 기존 2e 패키지가
사용할 때 서로 호환되지 않거나 장소에 미묘한 문제가 있음
함께 등 또는 그들이 하나 또는
사용자 인터페이스(그것 없이도 작동하는 것처럼 보였기 때문에).

당신은 기본적으로 우리에게 이것만 문서화하도록 계속해서 요구하고 있습니다.
즉, 디자인 원칙을 위반하는 가능한 바로 가기
그들은 때때로 작동하기 때문에 (또는 심지어 그 순간에 항상). 그러나 expl3
그리고 그 관습/규칙은 주로 다음과 같은 경험에서 파생됩니다.
코더는 과거에 그러한 규칙을 어겼고 결과는 엉망이었습니다.
이것으로부터. 따라서 규칙은 단순한 변덕이 아니라 고의적인 것입니다(대부분
시간) 그리고 "당신이하는 일을 알고 있다면
특정 상황에서 대부분 우회할 수 있습니다"라는 의미가 아닙니다.
코드를 이동하면 한 위치에서 다음 위치로 여전히
또는 시간이 지남에 따라 그럴 필요가 있습니까?

다른 사람들이 말했듯이 작성하는 코드에는 큰 차이가 있습니다.
"공식적으로" 배포되는 것으로 작성한 코드 및 자신을 위한 비행
패키지. 적어도 후자의 경우, 우리는 규칙을 수락하고
그것들을 언어의 일부라고 생각하십시오. 자신을 위해 다음을 수행할 수 있습니다.
위와 같이 문서를 코딩하는 방법을 배우지만 수행하는 방법에 대한 지식
expl3 설명서에서 나오지 않습니다.

그렇다고 해서 도전적인 개념을 낙담시키고 싶지는 않습니다.
명령, 인터페이스, 무엇을 가지고 있습니까? 당신이 제기한 많은 점들
다른 경우는 잘 처리되었습니다(또는 최소한
또는 다른 점).

그러나 expl3 매뉴얼에 관한 한 나는 당신이 들은 것을 생각합니다.
여러 사람들은 문서화에 관심이 없다는 것입니다.
"비관습"과 "비규칙". 또한 코드가 너무 많이 전환되면
우리가 규칙/관례라고 부르는 것에서 그것은 여전히 ​​TeX 코드이지만
더 이상 expl3 코드가 아닙니다.

나는 우리가 이것을 통해 이야기했다고 생각합니다. 나는 닫을 것이지만 요청하면 물론 다시 열 것입니다.