[সম্পাদনা করুন: প্রতিটি উপর কয়েকটি শব্দ Voilà]
এইচএম প্রকারের অনুক্রম বাড়ানোর বিভিন্ন উপায় রয়েছে। আমার উত্তর অনেকগুলি, কম বেশি সফল, তাদের কয়েকটি বাস্তবায়নের চেষ্টাের উপর ভিত্তি করে। আমি প্রথম যে হোঁচট খেয়েছি তা হ'ল প্যারামেট্রিক পলিমারফিজম । এই ধরণের এইচএম প্রসারিত করার চেষ্টা করছে এমন সিস্টেমগুলি সিস্টেম এফ এর দিকে ঝোঁক দেয় এবং তাই প্রকারের টীকাগুলির প্রয়োজন হয়। আমি যে দিক দিয়ে এসেছি সেদিকে দুটি উল্লেখযোগ্য এক্সটেনশন হ'ল:
এইচএমএফ, এটি সমস্ত সিস্টেম-এফ প্রকারের জন্য টাইপ অনুক্রমের অনুমতি দেয়, যার অর্থ আপনি কোনও প্রকারের "মাঝখানে" সার্বজনীন পরিমাণ নির্ধারণ করতে পারেন, তাদের উপস্থিতি সুস্পষ্টভাবে এইচএম পলিমারফিক ধরণের মতো উচ্চতর স্কোপে অবস্থিত নয়। কাগজে স্পষ্টভাবে বলা হয়েছে যে কতগুলি এবং কোথায় টাইপ টিকাশির প্রয়োজন হতে পারে সে সম্পর্কে কোনও স্পষ্ট বিধি বিদ্যমান নেই। এছাড়াও সিস্টেম এফ এর ধরণের ধরণের ক্ষেত্রে সাধারণত একটি প্রধান প্রকার থাকে না।
এমএলএফ কেবল এইচএম-র সম্প্রসারণই নয়, এটি সিস্টেম এফেরও একটি বর্ধন যা প্রকারভেদে একধরনের সীমাবদ্ধ পরিমার্জন প্রবর্তন করে এইচএমের মূল প্রকারের সম্পত্তি পুনরুদ্ধার করে। লেখকদের দ্বারা একটি তুলনা করা হয়েছে, এইচএমএফের তুলনায় এমএলএফ কঠোরভাবে আরও শক্তিশালী এবং টীকাগুলি কেবল পলিমার্ফিকভাবে ব্যবহৃত পরামিতিগুলির জন্য প্রয়োজন।
এইচএম প্রসারণের আরেকটি উপায় হ'ল সীমাবদ্ধ ডোমেনের পরিবর্তনের মাধ্যমে।
এইচএম (এক্স) হ্যান্ডলি-মিলনার একটি সীমাবদ্ধ ডোমেন এক্সকে কেন্দ্র করে প্যারামিটারাইজড approach শর্তাবলী সেট টাইপ এবং ধরণের ভেরিয়েবল থেকে তৈরি।
এক্স এর আরেকটি উদাহরণ হ'ল প্রেসবার্গার পাটিগণিতের ভাষায় বাধা প্রকাশ করা (যে ক্ষেত্রে প্রকারের অনুকরণ / চেকিং নির্ধারণযোগ্য) বা পানো পাথের গাণিতিকের ভাষায় (আর সিদ্ধান্ত নেওয়ার যোগ্য নয়) expressed এক্স তত্ত্বের বর্ণালী অনুসারে পরিবর্তিত হয়, প্রতিটি প্রকারের টীকাগুলির পরিমাণ এবং স্থানীয়করণ সম্পর্কিত প্রয়োজনীয়তা এবং সেগুলি একেবারেই নয়।
হ্যাস্কেলের ধরণের ক্লাসগুলিও ফর্মের পূর্বাভাস MyClass(MyType)(যেমন মাইটাইপ টাইপের জন্য মাইক্লাসের একটি উদাহরণ উপস্থিত রয়েছে) যোগ করে সীমাবদ্ধ ডোমেনের এক ধরণের প্রসার।
প্রকারের ক্লাসগুলি প্রকারের অনুকরণ সংরক্ষণ করে কারণ তারা মূলত একটি (প্রায়) অ र्थোগোনাল ধারণা যা তারা অ্যাডহক পলিমারফিজম প্রয়োগ করে ।
উদাহরণস্বরূপ, একটি প্রতীক নিতে valধরনের val :: MyClass a => aআপনি দৃষ্টান্ত থাকতে পারে, যার জন্য MyClass A, MyClass Bইত্যাদি যখন আপনি আপনার কোডে এই চিহ্নের পড়ুন, এটি একটি প্রকৃত কারণ টাইপ অনুমান ইতিমধ্যে সঞ্চালিত হয় যে কম্পাইলার ব্যবহার যা ক্লাসের নিদর্শনের সঙ্গে অনুমান করতে পারেন। এর অর্থ হল যে প্রকারটি valএটি ব্যবহৃত হয় সেই প্রসঙ্গে নির্ভর করে। এই কারণেই একটি একক valবিবৃতি চালানো একটি বাড়েambiguous type error : সংকলক প্রসঙ্গের ভিত্তিতে কোনও প্রকার অনুমান করতে পারে না।
জিএডিডি, টাইপ পরিবার, নির্ভরশীল প্রকারগুলি, সিস্টেম (এফ) etc. ইত্যাদির মতো আরও উন্নত প্রকারের সিস্টেমগুলির জন্য, টাইপ আর "প্রকার" নয় তারা জটিল কমপুটেশনাল অবজেক্টে পরিণত হয়। উদাহরণস্বরূপ এর অর্থ হ'ল দুটি ধরণের একইরকম না দেখানো অগত্যা পৃথক নয়। সুতরাং টাইপ সমতা তুচ্ছ হয়ে ওঠে না (মোটেও)।
প্রকৃত জটিলতার একটি উদাহরণ দেওয়ার জন্য আসুন তালিকার নির্ভরশীল প্রকারটি বিবেচনা করা যাক: তালিকার অবজেক্টগুলির ধরণ NList a nকোথায় aএবং nএর দৈর্ঘ্য।
সংযোজন ফাংশনের টাইপ হবে append :: NList a n -> NList a m -> NList a (n + m)এবং জিপ ফাংশন হবে zip :: NList a n -> NList b n -> NList (a, b) n।
ভাবুন এখন আমাদের ল্যাম্বডা আছে \a: NList t n, b: NList t m -> zip (append a b) (append b a)। এখানে জিপের প্রথম যুক্তি টাইপ NList t (n + m)এবং দ্বিতীয় ধরণের NList t (m + n)।
প্রায় একই, তবে যতক্ষণ না টাইপ চেকার জেনে থাকে যে প্রাকৃতিক সংখ্যায় "+" কমিট হয়, ততক্ষণ অবশ্যই এটি ফাংশনটি প্রত্যাখ্যান করতে হবে কারণ (এন + এম) আক্ষরিক (মি + এন) নয়। এটি আর টাইপ অনুমান / টাইপ চেকিং সম্পর্কে নয়, এটি উপপাদ্য প্রমাণ করার বিষয়ে।
তরল প্রকারগুলি মনে হয় কিছু নির্ভরশীল ধরণের অনুমিতি করছে। তবে আমি এটি বুঝতে পেরেছি যে এটি সত্যিকারের নির্ভরশীল ধরণের নয়, স্বাভাবিক এইচএম টাইপের মতো আরও কিছু যা স্থির সীমার গণনা করতে অতিরিক্ত অনুমান করা হয়।
আশা করি এটা কাজে লাগবে.