3 pontos por GN⁺ 2024-09-23 | 1 comentários | Compartilhar no WhatsApp
  • Hy 1.0.0, um dialeto Lisp embarcado em Python, foi lançado após cerca de 12 anos de desenvolvimento intermitente e uso no mundo real
  • No Hy 1.x, quebras de compatibilidade em elementos documentados da linguagem passarão a resultar em aumento da versão major, com exceção da descontinuação de suporte a versões de Python que os desenvolvedores do CPython já não suportam mais
  • O foco daqui para frente será em novas correções de bugs, adição de compatibilidade com novas versões do Python e suporte a novos recursos do Python de forma que o código existente em Hy 1.x.y não quebre
  • Um usuário deu como exemplo reduzir declarações do SQLAlchemy ORM para a forma defmodel com macros de Hy, explicando que, por serem expansões de macro, não há custo adicional em tempo de execução
  • Parece difícil rodar diretamente sobre MicroPython por causa do subconjunto da biblioteca padrão, mas pode ser possível converter com hy2py no CPython e depois usar apenas construções compatíveis com o MicroPython

Lançamento do Hy 1.0.0

  • Hy 1.0.0 foi lançado
    • Hy é um dialeto Lisp embarcado em Python
    • Houve quase 12 anos de desenvolvimento intermitente e muito uso real até este lançamento
  • A apresentação e a documentação estão disponíveis em Hylang.org
  • O histórico de versões pode ser consultado no arquivo NEWS file
  • Também foi vinculado um texto de lançamento menos sério, o HYPE POST

Política de compatibilidade da série 1.x

  • Daqui em diante, breaking changes nas partes documentadas da linguagem aumentarão o número da versão major
  • A exceção é quando o suporte a versões de Python que os desenvolvedores do CPython já não suportam mais for descontinuado
  • Foi apresentada a intenção de evitar que aumentos de versão major aconteçam com frequência
  • O foco do trabalho daqui para frente será em:
    • correções de bugs recém-descobertos
    • adicionar compatibilidade com novas versões do Python
    • oferecer suporte a novos recursos do Python sem quebrar código que funciona em versões anteriores do Hy 1.x.y

Exemplo de uso de macros Hy: DSL de modelos para SQLAlchemy

  • Um usuário explicou que está criando um ORM e um framework web assíncrono com Hy, ambos aproveitando bibliotecas existentes e compostos em sua maior parte por macros
  • Foi mostrado um exemplo que expressa de forma mais curta, com a macro defmodel do Hy, a declaração de modelos do SQLAlchemy ORM Quick Start Guide
    • Os modelos User e Address, além da declaração de relações, são escritos em forma de S-expression do Hy
    • defmodel é uma macro que se expande para código SQLAlchemy, portanto não há custo adicional em tempo de execução
  • O usuário afirmou que a estabilização do interior do Hy e da sua API é necessária para esse tipo de trabalho

Discussão sobre declaração de relações e DSL de consultas

  • O exemplo de defmodel se expande para vários padrões de relacionamento
    • one-to-one: 1->1
    • many-to-many: *->* e deflinktable
    • campos de timestamp: :timestamp-create, :timestamp-update
  • Após a declaração, os objetos são objetos ORM normais do SQLAlchemy 2.0, então é possível usar Hy apenas na parte da DSL de esquema do banco de dados e escrever o restante em Python
  • A DSL de consultas ainda está em andamento, e foi mencionado que uma fluent interface não combina bem com S-expressions
  • Um comentário sugeriu criar algo em que a ordem sintática e a ordem semântica do SQL coincidam, e vinculou o artigo do Google Research SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL
  • Em resposta, foi dito que algo como |> ou uma abordagem que imite list comprehensions pode ser possível, mas que o desenho final deve surgir depois de repetir o ciclo de criar pequenos apps e refatorar

Possibilidade com MicroPython e reação ao lançamento

  • Surgiu a pergunta se ele poderia rodar sobre MicroPython em vez de CPython
  • A resposta foi que isso parece difícil diretamente, porque o MicroPython inclui apenas um pequeno subconjunto da biblioteca padrão do Python
  • Ainda assim, depois de converter para código Python com hy2py no CPython e limitar-se a construções suportadas pelo MicroPython, pode ser possível executar o resultado
  • Também foi confirmado que, no dia do lançamento, o número diário de visitantes únicos do servidor web que hospeda o Hylang.org aumentou bastante

1 comentários

 
GN⁺ 2024-09-23
Comentários do Hacker News
  • Foi um pouco difícil entender como o Hy é realmente convertido para Python, e no começo eu também não tinha certeza se ele era compilado ou interpretado.
    No fim, encontrei na Wikipedia a explicação de que “Hy é um dialeto de Lisp projetado para interagir com Python convertendo s-expressions para a árvore de sintaxe abstrata (AST) do Python”, e olhando o código no GitHub parece que o compilador também é escrito em Python: https://github.com/hylang/hy/blob/master/hy/compiler.py
    Acho que no site principal ficaria mais claro apresentá-lo como “um dialeto de Lisp compilado para a AST do Python” em vez de “um dialeto de Lisp embutido em Python”. Há várias formas de embutir Lisp, como acoplar um interpretador, compilar para bytecode Python ou converter para código-fonte Python, e os trade-offs de cada uma são bem diferentes

    • O README/página do GitHub já diz que “Hy é um dialeto de Lisp embutido em Python e, como converte código Lisp em objetos AST do Python, permite usar o mundo Python em forma de Lisp”
    • Exato, esse compilador é escrito em Python, e o Hy não é self-hosting.
      Normalmente, o código-fonte Hy vira objetos AST do Python, e o Python os compila e executa. Dito isso, também é possível transformar objetos AST do Python em texto-fonte Python, além de haver interoperabilidade para usar Python a partir do Hy ou Hy a partir do Python: https://hylang.org/hy/doc/v1.0.0/interop
    • A expressão “embutido” vem do fato de que, dentro de um projeto, é possível misturar Python e Hy e fazer chamadas nos dois sentidos.
      No fim, tudo vira bytecode Python, então funciona bem
    • Na apresentação original do Hy fica claro que ele é embutido compilando Lisp para bytecode Python.
      Dá para ver por volta de 16:25 no vídeo abaixo: https://m.youtube.com/watch?v=1vui-LupKJI
  • À medida que o Hy amadureceu ao longo dos anos, em vez de acumular açúcar sintático e casos especiais para ficar mais Lispy e menos Pythony, parece que ele acabou se aproximando de uma abstração sintática fina sobre o conjunto de recursos do Python.
    Ou seja, a direção é focar no núcleo difícil de imitar de outras formas, especialmente macros. Um exemplo recente é que match é simplesmente o match nativo do Python, sem polyfill para versões anteriores ao Python 3.10. Antigamente, foo? era tratado como um caso especial e sofria name mangling para is_foo, mas isso foi removido; hy.eval foi reformulado para ficar mais próximo do eval do Python; e utilitários convenientes, mas não essenciais, como unless, frequentemente são empurrados para o pacote Hyrule.
    No começo isso parecia contraintuitivo, mas a grande vantagem é reduzir a curva de aprendizado ao passar de Python para Hy e facilitar a interação consistente com pacotes Python. Talvez também haja o motivo de simplificar a manutenção da linguagem; se bem me lembro, foram umas quatro tentativas até fazer let direito

    • Em algum momento, percebi que minimizar diferenças desnecessárias em relação ao Python torna tanto a manutenção quanto o uso da linguagem muito mais tranquilos.
      Mesmo ao escrever código Hy, acabo consultando a documentação do Python ou de bibliotecas Python de terceiros com muito mais frequência do que a documentação do Hy. Eu sentia que havia várias áreas em que o Python poderia ser melhorado, mas recursos antigos como permitir escrever True como true, por consideração ao Clojure, eram apenas complexidade desnecessária
  • O HYPE POST ficou realmente ótimo. Para quem trabalha com software corporativo, ele tem um senso de sátira excelente.
    https://github.com/hylang/hy/discussions/2609

  • Agora que finalmente saiu, acho que posso arrumar o https://github.com/rcarmo/sushy.
    Venho mexendo nele aos poucos há alguns anos, mas toda vez que eu atualizava o Hy alguma parte da sintaxe quebrava, ou recursos entravam e saíam do pacote Hyrule, o que era problemático.
    A propósito, o Hy também funciona bastante bem dentro do https://holzschu.github.io/a-Shell_iOS no iPad. Porém, o destaque de sintaxe do vim/neovim ainda precisa acompanhar os lançamentos 0.29+ e o assíncrono.
    Nesse meio-tempo também experimentei Fennel e Guile, mas prefiro ter acesso às bibliotecas e ao ecossistema do Python. Graças ao assíncrono, também dá para fazer trabalho eficiente com APIs; em vários Schemes, lidar com HTTPS mantendo controle fino sobre reutilização de sockets e headers ainda é trabalhoso, então acho muito melhor usar aiohttp

  • Ele avançou muito em comparação com o começo modesto dos primeiros dias.
    Vi a lightning talk na PyCon que apresentou o Hy ao mundo pela primeira vez e, não muito depois, conheci o Paul e comecei a contribuir com versões iniciais do Hy. Cuidei de kwargs no estilo Common Lisp, de algumas partes internas e de uma ou duas bibliotecas.
    Espírito brincalhão é útil, especialmente para manter o entusiasmo. É bom que hackers possam agir como hackers e que nem tudo precise ser negócio. Não participo há anos, mas fico feliz em ver o projeto continuar avançando, e isso me parece um excelente marco

  • Para fãs de Clojure, também existe o Basilisp, um dialeto de Lisp relacionado, próximo da compatibilidade com Clojure e voltado para Python 3.8+.
    https://github.com/basilisp-lang/basilisp

  • Não é Lisp, mas, do ponto de vista de uma linguagem de programação funcional que é transpilada para Python, Coconut também é interessante: https://coconut-lang.org/
    Tenho muita curiosidade de ouvir relatos de experiência de pessoas que já usaram Hy ou Coconut de verdade

    • Usei um pouco de Coconut alguns anos atrás, e minha impressão na época foi que o compilador não era inteligente o suficiente para ser útil
      No topo do código gerado vinham anexadas várias funções auxiliares hardcoded, e o programa ficava muito mais lento do que a mesma coisa escrita em Python comum
      Em contrapartida, Hy gera código bastante próximo de um Python que uma pessoa escreveria à mão, tirando uma leve camada de indireção decorrente do tratamento de escopo de let e algumas diferenças em torno de valores de retorno. Mas já faz bastante tempo no caso do Coconut, então é possível que tenha melhorado
  • Parabéns. Tenho duas curiosidades: se há suporte a desenvolvimento guiado por REPL, por exemplo algo como um sistema de condições ou breakloop
    Também queria saber se existe uma distribuição standalone. Como distribuir Python em si é trabalhoso, idealmente seria bom poder distribuir um único binário Hy com todas as dependências incluídas. Pode ser linkagem estática ou um arquivo zip que se descompacta em um diretório temporário

    • Não é uma distribuição standalone, mas dá para entrar no REPL do Hy com uvx hy@1.0.0
      Se você executar echo '(print "hi hn")' > hi.hy e depois uvx hy@1.0.0 hi.hy, ele imprime "hi hn"
      https://docs.astral.sh/uv/guides/tools/#running-tools
      A propósito, o uv também consegue instalar e gerenciar versões do Python
    • Não tenho certeza do que é breakloop. Hy usa o sistema de exceções do Python, que é mais próximo de um sistema tradicional de exceções do que do sistema de condições do Common Lisp
      Não há uma distribuição standalone
    • Há conteúdo relacionado na documentação do REPL: https://hylang.org/hy/doc/v1.0.0/repl
      Para depurar código interativamente, você pode colocar (.run (hy.REPL :locals {#\* (globals) #\* (locals)})) no código que quer depurar e, em Python, usar algo como import hy; hy.REPL(locals = {\*globals(), \*locals()}).run()
      Porém, assim como com code.interact(), se você alterar variáveis locais dentro do REPL, isso não se propaga de volta para o escopo original
    • Já fiz algo próximo do item 2 com py2app e algumas gambiarras cuidadosas
      Você pode compilar tudo para bytecode e depois usar uma ferramenta de distribuição em arquivo único do Python
    • Hy oferece exatamente o conjunto de recursos suportado pelo Python. Ele é bem bom para depuração tradicional passo a passo ou depuração post-mortem, e o CPython também tem muitos hooks internos mais avançados
      Mas não há nada como um sistema de condições nem handlers/restarts
  • Gostei muito da parte menos séria. Gostaria que mais projetos de programação abraçassem a excentricidade
    Talvez essa seja a melhor forma de honrar a tradição do Python

    • Alguns anos atrás, removemos muitos elementos brincalhões do Hy e da documentação. Eles distraíam e geravam falhas de teste barulhentas
      Mas em algum momento comecei a achar que tínhamos ido longe demais, então recentemente estamos tentando recolocar um pouco dessa brincadeira
  • Venho usando Hy de forma intermitente e, ao tentar criar um transformer, também publiquei https://github.com/kunalb/orphism, escrito em Hy
    Acho que agora é hora de tirá-lo da gaveta de novo e tentar fazê-lo rodar direito