Owl Andrew Olowude Ben Klingher Belai Lencho Kenneth Cheng Martin Li A language for finite automata Team 20 _________ /_ ___ \ \ \ \__/\___/ / \_\/______/

Slides:



Advertisements
Similar presentations
Semantic Analysis and Symbol Tables
Advertisements

4b Lexical analysis Finite Automata
Formal Language, chapter 4, slide 1Copyright © 2007 by Adam Webber Chapter Four: DFA Applications.
Lexical Analysis (4.2) Programming Languages Hiram College Ellen Walker.
CS 4800 By Brandon Andrews.  Specifications  Goals  Applications  Design Steps  Testing.
1 Chapter 3 Scanning – Theory and Practice. 2 Overview Formal notations for specifying the precise structure of tokens are necessary  Quoted string in.
Regular Expressions and Automata Chapter 2. Regular Expressions Standard notation for characterizing text sequences Used in all kinds of text processing.
Grammars, Languages and Finite-state automata Languages are described by grammars We need an algorithm that takes as input grammar sentence And gives a.
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 3 Lexical and Syntactic Analysis Syntactic.
1 Scanning Aaron Bloomfield CS 415 Fall Parsing & Scanning In real compilers the recognizer is split into two phases –Scanner: translate input.
Rosen 5th ed., ch. 11 Ref: Wikipedia
THE HOG LANGUAGE A scripting MapReduce language. Jason Halpern Testing/Validation Samuel Messing Project Manager Benjamin Rapaport System Architect Kurry.
CPSC 388 – Compiler Design and Construction Scanners – Finite State Automata.
General Computer Science for Engineers CISC 106 Lecture 02 Dr. John Cavazos Computer and Information Sciences 09/03/2010.
1 Week 4 Questions / Concerns Comments about Lab1 What’s due: Lab1 check off this week (see schedule) Homework #3 due Wednesday (Define grammar for your.
Boardr The Racing Board Game Creation Language. Project Manager: Eric Leung Language and Tools Guru: Shensi Ding System Architect: Seong Jin Park System.
CPTR 124 Review for Test 1. Development Tools Editor Similar to a word processor Allows programmer to compose/save/edit source code Compiler/interpreter.
AN IMPLEMENTATION OF A REGULAR EXPRESSION PARSER
Lexical Analysis - An Introduction. The Front End The purpose of the front end is to deal with the input language Perform a membership test: code  source.
Lexical Analysis - An Introduction Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at.
Lexical Analysis - An Introduction Copyright 2003, Keith D. Cooper, Ken Kennedy & Linda Torczon, all rights reserved. Students enrolled in Comp 412 at.
Introduction to Programming David Goldschmidt, Ph.D. Computer Science The College of Saint Rose Java Fundamentals (Comments, Variables, etc.)
Program A computer program (also software, or just a program) is a sequence of instructions written in a sequence to perform a specified task with a computer.
CoZy: A very cool language for temperature control Project Manager: Hannah Keiler Language and Tools Guru: Nate Booth System Architect: Giovanni Ortuno.
Lexical Analysis I Specifying Tokens Lecture 2 CS 4318/5531 Spring 2010 Apan Qasem Texas State University *some slides adopted from Cooper and Torczon.
4b 4b Lexical analysis Finite Automata. Finite Automata (FA) FA also called Finite State Machine (FSM) –Abstract model of a computing entity. –Decides.
D. M. Akbar Hussain: Department of Software & Media Technology 1 Compiler is tool: which translate notations from one system to another, usually from source.
BUILD ON THE POLYGLOT COMPILER FRAMEWORK MIHAL BRUMBULLI 7th Workshop “SEERE” Montenegro-Risan 9-14 September 2007 SimJ Programming Language.
Group 4 Java Compiler Group Members: Atul Singh(Y6127) Manish Agrawal(Y6241) Mayank Sachan(Y6253) Sudeept Sinha(Y6483)
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
TRANSITION DIAGRAM BASED LEXICAL ANALYZER and FINITE AUTOMATA Class date : 12 August, 2013 Prepared by : Karimgailiu R Panmei Roll no. : 11CS10020 GROUP.
Lexical Analysis: Finite Automata CS 471 September 5, 2007.
CS 153: Concepts of Compiler Design October 10 Class Meeting Department of Computer Science San Jose State University Fall 2015 Instructor: Ron Mak
The Functions and Purposes of Translators Syntax (& Semantic) Analysis.
Lecture 8 Theory of AUTOMATA
CSC 1010 Programming for All Lecture 3 Useful Python Elements for Designing Programs Some material based on material from Marty Stepp, Instructor, University.
Dharmen Mehta (Project Manager) Nimai Buch (Language Guru) Yash Parikh (System Architect) Amol Joshi (System Integrator) Chaitanya Korgaonkar (Verifier.
Lexical Analysis – Part II EECS 483 – Lecture 3 University of Michigan Wednesday, September 13, 2006.
Midterm Review Important control structures Functions Loops Conditionals Important things to review Binary Boolean operators (and, or, not) Libraries (import.
Inheritance of Automata Classes Using Dynamic Programming Languages (Using Ruby as an Example) Kirill Timofeev
Scanner Generation Using SLK and Flex++ Followed by a Demo Copyright © 2015 Curt Hill.
1 CS 177 Week 6 Recitation Slides Review for Midterm Exam.
CS412/413 Introduction to Compilers and Translators Spring ’99 Lecture 2: Lexical Analysis.
COMS W4115 Programming Languages and Translators Professor Alfred V. Aho GROUP 13 Project Manager - Neeraja Ramanan (nr2404) Language and Tools Guru -
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Designing with State Diagrams.
using Deterministic Finite Automata & Nondeterministic Finite Automata
CS 404Ahmed Ezzat 1 CS 404 Introduction to Compiler Design Lecture 1 Ahmed Ezzat.
LECTURE 5 Scanning. SYNTAX ANALYSIS We know from our previous lectures that the process of verifying the syntax of the program is performed in two stages:
Deterministic Finite Automata Nondeterministic Finite Automata.
Unix RE’s Text Processing Lexical Analysis.   RE’s appear in many systems, often private software that needs a simple language to describe sequences.
Department of Software & Media Technology
The need for Programming Languages
Lecture 2 Lexical Analysis
Introduction to Python
Chapter 2 Scanning – Part 1 June 10, 2018 Prof. Abdelaziz Khamis.
Lexical analysis Finite Automata
CS 153: Concepts of Compiler Design October 17 Class Meeting
Using SLK and Flex++ Followed by a Demo
CS 536 / Fall 2017 Introduction to programming languages and compilers
Imperative Programming
Lexical Analysis - An Introduction
Lecture 5: Lexical Analysis III: The final bits
4b Lexical analysis Finite Automata
Chapter Four: DFA Applications
4b Lexical analysis Finite Automata
Lexical Analysis - An Introduction
General Computer Science for Engineers CISC 106 Lecture 03
Lecture 5 Scanning.
CMPE 152: Compiler Design March 19 Class Meeting
Imperative Programming
Presentation transcript:

Owl Andrew Olowude Ben Klingher Belai Lencho Kenneth Cheng Martin Li A language for finite automata Team 20 _________ /_ ___ \ \ \ \__/\___/ / \_\/______/ / /\\\\\ | |\\\\\\ \ \\\\\\\ \______/\\\\\ _||_||_ Project Manager Language Guru System Architect System Integrator Verification and Validation

What is Owl? » General purpose programming language with domain- specific functionality for building finite state machines

Buzz Words ✓ Simple ✓ General Purpose ✓ Domain Specific Tools ✓ Educational ✓ Practical ✓ Automata-Based

Sample DFA (from HW2 solutions) How does this look in Owl?

# Input: abacbba m.step("a") m.step("b") m.step("a") m.step("c") m.step("b") m.step("a") if(accept) { print("Accepted") } else { print("Rejected") } # Output: Accepted m.step("a") if(accept) { print("Accepted") } else { print("Rejected") } # Output: Rejected bool accept = False machine m = { node s0 node s1 node s2 node s3 node s4 node dead s0("a") -> s1 s0() -> dead s1("b") -> s2 s1() -> dead s2("a") -> s2 s2("b") -> s3 s2("c") -> s2 s3("a") -> s4 s3("b") -> s3 s3("c") -> s2 enter(s4) { accept = True } exit(s4) { accept = False } s4() -> dead dead() -> dead }

Some Owl Features » Machines, Machine Functions » Transition Functions, Default Transitions » Control Flow, Iteration » Lists, List Iteration, Range Function » Functions » Type Casting » Regular Expression Transitions » User Input » Hoot

string[] list = ["a","b","c"] string s for s in list { print(s) } # a # b # c int x for x in range(5,10) { print("x: "+toString(x)) } # x: 5 # x: 6 # x: 7 # x: 8 # x: 9 float square(float x) { return x*x } string y = "2" float z = square(3.0) + toFloat(y) print(z) # 11.0 while (True) { hoot() } machine m = { node s0 node s1 exit (s0) { print("hello") } enter (s1) { print("!!!") } s0("go") -> s1 { print("world") } s0("stop") -> s1 s0() -> s0 s1() -> s1 } bool play = True if (play) { m.step("go") } else { m.step("stop") } # hello # world # !!!

Translation Block Diagram

Semantic Analysis » TypeChecker » MachineCodeGenerator » ScopeResolver » StandardLibraryAdder » PostProcessor

machine hello = { node s0 s0("a") -> s0 { print("hello world") } hello.step("a") import re from lib.automata import * groups = [] s0 = State() def trans_s0_s0_0cc175b9c0f1b6a831c399e (groups): global _hello, _s0 print 'hello world' _s0_s0_0cc175b9c0f1b6a831c399e = Transition(s0, s0, 'a') _s0_s0_0cc175b9c0f1b6a831c399e on_enter+=trans_s0_s0_0cc175b9c0f1b6a831c399e _hello = Automaton([s0], [_s0_s0_0cc175b9c0f1b6a831c399e ], s0) _hello.step('a') $ python compile.py hello_world.owl > hello_world.py hello_world.owl hello_world.py

Module(body=[ Machine(name=Name(id='hello', ctx=Store()), body=[ Node(name='s0'), Transition(left='s0', arg=Str(s='a'), right='s0', body=[ Print(dest=None, values=[ Str(s='hello world'), ], nl=True), ]), Expr(value=Call(func=Attribute(value=Name(id='hello', ctx=Load()), attr='step', ctx=Load()), args=[ Str(s='a'), ], keywords=[], starargs=None, kwargs=None)), ]) Symbol table: {'s0': 'node', 'hello': 'machine', '_trans_s0_s0_a': {'symbols': {}, 'params': [], 'type': 'void'}} Intermediate AST

Python, PLY, codegen Scripts for viewing state after each step of compilation lex.py, ptree.py, tree.py, compile.py, run.py run.py calls Python's exec on final AST ~/owl$ python run.py my_owl_program.owl Runtime Environment

Software Development Environment Python and PLY Command Line Git/Github Google Drive Various Editors

Testing » Some aspects of test driven development » unittest - Python's unit testing framework » python -m unittest discover » Test cases: LexerTestCase – tests whether a character stream is lexed into the expected tokens according to the language's grammar ParserTestCase – tests whether an AST generated from an Owl program matches the AST generated from the corresponding Python program TransformTestCase – an extension of ParserTestCase for a transformed AST OutputTestCase – tests whether the output of a Owl program (when run) matches what the expected output

Example Test import unittest import textwrap from test.parse_helper import ParserTestCase class TestSelectionStatements(ParserTestCase): def test_if_else_statements(self): owl = textwrap.dedent( r""" int x if(x == 3) { print("it's 3") } else { print("it's not 3") } """) python = textwrap.dedent( r""" x = 0 if x == 3: print "it's 3" else: print "it's not 3" """) self.assertAST(owl, python) AssertionError: Generated ASTs are not equal. Owl: Module(body=[ Assign(targets=[ Name(id='x', ctx=Store()), ], value=Num(n=0)), If(test=Compare(left=Name(id='x', ctx=Load()), ops=[ Eq(), ], comparators=[ Num(n=3), ]), body=[ Print(dest=None, values=[ Str(s="it's 3"), ], nl=True), ], orelse=[]), ]) Python: Module(body=[ Assign(targets=[ Name(id='x', ctx=Store()), ], value=Num(n=0)), If(test=Compare(left=Name(id='x', ctx=Load()), ops=[ Eq(), ], comparators=[ Num(n=3), ]), body=[ Print(dest=None, values=[ Str(s="it's 3"), ], nl=True), ], orelse=[ Print(dest=None, values=[ Str(s="it's not 3"), ], nl=True), ]), ]) test_selection_statement.py Possible test failure:

Project Management » Weekly meetings to discuss language, divvy up work and set weekly deliverables » Each member added individual features through all compiler stages (full compiler stack) » Version control: Git » Document collaboration: Google Drive

DEMO

Conclusions » What went wrong: » Difficulty of using static typing when translating to dynamically typed language » Language grammar too big » What went well: » Test driven development » Division of labor, collaborative workflow

Thank you! O>O