লুয়াউ-এ সেম্যান্টিক সাবটাইপিং

লুয়াউ হল প্রথম প্রোগ্রামিং ভাষা যা লক্ষ লক্ষ সৃজনকারীর হাতে সেম্যান্টিক সাবটাইপিং-এর ক্ষমতা তুলে দিয়েছে।

মিথ্যা ইতিবাচক ফলাফল হ্রাস করা

Roblox Studio-এর Script Analysis উইজেটের মতো টুলগুলোতে টাইপ ত্রুটি রিপোর্টিং-এ একটি সমস্যা হল মিথ্যা ইতিবাচক। এগুলো বিশ্লেষণের ফলস্বরূপ তৈরি হওয়া সতর্কবার্তা, যা রানটাইমে ঘটতে পারে এমন ত্রুটির সাথে মেলে না। উদাহরণস্বরূপ, প্রোগ্রাম

local x = CFrame.new()
local y
if math.random() < 0.5 then
  y = CFrame.new()
else
  y = Vector3.new()
end
local z = x * y

একটি টাইপ ত্রুটি রিপোর্ট করে যা রানটাইমে ঘটতে পারে না, কারণ CFrame উভয়ই Vector3 এবং CFrame দ্বারা গুণন সমর্থন করে। (এর টাইপ ((CFrame, CFrame) -> CFrame) & ((CFrame, Vector3) -> Vector3)।)

মিথ্যা পজিটিভ নতুন ব্যবহারকারীদের অনবোর্ডিং-এ বিশেষভাবে বিরক্তিকর। যদি কোনো টাইপ-কৌতূহলী নির্মাতা টাইপচেকিং চালু করে এবং সঙ্গে সঙ্গেই অসংখ্য অপ্রয়োজনীয় লাল ঢেউচিহ্ন দেখতে পায়, তাহলে সে তাৎক্ষণিকভাবে এটি বন্ধ করে দিতে প্রলুব্ধ হবে।

টাইপ ত্রুটিতে অনিশ্চয়তা অনিবার্য, কারণ রানটাইম ত্রুটি ঘটবে কিনা আগে থেকে বলা যায় না। টাইপ সিস্টেম ডিজাইনারদের সিদ্ধান্ত নিতে হয়—মিথ্যা পজিটিভ নাকি মিথ্যা নেগেটিভ, কোনটি সহ্য করবেন। Luau-তে এটি মোডের উপর নির্ভর করে: strict মোড মিথ্যা পজিটিভের দিকে ঝুঁকে, আর nonstrict মোড মিথ্যা নেগেটিভের দিকে ঝুঁকে।

যদিও ত্রুটিমুক্ত থাকা অসম্ভব, আমরা যতটা সম্ভব এগুলো দূর করার চেষ্টা করি, কারণ এগুলো অকার্যকর ত্রুটির কারণ হয় এবং অটোকমপ্লিট বা API ডকুমেন্টেশনের মতো টাইপ-চালিত টুলিং-এ অস্পষ্টতা সৃষ্টি করে।

মিথ্যা ইতিবাচকতার উৎস হিসেবে সাবটাইপিং

Luau-তে (এবং TypeScript বা Flow-এর মতো অন্যান্য অনেক অনুরূপ ভাষায়) মিথ্যা ইতিবাচকতার একটি প্রধান উৎস হল সাবটাইপিং। সাবটাইপিং তখনই ব্যবহৃত হয় যখন কোনো ভেরিয়েবল ইনিশিয়ালাইজ বা অ্যাসাইন করা হয়, এবং যখন কোনো ফাংশন কল করা হয়: টাইপ সিস্টেম পরীক্ষা করে যে এক্সপ্রেশনের টাইপটি ভেরিয়েবলের টাইপের সাবটাইপ কিনা। উদাহরণস্বরূপ, যদি আমরা উপরের প্রোগ্রামে টাইপ যোগ করি

local x : CFrame = CFrame.new()
local y : Vector3 | CFrame
if math.random() < 0.5 then
  y = CFrame.new()
else
  y = Vector3.new()
end
local z : Vector3 | CFrame = x * y

তাহলে টাইপ সিস্টেম পরীক্ষা করে যে CFrame গুণনের টাইপ (CFrame, Vector3 | CFrame) -> (Vector3 | CFrame)-এর সাবটাইপ কিনা।

সাবটাইপিং একটি অত্যন্ত দরকারী বৈশিষ্ট্য, এবং এটি টাইপ ইউনিয়ন (T | U) এবং ইন্টারসেকশন (T & U) এর মতো সমৃদ্ধ টাইপ নির্মাণকে সমর্থন করে। উদাহরণস্বরূপ, number? একটি ইউনিয়ন টাইপ (number | nil) হিসেবে বাস্তবায়িত হয়েছে, যার উপাদানগুলো হল সংখ্যা অথবা nil।

দুর্ভাগ্যবশত, সাবটাইপিং-এর ইন্টারসেকশন এবং ইউনিয়ন টাইপের সাথে মিথস্ক্রিয়া অদ্ভুত ফলাফল আনতে পারে। পুরনো Luau-তে একটি সাধারণ (কিন্তু বেশ কৃত্রিম) উদাহরণ ছিল:

local x : (number?) & (string?) = nil
local y : nil = nil
y = x -- Type '(number?) & (string?)' could not be converted into 'nil'
x = y

এই ত্রুটিটি সাবটাইপিং ব্যর্থতার কারণে ঘটে; পুরনো সাবটাইপিং অ্যালগরিদম রিপোর্ট করে যে number & string nil-এর সাবটাইপ নয়। এটি একটি ভুল ইতিবাচক, কারণ -এ কোনো মান নেই, তাই (number?) & (string?)-এর একমাত্র সম্ভাব্য বাসিন্দা হল nil।

এটি একটি কৃত্রিম উদাহরণ, তবে এই সমস্যাগুলো সৃজনকারীদের মধ্যে বাস্তব সমস্যা সৃষ্টি করেছে, উদাহরণস্বরূপ https://devforum.roblox.com/t/luau-recap-july-2021/1382101/5। বর্তমানে, এই সমস্যাগুলো প্রধানত উন্নত টাইপ সিস্টেম বৈশিষ্ট্য ব্যবহারকারী নির্মাতাদের প্রভাবিত করে, তবে আমরা টাইপ ইনফারেন্সকে আরও সঠিক করার সাথে সাথে ইউনিয়ন এবং ইন্টারসেকশন টাইপগুলো আরও সাধারণ হয়ে উঠবে, এমনকি এমন কোডেও যেখানে কোনো টাইপ অ্যানোটেশন নেই।

এই ধরনের ভুল ইতিবাচক ফলাফল আর Luau-তে ঘটে না, কারণ আমরা সিনট্যাকটিক সাবটাইপিং-এর পুরনো পদ্ধতি থেকে সেম্যান্টিক সাবটাইপিং নামে একটি বিকল্প পদ্ধতিতে সরে এসেছি।

সিনট্যাকটিক সাবটাইপিং

অর্থাৎ "আমরা আগে যা করতাম।"

সিনট্যাকটিক সাবটাইপিং একটি সিনট্যাক্স-নির্দেশিত পুনরাবৃত্তিমূলক অ্যালগরিদম। ইন্টারসেকশন এবং ইউনিয়ন টাইপের ক্ষেত্রে মোকাবেলা করার জন্য গুরুত্বপূর্ণ কেসগুলো হল:

• প্রতিফলন: T T-এর একটি উপপ্রকার।
• Intersection L: (T₁ & … & Tⱼ) একটি সাবটাইপ U এর, যখনই কিছু Tᵢ সাবটাইপ U এর।
• Union L: (T₁ | … | Tⱼ) একটি U-এর উপপ্রকার যখন সব Tᵢই U-এর উপপ্রকার।
• Intersection R: T একটি (U₁ & … & Uⱼ)-এর উপপ্রকার যখনই T সব Uᵢ-এর উপপ্রকার।
• ইউনিয়ন R: T হল (U₁ | … | Uⱼ)-এর একটি উপপ্রকার যখন T কিছু Uᵢ-এর উপপ্রকার।

উদাহরণস্বরূপ:

• প্রতিফলনশীলতার কারণে: nil একটি nil-এর উপপ্রকার।
• অতএব Union R দ্বারা: nil হলো number?-এর একটি উপপ্রকার
• এবং: nil একটি উপপ্রকার string?
• সুতরাং Intersection R অনুযায়ী: nil হল (number?) & (string?)-এর একটি উপপ্রকার।

হুররে! দুর্ভাগ্যবশত, এই নিয়মগুলো ব্যবহার করে:

• number nil-এর সাবটাইপ নয়
• সুতরাং Union L অনুযায়ী: (number?) nil-এর সাবটাইপ নয়
• এবং: string nil-এর উপপ্রকার নয়
• সুতরাং Union L অনুসারে: (string?) nil-এর সাবটাইপ নয়।
• সুতরাং Intersection L অনুযায়ী: (number?) & (string?) nil-এর সাবটাইপ নয়।

এটি সিনট্যাকটিক সাবটাইপিং-এর স্বাভাবিক বৈশিষ্ট্য: যখন এটি "হ্যাঁ" ফলাফল দেয়, তখন তা সঠিক, কিন্তু যখন এটি "না" ফলাফল দেয়, তখন তা ভুল হতে পারে। অ্যালগরিদমটি একটি রক্ষণশীল আনুমানিক পদ্ধতি, এবং "না" ফলাফল টাইপ ত্রুটির কারণ হতে পারে, যা মিথ্যা ইতিবাচকতার উৎস।

অর্থগত সাবটাইপিং

অর্থাৎ "আমরা এখন যা করি।"

সাবটাইপিংকে সিনট্যাক্স-নির্দেশিত হিসেবে ভাবার পরিবর্তে, আমরা প্রথমে এর সেম্যান্টিক্স বিবেচনা করি, এবং পরে ফিরে আসি কীভাবে সেম্যান্টিক্স বাস্তবায়িত হয়। এর জন্য, আমরা সেম্যান্টিক সাবটাইপিং গ্রহণ করি:

• একটি টাইপের সেম্যান্টিকস হল মানগুলির একটি সেট।
• ইন্টারসেকশন টাইপগুলোকে সেটগুলোর ছেদ হিসেবে ধরা হয়।
• ইউনিয়ন টাইপগুলোকে সেটগুলোর ইউনিয়ন হিসেবে ভাবা হয়।
• উপটাইপিংকে সেট অন্তর্ভুক্তি হিসেবে ধরা হয়।

উদাহরণস্বরূপ:

এবং যেহেতু সাবটাইপগুলোকে সেট অন্তর্ভুক্তি হিসেবে ব্যাখ্যা করা হয়:

সুতরাং সেম্যান্টিক সাবটাইপিং অনুযায়ী, (number?) & (string?) nil-এর সমতুল্য, কিন্তু সিনট্যাকটিক সাবটাইপিং শুধুমাত্র এক দিক সমর্থন করে।

এটা সব ঠিক আছে, কিন্তু যদি আমরা টুলগুলোতে সেম্যান্টিক সাবটাইপিং ব্যবহার করতে চাই, তাহলে আমাদের একটি অ্যালগরিদমের প্রয়োজন, এবং দেখা গেছে সেম্যান্টিক সাবটাইপিং যাচাই করা মোটেও সহজ নয়।

সেম্যান্টিক সাবটাইপিং কঠিন

নির্দিষ্টভাবে বলতে গেলে এটি NP-কঠিন।

আমরা গ্রাফ রঙকরণকে সেম্যান্টিক সাবটাইপিং-এ রূপান্তর করতে পারি, যদি গ্রাফটিকে একটি Luau টাইপ হিসেবে কোড করি, যাতে টাইপগুলিতে সাবটাইপিং পরীক্ষা করা এবং গ্রাফ রঙকরণ অসম্ভব কিনা তা পরীক্ষা করা একই ফলাফল দেয়।

উদাহরণস্বরূপ, তিনটি নোড এবং দুইটি রঙের একটি গ্রাফ রঙ করা টাইপ ব্যবহার করে করা যায়:

type Red = "red"
type Blue = "blue"
type Color = Red | Blue
type Coloring = (Color) -> (Color) -> (Color) -> boolean
type Uncolorable = (Color) -> (Color) -> (Color) -> false

তারপর একটি গ্রাফকে একটি ওভারলোড ফাংশন টাইপ হিসেবে এনকোড করা যায়, যার সাবটাইপ Uncolorable এবং সুপারটাইপ Coloring, একটি ওভারলোড ফাংশন হিসেবে যা কোনো শর্ত লঙ্ঘিত হলে false রিটার্ন করে। প্রতিটি ওভারলোড একটি শর্ত এনকোড করে। উদাহরণস্বরূপ, একটি লাইনের শর্ত বলে যে পার্শ্ববর্তী নোডগুলো একই রঙের হতে পারে না:

type Line = Coloring
  & ((Red) -> (Red) -> (Color) -> false)
  & ((Blue) -> (Blue) -> (Color) -> false)
  & ((Color) -> (Red) -> (Red) -> false)
  & ((Color) -> (Blue) -> (Blue) -> false)

একটি ত্রিভুজও অনুরূপ, তবে এর শেষ বিন্দুগুলোও একই রঙের হতে পারে না:

type Triangle = Line
  & ((Red) -> (Color) -> (Red) -> false)
  & ((Blue) -> (Color) -> (Blue) -> false)

এখন, Triangle হল Uncolorable-এর একটি সাবটাইপ, কিন্তু Line নয়, কারণ লাইনটি ২-রঙের হতে পারে। এটিকে যেকোনো সীমিত রঙের যেকোনো সীমিত গ্রাফে সাধারণীকরণ করা যায়, এবং তাই সাবটাইপ চেকিং NP-কঠিন।

আমরা এটি মোকাবেলা করি দুইভাবে:

• আমরা মেমোরির ব্যবহার কমাতে টাইপগুলো ক্যাশ করি, এবং
• যদি টাইপের ক্যাশ খুব বড় হয়ে যায়, তাহলে "Code Too Complex" ত্রুটির মাধ্যমে হাল ছেড়ে দেওয়া হয়।

আশা করি বাস্তবে এটা খুব একটা দেখা যাবে না। স্ট্যান্ডার্ড এমএল-এর মতো EXPTIME-সম্পূর্ণ টাইপ সিস্টেমের অভিজ্ঞতা থেকে প্রমাণ আছে যে এ ধরনের সমস্যা বাস্তবে দেখা দেয় না, তবে বাস্তবে আপনাকে ট্যুরিং মেশিনের টেপকে টাইপ হিসেবে কোড করতে বিশেষভাবে উদ্যোগী হতে হবে।

টাইপ নরম্যালাইজেশন

অর্থগত সাবটাইপিং নির্ধারণের জন্য যে অ্যালগরিদম ব্যবহার করা হয় তা হল টাইপ নরম্যালাইজেশন। সিনট্যাক্সের নির্দেশনা অনুসরণ না করে, আমরা প্রথমে টাইপগুলোকে নরম্যালাইজড ফর্মে পুনঃলিখন করি, তারপর নরম্যালাইজড টাইপগুলোর উপর সাবটাইপিং পরীক্ষা করি।

একটি স্বাভাবিকীকৃত টাইপ হল:

• একটি স্বাভাবিকীকৃত নীল টাইপ (never অথবা nil)
• একটি স্বাভাবিকীকৃত সংখ্যা টাইপ (never অথবা number)
• একটি স্বাভাবিকীকৃত বুলিয়ান টাইপ (never বা true বা false বা boolean)
• একটি স্বাভাবিকীকৃত ফাংশন টাইপ (never অথবা একাধিক ফাংশন টাইপের ইন্টারসেকশন) ইত্যাদি

একবার টাইপগুলো নরমালাইজ হয়ে গেলে, সেম্যান্টিক সাবটাইপিং যাচাই করা সহজ হয়ে যায়।

প্রতিটি টাইপকে নরমালাইজ করা যায় (হায়, জেনেরিক টাইপ প্যাকের চারপাশে কিছু প্রযুক্তিগত সীমাবদ্ধতা আছে)। গুরুত্বপূর্ণ ধাপগুলো হল:

• অসামঞ্জস্যপূর্ণ প্রিমিটিভের ইন্টারসেকশন অপসারণ, যেমন number & bool-এর পরিবর্তে never, এবং
• ফাংশনের ইউনিয়নগুলো অপসারণ, যেমন ((number?) -> number) | ((string?) -> string)-এর পরিবর্তে (nil) -> (number | string)।

উদাহরণস্বরূপ, (number?) & (string?)-কে স্বাভাবিকীকরণ করলে number & string বাদ পড়ে, ফলে শুধুমাত্র nil অবশিষ্ট থাকে।

টাইপ নরম্যালাইজেশন বাস্তবায়নের আমাদের প্রথম প্রচেষ্টা এটিকে উদারভাবে প্রয়োগ করেছিল, কিন্তু এর ফলে ভয়াবহ কর্মক্ষমতা দেখা দিয়েছিল (জটিল কোড যা এক মিনিটেরও কম সময়ে টাইপচেক হতো, তা রাতভর চলতে শুরু করেছিল)। এর কারণ বিরক্তিকরভাবেই সহজ: Luau-এর সাবটাইপিং অ্যালগরিদমে রিফ্লেক্সিটি (T একটি T-এর সাবটাইপ) মোকাবেলার জন্য একটি অপ্টিমাইজেশন আছে, যা একটি সস্তা পয়েন্টার সমতার পরীক্ষা করে। টাইপ নরম্যালাইজেশন পয়েন্টার-আইডেন্টিকাল টাইপগুলোকে সেম্যান্টিকালি-ইক্যুয়াল (কিন্তু পয়েন্টার-আইডেন্টিকাল নয়) টাইপে রূপান্তর করতে পারে, যা পারফরম্যান্সকে উল্লেখযোগ্যভাবে হ্রাস করে।

এই কর্মক্ষমতা সমস্যাগুলোর কারণে, আমরা এখনও সিনট্যাকটিক সাবটাইপিংকে সাবটাইপিংয়ের প্রথম পরীক্ষা হিসেবে ব্যবহার করি, এবং শুধুমাত্র সিনট্যাকটিক অ্যালগরিদম ব্যর্থ হলেই টাইপ নরমালাইজেশন প্রয়োগ করি। এটি সঠিক, কারণ সিনট্যাকটিক সাবটাইপিং সেম্যান্টিক সাবটাইপিংয়ের একটি রক্ষণশীল অনুমান।

ব্যবহারিক সেম্যান্টিক সাবটাইপিং

বাজারে প্রচলিত সেম্যান্টিক সাবটাইপিং Luau-তে বাস্তবায়িত পদ্ধতির থেকে কিছুটা ভিন্ন, কারণ এতে মডেলগুলোকে সেট-থিওরেটিক হতে হয়, যার ফলে ফাংশন টাইপের উপাদানগুলোকে "ফাংশনের মতো" আচরণ করতে হয়। আমরা এই শর্তটি বাদ দেওয়ার দুটি কারণ আছে।

প্রথমত, আমরা ফাংশন টাইপগুলোকে ফাংশনগুলোর একটি ইন্টারসেকশনে নরমালাইজ করি, উদাহরণস্বরূপ ফাংশনগুলোর ইউনিয়ন এবং ইন্টারসেকশনের এক ভয়ানক জঞ্জাল:

((number?) -> number?) | (((number) -> number) & ((string?) -> string?))

এটি একটি ওভারলোড করা ফাংশনে স্বাভাবিকীকৃত হয়:

((number) -> number?) & ((nil) -> (number | string)?)

সেট-থিওরেটিক সেম্যান্টিক সাবটাইপিং এই নরমালൈজেশন সমর্থন করে না, বরং ফাংশনগুলোকে ডিসজন্‌ক্টিভ নরমাল ফর্ম (ফাংশনের ইন্টারসেকশনের ইউনিয়ন) এ নরমালাইজ করে। আমরা এটি ব্যবহারের সুবিধার কারণে করি না: লুয়াউ-তে ওভারলোডেড ফাংশন স্বাভাবিক, কিন্তু ডিএনএফ স্বাভাবিক নয়, এবং আমরা ব্যবহারকারীদের এমন অ-স্বাভাবিক টাইপ উপস্থাপন করতে চাই না।

আমাদের নরম্যালাইজেশন ফাংশন টাইপের ইউনিয়নগুলোকে পুনঃলিখনের মাধ্যমে মুছে ফেলার ওপর নির্ভর করে:

((A) -> B) | ((C) -> D)   →   (A & C) -> (B | D)

এই নরমালizasন আমাদের মডেলে সঠিক, কিন্তু সেট-থিয়োরেটিক মডেলে নয়।

দ্বিতীয়ত, Luau-তে, একটি ফাংশন প্রয়োগের ধরন f(x) হল B যদি f-এর ধরন হয় (A) -> B এবং x-এর ধরন হয় A। অপ্রত্যাশিতভাবে, সেট-তাত্ত্বিক মডেলগুলোতে এটি সবসময় সত্য নয়, কারণ অব্যবহৃত টাইপ রয়েছে। সেট-তাত্ত্বিক মডেলগুলোতে, যদি x-এর টাইপ never হয়, তাহলে f(x)-এর টাইপ never হয়। আমরা ব্যবহারকারীদের ফাংশন প্রয়োগে একটি বিশেষ কোণ-ক্ষেত্রের ধারণা দিয়ে বোঝাতে চাই না, বিশেষ করে যেহেতু সেই কোণ-ক্ষেত্র কেবল মৃত কোডে উদ্ভূত হতে পারে।

সেট-থিওরেটিক মডেলগুলোতে, (never) -> A (never) -> B-এর একটি সাবটাইপ, A এবং B যাই হোক না কেন। Luau-তে এটা সত্য নয়।

এই দুই কারণে (যা মূলত প্রযুক্তিগতের চেয়ে ব্যবহারিক আরগনোমিক্স সম্পর্কে) আমরা সেট-তাত্ত্বিক শর্তটি বাদ দিই এবং ব্যবহারিক সেম্যান্টিক সাবটাইপিং ব্যবহার করি।

নেগেশন টাইপসমূহ

Luau-এর টাইপ সিস্টেম এবং প্রচলিত সেম্যান্টিক সাবটাইপিং-এর মধ্যে আরেকটি পার্থক্য হল Luau সব নেগেটেড টাইপ সমর্থন করে না।

শর্তসাপেক্ষ টাইপচেকিং-এ নেগেটেড টাইপের সাধারণ প্রয়োগ:

-- initially x has type T
if type(x) == "string" then
  --  in this branch x has type T & string
else
  -- in this branch x has type T & ~string
end

এটি একটি নেগেটেড টাইপ ~string ব্যবহার করে, যার মানগুলো স্ট্রিং নয়।

Luau-তে, আমরা শুধুমাত্র string, function, Part ইত্যাদি টেস্ট টাইপের ক্ষেত্রেই এই ধরনের টাইপিং রিফাইন্মেন্ট অনুমোদন করি, (A) -> B-এর মতো স্ট্রাকচারাল টাইপের ক্ষেত্রে নয়, যা সাধারণ নেগেটেড টাইপের ক্ষেত্রে প্রযোজ্যতা এড়িয়ে যায়।

প্রোটোটাইপিং এবং যাচাইকরণ

Luau-এর সেম্যান্টিক সাবটাইপিং অ্যালগরিদমের নকশার সময় কিছু পরিবর্তন করা হয়েছিল (উদাহরণস্বরূপ, প্রথমে আমরা ভেবেছিলাম যে আমরা সেট-থিওরেটিক সাবটাইপিং ব্যবহার করতে পারব)। এই দ্রুত পরিবর্তনের সময়ে দ্রুত পুনরাবৃত্তি করা গুরুত্বপূর্ণ ছিল, তাই আমরা সরাসরি প্রোডাকশন বাস্তবায়নে না গিয়ে প্রথমে একটি প্রোটোটাইপ বাস্তবায়ন করেছিলাম।

প্রোটোটাইপ যাচাই করা গুরুত্বপূর্ণ ছিল, কারণ সাবটাইপিং অ্যালগরিদমে অপ্রত্যাশিত কিছু বিশেষ ক্ষেত্রে সমস্যা দেখা দিতে পারে। এই কারণে আমরা প্রোটোটাইপিং ভাষা হিসেবে Agda গ্রহণ করেছিলাম। ইউনিট টেস্টিং সমর্থনের পাশাপাশি Agda যান্ত্রিক যাচাইকরণও সমর্থন করে, তাই আমরা ডিজাইনে আত্মবিশ্বাসী।

প্রোটোটাইপটি Luau-এর সবকিছু বাস্তবায়ন করে না, শুধুমাত্র কার্যকরী উপসেটটি বাস্তবায়ন করে, তবে এটি সূক্ষ্ম বৈশিষ্ট্যগত মিথস্ক্রিয়া আবিষ্কার করার জন্য যথেষ্ট ছিল, যা সম্ভবত প্রোডাকশনে ঠিক করতে কঠিন বাগ হিসেবে প্রকাশ পেত।

প্রোটোটাইপিং নিখুঁত নয়, উদাহরণস্বরূপ প্রোডাকশনে আমরা যে প্রধান সমস্যাগুলোর সম্মুখীন হয়েছিলাম তা ছিল পারফরম্যান্স এবং C++ স্ট্যান্ডার্ড লাইব্রেরি সম্পর্কিত, যা একটি প্রোটোটাইপ কখনোই ধরতে পারবে না। তবে প্রোডাকশন বাস্তবায়ন অন্যথায় বেশ সরল ছিল (অথবা অন্তত ৩kLOC পরিবর্তনের ক্ষেত্রে যতটা সরল হতে পারে)।

পরবর্তী পদক্ষেপ

সেম্যান্টিক সাবটাইপিং মিথ্যা পজিটিভের একটি উৎস দূর করেছে, তবে আমাদের এখনও অন্যান্যগুলো খুঁজে বের করতে হবে:

• ওভারলোডেড ফাংশন প্রয়োগ এবং অপারেটরসমূহ
• জটিল ধরনের এক্সপ্রেশনগুলিতে প্রপার্টি অ্যাক্সেস
• টেবিলের শুধুমাত্র-পঠনযোগ্য বৈশিষ্ট্যসমূহ
• সময়ের সাথে সাথে টাইপ পরিবর্তনশীল ভেরিয়েবল (যা টাইপস্টেট নামেও পরিচিত)

মিথ্যা লাল ঢেউচিহ্ন দূর করার অভিযান অব্যাহত!

কৃতজ্ঞতা

এই পোস্টের খসড়া নিয়ে সহায়ক মন্তব্যের জন্য জিউসেপ্পে কাস্তাগনা এবং বেন গ্রিনম্যানকে ধন্যবাদ।

অ্যালান লুয়াউ টাইপ সিস্টেমের নকশা ও বাস্তবায়ন সমন্বয় করেন, যা Roblox Studio-তে উন্নয়নের অনেক বৈশিষ্ট্যকে চালিত করে। ড. জেফ্রির প্রোগ্রামিং ভাষা গবেষণায় ৩০ বছরেরও বেশি অভিজ্ঞতা রয়েছে, তিনি অসংখ্য ওপেন-সোর্স সফটওয়্যার প্রকল্পের একজন সক্রিয় সদস্য, এবং ইংল্যান্ডের অক্সফোর্ড বিশ্ববিদ্যালয় থেকে DPhil ডিগ্রি অর্জন করেছেন।