Skip to content
Snippets Groups Projects
Commit 0d84fd42 authored by Ivan Vendrov's avatar Ivan Vendrov
Browse files

finalized external docs

parent 1e182122
No related merge requests found
# Makefile - CMPT 442 course project Makefile
#
# Authors:
# Joey Eremondi (jse313) - 11083040
# Ivan Vendrov (isv452) - STUDENT#
# Ivan Vendrov (isv452) - 11096960
# Alex Mair (ajm513) - 11099457
#
Milestone 1 External Documentation
Most of our lexer is standard and uninteresting.
(1) LEXER:
(a) string literals
To handle string literals, we introduce the concept
of "printable" characters, which include all ASCII
printables except '\'.
......@@ -22,7 +24,17 @@ or escape sequence.
We use the SML Standard Library String.fromString to un-escape the
characters, then stored the result in a STRING token.
(b) comments
We implemented comments using a global ref "commentDepth" that
keeps track of our current depth in the comment structure.
When commentDepth changes from 0 to 1, we enter the COMMENT state
in which we ignore all characters except comment open/close tokens;
when commentDepth changes from 1 to 0, we return to the INITIAL state
and continue lexing as normal.
(2) PARSER
In order to eliminate shift-reduce conflicts, we handle arrays specially.
We have two separate productions for "ID[exp]" and for "var[exp]"
......@@ -30,11 +42,14 @@ where var is an lvalue that is not an identifier.
Acessing an array value could begin with either production,
but creating an array always began with an identifier.
We have one shift-reduce conflict, which occurs because we
cannot distinguish between a seqExp and a letExp
with its body surrounded by parentheses.
It does not cause any incorrect parses.
The conflict arose from a hack to work around the extra
We have one remaining shift-reduce conflict, which occurs because we
allow (contrary to Tiger grammar) for a letExp body to be surrounded
by parentheses. This creates an ambiguity, since a letExp with
its body surrounded by parenthesis cannot be distinguished from
a let whose body is a single seqExp expression. The former
option is chosen if we shift, the latter if we reduce.
We made this allowance to work around the extra
parens that the unparser puts around let-bodies.
For example,
......@@ -49,12 +64,15 @@ pretty prints to
5)
end
on the first un-parse, but without our hack, the second un-parse
woudl print as
on the first un-parse, but without our change, the body would be
interpreted as a seqExp, and the second unparse would print as
let
in ((4;
5))
end
which, while semantically equivalent, creates a diff error.
which, while semantically equivalent, generates a nonempty diff.
With our change, however (since Yacc defaults to shifting),
the body is interpreted as a bracketed let-body, and the second
unparse produces the exact same result.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment