Piet: अमूर्त चित्र जैसी प्रोग्राम बनाने वाली प्रोग्रामिंग भाषा (2002 में विकसित)

 (dangermouse.net)
4 पॉइंट द्वारा GN⁺ 2024-04-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Piet एक esoteric प्रोग्रामिंग भाषा है, जिसे इस तरह बनाया गया है कि कोड अमूर्त कला जैसा दिखे, और इसका नाम ज्यामितीय अमूर्त कला के अग्रणी Piet Mondrian के नाम पर रखा गया है
  • प्रोग्राम 20 पहचाने जाने वाले रंगों से बना एक ग्राफिक होता है, और इंटरप्रेटर रंग ब्लॉकों के बीच चलते हुए रंग परिवर्तन की मात्रा को कमांड के रूप में समझता है
  • सारा डेटा केवल पूर्णांकों के रूप में मौजूद होता है और stack में संग्रहीत होता है, जबकि किसी रंग ब्लॉक का आकार एक मान होता है, लेकिन push कमांड के बिना वह अपने-आप stack पर नहीं चढ़ता
  • flow control Direction Pointer और Codel Chooser, तथा काले ब्लॉक, किनारों और सफेद ब्लॉक के नियमों से तय होता है, और कुछ व्यवहार implementation के अनुसार अलग हो सकते हैं
  • उदाहरण और बाहरी टूल ecosystem मौजूद हैं, लेकिन कोई आधिकारिक authoritative interpreter नहीं है, और error handling तथा non-standard रंगों की व्याख्या implementation पर निर्भर रहती है

Piet का मूल विचार

  • Piet एक ऐसी प्रोग्रामिंग भाषा है जिसमें प्रोग्राम कोड अमूर्त कला जैसा दिखाई देता है
  • इसका नाम ज्यामितीय अमूर्त कला के अग्रणी Piet Mondrian से लिया गया है
  • Mondrian नाम इस्तेमाल करना चाहा गया था, लेकिन उसी नाम की एक scripting language पहले से मौजूद थी, इसलिए Piet नाम अपनाया गया
  • specification लिखे जाने के बाद एक छोटी community बनी, जिसने प्रोग्राम, interpreter, IDE और compiler बनाए हैं
  • कोई आधिकारिक authoritative interpreter नहीं है, और उपलब्ध implementations specification की थोड़ी-थोड़ी अलग व्याख्या कर सकती हैं
  • specification की कुछ अतिरिक्त व्याख्याएँ जोड़ी गई हैं, लेकिन संभव है कि कुछ पुराने implementations उनका पालन न करें

रंग और कोड इकाइयाँ

  • Piet कुल 20 रंगों का उपयोग करता है
    • 18 रंग hue cycle और lightness cycle में शामिल हैं
    • सफेद और काला इन दोनों cycles में शामिल नहीं हैं
  • hue cycle का क्रम red -> yellow -> green -> cyan -> blue -> magenta -> red है
  • lightness cycle का क्रम light -> normal -> dark -> light है
    • light को dark से एक चरण अधिक गहरा भी माना जाता है, और इसका उलटा भी सही है
  • orange या brown जैसे non-standard रंगों का उपयोग किया जा सकता है, लेकिन उनका प्रभाव implementation पर निर्भर करता है
    • सबसे सरल स्थिति में non-standard रंगों को सफेद की तरह माना जाता है
    • दूसरी संभावना यह है कि उन्हें काले की तरह माना जाए

Codel और रंग ब्लॉक

  • Piet कोड पहचाने जा सकने वाले रंगों से बनी एक ग्राफिक छवि होता है
  • क्योंकि अलग-अलग कोड pixels का भाषाई अर्थ होता है, इसलिए देखने में सुविधा के लिए बड़े किए गए प्रोग्रामों में कोड के एकल pixel को codel कहा जाता है
  • मूल execution unit रंग ब्लॉक है
    • रंग ब्लॉक एक ही रंग के codels का ऐसा क्षेत्र है जो ऊपर-नीचे-দाएं-बाएं जुड़ा हो
    • जो ब्लॉक केवल diagonal रूप से छूते हैं, उन्हें जुड़ा हुआ नहीं माना जाता
    • रंग ब्लॉक किसी भी आकार का हो सकता है और उसके भीतर दूसरे रंगों के छेद हो सकते हैं
    • अंदर के छेद उस ब्लॉक का हिस्सा नहीं होते

Stack और मानों का निरूपण

  • Piet सभी डेटा मानों को stack में संग्रहीत करता है
  • डेटा मान केवल पूर्णांक होते हैं
    • कमांड के अनुसार उन्हें Unicode character values के रूप में input या output किया जा सकता है
  • stack वैचारिक रूप से असीम गहराई का है, लेकिन implementation एक सीमित maximum stack size रख सकता है
  • सीमित stack में overflow होना runtime error है, और उसका निपटान implementation पर निर्भर करता है
  • काले और सफेद को छोड़कर हर रंग ब्लॉक उस ब्लॉक में मौजूद codels की संख्या के बराबर एक पूर्णांक मान दर्शाता है
    • शून्य या ऋणात्मक पूर्णांकों को सीधे व्यक्त नहीं किया जा सकता
    • लेकिन उन्हें operators के जरिए बनाया जा सकता है
    • रंग ब्लॉक का मान अपने-आप stack पर push नहीं होता, उसके लिए स्पष्ट push कमांड चाहिए
  • पूर्णांकों का आकार भी वैचारिक रूप से असीम है, लेकिन implementation एक सीमित maximum integer size रख सकता है
    • integer overflow runtime error है और उसका निपटान implementation पर निर्भर है

execution flow

  • interpreter प्रोग्राम के ऊपर-बाएँ codel को शामिल करने वाले रंग ब्लॉक से execution शुरू करता है
  • execution के दौरान दो स्थितियाँ बनी रहती हैं
    • Direction Pointer (DP): शुरुआत में दाईं ओर इशारा करता है, और दाएँ, बाएँ, नीचे या ऊपर में से किसी एक दिशा की ओर हो सकता है
    • Codel Chooser (CC): शुरुआत में बाईं ओर सेट होता है, और बाएँ या दाएँ में से एक को चुनता है
  • अगला move target वर्तमान रंग ब्लॉक की सीमा और DP·CC के संयोजन से तय होता है
    • DP की दिशा में वर्तमान रंग ब्लॉक के सबसे दूर वाले किनारे को खोजा जाता है
    • उस किनारे पर DP की प्रगति दिशा के आधार पर CC दिशा में सबसे दूर वाले codel को चुना जाता है
    • उस codel से DP दिशा में ठीक अगले codel के रंग ब्लॉक में move किया जाता है
  • यह प्रक्रिया दोहराई जाती है, और termination condition आने पर प्रोग्राम समाप्त हो जाता है

काले ब्लॉक, किनारे और सफेद ब्लॉक

  • काले रंग ब्लॉक और प्रोग्राम की सीमाएँ execution flow को रोकने वाली बाधा की तरह काम करती हैं
  • यदि interpreter किसी काले ब्लॉक में जाने की कोशिश करे या किनारे से बाहर निकलना चाहे, तो वह रुकता है और CC को switch करता है
  • दूसरी कोशिश भी असफल होने पर DP को clockwise एक चरण घुमाया जाता है
  • CC और DP को बारी-बारी से बदलते हुए कुल 8 प्रयासों के बाद भी यदि वर्तमान रंग ब्लॉक से बाहर नहीं निकला जा सके, तो प्रोग्राम समाप्त हो जाता है

  • सफेद ब्लॉकों में move

    • सफेद रंग ब्लॉक एक free area है, जिसमें interpreter बिना बाधा के गुजरता है
    • रंग ब्लॉक से सफेद क्षेत्र में जाने पर interpreter DP दिशा में सीधी रेखा में चलता है, जब तक कि वह किसी गैर-सफेद रंग ब्लॉक तक न पहुँच जाए
    • सफेद ब्लॉक से होकर किसी नए रंग में जाने पर कोई कमांड execute नहीं होती
    • इसी गुण के कारण सफेद ब्लॉक बिना कमांड चलाए वर्तमान रंग बदल सकते हैं, इसलिए वे loop लिखने में उपयोगी हैं
    • सफेद ब्लॉक में movement गैर-सफेद रंग ब्लॉक की तरह exit चुनने की प्रक्रिया का उपयोग नहीं करता, बल्कि केवल सीधी चाल करता है

  • सफेद ब्लॉक में रुकावट आने पर

    • यदि सफेद ब्लॉक के भीतर सीधी चाल के दौरान काला ब्लॉक या किनारा मिल जाए, तो इसे restriction माना जाता है
    • इस स्थिति में CC switch किया जाता है, लेकिन जाने की जगह नहीं बदलती, इसलिए DP को तुरंत clockwise एक चरण घुमाया जाता है
    • इसके बाद वर्तमान सफेद codel से नई DP दिशा में फिर सीधी चाल की जाती है
    • सफेद ब्लॉक के भीतर हर restriction पर CC switching और DP rotation दोहराए जाते हैं
    • यदि किसी रंग ब्लॉक में प्रवेश मिल जाए तो execution जारी रहता है, और यदि सफेद ब्लॉक के भीतर रास्ता उलटकर वापस ट्रेस होने लगे, तो बाहर निकलने का मार्ग न होने के कारण execution समाप्त हो जाता है

कमांड प्रणाली

  • Piet में कमांड एक रंग ब्लॉक से अगले रंग ब्लॉक में जाने के दौरान हुए रंग परिवर्तन से तय होते हैं
  • hue cycle में कितने चरण चले और lightness cycle में कितने चरण चले, यही कमांड निर्धारित करते हैं
  • सफेद ब्लॉक के जरिए हुए रंग संक्रमण में कोई कमांड execute नहीं होती

  • stack और arithmetic कमांड

    • push: अभी छोड़े गए रंग ब्लॉक के मान को stack पर रखता है
    • pop: stack के सबसे ऊपर के मान को हटाकर फेंक देता है
    • add: ऊपर के दो मान जोड़कर परिणाम फिर stack पर रखता है
    • subtract: दूसरे मान में से सबसे ऊपर वाले मान को घटाकर परिणाम stack पर रखता है
    • multiply: ऊपर के दो मानों को गुणा करता है
    • divide: दूसरे मान को सबसे ऊपर वाले मान से integer division करता है
    • 0 से भाग देना implementation-dependent error है, और कमांड को ignore करना recommended है
    • mod: दूसरे मान को सबसे ऊपर वाले मान से भाग देने पर मिलने वाला शेषफल stack पर रखता है
    • परिणाम का sign divisor, यानी stack के सबसे ऊपर वाले मान, के समान होता है
    • यदि सबसे ऊपर का मान 0 हो, तो यह divide-by-zero error है, और कमांड को ignore करना recommended है
    • ऋणात्मक dividend के लिए mod, Wikipedia के modulus operation में बताए गए floored division के समान है

  • तुलना, pointer और input/output कमांड

    • not: यदि stack का सबसे ऊपर का मान 0 नहीं है तो उसे 0 में बदलता है, और यदि 0 है तो 1 में बदलता है
    • greater: यदि दूसरा मान सबसे ऊपर वाले मान से बड़ा है, तो 1, अन्यथा 0 stack पर रखता है
    • pointer: stack का सबसे ऊपर का मान निकालकर DP को उतनी बार clockwise घुमाता है
    • यदि मान ऋणात्मक हो, तो उसे anti-clockwise घुमाया जाता है
    • switch: stack का सबसे ऊपर का मान निकालकर CC को उतनी बार switch करता है
    • यदि मान ऋणात्मक हो, तो उसके absolute value जितनी बार switch किया जाता है
    • duplicate: stack के सबसे ऊपर वाले मान की प्रति stack पर रखता है
    • roll: ऊपर के दो मान निकालकर बचे हुए stack के एक हिस्से को दी गई depth और count के अनुसार rotate करता है
    • यदि depth ऋणात्मक हो तो यह error है और कमांड ignore की जाती है
    • implementation-dependent maximum stack depth से अधिक का roll implementation-dependent error है, और कमांड ignore करना recommended है
    • in: STDIN से संख्या या character पढ़कर stack पर रखता है
    • यदि input न हो, या integer input में integer न मिले, तो यह error है और कमांड ignore की जाती है
    • out: stack के सबसे ऊपर के मान को संख्या या character के रूप में STDOUT पर output करता है
    • जिन operations को stack में पर्याप्त मान न होने के कारण किया नहीं जा सकता, वे ignore कर दिए जाते हैं और execution अगले कमांड पर बढ़ जाता है

उदाहरण और टूल

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-25
Hacker News की राय

  • उदाहरण पेज का आखिरी program सच में हैरान करने वाला है: कहा गया कि Piet नाम के एक व्यक्ति ने ऐसी artwork देखी जो उसे Piet भाषा की याद दिलाती थी, और उसे run करके देखा
    वह run हुई, और शायद यह इतिहास का पहला मामला हो सकता है जिसमें किसी graphic artist ने संयोग से चलने वाला computer program बना दिया
    https://www.dangermouse.net/esoteric/piet/samples.html
    https://gitlab.fabcity.hamburg/hofalab/piet-get-together

    • अगर “चलने वाला” होने की शर्त को काफी ढीला रखा जाए, तो पहले दिखाया जा चुका है कि ज्यादातर paint splatter पहले से ही valid Perl programs होते हैं
      https://www.mcmillen.dev/sigbovik/
    • Piet J. एक छोटी gallery में artwork देख रहा था और उसे लगा कि यह Piet program जैसी दिखती है; artist ने कहा कि वह उस language के बारे में कुछ नहीं जानता
      Piet ने उस artwork की photo ली, उसे Piet palette के करीब रंगों में व्यवस्थित image file में बदला, और run किया तो वह सचमुच run हुई; code एक infinite loop था जो ASCII characters पढ़कर उनके ASCII numeric values output करता था
      यह वाकई यकीन करना मुश्किल है
    • π calculate करने वाला example भी अच्छा था
      “जाहिर है, बड़ा program इस्तेमाल करने पर ज्यादा accurate value मिल सकती है” वाली व्याख्या मुझे पहली बार देखे गए तरह का मजाक लगी
    • दुर्भाग्य से, वह npiet और मौजूदा Piet specification के बीच के फर्क पर निर्भर करता है
      specification के मुताबिक interpreter को मौजूदा white codel से नए direction की DP में slide करना शुरू करना चाहिए, और तब तक आगे बढ़ना चाहिए जब तक वह किसी color block में न घुस जाए या किसी और limit से न टकरा जाए
      लेकिन npiet interpreter whitespace में झांकने के बाद आखिरी color codel position पर rewind कर देता है। किसी दिन मैं अपने Piet compiler के lexer में इस behavior को option के तौर पर डालना चाहता हूं, लेकिन अभी तक उस पर काम नहीं किया
      specification के हिसाब से वह program एक simple non-terminating loop बन जाता है, क्योंकि लगभग हर block का extreme corner white से adjacent है। कई interpreters और compilers को target करके complex Piet programs लिखना काफी मुश्किल है, और सभी में undocumented subtle interpretation differences हैं
      मुझे लगता है कि मेरे Piet backend का output generally interpreter पर कम निर्भर करता है, लेकिन मैंने detail में सिर्फ तीन-चार दूसरे interpreters ही खंगाले हैं
      https://github.com/boothby/repiet/
    • मैं सोच रहा हूं कि ऐसी simple images, यानी कुछ बड़े rectangular blocks वाली, के valid program होने की probability कितनी होगी
      docs को सरसरी तौर पर देखने पर लगता है कि “जिन operations को perform नहीं किया जा सकता, जैसे stack में values कम होने के कारण pop न कर पाना, उन्हें बस ignore करके अगले command पर आगे बढ़ा जाता है” वाली condition की वजह से ऐसी सारी images बिना error के run हो सकती हैं
      हालांकि उन random images में से कितनी सच में “meaningful” काम करती होंगी, यह अलग सवाल है

  • Piet esoteric programming languages में भी milestone जैसा experiment है, लेकिन मुझे लगता है कि जब तक developer सच में इरादा न करे, program को Mondrian painting जैसा दिखाने के लक्ष्य तक यह नहीं पहुंचता
    अच्छा होता अगर language structure ही इस तरह design होती कि आप जो भी “लिखें”, वह Mondrian painting जैसा दिखे

    • बात सही है, लेकिन Mondrian असल में लगभग सिर्फ primary colors ही इस्तेमाल करता था, इसलिए यह काफी restrictive रहा होगा

  • हमेशा ऐसा सवाल मन में आता है: एल्गोरिदम दिखता कैसा होगा?
    Herman Hesse के उपन्यास The Glass Bead Game में आने वाली चीज़ जैसी कोई चीज़ क्या असल दुनिया में बनाई जा सकती है? इसका मूल शीर्षक Magister Ludi है
    एक दृश्य-केंद्रित व्यक्ति होने के नाते मैं मानना चाहता हूँ कि यह संभव है, और मैंने सच में ऐसे टूल इस्तेमाल भी किए हैं
    https://community.carbide3d.com/uploads/default/original/3X/5/b/5b0872a5666fec9b7bb6fd623c431de03263372d.jpeg
    लेकिन ऊपर वाले सवाल का साफ़ जवाब न हो, तो ऐसे टूल्स के साथ हमेशा यह जोखिम रहता है कि वे कुछ इस तरह बन जाएँ
    https://blueprintsfromhell.tumblr.com/
    https://scriptsofanotherdimension.tumblr.com/
    दृश्य अभिव्यक्ति और modularity के बीच संतुलन बैठाना भी मुश्किल है, और modularity को ज़्यादा आगे बढ़ाने पर हम बहुत आसानी से उसी text barrier पर लौट आते हैं जिससे बचना चाहते थे

    • Piet को हाथ से लिखकर देखने में “एल्गोरिदम दिखता कैसा है” यह तलाशने का मज़ा है
      Sergei Lewis और मैंने अलग-अलग Piet code जनरेट करने वाले टूल बनाए थे। Sergei का assembler मेरे Piet backend की तुलना में कहीं ज़्यादा अच्छा दिखने वाला code बनाता है
      मेरे compiler output में असल में जो दिखता है, वह बस इतना है कि मैंने सचमुच बहुत आलस से trampoline का इस्तेमाल किया था
      http://www.toothycat.net/wiki/wiki.pl?MoonShadow/Piet
      https://github.com/boothby/repiet/
      https://en.wikipedia.org/wiki/Trampoline_(computing)
    • मेरा मानना है कि किसी भी एल्गोरिदम, यहाँ तक कि किसी भी मानसिक अवधारणा का दृश्य निरूपण से 1:1 संबंध होता है
      Steven Pinker की किताब पढ़ते समय यह विचार आया था कि अमूर्त शब्दों को ज़्यादा सरल शब्दों में तोड़ा जा सकता है, और अंततः वे किसी न किसी स्थानिक संबंध का वर्णन करते हैं। उदाहरण के लिए “rekindle” को “दो चीज़ों को फिर से साथ लाना” माना जा सकता है
      इसी तरह for loop भी “एक चीज़ का कई दूसरी चीज़ों के ऊपर से गुजरना” जैसी मानसिक अवधारणा है, और इसका दृश्य निरूपण “100” -> “010” -> “001” जैसा है
      तो उत्सुकता होती है कि क्या ऐसी भाषा बनाई जा सकती है जो इन घटकों को शुद्ध दृश्य transformation के रूप में परिभाषित करे
    • किसी सरल प्रोग्राम के लिए यह कल्पना भी की जा सकती है कि symbols को रंगों के रूप में रखकर Turing machine लागू की जाए

  • ऐसी चीज़ किसी crime thriller में अच्छी लगेगी, जहाँ यह नायक या जांचकर्ताओं को अटका दे और फिर किसी को एहसास हो कि यह code है
    मैं तो सोचता था कि सिर्फ़ QR code ही उपयोगी होते हैं

  • किसी ने Piet में quine बनाया है: http://mamememo.blogspot.com/2009/10/piet-quine.html?m=1
    उस पोस्ट की image टूट गई है, लेकिन उसकी copy यहाँ है: https://codegolf.stackexchange.com/a/23255/103045

  • Piet को खोजने का पल विस्मय, उलझन और हैरानी से भरा एक खास पल होता है
    मेरे मामले में यह मेरे दोस्त Oz के साथ computer science podcast “The CS Primer Show” की इस बातचीत में दर्ज है: https://show.csprimer.com/episodes/e2-dont-let-a-gpt-have-all-the-fun

  • विश्वविद्यालय में esoteric programming languages पर एक छोटी class थी
    हर किसी को Brainfuck, Piet जैसी भाषाओं में से एक चुनकर उसके साथ प्रयोग करना था, और मैंने Piet चुना और काफ़ी आनंद लिया
    सच कहूँ तो मेरी बनाई छोटी example app सौंदर्य की दृष्टि से बहुत शानदार नहीं थी, और Piet से कला बनानी हो तो शायद Piet expert बनना पड़ेगा

  • examples वाला page शानदार है
    canvas को धीरे-धीरे और ज़्यादा जटिल और देखने में अच्छा बनते हुए देखा जा सकता है
    https://www.dangermouse.net/esoteric/piet/samples.html

  • “light को dark से एक स्तर ज़्यादा गहरा माना जाता है” — यह तो काफ़ी गहन है

  • अगर ऐसा autoencoder बनाया जा सके जो Python या किसी और कम esoteric भाषा का code लेकर उसे Piet के रूप में output करना सीखे, तो कमाल होगा
    फिर शायद Stable Diffusion जैसी तरह random algorithms भी जनरेट किए जा सकेंगे