مثل QBASIC باشه [تقریبا]؟!
مثل QBASIC باشه [تقریبا]؟!
نباید شبیه زبانی دیگه باشه؟
در ضمن همونطور که گفتم من فقط تا اواسط اسفند, وقت آزاد دارم. بعدش به خاطر درسهام نمیتونم فعلآ وقتم رو برای این کار بگذارم.
کی فکر می کنی وقتت آزاد می شه؟!
تا آخر ترم !
ولی متآسفانه تا همینجاش خیلی وقت و از دست دادیم.
شاید بتونم تا اون موقع تحلیلگر نحوی رو تکمیل کنم و باقی رو بذاریم برای بعد.
اعتماد به نفستون توی حلقم
صفحه 1 تایپیک بودم، اونجا بحث بود که ساختار لغات مشخص بشه! الان اومدم صفحه 29 می بینم که هنوز داره در مورد ساختار کلمات کلیدی و نحو برنامه بحث میشه!
کارتون قابل تحسین هست ولی فکر کنم حتی اگر بخواهید به یک نتیجه ساده برسید سال ها طول بکشه...
یک پیشنهاد:
چون پروژه تجاری نیست صرفا جنبه آموزشی داره به نظرم اول یک زبان ناقص طراحی کنید و اگر جواب داد بعد روی کامل کردنش تحت یک پروژه کاملا جدید و مستقل کار کنید...
مشکل وقته! وگرنه کار ادامه پیدا می کنه. کس دیگه هم غیر از جناب amin32 نیست که کارو سریع تر ادامه بدیم...
سلام بر دوستان عزیز
ضمن عرض تبریک سال نو میخواستم عرض کنم من هم تاپیک دارم دنبال میکنم ولی خبری نشد حالا که من میخوام یک پروژه تجاری اینجا ارائه بدم بلکه شما دوستان بتونید روی این موضوع کمکی به من بکنید شاید روش اجرا جنبه ایی آموزشی هم شد
من در حال نوشتن یک پلتفورم برای بازار فارکس هستم و میخوام با ساخت کامپلیر ساده بتونم اندیکاتورهای نوشته شده در این مورد به این پلتفرم اضافه کنم در زیز هم نمونه یکی از اندیکاتورها اضافه کردم حالا ضمن نوشته های قبلی دوستان هر کدوم از دوستان که توانایی دارن راهنمایی کنند(از همه دوستان تشکر میکنم)
//+------------------------------------------------------------------+
//| Heiken Ashi.mq4 |
//| Copyright c 2004, MetaQuotes Software Corp. |
//| http://www.metaquotes.net |
//+------------------------------------------------------------------+
//| For Heiken Ashi we recommend next chart settings ( press F8 or |
//| select on menu 'Charts'->'Properties...'): |
//| - On 'Color' Tab select 'Black' for 'Line Graph' |
//| - On 'Common' Tab disable 'Chart on Foreground' checkbox and |
//| select 'Line Chart' radiobutton |
//+------------------------------------------------------------------+
#property copyright "Copyright © 2004, MetaQuotes Software Corp."
#property link "http://www.metaquotes.net"
#property indicator_chart_window
#property indicator_buffers 4
#property indicator_color1 Red
#property indicator_color2 White
#property indicator_color3 Red
#property indicator_color4 White
#property indicator_width1 1
#property indicator_width2 1
#property indicator_width3 3
#property indicator_width4 3
//----
extern color color1 = Red;
extern color color2 = White;
extern color color3 = Red;
extern color color4 = White;
//---- buffers
double ExtMapBuffer1[];
double ExtMapBuffer2[];
double ExtMapBuffer3[];
double ExtMapBuffer4[];
//----
int ExtCountedBars=0;
//+------------------------------------------------------------------+
//| Custom indicator initialization function |
//|------------------------------------------------------------------|
int init()
{
//---- indicators
SetIndexStyle(0,DRAW_HISTOGRAM, 0, 1, color1);
SetIndexBuffer(0, ExtMapBuffer1);
SetIndexStyle(1,DRAW_HISTOGRAM, 0, 1, color2);
SetIndexBuffer(1, ExtMapBuffer2);
SetIndexStyle(2,DRAW_HISTOGRAM, 0, 3, color3);
SetIndexBuffer(2, ExtMapBuffer3);
SetIndexStyle(3,DRAW_HISTOGRAM, 0, 3, color4);
SetIndexBuffer(3, ExtMapBuffer4);
//----
SetIndexDrawBegin(0,10);
SetIndexDrawBegin(1,10);
SetIndexDrawBegin(2,10);
SetIndexDrawBegin(3,10);
//---- indicator buffers mapping
SetIndexBuffer(0,ExtMapBuffer1);
SetIndexBuffer(1,ExtMapBuffer2);
SetIndexBuffer(2,ExtMapBuffer3);
SetIndexBuffer(3,ExtMapBuffer4);
//---- initialization done
return(0);
}
//+------------------------------------------------------------------+
//| Custom indicator deinitialization function |
//+------------------------------------------------------------------+
int deinit()
{
//---- TODO: add your code here
//----
return(0);
}
//+------------------------------------------------------------------+
//| Custom indicator iteration function |
//+------------------------------------------------------------------+
int start()
{
double haOpen, haHigh, haLow, haClose;
if(Bars<=10) return(0);
ExtCountedBars=IndicatorCounted();
//---- check for possible errors
if (ExtCountedBars<0) return(-1);
//---- last counted bar will be recounted
if (ExtCountedBars>0) ExtCountedBars--;
int pos=Bars-ExtCountedBars-1;
while(pos>=0)
{
haOpen=(ExtMapBuffer3[pos+1]+ExtMapBuffer4[pos+1])/2;
haClose=(Open[pos]+High[pos]+Low[pos]+Close[pos])/4;
haHigh=MathMax(High[pos], MathMax(haOpen, haClose));
haLow=MathMin(Low[pos], MathMin(haOpen, haClose));
if (haOpen<haClose)
{
ExtMapBuffer1[pos]=haLow;
ExtMapBuffer2[pos]=haHigh;
}
else
{
ExtMapBuffer1[pos]=haHigh;
ExtMapBuffer2[pos]=haLow;
}
ExtMapBuffer3[pos]=haOpen;
ExtMapBuffer4[pos]=haClose;
pos--;
}
//----
return(0);
}
//+------------------------------------------------------------------+
سلام من برگشتم.
خب بعد از این وقفه طولانی تصمیم گرفتم دوباره تا جایی که میتونم روی پروژه کار کنم. البته این رو بگم که باز هم بودنم در پروژه قطعی نیست و ممکنه به خاطر مشکلات شخصی زیادی که دارم پروژه رو رها کنم.همینجا از دوستان و اساتید دیگه هم دعوت میکنم که اگه در پروژه مشارکت کنند.بگذریم...
یک تغییر کوچیک مد نظرم هست و اون اینه که به خاطر جلوگیری از بعضی سوء استفاده های احتمالی تا زمان تکمیل شدن کامل پروژه کدهای اصلی فازها فقط در اختیار اعضای گروه قرار میگیره. البته بحث و تحلیل کدها و الگوریتم ها و مسائل دیگه به صورت عمومی انجام میشه.
یک سوالی هم برام پیش اومده .در مورد استفاده از اسمبلر FASM که ما اینقدر برای تکمیل پروژه روش حساب کردیم آیا مشکلی از لحاظ قانونی و کپی رایت نداره.
...سلام!
فکر می کنم مشکلی نباشه، این جا رو ببینید: www.bttr-software.de/forum/forum_entry.php?id=8727
خب پس مثل اینکه مشکلی از این بابت نیست.
میرسیم به ساخت EBNF زبان برای پیاده سازی تحلیلگر نحوی.
فکر می کنم قبلا یه کدی برای تحلیلگر لغوی نوشته بودین...
خوب برای ساختار EBNF یه ساحتار کلی پیشنهاد بدید، روش کار کنیم، یه سری چیزهای اصولی هم که در اکثر ساختار ها مشترکه،...
بله تحلیلگر لغوی تقریبآ کامله. در مورد ساختار نحوی هم که قبلآ در موردش بحث کردیم:نوشته شده توسط IamOverlord
https://barnamenevis.org/showthread.p...=1#post1428198
و برای ساختار حلقه:
https://barnamenevis.org/showthread.p...=1#post1428655
فقط الان که دارم دقت میکنم با توجه به ساختار حلقه باید کلمه Check رو هم به کلمات کلیدی در تحلیلگر لغوی اضافه بشه که چیز مهمی نیست. الان باید با توجه به ساختاری که با مثال ایجاد کردیم EBNF رو بسازیم ولی باید دقت کنیم که گرامرها نباید ابهام یا بازگشتی چپ داشته باشند.
چون تا حالا یه گرامر درست و حسابی ننوشتم، اول یه نگاهی بندازیم به بقیه ی گرامر ها و روی اون ها کار کنیم و بعد گرامر خودمون رو بنویسیم...
این هم یه نمونه ی خوب: rosettacode.org/wiki/BNF_Grammar
سلام بر دوستان.
من همه پست های این تاپیک رو بررسی نکردم ولی تعداد زیادی از اون ها رو خوندم...
به دلیل علاقه ای که به طراحی کامپایلر ( و به شکل خاص تر parse کردن یک متن در نرم افزار خودم ) داشتم با کامپایلر و الگوریتم های طراحی اون آشنایی زیادی دارم...
دوستان... فراموش نکنید که تقریبا در اکثر کامپایلرهای دنیا (یا به عبارتی همه کامپایلرها) دو بخش اول یعنی تحلیلگر لغوی و تحلیلگر نحوی به هیچ عنوان دستی انجام نمی شه... یعنی برای نوشتن تحلیل گر لغوی و نحوی طراحان کامپایلر حتی شاید یک خط کد هم ننویسند... بلکه از ابزارهای آماده استفاده می کنند...
ابزارهای زیادی وجود داره...
به عنوان مثال برای طراحی تحلیلگر لغوی... وقتی زبان و واژگان زبان (توکن ها) رو طراحی کردیم... باید تحت یک فرمت مشخص این توکن ها رو به عنوان ورودی به ابزاری مثل LEX یا FLEX بدیم... خود این ابزار برای ما Scanner رو تولید می کنه و به ما یک کد و برنامه میده...
شما تصور کنید برای طراحی یک کامپایلر برای زبانی مثل C اگر بخوایم Scanner رو دستی طراحی کنیم چقدر کد وحشتناک می شه... DFD ما برای اسکنر مثلا شامل حدود 3000 state می شه... برای طراحی این states با جدول انتقال (Transition-Diagram) یا روش switch-case (دو روش طراحی scanner بدون ابزار) شاید نیاز بشه ماه ها وقت بزاریم... در نهایت هم احتمالا خطا و اشتباه به دلیل پیچیدگی وجود خواهد داشت و البته دو فاکتور مهم در مهندسی نرم افزار یعنی "وقت" و "هزینه" رو از دست میدیم... این رو میشه با ابزار در مدت زمان کوتاهی با دقت بسیار بالا انجام داد (اگر زبان و توکن ها طراحی شده باشه شاید کمتر از چند ساعت برای نوشتن و تولید scanner زمان نیاز باشه) و در عوض تمرکزمون رو روی بهینه سازی ها و تحلیل گر معنایی و سایر قسمت های مهم کامپایلر بزاریم...
برای طراحی parser یا تحلیل گر معنایی هم دقیقا همین طوره... دونستن مفاهیم پارسر مثل (SLR(1 یا گرامرهای (LL(1 یا (CLR(1 یا ... ضروری هست و باید بلد باشیم (چون به ما دید میده و گاهی اوقات حتی کمک هم میکنه) اما در عمل از هیچ کدوم از این ها استفاده نمی کنیم بلکه به عنوان مثال از ابزاری به نام YACC (مخفف Yet Another Compiler Compiler) استفاده می کنیم... ما به ابزار همه گرامر های زبان رو میدیم و ابزار به شکل اتوماتیک الگوریتم تحلیل پایین به بالا (LALR1) رو پیاده سازی می کنه و به ما مثلا کد C می ده.... در واقع تنها کاری که باید انجام بدیم طراحی همه گرامرهای زبان هست نه پیاده سازی parser مربوط به این گرامرها
فراموش نکنید طراحی تحلیل گر نحوی به شکل دستی کار بسیار دقیق و زمانبری هست و البته با وجود این ابزارهای خودکار و قدرتمند بیهوده... چون اگر صدها یا هزاران گرامر داشته باشیم باید برای تک تک گرامرها الگوریتمهای تحلیل نحوی (پایین به بالا یا بالا به پایین) مثلا (LALR(1 (یکی از قویترین الگوریتم های parser پایین به بالا) رو اعمال و پیاده سازی کنیم و چنین کاری با داشتن ابزار بیهوده است...
از این ابزارها و ابزارهای مشابه تقریبا همه شرکت های مشهور حتی طراحان جاوا یا مایکروسافت (برای طراحی کامپایلر) استفاده می کنند. بنابراین پیشنهاد می کنم از نرم افزارهای قدرتمند برای تولید حداقل این دو بخش از کامپایلر استفاده کنید...
موفق باشید...
آخرین ویرایش به وسیله emadfa : سه شنبه 20 تیر 1391 در 10:15 صبح
سلام دوست عزیز،
البته توجه داشته باشیم فعلا این پروژه جنبه ی یادگیری و سرگرمی داره، نه جنبه ی تجاری...
اما پیشنهاد خوبیه...
سلام دوست عزیز.
من تا حدودی با حرفتون موافقم یعنی اینکه استفاده از Yacc و bison میتونه به تولید تحلیلگر نحوی سرعت ببخشه. البته فکر میکنم در مورد تحلیلگر لغوی فرق چندانی نداره و ما توستیم اون رو به راحتی به صورت دستی بسازیم. با توجه به تعداد حالتهای لغات:
https://barnamenevis.org/showthread.p...=1#post1433481
همونطور که دوستمون گفتن چون ما هدفمون بیشتر جنبه یادگیری داره فکر میکنم بهتر باشه به شکل دستی ساخته بشه.بازم ممنون از نظرتون. ازتون دعوت میکنم اگر مایل بودید در پروژه با ما همکاری کنید.
دو تا لینک خوب برای آشنایی بهتر با EBNF و گرامرها:
http://c.comsci.us/syntax/expression/ebnf.html
http://cs.lmu.edu/~ray/notes/syntax/
یه مشکلی در طراحی EBNF وجود داره.این گرامر رو نگاه کنید:
<program>::=<uses><imports><define><main><function s>
<Uses>::={<Use>{NEWLINE}+}*
<Use>::= <USE_KEY><STRING>
اینجا ما تو خط اول نحو کلی یک برنامه به زبانمون رو بیان کردیم. همونطور که میبینید برناممون با تعریف Use ها شروع میشه ( کتابخانه ها) . بعدش import ها رو داریم و همینطور تا آخر. ولی مشکل از خط دوم شروع میشه. ببینید ما متآسفانه از کاراکتر خط جدید به عنوان کاراکتر هماهنگ کننده ( جدا کننده دستورات ) استفاده کردیم. یعنی بین هر دستور مستقل باید یک یا چند کاراکتر خط جدید وجود داشته باشه (علامت "+" بعد از Newline به همین معنی هست ) . مشکل اینجاست که ممکنه مثلآ برنامه نویس بخواد یه برنامه که فقط از یک دستور فراخوانی کتابخانه (USE) تشکیل شده رو بنویسه و بعد از این دستور هم قاعدتآ نیازی به درج خط جدید نیست. این درحالیه که با توجه به این گرامر , تحلیلگر نحویمون از این برنامه ایراد میگیره.
خوب ببینید می شه از | استفاده کنیم، یعنی اون حالت رو هم داخل خط اول گرامر در نظر بگیریم.
use فقط include می کنه؟ اگه آره، پس بهتره کاری کنیم که use رو بشه در هر قسمتی از کد استفاده کنیم.
ضمنا در این صورت قبل این که این مراحل تحلیل شروع بشه، بهتر نیست که دنبال عبارت های use بگردیم و محتوای فایل مورد نظر رو جایگزین use کنیم؟ یه replace ساده...
لطفآ اگه امکانش هست گرامرش رو بنویس. اینطوری نمیشه متوجه شد.
به نظرت منطقی تر نیست که کتابخانه ها در ابتدای برنامه معرفی بشن؟
در این مورد باید بعدآ بیشتر تحقیق کنیم. چون این رفتار در مورد ماکروها اتفاق می افته. ولی از این مطمئنم که تا قبل از تحلیل برنامه اصلی نباید در کدهای نوشته شده توسط برنامه نویس دست برد چون ممکنه مثلآ دستور use نوشته شده از نظر نحوی اشباه باشه. از من میپرسی میگم که این کارها باید در مرحله تولید کد میانی انجام بشه.ضمنا در این صورت قبل این که این مراحل تحلیل شروع بشه، بهتر نیست که دنبال عبارت های use بگردیم و محتوای فایل مورد نظر رو جایگزین use کنیم؟ یه replace ساده...
تا جایی که فهمیدم این دستور use اگه فقط به معنای جایگزینی محتوای فایل باشه، کار قسمت preprocessor هست اصولا... از اون جایی که دستوری مثل if هم در قسمت preprocessor داریم فکر می کنم جرف شما درست باشه، چون این ها هم مثل بقیه ی قسمت های کد نیاز به تحلیل دارند...
اما اگه مثل زبان c مکان زیربرنامه ها نسبت به هم مهمه، فکر می کنم بهتره قابلیت نوشتن use در جاهای مختلف رو بذاریم، چون مثلا ممکنه شما در فایل کتابخانه تون یه زیربرنامه ی B داشته باشید که از زیربرنامه ی A استفاده می کنه و می خواید زیربرنامه ی A رو بعدا در بیرون از فایل کتابخانه تون قبل از دستور use تعریف کنید، یه کارهای دیگه ای مثل استفاده از use لا به لای import ها که در این حالت در فایل کتابخانه مثلا تعدای import پرکاربرد نوشته شده یا ...
به نظرم یه مقدار باید آزادی عمل بدیم.
من هستم. ولی من نمی دونم چجوری می خوای این کار رو بکنی.به نظر من با زبان C# این کار رو بکنیم بهتره. من که نمی دونم چجوری بسازیم.خیلی سخته. باید اول برای هر کدی که می خوای یه متغیر تعریف کنی و کد خودتو در اون متغیر قرار بدید. ولی همین که به برنامه بفهمونی که این کد چکار می کنه خودش خیلی سخته.
قبل از هر چیز یه توضیح در مورد مسآله اول که عنوان کردی بدم. یک فایل کتابخانه میتونه شامل هزاران خط کد باشه ( و شاید هزاران تابع ) که برنامه نویس نیازی به همه اونها نداره. پس این که بخوایم به ازای هر معرفی کتابخانه , کل کتابخانه رو در کدها جایگزین کنیم یک کار بیهوده هست و باعث پایین آمدن شدید سرعت کامپایل میشه. کاری که باید انجام بشه اینه که برای هر فراخوانی تابع اول باید در توابع تعریف شده در خود برنامه به دنبال اون تابع بگردیم.اگر پیدا نشد در کتابخوانه های معرفی شده به دنبال آن تابع میگردیم. واگر باز هم پیدا نشد باید خطای تابع تعریف نشده رو صادر کنیم.که این اینکارها همگی مربوط به فازهای تحلیلگر معنایی و تولید کد میانی هست. پس بهتره فعلآ بهش فکر نکنیم.
اما اینکه use ها فقط در ابتدای برنامه به کار برده شوند یا در هر جای برنامه ,مربوط میشه به تحلیلگر نحوی و باید همین جا مشخص بشه. راستش با مثالی که زدی من هنوز نتونستم لزوم این که کتابخانه ها در هر جا تعریف بشند رو درک کنم. ببین کتابخونه ها یک فایل مستقل هستند. یعنی هیچ وابستگی به برنامه ای که قراره نوشته بشه ندارند. اگر هم قراره از یک تابع خارجی استفاده کنند , اون تابع در یک کتابخونه دیگه قرار میگیره و در کتابخونه مورد نظر معرفی میشه. دقیقآ مثل کاری که در مورد Include ها انجام میشه. اگر باز هم دلیل قانع کننده ای برای نظرت داشتی در میان بزار.تا در این مورد تصمیم گیری کنیم.
ضمنآ یک نکته هم خدمت دوستانی که فکر میکنند کار ایجاد ساختار لغوی و نحوی یک زبان جدید آسان هست و نیاز به صرف زمان چندانی نداره عرض میکنم. ببینید شما یک کتاب آموزش زبان برنامه نویسی رو در نظر بگیرید. چنین کتابی میتونه حجمی برابر 100 تا 1000 صفحه داشته که قطعآ حداقل 50 درصد اون صرف توضیح ساختار لغوی و نحوی زبان میشه . این در حالیه که تولید ساختار لغوی و نحوی یک زبان جدید به عوامل دیگه ای مثل خلاقیت و در نظر گرفتن موانع پیاده سازی نیازمند هست. شاید جالب باشه بدونید که فقط ابداع ساختار یک زبان جدید که جالب و قابل پیاده سازی باشه هم در علوم کامپیوتر میتونه ارزشمند باشه. و طراحی کامپایلر میتونه ارزش زبان رو به شکل ملموس تری نشون بده.
آخرین ویرایش به وسیله amin32 : پنج شنبه 22 تیر 1391 در 09:34 صبح
به نظرم فعلآ بهتره به قدرت و انعطاف زبان فکر نکنیم. هر تغییری رو میشه بعدن بهش اضافه کرد. الان باید روی پیاده سازی و مشکلاتی که ممکنه پیش بیاد فکر کنیم. وگرنه اگه بخوایم فقط همینطور روی گسترش زبان فرضیمون کار کنیم به جایی نخواهیم رسید. به نظرم حتی اگه ساده کردن و حذف بعضی قابلیتها میتونه به پیاده سازی کمک کنه, باید اینکار رو انجام بدیم.
با توجه به مشغله زیاد خودم باز هم از دوستان دیگه که در زمینه کامپایلر , پارسرها و مباحث مرتبط ( به هر زبانی ) کار کردن دعوت میکنم در پروژه مشارکت کنند.
آخرین ویرایش به وسیله amin32 : پنج شنبه 29 تیر 1391 در 19:37 عصر
سلام...
یه مدتیه سرم شلوغه، ولی همچنان سعیم رو می کنم...
خوب، اون گرامری رو که نوشتین این طوری تغییر دادم:
<program>::=<sec_uses_imports><sec_defines>
<sec_defines>::={<define>}
<define>::=<def_global_variables>|<def_procedure_m ain>|<def_procedure>|<def_function>|<def_structure >|<def_class>
<sec_uses_imports>::={<use_import>}
<use_import>::=<use>|<import>
<use>::=<use_key><file_address>|<use_key><quoted_f ile_address>
<use_key>::=
<import>::=
البته چون من زیاد وارد نیستم تو زمینه ی نوشتن گرامر، لطفا دوستان همکاری کنند، درستش کنیم.
سلام...
یه مدتیه سرم شلوغه، ولی همچنان سعیم رو می کنم...
خوب، اون گرامری رو که نوشتین این طوری تغییر دادم:
<program>::=<sec_uses_imports><sec_defines>
<sec_defines>::={<define>}
<define>::=<def_global_variables>|<def_procedure_m ain>|<def_procedure>|<def_function>|<def_structure >|<def_class>
<sec_uses_imports>::={<use_import>}
<use_import>::=<use>|<import>
<use>::=<use_key><file_address>|<use_key><quoted_f ile_address>
<use_key>::=
<import>::=
البته چون من زیاد وارد نیستم تو زمینه ی نوشتن گرامر، لطفا دوستان همکاری کنند، درستش کنیم.
ببین با توجه به این صفحه:
قسمت define فقط متغیرهای عمومی رو در بر میگیره و توابع و روالها رو شامل نمیشه !
این گرامر داره یک زبان کاملآ متفاوت رو تعریف میکنه!
یک پیشنهادی که بهت میکنم اینه که فعلآ به هیچ وجه قابلیت جدیدی رو به زبان اضافه نکنی.( مثل def_class) . به نظر من پیاده سازی یک زبان خیلی خیلی ساده هم میتونه مشکلات خودش رو داشته باشه. بیخود نیست که تعداد کامپایلرها تقریبآ کم هست و هنوز در بعضی از موارد کمبودهایی وجود داره. پس بهتره فعلآ روی همین قابلیتها کار کنیم.
لازم دیدم کمی در مورد تحلیلگر نحوی و عمکردش توضیح بدم. ببینید ما تا اینجای کار تحلیلگر لغوی رو نوشتیم. کار تحلیلگر لغوی این بود که نوع هر کلمه به کار رفته در کد برنامه رو تشخیص بده و به ازای هر لغت, نوعش رو که به اون توکن گفته میشه رو برای فاز بعدی بفرسته. در پایان این فاز ما علاوه بر کد اصلی برنامه , یک سری توکن رو داریم که نشون میده برنامه نویس انواع مختلف لغات ( عدد صحیح , رشته , کلمه کلیدی , عملگرها و.... ) رو با چه ترتیبی در کنار هم قرار داده که بهش ساختار نحوی برنامه گفته میشه . از طرفی ما به عنوان طراح کامپایلر باید بررسی کنم که این ساختار نحوی از ساختار نحوی زبان ما تبعیت میکنه یا خیر. اینجاست که بحث گرامرها( در اینجا EBNF) مطرح میشه. ما با استفاده از گرامرها و قابلیتهای اون در واقع ساختار نحوی زبان رو توصیف میکنیم. تا با پیاده سازی اون بتونیم این ساختار رو با ساختار کد نوشته شده برنامه نویس مقایسه کنیم و در صورت عدم تطبیق به کاربر هشدار لازم رو بدیم.
همونطور که در اینجا توضیح دادم :
https://barnamenevis.org/showthread.p...=1#post1545873
مشکل ما این هست که از کاراکتر خط جدید به عنوان هماهنگ کننده استفاده کردیم. و این یکم پیاده سازی گرامر رو مشکل کرده. فکر میکنم اگه مثل زبان C ( که از ';' استفاده کرد) و خیلی زبانهای دیگه , ما هم از یک کاراکتر خاص استفاده کنیم , احتمالآ باید این مشکل رفع بشه. البته با همین کاراکتر خط جدید هم غیر ممکن نیست ولی یکمی پیچیده میشه.
یعنی حداقل 1 کاراکتر خط جدید باید در هر کدی وجود داشته باشه؟ در این صورت به نظر من باید قبل از این که کد رو تحویل بدیم، خودمون یه سری ویرایش های جزئی روش بکنیم؛ مثلا به آخر هر کدی یه کاراکتر خط جدید اضافه کنیم...ولی مشکل از خط دوم شروع میشه. ببینید ما متآسفانه از کاراکتر خط جدید به عنوان کاراکتر هماهنگ کننده ( جدا کننده دستورات ) استفاده کردیم. یعنی بین هر دستور مستقل باید یک یا چند کاراکتر خط جدید وجود داشته باشه (علامت "+" بعد از Newline به همین معنی هست ) . مشکل اینجاست که ممکنه مثلآ برنامه نویس بخواد یه برنامه که فقط از یک دستور فراخوانی کتابخانه (USE) تشکیل شده رو بنویسه و بعد از این دستور هم قاعدتآ نیازی به درج خط جدید نیست. این درحالیه که با توجه به این گرامر , تحلیلگر نحویمون از این برنامه ایراد میگیره.
گرامر BASIC رو تو همون لینکی که گذاشتم نگاه کردم:
<Lines> ::= Integer <Statements> NewLine <Lines>
| Integer <Statements> NewLine
Integer رو که بی خیال، اما بقیش همون مشکلی که ما داریم رو داره، احتمالا اون ها هم یه ویرایش هایی قبل از تحلیل ها انجام می دن... البته برای حل مشکل ببینید این جواب می ده؟:
<Lines> ::= <Statements> NewLine <Lines>
| <LastLineOfCode>
<LastLineOfCode>::= <Statements> NewLine
| <Statements>
نه منظورم این نبود که فقط یک کاراکتر خط جدید داشته باشیم. منظورم اینه که کلآ کاراکتر هماهنگ کننده رو تغییر بدیم و یک کاراکتر خاص انتخاب کنیم. در ضمن اینو هم در نظر بگیر که اگه قرار باشه ما به جای برنامه نویس برای هر کد یک کاراکتر خط جدید اضافه کنیم , ممکنه کاربر به اشتباه دو تا دستور رو بدون خط جدید وارد کنه که در اون صورت تشخیصش برای ما خیلی مشکل میشه و پیاده سازی چنین چیزی میتونه خیلی کار رو پیچیده تر کنه.
اون گرامر بالا در مورد چند تا New Line بین 2 خط کد مشکل داره... فکر می کنم این بهتر باشه:
<NL> ::= NewLine <NL>
| NewLine
<Lines> ::= <Statements> <NL> <Lines>
| <LastLineOfCode>
<LastLineOfCode> ::= <Statements> <NL>
| <Statements>
من باز هم پیشنهاد میکنم از یک کاراکتر هماهنگ کننده دیگه استفاده کنیم . یا اصلآ مثل HTML دستورات رو داخل تگها قرار بدیم. در هر دو صورت به راحتی میتونیم مشکل خط جدید رو حل کنیم و فقط کافیه در گرامر بعد از هر دستور به تعداد صفر تا بینهایت خط جدید رو در نظر بگیریم.
ببینید با اون تعریف NL که در آخرین کد گذاشتم اون مشکل تعداد کاراکتر های خط جدید بین دو خط حله... من زیاد با ;... راحت نیستم! پیشنهاد می کنم همین مشکل رو با توجه به گرامر هایی که بقیه نوشتن حل کنیم...
OK !
با اینکه فکر میکنم استفاده از کاراکتر هماهنگ کننده , ساخت گرامر و پیاده سازی تحلیلگر رو به شدت سادهتر میکنه ولی با راهکارت موافقم.
یک فکر خوب به ذهنم زد:
<program>::=<uses><imports><define><main><function s>
<Uses>::={<Use>}*
<Use>::= <USE_KEY><STRING><Coordinator>
<Coordinator>::={NEWLINE}+|{NEWLINE}* <EOF_key>
مشکل رو با لغت پایان فایل (EOF) حل کردم. Coordinator به عنوان هماهنگ کننده تعریف شده که میتونه " یک یا بیشتر خط جدید باشه" یا میتونه "صفر یا چند خط جدید و یک کاراکتر پایان فایل" باشه. مورد اول برای دستورات میانی هست و مورد دوم برای دستور پایانی که میتونه خط جدید داشته باشه یا نداشته باشه. با این حساب فکر میکنم این مشکل حل شده باشه. فقط باید در تحلیلگر لغوی لغت EOF رو هم به کلمات کلیدی اضافه کنیم.
!===================
! CHARACTER SETS
!===================
{String Char} = {All Valid} - ["]
{ID Tail} = {Alphanumeric} + [_]
!=============
! LITERALS
!=============
StringLiteral = '"' ( {String Char} | '""' )* '"'
ID = {Letter} {ID Tail}*
!==========
! RULES
!==========
<program> ::= <NLOpt> <GlobalStmtList>
<GlobalStmtList> ::= <GlobalStmt> <GlobalStmtList>
|
<GlobalStmt> ::= <UseStmt>
| <ImportStmt>
| <DefineBlock>
| <ProcdureDecl>
| <FunctionDecl>
<UseStmt> ::= 'Use' StringLiteral <NL>
<NL> ::= {NewLine}+|{NewLine}* <EOF_key>
<NLOpt> ::= <NL>
|
<ProcedureDecl> ::= 'Procedure' ID <MethodArgList> <NL> <MethodStmtList> 'End' 'Procedure' <NL>
<FunctionDecl> ::= 'Function' ID <MethodArgList> <Type> <NL> <MethodStmtList> 'End' 'Function' <NL>
دوستان با توجه به مشغله خیلی خیلی زیادی که دارم فکر میکنم دیگه نتونم برای این پروژه وقت بزارم. دوستانی که مایل هستند میتونند پروژه رو ادامه بدند.
راستش منم می خوام ide (ساخت بازی و برنامه برای موبایل)درست کنم که با زبان بیسیک فارسی باشه و کدها رو تبدیل به جاوا کنه بعد با ماشین جاوا برنامه ساخته شده رو اجرا کنه .
دوستان کمکم کنید .
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول