[M3devel] HEADS UP: Release engineering, was: Re: CM3 Release

[Mika Nystrom]

Randy,

I think Tony and I are on the same page.  I've proposed that the
runtime and compiler be modified as necessary to allow values of
type REFANY to hold, instead of an actual memory reference, an
arbitrary (wordsize-1)-bit integer.  The necessary changes would
only guarantee that the type safety of Modula-3 could not be subverted
within any type of safe code by any manipulations involving these
new REFANY values.  The necessary modifications are pretty limited:
a tag check for uses of ISTYPE, NARROW, TYPECASE, and TYPECODE on
values known only to be REFANY.

Rodney has proposed adding a type constructor (I think that's the
right terminology) to permit tagged values as above to be held
in variables of type other than REFANY.  And our disagreement
at this point I think is only on whether REFANY itself should
then be allowed to hold the tagged values, as it wouldn't strictly
speaking be necessary, but I contend there are good "software
engineering" reasons for permitting it.

There are several applications for this idea.  Think of it as
using all those unused values of a reference.  My application is
to do small integers (a la Smalltalk); Rodney wants to do efficient
data structures that can either be small (max 31 bits) or 
pointers to something bigger.  In the former case they wouldn't
involve memory allocation or garbage collection.

     Mika

"Randy Coleburn" writes:
>This is a MIME message. If you are reading this text, you may want to 
>consider changing to a mail reader or gateway that understands how to 
>properly handle MIME multipart messages.
>
>--=__Part456DE886.0__=
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>There have been a lot of messages flying back and forth on this idea of =
>adding some sort of tagged ref.  I'm afraid I've gotten lost on what =
>exactly is being proposed.
>=20
>Can someone please succinctly state the proposal again along with the =
>reasoning behind why it should be done--what does this change enable us to =
>do that we couldn't do before?  Based on the messages, I'm not sure that =
>Mika, Tony, Rodney, et al are all saying the same thing.
>=20
>Also, not sure I clued into the significance of the LSB value.
>=20
>Regards,
>Randy
>
>>>> <hendrik at topoi.pooq.com> 4/17/2009 6:02 PM >>>
>On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony Hosking wrote:
>>=20
>> On 15 Apr 2009, at 02:56, Mika Nystrom wrote:
>>=20
>> >
>> >I agree with what Hendrik says, but what about TYPECASE, ISTYPE,
>> >NARROW?  Those are necessary to make it possible to pass "pointers"
>> >with the low-order bit set outside of unsafe code.
>> >
>> >My feeling is that if Tony can make the necessary changes, it could
>                                                                should
>> >be done immediately, and the language issues can be pushed to the
>> >future.  But admittedly I'm biased because of the application I'm
>> >working on.
>>=20
>> I can take care of this next week.
>
>I'm in favour of trying it out before freezing the feature.  That=20
>means going ahead now with an implementation, and reconsidering it=20
>in a few months.  Perhaps marking it experimental with an appropriate=20
>warning message.  A few months is little enough time to use it that it=20
>won't be traumatic if code that uses the new features has to be=20
>partially rewritten.
>
>-- hendrik
>
>
>CONFIDENTIALITY NOTICE:  This email and any attachments are intended =
>solely for the use of the named recipient(s). This e-mail may contain =
>confidential and/or proprietary information of Scientific Research =
>Corporation.  If you are not a named recipient, you are prohibited from =
>making any use of the information in the email and attachments.  If you =
>believe you have received this email in error, please notify the sender =
>immediately and permanently delete the email, any attachments, and all =
>copies thereof from any drives or storage media and destroy any printouts =
>of the email or attachments.
>
>EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain =
>technical data subject to U.S export restrictions under the International =
>Traffic in Arms Regulations (ITAR) or the Export Administration Regulations=
> (EAR).  Export or transfer of this technical data and/or related =
>information to any foreign person(s) or entity(ies), either within the =
>U.S. or outside of the U.S., may require export authorization by the =
>appropriate U.S. Government agency prior to export or transfer.  In =
>addition, technical data may not be exported or transferred to certain =
>countries or specified designated nationals identified by U.S. embargo =
>controls without prior export authorization.  By accepting this email and =
>any attachments, all recipients confirm that they understand and will =
>comply with all applicable ITAR, EAR and embargo compliance requirements.
>
>
>--=__Part456DE886.0__=
>Content-Type: text/html; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>Content-Description: HTML
>
><HTML><HEAD>
><META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
>">
><META content=3D"MSHTML 6.00.6000.16825" name=3DGENERATOR></HEAD>
><BODY style=3D"MARGIN: 4px 4px 1px">
><DIV>There have been a lot of messages flying back and forth on this idea =
>of adding some sort of tagged ref.  I'm afraid I've gotten lost on =
>what exactly is being proposed.</DIV>
><DIV> </DIV>
><DIV>Can someone please succinctly state the proposal again along with the =
>reasoning behind why it should be done--what does this change enable us to =
>do that we couldn't do before?  Based on the messages, I'm not sure =
>that Mika, Tony, Rodney, et al are all saying the same thing.</DIV>
><DIV> </DIV>
><DIV>Also, not sure I clued into the significance of the LSB value.</DIV>
><DIV> </DIV>
><DIV>Regards,</DIV>
><DIV>Randy<BR><BR>>>> <hendrik at topoi.pooq.com> 4/17/2009 =
>6:02 PM >>><BR>On Fri, Apr 17, 2009 at 12:54:13PM +1000, Tony =
>Hosking wrote:<BR>> <BR>> On 15 Apr 2009, at 02:56, Mika Nystrom =
>wrote:<BR>> <BR>> ><BR>> >I agree with what Hendrik says, =
>but what about TYPECASE, ISTYPE,<BR>> >NARROW?  Those are =
>necessary to make it possible to pass "pointers"<BR>> >with the =
>low-order bit set outside of unsafe code.<BR>> ><BR>> >My =
>feeling is that if Tony can make the necessary changes, it could<BR> &=
>nbsp;           &nbs=
>p;            &=
>nbsp;           &nbs=
>p;            &=
>nbsp;            =
>should<BR>> >be done immediately, and the language issues can be =
>pushed to the<BR>> >future.  But admittedly I'm biased because =
>of the application I'm<BR>> >working on.<BR>> <BR>> I can take =
>care of this next week.<BR><BR>I'm in favour of trying it out before =
>freezing the feature.  That <BR>means going ahead now with an =
>implementation, and reconsidering it <BR>in a few months.  Perhaps =
>marking it experimental with an appropriate <BR>warning message.  A =
>few months is little enough time to use it that it <BR>won't be traumatic =
>if code that uses the new features has to be <BR>partially rewritten.<BR><B=
>R>-- hendrik<BR><BR></DIV></BODY></HTML>
>
>--=__Part456DE886.0__=--