Julia: पागल विचार: `टाइप` कीवर्ड बदलें

अन्य संदर्भों में type प्रयोग करने योग्य शब्द महान होगा।

मुझे स्थिरता के लिए mutable है।

यदि ऐसा किया जाता है, तो इसे ASAP किया जाना चाहिए ताकि इसे 0.6 में शामिल किया जा सके

यदि ऐसा होने जा रहा है, तो उपयोग करने से पहले हर कोई सोचने से पहले पहचानता है: struct

मुझे भी लगता है कि type थोड़ा अजीब है। जब मैं इसे अन्य लोगों को समझाता हूं तो मैं आमतौर पर "एक संरचना की तरह" कहता हूं ताकि उसके लिए +1 हो।

यदि ऐसा होने जा रहा है, तो उपयोग करने से पहले हर कोई सोचने से पहले पहचानता है: struct

मैंने सोचा था कि immutable एक संरचना की तरह था?

+1 mutable

immutable में C संरचना की मेमोरी लेआउट होती है
type में C संरचना की पारस्परिकता है

इस प्रकार संरचना दोनों से संबंधित है। मुझे लगता है कि mutable struct बजाय यह स्पष्ट करने के लिए बेहतर है।

कोई भी परिवर्तनशील परिवर्तनशील है। उस लेबल को एक सार्वभौमिक रूप से मान्यता प्राप्त नाम (एक struct ) के लिए आवंटित करना, लेकिन मेरे लिए स्पष्ट है।

फोरट्रान से आने वाले किसी व्यक्ति के लिए कीवर्ड type पहले से ही प्राकृतिक है।
C कीवर्ड से आने वाले किसी व्यक्ति के लिए struct स्वाभाविक होगा।
immutable बहुत अधिक का उपयोग करने वाले व्यक्ति के लिए, विपरीत कीवर्ड mutable स्वाभाविक होगा।

इसलिए शायद हमें इसे छोड़ देना चाहिए।

struct{mutable}
struct{immutable}

या

record{mutable}
record{immutable}

यदि अधिक वर्णनात्मक रूप वांछित है।

अगर हम struct तो अपरिवर्तनीयों के लिए वाक्यविन्यास immutable struct ( struct कम से कम शुरू में वैकल्पिक होने के साथ) हो सकता है।

मुझे संदेह है कि फोरट्रान प्रोग्रामर "संरचना" शब्द से परिचित हैं।

स्थिरता के कारण mutable । यदि struct चुने जाते, तो क्या स्थिरता const struct जैसी किसी चीज़ के

मुझे लगता है कि struct और immutable struct वास्तव में बहुत अच्छा होगा; struct एक बहुत ही परिचित शब्द है और हमें केवल एक नया कीवर्ड जोड़ना होगा। mutable struct अनुमति देने से भी समझदारी आ सकती है, भले ही इसकी कड़ाई की आवश्यकता न हो।

मुझे स्पष्ट करना चाहिए कि मुझे लगता है कि struct एक संज्ञा होने का एक फायदा है। बेहतर होगा कि केवल इन चीजों के नाम के लिए विशेषण का इस्तेमाल न करें।

struct immutable struct जोड़ने से अनावश्यक लाइन-शोर जुड़ जाता है, और भी बहुत कुछ इस प्रकार का उपयोग नहीं करने के लिए किया जाता है।

ओटोह, मेरा मानना ​​है कि फोरट्रान का एक type कीवर्ड है जो हमारे जैसा कुछ करता है वैसा ही कुछ करता है। हालाँकि, मैं इसे बदलने का विरोध नहीं कर रहा हूँ।

@KristofferC के ऊपर यह अधिकार है: मैं यह बताते हुए भी "संरचना" कहता हूं कि यह क्या है। आंतरिक चर्चाओं में भी type की समस्या रही है; कोई कहेगा कि "मान लीजिए x एक प्रकार है", और यह स्पष्ट नहीं है कि इसका अर्थ " type कीवर्ड" या "प्रकार" के साथ किसी अन्य अर्थ में घोषित किया गया है।

अगर ये नाम वास्तव में मेज पर हैं ( s/type/new name/ थोड़ा अप्रिय लगता है), तो मेरा सुझाव है कि हम डिफ़ॉल्ट घोषणा को अपरिवर्तनीय बनाने के लिए इस अवसर का अधिकतम लाभ उठाना चाहते हैं।
तो struct की जगह लेंगे immutable , और mutable [struct] की जगह लेंगे type.

एक विचार के रूप में, उत्परिवर्तन के लिए एक और संभावित शब्द Ref भी हो सकता है।

एक अन्य संभावित नाम composite , क्योंकि इसके लिए एक सामान्य CS शब्द एक संयुक्त प्रकार है । लेकिन मैं अभी भी mutable Foo और immutable Foo से mutable struct Foo और immutable struct Foo - struct (या composite , या class , या जो भी हो) अतिशयोक्तिपूर्ण लगता है।

: +1: संज्ञा के लिए

मुझे हमेशा जूलिया में type struct (भले ही मेरी पृष्ठभूमि _C_ है) पसंद है, क्योंकि जूलिया के डेटाटिप्स एक पूरे गुच्छा अधिक शक्तिशाली और सूक्ष्म हैं और मुझे लगता है कि "संरचना" थोड़ी सरल हो सकती है विचार के लिए। मुझे यह भी लगता है कि चूंकि यह एक नई भाषा है जिसे हम इस सत्र से बाध्य नहीं होना चाहिए कि अनुभवी प्रोग्रामर का उपयोग किया जाता है - आपको यह भी विचार करना चाहिए कि "किसी व्यक्ति को यह समझाने के लिए सबसे अच्छा शब्द क्या होगा जो पहली भाषा जूलिया है"।

मैं अपने आप को यह कहते हुए "संरचना" भी बताता हूं कि यह क्या है

एक नवागंतुक को struct T लाने की कल्पना करें और फिर उन्हें T::DataType और आप जूलिया के "शक्तिशाली प्रकार प्रणाली" की व्याख्या करते हुए ::Type{T} का उपयोग करके भेज सकते हैं। मुझे लगता है कि यह सिर्फ सड़क के नीचे बाल्टी को लात मार रहा है।

संज्ञा होना एक फायदा है

: +1: संज्ञा के लिए

संभवतः ध्यान देने योग्य है कि लैटिन-भाषा-परिवार के विशेषण जैसे "उत्परिवर्तनीय" को व्याकरणिक रूप से भी अपनी भाषा में संज्ञा होने की अनुमति है। इसीलिए जब हम पूछते हैं कि "हम किस प्रकार का संज्ञा रूप है" हम अपने कंधों को सिकोड़ लेते हैं। लेकिन हम हमेशा "एक चर" कहते हैं और जूलिया-स्पीक में मैं कहता हूं कि "इसके लिए एक अपरिवर्तनीय परिचय दें"। दुर्भाग्य से यह अंग्रेजी व्याकरण की जर्मनिक जड़ों की वजह से पहली बार में अजीब लगता है - लेकिन यह वास्तव में अंग्रेजी में अक्सर होता है (क्योंकि हम भी फ्रेंच और लैटिन पर आधारित हैं) लेकिन आपको समय के साथ इसकी आदत हो जाती है।

अंत में, चूंकि विषय "पागल विचार" है, इसलिए ये कीवर्ड अधिक-या-कम एक नए DataType तो क्या हम कीवर्ड को पूरी तरह से हटा सकते हैं और बस एक कंस्ट्रक्टर का उपयोग कर सकते हैं?

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

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

मुझे लगता है कि ये विशेष रूप से (सांख्यिकीय रूप से) ccall तरह पार्स होना होगा और उन्हें केवल अब के लिए सबसे ऊपर कहा जा सकता है। (यह भी सुनिश्चित नहीं है कि अगर हमें सभी संभावनाओं को कवर करने के लिए Mutable <: DataType और Immutable <: DataType और BitsType <: DataType की आवश्यकता होगी, और शायद const बाइंडिंग के लिए)।

मुझे लगा कि अपरिवर्तनीय एक संरचना की तरह था?

अपरिवर्तनीय में C संरचना का मेमोरी लेआउट है
प्रकार में C संरचना की परिवर्तनशीलता है

ठीक है ... मुझे लगता है कि मैं स्विफ्ट के बारे में सोच रहा था, जहां:

यह संरचना और वर्गों के बीच सबसे बड़ा अंतर है। संरचनाओं की नकल की जाती है और कक्षाओं को संदर्भित किया जाता है। ... इस प्रकार, उन्हें बड़ी वस्तुओं के मामले में संदर्भ के रूप में नहीं मूल्यों के रूप में पारित किया जाएगा।

जो immutable बनाम type , और यह केवल संदर्भ है जो जूलिया बाइंडिंग के शब्दार्थ के संदर्भ में परिवर्तनशीलता की अनुमति देता है।

DataType सभी नाममात्र प्रकारों में शामिल हैं: abstract , बिटस्टिप्स, अपरिवर्तनीय और परिवर्तनशील संरचनाएं। तो यह type DataType type साथ बदलने के लिए बहुत स्पष्टता नहीं जोड़ता है। मैं "नवागंतुक" परिदृश्य से एक अलग निष्कर्ष निकालता हूं: ::Type और ::DataType type T द्वारा परिभाषित चीज़ों के सुपरसेट्स, इसलिए यह उनके अलग-अलग नामों के लिए पागल नहीं है । " struct में से एक प्रकार है Type की तुलना में अधिक समझ में आता है" " type में से एक प्रकार है Type "।

मैं मानता हूं कि विशेषण संज्ञा के रूप में काम कर सकते हैं। कोई कह सकता है जैसे "यह एक अपरिवर्तनीय है"। मुझे लगता है कि वे अपर्याप्त वर्णनात्मक हैं। आपको यह बताने के बजाय कि क्या चीज _is_ है, यह आपको बताता है कि जो कुछ भी है, आप इसे म्यूट नहीं कर सकते / कर सकते हैं।

मुझे structure और mutable structure प्रकारों के लिए पसंद है। शायद चर असाइनमेंट के लिए a = 1 और mutable a = 1 । निरंतरता, कोई संक्षिप्तता और डिफ़ॉल्ट रूप से अपरिवर्तनीयता के विचार से दूर जाना।

संपादित करें: शायद constant के बजाय const अस्थिरता में डिफ़ॉल्ट के मामले से

या एक ऐसा संस्करण जिसमें कम कीवर्ड होते हैं, वह struct बनाम const struct । डिफ़ॉल्ट रूप से सभी चर कांस्टेबल बनाना इस बिंदु पर बहुत विघटनकारी होगा जो मुझे लगता है।

मुझे लगता है कि वे अपर्याप्त वर्णनात्मक हैं। आपको यह बताने के बजाय कि वह चीज क्या है, यह आपको बताता है कि यह जो भी है, आप इसे म्यूट नहीं कर सकते हैं।

यह एक अच्छा बिंदु है - लेकिन मैं संदर्भित व्यवहार बनाम "मान" व्यवहार _much_ पर विचार करना अधिक महत्वपूर्ण होगा और यह वर्णन करने के लिए दिलचस्प है कि "क्या यह एक संरचना या एक बिटस्टाइप है?" (ज्यादातर क्योंकि bitstype बहुत बार नहीं आते हैं - मेरे द्वारा बनाए गए प्रत्येक जूलिया प्रकार एक संरचना है)। अपरिवर्तनीयता केवल बाध्यकारी अर्थ और पास-बाय-वैल्यू का परिणाम है।

struct bitstype की आवश्यकता को पूरी तरह से समाप्त करने के लिए हम इस विचार को @quinnj से भी शामिल कर सकते हैं जो था

immutable 32 Int32 <: Integer

या आपके पास बिट्स की संख्या के रूप में अन-एडर्ड फ़ील्ड हो सकते हैं

immutable Int32 <: Integer
   32
end

जो (सामान्य रूप से नामित क्षेत्रों के साथ मिश्रित होने पर) आवश्यक होने पर पैडिंग डालने के लिए भी उपयोगी हो सकता है।

फिर यह एक मान प्रकार (जो वर्तमान में अपरिवर्तनीय है) बनाम एक संदर्भ प्रकार (वर्तमान में क्या परिवर्तनशील है) के बीच एक विकल्प है - लेकिन संभवतः भविष्य में const फ़ील्ड के साथ जो इसे mutable न कहे जाने का एक और कारण है मूल्य संदर्भ प्रकार के लिए struct का उपयोग करके स्विफ्ट प्रोग्रामर को भ्रमित करेगा ...

यह सच है कि bitstype सभी गायब हो गए हैं, लेकिन immutable को पेश किया गया था। लेकिन संरचना बनाम बिट्स से अंतर करने के लिए और भी चीजें हैं: भविष्य में सार प्रकार, ट्यूपल्स (अपरिवर्तनीय भी हैं) और संभावित अपरिवर्तनीय रिकॉर्ड हैं।

हमने मूल रूप से immutable उठाया क्योंकि हमें लगा कि अन्य वस्तुओं के विपरीत यह सबसे दृश्यमान विशेषता होगी: आप उन्हें संशोधित नहीं कर सकते। वास्तव में, वे _not_ हमेशा मूल्य से पारित होते हैं; अपरिवर्तनशीलता का अर्थ है कि आप अंतर नहीं बता सकते। कुछ immutable सरणियों और अन्य वस्तुओं में अंतर्निर्मित हैं, और कुछ नहीं हैं। अपरिवर्तनशीलता का अर्थ है कि अंतर सादे जूलिया कोड के लिए कोई समस्या नहीं पैदा करता है; यह केवल एक मुद्दा बन जाता है जब मेमोरी लेआउट वास्तव में सी इंटरोप के लिए उदाहरण के लिए मायने रखता है।

वास्तव में, वे _not_ हमेशा मूल्य द्वारा पारित किए जाते हैं

अच्छी बात! हालांकि, वहाँ है कि, बदलने की योजना बना रहे हैं?

मुझे लगता है कि मैं कह रहा हूं कि आपको भविष्य के प्रूफ सेट की आवश्यकता होगी जो कुछ भविष्य के प्रूफ कॉन्सेप्ट्स को मिरर करें, क्योंकि हम 1.0 के करीब हो रहे हैं। जब अपरिवर्तनीय रूप से इनबिल्ट होते हैं, तो ऐसा लगता है कि उन्हें किसी चीज़ का नाम बदलने के लिए उचित समय हो सकता है जो परिणामी शब्दार्थ के संबंध में सहायक है (और यदि वे शब्दार्थ एफएफआई के साथ मदद करते हैं, तो यह और भी अच्छा है)।

मुझे नहीं लगता कि लोगों को abstract , Tuple s और "रिकॉर्ड" के साथ भ्रमित करने वाले नए ठोस प्रकार के कीवर्ड मिलेंगे (जो, अगर आप फ़ील्ड नामों के साथ प्रस्तावित टपल-जैसी चीज़ का मतलब रखते हैं, तो मुझे लगता है मैंने यह भी सुना है कि पहले "स्ट्रक्चर्स" के रूप में संदर्भित किया जा रहा है ...)।

"पास बाय वैल्यू" की धारणा का वास्तविक उद्देश्य उस प्रश्न का उत्तर देना है जब f(x) (किसी अर्थ में) x संशोधित होता है: क्या यह उसी x संशोधित करता है?

वैसे भी, मुझे लगता है कि immutable और mutable खोजशब्दों के लिए व्यवहार्य विकल्प हैं।

यह सच है कि बिटस्टाइप सभी है लेकिन अपरिवर्तनीय पेश किए जाने के बाद से गायब हो गया है

जबकि व्यक्तियों को आम तौर पर नए बिटस्टेप्स बनाने की आवश्यकता नहीं होती है, लेकिन मौजूदा बिटस्टिप्स और आम अपरिवर्तनीयों के बीच का अंतर आदिम स्तर पर अत्यधिक महत्वपूर्ण है क्योंकि एबीआई इन के लिए काफी अलग है। यह बस ऐसा होता है कि जब उपयोगकर्ता नए कंक्रीट डेटा प्रकार को परिभाषित करते हैं, तो अधिकांश समय अपरिवर्तनीय संरचना चाहते हैं, बिटस्टाइप नहीं।

FWIW, चूंकि चीजों को न बदलने के लिए बहुत समर्थन type और immutable ठीक उसी तरह हैं जैसे वे हैं।

( do सिंटैक्स मुझे बग, हालांकि ... ;-)

सब कुछ "साझा करके पास" है।

मैं इसका सम्मान कर सकता हूं - और चर्चा के लिए धन्यवाद।

सब कुछ "साझा करके पास" है।

उस नोट पर, बस एक अवलोकन - यदि हमारे पास const कीवर्ड प्रकार की घोषणाओं में हैं, तो immutable पूरी तरह से अनावश्यक हो जाते हैं:

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

(कंपाइलर यह निर्धारित कर सकता है कि यह प्रकार स्वचालित रूप से अपरिवर्तनीय है, और उपयोगकर्ता यह समझ सकते हैं कि const प्रकार हमें तेज कोड संकलित करने की अनुमति देते हैं)। तब type या struct कमाएँ। मिश्रित मामले में setfield! को const फ़ील्ड पर अक्षम किया जा सकता है।

type और const type क्या? - टाइप कीवर्ड मेरे लिए संरचना की तुलना में अधिक सुंदर लगता है और संरचना के साथ मैं एक तकनीकी मेमोरी लेआउट के सहयोगी की तरह होता है न कि एक ~ ऑब्जेक्ट जैसे कि इनर कंस्ट्रक्टर। जैसा कि कंपोजिट टाइप है '... जूलिया में अब तक का सबसे ज्यादा इस्तेमाल किया जाने वाला यूजर-डिफाइन्ड टाइप ...', 'टाइप वन टाइप है तो क्या यह बुरा नहीं है?' 'मिश्रित प्रकार' का उपयोग करते हुए संचार में स्पष्ट करना चाहिए, जैसे कि मैं 'सार प्रकार' कहूँगा। लाइन-शोर के संबंध में, 'कांस्ट प्रकार' 'अपरिवर्तनीय' से भी बदतर नहीं है।

मैं चर (बनाम) प्रकारों के साथ const के अर्थ में (मामूली) अंतर के बारे में निश्चित नहीं हूं। - किसी भी मामले में और अपरिवर्तनीय ने हमेशा मुझे एक छोटी मानसिक हिचकी दी। यहाँ इस मुद्दे को देखने के लिए अच्छा है!

struct का उपयोग करने के साथ मुख्य समस्या यह होगी कि लोग स्वाभाविक रूप से ऐसी धारणाएं बना सकते हैं जिनका उपयोग वे C / C ++ से करते हैं जो जरूरी नहीं कि जूलिया में सच हों, उदाहरण के लिए, एक उत्परिवर्ती मिश्रित प्रकार को किसी सरणी में मान द्वारा संग्रहीत नहीं किया जाता है अपरिवर्तनीय है

क्या प्रतिमान immutable type से अधिक सुरुचिपूर्ण ढंग से प्रदर्शित करते हैं? उदाहरण के लिए, एटोमिक रूप से "फ़ील्डिंग" कई क्षेत्रों की स्थिति को एक साथ सिंक्रनाइज़ेशन प्राइमेटिव्स की आवश्यकता के बिना मूल से एक नई अपरिवर्तनीय को तुरंत अपडेट करके वांछित अपडेट किए गए।

उनके प्रेषण / उपयोग के बिंदु के बजाय उनकी परिभाषा के बिंदु पर प्रकार को दो अलग-अलग श्रेणियों में क्यों अलग किया जाना चाहिए (C ++ में const )? मिश्रित प्रकारों को परिभाषित करने के लिए केवल type / struct / composite करके, हम अपरिवर्तनीय को बढ़ावा देने के लिए Immutable{T} निर्माण कर सकते हैं:

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

इसके अलावा, abstract और bitstype परिवर्तन यहां माना जा सकता है? AFAICT "अमूर्त" का उपयोग विशेषण के रूप में होता है, संज्ञा के रूप में नहीं। टाइप कीवर्ड्स में कम से कम एक भाषाई स्थिरता होनी चाहिए: सभी संज्ञा, सभी विशेषण, आदि bitstype बेहतर हो सकते हैं जैसा कि bits या primitive ।

कृपया, जूलिया कीवर्ड की वर्तनी (या शब्दार्थ) पर चर्चा करने के लिए इसे एक खुले धागे में न बदल दें। इस बिंदु पर, जहाज type और immutable के मूल _behavior_ पर रवाना हो गया है। यहाँ केवल एक ही सवाल है कि क्या हम type और immutable वर्तनी रख सकते हैं जो बेहतर रूप से उनकी समानता को दर्शाता है।

मैं इस बिंदु पर दो सबसे उचित विकल्पों के रूप में mutable बनाम immutable का समर्थन करना जारी रखता हूं। और कुछ भी व्यर्थ नहीं होगा।

@ कैंडीफेरिस मैं वास्तव में उस विचार को पसंद करता हूं; struct और const कुछ संयोजन अच्छा होगा। यदि हम इस तरह से चलते हैं, तो मैं भी const struct या const type , (1) हर क्षेत्र पर const लिखने की आवश्यकता से बचने के लिए कहने में सक्षम होना चाहता हूँ, (2) ) इसलिए हमें प्रति-फ़ील्ड अपरिवर्तनीयता की नई सुविधा को तुरंत जोड़ना नहीं है। अगर हम कभी भी उस सुविधा को जोड़ना चाहते हैं, तो इसके लिए लगातार शब्दावली उपलब्ध होना अच्छा होगा।

संचार में 'मिश्रित प्रकार' का उपयोग करके स्पष्ट करना चाहिए

नामकरण के लिए हमारी पसंदीदा तकनीकों में से एक वाक्य में किसी को एक बात समझाने के लिए किया गया है, फिर जो भी शब्द या दो सबसे अधिक काम कर रहे हैं उसे बाहर निकालें। तो मेरे लिए यह composite लिए एक वोट होगा।

उनके प्रेषण / उपयोग के बिंदु (C ++ में अधिक की तरह) के बजाय उनकी परिभाषा के बिंदु पर टाइप को दो अलग-अलग श्रेणियों में क्यों अलग किया जाना चाहिए?

यह आसान है: वैश्विक गारंटी प्रदान करना। C ++ में "कॉन्स्ट" ऑब्जेक्ट अभी भी आपके अधीन बदल सकता है यदि किसी के पास इसका गैर-कॉन्स्टेंस संदर्भ है।

इसके अलावा, क्या अमूर्त और बिटस्टाइप में बदलाव को यहां माना जा सकता है?

एक प्रस्ताव तैयार करें। bitstype , कीवर्ड का उपयोग बहुत ही कम किया जाता है, इसलिए मैं इसके लिए bits जैसे छोटे उपयोगी शब्द को चोरी नहीं करना चाहूंगा।

immutable -> const type भी मुझे ठीक लगता है। type -> composite या struct साथ संयुक्त अगर हम वास्तव में type मुक्त करना चाहते हैं।

मैं कोड के सभी के बारे में सुपर खुश नहीं हूँ कि यह कारण होगा, विशेष रूप से क्योंकि यह @compat द्वारा समर्थित नहीं हो सकता है। अगर हमें ऐसा करना चाहिए, तो मुझे लगता है कि उन्नयन पथ कुछ ऐसा होना चाहिए (1) 0.6 में नए कीवर्ड समानार्थी शब्द प्रस्तुत करें लेकिन _d't_ deprecate पुराने वाले ( @compat की कमी के कारण), तो (2) संक्षिप्त करें 0.7 में पुराने।

bitstype , यह primitive प्रकार को कॉल करने के बारे में कैसे? an isbits composite type समानता के कारण वर्तमान नाम थोड़ा कष्टप्रद है

मुझे पसंद है कि जिस तरह से जूलिया ने अक्सर कुछ अन्य भाषाओं के "डिफ / फंक / एलिफ" -स्टाइल संक्षिप्तीकरण से बचा है। (Dn w abbrevs, kthx।) तो mutable मेरे लिए struct से अधिक जीतता है।

FWIW, OCaml रिकॉर्ड्स और वेरिएंट (संरचना और यूनियनों) और उपनामों के लिए type का उपयोग करता है। मानक ML datatype का उपयोग करता है मुझे लगता है।

समरूपता अच्छा है, लेकिन मुझे mutable अपर्याप्त रूप से वर्णनात्मक लगता है; immutable भी, उस बात के लिए (मुझे const type का विचार पसंद है)।

जैसा कि स्टीव बताते हैं, इससे समुदाय में बहुत बुरा कोड मंथन होगा। और लाभ संदिग्ध है।

मैं निश्चित रूप से const type के मामले को देखता हूं; यह नेट -1 कीवर्ड होगा, और प्रकार और अपरिवर्तनीय के बीच संबंध को स्पष्ट करेगा। हालाँकि अन्य तरीकों से type का उपयोग करने में सक्षम होना वास्तव में अच्छा होगा। उस लाभ के बिना किसी बदलाव को सही ठहराना बहुत कठिन है। हालाँकि इसके लिए अपडेट कोड बहुत आसान होना चाहिए; type का सिंटैक्स ऐसा है कि इसे मूल रूप से किसी अन्य संदर्भ में उपयोग नहीं किया जा सकता है।

+1 composite / const composite ।

मुझे लग रहा है कि primitive vs composite एक महान विभेदक है, const कीवर्ड आवश्यक के रूप में जोड़े गए हैं।

क्या हमें कुछ बिट्स से अंतर करने के लिए const primitive है जो बदल सकते हैं (और स्थिरता के लिए)? इसलिए सममित रूप से हमारे पास होगा

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

एक परस्पर आदिम प्रकार होने की समस्या को लागू किया जाना होगा ... (बेशक यह संभवतः बाद की तारीख में हो सकता है, लेकिन हम bitstype -> const primitive _now_ चाहते हैं यदि वह जा रहा था एक चीज़ बनने के लिए। सरल होने के नाते, यह एक अच्छा "अभ्यास" लक्ष्य हो सकता है जो स्टैक के लिए म्यूटेबल लाने के लिए है, लेकिन मैं उस पर एक विशेषज्ञ नहीं हूं)।

इसी तरह, एक सम्मिश्र के व्यक्तिगत क्षेत्रों में const को जोड़ने का विचार बाद की तारीख में आसानी से लागू किया जा सकता है, और इससे भी बेहतर, यह एक गैर-ब्रेकिंग परिवर्तन है।

अगर हम इस तरह से चलते हैं, तो मैं कॉन्स्टेबल या कांस्टेबल टाइप भी कह सकता हूं, (1) हर क्षेत्र में कॉन्स्ट लिखने की जरूरत से बचने के लिए, (2) इसलिए हमें नई सुविधा नहीं मिलानी चाहिए प्रति-क्षेत्र अपरिवर्तनीयता तुरंत। अगर हम कभी भी उस सुविधा को जोड़ना चाहते हैं, तो इसके लिए लगातार शब्दावली उपलब्ध होना अच्छा होगा।

मेरे लिए बिल्कुल ठीक है।

मैंने composite डेटा प्रकार देखा और पाया कि कम से कम Ada और Visual Basic भी इसके अंतर्गत सरणी प्रकारों को ग्रहण करते हैं। (अन्यथा, थोड़ा बेतरतीब ढंग से, पाया गया: हास्केल: सूचियाँ और टुपल्स (हालाँकि एक परिभाषा पूछी गई है); पायथन: सूचियाँ, टुपल्स, डिक्सेस; लिस्प: सूचियाँ, वेक्टर, हैश टेबल, उपयोगकर्ता-परिभाषित कक्षाएं, संरचना)।

इस प्रकार मैं अब सोचता हूं कि संरचना के समान type लिए कंपोजिट कितना सटीक है? (लेकिन मैं कोई कंप्यूटर वैज्ञानिक नहीं हूँ, मुझे शब्दावली / व्यापक दृष्टिकोण की कमी है)।

हम्म, यह सही हो सकता है: इस विशेष प्रकार के प्रकार को हमेशा एक संरचना, संरचना या रिकॉर्ड (या वर्ग या वस्तु) कहा जाता है, जिसमें "समग्र" एक व्यापक शब्द है। Http://rosettacode.org/wiki/Compound_data_type पर कई उदाहरण हैं

एक पहचानकर्ता के रूप में type वसूली करना और अधिक विशिष्ट नाम का उपयोग करना अच्छा होगा। ~ 0.6 से पहले लिखे गए बहुत से हर तुच्छ पैकेज का टूटना सुपर दुर्भाग्यपूर्ण होगा, मुझे यकीन नहीं है कि इसे कैसे तौलना चाहिए।

const कीवर्ड का पुन: उपयोग करने का विचार काफी सम्मोहक है क्योंकि यह वैश्विक स्तर पर const परिवर्तनीय बाइंडिंग के बराबर होने के साथ const इमिग्रैबल्स के अंदर फ़ील्ड्स के बाइंडिंग पर जोर देता है। यह एक अच्छा एकीकरण और immutable से बेहतर नामकरण जैसा लगता है।

जैसा कि नामों के लिए type , struct अस्पष्टता से बचने के लिए काफी अच्छा लगता है (मैं अक्सर वाक्यांशों को "एक उत्परिवर्ती प्रकार" और "अपरिवर्तनीय प्रकार" ध्वनि भी समान लगता है)।

निम्नलिखित काफी अच्छा लग रहा है मुझे लगता है:

struct A
    a::Float64
end

const struct B
    b::Float64
end

एक पहचानकर्ता के रूप में प्रकार को पुनर्प्राप्त करना और अधिक विशिष्ट नाम का उपयोग करना अच्छा होगा।

मैं इस भावना को प्रतिध्वनित करता हूं।

अगर हम नाम बदलने जा रहे हैं, तो वंचितों को कैसे संभाला जाएगा? क्या type और immutable अभी भी 0.6 में मान्य होंगे और शायद 1.0 चेतावनियों के साथ? Compat.jl इसे पारदर्शी रूप से संभाल सकते हैं। नेट पर थोड़ा सा साहित्य (ब्लॉग पोस्ट, ट्यूटोरियल, आदि) एक नवागंतुक के लिए चेतावनी - मामूली झुंझलाहट दिखाएंगे।

हम अभी भी type और immutable अधिक समय के लिए आमतौर पर संक्रमण को कम करने के लिए कर सकते हैं।

हम पूर्व 1.0 हैं: इसे बदलने का समय अभी या कभी नहीं है। पुराना कीवर्ड अब उपलब्ध होना निश्चित रूप से एक अच्छा संक्रमण सुनिश्चित करने के लिए अच्छा है। मैं दर्द के साथ वास्तविक नामकरण पर चर्चा को नहीं मिलाऊंगा कि संक्रमण का अर्थ होगा।

व्यक्तिगत रूप से मैं इसे struct कहने के लिए हूं। यह कहने के बाद

मैं दर्द के साथ वास्तविक नामकरण पर चर्चा को नहीं मिलाऊंगा कि संक्रमण का अर्थ होगा।

यदि परिवर्तन बहुत दर्दनाक है, तो मैं बदलाव के खिलाफ मतदान करूंगा। हालांकि एक बदलाव प्री 1.0 न्यायसंगत है, इसे किसी भी व्यवधान के कारण तौलना आईएमओ को सही काम करना है।

@stevengj का एक अच्छा सुझाव था कि किस तरह से पदावनति की @amitmurthy एक ही निष्कर्ष पर आया (हमारे आस-पास के खोजशब्दों को सामान्य रूप से अधिक लंबे समय तक रखें)। हालांकि हम सभी इस भाषा का उपयोग थोड़ी देर से कर रहे हैं, अभी भी शुरुआती दिन हैं और हमें बदलाव करने से डरना नहीं चाहिए। यह एक आसान खोज है और प्रतिस्थापित भी है।

मैं आगे जाऊंगा और struct लिए वोट डालूंगा। मुझे लगता है कि यह उन परिवर्तनों में से एक है जो बहुत सारी चर्चा और शिकायतें पैदा करेगा, लेकिन यह वास्तव में संकुल / उपयोगकर्ता कोड को ठीक करने के लिए बहुत कठिन नहीं है ... बस इसे करें और लोग इसका पता लगाएंगे।

immutable -> const type कम से कम प्रतिरोध का मार्ग प्रतीत होता है, और IMO निश्चित रूप से किया जाना चाहिए। मुझे लगता है कि यह चीजों को बहुत अच्छे तरीके से समझाता है।

type -> composite तुलना में अधिक सटीक है type लेकिन कम से कम सटीक struct , जबकि कम होने के बजाय शब्दजाल-y struct (करने के लिए नए प्रोग्रामर)। यह जेफ के 'एक नौसिखिया को समझाने के लिए एक वाक्य लिखता है "परीक्षा पास करता है और type कीवर्ड प्राप्त करता है। नकारात्मक पक्ष पर, मुझे नहीं लगता कि composite अन्य भाषाओं में प्रकट होता है, इसलिए हम। अकेले जा रहे हो।

type -> struct सबसे सटीक है, लेकिन संभवतः structure एक संक्षिप्त नाम से अधिक सुंदर होगा (मैं एक संक्षिप्त रूप में struct रूप में बदसूरत के बारे में सोचने की कोशिश कर रहा हूँ) भाषा में eye() एक अंग्रेजी भाषा के दृष्टिकोण से एक बहुत ही घृणित परंपरा है)।

bitstype -> primitive मतलब है अगर type बदला गया है।

@tbreloff सही है - कोर

मुझे आश्चर्य है कि, जब से immutable मानक होना चाहिए जब तक कि आपको स्पष्ट रूप से म्यूट करने की आवश्यकता न हो, चाहे नाम बदला जाना चाहिए:

• immutable -> struct
• type -> mutable

फिर सामान्य / अपेक्षित नाम सबसे अच्छा अभ्यास है, और इसमें परिवर्तनशीलता का अनुरोध करने के लिए एक स्पष्ट और स्पष्ट नाम है।

मुझे bitstype -> primitive रूप में अच्छी तरह से ...

मुझे नहीं लगता कि const डिफ़ॉल्ट होना चाहिए। कार्यक्षमता को कम करने वाले अनुकूलन डिफ़ॉल्ट नहीं होने चाहिए।

+1 struct और const struct ।

composite थोड़ा अधिक वर्णनात्मक है, लेकिन struct कम है, और बहुत सामान्यतः एक समग्र प्रकार के रूप में जाना जाता है।

मैं कुछ के लिए एक वास्तविक शब्द नहीं चुराऊंगा क्योंकि शायद ही कभी bitstype रूप में उपयोग किया जाता हो। शायद primtype या primitivetype ?

यदि हम bitstype को primitive जैसे स्पष्ट रूप से बेहतर नाम में बदलने नहीं जा रहे हैं, तो मुझे लगता है कि इसे छोड़ना शायद बेहतर होगा।

-1 से struct । मैं इस शब्द का उपयोग यह समझाने के लिए नहीं करता हूं कि जब तक मैं C प्रोग्रामर से बात नहीं कर रहा हूं, तब तक किस प्रकार की परिभाषा है, और उसके बाद केवल यह उल्लेख करना है कि लेआउट संगत है और उनके गुणों की तुलना / तुलना करना है।

-1 से const । सी बिल्कुल कम से कम कीवर्ड रखने की इस दिशा में चला गया, और अब हम कई कीवर्ड के साथ संदर्भ-संवेदनशील अर्थों के साथ फंस गए हैं। मुझे नहीं लगता कि const इन प्रकारों की प्रमुख संपत्ति है, बल्कि यह है कि वे मूल्य प्रकार हैं (संदर्भ के विपरीत)।

एक और दिशा में जा रहे हैं, हालांकि, खोजशब्द 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`

"मूल्य प्रकार" के साथ समस्या यह है कि यह कुछ ऐसा है जो केवल भाषा में काफी गहरे लोग समझ सकते हैं। नए उपयोगकर्ताओं के लिए, यह तथ्य कि फ़ील्ड अपरिवर्तनीय हैं, _semantic_ तथ्य यह है कि वे तुरंत सामना कर रहे हैं; बाकी सब कुछ एक कार्यान्वयन विवरण है। इसलिए मैं const पसंद करता हूं।

मैं देखता हूं कि आप रिकॉर्ड के साथ कहां जा रहे हैं, लेकिन ईमानदारी से मुझे लगता है कि यह शब्दावली struct से भी कम आम है (भले ही आप Google "रिकॉर्ड प्रकार माणिक" बनाम "संरचना प्रकार रूबी", या स्थानापन्न अजगर या एलएल या कुछ और अन्य गैर-सी भाषा)। समस्या यह भी है कि record काफी उपयोगी अंग्रेजी शब्द है कि यह एक खोजशब्द के रूप में आरक्षित करने के लिए शर्म की बात है, जबकि struct एक कार्यक्रम में किसी और चीज के लिए आवश्यक होने की संभावना नहीं है।

struct बहुत आम उपयोग में है; रोसेटेकोड को देख कर इसका उपयोग किया जाता है:

अल्गोल, सी, सी #, सी ++, लिस्प, डी, अमृत, आगे, गो, मैक्सिमा, रैकेट, रस्ट, सीड 7, स्विफ्ट, विजुअल बेसिक ( structure )

record का उपयोग इसके द्वारा किया जाता है:

ada, clojure, delphi, pascal, erlang, icon, modula-2, कुछ योजनाएँ

record पुरानी भाषाओं में पसंद किए जा रहे हैं; इन दिनों के रूप में कार्यात्मक प्रोग्रामिंग अधिक लोकप्रिय हो गया है यह संरचनात्मक रूप से टाइप किए गए रिकॉर्ड को संदर्भित करता है।

दिलचस्प है कि हालांकि seed7 new struct का उपयोग करता है।

struct को देखने के लिए थोड़ा सा दुखी होना (शब्द को वास्तव में बुरा मानने के लिए अतिरिक्त तीन अक्षर हैं?) इसे एक ऐसी भाषा में बनाते हैं जो अब तक function बजाय func , और इसी तरह। यह ऐसा कुछ नहीं है जिस पर कोई भी भाषा अस्वीकार करने जा रही हो, लेकिन फिर भी ...

structure वास्तव में PL / I और विज़ुअल बेसिक में उपयोग किया जाता है। VB में structure immutable । हालांकि struct इतना आम है मुझे लगता है कि यह लगभग एक नया शब्द बन गया है।

मुझे आश्चर्य है कि अगर यहां भी देशी बोलने का मुद्दा है। मेरे लिए जो इस संदर्भ में struct का उपयोग करने के लिए उपयोग किया जाता है वह structure है जो अधिक अजीब लगता है। उसी कारण से func भयंकर लगता है और function प्राकृतिक।

क्या विभिन्न प्रोग्रामिंग भाषाओं में इसके उपयोग के कारण struct एक स्व-निहित शब्द नहीं है? शब्द structure (कम से कम मेरे लिए एक जर्मन मूल निवासी के रूप में) बहुत अधिक सार है। उदाहरण के लिए कि टाइप पदानुक्रम में एक निश्चित "संरचना" होती है।

func मेरे लिए कोई स्व-निहित शब्द नहीं है, बल्कि सिर्फ एक संक्षिप्त नाम है।

func मेरे लिए कोई स्व-निहित शब्द नहीं है, बल्कि केवल एक संक्षिप्त नाम है।

कैसे एक संक्षिप्त रूप में भी संरचना नहीं है? क्या यह संरचना के लिए शाब्दिक रूप से छोटा नहीं है, या क्या मैंने केवल शब्द को गलत समझा है? आप func तुलना में इसके अधिक

वैसे भी, मैं mutable पसंद करूंगा, इसलिए मैं _too_ की गहराई से परवाह नहीं करता अगर यह संरचना या संरचना है। उत्परिवर्तनीय const जो अब immutable है उसके लिए हर समय लिखने से बचना होगा।

लेकिन, भले ही यह struct या strct या stct या strctr होने की संभावना न हो, यह बहुत कम संभावना है कि मैं जूलिया को किसी अन्य भाषा के लिए बदल दूं मेरा काम, इसलिए ... :)

क्षमा करें यदि यह अंग्रेजी में समझ में नहीं आता है: लेकिन struct construct का संक्षिप्त नाम नहीं है। कम से कम जर्मन में Konstrukt शब्द एक समग्र प्रकार का वर्णन करने के लिए बहुत अधिक समझ में आता है।

अंग्रेजी में यह बताने में सक्षम नहीं किया जा रहा है कि क्या construct एक संज्ञा है या क्रिया ने संभवतः अंग्रेजी-आधारित प्रोग्रामिंग भाषाओं में इसका उपयोग शुरू कर दिया है :) अपरकेस का जर्मन उपयोग वहां सहायक है।

struct का अपना एक ही शब्द है जिस तरह से TV, ASAP और LOL शब्द हैं। मैंने शायद ही कभी लोगों को "संरचना" कहते सुना है। मेरे अनुभव में, शब्द "संरचना" है, जो बोला और लिखा गया है।

BTW: Matlab struct शब्द का उपयोग करता है, अगर इससे कोई फ़र्क पड़ता है।

OTOH, जैसा कि ऊपर उल्लेख किया गया है, C # और स्विफ्ट struct एक मूल्य प्रकार ( class विपरीत) से मेल खाती है। तो उत्परिवर्तनीय और अपरिवर्तनीय दोनों प्रकारों के लिए समान शब्दावली का उपयोग करने से वास्तव में इन भाषाओं से परिचित लोगों को मदद नहीं मिलेगी। यकीन नहीं होता कि क्या निर्णायक बात है ...।

mutable / immutable सबसे स्पष्ट पसंद की तरह लगता है, जो नए लोगों के लिए काफी स्पष्ट होना चाहिए।

struct उपयोग करने वाली विभिन्न भाषाओं की बड़ी संख्या को देखते हुए, मुझे नहीं लगता कि उस नाम का उपयोग करने के लिए समान शब्दार्थ होने की आवश्यकता है।

मुझे type और const type सबसे अच्छा लगता है, लेकिन यह type कीवर्ड को मुक्त नहीं करता है। चूंकि मुझे नहीं पता कि type लिए क्या योजना बनाई गई है, मुझे नहीं पता कि यह कितनी बड़ी लागत है।

लेकिन चूंकि type हिस्सा पहले से ही abstract में निहित है, शायद mutable और immutable करके खुद को सबसे अधिक समझ में आता है। और इसकी कम टाइपिंग कि immutable struct और एक छोटा सा बदलाव (टाइप -> म्यूटेबल)।

शब्द संरचना (कम से कम मेरे लिए एक जर्मन मूल निवासी के रूप में) बहुत अधिक सार है।

जब हम भाषा पर बहस कर रहे हैं, हर कोई उस संक्षिप्त नाम की राशि को कम कर रहा है जो struct । यह "डेटा संरचना" के लिए छोटा है। इसी तरह, मैं कहूंगा कि "डेटा प्रकार" के लिए type कम है। मैं कहता हूं कि एक सरणी या बफ़र भी एक डेटा संरचना है, जैसा कि एक लिंक की गई सूची है, और इसी तरह, लेकिन struct में पहले आम डेटा संरचनाओं में से एक के रूप में शुरुआती जड़ें हैं और कंप्यूटिंग के भीतर यह एक के लिए आया है अपने स्वयं के और अधिक विशिष्ट अर्थ (और इसलिए अंग्रेजी के मूल निवासी या अन्यथा, यह structure रूप में सार के रूप में ध्वनि नहीं करता है)।

-1 से struct । मैं इस शब्द का उपयोग यह समझाने के लिए नहीं करता हूं कि जब तक मैं C प्रोग्रामर से बात नहीं कर रहा हूं, तब तक किस प्रकार की परिभाषा है, और उसके बाद केवल यह उल्लेख करना है कि लेआउट संगत है और उनके गुणों की तुलना / तुलना करना है।

मैं वास्तव में के बारे में इस तरह से लग रहा है struct । मुझे लगता है कि हम बिना किसी विशेष कारण के जूलिया के लिए एक नया शब्द पेश करेंगे।

-1 से const । सी बिल्कुल कम से कम कीवर्ड रखने की इस दिशा में चला गया, और अब हम कई कीवर्ड के साथ संदर्भ-संवेदनशील अर्थों के साथ फंस गए हैं। मुझे नहीं लगता है कि कॉन्स्ट इन प्रकारों की महत्वपूर्ण संपत्ति है, बल्कि यह है कि वे मूल्य प्रकार हैं (संदर्भ प्रकारों के विपरीत)।

जेफ ने मुझे समझाया (बहुत विनम्रता से) कि हम मूल्यों या संदर्भों या जो भी हैं, उसके ऊपर ध्यान नहीं देते हैं - ये कार्यान्वयन विवरण हैं, शब्दार्थ नहीं और भविष्य के सुनहरे युग में _ हम सिर्फ care_ नहीं करेंगे। संकलक (जो कुछ आवश्यक रूप से एफएफआई की गारंटी के साथ) चाहते हैं, चीजें "पास-बाय-शेयरिंग" हैं। पिछले कुछ दिनों में मैं पहले ही कह चुका हूं कि "शेयर-बाय-मैजिक" और मुझे लगता है कि यह मेरे लिए एक रहस्योद्घाटन रहा है कि मानसिक दबाव का एक गुच्छा (आदर्श रूप से) मुझे अभी सोचने की ज़रूरत नहीं है ( @vtjnash आपने देखा है कि मैंने मूल्यों और संदर्भों के साथ कैसे संघर्ष किया है और ये कैसे कंपाइलर और जीसी और अन्य पैकेजों और थ्रेड्स द्वारा कार्यान्वित किए जाते हैं)।

बाइंडिंग या तो बदल सकते हैं या स्थिर हैं (हम const लेकिन constant भी बहुत प्यारा है)। इसी तरह, एक समग्र डेटा प्रकार के अंदर फ़ील्ड्स की बाइंडिंग या तो बदल सकती है या स्थिर होती है। यही कारण है कि मैंने पहले प्रत्येक क्षेत्र में const स्पष्ट रूप से संलग्न करने का सुझाव दिया था - इसने शब्दार्थ को स्पष्ट (कम से कम मेरे लिए) कर दिया।

IMO को इस सामग्री के बारे में बात करने के लिए "उत्परिवर्तन" और "अपरिवर्तनीय" जैसे फैंसी शब्दों का उपयोग करने की आवश्यकता नहीं होनी चाहिए। किसी वस्तु का किसी नई वस्तु के लिए पुनर्जन्म हो सकता है, या फिर वह स्थिर होती है। जूलिया के बारे में हमारे प्रवचन से struct और immutable जैसे जटिल अंग्रेजी भाषा के शब्दों की आवश्यकता को हटाकर (न केवल कोड) एक अच्छी चीज के रूप में देखा जाना चाहिए (एक लक्ष्य, यहां तक ​​कि)।

मुझे यह भी लगता है कि "संरचना" इसका अपना शब्द है (सी में इसका अर्थ क्या है) जबकि "संरचना" संभवतः एक "डेटा संरचना" है - क्योंकि यदि आपका मतलब रिकॉर्ड प्रकार है, तो आप कहेंगे "संरचना"। लेकिन मैं अपनी सी जड़ें यहां दिखा रहा हूं।

यह आम लिस्प में भी है; defstruct ।

संभवतः यहां अन्य अधिकांश बिंदुओं की तुलना में अधिक तुच्छ, लेकिन जब तक हम बिकेशिंग कर रहे हैं: जब जोर से बात की जाती है, तो वाक्यांश immutable object और a mutable object ध्वनि कष्टप्रद समान हों। यह जूलिया के प्रकार प्रणाली के बारे में बातचीत करना अधिक कठिन होगा, जितना कि यह होना चाहिए। संपादित करें: ऐसा लगता है कि यह पहले से

+1 से type -> struct और immutable -> const struct । मुझे नहीं लगता कि मैं कभी किसी से मिला हूं, जो इससे भ्रमित हो, विशेष रूप से एक सरसरी स्पष्टीकरण के बाद।

type जगह v0.6 के लिए यथार्थवादी है, और v0.8 के लिए अवास्तविक है। हमें ऐसा करना चाहिए। यह स्पष्ट संचार और अभिव्यंजक रैपिडिटी के लिए जूलिया की प्राकृतिक प्रतिभा को और अधिक सुचारू बनाने और बेहतर बनाने का अवसर है। प्रकार अच्छी तरह से काम कर रहे सॉफ़्टवेयर बनाने के बहुत सारे हैं। टाइपिक चीजों का बेहतर नामकरण शक्तिशाली रूप से प्रतिध्वनित होता है और जूलिया के भविष्य को और आगे ले जाएगा।

मेरा सुझाव है कि struct अप्रयुक्त छोड़ दें। सी में, एक संरचना टाइप-फिक्स्ड फ़ील्ड के एक निश्चित अनुक्रम के लिए एक सिंटैक्टिक कंटेनर है। जूलिया सी नहीं है, और जूलियन प्रवचन में एक सी-आईएसएम को खींचना जूलिया के पहलुओं को अवधारणा के सर्वोत्तम तरीकों के बेहतर उपयोग के गंभीर चर्चा के बाहर जूलिया के एपिफायरल प्रकृति को धक्का देगा।

इसके अलावा, "अपरिवर्तनीय" और "उत्परिवर्तित" बहुत अधिक नेत्रहीन हैं। हम बेहतर कर सकते हैं।

  immutable ComplexNumber ... end

  alterable MethodTable   ... end

@JeffreySarnoff समुदाय के मानकों के अनुसार, जूलिया को "इसे" के रूप में संदर्भित करना पसंद करते हैं। बस सोचा था कि मैं इसका उल्लेख करूंगा। 🙂

@ararslan जूलिया पर समुदाय मानक मार्गदर्शन बदल गया है, अब साहित्यिक सर्वनाम के आवेदन। इसे मेरे ध्यान में लाने के लिए धन्यवाद। :क्रिकेट:

स्त्रीलिंग सर्वनाम का उपयोग करना, अपने आप में, बुरा नहीं है (और कई भाषाओं में अनुपयोगी), लेकिन ऐसा लगता है कि कई लोग "उसे" शब्द का उपयोग करने से कूदने के लिए जूलिया के बारे में गर्म तारीख के रूप में बात करना अपरिवर्तनीय पाते हैं, इसलिए यह सबसे अच्छा है। जितना संभव हो उतना प्रलोभन से बचें।

धन्यवाद

Thu, Nov 3, 2016 को शाम 4:29 बजे, स्टीफन करपिंस्की सूचनाएं @github.com
लिखा था:

स्त्रीलिंग सर्वनाम का उपयोग करना, अपने आप में, बुरा नहीं है (और कई में अपरिहार्य है
भाषाएँ), लेकिन ऐसा लगता है कि बहुत से इसे उपयोग करने से कूदना अपरिवर्तनीय लगता है
शब्द "उसकी" जूलिया के बारे में एक गर्म तारीख के रूप में बात करने के लिए, इसलिए यह सबसे अच्छा लगता है
जितना संभव हो उतना प्रलोभन से बचें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/JuliaLang/julia/issues/19157#issuecomment -25256464,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABmqxopTX8oWKbwnLxfCBtIv-Ih7l-nXks5q6kRFgaJpZM4KkN_g
।

हाथ में मुद्दे के संबंध में, मैं व्यक्तिगत रूप से इस बारे में अनिच्छुक हूं कि मैं सबसे अच्छे बदलाव पर क्या विचार करूंगा। लेकिन मुझे जूलिया के अद्भुत _type_ सिस्टम के बारे में बात करना अजीब लगता है और फिर निर्दिष्ट करें कि एक प्रकार का निर्माण करने के लिए उपयोग किया जाने वाला कीवर्ड वास्तव में struct बजाय type । मुझे लगता है कि यह लोगों को इसके बजाय प्रकार के बारे में बात करने के लिए प्रोत्साहित कर सकता है, अंततः जूलिया का वर्णन करने के लिए इस्तेमाल की जाने वाली भाषा में बदलाव के लिए अग्रणी है, उदाहरण के लिए जूलिया के अद्भुत _struct_ प्रणाली पर चर्चा करना।

एक प्रकार का निर्माण करने के लिए उपयोग किया जाने वाला कीवर्ड वास्तव में टाइप के बजाय संरचना है

लेकिन कीवर्ड वास्तव में प्रकारों के निर्माण के बारे में नहीं है --- उदाहरण के लिए अभिव्यक्ति Tuple{Int} भी एक प्रकार का निर्माण करती है। यह बहुत अच्छा होगा यदि वर्तमान में type साथ परिभाषित की गई चीजों को हमेशा struct s के रूप में संदर्भित किया जाता है, तब से कोई भ्रम नहीं होगा कि Real एक प्रकार है, और Union{Int8,Int16} एक प्रकार है, आदि।

हां, मैं अपना पूर्व नोट संपादित कर रहा हूं और अभी उस बारे में लिखा है। यह होगा
जूलिया के "देखभाल और भोजन" के लिए व्यापक रूप से हानिकारक
भविष्य की अभिव्यक्ति शक्ति और संक्षिप्तता का विकास। दरवाजा होना चाहिए
के रूप में जूलिया के प्रकार प्रणाली के विचार को वैध बनाने के लिए खोला गया
सी संरचनाओं पर मचान, युद्ध खो गया है।

Thu, Nov 3, 2016 को शाम 4:38 बजे, एलेक्स अर्सलान नोटिफिकेशन @github.com
लिखा था:

हाथ में मुद्दे के संबंध में, मैं व्यक्तिगत रूप से मैं क्या हूँ के बारे में अनिर्दिष्ट हूं
सबसे अच्छा बदलाव पर विचार करेंगे। लेकिन बात करना मुझे अजीब लगता है
जूलिया का अद्भुत _type_ सिस्टम और फिर निर्दिष्ट करें कि कीवर्ड किसके लिए उपयोग किया जाता है
एक प्रकार का निर्माण वास्तव में प्रकार के बजाय संरचना है। मुझे लगता है कि यह हो सकता है
लोगों को प्रोत्साहित करने के बजाय प्रकारों के बारे में बात करने के लिए प्रोत्साहित करें, अंततः अग्रणी
जूलिया का वर्णन करने के लिए इस्तेमाल की जाने वाली भाषा में एक बदलाव, उदाहरण के लिए जूलिया की चर्चा करना
अद्भुत _struct_ प्रणाली।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/JuliaLang/julia/issues/19157#issuecomment -258266857,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABmqxsZ_rXkn6GpVFxhd6TZnkkao9plWks5q6kZggaJpZM4KkN_g
।

यह बहुत अच्छा होगा यदि वर्तमान में type साथ परिभाषित की गई चीज़ों को हमेशा struct s के रूप में संदर्भित किया जाता है, तब से कोई भ्रम नहीं होगा कि Real एक प्रकार है, और Union{Int8,Int16} एक प्रकार है, आदि।

क्या वर्तमान में इस बारे में भ्रम है? मुझे लगता है कि मेरे लिए बहुत स्पष्ट लग रहा था, हालांकि शायद मैं इसके बारे में चर्चा करने से चूक गया हूं।

@ararslan : type का शब्द वर्तमान में निर्मित किए गए कार्यों के लिए सामान्य है। वर्तमान में हम type कीवर्ड के साथ जो निर्माण करते हैं वह एक ऐसी संरचना है जिसमें समग्र प्रकार होते हैं। लेकिन जूलिया के भीतर कई अन्य प्रकार हैं जो type कीवर्ड का उपयोग करके नहीं बनाए गए हैं।

नहीं, मुझे नहीं लगता कि उस समय इस बारे में बहुत अधिक भ्रम है, लेकिन न ही हर कोई सोचता है कि सभी प्रकार के जूलिया संरचनाएं हैं यदि हमने कीवर्ड struct ।

ठीक है, अच्छी बात है।

और यूनियन {Int8, Int16} एक प्रकार है

आह। मैं भूल गया था कि Union भी मौजूद है। जो struct ( Struct ?) को और अधिक सम्मोहक, IMO का तर्क देता है। हालांकि अभी भी mutable और immutable नहीं है।

मुझे लगता है कि _struct_ आग्नेय और सच में विश्वास है कि जूलिया को ले जाने के लिए, समय के साथ, विकसित होने वाले जिटजिस्ट को नीचे की ओर खींचना होगा। सिद्धांत गति में बिट्स के विस्तार के बीच एक विरोधाभास है और कम्प्यूटेशनल मेब्स की अभिव्यक्ति उच्च-क्रम के पिघलने और गहरे इशारों के रूप में है। struct का उपयोग करने से हर किसी को इस बात के बारे में सोचने का मौका नहीं मिलेगा कि एक बिंदु किसके पास है। ... मुझे अति करने दो ...

मैं यह तर्क नहीं दे सकता कि एक पेटेंट क्लर्क के रूप में आइंस्टीन के बारे में लिखना उनके योगदान की सराहना को कम करता है। इसका पालन नहीं होता है, एक ऐसे पाठ्यक्रम में, जहां अल्बर्ट आइंस्टीन के संदर्भ में पेटेंट क्लर्क के रूप में अपने समय के आयात को समाप्त कर दिया गया था, कुछ से अधिक छात्र भविष्य की बातचीत में इसके बारे में कुछ समझेंगे। यह एक बात है so यह सुनिश्चित नहीं करता है कि यह एक नए स्कूल में जाने के बाद सिर्फ so व्यवहार करता है।

अगर _struct_ का उपयोग करने के लिए सम्मोहक मामला है, तो किसी एक के लिए एक बेहतर मामला होना चाहिए

एक structure भागों का एक सार्थक अंतर्संबंध है, एक सूचित रचना
construct प्रासंगिकताओं की एक उपयोगी संरचना है, एक मूल्य-वर्धक डिज़ाइन है

एक अपरिवर्तनीय structure एक कठिन कम्पोजिट है
एक उत्परिवर्तनीय structure एक अप्रकाशित पूर्वानुमान है
एक अपरिवर्तनीय construct एक स्थापित घटना है
एक उत्परिवर्ती construct संदर्भ पर एक जानबूझकर बाधा है

हमें बोलने के तरीके के माध्यम से और "फाटकों के माध्यम से स्थानों में बिट्स" की आवश्यकता होती है और "डेटा स्ट्रक्चरिंग से ऑन्कोलॉजिकल जानकारी का पता चलता है" और इसे बोलने के रूपांतरण संशोधक तरीके के रूप में उपलब्ध कराया जा सकता है। सामुदायिक प्रतिभागी, जो सीएस टैलेंट हैं और अधिकांश अन्य डोमेन विशेषज्ञ हैं, जो बड़े पैमाने पर प्रोग्राम करते हैं, उनके पास बाइट्स, मेमोरी, लॉजिक, इंस्ट्रक्शनल ऑपरेशंस आदि का गहन प्रबंधन होता है। इच्छा, रचनात्मकता, संभावनाएं और कल्पना बनाने का दूसरा तरीका सॉफ्टवेयर है जो अच्छी तरह से काम करता है और है अच्छी तरह से काम के लायक है - जो कम साझा किया जाता है। शब्द नामकरण के बारे में कोई भी निर्णय उस बात को प्रोत्साहित करने के लिए पहुंचना चाहिए।

class और immutable क्या?

मैं डेल्फी से क्लास जानता हूं और सोचा कि यहां असंभव होगा, लेकिन नीस भाषा में, जिसमें मल्टीमिथोड्स है, इसका उपयोग एक कीवर्ड ( लिंक ) के रूप में किया जाता है। और - अगर मैं मैनुअल को सही ढंग से पढ़ता हूं - हास्केल और डायलन में भी। यह "क्लास वन टाइप का एक प्रकार" टेस्ट पास करता है और अभी भी काफी अस्पष्ट है (जैसा कि 'टाइप' आज), मुझे कुछ पसंद है। 15:00 - 15:20 मिनट पर 'एरेस एंड इटरेशन' वीडियो के एक अवलोकन में, टिम होली (आकस्मिक रूप से) 'क्लास' कहते हैं, एक महत्वहीन विवरण लेकिन फिर भी शायद यह दर्शाता है कि जूलिया संदर्भ में क्लास कुल विदेशी नहीं होगी।

अन्यथा, reftype और immutable ? प्रारंभिक टिप्पणी में उल्लिखित शब्द का उल्लेख किया गया था और तब से इसे नजरअंदाज किया गया है। क्यों? मेरे लिए यह काफी अच्छा लगता है, प्रकार को मुक्त करता है और संदर्भ अर्थ को स्थानांतरित करता है।

(मुझे 'नए' कीवर्ड का उद्देश्य समझ में नहीं आया। बिना बदलाव के सभी लाइनों में 'नया' नहीं छोड़ा जा सकता है! 'मूल्य' और 'रिकॉर्ड' शब्द कीवर्ड होंगे और वर्तमान में उपयोग किए गए 'अपरिवर्तनीय' की जगह लेंगे। और 'टाइप', सही? '

इन दोनों प्रकारों के बीच @swissr केवल अंतर (ज्यादातर उपयोगकर्ताओं को पता होना चाहिए) यह है कि एक में फ़ील्ड बदल सकते हैं और दूसरे में फ़ील्ड नहीं कर सकते। यह तर्कसंगत होगा यदि उनके नामों ने उनके एकमात्र अर्थ भेद का संकेत दिया। (जैसा कि उल्लेख किया गया है, मूल्यों और संदर्भों का उपयोग करने वाला कार्यान्वयन तरल है - उदाहरण के लिए एक संकलक एक अनुकूलन के रूप में संदर्भ द्वारा स्वचालित रूप से बड़े isbits पास कर सकता है, और इसके विपरीत छोटे परिवर्तन कुछ स्थितियों में स्टैक में जा सकते हैं)।

type struct , मैं देखता हूं कि मैं abstract , Union{} , typealias और इतने पर Tuple{} के मामले में यह एक नया प्रकार या बस एक पैरामीटर प्रकार) होने पर यकीनन तर्कपूर्ण है, लेकिन वास्तव में केवल _user- परिभाषित कंक्रीट टाइप_ bitstype , type द्वारा बनाए जाते हैं। immutable । इन के लिए वाक्यविन्यास अचूक wrt अमूर्त परिभाषा है कि वे डेटा को परिभाषित करते हैं जिसमें वे किसी भी तरह होते हैं, और अमूर्त वाले नहीं होते हैं। immutable से const type बदलने से मुझे स्थिति स्पष्ट हो जाएगी।

मैं भाषा के बारे में चिंता करता हूं और तकनीकी शब्द struct प्रचार केवल परंपरा होने के कारण करता हूं, जब हमारे पास एक प्रोग्रामिंग भाषा बनाने का अवसर होता है जो आम आदमी की शर्तों पर चर्चा की जाती है। एक उदाहरण जहां मुझे लगता है कि यह मदद नहीं करेगा, जब मैं Symmetric{Matrix{T}} जैसे एक आवरण प्रकार बनाता हूं - मैं नहीं चाहता कि मेरी चर्चाएं हों, "मैंने इस struct को केवल एक फ़ील्ड के साथ बनाया कौन सा ... "जब मैं कह सकता हूं" मैंने Symmetric रैपर type Matrix "(ध्यान दें कि उस वाक्य का आधा वास्तविक वाक्यविन्यास है)। एक "आवरण संरचना"? मूर्खतापूर्ण लगता है - और कौन एक क्षेत्र के साथ एक संरचना बनाता है? उस मामले के लिए, बिना किसी क्षेत्र वाले एकल के बारे में क्या? types और immutables एक बड़ा अंश किसी भी (गैर-तुच्छ) डेटा संरचना को बनाने के लिए परिभाषित नहीं किया जाता है, बल्कि रैपर और सिंगलटन के साथ शक्तिशाली प्रकार और प्रेषण प्रणाली का उपयोग करने के व्यक्त उद्देश्य से किया जाता है। IMO यह जूलिया का सबसे दिलचस्प, शक्तिशाली और अभिव्यंजक पहलू है (इस तथ्य के साथ संयुक्त है कि यह _fast_ है)।

मुझे लगता है कि struct की पूरी शक्ति केवल अनुभवी टेम्पलेट C ++ मेटाप्रोग्रामर्स को तुरंत स्पष्ट हो जाएगी, जो जानते हैं कि वे लक्षण, आदि को लागू कर सकते हैं, संरचना के साथ, और यह थोड़ा शर्म की बात है।

"किड" का प्रकार सिद्धांत में काफी विशिष्ट तकनीकी अर्थ है।

यदि लक्ष्य / लाभ type को मुक्त करना है तो कैसे:

const datatype  # immutable
datatype        # type

वे ठोस प्रकार हैं इसलिए उनमें संभवतः डेटा होता है, और यह DataType का निर्माण करने के कई (एक) तरीकों में से एक है।

"किड" का प्रकार सिद्धांत में काफी विशिष्ट तकनीकी अर्थ है।

विकी का परिचय बिलकुल Type{} (जो DataType और TypeConstructor , Union , आदि) को स्वीकार करता है (EDIT: ऐसा नहीं है कि मुझे लगता है कि ऐसा कोई बदलाव है। विघटन के लायक है)

kind यहाँ सही शब्द नहीं है।

मुझे लगता है कि अक्सर सबसे अच्छा तरीका सिर्फ एक क्षेत्र सीखना है
मानक शब्दावली के बजाय आप इसे कुछ के साथ बदलने की कोशिश कर रहे हैं
अनुमान आसान हो जाएगा।

यह निर्णय अनौपचारिक भाषण को प्रभावित नहीं करता है। आप अभी भी समझदारी से कह सकते हैं “मैं
एक प्रकार को परिभाषित किया गया "। अधिक विशिष्ट कीवर्ड का उपयोग करना आसान बनाता है
आपको सटीक होने की आवश्यकता है।

फेयर पॉइंट, जेफ। कृपया ध्यान दें कि मैं _do_ लगता है कि const struct और struct immutable type से अधिक का सुधार होगा (लेकिन इसका मतलब यह नहीं है कि हमें खोज नहीं करनी चाहिए। कुछ और भी बेहतर)।

जब आप सोचते हैं कि संरचना एक संरचना के रूप में अधिक है या एक निर्माण के रूप में, न तो या दोनों के रूप में?

@ कैंडीफ्रीज ने मेरी 'क्लास' और 'रिफ़ॉस्टाइप' टिप्पणी का मतलब यह नहीं था कि मैं 'कास्ट टाइप' भी पसंद नहीं करूंगा या उस const struct समर्थन नहीं करूंगा और struct एक सुधार होगा। 'कॉन्स्ट' से बचना, 'अपरिवर्तनीय' को बचाए रखना और 'स्ट्रक्चर' को बनाए रखना (जब यह उल्लेखित कार्यान्वयन के बारे में पता था, तो यह कहना सही होगा कि 80plus% मामलों में यह ठीक है) ।

fieldtype (या fieldstype ) कैसे? यह के समानांतर है bitstype और के साथ संगत fieldnames() ।

ग्लेन,
मुझे सत्यनिष्ठा पसंद है। फ़ील्डस्टाइप बेहतर विकल्प है क्योंकि बहुवचन रूप का उपयोग करना जहां कुछ विलक्षण हो सकता है या बहुवचन उचित है।
--Jeffrey

class ठीक हो सकता है; हमने मूल रूप से वस्तुओं के अंदर तरीकों के साथ वर्ग-आधारित OO के साथ इसके जुड़ाव के कारण इसे अस्वीकार कर दिया। मैं कहूंगा कि struct अधिक सटीक है।

मैं किसी भी चीज़ के लिए struct कम नहीं देखता; यह सिर्फ इस प्रकार की डेटा संरचनाओं को इस बिंदु पर कहा जाता है। कुछ हद तक मनोरंजक, लिस्प में cons , जो मूल रूप से construct लिए एक संक्षिप्त नाम हो सकता है, लेकिन लोग यह भूल गए कि बहुत जल्दी और बस "कॉन्स सेल" के बारे में बात करना शुरू कर दिया।

मुझे लगता है कि हमें class को अस्वीकार करना जारी रखना चाहिए। उस शब्द का उपयोग करने से जूलिया शैली में काउंटर चलाने वाले ओओपी उम्मीदों की एक पूरी श्रृंखला को आमंत्रित किया जाएगा।

मुझे किसी भी चीज़ के लिए struct कम नहीं दिख रहे हैं, लेकिन मुझे चिंता है कि C के स्ट्रक्चर के लिए निहित संदर्भ का अर्थ है कि जूलिया का मूल्य प्रकार होगा, जो वे नहीं हैं, ज़ाहिर है। इस समय तक, मैं वर्तमान में record ओर थोड़ा सा झुक रहा हूं क्योंकि इसमें अभी तक तत्काल कम अनुमान हैं।

एक बिंदु को स्पष्ट करने के लिए जो स्पष्ट नहीं हो सकता है, मुझे लगता है कि const record या const struct का उपयोग करना केवल व्यवहार्य है यदि इसे सभी क्षेत्रों में const मैपिंग के लिए छोटा होने के अर्थ में समझा जाए। , यह कहते हुए कि हम व्यक्तिगत क्षेत्रों को const रूप में चिह्नित करना चाहते हैं। तो मैं जो कह रहा हूं वह यह है कि हम ये कर सकते हैं:

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

यहाँ T3 और T4 वास्तव में समतुल्य प्रकारों का वर्णन करते हैं - अर्थात const record लिखना, सभी क्षेत्रों के लिए const शॉर्टहैंड है। यदि यह व्याख्या नहीं है, तो मुझे लगता है कि कब्ज के साथ अपरिवर्तनीयता का अनुमान खतरनाक है क्योंकि यह पहले से ही वैचारिक भ्रम का एक सामान्य स्रोत है और अगर हम उस शब्दावली भ्रम में जोड़ते हैं, तो हम मामलों में मदद करने वाले नहीं हैं।

यहाँ T3 और T4 वास्तव में समतुल्य प्रकारों का वर्णन करते हैं - अर्थात कॉन्स्ट रिकॉर्ड लिखना सभी क्षेत्रों के लिए केवल शॉर्टहैंड है।

अगर हम const record मतलब क्या immutable मतलब रखते हैं, तो यह सच नहीं हो सकता है। const record एक संदर्भ प्रकार का वर्णन करेगा जिसके लिए कोई भी फ़ील्ड परिवर्तित नहीं की जा सकती है। जबकि वर्तमान immutable एक मूल्य प्रकार है।

Https://github.com/JuliaLang/julia/issues/19157#issuecomment -257942059 और record की कुछ चर्चा के लिए निम्न टिप्पणी देखें।

@vtjnash यह एक अच्छा बिंदु है, लेकिन यह ऐसा ही है जैसा कि अब होता है जहां immutable एक "संदर्भ" प्रकार बन जाता है यदि इसमें कोई संदर्भ हो।

मुझे लगता है कि तथ्य यह है कि record कम आम है ठीक है, तथ्य यह है कि यह एक संज्ञा और क्रिया दोनों के रूप में एक उपयोगी शब्द है और अधिक समस्याग्रस्त है।

कैसे nuple ? "नामित टपल" के लिए लघु, निश्चित रूप से।

मुझे ऊपर दिए गए सुझाव पसंद हैं

const datatype  # immutable
datatype        # type

अब तक का सबसे अच्छा। यह ऐतिहासिक सामान के साथ एक पुराने शब्द को लाने से बचता है और मुझे पूरी तरह से स्पष्ट लगता है। यकीन है कि यह जूलिया में एकमात्र डेटाटाइप नहीं है, लेकिन यह सामान्य उपयोगकर्ताओं द्वारा परिभाषित सबसे आम है।

क्या दस्तावेज़ीकरण में इसे समझाने के लिए शब्दावली को बदलने की कोई योजना है, इस बिंदु पर अधिक इस तरह अध्यायों के शीर्षक बदल सकते हैं? यदि नहीं, तो मुझे लगता है कि मुझे composite और immutable composite या const composite सबसे अच्छा लगता है। चूँकि const का उपयोग वैश्विक स्थिरांक के लिए भी किया जाता है, इसलिए मैं इन दोनों के लिए const या immutable चयन करूँगा, क्योंकि const यह थोड़ी सी वरीयता के साथ है क्योंकि यह कम। कम से कम शब्द कंपोजिट ज्यादातर नए लोगों के लिए परिचित नहीं होगा, प्रलेखन पर एक नजर डालने और सी नाम के साथ समानता के कारण गलत धारणाओं से बचने के लिए। const बारे में गलत धारणाएं कम होने की संभावना लगती हैं, क्योंकि C ++ में कोई भी व्यक्ति कुछ भी ग्रहण नहीं करना जानता है।

इसके अलावा अपरिवर्तनीयता को इंगित करने के लिए दो शब्दों का उपयोग करने का लाभ संभव भविष्य const abstract और const bitstype की आवश्यकता से मुक्त होता है।

अगर हम कॉन्स्ट रिकॉर्ड बनाते हैं तो इसका मतलब क्या अपरिवर्तनीय है, यह सच नहीं हो सकता है। कॉन्स्ट रिकॉर्ड एक संदर्भ प्रकार का वर्णन करेगा जिसके लिए कोई भी फ़ील्ड नहीं बदला जा सकता है। जबकि वर्तमान अपरिवर्तनीय एक मूल्य प्रकार है।

उह ओह। मैंने सोचा था कि immutable का मूल्य-या-नेस कार्यान्वयन स्तर पर परिभाषित किया गया था, और सभी उपयोगकर्ता इस बात पर विचार करने के लिए हैं कि फ़ील्ड रीबाउंड नहीं हो सकते। मूल्य से गुजरना (या नहीं) तो एक शुद्ध ABI मुद्दा है, जहां संकलक सिद्धांत रूप में स्वतंत्र होना चाहिए जो कुछ भी अधिक कुशल हो। मेरे लिए अपरिवर्तनीय के दृश्यमान शब्दार्थ एक प्रकार के सभी क्षेत्रों में const के वर्तमान शब्दार्थ को लागू करने के बराबर प्रतीत होते हैं।

क्या मैं _still_ अपरिवर्तनीय के उपयोगकर्ता-स्तर के शब्दार्थों के बारे में भ्रमित हूं, या क्या आप यहां कार्यान्वयन विवरण की बात कर रहे हैं?

नुपले के बारे में कैसे? "नामित टपल" के लिए लघु, निश्चित रूप से।

साथ ही record , सही के साथ जा सकते हैं? उदाहरण के लिए, एक नामित टपल एरलंग में record है। और मुझे लगता है कि डेटाबेस की दुनिया में भी।

लेकिन अगर जूलिया के पास उन लोगों के साथ अधिक ओवरलैप है जो C भी जानते हैं, तो struct अधिक उपयुक्त परिवर्तन है।

मैं व्यक्तिगत रूप से record विचित्र और अस्पष्ट है। डेटाबेस की दुनिया में, एक रिकॉर्ड एक तालिका में एक पंक्ति है; ऐसा लगता है कि यह जूलिया प्रकार (अपरिवर्तनीय या अन्यथा) के रूप में कुछ के साथ एक भ्रामक संघर्ष होगा।

इस धागे को फिर से उगाने के बाद मैं composite type की ओर झुक रहा हूं। यह जेफ़ को "एक वाक्य नियम" रखता है और इसके लिए इतने नकारात्मक वोट नहीं मिले हैं। यह शब्द अन्य भाषाओं में इतना अधिक उपयोग नहीं है, मेरी राय में यह कोई मुद्दा नहीं है। और composite वास्तव में सबसे वर्णनात्मक शब्द है जिसे कोई भी उसके लिए खोज सकता है। कारण यह है कि प्रलेखन इन बातों को composite types रूप में संदर्भित करता है।

फोरट्रान से आ रहा है मुझे अभी भी लगता है कि खोजशब्द type सिर्फ ठीक है,
और एक न्यूनतम समझदार परिवर्तन immutable -> const type ।

लेकिन अगर type वास्तव में जाना है,
composite और const composite अगले सर्वोत्तम विकल्प प्रतीत होते हैं।

immutable -> const type निश्चित रूप से व्यवहार्य लगता है: यह एक साथ विघटन से बचता है, एक कीवर्ड को हटाता है, और भाषा में स्पष्टता जोड़ता है।

यह type का उपयोग करने में सक्षम नहीं होने के लिए दुखी हो सकता है लेकिन ईमानदार होना चाहिए जो मैं उपयोग करना चाहता हूं वह Type वैसे भी है। मेरे दस प्रकारों में से नौ बार स्थिर प्रेषण के लिए पैरामीटर हैं न कि गतिशील प्रकार के विश्लेषण के लिए DataType चर (अपवाद उत्पन्न होने वाले कार्य)। जो लोग inference.jl लिखते हैं, उनके लिए सही नहीं है, लेकिन यदि आप करेंगे तो वे वास्तव में भाषा के "लक्षित दर्शक" नहीं हैं।

संबंधित प्रश्न: क्या यह type का उपयोग करने के लिए सभी व्यवहार्य है, क्योंकि यह सबसे ऊपर है, लेकिन एक फ़ंक्शन के अंदर (जहां यह हमेशा अमान्य है, वर्तमान में) इसे एक चर नाम बनाने की अनुमति है? या इससे भी आगे, एक प्रकार की परिभाषा की संरचना बहुत विशिष्ट है ... क्या हम वैश्विक चर (या फ़ंक्शंस) को type लिए बाध्य करने की अनुमति देते समय विशिष्ट परिभाषा के रूप में प्रकार की परिभाषा का पता लगा सकते हैं?

एक प्रकार को परिभाषित करने के लिए सिंटैक्स रखते समय क्या हम कीवर्ड व्यवहार से छुटकारा पा सकते हैं?

(असंभावित इमो) एक मजबूत जोखिम जुड़ा हुआ है: यह बहुत आसान हो जाता है कि इडियोसिंक्रेटिक लेक्सोग्राफी के लिए विचलित हो। और उन लापता सूक्ष्म-निरंतरताएं सहयोग और स्पष्ट संचार के साथ आसानी से नष्ट हो जाती हैं।

@ c42f :

क्या मैं अभी भी अपरिवर्तनीय के इच्छित उपयोगकर्ता-स्तर के शब्दार्थों के बारे में उलझन में हूँ, या आप यहाँ कार्यान्वयन विवरण की बात कर रहे हैं?

नहीं, आप नहीं हैं - मैं मैला हो रहा था। Immutables वास्तव में मूल्य प्रकार नहीं हैं, लेकिन उत्परिवर्तन निश्चित रूप से नहीं होते हैं और मुझे लगा कि C के समान शर्तों का उपयोग करके यह सुझाव दिया जा सकता है कि वे हैं।

मुझे बस एहसास हुआ कि सी के संदर्भ में यह स्पष्ट नहीं है कि क्या यह संरचना को "मूल्य प्रकार" कहने के लिए समझ में आता है, क्योंकि वास्तविक स्थिति यह है कि सी एक पास-बाय-वैल्यू भाषा है। तो यकीनन यह अलग और असाइनमेंट कन्वेंशन हैं जो अलग-अलग हैं, न कि डेटा के प्रकार।

मैं पूरी तरह से इस मुद्दे को खोलने के परिवर्तन को लागू करने के पक्ष में हूं। उपयोगिता किसी भी अभिप्रेरित वरीयता को पछाड़ देती है, जिसका उपयोग उम्मीदवार की अन्य शर्तों के बजाय किया जाता है।

_although_

चूंकि वास्तविक स्थिति यह है कि सी

अभ्यर्थी की शर्तों को अच्छी तरह से पकड़ लेता है, struct मेरा सबसे कम पसंदीदा है

यहां मैं कहानी बेच रहा हूं: "सी और जूलिया दोनों में, एक struct एक डेटा संरचना है जो विभिन्न प्रकारों के मूल्यों के लिए फ़ील्ड नामों का एक निश्चित सेट मैप करता है। लेकिन जब आप इन चारों ओर से गुजरते हैं, तो सी पास होता है। -तब मूल्य और जूलिया पास-पास-साझा है। "

यह खाता नॉन-ऑनर्स और पूरी तरह से सटीक है। इसमें सब कुछ सफलतापूर्वक गुगाया जा सकता है। कोई भी पीएल सिद्धांतकार इसके बारे में शिकायत नहीं करेगा, और गैर-पीएल सिद्धांतकार इसे सुनकर कुछ सीखेंगे।

मैं वह कहानी खरीदता हूं। हालांकि मुझे आश्चर्य है कि, क्या कोई नियम यहां वर्णित है कि एक पीएल सिद्धांतकार _would_ के बारे में शिकायत करते हैं? मुझे लगता है कि जूलिया उस जगह पर सही बैठता है जो पीएल सिद्धांतकारों और गैर-सिद्धांतवादियों दोनों को समान रूप से संतुष्ट करता है, इसलिए शुद्धता और सामान्य स्पष्टता के बीच एक संतुलन बनाना महत्वपूर्ण लगता है।

खैर, मैं किसी के मुंह में शब्द नहीं डालना चाहता; मैं सिर्फ इस विचार को संबोधित करना चाहता था कि struct को" मूल्य प्रकार "होने के कारण भ्रमित किया जा सकता है।

मुझे लगता है कि immutable को एकल-शब्द कीवर्ड रहना चाहिए। मुझे const type या const struct या immutable struct । मैं immutable बहुत का उपयोग करता हूं और मुझे लगता है कि इन घोषणाओं के लिए वास्तव में काफी अजीब होगा जब दो चीजें बाकी सब एक शब्द के बारे में होंगी। टाइपिंग के अर्थ में नहीं, क्योंकि यह वास्तविक चिंता नहीं है; लेकिन इस अर्थ में कि "टैग" की तरह अपरिवर्तनीय होने से यह दूसरे दर्जे का लगता है।

@TotalVerb मुझे नहीं लगता कि इस तथ्य के साथ बहुत संगत है

type MyType
    const field::Int
end

बिल्कुल वैसा ही व्यवहार करना चाहिए

immutable MyType
    field::Int
end

अब करता है।

यह देखते हुए कि, const type (या const struct , const composite , या जो भी हो) प्रत्येक क्षेत्र में const का प्रसारण एक शॉर्टकट के रूप में एक उपयोगी लगता है (हालांकि सख्ती से आवश्यक नहीं) सुविधा। मुझे उम्मीद है कि भविष्य में कंपाइलर को यह भी पता नहीं होगा कि आपने किसको टाइप किया है (प्रत्येक क्षेत्र के सामने const type या const - पूर्व पार्सर द्वारा बाद में बदल सकता है)। उस बिंदु पर, क्यों immutable ?

एक "टैग" की तरह अपरिवर्तनीय होने से यह दूसरे दर्जे का लगता है।

अगर मैं जेफ और स्टीफन को सही ढंग से समझता हूं, तो, immutable केवल एक टैग है जो कहता है कि एक प्रकार के क्षेत्र निरंतर बाइंडिंग हैं। निरंतर (_really_ स्थिर, C की तरह नहीं) होने से कंपाइलर को अनुकूलन करने में मदद मिलती है, और यदि फ़ील्ड स्वयं स्थिरांक या आदिम हैं तो पुनरावर्ती (यानी isbits ) यह और भी अधिक अनुकूलन बनाने में मदद करता है। यह अच्छी तरह से पता है, लेकिन महत्वपूर्ण रूप से महत्वपूर्ण नहीं है। वर्तमान व्यवहार को शब्दार्थ बांधने से भविष्य में उस व्यवहार को सुधारना अधिक कठिन हो सकता है।

लेकिन वहाँ _is_ एक महत्वपूर्ण शब्दार्थ अंतर है: अपरिवर्तनीय प्रकार मूल्य हैं, और इस प्रकार कोई भी सुरक्षित रूप से मान सकता है कि किसी वस्तु की पहचान उसके क्षेत्रों द्वारा निर्दिष्ट है। उपयोगकर्ता के दृष्टिकोण से, एक अपरिवर्तनीय प्रकार की एक वस्तु है, कोई विशेष "पहचानने की विशेषता" अपने क्षेत्रों से सुलभ नहीं है। गैर-सिंगलटन उत्परिवर्तित प्रकार की कोई भी वस्तु, दूसरी ओर, स्पष्ट रूप से इस अदृश्य "पहचान" की है। तथ्य यह है कि कई अपरिवर्तनीय प्रकारों को बॉक्सिंग ऑब्जेक्ट्स के रूप में संग्रहीत किया जाता है, और इसलिए वास्तव में आंतरिक रूप से यह अतिरिक्त पहचान है, शब्दार्थ के लिए अप्रासंगिक है।

मेरी राय में, यह सिर्फ एक _optimization_ करने के लिए नहीं है

immutable Complex{T} ... end

के बजाय

type Complex{T} ... end

क्योंकि उपयोगकर्ता-दृश्यमान व्यवहार के कई पहलू बदलते हैं: === , डिफ़ॉल्ट == , objectid , hash , आदि। यह कहना सही नहीं है कि अपरिवर्तनीय प्रकार उत्परिवर्तनीय प्रकारों की कार्यक्षमता का सबसेट प्रदान करते हैं; इसके विपरीत, बहुत तथ्य यह है कि वे अपरिवर्तनीय हैं महत्वपूर्ण गारंटी देता है जो अपरिवर्तनीय प्रकारों को अधिक शक्तिशाली बनाने की अनुमति देता है।

समुदाय const और struct पर बसने से पहले, मैं सिर्फ constant और structure लिए एक और प्लग बनाना चाहता था।

1) वास्तविक शब्दों के लिए सिर्फ तीन अतिरिक्त अक्षर!
2) दावे के बावजूद कि struct मुहावरेदार हो गया है
2a) कोई व्यक्ति जो R (मेरी तरह) से माइग्रेट हो रहा है, भ्रमित हो सकता है
2 बी) कोई व्यक्ति जो प्रोग्रामिंग में नया है (जिन्हें सबसे अधिक सहायता की आवश्यकता है) भ्रमित हो सकता है

बस मज़े के लिए, मूर्खतापूर्ण शब्द जो संरचना के लिए भ्रमित हो सकते हैं:
अक्षयता
ओब्स्टराकथियनिज़्म
उत्तर-संरचनावाद
अधिरचना (ओह हाय मार्क्स)

और स्तर:
कांस्टेंटिनोपल
CONSTELLATION
बोआ कंस्ट्रिकटर
असंवैधानिक

क्या पीएल सौंदर्य / शक्ति बहुसांस्कृतिक अपरिवर्तनीय और इस प्रकार के कॉन्स्टेंट द्वारा प्राप्त की गई है: अपरिवर्तनीय कभी भी प्रसारण नहीं किया जाता है (इसकी प्रकृति का अनुमान लगाना) इसके सुलझे हुए संदर्भों के माध्यम से / अंदर प्रसारित करना और एम्बेडेड संदर्भों के माध्यम से प्रसारित करना जो अपरिवर्तनीय नहीं हैं, जैसे कि यह एक क्रिया विशेषण या गेरुंड है?

वही प्रश्न, दूसरे शब्दों में:

फिलहाल, वैश्विक स्कोप में वैरिएबल का उपयोग समस्याग्रस्त है और चारों ओर काम करने के लिए trick एक प्रविष्टि के साथ एक सदिश वेक्टर में अलग-अलग मूल्य को लपेटना है। उस स्थिति में const प्रसारित नहीं होता है। const का एक प्रसारण संस्करण लागू होगा? वेक्टर में प्रवेश के मूल्य के साथ ही वेक्टर के लिए निरंतरता। इसी प्रकार, एक प्रकार की घोषणा जिसमें फ़ील्ड होते हैं जो उन मानों को पकड़ सकते हैं जो अन्य प्रकार के मूल्य को लपेटते हैं या संलग्न करते हैं। एक अपरिवर्तनीय प्रकार अब अपने क्षेत्रों के मूल्यों पर अपरिवर्तनीयता प्रदान नहीं करता है (और ऐसा कोई मूल्य नहीं जो अप्रत्यक्ष रूप से उसके क्षेत्रों तक पहुँचा जा सके)। Afaik एक लालित्य और सहायक क्षमता है जो एक कीवर्ड के प्रसारण संस्करण के साथ आता है, जिसका अर्थ है "एक बार निर्मित / इस आइटम के लिए निर्दिष्ट मान [या इस प्रकार की वस्तुओं में] परिवर्तन नहीं करता है [बदलने की अनुमति नहीं है]" ।

तत्काल (गैर-प्रसारण) प्रकार का व्यापक रूप से उपयोग किया जाता है, और कुछ लोगों को यह मानते हुए कि जूलिया के साथ लोग क्या करते हैं, जूलिया के प्रीकंपिलेशन के लिए बेहतर / तेज / सरल बनाने के लिए उपयोग करना आसान है या परिचय प्रसारण योग्यता के साथ भरोसा करना, फिर उसे खेलने की जरूरत है। तत्काल प्रकार के साथ अच्छी तरह से। मुझे आश्चर्य है कि अगर यह एक ऐसा तरीका है जो अतिरिक्त _theoretical प्रोग्रामिंग भाषा goodness_ लाता है (अभिव्यक्ति की आसानी, प्रतिनिधित्व शक्ति, ...): प्रसारण कॉन्स्टेंस प्रसारण उन प्रकारों के मूल्यों के माध्यम से प्रसारित होता है जिनमें एम्बेडेड संदर्भ प्रकार और / या हैं? (ए) एक मूल्य तक पहुंचना जिसमें आंतरिक एम्बेडिंग या कंटेनर नहीं हैं या (बी) एक मूल्य पर पहुंचना स्वयं (स्वतंत्र रूप से या अन्यथा) एक प्रकार का गैर-प्रसारण स्थैतिकता है।

इसके बारे में अधिक सोचने पर, एकमात्र परिवर्तन जो मुझे वास्तव में लगता है कि मूल्य टूटने के लायक है bitstype -> primitive , ज्यादातर इस बात के लिए कि isbits कुछ कॉल करना कितना कष्टप्रद है।

इस चर्चा के वास्तविक बिंदु के रूप में, type और immutable , इस बिंदु पर मुझे जो विकल्प मिल रहा है वह मुझे सबसे अधिक पसंद है कोई बदलाव नहीं है; type एक प्रकार के निर्माण के लिए स्पष्ट है, immutable एक अपरिवर्तनीय प्रकार के निर्माण के लिए स्पष्ट है। हालाँकि, मैं खुशी-खुशी ले जाऊंगा, जो भी हमारे सर्वोच्च अधिपति हमें देते हैं, जैसा कि मैंने स्पष्ट रूप से आगे आने वाली भाषा के लिए उनके निर्णय पर भरोसा किया है।

क्या कोई कारण है कि कब्ज या स्थिरांक के बजाय निश्चित उपयोग नहीं करना है? मेरे लिए कम से कम, बहुत स्पष्ट वर्णन लगता है।

@JeffreySarnoff यह मतलब मुश्किल है const करने के लिए एक बात आप एक संदर्भ प्राप्त कर सकते हैं (यानी सूचक) को सत्ता। जूलिया के "साझाकरण" शब्दार्थ का अर्थ है कि संकलक के लिए कुछ भी जो सही मायने में अपरिवर्तनीय साबित नहीं हो सकता है। जब आप इस तरह के संदर्भ को const type ( immutable ) के क्षेत्र में बाँधते हैं, तो इस बात का कोई प्रमाण नहीं है कि यह संदर्भ कहीं और मौजूद नहीं है और इसलिए कोई सबूत नहीं है कि जिस डेटा को संदर्भित किया गया है वह स्थिर है।

मुझे लगता है कि इस व्यवहार को बदलना जूलिया भाषा के लिए वास्तव में मौलिक परिवर्तन होगा।

@ कैंडीफरिस उस स्पष्ट उत्तर के लिए धन्यवाद।

क्या const या constant बजाय fixed का उपयोग न करने का कोई कारण है? मेरे लिए कम से कम, बहुत स्पष्ट वर्णन लगता है।

मैं सोच रहा था कि क्या const या constant जो दर्शाता है कि यह बाध्यकारी है जो स्थायी है, और नहीं (आवश्यक) कि बाध्य ऑब्जेक्ट के अंदर डेटा अपरिवर्तनीय होना चाहिए। fixed उस ओर जाता है, लेकिन मैंने अन्य भाषाओं में नहीं देखा है (तब फिर से, मैंने जूलिया को अन्य भाषाओं में बाध्यकारी / साझा अर्थ भी नहीं देखा है)।

शायद bind (जैसे bind x = 2 ) कुछ ... थिसॉरस glue सुझाव देता है ... यह बहुत सट्टा हो रहा है ...

const को कुछ अधिक सटीक के साथ बदलने का विचार मोहक है। हालाँकि, हम चाहते हैं कि यह समझदारी से एक प्रकार की घोषणा और एक व्यक्तिगत चर असाइनमेंट दोनों पर लागू हो। fixed struct कुछ समझ में आता है, लेकिन यह संरचना के क्षेत्र हैं जो कि प्रकार की घोषणा के बजाय तय किए गए हैं। दुर्भाग्य से bound struct ( tied struct ?) बजाय अस्पष्ट लगता है। किसी कारण से, const एक प्रकार से लागू होने पर मुझे स्पष्ट लगता है।

हम इसे एक प्रकार की घोषणा और एक व्यक्तिगत चर असाइनमेंट दोनों पर समझदारी से लागू करना चाहते हैं।

मुझे लगता है कि यह उद्देश्य के लिए उत्पादक होगा

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

समझ में आता है। type , struct सामने एक शॉर्टकट होने या जो कुछ भी एक शॉर्टकट होगा जिसका अर्थ है उपरोक्त।

यह इसे एक मैक्रो बनाने के लिए समझ सकता है, जैसे अन्य महत्वपूर्ण सजावट जो किसी चीज़ के चरित्र को बदलते हैं, जैसे @generated । यह अभी तक एक और कीवर्ड हटा देगा ...

+1 type -> composite , हालांकि वास्तव में type से कोई भी परिवर्तन बहुत अच्छा लगता है।

काश मैं थ्रेड पर एक नई टिप्पणी जोड़ने के लिए बिना GitHub मुद्दों पर वोट कर सकता ... मेरा वोट mutable और immutable , यह बहुत साफ और स्वच्छ है। struct का उपयोग नहीं किया गया है और यह उत्परिवर्तन भाग पर जोर नहीं देता है।

पुनश्च: क्या कोई जानता है कि GitHub में योगदान दे सकता है या एक वोटिंग सुविधा जोड़ सकता है? मैंने उनसे "हमसे संपर्क करें" पेज में पूछा, लेकिन मेरा ईमेल शायद खो गया था।

हाल ही में कई अन्य भाषाओं में एक पृष्ठभूमि के साथ जूलिया पर स्विच करने के बाद, मैंने नहीं देखा कि जूलिया सी-स्टाइल नामकरण को गोद ले और सी / सी ++ के सभी भ्रामक कॉन्स्टेंट-नेस मुद्दों में खींच ले। इसके बजाय, एक डेटा प्रकार की घोषणा को एक धारणा देने से जो किसी तरह मूल्य मान या एक साझा संदर्भ प्रकार होने के इरादे को दर्शाता है, जिसने मुझे केवल उत्परिवर्तन का संदर्भ देने के बजाय, काफी मदद की होगी।

जूलिया में मेरी प्रारंभिक उम्मीद एक साधारण सी type एक अपरिवर्तनीय सी-शैली struct या पायथन ऑब्जेक्ट के समान व्यवहार करने की रही होगी, क्योंकि जूलिया एक कार्यात्मक प्रोग्रामिंग शैली और गति के बारे में बहुत कुछ प्रतीत होता है।
मैं अभी भी type ... और immutable... शब्दों में असममितता से भ्रमित हो रहा हूं, लेकिन DataType से typeof(SomeType) कर रहा हूं, या 'बिटमैप' का वास्तविक अर्थ ', और एक सरल Alias = DataType विवरण के बजाय typealias कीवर्ड के लिए आवश्यकता।

इस प्रकार, मैं datatype वोट दूंगा, जो typeof(SomeType) == DataType अनुरूप होगा, और ::Type{} साथ चिड़चिड़ापन समानता को तोड़ देगा। composite [datatype] साथ परस्पर प्रकार को सजाने से मौलिक 'बिटस्टाइप्स' की तुलना में इसकी विशेष और संभवतः अधिक महंगी प्रकृति को उजागर किया जा सकता है।

C / C ++ के सभी भ्रमित कॉन्सेप्ट-नेस मुद्दों में खींच

इस कीवर्ड का कोई भी नामकरण ऐसा नहीं करेगा। उन मुद्दों को स्टेटिक चेकिंग और कास्ट्स के साथ करना है, जो यहां बिल्कुल भी शामिल नहीं हैं।

एक मूल्य प्रकार या एक साझा संदर्भ प्रकार होने के इरादे से मुझे काफी मदद मिली होगी, बजाय केवल उत्परिवर्तन को संदर्भित करने के

मैं इसे पूरी तरह से नहीं समझता। यदि कोई वस्तु अपरिवर्तनीय है, तो यह बताने का कोई तरीका नहीं है कि क्या यह मान या संदर्भ द्वारा पारित किया गया है, इसलिए मूल्य / संदर्भ भेद मौलिक कैसे हो सकता है?

datatype एक बुरा विकल्प नहीं है। लेकिन मुझे नहीं लगता है कि datatype बनाम composite datatype का एक अच्छा तरीका है कि आपस में सामंजस्य बिगाड़ सकें।

@JeffBezanson , C-like const-ness के साथ मेरा मतलब है कि जूलिया प्रकार की संभवतः निहित अपेक्षा है कि C / C ++ में समान व्यवहार हो: केवल निर्माण के बाद अपरिवर्तनीय, वैसे भी कास्टिंग के माध्यम से परिवर्तनीय, कभी-कभी फ़ंक्शन तर्कों के लिए सभी पर प्रभाव के बिना। वापसी के प्रकार। इस प्रकार, जब कीवर्ड चुनना शायद C / C ++ को संदर्भित नहीं करता है, तो यह एक अच्छा विकल्प है, इसलिए कृपया const struct ।

'मूल्य बनाम संदर्भ' के बारे में: मुझे यह समझने में काफी समय लगा कि एक अपरिवर्तनीय प्रकार सदस्यों को सीधे क्यों एम्बेड करता है और अच्छा और कॉम्पैक्ट फास्ट असेंबलर कोड तैयार करता है, लेकिन 'टाइप' नहीं था और अभी भी ऑब्जेक्ट में सभी कॉल शामिल हैं। या दूसरे शब्दों में, क्यों मैं आमतौर पर गति के लिए लक्ष्य करते समय एक NTuple का उपयोग करना चाहता हूं। इस प्रकार, 'अपरिवर्तनीय' और 'उत्परिवर्तित' पढ़ते हुए, मैंने फोरट्रान में 'पैरामीटर' के रूप में अर्थ की अपेक्षा की होगी, लेकिन वास्तविक डेटाटाइप के लेआउट या तरह के कार्यान्वयन में परिवर्तन भी नहीं।
संभवतः, अधिकांश समय कॉम्प्लेक्स जैसे छोटे मिश्रित प्रकारों के लिए 'अपरिवर्तनीय मूल्य' शब्दार्थ रखना चाहते हैं, लेकिन बड़े डेटा सेट जैसे सरणियों आदि के लिए 'परस्पर और संदर्भित / गैर-कॉपी करना'।
फिर, अंतर्निहित आशय शायद परिवर्तनशीलता नहीं है, लेकिन चारों ओर डेटा की प्रतिलिपि बनाने से बचना चाहिए।

हालाँकि, जूलिया लो-लेवल मशीनरी को फास्ट असेंबलर कोड प्राप्त करने के लिए सीखने के दौरान यह मेरा अनुभव था, लेकिन मुझे नहीं पता है कि बेहतर तरीके से यह दर्शाया जा सकता है कि नामकरण कीवर्ड में और कैसे परस्पर संयोजन के साथ या इसे व्यक्त करें।

मुझे लगता है कि आप जहाँ से @mjw आ रहे हैं, मैं वहाँ गया हूँ, लेकिन मुझे लगता है कि आप C / C ++ के बारे में जो कुछ भी जानते हैं, उसे अनलिमिटेड करना बेहतर है। यहां, यह const है जो अपरिवर्तनीय है और क्या कुछ स्टैक या डायनामिक रूप से आवंटित किया गया है, और क्या यह संदर्भ या मूल्य द्वारा पारित किया गया है, भिन्न होने के लिए स्वतंत्र हैं और कंपाइलर के लिए अनुकूलन विकल्प होंगे। आप एक ऐसी भाषा बना सकते हैं जहां सब कुछ गतिशील रूप से आवंटित किया गया है और संदर्भ द्वारा पारित किया गया है, और यह जूलिया का डिफ़ॉल्ट तरीका है (बॉक्सिंग मानों के लिए - यह अज्ञात होने पर भी "साझा करके पास" लागू करता है)। आप (हम और बाकी लोग) ध्यान देते हैं कि छोटे अपरिवर्तनीय इसलिए बहुत तेजी से होते हैं क्योंकि यही वह स्थान है जहां वर्तमान में अनुकूलन लागू होते हैं। यह immutable अनुकूलन के शब्दार्थों को आसान बनाने का परिणाम है।

लेकिन, वास्तव में, मैं पसंद करूंगा कि बड़े इम्यूटेबल्स को संदर्भ द्वारा पारित किया गया था (शायद स्टैक पॉइंटर्स द्वारा, जहां यह समझ में आता है, लेकिन संभवतः NTuple{1_000_000} आवंटित करना सबसे अच्छा है) और ज्ञात आकार के छोटे म्यूटेंट स्टैक आवंटित किए गए हैं (फिर से, जहां संभव हो)। यहां तक ​​कि कचरा संग्रह को कुछ मामलों में सांख्यिकीय रूप से निर्धारित किया जा सकता है, जिससे ढेर-स्थान को उदाहरण के लिए छोरों के अंदर पुन: उपयोग किया जा सकता है। मैं भविष्य के अनुकूलन के अवसरों के रूप में इन चित्रों का उपयोग करता हूं जिनके लिए भागने के विश्लेषण की आवश्यकता होती है (और इनमें से कोई भी भाषा के शब्दार्थ को प्रभावित नहीं करता है, बस प्रदर्शन)।

मुझे लगता है कि मैं जो कह रहा हूं वह यह है कि कीवर्ड को शब्दार्थ को प्रतिबिंबित करने की आवश्यकता है जो एक या दो दशक तक स्थिर रहेगा, कार्यान्वयन विवरण नहीं जो कुछ वर्षों में बदल जाएंगे (अर्थात कुशल छोटे म्यूटेबल्स और कुशल बड़े इम्यूटेबल्स)।

मेरा मतलब था कि जूलिया प्रकार के संभवतः समान व्यवहार की अपेक्षा C / C ++ में है

यह ईमानदार होने के लिए const -> constant पर विचार करने के लिए अपने आप में एक अच्छा पर्याप्त कारण हो सकता है। मुझे लगता है कि इस समय const हमारा एकमात्र संक्षिप्त कीवर्ड हो सकता है, जो इसे वैसे भी एक विषम बनाता है।

एक सरल Alias = DataType बयान।

मुझे पूरा यकीन है कि यह बिल्कुल ठीक है जहां यह समझ में आता है, लेकिन यह प्रकार के अधिक जटिल संशोधनों की अनुमति नहीं देगा, जैसे typealias RealMatrix{T<:Real} Matrix{T} , और न ही यह (यह एक सरल बंधन है, एक नया Type नहीं बनाना चाहिए TypeVar s के साथ)। जब तक आप इसे दूसरे तरीके से परिभाषित नहीं करना चाहते हैं: RealMatrix = Matrix{T <: Real} और सामान्य करें कि apply TypeVar लिए क्या करता है (यानी TypeConstructor बनाता है) ... वास्तव में यह एक दिलचस्प विचार है (लेकिन इसमें वाक्यविन्यास मुद्दे हैं, यही वजह है कि typealias अच्छा है ...)।

@ कैंडीफेरिस , मैं पहले से ही 'अनजान' हूं, लेकिन अन्य नए उपयोगकर्ताओं के लिए 'क्यों जूलिया संकलन के बावजूद इतनी धीमी है' पर

@mjw ग्रेट, और मैं उन सभी से सहमत हूं। :)

आपको बताते हैं कि, हम सबसे अच्छी GitHub कार्यक्षमता का उपयोग करके एक निकटतम चीज़ की कोशिश कर सकते हैं: प्रतिक्रिया emojis।

यहाँ मैंने सारणीबद्ध किया है, _ कोई विशेष क्रम_ नहीं है, जो सुझाव सबसे अधिक समर्थन के लिए दिखाई देते हैं। उस सुझाव के लिए अपना वोट डालने के लिए निर्दिष्ट इमोजी का उपयोग करके प्रतिक्रिया करें। मेरा मानना ​​है कि यह एक डेस्कटॉप ब्राउज़र के माध्यम से GitHub तक पहुँचने की आवश्यकता है; AFAIK प्रतिक्रिया emojis मोबाइल इंटरफ़ेस में लागू नहीं किया गया है। इस पोस्ट के ऊपरी दाएं कोने में चेहरा क्लिक करें इमोजीज़ के मेनू तक पहुंचने के लिए।

| type | immutable | के साथ प्रतिक्रिया |
| : -: | : -: | : -: |
| struct | const struct | | (+1) |
| mutable | immutable | | (-1) |
| type | immutable | ) (हंसते हुए) |
| composite | const composite | : टाडा: (हुर्रे) |
| datatype | const datatype | ) (उलझन में) |
| type | const type | | (दिल) |

वोट करने में विफलता nuple लिए एक निहित वोट से मेल खाती है, ज़ाहिर है। :ट्रॉल फ़ेस:

मुझे कहना है, मैं इस "लोकतांत्रिक" जैसे विवादास्पद फैसले करने का बहुत बड़ा प्रशंसक नहीं हूं। अगर चर्चा बिना किसी सहमति के हुई है, तो मैं सिर्फ बीडीएफएल के फैसले को टाल दूंगा।

फेयर पॉइंट, @TotalVerb। जैसा कि मैंने पहले कहा था, मैं पूरी तरह से ठीक होने वाली शक्तियां होंगी, जो हमें सबसे अच्छा लगता है। ऐसा लगता है जैसे धागा थोडा कम हो रहा है और वोटिंग के बारे में @juliohm की बात उचित प्रतीत होती है, इसलिए मुझे लगा कि मैं इस बात का ध्यान

व्यक्तिगत रूप से, मुझे नहीं लगता कि मुझे दो शब्द सौंदर्यशास्त्रीय रूप से पसंद हैं ( const type )। यह थोड़ा शब्दार्थ भी लगता है। जब हम const x = 1 । हमारा मतलब है कि x स्थिर है। जब हम कहते हैं कि const type; x; end का अर्थ होगा कि निर्माण के बाद इस प्रकार के परिवर्तन नहीं होते हैं। सीधे प्रक्षेप से ऐसा लगता है कि कुछ कहना एक निरंतर प्रकार का अर्थ है कि प्रकार स्वयं नहीं बदलता है (जो पहले से ही अब है)। यह सभी देखें:

type foo
end
const bar = foo

तो bar है और यह हमेशा foo है, लेकिन फिर भी यह const type । ऐसा लगता है कि const (बाइंडिंग पर लागू) के मौजूदा शब्दार्थों के लिए wrt, प्रकारों के नाम पहले से ही कास्ट हैं।

मुझे संदेह है कि कोई भी कीवर्ड नहीं हैं जो संक्षिप्त हैं, इच्छित शब्दार्थों को व्यक्त करते हैं, और चर नामों के रूप में वांछनीय होने की संभावना नहीं है। मुझे लगता है कि शब्दावली इन लक्ष्यों के सबसे करीब है mutable datatype , immutable datatype , और abstract datatype तीन प्रकार के घोषित प्रकारों के लिए।

मैं type और immutable अलावा एक अतिरिक्त परिवर्तनशील मूल्य प्रकार था।
मैंने मुद्दों पर कुछ चर्चाएँ देखी हैं, लेकिन मूल रूप से इस समय इस तरह से कुशलता से परिदृश्यों को संभालना असंभव है (अगर मुझे कुछ करना है तो मुझे सही करें):

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  

कोड मूल्य प्रकार sizeof(T) * 10 एक साफ सरणी बनाता है, लेकिन कुछ फ़ील्ड को बदलने के लिए पूरे T(...) को पुन: असाइन करने की आवश्यकता होती है, जो आमतौर पर 3-5 फ़ील्ड लंबी होती है।
तो मूल रूप से मेरे 5 सेंट:
type - GC ने संदर्भ एकत्र किया
immutable - मूल्य (स्टैक आवंटित) प्रकार जो बदलना असंभव है
mutable - मूल्य प्रकार जो बदलना संभव है, खासकर सरणियों में

मूल्य प्रकार जो बदलना संभव है

मुझे लगता है कि यह एक असंभव-सा लक्ष्य है क्योंकि बदलावों की अनुमति देना ठीक है जो किसी वस्तु को पहचान देता है।

शायद आप इसके बजाय इस दृष्टिकोण को पसंद करेंगे: # 11902

उत्परिवर्तनों और अपरिवर्तनों को अलग करने के अलावा, यह बेहतर होना चाहिए अगर हम मूल्यों और संदर्भों को विभाजित करते हैं ।

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

मूल्यों और संदर्भों के बीच एक कृत्रिम अंतर के साथ भाषा को ओवरक्लंप करने की आवश्यकता नहीं है। उत्परिवर्तनीय और अपरिवर्तनीय प्रकार शब्दार्थ बहुत सरल होते हैं; तथ्य यह है कि एक प्रकार एक मूल्य प्रकार केवल एक अनुकूलन है।

@ केनो एक अच्छी बात करता है

व्यक्तिगत रूप से, मुझे नहीं लगता कि मुझे दो शब्द सौंदर्यशास्त्रीय रूप से पसंद हैं (कास्ट टाइप)। यह थोड़ा शब्दार्थ भी लगता है। जब हम const x = 1. कहते हैं तो हमारा मतलब है कि x स्थिर है। जब हम कहते हैं कि कांस्ट प्रकार; एक्स; अंत हमारा मतलब है कि निर्माण के बाद इस प्रकार के परिवर्तन नहीं होते हैं। सीधे प्रक्षेप से ऐसा महसूस होता है कि कुछ कहना एक निरंतर प्रकार का अर्थ है कि प्रकार स्वयं नहीं बदलता (जो पहले से ही अब है)

जैसा कि मैंने पहले उल्लेख किया है, मुझे लगता है कि "सही" शब्दार्थ द्वारा दिया गया है

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

यहाँ z.re व्यवहार तब ही होता है जब हम const z.re = 1 कुछ टाइप करते हैं, इसलिए कोई अर्थपूर्ण भ्रम नहीं है कि वास्तव में कौन सा बंधन const ।

जैसा कि @JeffBezanson बताता है, यह वास्तव में बड़ी संख्या में क्षेत्रों के लिए सुविधाजनक नहीं है, और वर्तमान प्रकार के कार्यान्वयन के साथ संगत नहीं है। आंशिक रूप से परिवर्तनशील, आंशिक रूप से निरंतर संरचना भविष्य में लागू हो भी सकती है और नहीं भी। हालांकि, वहाँ एक वाक्य रचना जो समझ में आता है दोनों वर्तमान और भविष्य में है:

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

वर्तमान तरीका इसे लागू किया गया है, एक मैक्रो एएसटी में type से immutable में बदल सकता है। भविष्य में, यदि आंशिक रूप से स्थिर संरचना को लागू किया जाता है, तो मैक्रो अभी भी प्रत्येक क्षेत्र में const जोड़कर एएसटी को जोड़तोड़ कर सकता है, और यह सभी के लिए स्पष्ट हो जाएगा और यह स्पष्ट होगा कि यह क्षेत्र बाइंडिंग है जो निरंतर हैं। एस्थेटिक रूप से, यह एक पंक्ति में दो खोजशब्दों से बेहतर है - हम कार्यों के लिए समान काम करते हैं ( @generated , @inline , @proagate_inbounds , आदि)।

@const आसानी से @immutable या कुछ समान हो सकता है ( <strong i="31">@immutable</strong> type Val{T}; end ठीक पढ़ता है, IMO) और मैक्रो विचार struct , composite के साथ संगत है , और इसी तरह।

@ be5invis हाँ, यह कई भाषाओं में एक सामान्य तरीका है, उदाहरण के लिए C # में struct , जो कई तरह से immutable रूप में व्यवहार करता है: यह कार्यों के लिए कॉपी द्वारा पारित किया जाता है, स्पष्ट रूप से आवंटित किया जाता है arrays ( class | type के मामले में GC- प्रबंधित वस्तुओं के संदर्भ में नहीं)। हालाँकि यह _mutable_ है, और सरणियों में किसी एक क्षेत्र द्वारा संशोधित किया जा सकता है।
मुझे क्या लगता है कि immutable के मामले में 2 गुणों का मिश्रण है:

1. अपरिवर्तनीयता (उचित कार्यात्मक प्रोग्रामिंग करने के लिए)
2. निचले स्तर पर मूल्य प्रकार के रूप में व्यवहार करना

इसलिए मूल रूप से मैं केवल संपत्ति 2 के साथ एक प्रकार का परिचय देखना पसंद करूंगा। यह मौजूदा कोडबेस ( immutable अवशेष) को बाधित नहीं करेगा, लेकिन जो लोग न्यूनतम जीसी भागीदारी के साथ कुछ तेजी से लिखते हैं उनके लिए यह मूल्यवान होगा ।

@johnmyleswhite # आपका धन्यवाद, फिर भी विश्वास है कि ऐसा नहीं होना चाहिए

@wgreenr जैसा कि पहले उल्लेख किया गया है, और कई बार चर्चा की गई है, यह संभव नहीं है। यह वास्तव में इस मुद्दे में चर्चा से संबंधित नहीं है।

कुछ भी संभव है लेकिन उत्परिवर्तनीय मूल्य प्रकारों को प्रस्तुत करना बेतहाशा विघटनकारी और बहुत बुरा विचार होगा। मैं समझ सकता हूं कि यह एक स्पष्ट रूप से सरल और आकर्षक विचार क्यों है, लेकिन एक नए, पूरी तरह से अलग तरह के ऑब्जेक्ट शब्दार्थ को जोड़ना और संदर्भ और मूल्य शब्दार्थ में टाइप ग्राफ को द्विभाजित करना भाषा को बेहतर बनाने वाला नहीं है। यह क्या हासिल करेगा यह सामान्य कोड को सुरक्षित रूप से लिखना असंभव बना रहा है क्योंकि एक ही कोड अज्ञात शब्दार्थ के आधार पर बहुत अलग चीजें करेगा। यहां उदाहरणों के साथ एक व्यापक चर्चा है । # ११ ९ ०२ की बात यह है कि बिना मलबे वाली चीजों के परस्पर मूल्य प्रकार के लाभों को प्राप्त करना।

मुझे यकीन नहीं है अगर यह भी ध्यान देने योग्य है; लेकिन C / C ++ 'संरचना' में डेटा के लेआउट के बारे में भी कुछ बताया गया है। दूसरी ओर, बेहतर मेमोरी लेआउट प्राप्त करने के लिए अक्सर संरचना सदस्यों को फिर से व्यवस्थित करना सार्थक है। यदि आप वाक्य-रचना में परिवर्तन को विचार कर रहे हैं, तो क्या किसी 'मैकेनिज्म' (ऑर्डर किया गया -> सी इंटरोप) और 'अपरिवर्तनीय (किसी भी तरह से आदेश दिया जा सकता है) के बीच अंतर करने के लिए एक तंत्र होना सार्थक हो सकता है।

मैं जूलिया के लिए काफी नया हूं, इसलिए मुझे खेद है अगर मैं कुछ स्पष्ट याद कर रहा हूं।

मेरे पास व्यक्तिगत रूप से कोई वास्तविक वरीयता नाम नहीं है; हालाँकि, मुझे आश्चर्य है कि किसी को भी "ठोस" का सुझाव नहीं दिया गया था, यह देखते हुए कि पहले से ही "अमूर्त" मौजूद है।

अभी तक एक और सुझाव जोड़ने के लिए, निम्नलिखित मुझे सबसे अच्छा लगता है:

• का प्रयोग करें struct के बजाय immutable ।

• struct! बजाय type । अंग्रेजी बोलते समय, इसे "म्यूटेबल स्ट्रक्चर" के रूप में जाना जाना चाहिए।

  • (शायद) एक के अंदर से कुछ फ़ील्ड होने की अनुमति देते हैं struct! के रूप में चिह्नित किया जाना है const ।

कुछ औचित्य और विचार:

1) जब तक मैं कुछ स्पष्ट याद नहीं करता, आप एक अपरिवर्तनीय प्रकार के मूल्य में हेरफेर करने के लिए ! साथ एक फ़ंक्शन का उपयोग कभी नहीं करना चाहते हैं। यदि वह गलत है (जैसे कि अगर कोई महत्वपूर्ण मामला है जहां अपरिवर्तनीय प्रकार एक परस्पर एक को संदर्भित करता है, और ! साथ फ़ंक्शन इसे बदलता है), तो यह सुझाव एक अच्छा नहीं हो सकता है।

2) मुझे लगता है कि अपरिवर्तनीय प्रकारों को आम तौर पर पारस्परिक रूप से अधिक पसंद किया जाना चाहिए, क्योंकि वे अधिक अनुकूलन के अधीन होते हैं और प्रोग्रामर के लिए अधिक पूर्वानुमानित व्यवहार होता है।

3) काम करने के लिए, लगभग सभी मामलों में अपरिवर्तनीय प्रकारों के रूप में कम से कम कुशल बनाने के लिए अनुकूलन को लागू करना शायद एक शर्त है। विशेष रूप से, संकलक को संदर्भ द्वारा बड़े अपरिवर्तनीय प्रकारों को पारित करने के बारे में स्मार्ट होना चाहिए।

अद्यतन : मैं record बजाय struct , लेकिन record! एक क्रिया की तरह बहुत अधिक है। कुछ अन्य विकल्प जो दिमाग में आते हैं: newtype , typedef (जो कि 10 सेकंड के लिए C प्रोग्रामर्स को भ्रमित करेगा), composite , या concrete किसी के ऊपर के रूप में सुझाए गए ।

क्या यह संभावना है कि v0.6 फीचर फ्रीज होने से पहले इस जगह में कुछ होगा?

शायद नहीं, यह देखते हुए कि कोई निर्णय नहीं किया गया है (कम से कम सार्वजनिक रूप से) और हम फ्रीज से सिर्फ 10 दिन दूर हैं।

मैंने ध्यान से इसका पालन नहीं किया है, लेकिन एक टिप्पणी यह ​​है कि यदि / जब यह बदलता है, तो मैं अनुरोध करना चाहता हूं कि हमारे पास पहली बार अपमानजनक फ़ाइल / लाइन नंबर की अच्छी रिपोर्टिंग है। या कम से कम मॉड्यूल; 0.5 में यह अभी भी कभी-कभी यह पता लगाना मुश्किल होता है कि किस पैकेज में @deprecate d _binding ।

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