MrJoltCola <[EMAIL PROTECTED]> wrote: > At 07:50 AM 3/7/2005, Leopold Toetsch wrote: >> >> >> >> .HL_language Python
> Sounds good to me except that I would prefer you remove the HL_ > and just call it .language to be consistent with other directives. I don't care much about the actual keyword - as long as we find a reasonable compromise ;) Anyway, the HL_ prefix should make sure that it's not mixed up with any kind of string's language declaration. But as strings don't have a language setting anymore ".language" would be fine too. > Incidentally this is what .NET uses as well except its implementation > uses GUID instead of a string, and it also allows the compiler > vendor and source document type to be included in the directive. I don't like GUIDs. I prefer text. > Dan and I talked about this a couple of years ago on IRC. > Originally I wanted to stay away from GUIDs as I think they are overkill, > and had considered allowing ASCII: Yep. > .language Perl6 > .language Perl6:ThePerlFoundation > But..., this requires this section in the bytecode to be variable sized, No. All that kind of information should either go into PBCs metadata or stored as PMC constants: .const .Version $P0 = "vendor=>tpf,author=>mel,version=0.815" or whatever. It's up to the Version PMC to parse the passed in string and freeze it appropriately. The constant PMC syntax is used already for subroutines. We'd need just to switch to freeze/thaw for PMC constants. WRT .language: that should be just a plain string. > In any case, it needs to be fixed width in the bytecode header. Not really. Metadata are in separate sections or .language becomes a string constant. > We need to revisit the bytecode format. Last time through, I put > an "Opcode type" at some offset, per Dan's request. You mean C<opcodetype> in the PBC header? That's still unused. But there is: #define OPCODE_TYPE_PERL 0x5045524c #define OPCODE_TYPE_PYTHON 0x5045524b #define OPCODE_TYPE_JAVA 4871757 #define OPCODE_TYPE_MSNET 2e4e4554 which defines 4-byte char constants denoting the language, somehow. > We store a magic number for that. I'm pretty sure we can use > this field to identify the language using whatever is provided in the > .language pragma, but I can't speak for Dan. I think he might > have had different plans for opcode type. Well, it seems to be that. But we want and additional type mapping for Parrot standard types. So that doesn't fit there anyway. > -Melvin leo
