Front page | perl.perl6.internals |
Postings from October 2002
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 drunk
Thread Previous