Roger Browne <[EMAIL PROTECTED]> wrote: > On Mon, 2005-03-07 at 11:01 +0100, Leopold Toetsch wrote:
>> 4.1.1) implement a language pragma in assembler, e.g.: >> >> .HL_language Python > A pragma like that seems to split high-level languages into two groups: > those that are specially known to parrot, and those that are not. Not really. The rational for the .HL_language is twofold: - all modules and therefore all subroutines in it should have the HLL name attached to it. - the vtable and MMD methods that return new PMCs should return a PMC that is consistent with the types of that language. If no specific type is registered, Parrot's default or standard types like Integer, Float, or String are used. > Why not use a pragma to list the canonical types, instead of a > ".HL_language" pragma. This is of course part of the plan :) The ".HL_language" or ".Language_name" pragma specifies the mapping to use for the rest of the source file. And the mappings should be dynamically extendable as ... > .Language_mapping Integer <-> RubyInt .. it's shown here, yes. > I'd be very pleased to see working support in 0.2 for > setfile/setline/setcolumn so that when my IMC code fails due to (e.g.) a > divide by zero error, the parrot runtime can report the source location > in my high-level code rather than the source location in my IMC. Yep. Good point. It was discussed some time ago and went off into the multi-dimensionality of the code location ;) But yes. Code is ever becoming more complex and debugging is already a pain. The lexer already knows about setfile and setline as well as C-like #line directives. The information is discarded but should go into similar metadata like PIR-line information is already using. > Regards, > Roger leo
