누셸 코드가 실행되는 방법

누셸 방식으로 생각하기에서 누셸 코드가 처리되는 방식 때문에 *"누셸을 컴파일된 언어로 생각하라"*고 권장했습니다. 또한 해당 프로세스로 인해 누셸에서 작동하지 않는 여러 코드 예제를 다루었습니다.

이에 대한 근본적인 이유는 **eval과 유사한 기능을 허용하지 않는 파싱 및 평가 단계의 엄격한 분리**입니다. 이 섹션에서는 이것이 무엇을 의미하는지, 왜 그렇게 하는지, 그리고 그 의미가 무엇인지 자세히 설명합니다. 설명은 가능한 한 간단하게 하려고 하지만, 이전에 다른 언어로 프로그래밍한 경험이 있다면 도움이 될 수 있습니다.

인터프리터 언어 대 컴파일 언어

인터프리터 언어

누셸, 파이썬, Bash(그리고 다른 많은 언어)는 "인터프리터" 언어입니다.

간단한 "Hello, World!" 누셸 프로그램으로 시작하겠습니다.

# hello.nu

print "Hello, World!"

물론 이것은 nu hello.nu를 사용하여 예상대로 실행됩니다. 파이썬이나 Bash로 작성된 유사한 프로그램은 거의 동일하게 보이고 동작합니다.

*"인터프리터 언어"*에서 코드는 일반적으로 다음과 같이 처리됩니다.

소스 코드 → 인터프리터 → 결과

누셸은 이 패턴을 따르며, "인터프리터"는 두 부분으로 나뉩니다.

1. 소스 코드 → 파서 → 중간 표현(IR)
2. IR → 평가 엔진 → 결과

먼저 소스 코드가 파서에 의해 분석되고 중간 표현(IR)으로 변환되는데, 누셸의 경우 이는 단지 데이터 구조의 모음입니다. 그런 다음 이러한 데이터 구조는 평가 및 결과 출력을 위해 엔진에 전달됩니다.

이것 역시 인터프리터 언어에서 일반적입니다. 예를 들어 파이썬의 소스 코드는 일반적으로 평가 전에 바이트코드로 변환됩니다.

컴파일 언어

반면에 C, C++, Rust와 같이 일반적으로 "컴파일"되는 언어가 있습니다. 예를 들어, Rust로 작성된 간단한 *"Hello, World!"*입니다.

// main.rs

fn main() {
    println!("Hello, World!");
}

이 코드를 "실행"하려면 다음을 수행해야 합니다.

1. 기계어 명령어로 컴파일
2. 컴파일 결과를 디스크에 바이너리 파일로 저장

처음 두 단계는 rustc main.rs로 처리됩니다.

3. 그런 다음 결과를 생성하려면 바이너리(/.main)를 실행해야 하며, 이는 명령어를 CPU에 전달합니다.

그래서:

1. 소스 코드 ⇒ 컴파일러 ⇒ 기계어
2. 기계어 ⇒ CPU ⇒ 결과

동적 언어 대 정적 언어

Eval 함수

대부분의 동적 인터프리터 언어에는 eval 함수가 있습니다. 예를 들어, Python eval(또한 Python exec) 또는 Bash eval이 있습니다.

eval의 인수는 *"소스 코드 내부의 소스 코드"*이며, 일반적으로 조건부 또는 동적으로 계산됩니다. 즉, 인터프리터 언어가 파싱/평가 중에 소스 코드에서 eval을 만나면 일반적으로 정상적인 평가 프로세스를 중단하고 eval의 소스 코드 인수에 대한 새로운 파싱/평가를 시작합니다.

다음은 이 (잠재적으로 혼란스러운!) 개념을 설명하기 위한 간단한 Python eval 예제입니다.

# hello_eval.py

print("Hello, World!")
eval("print('Hello, Eval!')")

파일(python hello_eval.py)을 실행하면 *"Hello, World!"*와 *"Hello, Eval!"*이라는 두 가지 메시지가 표시됩니다. 다음은 발생하는 일입니다.

1. 전체 프로그램이 파싱됩니다.
2. (3행) print("Hello, World!")가 평가됩니다.
3. (4행) eval("print('Hello, Eval!')")을 평가하기 위해:
   1. print('Hello, Eval!')가 파싱됩니다.
   2. print('Hello, Eval!')가 평가됩니다.

여기서 eval을 사용하면 실행 프로세스에 새로운 "메타" 단계가 추가됩니다. 단일 파싱/평가 대신 eval은 추가적인 "재귀적" 파싱/평가 단계를 만듭니다. 즉, 파이썬 인터프리터가 생성한 바이트코드는 평가 중에 추가로 수정될 수 있습니다.

누셸은 이를 허용하지 않습니다.

위에서 언급했듯이 해석 과정 중에 바이트코드를 수정할 eval 함수가 없으면 인터프리터 언어의 파싱/평가 과정과 C++ 및 Rust와 같은 컴파일 언어의 컴파일/실행 과정 사이에는 (높은 수준에서) 거의 차이가 없습니다.

다음 섹션에서는 이것이 무엇을 의미하는지 더 자세히 살펴보겠습니다.

영향

이 파이썬 예제를 고려하십시오.

exec("def hello(): print('Hello eval!')")
hello()

해석 중:

1. 전체 프로그램이 파싱됩니다.
2. 1행을 평가하기 위해:
   1. def hello(): print('Hello eval!')가 파싱됩니다.
   2. def hello(): print('Hello eval!')가 평가됩니다.
3. (2행) hello()가 평가됩니다.

2.2 단계까지 인터프리터는 hello라는 함수가 존재하는지조차 모릅니다! 이로 인해 동적 언어의 정적 분석이 어려워집니다. 이 예제에서 hello 함수의 존재는 소스 코드를 파싱(컴파일)하는 것만으로는 확인할 수 없습니다. 인터프리터는 코드를 평가(실행)하여 이를 발견해야 합니다.

• 정적, 컴파일 언어에서는 누락된 함수가 컴파일 시간에 잡히는 것이 보장됩니다.
• 그러나 동적, 인터프리터 언어에서는 가능한 런타임 오류가 됩니다. eval로 정의된 함수가 조건부로 호출되는 경우 해당 조건이 프로덕션에서 충족될 때까지 오류가 발견되지 않을 수 있습니다.

누셸 REPL

대부분의 셸과 마찬가지로 누셸에는 파일 없이 nu를 실행할 때 시작되는 "읽기→평가→인쇄 루프"(REPL)가 있습니다. 이것은 종종 *"명령줄"*과 같다고 생각되지만 실제로는 그렇지 않습니다.

> some code...

> print "Hello world!"
# => Hello world!

> ls
# => prints files and directories...

명령줄을 입력한 후 Enter를 누르면 누셸은 다음을 수행합니다.

1. (읽기): 명령줄 입력을 읽습니다.
2. (평가): 명령줄 입력을 구문 분석합니다.
3. (평가): 명령줄 입력을 평가합니다.
4. (평가): 환경(예: 현재 작업 디렉터리)을 내부 누셸 상태에 병합합니다.
5. (인쇄): 결과(비-null인 경우)를 표시합니다.
6. (루프): 다른 입력을 기다립니다.

즉, 각 REPL 호출은 자체적인 별도의 구문 분석-평가 시퀀스입니다. 환경을 누셸의 상태에 다시 병합함으로써 REPL 호출 간의 연속성을 유지합니다.

*"누셸 방식으로 생각하기"*에서 cd 예제의 단순화된 버전을 비교해 보십시오.

cd spam
source-env foo.nu

거기서 우리는 디렉터리가 구문 분석 시간 source-env 키워드가 파일을 읽으려고 시도한 후에 변경되기 때문에 이것이 (스크립트나 다른 단일 표현식으로) 작동할 수 없다는 것을 보았습니다.

그러나 이러한 명령을 별도의 REPL 항목으로 실행하면 작동합니다.

> cd spam
> source-env foo.nu
# 야호, 작동합니다!

이유를 보려면 예제에서 무슨 일이 일어나는지 분석해 보겠습니다.

1. cd spam 명령줄을 읽습니다.
2. cd spam 명령줄을 구문 분석합니다.
3. cd spam 명령줄을 평가합니다.
4. 환경(현재 디렉터리 포함)을 누셸 상태에 병합합니다.
5. source-env foo.nu를 읽고 구문 분석합니다.
6. source-env foo.nu를 평가합니다.
7. 환경(foo.nu의 모든 변경 사항 포함)을 누셸 상태에 병합합니다.

5단계에서 구문 분석 중에 source-env가 foo.nu를 열려고 할 때 3단계의 디렉터리 변경 사항이 4단계에서 누셸 상태에 병합되었기 때문에 그렇게 할 수 있습니다. 결과적으로 다음 구문 분석/평가 주기에서 볼 수 있습니다.

여러 줄 REPL 명령줄

이것은 별도의 명령줄에만 작동한다는 점을 명심하십시오.

누셸에서는 다음을 사용하여 여러 명령을 하나의 명령줄로 그룹화할 수 있습니다.

• 세미콜론:

  cd spam; source-env foo.nu

• 줄 바꿈:

  > cd span
    source-env foo.nu

  두 번째 줄 앞에 "프롬프트"가 없다는 점에 유의하십시오. 이러한 유형의 여러 줄 명령줄은 일반적으로 Alt+Enter 또는 Shift+ Enter를 누를 때 줄 바꿈을 삽입하기 위해 키 바인딩으로 만들어집니다.

이 두 예제는 누셸 REPL에서 정확히 동일하게 작동합니다. 전체 명령줄(두 문 모두)은 단일 읽기→평가→인쇄 루프로 처리됩니다. 따라서 이전 스크립트 예제와 동일한 방식으로 실패합니다.

구문 분석 시간 상수 평가

평가 단계에 구문 분석을 추가하면서도 정적 언어의 이점을 유지하는 것은 불가능하지만, 구문 분석에 약간의 평가를 안전하게 추가할 수 있습니다.

let my_path = "~/nushell-files"
source $"($my_path)/common.nu"

const my_path = "~/nushell-files"
source $"($my_path)/common.nu"

const foo_contents = (open foo.nu)

help commands | where is_const

예를 들어, path join 명령은 상수 값을 출력할 수 있습니다. 누셸은 또한 $nu 상수 레코드에 몇 가지 유용한 경로를 정의합니다. 이를 결합하여 다음과 같은 유용한 구문 분석 시간 상수 평가를 만들 수 있습니다.

const my_startup_modules =  $nu.default-config-dir | path join "my-mods"
use $"($my_startup_modules)/my-utils.nu"