I'd like to move Companion's Sierra Script syntax a little closer to the original. That means getting rid of *use* statements.
In Sierra's compiler, the alternative was the classdef file (for classes), and individual header files (for public procedures).
The information in those (text) files is essentially what is in the binary .sco format that Brian invented.
Now, the use statements are really just there so the compiler doesn't have to scan *all* sco files in the directory to look for a name match. So it's to speed up the compiler, and partially to scope name matches (but with the small scope of these games, duplicate public procedure names aren't really an issue). So technically, uses could be optional.
So I *could* say, for Sierra Script syntax, they are just optional. I'm not sure if performance would actually be a problem.
For procedures, I could also do what Sierra does, which is require someone to include a header file that has the extern declaration in it:
(extern
ProcName ScriptNumber ExportNumber
)
The problem is, these are tedious to maintain, since the ExportNumber needs to match what is in the exports statement in that script. I *could* generate a foo.sh header file with the extern statement automatically when you compile a foo.sc script. Of course, there is game.sc, and an already existing game.sh which we don't want to overwrite.
Another alternative is to write all procedures into a single procs.sh file, which could get included by the compiler automatically (or included by sci.sh or something).
Leveraging extern statements is kind of nice, because then kernels can just be a special case of that (like they were with Sierra's compiler). That means you could compile against various different kernel.sh files depending on the interpreter. Instead, I currently have hard-coded kernel function mappings for SCI0/1, SCI2, SCI2.1. But in reality, I think there are cases where each interpreter had a slightly different kernel set (especially for later SCI versions), and this "future-proofs" SCI Companion, because people could adapt it to different interpreters just by modifying kernels.sh.
Just rambling here...