Singletons and Sealed Domains 
Author Message
 Singletons and Sealed Domains

Is this valid?

Library L1
define generic f (x :: <object>);
define class <a> (<object>) end class;
define class <b> (<object>) end class;
define constant $ca = make(<a>);
define method f (x :: singleton($ca)) end method;
define sealed domain f (<b>);

Library L2
define class <ab> (<a>, <b>) end class;

The class definition <ab> does not join the types '<b>' and
'singleton($ca)', and therefore does not join the domain of the method and
the sealed domain, nevertheless, this appears to be forbidden by the DRM
'pseudosubtype' rules for class-blocking at
< http://www.*-*-*.com/ ;.

It's my belief that:

1. specifiable type disjointness is computable (see my formalisation efforts);

2. given this, specifiable domain disjointness can be computed fairly easily;

3. given this, a correct algorithm for class-blocking is possible;

4. 'pseudosubtype' is not a useful notion.

--
Ashley Yakeley, Seattle WA



Thu, 24 May 2001 03:00:00 GMT  
 Singletons and Sealed Domains

Quote:

> define class <a> (<object>) end class;
> define class <b> (<object>) end class;

Sorry, that should be:

define open class <a> (<object>) end class;
define open class <b> (<object>) end class;

--
Ashley Yakeley, Seattle WA



Fri, 25 May 2001 03:00:00 GMT  
 Singletons and Sealed Domains


Quote:
>Is this valid?

>Library L1
>define generic f (x :: <object>);
>define class <a> (<object>) end class;
>define class <b> (<object>) end class;
>define constant $ca = make(<a>);
>define method f (x :: singleton($ca)) end method;
>define sealed domain f (<b>);

>Library L2
>define class <ab> (<a>, <b>) end class;

Yes, this is valid.

Quote:
>The class definition <ab> does not join the types '<b>' and
>'singleton($ca)', and therefore does not join the domain of the method and
>the sealed domain, nevertheless, this appears to be forbidden by the DRM
>'pseudosubtype' rules for class-blocking at
><http://www.harlequin.com/products/ads/dylan/doc/drm/drm_75.htm>.

Not true.  I suspect you've misremembered the definition of "base type"
for singletons, which is that the base type of a singleton type is that
singleton type, and that you incorrectly believe that <a> is a
pseudosubtype of $ca.

Quote:
>3. given this, a correct algorithm for class-blocking is possible;

Well, I think we already have a correct algorithm for class blocking.

Quote:
>4. 'pseudosubtype' is not a useful notion.

I wish this were true, but I don't believe it.  We tried really hard to
eliminate it, because it really does look like an ugly kludge.  I'd be
quite thrilled to see a proof that neither it nor anything with a
similarly contrived appearance is necessary, but I'm not going to hold
my breath.  The fact that it only became necessary when limited types
were added, coupled with the fact that limited types were added pretty
late in the design process, gives me hope that it might be possible to
develop a better understanding of what this relationship really means
and why it is needed, and that such improved understanding will lead to
a better name for it.


Sat, 26 May 2001 03:00:00 GMT  
 Singletons and Sealed Domains
In article

Quote:

> >The class definition <ab> does not join the types '<b>' and
> >'singleton($ca)', and therefore does not join the domain of the method and
> >the sealed domain, nevertheless, this appears to be forbidden by the DRM
> >'pseudosubtype' rules for class-blocking at
> ><http://www.harlequin.com/products/ads/dylan/doc/drm/drm_75.htm>.

> Not true.  I suspect you've misremembered the definition of "base type"
> for singletons, which is that the base type of a singleton type is that
> singleton type, and that you incorrectly believe that <a> is a
> pseudosubtype of $ca.

Foo! Foiled again...

...

Quote:
> >4. 'pseudosubtype' is not a useful notion.

> I wish this were true, but I don't believe it.  We tried really hard to
> eliminate it, because it really does look like an ugly kludge.  I'd be
> quite thrilled to see a proof that neither it nor anything with a
> similarly contrived appearance is necessary, but I'm not going to hold
> my breath.

Well I very nearly have one. All I need to do is complete my algorithm for
disjoint-type class-blocking by providing algorithms related to existing
limited types as per (33.d) in my formalisation effort, and then provide
an algorithm for disjoint-domain class-blocking based on this, which
should be straightforward.

On the other hand, this isn't arguably any shorter, but it is at least
broken down into intuitive concepts that can be more easily checked for
correctness line by line.

At some point I will rewrite the algorithms in some kind of 'meta-Dylan'
to make things a little clearer.

Quote:
> The fact that it only became necessary when limited types
> were added, coupled with the fact that limited types were added pretty
> late in the design process, gives me hope that it might be possible to
> develop a better understanding of what this relationship really means
> and why it is needed, and that such improved understanding will lead to
> a better name for it.

It's a formalism rather than anything intuitive. Consider:

define constant $limited-zero = limited (<integer>, min: 0, max: 0);
define constant $singleton-zero = singleton (0);

$limited-zero and $singleton-zero both instances of <type>. Are they
type-equivalent? What would 'subtype?($limited-zero, $singleton-zero)' and
'subtype?($singleton-zero, $limited-zero)' return? The DRM isn't clear.
Whatever, note that:

1. $limited-zero and $singleton-zero are exactly the same in terms of
'instance?'. If there's an intuitive notion of 'type', it's 'set of
objects'. With the possibility of an exception here and for empty limited
integer types, which seem to be oversights anyway, Dylan as per the DRM
can (and should!) be formalised along these lines. And the sets of objects
represented by $limited-zero and $singleton-zero are identical.

2. Their 'base types' for the purposes of pseudosubtype are different.

Of course, $limited-zero and $singleton-zero would not be conceptually
identical if <integer> were not sealed. But because <integer> is sealed,
the difference in base types of $limited-zero and $singleton-zero doesn't
matter much.

--
Ashley Yakeley, Seattle WA



Sat, 26 May 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. singletons and sealed classes

2. Sealed domain question

3. Sealed Domain Errata?

4. Sealed Domain Errata?

5. Fun with singletons' singleton classes

6. Time domain to frequency domain...and back again

7. convert time domain to frequency domain

8. public domain prolog for apollo domain

9. ForSale: Clipper 5.2 sealed in Box - Best offer!

10. Sealed as Source Annotation

 

 
Powered by phpBB® Forum Software