... as it was parsing the load command, the resulting string was upper cased and escaped with \" characters.
Sorry John,
I missed this question somehow. No, you weren't seeing things. As the LISP parser was trying to chew the
"filename.ext
" string, the SB parser was dealing with its individual characters. Presumably, a
\" escape is its internal representation of the DQ glyph similar to how it is expressed within a C string (SB is written in C). This is because strictly speaking, the debugger doesn't respond to what goes on in your SB "program" but rather to what happens in its underlying machine code compiled from the C language sources.
Now that we know SBLisp doesn't recognise enquoted strings, we aren't using DQ's and you won't see such escaped artifacts in your debugger any more.
This implementation of the language doesn't distinguish between numeric data and enquoted string data. It only distinguishes between evaluatable/executable statements, variables, and data literals as a whole. A data literal is an entity enclosed in parentheses and denoted with a
quote marker in between them. Data literals are never executed or evaluated and their corresponding parentheses don't denote a command but rather the bounds (scope) of the literal.
That said,
(load (quote filename.ext)) can be understood as a command to accept
filename.ext as a literal non-evaluatable non-executable piece of data and apply it to
load as an argument for execution, or in simpler words, as a command to
load filename.exe.
Pooh!
