Guaranteeing Disjointness 
Author Message
 Guaranteeing Disjointness

Wouldn't it be cool if you could guarantee disjointness between two types
in Dylan? For instance, the declaration:

disjoin(<male>,<female>);

would guarantee that if the classes <female> and <male> are disjoint in
the current library, they stay disjoint.

Actually, this can already be done:

define generic anonymous (x);
define method anonymous (x :: <male>) end;
define sealed domain anonymous (<female>);

Perhaps someone would like to write a macro for this...

--
Ashley Yakeley, Seattle WA



Fri, 18 May 2001 03:00:00 GMT  
 Guaranteeing Disjointness


Quote:
>Wouldn't it be cool if you could guarantee disjointness between two types
>in Dylan? For instance, the declaration:

>disjoin(<male>,<female>);

>would guarantee that if the classes <female> and <male> are disjoint in
>the current library, they stay disjoint.

>Actually, this can already be done:

>define generic anonymous (x);
>define method anonymous (x :: <male>) end;
>define sealed domain anonymous (<female>);

>Perhaps someone would like to write a macro for this...

Regretably, you can't.  The macro one would like to write is (please
pardon any syntactic screwups)

define macro disjoin
  { disjoin(?t1:variable, ?t2:variable) }
    => { define generic anonymous (x);
         define method anonymous (x :: ?t1) end;
         define sealed domain anonymous (?t2); }

disjoin(<a>, <b>);
disjoin(<c>, <d>);

Unfortunately, the current language specification is not completely
consistent about what should happen in this situation.  It *almost* says
that such a program is erroneous because the two calls to disjoin
result in two "define generic" forms for the same module variable.

Another possibility would be that each call expands into a new hygenically
renamed binding created by the "define generic", along with some hygenically
matching references to that binding.  The current language specification
seems to come pretty close to saying that as well.  Under such a
specification, each macro call would really create an anonymous (i.e. not
accessible from anywhere outside the code generated by the expansion of
the macro call) generic function.

There was a long discussion of this a while ago on the (now quiescent)
dylan-partners mailing list, the conclusion of which was that there were
a small number of changes that would need to be made in order to
disambiguate in favor of the first of these alternatives, and some
unknown but probably larger (possibly significantly larger) number of
changes would be required to disambiguate in favor of the second
alternative.  Part of the problem with trying to do the latter is that
Moon said that when he wrote the text for the macro chapter he was
assuming the first interpretation and had not even considered the second.
Thus, there may be a number of scattered subtle or not so subtle changes
needed to make everything consistent with the second interpretation.
Which is really too bad, if you ask me.



Sat, 19 May 2001 03:00:00 GMT  
 Guaranteeing Disjointness


Quote:

>>Wouldn't it be cool if you could guarantee disjointness between two types
>>in Dylan? For instance, the declaration:

>>disjoin(<male>,<female>);

>>would guarantee that if the classes <female> and <male> are disjoint in
>>the current library, they stay disjoint.

>>Actually, this can already be done:

>>define generic anonymous (x);
>>define method anonymous (x :: <male>) end;
>>define sealed domain anonymous (<female>);

>>Perhaps someone would like to write a macro for this...

>Regretably, you can't.  The macro one would like to write is (please
>pardon any syntactic screwups)

>define macro disjoin
>  { disjoin(?t1:variable, ?t2:variable) }
>    => { define generic anonymous (x);
>         define method anonymous (x :: ?t1) end;
>         define sealed domain anonymous (?t2); }

>disjoin(<a>, <b>);
>disjoin(<c>, <d>);

>Unfortunately, the current language specification is not completely
>consistent about what should happen in this situation.  It *almost* says
>that such a program is erroneous because the two calls to disjoin
>result in two "define generic" forms for the same module variable.

>Another possibility would be that each call expands into a new hygenically
>renamed binding created by the "define generic", along with some hygenically
>matching references to that binding.  The current language specification
>seems to come pretty close to saying that as well.  Under such a
>specification, each macro call would really create an anonymous (i.e. not
>accessible from anywhere outside the code generated by the expansion of
>the macro call) generic function.

>There was a long discussion of this a while ago on the (now quiescent)
>dylan-partners mailing list, the conclusion of which was that there were
>a small number of changes that would need to be made in order to
>disambiguate in favor of the first of these alternatives, and some
>unknown but probably larger (possibly significantly larger) number of
>changes would be required to disambiguate in favor of the second
>alternative.  Part of the problem with trying to do the latter is that
>Moon said that when he wrote the text for the macro chapter he was
>assuming the first interpretation and had not even considered the second.
>Thus, there may be a number of scattered subtle or not so subtle changes
>needed to make everything consistent with the second interpretation.
>Which is really too bad, if you ask me.

Hmmmm... Doesn't the macro system provide some way to force the creation
of a new symbol?  A Dylan equivalent to gensym?


Sat, 19 May 2001 03:00:00 GMT  
 Guaranteeing Disjointness


Quote:


>>Regretably, you can't.  The macro one would like to write is (please
>>pardon any syntactic screwups)

>>define macro disjoin
>>  { disjoin(?t1:variable, ?t2:variable) }
>>    => { define generic anonymous (x);
>>         define method anonymous (x :: ?t1) end;
>>         define sealed domain anonymous (?t2); }

  Actually, I'd make it a definition macro since definitions must occur
  at the "top level" while statements can be inside of a block.

Quote:
>Hmmmm... Doesn't the macro system provide some way to force the creation
>of a new symbol?

   Besides the  literal string pre/postfix "magic"? ;-)
   [ I think I had a solution up until I remember that the pre/post fix has to
      be a literal string.... :-(

             define   macro  foo
                {   foo ( ?t1 , ?t2, ?t3  )  }
              =>
                {   ?"t1" ## ?t2 ## ?"t3" ( ?t1 , ?t3 )  }
             end

      the string of the argument would seemingly be as "available" as a literal
      during the expansion of the macro. ]

Quote:
>  .....  A Dylan equivalent to gensym?

   Seperate compilation?   A gensym is only unique to a particular
   lisp session.  Unique with the libraries name as a prefix perhaps.
   If one writes macros that write macros it seems as though
   you need a mechanism to aid in providing hygenie.

--

Lyman S. Taylor           "Computers are too reliable to replace

                                Commander Nathan Spring, "Starcops"



Sun, 20 May 2001 03:00:00 GMT  
 Guaranteeing Disjointness


Quote:
>>Perhaps someone would like to write a macro for this...

>Regretably, you can't.  The macro one would like to write is (please
>pardon any syntactic screwups)

>define macro disjoin
>  { disjoin(?t1:variable, ?t2:variable) }
>    => { define generic anonymous (x);
>         define method anonymous (x :: ?t1) end;
>         define sealed domain anonymous (?t2); }

>disjoin(<a>, <b>);
>disjoin(<c>, <d>);

Some further comments on this, in addition to the problems I noted in my
original message.

Andrew Shalit asked about whether the macro system provided some way for the
macro to create a unique name, and Lyman Taylor correctly noted that you
can't do any better than concatenation with a literal string prefix or
suffix.

In the above example definition, I should have constrainted ?t1 and ?t2 to
be "expression" rather than "variable" (and I meant "name" at the time).
That would be more in keeping with other parts of Dylan.

However, the biggest problem with such a definition is that it simply
does not do what its name claims, i.e. it does not ensure that the types
are disjoint.  The reason is that the sealed domain does not prevent a
common subclass of the two classes from being defined in the same library
as that in which the disjoint form appears.



Fri, 25 May 2001 03:00:00 GMT  
 Guaranteeing Disjointness
In article

Quote:

> However, the biggest problem with such a definition is that it simply
> does not do what its name claims, i.e. it does not ensure that the types
> are disjoint.  The reason is that the sealed domain does not prevent a
> common subclass of the two classes from being defined in the same library
> as that in which the disjoint form appears.

Right, and that's a shame. Maybe the macro could be written to expand into
its own little library. On the other hand, you're responsible for anything
you put in your own library, whereas you can't always directly control
what client code does.

--
Ashley Yakeley, Seattle WA



Fri, 25 May 2001 03:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Algorithm for Type Disjointness Blocking Classes

2. Limited Collection Type Disjointness

3. Proven Weight Loss, Satisfaction Guaranteed! wombv

4. A GUARANTEED MONEY MAKER!!

5. A GUARANTEED MONEY MAKER!!

6. A GUARANTEED MONEY MAKER!!

7. New 60 day money back guarantee and free upgrades for a year

8. How to guarantee compiler/platform independance

9. A GUARANTEED MONEY MAKER!!

10. A GUARANTEED MONEY MAKER!!

11. A GUARANTEED MONEY MAKER!!

12. We guarantee...one full grade-level equivalent

 

 
Powered by phpBB® Forum Software