1 Interpretting - April 2013
3 Supposing I had a language design, and a parser which created a basic
4 abstract syntax graph. What else is needed before I can have an
5 interpreter which can run programs.
7 Assume a simple source-only interpreter - no bytecode format.
10 - symbol tables - lots of them. One for every scope. Each symbol can
11 have a type and a value. Symbol table must complain about
14 - process declarations by putting things in symbol tables. This may
15 involve loading modules, but that can happen later too.
16 Also create proper internal representations for things like
17 structures and assign numbers for enums. Though we need to be
18 able to evaluate constant expressions for that, which requires
19 type analysis. So I guess that has to come later.
22 - type resolution. Need to determine type for each expression and
23 for each name and make sure the types all match - or at least are
26 - Actually, we cannot separate type checking from expression
27 evaluation as they can depend on each other: if two arrays are
28 sized by expressions and need to be compatible.
31 - a virtual machine with a stack of frames and a heap. Maybe several
32 stacks for tasks or co-routines.
34 - a 'standard library' of functions, methods, constants
41 What errors are possible:
42 - parse errors: bad token, unexpected token (which might EOF)
43 - type errors: access attempt doesn't match type, in lots of
44 different ways. Is ignored return value a type error?
45 - namespace errors: name not defined, or already defined.
46 - enum values being reused ( { a=1, b=1} ).
47 - some constructs only allowed when 'unsafe' - is that a type error
48 or something else? If an 'unsafe' module provides those
49 constructs, then it could be a type/namespace error. But that
50 hides them from the language.
51 - numeric value is badly formatted
52 - string contains unknown escape
55 - generic number handling
58 \ b r t n a f q v 0-3 x u U \
60 - structure to hold type info
61 - expression structure