(एक लंबे उत्तर के लिए माफी के साथ जो साइट के दायरे से अलग एक दिशा में जाता है: स्पष्ट रूप से मैं यहां पहले प्रश्न को देखकर आश्चर्यचकित था ...)
TeX को टाइप करने के लिए डिज़ाइन किया गया था, प्रोग्रामिंग के लिए नहीं; तो यह सबसे अच्छा "अजीब" है जब एक प्रोग्रामिंग भाषा के रूप में माना जाता है।
- डोनाल्ड नुथ, डिजिटल टाइपोग्राफी, पृष्ठ 235
मैंने TeX के शुरुआती इतिहास (लगभग 1977) के बारे में पिछले कुछ वर्षों में बहुत कुछ पढ़ा है, और बहुत कुछ जो नुथ ने लिखा है। मेरा निष्कर्ष यह है कि जिस क्षण हम "TeX (एक प्रोग्रामिंग भाषा के रूप में)" के बारे में बात करते हैं , कुछ पहले से ही गलत है।
यदि हम TeX के लिए पहले लिखे गए "डिज़ाइन दस्तावेज़" देखें (देखें TEXDR.AFTऔर डिजिटल टाइपोग्राफीTEX.ONE में प्रकाशित ), तो यह स्पष्ट है कि नुथ मुख्य रूप से द आर्ट ऑफ़ कंप्यूटर प्रोग्रामिंग टाइप करने के लिए एक सिस्टम डिज़ाइन कर रहा था (उसने कहा है (जैसे यहाँ ) जो मुख्य उपयोगकर्ता उनके मन में थे, वे स्वयं और उनके सचिव थे), इस विचार के साथ कि, उपयुक्त रूप से संशोधित, यह आमतौर पर अधिक उपयोगी हो सकता है। टाइपिंग को बचाने के लिए, एक चीज़ को बार-बार करना पड़ता है (जैसे कि हर बार TAOCP को एक लेखक से एक उद्धरण शामिल करने की आवश्यकता होती है; आप एक निश्चित राशि से लंबवत रूप से बढ़ना चाहते हैं, एक निश्चित रेखा निर्धारित करते हैं, एक निश्चित फ़ॉन्ट चुनते हैं, टाइपसेट। सही-संरेखित करें, दूसरा फ़ॉन्ट चुनें, लेखक का नाम टाइप करें ...), मैक्रोज़ थे।
आप बाकी का अनुमान लगा सकते हैं। टीईएक्स में हमारे पास "दुर्घटनावश ट्यूरिंग-पूर्ण" ( अधिक ) का मामला है , सिवाय इसके कि यह एक समुदाय (कंप्यूटर वैज्ञानिकों और गणितज्ञों के बीच में हुआ था, और डीईके खुद को "दोष" भी है) जो (दुर्भाग्य से) थे इसे अनदेखा करने के लिए बहुत चालाक है। (किंवदंती है कि माइकल स्पिवक ने TeX का सामना करने से पहले कभी भी प्रोग्राम नहीं किया था, लेकिन वह इसके साथ इतना ले गया था कि उसने अस्तित्व में मैक्रोज़ के सबसे जटिल सेटों में से एक में AMS-TeX लिखना समाप्त कर दिया था।) क्योंकि TeX लिखा गया था। बड़ी संख्या में सिस्टम में पोर्टेबल होना (जो उस समय एक बड़ी बात थी), हमेशा TeX में सब कुछ करने का प्रलोभन था। इसके अलावा, अपने संकलक-लेखन के अनुभव के कारण, नुथ ने TeX को एक संकलक की तरह लिखा है, और कभी-कभी इसे एक के रूप में वर्णित किया है, और यदि आपके इनपुट पर काम करने वाला कार्यक्रम एक "संकलक" है, तो निश्चित रूप से आप प्रोग्रामिंग कर रहे हैं, है ना?
आप इस बारे में थोड़ा और पढ़ सकते हैं कि नथ ने टीएक्सएक्स में किए जाने वाले किसी भी प्रोग्रामिंग के लिए कैसे इरादा नहीं किया था, और उसने "टीएक्स के कई प्रोग्रामिंग सुविधाओं में केवल किक करने और चिल्लाने के बाद" कैसे डाला, इस जवाब में । जो भी उसके इरादे थे, जैसा कि मैंने कहा, लोगों ने प्रोग्रामिंग के आश्चर्यजनक करतबों को पूरा करने के लिए TeX मैक्रो सिस्टम का उपयोग (ab) करने के तरीकों का पता लगाना शुरू कर दिया। नुथ ने यह आकर्षक पाया और (TeX में कुछ सुविधाओं को जोड़ने के अलावा) इनमें से कुछ को द टेक्सबुक के परिशिष्ट डी "डर्टी ट्रिक्स" में शामिल किया, लेकिन यह नाम के बावजूद, पता चलता है कि "दस में से नौ उदाहरण हैं" LaTeX के कार्यान्वयन में उपयोग किया जाता है ”।
मुझे इसे एक और तरीका देना चाहिए: LaTeX, एक मैक्रो सिस्टम, जिसे लेस्ली लामपोर्ट ने TeX के शीर्ष पर लिखा था, एक विचार के रूप में , एक शानदार है। सेन्चुरी, संरचित, मानव-उन्मुख तरीके से दस्तावेजों को संकलित करना (नथ) TeX के पृष्ठ-उन्मुख तरीके के बजाय (या जैसा कि लामपोर्ट इसे कहते हैं, दृश्य के बजाय तार्किक ) एक महान है। लेकिन "उचित" प्रोग्रामिंग भाषा के बजाय TeX मैक्रोज़ का उपयोग करते हुए LaTeX के रूप में जटिल कुछ को लागू करना, मेरे विचार में और कम से कम अगर यह आज किया गया था, तो कहीं न कहीं एक विशाल गलती और प्रचंड विकृतता के एक अधिनियम के बीच। नूथ भी हैरान है कि लोग TeX मैक्रोज़ में सब कुछ करने के बजाय सिर्फ TeX प्रोग्राम का विस्तार नहीं करते हैं।
आज "प्रोग्रामिंग" करने के बहुत बेहतर तरीके हैं; आप अधिकांश लोगों के कंप्यूटरों पर व्यापक रूप से उपलब्ध कई भाषाओं में से किसी एक में बाहरी प्रोग्राम का उपयोग कर सकते हैं, या आप LuaTeX और Lua में प्रोग्राम का उपयोग कर सकते हैं (और अकेले TeX मैक्रोज़ के साथ आप जितना बेहतर काम कर सकते हैं, क्योंकि आप आंतरिक संरचनाओं में हेरफेर कर सकते हैं। सही स्तर पर एल्गोरिदम)। और यदि आप इसे सही करते हैं, तो आपके पास ऐसे कार्यक्रम हो सकते हैं जो TeX मैक्रोज़ में लागू किए गए लोगों की तुलना में बेहतर या तेज़ काम करते हैं।
TeX में प्रोग्राम बनाने का काम इस प्रकाश में देखे जाने पर तेज़ गति से हो रहा है, और पेपर के अंतिम शब्दों की याद दिलाता है, जिसमें एक और "गलती से ट्यूरिंग पूर्ण" प्रोग्रामिंग "भाषा" का वर्णन किया गया है: टॉम वाइल्डनहाइन की प्यारी " ऑन ट्यूरिंग कम्प्लीटनेस ऑफ़ एमएस पावरपॉइंट ( वीडियो ) पिछले साल से:
जबकि PPTXTM PowerPoint विकास की सैद्धांतिक संभावना को साबित करता है, […]। PowerPoint अनुप्रयोग अनुकूलन में भी काम करने की आवश्यकता है। अगली स्लाइड में पावरपॉइंट की ऑटोमैटिक बफरिंग का फायदा उठाने के लिए यहाँ बहुत सारी संभावनाएँ हैं, जो सावधानीपूर्वक स्लाइड प्लेसमेंट के माध्यम से एप्लिकेशन के प्रदर्शन को बढ़ाने के लिए उपयोग की जा सकती हैं।
लिप्टन जिस किस्से का वर्णन करते हैं , वह दृष्टव्य है। इतना ही नहीं TeX का कोई औपचारिक शब्दार्थ मौजूद नहीं है, वहाँ भी एक होने की संभावना नहीं है। यह उसके लिए बस "अजीब" एक "भाषा" है, और (जैसा कि मुझे आशा है कि मैंने ऊपर समझाया है) यह एक भाषा के रूप में भी इरादा नहीं है। उदाहरण के लिए, आप सोच सकते हैं कि आप मैक्रोज़ को फ़ंक्शंस के रूप में लिख रहे हैं, लेकिन इसमें एक एकल आवारा चरित्र (यहां तक कि एक स्थान ) का परिचय दें, और TeX इसे तुरंत एक टाइपिंग निर्देश के रूप में मानता है।
संक्षेप में: TeX सबसे शुरुआती अवसर पर टाइपसेटिंग करने का सम्मान करता है, और जब यह मैक्रोज़ का विस्तार करता है तो यह बहुत ही गंभीर रूप से करता है (टाइप करने के अपने "वास्तविक" काम करने के लिए अधीर), और ये विस्तार स्वयं सैकड़ों प्रकार के "राज्य" पर निर्भर कर सकते हैं टीईएक्स कार्यक्रम (जैसे मापदंडों का मान \hsizeया \baselineskip, बक्से और अन्य रजिस्टरों की सामग्री ...), यही कारण है कि टीएक्स के किसी भी औपचारिक शब्दार्थ को आवश्यक रूप से कुछ होना चाहिए जो कार्यक्रम की संपूर्ण स्थिति और इसकी सभी मेमोरी को ध्यान में रखता है, जब तक कि हम नहीं। TeX प्रोग्राम से अधिक जटिल रूप में "TeX कोड का अर्थ जो कुछ भी TeX करता है" जैसे कुछ के साथ समाप्त होता है।
तो ठीक है, (यदि मैंने आपको आश्वस्त किया है) TeX एक प्रोग्रामिंग भाषा के रूप में नहीं था और वास्तविक लोगों की तरह काम नहीं करता है, तो कोई औपचारिक शब्दार्थ नहीं है, और आज प्रोग्राम करने के बेहतर तरीके हैं - लेकिन यह सब आपके साथ मदद नहीं करता है वास्तविक प्रश्न / समस्या, जो यह है कि व्यवहार में, TeX द्वारा प्रसंस्करण के लिए किए गए कई दस्तावेज़ जटिल मैक्रोज़ (जैसे LaTeX और TikZ) का उपयोग करते हैं, एक दूसरे के शीर्ष पर निर्मित राक्षसी जटिलता के तेजस्वी संस्करण होते हैं। हम इसे कैसे तेज बना सकते हैं और "अनुकूलन पास" विकसित कर सकते हैं?
आप औपचारिक शब्दार्थ आईएमओ के साथ वहां नहीं पहुंचेंगे। मैंने हाल ही में इस बारे में सोचा है, और निम्नलिखित कुछ प्रारंभिक विचार हैं।
मेरी धारणा है कि नूथ 1960 के दशक में अनुभवी संकलक-लेखकों में से एक था (इसीलिए उसे कंपाइलर बुक लिखने के लिए कहा गया जो द आर्ट ऑफ़ कंप्यूटर प्रोग्रामिंग में बदल गया ), और टीएक्स (कई मायनों में) में कंपाइलर्स के लिखने का तरीका था 1970 के दशक में लिखा गया था। तब से कंपाइलर तकनीक और डिज़ाइन में सुधार हुआ है, और ऐसा ही TeX प्रोग्राम हो सकता है। यहां कुछ चीजें दी गई हैं, जो चीजों को गति देने के द्वारा की जा सकती हैं:
दिल में, TeX को एक "व्याख्यात्मक दिनचर्या" की तरह लिखा जाता है, जहाँ TeX "आँखें" और "मुंह" (इसकी इनपुट दिनचर्या) अपने "पेट" (इसके अर्थ रूटीन) को एक-एक करके निष्पादित करने के निर्देश देता है। (आप TeX कार्यक्रम के भाग 15 में एक सूची देख सकते हैं ।) उदाहरण के लिए, जब TeX की आंखें / मुंह मुठभेड़ \hfillया \hskipउसके इनपुट में, पेट को एक "hskip" कमांड मिलती है, जो उस पर कार्य करता है। यह आज बायटेकोड दुभाषियों के रूप में कहा जाता है, और इन बाइटेकोड्स / ओपकोडों को स्पष्ट रूप से बाहर निकालने के लिए TeX कार्यक्रम को फिर से शुरू करने में मूल्य हो सकता है, ताकि हम मौजूदा (अधिक पारंपरिक आज) कंपार्टमेंट तकनीकों का उपयोग करने में सक्षम हो सकें। या कम से कम उन्हें कैश करने के लिए फिर से काम करने से बचें। बेशक कई चुनौतियां हैं:
"पेट" में एक कमांड के निष्पादन में आम तौर पर इनपुट को पढ़ना शामिल होता है, अर्थात इनपुट रूटीन और सिमेंटिक रूटीन का काम अलग-अलग चरणों में नहीं होता है। उदाहरण के लिए, "hskip" कमांड, यदि दिया गया \hskip(कहने के बजाय \hfill) scan_glueइनपुट से एक गोंद विनिर्देशन पढ़ने के लिए आमंत्रित करेगा , जिसमें बदले में मैक्रोज़ का विस्तार शामिल हो सकता है और इसी तरह जब तक गोंद के लिए पर्याप्त टोकन नहीं मिल जाते, तब तक इनपुट स्टैक को छोड़ दें। काफी हद तक अलग राज्य।
ETeX और pdfTeX और XeTeX और LuaTeX जैसे इंजन नए कमांड और प्राइमेटिव्स पेश करते हैं (eTeX / pdfTex प्राइमेटिक्स व्यावहारिक रूप से व्यवहार में सभी द्वारा उपयोग किए जाते हैं); आपको उन्हें मूल नथ के TeX कार्यक्रम में ही नहीं, उनका भी समर्थन करने की आवश्यकता होगी।
हम "सट्टा निष्पादन", भविष्य के पैराग्राफ (शायद नए वर्गों या अध्यायों की तरह प्राकृतिक चौकियों पर शुरू) (समानांतर में कई कोर का उपयोग करके), सभी TeX आंतरिक स्थिति का उपयोग करते हुए (उन पर निर्भर) का ट्रैक रखते हुए, और फेंकने जैसा कुछ कर सकते हैं। उस काम को दूर (और इसे फिर से करना) अगर बाद में हमें पता चलता है कि पहले वाला पैराग्राफ उस राज्य में से कुछ को बदलकर समाप्त हो जाता है। फिलहाल TeX पूरी तरह से क्रमिक रूप से 1 प्रोसेसर पर चलता है; विशिष्ट हार्डवेयर एक अलग दिशा में चला गया है और कई कोर उपलब्ध हैं।
और भी सरल, हम काम को कैश कर सकते हैं (क्या TeX राज्य एक्सेस किया गया था और संशोधित किया गया था) इनपुट फ़ाइल के एक निश्चित अनुभाग द्वारा। (हम इनपुट के स्तर पर यह कैशिंग कर सकते हैं - सभी मैक्रोज़ का विस्तार करने का शुद्ध परिणाम- या बक्से के किस स्तर पर इकट्ठे किए गए थे, या कार्यक्रम के कुल राज्य में सभी तरह से।) उदाहरण के लिए सामग्री। a \begin{tikzpicture} … \end{tikzpicture}, पृष्ठ संख्या काउंटर की तरह TeX राज्य पर बहुत अधिक निर्भर होने की संभावना नहीं है, इसलिए जब हम TeX दस्तावेज़ को फिर से जोड़ते हैं तो हम सभी कामों का पुन: उपयोग कर सकते हैं - अगर हमने यह जानने के लिए पर्याप्त जानकारी का ट्रैक रखा है कि ऐसा करना सुरक्षित है। (बेशक TikZ में विशेष रूप से इसे बाहरी बनाने और परिणाम शामिल करने के तरीके हैं, लेकिन विचार अधिक सामान्य है।)
हम तकनीक का उपयोग कर सकते हैं (जैसे कार्यात्मक प्रोग्रामिंग में उपयोग किए जाने वाले) "छेद" के साथ कुछ TeX प्रसंस्करण करने के लिए - जैसे अभी, जब आप \ref{foo}LaTeX में लिखते हैं कि (भविष्य कहते हैं) अनुभाग संख्या, यह केवल दो संकलन पास में काम करता है: पहले पूरे दस्तावेज संसाधित किया जाता है (सभी अनुच्छेदों टाइपसेट,, पृष्ठों पर स्थान दिया झांकियां आदि) के साथ खंड संख्या एक दूसरे पास पर एक सहायक फाइल करने के लिए बाहर लिखा जा रहा है, तो सभीइस बार वास्तव में उपलब्ध अनुभाग संख्या के साथ काम फिर से किया जाता है। (इस तरह की हैक समय पर अपरिहार्य हो सकती है, और मुझे पता है कि चल रहे समय पर प्रभाव "केवल एक स्थिर कारक" है, लेकिन ...) इसके बजाय, क्या होगा यदि हम दस्तावेज़ को "छेद" के साथ संसाधित कर सकते हैं ( अनिर्धारित सामग्रियों वाला एक बॉक्स लेकिन कुछ अनुमानित चौड़ाई) अनुभाग संख्या के लिए छोड़ दिया गया, फिर दस्तावेज़ प्रसंस्करण के अंत में बॉक्स को आबाद करें? (हां, हमारी अनुमानित चौड़ाई गलत हो सकती है और पैराग्राफ को पुनर्संसाधन की आवश्यकता हो सकती है और परिणामस्वरूप पृष्ठ भी, लेकिन हम या तो काम कर सकते हैं यदि आवश्यक हो, या गति के लिए, एक मोड जिसमें हम एक गलत चौड़ाई की अनुमति देंगे अनुभाग संख्या।)
इसी तरह की तकनीकें TeX दस्तावेज़ के संवादात्मक संपादन के लिए काम कर सकती हैं: जब आप एक पैराग्राफ को संपादित करते हैं तो इसे "लाइव" संसाधित किया जा सकता है, भविष्य के पैराग्राफों के साथ बस गैली (कहते हैं) नीचे चली गई। हम जानते हैं कि यह संभव है, क्योंकि पहले से मौजूद (वाणिज्यिक) TeX कार्यान्वयन जो ऐसा करते हैं, जैसे BaKoMaTeX और टेक्सपैड और पूर्व बनावट । ( BaKoMa-TeX के होम पेज पर वीडियो देखें और इसी तरह TeXpad का, उदाहरण के लिए इस वीडियो - मैंने बाद की कोशिश की और यह अभ्यास में असहनीय छोटी गाड़ी थी।)
कम नहीं आंका जाना: उपयोगकर्ता को चीजों को दिखाने का मूल्य, TeX को अधिक डिबग करने योग्य बनाना। अभी, उपयोगकर्ता केवल अपने TeX इनपुट को देखते हैं और पता नहीं है कि वास्तव में TeX क्या काम कर रहा है, उदाहरण के लिए, अनुच्छेदों के लिए लाइन-ब्रेकिंग पर कितना समय व्यतीत कर रहा है, या मैक्रो-एक्सपेंशन (और मैक्रोज़) में, यह किस बॉक्स को असेंबल कर रहा है और फेंकना, किस पैकेज के द्वारा विशेष लिखा जा रहा है, आदि। मैं (शायद आशावादी) यह मानता हूं कि ऐसे उपयोगकर्ता मौजूद हैं जो इस जानकारी को देखना चाहेंगे और यह उपयोगी होगा जैसे कि यह जानने के लिए कि क्या अजीब पैकेज वे छायांकन के लिए उपयोग कर रहे हैं पृष्ठभूमि में एक ढाल के साथ समीकरण सस्ते हैं (प्रसंस्करण समय में थोड़ा जोड़कर) या नहीं। यह देखकर कि जहां बहुत सारे बेकार काम हो रहे हैं, वे इसे कुछ दूर फेंक सकते हैं (कम से कम उनके अंतिम प्रिंट तक)। (यह कुछ हद तक कंपाइलर या प्रोग्राम में प्रोफाइलिंग जानकारी डालने वाले अन्य टूल की तरह है।) उदाहरण के लिए, TeX को अधिक पारदर्शी और डिबगेबल बनाना एक बहुत बड़ा प्रयोज्य सुधार हो सकता है। (TeX पहले से ही अपने समय के IMO के लिए काफी उपयोगकर्ता के अनुकूल और डीबग करने योग्य है, यदि हम ज्यादातर सादे TeX का उपयोग बहुत कम मैक्रोज़ के साथ करते हैं, लेकिन LaTeX के साथ नहीं है या उपयोगकर्ताओं के थोक आज इसका सामना कैसे करते हैं।)
इसके अलावा, किसी भी भविष्य के काम को संभवतः LuaTeX पर ध्यान देना चाहिए (निर्माण पर) जो कि वर्तमान में हमारे पास TeX का सबसे अच्छा संशोधन है।
ये सभी केवल बेकार विचार हैं (मैंने उनमें से किसी को भी लागू नहीं किया है, यह जानने के लिए आवश्यक प्रयास या हमें कितना गति प्राप्त होगी), लेकिन मुझे आशा है कि यह आपके प्रश्न का उत्तर देने या भविष्य के निर्देशों के लिए आपको विचार देने के लिए कुछ रास्ता देता है। ।