Hy 1.0 – Python के लिए एक Lisp dialect

 (github.com/hylang)
3 पॉइंट द्वारा GN⁺ 2024-09-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Hy 1.0.0 रिलीज़ हो गया है, जो Python में एम्बेड होने वाला एक Lisp dialect है; यह लगभग 12 साल के रुक-रुक कर हुए development और वास्तविक उपयोग के बाद आया है
  • Hy 1.x में documented language elements के breaking changes पर major version बढ़ेगा, जबकि CPython developers द्वारा अब support न किए जाने वाले Python versions का support हटाना इसका अपवाद होगा
  • आगे का फ़ोकस नए bug fixes, नए Python versions के साथ compatibility जोड़ने, और मौजूदा Hy 1.x.y code को तोड़े बिना Python की नई features के support पर रहेगा
  • एक उपयोगकर्ता ने बताया कि Hy macros के ज़रिए SQLAlchemy ORM declarations को defmodel रूप में छोटा किया जा सकता है, और क्योंकि यह macro expansion है इसलिए runtime पर कोई अतिरिक्त cost नहीं है
  • MicroPython पर सीधे चलना standard library के subset होने की वजह से मुश्किल लगता है, लेकिन CPython में hy2py से convert करने के बाद केवल MicroPython-supported constructs का उपयोग करना संभव हो सकता है

Hy 1.0.0 रिलीज़

  • Hy 1.0.0 रिलीज़ हो गया है
    • Hy, Python में एम्बेड होने वाला एक Lisp dialect है
    • इस रिलीज़ तक पहुँचने में लगभग 12 साल का रुक-रुक कर development और काफी वास्तविक उपयोग शामिल रहा है
  • परिचय और documentation Hylang.org पर उपलब्ध है
  • version history NEWS file में देखी जा सकती है
  • रिलीज़ से जुड़ी एक कम औपचारिक पोस्ट HYPE POST भी लिंक की गई है

1.x compatibility policy

  • आगे documented language parts में किसी भी breaking change के लिए major version number बढ़ाया जाएगा
  • अपवाद सिर्फ़ वह स्थिति होगी जब CPython developers जिन Python versions को अब support नहीं करते, उनका support हटाया जाए
  • इसका उद्देश्य है कि major version increments बार-बार न हों
  • आगे के काम का फ़ोकस इन बातों पर रहेगा
    • नए bug fixes
    • नए Python versions के साथ compatibility जोड़ना
    • पुराने Hy 1.x.y में चलने वाले code को बिना तोड़े Python की नई features का support देना

Hy macros का उपयोग: SQLAlchemy model DSL

  • एक उपयोगकर्ता ने बताया कि वह Hy के साथ ORM और एक asynchronous web framework बना रहा है, और दोनों मौजूदा libraries का उपयोग करते हैं तथा ज़्यादातर macros से बने हैं
  • SQLAlchemy ORM Quick Start Guide की model declaration को Hy के defmodel macro से अधिक संक्षिप्त रूप में लिखने का उदाहरण दिया गया
    • User, Address models और relationship declarations को Hy S-expression रूप में लिखा गया
    • defmodel, SQLAlchemy code में expand होने वाला macro है, इसलिए runtime पर कोई अतिरिक्त cost नहीं होती
  • उपयोगकर्ता ने कहा कि ऐसे काम के लिए Hy के internals और API का stable होना ज़रूरी है

relationship declarations और query DSL पर चर्चा

  • defmodel उदाहरण को कई relationship patterns तक बढ़ाया गया
    • one-to-one: 1->1
    • many-to-many: *->* और deflinktable
    • timestamp fields: :timestamp-create, :timestamp-update
  • declaration के बाद objects सामान्य SQLAlchemy 2.0 ORM objects होते हैं, इसलिए database schema DSL वाला हिस्सा Hy में और बाकी Python में लिखा जा सकता है
  • query DSL अभी काम में है, और कहा गया कि fluent interface, S-expression के साथ बहुत स्वाभाविक रूप से फिट नहीं बैठता
  • एक टिप्पणी में सुझाव दिया गया कि SQL की syntactic order और semantic order को मेल खाना चाहिए, और Google Research का SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL लिंक किया गया
  • इसके जवाब में कहा गया कि |> जैसी form या list comprehension की नकल करने वाला तरीका संभव हो सकता है, लेकिन अंतिम design छोटे apps बनाकर और refactoring दोहराने के बाद ही सामने आएगा

MicroPython की संभावना और रिलीज़ पर प्रतिक्रिया

  • यह सवाल उठा कि क्या यह CPython के बजाय MicroPython पर चल सकता है
  • जवाब यह था कि MicroPython, Python standard library का केवल छोटा subset शामिल करता है, इसलिए सीधे चलना मुश्किल लगता है
  • फिर भी, CPython में hy2py का उपयोग करके Python code में convert करने के बाद, अगर उसे MicroPython-supported constructs तक सीमित रखा जाए तो output चल सकता है
  • रिलीज़ वाले दिन Hylang.org host करने वाले web server पर daily unique visitors की संख्या में बड़ा उछाल देखा गया

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

1 टिप्पणियां

 
GN⁺ 2024-09-23
Hacker News टिप्पणियाँ

  • यह समझना थोड़ा मुश्किल था कि Hy असल में Python में कैसे बदला जाता है, और शुरुआत में यह भी पक्का नहीं था कि यह compile होता है या interpret
    आखिरकार Wikipedia पर यह विवरण मिला कि “Hy एक Lisp dialect है जिसे s-expression को Python के abstract syntax tree (AST) में बदलकर Python के साथ interact करने के लिए design किया गया है”, और GitHub code देखने पर compiler भी Python में लिखा लगता है: https://github.com/hylang/hy/blob/master/hy/compiler.py
    main site पर भी “Python में embedded Lisp dialect” की बजाय “Python AST में compile होने वाला Lisp dialect” कहकर पेश किया जाए तो ज्यादा स्पष्ट होगा। Lisp को embed करने के कई तरीके हैं, जैसे interpreter जोड़ना, Python bytecode में compile करना, या Python source code में बदलना, और हर तरीके के trade-off काफी अलग हैं

    • README/GitHub page पर पहले से लिखा है कि “Hy Python में embedded Lisp dialect है, और Lisp code को Python AST objects में बदलता है, इसलिए Python world को Lisp रूप में इस्तेमाल किया जा सकता है”
    • सही, यह compiler Python में लिखा गया है और Hy self-hosting नहीं है
      आम तौर पर Hy source code Python AST object बनता है, और Python उसे compile करके चलाता है। हालांकि Python AST object को Python source text में बदलना भी संभव है, और Hy में Python इस्तेमाल करने या Python में Hy इस्तेमाल करने की interoperability भी संभव है: https://hylang.org/hy/doc/v1.0.0/interop
    • “embed” शब्द इस बात से आया है कि एक project में Python और Hy को मिलाया जा सकता है और दोनों दिशाओं में call किया जा सकता है
      आखिर में सब Python bytecode बन जाता है, इसलिए यह ठीक से काम करता है
    • Hy की मूल घोषणा में यह बात साफ दिखती है कि Lisp को Python bytecode में compile करके embed किया जाता है
      नीचे दिए गए video में लगभग 16:25 पर देखा जा सकता है: https://m.youtube.com/watch?v=1vui-LupKJI

  • कई सालों में Hy के mature होने के साथ, वह ज्यादा Lispy और कम Pythony बनने के लिए syntax sugar और special cases जोड़ने की बजाय, उल्टा Python feature set का एक पतला syntactic abstraction जैसा बन गया है
    यानी फोकस उस core पर है जिसकी नकल दूसरे तरीकों से करना मुश्किल है, खासकर macros पर। हालिया उदाहरण के तौर पर match बस Python का native match है और Python 3.10 से पहले के versions के लिए कोई polyfill नहीं है। पहले foo? एक special case के रूप में is_foo में mangle होता था, लेकिन हटा दिया गया; hy.eval को Python के eval के ज्यादा करीब फिर से बनाया गया; और unless जैसी अच्छी-लेकिन-non-core utilities अक्सर Hyrule package में भेज दी जाती हैं
    शुरू में यह दिशा intuition के उलट लगी, लेकिन Python से Hy पर आते समय learning curve कम करने और Python packages के साथ consistent तरीके से interact करना आसान बनाने का बड़ा फायदा है। शायद language maintenance को सरल बनाने की वजह भी हो सकती है, और याद पड़ता है कि let को ठीक से बनाने में भी करीब चार कोशिशें लगी थीं

    • किसी point पर समझ आया कि Python से गैर-जरूरी differences को कम से कम करने से language maintenance और use दोनों बहुत ज्यादा smooth हो जाते हैं
      Hy code लिखते समय भी Hy documentation की तुलना में Python या third-party Python libraries की documentation कहीं ज्यादा बार देखनी पड़ती है। लगा कि Python को बेहतर बनाने की कई जगहें हैं, लेकिन पहले की तरह Clojure का ध्यान रखते हुए True को true लिखने देने वाला feature बस unnecessary complexity था

  • HYPE POST वाकई बहुत अच्छा था। enterprise software में काम करने वाले के तौर पर इसका व्यंग्यबोध बहुत शानदार है
    https://github.com/hylang/hy/discussions/2609

  • अब जब यह आखिरकार आ गया है, तो https://github.com/rcarmo/sushy को व्यवस्थित कर पाऊँगा
    कई सालों से इसे थोड़ा-थोड़ा छेड़ता रहा हूँ, लेकिन Hy upgrade करते समय हर बार syntax का कुछ हिस्सा टूट जाता था या features Hyrule package में अंदर-बाहर होते रहते थे, जिससे दिक्कत होती थी
    संदर्भ के लिए, Hy iPad के https://holzschu.github.io/a-Shell_iOS के अंदर भी काफी अच्छी तरह चलता है। हालांकि vim/neovim की syntax highlighting को 0.29+ releases और async के साथ catch up करना होगा
    इस बीच Fennel और Guile भी आज़माए, लेकिन Python libraries और ecosystem तक access मिलना बेहतर है। async की वजह से efficient API work भी अच्छे से हो जाता है, और कई Scheme में socket reuse और headers पर fine control रखते हुए HTTPS handle करना अभी भी झंझट भरा है, इसलिए aiohttp इस्तेमाल करना कहीं बेहतर लगता है

  • शुरुआती साधारण शुरुआत की तुलना में यह सचमुच बहुत आगे आ गया है
    पहले PyCon में Hy को दुनिया के सामने पहली बार introduce करने वाली lightning talk देखी थी, और कुछ ही समय बाद Paul से मिलकर Hy के शुरुआती versions में contribute करना शुरू किया। Common Lisp style के kwargs, कुछ internals, और एक-दो libraries पर काम किया
    खेल-भावना/मस्ती उपयोगी होती है, खासकर enthusiasm बनाए रखने में। अच्छा लगता है कि hackers hackers की तरह रह सकते हैं और हर चीज business होना जरूरी नहीं। कई सालों से involved नहीं हूँ, लेकिन project को आगे बढ़ते देखकर अच्छा लगता है, और यह एक बेहतरीन milestone लगता है

  • Clojure fans के लिए, इसी संदर्भ में Python 3.8+ को target करने वाला Clojure-compatible के करीब Lisp dialect Basilisp भी है
    https://github.com/basilisp-lang/basilisp

  • Lisp नहीं है, लेकिन Python में transpile होने वाली functional programming language के नजरिए से Coconut भी दिलचस्प है: https://coconut-lang.org/
    Hy या Coconut को सच में इस्तेमाल कर चुके लोगों के अनुभव वाकई जानना चाहता हूँ

    • कुछ साल पहले Coconut थोड़ा इस्तेमाल किया था, और उस समय impression यह था कि compiler उपयोगी होने लायक स्मार्ट नहीं था
      generated code के सबसे ऊपर hardcoded helper functions का ढेर जुड़ जाता था, और वही चीज़ सामान्य Python में लिखने की तुलना में program काफी धीमा था
      इसके उलट Hy, let की scope handling से पैदा होने वाली थोड़ी-सी indirection layer या return value के आसपास के फर्क को छोड़ दें, तो ऐसे code generate करता है जो इंसान के हाथ से लिखे जाने वाले Python code के काफी करीब होता है। हालांकि Coconut को भी अब काफी समय हो गया है, इसलिए शायद उसमें सुधार हुआ हो

  • बधाई। दो बातें जाननी हैं: क्या यह REPL-driven development को support करता है, जैसे condition system या breakloop जैसी कोई चीज़ है?
    और क्या कोई standalone distribution भी है? Python distribution खुद ही झंझट भरा है, इसलिए आदर्श रूप से अच्छा होगा अगर सभी dependencies के साथ एक single Hy binary distribute की जा सके। static link हो या temporary directory में unpack होने वाली zip file, दोनों ठीक हैं

    • standalone distribution तो नहीं है, लेकिन uvx hy@1.0.0 से Hy REPL में जा सकते हैं
      echo '(print "hi hn")' > hi.hy के बाद uvx hy@1.0.0 hi.hy चलाएँ तो यह "hi hn" print करता है
      https://docs.astral.sh/uv/guides/tools/#running-tools
      संदर्भ के लिए, uv Python version install और manage भी कर सकता है
    • breakloop क्या है, यह मुझे ठीक से नहीं पता। Hy Python का exception system इस्तेमाल करता है, जो Common Lisp के condition system की तुलना में traditional exception system के ज्यादा करीब है
      standalone distribution नहीं है
    • REPL docs में इससे जुड़ी जानकारी है: https://hylang.org/hy/doc/v1.0.0/repl
      code को interactively debug करने के लिए जिस code को debug करना है उसमें (.run (hy.REPL :locals {#\* (globals) #\* (locals)})) डाल सकते हैं, और Python में import hy; hy.REPL(locals = {\*globals(), \*locals()}).run() की तरह लिख सकते हैं
      हालांकि code.interact() की तरह, REPL के अंदर local variables बदलने पर वे original scope में propagate नहीं होते
    • py2app और सावधानी से की गई hacking के साथ मैंने #2 के करीब कुछ किया है
      सब कुछ bytecode में compile करने के बाद Python के single-file distribution tools इस्तेमाल किए जा सकते हैं
    • Hy वही feature set support करता है जो Python support करता है। traditional step-by-step debugging या post-mortem debugging के लिए यह काफी अच्छा है, और CPython में इससे भी advanced internal hooks बहुत हैं
      लेकिन condition system या handlers/restarts जैसी चीज़ें नहीं हैं

  • कम गंभीर वाला हिस्सा बहुत अच्छा लगा। काश और programming projects सनकपन को अपनाएँ
    शायद Python परंपरा का सम्मान करने का यह सबसे अच्छा तरीका भी हो सकता है

    • कुछ साल पहले Hy और docs से हमने काफी सारे playful elements हटा दिए थे। वे ध्यान भटकाते थे और noisy test failures पैदा करते थे
      लेकिन किसी point पर लगा कि हम बहुत आगे निकल गए हैं, इसलिए हाल में थोड़ी-सी playful चीज़ें वापस जोड़ने की कोशिश कर रहे हैं

  • Hy को बीच-बीच में इस्तेमाल करता रहा हूँ, और transformer बनाने की कोशिश करते हुए Hy में लिखा https://github.com/kunalb/orphism भी publish किया था
    लगता है अब इसे फिर से निकालकर ठीक से चलाने का समय आ गया है