3 poin oleh GN⁺ 2023-07-19 | 1 komentar | Bagikan ke WhatsApp
  • Hylo berorientasi pada pemrograman sistem dan generik yang aman berbasis semantik nilai, dan meskipun kompiler serta pustaka standarnya masih pada tahap awal, contoh dapat dijalankan di Compiler Explorer
  • Riset bahasa ini berfokus pada topik seperti perluasan inout projection pada subscript Swift, method bundles, konkurensi terstruktur, dan linked list ganda berbasis semantik nilai
  • Kompilernya menggunakan LLVM dan juga membahas kompilasi generik dengan coherence, caching·serialisasi status program, serta riset interoperabilitas dengan C
  • Lingkungan pengembangannya menyediakan ekstensi VSCode, kompiler dokumentasi, dan prototipe Language Server, serta mendukung SPM/CMake, Ninja/Xcode, Windows/Linux/macOS, dan image toolchain pengembangan Docker
  • Contohnya menunjukkan aturan kepemilikan·deinisialisasi secara eksplisit di level kode melalui projection yang aman dan sink method, memperlihatkan bagaimana bahasa sistem dapat memaksakan keamanan

Cakupan dan status saat ini Hylo

  • Kompiler dan pustaka standar Hylo masih berada pada tahap awal
  • Contoh kode Hylo tingkat lanjut dapat dijalankan di Compiler Explorer
  • Pada halaman awal juga tersedia tautan untuk mencoba Hylo di Compiler Explorer

Semantik nilai dan riset bahasa

Kompiler dan pustaka standar

  • Pekerjaan pada kompiler mencakup kompilasi berbasis LLVM, generik, penyimpanan status, dan interoperabilitas dengan C
  • Di sisi pustaka standar, saat ini dipublikasikan dokumentasi implementasi dan pekerjaan terkait algoritme koleksi

Pengalaman pengembang dan lingkungan build

  • Disediakan pula alat untuk editor, dokumentasi, dan language server
  • Lingkungan build dan pengembangan mendukung berbagai sistem operasi dan alur berbasis kontainer
    • Dukungan Development Containers mengurangi langkah awal penyiapan
    • Dukungan SPM/CMake, Ninja/Xcode, Windows/Linux/macOS
    • Plugin kompiler pembuat pengujian
    • Image Docker Hylo development toolchain yang sudah dibangun sebelumnya
    • Kompiler ditulis dengan Swift 6.2

Riset dan materi presentasi terkait Hylo

Contoh kode: projection aman dan pelepasan eksplisit

  • Contoh Subscripts - A Safe Projection Mechanism menunjukkan struktur di mana tipe Angle menyimpan nilai radians dan menyediakan properti degrees melalui blok let dan inout
    • let pada degrees mengonversi radians ke derajat lalu mengembalikannya
    • inout mengekspos nilai derajat sementara d dengan yield &d, lalu mengonversi nilai yang telah diubah kembali ke radians dan menerapkannya ke self.radians
    • main memperoleh projection dengan inout d = &a.degrees, mengubah d menjadi 0.0, lalu memeriksa a.radians == 0.0
  • Contoh Sink Methods - Capability for Deinitializing memperlihatkan struktur di mana tipe Computer menyediakan shutdown() sebagai sink method
    • shutdown() mencetak isi memori lalu melakukan sink pada self.ram
    • test1 membuat Computer tetapi tidak memanggil shutdown sehingga muncul Cannot deinit computer
    • test2 hanya memanggil shutdown di dalam if random_bool(), sehingga pada jalur saat tidak masuk ke if muncul Cannot deinit computer
    • test3 memanggil shutdown di dalam while, sehingga setelah iterasi pertama muncul masalah penggunaan objek yang sudah consumed, dan pada jalur saat tidak masuk ke while tetap tersisa kondisi tidak bisa dideinit
  • Contoh tambahan dapat dilihat di compiler test suite

1 komentar

 
GN⁺ 2023-07-19
Komentar Hacker News
  • Sebagai penerus C++, mungkin Val malah lebih menjanjikan daripada CppFront karya Herb Sutter yang sangat bagus. Saya baru melihat dua presentasi di bawah ini, tetapi tampaknya poin intinya adalah kompilasi statis, tipe statis, interoperabilitas C++, keamanan memori, keamanan tipe, dan tidak adanya data race
    Saat menjelaskannya, saya biasanya mengatakan, “Kalau memulai proyek C++ baru dan menganggap performa bukan perhatian utama, bukankah akan lebih baik jika semuanya diteruskan sebagai nilai dan dikembalikan sebagai nilai tanpa pointer atau referensi, sehingga tidak perlu khawatir soal efek samping atau data race?” Yang menarik dari Val adalah, meski pointer dan referensi dihapus dari bahasanya, kompiler secara internal tetap menerapkan pengoperan const reference dan return value optimization sehingga semantik yang diinginkan dan performa bisa dipertahankan sekaligus
    Val: A Safe Language to Interoperate with C++ - Dimitri Racordon - CppCon 2022 https://www.youtube.com/watch?v=ws-Z8xKbP4w
    https://cppcast.com/val-and-mutable-value-semantics/

    • Sebaiknya dengarkan dua episode terbaru ADSP Podcast yang membahas Val oleh Sean Parent. Adobe Research Labs mendukung pengembangannya dengan cukup serius
      https://adspthepodcast.com/
    • “Interoperabilitas dengan C++” terdengar meragukan. Sulit percaya bahwa bahasa lain bisa benar-benar berinteroperasi dengan C++, padahal antar kompiler C++ saja kompatibilitas binernya bisa rusak, bahkan kadang berbeda antar versi dari kompiler yang sama
    • Ini terdengar seperti desain yang terlalu banyak bergantung pada kompiler. Saya khawatir satu perubahan kecil bisa merusak optimisasi di kode yang jauh dan akhirnya menghancurkan performa
    • Jika “sepanjang hari meneruskan sebagai nilai dan mengembalikan sebagai nilai”, maka akan makin sulit untuk mengubah atau menyimpan referensi secara efisien di dalam struct. Jika program membutuhkan struktur data yang sedikit saja tidak standar atau kompleks, ini tampak seperti batasan yang fatal. Tentu saja, mengingat betapa sulitnya mengimplementasikan struktur data semacam itu dengan benar, ini justru bisa dianggap sebagai kelebihan
    • Selama beberapa tahun saya benar-benar menulis program PHP dengan cara seperti ini, terus-menerus meneruskan array tanpa terlalu memikirkannya
      Saya rasa interpreter PHP cukup pintar untuk benar-benar memakai copy-on-write, tetapi saya belum pernah memprofilkannya sendiri. Meski begitu, walaupun pada setiap page load saya melakukan pemrosesan data yang cukup rumit, parsing DSL per karakter, pembuatan SQL dinamis, dan membentuk hasil ke struktur arbitrer, saya tidak pernah merasakan masalah performa
      Pada era PHP 4, objek juga berperilaku seperti nilai yang disimpan di variabel, dan ketika kemudian variabel objek diubah menjadi semantik referensi, menurut saya itu kesempatan yang terlewat karena mereka tidak menjadikan “nilai, referensi variabel, dan pointer ke nilai” sebagai properti variabel yang ortogonal terhadap tipe penyimpanan
      $a = $b; // salin nilai $b ke $a
      $a = &$b; // $a dan $b sekarang adalah variabel yang sama
      $a = *$b; // $a menunjuk ke objek yang sama dengan $b, tetapi tidak seperti $a = &$b, variabelnya sendiri tidak saling terikat
  • Senang juga melihat begitu banyak bahasa zero-cost abstraction bermunculan, tetapi di sisi lain saya berharap para programmer sistem segera memilih satu pemenang. Saya tidak ingin komunitas programmer sistem yang sudah kecil ini makin terpecah ke Rust, Zig, Val, dan sebagainya, dan berharap perang bahasa sistem cepat selesai

    • Mungkin justru kita terlalu cepat memilih satu pemenang, sehingga inovasi di bidang ini terlalu lama kurang berkembang. Saya menyambut perang ini
    • Pada titik ini, saya melihat Rust sebagai pemenangnya. Karena ia sudah melewati hambatan besar untuk benar-benar masuk ke kernel Linux dan Windows. Dalam arti itu, tampaknya kini tidak banyak ruang tersisa bagi bahasa sistem baru untuk masuk
    • Rasanya tidak akan begitu. Justru itu makin memperkuat alasan untuk memperluas dukungan wasm + wasi di mana-mana
  • Alur perasaan saya saat pertama kali mengenal Val hari ini kurang lebih begini. “Oh, bahasa sistem baru. Mungkin bukan apa-apa, tapi mari lihat. Dokumentasinya lumayan. Ide-ide terkait ownership cukup matang dan sintaksnya juga masuk akal. Tapi apakah cukup berbeda sampai punya alasan eksis sendiri? Siapa yang membuatnya?”
    Lalu saya melihat Dave Abrahams yang sedang mengerjakannya, dan ketertarikan saya pun meningkat. Saya pernah bertemu dengannya di Apple dan juga ingat presentasi Crusty tentang Swift[1]. Saya suka pandangannya yang tegas, tetapi Apple belakangan menurunkan video itu dengan alasan ada saran lama di dalamnya. Sekarang ternyata dia ada di Adobe, jadi saya sempat bertanya-tanya apakah ini bahasa milik Adobe
    Kesimpulannya, ini layak dipantau, dan setelah menonton presentasi yang ditautkan, saya memilih menunggu sambil melihat perkembangannya
    [1] Saya menemukan presentasi Crusty itu: "I don't do Object Oriented!" https://www.youtube.com/watch?v=p3zo4ptMBiQ

    • David Abrahams sudah menjadi kontributor yang sangat penting untuk Boost bahkan sebelum berada di Apple, juga anggota komite C++ dan pendukung kuat generic programming ala Stepanov. Jadi tidak mengejutkan jika ia bergabung dengan proyek Val
  • Sebagai pengembang compiler, saya kaget melihat issue-issue berikut
    https://github.com/val-lang/val/issues/758
    https://github.com/val-lang/val/issues/711
    Ini memberi kesan bahwa kondisi implementasinya kurang baik. Seharusnya mereka melakukan self-hosting secepat mungkin, dan dengan begitu akan menemukan lebih banyak bug mendasar seperti ini. Meski begitu, bintangnya sudah lebih dari 500

    • Dari sudut pandang pengembang compiler lain, hanya sedikit kesalahan yang sama merugikannya dengan self-hosting yang terlalu dini. Meski bahasa itu bisa memberi manfaat bersih untuk program kecil hingga menengah, agar cocok untuk proyek besar seperti compiler dan dilengkapi tooling, dibutuhkan waktu jauh lebih lama. Syukurlah mereka tidak terburu-buru
    • Kalau bug seperti itu ada di compiler yang sudah dipakai dalam operasional, tentu mengkhawatirkan, tetapi untuk compiler dari bahasa yang masih sedang didefinisikan, itu tidak terlalu bermasalah. Jika membandingkan Rust 1.0 dan 1.71, kita bisa melihat betapa besarnya jarak antara “rilis stabil pertama” dan “compiler dari bahasa stabil yang banyak dipakai di dunia nyata”
      Self-hosting juga bukan segalanya. Itu lebih merupakan tonggak simbolis; ketika tercapai memang patut dirayakan, tetapi saya rasa itu bukan sesuatu yang layak dijadikan kelemahan bahasa tersebut sampai jauh di tahap akhir siklus pengembangan
    • Swift sendiri juga masih belum self-hosting, padahal sedang menuju rilis versi 6. Saya bukan pengembang compiler, tetapi kesimpulan diskusi di komunitas Swift soal topik ini tampaknya masih bahwa itu belum sepadan untuk dilakukan
  • Saya sudah lama menunda “bermain-main dengan Val”, dan akhirnya mencobanya hari ini, tetapi meski commit-nya sudah lebih dari 4.000, kondisinya masih jauh dari bisa dipakai. Sebagian besar contoh di tur bahasa tidak bisa dikompilasi, dan contoh yang terlihat sederhana pun gagal
    Carbon juga belum benar-benar merilis sesuatu yang layak, sementara Sean Baxter membuat banyak kemajuan di compiler Circle dan sudah mengimplementasikan banyak bagian bagus dari Carbon. Jika itu masih sulit disebut sebagai sebuah bahasa, maka sulit juga menyebutnya sebagai penerus

  • Sekarang ada V, Val, Vala, dan Vale. Apakah ada bahasa lain yang saya lupa?

    • Ada juga VAL. Itu salah satu bahasa dari era 80-an, dan melalui SISAL memberi pengaruh pada Haskell. Hanya saja, sepertinya tidak banyak orang di luar komunitas bahasa paralel yang mengenal VAL itu
    • Nama yang mirip justru bisa menguntungkan. Orang yang belajar bahasa seperti ini kemungkinan besar sedang mencari “hal baru yang lagi panas”, dan karena itu mereka bisa sekalian mengetahui bahasa lain dengan nama serupa lalu ikut mencarinya. JavaScript juga begitu, dan hasilnya tidak buruk
    • Saya kira ini benar-benar Vale. Benturan nama seperti ini cukup disayangkan
    • Sebagai tambahan, V juga disebut Vlang, dan Vale dulu juga pernah disebut Vlang
  • Ini memang komentar yang selalu muncul, tetapi satu-satunya hal yang tidak saya suka dari Val adalah bahwa Vale dan V juga merupakan bahasa sistem baru. Karena namanya, ketiganya terlalu mudah tertukar

    • Ada juga Vala. Ranahnya memang agak berbeda, tetapi ada satu lagi bahasa dengan nama yang mirip
    • Saya bahkan harus membuka tautannya dulu untuk memastikan apakah ini bahasa projection atau bahasa region
    • Ada juga VAL: Variable Assembly Language https://en.m.wikipedia.org/wiki/Variable_Assembly_Language
  • Ada tulisan terkait. Apakah ada lagi?
    Val, a new programing language inspired by Swift and Rust - https://news.ycombinator.com/item?id=31788527 - Juni 2022, 19 komentar

  • Saya sempat menelusuri makalah “mutable value semantics”, dan penasaran apakah saya benar memahami bahwa para penulis mengusulkan untuk mengganti reference dan pointer dengan a) sebagian indireksi dan pemeriksaan runtime melalui struct bersarang dan Any, serta b) indeks array
    Bagian yang menonjol adalah kalimat, “Wajar jika orang bertanya bagaimana tipe nilai yang dapat diubah bisa merepresentasikan struktur data self-reference seperti doubly linked list atau graf berarah. Faktanya, graf arbitrer dapat direpresentasikan sebagai adjacency list…” Saya tidak begitu melihat cara yang masuk akal untuk mengimplementasikan doubly linked list tanpa pada dasarnya membuat ulang memory heap dan semacam garbage collection di dalam implementasinya
    Selain itu, saya juga menemukan diskusi di https://github.com/orgs/val-lang/discussions/736, dan sepertinya akan muncul jalan keluar seperti unsafe di Rust. Jika begitu, semua masalah memang terselesaikan, tetapi pertanyaan “apakah subset aman dari Val saja cukup untuk membangun aplikasi praktis” tampaknya akan tetap menjadi bahan perdebatan untuk waktu yang lama

    • Jika memakai array dan menggunakan indeks array alih-alih pointer, kita memang pada praktiknya bisa membuat ulang memori
      Alasan pendekatan itu tidak sebodoh yang terlihat adalah karena indeks-indeks ini terikat pada struktur data tertentu, misalnya doubly linked list atau graf, sehingga tidak mudah dimanipulasi untuk mengakses bagian lain dari program. Ini juga berlaku jika compiler memeriksanya, termasuk terhadap upaya untuk merusak program
  • Saya tidak paham bagaimana harus membaca penjelasan pada contoh di situs resminya. Tertulis, “Tidak ada alokasi yang tidak perlu. Hasil longer_of adalah projection dari argumen yang lebih panjang, sehingga jika emphasize mengubah z, perubahan itu terjadi langsung pada nilai y. Nilai tersebut tidak disalin maupun dipindahkan, tetapi juga tidak diteruskan ke emphasize sebagai referensi.”
    Dalam situasi ketika argumen string diteruskan ke fungsi lalu sebuah karakter ditambahkan, string yang sudah ada semestinya punya panjang awal serta lokasi dan ukuran tertentu di stack, jadi saya tidak mengerti bagaimana ini bisa dilakukan tanpa salinan baru dari y. Apakah string diberi padding ekstra di bagian akhir untuk berjaga-jaga jika seseorang menambahkan sesuatu? Jika begitu, padding-nya seberapa banyak, dan mengapa itu tidak malah jadi kurang efisien secara keseluruhan?

    • Awalan empat spasi itu bukan untuk kutipan, melainkan untuk blok kode/teks monospace. Di HN biasanya orang memakai konvensi > untuk mengutip, dan itu bekerja baik meski parser tidak memberi perlakuan khusus
    • Nilai yang immutable tidak harus selalu berada di stack
      Namun saya punya pertanyaan serupa. Bagaimana jika yang diubah adalah string 1GB? Apakah ini copy-on-write?
      Dalam 99% kasus mungkin akan hilang karena optimasi, tetapi terasa seperti 1% sisanya bisa menimbulkan penurunan performa yang sangat sulit ditemukan
    • Beberapa hari kemudian, kalau mencoba menjawab sendiri, sepertinya ini mungkin jika nama variabel yang berubah diam-diam di-shadowing di stack dengan nilai baru yang lebih panjang. Mungkin ini juga yang dimaksud dengan “projection”. Dalam kasus ini stack sudah dialokasikan, jadi tidak ada alokasi baru. Saya bukan ahli bahasa atau compiler, jadi mungkin istilah ini memang sudah umum dikenal di bidang itu
    • Ada penjelasan lebih lanjut di bawah. longer_of bukan fungsi melainkan subscript, dan subscript tidak mengembalikan nilai, melainkan mem-projection nilai dan memberi pemanggil hak akses baca/tulis sementara
      Saya tetap tidak begitu paham bagaimana ini tidak dihitung sebagai perpindahan. Untuk string, mungkin seperti Rust, nilainya bisa ditempatkan di heap agar ukuran variabel tetap dimungkinkan