۵ - ۲تایپ‌ها چه فایده‌ای دارن؟

هسکل در واقع یک پیاده‌سازی از جبر لاندا ِ خالص‌ِه، و به نوعی فقط یه شکر گرامری برای اون سیستمِ پایه از متغیرها، تجریدها، و اعمال‌هایی‌ه که قوانین جبر لاندا رو تشکیل میدن – یا حداقل یه پیاده‌سازی از جبر لاندا ِ تایپ‌دار ِه. پیشرفت در منطق، ریاضیات، و علم کامپیوتر منجر به کشفِ (یا اختراع، هر کدوم راحتین) یک جبر لاندا ِ تایپ‌دار به اسم System F در دهه‌ی ۱۹۷۰ شد. هسکل از System F در چند موردِ کلیدی ارتقا پیدا کرد، مثل امکانِ تعریف توابع بازگشتی یا خوداتکا (توضیحات بیشتر در یکی از فصل‌های آینده) و سیستم هیندلی-میلنر برای استنتاج تایپ (توضیحات بیشتر در همین فصل)، اما هسته‌ی منطقِ اون یکسانه.

خوب حالا چرا تایپ می‌خوایم؟ در منطق و ریاضیات، تایپ سیستم‌ها درست شدن تا با اعمالِ محدودیت‌هایی، صحت و درستی رو اجبار کنن. تایپ سیستم ای که خوب طراحی شده باشه، جلوی خیلی از خطاها رو می‌گیره و باعث حذف دسته‌ای از مشغله‌ها میشه – مثل اینکه تأثیرِ یه جمله‌ی شرطی روی یه مقدارِ غیربولی چی ممکنه باشه. یک تایپ سیستم، روابط بین بخشهای مختلف برنامه رو تعریف می‌کنه، و مطمئن میشه که همه‌ی این بخشها با انسجام منطقی و صحتِ قابل اثبات کنار هم کار می‌کنن.

یه مثال کوتاه و شاید بیش از اندازه ساده میزنیم. فصل قبل دیدیم که تایپِ ‏‎Bool‎‏، یک مجموعه با دو عضو بود، ‏‎True‎‏ و ‏‎False‎‏. هر وقت تایپچِکر (م. یا بررسی‌کننده‌ی تایپ) ِ هسکل یکی از مقادیرِ ‏‎True‎‏ یا ‏‎False‎‏ رو ببینه، میدونه که اعضای تایپِ ‏‎Bool‎‏ اند. برعکس‌ش هم صادق‌ِه، یعنی هروقت در یه تایپ سیگنچر، تایپِ ‏‎Bool‎‏ تعریف بشه، کامپایلر فقط و فقط انتظارِ یکی از اون دو مقدار رو داره؛ اگه جایی انتظارِ ‏‎Bool‎‏ داره و بِهِش عدد بدین، خطای تایپ می‌گیرین.

تایپ‌ها در هسکل ایستا اند*، و تایپچِک در لحظه‌ی کامپایل انجام میشه. پس خیلی از خطاها قبل از اجرای برنامه گرفته میشن. اما هیچ تایپ سیستم ای نمی‌تونه همه‌ی احتمالاتِ خطا رو منحل کنه، و هنوز احتمال خطاهای زمان اجرا و استثنا ها باقی می‌مونه. با این اوصاف، تست کردنِ برنامه‌ها در هسکل هم ضروری‌ه، ولی به لطف تایپ سیستم ِش، تعداد و انواع تست‌های لازم کمتر شدن.

*

م. به کلامی دیگه، هسکل statically typed ِه.

یه تایپ سیستم ِ خوب، امکانِ بهینه‌سازیِ کامپایلر رو هم فراهم می‌کنه؛ چراکه کامپایلر با دونستنِ تایپ‌ها، می‌تونه چیزهای خاصی درباره‌ی اجرای برنامه بدونه یا پیش‌بینی کنه. تایپ‌ها می‌تونن نقشِ مستندات ِ برنامه‌تون رو هم داشته باشن، که در واقع یکی از دلایلی‌ه که ما شما رو به نوشتنِ تایپ سیگنچرها تشویق می‌کنیم. برای برنامه‌های کوچیک خیلی مهم نیست، ولی با رشد برنامه‌ها، تایپ سیگنچرها کمک زیادی به خوندن برنامه‌ها می‌کنن؛ چه برای شخص دیگه‌ای که بخواد از کُدِتون استفاده کنه، چه برای خودتون در آینده که فقط با خوندن تایپ سیگنچرها ممکنه کاری که کرده بودین رو به یاد بیارین.

ممکنه به نظر بیاد که قبل از کدنویسیِ هسکل، خیلی برنامه‌ریزی و کارِ اولیه لازم باشه. ولی این کارهای اولیه بعداً بازدهی خوبی دارن: کُدی که مطمئن‌تره، و آخرِ کار هم نگهداری ِ آسون‌تری داره. وقتی با یه تایپ سیستم ِ خوب کار می‌کنین، دیگه لازم ندارین برای درست بودن داده‌های ورودی به توابع، تست بنویسین؛ نوشتنِ تست هم به‌خودیِ‌خود کدنویسی‌ه (که باید صحیح نوشته و نگهداری بشه). پس در کل زحمتی که باید بکشین و وقتی که باید بذارین کمتر میشه.

تایپ سیستم‌های اکثر زبان‌های برنامه‌نویسی، چیزی شبیه چونه زدن با یه دست‌فروش رو تداعی می‌کنن. ولی به نظر ما، تایپ سیستم ِ هسکل بیشتر تداعی‌کننده‌ی یه مصاحبت آروم و خوشایند با شریک‌تون می‌مونه تا یه جرّوبحث وسط بازار. بیشتر پیشنهادهای ما، مثل نوشتن کد تو یه فایل، بارگذاری ِش تو REPL، استعلام کردن ِ تایپ‌ها در REPL، و غیره، در حقیقت برای ایجادِ عادتهایی‌اند که شما رو به همون مصاحبتِ خوشایند با تایپ سیستم می‌رسونن.