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

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?

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

   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. ]

   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"

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.

In article

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