1 untuk tidak ada operator infix sama sekali. Subjek ini menarik terlalu banyak kebisingan, dan O (n) untuk a * b * c * d ... penggabungan tidak baik.

Jika ada pembahasan tentang alternatif, maka +100 untuk dipindahkan ke milis julia-infix-operator-debates .

1 untuk tidak ada operator infix sama sekali. Subjek ini menarik terlalu banyak noise, dan O (n) untuk a * b * c * d ... penggabungan tidak baik.

+1 untuk itu

Jika ada pembahasan tentang alternatif, maka +100 untuk dipindahkan ke mailing list julia-infix-operator-debates.

:tertawa:

LOL. +1 di julia-infix-operator-debates .

(Saya pribadi akan merasa sedih melihat penggunaan * dan ^ go ...)

Stefan baru-baru ini memberikan penjelasan yang bagus dan ringkas mengapa dia ingin melihat mereka pergi, saya akan mengutipnya di sini:

Masalah saya dengan * untuk penggabungan string bukanlah karena orang merasa tidak terduga, tetapi itu adalah penggunaan yang tidak tepat dari fungsi * generik, yang disepakati sebagai perkalian numerik. Argumen bahwa string membentuk monoid agak tipis karena banyak hal membentuk monoid dan kami biasanya tidak menggunakan * untuk mereka. Pada saat saya memperkenalkan * untuk string, kami jauh lebih tidak ketat tentang hukuman operator - recall | dan & untuk perintah shell - kami menjadi jauh lebih ketat dari waktu ke waktu, yang merupakan hal yang baik. Ini adalah salah satu permainan kata terakhir yang tersisa di perpustakaan standar. Alasan ++ lebih baik bukan karena lebih mudah dipelajari (tergantung dari mana Anda berasal), tetapi karena operator ++ di Julia secara tegas berarti penggabungan urutan.

Perhatikan bahwa hukuman operator tidak sepenuhnya menjadi perhatian akademis. Kasus sudut Char menunjukkan di mana punning dapat menyebabkan masalah: orang mungkin secara wajar mengharapkan 'x' * 'y' menghasilkan "xy" atau 241. Karena itu, kita hanya membuat kedua operasi ini tidak ada kesalahan metode, tetapi itu akan sangat masuk akal untuk mengizinkan 'x' ++ 'y' menghasilkan "xy". Ada jauh lebih sedikit kasus untuk memiliki 'x' * 'y' menghasilkan 241 atau 'ñ', tetapi operasi penggabungan urutan sebenarnya masuk akal.

Referensi untuk diskusi sebelumnya:
https://groups.google.com/forum/#!msg/julia -dev / 4K6S7tWnuEs / RF6x-f59IaoJ
https://groups.google.com/d/msg/julia-users/nQg_d_n0t1Q/9PSt5aya5TsJ
https://groups.google.com/d/msg/julia-users/JnTy-XcfLF8/JeeHREk2TvwJ

1771

2301

Saya salah satunya setuju bahwa ++ sebagai operator concat urutan umum jelas dan eksplisit, dan setuju bahwa contoh Char yang dibawa oleh Stefan adalah contoh yang baik di mana ini menyederhanakan hal-hal dengan menghilangkan maksud pengguna.

Saya tidak melihat ini sebelum melontarkan kata-kata kasar pada utas milis terakhir yang tidak curiga, di mana saya menyarankan julia-stringconcat sebagai pengganti (lebih baik) julia-infix-operator-debates . + INTMAX. Bunuh operator infix.

Saya _ benar-benar_ berpikir Anda harus menghindari menggunakan apa pun yang sudah memiliki arti (selain penggabungan string) dalam bahasa utama lainnya di dunia.
Saya menghabiskan terlalu banyak waktu melihat bug karena pengembang bolak-balik antara banyak bahasa yang terlalu sering menggunakan operator sederhana, yang berarti hal yang berbeda dalam bahasa yang berbeda atau
dalam konteks yang berbeda.

1) Anda membutuhkan sesuatu yang tidak memiliki arti lain untuk vektor, karena orang yang
melakukan pemrosesan string untuk mencari nafkah untuk dapat menggunakan string sebagai vektor karakter
(dan sebaliknya). Itu akan menyingkirkan +, *, ^, &, dan ||.

2) Anda membutuhkan sesuatu yang tidak membingungkan kebanyakan programmer (bukan hanya numerik
dunia komputasi). Itu mengesampingkan , <> (SQL dan bahasa lain).
Saya pikir ++ akan menjadi _little_ confusable, tetapi karena ini adalah operator unary di C / C ++ / Java / etc.,
dan ini akan menjadi operator biner, saya pikir itu akan baik-baik saja.

3) Anda memerlukan operator infix sederhana, setidaknya untuk penggabungan, jika tidak, Anda akan disisipkan
ton tomat virtual oleh kita semua yang melakukan pemrosesan string.

Saya akan memilih ++, ini digunakan untuk penggabungan dalam bahasa yang cukup populer, yaitu Haskell,
itu membangkitkan ide untuk menambahkan string bersama-sama, yaitu menggabungkannya, dan memang demikian
tidak memiliki arti lain untuk vektor / larik, dan dapat digunakan sebagai umum
operator penggabungan vektor / larik, yang juga bagus (per poin 1 di atas)

https://www.destroyallsoftware.com/talks/wat

Untuk menyuarakan pendapat saya tentang masalah ini, saya telah menggunakan bahasa yang operator penggabungan stringnya adalah . , + , (spasi), _ dan ++ . Ketika saya mulai julia dan mengetahui bahwa _ adalah operator concat, pikiran pertama saya adalah cool, that makes sense , karena saya tidak pernah benar-benar menyukai + . Satu argumen yang mendukung tidak menggunakan * Saya suka adalah yang diberikan oleh @StefanKarpinski tentang ambiguitas antara Char sebagai integer dan Char sebagai string 1 karakter. Dengan demikian, tampaknya ++ sebagai operator concat masuk akal, meskipun dalam hal ini kita harus memberikan semantik yang jelas. Tiga opsi untuk ++ generik (apa yang harus dilakukan jika tipenya sama tampak jelas) yang menurut saya masuk akal adalah:

++(x,y) = ++(string(x),string(y))
++(x,y) = #MethodError
++(x,y) = ++(promote(x,y)...)

Dimana promosikan mempromosikan jenis wadah yang sesuai. Pilihan terakhir akan menyiratkan

x = Uint8[1,2,3]
"abc"++x == Uint8['a','b','c',1,2,3]

@keno , saya tidak benar, karena 'a' adalah Char, tipe 32-bit.
Jadi, jawabannya harus: UInt8 [97, 98, 99, 1, 2, 3], atau Char ['a', 'b', 'c', 'x01', 'x02', 'x03 ']

Saya memilih ++

Sebenarnya, jika Anda memiliki ASCIIString, itu bisa dipromosikan hanya ke UInt8 [], tetapi UTF8String (serta UTF16String dan UTF32String) perlu dipromosikan ke Char [].

(dan promosi semacam itu akan sangat berguna untuk pemrosesan string saya ...)

Masalah ini bisa jadi berjudul "Menganggap serius penggabungan string".

ambiguitas antara Char sebagai integer dan Char sebagai string 1 karakter.

Saya hanya akan mencatat bahwa:

julia-0.4> Char <: Integer
false

julia-0.4> 'a' * 'b'
ERROR: MethodError: `*` has no method matching *(::Char, ::Char)
Closest candidates are:
  *(::Any, ::Any, ::Any)
  *(::Any, ::Any, ::Any, ::Any...)

jadi tidak, Char bukan integer, dan sudah lama tidak ada di seri 0.4, dan oleh karena itu tidak ada ambiguitas sama sekali. String * Char bisa dengan sempurna mengembalikan string yang digabungkan, dll. Argumen itu sudah usang.

Mohon jangan biarkan diri kami menerima 200+ komentar sebelum kami merasa komentar itu dianggap cukup serius.

Bisakah seseorang membuat PR? Saya pikir semua orang mendukung penghentian *, ^ (jika hanya untuk menghilangkan bug milis). Operator ++ tampaknya mendapatkan daya tarik yang layak, tetapi jelas rumit dan tidak jelas untuk membuatnya umum. Ada semantik yang rumit (mirip dengan push! vs. append! ), kompleksitas algoritmik yang buruk, dan tidak ada kebutuhan yang jelas untuk iterable lainnya. Jadi mari kita membuatnya bekerja dengan baik untuk string (dan mungkin karakter) dan menyebutnya sehari.

@ScottPJones Tentu, saya menulisnya seperti itu untuk tujuan ilustrasi, karena Char s dapat dikonversi menjadi Uint8 s jika mereka dalam kisaran. Setuju pada masalah promosi UTF8String.

@jiahao : Masalah ini bisa jadi berjudul "

LOL.

Ada yang mau pesanan batch?

Saya rasa saya ingin satu, tetapi bisakah saya mendapatkannya dengan ++ alih-alih * ?

Oke maaf. Melanjutkan cedera memang menyenangkan, tapi mari kita tetap fokus. Mari kita coba menghasilkan serangkaian fitur minimal yang dapat diimplementasikan oleh PR:

• Penghentian * dan ^ untuk string
• Implementasi ++ untuk string pada string

Apa pun yang digeneralisasi ke wadah lain saya pikir kita bisa hash di dalam PR.

Saya ingin satu dengan ++! : menyeringai:

@staticfloat : 100:: +1:

Jika kita ingin benar-benar melakukan diskusi "menanggapi string dengan serius", misalnya, seperti masalah kinerja yang terkait dengan mencoba membuat string menjadi 0 dihentikan, di mana kita bisa melakukannya? (pikirkan tentang operasi substring atau slice yang sangat umum pada string ... dengan Julia Anda harus membuat string baru setiap saat)

jika kita mengalami kerusakan string, sepertinya waktu yang tepat untuk menghilangkan $ juga.

Alternatif favorit terbaik saya berikutnya untuk tidak menyebabkan kerusakan mungkin adalah versi bebas operator (https://github.com/JuliaLang/julia/tree/jb/strjuxtapose)

+1 untuk menghentikan * dan ^ untuk string.

Saya merasakan banyak ketidakjelasan di sekitar operator ++. Saat ini bagus, misalnya, "$a$b" dan string(a,b) melakukan hal yang persis sama. Akan mudah untuk mengacaukan ini dengan a++b . Seberapa sering Anda perlu menggabungkan string dengan array? Itu operasi yang aneh, karena tidak jelas apa yang dirujuk elemen array --- bisa berupa titik kode, atau data mentah.

Saya enggan untuk terlibat dalam diskusi ini, tetapi saya merasa terdorong untuk menyebutkan satu kemungkinan yang telah muncul di masa lalu (bahkan ada PR yang mengimplementasikannya pada satu titik): menggunakan penjajaran untuk penggabungan string. Anda akan menulis yang berikut ini:

"foo"  "bar" # "foobar"
"foo"   bar  # "foo$bar"
 foo   "bar" # "$(foo)bar"
 foo "" bar  # "$foo$bar"

Sebelumnya, ada kekurangannya yaitu tidak ada bentuk operatornya, misalnya Anda bisa meneruskan ke reduce , tetapi itu tidak berlaku lagi karena Anda dapat menggunakan call overloading untuk membuat ""(args...) melakukan penggabungan string . Jadi, Anda bisa menulis reduce("", objs) dan mendapatkan rangkaian stringifikasi dari kumpulan objek. Ini dapat digeneralisasikan dengan ini:

julia> call{S<:String}(str::S, args...) = join(args, str)
call (generic function with 934 methods)

julia> reduce("", [1,"foo",1.23])
"1foo1.23"

julia> reduce(",", [1,"foo",1.23])
"1,foo,1.23"

Jika Anda hendak mengomentari apa yang baru saja ditulis

@fankarpindonesia Tidak memiliki akhir kesalahan dalam kode dari aplikasi Multivalue / Pick, karena mereka menggunakan penjajaran ... sulit untuk mengatakan apa yang sebenarnya dilakukan kode tersebut.
Juga, apa yang terjadi dengan argumen makro ... spasi sangat penting di Julia, jadi
<strong i="8">@foo</strong> "Scott" "Paul" "Jones" ke makro mengharapkan 3 argumen mulai rusak, bukan?

@JeffBezanson Jika saya harus menggunakan Vector {UInt8} atau Vector {Char} untuk string yang bisa berubah, untuk melakukan pemrosesan string saya, maka saya benar-benar ingin bisa menggabungkan string yang tidak bisa diubah menjadi salah satunya ... seperti orang mengeluh karena tidak dapat menggabungkan string dan Karakter sekarang, keduanya adalah operasi yang sering dilakukan.

Tapi apa yang dilakukan penggabungan string dengan Vector {UInt8}? Bagaimana jika vektor berisi UTF-8?

@JeffBezanson Concatenating with a Vector (UInt8) and a UTF8String mungkin merupakan kesalahan. Penggabungan dengan ASCIIString akan baik-baik saja (mengembalikan Vektor {UInt8}).
Konsentrasi Vektor {Char} dengan UTF8String harus mengembalikan Vektor {Char} (yaitu melakukan konversi UTF8-> UTF32 terlebih dahulu) ... untuk kinerja, saya akan memeriksa UTF8String untuk mengetahui berapa banyak karakter logis terlebih dahulu, membuat keluaran buffer yang cukup besar untuk keduanya, lalu salin Vector {Char}, dan konversikan UTF8String langsung ke buffer ...)

Sebenarnya, mungkin akan lebih baik untuk melakukan punt pada penggabungan apa pun dengan Vektor, kecuali mungkin Vector {Char}, dan memiliki paket string yang bisa berubah, dan menambahkan metode untuk ++ di sana ... Jauh lebih bersih, IMO.

Ya, saya setuju, itu akan menjadi sedikit rumit jika tidak.

Saya pikir itu akan menjadi keputusan yang buruk untuk tidak memiliki operator infix sama sekali untuk penggabungan string. Ini harus menjadi petunjuk bahwa hampir setiap bahasa tujuan umum modern telah memilih untuk menentukan beberapa operator infix untuk operasi ini. Dan fakta bahwa bahasa lain membuat _banyak pilihan_berbeda_ untuk operator menunjukkan bahwa tidak ada kesepakatan ketat yang membuat kita tersesat dari bahaya kita.

Saya setuju dengan @pao bahwa bikeshed di atas ini kontraproduktif, dan saya merasa sulit untuk memahami mengapa orang sangat peduli dengan ejaan ini. * mudah digunakan, tidak _yang_ aneh, dan Char*Char tidak cukup sering muncul sehingga tidak perlu dikhawatirkan.

Urutan a * b adalah alias untuk string(a, b) kecuali dalam kasus khusus di mana a dan b adalah numerik, oh ya, atau array numerik, maka artinya berkembang biak.

Akan lebih baik jika memberikan catenation string pada operatornya sendiri sehingga de-sugaring selalu benar. Dan jika tidak digunakan dalam bahasa lain maka itu adil untuk semua dengan membuat semua orang sama-sama tidak bahagia :)

Itu juga akan mempermudah membuat a op b op c op d menjadi string(a,b,c,d) dengan implikasi kinerja yang jelas. Jadi hanya string() maka perlu optimasi kinerja (karena saat ini fungsi yang sangat umum).

++ bagus. Apa yang dilakukannya untuk non-string bisa dikerjakan nanti.

@stevengj 1) Mengapa Anda berasumsi bahwa Char ++ Char tidak cukup sering muncul untuk dikhawatirkan?
Ini adalah sesuatu yang mengganggu saya tentang diskusi di sini ... Saya melihat banyak "ini tidak penting" ... tapi itu hanya pendapat, dan Anda memiliki orang yang berpengalaman dalam pemrosesan string memberi tahu Anda bahwa _is_ penting. 2) * agak membingungkan bagi banyak orang, seperti yang saya katakan bahwa bagi kebanyakan orang yang melakukan pemrosesan string, pertama-tama mereka akan memikirkan pengulangan, bukan penggabungan. Saya telah melihat banyak orang mengungkit hal itu. 3) Mungkin jumlah komentar negatif tentang * sebagai operator penggabungan, beberapa tahun yang lalu dari apa yang saya lihat, seharusnya menjadi petunjuk bahwa itu bukan keputusan terbaik, dan seharusnya dipertimbangkan kembali di versi 0.1 atau 0.2 , bukan ketika orang ingin mendapatkan 0,4 dirilis ...

@simonster Mengenai "abc"++[1, 2, 3] . Ini adalah contoh yang bagus bahwa simbol "operator dengan titik" yang diwarisi dari matlab menggigit kita dari waktu ke waktu. Untuk membandingkannya, operator penggabungan di J / APL adalah , dan dilengkapi dengan "keluarga operator titik" yang dibedakan oleh irisan yang harus dikerjakan oleh operator.

   'abc' , '123'
abc123

'abc' ,"0 '123'
a1
b2
c3

atau bahkan

 'abc' ,"1 0 '123'
abc1
abc2
abc3

Ini tidak menjawab pertanyaan jenis promosi yang Anda tujukan.

_Edit: Argh, saya menyia-nyiakan kesempatan untuk tidak mengatakan apa-apa_

@ScottPJones , banyak bahasa lain yang tampaknya memiliki operator infix penggabungan string tetapi tidak operator penggabungan karakter. Saya tidak melihat banyak keluhan. Anda masih dapat menggabungkan karakter dengan melakukan string(char1, char2) (atau menggunakan string panjang-1 seperti pada Python), jadi tidak ada fungsionalitas yang hilang. Jika Anda melihat kode yang ada dalam bahasa yang tersebar luas, jumlah penggunaan penggabungan string jauh melebihi jumlah contoh penggabungan dua karakter.

Klaim bahwa penggabungan karakter hampir sama pentingnya atau berguna seperti penggabungan string sama sekali tidak masuk akal.

Akan selalu ada komentar negatif tentang pilihan ejaan. (Orang yang berasal dari Python akan selalu mengeluh bahwa kami membutuhkan end daripada menggunakan indentasi.) Rasanya berbeda, dan beberapa orang dengan perasaan yang kuat dapat membuat banyak suara. Jika kita memilih ++ , saya jamin bahwa pendatang baru masih akan mengeluh - "Mengapa Anda tidak menggunakan + ? + jauh lebih mudah ditemukan dan intuitif karena saya terbiasa untuk itu dari bahasa _X_. "

Saya tidak terlalu menyukai * ; Saya tidak terlalu peduli. Perasaan saya adalah kode yang terus-menerus berganti pada perubahan ejaan yang tidak berguna lebih merugikan Julia daripada manfaat apa pun yang akan kita dapatkan dari mengganti satu karakter dengan yang lain.

Selain semua itu, ++ akan sangat menyakitkan dari sudut pandang peningkatan. Karena ++ saat ini tidak diurai sebagai operator infix, tidak akan ada cara bersih untuk mempertahankan kompatibilitas mundur dengan Compat - ini akan menjadi peningkatan hari bendera , mengharuskan setiap paket menggunakan penggabungan string ke garpu menjadi 0,3 dan 0,4 versi (atau gunakan string(a,b) , menyerah pada rangkaian infix seluruhnya).

Faktanya adalah bahwa kode yang terus-menerus berputar pada perubahan ejaan yang tidak berguna lebih merugikan Julia daripada manfaat apa pun yang akan kita dapatkan dari mengganti satu karakter dengan karakter lainnya.

Ya, itu hanya boleh diubah sekali, dari apa yang sekarang menjadi keadaan akhir (atau tidak ada perubahan jika itu keputusannya). Menghentikan sekarang dan menambahkan operator nanti ketika semua orang telah mengubah kode mereka menjadi string (a, b) atau "$ a $ b" hanya berarti bagi pengguna.

dan O (n) untuk a * b * c * d ... penggabungan tidak baik.

Bisakah Anda melakukan lebih baik daripada O (n) untuk penggabungan string?

@stevengj Bahasa yang telah saya gunakan (yang juga banyak digunakan dalam pemrosesan string) cenderung tidak memiliki tipe karakter terpisah (M [UMPS], Pick, JavaScript, Lua, Python, dan banyak lagi ...), jadi itu bahkan tidak pernah muncul sebagai masalah, dan yang (Java, C ++) menangani penggabungan string dengan karakter dan karakter dengan karakter dengan baik.
Saya tidak tahu kode apa yang telah Anda lihat, tetapi di sebagian besar kode yang saya tangani (baik kode internal dan kode pada 1000 pelanggan), menggabungkan karakter dengan karakter, dan dengan string, dilakukan dengan berat (dan dioptimalkan secara khusus karena seberapa sering itu dilakukan) [dan hanya 1 dari pelanggan tersebut yang bertanggung jawab atas sekitar 54% dari rekam medis di AS].
Ini bukan "perubahan ejaan yang tidak berguna", cukup banyak orang yang mengajukan sejumlah keberatan yang baik untuk menggunakan * untuk penggabungan string ... jika tidak memperburuk orang secara serius, Anda tidak akan melihat percakapan ini terus menerus Majulah.
Jika Anda tidak terlalu sering menggunakannya, dan tidak terlalu peduli, dan orang-orang yang ingin melakukan pemrosesan string di Julia melihat ini sebagai masalah serius, mengapa Anda begitu keberatan?
Saya tidak pernah menganjurkan untuk mengubah * ke sesuatu yang lain berdasarkan selera, atau karena beberapa bahasa lain melakukannya dengan cara yang berbeda, argumen saya adalah tentang: kebingungan (orang lebih cenderung memikirkan pengulangan ... (* berarti membuat kelipatan sesuatu!), kurangnya konsistensi dengan vektor (yang merupakan masalah bagi orang yang melakukan banyak pemrosesan string, kami cenderung menganggap string sebagai vektor karakter), dan masalah dengan penggunaan Char secara konsisten (Char * Char, yang memiliki telah dihapus, tetapi bagaimana dengan operator numerik lain dengan Char? Terkadang Char bertindak seperti UInt32, terkadang tidak ...)

Pilih, misalnya, menggunakan karakter tunggal "pembatas sistem", dilambangkan dengan hal-hal seperti @RM , @VM , @FM , @SVM. .. (catatan, nilai , file, tanda subvalue), jadi Anda akan melihat "Scott":<strong i="9">@SVM</strong>:"Jones":<strong i="10">@VM</strong>:1:<strong i="11">@SVM</strong>:"Memorial":<strong i="12">@SVM</strong>:"Drive" , untuk membuat catatan, yang di JSON mungkin akan terlihat seperti [["Scott","Jones"],["1","Memorial","Drive"]] .
Di Mumps, itu akan dilakukan seperti ini:
"Scott"_$c(1)_"Jones"_$c(0)_1_$c(1)_"Memorial"_$c(1)_"Drive"
(tetapi dalam praktiknya, Anda akan menggunakan makro untuk $c(0) dan $c(1) , seperti $$$subdlm dan $$$valdlm ... ini sama dengan Char(0) dan Char(1) pada Julia)
Dan ya, ada juga banyak tempat yang menggabungkan beberapa karakter ... di M [umps], ada sintaks $char(codepoint,...) , jadi Anda dapat memiliki $c(1,a,1,b,2,c) ... [ dimana a, b, c dievaluasi sebagai bilangan bulat, yaitu titik kode).

@simonbyrne Saya bahkan tidak mengerti mengapa seseorang mengatakan a * b * c * d harus O (n) ... Itu gila!
(tapi mungkin seperti itu pada Julia, indikasi lain bahwa penanganan string tidak dianggap serius)

Data rangkaian string dari beberapa bahasa pemrograman paling populer :

• Python: + , tanpa rangkaian karakter (atau tipe karakter)
• Perl: . , tanpa tipe karakter
• Ruby: + , tanpa tipe karakter
• C ++: + untuk string dan karakter (tetapi hanya untuk string + char, bukan char + char)
• Fortran: // (karakter dan string panjang-1 diperlakukan hampir secara bergantian)
• Pergi: + , tanpa karakter concat
• Haskell: ++ , tidak ada rangkaian karakter (tetapi ditambahkan melalui : )
• Java: + , tidak ada rangkaian karakter (tampaknya ada tetapi tidak terdokumentasi dengan baik)
• Tujuan C: tidak ada operator penggabungan (dan banyak keluhan online)
• C #: + untuk string dan karakter (karakter "unicode" 16-bit)
• JavaScript: + , tanpa tipe karakter
• Pascal: + , rangkaian karakter (tampaknya ada di beberapa versi Pascal) tidak terdokumentasi dengan baik
• Visual Basic: + dan & , concat karakter tampaknya ada tetapi tidak terdokumentasi dengan baik

Kesimpulan: operator infix string-concatenation berguna, dan jika kita mengubah apa pun, seharusnya + - ini adalah konvensi dominan sejauh ini, meskipun tidak universal. Setidaknya kompatibilitas mundur / maju akan mudah diterapkan (dua baris di Compat.jl). Tapi itu hanyalah perubahan ejaan yang menambahkan fungsionalitas nol dan tidak menyimpan karakter kode nol, dengan harga banyak kode churn, oleh karena itu saya mempertanyakan kegunaannya.

Selain itu, data menunjukkan bahwa kelebihan makna penggabungan dengan operasi aritmatika bukanlah masalah serius: orang tampaknya dengan mudah terbiasa dengannya, dan terus mengadopsinya dalam bahasa baru.

Dan data menunjukkan bahwa sintaks untuk penggabungan karakter bukanlah masalah penting - banyak bahasa yang biasa digunakan untuk pemrosesan string bahkan tidak memiliki tipe karakter, dan banyak bahasa yang memiliki tipe karakter tidak memiliki karakter + string atau char + char penggabungan, atau jika mereka melakukannya mereka tidak repot-repot mendokumentasikannya dengan baik. Jika Anda melakukan banyak penggabungan karakter di loop dalam, Anda mungkin memerlukan kode yang lebih khusus, dan jika tidak ada dalam kode kinerja-kritis, Anda selalu dapat menggunakan string string atau panjang-1.

(Bagaimanapun, karena Char bukan lagi subtipe Integer dalam 0.4, jika ingin, kami selalu dapat menambahkan operator penggabungan karakter di lain waktu. Atau Anda dapat menambahkannya sendiri di program Anda sendiri jika merupakan operasi penting dalam beberapa kasus penggunaan khusus. Inti dari desain Julia adalah bahwa fungsi "bawaan" biasanya tidak memiliki keunggulan kinerja tertentu dibandingkan kode pengguna.)

@ScottPJones , jika mengalokasikan string baru yang berdekatan, a * b * c * d harus Ω (n), dengan n adalah jumlah total karakter, karena perlu menyentuh semua data. Anda hanya dapat melakukan lebih baik jika menghasilkan " string tali " atau struktur data serupa yang sebenarnya tidak menyalin data, tetapi memiliki kekurangannya sendiri (operasi selanjutnya mungkin lebih lambat). Mengalokasikan default untuk mengalokasikan string bersebelahan baru hampir tidak "gila", dan pada kenyataannya tampaknya _every_ bahasa lain juga default.

Saya tidak berpikir ada masalah sama sekali dengan a * b * c , setidaknya tidak lebih dari string(a,b,c) , karena diterjemahkan sebagai :

julia-0.4> <strong i="9">@which</strong> "a" * "b" * "c"
*(s::AbstractString...) at string.jl:77

Karena itu, saya setuju 100% dengan @stevengj jadi saya akan berhenti di situ.

Karena itu, saya setuju 100% dengan @stevengj jadi saya akan berhenti di situ.

: +1:

Jika tidak jelas, sementara orang lain mungkin keberatan dengan * dengan alasan tidak biasa atau tidak terduga bagi pemrogram yang berasal dari bahasa lain, saya TIDAK khawatir tentang itu - ini bukan alasan saya tidak suka * . Saya _hanya_ khawatir bahwa ini adalah penyalahgunaan dari fungsi generik * . Dengan kata lain, apakah rangkaian string benar-benar merupakan bentuk perkalian? Karenanya, saya sepenuhnya menentang penggunaan + untuk penggabungan string, tidak peduli berapa banyak bahasa yang dapat menggunakannya: ini adalah penyalahgunaan yang jelas dan mencolok dari arti fungsi + - sama sekali tidak adalah rangkaian string suatu bentuk penambahan.

@stevengj Itulah kesimpulan Anda ... Saya sangat tidak setuju bahwa seharusnya + , jika ada, karena banyak alasan yang sama bahwa * adalah masalah di Julia, karena itu membuat banyak masalah saat berhadapan dengan Karakter dan mampu bertindak sama pada string dan Vektor.
Data Anda tidak benar, + untuk Java berfungsi baik dengan sebuah karakter, dan VB juga (coba saja jika Anda tidak mempercayai saya! [Dan _is_ didokumentasikan])
Di Haskell, cukup lakukan string ++ [ch] atau [ch] ++ string.
Pascal juga berfungsi dengan baik (saya dapat mengirimkan Anda contoh)
Jadi, untuk Python, Perl, Ruby, C ++, Java, C #, JavaScript, VB, Fortran, Haskell, Pascal semuanya TIDAK bermasalah dalam menggabungkan karakter ...
(juga, Anda melihat bahwa bahasa yang benar-benar lebih fokus pada pemrosesan string biasanya _don't_ memiliki tipe karakter terpisah, dan hanya satu panjang 1 string, seperti bahasa yang saya kerjakan, di mana semuanya adalah string ...)
Anda akan mendapatkan Go & Objective C yang membuatnya sedikit lebih sulit ...
Saya pikir Anda benar-benar salah menafsirkan "data" ... bukan karena penggabungan karakter bukanlah masalah penting, ini hanya karena sebagian besar bahasa, ditangani, berfungsi seperti yang diharapkan, sehingga Anda tidak mengerti semua keluhan yang Anda dapatkan tentang Julia.

Python, Perl dan Ruby tidak memiliki tipe karakter.

@simonbyrne Maaf, saya salah membaca itu ... Saya sedang memikirkan O (n ^ 2), yang saya lihat di Julia akhir-akhir ini ... (karena string tidak dapat diubah, dan jika Anda memiliki lingkaran yang membangun string, itu mengalokasikan banyak memori, dan menghabiskan banyak waktu melakukan GC ...)

sehingga Anda tidak mendapatkan semua keluhan yang Anda dapatkan tentang Julia.

Ini muncul di milis bikeshed setiap beberapa bulan dan memicu diskusi ringan, biasanya hanya beberapa pesan ringan. Saya telah bekerja dengan banyak orang yang melakukan pemrograman Julia sehari-hari, sebagian besar dengan string, dan ini benar-benar tidak pernah muncul.

@StefanKarpinski Itu adalah bagian dari maksud saya, bahwa bahasa yang berfokus pada pemrosesan string tidak memiliki tipe karakter khusus, karakter hanyalah string dengan panjang 1 ... (atau Haskell, di mana string tidak terlalu istimewa, mereka hanyalah [char].

karena string tidak dapat diubah, dan jika Anda memiliki loop yang membangun string, ia mengalokasikan banyak memori, dan menghabiskan banyak waktu untuk melakukan GC

Anda tidak ingin melakukan ini. Anda harus mencetak ke objek IOBuffer sebagai gantinya dan kemudian mengambil string di bagian akhir. Ini mirip dengan pola StringBuilder di Java.

Stefan mungkin berakhir seperti semua pemimpin C ++: mereka mengklaim dengan keras bahwa menggunakan unsigned integer untuk std :: vector Subscripting adalah kesalahan besar yang mereka buat, tetapi sebagian besar programmer C ++ masih percaya bahwa itulah yang membuat C ++ begitu bagus. Julia akan terkenal ;-)

Omong-omong, saya memilih ++.

@ScottPJones , dokumentasi tersebut buruk, jika Anda tidak dapat menemukan dokumentasi dalam 10 menit dari Googling tentang "bahasa karakter gabungan X". (Secara umum, jika Anda menelusuri "string gabungan" vs. "karakter gabungan", akan langsung terlihat jelas mana yang lebih dipedulikan orang.)

@stevengj Umm ... untuk orang yang peduli, mereka umumnya hanya memperlakukan semuanya sebagai string, jadi Anda tidak akan melihat "karakter gabungan" muncul dalam pencarian. Tidak berarti bahwa itu tidak penting, atau berat dilakukan ... (dengan argumen itu, perkalian adalah menurut definisi komutatif, karena itulah yang akan diberitahukan oleh pencarian Google!)

Ini sedikit meretas tetapi untuk mengizinkan Compat menangani ++ ia dapat mencari pola AST semacam ini:

julia> :('x'++'y') |> dump
Expr
  head: Symbol call
  args: Array(Any,(3,))
    1: Symbol +
    2: Char x
    3: Expr
      head: Symbol call
      args: Array(Any,(2,))
        1: Symbol +
        2: Char y
      typ: Any
  typ: Any

Operator .. juga tersedia. Sepertinya tidak ada yang menyukai penjajaran / "" untuk penggabungan.

@StefanKarpinski , jika Anda tidak khawatir tentang pertanyaan keakraban, saya mempertanyakan kemurnian filosofis dari sudut pandang " + dan * hanya untuk aritmatika". Ini adalah pertanyaan bahasa, oleh karena itu pertanyaan tentang _convention_, bukan _correctness_, dan _vast mayoritas_ bahasa komputer menggunakan simbol aritmatika untuk rangkaian string tanpa tekanan yang jelas. Manusia sudah terbiasa dengan ini.

Pembahasan karakter bersinggungan. Jika kami memiliki operator penggabungan string, saya sangat setuju itu harus menangani karakter juga.

Anda tidak ingin melakukan ini. Anda harus mencetak ke objek IOBuffer sebagai gantinya dan kemudian mengambil string di bagian akhir. Ini mirip dengan pola StringBuilder di Java.

@StefanKarpinski Itulah yang harus Anda lakukan di Java atau Julia untuk kinerja, karena string yang tidak berubah ... itu tidak berarti mudah digunakan, atau orang-orang pada awalnya akan mengerti mengapa Julia sangat lambat dibandingkan ke Python melakukan sesuatu seperti membangun string ...
(Saya juga tidak suka Java untuk pemrosesan string, karena alasan itu)

@StefanKarpinski , x + +y dimana x dan y adalah angka. Memang, itu tidak terlalu sering muncul, tetapi saya tidak suka melihat @compat melakukan transformasi yang berpotensi menghasilkan kode yang salah.

Bukankah string python juga tidak bisa diubah?

@ScottPJones Saya telah mengajar matematika selama bertahun-tahun. Google mengatakan hal-hal bodoh.

Plus +: Dalam matematika, konvensi + selalu merupakan operator komutatif
Waktu *: Dalam matematika, ketentuannya adalah * dapat berupa komutatif (seperti bilangan) atau non-komutatif (seperti pada matriks). Itulah mengapa kami memiliki lingkaran komutatif dan non-komutatif.

Sekarang, jika kita kembali ke argumen semacam ini, Anda harus berhenti menggunakan + untuk menambahkan poin mengambang karena + tidak terkait dengan poin mengambang. Dan + selalu asosiatif dalam matematika. Ini hanya untuk menunjukkan kepada Anda bahwa argumen "non-komutatif" untuk mencegah penggunaan + lakukan string yang digabungkan tidak berlaku. Saya cenderung lebih suka ++ tetapi saya pikir argumen aljabar tidak boleh masuk dalam game ini.

Sepertinya tidak ada yang menyukai penjajaran / "" untuk penggabungan.

Ruang kosong sudah kelebihan muatan. Ini akan bertentangan dengan konteks makro / hcat. Yang membawa saya ke poin yang saya angkat di ML:

Julia sudah memiliki dua operator penggabungan, yaitu h - dan vcat . Mengapa tidak menggunakan hcat untuk penggabungan string, gaya MATLAB? Apakah masuk akal untuk membuat matriks string?

Apapun hasilnya ( .. , ++ , [ ... ] ), saya mendukung operator penggabungan yang eksplisit dan berbeda untuk string dan karakter.

Kita bisa menambahkan ++ sebagai operator ke 0.4, dan kemudian membuat penghentian terjadi setelah kita menggunakan 0.5-dev. Apakah benar-benar terburu-buru di sini?

Fortran: // (karakter dan string panjang-1 diperlakukan secara bergantian)

sepertinya pilihan "rasional" yang baik untuk Julia [1].

saya akan berharap bahwa membangun string dengan * / string kira-kira O (n * m) dalam jumlah string yang digabungkan (n) dan jumlah total karakter yang digabungkan (m) . Semacam objek pembuat string (cStringIO di python, StringBuilder / StringBuffer di Java, IOBuffer di Julia) sangat penting untuk kinerja yang baik saat membangun sesuatu yang besar.

[1] untuk konteks:

> typeof(1//2)
Rational

Argumen purist di sini mengingatkan saya pada bencana .+ untuk array + skalar. Ketika purisme filosofis bertabrakan dengan konvensi linguistik dan kepraktisan, purisme kalah.

Ah, diskusi yang bagus tentang pembuatan string O (n ^ 2) dan re: python: http://stackoverflow.com/questions/4435169/good-way-to-append-to-a-string

Saya suka solusi membangun daftar atau array dan kemudian memanggil join jika perlu.

Saya tahu orang membuat string sepanjang waktu, tetapi sepertinya ini adalah sesuatu yang harus dihindari. Jika itu untuk I / O (biasanya kasusnya) Anda jelas akan mendapatkan kinerja yang lebih baik melakukan I / O secara langsung, daripada membuat string terlebih dahulu dan kemudian mengirimkannya. Bahkan hal-hal seperti cPython yang dioptimalkan append hanya _amortized_ O (n), dan Anda cenderung menyerah faktor 2 atau lebih.

@mbauman Setidaknya itu masuk akal bagiku.

+1 untuk proposal @mbauman . Semua orang tampaknya baik-baik saja dengan ++ dan memiliki operator concat urutan umum cukup menarik.

Dengan asumsi ++ sedang diperkenalkan, saya pikir poin @stevengj di * tidak dapat ditinggalkan dalam 0.4.

@vtjnash // memiliki masalah yang sama yaitu sudah memiliki arti di Julia sebagai operator biner ... sesuatu yang menurut saya akan menyenangkan untuk dihindari ...

Karena kami mendesain dengan keluhan milis, perlu diingat bahwa kami belum mendengar dari semua orang yang mengharapkan ++ menjadi operator kenaikan.

Saya rasa saya tidak pernah mengatakan bahwa * untuk concat harus segera dihentikan, hanya saja seharusnya, beberapa saat setelah .. atau ++ atau apa pun yang diperkenalkan

@JeffBezanson Itulah sebabnya saya lebih suka Lua .. , tetapi tampaknya kebanyakan orang lebih suka melihat ++ .
Saya juga berpikir itu bukan masalah besar, karena yang satu unary, dan yang lainnya biner.
(seperti DataFrames overloaded ~)

@JeffBezanson Ketika saya menjalankan pengujian pembuatan string sederhana pada Python dan Julia, tepat setelah saya mengunduh Julia bulan lalu, saya melihat bahwa itu> 800x lebih lambat dari Python, dan membuat asumsi keliru bahwa itu berarti string bisa berubah .. Dalam Mumps, mutable vs. immutable tidak akan pernah muncul, karena tidak ada referensi ke sesuatu, Anda hanya memiliki nilai yang disimpan dalam array asosiatif, dalam memori atau pada disk, tidak ada yang lain. Saya melakukan jenis pengoptimalan yang sama yang tampaknya telah dilakukan CPython (dengan jumlah referensi pada string besar, salin saat menulis di bawah tenda).

@ScottPJones , membuat S=""; for s in list; S*=s; end sebuah operasi O (n) untuk string yang tidak dapat diubah daripada O (n ^ 2) sangat berbeda dari pembahasan di sini; bisakah saya mengajukan permohonan untuk fokus?

@stevengj Itu @timholy dan @johnmyleswhite yang membawa O (n) .. dan sayangnya saya salah membaca itu sebagai O (n ^ 2), yang saya lihat untuk membangun string dibandingkan dengan bahasa lain seperti Python. .. kesalahanku!

Saya mungkin salah membaca, tapi sepertinya masalah itu dimulai bukan karena banyak orang bermasalah dengan penggabungan string di Julia seperti sekarang, tetapi karena banyak yang muak dengan diskusi yang berulang, terutama yang terakhir yang berlangsung sebentar . Namun, dalam kasus ini saya tidak yakin bahwa masalah ini adalah masalah Julia _per se_ secara teknis.

Saya telah membaca ulang beberapa diskusi sebelumnya dan tidak ada satupun dari mereka yang sependapat dengan diskusi terbaru . Kebanyakan dari mereka sangat bersahabat: orang tidak dapat memahami string concat, bertanya pada daftar, belajar tentang * , mungkin bertanya tentang sejarah / pembenarannya, dan kemudian secara umum melanjutkan.

Kalau pembahasannya, tapi bukan pilihan operatornya sendiri yang jadi perhatian, mungkin bisa ditangani tanpa mengubah bahasa, paling tidak untuk saat ini. FAQ dapat menjelaskan situasinya, dan menyarankan bahwa pengguna baru dengan hormat diminta untuk menahan diri dari membuka masalah untuk sementara waktu.

IMO ini akan menjadi solusi paling murah, dalam hal kode rusak dan jam pemrogram.

Utas ini meningkatkan tekanan darah saya, yang bukanlah tugas yang mudah, tetapi saya merasa karena ini adalah jenis diskusi design-by-mailing-list , saya hanya ingin membuang berat badan saya (penggunaan Julia sehari-hari) di belakang hampir semua hal @evolusi . Saya pikir mengubah operator menjadi ++ tidak apa-apa, tetapi hanya akan memicu putaran baru keluhan bahwa itu bukan hanya + (dan sepertinya kenaikan), seperti poin @JeffBezanson di luar. Saya tidak mengerti masalah dengan string * char karena char s bukan bilangan bulat lagi - apakah ada masalah?

Jika operator ingin berubah, @mbauman memiliki ide timeline yang tepat. Saya pikir itu harus:

1. Tambahkan sebagai alternatif ke * sekarang. Tidak seorang pun yang mendukung 0,3 dan 0,4 dapat menggunakannya. Menambahkan peringatan deprecation untuk *(string,string) tidak pantas karena siapapun yang menggunakan 0.4 dengan paket yang mencoba mendukung 0.3 akan dipukul dengan mereka.
2. 0.4 keluar. Paket mulai bergeser dari 0,3 / 0,4 hingga 0,4 / 0,5
3. Peringatan penghentian ditambahkan untuk 0,5, sehingga paket yang mendukung 0,4 dan 0,5 hanya dapat bergeser ke ++ .
4. 0,5 keluar. Hapus * dari 0.6.

Apakah itu sangat berharga?

Menambahkan operator penggabungan urutan, yang tidak kita miliki, adalah ide yang sah. Jelas * tidak akan digunakan untuk menambahkan daftar atau array. Namun mungkin memiliki operator mengundang O (n ^ 2) x ++= y loop terlalu banyak. Secara teknis, sintaks dan performanya bersifat ortogonal, tetapi dalam praktiknya, sintaksis dapat memiliki efek semacam ini.

@IainNZ Saya rasa tidak benar bahwa Char bukan integer lagi, hanya saja operasi tertentu telah dihapus (*, /, dan ^), tapi saya pikir itu hanya menciptakan masalah inkonsistensi lainnya ... yaitu mengapa + dan - berfungsi, tetapi tidak * ...)

@Cantik_bugil

julia> Char <: Integer
false

EDIT: ... dan saya dengan @IainNZ tentang tekanan darah.

@JeffBezanson ++ = y tidak akan mengundang loop O (n ^ 2) lebih dari * = y saat ini, dan mungkin memberi kompiler lebih banyak kesempatan untuk mengoptimalkannya?

@pao , benar, saya perhatikan bahwa * berhenti berfungsi antara 0,3 dan 0,4, dan +/- masih melakukannya ... jadi itu pasti ditambahkan secara khusus untuk jenis Char?

Saya lebih khawatir tentang masalah yang menyebar ke tipe lain, dengan asumsi ++ mendukung array dan daftar.

Kami sekarang memperlakukan Char sebagai tipe ordinal.

@JeffBezanson Saya akan mengatakan Anda tidak bisa menghentikan orang melakukan hal-hal bodoh ... mencoba memberi mereka alat yang baik untuk membuat hidup mereka lebih mudah, dan mencoba memperingatkan mereka ya, tetapi jangan berubah karena beberapa orang mungkin menyalahgunakannya ...

Saya pikir itu akan menghilangkan ketakutan saya hampir seluruhnya jika kita tidak memiliki operator ++= . Banyak orang berasumsi, dan saya benar-benar tidak dapat menyalahkan mereka, bahwa operator seperti += bermutasi.

Memiliki operator mungkin Anda memiliki kesempatan untuk mengoptimalkan hal-hal seperti yang dilakukan CPython dengan lebih mudah ...

Tidaklah praktis untuk mengoptimalkan S=""; for s in list; S*=s; end seperti CPython, apa pun ejaannya. Julia tidak memiliki jumlah referensi, jadi tidak ada cara untuk fungsi *(S,s) mengetahui bahwa ia memiliki satu-satunya referensi ke S dan karenanya S aman untuk dimutasi. Kompiler dapat mengetahui hal ini dalam beberapa kasus, tentu saja, tetapi poin utama dari desain Julia adalah bahwa ia tidak mengistimewakan tipe bawaan daripada tipe yang ditentukan pengguna. Selain itu, pengoptimalan kompiler ajaib membuatnya jauh lebih sulit untuk bernalar tentang kinerja kode dan _pendesain_ kode yang dapat diprediksi untuk kinerja yang baik (cf CPython vs. PyPy). Operator ++= akan mengubah apa pun tentang ini, dan seperti yang dikatakan @JeffBezanson , hal itu mungkin akan mendorong orang untuk menggunakan penggabungan array secara berlebihan juga. Lihat juga pembahasan di # 7052.

Bagaimanapun, saya tidak melihatnya sebagai masalah besar bahwa struktur kode optimal di Julia sedikit berbeda dari struktur kode optimal di CPython. Akan menjadi masalah besar jika terlalu _harder_ untuk mendapatkan kinerja yang baik di Julia daripada di CPython, tetapi join(list) tidak terlalu sulit / berbelit-belit, juga tidak menulis ke IOBuffer() .

Perhatikan juga bahwa Julia tidak biasa dalam penggabungan berulang menjadi O (n ^ 2); lihat misalnya Ruby atau Go . Fakta bahwa penggabungan (kebalikan dari misalnya append! ) tidak pernah bermutasi adalah perilaku yang mudah dipahami, dapat diprediksi, dan umum.

Keseluruhan += overloading dengan python sangat mengganggu, ini membuka bug aliasing halus seperti ini:

>>> x = [1,2,3]; y = x
>>> x += [4]
>>> print(x,y)
[1, 2, 3, 4] [1, 2, 3, 4]
>>> x = x + [5]
>>> print(x,y)
[1, 2, 3, 4, 5] [1, 2, 3, 4]

Saya pikir diskusi ini benar-benar akan berakhir dengan bermakna (!!).

Langkah selanjutnya terdengar seperti itu akan menjadi proyek yang bagus untuk diperebutkan yang dapat dilakukan oleh kebanyakan pembuat kode pemberani: membuat fungsi penggabungan sekuens yang teruji dengan baik dan kokoh. Dia bahkan tidak perlu mengejanya ++ , tetapi juga tidak sulit untuk menambahkannya ke tabel operator parser . Jadi, jika Anda merasa kuat di sini, lakukanlah. (Peringatan biasa berlaku, hanya karena Anda membuat kode, itu tidak berarti itu akan digabungkan, dll.).

Sayang sekali kami tidak bisa memiliki "_" sebagai operator penggabungan string. Karena memang begitulah fungsinya, ketika digunakan dalam nama variabel ...

Jika itu adalah operator penggabungan string, Anda tidak dapat menggunakannya dalam nama variabel ...

Program @cormullion di M [umps] atau CacheObjectScript lalu! : grinning: Serius, memiliki operator terpisah untuk penggabungan, yang tidak digunakan untuk hal lain, itu bagus, meskipun terkadang saya berharap ada karakter lain yang tersedia, karena orang yang datang dari mana pun melihat this_is_foo_bar dan berpikir itu mungkin a name ... (tapi M tanggal kembali ke pertengahan 60-an, sebelum konvensi nama variabel / makro C)

Hanya sebuah pertanyaan ... dan tolong jangan ada yang marah! Dapatkah kombinasi seperti $+ $/ $* digunakan sebagai operator? Apakah mereka akan memiliki masalah yang diajukan sebesar ++ (yaitu a + +b )? (selain itu _slightly_ membingungkan pada pandangan pertama untuk pemrogram C / C ++ / C # / Java ...)

Saya menyukai $ sebagai (bagian dari) operator catenation string, ia memiliki kemiripan yang bagus dengan penggunaan $ sebagai operator interpolasi string dan $ terlihat seperti S untuk string.

Jika saya dapat menemukan (mungkin dengan beberapa bantuan :-)) bagaimana mengizinkan pengurai Skema untuk mengizinkan $ + $ * $ /, dll. Sebagai token, maka saya akan membuat garpu bagi orang-orang untuk mencobanya, lihat bagaimana mereka suka itu...

Sebenarnya sangat mudah. Saya rasa yang Anda butuhkan hanyalah menambahkannya ke daftar operator pada tingkat prioritas yang tepat: src / parser. scm: 16 . Anda bahkan tidak perlu membangun kembali semua Julia untuk mengujinya - cukup make -C src dan itu akan memakan waktu 5 detik. Saya pikir $$ juga terbuka.

jika * sulit untuk diingat, saya tidak melihat bagaimana $+ lebih mudah. juga, saya pikir lebih baik hanya untuk mengajarkan bahwa IOBuffer adalah abstraksi pembangun string di Julia dan selesai dengannya, daripada memiliki string yang bisa berubah (dengan append! dan insert! metode) dan objek IOBuffer (dengan metode print dan write ) dan memberi tahu pengguna untuk mencoba memilih yang benar.

Ada beberapa keuntungan konseptual untuk menggunakan operator non-aritmatika terpisah untuk rangkaian urutan. IOBuffer adalah alat yang tepat untuk string, tetapi tidak benar-benar meluas ke jenis wadah sembarang.

Saya pikir $$ akan jauh lebih mudah diingat daripada misalnya $+ .

Hanya beberapa pemikiran:

1. Jika ada masalah dengan penerapan ++ , mengapa tidak ** sebagai gantinya? [1]
2. Harap tidak ada kombinasi $ ! IMHO itu terlalu samar.
3. ** didasarkan pada aktual * dan mengusulkan ++ .

Saya pikir "a" ** "b" untuk mendapatkan "ab" (atau menggabungkan urutan lain) sepertinya tidak buruk.

• [1]: Python dan Ruby menggunakan ** untuk eksponensial daripada ˆ (bahkan ada peringatan sintaksis):

julia julia> ** ERROR: syntax: use "^" instead of "**"

Itu hanya bisa didokumentasikan dalam perbedaan dari bahasa lain di FAQ.

@vtjnash Masalah dengan *, adalah membingungkan bagi kebanyakan orang di luar sana, yang akan secara alami mengasosiasikan perkalian dengan membuat kelipatan sesuatu, yang akan diulang untuk sebuah string.
$ sering dikaitkan dengan string, dan + untuk penggabungan (+ berarti Anda _menambahkan_ sesuatu ke string, yaitu penggabungan) ... karenanya saya pikir $ + akan menjadi pilihan yang baik ...

1) Tidak membingungkan dengan operator matematika mana pun (setidaknya dalam bahasa utama yang saya kenal),
tidak seperti ++ , ** , + , * , <> , || , & , ~ yang digunakan dalam bahasa lain.
2) Itu tidak membebani sesuatu yang lain sehingga dapat digunakan sebagai operator penggabungan generik,
yaitu vcat untuk vektor ...
3) Tidak ada masalah penguraian (setidaknya, yang saya ketahui sejauh ini), yang dimiliki ++ , yang
Saya pikir @StefanKarpinski dibesarkan.
4) Ini mengingatkan pada "string" $ dan penambahan +.

Bagi orang yang melakukan manipulasi string, sangat merepotkan untuk mencoba membuat kode semuanya menggunakan IOBuffers ... kode tersebut sama sekali tidak terlihat intuitif, tidak memiliki operasi string yang Anda inginkan, mungkin memiliki lebih banyak overhead daripada ketika Anda hanya ingin melakukan beberapa operasi seperti:
`mystr [5:10] =" fish "# yaitu mengganti substring antara karakter 5 dan 10 dengan" fish "`

@toivoh Setidaknya untuk orang yang berasal dari salah satu bahasa yang digunakan untuk manipulasi string / database, $$ akan membingungkan orang, ini menunjukkan panggilan fungsi eksplisit ... dan tidak ada yang menunjukkan penggabungan sebagai lawan untuk pengulangan atau membagi atau memotong string dengan karakter atau substring ... Misalnya, $* bisa berarti pengulangan, "foo" $* 3 akan mendapatkan "foofoofoo" dan "foo,bar,baz" $/ "," (atau bahkan ',' ) akan mengembalikan tupel ("foo","bar","baz") , yang menurut saya akan cukup bagus ;-)

@ Ismael-VC ** _very_ sering digunakan untuk eksponen ... Seluruh alasan saya untuk mengemukakan beberapa kekacauan ini adalah untuk menghindari kebingungan sebanyak mungkin, baik untuk orang yang datang dari luar Julia, dan juga untuk Julians, di mana kelebihan beban operator * dengan sesuatu yang secara konseptual sangat berbeda dapat menyebabkan sakit kepala.
Jika Anda melihat ** b dalam kode, apakah Anda benar-benar akan memikirkan penggabungan string?
Pertama, Anda mungkin berpikir itu eksponensiasi, jika Anda berasal dari banyak bahasa lain ...
Kedua, tidak ada yang menunjukkan bahwa Anda melakukan operasi string.

+ pada string dapat memberikan kesalahan, ERROR: syntax: use "$+" instead of "+"
* pada string pada suatu saat dapat ditinggalkan (tidak terburu-buru, jika kita memiliki sintaks konsisten baru yang orang-orang pindah ke), dan itu bisa mengatakan: ERROR: syntax: use "$+" instead of "*" ,
sama untuk "^" ... ERROR: syntax: use "$*" instead of "^" .

@mbauman Sangat membantu !!! Hanya beberapa tambahan sederhana untuk tabel yang sudah ada, saya melakukan make -C src, ya, super cepat (saya harap saya tahu tentang itu sebelumnya ;-)) dan kemudian saya melakukan $+ = string (yang saya sadari mungkin terlalu sederhana), tapi hei, berhasil! Oh, semua pujian untuk kecantikan dan kekuatan Julia! ;-)
(dan pujian kepada siapa pun yang menulis parser ... Saya dulu dibayar sebagai UTA untuk membantu siswa dengan kode Skema mereka di 6.001 ... bahkan setelah tidak menggunakan Skema dalam 30 tahun, kode itu tampak cukup bisa dimengerti)

Satu hal yang saya coba cari tahu sekarang, adalah bagaimana juga membuat $ + bertindak seperti vcat pada vektor ...
Tolonglah?

karena $ adalah simbol interpolasi, $+ sudah berarti untuk menginterpolasi + dan $$ sudah diambil sebagai operator untuk interpolasi dua kali (mis. dari luar cakupan).

dan menambahkan metode untuk operasi ini tidak mengubah fakta bahwa operasi tersebut adalah O(n*m) dan karenanya tidak diinginkan untuk diajarkan

Saya hanya khawatir bahwa ini adalah penyalahgunaan arti dari fungsi * generik.

Saya tidak melihat ini sebagai penyalahgunaan arti * . Di sisi lain, akan menarik (jika mainan) jika perubahan caesar dapat ditulis sebagai (((uppercase(string) - 'A') + shift) % 26) + 'A' . Karena + adalah elemen-bijaksana, ini masuk akal (sementara .* akan menjadi operator perkalian string yang bijaksana). Saya pikir pertanyaan umum yang dibuat ini adalah apakah case string * non-string harus mempromosikan non-string menjadi string, atau apakah hanya valid untuk digunakan saat menggabungkan string.

@vtjash Itu tidak benar. $ ONLY berarti simbol interpolasi dalam konteks string literal .... sama dengan $$ . Di luar string literal, $ biasanya berarti bitwise XOR di Julia, dan
$$ , $+ , $* , $/ tidak berarti apa-apa. Itu sama sekali tidak diurai. Menariknya, seseorang telah menambahkan dukungan untuk parsing .. , tetapi itu tidak digunakan untuk apa pun saat ini.

@ScottPJones Ini sedikit lebih kompleks dari itu: http://docs.julialang.org/en/latest/manual/metaprogramming/#interpolation

.. perlu diurai sebagai operator karena ... adalah operator yang valid dan, sebagai quirk dari parser, semua string awalan operator juga harus ada di daftar operator

@nalimilan Sial! Apakah itu benar-benar menghalangi bisa menggunakan $ + sebagai operator penggabungan umum? Semuanya tampak berfungsi dengan baik ketika saya mengubah parser untuk menerimanya, dan menjalankan semua pengujian unit ...
Terima kasih atas penunjuknya ... Saya baru saja melihat interpolasi string.

@vtjnash Oke, itu aneh ... Saya pernah melihat berbicara tentang menggunakan .. untuk berbagai hal, dan berpikir bahwa itu sudah didukung di parser karena alasan itu (untuk paket yang menguji ide yang menggunakannya)

@ScottPJones , mungkin belum jelas, tetapi @vtjnash menjelaskan mengapa .. dapat diuraikan tetapi tidak digunakan. Mendefinisikan dan menggunakannya tidak masalah:

julia> ..(a, b) = a:b
.. (generic function with 1 method)

julia> 1..4
1:4

Saya benar-benar membayangkan bahwa .. dapat digunakan untuk sesuatu, mungkin interval atau penggabungan. Ini telah diusulkan untuk "kontra" juga (# 3160).

Jika itu terserah saya, saya lebih suka hanya memiliki string() . Ini menghindari perdebatan ini, itu secara jelas mengubah hal-hal menjadi string (sebagai lawan memperlakukan mereka sebagai urutan), dan membantu mencegah pembentukan string O (n ^ 2). string(string(string(a,b),c),d) terlihat tidak efisien seperti itu. Dengan seorang operator, menulis menjadi tergoda

a ++= b
a ++= c
a ++= d

Dengan sintaks fungsi, cara yang jelas untuk menulisnya adalah string(a,b,c,d) . Tentu saja ini tidak "menyelesaikan" pembentukan string O (n ^ 2), tapi saya pikir itu membantu.

@JeffBezanson :: +1:

Juga, secara umum, jika orang bersikeras menggunakan infix untuk fungsi favorit mereka, maka Julia mungkin tidak memiliki cukup operator untuk semuanya (terbatas pada ASCII). Banyak pembahasan di atas hanya mencerminkan bahwa: sulit untuk menemukan sebuah infix op untuk rangkaian string karena tidak banyak lagi yang bisa dipilih. Diberikan string , $ -interpolasi, @sprintf dan pustaka (misalnya Pemformatan ), apakah sebuah infix op untuk rangkaian string yang diperlukan?

Pada 3 Mei 2015 pukul 16:41, Tamas K.Papp [email protected] menulis:

@JeffBezanson https://github.com/JeffBezanson : [gambar:: +1:]

Juga, secara umum, jika orang bersikeras menggunakan infix untuk fungsi favorit mereka,
maka Julia mungkin tidak memiliki cukup operator untuk semuanya (membatasi
ke ASCII). Banyak pembahasan di atas hanya mencerminkan bahwa: itu sulit
cari operasi infiks untuk penggabungan string karena tidak banyak yang tersisa
Pilih dari. Diberikan string, $ -interpolation, @sprintf dan libraries (mis
Memformat https://github.com/lindahua/Formatting.jl), adalah op infix
untuk string concat yang diperlukan?

Seseorang harus mengatakannya: sejak penambahan emoji, mengapa tidak: smile_cat:
untuk catenation :)

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/JuliaLang/julia/issues/11030#issuecomment -98443533.

@JeffBezanson Komentar semacam ini yang benar-benar membuat saya

Jika itu terserah saya, saya lebih suka hanya memiliki string ()

Bagaimana perasaan Anda jika saya mengatakan bahwa Julia tidak boleh memiliki. * ./ etc?
Apakah Anda akan senang jika selalu melakukan sesuatu seperti matrix_multiply (a, b)?

Juga, argumen Anda tentang efisiensi agak merendahkan ... Anda memberi tahu orang-orang bahwa Anda lebih tahu daripada mereka, tentang apa yang masuk akal untuk pemrograman mereka.
Saya juga tidak melihat bahwa itu benar-benar membantu ... Saya menemukan bahwa orang akan memprogram dengan buruk tidak peduli alat apa yang Anda berikan kepada mereka untuk melakukan lebih baik. Saya melihat banyak O (n ^ 2) [atau O (n log n) hanya karena alokasi naik dengan pangkat 2, tapi itu juga tidak selalu bagus] kode di mana string dibangun dengan push! ... (dan Saya sudah mencoba memperbaikinya, dengan beberapa hasil yang agak bagus untuk kinerja).
Jika .. = atau ++ = atau $ + = adalah operator penggabungan vektor umum, maka a ++ = b juga pada dasarnya sama dengan melakukan push! (A, b).
Apakah Anda kemudian akan mengatakan bahwa push! (A, b) harus dihilangkan, karena dapat mengarah ke kode O (n ^ 2), yang telah saya lihat contoh nyata dalam kode di Base?
Operator juga sangat masuk akal untuk menambahkan ke string yang bisa berubah (atau IOBuffer) ... mengapa Anda terus melihatnya dalam hal kinerja hanya satu jenis?

@tpapp Maaf, tetapi argumen itu tampaknya agak tidak masuk akal bagi saya ... mengingat 1) pengurai Julia sudah mendefinisikan ratusan karakter Unicode tidak jelas yang dapat Anda gunakan sebagai operator infix ... lihat src / julia-parser .scm. 2) penggabungan string adalah operasi mendasar di hampir semua bahasa ... menggunakan interpolasi string atau string atau @sprintf jelek dibandingkan dengan memiliki operator infix sederhana, mungkin tidak berfungsi dengan baik [Saya harus melihat kode apa yang dihasilkan @sprintf ]. Ini BUKAN kasus orang yang menginginkan operator infix untuk fungsi favorit mereka, ini adalah kasus dari seluruh kelas programmer yang menginginkan operasi mendasar yang mudah dipahami (yang bukan overloading), dan mudah digunakan ...

@elextr Mengingat ratusan operator infix yang telah diizinkan Julia di parser, mungkin seseorang sebaiknya menambahkan _every_ kemungkinan karakter Unicode sebagai operator! ;-)

@kmsquire Ya, saya mengerti itu, dan di tempat lain sudah berkomentar tentang dapat melakukan hal itu dengan .. (masalahnya adalah .. = tidak ditangani di parser).

Saya yakin operator unicode dipilih dari subset tertentu berdasarkan kode kategori. Anda bebas memilih operator unicode seperti ⊞ dan melakukan apa pun yang Anda inginkan dengan itu di kode Anda sendiri (dan cukup mudah untuk mengetikkannya di Julia REPL, \boxplus lalu tekan tab - banyak editor memiliki plugin untuk fungsi yang sama). Dalam kebanyakan kasus, operator unicode mungkin memiliki arti khusus aplikasi jadi kami belum menetapkan definisi standar di Julia untuk sebagian besar dari mereka.

Seperti banyak argumen sintaks lainnya, nampaknya ini bermuara pada tidak adanya operator ascii yang tidak diklaim yang dengannya kita dapat menghindari ambiguitas di sini. Ada banyak operasi berguna yang terus muncul berulang kali, di mana alangkah baiknya jika mereka dapat memiliki sintaks operator / pembatas / braket non-unicode untuk mereka, tetapi jarang menemukan sesuatu yang dapat digunakan.

Ini mungkin merupakan latihan yang bermanfaat untuk menyusun tabel sintaks dari operator ascii satu dan multi-karakter untuk menyebutkan ambiguitas apa yang ada untuk kombinasi yang tidak diklaim.

Parser Julia sudah menentukan ratusan karakter Unicode tidak jelas yang dapat Anda gunakan sebagai operator infix

Untuk kedua kalinya, @ScottPJones , itu bukan hanya karakter acak yang kami pilih. Mereka jelas adalah operator. Kode kategori Unicode mengatakan demikian, dan memang demikian adanya. Jika kita telah mengacaukannya begitu parah, bagaimana Anda akan melakukannya? Gunakan karakter itu sebagai pengenal normal? Larang mereka sepenuhnya?

Anda terus mengatakan berulang push! adalah O (n ^ 2) tetapi sebenarnya tidak. Tidak. Tidak. Bukan masalah opini.

Saya menggunakan fakta bahwa sintaks menyarankan bagaimana hal-hal harus dilakukan. Kebanyakan orang, termasuk saya sendiri, tidak bersusah payah mempelajari karakteristik kinerja segala sesuatu secara mendetail. Kami belajar idiom, dan mengikuti sintaks apa yang disediakan dan apa yang terlihat bagus. Perbarui operator seperti + = sarankan untuk mengubah sesuatu secara bertahap. Di julia mereka tidak bermutasi. Melakukan ini untuk string tidak efisien. Saya tidak melihat ini sebagai menggurui, saya melihatnya sebagai upaya untuk menghindari meninggalkan jebakan kinerja. Tidak menggurui perancang mobil untuk membesarkan pedal rem. "Apa, menurutmu aku tidak bisa menemukan pedal rem?"

Lucu sekali Anda menyebutkan matrix_multiply(a,b) , karena sejauh ini kami dengan senang hati membagikan operator itu dengan penggabungan string!

Saya yakin operator unicode dipilih dari subset tertentu berdasarkan kode kategori. Anda bebas memilih operator unicode seperti ⊞ dan melakukan apa pun yang Anda inginkan dengan itu di kode Anda sendiri (dan cukup mudah untuk mengetikkannya di Julia REPL, lalu tekan tab boxplus - banyak editor memiliki plugin untuk fungsi yang sama).

@tkelman Di editor saya, hampir semua karakter di julia-parser.scm dikosongkan :-( Ini membuatnya agak sulit untuk diedit!

Ada banyak operasi berguna yang terus muncul berulang kali, di mana alangkah baiknya jika mereka dapat memiliki sintaks operator / pembatas / braket non-unicode untuk mereka, tetapi jarang menemukan sesuatu yang dapat digunakan.

Itulah yang mengganggu saya karena diberi tahu bahwa ~ tidak tersedia, karena sudah diklaim oleh DataFrames.jl.

Ini mungkin merupakan latihan yang bermanfaat untuk menyusun tabel sintaks dari operator ascii satu dan multi-karakter untuk menyebutkan ambiguitas apa yang ada untuk kombinasi yang tidak diklaim.

Ya, saya pikir itu ide yang sangat bagus.

@JeffBezanson Saya tidak mengatakan mereka acak, hanya saja mereka tidak jelas ... sekitar setengah dari mereka bahkan tidak ditampilkan di editor saya ... Orang lain, Anda ?, menuduh ide saya menggunakan $+ , $* , dan $/ sebagai "percikan acak", setelah saya sudah menjelaskan alasan saya (mirip dengan memiliki .+ , .* , ./ )
Anda sendiri berbicara tentang O (n ^ 2):

Menambahkan operator penggabungan urutan, yang tidak kita miliki, adalah ide yang sah. Jelas * tidak akan digunakan untuk menambahkan daftar atau larik. Namun mungkin memiliki operator yang mengundang O (n ^ 2) x ++ = y loop terlalu banyak. Secara teknis, sintaks dan performanya bersifat ortogonal, tetapi dalam praktiknya, sintaksis dapat memiliki efek semacam ini.

Juga, saya ingin menggunakan ..= atau $+= pada string yang dapat diubah (atau vektor, atau IOBuffers), bukan pada string yang tidak dapat diubah.
Saya pikir memiliki:

myStringBuffer ..= ".txt"

Apakah _very_ jelas, dapat dibaca, dan berguna!

Silakan kembali dan baca apa yang sebenarnya saya katakan tentang push! ... Saya mengatakan bahwa, jika bukan karena cara pengalokasi memori bekerja, itu akan menjadi O (n ^ 2), tetapi karena trik (yang dapat membuang memori) untuk meningkatkan ukuran dengan pangkat 2, itu hanya O (n log n).

Anda dengan senang hati membagikan matrix_multiply dengan penggabungan string, tetapi bagi saya, ini membingungkan, dan mencegah memperlakukan string dan vektor secara konsisten di tempat-tempat yang masuk akal.
Saya telah melihat banyak komentar di Google dan GitHub tentang bagaimana * untuk penggabungan mengejutkan orang pada awalnya ...

myStringBuffer .. = ".txt"
Sangat jelas, mudah dibaca, dan berguna!

Saya setuju, dan saya benci melakukan ini, tetapi sayangnya Anda akan kecewa: a += b segera diturunkan menjadi a = a+b , jadi Anda tidak dapat menentukan += secara terpisah dari + (sama untuk semua operator lain pada formulir ini). Untuk mendukung ini, kami harus membuat pengecualian untuk ..= .

Juga, poin yang sangat halus: kinerja push! tidak bergantung pada cara kerja pengalokasi memori. Ini adalah bagian dari implementasi struktur data untuk secara eksplisit meminta lebih banyak ruang, dan melacak berapa banyak kelonggaran yang tersedia. Kinerja ini portabel untuk semua jenis alokasi atau skema GC, tidak seperti pendekatan yang didasarkan pada penghitungan referensi.

@Bayu_joo

Saya setuju, dan saya benci melakukan ini, tetapi sayangnya Anda akan kecewa: a + = b segera diturunkan menjadi a = a + b, jadi Anda tidak dapat mendefinisikan + = secara terpisah dari + (sama untuk semua operator lain dari formulir ini). Untuk mendukung ini, kami harus membuat pengecualian untuk .. =.

Oke, sekarang saya pikir Anda mungkin memahami dari mana saya berasal ... Apa yang akan terlibat dalam membuat pengecualian untuk ..= ? Saya perhatikan bahwa ~ ditangani dengan cara khusus, sebagai makro, yang masih memungkinkan modul untuk mengontrol artinya ... dapatkah hal seperti itu dilakukan? Saya tidak menyukai gagasan tentang beberapa pengecualian khusus ... akan lebih baik jika teknik yang lebih umum dapat digunakan.

Terima kasih atas informasinya.

Tentang push! , saya mengikuti apa yang saya telah diberitahu ... itu baik untuk mengetahui bahwa itu hanya dikendalikan oleh implementasi struktur data, dan dapat diubah (saya tidak ingin saya strings _always_ menggandakan ukuran, ketika ukurannya banyak megabyte, hanya karena saya menambahkan satu karakter tambahan (seperti \0 termination ;-))

Minor nitpick: Membangun urutan dengan push! , yang menggandakan ukuran buffer pada setiap realokasi, sebenarnya adalah O(n) waktu diamortisasi dalam ukuran hasil; setiap realokasi dari ukuran k menjadi 2k dibayar dengan k/2 realokasi gratis push yang datang sebelumnya.

@toivoh Seseorang telah memberi tahu saya bahwa ini berhasil ke O (n log n) ... bukankah biasanya Anda harus menyalin data beberapa kali? Yaitu Anda mengisi 16 byte, lalu Anda mengalokasikan 32 dan menyalin 16, mengisi 32, mengalokasikan 64 dan menyalin 32, dan seterusnya, ditambah waktu untuk menyalin karakter ke buffer di tempat pertama ...

Jumlah dari semua pangkat 2 sampai dan termasuk N adalah 2N-1, yaitu O (N). Tentu saja push! dapat menjadi lambat dalam prakteknya karena pembukuan ekstra, dan tidak membuang memori.

Apa yang akan terlibat dalam membuat pengecualian untuk ..= ?

Silakan lihat https://github.com/JuliaLang/julia/issues/249 dan https://github.com/JuliaLang/julia/issues/3217 dan https://github.com/JuliaLang/julia/issues/7052 , yang terakhir telah ditautkan ke sini. Saya tidak berpikir mengubah cara kerja operator op= sangat mungkin terjadi di sini (termasuk yang belum ditetapkan). Mengingat sudah ada paket untuk melakukan operasi di tempat pada array, saya pikir taruhan terbaik Anda adalah terus menulis paket untuk operasi di tempat pada string dengan cara yang tidak memerlukan kasus khusus di basis Julia.

@ScottPJones : Ya, harap O(n) ). Katakanlah kita mulai dengan buffer dengan 16 byte data, dan kita telah melakukan salinan 16 byte. Kami mengalokasikan ulang dan menyalin, jadi total 32 salinan. Ketika buffer berada pada 32 byte, kami mengalokasikan ulang dan menyalin lagi, naik menjadi 64 salinan secara total, berikutnya 128, dan seterusnya. Jadi ya, Anda harus melakukan banyak salinan, tetapi dalam kasus ini itu hanya berlaku untuk sebagian kecil data sehingga total biayanya masih O(n) .

Ini bergantung pada fakta bahwa Anda meningkatkan buffer dengan setidaknya beberapa faktor tertentu setiap kali, jika Anda tumbuh dengan jumlah tetap, Anda mendapatkan O(n^2) . Jadi, jika Anda tidak ingin mengalokasikan 2 megabyte untuk string satu megabyte, saya pikir taruhan terbaik Anda adalah mengalokasikan terlebih dahulu berapa banyak yang Anda butuhkan (atau sedikit lebih, jika Anda hanya dapat melebih-lebihkannya).

@toivoh OK ... Saya telah melihat komentar di sini tentang * = menjadi O (n ^ 2) untuk string, telah melihat kinerja buruk dari rutinitas konversi menggunakan push !, orang lain di sini memberi tahu saya bahwa cara penyangga dikembangkan berarti itu adalah O (n log n) dan bukan O (n ^ 2), dan karena kalian kebanyakan bilangan, saya mengambilnya begitu saja, dan tidak menambahkannya sendiri ... Saya hanya melihat bahwa 16 karakter pertama itu disalin 16 kali jika Anda meningkatkan buffer dengan kekuatan 2 hingga 1 juta, 16 karakter berikutnya disalin 15 kali, dan seterusnya ... jadi ketika mereka mengatakan itu adalah O (n log n), itu masuk akal ... maaf atas kebingungan itu, dan terima kasih telah mencerahkan saya!

push! dan *= bukan operasi terkait. push! adalah O(n) diamortisasi ketika diimplementasikan sebagai operasi% pertumbuhan, penggabungan string bukan O(n) karena tidak ada operasi gratis yang memungkinkan, setiap kombinasi string baru memerlukan penyalinan baik yang lama maupun yang lama. data baru ke string baru. String pertama disalin N kali, string berikutnya disalin N-1 kali, ... string terakhir disalin 1 kali - yaitu O(N^2) .

Di editor saya, hampir semua karakter di julia-parser.scm dikosongkan :-( Ini membuatnya agak sulit untuk diedit!

saya pikir sudah waktunya Anda menemukan editor baru, atau setidaknya unduh font yang lebih baik https://github.com/JuliaLang/julia/blob/master/README.windows.md#unicode -font-support
kekhawatiran ini muncul pada awalnya karena operator baru diusulkan untuk ditambahkan, dengan kesimpulan bahwa editor apa pun yang tidak mendukung unicode pada tahun 2015 mungkin terlalu tidak relevan untuk menjadi masalah. sekarang ada plugin julia untuk editor paling populer yang mendukung penyelesaian \pi<tab> -> π .

OT: Saya yakin seharusnya push!(mutablestring, character) atau append!(mutablestring, string) . karena push! menyiratkan perubahan elemen-bijaksana, sedangkan append! berarti menggabungkan dua objek serupa. bentuk non-mutasi dari append! Saya yakin paling mendekati vcat , jadi vcat(string, string) => string mungkin akan menjadi operasi yang berarti.

@vtjnash Saya berbicara tentang memiliki operator
bukan operator *= , dan saya tahu semua tentang masalah O (n ^ 2) ... Saya baru saja membuat kesalahan, tidak tahu persis bagaimana alokasi memori Julia terjadi untuk array dengan push !, bahwa itu adalah O (n ^ 2)
(berikan kinerja yang saya lihat, itu asumsi yang mudah)

Tentang editor, itu mendukung Unicode, dan sekitar setengah dari daftar karakter Unicode yang aneh memang muncul ... Ini benar-benar lebih merupakan masalah font ... tapi bukan yang tidak biasa! Sampai itu terjadi, saya tidak menyadari font tersebut kehilangan karakter apa pun ... Ada huruf Jepang, Cina, Korea, dan sebagian besar yang matematika ....

OT: Saya yakin itu harus push! (Mutablestring, character) or append! (Mutablestring, string). sejak push! menyiratkan perubahan bijak, sedangkan append! menyiratkan penggabungan dua objek serupa. bentuk lampiran yang tidak bermutasi! Saya percaya paling mendekati vcat, jadi vcat (string, string) => string mungkin akan menjadi operasi yang berarti.

Saya rasa sebagian besar orang "string", seperti saya, akan menganggap bahwa karakter sebenarnya hanyalah string 1 elemen,
atau string hanyalah sebuah array karakter ... pikirkan C, C ++, Go, Haskell, ... semua bahasa yang bahkan tidak memiliki tipe karakter terpisah (Anda hanya menggunakan string dengan panjang 1) ...
Membuat perbedaan itu tidak membuat sejak untuk pemrograman saya, dan itu bahkan tidak konsisten sekarang di Julia ...

julia> string("foo",'\n')
"foo\n"
julia> "foo" * '\n'
ERROR: MethodError: `*` has no method matching *(::ASCIIString, ::Char)
Closest candidates are:
  *(::Any, ::Any, ::Any)
  *(::Any, ::Any, ::Any, ::Any...)
  *(::AbstractString...)
julia> "foo" * "\n"
"foo\n"

Inilah mengapa saya pikir diperlukan operator baru, yang akan bekerja secara konsisten dalam semua kasus ini ... dan bahkan dapat bekerja pada IOBuffers ...

MyBuff ..= myline
.... other code ...
MyBuff ..= '\n'
MyBuff ..= "Scott was here!"

Saya juga akan mengatakan, bahwa mungkin operator ini, yang Anda benar-benar hanya ingin orang gunakan pada tipe yang bisa berubah, bisa memberi kesalahan jika Anda mencoba menggunakannya pada tipe yang tidak bisa diubah ...

MyString::UTF8String = "My string"
... code ...
MyString ..= "\n My bad!"
-> would get a compile time error... (or would it be a run-time error?)

Berbicara tentang .. , perlu dicatat bahwa # 5715 masih terjadi di v0.4:

#  Version 0.4.0-dev+4629 (2015-05-04 00:27 UTC)

julia> ..(a, b) = a * b
.. (generic function with 1 method)

julia> "a".."b".."c"
ERROR: syntax: extra token ".." after end of expression

TL; DR (Saya mencoba, memindai dan membaca sebagian besar .. dan semua di forum julia saya mulai, dan baru saja menemukan utas ini).

"a * b * c, setidaknya tidak lebih dari yang ada dengan string (a, b, c)"

Saya tidak yakin apa artinya a_b_c diubah menjadi string (a, b, c), yang merupakan salah satu aplikasi fungsi string (atau tiga).

Saya tidak mengerti untuk atau menentang operator + atau *. Kecuali + digunakan, saya tidak memiliki preferensi untuk yang lain. Tahu saja || digunakan dalam SQL atau hanya fungsi concat (a, b) atau cat (a, b). Saya bisa pergi tanpa operator.

Yang paling saya khawatirkan adalah apakah Julia lambat atau tidak. Dan secara default. Bisakah penggabungan apa pun tidak hanya memberi Anda tali dan menjadi lebih cepat? Dan jika Anda mencoba untuk mengganti di tengah-tengah string maka Anda mendapatkan non-ropestring?

@PallHaraldsson Lihat https://github.com/JuliaLang/julia/issues/2301#issuecomment -13573303 untuk alasan mengapa kami tidak menggunakan RopeStrings secara default. Tetapi diskusi lebih lanjut tentang kinerja string harus dilakukan dalam masalah terpisah.

Bagi saya, string di Julia secara sintaksis mirip dengan array karakter (misalnya, string dapat diindeks / disubset dengan cara yang sama seperti array). Jadi saya pikir semantik append! mungkin lebih tepat daripada push! dalam hal merangkai string.

Mengenai memperkenalkan operator baru yang kelebihan beban untuk penggabungan, saya cenderung berpikir + adalah pilihan yang lebih baik hanya karena adopsi yang lebih luas. Masalahnya, tentu saja, adalah bahwa + telah kelebihan beban untuk array dan semantiknya tidak ada hubungannya dengan penggabungan. Namun, pemilihan operator yang akan diganti sebagian besar adalah masalah selera pribadi - yang lebih penting, menurut saya, adalah konsistensi dalam semantik operator; operator apa pun yang kita temukan untuk tugas ini harus dapat digunakan untuk menggabungkan semua larik satu dimensi (atau, multi-dimensi) dengan perilaku tak terduga minimal.

Mungkin kita sebaiknya menghentikan operator ^ dan * dan membiarkan penggabungan ke fungsi yang dinamai secara eksplisit untuk menghindari kebingungan.

-100 untuk menghapus * untuk penggabungan string. Ini sangat berguna dalam praktik dan membuat kode sangat mudah dibaca. Argumen bahwa itu bisa tidak efisien menurut saya tidak valid. Dalam hal ini kita juga harus menghilangkan penambahan tiga vektor a+b+c yang juga tidak efisien karena temporer yang dibuat.

@tknopp Saya tidak setuju bahwa * membuat kode sangat mudah dibaca, karena ini adalah kejutan bagi semua orang yang baru mengenal bahasa ini, dan membuat orang berpikir lebih banyak tentang pengulangan, daripada penggabungan, serta menjadi bingung apakah hal-hal yang diterapkan adalah string atau vektor atau nomor skalar ...
Saya pikir proposal yang tampaknya paling mendukung adalah mengganti * dengan ++ , ala Haskell.

Masalah ini harus didorong oleh pengalaman praktis daripada dari sudut pandang akademis. Dalam beberapa tahun terakhir tidak pernah ada banyak diskusi tentang * menjadi hal yang salah. Mengapa tiba-tiba ada masalah?

Pada prinsipnya saya akan baik-baik saja dengan + tetapi saya tidak melihat bahwa ada cukup pembenaran bahwa + akan lebih baik.

Penggunaan * cukup umum dalam ilmu komputer teoretis (tata bahasa formal). Di sini * dengan string kosong "" membentuk monoid.

Saya mulai berpikir kita harus meminta agar keputusan akhir dibuat oleh kekuatan yang ada dan kemudian berhenti mengkhawatirkan topik ini.

@tknopp Seperti yang sudah sering dikatakan di utas ini, + bukanlah pilihan yang baik karena beberapa alasan yang sama bahwa * bukanlah pilihan yang baik. Ada juga sejumlah diskusi tentang * yang membingungkan, dll. ++ akan berfungsi karena ini hanya operator unary dalam bahasa lain, kecuali untuk Haskell, di mana ini adalah operator penggabungan.

@johnmyleswhite : ya saya setuju. Tetapi saya pikir mereka telah melakukan ini beberapa tahun yang lalu. Pada titik tertentu, seseorang harus tetap pada pilihan.

Nah, mungkin kekuatan yang akan memutuskan untuk menutup masalah ini.

O (n) untuk a * b * c * d ... penggabungan tidak baik.

Dalam hal ini kita juga harus menghilangkan penambahan tiga vektor a + b + c yang juga tidak efisien karena temporer dibuat.

Apakah mungkin operator infix berulang bisa diturunkan menjadi +(a, b, c) / *("a", "b", "c") ? Ketika ini masuk akal / didefinisikan ...

_ (IMO kapal telah berlayar di * untuk string concat, argumen untuk melanggar kode semua orang harus ... kuat.) _

Apakah mungkin operator infix berulang dapat diturunkan menjadi + (a, b, c) / * ("a", "b", "c")? Ketika ini masuk akal / didefinisikan ...

Bukan?

julia> Meta.show_sexpr(:("a" * "b" * "c"))
(:call, :*, "a", "b", "c")

@hayd Saya tidak berpikir kapal telah berlayar, bukan untuk membuat sesuatu seperti ++ operator penggabungan umum (bukan hanya untuk string), atau bahkan untuk mungkin mencela * sebagai operator penggabungan string , jika orang ketinggalan menggunakan ++ sebagai gantinya.

Apakah kapal telah berlayar dengan operator penggabungan baru atau tidak, * dan + hanyalah operator biner?

Saya mungkin salah:

julia> a = 10

julia> dump (:( a_a_a))

Ekspr
head: Panggilan simbol
args: Array (Any, (4,))
1: Simbol *
2: Simbol a
3: Simbol a
4: Simbol a
ketik: Apa saja

julia> println (a, a, a)
101010

Julia> println (a_a_a) # tidak sama jika a kebetulan adalah string "10"
1000

Sama seperti println dan banyak fungsi, termasuk b = string (a, a, a), itu
bersambung, saya tidak yakin kita membutuhkan lebih banyak operator untuk melakukannya? Tidak bisakah itu menjadi
cara yang direkomendasikan?

Seperti yang ditunjukkan di atas, * atau apa pun, mungkin dievaluasi sekali sebagai operasi penggabungan string, bukan
Tentu. Itulah yang sudah dilakukan dengan string, dan dalam ide saya untuk mutable baru
string akan berguna jika tidak melakukan operasi tiga kali (akan menghemat ruang).

[Ada prasyarat untuk, untuk penggabungan, Anda tidak perlu mencari lebih jauh
Informix 4GL itu :)]

@ ScottPJones : "++ operator penggabungan umum (bukan hanya untuk string)", apa maksud Anda? Jika 1 ++ 1 harus "11" dan bukan 2, apakah itu ide yang buruk?

@PallHaraldsson Seperti yang saya katakan, saya menginginkan operator penggabungan umum untuk string dan vektor (misalnya seperti vcat ). Saya tidak pernah mengatakan bahwa saya ingin operator itu digunakan untuk skalar (saya pikir itu bukan ide yang baik,
itu hanya membuat hal-hal menjadi lebih berpotensi membingungkan).

Ada sejumlah masalah konsistensi saat ini, seperti:

julia> b"a" * b"b"
ERROR: MethodError: `*` has no method matching *(::Array{UInt8,1}, ::Array{UInt8,1})
Closest candidates are:
  *(::Any, ::Any, ::Any)
  *(::Any, ::Any, ::Any, ::Any...)
  *{T<:Union(Float64,Complex{Float32},Complex{Float64},Float32),S}(::Union(SubArray{T<:Union(Float64,Complex{Float32},Complex{Float64},Float32),2,A<:DenseArray{T,N},I<:Tuple{Vararg{Union(Range{Int64},Int64,Colon)}},LD},DenseArray{T<:Union(Float64,Complex{Float32},Complex{Float64},Float32),2}), ::Union(SubArray{S,1,A<:DenseArray{T,N},I<:Tuple{Vararg{Union(Range{Int64},Int64,Colon)}},LD},DenseArray{S,1}))
  ...

julia> vcat(b"a", b"b")
2-element Array{UInt8,1}:
 0x61
 0x62

Operator penggabungan umum, seperti yang telah saya usulkan, apakah ++ atau .. atau yang lainnya, akan menghilangkan perilaku tidak konsisten semacam itu.

@scottjones : "Saya tidak pernah mengatakan bahwa saya ingin operator itu digunakan
skalar "- apakah itu ide yang baik (atau buruk) untuk mengecualikan angka - itu
sudah ditangani:

julia> print ("Páll", 1.0, 1)
HAL1.01
julia> string ("Páll", 1.0, 1)
"Páll1.01"

@PallHaraldsson Masalahnya adalah bahwa print dan string melakukan lebih dari sekadar penggabungan, mereka "merangkai" argumen mereka ... Saya tidak yakin bahwa itu harus terjadi _implicitly_ dengan operator penggabungan umum. Ini tidak terjadi dengan * saat ini ketika digunakan sebagai operator penggabungan string.
BTW, Anda perlu belajar cara mengutip sesuatu di sini dengan Markdown ... orang-orang di sini dengan ramah menunjukkan kepada saya bagaimana menggunakan kutipan tiga-belakang diikuti oleh julia di sekitar potongan kode Julia, dan meletakkan baris kosong setelah mengutip seseorang dengan > dan komentar Anda.
yaitu sesuatu seperti:

@tokopedia

Saya tidak pernah mengatakan bahwa saya ingin operator itu digunakan untuk skalar

apakah itu ide yang baik (atau buruk) untuk mengecualikan nomor - yang sudah ditangani:

julia> print("Páll", 1.0, 1)
Páll1.01
julia> string("Páll", 1.0, 1)
"Páll1.01"

@ScottPJones , sayangnya mengutip tampaknya tidak berhasil saat menanggapi oleh
email, bahkan jika Anda mengedit setelah fakta (uji ini di sini).

print("Hi GitHub!  Is this quoted")

@PallHaraldsson , berhati-hatilah saat menulis nama seseorang. Kamu
sebenarnya melakukan ping ke Scott Jones yang berbeda dalam pesan Anda, yang mungkin saja
bingung mendapat notifikasi dari kamu tentang julia.

Dalam kedua kasus tersebut, menggunakan antarmuka GitHub, daripada membalas melalui email,
membantu dengan kedua hal ini.

Pada hari Sabtu, 13 Juni 2015 pukul 5:24, Scott P. Jones [email protected]
menulis:

@PallHaraldsson https://github.com/PallHaraldsson Masalahnya ada
bahwa print dan string melakukan lebih dari sekadar penggabungan, keduanya
"merangkai" argumen mereka ... Saya tidak yakin itu seharusnya terjadi
_implicitly_ dengan operator penggabungan umum. Itu tidak terjadi
dengan * saat ini juga saat digunakan sebagai operator penggabungan string.
BTW, Anda perlu belajar bagaimana mengutip sesuatu di sini dengan penurunan harga ... orang
di sini dengan ramah menunjukkan kepada saya bagaimana menggunakan kutipan tiga punggung diikuti oleh julia
di sekitar cuplikan kode Julia, dan beri baris kosong setelah mengutip seseorang
dengan> dan komentar Anda.
yaitu sesuatu seperti:

@scottjones https://github.com/scottjones :

Saya tidak pernah mengatakan bahwa saya ingin operator itu digunakan untuk skalar

apakah itu ide yang baik (atau buruk) untuk mengecualikan angka - itu sudah
ditangani:

julia> print ("Páll", 1.0, 1)
HAL1.01
Julia> string ("Páll", 1.0, 1) "Páll1.01"

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/JuliaLang/julia/issues/11030#issuecomment -111706133.

Ugh ... Saya tidak tahu bahwa @PallHaraldsson merespons melalui email, atau email itu memiliki masalah itu (saya menggunakan aplikasi CodeHub ketika saya tidak berada di laptop saya ... ada masalah sendiri, tapi bukan itu).
Ya, itu Scott Jones yang sangat berbeda ... bahkan tidak dengan Scott A. Jones yang merupakan mahasiswa pascasarjana MIT ketika saya masih mahasiswa, yang juga tinggal di Arlington setelah itu!

LOL, ya, ini membingungkan! Saya telah bertemu "diri saya" beberapa kali selama bertahun-tahun, jadi ini bukan pertama kalinya kebingungan semacam ini terjadi. :)

Bersulang,

-Scott

Pada 13 Juni 2015, pukul 11:37, Scott P. Jones < [email protected] [email protected] > menulis:

Ugh ... Saya tidak tahu bahwa @PallHarald ssonhttps: //github.com/PallHaraldsson merespons melalui email, atau email itu tidak memiliki masalah itu (saya menggunakan aplikasi CodeHub ketika saya tidak di laptop saya ... itu punya masalah sendiri, tapi bukan itu).
Ya, itu Scott Jones yang sangat berbeda ... bahkan tidak dengan Scott A. Jones yang merupakan mahasiswa pascasarjana MIT ketika saya masih mahasiswa, yang juga tinggal di Arlington setelah itu!

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/JuliaLang/julia/issues/11030#issuecomment -111727642.

Untuk apa nilainya saya sebenarnya sangat suka * sebagai rangkaian string. Pertama, ini cocok dengan notasi yang digunakan dalam _Computability, Complexity, dan Languages_ oleh Davis et al. Ini juga memberi Anda penggabungan penjajaran secara gratis (bukan yang pernah saya lihat yang digunakan, itu hanya rapi). Saya menemukan diri saya menggunakan * sepanjang waktu, dan saya telah melihatnya digunakan di banyak tempat lain, jadi saya pikir skala kode churn untuk penghentian ini akan sangat besar, dengan (setidaknya IMHO) sedikit manfaat.

Saya pikir kita harus menyimpan * untuk string, tetapi mungkin menambahkan ++ nanti sebagai operator penggabungan umum (yang akan mendukung string serta hal-hal lain).

Kami dapat menambahkan ++ sebagai operator penggabungan urutan umum di masa mendatang, tetapi tampaknya seperti menghilangkan * dan ^ untuk string tidak akan terjadi. Saya akan mengatakan bahwa saya tidak lagi terlalu khawatir tentang "menghukum" pada * , saya juga tidak berpikir ini adalah pukulan lagi - dalam aljabar abstrak, perkalian (direpresentasikan sebagai * atau juxtaposition) sering digunakan sebagai operasi grup non-komutatif pada hal-hal yang bukan angka. Masalah utama di sini berasal dari kenyataan bahwa sebelumnya Char <: Number tetapi operasi * untuk Char tidak kompatibel dengan * untuk Number . Sekarang Char bukan subtipe dari Nubmer , itu tidak lagi menjadi masalah.

Saya akan menyimpan * untuk rangkaian string untuk alasan asli.

Inilah yang dikatakan Wikipedia tentang ekspresi reguler sebagai operasi aljabar:

Diberikan ekspresi reguler R dan S, operasi berikut di atasnya ditentukan untuk menghasilkan ekspresi reguler:
(concatenation) RS menunjukkan himpunan string yang bisa diperoleh dengan menggabungkan string di R dan string di S. Misalnya, {"ab", "c"} {"d", "ef"} = {"abd "," abef "," cd "," cef "}.
(pergantian) R | S menunjukkan gabungan himpunan yang dijelaskan oleh R dan S. Misalnya, jika R menjelaskan {"ab", "c"} dan S menjelaskan {"ab", "d", "ef"}, ekspresi R | S menjelaskan {"ab", "c", "d", "ef"}.
(Bintang Kleene) R * menunjukkan superset terkecil dari set yang dijelaskan oleh R yang berisi ε dan ditutup di bawah rangkaian string. Ini adalah himpunan dari semua string yang dapat dibuat dengan menggabungkan bilangan hingga (termasuk nol) string dari himpunan yang dijelaskan oleh R. Misalnya, {"0", "1"} * adalah himpunan dari semua string biner hingga ( termasuk string kosong), dan {"ab", "c"} * = {ε, "ab", "c", "abab", "abc", "cab", "cc", "ababab", " abcab ",…}.

Dalam aljabar linier, ada operator unary, operator adjoint, sering kali dilambangkan dengan * . Di Julia dan Matlab, operator adjoint diberikan dengan satu kutipan ( ' ), karena * umumnya digunakan untuk multplikasi. Jadi saya akan mengusulkan operator string di Julia menjadi ( *,+,' ) masing-masing untuk penggabungan, pergantian, dan bintang Kleene.

Seperti yang ditunjukkan @stevengj , argumen antara + dan pesaingnya adalah tentang konvensi, bukan kebenaran. Dan data @stevengj yang diberikan di atas telah dengan jelas membuktikan bahwa + sebagai operator penggabungan string adalah konvensi yang paling banyak diterima di dunia pemrograman (C ++ / C # / Java / Python / Javascript dan banyak lainnya). Dan semua pilihan lain tampaknya jauh lebih tidak umum, apakah sebagian orang lebih menyukainya atau tidak.

Maka alasan utama saya berpikir tentang menyimpan * adalah karena membatalkannya akan merusak kode yang ada seperti “abc” * “efg” . Adakah yang bisa menjelaskan apa lagi yang akan rusak + jika digunakan sebagai operator penggabungan string di Julia, untuk membantu saya memahami latar belakang dengan lebih baik? (Saya mengerti penggabungan string bukanlah operasi komutatif.)

Tidak ada yang akan rusak dan jika Anda benar-benar menginginkannya, Anda dapat menentukan + untuk melakukan ini. Namun, ini hanyalah matematika yang buruk. Dalam aljabar, + selalu merupakan operasi komutatif - dan penggabungan string tidak bersifat komutatif. Anda dapat melihat beberapa kebingungan yang disebabkan karena + tidak mengarah pada cara alami untuk mengulang string. Apakah Anda menulis "hi" * 5 atau 5 * "hi" ? Tidak ada yang benar-benar masuk akal. Bandingkan ini dengan * untuk penggabungan di mana sudah jelas bahwa Anda harus menulis "hi"^5 . Dalam kasus apapun, meskipun kami dapat memperkenalkan ++ untuk penggabungan (termasuk string), kami tidak akan menggunakan + untuk penggabungan string tidak peduli berapa banyak bahasa yang mungkin telah memilih sintaks ini.

Saya mengusulkan menggunakan . untuk string concat agar sesuai dengan PHP. Dengan getfield yang dapat kelebihan beban, itu bahkan dapat diterapkan secara sepele:

getfield(x::String, y::String) = string(x, y)
"a"."b"."c"

Kita bisa menggunakan .. untuk pengulangan " "..5

@ Stefan_karp
Terima kasih untuk penjelasannya! Sekarang saya lebih memahami tentang latar belakang.

(1) Jika * digunakan untuk penggabungan string, maka ^ akan menjadi operasi logis dan alami dari pengulangan string.
(2) Jika + digunakan untuk penggabungan string, maka * akan menjadi hasil logis dari pengulangan string.
Untuk opsi (1), saya setuju ^ adalah operator intuitif untuk pengulangan string. Untuk (2), bahkan * adalah hasil logis, mungkin masih belum cukup intuitif (mis. “Hi” * 3 == “hihihi”).

Apakah Anda menulis "hi" * 5 atau 5 * "hi" ?

Tidak, pengulangan string (operator apa pun itu) bukanlah operasi yang sering dilakukan bagi saya. Tapi penggabungan string adalah. Jika ini kasus umum, tampaknya mengganti operator pengulangan dengan fungsi bernama (mis. repeat , sudah didukung di Julia) masuk akal.

Dan saya menyadari membuat operator _new_ benar-benar hal yang dapat disengketakan / berbahaya, sementara mendukung lebih banyak API biasanya diterima :)

Edit: Menemukan utas lain yang memperkenalkan / dan \ untuk string. Dan ini membantu saya lebih memahami mengapa * dipilih untuk penggabungan string.