क्या हास्केल का प्रकार प्रणाली औपचारिक रूप से जावा के बराबर है? [बन्द है]


66

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


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

1
यह एक महान सवाल है - महान हास्केल / जेवीएम बहस के लिए अनुयायियों को इसे ट्वीट करने का समय!
मार्टिब्न वेरबर्ग

6
@ m3th0dman: स्केल के पास उच्च-क्रम के कार्यों के लिए सटीक समर्थन है जैसा कि जावा के पास है। स्काला में, प्रथम श्रेणी के कार्यों को केवल जावा की तरह, एक ही सार पद्धति के साथ अमूर्त वर्गों के उदाहरण के रूप में दर्शाया गया है। निश्चित रूप से, स्काला के पास इन कार्यों को परिभाषित करने के लिए वाक्य रचना चीनी है, और इसमें पूर्व-परिभाषित फ़ंक्शन प्रकार और विधियों के एक समृद्ध मानक पुस्तकालय हैं जो फ़ंक्शन को स्वीकार करते हैं, लेकिन एक प्रकार के सिस्टम के नजरिए से , जो कि यह सवाल है, इसमें कोई अंतर नहीं है । तो, अगर स्काला यह कर सकता है, तो जावा भी कर सकता है, और वास्तव में जावा के लिए हास्केल से प्रेरित एफपी लाइब्रेरी हैं।
जोर्ग डब्ल्यू मित्तग

2
@ m3th0dman: यह ऐसा सवाल नहीं है।
फिल

7
@ m3th0dman वे पूरी तरह से सामान्य प्रकार हैं। कुछ पर्यायवाची उपनामों को छोड़कर सूचियों के बारे में कुछ खास नहीं है। आप आसानी से अपने स्वयं के बीजीय डेटा प्रकार को परिभाषित कर सकते हैं जो कि अंतर्निहित सूची प्रकार के बराबर है सिवाय शाब्दिक सिंटैक्स और कंस्ट्रक्टर्स के नाम के।
sepp2k

जवाबों:


63

("जावा", जैसा कि यहां उपयोग किया गया है, मानक जावा एसई 7 के रूप में परिभाषित किया गया है ; "हास्केल", जैसा कि यहां इस्तेमाल किया गया है, इसे मानक हास्केल 2010 के रूप में परिभाषित किया गया है ।)

चीजें हैं जो जावा के प्रकार की प्रणाली है, लेकिन हास्केल की नहीं है:

  • नाममात्र उपप्रकार बहुरूपता
  • आंशिक रनटाइम प्रकार की जानकारी

हास्केल के प्रकार की चीजें जो कि है, लेकिन वह जावा की नहीं है:

  • बंधे हुए तदर्थ बहुरूपता
    • "बाधा-आधारित" उपप्रकार बहुरूपता को जन्म देता है
  • उच्च-दयालु पैरामीट्रिक बहुरूपता
  • प्रिंसिपल टाइपिंग

संपादित करें:

ऊपर सूचीबद्ध प्रत्येक बिंदु के उदाहरण:

जावा के लिए अद्वितीय (हास्केल की तुलना में)

नाममात्र उपप्रकार बहुरूपता

/* declare explicit subtypes (limited multiple inheritance is allowed) */
abstract class MyList extends AbstractList<String> implements RandomAccess {

    /* specify a type's additional initialization requirements */
    public MyList(elem1: String) {
        super() /* explicit call to a supertype's implementation */
        this.add(elem1) /* might be overridden in a subtype of this type */
    }

}

/* use a type as one of its supertypes (implicit upcasting) */
List<String> l = new ArrayList<>() /* some inference is available for generics */

आंशिक क्रम प्रकार की जानकारी

/* find the outermost actual type of a value at runtime */
Class<?> c = l.getClass // will be 'java.util.ArrayList'

/* query the relationship between runtime and compile-time types */
Boolean b = l instanceOf MyList // will be 'false'

हास्केल के लिए अद्वितीय (जावा की तुलना में)

बंधे हुए तदर्थ बहुरूपता

-- declare a parametrized bound
class A t where
  -- provide a function via this bound
  tInt :: t Int
  -- require other bounds within the functions provided by this bound
  mtInt :: Monad m => m (t Int)
  mtInt = return tInt -- define bound-provided functions via other bound-provided functions

-- fullfill a bound
instance A Maybe where
  tInt = Just 5
  mtInt = return Nothing -- override defaults

-- require exactly the bounds you need (ideally)
tString :: (Functor t, A t) => t String
tString = fmap show tInt -- use bounds that are implied by a concrete type (e.g., "Show Int")

"बाधा-आधारित" उप-प्रकार बहुरूपता (बंधे हुए तदर्थ बहुरूपता पर आधारित)

-- declare that a bound implies other bounds (introduce a subbound)
class (A t, Applicative t) => B t where -- bounds don't have to provide functions

-- use multiple bounds (intersection types in the context, union types in the full type)
mtString :: (Monad m, B t) => m (t String)
mtString = return mtInt -- use a bound that is implied by another bound (implicit upcasting)

optString :: Maybe String
optString = join mtString -- full types are contravariant in their contexts

उच्चतर प्रकार के पैरामीट्रिक बहुरूपता

-- parametrize types over type variables that are themselves parametrized
data OneOrTwoTs t x = OneVariableT (t x) | TwoFixedTs (t Int) (t String)

-- bounds can be higher-kinded, too
class MonadStrip s where
  -- use arbitrarily nested higher-kinded type variables
  strip :: (Monad m, MonadTrans t) => s t m a -> t m a -> m a

प्रिंसिपल टाइपिंग

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


7
lएकल पत्र चर के रूप में उपयोग न करें , यह भेद करना बहुत मुश्किल है 1!
recursion.ninja

5
यह ध्यान देने योग्य हो सकता है, जबकि आप बिल्कुल सही कह रहे हैं कि जावा में कुछ रनटाइम प्रकार की जानकारी है और हास्केल नहीं है, तो आप कुछ उपलब्ध कराने के लिए हास्केल में टाइप करने योग्य टाइप-क्लास का उपयोग कर सकते हैं, जो कई प्रकारों के लिए रनटाइम प्रकार की जानकारी का व्यवहार करता है (नए PolyKinded के साथ) रास्ते में कक्षाएं, यह सभी प्रकार के iirc होगा), हालांकि मुझे लगता है कि यह उस स्थिति पर निर्भर करता है कि क्या यह वास्तव में रनटाइम पर किसी भी प्रकार की जानकारी पारित करता है या नहीं।

3
@DarkOtter से मैं अवगत हूं Typeable, लेकिन हास्केल 2010 में यह नहीं है (शायद हास्केल 2014 होगा?)।
पथरियन की लौ

5
क्या (बंद) योग प्रकारों के बारे में? वे एन्कोडिंग बाधाओं के लिए अधिक महत्वपूर्ण तंत्रों में से एक हैं।
टिब्बी

3
Nullability? साउंडनेस (कोई सहसंयोजक sillinses)? बंद राशि प्रकार / पैटर्न मैच? यह उत्तर रास्ता बहुत संकीर्ण है
पीकर

32

जावा के प्रकार प्रणाली में उच्च किस्म के बहुरूपता का अभाव है; हास्केल के प्रकार प्रणाली में यह है।

दूसरे शब्दों में: जावा में, टाइप कंस्ट्रक्टर प्रकारों पर अमूर्त कर सकते हैं, लेकिन टाइप कंस्ट्रक्टर्स पर नहीं, जबकि हास्केल में, टाइप कंस्ट्रक्टर टाइप कंस्ट्रक्टर्स के साथ-साथ टाइप पर भी अमूर्त कर सकते हैं।

अंग्रेजी में: जावा में एक जेनेरिक दूसरे जेनेरिक प्रकार में नहीं ले जा सकता है और इसे मानकीकृत कर सकता है,

public void <Foo> nonsense(Foo<Integer> i, Foo<String> j)

हास्केल में यह काफी आसान है

higherKinded :: Functor f => f Int -> f String
higherKinded = fmap show

28
दिमाग चल रहा है कि हमारे द्वारा, इस बार अंग्रेजी में? : पी
मेसन व्हीलर

8
@ मैट: एक उदाहरण के रूप में मैं इसे जावा में नहीं लिख सकता, लेकिन मैं हास्केल में बराबर लिख सकता हूं <T<_> extends Collection> T<Integer> convertStringsToInts(T<string> strings):। यहां विचार यह होगा कि अगर कोई इसे convertStringsToInts<ArrayList>बुलाएगा तो यह स्ट्रिंग्स की एक सरणी ले जाएगा और पूर्णांक की एक सरणी सूची लौटाएगा। और अगर वे इसके बजाय उपयोग करते हैं convertStringsToInts<LinkedList>, तो इसके बजाय लिंक्ड सूची के साथ भी ऐसा ही होगा।
sepp2k

8
क्या यह रैंक 1 बनाम n के बजाय उच्च-प्रकार का बहुरूपता नहीं है?
एडम

8
@ JörgWMittag: मेरी समझ यह है कि उच्च-श्रेणी के बहुरूपता की चिंता जहाँ आप forallअपने प्रकारों में रख सकते हैं। हास्केल में, एक प्रकार a -> bअंतर्निहित है forall a. forall b. a -> b। एक एक्सटेंशन के साथ, आप इन forallएस को स्पष्ट कर सकते हैं और उन्हें इधर-उधर कर सकते हैं ।
तिखन जेल्विस

8
@ एडडम कठोर है: उच्च रैंक और उच्च तरह पूरी तरह से अलग हैं। जीएचसी कुछ भाषा विस्तार के साथ उच्च रैंक वाले प्रकार (यानी छोटे प्रकार) भी कर सकता है। जावा न तो उच्च प्रकार और न ही उच्च रैंक वाले प्रकारों को जानता है।
इंगो

11

अन्य उत्तरों के पूरक के लिए, हास्केल के प्रकार की प्रणाली में उप-योग नहीं है , जबकि जावा के रूप में ऑब्जेक्ट ओरिएंटेड भाषाओं को टाइप किया गया है।

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

उप-संबंध के कारण, एक शब्द एक से अधिक प्रकार का हो सकता है। इसलिए सबटाइपिंग एक प्रकार का बहुरूपता है। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में 'पॉलीमॉर्फिज्म' शब्द का उपयोग आमतौर पर इस उप-प्रकार के पॉलीमॉर्फिज्म को संदर्भित करने के लिए किया जाता है , जबकि पैरामीट्रिक पॉलीमॉर्फिज्म की तकनीकों को जेनेरिक प्रोग्रामिंग माना जाएगा ...


4
हालांकि इसका मतलब यह नहीं है कि आपको तदर्थ बहुरूपता नहीं मिलती है। आप करते हैं, बस एक अलग रूप में (उपप्रकार बहुरूपता के बजाय टाइप कक्षाएं)।

3
उपवर्ग में उप-योग नहीं है!
फ्रैंक शीयर

8

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

एक और बात लोगों को अभी तक बीजीय डेटा प्रकार का उल्लेख नहीं किया है लगता है। अर्थात्, प्रकार ('या') और अन्य प्रकार के उत्पादों ('और') से प्रकारों के निर्माण की क्षमता। जावा वर्ग उत्पाद (फ़ील्ड ए और फ़ील्ड बी, कहते हैं) ठीक करते हैं। लेकिन वे वास्तव में रकम नहीं देते हैं (फ़ील्ड को OR फ़ील्ड b, कहते हैं)। स्काला को इसे कई केस क्लासेस के रूप में एनकोड करना है, जो कि समान नहीं है। और जब यह स्काला के लिए काम करता है, तो जावा के पास यह कहने के लिए थोड़ा खिंचाव होता है।

हास्केल फ़ंक्शन कंस्ट्रक्टर का उपयोग करके फ़ंक्शन प्रकारों का निर्माण भी कर सकता है, ->। जबकि जावा के तरीकों में हस्ताक्षर होते हैं, आप उन्हें जोड़ नहीं सकते।

जावा का प्रकार सिस्टम एक प्रकार की प्रतिरूपकता को सक्षम करता है जो हास्केल को नहीं मिला है। हास्केल के लिए OSGi होने से पहले यह कुछ समय होगा।


1
@MattFenwick, मैंने आपकी प्रतिक्रिया के आधार पर तीसरे पैराग्राफ को संशोधित किया है। दो प्रकार के सिस्टम बहुत अलग तरीके से कार्यों का इलाज करते हैं।
गारेथ

मैं ADTs को टाइप सिस्टम की सुविधा नहीं कहूंगा। आप पूरी तरह से (यदि अजीब तरह से) उन्हें OO रैपर के साथ अनुकरण कर सकते हैं।
12

@leftaroundabout मुझे लगता है कि यह यकीनन है। उदाहरण के लिए, ऐसी चीजें हो सकती हैं जो एक भाषा की एक प्रकार की प्रणाली के मूल निवासी हैं, लेकिन एक दूसरे में डिजाइन पैटर्न के साथ लागू की जा सकती हैं। जाहिर है, डिजाइन पैटर्न तरीका, मूल निवासी की तुलना में, एक वर्कअराउंड है। कमजोर प्रकार की प्रणाली के कारण वर्कअराउंड।
हाय-एंजेल

चुने गए उत्तर में 'प्रधानाचार्य टाइपिंग' अनुभाग में 'पूर्ण प्रकार का अनुमान' का उल्लेख किया गया है। जावा उप-प्रकारों और रनटाइम प्रकार की जानकारी के साथ अनुकरण योगों को सॉर्ट कर सकता है, लेकिन जैसा कि आप कहते हैं कि यह समान नहीं है क्योंकि योग टाइप सिस्टम का समग्र विशेषता नहीं है।
शेल्बी मूर III
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.