At 6:34 PM +0000 10/27/02, Nicholas Clark wrote: >On Sun, Oct 27, 2002 at 11:54:08AM -0500, Dan Sugalski wrote: >> The bytecode segments can hold more than just bytecode. They can also >> hold the source that corresponds to the generated bytecode, the AST >> for the source that corresponds to the generated bytecode, the line >> number information for the generated bytecode (for error reporting), >> and potentially some pieces of raw binary data, both for program >> needs and potential future expansion. > >On a serious note, I think column number information for syntax errors (if >available) would be useful for languages such as perl (and not just Befunge) >For example, it would let a single stepping debugger show you progress through >the statement. I'm having visions of n-dimensional numbers for errors... "Division by zero at (5, 6, 3) of foo.pl" (Whatever we decide, we are *not* adding in time information--quantum or not, there's no way we're going to be throwing errors yesterday or tomorrow... :) > > =item Add binary data chunk to segment >> >> Add in some raw binary data to the bytecode segment > >For each call this puts the binary into its own chunk? If not, what's wrong >with having binary data stored as a "string" in the string constant pool? This puts it in the binary data section. Partially for those compilers that want to throw extra non-string data into the bytecode for whatever reason, and partially for potential forwards-compatibility issues. We could, for example, consider the line number information for bytecode a piece of binary data. (Just binary data that we know more information about) -- Dan --------------------------------------"it's like this"------------------- Dan Sugalski even samurai dan@sidhe.org have teddy bears and even teddy bears get drunkThread Previous