Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
perl.perl6.internals
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion .HL_language pragma (was: Proposed steps towards the next release 0.2 and beyond.)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Leopold Toetsch  
View profile  
 More options Mar 7 2005, 7:50 am
Newsgroups: perl.perl6.internals
From: l...@toetsch.at (Leopold Toetsch)
Date: Mon, 7 Mar 2005 13:50:59 +0100
Local: Mon, Mar 7 2005 7:50 am
Subject: .HL_language pragma (was: Proposed steps towards the next release 0.2 and beyond.)
Reply to author | Forward | Print | View thread | Show original | Report this message | Find messages by this author

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

    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google