কেন প্রত্যেকের জন্য "ইন" এর পরিবর্তে কোলন রয়েছে?


9

জাভা 5 ভাষা নির্দেশিকা থেকে :

যখন আপনি কোলন দেখবেন (:) এটি "ইন" হিসাবে পড়ুন।

inতাহলে প্রথমে কেন ব্যবহার করবেন না?

বছরের পর বছর ধরে এটি আমাকে তুচ্ছ করে চলেছে। কারণ এটি বাকী ভাষার সাথে বেমানান। উদাহরণস্বরূপ, জাভা আছে implements, extends, superসি ++, Scala বা রুবি মত চিহ্ন পরিবর্তে ধরনের মধ্যে সম্পর্ক জন্য।

জাভা কোলনে 5 টি প্রসঙ্গে ব্যবহৃত হয় । যার মধ্যে তিনটি উত্তরাধিকার সূত্রে সি। এবং অন্য দু'জনকে জোশুয়া ব্লচ দ্বারা সমর্থন করা হয়েছিল। " ক্লোজার্স বিতর্ক" আলোচনার সময় অন্তত তিনি ছিলেন সইস । এটি প্রকাশিত হয় যখন তিনি প্রতিটি শব্দার্থবিজ্ঞানের সাথে সঙ্গতিপূর্ণ হিসাবে ম্যাপিংয়ের জন্য কোনও কোলন ব্যবহারের সমালোচনা করেন। আমার কাছে কোনটি অদ্ভুত বলে মনে হচ্ছে কারণ এটি প্রতিটি আপত্তিজনক প্রত্যাশার জন্য। লাইক list_name/category: elementsবা laberl/term: meaning

আমি jcp এবং jsr এর আশেপাশে স্নোপ করেছি, কিন্তু মেলিং তালিকার কোনও চিহ্ন পাইনি। গুগল দ্বারা এই বিষয়ে কোন আলোচনা খুঁজে পাওয়া যায় নি। শুধুমাত্র কোলন এর অর্থ দ্বারা বিভ্রান্ত newbies for


inএখন পর্যন্ত সরবরাহ করা বিরুদ্ধে প্রধান যুক্তি :

  • নতুন কীওয়ার্ড প্রয়োজন; এবং
  • লেক্সিংকে জটিল করে তোলে।

আসুন প্রাসঙ্গিক ব্যাকরণ সংজ্ঞাটি দেখুন:

বিবৃতি
    : 'জন্য' '(' নিয়ন্ত্রণের জন্য ')' বিবৃতি
    | ...
    ;

forControl
    : বর্ধিতকেন্দ্র
    | forInit? ';' অভিব্যক্তি? ';' forUpdate?
    ;

enhancedForControl
    : ভেরিয়েবলমডিফায়ার * টাইপ ভেরিয়েবলডেক্লেয়ারআইডি ':' এক্সপ্রেশন
    ;

থেকে পরিবর্তন :করতে inঅতিরিক্ত জটিলতা আনতে না বা নতুন শব্দ প্রয়োজন।


1
ভাষা ডিজাইনারদের অনুপ্রেরণা খুঁজে বের করার জন্য সর্বোত্তম উত্স হ'ল প্রায়শই ডিজাইনাররা ers এটি বলেছিল, এটি সম্ভবত একটি পুনরাবৃত্তিযোগ্য উপর কেবল সিনট্যাকটিক চিনি; স্ট্যাকওভারফ্লো
রবার্ট হার্ভে

উত্তর:


8

পার্সার ইনপুটটি স্পর্শ করার আগে সাধারণত পার্সারগুলি সাধারণত শেখানো হয় তাদের একটি লেজার স্টেজ থাকে। লেক্সার (এছাড়াও "স্ক্যানার" বা "টোকেনাইজার") ইনপুটটিকে ছোট টোকেনগুলিতে ছেঁকে দেয় যা কোনও প্রকারের সাথে টিকা দেওয়া থাকে। এটি প্রধান পার্সারকে প্রতিটি অক্ষরকে টার্মিনাল হিসাবে বিবেচনা করার পরিবর্তে টোকেনগুলি টার্মিনাল উপাদান হিসাবে ব্যবহার করতে দেয়, যা লক্ষণীয় দক্ষতা লাভের দিকে নিয়ে যায়। বিশেষত, লেক্সার সমস্ত মন্তব্য এবং সাদা স্থানও সরাতে পারে। তবে, একটি পৃথক টোকনাইজার পর্বের অর্থ হ'ল কীওয়ার্ডগুলি সনাক্তকারী হিসাবেও ব্যবহার করা যাবে না (যদি না ভাষা স্ট্রপিংকে সমর্থন করে যা কিছুটা অনুকূল হয়ে পড়েছে বা সিগিলের মতো সমস্ত সনাক্তকারীকে উপসর্গ না করে $foo)।

কেন? ধরে নেওয়া যাক আমাদের কাছে একটি সাধারণ টোকেনাইজার রয়েছে যা নিম্নলিখিত টোকেনগুলি বোঝে:

FOR = 'for'
LPAREN = '('
RPAREN = ')'
IN = 'in'
IDENT = /\w+/
COLON = ':'
SEMICOLON = ';'

টোকেনাইজার সর্বদা দীর্ঘতম টোকেনের সাথে মিলবে এবং শনাক্তকারীদের চেয়ে কীওয়ার্ড পছন্দ করবে। সুতরাং interestingহিসাবে lexed করা হবে IDENT:interesting, কিন্তু inযেমন হিসাবে INকখনও lexed হবে IDENT:interesting। একটি কোড স্নিপেট মত

for(var in expression)

টোকেন প্রবাহে অনুবাদ করা হবে

FOR LPAREN IDENT:var IN IDENT:expression RPAREN

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

for(in in expression)

প্রথমটি inএকটি সনাক্তকারী হবে, দ্বিতীয়টি কীওয়ার্ড হবে।

এই সমস্যাটির জন্য দুটি প্রতিক্রিয়া রয়েছে:

প্রাসঙ্গিক কীওয়ার্ডগুলি বিভ্রান্তিকর, এর পরিবর্তে কীওয়ার্ডগুলি পুনরায় ব্যবহার করুন।

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

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

প্রাসঙ্গিক কীওয়ার্ডগুলি ভাষাগুলি সরল করে, আসুন সেগুলি বাস্তবায়ন করি

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

for_loop = for_loop_cstyle | for_each_loop
for_loop_cstyle = 'for' '(' declaration · ';' expression ';' expression ')'
for_each_loop = 'for' '(' declaration · 'in' expression ')'

এই অবস্থানে, আইনী টোকেনগুলি হয় SEMICOLONবা INনা, তবে তা নয় IDENT। একটি কীওয়ার্ডটি inপুরোপুরি দ্ব্যর্থহীন।

এই নির্দিষ্ট উদাহরণে, উপরের ডাউন পার্সারগুলির কোনও সমস্যা নেই কারণ আমরা উপরের ব্যাকরণটি আবার লিখতে পারি

for_loop = 'for' '(' declaration · for_loop_rest ')'
for_loop_rest =  · ';' expression ';' expression
for_loop_rest = · 'in' expression

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

ব্যবহারযোগ্যতা বিবেচনা করুন

জাভা সর্বদা শব্দার্থক এবং সিনট্যাকটিক সরলতার দিকে ঝুঁকছে। উদাহরণস্বরূপ, ভাষা অপারেটর ওভারলোডিং সমর্থন করে না কারণ এটি কোডটিকে আরও জটিল করে তুলবে। সুতরাং প্রতিটি লুপ সিনট্যাক্সের মধ্যে inএবং এর মধ্যে সিদ্ধান্ত নেওয়ার সময় :, আমাদের বিবেচনা করতে হবে যেগুলি কম বিভ্রান্তিকর এবং ব্যবহারকারীদের কাছে আরও স্পষ্ট। চরম ঘটনা সম্ভবত হবে

for (in in in in())
for (in in : in())

(দ্রষ্টব্য: জাভা জন্য টাইপ নাম, ভেরিয়েবল, এবং পদ্ধতি পৃথক নামব্যবধান হয়েছে আমার মনে হয় বেশিরভাগ এই একটা ভুল ছিল, এই গড় পরে ভাষা নকশা যোগ করার জন্য হয়ে যায়।। আরো ভুল।)

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


17

প্রতিটি লুপ সিনট্যাক্সটি জাভা 5-এ যুক্ত করা হয়েছিল। আপনাকে কোনও inভাষার কীওয়ার্ড তৈরি করতে হবে এবং পরে কোনও ভাষায় কীওয়ার্ড যুক্ত করতে হবে যা আপনি যে কোনও মূল্যে এড়াতে পারবেন কারণ এটি বিদ্যমান কোডটি ভেঙে দেয় - হঠাৎ করে সমস্ত ভেরিয়েবল নামকরণ in পার্সিং করে ত্রুটি. enumএই ক্ষেত্রে যথেষ্ট খারাপ ছিল।


2
মনে হচ্ছে ... অসুবিধে হচ্ছে। এটি অনুমান করে যে ভাষা ডিজাইনাররা শুরু থেকেই বেশিরভাগ প্রয়োজনীয় কীওয়ার্ডের পূর্বাভাস দিতে যথেষ্ট ভাল ছিলেন। আমি নিশ্চিত না যে এটি এমনকি প্রয়োজনীয়; শালীন সংকলকরা নির্ধারণ করতে পারে কীওয়ার্ডটি তার প্রসঙ্গে একটি পরিবর্তনশীল কিনা।
রবার্ট হার্ভে

2
আমি মনে করি না জাভাতে সি # এর মতো প্রাসঙ্গিক কীওয়ার্ড রয়েছে। সুতরাং, ব্যবহারের inঅর্থ হ'ল হয় কোনও নতুন কীওয়ার্ড প্রবর্তন করা, যার ফলে পিছনে সামঞ্জস্যতা ( System.in, কারও?) ভেঙে দেওয়া বা পূর্বে অজানা একদম নতুন ধারণা (প্রাসঙ্গিক কীওয়ার্ড) প্রবর্তন করা। সব কি লাভের জন্য?
Jörg ডব্লু মিটাগ

2
প্রাসঙ্গিক কীওয়ার্ডগুলির কী ক্ষতি?
ব্যবহারকারী 2418306

5
@ user2418306 একটি কীওয়ার্ড যুক্ত করতে বিদ্যমান কোডটি ভাঙার দরকার নেই, তবে শর্ত থাকে যে ভাষাটি একটি পৃথক লেক্সার পর্যায়ে পার্স করা হয়নি। বিশেষত, একটি "ইন" for(variable in expression)কোনও বৈধ কোডের সাথে অস্পষ্ট হতে পারে না, এমনকি যদি "ইন" ভেরিয়েবলের জন্য ব্যবহার করা যায়। তবে অনেকগুলি সংকলক সরঞ্জামচইনে একটি পৃথক লেক্সার পর্ব বেশ সাধারণ। এটি কিছু সাধারণ পার্সার জেনারেটরগুলির সাথে জাভা পার্স করা অসম্ভব বা কমপক্ষে আরও জটিল করে তুলবে। কোনও ভাষার বাক্য গঠনকে সহজ রাখা সাধারণত জড়িত সকলের পক্ষে ভাল; প্রত্যেকেরই সি ++ বা পার্লের মতো সিনট্যাকটিক একত্বের প্রয়োজন হয় না।
আমন

1
@RobertHarvey: যে ভুলবেন না constএবং gotoজাভা উভয় সংরক্ষিত শব্দ, কিন্তু (এখনও) ব্যবহার করা হয় না।
টিএমএন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.