Grades and deadlines
-
Initial deadline: 23:59 on Wednesday 26 August
-
How to submit: Turn in your completed
lab1.1.ymlfile, as well as a fileaichat.mdwith transcript(s) of your Gemini conversations, to the CS department submit system underSI413/lab1.1I recommend using the
clubtool to submit, by runningclub -cSI413 -plab1.1 lab1.1.yml aichat.md -
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, if you just say “transcript” it should 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:
- Design a new language to meet the capabilities specified below
- Write an example program to demonstrate how your language works
- Write a clear and complete specification of your language’s syntax and semantics
- Do peer review of the languages specs with your classmates.
If your submission meets the requirements for each task, you will receive 7 points towards your total lab grade.
Remember the somewhat unusual way we are assigning points for lab assignments this semester: If your submission meets the requirements, you get all 7 points. If it does not yet meet the requirements, you get 0 points (and a chance to revise and resubmit for full credit next week).
-
Resubmissions:
We will follow the same resubmission policy for all labs this semester. Here is how it will work:
- Every lab has an initial deadline.
- If your work is submitted by the deadline and meets the requirements, you get full credit and are done.
- If your work is submitted by the deadline, demonstrates significant progress (at the discretion of your instructor), but does not yet meet the requirements, then you get a new deadline which is exactly 1 week from the previous one (or the end of classes, whichever is sooner). Go back to step 2.
- Otherwise, if you do not submit work which demonstrates significant progress (from the prior submission) by the deadline, you will earn no points and lose the possiblity for further resubmission.
Unit 1 Labs Overview (next three weeks)
You will design and write careful specifications for a new programming language. As of now, and for the next three weeks, your language will only support string literals, string input/output, and a few string operations.
For this week’s lab, you will work creatively to design a new language that provides the features (details below). You will turn in a careful spec of your language, and an example program written in that language which demonstrates all of the features.
Unlike code, language specs are mostly written for other humans. You will do peer review of each other’s work to help make sure your spec makes sense to someone else, and to give you all an opportunity to see a wider variety of different approaches. At a minimum, everyone is responsible to review at least one classmate’s spec, and to have their spec reviewed by at least one classmate.
Looking ahead, for next week’s lab your instructors will select a few of the clearest and most interesting language specifications from this week. You will all choose one of those select-few languages, write an example program in that language, and then write code for an interpreter for that language. A complete, working, and well tested interpreter will be earn 10 points.
In two weeks, you will continue and write a compiler for that same language to LLVM IR code. A complete, working compiler will earn 3 points.
In total, up to 20 points of your total lab grade are available over the next three weeks.
YAML file to complete
Download the file lab1.1.yml.
As you complete your work for this part, you will fill in and eventually submit this file.
The parts you need to fill in are written in all caps like
BLAH BLAH. Replace any of that with your actual responses.
The file format should be mostly self-explanatory. Just be careful about the indentation. Generally, when your response goes over multiple lines, you have to maintain the same level of indentation (or greater) to keep that response together.
(If you care, you can read the full YAML language specification here: https://yaml.org/spec/1.2.2/)
Task 1: Language Design
Ground rules
Source code for your language should be plain-text, using the characters on your keyboard. Specifically, the 95 ASCII printable characters, space, and newline. (So no weird control characters, tabs, emojis, accents, etc.)
Required capabilities
Your language needs to support:
-
String literals: a literal sequence of zero or more of the 97 ASCII characters that your program source code may contain.
(Hint: making sure your string literals can support any possible string is part of the challenge!)
-
Concatenation: combining two (or more) string expressions into a single string, one after the other
-
Reversal: taking any string expression and producing a new string with the same characters in the reversed order
-
Input: reading a single line of text from the console as a string in your program
-
Print: displaying any string expression to the screen
-
Comments: a way to write notes in English which appear in your source code but do not affect the program meaning in any way.
REQUIREMENTS
Fill in the language_name field in lab1.1.yml with a name you choose
for your programming language.
There is nothing else really to turn in for this part — you are still brainstorming before you get into the details. But before you move on to the next part, you should have a pretty good idea of what your language looks like.
To receive credit for this lab, your language needs to:
-
Be original. The syntax and semantics should not be too similar to any single existing language, or to any of your classmates’ languages.
-
Support the required capabilities
-
Not have unnecessary extra features, like variables, functions, or while loops. We have a whole semester to add more cool capabilities, don’t worry!
Tips
If you are feeling stuck for ideas, feel free to peruse some of these sources of inspiration.
(Note, I was starting to make links for all of these so you can read more, but often the official documentation is too technical for a casual browse, and the many unofficial tutorials are on random websites that aren’t of high quality. You are genuinely better off asking an AI chatbot to explain these to you and give you some examples.)
-
Python’s raw literals and multi-line literals
-
Haskell’s comment syntax, which allows for nested comments
-
Quote-like operators in Perl, which is essentially another way to write string literals. (Ruby also has something similar.)
-
Heredocs and nowdocs in languages such as Bash or PHP
-
Reverse Polish Notation (RPN), while not really a complete programming language, is an alternate way of writing math expressions which amazingly can be unambiguous without requiring any parentheses
-
The Brainfuck language, which is extremely minimal with only 8 single-character commands, and yet powerful enough to perform any computation. How can you write code comments in such a language?
-
Befunge, a two-dimensional kind of ASCII art programming language. Each individual character acts like a command, and execution follows straight-line paths through the code itself, turning according to certain commands.
Task 2: Example program
Once you have a good “feel” for how you want your language to work, test it out by writing an example program in your language.
Your program should first prompt for a name, then say hello to that
name. Then it should prompt for a noun and a verb, read in two strings,
reverse the first string, and then concatenate it with is not and the
second string.
Specifically, it should work exactly the same as this Ruby program:
puts "What is your name?"
puts "Hello #{gets.chomp}"
puts "Enter a noun and an adjective:"
puts "#{gets.chomp.reverse} is not #{gets.chomp}"
(Note, you probably haven’t seen the Ruby programming language before,
but I bet you can still see easily how this program works!
You can try copy-pasting this code to a file like
stringex.rb and then running it from the command line with ruby
stringex.rb)
Here is a Python version of the same exact program:
print("What is your name?")
name = input()
print("Hello " + name)
print("Enter a noun and an adjective:")
noun = input()
adj = input()
revnoun = ''.join(reversed(noun))
print(revnoun + " is not " + adj)
Note that the Python version is a little more verbose and the method to reverse a string is a little more complicated, but it is functionally equivalent to the Ruby program above.
(Also note that your program will not be able to be just like the Python one, since your language probably doesn’t support variables!)
For either version — or for the version you write in your language — if you enter these three strings for the prompts:
Walter
drawer
open
then the program should print
What is your name?
Hello Walter
Enter a noun and an adjective:
reward is not open
REQUIREMENTS
Fill in the complete source code (along with comments) under the
example_program field in your YAML file.
Your example program must:
-
Demonstrate all of the capabilities that your language has in simple form, clearly demonstrating how your language is supposed to look and work.
-
Demonstrate more complex parts to show how your language’s capabilities can be nested and combined.
-
Make good use of code comments to explain clearly what your code means and what would happen if it were executed.
Task 3: Language specification
Syntax specification
Start by clearly and unambiguously defining the syntax of allowable programs in your language. You are not yet saying what anything means or how it should be executed, just what any possible program could look like.
You might want to look at the COOLBOOL language from
your homework to see an example of a (very simple!)
language spec.
You might want to think about organizing things into statements and expressions, and be clear when an expression can be nested inside another expression, or inside a statement.
Semantics specification
Now describe the precise meaning of the syntax you just laid out.
For each kind of expression, you should explain what value that expression produces. (Remember, every value in this language has the same type, strings.)
And for each kind of statement, you should explain exactly what that statement is supposed to do when executed.
REQUIREMENTS
Fill in the language syntax and semantics under language_syntax and
language_semantics in the lab1.1.yml file.
Your spec must:
-
Clearly and unambigiously define the syntax of allowable programs in your language
-
Be written with technical precision and clarity, at an abstract level without the use of examples
-
Support all of the required capabilities in the language from Task 1
-
Contain no UB (underspecified behavior).
On a technical level, this means that every syntactically valid program in your language must have a single, clear, and unambiguous meaning. (Even if that meaning is sometimes “this program causes a runtime error” or something like that.)
Task 4: Peer Review
Everyone is expected to act as a reviewer for at least one classmate’s submission, and everyone must have a classmate carefully review and sign off on their submission before it can be considered complete.
(Note, you can still turn in your work if it’s incomplete and not yet reviewed! That can certainly count as “significant progress” to get a chance to resubmit with a new deadline.)
Reviewer guidelines
-
Be kind, but remember your job is to help you peer by identifying issues that they need to fix to meet the requirements.
-
Focus mostly on the objective aspects of the requirements, like whether the language supports all the required capabilities, and whether the spec is unambiguous and free of any UB.
-
Examples are not definitions. If you needed to look at the example to understand a part of the spec, that means the spec was not clear or complete on that aspect.
-
Be pedantic. Think about edge cases and weird ways of putting things together which are technically allowed by the spec, but may not be what the author intended.
-
Feel free to discuss further and offer suggestions if you want, but you are not required to fix any problems, just to help identify them.
-
When you say
Yand agree that the spec meets all the requirements, you are putting your integrity on the line. If you sign off on a spec which has particularly glaring flaws or omissions, you may be deducted up to 2 points from your own grade.
Reviewee guidelines
-
Be respectful of your reviewer’s time. You should feel confident that your work satisfies all of the requirements before you ask someone else to (officially) review it.
-
Be happy when your reviewer finds errors in what you did. They are not attacking you, they are helping you improve your work and get it up to the required standard.
-
Try to avoid explaining things about your language. Your spec is supposed to stand alone without added commentary.
-
If your reviewer doesn’t have time to complete a careful review before the deadline, remember you can submit your (incomplete) work and add in the review for a resubmission the following week.
REQUIREMENTS
Fill in the following fields in your lab1.1.yml:
-
reviewed_by: Which classmate is performing the final review on your submission? -
review_passed: Change this toYwhen your reviewer agrees that your submission meets all of the requirements. -
reviewer_comments: Get your reviewer to write a sentence or two summarizing what they thought of your language design and spec.