Re: question about generics

[agate!doc.ic.ac.uk!uknet!mcsun!ub4b!cfmu!news@ucbvax.Berkeley.EDU (Stef Van Vlierberghe)]

In article <CBLyxC.64x@crdnns.crd.ge.com> groleau@e7sa.crd.ge.com (Wes
Groleau x1240 C73-8) writes:

> P.S.  I have seen several "free"  variable  string  packages that have
> what is to me a RIDICULOUS  usage of access types, requiring all sorts
> of contortions by client packages to avoid dangling  pointers and heap
> exhaustion.  My package  and the ones I'm  complaining  about make the
> type private.

Wes, I believe that  introducing an arbitrary  limit is perfectly o.k.
in many situations, but it's just a technique that (in practice) won't
scale up.  If, rather than a simple  string,  you are  implementing  a
multi-file  screen  editor,  you might  want a list of  buffers,  each
buffer  is a list of lines and each line is a list of  characters.  My
favorite  editor has a 64K line length  limit, I have  already  opened
files of 160_000 lines, and often I had more than 20 files open at the
time (of  course I  *never*  hit all  limits in all  lists at the same
time).

The  technique  you  describe is elegant and simple, but I don't think
your  environment  is strong  enough to implement  my favorite  editor
(although  theoretically speaking, it could).  The packages with those
contortions  (typically) will scale up !  As most of the cost of these
contortions  is getting to understand the mechanism, one might as well
bite the bullet.

The *real* fun will obviusly start when we get a 9X compiler,  then we
will  be able to use  the  User-Defined  assignment  and  Finalization
(which I am so  terribly  fond  of) to  transparently  manage  all the
memory  without  any  help  from  the  client  code  (it  just  sees a
non-limited private type).

Where I live, we have terribly  suffered  from this  difficult  choice
between simple techniques that don't scale up and contortions that do,
but  are  quite  complex   indeed.  That's  why  I  did  my  share  of
complaining when the Mapping Specification didn't include User-Defined
Assignment,  and also why I can't praize the Mapping  Team enough, now
that this feature is in !

Halleluia ! God save the Mapping Team !

Thanks Tuck and Bob, you're heroes !

--------------------------------------------------------------------------
Stef VAN VLIERBERGHE            Eurocontrol - Central Flow Management Unit
stef@cfmu.eurocontrol.be        Avenue des Arts 19H
Tel: +32 2 729 33 42            B-1040 BRUSSELS
Fax: +32 2 729 32 16            Belgium