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

Re: Some Dylan improvements

On Thu, 30 Mar 2000, Scott McKay wrote:
> Eric Gouriou wrote in message <38E1B578.BC05AD4E@cup.hp.com>...
> >
> > Hello,
> >
> > Following the module/library discussion, I would expose to the
> >community some ideas I have on how Dylan could be improved. ...
> >
> > Proposed changes (more comments below):
> > ...
> >B) add a way to specify a module interface beyond mere names
> 
> I think this is a good idea ...  Yes, there is the "two hunks of code"
> problem, but ... if this were an optional part of 'define module', it
> would be worth trying. 

Yes, absolutely, this should be optional, just like type declarations,
sealing etc.  I see no reason why you shouldn't provide type info for some
exported names and not for others (in which case they'd effectively have
type <object>), specially in incremental development.

> >I) get size() to return an integer or signal an error on
> >   infinite size collections
> 
> Yes, for sure.

I previously suggested an invalid-size? predicate in addition; it then
occured to me that you might instead want something like

  function valid-size (c :: <collection>) => (s :: false-or(<integer>))

to avoid having to do internal work twice if it *does* have a valid size.
(E.g., this should be cheap to determine for <range>s but it's relatively
expensive for circular lists.)

> I would also clean up collections (ask Andy Armstrong about this),

Yeah, I've seen Andy's notes on this and they're good, though they focus
mostly on the functions, not the classes.  Changing the classes would
probably cause more hassle then the functions but I'd quite like (a) to
make improper <list>s *not* a subclass of <collection>; and (b) to have
collections which just have members, not key-value pairs, e.g., for sets
and multisets.

-- Hugh
Follow-Ups: References: