OMetaเป็นภาษาการเขียนโปรแกรมเชิงวัตถุ เฉพาะทาง สำหรับการจับคู่รูปแบบพัฒนาโดย Alessandro Warth และ Ian Piumarta ในปี 2007 ที่สถาบันวิจัย Viewpointsภาษาดังกล่าวมีพื้นฐานมาจากไวยากรณ์การแยกวิเคราะห์นิพจน์ (PEGs) แทนที่จะเป็นไวยากรณ์แบบไร้บริบทโดยมีจุดประสงค์เพื่อให้ "วิธีการที่เป็นธรรมชาติและสะดวกสำหรับโปรแกรมเมอร์ในการใช้งานตัวแยกโทเค็นตัวแยกวิเคราะห์ตัวเยี่ยมชมและตัวแปลงต้นไม้" ^{[ 1 ]}

เป้าหมายหลักของ OMeta คือการอนุญาตให้กลุ่มผู้ชมที่กว้างขึ้นสามารถใช้เทคนิคที่โดยทั่วไปมีให้เฉพาะโปรแกรมเมอร์ภาษาเท่านั้น เช่น การแยกวิเคราะห์^{[ 1 ]}นอกจากนี้ยังเป็นที่รู้จักในด้านการใช้ในการสร้างต้นแบบอย่างรวดเร็ว แม้ว่าโปรแกรมที่เขียนด้วย OMeta จะมีประสิทธิภาพโดยทั่วไปน้อยกว่าโปรแกรมที่เขียนด้วยภาษาพื้นฐานเช่นJavaScript ^{[ 2 ] [ 3 ]}

OMeta เป็นที่รู้จักในด้านการใช้งานในการสร้างภาษาเฉพาะโดเมนและโดยเฉพาะอย่างยิ่งในด้านการบำรุงรักษาการใช้งาน (Newcome) OMeta เช่นเดียวกับภาษาเมตา อื่นๆ ต้องการภาษาโฮสต์ โดยเดิมทีถูกสร้างขึ้นเป็นการใช้งาน COLA ^{[ 1 ]}

OMeta เป็นภาษาเมตาที่ใช้ในการสร้างต้นแบบและสร้างภาษาเฉพาะโดเมนมันถูกนำเสนอในฐานะ "ภาษาเชิงวัตถุสำหรับการจับคู่รูปแบบ" ^{[ 1 ]}มันใช้ไวยากรณ์นิพจน์การแยกวิเคราะห์ (คำอธิบายของภาษา "โดยอิงจากการจดจำสตริงแทนที่จะสร้างสตริง" ^{[ 4 ]} ) ที่ออกแบบมาเพื่อ "จัดการกับข้อมูลประเภทใดก็ได้" เช่น อักขระ ตัวเลข สตริง อะตอม และรายการ สิ่งนี้เพิ่มความหลากหลายในการใช้งาน ทำให้สามารถทำงานได้ทั้งกับข้อมูลที่มีโครงสร้างและไม่มีโครงสร้าง^{[ 1 ]}

ข้อได้เปรียบหลักของภาษานี้เหนือภาษาที่คล้ายคลึงกันคือความสามารถในการใช้โค้ดเดียวกันสำหรับทุกขั้นตอนของการคอมไพล์ เช่น การแยกคำและการแยกวิเคราะห์ OMeta ยังรองรับการกำหนดกฎการผลิตโดยอิงจากอาร์กิวเมนต์ ซึ่งสามารถใช้เพื่อเพิ่มกฎดังกล่าวลงใน OMeta และภาษาโฮสต์ที่ OMeta ทำงานอยู่ นอกจากนี้ กฎเหล่านี้ยังสามารถใช้ซึ่งกันและกันเป็นอาร์กิวเมนต์ สร้าง "กฎลำดับสูง" และสืบทอดซึ่งกันและกันเพื่อรับกฎการผลิตจากโค้ดที่มีอยู่ OMeta สามารถใช้ค่าบูลีนของภาษาโฮสต์ (จริง/เท็จ) ในขณะที่จับคู่รูปแบบ ซึ่งเรียกว่า "ตัวบ่งชี้ความหมาย" OMeta ใช้การจับคู่รูปแบบทั่วไปเพื่อให้โปรแกรมเมอร์สามารถใช้งานและขยายขั้นตอนการคอมไพล์ได้ง่ายขึ้นด้วยเครื่องมือเดียว^{[ 1 ]}

OMeta ใช้ไวยากรณ์เพื่อกำหนดกฎในการทำงาน ไวยากรณ์สามารถเก็บตัวแปรได้ไม่จำกัดจำนวนเนื่องจากการใช้ฟังก์ชัน __init__ ที่เรียกใช้เมื่อสร้างไวยากรณ์ ไวยากรณ์สามารถสืบทอดและเรียกใช้ซึ่งกันและกันได้ (โดยใช้ "กลไกการเรียกใช้งานการผลิตภายนอก" ซึ่งทำให้ไวยากรณ์สามารถ "ยืม" สตรีมอินพุตของกันและกันได้) คล้ายกับคลาสในภาษาโปรแกรมเต็มรูปแบบ^{[ 1 ]}นอกจากนี้ OMeta ยังให้ความสำคัญกับตัวเลือกภายในไวยากรณ์ที่กำหนดเพื่อขจัดความกำกวม ซึ่งแตกต่างจากภาษาเมตาอื่นๆ ส่วนใหญ่ หลังจากจับคู่รูปแบบอินพุตกับไวยากรณ์ที่กำหนดแล้ว OMeta จะกำหนดส่วนประกอบแต่ละส่วนของรูปแบบให้กับตัวแปร จากนั้นจึงป้อนตัวแปรนั้นเข้าไปในภาษาโฮสต์^{[ 5 ]}

OMeta ใช้การจับคู่รูปแบบเพื่อดำเนินการทุกขั้นตอนของการคอมไพล์แบบดั้งเดิมด้วยตัวเอง โดยจะค้นหารูปแบบในอักขระเพื่อสร้างโทเค็นก่อน จากนั้นจึงจับคู่โทเค็นเหล่านั้นกับไวยากรณ์เพื่อสร้างต้นไม้ไวยากรณ์ ตัวตรวจสอบประเภทจะจับคู่รูปแบบบนต้นไม้ไวยากรณ์เพื่อสร้างต้นไม้ที่มีคำอธิบายประกอบ และตัวเยี่ยมชมจะทำเช่นเดียวกันเพื่อสร้างต้นไม้อื่นๆ จากนั้นตัวสร้างโค้ดจะจับคู่รูปแบบกับต้นไม้เพื่อสร้างโค้ด^{[ 3 ]}ใน OMeta การ "เดินทางผ่านต้นไม้การวิเคราะห์ไวยากรณ์" นั้นง่าย เนื่องจากฟังก์ชันดังกล่าวได้รับการสนับสนุนโดยธรรมชาติ^{[ 3 ]}

เมตาภาษานี้โดดเด่นในด้านความสามารถในการใช้งานในภาษาโปรแกรมส่วนใหญ่ แม้ว่าจะใช้กันทั่วไปในภาษาที่ใช้ในการพัฒนา—เช่น OMeta/JS ใช้ใน JavaScript ^{[ 5 ]}เนื่องจากต้องใช้ภาษาโฮสต์ ผู้สร้าง OMeta จึงเรียกมันว่า "ภาษาปรสิต" ^{[ 6 ]}

Alessandro Warth และ Ian Piumarta พัฒนา OMeta ที่ Viewpoints Research Institute ซึ่งเป็นองค์กรที่มุ่งปรับปรุงระบบการวิจัยและการประมวลผลส่วนบุคคลในปี 2550 พวกเขาใช้ Combined Object Lambda Architecture (COLA) ซึ่งเป็นภาษาที่อธิบายตัวเองได้ซึ่งได้รับการศึกษาที่ Viewpoints Research Institute เป็นภาษาหลักของ OMeta เป็นครั้งแรก และต่อมาได้รับความช่วยเหลือจาก Yoshiki Ohshima ในการพอร์ตไปยังSqueak Smalltalkเพื่อตรวจสอบความสามารถในการใช้งานกับภาษาหลักหลายภาษา OMeta ยังถูกใช้ "เพื่อนำชุดย่อยที่เกือบสมบูรณ์ของ...JavaScript" มาใช้ในกรณีศึกษาในเอกสารแนะนำ^{[ 1 ]}

OMeta เช่นเดียวกับภาษาเมตาอื่นๆ ใช้เพื่อสร้างภาษาเฉพาะโดเมน (DSL) เป็นหลัก โดยเฉพาะอย่างยิ่ง ใช้เพื่อสร้างต้นแบบ DSL อย่างรวดเร็ว ความเร็วในการทำงานที่ช้าและรายงานข้อผิดพลาดที่ไม่ชัดเจนของ OMeta ทำให้ฟังก์ชันของมันในฐานะภาษาโปรแกรม เต็มรูปแบบลดลง (Heirbaut 73–74) OMeta มีประโยชน์เนื่องจากความสามารถในการใช้ไวยากรณ์เดียวสำหรับทุกขั้นตอนของการคอมไพล์ ทำให้สามารถใช้แทนเครื่องมือแยกต่างหากหลายอย่างในการสร้างคอมไพเลอร์ได้^{[ 5 ]}นอกจากนี้ OMeta ยังมีคุณค่าทั้งในด้านความเร็วในการใช้สร้าง DSL และปริมาณโค้ดที่จำเป็นในการทำงานดังกล่าวที่น้อยกว่าอย่างมากเมื่อเทียบกับการใช้งานแบบดั้งเดิม โดยมีรายงานแสดงให้เห็นว่ามีโค้ดฟังก์ชันเพียงประมาณ 26% ของการใช้งานแบบดั้งเดิม^{[ 2 ]}

ต่อไปนี้เป็นตัวอย่างของภาษาเครื่องคิดเลขพื้นฐานในภาษา C# โดยใช้ OMeta:

ometa BasicCalc < : Parser { Digit = super : d -> d . ToDigit (), Number = Number : n Digit : d -> ( n * 10 + d ) | Digit , AddExpr = AddExpr : x ' + ' MulExpr : y -> ( x + y ) | AddExpr : x ' - ' MulExpr : y -> ( x - y ) | MulExpr , MulExpr = MulExpr : x ' * ' primExpr : y -> ( x * y ) | MulExpr : x ' / ' primExpr : y -> ( x / y ) | PrimExpr , PrimExpr = ' ( ' Expr : x ' ) ' -> x | Number , Expr = AddExpr }

^{[ 5 ]}

นอกจากนี้ ยังสามารถสร้างคลาสย่อยของภาษาที่คุณเขียนขึ้นได้อีกด้วย:

ometa ExponentCalc < : BasicCalc { MulExpr = MulExpr : x ' ^ ' PrimExpr : e -> Math . pow ( x , e ) | super }

^{[ 5 ]}

ภาษาที่เขียนไว้ก่อนหน้านี้อาจเรียกได้ว่าเป็นภาษาที่สืบทอดมา แทนที่จะเรียกว่าเป็นภาษาที่สืบทอดมา:

ometa ScientificCalc < : Parser { MathFunc : n = Token ( n ) Spaces , AdvExp = MathFunc ( ' sqrt ' ) AdvExp : x -> Math . Sqrt ( x ) | FacExp FacExp = PrimExp : x ' ! ' -> { var r = 1 ; for (; x > 1 ; x -- ) { r *= x ; } return r ; } | PrimExp PrimExp = foreign ( ExponentCalc . Expr ): x -> x Expr = AdvExp }

^{[ 5 ]}

OMeta สามารถนำไปใช้ในภาษาโฮสต์ใดก็ได้ในทางทฤษฎี แต่ส่วนใหญ่จะใช้เป็น OMeta/JS ซึ่งเป็นการใช้งานใน JavaScript ^{[ 5 ]} Warth ได้กล่าวว่ารูปแบบใน "OMeta/X---โดยที่ X เป็นภาษาโฮสต์บางภาษา" ควรปล่อยให้ได้รับอิทธิพลจาก "X" มากกว่าที่จะกำหนดมาตรฐานภายใน OMeta เนื่องจากภาษาโฮสต์ที่แตกต่างกันรู้จักวัตถุประเภทต่างๆ กัน^{[ 6 ]}

MetaCOLA เป็นการนำ OMeta มาใช้ครั้งแรก ซึ่งใช้ในเอกสารแนะนำภาษา MetaCOLA ได้นำโค้ดทดสอบแรกของ OMeta มาใช้ และเป็นหนึ่งในสามรูปแบบ (อีกสองรูปแบบคือ OMeta/Squeak และ OMeta/JS ที่เกือบเสร็จสมบูรณ์) ของภาษาที่สร้างขึ้นก่อนการเผยแพร่^{[ 1 ]}

OMeta/Squeak เป็นพอร์ตของ OMeta ที่ใช้ระหว่างการสาธิตระบบในเบื้องต้น OMeta/Squeak ถูกใช้ "เพื่อทดลองไวยากรณ์ทางเลือกสำหรับระบบ Squeak EToys" OMeta/Squeak ต้องการวงเล็บเหลี่ยมและ "วงเล็บแหลม" (วงเล็บปีกกา) ในการดำเนินการตามกฎ ซึ่งแตกต่างจาก OMeta/JS ที่ต้องการเพียงวงเล็บเหลี่ยมเท่านั้น^{[ 6 ]}อย่างไรก็ตาม OMeta/Squeak 2 มีไวยากรณ์ที่คล้ายกับ OMeta/JS มากกว่า^{[ 7 ]}แตกต่างจากการใช้งาน OMeta ของ COLA เวอร์ชัน Squeak ไม่จดจำผลลัพธ์ระหว่างกลาง (เก็บตัวเลขที่ใช้ในการคำนวณแล้ว) ^{[ 1 ]}

OMeta/JS คือ OMeta ในรูปแบบของการใช้งาน JavaScript การใช้งานภาษาโดยใช้ OMeta/JS นั้นเป็นที่ทราบกันดีว่าใช้งานง่ายกว่าและประหยัดพื้นที่มากกว่าภาษาที่เขียนโดยใช้ JavaScript แบบดั้งเดิม แต่ภาษาที่ใช้ OMeta/JS นั้นทำงานได้ช้ากว่ามาก ด้วยเหตุนี้ OMeta/JS จึงถือเป็นเครื่องมือที่มีประโยชน์อย่างมากสำหรับการสร้างต้นแบบ แต่ไม่เป็นที่นิยมสำหรับการใช้งานภาษาในระดับการผลิต^{[ 3 ]}

การใช้เครื่องมือพัฒนา DSL เช่น OMeta ถือว่าสามารถบำรุงรักษาได้ง่ายกว่า "การใช้งานแบบดั้งเดิม" (เช่น JavaScript) เนื่องจากมีจำนวนบรรทัดโค้ดที่ไม่ใช่ความคิดเห็น (NCLOC) ต่ำ ส่วนหนึ่งเป็นเพราะ "โค้ดการกระทำเชิงความหมายที่สร้างวัตถุ AST หรือดำเนินการกับสตริงแบบจำกัด" การที่ OMeta ไม่มี "ไวยากรณ์ที่ไม่ขึ้นกับบริบท" ทำให้สามารถนำไปใช้ในการสร้างทั้งตัวแยกวิเคราะห์และตัวแยกคำได้ โดยแลกกับจำนวนบรรทัดโค้ดที่เพิ่มขึ้น ปัจจัยเพิ่มเติมที่บ่งชี้ถึงความสามารถในการบำรุงรักษาของ OMeta ได้แก่ ดัชนีความสามารถในการบำรุงรักษาที่สูง "ในขณะที่ Halstead Effort ระบุว่าตัวแยกวิเคราะห์แบบดั้งเดิมต้องใช้ความพยายามในการพัฒนามากกว่าตัวแยกวิเคราะห์ OMeta ถึงสามเท่า" เช่นเดียวกับ JavaScript, OMeta/JS รองรับ "สัญกรณ์ไวยากรณ์ที่สมบูรณ์ของ Waebric" ^{[ 3 ]}

ข้อดีหลักประการหนึ่งของ OMeta ที่ทำให้เกิดความแตกต่างใน NCLOC คือการที่ OMeta นำ "กลไกการเดินต้นไม้" กลับมาใช้ใหม่โดยอนุญาตให้ตัวตรวจสอบประเภทสืบทอดกลไกจากตัวแยกวิเคราะห์ ซึ่งทำให้ตัวตรวจสอบประเภทปรับตัวให้เข้ากับการเปลี่ยนแปลงในตัวแยกวิเคราะห์ OMeta ในขณะที่กลไกการเดินต้นไม้ของ JavaScript มีโค้ดมากกว่าและต้องปรับให้เข้ากับการเปลี่ยนแปลงในตัวแยกวิเคราะห์ด้วยตนเอง อีกประการหนึ่งคือข้อเท็จจริงที่ว่าไวยากรณ์ของ OMeta มี "ระดับนามธรรมที่สูงกว่า...โค้ดโปรแกรม" นอกจากนี้ยังสามารถพิจารณาได้ว่าเป็น "ผลลัพธ์ของโค้ดการกระทำเชิงความหมายที่สร้างวัตถุ AST หรือดำเนินการกับสตริงแบบจำกัด" แม้ว่าความไม่เชิงความหมายของไวยากรณ์จะสร้างความต้องการโค้ดหลายบรรทัดต่อฟังก์ชันเนื่องจากการกำหนดช่องว่างอย่างชัดเจน ซึ่งเป็นกลไกที่นำมาใช้เพื่อให้ OMeta ทำหน้าที่เป็นเครื่องมือเดียวสำหรับการสร้าง DSL ^{[ 3 ]}

ในแง่ของประสิทธิภาพ พบว่า OMeta ทำงานช้ากว่าเมื่อเทียบกับการใช้งานแบบพื้นฐาน การใช้เทคนิคการย้อนกลับ (backtracking) ของ OMeta อาจเป็นสาเหตุหลัก (ตัวแยกวิเคราะห์ของ OMeta "มีตัวดำเนินการมองล่วงหน้าเจ็ดตัว...ตัวดำเนินการเหล่านี้จำเป็นต่อการแยกแยะกฎบางอย่างออกจากกันและไม่สามารถละเว้นได้จากไวยากรณ์") อย่างไรก็ตาม มีความเป็นไปได้มากกว่าที่ประสิทธิภาพที่ลดลงนี้เกิดจากวิธีการจดจำผลลัพธ์ (memoization) ของ OMeta:

"การจัดเก็บขั้นตอนการวิเคราะห์ขั้นกลางทำให้ขนาดของตารางการวิเคราะห์เป็นสัดส่วนกับจำนวนเทอร์มินัลและไม่ใช่เทอร์มินัล (ตัวดำเนินการ) ที่ใช้ในไวยากรณ์ เนื่องจากไวยากรณ์ของตัววิเคราะห์ OMeta มีตัวดำเนินการ 446 ตัว จึงเชื่อว่าประสิทธิภาพจะได้รับผลกระทบในทางลบ" ^{[ 3 ]}

อย่างไรก็ตาม OMeta ได้เปรียบเรื่องเวลาในการใช้งานแบบดั้งเดิมในส่วนของการแยกคำ (lexing) ตัวแยกคำแบบดั้งเดิมของ JavaScript ทำงานช้าลงอย่างมากเนื่องจากวิธีการที่การใช้งานแปลงโปรแกรมทั้งหมดเป็นสตริงผ่าน Java ก่อนที่ตัวแยกคำจะเริ่มทำงาน ถึงกระนั้น การใช้งาน OMeta ก็ยังทำงานช้าลงโดยรวม^{[ 3 ]}

นอกจากนี้ OMeta ยังล้าหลังในแง่ของการรายงานข้อผิดพลาด ในขณะที่การใช้งานแบบพื้นฐานจะส่งคืนข้อความแสดงข้อผิดพลาดที่ถูกต้องใน "ประมาณ 92% ของกรณีทดสอบ" ในแง่ของตำแหน่งข้อผิดพลาด แต่ OMeta จะส่งคืน "การจับคู่ล้มเหลว!" สำหรับข้อผิดพลาดใดๆ ก็ตาม การค้นหาแหล่งที่มาผ่าน OMeta ต้องใช้ "การนับอักขระขึ้นบรรทัดใหม่ด้วยตนเองในโค้ดการกระทำเชิงความหมายเพื่อแสดงผลอย่างน้อยหมายเลขบรรทัดที่การแยกวิเคราะห์ล้มเหลว" ^{[ 3 ]}

OMeta# เป็นโครงการของ Jeff Moser ที่มีจุดประสงค์เพื่อแปล OMeta/JS ให้เป็นฟังก์ชัน C# ดังนั้น การออกแบบของ OMeta# จึงอิงตามการออกแบบ OMeta/JS ของ Alessandro Warth เป้าหมายของโครงการคือการให้ผู้ใช้สามารถสร้างภาษาที่ใช้งานได้จริงด้วยความเรียบง่ายสูง โดยเฉพาะอย่างยิ่ง OMeta# มีจุดประสงค์เพื่อเป็นเครื่องมือเดียวสำหรับ การพัฒนาภาษา .NETลดเส้นโค้งการเรียนรู้ที่สูงชันของการพัฒนาภาษา กลายเป็นแหล่งข้อมูลการสอนที่มีประโยชน์ และใช้งานได้จริงในแอปพลิเคชันจริง^{[ 5 ]}ปัจจุบัน OMeta# ใช้ C# 3.0 เป็นภาษาโฮสต์ของ OMeta แทนที่จะเป็น 4.0 เนื่องจาก C# 3.0 เป็นภาษาแบบคงที่แทนที่จะเป็นแบบไดนามิก การรับรู้ภาษาโฮสต์ภายใน OMeta# จึง "ยุ่งยากและใหญ่กว่าที่ควรจะเป็นสองถึงสามเท่า" ในภาษาที่มีการกำหนดประเภทแบบไดนามิก^{[ 8 ]}

OMeta# ใช้คลาส .NET หรือ Type เป็นไวยากรณ์และเมธอดสำหรับ "กฎ" ภายในของไวยากรณ์ OMeta# ใช้วงเล็บปีกกา ( { และ } ) เพื่อจดจำภาษาโฮสต์ในไวยากรณ์ ภาษานี้เน้นที่การกำหนดประเภทแบบคงที่ที่แข็งแกร่งและสะอาดตาเช่นเดียวกับภาษาโฮสต์ แม้ว่าสิ่งนี้จะเพิ่มความซับซ้อนในการสร้างภาษา การใช้งานใหม่ใน C# ต้องเข้ากันได้กับเมตาภาษาของ .NET ด้วย ทำให้การสร้างซับซ้อนยิ่งขึ้น นอกจากนี้ เพื่อป้องกันไม่ให้ผู้ใช้ใช้เมตารูลใน OMeta# ผิดวิธีโดยไม่ได้ตั้งใจ Moser จึงเลือกที่จะใช้งานเป็น "อินเทอร์เฟซที่ชัดเจนที่เปิดเผยผ่านคุณสมบัติ (เช่น แทนที่จะใช้ "_apply" ฉันใช้ "MetaRules.Apply")" ส่วนหลังๆ ของ OMeta# เขียนด้วย OMeta# เอง แม้ว่าฟังก์ชันของภาษาจะยังคงผูกติดอยู่กับ C# อยู่บ้าง^{[ 9 ]}ซอร์สโค้ดของ OMeta# ถูกโพสต์บน Codeplex และตั้งใจที่จะคงไว้เป็นโครงการโอเพนซอร์ส อย่างไรก็ตาม การอัปเดตได้หยุดชั่วคราวอย่างไม่มีกำหนดนับตั้งแต่เริ่มโครงการได้ไม่นาน โดยมีการส่งคำสั่งใหม่โดยเซิร์ฟเวอร์เมื่อวันที่ 1 ตุลาคม 2555 ^{[ 5 ]}

Gordon Tisher สร้างIronMetaสำหรับ .NET ในปี 2009 และถึงแม้จะคล้ายกับ OMeta# แต่ก็เป็นเวอร์ชันที่ได้รับการสนับสนุนและมีความเสถียรมากกว่ามาก โดยเผยแพร่ภายใต้ใบอนุญาต BSD บน GitHub

Ohmเป็นระบบที่พัฒนาต่อจาก Ometa โดยมีเป้าหมายเพื่อปรับปรุงระบบดังกล่าวให้ดีขึ้น (โดยเฉพาะอย่างยิ่ง) โดยการแยกไวยากรณ์ออกจากการกระทำเชิงความหมาย^{[ 10 ]}

• ANTLR (ANother Tool for Language Recognition) เป็นภาษาเมตาที่คล้ายกัน
• META IIเป็นคอมไพเลอร์รุ่น แรกๆ ที่มีอิทธิพลต่อการพัฒนา OMeta

• OMeta/JSบนGitHubสำหรับ JavaScript