Reference
Appendix D: What QF Code Doesn't Do Yet (as of 1.1.0), and Why
This appendix is deliberately factual, not aspirational. It documents QF Code 1.1.0's real boundaries, drawn on purpose in most cases, still open in progress in a few others. If you want the more personal case for where the language is headed, that's chapter 16. This is just what's true right now, and this appendix gets updated every time QF Code does.
Classes and Objects
QF Code has no class, no object, no new, no inheritance. Every value
you've worked with in this book, numbers, strings, booleans, arrays, has
been enough to build a complete game. That's on purpose: object-oriented
design is a real, useful idea, but it's also one more layer a beginner
has to learn before writing their first working program. QF Code puts
that layer off entirely for now, so nothing stands between you and
running code. The words class, object, extends, new, and this
are already reserved, held in place for if and when this changes.
Closures
A function in QF Code can't reach into another function's local variables just because it's defined nearby, chapters 6 and 11 both flag this directly. Closures are a genuinely useful pattern in most modern languages, but they also make it harder to answer a simple question: what can this function actually see? QF Code trades that flexibility for a scope model you can hold in your head in one sentence, a function sees its own locals and the globals, nothing else.
Modules and Imports
Everything in QF Code lives in one file. There's no import, no
export, no splitting a program across multiple source files. For a
project the size of the one you built in this book, that's not really a
limitation, it's just how the language currently works. import,
export, and module are reserved words already, so this is a known
direction, not a permanently closed door.
Reading and Writing Files
QF Code programs can't read from or write to files on your computer.
Everything a program knows, it has to get from input() or build itself.
This is on the project's own backlog, not a permanent design decision.
Canvas and Sprite Graphics
Output in QF Code is text only, the output panel prints lines, it doesn't draw shapes, images, or sprites. If you want a visual game with graphics instead of a text adventure, QF Code 1.1.0 isn't there yet. This is also on the backlog.
Individual Key Detection
There's no getkey() or keypressed(), no way to react to a single key
the instant it's pressed. input() always waits for a full line of text
and the Enter key. Real-time, arcade-style input isn't something QF Code
supports yet.
wait()
You met sound() and bell() in chapter 12, and learned that both block
your program until they finish playing. A proper wait(), a way to pause
for a set amount of time without blocking everything else, doesn't exist
yet either. It's meant to arrive alongside a fix for the related issue
below.
Stop Can't Interrupt sound(), bell(), or input() Mid-Wait
Chapter 12 already covered this directly: once sound() or bell()
starts playing, or once input() is waiting for the player to type
something and press Enter, the Stop button can't interrupt it. This is a
known, documented gap, not a hidden one, and fixing it is linked to
adding wait() above.
Text Color
There's no color() or resetcolor(). Output in the panel is a single,
fixed style, you can't make one line red and another green. This is on
the backlog as well.
A Note on Standalone stop()
Appendix A already covers this in practical terms: a standalone stop()
line, on its own, doesn't currently behave as cleanly as the language
intends. Calling it from inside an expression works correctly. This is a
known defect in the current reference shell, not an intended limitation,
and it's expected to be corrected in a future release.
Reserved, But Not Yet Real
A handful of words are already off-limits as variable names, held in
reserve for features that don't exist yet: class, object, extends,
new, this, import, export, module, async, await, list,
map, and set. None of them do anything in 1.1.0. Their presence on
this list is itself a small promise about where the language is headed,
without committing to exactly when.
Copyright © 2026 Edison Mooers. Published by Gibidda Press. Free for personal learning and qualifying noncommercial educational use. Commercial training, organizational use, redistribution, and adaptation require written permission. Full use terms.