Julia: ide gila: ubah kata kunci `type`

Membuat kata type dapat digunakan dalam konteks lain akan sangat bagus.

Saya suka mutable untuk konsistensi.

Jika ini dilakukan, itu harus dilakukan SECEPATNYA sehingga dapat dimasukkan dalam 0.6

Jika ini akan terjadi, daripada menggunakan apa yang dikenali semua orang sebelum berpikir: struct

Saya juga berpikir type agak canggung. Ketika saya menjelaskannya kepada orang lain, saya biasanya mengatakan "like a struct" jadi +1 untuk itu.

Jika ini akan terjadi, daripada menggunakan apa yang dikenali semua orang sebelum berpikir: struct

Saya pikir immutable seperti struct?

+1 untuk mutable

immutable memiliki tata letak memori dari sebuah C struct
type memiliki mutabilitas dari C struct

Jadi struct terkait dengan keduanya. Saya pikir mutable daripada struct lebih baik untuk menjelaskan ini.

Variabel apa pun bisa berubah. Menetapkan label itu ke nama yang dikenal secara universal ( struct ) sudah jelas bagi saya.

Untuk seseorang yang berasal dari Fortran, kata kunci type sudah wajar.
Untuk seseorang yang berasal dari C kata kunci struct akan menjadi wajar.
Untuk seseorang yang menggunakan immutable banyak, kata kunci sebaliknya mutable akan menjadi wajar.

Jadi mungkin kita harus membiarkannya apa adanya.

struct{mutable}
struct{immutable}

atau

record{mutable}
record{immutable}

jika diinginkan bentuk yang lebih deskriptif.

Jika kita menggunakan struct maka sintaks untuk immutables dapat menjadi immutable struct (dengan bagian struct menjadi opsional setidaknya pada awalnya).

Saya menduga programmer Fortran akrab dengan istilah "struct".

+1 untuk mutable karena konsistensi. Jika struct dipilih, bukankah konsistensi akan mendikte perubahan tetap menjadi sesuatu seperti const struct ? ;)

Saya pikir struct dan immutable struct sebenarnya cukup bagus; struct adalah istilah yang sangat familiar dan kita hanya perlu menambahkan satu kata kunci baru. Mengizinkan mutable struct mungkin masuk akal juga, meskipun itu tidak sepenuhnya diperlukan.

Saya harus menjelaskan bahwa menurut saya struct menjadi kata benda adalah keuntungan. Akan lebih baik jika tidak hanya menggunakan kata sifat untuk menamai hal-hal ini.

Harus menambahkan struct ke immutable struct menambahkan derau baris yang tidak perlu, terlebih lagi karena tidak perlu mengetik ini.

Otoh, saya yakin Fortran memiliki kata kunci type yang melakukan sesuatu yang sangat mirip dengan yang kami lakukan. Namun, saya tidak menolak untuk mengubah ini.

@KristofferC di atas benar: Saya juga mendapati diri saya mengatakan "struct" ketika menjelaskan apa ini. Bahkan dalam diskusi internal type telah menjadi masalah; seseorang akan berkata "misalkan x adalah tipe", dan tidak jelas apakah itu berarti "hal yang dideklarasikan dengan type kata kunci" atau "tipe" dalam arti lain.

Jika nama-nama ini benar-benar ada di atas meja ( s/type/new name/ tampaknya sedikit menjengkelkan), saya sarankan kita mungkin ingin memanfaatkan kesempatan ini untuk membuat deklarasi default menjadi tidak berubah.
Jadi struct akan menggantikan immutable , dan mutable [struct] akan menggantikan type.

Sekadar pemikiran, istilah lain yang mungkin untuk bisa berubah mungkin juga Ref .

Nama lain yang mungkin adalah composite , karena istilah CS umum untuk ini adalah tipe gabungan . Tapi saya masih lebih suka mutable Foo dan immutable Foo ke mutable struct Foo dan immutable struct Foo - struct (atau composite , atau class , atau apa pun) tampaknya tidak berguna.

: +1: ke kata benda

Saya selalu menyukai type lebih dari struct di Julia (meskipun latar belakang saya _C_), karena tipe data Julia jauh lebih kuat dan halus dan menurut saya "struct" mungkin sedikit sederhana untuk idenya. Saya juga merasa karena ini adalah bahasa baru, kami tidak boleh terikat oleh konvensi yang biasa digunakan oleh programmer berpengalaman - Anda juga harus mempertimbangkan "apa kata terbaik untuk menjelaskan hal ini kepada orang yang bahasa pertamanya adalah Julia".

Saya juga menemukan diri saya mengatakan "struct" saat menjelaskan apa ini

Bayangkan memperkenalkan pendatang baru ke struct T lalu memberi tahu mereka T::DataType dan Anda dapat mengirim menggunakan ::Type{T} , sambil menjelaskan "sistem tipe yang hebat" dari Julia. Saya pikir ini hanya menendang ember lebih jauh di jalan.

menjadi kata benda adalah keuntungan

: +1: ke kata benda

Mungkin perlu dicatat bahwa kata sifat keluarga bahasa Latin seperti "bisa berubah" secara gramatikal juga diperbolehkan menjadi kata benda dalam bahasa mereka sendiri. Itulah mengapa ketika kita bertanya "apa bentuk kata benda yang bisa berubah" kita mengangkat bahu. Tapi kami selalu mengatakan "variabel" dan dalam bahasa Julia saya akan mengatakan "mari kita perkenalkan yang tidak berubah untuk ini". Sayangnya awalnya terasa canggung karena akar bahasa Jerman dari tata bahasa Inggris - tetapi ini sering terjadi dalam bahasa Inggris (karena kami juga didasarkan pada bahasa Prancis dan Latin) tetapi Anda akan terbiasa seiring waktu.

Terakhir, karena topiknya adalah "ide gila", kata kunci ini kurang lebih membuat DataType jadi dapatkah kita menghapus kata kunci seluruhnya dan hanya menggunakan konstruktor?

# Similar-ish to current
MyType = DataType(
    a::Int,
    b::Float64
)

# A DataFrame-like constructor
MyType = DataType(a = Int, b = Float64)

Saya kira ini harus diurai secara khusus (secara statis) seperti ccall adalah dan mereka hanya dapat dipanggil di tingkat atas untuk saat ini. (Juga - tidak yakin apakah kita membutuhkan Mutable <: DataType dan Immutable <: DataType dan BitsType <: DataType untuk menutupi semua kemungkinan, dan mungkin const untuk penjilidan).

Saya pikir kekal seperti struct?

immutable memiliki tata letak memori dari C struct
tipe memiliki mutabilitas dari sebuah C struct

Benar ... Saya pikir saya sedang memikirkan Swift, di mana:

Ini adalah perbedaan terbesar antara struct dan class. Struktur disalin dan kelas direferensikan. ... Jadi, mereka akan diteruskan sebagai nilai bukan sebagai referensi dalam kasus benda besar.

yang terdengar seperti immutable vs type , dan ini hanya referensi yang memungkinkan mutabilitas dalam konteks semantik binding Julia.

DataType mencakup semua tipe nominal: abstract , bitstypes, struct tidak berubah dan berubah. Jadi tidak menambahkan banyak kejelasan untuk mengganti type dengan DataType . Saya juga menarik kesimpulan yang berbeda dari skenario "pendatang baru": ::Type dan ::DataType pilih superset dari hal-hal yang ditentukan oleh type T , jadi tidak gila bagi mereka untuk memiliki nama yang berbeda . " struct adalah salah satu jenis Type " lebih masuk akal daripada " type adalah salah satu jenis Type ".

Saya setuju kata sifat dalam praktiknya bisa berfungsi sebagai kata benda. Seseorang dapat mengatakan misalnya "ini adalah kekekalan". Saya hanya berpikir mereka tidak cukup deskriptif. Alih-alih memberi tahu Anda apa _is_, itu hanya memberi tahu Anda bahwa apa pun itu, Anda dapat / tidak dapat memutasinya.

Saya suka structure dan mutable structure untuk tipe. mungkin a = 1 dan mutable a = 1 untuk tugas variabel. Melontarkan gagasan menginginkan konsistensi, tidak ada singkatan, dan kekekalan secara default.

Edit: mungkin constant bukannya const dalam kasus default bisa berubah

Atau versi yang melibatkan memiliki lebih sedikit kata kunci akan menjadi struct vs. const struct . Membuat semua variabel secara default akan terlalu mengganggu saat ini.

Saya hanya berpikir mereka tidak cukup deskriptif. Alih-alih memberi tahu Anda apa itu, itu hanya memberi tahu Anda bahwa apa pun itu, Anda dapat / tidak dapat mengubahnya.

Itu poin yang bagus - tapi saya akan menganggap perilaku referensi vs perilaku "nilai" _much_ lebih penting dan menarik untuk dijelaskan daripada "apakah itu struct atau bitstype?" (kebanyakan karena bitstype tidak sering muncul - setiap tipe Julia yang saya buat adalah sebuah struct). Keabadian hanyalah konsekuensi dari semantik yang mengikat dan nilai yang lewat.

Untuk sepenuhnya menghilangkan kebutuhan akan struct vs bitstype kami juga dapat menyertakan ide ini dari @quinnj yang

immutable 32 Int32 <: Integer

atau Anda bisa memiliki bidang yang tidak dihias sebagai jumlah bit

immutable Int32 <: Integer
   32
end

yang (secara umum bila dicampur dengan bidang bernama) juga dapat berguna untuk memasukkan pengisi jika diperlukan.

Maka itu hanya pilihan antara tipe nilai (apa yang saat ini tidak dapat diubah) vs tipe referensi (apa yang saat ini bisa berubah - tetapi berpotensi dengan bidang const di masa mendatang yang merupakan alasan lain untuk tidak menyebutnya mutable ) dan nama yang sesuai diperlukan untuk membedakannya. Dan terakhir, menggunakan struct untuk tipe referensi nilai akan membingungkan pemrogram Swift ...

Memang benar bahwa bitstype telah hilang semuanya sejak immutable diperkenalkan. Tetapi ada lebih banyak hal yang perlu dibedakan daripada struct vs. bits: ada tipe abstrak, tupel (juga tidak dapat diubah), dan kemungkinan record yang tidak dapat diubah di masa depan.

Kami awalnya memilih immutable karena kami merasa itu akan menjadi fitur pembeda yang paling terlihat: tidak seperti objek lain, Anda tidak dapat memodifikasinya. Faktanya, mereka _tidak_ selalu diteruskan oleh nilai; kekekalan berarti Anda tidak dapat membedakannya. Beberapa immutable s dimasukkan ke dalam array dan objek lain, dan beberapa tidak. Kekekalan berarti bahwa perbedaan tidak menimbulkan masalah bagi kode julia biasa; ini hanya menjadi masalah ketika tata letak memori benar-benar penting, misalnya untuk interop C.

Faktanya, mereka _tidak_ selalu diteruskan oleh nilai

Poin bagus! Padahal, ada rencana untuk mengubahnya, bukan?

Saya rasa saya mengatakan Anda akan membutuhkan sekumpulan kata kunci yang terbukti di masa depan yang mencerminkan beberapa konsep bukti masa depan, karena kita semakin mendekati 1.0. Ketika immutable dimasukkan ke dalam garis, sepertinya itu adalah waktu yang wajar untuk mengganti namanya menjadi sesuatu yang berguna sehubungan dengan semantik yang dihasilkan (dan jika semantik tersebut membantu dengan FFI, itu lebih baik).

Saya tidak berpikir orang akan mendapatkan kata kunci definisi jenis konkret baru yang bingung dengan abstract , Tuple s dan "catatan" (yang, jika Anda bermaksud hal seperti tupel yang diusulkan dengan nama bidang, menurut saya Saya juga mendengar disebut sebagai "struct" sebelumnya ...).

Tujuan sebenarnya dari gagasan "pass by value" adalah untuk menjawab pertanyaan tentang apa yang terjadi ketika f(x) memodifikasi (dalam arti tertentu) x : apakah itu memodifikasi x pemanggil lewat, atau apakah modifikasinya hanya untuk lokal? Julia tidak pernah, dan tidak akan pernah (saya harap), jenis, argumen, atau fungsi yang berbeda sehubungan dengan perilaku ini. Semuanya "lewat berbagi". Bagi kami, pass-by-value hanya ada di level ABI, tetapi pembahasan itu hanya ada di bagian FFI manual. Saya tidak yakin kita akan pernah memiliki jenis tipe yang selalu diteruskan oleh nilai atau selalu sebaris, karena itu bisa berkinerja lebih buruk untuk objek besar.

Bagaimanapun, menurut saya immutable dan mutable adalah opsi yang layak untuk kata kunci.

Memang benar bahwa bitstype telah menghilang sejak immutable diperkenalkan

Sementara individu biasanya tidak perlu membuat bitstypes baru, perbedaan antara bitstypes yang ada dan yang umum tetap sangat signifikan pada tingkat primitif karena ABI untuk bitstypes ini sangat berbeda. Kebetulan sebagian besar waktu pengguna menginginkan struct yang tidak dapat diubah, bukan tipe bit, saat menentukan tipe data konkret baru.

FWIW, karena belum banyak dukungan untuk tidak mengubah sesuatu, saya pikir type dan immutable baik-baik saja.

(Sintaks do mengganggu saya, meskipun ... ;-)

Semuanya "lewat berbagi".

Saya bisa menghargai itu - dan terima kasih untuk diskusi.

Semuanya "lewat berbagi".

Pada catatan itu, hanya pengamatan - jika kita memiliki const kata kunci dalam deklarasi tipe maka immutable menjadi sama sekali tidak diperlukan:

type Complex{T}
    const re::T
    const im::T
end

(kompilator dapat menentukan bahwa tipe ini tidak dapat diubah secara otomatis, dan pengguna dapat memahami bahwa tipe const memungkinkan kita untuk mengkompilasi ke kode yang lebih cepat). Maka type atau struct masuk akal. setfield! dapat dinonaktifkan pada kolom const dalam kasus campuran.

Bagaimana dengan type dan const type ? - Kata kunci tipe terdengar lebih elegan bagi saya daripada struct dan dengan struct saya semacam mengasosiasikan tata letak memori teknis dan bukan ~ objek yang memiliki misalnya konstruktor dalam. Karena tipe kompositnya adalah '... sejauh ini tipe buatan pengguna yang paling umum digunakan di Julia ...', mungkin tidak seburuk itu jika 'tipe adalah satu jenis Tipe'? Dalam komunikasi menggunakan 'tipe komposit' harus menjelaskan, sama seperti yang saya katakan 'tipe abstrak'. Mengenai line-noise, 'tipe const' tidak lebih buruk dari 'tidak dapat diubah'.

Saya tidak yakin tentang perbedaan (sedikit) dalam arti const dengan variabel vs. jenis. - Bagaimanapun tipe dan kekal selalu memberi saya cegukan mental kecil. Senang melihat masalah ini di sini!

Masalah utama dengan menggunakan struct adalah bahwa orang mungkin secara alami membuat asumsi yang biasa mereka gunakan dari C / C ++ yang belum tentu benar di Julia, misalnya tipe komposit yang bisa berubah tidak disimpan oleh nilai dalam array sedangkan kekal adalah.

Paradigma apa yang direpresentasikan immutable lebih elegan daripada type ? Misalnya, secara atomis "mentransisikan" status beberapa kolom secara bersamaan tanpa memerlukan sinkronisasi primitif dengan membuat instance immutable baru dari aslinya dengan kolom yang diinginkan diperbarui.

Mengapa tipe harus dipisahkan menjadi dua kategori berbeda pada titik definisi mereka daripada titik pengiriman / penggunaannya (lebih seperti const dalam C ++)? Dengan hanya menggunakan type / struct / composite untuk mendefinisikan tipe komposit dan memperkenalkan konstruksi Immutable{T} untuk mempromosikan mutable menjadi immutable, kita dapat memiliki:

type CompositeType end
f(x::Immutable{CompositeType}) = x
a = f(CompositeType())
b = f(a)

Juga, dapatkah perubahan ke abstract dan bitstype dipertimbangkan di sini? AFAICT penggunaan "abstrak" adalah sebagai kata sifat, bukan kata benda. Setidaknya harus ada konsistensi linguistik di seluruh jenis kata kunci: semua kata benda, semua kata sifat, dll. bitstype mungkin lebih baik dinyatakan sebagai bits atau primitive .

Tolong, jangan ubah ini menjadi utas terbuka untuk membahas perubahan ejaan (atau semantik!) Kata kunci Julia. Pada titik ini, kapal telah berlayar dengan _behavior_ dasar type dan immutable . Satu-satunya pertanyaan yang diangkat di sini adalah apakah kita dapat memiliki ejaan type dan immutable yang lebih mencerminkan kesamaan mereka.

Saya terus mendukung mutable vs immutable , atau membiarkannya apa adanya, sebagai dua opsi paling masuk akal pada saat ini. Ada lagi yang akan mengganggu tanpa tujuan.

@andyferris Saya sangat suka ide itu; beberapa kombinasi dari struct dan const akan bagus. Jika kita melakukannya, saya juga ingin mengatakan const struct atau const type , (1) untuk menghindari keharusan menulis const pada setiap bidang, (2 ) jadi kami tidak perlu langsung menambahkan fitur baru dari kekekalan per bidang. Jika kita ingin menambahkan fitur itu, alangkah baiknya jika tersedia kosakata yang konsisten untuk itu.

Dalam komunikasi menggunakan 'tipe komposit' harus memperjelas

Salah satu teknik favorit kami untuk memberi nama adalah menjelaskan sesuatu kepada seseorang dalam satu kalimat, lalu memilih kata atau dua kata apa pun yang tampaknya paling berhasil. Jadi bagi saya ini akan menjadi pemungutan suara untuk composite .

Mengapa tipe harus dipisahkan menjadi dua kategori berbeda pada titik definisinya daripada titik pengiriman / penggunaannya (lebih mirip const di C ++)?

Itu mudah: untuk memberikan jaminan global. Dalam C ++, objek "const" masih bisa berubah di bawah Anda jika seseorang memiliki referensi non-const padanya.

Selain itu, dapatkah perubahan ke abstrak dan jenis bit dipertimbangkan di sini?

Buat proposal. Adapun bitstype , kata kunci tersebut sangat jarang digunakan jadi saya tidak ingin mencuri kata kecil yang berguna seperti bits untuk itu.

immutable -> const type sepertinya juga oke buat saya. Dikombinasikan dengan type -> composite atau struct , jika kita benar-benar ingin membebaskan type .

Saya tidak terlalu senang dengan semua kode churn yang akan terjadi, terutama karena tidak dapat didukung oleh @compat . Jika kita harus melakukan ini, saya pikir jalur peningkatan harus seperti (1) memperkenalkan sinonim kata kunci baru di 0.6 tetapi _don't_ deprecate the old (karena kurangnya @compat ), lalu (2) deprecate yang lama di 0,7.

Untuk bitstype , bagaimana kalau menyebutnya tipe primitive ? Nama saat ini agak mengganggu karena kemiripannya dengan an isbits composite type

Saya suka cara Julia sering menghindari beberapa singkatan gaya "def / func / elif" dari beberapa bahasa lain. (Dn w singkatan, kthx.) Jadi mutable menang atas struct untuk saya.

FWIW, OCaml menggunakan type untuk catatan dan varian (struct dan unions) dan alias. ML standar menggunakan datatype saya kira.

Simetri itu bagus, tetapi saya menemukan mutable tidak cukup deskriptif; immutable juga, dalam hal ini (saya suka ide const type ).

Seperti yang ditunjukkan Steve, ini akan menyebabkan perputaran kode yang sangat buruk di seluruh komunitas. Dan manfaatnya meragukan.

Saya pasti melihat kasing untuk const type ; itu akan menjadi kata kunci -1 bersih, dan memperjelas hubungan antara tipe dan tidak dapat diubah. Akan sangat menyenangkan bisa menggunakan type dengan cara lain. Tanpa manfaat itu, jauh lebih sulit untuk membenarkan perubahan. Namun memperbarui kode untuk ini seharusnya sangat mudah; sintaks type sedemikian rupa sehingga pada dasarnya tidak dapat digunakan dalam konteks lain.

+1 untuk composite / const composite .

Saya merasa bahwa primitive vs composite adalah pembeda yang hebat, dengan const kata kunci ditambahkan seperlunya.

Apakah kita memerlukan const primitive untuk membedakan dari beberapa bit yang dapat berubah (dan untuk konsistensi)? Jadi secara simetris kita akan melakukannya

primitive        # something new... 
const primitive  # bitstype
composite        # type
const composite  # immutable

Masalah menjadi tipe primitif yang bisa berubah harus diterapkan ... (tentu saja ini mungkin terjadi di kemudian hari, tetapi kami ingin bitstype -> const primitive _now_ jika itu terjadi menjadi sesuatu. Menjadi lebih sederhana, ini bisa menjadi target "latihan" yang baik untuk membawa mutables ke tumpukan, tapi saya bukan ahli dalam hal itu).

Demikian pula, gagasan untuk menambahkan const ke bidang individual komposit dapat dengan mudah diterapkan di kemudian hari, dan bahkan lebih baik, ini adalah perubahan yang tidak dapat dipecahkan.

Jika kita pergi ke sana, saya juga ingin bisa mengatakan const struct atau tipe const, (1) untuk menghindari perlunya menulis const di setiap bidang, (2) jadi kita tidak perlu menambahkan fitur baru dari kekekalan per bidang segera. Jika kita ingin menambahkan fitur itu, alangkah baiknya jika tersedia kosakata yang konsisten untuk itu.

Sangat masuk akal bagiku.

Saya mencari tipe data composite dan menemukan bahwa setidaknya Ada dan Visual Basic juga memasukkan tipe array di bawahnya. (Jika tidak, agak acak, ditemukan: Haskell: daftar dan tupel (namun definisi telah diminta); Python: daftar, tupel, dicts; Lisp: daftar, vektor, tabel hash, kelas yang ditentukan pengguna, struktur).

Jadi sekarang saya bertanya-tanya seberapa akurat komposit untuk struktur seperti type ? (Tapi saya bukan ilmuwan komputer, saya kurang kosakata / pandangan luas).

Hmm, itu mungkin benar: jenis khusus ini sepertinya selalu disebut struct, structure atau record (atau class atau object), dengan "composite" menjadi istilah yang lebih luas. Ada banyak contoh di http://rosettacode.org/wiki/Compound_data_type

Alangkah baiknya untuk memulihkan type sebagai pengenal dan menggunakan nama yang lebih spesifik. Kerusakan hampir setiap paket sepele yang ditulis sebelumnya ~ 0,6 akan sangat disayangkan, saya tidak yakin bagaimana menimbangnya.

Gagasan untuk menggunakan kembali kata kunci const cukup menarik karena menekankan kesetaraan dari variabel binding const pada lingkup global dengan const binding bidang di dalam yang tidak dapat diubah. Ini sepertinya penyatuan yang baik dan penamaan yang lebih baik daripada immutable .

Adapun nama untuk menggantikan type , struct tampaknya menghindari ambiguitas dengan cukup baik (saya sering menemukan frase "tipe yang bisa berubah" dan "tipe yang tidak bisa diubah" terdengar terlalu mirip).

Saya kira berikut ini terlihat cukup bagus:

struct A
    a::Float64
end

const struct B
    b::Float64
end

Alangkah baiknya untuk memulihkan tipe sebagai pengenal dan menggunakan nama yang lebih spesifik.

Saya menggemakan sentimen ini.

Jika kami akan mengubah nama, bagaimana deprecation tersebut akan ditangani? Akankah type dan immutable masih berlaku di 0.6 dan mungkin 1.0 dengan peringatan? Dapatkah Compat.jl menangani ini secara transparan. Cukup banyak literatur di internet (posting blog, tutorial, dll) akan menampilkan peringatan - gangguan kecil bagi pendatang baru.

Kami masih dapat memesan type dan immutable lebih lama dari biasanya untuk memudahkan transisi.

We are pre 1.0: Waktu untuk mengubah ini sekarang atau tidak sama sekali. Memiliki kata kunci lama yang tersedia lebih lama tentu bagus untuk memastikan transisi yang lancar. Saya tidak akan mencampurkan diskusi tentang penamaan yang sebenarnya dengan rasa sakit yang akan disiratkan oleh transisi.

Secara pribadi saya semua menyebutnya struct . Karena itu

Saya tidak akan mencampurkan diskusi tentang penamaan yang sebenarnya dengan rasa sakit yang akan disiratkan oleh transisi.

Jika perubahan itu terlalu menyakitkan, saya akan menentang perubahan itu. Sementara perubahan pre1.0 dapat dibenarkan, menimbangnya dengan gangguan yang disebabkan IMO adalah hal yang benar untuk dilakukan.

@stevengj memiliki saran yang baik tentang cara melakukan penghentian, dan sepertinya @amitmurthy memiliki kesimpulan yang sama (pertahankan kata kunci lebih lama dari biasanya). Meskipun kita semua telah menggunakan bahasa ini cukup lama, ini masih awal dan kita tidak perlu takut untuk membuat perubahan. Yang ini juga mudah dicari dan diganti.

Saya akan melanjutkan dan memberikan suara untuk struct . Saya pikir ini adalah salah satu perubahan yang akan menimbulkan banyak desas-desus dan keluhan, tetapi sebenarnya tidak terlalu sulit untuk memperbaiki paket / kode pengguna ... lakukan saja dan orang akan mengetahuinya.

immutable -> const type tampaknya merupakan jalan yang paling sedikit perlawanannya, dan IMO pasti harus dilakukan. Saya pikir ini menjelaskan hal-hal yang jauh lebih baik.

type -> composite lebih tepat daripada type tetapi kurang tepat dari struct , sementara jargon-y kurang dari struct (untuk programmer baru). Ini melewati Jeff 'tulis kalimat untuk menjelaskannya kepada pemula "tes dan memulihkan kata kunci type . Sisi negatifnya, saya tidak berpikir composite muncul dalam bahasa lain, jadi kami akan akan melakukannya sendiri.

type -> struct adalah yang paling tepat, tetapi mungkin structure akan lebih cantik daripada singkatan (Saya mencoba menganggap singkatan seburuk struct di tempat lain dalam bahasa dan muncul kosong - Saya kira eye() adalah tradisi yang cukup menjijikkan dari perspektif bahasa Inggris).

bitstype -> primitive masuk akal jika type diubah.

@tbreloff benar - pengembang inti telah menunjukkan selera yang baik di masa lalu dan, pada akhirnya, orang akan mengikuti petunjuk mereka. Lakukan segera!

Saya bertanya-tanya apakah, karena immutable harus menjadi standar kecuali Anda secara eksplisit perlu bermutasi, apakah penggantian namanya harus:

• immutable -> struct
• type -> mutable

Maka nama umum / yang diharapkan adalah praktik terbaik, dan ada nama yang eksplisit dan jelas untuk meminta mutabilitas.

Saya suka bitstype -> primitive juga ...

Saya tidak berpikir const harus menjadi default. Pengoptimalan yang mengurangi fungsionalitas seharusnya tidak menjadi default.

+1 untuk struct dan const struct .

Istilah composite sedikit lebih deskriptif tetapi struct pendek, dan sangat umum dikenal sebagai tipe komposit.

Saya lebih suka tidak mencuri kata sebenarnya untuk sesuatu yang jarang digunakan seperti bitstype . Mungkin primtype atau primitivetype ?

Jika kita tidak akan mengubah bitstype menjadi nama yang jelas lebih baik seperti primitive maka saya pikir membiarkannya apa adanya mungkin akan lebih baik.

-1 sampai struct . Saya tidak menggunakan istilah ini untuk menjelaskan apa definisi tipe kecuali saya sedang berbicara dengan programmer C, dan hanya untuk menyebutkan bahwa tata letak kompatibel dan untuk membandingkan / membedakan properti mereka.

-1 sampai const . C pergi ke arah ini dengan memiliki kata kunci yang sangat minimal, dan sekarang kami terjebak dengan banyak kata kunci yang memiliki makna peka konteks. Saya tidak benar-benar berpikir const adalah properti kunci dari tipe ini, tetapi mereka adalah tipe nilai (sebagai lawan tipe referensi).

Namun, pergi ke arah lain, bagaimana jika menggunakan kata kunci new ?

new abstract Abstract
new value Value <: Abstract
    Value() = new()
end
new primitive 8 BitsByte <: Abstract
new record Object <: Abstract
    Object() = new()
end
new function WhyNot # equivalent to `function WhyNot end`

Masalah dengan "tipe nilai" adalah bahwa itu adalah sesuatu yang hanya bisa dipahami oleh orang-orang yang cukup paham bahasa. Untuk pengguna baru, fakta bahwa bidang tidak dapat diubah adalah fakta _semantic_ yang langsung mereka hadapi; yang lainnya adalah detail implementasi. Jadi saya lebih suka const .

Saya mengerti ke mana Anda akan pergi dengan catatan , tapi sejujurnya saya pikir terminologi ini bahkan kurang umum daripada struct (bahkan jika Anda google "tipe catatan ruby" vs "tipe struktur ruby", atau mengganti python atau perl atau beberapa bahasa non-C lainnya). Ada juga masalah bahwa record adalah kata bahasa Inggris yang cukup berguna sehingga akan memalukan jika disimpan sebagai kata kunci, sedangkan struct sepertinya tidak diperlukan untuk hal lain dalam program.

struct sangat umum digunakan; melihat-lihat rosettacode itu digunakan oleh:

algol, C, C #, C ++, cadel, D, elixir, sebagainya, go, maxima, racket, rust, seed7, swift, visual basic ( structure )

record digunakan oleh:

ada, clojure, delphi, pascal, erlang, icon, modula-2, beberapa skema

record tampaknya lebih disukai dalam bahasa lama; hari-hari ini karena pemrograman fungsional menjadi lebih populer, ia cenderung mengacu pada catatan yang diketik secara struktural.

Menariknya, seed7 menggunakan new struct .

Agak sedih melihat struct (apakah tiga huruf tambahan untuk melengkapi kata benar-benar seburuk itu?) Membuatnya menjadi bahasa yang sejauh ini memiliki function bukan func , dan seterusnya. Itu bukan sesuatu yang akan ditolak oleh siapa pun, tetapi tetap saja ...

structure sebenarnya digunakan dalam PL / I dan visual basic. VB juga memiliki structure immutable . Namun struct sangat umum sehingga saya merasa ini hampir menjadi kata baru sendiri.

Saya ingin tahu apakah ada juga masalah penutur asli di sini. Bagi saya yang sangat terbiasa dengan kata struct dalam konteks ini adalah structure yang terasa lebih aneh. Untuk alasan yang sama func terdengar mengerikan dan function natural.

Bukankah struct menjadi istilah yang berdiri sendiri karena penggunaannya dalam berbagai bahasa pemrograman? Kata structure (setidaknya bagi saya sebagai orang Jerman asli) jauh lebih abstrak. Misalnya, hierarki tipe memiliki "struktur" tertentu.

func bagi saya bukan istilah yang berdiri sendiri tetapi hanya singkatan.

Func bagi saya bukanlah istilah yang berdiri sendiri melainkan hanya sebuah singkatan.

Bagaimana struct bukan hanya singkatan juga? Bukankah secara harfiah ini adalah kependekan dari struktur, atau apakah saya hanya salah paham? Anda hanya lebih terbiasa daripada func . Banyak hal yang "istilah mandiri" dan umum di banyak bahasa, tetapi itu tidak berarti bahwa Julia harus mengikuti tradisi jika lebih baik tidak melakukannya. Maka itu hanya pertarungan tentang apa yang lebih baik atau lebih buruk, dan itu hanya masalah selera.

Bagaimanapun, saya lebih suka mutable , jadi saya tidak terlalu peduli _too_ jika itu struct atau struktur. bisa berubah akan menghindari menulis const sepanjang waktu untuk apa yang sekarang menjadi immutable .

Tetapi, meskipun akhirnya menjadi struct atau bahkan strct atau stct atau strctr , sangat kecil kemungkinannya saya akan mengubah Julia untuk bahasa lain untuk pekerjaan saya, jadi ... :)

Maaf jika ini tidak masuk akal dalam bahasa Inggris: Tapi bukan struct singkatan dari construct . Setidaknya dalam bahasa Jerman, kata Konstrukt lebih masuk akal untuk mendeskripsikan tipe komposit.

Dalam bahasa Inggris tidak dapat membedakan apakah construct adalah kata benda atau kata kerja mungkin menghalangi penggunaannya dalam bahasa pemrograman berbasis bahasa Inggris :) Penggunaan huruf besar dalam bahasa Jerman sangat membantu di sana.

struct adalah kata-katanya sendiri dengan cara yang sama seperti TV, ASAP dan LOL adalah kata-kata. Saya jarang mendengar orang mengatakan "struktur". Menurut pengalaman saya, kata itu adalah "struct" baik lisan maupun tulisan.

BTW: Matlab menggunakan kata struct , jika ada bedanya.

OTOH, seperti disebutkan di atas, di C # dan Swift struct sesuai dengan tipe nilai (berlawanan dengan class ). Jadi, menggunakan terminologi serupa untuk tipe yang bisa berubah dan yang tidak bisa diubah tidak akan benar-benar membantu orang yang terbiasa dengan bahasa ini. Tidak yakin apakah itu poin yang menentukan ....

mutable / immutable terdengar seperti pilihan paling eksplisit, yang seharusnya sudah cukup jelas bagi pendatang baru.

Mengingat banyaknya bahasa berbeda yang menggunakan struct , menurut saya semantik identik tidak diperlukan untuk menggunakan nama itu.

Saya suka type dan const type yang terbaik, tapi itu tidak membebaskan kata kunci type . Karena saya tidak tahu apa yang direncanakan untuk type , saya tidak tahu berapa besar biayanya.

Tetapi karena bagian type sudah tersirat dalam abstract , mungkin menggunakan mutable dan immutable sendiri paling masuk akal. Dan itu kurang mengetik immutable struct dan sedikit perubahan (ketik -> bisa berubah).

struktur kata (setidaknya bagi saya sebagai orang Jerman asli) jauh lebih abstrak.

Sementara kami berdebat tentang bahasa, semua orang meremehkan jumlah singkatan yaitu struct . Ini adalah singkatan dari "struktur data". Demikian pula, saya akan mengatakan type adalah singkatan dari "tipe data". Saya berani mengatakan array atau buffer juga merupakan struktur data, seperti daftar tertaut, dan seterusnya, tetapi struct memiliki akar awal sebagai salah satu struktur data umum pertama dan dalam komputasi telah memiliki a arti yang lebih spesifik (dan karenanya bagi pemrogram asli bahasa Inggris atau sebaliknya, ini tidak terdengar abstrak seperti structure ).

-1 sampai struct . Saya tidak menggunakan istilah ini untuk menjelaskan apa definisi tipe kecuali saya sedang berbicara dengan programmer C, dan hanya untuk menyebutkan bahwa tata letak kompatibel dan untuk membandingkan / membedakan properti mereka.

Saya merasa seperti ini tentang struct . Saya merasa kami akan memperkenalkan istilah baru untuk Julia tanpa alasan khusus.

-1 sampai const . C pergi ke arah ini dengan memiliki kata kunci yang sangat minimal, dan sekarang kami terjebak dengan banyak kata kunci yang memiliki makna peka konteks. Saya tidak benar-benar berpikir const adalah properti utama dari tipe ini, tetapi mereka adalah tipe nilai (berlawanan dengan tipe referensi).

Jeff menjelaskan kepada saya (dengan sangat baik) di atas bahwa secara semantik kami tidak peduli jika sesuatu adalah nilai atau referensi atau apa pun - ini adalah detail implementasi bukan semantik dan di masa keemasan _kami tidak akan peduli_ di masa depan. Segala sesuatunya "diteruskan oleh berbagi" dengan cara apapun yang diinginkan kompilator (dengan beberapa jaminan FFI seperlunya). Dalam beberapa hari terakhir saya telah datang untuk menyebutnya "berbagi-demi-sihir" dan saya merasa ini telah menjadi wahyu bagi saya untuk mengurangi banyak tekanan mental yang (idealnya) saya tidak perlu memikirkannya ( @vtjnash Anda telah melihat bagaimana saya berjuang dengan nilai dan referensi dan bagaimana ini diimplementasikan oleh compiler dan GC dan seterusnya di paket dan utas lain).

Binding dapat berubah atau konstan (kami menggunakan const tetapi constant juga cukup lucu). Demikian pula, binding bidang di dalam tipe data komposit bisa berubah atau konstan. Inilah sebabnya mengapa saya menyarankan sebelumnya untuk melampirkan const secara eksplisit ke setiap bidang - itu membuat semantik sangat jelas (setidaknya bagi saya).

IMO kita tidak perlu menggunakan kata-kata mewah seperti "bisa berubah" dan "kekal" untuk membicarakan hal ini. Sesuatu bisa dipantulkan ke objek baru, atau itu konstan. Menghilangkan kebutuhan akan kata-kata bahasa Inggris yang rumit seperti struct dan immutable seluruhnya dari wacana kita tentang Julia (bukan hanya kode) harus dilihat sebagai hal yang baik (bahkan tujuan).

Saya juga merasa seperti "struct" adalah kata sendiri (artinya apa yang dimaksud dalam C) sedangkan "struktur" mungkin adalah "struktur data" - karena jika yang Anda maksud adalah tipe record, Anda akan mengatakan "struct". Tapi saya menunjukkan akar C saya di sini.

Ini juga dalam cadel umum; defstruct .

Mungkin lebih sepele daripada kebanyakan poin lain di sini, tapi selama kita bikeshedding: Ketika diucapkan dengan keras, frase immutable object dan a mutable object terdengar sangat mirip. Itu akan membuat percakapan tentang sistem tipe Julia lebih sulit daripada yang seharusnya. EDIT: Sepertinya ini sudah dibahas di utas ini .

+1 hingga type -> struct dan immutable -> const struct . Saya rasa saya belum pernah bertemu orang yang akan bingung dengan ini, terutama setelah penjelasan sepintas.

Mengganti type realistis untuk v0.6, dan tidak realistis untuk v0.8. Kita harus melakukan ini. Ini adalah kesempatan untuk memperhalus dan meningkatkan bakat alami Julia untuk komunikasi yang jelas dan kecepatan ekspresif. Jenis sangat banyak bekerja dengan baik membuat perangkat lunak yang berfungsi. Penamaan yang lebih baik untuk hal-hal tipik beresonansi dengan kuat dan akan membawa masa depan yang lebih bertingkat bagi Julia.

Saya sarankan meninggalkan struct tidak terpakai. Di C, struct adalah wadah sintaksis untuk urutan tetap bidang tipe-tetap. Julia bukan C, dan memasukkan C-isme ke dalam wacana Julian akan mendorong sifat singkat Julia di luar diskusi serius tentang penggunaan terbaik dan cara yang lebih baik untuk mengkonseptualisasikan aspek Julia.

Juga, "kekal" dan "bisa berubah" terlalu serasi secara visual. Kami bisa lebih baik.

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff Sebagai tambahan, sesuai standar komunitas , lebih disukai menyebut Julia sebagai "itu". Kupikir aku akan menyebutkannya. 🙂

@ararslan Panduan standar komunitas tentang Julia tampaknya telah berubah, sekarang menghindari penerapan kata ganti sastra. Terima kasih untuk mengingatkan saya pada hal ini. :jangkrik:

Menggunakan kata ganti wanita itu sendiri tidak buruk (dan tidak dapat dihindari dalam banyak bahasa), tetapi tampaknya banyak yang merasa tak tertahankan untuk beralih dari penggunaan istilah "dia" menjadi membicarakan tentang Julia sebagai teman kencan yang seksi, jadi tampaknya yang terbaik adalah hindari godaan sama sekali.

Terima kasih

Pada Kamis, 3 Nov 2016 jam 16.29, Stefan Karpinski [email protected]
menulis:

Menggunakan kata ganti feminin itu sendiri tidak buruk (dan tidak dapat dihindari dalam banyak hal
bahasa), tetapi tampaknya banyak yang merasa tak tertahankan untuk melompat dari penggunaan
istilah "dia" untuk berbicara tentang Julia sebagai kencan panas, jadi sepertinya yang terbaik
hindari godaan sama sekali.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258264451,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
.

Berkenaan dengan masalah yang sedang dihadapi, saya pribadi ragu-ragu tentang apa yang akan saya anggap sebagai perubahan terbaik. Tetapi tampaknya aneh bagi saya untuk berbicara tentang sistem _type_ Julia yang luar biasa dan kemudian menetapkan bahwa kata kunci yang digunakan untuk membuat suatu tipe sebenarnya adalah struct daripada type . Saya pikir ini mungkin mendorong orang untuk berbicara tentang tipe sebagai struct, yang pada akhirnya mengarah pada pergeseran bahasa yang digunakan untuk menggambarkan Julia, misalnya mendiskusikan sistem _struct_ Julia yang menakjubkan.

kata kunci yang digunakan untuk membuat tipe sebenarnya adalah struct daripada type

Tetapi kata kunci tidak benar-benar tentang membangun tipe --- misalnya ekspresi Tuple{Int} juga membangun tipe. Akan sangat bagus jika hal-hal yang saat ini didefinisikan dengan type selalu disebut sebagai struct s, karena itu tidak akan ada kebingungan tentang bagaimana Real adalah sebuah tipe, dan Union{Int8,Int16} adalah tipe, dll.

ya, saya mengedit catatan saya sebelumnya dan baru saja menulis tentang itu. Itu akan
sangat merugikan "perawatan dan pemberian makan" dari Julia dan
pengembangan kekuatan ekspresif dan keringkasan di masa depan. Haruskah pintunya
dibuka untuk membuat pertimbangan sah sistem tipe Julia sebagai
perancah pada struktur C, perang hilang.

Pada Kamis, 3 November 2016 jam 16.38, Alex Arslan [email protected]
menulis:

Berkenaan dengan masalah yang dihadapi, saya pribadi ragu-ragu tentang apa yang saya
akan mempertimbangkan perubahan terbaik. Tapi memang aneh bagiku untuk membicarakannya
Sistem _type_ Julia yang luar biasa dan kemudian tentukan kata kunci yang digunakan
membangun tipe sebenarnya adalah struct daripada tipe. Saya pikir itu mungkin
dorong orang untuk berbicara tentang tipe sebagai struct, akhirnya memimpin
ke pergeseran dalam bahasa yang digunakan untuk mendeskripsikan Julia, misalnya membahas bahasa Julia
sistem _struct_ yang luar biasa.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
.

Akan sangat bagus jika hal-hal yang saat ini didefinisikan dengan type selalu disebut sebagai struct s, karena tidak akan ada kebingungan tentang bagaimana Real adalah sebuah tipe, dan Union{Int8,Int16} adalah tipe, dll.

Apakah ada kebingungan tentang itu saat ini? Saya rasa itu sudah jelas bagi saya meskipun mungkin saya melewatkan diskusi tentang itu.

@ararslan : Istilah type terlalu umum untuk apa yang sedang dibangun. Apa yang saat ini kami buat dengan kata kunci type adalah struktur yang terdiri dari tipe gabungan. Tetapi ada banyak jenis lain dalam Julia yang tidak dibuat menggunakan kata kunci type .

Tidak, saya tidak berpikir ada terlalu banyak kebingungan tentang hal itu saat ini, tetapi semua orang juga tidak akan berpikir semua tipe julia adalah struct jika kita menggunakan kata kunci struct .

Oke, poin yang bagus.

dan Union {Int8, Int16} adalah sebuah tipe

Ah. Saya lupa bahwa Union juga ada. Yang mana yang membuat argumen untuk struct ( Struct ?) Lebih menarik, IMO. Namun tetap tidak suka mutable dan immutable .

Saya menganggap _struct_ memalukan dan benar-benar percaya membawa Julia ke sana, seiring waktu, akan menarik zeitgeist yang sedang berkembang ke bawah. Prinsipnya adalah antagonisme antara eksposisi bit yang bergerak dan ekspresi komputasi maybes sebagai perpaduan tingkat tinggi dan gestal yang lebih dalam. Bahwa menggunakan struct tidak akan membuat semua orang berpikir jenis struct tidak penting. ... biarkan aku mendramatisasi ...

Saya tidak dapat membantah bahwa menulis tentang Einstein sebagai juru tulis paten mengurangi apresiasi atas kontribusinya. Tidaklah berarti, dalam sebuah kursus di mana referensi ke Albert Einstein menekankan impor waktunya sebagai juru tulis paten, lebih dari sedikit siswa akan memahami beberapa pengertian itu dalam percakapan di masa depan. Bahwa suatu benda adalah so tidak menjamin ia hanya berperilaku so setelah pindah ke sekolah baru.

Jika ada kasus yang menarik untuk menggunakan _struct_, seharusnya ada kasus yang lebih baik untuk salah satu dari

structure adalah keterkaitan yang berarti dari bagian-bagian, komposisi informasi
construct adalah penataan relevansi yang berguna, desain peningkat nilai

structure dapat diubah adalah komposit perdurant
structure yang dapat disepakati adalah pemilihan pendahuluan yang tidak tetap
construct tidak dapat diubah adalah kemungkinan yang mapan
construct bisa berubah adalah batasan yang disengaja pada konteks

Kita membutuhkan cara bicara "bit di tempat dan melalui gerbang" dan "penataan data mengungkapkan informasi ontologis" dan itu dapat disediakan sebagai cara pengubah transformasi berbicara. Peserta komunitas yang merupakan bakat CS dan sebagian besar pakar domain lainnya yang memprogram secara luas memiliki pemahaman yang menyeluruh tentang byte, memori, logika, operasi yang diinstruksikan, dll. Cara lain untuk membuat keinginan, kreativitas, kemungkinan, dan imajinasi menjadi perangkat lunak yang bekerja dengan baik dan baik. sepadan dengan pekerjaan - yang dibagikan lebih sedikit. Keputusan apa pun tentang penamaan istilah harus diambil untuk mendorong pembicaraan itu.

Bagaimana dengan class dan immutable ?

Saya tahu kelas dari Delphi dan berpikir itu tidak mungkin terjadi di sini, tetapi dalam bahasa Nice, yang memiliki banyak metode, ini digunakan sebagai kata kunci ( tautan ). Dan - jika saya membaca manual dengan benar - juga di Haskell dan Dylan. Ia lulus tes "class is one kind of Type" dan masih cukup kabur (sebagai 'type' hari ini), sesuatu yang saya suka. Dalam video 'An overview of arrays and Iteration' pada pukul 15:00 - 15:20 menit, Tim Holy (secara tidak sengaja) mengatakan 'class', sebuah detail yang tidak penting tetapi bagaimanapun mungkin menunjukkan bahwa class tidak akan menjadi sangat asing dalam konteks Julia.

Jika tidak, reftype dan immutable ? Istilah reftype disebutkan dalam komentar awal dan telah diabaikan sejak itu. Mengapa? Bagi saya kedengarannya cukup bagus, membebaskan tipe dan menyampaikan makna referensi.

(Saya tidak mengerti tujuan kata kunci 'baru'. Tidak bisakah 'baru' ditinggalkan di semua baris tanpa perubahan? Istilah 'nilai' dan 'rekam' akan menjadi kata kunci dan menggantikan kata 'tidak dapat diubah' yang saat ini digunakan dan 'tipe', kan?)

@swissr satu-satunya perbedaan (yang harus diketahui oleh sebagian besar pengguna) antara kedua jenis ini adalah bahwa bidang di satu dapat berubah dan di bidang lain tidak bisa. Masuk akal jika nama mereka menunjukkan satu - isbits dengan referensi secara otomatis sebagai pengoptimalan, dan sebaliknya kecil yang bisa berubah dapat berpindah ke tumpukan dalam situasi tertentu).

Mengenai type vs struct , saya melihat bahwa saya dapat membuat tipe data abstrak dengan abstract , Union{} , typealias dan seterusnya ( dalam kasus Tuple{} itu bisa diperdebatkan jika itu tipe baru atau hanya tipe parameterized), tetapi sebenarnya satu-satunya tipe beton yang ditentukan pengguna_ dibuat oleh bitstype , type dan immutable . Sintaks untuk ini tidak salah lagi dengan definisi abstrak di mana mereka mendefinisikan data yang dikandungnya, dan yang abstrak tidak. Mengubah immutable menjadi const type tampaknya membuat situasi menjadi jelas bagi saya.

Saya khawatir tentang bahasa dan menyebarkan kata teknis struct dengan satu-satunya alasan adalah tradisi, ketika kita memiliki kesempatan untuk membuat bahasa pemrograman yang dibahas dalam istilah awam. Contoh di mana menurut saya ini tidak akan membantu adalah ketika saya membuat jenis pembungkus seperti Symmetric{Matrix{T}} - Saya tidak ingin diskusi saya menjadi, "Saya membuat struct hanya dengan satu bidang yang ... "ketika saya dapat mengatakan" Saya membuat Symmetric pembungkus type untuk Matrix "(perhatikan bahwa setengah dari kalimat itu adalah sintaks yang sebenarnya). Sebuah "struktur pembungkus"? Kedengarannya konyol - dan siapa yang membuat struct dengan satu bidang? Dalam hal ini, bagaimana dengan lajang tanpa bidang? Bagian yang cukup besar dari types dan immutables tidak didefinisikan untuk membuat struktur data (non-sepele) apa pun melainkan dengan tujuan yang jelas untuk menggunakan sistem tipe dan pengiriman yang kuat dengan pembungkus dan lajang. IMO ini adalah aspek Julia yang paling menarik, kuat, dan ekspresif (dikombinasikan dengan fakta bahwa itu adalah _fast_).

Saya merasa kekuatan penuh dari struct hanya akan segera terlihat oleh pemrogram metaprogram C ++ berpengalaman yang tahu mereka dapat menerapkan sifat, dll, dengan struct, dan itu sedikit memalukan.

"Jenis" memiliki arti teknis yang cukup spesifik dalam teori tipe.

Jika tujuan / keuntungannya adalah untuk membebaskan type lalu bagaimana dengan:

const datatype  # immutable
datatype        # type

Mereka adalah tipe konkret sehingga mereka mungkin berisi data, dan ini adalah salah satu (dari banyak) cara untuk membangun DataType .

"Jenis" memiliki arti teknis yang cukup spesifik dalam teori tipe.

Pengenalan ke wiki terdengar persis seperti Type{} (yang menerima DataType dan TypeConstructor , Union , dll) (EDIT: bukan berarti saya menganggap perubahan seperti itu sepadan dengan gangguannya)

kind bukanlah kata yang tepat di sini.

Saya merasa bahwa paling sering pendekatan terbaik adalah hanya mempelajari suatu bidang
kosa kata standar alih-alih mencoba menggantinya dengan sesuatu yang Anda sendiri
tebakan akan lebih mudah.

Keputusan ini tidak mempengaruhi pidato informal. Anda masih bisa dengan bijaksana mengatakan "Saya
menentukan jenis ". Menggunakan kata kunci yang lebih spesifik hanya akan mempermudah saat
Anda harus tepat.

Poin yang adil, Jeff. Harap perhatikan bahwa menurut saya const struct dan struct akan menjadi peningkatan lebih dari immutable vs type (tetapi itu tidak berarti kita tidak boleh mencari sesuatu yang lebih baik).

Ketika Anda berpikir bahwa struct lebih mempersepsikan sebagai struktur atau sebagai konstruksi, tidak ada atau keduanya?

@andyferris komentar 'class' dan 'reftype' saya tidak berarti bahwa saya juga tidak suka 'const type' atau tidak mendukung bahwa const struct dan struct akan menjadi peningkatan. Itu adalah upaya lain untuk mencari istilah yang mungkin ketika ingin menghindari 'const', pertahankan 'immutable' dan simpan 'struct' (mengetahui implementasi yang disebutkan tetapi berpikir, jika itu benar, katakanlah 80% lebih kasus itu baik-baik saja) .

Bagaimana dengan fieldtype (atau fieldstype )? Ini sejajar dengan bitstype dan konsisten dengan fieldnames() .

Lembah kecil,
Saya suka verisimilitude. fieldstype adalah pilihan yang lebih baik karena menggunakan bentuk jamak di mana sesuatu bisa tunggal atau jamak adalah tepat.
--Jeffrey

class mungkin baik-baik saja; kami awalnya menolaknya karena asosiasinya dengan OO berbasis kelas dengan metode di dalam objek. Saya akan mengatakan struct lebih akurat.

Saya tidak melihat struct sebagai kependekan dari apa pun; hanya apa jenis struktur data ini disebut pada saat ini. Agak lucu, cadel memiliki cons , yang semula mungkin merupakan singkatan dari construct , tetapi orang-orang segera melupakannya dan baru saja mulai berbicara tentang "sel kontra".

Saya pikir kita harus terus menolak class . Menggunakan istilah itu akan mengundang banyak ekspektasi OOP yang bertentangan dengan gaya Julia.

Saya tidak melihat struct sebagai kependekan dari apa pun, tetapi saya khawatir bahwa referensi implisit ke struct C menyiratkan bahwa Julia akan menjadi tipe nilai, yang sebenarnya bukan tipe nilai. Untuk itu, saat ini saya sedikit condong ke record karena konotasi langsungnya jauh lebih sedikit.

Untuk memperjelas poin yang mungkin tidak jelas, saya pikir menggunakan const record atau const struct hanya layak jika ditafsirkan dalam arti singkat untuk memetakan const di semua bidang , menyiratkan bahwa kami ingin mendukung penandaan bidang individu sebagai const . Jadi yang saya katakan adalah kita bisa mendapatkan ini:

record T0
    f::A
    g::B
end

record T1
    const f::A
    g::B
end

record T2
    f::A
    const g::B
end

record T3
    const f::A
    const g::B
end

const record T4
   f::A
   g::B
end

Di sini T3 dan T4 sebenarnya mendeskripsikan tipe yang setara - yaitu menulis const record hanyalah singkatan dari semua field menjadi const . Jika ini bukan interpretasi maka saya pikir penggabungan kekekalan dengan ketetapan agak berbahaya karena ini sudah menjadi sumber umum kebingungan konseptual dan jika kita menambahkan kebingungan terminologis itu, kita tidak akan membantu masalah.

Di sini T3 dan T4 sebenarnya mendeskripsikan tipe ekuivalen - yaitu menulis record const hanyalah singkatan dari semua field yang menjadi const.

Jika kita menghasilkan const record artinya immutable sekarang, ini mungkin tidak benar. const record akan mendeskripsikan tipe referensi yang tidak ada isinya yang dapat diubah. Sedangkan immutable ini adalah tipe nilai.

Lihat https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 dan komentar berikut untuk beberapa diskusi tentang record .

@vtjnash Itu poin yang bagus, tapi ini mirip dengan yang terjadi sekarang di mana immutable menjadi tipe "referensi" jika mengandung referensi.

Saya pikir fakta bahwa record kurang umum tidak apa-apa, fakta bahwa itu adalah kata yang berguna karena kata benda dan kata kerja lebih bermasalah.

Bagaimana dengan nuple ? Singkatan dari "tuple bernama", tentu saja.

Saya suka saran yang dibuat di atas

const datatype  # immutable
datatype        # type

terbaik sejauh ini. Ini menghindari memasukkan kata lama dengan beban sejarah dan tampak sangat jelas bagi saya. Tentu itu bukan satu-satunya tipe data di julia tetapi itu adalah yang paling umum yang ditentukan oleh pengguna normal.

Adakah rencana juga untuk mengubah terminologi penjelasannya di dokumentasi, lebih tepatnya mengganti judul bab seperti ini ? Jika tidak, saya rasa saya paling suka composite dan immutable composite atau const composite . Karena const juga digunakan untuk konstanta global, saya akan memilih const atau immutable untuk keduanya, dengan sedikit preferensi untuk const karena itu singkat. Setidaknya kata komposit tidak akan terlihat asing bagi kebanyakan pendatang baru, memaksa untuk melihat dokumentasi dan menghindari asumsi yang salah karena kemiripan dengan nama C. Asumsi yang salah tentang const tampaknya kecil kemungkinannya, karena siapa pun yang terbiasa dengan itu di C ++ tahu untuk tidak berasumsi apa-apa.

Juga keuntungan menggunakan dua kata untuk menunjukkan keabadian membebaskan kemungkinan masa depan const abstract dan const bitstype jika diperlukan.

Jika kita membuat catatan const berarti apa yang tidak dapat diubah sekarang, ini mungkin tidak benar. catatan const akan mendeskripsikan tipe referensi yang tidak ada bidangnya yang dapat diubah. Sedangkan current immutable adalah tipe nilai.

Uh oh. Saya pikir nilai-atau-tidak-ness dari immutable didefinisikan pada tingkat implementasi, dan semua pengguna yang dimaksudkan untuk mempertimbangkan adalah bahwa bidang tidak dapat dipulihkan. Meneruskan nilai (atau tidak) kemudian menjadi masalah ABI murni, di mana kompiler pada prinsipnya harus bebas memilih apa pun yang lebih efisien. Bagi saya, semantik yang terlihat dari pengguna yang tidak dapat diubah tampaknya sama persis dengan menerapkan semantik saat ini dari const ke semua bidang jenis.

Apakah saya _masih_ bingung tentang semantik tingkat pengguna yang dimaksudkan dari immutable, atau apakah Anda membicarakan detail implementasi di sini?

Bagaimana dengan nuple? Singkatan dari "tuple bernama", tentu saja.

Mungkin sebaiknya pergi dengan record , bukan? Misalnya, tupel bernama adalah record di Erlang. Dan saya pikir di dunia database juga.

Tetapi jika Julia lebih sering tumpang tindih dengan orang-orang yang juga tahu C , struct adalah perubahan yang lebih tepat.

Saya pribadi menemukan record agak aneh dan tidak jelas. Dalam dunia database, record adalah baris dalam tabel; yang sepertinya akan menjadi konflik yang membingungkan dengan sesuatu yang umum seperti tipe Julia (tidak dapat diubah atau sebaliknya).

Setelah membaca ulang utas ini, saya cenderung menggunakan composite untuk type . Ini memegang Jeffs "aturan satu kalimat" dan belum ada begitu banyak suara negatif untuk itu. Bahwa istilah tersebut tidak begitu banyak digunakan dalam bahasa lain, menurut saya tidak menjadi masalah. Dan composite benar-benar merupakan kata paling deskriptif yang dapat ditemukan orang untuk itu. Itulah alasan mengapa dokumentasi menyebut hal-hal ini sebagai composite types .

Berasal dari Fortran saya masih berpikir bahwa kata kunci type baik-baik saja,
dan perubahan minimum yang masuk akal adalah immutable -> const type .

Tetapi jika type benar-benar harus dihilangkan,
composite dan const composite tampaknya menjadi pilihan terbaik berikutnya.

immutable -> const type tampaknya dapat dijalankan: ini secara bersamaan menghindari gangguan, menghapus kata kunci, dan menambahkan kejelasan pada bahasa.

Mungkin sedih tidak bisa menggunakan type tapi jujur ​​saja yang ingin saya gunakan adalah Type . Sembilan dari sepuluh variabel tipe saya adalah parameter untuk pengiriman statis, bukan variabel DataType untuk analisis tipe dinamis (kecuali fungsi yang dihasilkan). Tidak benar untuk orang yang menulis inference.jl tetapi mereka sebenarnya bukan "target audiens" dari bahasa tersebut, jika Anda mau.

Pertanyaan terkait: apakah layak untuk menggunakan type seperti pada tingkat atas, tetapi di dalam fungsi (yang selalu tidak valid, saat ini) memungkinkannya menjadi nama variabel? Atau bahkan lebih jauh lagi, struktur definisi tipe cukup spesifik ... dapatkah kita mendeteksi definisi tipe sebagai sintaks spesifik sementara membiarkan variabel global (atau fungsi) terikat ke type ?

Yaitu dapatkah kita menyingkirkan perilaku kata kunci sambil mempertahankan sintaksis untuk mendefinisikan suatu tipe?

(kemungkinan besar) ada risiko kuat yang melekat: leksikografi idiosinkratik menjadi terlalu mudah untuk mengalihkan perhatiannya. Dan kontinuitas mikro yang hilang itu merusak kemudahan dengan kolaborasi dan komunikasi yang jelas.

@ c42 :

Apakah saya masih bingung tentang semantik tingkat pengguna yang dimaksudkan dari immutable, atau apakah Anda membicarakan detail implementasi di sini?

Tidak, Anda tidak - saya sedang ceroboh. Yang tidak bisa diubah sebenarnya bukan tipe nilai, tapi bisa saja tidak dan saya merasa bahwa menggunakan istilah yang sama dengan C mungkin menyarankan demikian.

Saya baru menyadari bahwa dalam konteks C tidak jelas apakah masuk akal untuk memanggil struct "tipe nilai", karena situasi sebenarnya adalah bahwa C adalah bahasa nilai yang lewat. Jadi bisa dibilang itu adalah konvensi passing dan assignment yang berbeda, bukan tipe datanya sendiri.

Saya sepenuhnya mendukung pemberlakuan perubahan yang dibuka masalah ini. Kegunaannya melebihi preferensi visceral yang digunakan salah satu istilah kandidat daripada istilah kandidat lainnya.

_meskipun_

karena situasi sebenarnya adalah C

menangkap dengan baik mengapa, dari istilah kandidat, struct adalah yang paling tidak saya sukai

Inilah cerita yang saya jual: "Di C dan Julia, struct adalah struktur data yang memetakan sekumpulan tetap nama bidang ke nilai dari berbagai jenis. Tapi ketika Anda menyebarkannya, C berlalu -by-value dan julia pass-by-sharing. "

Akun itu tidak memberatkan dan sepenuhnya akurat. Semua yang ada di dalamnya dapat berhasil di Google. Tidak ada ahli teori PL yang akan mengeluh tentang hal itu, dan ahli teori non-PL akan belajar sesuatu dengan mendengarkannya.

Saya percaya cerita itu. Meskipun saya bertanya-tanya, apakah ada istilah yang disebutkan di sini yang dikeluhkan oleh ahli teori PL? Saya suka berpikir bahwa Julia cocok dalam ceruk yang memuaskan baik ahli teori PL maupun non-teori, jadi keseimbangan antara kebenaran dan kejelasan umum di sini tampaknya penting.

Nah, saya tidak ingin mengucapkan kata-kata ke mulut siapa pun; Saya hanya ingin membahas gagasan bahwa struct bisa membingungkan karena struct menjadi "tipe nilai".

Saya pikir immutable harus tetap menjadi kata kunci tunggal. Saya tidak suka const type atau const struct atau immutable struct . Saya menggunakan immutable banyak dan saya pikir akan sangat aneh jika deklarasi ini menjadi dua kata ketika hampir semua yang lain adalah satu kata. Bukan dalam arti mengetik, karena itu bukan masalah nyata; namun dalam artian memiliki kekal seperti "tag" membuatnya terasa berkelas.

@TotalVerb Saya tidak merasa itu sangat cocok dengan fakta bahwa

type MyType
    const field::Int
end

harus berperilaku persis seperti

immutable MyType
    field::Int
end

lakukan sekarang.

Mengingat bahwa, memiliki const type (atau const struct , const composite , atau apa pun) menyiarkan const ke setiap bidang sebagai pintasan tampaknya berguna (meskipun tidak sepenuhnya diperlukan). Saya berharap bahwa di masa depan compiler tidak akan tahu yang mana yang Anda ketikkan ( const type atau const di depan setiap bidang - yang pertama dapat diubah menjadi yang terakhir oleh parser). Pada titik itu, mengapa menyimpan immutable ?

memiliki kekal seperti "tag" membuatnya terasa seperti kelas dua.

Jika saya memahami Jeff dan Stefan dengan benar, ya, immutable hanyalah sebuah tag yang mengatakan bahwa bidang dari suatu tipe adalah binding konstan. Menjadi konstan (_really_ constant, tidak seperti C) membantu compiler melakukan pengoptimalan, dan jika field itu sendiri adalah konstanta atau primitif secara rekursif (yaitu isbits ) itu membantu kompilator membuat lebih banyak pengoptimalan. Ini bagus untuk diketahui, tetapi tidak penting secara semantik. Mengikat semantik ke perilaku saat ini mungkin akan mempersulit perbaikan perilaku tersebut di masa mendatang.

Tetapi ada perbedaan semantik yang penting: tipe yang tidak dapat diubah adalah nilai, dan dengan demikian orang dapat dengan aman berasumsi bahwa identitas objek ditentukan oleh bidangnya. Objek dengan tipe yang tidak dapat diubah, dari sudut pandang pengguna, tidak memiliki "fitur pengenal" khusus yang tidak dapat diakses dari bidangnya. Di sisi lain, objek apa pun dari tipe non-singleton yang bisa berubah, jelas memiliki "identitas" yang tidak terlihat ini. Fakta bahwa banyak tipe yang tidak dapat diubah disimpan sebagai objek dalam kotak, dan karenanya memang memiliki identitas tambahan ini secara internal, tidak relevan dengan semantik.

Menurut pendapat saya, ini bukan hanya _optimisasi_ yang harus dilakukan

immutable Complex{T} ... end

dari pada

type Complex{T} ... end

karena banyak aspek dari perubahan perilaku yang terlihat oleh pengguna: === , default == , objectid , hash , dll. Tidak benar untuk mengatakan itu tipe yang tidak bisa diubah menyediakan subset dari fungsionalitas tipe yang bisa berubah; sebaliknya, fakta bahwa mereka tidak dapat diubah memberikan jaminan penting yang memungkinkan tipe yang tidak dapat diubah menjadi lebih kuat.

Sebelum komunitas memilih const dan struct , saya hanya ingin membuat satu steker lagi untuk constant dan structure .

1) Hanya tiga huruf tambahan untuk kata-kata yang sebenarnya!
2) Meskipun ada klaim bahwa struct telah menjadi idiomatis
2a) Seseorang yang bermigrasi dari R (seperti saya) mungkin bingung
2b) Seseorang yang baru mengenal pemrograman (mereka yang paling membutuhkan bantuan) mungkin bingung

Hanya untuk iseng, kata-kata konyol yang struct mungkin membingungkan:
hal tdk dpt dihancurkan
obstruksi
pasca-strukturalisme
superstruktur (oh hi Marx)

dan const:
Konstantinopel
konstelasi
ular sanca ular piton
inkonstitusionil

Adakah keindahan / kekuatan PL yang diperoleh oleh multikontekstual yang tidak dapat diubah dan konstanta semacam ini: tidak pernah berubah tidak pernah menyiarkan (memproyeksikan sifatnya) melalui / di dalam rujukannya yang terselesaikan dan penyiaran konstan melalui rujukan tertanam yang tidak dapat diubah, seolah-olah itu adalah kata keterangan atau gerund?

Pertanyaan yang sama, dengan kata lain:

Untuk saat ini, menggunakan variabel dalam lingkup global bermasalah dan trick untuk dikerjakan adalah membungkus nilai yang bervariasi dalam vektor const dengan satu entri. Dalam hal ini const tidak disiarkan. Versi penyiaran const akan berlaku? Menyiratkan keteguhan nilai entri dalam vektor dan juga vektor. Demikian pula, deklarasi tipe yang memiliki bidang yang mungkin menyimpan nilai yang membungkus atau menyertakan jenis nilai lain. Jenis yang tidak dapat diubah sekarang tidak memberikan keabadian pada nilai bidangnya (dan bukan nilai apa pun yang dapat dicapai secara tidak langsung melalui bidangnya). Ada afaik sebuah keanggunan dan kapasitas membantu yang datang dengan versi penyiaran dari kata kunci yang berarti "setelah dibangun / diinisialisasi, nilai yang dianggap berasal dari item ini [atau item jenis ini] tidak berubah [tidak boleh diubah]" .

Jenis langsung (non-penyiaran) digunakan secara luas, dan dengan asumsi beberapa dari apa yang dilakukan orang dengan Julia menjadi lebih mudah bagi prakompilasi Julia untuk membuatnya lebih baik / lebih cepat / lebih sederhana untuk digunakan atau diandalkan dengan pengantar penyiaran yang dapat disiarkan, maka itu perlu dimainkan baik dengan jenis langsung. Saya ingin tahu apakah ini adalah cara yang membawa kebaikan _theoretical pemrograman bahasa_ (kemudahan ekspresi, kekuatan representasi, ...): penyiaran constness siaran melalui nilai tipe yang memiliki tipe referensi tertanam dan / atau memiliki? Secara tidak langsung berisi tipe sampai (a) mencapai nilai yang tidak memiliki penyematan atau penampung internal atau (b) mencapai nilai itu sendiri (secara independen atau tidak) dari jenis yang memiliki keteguhan non-penyiaran.

Memikirkan lebih banyak tentang ini, satu-satunya perubahan yang menurut saya layak untuk dihancurkan adalah bitstype -> primitive , sebagian besar karena betapa menjengkelkannya menyebut sesuatu isbits .

Adapun poin sebenarnya dari diskusi ini, type dan immutable , pada titik ini opsi yang paling saya sukai adalah tidak ada perubahan sama sekali; type untuk membangun tipe yang jelas, immutable untuk membangun tipe yang tidak dapat diubah adalah jelas. Namun, saya akan dengan senang hati menerima apa pun yang diberikan tuan tertinggi kami, karena saya secara implisit mempercayai penilaian mereka tentang apa yang terbaik untuk bahasa yang akan datang.

Apakah ada alasan untuk tidak menggunakan fixed daripada const atau constant? Bagi saya setidaknya, ini adalah deskripsi yang jauh lebih jelas.

@JeffreySarnoff Sulit untuk menyiratkan const ness ke sesuatu yang Anda bisa mendapatkan referensi (yaitu pointer). Semantik "berbagi" Julia berarti bahwa apa pun yang tidak dapat dibuktikan oleh compiler benar-benar tidak dapat diubah harus menjadi jenis referensi. Saat Anda mengikat referensi semacam itu ke bidang const type ( immutable ), tidak ada bukti bahwa referensi ini tidak ada di tempat lain dan oleh karena itu tidak ada bukti bahwa data yang dirujuk konstan.

Saya pikir mengubah perilaku ini akan menjadi perubahan yang sangat mendasar bagi bahasa Julia.

@andyferris Terima kasih atas jawaban yang jelas itu.

Apakah ada alasan untuk tidak menggunakan fixed daripada const atau constant ? Bagi saya setidaknya, ini adalah deskripsi yang jauh lebih jelas.

Saya telah bertanya-tanya apakah ada sesuatu yang lebih baik dari const atau constant yang mencerminkan bahwa itu adalah pengikatan yang permanen, dan tidak (harus) bahwa data di dalam objek terikat tidak dapat diubah. fixed memang mengarah ke sana, tetapi saya belum melihatnya di bahasa lain (sekali lagi, saya juga belum memperhatikan semantik pengikatan / berbagi Julia dalam bahasa lain).

Mungkin sesuatu seperti bind (misalnya bind x = 2 ) ... tesaurus menyarankan glue ... ini menjadi sangat spekulatif ...

Ide untuk mengganti const dengan sesuatu yang lebih tepat memang menarik. Namun, kami ingin menerapkannya secara bijak ke deklarasi tipe dan tugas variabel individual. fixed struct masuk akal, tapi field dari struct yang diperbaiki daripada deklarasi type. Sayangnya bound struct ( tied struct ?) Tampaknya agak tidak jelas. Untuk beberapa alasan, const tampak lebih jelas bagi saya saat diterapkan ke suatu tipe.

Kami ingin menerapkannya secara bijak ke deklarasi tipe dan tugas variabel individual.

Saya merasa akan produktif untuk mencapai itu

type A
    const x::Int  # fixed, bind, bound, tied, glue
end

masuk akal. Memiliki jalan pintas di depan type , struct atau apapun akan menjadi jalan pintas yang berarti di atas.

Masuk akal untuk menjadikan ini makro, seperti dekorasi penting lainnya yang mengubah karakter suatu benda, seperti @generated . Itu akan menghapus kata kunci lain ...

+1 untuk type -> composite , meskipun sebenarnya perubahan apa pun dari type kedengarannya bagus.

Saya berharap saya dapat memberikan suara pada masalah GitHub tanpa harus menambahkan komentar baru ke utas ... Pilihan saya adalah untuk mutable dan immutable , ini cukup rapi dan bersih. struct digunakan secara berlebihan dan tidak menekankan bagian mutabilitas.

PS: Apakah ada yang tahu atau bisa berkontribusi ke GitHub dan menambahkan fitur voting? Saya bertanya kepada mereka di halaman "hubungi kami", tetapi email saya mungkin hilang.

Setelah baru-baru ini beralih ke Julia dengan latar belakang dalam banyak bahasa lain, saya lebih suka tidak melihat Julia mengadopsi penamaan C-style dan menarik semua masalah konstan C / C ++ yang membingungkan. Sebaliknya, memberikan deklarasi tipe data sebuah gagasan yang mencerminkan entah bagaimana maksud menjadi tipe nilai atau tipe referensi bersama akan membantu saya secara signifikan, alih-alih hanya merujuk pada mutabilitas.

Harapan awal saya di Julia akan menjadi type untuk berperilaku mirip dengan objek C-style struct atau Python, karena Julia tampaknya lebih banyak tentang gaya dan kecepatan pemrograman fungsional.
Saya masih bingung dengan asimetri dalam kata-kata type ... dan immutable... , tetapi mendapatkan DataType dari typeof(SomeType) , atau arti sebenarnya dari 'bitstype ', dan kebutuhan untuk kata kunci typealias alih-alih pernyataan sederhana Alias = DataType .

Jadi, saya akan memilih datatype , yang akan konsisten dengan typeof(SomeType) == DataType , dan akan mematahkan kesamaan yang menjengkelkan dengan ::Type{} . Menghias jenis yang bisa berubah dengan composite [datatype] dapat menonjolkan sifat khusus dan mungkin lebih mahal dibandingkan dengan 'jenis bit' dasar.

menarik semua masalah konstan C / C ++ yang membingungkan

Tidak ada penggantian nama kata kunci ini akan melakukan itu. Masalah tersebut berkaitan dengan pemeriksaan statis dan pemeran, yang sama sekali tidak terlibat di sini.

maksud menjadi tipe nilai atau tipe referensi bersama akan sangat membantu saya, alih-alih hanya merujuk pada mutabilitas

Saya tidak sepenuhnya memahami ini. Jika suatu objek tidak dapat diubah, tidak ada cara untuk mengetahui apakah itu diteruskan oleh nilai atau referensi, jadi bagaimana perbedaan nilai / referensi menjadi fundamental?

datatype bukanlah pilihan yang buruk. Tetapi menurut saya datatype vs. composite datatype adalah cara yang baik untuk menyampaikan perbedaan mutabilitas.

@JeffBezanson , dengan C-like const-ness yang saya maksud adalah ekspektasi yang mungkin tersirat dari tipe Julia untuk memiliki perilaku yang sama seperti di C / C ++: tidak dapat diubah hanya setelah konstruksi, tetap dapat dimodifikasi melalui casting, terkadang tanpa efek sama sekali untuk argumen fungsi atau tipe pengembalian. Jadi, ketika memilih kata kunci yang mungkin tidak mengacu pada C / C ++ adalah pilihan yang baik, maka jangan const struct .

Mengenai 'nilai vs. referensi': Saya membutuhkan waktu cukup lama untuk memahami mengapa tipe yang tidak dapat diubah menyematkan anggota secara langsung dan menghasilkan kode assembler cepat yang bagus dan ringkas, tetapi 'tipe' tidak dan masih berisi semua panggilan ke objek. Atau dengan kata lain, mengapa saya biasanya ingin menggunakan NTuple saat membidik kecepatan. Jadi, ketika membaca 'tidak dapat diubah' dan 'dapat berubah' saya mengharapkan arti sebagai 'parameter' di Fortran, tetapi tidak juga perubahan dalam tata letak atau jenis implementasi dari tipe data yang sebenarnya.
Mungkin, sebagian besar waktu seseorang mungkin ingin memiliki semantik 'nilai yang tidak dapat diubah' untuk tipe komposit kecil seperti Kompleks, tetapi 'dapat berubah dan merujuk / tidak menyalin' untuk kumpulan data besar seperti array dll.
Kemudian, maksud dasarnya mungkin bukan mutabilitas, tetapi menghindari penyalinan data.

Namun, itulah pengalaman saya ketika mempelajari mesin tingkat rendah Julia untuk mendapatkan kode assembler yang cepat, tetapi saya tidak tahu bagaimana cara merefleksikannya dengan lebih baik dalam menamai kata kunci dan bagaimana menggabungkan atau mengekspresikannya hanya dengan mutabilitas.

Saya mengerti dari mana Anda berasal @mjw, saya pernah ke sana, tapi saya pikir Anda lebih baik tidak mempelajari semua yang Anda ketahui tentang C / C ++. Di sini, ini adalah const -ness yang tidak dapat diubah dan apakah sesuatu ditumpuk atau dialokasikan secara dinamis, dan apakah diteruskan oleh referensi atau nilai, bebas untuk bervariasi dan akan menjadi pilihan pengoptimalan untuk kompilator. Anda bisa membuat bahasa yang semuanya dialokasikan secara dinamis dan diteruskan oleh referensi, dan ini adalah cara default Julia (untuk nilai dalam kotak - ini mengimplementasikan "pass by sharing" meskipun jenisnya tidak diketahui). Anda (dan kita semua) melihat bahwa immutable kecil jauh lebih cepat karena di situlah pengoptimalan saat ini diterapkan. Ini adalah hasil dari semantik immutable membuat pengoptimalan lebih mudah.

Tapi, sungguh, saya lebih suka immutable besar diteruskan oleh referensi (mungkin oleh stack pointer, di mana itu masuk akal, tetapi mungkin yang terbaik adalah mengalokasikan heap NTuple{1_000_000} ) dan bahwa mutable kecil dengan ukuran yang diketahui dialokasikan tumpukan (sekali lagi, jika memungkinkan). Bahkan pengumpulan sampah dapat ditentukan secara statis dalam beberapa kasus, memungkinkan heap-space untuk digunakan kembali di dalam loop, misalnya. Saya membayangkan ini sebagai peluang pengoptimalan di masa depan yang memerlukan analisis pelarian (dan tidak satu pun dari ini memengaruhi semantik bahasa, hanya kinerja).

Saya pikir apa yang saya katakan adalah bahwa kata kunci harus mencerminkan semantik yang akan tetap konstan selama satu atau dua dekade, bukan detail implementasi yang akan berubah dalam beberapa tahun (yaitu, perubahan kecil yang efisien dan tidak dapat diubah besar yang efisien).

Yang saya maksud adalah ekspektasi yang mungkin tersirat dari jenis Julia untuk memiliki perilaku yang sama seperti di C / C ++

Ini mungkin alasan yang cukup baik untuk mempertimbangkan const -> constant , jujur ​​saja. Saya pikir const mungkin satu-satunya kata kunci kami yang disingkat saat ini, yang membuatnya menjadi aneh.

pernyataan sederhana Alias = DataType .

Saya cukup yakin ini benar-benar baik-baik saja jika masuk akal, tetapi tidak mengizinkan modifikasi yang lebih kompleks dari jenisnya, misalnya typealias RealMatrix{T<:Real} Matrix{T} , juga tidak seharusnya (ini adalah penjilidan sederhana, bukan membuat Type dengan TypeVar s baru). Kecuali jika Anda ingin mendefinisikannya sebaliknya: RealMatrix = Matrix{T <: Real} dan menggeneralisasi apa yang apply lakukan untuk TypeVar (yaitu menghasilkan TypeConstructor ) ... sebenarnya itu ide yang menarik (tetapi memiliki masalah sintaksis, itulah mengapa typealias bagus ...).

@andyferris , saya sudah 'tidak

@mjw Hebat, dan saya setuju dengan semua itu. :)

Begini, mari kita coba sedekat mungkin dengan polling menggunakan fungsi GitHub terbaik: emoji reaksi.

Di sini saya telah membuat tabel, _tidak dalam urutan tertentu_, saran-saran yang tampaknya paling mendukung. Bereaksi menggunakan emoji yang ditentukan untuk memberikan suara Anda untuk saran itu. Saya yakin ini membutuhkan akses GitHub melalui browser desktop; Emoji reaksi AFAIK belum diterapkan di antarmuka seluler. Klik wajah di sudut kanan atas posting ini untuk mengakses menu emoji.

| type | immutable | bereaksi dengan |
| : -: | : -: | : -: |
| struct | const struct | 👍 (+1) |
| mutable | immutable | 👎 (-1) |
| type | immutable | 😄 (Tertawa) |
| composite | const composite | : tada: (Hore) |
| datatype | const datatype | 😕 (Bingung) |
| type | const type | ❤️ (Hati) |

Kegagalan memberikan suara sesuai dengan pemungutan suara implisit untuk nuple , tentu saja. :muka mengejek:

Saya harus mengatakan, saya bukan penggemar berat melakukan keputusan kontroversial seperti ini "secara demokratis". Jika diskusi berjalan tanpa konsensus, saya hanya akan menunda keputusan BDFL.

Poin yang adil, @TotalVerb. Seperti yang saya katakan sebelumnya, saya akan baik-baik saja memiliki kekuatan yang hanya memberi kita apa pun yang menurut mereka terbaik. Menurut saya utasnya sedikit berkelok-kelok dan

Secara pribadi, saya rasa saya tidak suka memiliki dua kata secara estetis ( const type ). Ini juga terasa sedikit disonan secara semantik. Saat kita mengatakan const x = 1 . Maksud kami x konstan. Ketika kami mengatakan const type; x; end kami maksud adalah bahwa contoh jenis ini tidak berubah setelah konstruksi. Dari interpolasi langsung rasanya mengatakan sesuatu adalah tipe konstan artinya tipe itu sendiri tidak berubah (yang sudah terjadi sekarang). Lihat juga:

type foo
end
const bar = foo

Jadi bar adalah const dan itu selalu foo, tetapi bukan const type . Rasanya seperti wrt ke semantik const (berlaku untuk binding) yang ada, nama-nama tipe sudah menjadi const.

Saya menduga tidak ada kata kunci yang ringkas, menyampaikan semantik yang dimaksudkan, dan kemungkinan besar tidak diinginkan sebagai nama variabel. Terminologi yang saya rasa paling mendekati tujuan ini adalah mutable datatype , immutable datatype , dan abstract datatype untuk tiga jenis tipe yang dideklarasikan.

Saya berharap selain type dan immutable ada jenis nilai tambahan yang bisa berubah.
Saya telah melihat beberapa diskusi di suatu tempat dalam masalah, tetapi pada dasarnya saat ini tidak mungkin untuk menangani skenario seperti ini secara efisien (perbaiki saya jika saya melewatkan sesuatu):

immutable T
    a::Int
    b::Float64
    ...
end

t = Vector{T}(10)
t[2].a = 5    # error here
# instead
c = t[2]
t[2] = T(5, c.b, ...)   # works  

Kode membuat array rapi tipe nilai sizeof(T) * 10 , tetapi untuk mengubah beberapa bidang seseorang perlu menetapkan ulang seluruh T(...) , yang biasanya sepanjang 3-5 bidang.
Jadi pada dasarnya 5 sen saya:
type - Referensi yang dikumpulkan GC
immutable - tipe nilai (stack dialokasikan) yang tidak mungkin diubah
mutable - tipe nilai yang dapat diubah, terutama dalam array

jenis nilai yang dapat diubah

Saya pikir ini adalah tujuan yang mustahil untuk dicapai karena memungkinkan perubahan justru memberikan identitas objek.

Mungkin Anda lebih menyukai pendekatan ini: # 11902

kecuali untuk memisahkan mutables dan immutables , sebaiknya kita membagi nilai dan referensi .

abstract Node{T}
immutable Link{T} <: Node{T}
    value :: T
    next :: ref{Link{T}} # next :: Link{T} will be an error: Recursive type
end

Tidak perlu memperumit bahasa dengan perbedaan artifisial antara nilai dan referensi. Jenis yang dapat berubah dan tidak dapat diubah secara semantik jauh lebih sederhana; fakta bahwa tipe adalah tipe nilai hanyalah pengoptimalan.

@Keno membuat poin yang bagus

Secara pribadi, saya rasa saya tidak suka memiliki dua kata secara estetika (tipe const). Ini juga terasa sedikit disonan secara semantik. Ketika kita mengatakan const x = 1. Yang kita maksud adalah x konstan. Ketika kita mengatakan tipe const; x; akhir yang kami maksud adalah contoh jenis ini tidak berubah setelah konstruksi. Dari interpolasi langsung rasanya mengatakan sesuatu adalah tipe konstan berarti tipe itu sendiri tidak berubah (yang sudah terjadi sekarang)

Seperti yang saya sebutkan sebelumnya, saya pikir semantik yang "benar" diberikan oleh

type Complex{T}
    const re::T
    const im::T
end
z = Complex(1,2)

Di sini z.re berperilaku seperti ketika kita mengetik sesuatu yang mirip dengan const z.re = 1 , jadi tidak ada kebingungan semantik tentang pengikatan mana yang sebenarnya const .

Seperti yang dinyatakan @JeffBezanson , ini tidak benar-benar nyaman untuk sejumlah besar bidang, dan tidak kompatibel dengan implementasi tipe saat ini. Sebagian dapat berubah, sebagian struct konstan mungkin atau mungkin tidak diimplementasikan di masa depan. Namun, ada sintaks yang masuk akal baik saat ini dan ke masa depan:

<strong i="19">@const</strong> type Complex{T}
   re::T
   im::T
end

Cara penerapannya saat ini, makro dapat mengubah dari type menjadi immutable di AST. Di masa mendatang, jika struct sebagian-konstan diimplementasikan, maka makro masih dapat melakukan manipulasi ke AST dengan menambahkan const ke setiap bidang, dan akan menjadi jelas bagi semua orang bahwa itu adalah ikatan bidang yang konstan. Secara estetika, ini lebih baik daripada dua kata kunci berturut-turut - kami melakukan hal serupa untuk fungsi ( @generated , @inline , @proagate_inbounds , dll).

@const dapat dengan mudah menjadi @immutable atau sesuatu yang serupa ( <strong i="31">@immutable</strong> type Val{T}; end terbaca OK, IMO) dan ide makro kompatibel dengan struct , composite , dan seterusnya.

@ be5invis ya, ini adalah cara yang biasa di banyak bahasa, misalnya di C # ada struct , yang berperilaku dalam banyak cara sebagai immutable : ini diteruskan oleh copy ke fungsi, secara eksplisit dialokasikan di array (bukan referensi ke objek yang dikelola GC seperti dalam kasus class | type ). Bagaimanapun itu adalah _mutable_, dan dalam array dapat dimodifikasi dengan satu field.
Yang saya yakini bahwa dalam kasus immutable ada campuran 2 properti:

1. Kekekalan (untuk melakukan pemrograman fungsional yang tepat)
2. Berperilaku sebagai tipe nilai di tingkat yang lebih rendah

Jadi pada dasarnya saya ingin melihat pengenalan tipe dengan hanya properti 2. Ini tidak akan mengganggu basis kode yang ada (sisa immutable ), tetapi bagi mereka yang menulis sesuatu dengan cepat dengan keterlibatan GC minimal, itu akan sangat berharga .

@johnmyleswhite terima kasih untuk # 11902, tetap percaya bahwa itu tidak boleh

@wgreenr Seperti disebutkan sebelumnya, dan telah didiskusikan berkali-kali, itu tidak mungkin. Itu juga tidak terlalu terkait dengan pembahasan dalam masalah ini.

Segalanya mungkin tetapi memasukkan tipe nilai yang bisa berubah akan sangat mengganggu dan ide yang sangat buruk. Saya dapat memahami mengapa ini adalah ide yang tampaknya sederhana dan menarik, tetapi menambahkan jenis semantik objek baru yang sama sekali berbeda dan membagi tipe grafik menjadi referensi dan semantik nilai tidak akan membuat bahasa menjadi lebih baik. Apa yang akan dicapai adalah membuatnya tidak mungkin untuk menulis kode generik dengan aman karena kode yang sama akan melakukan hal yang sangat berbeda tergantung pada semantik yang tidak diketahui. Ada diskusi ekstensif dengan contoh di sini . Inti dari # 11902 adalah memulihkan manfaat dari jenis nilai yang dapat berubah tanpa merusak apa pun.

Saya tidak yakin apakah ini layak disebut; tetapi dalam C / C ++ 'struct' juga menyiratkan sesuatu tentang tata letak data. Di sisi lain, sering kali bermanfaat untuk mengatur ulang anggota struct untuk mendapatkan tata letak memori yang lebih baik. Jika Anda sedang mempertimbangkan untuk mengubah sintaksis, mungkin ada gunanya memiliki mekanisme untuk membedakan antara 'struct' (dipesan -> C interop) dan 'immutable's (berpotensi dapat dipesan dengan cara apa pun).

Saya cukup baru mengenal Julia, jadi saya minta maaf jika saya melewatkan sesuatu yang jelas.

Saya pribadi tidak punya preferensi nama wrt; Namun, saya terkejut bahwa tidak ada yang tampaknya menyarankan "konkret", mengingat bahwa "abstrak" sudah ada.

Untuk menambahkan saran lain, berikut ini tampaknya yang terbaik bagi saya:

• Gunakan struct alih-alih immutable .

• Gunakan struct! alih-alih type . Saat berbicara bahasa Inggris, ini harus disebut sebagai "struct yang bisa berubah".

  • (Mungkin) memungkinkan memiliki beberapa bidang di dalam struct! untuk ditandai sebagai const .

Beberapa pembenaran dan pemikiran:

1) Kecuali saya melewatkan sesuatu yang jelas, Anda tidak pernah ingin menggunakan fungsi dengan ! untuk memanipulasi nilai dari tipe yang tidak dapat diubah. Jika itu salah (misalnya jika ada kasus penting di mana tipe yang tidak dapat diubah mengacu pada yang bisa berubah, dan fungsi dengan ! mengubahnya), saran ini mungkin tidak bagus.

2) Saya pikir tipe yang tidak dapat diubah umumnya lebih disukai daripada yang bisa berubah, karena mereka tunduk pada lebih banyak pengoptimalan dan memiliki perilaku yang lebih dapat diprediksi untuk programmer.

3) Agar ini berfungsi, mungkin merupakan prasyarat untuk mengimplementasikan pengoptimalan untuk membuat jenis yang tidak dapat diubah setidaknya seefisien jenis yang dapat berubah di hampir semua kasus. Secara khusus, compiler harus pandai meneruskan tipe besar yang tidak dapat diubah melalui referensi.

PEMBARUAN : Saya dulu memiliki record bukan struct , tetapi record! terlalu banyak seperti kata kerja. Beberapa opsi lain yang terlintas dalam pikiran: newtype , typedef (yang akan membingungkan programmer C selama 10 detik), composite , atau concrete seperti yang disarankan orang di atas .

Apakah mungkin sesuatu akan terjadi di ruang ini sebelum fitur v0.6 dibekukan?

Mungkin tidak, mengingat belum ada keputusan yang dibuat (setidaknya secara publik) dan kami hanya ~ 10 hari lagi dari pembekuan.

Saya belum mengikuti ini dengan hati-hati, tetapi satu komentar adalah bahwa jika / ketika ini benar-benar berubah, saya ingin meminta agar kita terlebih dahulu memiliki pelaporan yang benar-benar baik dari file / nomor baris yang melanggar. Atau setidaknya modulnya; dalam 0,5 terkadang masih sulit bahkan untuk mengetahui paket mana yang memiliki @deprecate d _binding .

xref https://github.com/JuliaLang/julia/pull/20418#issuecomment -277475415