Proposed steps towards the next release 0.2 and beyond. - perl.perl6.internals

Message from discussion Proposed steps towards the next release 0.2 and beyond.
Newsgroups: perl.perl6.internals
Path: g2news1.google.com!news4.google.com!newsfeed.stanford.edu!nntp.perl.org
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Received-SPF: pass (x1.develooper.com: local policy)
Subject: Re: Proposed steps towards the next release 0.2 and beyond.
To: Perl 6 Internals <perl6-intern...@perl.org>
In-Reply-To: <422C2669.6050206@toetsch.at>
References: <422C2669.6050206@toetsch.at>
Content-Type: text/plain
Date: Mon, 07 Mar 2005 12:09:02 +0000
Message-ID: <1110197342.20272.56.camel@eden>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Approved: n...@nntp.perl.org
From: ro...@eiffel.demon.co.uk (Roger Browne)

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 <ro...@eiffel.demon.co.uk>