Hy 1.0 – Python için bir Lisp lehçesi

 (github.com/hylang)
3 puan yazan GN⁺ 2024-09-23 | 1 yorum | WhatsApp'ta paylaş
  • Python’a gömülen bir Lisp lehçesi olan Hy 1.0.0, yaklaşık 12 yıllık aralıklı geliştirme ve gerçek kullanımın ardından yayımlandı
  • Hy 1.x’te belgelenmiş dil öğelerindeki uyumluluğu bozan değişiklikler major sürüm artışına yol açacak; CPython geliştiricilerinin artık desteklemediği Python sürümleri için desteğin kaldırılması bunun istisnası olacak
  • Bundan sonraki odak, yeni hata düzeltmeleri, yeni Python sürümleriyle uyumluluk eklenmesi ve mevcut Hy 1.x.y kodunu bozmadan Python’un yeni özelliklerinin desteklenmesi olacak
  • Bir kullanıcı, Hy makrolarıyla SQLAlchemy ORM bildirimlerini defmodel biçimine kısaltan bir örnek vererek bunun makro genişletmesi olduğu için çalışma zamanında ek maliyet oluşturmadığını açıkladı
  • MicroPython üzerinde doğrudan çalışması, standart kütüphanenin alt kümesi nedeniyle zor görünüyor; CPython’da hy2py ile dönüştürdükten sonra yalnızca MicroPython’ın desteklediği yapıları kullanmak mümkün olabilir

Hy 1.0.0 sürümü

  • Hy 1.0.0 yayımlandı
    • Hy, Python’a gömülen bir Lisp lehçesidir
    • Sürüme kadar neredeyse 12 yıl süren aralıklı geliştirme ve çok sayıda gerçek kullanım gerçekleşti
  • Tanıtım ve belgeler Hylang.org adresinde sunuluyor
  • Sürüm geçmişi NEWS file üzerinden görülebilir
  • Sürümle ilgili daha az ciddi bir yazı olarak HYPE POST da bağlantılanmış

1.x uyumluluk politikası

  • Bundan sonra dilin belgelenmiş bölümlerindeki breaking change’ler major sürüm numarasını yükseltecek
  • İstisna, CPython geliştiricilerinin artık desteklemediği Python sürümleri için desteğin kaldırılması
  • Major sürüm artışlarının sık yaşanmamasının amaçlandığı belirtiliyor
  • Gelecekteki çalışmalar şu noktalara odaklanacak
    • Yeni ortaya çıkan hataların düzeltilmesi
    • Yeni Python sürümleriyle uyumluluk eklenmesi
    • Önceki Hy 1.x.y’de çalışan kodu bozmadan Python’un yeni özelliklerini desteklemek

Hy makro kullanım örneği: SQLAlchemy model DSL’i

  • Bir kullanıcı, Hy ile ORM ve asenkron web framework geliştirdiğini; her ikisinin de mevcut kütüphanelerden yararlandığını ve büyük ölçüde makrolardan oluştuğunu açıkladı
  • SQLAlchemy ORM Quick Start Guide’daki model bildirimini Hy’nin defmodel makrosuyla daha kısa ifade eden bir örnek sunuldu
    • User, Address modelleri ve ilişki bildirimleri Hy S-expression biçiminde yazılıyor
    • defmodel, SQLAlchemy koduna genişleyen bir makro olduğundan çalışma zamanında ek maliyet yok
  • Kullanıcı, Hy’nin iç yapısının ve API’sinin kararlı hale gelmesinin bu tür çalışmalar için gerekli olduğunu belirtti

İlişki bildirimleri ve sorgu DSL’i tartışması

  • defmodel örneği çeşitli ilişki kalıplarına genişletiliyor
    • one-to-one: 1->1
    • many-to-many: *->* ve deflinktable
    • timestamp alanları: :timestamp-create, :timestamp-update
  • Bildirimden sonra nesneler sıradan SQLAlchemy 2.0 ORM nesneleri olduğundan, veritabanı şeması DSL kısmı Hy ile yazılıp geri kalanı Python ile kullanılabilir
  • Sorgu DSL’i hâlâ üzerinde çalışılan bir alan; fluent interface’in S-expression’larla pek iyi uyuşmadığı belirtiliyor
  • Bir yorum, SQL’in syntactic order’ı ile semantic order’ının uyumlu hale getirilmesini önererek Google Research’ün SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL yazısına bağlantı verdi
  • Buna karşılık, |> gibi bir biçimin ya da list comprehension’ı taklit eden bir yaklaşımın mümkün olabileceği; ancak nihai tasarımın küçük uygulamalar yapıp refactor ederek ilerleyen tekrarların ardından ortaya çıkacağı yanıtı verildi

MicroPython olasılığı ve sürüme tepkiler

  • CPython yerine MicroPython üzerinde çalışıp çalışamayacağına dair bir soru geldi
  • Yanıt, MicroPython’ın Python standart kütüphanesinin yalnızca küçük bir alt kümesini içerdiği için doğrudan çalışmasının zor göründüğü yönündeydi
  • Bununla birlikte CPython’da hy2py kullanarak Python koduna dönüştürüp, MicroPython’ın desteklediği yapılarla sınırlı kalınırsa çıktının çalıştırılabilmesi mümkün olabilir
  • Sürüm günü Hylang.org’u barındıran web sunucusunun günlük tekil ziyaretçi sayısında büyük bir artış görüldü

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-23
Hacker News yorumları

  • Hy’nin gerçekte Python’a nasıl dönüştürüldüğünü anlamak biraz zordu; başta derleniyor mu yoksa yorumlanıyor mu bundan da emin değildim.
    Sonunda Wikipedia’da “Hy, s-expression’ları Python’un soyut sözdizimi ağacına (AST) dönüştürerek Python’la etkileşime girecek şekilde tasarlanmış bir Lisp lehçesidir” açıklamasını buldum; GitHub koduna bakınca derleyici de Python ile yazılmış gibi görünüyor: https://github.com/hylang/hy/blob/master/hy/compiler.py
    Ana sitede de “Python’a gömülü bir Lisp lehçesi” yerine “Python AST’sine derlenen bir Lisp lehçesi” diye tanıtılsa daha net olur gibi. Lisp’i gömme yöntemi; bir yorumlayıcı eklemek, Python bytecode’una derlemek ya da Python kaynak koduna dönüştürmek gibi farklı biçimlerde olabilir ve her birinin ödünleşimleri oldukça farklıdır.

    • README/GitHub sayfasında zaten “Hy, Python’a gömülü bir Lisp lehçesidir; Lisp kodunu Python AST nesnelerine dönüştürdüğü için Python dünyasını Lisp biçiminde kullanabilirsiniz” deniyor.
    • Doğru, bu derleyici Python ile yazılmış ve Hy self-hosting değil.
      Genelde Hy kaynak kodu Python AST nesnelerine dönüşür, Python da bunları derleyip çalıştırır. Bununla birlikte Python AST nesnelerini Python kaynak metnine çevirmek de mümkün; Hy içinden Python kullanmak ya da Python içinden Hy kullanmak gibi birlikte çalışabilirlik de mümkün: https://hylang.org/hy/doc/v1.0.0/interop
    • “Gömülü” ifadesi, tek bir proje içinde Python ile Hy’nin karıştırılabilmesi ve çift yönlü çağrı yapılabilmesinden geliyor.
      Sonuçta hepsi Python bytecode’una dönüştüğü için iyi çalışıyor.
    • Hy’nin ilk sunumunda Lisp’in Python bytecode’una derlenerek gömüldüğü açıkça belirtiliyor.
      Aşağıdaki videoda 16:25 civarında görülebilir: https://m.youtube.com/watch?v=1vui-LupKJI

  • Hy yıllar içinde olgunlaştıkça, daha Lispy ve daha az Pythony olması için sözdizimsel şeker ve özel durumlar biriktirmek yerine, sanki Python özellik kümesinin ince bir sözdizimsel soyutlamasına daha yakın hale gelmiş.
    Yani başka yollarla taklit edilmesi zor olan çekirdeğe, özellikle de makrolara odaklanan bir yönelim. Yakın tarihli bir örnek olarak match, doğrudan Python’un yerel match’i ve Python 3.10 öncesi sürümler için bir polyfill de yok. Eskiden foo? özel bir durum olarak is_fooya mangle ediliyordu, ama kaldırıldı; hy.eval Python’un evaline daha yakın olacak şekilde yeniden düzenlendi; unless gibi olsa iyi olur türünden çekirdek dışı yardımcılar da sık sık Hyrule paketine taşınıyor.
    Başta sezgiye aykırı bir yön gibi gelmişti, ama Python’dan Hy’ye geçerken öğrenme eğrisini azaltması ve Python paketleriyle tutarlı biçimde etkileşmeyi kolaylaştırması büyük avantaj. Belki dil bakımını basitleştirme nedeni de vardır; hatırladığım kadarıyla leti düzgün yapmak için de dört kez falan deneme yapılmıştı.

    • Bir noktada, Python’la gereksiz farkları en aza indirmenin hem dilin bakımını hem kullanımını çok daha pürüzsüz hale getirdiğini fark ettim.
      Hy kodu yazarken de Hy belgelerinden çok Python ya da üçüncü taraf Python kütüphanelerinin belgelerine çok daha sık bakıyorum. Python’un iyileştirilebileceği çeşitli noktalar olduğunu düşünüyordum, ama eskiden Clojure’u düşünerek Truenun true olarak yazılmasına izin veren özellik sadece gereksiz karmaşıklıktı.

  • HYPE POST gerçekten çok iyiydi. Kurumsal yazılım işi yapan biri olarak hiciv duygusu çok başarılı.
    https://github.com/hylang/hy/discussions/2609

  • Sonunda çıktığına göre artık https://github.com/rcarmo/sushy’yi toparlayabilirim.
    Birkaç yıldır azar azar kurcalıyordum ama Hy’yi her yükselttiğimde sözdiziminin bir kısmı bozuluyor ya da bazı özellikler Hyrule paketine girip çıkıyordu; bu da zorlaştırıyordu.
    Bu arada Hy, iPad’deki https://holzschu.github.io/a-Shell_iOS içinde de oldukça iyi çalışıyor. Ancak vim/neovim’in sözdizimi vurgulamasının 0.29+ sürümlerini ve async’i yakalaması gerekiyor.
    Bu süre içinde Fennel ve Guile’ı da denedim ama Python kütüphanelerine ve ekosistemine erişebilmek daha iyi. Async sayesinde verimli API işleri de iyi yapılabiliyor; çeşitli Scheme’lerde HTTPS ile uğraşırken soket yeniden kullanımı ve header’lar üzerinde ince denetim hâlâ zahmetli olduğundan aiohttp kullanmanın çok daha iyi olduğunu düşünüyorum.

  • İlk zamanlardaki mütevazı başlangıç noktasıyla karşılaştırınca gerçekten çok yol katetmiş.
    Eskiden PyCon’da Hy’yi dünyaya ilk tanıtan lightning talk’u izlemiştim; çok geçmeden Paul ile tanışıp Hy’nin erken sürümlerine katkı vermeye başladım. Common Lisp tarzı kwargs, bazı iç kısımlar ve bir iki kütüphane üzerinde çalıştım.
    Oyunculuk faydalı; özellikle de tutkuyu sürdürmeye yardımcı oluyor. Hacker’ların hacker gibi davranabilmesi ve her şeyin iş olmak zorunda olmaması güzel. Birkaç yıldır içinde değilim ama projenin ilerlemeye devam ettiğini görmek hoşuma gidiyor; bence harika bir dönüm noktası.

  • Clojure hayranları için, bununla ilişkili olarak Python 3.8+ hedefleyen ve Clojure uyumluluğuna yakın bir Lisp lehçesi olan Basilisp de var.
    https://github.com/basilisp-lang/basilisp

  • Lisp değil ama Python’a transpile edilen işlevsel bir programlama dili olması açısından Coconut da ilginç: https://coconut-lang.org/
    Hy veya Coconut’u gerçekten kullanmış kişilerin deneyimlerini çok merak ediyorum

    • Birkaç yıl önce Coconut’u biraz denemiştim; o zamanki izlenimim, derleyicinin işe yarayacak kadar akıllı olmadığı yönündeydi
      Üretilen kodun en başına sabit kodlanmış bir sürü yardımcı fonksiyon ekleniyordu ve program, aynı şeyi düz Python ile yazdığıma kıyasla çok daha yavaştı
      Buna karşılık Hy, let kapsamının işlenmesinden kaynaklanan küçük bir dolaylılık katmanı ya da dönüş değeri etrafındaki farklar dışında, bir insanın elle yazabileceği Python koduna oldukça yakın kod üretiyor. Tabii Coconut’un üzerinden de uzun zaman geçtiği için iyileşmiş olabilir

  • Tebrikler. İki şeyi merak ediyorum: REPL güdümlü geliştirmeyi destekliyor mu; örneğin condition system veya breakloop gibi şeyler var mı?
    Bir de bağımsız çalıştırılabilir bir dağıtımı olup olmadığını merak ediyorum. Python dağıtımı başlı başına zahmetli olduğundan, ideal olarak tüm bağımlılıkları içeren tek bir Hy ikili dosyası dağıtabilmek güzel olurdu. Statik linkli de olabilir, geçici bir dizine açılan bir zip dosyası da

    • Bağımsız çalıştırılabilir bir dağıtım değil ama uvx hy@1.0.0 ile Hy REPL’e girebilirsiniz
      echo '(print "hi hn")' > hi.hy ardından uvx hy@1.0.0 hi.hy çalıştırırsanız "hi hn" çıktısını verir
      https://docs.astral.sh/uv/guides/tools/#running-tools
      Bu arada uv, Python sürümlerini kurup yönetmeyi de yapabiliyor
    • Breakloop’un ne olduğundan tam emin değilim. Hy, Python’ın istisna sistemini kullanır; bu da Common Lisp’in condition system’ından çok geleneksel bir istisna sistemine daha yakındır
      Bağımsız çalıştırılabilir bir dağıtımı yok
    • REPL belgelerinde bununla ilgili içerik var: https://hylang.org/hy/doc/v1.0.0/repl
      Kodu etkileşimli olarak hata ayıklamak için, hata ayıklamak istediğiniz koda (.run (hy.REPL :locals {#\* (globals) #\* (locals)})) ekleyebilirsiniz; Python’da ise import hy; hy.REPL(locals = {\*globals(), \*locals()}).run() şeklinde kullanabilirsiniz
      Ancak code.interact() gibi, REPL içinde yerel değişkenleri değiştirseniz de bunlar özgün kapsama geri yayılmaz
    • py2app ve dikkatli biraz hack’leme ile 2. maddeye yakın bir şeyi yapmışlığım var
      Her şeyi bytecode’a derledikten sonra Python’ın tek dosya dağıtım araçlarını kullanabilirsiniz
    • Hy, Python’ın desteklediği özellik kümesini aynen destekler. Geleneksel adım adım hata ayıklama veya post-mortem hata ayıklama için oldukça iyidir; CPython’da daha gelişmiş birçok dahili hook da vardır
      Ama condition system ya da handlers/restarts gibi şeyler yok

  • Daha az ciddi olan kısmı çok sevdim. Keşke daha fazla programlama projesi acayipliği benimsese
    Belki de Python geleneğini onurlandırmanın en iyi yolu budur

    • Birkaç yıl önce Hy’den ve belgelerden şakacı unsurların çoğunu kaldırmıştık. Dikkat dağıtıyordu ve gürültülü test hataları oluşturuyordu
      Yine de bir noktada fazla ileri gittiğimizi düşündüm; bu yüzden son zamanlarda şakacılığı biraz geri katmaya çalışıyoruz

  • Hy’yi ara sıra kullanıyordum ve bir transformer yapmayı denerken Hy ile yazdığım https://github.com/kunalb/orphism’i de yayımlamıştım
    Sanırım artık onu tekrar çıkarıp düzgünce çalıştırmanın zamanı geldi