خرسِ برنامه نویس

خرسِ برنامه نویس

چیشد و چرا یهو lambda calculus رو به Closure ربط داد؟ از جایی شروع کنیم که هنوز خبری از Closure نبود؛ روزهایی که برنامه‌نویسان با زبان‌هایی مثل Algol 60 تازه با مفهوم توابع تو در تو آشنا می‌شدند. در آن دوران، گروهی از پژوهشگران در نشست ۱۹۵۸ زوریخ قواعد «block…

در خط اول یک ثابت به نام ‎y تعریف کرده‌ایم و مقدار ۵ را در آن گذاشته‌ایم. این عدد قرار است همان متغیر آزاد (free variable) باشد که تابع‌های بعدی از محیط بیرونی بردارند.
بعد تابع ‎f را می‌بینید که دو ورودی ‎x و ‎y می‌گیرد. این تابع در ساده‌ترین حالت فقط این دو عدد را با هم جمع می‌کند و حاصل را برمی‌گرداند. بنابراین اگر ‎f(3, 5) را صدا بزنیم جواب ۸ می‌شود.
در ادامه تابع ‎g را تعریف کرده‌ایم؛ ‎g خودش فانکشن است که تنها پارامترش ‎x است. داخل بدنهٔ ‎g، تابع ‎f را صدا می‌زنیم و ‎x را به عنوان آرگومان اول و ‎y بیرونی را به عنوان آرگومان دوم به ‎f می‌دهیم. به این ترتیب ‎g یک Closure تشکیل می‌دهد، چون ‎y را همراه خودش «می‌بندد» و هر جا ‎g را اجرا کنیم همان مقدار ۵ را کنار ‎x قرار می‌دهد.

در نهایت با ‎console.log(g(3)) تابع ‎g را برای ورودی ‎3 اجرا کرده‌ایم. ‎g مقدار ۳ را به ‎f می‌دهد، ‎f هم ۳ و ۵ را جمع می‌کند و نتیجه‌ی ۸ را برمی‌گرداند.

بعد ها Guy Sussman و Gerald Steele هنگام طراحی زبان Scheme دریافتند که اگر قرار است lexical scope تعیین کند چه نامی در دسترس است، Closure باید تضمین کند آن نام‌ها بعد از پایان تابع بیرونی از بین نرود. با جا افتادن این الگو، Closure به بخش جدایی‌ناپذیر پیاده‌سازی تمام زبان‌های امروزی—from JavaScript و C# تا Python—تبدیل شد؛ سازوکاری که اجازه می‌دهد callbackها context خود را «به خاطر بسپارند»، فکتوری فانکشن ها state مخصوص به خود بسازند و کد بدون اتکا به global متغیرهای خصوصی نگه دارد.

داستان از λ‑calculus شروع شد، جایی که مفهوم متغیرهای free و bound شکل گرفت. با ورود lexical scope فهمیدیم که جای قرارگیری کد در متن، دسترسی به نام‌ها را مشخص می‌کند. Peter Landin ایدهٔ closure را اضافه کرد تا یک تابع بتواند محیط تعریفِ خود را همراه داشته باشد. در نتیجه، آنچه از نظریهٔ محاسبه آغاز شده بود، در closure به کاربردی عملی تبدیل شد و امروز در بیشتر زبان‌ها به‌عنوان روشی ساده برای نگه‌داشتن state در کنار توابع به‌کار می‌رود.

پایان
#بخش3

www.tgoop.com/bear_the_software_engineer/979

197 viewsedited  Jun 7 at 18:47

در خط اول یک ثابت به نام ‎y تعریف کرده‌ایم و مقدار ۵ را در آن گذاشته‌ایم. این عدد قرار است همان متغیر آزاد (free variable) باشد که تابع‌های بعدی از محیط بیرونی بردارند.
بعد تابع ‎f را می‌بینید که دو ورودی ‎x و ‎y می‌گیرد. این تابع در ساده‌ترین حالت فقط این دو عدد را با هم جمع می‌کند و حاصل را برمی‌گرداند. بنابراین اگر ‎f(3, 5) را صدا بزنیم جواب ۸ می‌شود.
در ادامه تابع ‎g را تعریف کرده‌ایم؛ ‎g خودش فانکشن است که تنها پارامترش ‎x است. داخل بدنهٔ ‎g، تابع ‎f را صدا می‌زنیم و ‎x را به عنوان آرگومان اول و ‎y بیرونی را به عنوان آرگومان دوم به ‎f می‌دهیم. به این ترتیب ‎g یک Closure تشکیل می‌دهد، چون ‎y را همراه خودش «می‌بندد» و هر جا ‎g را اجرا کنیم همان مقدار ۵ را کنار ‎x قرار می‌دهد.

در نهایت با ‎console.log(g(3)) تابع ‎g را برای ورودی ‎3 اجرا کرده‌ایم. ‎g مقدار ۳ را به ‎f می‌دهد، ‎f هم ۳ و ۵ را جمع می‌کند و نتیجه‌ی ۸ را برمی‌گرداند.

بعد ها Guy Sussman و Gerald Steele هنگام طراحی زبان Scheme دریافتند که اگر قرار است lexical scope تعیین کند چه نامی در دسترس است، Closure باید تضمین کند آن نام‌ها بعد از پایان تابع بیرونی از بین نرود. با جا افتادن این الگو، Closure به بخش جدایی‌ناپذیر پیاده‌سازی تمام زبان‌های امروزی—from JavaScript و C# تا Python—تبدیل شد؛ سازوکاری که اجازه می‌دهد callbackها context خود را «به خاطر بسپارند»، فکتوری فانکشن ها state مخصوص به خود بسازند و کد بدون اتکا به global متغیرهای خصوصی نگه دارد.

داستان از λ‑calculus شروع شد، جایی که مفهوم متغیرهای free و bound شکل گرفت. با ورود lexical scope فهمیدیم که جای قرارگیری کد در متن، دسترسی به نام‌ها را مشخص می‌کند. Peter Landin ایدهٔ closure را اضافه کرد تا یک تابع بتواند محیط تعریفِ خود را همراه داشته باشد. در نتیجه، آنچه از نظریهٔ محاسبه آغاز شده بود، در closure به کاربردی عملی تبدیل شد و امروز در بیشتر زبان‌ها به‌عنوان روشی ساده برای نگه‌داشتن state در کنار توابع به‌کار می‌رود.

پایان
#بخش3

BY خرسِ برنامه نویس