이론적이지 않은 실용적인 프로그래밍 언어에는 예약 키워드가없는 것은 무엇입니까?

나는 예약 된 키워드가없는 실용적인 프로그래밍 언어를 찾고 있었지만 하나를 찾지 못했다.

나는 내 자신의 교육과 오락을위한 프로그래밍 언어를 연구하고 있는데 키워드를 포함시킬 필요가 없었습니다. 그것이 저의 검색과 질문으로 이끌었습니다.

컴파일러 라이터의 편의성이 언어의 최종 사용자에게 중요하다고 생각하지 않습니다. 컴퓨터는 오늘날 문맥에서 의미를 유추 할 수있을만큼 강력합니다. 더 이상 라벨 명사, 동사와에 작가의 요구에 비해 같은 소설을 쓸 때, 왜 프로그래머가 라벨 기능과 변수가 있어야 function x() {}하거나 set x = 1또는 var x = 1등,하지 명령문의 컨텍스트에서 함수 선언 또는 호출이거나 레이블이 값에 대한 지정 또는 해당 레이블 값에 대한 참조임을 유추 할 수 있습니까?

다음은 현재 파서가 수행하는 작업의 구체적인 예입니다. 예약 키워드를 사용하여 일반적으로 잡음 이 func많 function거나 dec그렇지 않은 일반적인 것들을 지원할 필요가 없습니다.

함수 선언

sum3(a,b,c) -> a + b + c.

함수 호출

x = sum3(1,2,3).

x라는 익명 함수

x = (a,b,c) -> a + b + c.
y = x(1,2,3).

성공적인 프로그래밍 언어에 키워드가 중요한 이유를 알고 싶습니다.

MUMPS 는 매우 성공적이며 보험 및 건강 관리에 널리 사용되며 예약어가 없습니다. 더 명확한 코드 작성 측면에서 도움이되지만 꼭 필요한 것은 아닙니다. APL이 또 다른 예입니다. APL은 원자력 산업에서 일회성 스크립트 사용을보고 있습니다. APL 제품군의 구성원 인 J 도 키워드가 없습니다.

키워드는 컴파일러 작성자가 구문 분석을보다 쉽게 ​​구현하는 데 도움이됩니다. APL은 잘 맞습니다. 또한 규칙을 강화하고 가독성을 향상시킵니다. APL은 대부분의 사람들이 읽을 수있는 것으로 알려져 있지 않습니다.

키워드가없는 잘 알려진 언어는 Lisp입니다. 키워드와 가장 가까운 것은 소위 특수 형식이라고하며, 그 숫자는 방언마다 다를 수 있으며 통역사로부터 특별한 대우를받습니다. 그 외에도 그것들은 그것들이 어떻게 사용되는지에 관해서는 정규 함수와 구별 할 수 없지만, 재정의 할 수 없다는 것을 제외하고는 (적어도 내가 알고있는 Lisps에서는).

이로 인해 단순하지만 (paren-heavy) 구문이 생성되며 Lisp가 강력한 매크로 시스템을 가질 수있게 해주는 것 중 하나입니다. 반면에 Lisp는 종종 읽기 어렵다고합니다. APL과 MUMPS는 훨씬 더 그렇습니다. 두 가지 모두 Brainf * ck의 절반이라고 설명했습니다. 키워드는이 부서에서 도움이되며 사람도 쉽게 코드를 읽을 수 있습니다.

따라서 성공적인 언어에 키워드가 필요하다고 말하지는 않지만 언어가 성공적인 언어가되도록 도와줍니다.

TCL 에는 키워드가 없으며 실제로 12 개의 구문 규칙 만 있습니다. 예전만큼 인기가 없었지만 ECAD와 라우터에 기대와 내장이있는 틈새 시장이 있기 때문에 확실히 내 마음에 실용적으로 계산됩니다.

또한 많은 언어가이 경로를 따르지 않는 이유를 보여줄 수 있다고 생각합니다. 그렇습니다. TCL 파서를 작성하는 것은 완벽하게 가능하지만 (다른 많은 언어보다 쉽습니다) 언어에 매우 유용한 BNF 문법을 작성할 수 없으며 많은 사람들이 언어를 배우는 데 어려움을 겪고있는 것 같습니다. 키워드가 없기 때문에 이것이 부분적으로 의심됩니다.

컴퓨터는 오늘날 문맥에서 의미를 유추 할 수있을만큼 강력합니다.

문맥에 맞지 않는 문법을 원하십니까? 행운을 빕니다.

강력함에 대한 질문이 아닙니다. 언어에 대한 영원한 규칙은 변하지 않습니다. 수학적인 것입니다. 이것은 프로그래밍 언어가 문법적으로 쉬워야한다는 사실은 앞으로 수십 년 동안 CFG를 지배하게 할 것입니다.

Btw., Haskell에서 구문과 같은 방식으로

f x y = (x+1)*(y-1)

함수를 정의합니다. 그러나이 경우 "키워드"는 '='입니다. 당신이 그것을 그리워하면 파서에서 끔찍한 일이 일어날 것입니다.

그러나 이것은 내가 당신에게 동의하는 지점입니다. 다른 언어로 기능을 소개하는 모든 def, dcl, fun, fn, function 또는 what-not 키워드보다 훨씬 직관적입니다.

그러나이 문법은 평범한 오래된 LALR (1)로 작성 될 수 있으며, 여기서 "상황에서 추론"되는 의미는 없습니다.

내가 아는 한, Smalltalk는 키워드가 가장 적은 언어입니다 (Brainfuck과 같은 언어를 세지 않는 경우). 스몰 토크 키워드는 true, false, nil, self, super와 thisContext.

키워드가없는 스몰 토크에서 영감을 얻은 언어를 디자인했습니다. 그러나 그것을 사용한 시간이 지나면 나는 주로 구문 설탕에 대한 몇 가지 키워드를 추가하게되었습니다.

키워드가없는 언어는 가능하지만 실용적이지 않기 때문에 인기있는 모든 언어에 키워드가있는 것입니다.

당신은 잘못된 가정하에 노력하고있는 것 같습니다. 키워드는 컴파일러가 일을 쉽게 할 수 있도록합니다. 컴파일러는 일을 더 쉽게 해주지 만 훨씬 더 중요한 이점 이 있습니다 . 코드를 읽는 사람이 일을 더 쉽게 만듭니다 .

예, 많은 컨텍스트를 살펴보고 함수 선언이나 변수 선언을보고 있음을 알 수 있지만 컨텍스트와 관련 코드의 복잡성에 따라 파악하는 데 시간이 오래 걸릴 수 있습니다 . 또는 function 또는 var 와 같은 편리한 키워드가있을 수 있으며 보고있는 내용을 즉시 알 수 있습니다.

예, 코드를 작성 하기가 더 복잡해 지지만 프로그램은 프로덕션보다 유지 관리에 더 많은 시간을 소비하고 코드를 작성, 작성 및 디버깅하는 것보다 코드를 작성하는 것보다 훨씬 많은 시간을 소비하여 언어를 설계하려고합니다. 읽기 쉬운 대신 쓰기가 쉬운 것은 해로운 조기 최적화의 전형적인 사례입니다.

또한 컴파일러 작업을보다 쉽게하는 개념을 무시하지 마십시오. 구문 분석이 쉬울 수록 코드 컴파일 속도가 빨라져 편집 빌드 디버그주기가 빨라져 생산성이 향상됩니다.

크고 복잡한 코드베이스가 있으면 생산성에 큰 차이가 없을 수 있습니다. 예를 들어, 내가 일하는 곳에 약 4 백만 줄의 델파이 프로그램이 있습니다. 약 30 만 줄의 C ++ 인 다른 모듈이 있습니다. 둘 다 컴파일하는 데 동일한 시간이 걸립니다. (약 3 분) 4 백만 줄의 C ++가 있다면 구축하는 데 1 시간이 걸릴 수 있습니다!

몇 가지 드문 예가 있습니다.

APL은 기호 만 사용하지만 많은 기호를 사용합니다! 언어를 사용하려면 특수 키보드가 필요합니다.

참조 이 위키 피 디아 문서를

CORAL 66-키워드가 있지만 작은 따옴표로 인용 한 경우에만 키워드를 인식했습니다.

PL / 1에도 키워드가 있지만 변수 또는 프로 시저 이름으로 사용할 수도 있습니다.

당신의 질문은 "말하는 언어에 왜 단어가 있습니까?"라고 묻는 것과 약간 비슷합니다.

주된 이유는 사람과 컴퓨터가 구문 분석하기가 더 쉽기 때문입니다. 키워드없이 복잡한 언어를 명확하게 표현하려면 구문으로 많은 기호가 필요하며, 이는 혼란스럽고 불필요합니다. function보다 읽기 가 훨씬 쉽습니다 $!{}. 문맥이 모든 모호성을 해결하지는 않습니다.