Mengapa bahasa tidak termasuk implikasi sebagai operator logis?

Ini mungkin pertanyaan yang aneh, tetapi mengapa tidak ada implikasi sebagai operator logis dalam banyak bahasa (Java, C, C ++, Python Haskell - meskipun sebagai yang terakhir ada pengguna yang mendefinisikan operatornya sepele untuk menambahkannya)? Saya menemukan implikasi logis yang jauh lebih jelas untuk ditulis (terutama dalam menegaskan atau menyatakan seperti pernyataan) kemudian negasi dengan atau:

encrypt(buf, key, mode, iv = null) {
    assert (mode != ECB --> iv != null);
    assert (mode == ECB || iv != null);
    assert (implies(mode != ECB, iv != null)); // User-defined function
}

Mungkin bermanfaat terkadang, tidak diragukan. Beberapa poin menentang operator semacam itu:

• Karakter -dan >bernilai, baik dalam isolasi dan gabungan. Banyak bahasa sudah menggunakannya untuk maksud lain. (Dan banyak yang tidak dapat menggunakan set karakter unicode untuk sintaks mereka.)
• Implikasi sangat kontra-intuitif, bahkan untuk orang yang berpikiran logis seperti programmer. Fakta bahwa tiga dari empat entri tabel kebenaran truemengejutkan banyak orang.
• Semua operator logis lainnya simetris, yang akan membuat ->pengecualian untuk ortogonalitas.
• Pada saat yang sama, ada solusi yang mudah: gunakan operator !dan ||.
• Implikasi digunakan jauh lebih jarang daripada logis and/ or.

Ini mungkin sebabnya operator jarang hari ini. Tentu saja itu bisa menjadi lebih umum, karena bahasa dinamis baru menggunakan Unicode untuk semuanya dan operator yang berlebihan menjadi lebih modis lagi.

Saya percaya jawabannya terletak pada dasar matematika . Implikasi biasanya dianggap dan didefinisikan sebagai operasi aljabar boolean yang diturunkan, bukan elementer. Bahasa pemrograman mengikuti konvensi ini.

Ini adalah Proposisi I Bab II dari Investigasi Hukum Berpikir George Boole (1854) :

Semua operasi Bahasa, sebagai instrumen penalaran, dapat dilakukan oleh sistem tanda yang terdiri dari unsur-unsur berikut, yaitu .:

1 Simbol literal, seperti x, y, & c., Mewakili hal-hal sebagai subjek dari konsepsi kami.

Ke-2 Tanda-tanda operasi, sebagai +, -, ×, berdiri untuk operasi-operasi pikiran dengan mana konsepsi hal-hal digabungkan atau diselesaikan sehingga membentuk konsepsi baru yang melibatkan unsur-unsur yang sama.

Ke-3 Tanda identitas, =.

Dan simbol-simbol Logika ini dalam penggunaannya tunduk pada hukum yang pasti, sebagian setuju dengan dan sebagian berbeda dari hukum simbol yang sesuai dalam ilmu Aljabar.

Tanda Boole + mewakili "operasi pikiran" yang sama dengan yang kita kenal sekarang sebagai asor 'boolean dan penyatuan set. Demikian pula tanda-tanda - dan × sesuai dengan negasi boolean kami, komplemen dari set, boolean ´and 'dan persimpangan set.

UPDATE: Pertanyaan ini adalah topik blog saya pada bulan November 2015 . Terima kasih untuk pertanyaan yang menarik!

Visual Basic 6 (dan VBScript) miliki Impdan Eqvoperator. Tidak ada yang menggunakannya. Keduanya dihapus di VB.NET; setahu saya, tidak ada yang mengeluh.

Saya bekerja di tim kompiler Visual Basic (sebagai pekerja magang) selama setahun penuh dan tidak pernah sekalipun menyadari bahwa VB bahkan memiliki operator tersebut. Seandainya saya bukan orang yang menulis kompiler VBScript, dan karena itu harus menguji implementasi mereka, saya mungkin tidak akan memperhatikan mereka. Jika orang di tim kompiler tidak tahu tentang fitur dan tidak menggunakannya, itu memberitahu Anda sesuatu tentang popularitas dan kegunaan dari fitur tersebut.

Anda menyebutkan bahasa mirip-C. Saya tidak dapat berbicara dengan C atau C ++ atau Java tetapi saya dapat berbicara dengan C #. Ada daftar fitur yang disarankan pengguna untuk C # secara harfiah lebih panjang dari lengan Anda. Sepengetahuan saya, tidak ada pengguna yang pernah mengusulkan operator semacam itu ke tim C #, dan saya telah berulang kali memeriksa daftar itu.

Fitur yang ada dan tidak digunakan dalam satu bahasa, dan tidak pernah diminta dalam bahasa lain adalah kandidat yang tidak mungkin untuk membuatnya menjadi bahasa pemrograman modern. Terutama ketika tidak ada cukup waktu dan usaha dan uang yang tersedia dalam anggaran untuk membuat fitur yang orang lakukan inginkan.

Saya hanya bisa menebak, tetapi alasannya mungkin karena ada solusi yang cukup sederhana dan mudah dibaca. Mari kita perhatikan contoh Anda:

if (mode != ECB) assert (iv != null);

assert (mode != ECB --> iv != null);  // <-- that's only one character shorter

Jika Anda memerlukan ekspresi, operator inline-if yang tersedia di sebagian besar bahasa (sering disebut operator ternary) dapat digunakan. Memang, ini tidak seanggun A --> B, tetapi jumlah kasus penggunaan mungkin tidak membenarkan penambahan (dan pemeliharaan!) Operator lain:

assert (mode != ECB ? iv != null : true);

Eiffel memiliki Implikasi

Sebenarnya memiliki lebih banyak. Ini memiliki sejumlah operator semi-ketat dan juga ketat.

Alasan pemrogram tidak menggunakan hal-hal seperti itu adalah karena mereka tidak pernah dilatih untuk mengetahui dengan tepat apa mereka, bagaimana menggunakannya, dan kapan menggunakannya - serta bagaimana merancang dengan mereka. Karena mereka tidak pernah dilatih, mereka tidak pernah memintanya dari penulis kompiler, itulah sebabnya orang-orang kompiler tidak repot-repot menempatkan mekanisme seperti itu di kompiler. Ketika siswa Ilmu Komputer dan programmer Shade-tree mulai mendapatkan pendidikan yang lebih bulat, maka para penyusun akan mulai mengejar ketinggalan.

Ternyata sekali Anda memiliki bahasa dengan operator Boolean tersebut dan Anda tahu cara mendesain dengan mereka dan menggunakannya, maka Anda menggunakannya.

Di Eiffel penggunaan kata kunci "menyiratkan" agak menonjol karena Desain-oleh-Kontrak karena sifat berat pernyataan Boolean dari kontrak. Ada beberapa kontrak yang hanya dapat ditulis dengan benar dan efisien dengan operator "menyiratkan". Ini kemudian memunculkan komentar bahwa bahasa tanpa kontrak lebih jauh tanpa alasan untuk melihat, melatih, dan mengimplementasikan penggunaan implikasi.

Tambahkan ke ini bahwa kebanyakan programmer adalah "matematika-dan-logika-lemah" memberitahu kita sisa cerita. Bahkan jika Anda matematika-dan-logika-berat dalam pendidikan Anda, ketika seseorang memilih bahasa yang tidak mengimplementasikan konstruksi seperti implikasi, maka orang cenderung berpikir hal-hal seperti itu tidak perlu atau tidak berguna. Satu jarang mempertanyakan bahasa dan masuk ke ruang gema dari: "Yah kompiler tidak melihat kebutuhan" dan "Yah programmer tidak melihat kebutuhan" - lingkaran yang tak berujung dan ganas.

Sebagai gantinya, orang-orang penyusun perlu mendukung teori, menulis notasi bahasa yang disarankan atau disiratkan oleh teori (misalnya Teori Berorientasi Objek) terlepas dari apa yang dipikirkan atau diminta oleh massa programmer yang tidak dicuci. Dari sana, para profesor, guru, dan profesional lainnya perlu melatih para ahli muda yang cakap berdasarkan teori mentah dan BUKAN "teori-melalui-lensa-bahasa". Ketika ini terjadi, orang-orang akan tiba-tiba bangun dan menyadari apa yang telah mereka lewatkan dan apa yang telah dilakukan pada mereka.

Saat ini - ada banyak teori di luar sana yang menyamar sebagai Berorientasi Objek, tetapi hanya OO-melalui-kaca-gelap-of-[pilih-bahasa-Anda]. Seseorang tidak dapat membaca sebagian besar buku "teori" tentang OO karena mereka ingin menafsirkan apa teorinya melalui lensa dari beberapa bahasa. Benar-benar salah dan salah. Ini akan seperti mengajar berbasis matematika pada kalkulator saya atau aturan slide saya. TIDAK - seseorang mengizinkan kenyataan untuk mengajarkan satu tentang dirinya sendiri dan kemudian menggunakan notasi untuk menggambarkan apa yang diamati - yang disebut "sains". Tumbuk lain yang disebut OO berbasis-bahasa-X ini sangat miring sehingga nyaris tidak mewakili kenyataan.

Jadi, menjauhlah dari bahasanya, lihat teori mentah, dan mulai lagi. Jangan biarkan batasan, kendala, dan pekerjaan cat suatu bahasa memberi tahu Anda apa teorinya. Biarkan saja realitas teori menentukan notasinya sendiri dan kemudian pindah dari sana ke merumuskan bahasa.

Dari sana, Anda akan mulai mendapatkan bagaimana implikasi dan "implikasi" tidak hanya berguna, tetapi elegan dan sangat keren!

Selamat menikmati!

Python memiliki operator implikasi dalam semacam cara tersembunyi.

Operator yang kurang dari atau sama dengan kelebihan beban untuk menerima nilai boolean. Sebagai hasilnya, seseorang dapat menggunakannya sebagai operator implikasi.

Bukti dengan Contoh (Kode Python):

print (False <= False) # This will print True.
print (False <= True)  # This will print True.
print (True <= False)  # This will print False.
print (True <= True)   # This will print True.

Ingat tabel kebenaran dari operator implikasi adalah:

LEFT RIGHT RESULT
F    F     T
F    T     T
T    F     F
T    T     T

Eiffel memiliki operator "tersirat" dan sangat bagus untuk membuat pra dan pasca kondisi. Itu membuat kode lebih mudah dibaca, sayangnya itu tidak pernah menjadi kehebatan mendasar untuk bahasa seperti C dan terlalu sedikit orang menggunakan eiffel sehingga keindahan "menyiratkan" sebagai operator tidak dikenal.

Bagi saya, masalah besar dengan menyiratkan datang ketika kondisi awal salah; misalnya: "Jika matahari berwarna hijau, maka saya adalah kelelawar buah." Benar!

Dalam logika formal hanya berfungsi untuk menetapkan "Benar" ke nilai ketika kondisi implikasi tidak terpenuhi. Tetapi dalam pemrograman, itu bisa mengarah pada hasil kontra-intuitif dan mengejutkan.

Saya benar-benar berpikir contoh @Heinzi berikan di atas:

if (sun.color() == "green") then assert(me.species() == "fruitbat")

Jauh lebih mudah untuk dipahami, dan kurang rentan terhadap kesalahan karena kesalahpahaman logika.

Dalam konteks pengujian, saya hanya akan berhenti saat asumsi saya menjadi salah:

assert(sun.color() == "green")
assert(me.species() == "fruitbat")

Jadi, untuk titik @Eric Lippert, sebagai seorang programmer saya tidak tahu kapan saya akan menggunakan operator tersirat. Perilaku "False is True" tampaknya berguna dalam konteks matematika, logika formal, tetapi dapat menyebabkan hasil yang tidak terduga dalam logika program.

...

Tidak ada yang menyebutkan yang umum "?" operator, di mana "A? B: true" sama dengan "menyiratkan". Tetapi sementara logika formal berlaku untuk kondisi "lain", "?" memungkinkan pengembang menetapkannya secara eksplisit.

Dalam logika formal, menggunakan "true" berhasil, tetapi dalam pemrograman, jika kondisinya salah, maka jawaban yang lebih baik lebih seperti "null" atau "void" atau "skip", atau bahkan mungkin false.

Saya pikir seseorang harus menjelaskan mengapa "menyiratkan" adalah operator yang lebih berguna daripada pernyataan "?", Atau "jika", atau hanya aliran program biasa.

Racket memiliki implies. Makro-memperluas ke ifekspresi.