Grades and deadlines

• Initial deadline: 23:59 on Wednesday 04 November

• How to submit: Turn in your completed lab4.1.yml file, along with the files containing your work, plus aichat.md if needed:

  club -csi413 -plab4.1 -f lab4.1.yml tokenSpec.txt Grammar.g4 example_prog dinner_prog aichat.md
  

  or

  submit -c=si413 -p=lab4.1 lab4.1.yml tokenSpec.txt Grammar.g4 example_prog dinner_prog aichat.md
  

  (you can download the club tool here)

• Collaboration and AI: Recall the course policy on collaboration and AI usage. For this lab:

  • You can collaborate with your classmates as long as that is cited and you do your own work. (You are all designing different languages.)

  • You may use the class Gemini Gem as long as you cite where/how you used it and you turn in a complete transcript of all relevant conversations.

    For the gem, switch to the “Pro” mode and write “transcript to produce a complete block of the conversation for you to copy/paste.

  • You may not use other AI tools besides the course-specific Gemini Gem. If you think there is something useful that you aren’t able to do with the Gem, talk to your instructor!

• Grading:

  In this lab you will complete the following tasks:

  1. Design a new, original programming language that supports all features from the Unit 3 labs, plus first-class functions with lexical scope.

  2. Write an example program and input/output test cases demonstrating clearly how your language works.

  3. Write another program to match the behavior of the “dinner program” example given below.

  4. Provide the full syntax of your language in the form of tokenSpec.txt and Grammar.g4 files, to correctly scan and parse any program in your language.

  5. Thoroughly test, then submit your code along with a completed YAML file

  If your submission meets the requirements for each task, you will receive 5 points towards your total lab grade.

• Resubmissions:

  We will follow the same resubmission policy for all labs this semester. For any given deadline you must at leat demonstrate significant progress or you get a zero that cannot be revised. The initial deadline for this lab is the same regardless of any other pending resubmissions on previous labs. If your work is not yet up to the standard, you will receive a new deadline of one week later (up to the end of the semester) and a chance to revise for full credit.

Getting started: files

Start by downloading the starter code. Running this command will create a new directory lab4.1:

git clone https://github.com/si413usna/startlab.git -b lab4.1 lab4.1

In there you will find:

• lab4.1.yml: for you to fill in and submit
• (Mostly) empty files for you to fill in: tokenSpec.txt, Grammar.g4, example_prog, dinner_prog
• A small bash script ptree to download and run the ptree program (same one that we used in Lab 2.1)
• A python version of the dinner program, dinner.py, to demonstrate exactly what your dinner_program is supposed to do.

What you need to fill in for this lab are the YAML file, the syntax specification in tokenSpec.txt and Grammar.g4, and two programs in your language, example_prog and dinner_prog.

To run the ptree program on a program in your lauguage such as example_prog, you just do

./ptree tokenSpec.txt Grammar.g4 example_prog

Task 1: Design your language

You need a language that supports all of the string and boolean operations from Unit 3, but now must additionally support functions with lexical scope and closures.

Your language must treat functions as first-class, so that they can be created within and returned from other functions, and passed as arguments, assigned to variables, and so on.

Your language should be original and should not look the same as existing languages, or other languages we have all used in previous weeks. (You can base it off a language you designed for a previous lab, as long as it wasn’t one of the ones chosen for everyone to use.)

Some of the choices you should think about are:

• What do function definitions look like? Can we create “anonymous” (i.e. unnamed) functions with some kind of lambda syntax, or do you always have to give a function a name?

• What do function calls look like? Does the function name come first? Or does it come last? How does the syntax indicate where the arguments begin and end?

• Do functions always take exactly one argument, or do they allow any number of arguments?

  (Note, there are a number of languages which demand every function takes exactly one argument. This can greatly simplify the function definition and function call syntax! You might want to look up the concept of currying.)

• Do functions always need to return a value? If not, is it the same as returning some special value like None, or something else?

• Within a function, how is the return value indicated? Is it just the last expression in the function, or does it have to be an explicit statement, or does it use a special variable assignment, or …?

• Will your language use static or dynamic typing?

  (In the previous unit labs, we kind of “forced” you to have static typing because of the structure of the AST. But with functions, the typing gets more complicated, since you would also have to deal with the types of arguments and return values.)

Fill in the langauge_name and language_description fields in the YAML file.

Task 2: Write the specs for your syntax

Fill in the tokenSpec.txt and Grammar.g4 files with (respectively) your formal token spec and ANTLR grammar.

You can’t test them yet because you first need to…

Task 3: Write an example program.

Fill in the file example_prog with a complete example program that demonstrates all the features of your language. Make good use of variable and function names, spacing, and comments so that your code is easily readable and understandable.

Be sure to feature how your function definitions and function calls work!

If this example program is done correctly, it should be self-documenting: anyone who looks at your example program should pretty much get the idea of how your language works without having to read anything else.

Fill in the example_input1, example_output1, example_input2, and example_output2 fields in the YAML file, demonstrating what successful runs of your program would look like.

Make sure this works with the ptree! When you submit your lab, we will check that the example program you wrote correctly tokenizes and parses using the spec you wrote from the previous part.

To test it yourself, just run

./ptree tokenSpec.txt Grammar.g4 example_prog

and be sure to look over the parse tree to make sure it ended up how you intended it to.

Task 3: Write the dinner program in your language

Here is a simple Python program that demonstrates the features your language should support. (It’s also included in your starter code as dinner.py):

def table_tracker(name):
    first = True
    total = ""

    def order(food):
        nonlocal first, total, name

        print("Table " + name + " ordering " + food)

        if first:
            first = False
            total = food
        else:
            total = total + ", " + food

        return total

    return order

def string_eq(s1, s2):
    return not (s1 < s2 or s2 < s1)

table1 = table_tracker("CS profs")
table1("Kimchi")

print("Your name?")
table2 = table_tracker(input())

done = False
t2got = "nothing"
while not done:
    print("What do you want?")
    food = input()
    if string_eq(food, "done"):
        done = True
    else:
        t2got = table2(food)

table1("Tteokbokki")
total1 = table1("Samgyeopsal")

print("We got " + total1 + " and you got " + t2got)

You need to write a program in your language which is exactly equivalent to this one in terms of its run-time behavior. That is, running your program in your (eventually) working interpreter, should be the same as running the code above using the python3 interpreter.

Fill in the dinner_prog file with your code.

You don’t need to provide sample input/output pairs for this one, but you should still make sure it parses correctly:

./ptree tokenSpec.txt Grammar.g4 dinner_prog

Task 5: Test and submit

Be sure to test your own example programs with the parse tree generator using your own token spec and grammar. This is how you make sure that your syntax spec is correctly describing the language as you intended, and it will also help us get to work more quickly next week when we have to write an interpreter for some of these languages!

Follow the submit commands at the top of this page to turn everything in.