[M3devel] Resummary of tagged reference proposals

[Mika Nystrom]

Rodney,

Yes I agree that minimalist doesn't solve your problems as well as
TAGGED does.

However, if you allow REFANY to hold tagged values in the future
(once you have TAGGED in the language), adding TAGGED will be a 
backward-compatible step on top of minimalist.

In my application anything that might want to be TAGGED is today
declared as (exactly) REFANY, so I'm happy either way.  But of
course I realize I am not the only Modula-3 programmer in the world
(even if sometimes it does feel a bit like it).

     Mika

"Rodney M. Bates" writes:
>Tony Hosking wrote:
>> I'd prefer something like TAGGEDINT or some such.  But I am still not 
>> convinced that the minimalist proposal and this proposal differ in any 
>> significant way.
>The minimalist proposal forces you to give up some static safety you have
>in the current language, that the safe proposal allows.   In the minimalist
>proposal, you cannot both use tagged pointers and have any of the 
>following:
>
>1) An abstract data type T can (and today virtually always is) some 
>proper subtype
>    of REFANY.  This statically restricts values to this type.  In 
>minimalist, T can
>    only be declared REFANY, allowing a client to provide a value that 
>was neither
>    tagged nor of the type the abstraction expects.   Instead, the type 
>constraint will be
>    checked at runtime, on every call into the abstraction.   And this 
>is a more expensive
>    check than just a tag bit check.  Aside from the overhead, going 
>from static to
    runtime type checking requires an extensive test suite to get 
>somewhere short
>    of the same level of confidence that a mere compile would 
>guarantee.   In the safe
>    proposal, T could be replaced by TAGGED T, and the static rules 
>would guarantee
>    its values are always either integer or T, comparable to the current 
>language.
>
>2) If there is more than one abstraction that uses tagged types, 
>minimalist loses static
>    guarantee that they are not mixed up by client code.   Since Abs1.T 
>and Abs2.T must
>    both be REFANY,  a client can get a value from Abs1 and pass it to 
>Abs2.  Again, this
>    is a demotion of static to runtime type checking.  In safe, Abs1.T 
>and Abs2.T could
>    be tagged types built from different opaque types, giving the same 
>separation that
>    we get in the current language.
>
>3) The type declared in an abstraction can currently be an opaque 
>subtype of some
>    proper subtype of REFANY.  This allows the abstraction writer to 
>give clients the
>    ability to directly access some fields/methods, while hiding 
>others.  Once again,
>    the restriction that only REFANY can be tagged makes this impossible 
>in minimalist.
>    I suppose this could be worked around by providing accessors, 
>mutators, and plain
>    procedures in the abstraction, but then these would have to take 
>REFANY too, just
>    making for more instances of loss of static checking.
>>
>> On 21 Apr 2009, at 22:26, hendrik at topoi.pooq.com wrote:
>>
>>> On Mon, Apr 20, 2009 at 08:35:02AM -0500, Rodney M. Bates wrote:
>>>>
>>>> ---------------------------------------------------------------------
>>>> My (Rodney's) "safe" proposal:
>>>>
>>>> There is a new type named TAGABLE.  It is a subrange of INTEGER, whose
>>>
>>> Please spell it TAGGABLE.  TAG doubles its last consonant when adding
>>> suffixes:  TAGGED, TAGGING.
>>>
>>> -- hendrik
>>
>>