[Prev][Next][Index][Thread]

Re: Why are head and tail completely sealed?

Bruce Hoult <brucehoult@pobox.com> wrote:
>In article <slrn84378n.1a6.neelk@brick.cswv.com>, neelk@alum.mit.edu wrote:
>
>> Is there some subtlety I'm not seeing?
>
>Other than that part of the DRM having been written before sealed domains
>were invented, you mean? :-)

Well, that would explain the underlying rationale. :) But I'm still
confused by d2c's behavior in particular.

When I looked in d2c/runtime/dylan/list.dylan, I saw that the
definition of the list class looked like this:

  define abstract class <list> (<mutable-sequence>)
    sealed slot head :: <object>, setter: %head-setter,
      required-init-keyword: head:;
    sealed slot tail :: <object>, setter: %tail-setter,
      required-init-keyword: tail:;
  end;

Now, if I understand the section "Abbreviations for Define Sealed
Domain" on 138-139 of the DRM, then this should give the same seals
for head and tail as:

  define abstract class <list> (<mutable-sequence>)
    slot head :: <object>, setter: %head-setter,
      required-init-keyword: head:;
    slot tail :: <object>, setter: %tail-setter,
      required-init-keyword: tail:;
  end class <list>;
  
  define sealed domain head(<list>);
  define sealed domain tail(<list>);
  define sealed domain %head-setter(<object>, <list>);
  define sealed domain %tail-setter(<object>, <list>);

But when I try to compile my program with a head method for my custom
class, I get a sealing violation error. What's going on?  

I have a suspicion (without any real basis) that it has to do with
head-setter and tail-setter, which are defined in list.dylan as inline
methods on top of this in the source code. Some questions:

(a) Was this definition really necessary to make foo.tail := bar work? 
(b) what are the sealing semantics d2c uses wrt inline methods?
(c) I don't need assignment for my data structure, so can I use a 
    setter: #f slot specification to avoid this problem?

>- it's though to be to specialised and non-general to make it generic.
>
>I suspect that the latter is the case here.  Pairs and Lists are very
>wierd data structures, with strange semantics.

However, they do have sensible semantics for my new collection type,
and I'd like to be able to use those names for my class. Right now I'm
calling them "car" and "cdr", but that feels like a kludge.


Neel
Follow-Ups: References: