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. I'd like it to be possible for ANY scripting language to be compiled to IMC or PASM, and for that compiled code to be runnable directly (if it uses only built-in PMC classes), or with the addition of dynamically-loaded classes (if the built-in PMC classes are not suitable). > 4.1.2) create table of canonical types per language mapping > > Integer - PyInt - TclInt - Perl6Int - ... Why not use a pragma to list the canonical types, instead of a ".HL_language" pragma. In the language I'm implementing, there are distinct PMCs for Integer, Character, Boolean, Bits and Enumeration - but I don't want lose interoperability with other languages that use one integer type for all of these. Within my language, each of the above types is implemented with its own PMC, but each of these PMCs uses the same internal layout as .Integer. Therefore, it would be fine for them all to be treated at an integer within inter-language calls. But there needs to be a way for my IMC to tell parrot about this. Here's an example of how it could be done for a language that uses one PMC for all integer-like types: .Language_name "ruby" # just a String; used for messages etc .Language_mapping Integer <-> RubyInt .Language_mapping Character <-> RubyInt .Language_mapping Boolean <-> RubyInt .Language_mapping Bits <-> RubyInt .Language_mapping Enumeration <-> RubyInt .Language_mapping String <-> RubyString ...etc and here's how it might look for a language that has a greater degree of abstraction: .Language_name "Bird" .Language_mapping Integer <-> BirdInteger .Language_mapping Character <-> BirdCharacter .Language_mapping Boolean <-> BirdBoolean .Language_mapping Bits <-> BirdBits .Language_mapping Enumeration <-> BirdEnum .Language_mapping String <-> BirdString ...etc This would enable parrot to know that when a BirdBoolean is passed to a ruby method, BirdBoolean has a Boolean interface which ruby can treat as a RubyInt. If the ruby method wants to return a character, perhaps parrot could provide an "abstract" version of the "new" opcode, so that ruby can create a "new abstract Character". Parrot would then consult the canonical types, and would create a BirdCharacter if the calling language was "Bird", but would create a PyInt if the calling language was "Python". I hope this makes some sense, and that you can see some merit in it. > Proposed steps towards the next release 0.2 and beyond. 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. Regards, Roger -- Roger Browne <[EMAIL PROTECTED]>
