[M3devel] small objects

[Mika Nystrom]

hendrik at topoi.pooq.com writes:
>On Thu, Apr 09, 2009 at 07:10:44AM -0700, Mika Nystrom wrote:
>> I don't know why we're having such a tough time understanding each 
>> other here :-)
>> 
>> I think that what Rodney says is that he wants (in pseudo-modula-2
>> syntax):
>> 
>> T = CASE LSB OF
>>      1 : SmallInt 
>>    |
>>      0 : U
>>     END;
>> 
>> SmallInt = [SmallMin..SmallMax];
>> 
>> for any reference type U.
>
>Yes.  That's what I wanted too, originally.  I can accept the
>restriction that the reference type U might be restricted to be
>REFANY.

I think this is what Tony says he's implemented, essentially...

...
>> 
>> The only problem I have with this (except for the changes necessary
>> to Modula-3) is that it can't be held in a REFANY, and that's part
>> of the design.
>
>Much better not to pervert REFANY, but use a new type instead.

Are you sure?  I want a type---some type---that can hold "any
reference, even a tagged one", and I would rewrite most library
code that today takes REFANY to take that instead.  Why not?  Why
would I want to limit it to REFANY when it performs no operations
that couldn't legally be performed on TAGGED REFANY.  

>
>> 
>> Of course we could go halfway and let it be held in a REFANY, but
>> then you get the runtime LSB check again, for all instances of
>> REFANY,
>
>I really don't like requiriny a run-time check on REFANY.  That's why
>I want it to be a separate type.

All the operations in question already require (*much* more
complicated) run-time checks on REFANY.... and most uses of REFANY
still wouldn't require the LSB check.

I really think the runtime issue is a non-issue, and as I said
above, if it turns out to be a real issue, one can either abandon
the change (since the whole thing can be implemented transparently
with a library) or else re-root ROOT and all the REF types in a new
NOTQUITEREFANY type.  This would be a backward-compatible change
(in every sense) with Tony's runtime changes:

REFANY ; (* Tony's, with the LSB trick *)

NOTQUITEREFANY <: REFANY;

ROOT <: NOTQUITEREFANY;

REF T <: NOTQUITEREFANY; (* for all T *)

After that, future, change, people who want to avoid the LSB check
on REFANY can instead use NOTQUITEREFANY.  I think barely anyone
will bother.

Come to think of it, Modula-3 doesn't specify that there's no
intermediate type between REFANY and ROOT and the other REF T's,
so there's no way it could break the current language.  In
fact you don't have to "reveal" this new type in the language
specification at all.  It could just be a library type
NotQuiteRefany.T.

You could then introduce separately, a la Rodney,

TAGGED T <: REFANY; (* for all T *)

(* but *not* TAGGED T <: NOTQUITEREFANY *)


>
>> but maybe it doesn't break anything else.  Although you do
>> in any case get LSB checks all over the place (in safe code!) where
>> the TAGGED U is revealed to be a TAGGED U.
>> 
>> Note that, as we probably all know, the Modula-3 designers expressly
>> considered, and rejected, full variant records.
>
>Are these the factors they based their decision on?
>
>(1) The ones in Pascal are insecure without a lot of run-time checking.
>
>(2) Objects and inheritance take care of much of the functionality.
>
>(3) The ones in Algol 68 involve copying entire records when
>construction and deconstructing unions of records.

(1) and (2) at least.  I'll quote:

"[talk about runtime errors due to freeing still-used references]

Another well-known runtime error is to assign to the tag of a variant
record in a way that subverts the type system.  Distinguishing
subversive assignments from benign assignments in the language
definition is error-prone and arbitrary.  The objects and classes
first introduced in Simula and adopted in Oberon and Object Pascal
are more general than variant records, and they are safe, so we
have discarded variant records and adopted objects.

[talk about objects]"

(See Cardelli et al., "The Modula-3 Type System" (c) 1989 ACM.)

     Mika

>
>What we're considering not is the case in which (2) provides
>excessive indirection and garbage-collector load, and in which
>the copying in (3) is really cheap.  There are applications
>for which this feature could have major effects on efficiency.
>I have some I'd consider rewriting from C/C++ to Modula 3
>if this feature were available.
>
>-- hendrik
....