Desain Bahasa Pemrograman Mengeksplorasi Penggantian Logika Boolean dengan Tipe Optional

Sebuah eksplorasi menarik dalam desain bahasa pemrograman telah muncul, mengusulkan perubahan radikal dari logika boolean tradisional dengan mengganti nilai true/false menggunakan tipe optional. Konsep ini menantang asumsi fundamental tentang bagaimana bahasa pemrograman menangani logika kondisional dan alur kontrol.

Mengganti Boolean dengan Options dan Results

Ide inti berpusat pada penghapusan tipe boolean sepenuhnya, sebagai gantinya menggunakan tipe Option<()> atau Result<(), ()> untuk merepresentasikan apa yang secara tradisional kita anggap sebagai true dan false. Dalam sistem ini, true menjadi Ok(unit) dan false menjadi Err(unit). Pendekatan ini mengubah pernyataan kondisional dari evaluasi boolean menjadi operasi yang berhasil dengan nilai atau gagal dengan status error.

Respons komunitas beragam namun penuh keingintahuan intelektual. Banyak developer mengenali kesamaan dengan konsep pemrograman fungsional yang sudah ada, khususnya monad dalam Haskell. Seorang komentator mencatat kemiripan dengan sistem truthy/falsy JavaScript, meskipun proposal ini mengambil pendekatan yang lebih terstruktur melalui type safety.

Ekuivalensi Tipe dalam Sistem yang Diusulkan:

• bool → Option<()>
• true → Ok(unit) atau Some(())
• false → Err(unit) atau None
• tipe test → Result<(), ()> (alias: ??)

Membayangkan Ulang Operator Alur Kontrol

Dalam sistem ini, pernyataan if tradisional menjadi operator biner yang mengembalikan nilai optional. Pernyataan if tanpa klausa else akan mengembalikan Option<T>, sementara konstruksi if-else akan mengembalikan Option<T | U>. Operator and dan or juga akan bekerja pada tipe optional, menciptakan sistem yang lebih seragam di mana semua logika kondisional beroperasi pada struktur tipe yang sama.

Beberapa anggota komunitas menunjukkan koneksi dengan bahasa dan paradigma yang sudah ada. Eksekusi goal-directed Icon dan berbagai dialek Lisp sudah mengimplementasikan konsep serupa, di mana nil berfungsi sebagai satu-satunya nilai falsy dan yang lainnya dianggap truthy.

Perilaku Operator dengan Tipe Opsional:

• None and X → None
• Some(x) and Y → Some(y)
• None or X → X
• Some(x) or Y → Some(x)
• not Err → Ok
• not Ok → Err

Implikasi Praktis dan Konteks Historis

Diskusi mengungkapkan bahwa konsep ini tidak sepenuhnya baru. Banyak bahasa pemrograman lama, termasuk dialek BASIC awal dan C sebelum C99, tidak memiliki tipe boolean khusus. Bahasa assembly biasanya menggunakan perbandingan integer dan register flag daripada nilai boolean eksplisit.

Everything old is new again

Manfaat praktis meliputi penghapusan kebutuhan untuk wrapping Some() eksplisit dalam banyak kasus dan mengurangi pernyataan early return dalam fungsi. Namun, kritikus khawatir tentang kompleksitas yang diperkenalkan, terutama ketika berurusan dengan format data eksternal seperti JSON yang membedakan antara false, null, dan nilai yang hilang.

Bahasa Pemrograman Historis Tanpa Boolean Khusus:

• Sebagian besar dialek BASIC
• C sebelum C99 (menggunakan integer)
• Sebagian besar bahasa assembly
• FORTH (boolean didefinisikan sebagai kata)
• Emacs Lisp (hanya nil yang bernilai salah)
• Ruby (hanya false dan nil yang bernilai salah)

Skeptisisme Komunitas dan Tantangan Teknis

Meskipun keanggunan teoretis menarik bagi banyak developer, kekhawatiran praktis mendominasi diskusi. Sistem ini masih memerlukan beberapa bentuk pengambilan keputusan biner di tingkat mesin, membuat beberapa orang berargumen bahwa ini hanya menyamarkan boolean daripada menghilangkannya. Pemrograman GPU shader dan teknik branchless programming sudah mendemonstrasikan pendekatan alternatif untuk logika kondisional tanpa tipe boolean tradisional.

Proposal ini menghadapi tantangan dalam skenario dunia nyata di mana nilai boolean eksplisit diperlukan, seperti respons API atau file konfigurasi. Kritikus menyarankan bahwa pengguna pasti akan membuat tipe wrapper yang berperilaku seperti boolean, berpotensi membuat sistem lebih kompleks daripada lebih sederhana.

Meskipun ada kekhawatiran ini, eksplorasi ini menawarkan wawasan berharga tentang prinsip desain bahasa dan menantang developer untuk mempertimbangkan kembali konsep pemrograman fundamental. Baik praktis atau tidak, eksperimen pemikiran seperti ini mendorong batas-batas bagaimana kita berpikir tentang sistem tipe dan alur kontrol dalam bahasa pemrograman.

Referensi: Imagining a Language without Booleans