Pengurutan parameter untuk memanfaatkan kari

93

Saya baru-baru ini memiliki dua kali kode refactored untuk mengubah urutan parameter karena ada terlalu banyak kode di mana peretasan suka flipatau \x -> foo bar x 42sedang terjadi.

Saat mendesain fungsi tanda tangan, prinsip apa yang akan membantu saya memanfaatkan kari sebaik-baiknya?

haskell  functional-programming  currying  partial-application 
— John F. Miller
sumber

Jawaban:

111

Untuk bahasa yang mendukung kari dan aplikasi parsial dengan mudah, ada satu rangkaian argumen yang menarik, yang berasal dari Chris Okasaki:

  • Letakkan struktur data sebagai argumen terakhir

Mengapa? Anda kemudian dapat membuat operasi pada data dengan baik. Mis insert 1 $ insert 2 $ insert 3 $ s. Ini juga membantu untuk fungsi di negara bagian .

Pustaka standar seperti "kontainer" mengikuti konvensi ini .

Argumen alternatif terkadang diberikan untuk meletakkan struktur data terlebih dahulu, sehingga dapat ditutup, menghasilkan fungsi pada struktur statis (misalnya pencarian) yang sedikit lebih ringkas. Namun, konsensus umum tampaknya adalah bahwa ini kurang menguntungkan, terutama karena ini mendorong Anda ke kode yang diberi tanda kurung.

  • Letakkan argumen yang paling beragam di akhir

Untuk fungsi rekursif, biasanya meletakkan argumen yang paling bervariasi (misalnya akumulator) sebagai argumen terakhir, sedangkan argumen yang paling sedikit bervariasi (misalnya argumen fungsi) di awal. Ini cocok dengan gaya terakhir struktur data.

Ringkasan tampilan Okasaki diberikan di pustaka Edison miliknya (sekali lagi, pustaka struktur data lain):

  • Penerapan parsial : argumen yang lebih cenderung statis biasanya muncul sebelum argumen lain untuk memfasilitasi penerapan parsial.
  • Koleksi muncul terakhir : dalam semua kasus di mana operasi meminta satu koleksi atau mengubah koleksi yang ada, argumen collection akan muncul terakhir. Ini adalah semacam standar de facto untuk pustaka struktur data Haskell dan memberikan tingkat konsistensi ke API.
  • Urutan paling umum : di mana operasi merepresentasikan fungsi matematika terkenal pada lebih dari satu struktur data, argumen dipilih untuk mencocokkan urutan argumen yang paling umum untuk fungsi tersebut.
— Don Stewart
sumber
Sebagai akibat wajar untuk poin pertama, letakkan juga argumen yang mungkin tinggal dalam struktur data terakhir. Itu membuat peta, lipatan, dan teman lebih bersih. tl; dr hal dalam daftar pergi terakhir.
— John F. Miller
1
Bagaimanapun juga, pencarian tidak dapat dirantai, jadi poin pertama tidak mendukung hal itu. haskell.org/haskellwiki/Parameter_order membuat argumen meyakinkan sebaliknya - "Karena objek bertipe Map merepresentasikan pemetaan, wajar jika memiliki beberapa fungsi yang mengubah objek Map menjadi fungsi yang direpresentasikan."
— Brandon
11

Tempatkan argumen yang kemungkinan besar akan Anda gunakan kembali terlebih dahulu. Argumen fungsi adalah contoh yang bagus untuk ini. Anda lebih cenderung ingin map flebih dari dua daftar yang berbeda, daripada Anda ingin memetakan banyak fungsi yang berbeda di atas daftar yang sama.

— hammar
sumber
5
Jika Anda sebenarnya memetakan banyak fungsi pada daftar yang sama, mungkin Anda harus membuat daftar fungsi, dan map ($myList)lebih dari daftar itu.
— Squidly
3

Saya cenderung melakukan apa yang Anda lakukan, memilih beberapa pesanan yang tampaknya bagus dan kemudian melakukan refactor jika ternyata pesanan lain lebih baik. Urutannya sangat bergantung pada bagaimana Anda akan menggunakan fungsi (secara alami).

— agustus
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.