हास्केल - डिज़ाइन

वे कहते हैं कि अपने जीवन में प्रत्येक प्रोग्रामर को कम से कम एक कंपाइलर लिखना चाहिए या किसी प्रोग्रामिंग भाषा के साथ आना चाहिए। एक नई भाषा को डिजाइन करना आसान काम नहीं है, क्योंकि आपको दर्जनों मापदंडों के माध्यम से सोचने की जरूरत है, जैसे कि लेगो क्यूब्स को एक साथ अच्छी तरह से काम करना चाहिए। एक असफल निर्णय भाषा के भाग्य को पार कर सकता है जब यह प्रकाशित भी नहीं हुआ है। सैकड़ों भाषाएं गुमनामी में वनस्पति करती हैं, बड़े भाइयों द्वारा कैटवॉक से धक्का दिया जाता है, लेकिन सबसे अच्छा उपयोग के योग्य तप के साथ दुनिया सालाना दो या तीन नए जन्म देती है। चाहे वे कम से कम एक "वैकल्पिक विश्व साक्षात्कारों के समूह" में आते हैं या यहां तक ​​कि मुख्यधारा बन जाते हैं, समय बताएगा। सौभाग्य से, मेरी भाषा को इसकी आवश्यकता नहीं है, क्योंकि आप इसे प्रोग्राम नहीं कर सकते, आप केवल इसकी प्रशंसा कर सकते हैं। इसके लिए हास्केल-कोड विज़ुअलाइज़ेशन भाषा है, जिसके डिज़ाइन पर लेख में चर्चा की जाएगी।





हास्केल एक अद्भुत भाषा है। वह बहुत ही एक्सप्रेसिव और कैपेसिटिव हैं। कोड अनिवार्य भाषा (C ++, Java, C #) में कोड की तुलना में अधिक कॉम्पैक्ट परिमाण का एक आदेश है, इस तथ्य के बावजूद कि इसमें कम वाक्य रचना है। हास्केल की शुद्ध कार्यात्मक प्रकृति और इसकी डिज़ाइन एक गणित संकेतन की तरह कोड बनाती है। उदाहरण के लिए सांकेतिक (लेकिन सबसे अच्छा नहीं) संस्करण का उदाहरण लें:

तथ्य एन | n == 0 = 1
| n > 0 = n * fact ( n - 1 )

इन दो पंक्तियों में, स्कूल से परिचित आवर्तक तथ्यात्मक सूत्र को अच्छी तरह से जाना जाता है:



बेशक, एक फैक्टरियल को पुनरावर्ती रूप से परिभाषित करना किसी भी अन्य भाषा में बहुत बुरा नहीं होगा, जो संदेह पैदा कर सकता है कि क्या हास्केल इतना स्पष्ट है।

इंट फैक्ट ( int n )
{
if ( n == 0 ) वापसी 1 ;
वापसी n * fact ( n - 1 ) ;
}

चाल यह है कि दोनों फ़ंक्शन एक कार्यात्मक शैली में लिखे गए हैं, इसलिए उनके बीच बहुत अंतर नहीं है। हालांकि, स्टैक को पछतावा होने पर, हम एक लूप का उपयोग एक अनिवार्य भाषा में कर सकते हैं, जो पूरी तरह से अलग दिखता है:

इंट फैक्ट ( int n )
{
int f = 1 ;
for ( int i = 2 ; मैं <= n ; ++ i )
f * = i ;
वापसी च ;
}

प्रोग्रामर अच्छी तरह से जानते हैं कि पिछले दो उदाहरणों का फ़्लोचार्ट का उपयोग करके कल्पना की जा सकती है:



दूसरी योजना, सिद्धांत रूप में, वर्णन करती है कि हास्केल पुनरावर्ती कोड में क्या होता है। और हालांकि फ़्लोचार्ट्स विज़ुअलाइज़ेशन हैं, फिर भी वे जो चाहते हैं उससे अलग हैं: वे दिखाते हैं कि क्या हो रहा है और यह नहीं कि यह कैसा दिखता है । मैं कोड को तीन-आयामी दृश्य में स्थानांतरित करना चाहता हूं, ताकि दृश्य सुंदर, सहज और यथासंभव असामान्य हो। विज़ुअलाइज़ेशन का अर्थ यह है।

भाषा डिजाइन करते समय, आपको यह सोचना होगा कि इसे बाद में कैसे विस्तारित किया जाए। यदि आप इसे गलत या असुविधाजनक करते हैं, तो पिछड़े संगतता को नष्ट किए बिना नए उपक्रमों के लिए कोई जगह नहीं होगी। ऐसे उदाहरणों से कहानियाँ जानी जाती हैं; इस कटोरे ने कुछ बहुत लोकप्रिय भाषाओं को पारित नहीं किया है (उदाहरण के लिए, पायथन 3.0, जो पहले के संस्करणों के साथ संगत नहीं है)। बहुत हद तक, बहुत छोटी चीजें डिजाइन की संवेदनशीलता को प्रभावित करती हैं, इसलिए बोलने के लिए, छोटे में वाक्य रचना। सफल विवरण के साथ, पूरी भाषा एक बड़े और अच्छी तरह से डिजाइन किए गए निर्माता के रूप में बनाई गई है। हास्केल इनमें से एक है, जिसका अर्थ है कि विज़ुअलाइज़ेशन भाषा को भी निशान रखना चाहिए। और यहां मैं इस तथ्य पर भी छूट नहीं दे सकता कि हास्केल डिजाइन ज्ञात है - मुझे अभी भी इन कठिनाइयों को शुरू से ही दूर करना होगा। हालांकि एक मायने में, यह मेरे लिए आसान है।

तो, आपको ग्राफिक भाषा के डिजाइन पर विचार करने की आवश्यकता है, काफी स्वतंत्र, लेकिन एक ही समय में दृश्य और सौंदर्य के लिए उपयोगी। आपको व्यक्तिगत सिंटैक्टिक इकाइयों के बारे में सोचने की ज़रूरत है, एक ही समय में उच्च स्तर पर - उनके कनेक्शन और सामान्य रूपरेखा में उनके महत्व को देखते हुए। उस तथ्य के आधार पर, मैं किसी दिन हास्केल कोड के लिए भी स्केच बनाने की योजना बना रहा हूं:

- | निर्दिष्ट बॉक्स साइड ड्राइंग के लिए कार्रवाई एकत्र करता है।
- | इसका उपयोग केवल इस मॉड्यूल में किया जाना चाहिए।
f :: ReadyTextureObjects
-> GLfVertex3
-> ( BoxSide , QuadColorSpec )
-> ( [ BoxSide ] , [ IO ( ) ] )
-> ( [ BoxSide ] , [ IO ( ) ] )
f टेक्सस बॉक्सडिम ( साइड , qColorSpec ) ( sList , ioList ) = let
BoxIO = do setQuadColorSpec texRes qColorSpec
जीएल। प्रस्तुत करना GL । क्वाड्स ( बॉक्ससाइड बॉक्सडिम साइड )
में ( पक्ष: sList , boxIO: ioList )

या इसके लिए:

डेटा QuadColorSpec = QuadTexture TextureName
| QuadPlainColor GLfColor4
| NoQuadColorSpec
व्युत्पन्न ( दिखाना )

data ObjectTextureSpec = BoxTextureSpec
{ quadSideTexes :: [ ( BoxSide , QuadColorSpec ) ]
, defQuadSideTex :: QuadColorSpec
} व्युत्पन्न ( दिखाएँ )

data CornerCoord = UR | डीआर | डीएल | यूएल
व्युत्पन्न ( दिखाना )

इस बीच, मेरे पास फैक्टरियल कोड है, और विज़ुअलाइज़ेशन भाषा इसके साथ शुरू हुई:

तथ्य एन | n == 0 = 1
| n / = 0 = fact ( n - 1 ) * n

यहाँ हम कई वाक्यात्मक निर्माण देखते हैं:

समारोह का नाम		तथ्य
तर्क		n
2 सुरक्षा भाव		| एन == 0
		| एन / = 0
2 शरीर के कार्य		= 1
		= fact (n - 1) * n

बदले में, फ़ंक्शन के प्रत्येक शरीर को एक पेड़ की तरह कम्प्यूटेशनल अभिव्यक्ति में विभाजित किया गया है। दूसरा मामला लीजिए। इस पेड़ के तत्वों को बक्से के रूप में प्रस्तुत करते हुए, हमें पहला मोटा विकल्प मिलता है:



और तुरंत खामियां सामने आती हैं। आप कल्पना कर सकते हैं कि यदि आप फ़ंक्शन बॉडी में कुछ और क्रियाओं और अभिव्यक्तियों को जोड़ते हैं तो कोड विज़ुअलाइज़ेशन कैसे बढ़ेगा। हाँ वहाँ! अभिव्यक्तियाँ खुद में अभिव्यक्तियाँ शामिल कर सकती हैं, और बस प्रत्येक तत्व को एक बॉक्स के साथ सहसंबंधित करने से हमें केवल बॉक्स की एक लंबी और unintuitive श्रृंखला प्राप्त होगी। "माथे" समाधान यहाँ फिट नहीं है। एक उपयोगी तथ्य को याद करें: पिरामिड पेड़ की संरचना का स्पष्ट अवतार है। एक कम्प्यूटेशनल अभिव्यक्ति को इस रूप में भी दर्शाया जा सकता है, यहां तक ​​कि कई मायनों में:






अंतिम तस्वीर विशेषता पिरामिडल प्रोट्रूशियंस के कारण विषयगत रूप से पूर्ववर्ती है। इस फॉर्म पर निवास करना संभव होगा, लेकिन बाइनरी फ़ंक्शन की ख़ासियत यह है कि वे ऑपरेटर हो सकते हैं। ऑपरेटरों और कार्यों के बीच का अंतर विशुद्ध रूप से सहज है, लेकिन भाषा के दृष्टिकोण से यह एक और एक ही बात है, यह बस कार्यात्मक और infix प्रविष्टियों में अलग तरह से लिखा गया है:

isListElement x xs = ग्यारह x xs - कार्यात्मक रूप
isListElement 'x xs = x ` elem` xs - infix form

डिफ़ॉल्ट ऑपरेटरों का उपयोग infix संकेतन में किया जाता है, लेकिन कार्यात्मक भी स्वीकार्य है:

a b = a + b जोड़ें
add 'a b = ( + ) a

और इस तथ्य को विज़ुअलाइज़ेशन के दौरान आसानी से प्रदर्शित किया जा सकता है। निम्नलिखित स्केच में, इन्फिक्स फॉर्म को हाइलाइट करने के अलावा, मैंने अंतिम सिंटैक्टिक इकाइयों (चर और स्थिरांक) को दोगुना कर दिया है:



पिरामिड की ऊंचाई कम हो गई, जो अच्छा है, और यह स्पष्ट हो गया कि इन्फिक्स प्रविष्टि कहां है और कार्यात्मक कहां है। लगातार गणना को परिभाषित करते समय यह दृष्टिकोण उपयोगी हो जाता है:

add3 a b c = a + b + c
someF x y z = x >> = y >> z

और बड़ी संख्या में तर्कों के साथ कार्यों के लिए, यह बक्से के बीच की खाई को संरक्षित करने के लायक है।

रेखाचित्र दिखाते हैं कि बक्से की लंबाई बॉक्स पर नाम पर और तर्कों के कब्जे वाली जगह पर निर्भर करती है। कुछ भी नहीं किया जाना चाहिए: शिलालेख की आवश्यकता है, और यह आकार में इसे कम करने के लायक नहीं है, अन्यथा हम एकरूपता खो देंगे। वेब पेज या किसी डॉक्यूमेंट में फोंट को कस्टमाइज़ करना संभव है, और कोड को सख्ती से देखना चाहिए, क्योंकि इसे पढ़ना इतना आसान है। इसलिए, जटिल, बड़े पैमाने पर कम्प्यूटेशनल अभिव्यक्तियां भी प्रभावशाली दिखेंगी। आइए फिबोनाची संख्या के लिए फ़ंक्शन देखें:

तंतुओं = 0 : 1 : zipWith ( + ) तंतुओं ( पूंछ तंतु )

अभिव्यक्ति (और यह भी काम करता है!) बहुत सुंदर दिखता है। आइए इसके लिए एक स्केच बनाने की कोशिश करते हैं, यह याद करते हुए कि दो बार इस्तेमाल होने वाले बृहदान्त्र का चिह्न infix रूप में लिखा गया है, और zipWith एक फ़ंक्शन है जो तीन तर्क लेता है: (+), फ़ाइब और (टेल फ़ाइब)। यहां समस्या कोष्ठक में एक प्लस के साथ दिखाई देती है। यह संकेत एक तर्क के रूप में दूसरे फ़ंक्शन को दिया जाता है, और हास्केल के लिए यह एक सामान्य और बहुत उपयोगी घटना है, जिसे "उच्चतर कार्य समारोह" के रूप में जाना जाता है। इसके अतिरिक्त, ऑपरेटर + ने अपने स्वयं के दोनों तर्कों को काट दिया है, और इसे पहले से ही एक अनुभाग कहा जाता है। हमारे पिछले नियमों के अनुसार, + ऑपरेटर एक बढ़े हुए बॉक्स के साथ अंतिम तर्क होना चाहिए। मूल रूप से, यह सामान्य है:



लेकिन भविष्य को देखते हुए, हम इस बात पर विचार कर सकते हैं कि आम तौर पर सेक्शन और क्युरेटेड फंक्शन कैसे दिखेंगे। उदाहरण के लिए थोड़ा कृत्रिम कोड लें:

ops = [ ( + ) , ( * ) , ( - ) ]

func x y op = x `op` y

परिणाम = नक्शा ( फंक 2 3 ) ऑप्स

तीन कार्य हैं: ऑप्स ऑपरेटरों की एक सूची लौटाते हैं, फंक - तर्क एक्स और वाई पर ऑप के रूप में पारित कार्रवाई करते हैं, और परिणाम के अंदर इसका उपयोग किया जाता है और कुछ की गणना की जाती है। ईमानदार होने के लिए, परिणाम निष्पादित करते समय, यह निम्नलिखित सूची लौटाता है: [5, 6, -1], और यह पता लगाना आसान है कि यह कैसे निकला है। मानचित्र फ़ंक्शन (func 2 3) ऑप्स सूची से सभी ऑपरेटरों के लिए लागू किया गया था। हम इस मामले में रुचि रखते हैं कि (func 2 3) एक तर्क युक्त एक रिकॉर्ड है जो खाली रहता है। कोष्ठक में ऑपरेटरों को भी घुंघराले (या बल्कि काट दिया जाता है), सब कुछ पहले ही हमसे चुरा लिया गया है ... अर्थात, दो तर्क चुने गए थे। यह हास्केल कोड और इस तरह एक अजीब प्रविष्टि में परिलक्षित नहीं होता है:

nullMap = map null

जब तक आपको पता न चले कि मानचित्र और अशक्त कार्य क्या है, और यदि प्रकार के हस्ताक्षर निर्दिष्ट नहीं हैं, तो यह हमें कुछ भी नहीं बता सकता है। हालाँकि, विज़ुअलाइज़ेशन में, हम स्पष्ट रूप से दिखा सकते हैं कि इन कार्यों के लिए कुछ अन्य तर्कों की आवश्यकता है। यह तर्क देने के लिए पर्याप्त है कि तर्क कार्यों के खांचे में फिट होते हैं, और खांचे की संख्या arity से मेल खाती है। यहाँ परिणाम और nullMap कार्यों के लिए परिणाम है:




कम्प्यूटेशनल अभिव्यक्तियों के डिजाइन में, अनुपात का सवाल अभी भी एक आवश्यक है, और यहां पर कल्पना की कुल पुनरावृत्ति संभव है। तत्वों की ऊंचाई, तर्कों के बीच की दूरी, खाली खांचे की लंबाई और गहराई, परिमित तत्वों की ऊंचाई और लंबाई, पिरामिड इंडेंटेशन का आकार खुद को पैरामीटर के लिए उधार देता है। यदि आप अपने आप को सद्भाव के ज्ञान के साथ जोड़ते हैं, तो आपको संभवतः अनुपात में जादू का सुनहरा अनुपात जोड़ना चाहिए। यह सब कुछ बेहतर करता है!

किसी भी भाषा का एक महत्वपूर्ण निर्माण सशर्त संक्रमण है। हास्केल का भी एक बयान है, और यह ऐसा है कि अन्य विवरण के साथ होना चाहिए। ऐसी कोई अभिव्यक्ति नहीं हो सकती है जिसमें कोई एक विकल्प गायब हो - एक ऐसी दुनिया में जहां हर चीज का एक फ़ंक्शन होता है, परिणाम हमेशा वापस होना चाहिए। नीचे (यदि हम पिछली बार की तरह, इस तथ्य के बारे में नहीं सोचते हैं कि n नकारात्मक आ सकता है)

fact n = if n == 0 तो 1 और तथ्य ( n - 1 ) * n

आप यहां किसी भी तरह से कोड को फॉर्मेट कर सकते हैं। तब और अन्य इंडेंटेशन के लिए संवेदनशील नहीं हैं और एक नई लाइन पर स्थित हो सकते हैं (केवल तथ्य समारोह से कम से कम एक सफेद स्थान की गिनती करके):

fact n = अगर n == 0
फिर 1
और तथ्य ( n - 1 ) * n

शायद ये क्रमपरिवर्तन किसी भी तरह इस डिजाइन के डिजाइन के साथ आने में मदद करते हैं। शब्दों का भोली हस्तांतरण अगर, फिर और पिरामिड की सबसे निचली परतों के रूप में पिछले संस्करण के साथ ओवरलैप करता है और भ्रमित कर रहा है। लेकिन अगर आप उन्हें कुछ अलग-थलग तत्व से अलग करते हैं, तो यह अधिक दिलचस्प हो जाएगा। निम्नलिखित दो विकल्पों की तुलना करें:




कल्पना करने के लिए वेंट देकर, व्यक्ति बाद के विकल्प के कुछ अंतर को प्राप्त कर सकता है। आखिर है तो क्या? यह तब है जब एक बूलियन अभिव्यक्ति को सत्य के लिए जांचा जाता है, अर्थात ट्रू के साथ मैच के लिए। संयोग के सिद्धांत पर, रचनाकार, पहेली और कुछ और निर्मित होते हैं: एक संयोग है, - पिन नाली को फिट बैठता है; कोई संयोग नहीं है - ठीक है, मुझे क्षमा करें ... आइए इस अवधारणा को स्केच में जोड़ने का प्रयास करें:




यह दिलचस्प लग रहा है और आपको आगे कल्पना करता है। आप स्थिति, आकार, आकार के साथ प्रयोग कर सकते हैं, लेकिन आपको यह नहीं भूलना चाहिए कि अगर-तब-तब एक अभिव्यक्ति है, और इसका उपयोग अन्य अभिव्यक्तियों के अंदर किया जाएगा। यही है, चूंकि हम खुद को अभिव्यक्ति की खातिर अंतरिक्ष में सीमित करते हैं, तो सशर्त ऑपरेटर को कुछ अनुभवजन्य ढांचे से परे नहीं जाना चाहिए।

शायद यह मुश्किल नहीं है अगर-और-और, इन वाक्यविन्यास तत्व, एक अच्छी जोड़ी की तरह, अभिव्यक्ति के किसी भी हिस्से में फिट हो सकते हैं, लेकिन संबंधित केस-कंस्ट्रक्शन परेशानी भरा हो सकता है। यह विस्तार कर सकता है: विकल्पों की संख्या असीमित है। हम फैक्टरियल फंक्शन को फिर से लिखते हैं:

fact n = case n == 0 का
सत्य -> १
मिथ्या -> तथ्य ( n - 1 ) * n

सोचने के लिए कुछ है। केस निर्माण में एक नया शब्दार्थ जोड़ा गया है: पैटर्न मिलान। यहां, मैं स्वीकार करता हूं, मैं अभी तक एक सभ्य विकल्प के साथ नहीं आया हूं। लेकिन आप स्केचेस में से किसी एक के साथ सादृश्य द्वारा कोशिश कर सकते हैं:



नमूने के साथ तुलना का अर्थ यह है कि "->" संकेत के सामने प्रत्येक क्यूब्स पर एक काफी बड़ी अभिव्यक्ति हो सकती है। संभावनाएं बहुत अधिक हैं: यहां सूचियों का विभाजन है, और बीजीय डेटा प्रकारों के साथ मनमाने ढंग से गहरी तुलना, और यहां तक ​​कि व्यू पैटर्न भाषा के जुड़े विस्तार के साथ - एक प्रकार का सिंटैक्स जो फ़ंक्शन जैसा दिखता है। मैं केवल सरल, काफी विशिष्ट कोड दिखाऊंगा जहाँ पैटर्न मिलान मामले के अंदर उपयोग किया जाता है:

toHabrFormat ( s , ( ch: [ ] ) ) = s ++ [ ch ]
toHabrFormat a @ ( s , b @ ( ch: inStr ) ) = let स्वरूपित = ( foldr1 ( <>> ) स्वरूपक ) a
के स्वरूप में
बस ( रेस , [ ] ) -> रेस
बस ( Res , ( r: rs ) ) -> toHabrFormat ( res ++ [ r ] , rs )
कुछ भी नहीं -> हैफब्रमेट ( s + [ ch ] , inStr )

जाहिरा तौर पर, जबकि बीजीय डेटा प्रकारों, सूचियों, टुपल्स आदि का प्रतिनिधित्व करने के बारे में कोई स्पष्टता नहीं है, मामला-निर्माण असंबद्ध होगा।

अब, फिर भी, कम्प्यूटेशनल अभिव्यक्तियों को अलग रखें और अपने नाम और सुरक्षा अभिव्यक्तियों के साथ तथ्यात्मक फ़ंक्शन के विज़ुअलाइज़ेशन को पूरा करने का प्रयास करें।

तथ्य एन | n == 0 = 1
| n / = 0 = fact ( n - 1 ) * n

सुरक्षा अभिव्यक्तियों के बारे में कुछ कहा जाना है। ये नियमित अभिव्यक्ति हैं, लेकिन वे हमेशा एक बूलियन मान लौटाते हैं - सच या गलत। वे कुछ फ़िल्टरों के रूप में कार्य करते हैं, जैसे कि शरीर में निष्पादन को लंघन नहीं, यदि स्थिति सही नहीं है। इस अवधारणा के साथ खेलते हुए, आप कुख्यात की तरह कुछ के साथ आ सकते हैं अगर। आइए निम्न विकल्प का मूल्यांकन करें:



समानता के साथ बॉक्स ("पुल") सुरक्षा अभिव्यक्तियों और फ़ंक्शन के शरीर को उसी तरह से संयोजित करने की इच्छा से उभरा, जैसे कोड में। और यह एक दिलचस्प विचार है। जैसा कि यह विकसित हुआ, यह कुछ और बढ़ गया - भागों का एक दृश्य पृथक्करण (फ़ंक्शन नाम; सुरक्षा अभिव्यक्तियाँ; कम्प्यूटेशनल अभिव्यक्ति)। आप और आगे जा सकते हैं: उन्हें प्लेटफ़ॉर्म पर रखें, जिससे प्रत्येक भाग के स्थान का परिसीमन हो।



कोड में, गार्ड की अभिव्यक्ति चरित्र से शुरू होती है '|' यदि यह नहीं है, तो कोड विरोधाभासी लगेगा:

fact n n == 0 = 1
n / = 0 = fact ( n - 1 ) * n

संकलक यह नहीं समझ पाएंगे कि शब्द तथ्य के बाद अक्षर और प्रतीक क्या हैं। एक ऊर्ध्वाधर पट्टी वाक्यविन्यास का एक आवश्यक तत्व है, और इसलिए हमें इसे विज़ुअलाइज़ेशन में जोड़ने की आवश्यकता है। बूलियन अभिव्यक्ति के साथ मंच के बाईं ओर कुछ डालना तर्कसंगत है; यह हो सकता है, उदाहरण के लिए, एक "दीवार":



लेकिन क्या यह इतना सहज है? एक ठोस बॉक्स एक बाधा, प्रतिबंध जैसा दिखता है, और हमें इसकी आवश्यकता है - एक स्थिति, परिवर्तनशीलता। यदि हम एक घन के रूप में प्रगति को प्रस्तुत करते हैं, तो, फ़ंक्शन के नाम से गार्ड अभिव्यक्ति तक बढ़ते हुए, यह बस दीवार से टकराएगा - और फ़ंक्शन के किसी भी निकाय को प्राप्त नहीं किया जाएगा। इस प्रतिबिंब में एक अधिक सहज संस्करण की कुंजी निहित है: क्या होगा यदि आप दीवार में एक छेद बनाते हैं? आप अपने आप को इस तरह से सोच सकते हैं: यदि तार्किक स्थिति सच है, तो क्यूब छेद से गुजरेगा और आपको जहां जरूरत होगी, वहां पहुंच जाएगा। आंदोलन की दिशा भी देखने लायक है: तीर वाले पुलों को इसे दिखाने दें, वे फ़ंक्शन के दाएं और बाएं हिस्सों को जोड़ने में भी मदद करेंगे:



बहुत बेहतर! अब हम तर्कों के साथ फ़ंक्शन के नाम की कल्पना करते हैं। फिर से, यहां हम पैटर्न मिलान के साथ काम कर रहे हैं, और, एक अच्छे तरीके से, इसे आर्किटी के साथ जोड़ा जाना चाहिए। हमने पहले ही सीखा है कि तर्कों के लिए कटआउट कैसे बनाया जाता है, और वे यहाँ काम आएंगे। नमूने के साथ तुलना के बिना, हमारे पास ऐसा विकल्प होगा:



तो, ग्राफिक भाषा का आधार बनाया गया है, और हम अब लगभग कल्पना करते हैं कि यह कैसा दिखना चाहिए। स्पष्ट तस्वीर के लिए, आपको अभी भी बीजीय डेटा प्रकारों, सूचियों, टुपल्स और पैटर्न मिलान जैसी महत्वपूर्ण चीजों से निपटना होगा। जब वे समाप्त हो जाते हैं, तो अधिकांश संभावना विचार प्रकट होंगे कि किस प्रकार के घोषणाओं के साथ क्या करना है, do-constructs, सूची जनरेटर, as-pattern, वर्ग प्रकार, वर्ग अवतार, और हास्केल सिंटैक्स के अन्य अद्भुत तत्वों के साथ।

आइए बीजीय डेटा प्रकारों, सूचियों और पैटर्न मिलान से शुरू करें। उपरोक्त उदाहरण में, हमने पहले से ही एडीटी और पैटर्न मिलान की कल्पना करने की कोशिश की। कल्पना करें कि कटौती के बजाय एरिटी को प्रोट्रूशियंस द्वारा इंगित किया गया है। केस, ट्रू और फाल्स वाली तस्वीर तब गलत होगी, क्योंकि इन दोनों कंस्ट्रक्टर्स की अरैस्ट जीरो है। हालांकि, जस्ट 1 की योग्यता 1 है, और उसके पास एक लीड होगी।



सूचियाँ infix ऑपरेटर के माध्यम से बनाई गई हैं: ":" (जो वास्तव में एक प्रकार का निर्माता है, लेकिन यह एक और कहानी है [1])। हम पहले से ही यह कल्पना करना जानते हैं। आइए हम एक और अधिक जटिल मामला लेते हैं, जब दोनों "महत्वहीन" तत्व और एक खाली सूची होती है। यहाँ एक काल्पनिक कोड है:

someFunc someList = केस के कुछ कलाकार
( X1: x2: _ : xs ) -> बस ( X1 , x2 )
( X1: [ ] ) -> बस ( X1 , X1 )
[ ] -> कुछ नहीं

हास्केल भाषा के निर्माण स्वयं उनके सार को स्पष्ट रूप से प्रदर्शित करते हैं। एक महत्वहीन तर्क को एक अंडरस्कोर द्वारा प्रतिस्थापित किया जाता है, और एक खाली सूची को खाली वर्ग कोष्ठक द्वारा प्रतिस्थापित किया जाता है। रेंडर करते समय हम इसे ध्यान में रखेंगे। कोड औपचारिकता में, पहले विकल्प से केवल तर्क X1, X2 और xs के बीच अंतर दिखाई नहीं देते हैं। इस बीच, एक्स 1 और एक्स 2 सामने की सूची के तत्व हैं, और एक्स संभवतः संभावित खाली सूची के बाकी हैं। किसी भी तरह अंतर दिखाना उपयोगी होगा।




हां, लिस्टिंग बहुत अच्छी लग रही है। मुझे विशेष रूप से "महत्वहीन" तत्व पसंद है। ट्यूपल्स के बारे में क्या? ठीक है, स्मार्ट होने का कोई कारण नहीं है: बस टुप्ल के प्रत्येक तत्व को एक आम बोर्ड पर खांचे में रखें। फ़ंक्शन को भ्रमित नहीं किया जा सकता है, क्योंकि टपल का कोई नाम नहीं है, और इसका आधार पतला है। विश्वसनीयता के लिए, आप रंग बदल सकते हैं।



ऐसा मुश्किल काम नहीं! इसलिए, तार्किक रूप से, आप विज़ुअलाइज़ेशन के लिए एक भाषा का निर्माण कर सकते हैं। यह ठीक है अगर कुछ डिज़ाइनों को कई संस्करणों के माध्यम से मान्यता से परे बदल दिया जाता है। अब, इस प्रकार की घोषणा की कल्पना करने के बिना, मैं बाद में यह पता लगाने का जोखिम उठाता हूं कि वे अर्ध-समाप्त योजना में फिट नहीं होते हैं। आपको कुछ बदलना होगा, कुछ त्याग करना होगा, लेकिन विज़ुअलाइज़ेशन के सामान्य सिद्धांत समान रहेंगे। बेशक, कल्पना के लिए बड़े खुले स्थान थे। मैंने अभी तक रंगों और रंगों का चयन नहीं किया है, मैंने फोंट के बारे में नहीं सोचा है, और तत्वों के आकार में कई तरीकों से सुधार किया जा सकता है। यहां तक ​​कि इस तरह के एक विचार था: शिलालेख ग्लास के साथ बक्से बनाने के लिए, और शिलालेख अंदर डाल दिया, और इसे प्रतिबिंबित प्रकाश के साथ सभी टिमटिमाना। Perpetuate, तो बोलने के लिए, ग्लास में कोड। यह शायद कुछ इस तरह होगा:



सौंदर्य, ज़ाहिर है। और यह पहले से ही लगता है कि यहां मुख्य लागत एक डिजाइन का आविष्कार करना है, और विज़ुअलाइज़ेशन को किसी तरह के ग्राफिक संपादक में जल्दी से पकाया जा सकता है, लेकिन ... वास्तव में, सब कुछ कुछ अधिक जटिल है, क्योंकि विज़ुअलाइज़ेशन के लिए एक कार्यक्रम की आवश्यकता होती है, न कि एक स्थिर 3 डी दृश्य। यह बिल्कुल उसी तरह का कार्यक्रम है जैसा कि मैं ग्राफसर्वर परियोजना में बनाता हूं। यह कार्य इस तथ्य से जटिल है कि सभी डिजाइनों के लिए मैं विज़ुअलाइज़ेशन के साथ नहीं आया था;पहले से ही इस लेख को लिखने के समय, कुछ डिज़ाइनों को बहुत बदल दिया गया था या उनका आविष्कार किया गया था। लेकिन इस समय जो तैयार है वह आशाजनक लग रहा है।

यह एक क्रॉस आर्टिकल है। "हास्केल - सौंदर्यशास्त्र" लेख में एक विज़ुअलाइज़ेशन सर्वर बनाने के बारे में पढ़ें ।

पीएस मैं काफी उच्च-गुणवत्ता वाली तस्वीरों के लिए माफी नहीं मांगता। लगता है कि हेब्रस्ट्रॉज उनके साथ कुछ कर रहा है।
[१] - इस टिप्पणी के संबंध में सुधार: it-talk.org/post76900.html#p76900