پس از مدتی دست کشیدن از بلاگ نوشتن، به دنیای نویسندگی فنی برگشتم و قراره که امروز با هم یاد بگیریم چطور یک Rest API رو با روبی آن ریلز بسازیم. چرا روبی آن ریلز؟ دو تا دلیل داره. یکی این که چون من بلدمش و دلیل دوم این که منبع فارسی خوب براش به شدت کمه (کما این که برنامه‌نویس خوب ریلز کم نداریم در ایران).

در این پست قراره چیا یاد بگیریم؟ اول این که Rest چیه. بعدش با ریلز یه پروژه جدید ایجاد می‌کنیم، بعدش هم یک سناریوی ریزی که در این قسمت تا بخش خوبیش رو پیش می‌بریم. در قسمت بعدی هم پروژه رو تموم می‌کنیم و میریم که داشته باشیم فرانتند رو 🙂

تعریف Rest

واژه REST مخفف Representational State Transfer و به معنای «انتقال بازنمودی حالت» است. یعنی چی؟ یعنی ساده‌ و مختصر و مفیدش اینه که شما هرچی که دارید رو بدون تغییر در حالاتش، به کاربر منتقل می‌کنید. یک تعریف بهترش هم اینه که همه چی به شکل یک لینک اینترنتی و خروجی قابل فهم برای مرورگر (و البته بهتر بگم، پروتکل HTTP) دربیاد.

رست، مزایای خاص خودش هم داره. اما بزرگترین مزیتش اینه که همه‌جا یکیه! یعنی اینطوری نیست که روی وبسایت من یه شکل باشه و روی یک وبسایت دیگه یه شکل دیگه. همه‌جا میتونید با دانشی که از HTTP و ابزارهایی که برای ارسال و دریافت درخواست HTTP دارید، باهاش کار کنید. ابزاری که در این پست باهاش کار می‌کنیم چیزی نیست جز curl دوست داشتنی. یک ابزار خط‌فرمانی در یونیکس که سالیان ساله برای هر بده بستانی با HTTP داره استفاده میشه.

نصب و راه‌اندازی روبی، ریلز و نود جی اس!

نصب کردن این موارد حقیقتا چیزی نیست که بخوام در این مطلب بهشون اشاره کنم، فقط یک سرنخ کوتاه میدم و شما خودتون دنبالش کنید.

همونطور که از اسم فرمورک مورد نظر پیداست، یک چارچوب توسعه روی زبان روبی محسوب میشه. حالا چطوری روبی رو نصب کنیم؟ یک راه نسبتا بدی هست که از مخازن توزیع یا brew نصب کنیم، یک راه بهتر هم استفاده از RVM میتونه باشه. شخصا همیشه از RVM استفاده می‌کنم، و راضی هم هستم. چون بهتون اجازه میده که چندین و چند نسخه روبی نصب داشته باشید.

برای نصب RVM از وبسایتش (لینک) استفاده کنید. این ابزار روی لینوکس و مک به راحتی نصب میشه. برای نصب روی ویندوز هم من از همین ابزار به کمک WSL استفاده کرده بودم و نتیجه، رضایت بخش بود. بعد از نصب این بزرگوار مطابق راهنماهاش، یک نسخه روبی (پیشنهاد من ۲.۷.۲ که این مطلب با استناد به استانداردهاش نوشته شده) نصب کنید. بعد از نصب روبی، این دو دستور رو اجرا کنید که ریلز و متعلقات نصب بشن:

gem install bundle
gem install rails

نصب ریلز یکمی طولانیه. میتونید این زمان رو صرف نوشیدن یک فنجان قهوه کنید 🙂 این طولانی بودن هم ربط زیادی به اینترنت نداره، چون روی بسته‌های خاصی مثل sass یکم درجا میزنه چون نیاز داره یه چیزایی رو کامپایل کنه.

بعد از این، شما با مراجعه به وبسایت نود جی اس (لینک) و yarn (لینک) میتونید این‌ها رو هم متناسب با سیستم‌عامل خودتون نصب کنید. حالا همه چی آماده‌ست که پروژه‌مون رو بزنیم 🙂

آغاز پروژه

سناریو

خب بیاید فرض کنیم که یک شرکتی قراره یه سرویس وبلاگ‌دهی مشابه مدیوم یا ویرگول ارائه کنه. در حال حاضر هیچی ازمون نخواسته جز :

• امکان ارسال پست از طریق API
• امکان ارسال نظر روی پست از طریق API

و خب در حال حاضر احراز هویت و … براشون مهم نیست چون میخوان ببینن که MVP کار می‌کنه یا نه؟! و ما هم از خداخواسته قبول کردیم این رو براشون پیاده کنیم. اما این همه ماجرا نیست. این دو مورد، باید یک سری ویژگی هم داشته باشن. این ویژگی‌ها رو طراح محصول باید درآورده باشه. فرض کنیم که طراح محصول اینا رو درآورده و فعلا برای «پست» به ما یک سری ویژگی داده :

• عنوان یا title : یک رشته کرکتری
• عنوان کوتاه یا slug : یک رشته کرکتری که با – از هم جدا میشه، یک رشته رندم هم تهش می‌چسبه که منحصر به فرد بودنش رو تعیین کنه (چسبیدن رشته رندم رو از فرانت هندل کنید)
• بدنه یا body : متن اصلی.

خب، با این ویژگی‌ها از ما میخوان که پست رو پیاده کنیم تا ویژگی‌های کامنت رو بهمون بدن 🙂

ساخت پروژه جدید

ساخت پروژه جدید در ریلز بسیار ساده‌ست. شما فقط کافیه که در پوشه‌ای (مثلا من روی کامپیوتر یه پوشه دارم به اسم playground که پروژه‌های شخصیم توشن) که میخواید پروژه اونجا باشه، این دستور رو اجرا کنید:

rails new api-tutorial --api

اینجا چی کار می‌کنیم؟ rails که مشخصه، داره rails رو فراخوانی می‌کنه. new میگه یک پروژه جدید میخوام. قسمت بعدی، اسم پروژه و طبیعتا اسم پوشه پروژه‌ست. در نهایت بخش مهم همون api عه. این داره به ریلز میگه که view‌ها و کلا مسخره‌بازیای فرانتی رو بعدا و جدا انجام میدم. فعلا مسخره‌بازی بکندی میخوام فقط 😁

حالا با اجرای دستور زیر، میریم به داخل پوشه پروژه‌مون:

cd api-tutorial

ساخت مدل جدید برای پست

همونطور که از مطلب MVC (لینک) می‌دونیم، مدل تعیین می‌کنه که یک موجودیت در دیتابیس به چه شکل قرار بگیره. خب، الان کاری که ما باید بکنیم چیه؟ اینه که دستور زیر رو اجرا کنیم و بگیم که چی میخوایم:

rails generate model Post title:string slug:string body:text

خب، در اینجا دقیقا همون چیزی که طراح محصول خواسته رو داریم پیاده‌سازی می‌کنیم. خب، الان در پوشه:

app/models

یک فایل به اسم post.rb ساخته شده که توش تقریبا هیچی نیست. و فعلا به اون فایل، کاری نداریم (تو قسمت دوم در مورد این فایل صحبت خواهیم کرد).

الان فقط لازمه که به دیتابیس بفهمونیم که ما یک جدول جدید برای پست‌ها نیاز داریم. برای اون کار، دستور زیر رو اجرا می‌کنیم:

rails db:migrate

این کار برای ما جدول و روابطش رو میسازه.

ساخت کنترلر برای پست

خب، ما نیاز داریم که عملیات CRUD روی پست انجام بدیم. چرا؟

• هر پست نیاز داره ایجاد بشه. پستی که ایجاد نشه پستیه که قطعا ایجاد نشده 😐
• هر پست نیازمند اینه که به کاربر نمایش داده شه. قرار نیست مخزن‌الاسرار بسازیم که!
• هر پست نیاز داره که ویرایش بشه. فرض کنید یه جا تو پست نوشتیم «خورش کرفس بهترین غذای دنیاست». خب معلومه که باید «خورش کرفس» رو به «قرمه سبزی» تغییر بدیم.
• و هر پست باید قابل حذف شدن باشه. در مورد حذف نرم و سخت بعدا صحبت خواهیم کرد. اما فرض رو روی destroy یا همون «حذف سخت» میذاریم. چون طراح محصول هنوز اطلاعات بیشتری بهمون نداده.

خب، الان که این رو یاد گرفتیم چی کار می‌کنیم؟ این دستور رو اجرا می‌کنیم:

rails generate controller api/v1/post index show create update destroy

بعدش فایل :

app/controllers/api/v1/post_controller.rb

رو باز کنید. با چنین صحنه‌ای روبرو خواهید شد:

class Api::V1::PostController < ApplicationController
  def index
  end

  def show
  end

  def create
  end

  def update
  end

  def destroy
  end
end

خب اول از new شروع می‌کنیم! از حرف C ! اما قبلش باید یک تغییر کوچکی در این فایل بدیم :

class Api::V1::PostController < ApplicationController
  def index
  end

  def show
  end

  def new
  end

  def update
  end

  def destroy
  end

  private
  def post_params 
    params.require(:post).permit(:title, :slug, :body)
  end
end

متد post_params چی کار می‌کنه؟ این متد میاد فقط مواردی که نیازن رو validate می‌کنه و نمیذاره پارامتر بیشتر و یا اشتباهی به endpoint مربوطه پاس بدیم. خب، الان متد new رو به این شکل تغییر می‌دیم:

def new
  @post = Post.new(post_params)
  if @post.save 
    render json: {:status => "success", :content => @post}
  else 
    render error: {:status => "fail"}
  end 
end

خب یک مزیت دیگر استفاده از post_params هم همینه، بدون دردسر میتونیم همه پارامترها رو پاس بدیم به متدهامون. حالا، بهتر اینه که این متد رو تست هم بکنیم نه؟ پس این دستور رو وارد می‌کنیم:

rails server

این دستور، سرور ریلز رو ران می‌کنه و به ما اجازه می‌ده که برنامه خودمون رو آزمایش کنیم.

اما الان بهمون ارور میده. پس چی کار کنیم؟ هیچی. این فایل :

config/routes.rb

رو باز می‌کنیم و به این شکل درش میاریم:

Rails.application.routes.draw do
  namespace :api do
    namespace :v1 do
     resources :post
    end
  end
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
end

و حالا دوباره تست می‌کنیم. چطوری؟ به این شکل:

curl -X POST -H 'Content-Type: application/json' -i http://localhost:3000/api/v1/post --data '{
"title":"Hello, World",
"slug":"hello-world-abcd1234",
"body":"Hello, world! this is a simple test for my app"
}'

و خروجی‌ای که میده به این شکله:

{
  "status": "success",
  "content": {
    "id": 1,
    "title": "Hello, World",
    "slug": "hello-world-abcd1234",
    "body": "Hello, world! this is a simple test for my app",
    "created_at": "2021-03-28T17:44:16.608Z",
    "updated_at": "2021-03-28T17:44:16.608Z"
  }
}

حالا وقتشه که بریم سراغ R یعنی Retrieve/Restore. یعنی نمایش پست‌ها و پست به صورت تکی. کافیه index و show رو یکم دستخوش تغییر کنیم:

def index
  @posts = Post.all 
  render json: @posts 
end

def show
  @post = Post.find(params[:id])
  render json: @post 
end

و الان با ارسال چنین دستوری:

curl -X GET -i http://localhost:3000/api/v1/post/1

میتونیم پست‌هامون رو ببینیم.

حالا بیایم برای ویرایش هم چاره‌ای بی‌اندیشیم 🙂 پس متد آپدیت هم به این شکل به‌روز می‌کنیم:

def update
  @post = Post.find(params[:id]) 
  if @post 
    @post.update(post_params)
  end 
end

خب، اینجا چرا else نگذاشتم؟ چون اگر پست موجود نباشه (موجودیتش با if چک میشه) خود ریلز به ما ارور مناسب (معمولا ۴۰۴) رو نشون میده.

من در سیستم خودم، یک پست با آیدی ۲ دارم که قرار بود آپدیت بشه. الان اون رو با این دستور آپدیت می‌کنم:

curl -X PUT -H 'Content-Type: application/json' -i http://localhost:3000/api/v1/post/2 --data '{
"body":"updated"
}'

حواستون باشه که در چنین موردی، ممکنه به شما استتوس ۲۰۴ داده بشه. نترسید چون آپدیت انجام شده.

و در نهایت، بیاید یک پست حذف کنیم 🙂

برای حذف پست، کافیه که شما متد destroy رو به این شکل دربیارید :

def destroy
  @post = Post.find(params[:id])
  if @post 
    @post.destroy 
    render json: {:status => "success", :post_id => @post.id }
  end 
end

در این متد ما گفتیم که پست رو پیدا کن و نابودش کن. تهش هم گفتیم که انجام شد و یک پیام موفقیت هم به کاربر برگردوندیم.

این هم درخواست مربوطه:

curl -X DELETE -i http://localhost:3000/api/v1/post/3

و این هم جوابی که سرور به ما برمی‌گردونه:

{
  "status": "success",
  "post_id": 3
}

خب، در نهایت فایل post_controller.rb ما به این شکل در اومده:

class Api::V1::PostController < ApplicationController
  def index
    @posts = Post.all 
    render json: @posts 
  end

  def show
    @post = Post.find(params[:id])
    render json: @post 
  end

  def create
    @post = Post.new(post_params)
    if @post.save 
      render json: {:status => "success", :content => @post}
    else 
      render error: {:status => "fail"}
    end 
  end

  def update
    @post = Post.find(params[:id]) 
    if @post 
      @post.update(post_params)
    end 
  end

  def destroy
    @post = Post.find(params[:id])
    if @post 
      @post.destroy 
      render json: {:status => "success", :post_id => @post.id }
    end 
  end

  private
  def post_params 
    params.require(:post).permit(:title, :slug, :body)
  end
end

کل چیزی که در این قسمت نوشتم، برای درک عملکرد API کافیه. از شما هم میخوام که همین سناریو رو برای خودتون، یک دور به صورت کاملا دستی پیاده کنید و سعی کنید درش خلاقیت به خرج بدید. تجربیاتتون هم در بخش نظرات با من به اشتراک بذارید 🙂

قسمت بعدی، چی یاد می‌گیریم؟

در قسمت بعدی، کاری می‌کنیم کارستان. یاد می‌گیریم که در مدلها روابطشون رو تعیین کنیم. بعد مدلی می‌سازیم که به این مدل وابسته‌ست. در نهایت هم به همین شکل، کنترلرش رو می‌سازیم و پروژه رو تحویل کارفرمای عصبانی می‌دیم 🙂

از این که وقت گذاشتید و این پست رو خوندید، واقعا ممنونم. هر یک ویویی که این پست‌ها میخوره، برای من شدیدا ارزشمنده.

مدتی پیش، خواستم یک نمونه شخصی از ماستودون بسازم. موقع نصب، ارورهای عجیب و غریب دریافت کردم و خب شروع کردم به جست و جو پیرامون این که چرا اینطوریه و خیلی‌ها واضحا بیان کردند که «مشکل از تصویر داکر PostgresSQL بوده و باید روی اون تصویر کمی تغییر داده شه».

حقیقتا من از PGSQL استفاده نکردم و خیلی هم دلم نمیخواست وارد قضیه بشم و روی داکرفایل و داکر کامپوز و …، تغییر ایجاد کنم. به نظرم همون چیزی که خود توسعه‌دهنده پیشنهاد می‌کنه، معمولا بهترین حالتیه که داره با نرم‌افزار کار می‌کنه. اما یه ایده‌ای به سرم زد و اون هم این بود که چی میشه اگر پشتیبانی از MySQL رو به این بزرگوار اضافه کنم؟ نتیجه این شد که تصمیم گرفتم این مطلب رو بنویسم 😀

ماستودون چیه؟

ماستودون یک شبکه اجتماعی از نوع «فدریتد» (انگلیسی : Federated) محسوب میشه. به این شکل که وقتی شما روی سرور خودتون هم اون رو اجرا کنید، می‌تونید باقی سرورها رو ببینید و تعامل کنید.

مدتی میشه که خیلی از دوستانم، ماستودون رو بعنوان شبکه اجتماعی اصلی استفاده می‌کنند و خیلی کم‌تر به توییتر میان. شاید هم کلا توییتر نیان. یکی از دلایلش همینه که شما، صاحب داده‌های خودت هستی. این یک ایده خیلی خوبه که اگر واقعا حریم خصوصی و گردش اطلاعات براتون مهمه، به سمت ماستودون مهاجرت کنید.

نگاه به کد و چندکلمه‌ای صحبت پیرامون اون

خب از اینجا اصل ماجرا شروع میشه. کد ماستودون با فرمورک روبی آن ریلز (لینک) نوشته شده. این برای من خیلی خوشحال‌کننده بود چون خوندن و تغییر دادن اون کد رو آسون می‌کرد. اما این هم باید در نظر گرفت که کد، به شدت بزرگه و حتی برای حرفه‌ای‌های روبی آن ریلز هم خوندنش کمی دشواره. بهرحال می‌شه یکم حوصله به خرج داد و کد بزرگ رو درک کرد. این مشکل کد نیست. بلکه مشکل اون ساختار MVC محسوب میشه که بعد یه مدتی کد رو به شدت بزرگ می‌کنه و پیمایش و رفع اشکالش رو سخت.

در نگاه اول، کد واقعا ایراد خاصی (جز ایرادات مرسوم پروژه‌های مشابه) رو نداره. اما اولین ایراد جایی خودش رو نشون میده که شما چندین کتابخونه سیستمی اضافی نیاز دارید. برای من libicu و libidn و اینا بود. یکم جا خوردم که چرا باید این‌ها نصب باشه؟ اما با کمی تحقیق در موردش، فهمیدم که یک سری از کتابخونه‌های روبی هستند که وابسته به این بزرگوارهان. در واقع، هردوی این‌ها به شکلی برای پردازش متن استفاده شدند و خب این که پردازش متن، از طرف سیستم انجام بشه خیلی منطقیه. این موضوع فقط کمی باعث بزرگتر شدن پروژه شده. اما خوبی‌هاش، به شدت بیشتر از بدی‌هاشه.

مورد بعدی اروری بود که سر PGSQL گرفتم. خب حقیقتا انتظار این یکی رو داشتم. چون PGSQL و کتابخونه‌های سیستمیش، روی سیستم من نصب نیستند (البته شاید بعدها مجبور شم برای اشکال زدایی و کمک به همین ماستودون، نصبش کنم) و خب اروری که گرفتم دقیقا همین رو می‌گفت. وقتی مطمئن شدم که هیچ کتابخونه دیگری مشکلی نداره، دست به کار شدم که PGSQL رو با MySQL عوض کنم.

پروسه تغییر سیستم مدیریت پایگاه داده

خب معمولش اینه که اول، به پروژه می‌گیم کتابخونه‌های لازم رو نصب کنه. نیاز بود روی سیستم libmysqlclient-dev هم نصب کنم و کردم. بعدش در Gemfile، جم‌های مربوط به مدیریت MySQL رو اضافه کردم و جم‌های مربوط به PGSQL رو به دیدگاه تبدیل کردم و رفتم سراغ مراحل ساخت پروژه.

متاسفانه، اینجا کلی ارور گرفتم سر یک سری جم خاص! جم‌هایی که مرتبط با PGSQL هستند و شدیدا Hard Code شدن رو در کد منبع، شاهد بودیم.

قسمتیش رو دستی حذف کردم به امید این که کار کنه. اما موقع اجرای Migration ها، ارورهای جدیدی گرفتم. قسمت بزرگی از Migration ها رو چک کردم و دیدم که یه جاهایی حتی به صورت دستی دستورات PGSQL نوشته شده. حس می‌کردم که دیگه از اینجا جلوتر رفتن، یه جورایی مسخره کردن خودم باشه. حقیقتا بود، چون اصلا آشنا نبودم به این که اینجا چه اتفاقی داره می‌افته و خب بیخیال اضافه کردن پشتیبانی MySQL به این پروژه شدم.

جمع‌بندی

همونطوری که عرض کردم خدمت شما، بزرگترین اشکال این کد اینه که شدیدا وابسته به PGSQL عه. اگر اینقدر هاردکد نمی‌شد، شاید وضعیت طور دیگری بود و می‌شد پشتیبانی پایگاه‌های دیگر رو بهش اضافه کرد. متاسفانه در issue هایی که در پروژه بود هم دیدم که خیلی صریح پیشنهادات مرتبط با MySQL رو رد کردند و امیدم رو به طور کلی به این پروژه برای اضافه کردن این دیتابیس، از دست دادم.

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

مورد بعدی هم اینه که اگر نفر بعدی به هر دلیلی خواست با سیستم متفاوتی پروژه رو اجرا کنه، انقدر سختش نباشه. بهرحال، همه قرار نیست همه چیز رو اونطوری که من و شما دوست داریم، استفاده کنن.

چندین پست قبل، در مورد نوشتن یک زبان برنامه سازی ، مطلبی نوشته بودم. در این مطلب قصد داریم یکی از بخشهای مهم هر زبان یعنی Parser رو بررسی کنیم. اگر یک جست و جوی ساده در اینترنت انجام دهید، حتما خواهید دید که اکثر آموزشهای ساخت زبان برنامه سازی، عملیات parse کردن داده رو با parser generator های موجود مثل bison و … انجام دادن. اما چرا اون رو خودمون ننویسیم؟

برای نوشتن یک Parser ساده تنها نیاز داریم به این که از Regex ها استفاده کنیم. البته، چیزی که در این مطلب نوشته میشه به هیچ وجه شما رو برنامه نویس نمی‌کنه، فقط ممکنه راه رو برای برنامه نویس شدن شما باز کنه.

خب، بریم سر اصل مطلب. میشه گفت تقریبا همه با زبان Lisp و Scheme و سینتکسشون آشنا میشن. این زبان ها سینتکس های جالبی دارن و از همه مهم تر این سینتکس ها نسبتا راحته، و در همان نتایج جست و جو، شما هزاران آموزش پیاده سازی Lisp و Scheme خواهید دید. یک عملیات ساده در Lisp و Scheme به این شکله :

کد

(+ 1 2)

خب ساختار پرانتز مبنا، باعث میشه کار ما برای بازسازی عملیات های ساده در این زبان ها، بسیار بسیار ساده تر بشه. بیایم اول ببینیم که دیتا پارسر ما باید چه کنه؟

1. باید این خط از برنامه بهش داده بشه
2. باید اون رو تجزیه تحلیل کنه و انواع داده ای رو جدا کنه
3. عملگر رو تشخیص بده
4. عملیات رو انجام بده و خروجی مناسب رو بگردونه

خب، ما میخوایم نوع داده ایمون عدد باشه، حرف باشه، و بعد از اولین پرانتز، عملگر تعریف شه.

برای این کار، ابتدا دستورات زیر رو در نظر میگیریم :

کد

( + 1 2 )
( display 'Hello')

خب، الان باید یه تابع کوچولو بنویسیم که نوع داده ای رو بهمون نشون بده. این تابع رو من توی روبی مینویسم و به این شکل در میاد :

کد

def parse(str)
 str = str.split(' ')
 str[1] = str[1].to_sym
 for i in str
  if /[a-zA-Z]/ === i
   puts "#{i} is STRING"
  elsif /[0-9]/ === i
   puts "#{i} is NUMBER"
  elsif /[:a-z\+\-]/ === i
   puts "#{i} is OPERATOR"
  else
   puts "#{i} is not defined}
  end
end
end

ابتدا، تمام اعضای یک رشته که با فاصله از هم قرار گرفته اند را جدا کردیم (در واقع فاصله ای که در قطعه کد Scheme قرار داده شده، برای Parser ما مهم است) ، سپس با یک دستور شرطی نوع آن را بررسی کردیم. عضو شماره ۱ هر آرایه هم به یک Symbol تبدیل شده است (بعدها سمبل ها را بعنوان اوپراتور ها استفاده خواهیم نمود). بیاید این تابع را اجرا کنیم. آن هم با دو دستور داده شده.

نتیجه به این شکل خواهد بود :

همانگونه که شاهدید، پرانتز هارا نمیشناسد، display را هم به عنوان اوپراتور قبول ندارد، حال باید چه کرد؟ برای پرانتز ها باید دو شرط دیگر اضافه کنیم. پس برنامه ما به این شکل خواهد بود :

کد

def parse(str)
 str = str.split(' ')
 str[1] = str[1].to_sym
 for i in str
  if /[a-zA-Z]/ === i
   puts "#{i} is STRING"
  elsif /[0-9]/ === i
   puts "#{i} is NUMBER"
  elsif /:[a-z\+\-]/ === i
   puts "#{i} is OPERATOR"
  elsif /\(/ === i
   puts "#{i} is LPAREN"
  elsif /\)/ === i 
   puts "#{i} is RPAREN"
  else
   puts "#{i} is not defined
  end
end
end

خب، کد جدید را تست میکنیم وبا تست کد جدید، شما شاهد نتیجه درست خواهید بود.

در این مطلب قصد آن بود که شما ببینید چگونه میتوان فهمید که زبان Lisp ، بررسی میکند که یک داده از چه نوعی است. برای پردازش دستورات درون یک repl هم کافیست تا با یک حلقه بی نهایت، دستوری مشابه دستور زیر بنویسید :

کد

while true
 print "Lisp > "
 cmd = gets.chomp
 parse(cmd)
end

تبریک، شما یک دیتا پارسر نوشته اید. در مراحل بعدی، سعی میکنم تا توضیح دهم چگونه یک Lisp یا Scheme کوچک درست کنیم.