Restrictions on compilers for Microsoft's .NET project

Restrictions on compilers for Microsoft's .NET project

[Larry Kilgallen]

Page 11 of the March 2002 MSDN magazine from Microsoft announces
TMT Development Corporation's Pascal compiler for .NET.  It says the
compiler "can accept programs in standard Pascal (except for some unsafe
features, such as records with variants, which are allowed if variants
aren't overlapped)".

Is lack of variant records a TMT decision or a requirement of .NET ?
If the latter, it would not bode well for the possibility of a full
Ada compiler targeting that environment.

Re: Restrictions on compilers for Microsoft's .NET project

[Britt Snodgrass]

There is a current discussion of the .NET Common Language Runtime
(CLR) on Slashdot at
http://slashdot.org/article.pl?sid=02/02/09/1538238&mode=thread&tid=109
based on the interesting article at http://www.javalobby.org/clr.html.
I'm not a compiler person but after reading the article I would guess
that the .NET CLR would present fewer difficulties for an Ada compiler
than the Java JVM does.

Britt

Kilgallen@SpamCop.net (Larry Kilgallen) wrote in message news:<2sk5nInklHl1@eisner.encompasserve.org>...
> Page 11 of the March 2002 MSDN magazine from Microsoft announces
> TMT Development Corporation's Pascal compiler for .NET.  It says the
> compiler "can accept programs in standard Pascal (except for some unsafe
> features, such as records with variants, which are allowed if variants
> aren't overlapped)".
> 
> Is lack of variant records a TMT decision or a requirement of .NET ?
> If the latter, it would not bode well for the possibility of a full
> Ada compiler targeting that environment.

Re: Restrictions on compilers for Microsoft's .NET project

[Stephen Leake]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> Page 11 of the March 2002 MSDN magazine from Microsoft announces
> TMT Development Corporation's Pascal compiler for .NET.  It says the
> compiler "can accept programs in standard Pascal (except for some unsafe
> features, such as records with variants, which are allowed if variants
> aren't overlapped)".

Note that this says that non-overlapped variants are ok. Ada only
allows non-overlapped variants.

> Is lack of variant records a TMT decision or a requirement of .NET ?
> If the latter, it would not bode well for the possibility of a full
> Ada compiler targeting that environment.

It sounds to me like we are ok. MS is trying to forbid unchecked
conversions via C-style unions.

-- 
-- Stephe

Re: Restrictions on compilers for Microsoft's .NET project

[Larry Kilgallen]

In article <uzo2geyyf.fsf@gsfc.nasa.gov>, Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> Page 11 of the March 2002 MSDN magazine from Microsoft announces
>> TMT Development Corporation's Pascal compiler for .NET.  It says the
>> compiler "can accept programs in standard Pascal (except for some unsafe
>> features, such as records with variants, which are allowed if variants
>> aren't overlapped)".
> 
> Note that this says that non-overlapped variants are ok. Ada only
> allows non-overlapped variants.

Is this a change for Ada95 ?

I believe I recall using overlapped variants in VAX/DEC/Compaq Ada (83).

Or do I have a different understanding of the word "overlapped" ?

Re: Restrictions on compilers for Microsoft's .NET project

[Martin Dowie]

> Note that this says that non-overlapped variants are ok. Ada only
> allows non-overlapped variants.

er, shurely shome mishtake?...

it does allow them to be overlapping (via 'Size or a rep spec) but
e.g.
   type A_Variant (Value : Foo := Foo'First) is record
      case Value is
         when Bar1 =>
            Int : Integer;
         when Bar2 =>
            Bool : Boolean;
      end case;
   end record;
   for A_Variant'Size use 64;

but you do have to make a positive decision to do it and to do
and you can't just change to the other variant without again
doing something explicit (e.g. uncheck conversion, or a whole
record assignment).

Re: Restrictions on compilers for Microsoft's .NET project

[Larry Kilgallen]

In article <3c680086@pull.gecm.com>, "Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:
>> Note that this says that non-overlapped variants are ok. Ada only
>> allows non-overlapped variants.
> 
> er, shurely shome mishtake?...
> 
> it does allow them to be overlapping (via 'Size or a rep spec) but
> e.g.
>    type A_Variant (Value : Foo := Foo'First) is record
>       case Value is
>          when Bar1 =>
>             Int : Integer;
>          when Bar2 =>
>             Bool : Boolean;
>       end case;
>    end record;
>    for A_Variant'Size use 64;
> 
> but you do have to make a positive decision to do it and to do
> and you can't just change to the other variant without again
> doing something explicit (e.g. uncheck conversion, or a whole
> record assignment).

Certainly I am not expecting to be able to change variants on the fly,
but I have a lot of code that receives an access value denoting a
record and I have to check the value of a discriminant to determine
which fields of the record are available to me.  If I get it wrong
Compaq Ada will detect my error just as surely as it will detect an
out-of-range value of the discriminant.  Those possibly-present
fields from various variants are located at the same offsets as
each other.

The Microsoft publication I quoted described this as "unsafe".  Is
this prohibited by .NET ?  Is it allowed in Ada95 as in Ada83 ?

Re: Restrictions on compilers for Microsoft's .NET project

[Martin Dowie]

> Certainly I am not expecting to be able to change variants on the fly,
> but I have a lot of code that receives an access value denoting a
> record and I have to check the value of a discriminant to determine
> which fields of the record are available to me.  If I get it wrong
> Compaq Ada will detect my error just as surely as it will detect an
> out-of-range value of the discriminant.  Those possibly-present
> fields from various variants are located at the same offsets as
> each other.
>
> The Microsoft publication I quoted described this as "unsafe".  Is
> this prohibited by .NET ?  Is it allowed in Ada95 as in Ada83 ?

Well, I can see how this would be "unsafe" in C-style languages but
with all checks in place Ada programs will prevent you from assigning
to variant fields if the discriminant doesn't allow it.

So in:

   type A_Variant (Value : Foo := Foo'First) is record
      case Value is
         when Bar1 =>
            Int : Integer;
         when Bar2 =>
            Bool : Boolean;
      end case;
   end record;

if you wanted to have a data item with Value = Bar2 but an integer
value assigned to the memory area that Bool occupies you can, but
only by using a big ugly thing like an unchecked conversion.

otherwise, if you want to have 'Bool' assigned a value, you have
to change the discriminant to Bar2 at the same time.

Re: Restrictions on compilers for Microsoft's .NET project

[Jerry Petrey]

Stephen Leake wrote:

> Note that this says that non-overlapped variants are ok. Ada only
> allows non-overlapped variants.
> 

Stephen,

I don't think this is correct.
In regards to record representation, ARM 13.5.1-11 states:

At most one component_clause is allowed for each component of the type,
including for each discriminant (component_clauses may be given for some, all,
or none of the components). Storage places within a component_list shall not
overlap, UNLESS they are for components in distinct variants of the same
variant_part. 


Jerry
-- 
-----------------------------------------------------------------------------
-- Jerry Petrey                                                
-- Senior Principal Systems Engineer - Navigation, Guidance, & Control
-- Raytheon Missile Systems          - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to reply                  
-----------------------------------------------------------------------------

Re: Restrictions on compilers for Microsoft's .NET project

[Robert Dewar]

Jerry Petrey <"jdpetrey<NOSPAM>"@west.raytheon.com> wrote in message news:<3C681C25.6356CAF3@west.raytheon.com>...
.
> In regards to record representation, ARM 13.5.1-11 
> states:
> 
> At most one component_clause is allowed for each 
> component of the type, including for each discriminant 
> (component_clauses may be given for some, all,
> or none of the components). Storage places within a 
> component_list shall not overlap, UNLESS they are for 
> components in distinct variants of the same
> variant_part. 

This seems to me a tempest in a teapot (nice english phrase 
meaning Much Ado About Nothing (entertating Shakespeare
title, meaning a lot of fuss about a small point)).

The RM also says you don't have to do anything you can't
do. So if indeed .NET does not allow variants to overlap,
then Ada compilers in this environment won't allow overlapped
variants. This only affects the set of rep clauses that are accepted,
and it is to be expected that
in protected environments such as the JVM and .NET that there will be
restrictions on rep clauses.

Re: Restrictions on compilers for Microsoft's .NET project

[Larry Kilgallen]

In article <5ee5b646.0202111821.4dba9889@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:

> This seems to me a tempest in a teapot (nice english phrase 
> meaning Much Ado About Nothing (entertating Shakespeare
> title, meaning a lot of fuss about a small point)).

The phrase is quite familiar to me with a non-classical US education.

> The RM also says you don't have to do anything you can't
> do. So if indeed .NET does not allow variants to overlap,
> then Ada compilers in this environment won't allow overlapped
> variants. This only affects the set of rep clauses that are accepted,
> and it is to be expected that
> in protected environments such as the JVM and .NET that there will be
> restrictions on rep clauses.

Whether this matters or not, as we say in computers, depends on
the application.  I have some variant records that would require
up to four times as much disk space without overlap. My records
are in an application for which .NET would not be suitable,
but someone else might have an application for which .NET
would otherwise be suitable.

Re: Restrictions on compilers for Microsoft's .NET project

[Stephen Leake]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> Whether this matters or not, as we say in computers, depends on
> the application.  I have some variant records that would require
> up to four times as much disk space without overlap. 

Hmm. Overlapped variant records exist in RAM. Writing them to disk can
always be done with a different format, if necessary for efficiency.

> My records are in an application for which .NET would not be
> suitable, but someone else might have an application for which .NET
> would otherwise be suitable.

Yes, and I have some applications that are suitable for an 8086
system, except that has no floating point. 

If the platform doesn't meet the application requirements, it doesn't
meet the requirements!

-- 
-- Stephe

Re: Restrictions on compilers for Microsoft's .NET project

[Larry Kilgallen]

In article <ug046irse.fsf@gsfc.nasa.gov>, Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> Whether this matters or not, as we say in computers, depends on
>> the application.  I have some variant records that would require
>> up to four times as much disk space without overlap. 
> 
> Hmm. Overlapped variant records exist in RAM. Writing them to disk can
> always be done with a different format, if necessary for efficiency.

But that can run afoul of porting efficiency.

>> My records are in an application for which .NET would not be
>> suitable, but someone else might have an application for which .NET
>> would otherwise be suitable.
> 
> Yes, and I have some applications that are suitable for an 8086
> system, except that has no floating point. 
> 
> If the platform doesn't meet the application requirements, it doesn't
> meet the requirements!

But for the barrier to be a Microsoft rule that overlapping variants
can never be safe in any language is a bit foolish.

Re: Restrictions on compilers for Microsoft's .NET project

[Richard Riehle]

Larry Kilgallen wrote:

> In article <5ee5b646.0202111821.4dba9889@posting.google.com>, dewar@gnat.com (Robert Dewar) writes:
>
> > This seems to me a tempest in a teapot (nice english phrase
> > meaning Much Ado About Nothing (entertating Shakespeare
> > title, meaning a lot of fuss about a small point)).
>
> The phrase is quite familiar to me with a non-classical US education.

It is hilarious when one understands the slang meaning of "nothing" during
Shakespeare's time.   Sorry, cannot print it here for this family audience.
You will need to research it on your own.

Richard Riehle