Add test cases for packages. They mention this quite a bit in the Phase 4 document and I don't believe it directly relates to anyones part so we just need to cover these at the end

• constants
• types
• like clause

Implement changes to @SimpleType to accept new like keyword syntax from string type declaration.
Ex: var str : like "Hello"

Description

Make fails when the lib/ and bin/ folders do not exist. The Makefiles assume that they exist but may be empty.

Possible Solutions

• Add an arbitrary file to both lib/ and bin/ such that git keeps track of them
• Edit Makefiles to automatically create lib/ and bin/, probably via mkdir

Example unary operators
val str_length = #str or val str_length = #"Hello"

The output of the parser for these statements is:
.sConst .sIdentifier .sIdentifier .sLength

The semantic analyzer reads both of these identifiers through @ConstDefinition and @operand. Then call is made to @unaryoperator where .sLength is recognized. Put type integer (since length is integer) on the type stack. Then call made to @CompareAndSwapTypes which tries to compare the top two types on the type stack to ensure it can be set.
The idea for this is to ensure that the identifier to be set is the same type as the value being set. Ex. When setting a variable x to a string we need to ensure that x can take a string.

What happens though with the @CompareAndSwapTypes is that it compares to the identifier attached to the unary operator. So for val str_length = #str an integer is placed on the type stack (since length is integer). Then it is compared with the identifier str which is a string literal. So matching fails in @CompareAndSwapTypes.

Changes in parser.ssll to add .sLength ouput token when used in constant defintion. Around line 370 with pHash.

The code should output errors when we try to do something illegal( i.e. substring with non-integer values) so we need to create some tests that are intended to create an error.

They really liked this from last time. If you look at the semantic test cases for string operations I cover this. As long as we do a few for string operations and maybe some other operations we should be good to get full marks

Need to make sure all test cases are in their own files (ex. + - should have their own test files).

Test the changes to file names in AssignProcedures

Modify the Program rule in parser.ssl to match the Like specification

working on initial values, code is in initialValues branch. the test can be run using:

ssltrace "ptc -o4 -t4 -L lib/pt test/coder/initial-values/initial-integer.pt" lib/pt/coder.def

The semantic phase prints out the correct token stream for the initial value but when the coder analyzes the stream, it is skipping over the tStoreInteger which should be the expected token

• Copy scan.ssl output tokens into parser.ssl input tokens
• Replace parser.ssl output token sType with sLike
• Add parser.ssl output tokens
  • sPackage
  • sPublic
  • sConcatenate
  • sRepeatString
  • sSubstring
  • sLength
  • sInitialValue
  • sCaseElse

To Do

• Fix assertion errors in String length
• Add support for string literal comparisons (sEq, sNEq)

Tests needed

• Test all operations (*, /, %). These are needed since an issue was found with types not being linked to their std type in the semantic.ssl file