From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ef86287aa487b07a
X-Google-Attributes: gid103376,public
From: Brian Rogoff <bpr@shell5.ba.best.com>
Subject: Re: Pb with use of redefined "=" operator
Date: 1998/11/09
Message-ID: <Pine.BSF.4.05.9811092044320.1064-100000@shell5.ba.best.com>#1/1
X-Deja-AN: 410204660
References: <363F62F3.3FF7@club-internet.fr> <m3zpa860yd.fsf@mheaney.ni.net>
 <3640B520.D7BEEE72@elca-matrix.ch> <m3iugv70ke.fsf@mheaney.ni.net>
 <3641D551.CCA4379C@elca-matrix.ch> <m3btmm4eq0.fsf@mheaney.ni.net>
 <wccg1bssf6n.fsf@world.std.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: nntp1.ba.best.com 910674260 12753 bpr@206.184.139.136
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Date: 1998-11-09T00:00:00+00:00
List-Id: <comp.lang.ada>

On Mon, 9 Nov 1998, Robert A Duff wrote:

> Matthew Heaney <matthew_heaney@acm.org> writes:
> 
> > Why would anyone complain about using a component that always works?
> 
> Because it's too slow?
> 
> Maybe it's no big deal for your stack example -- maybe the stack needs
> 100 words, and the tag field makes it 101.  But suppose the abstraction
> were "point-in-a-plane" or "complex", where the thing needs two words of
> useful data -- in that case, adding a tag field is a huge space
> inefficiency.  And don't tell me memory is cheap -- it takes time to
> initialize it, and it can wreck your caching behavior, which costs time,
> and time is *not* cheap.

I agree that certain "small" data types are best not tagged, but I would
think that a collection in general is not such a type. Indeed, we have to
use tagged types for collections if we want the ability to treat them as 
values and define our own ":=". I'm definitely struggling with some of the 
same issues that Matt is struggling with, in my own attempts to create a 
flexible, usable, and most of all, efficient, data structure library. I
haven't found any totally satisfactory approaches.

I really liked the way that Sather divided its types into immutable (stack
allocated) value types and mutable (heap allocated) reference types, and
how it also used $ for the polymorphic abstract types. Too bad its a dead 
language. In any case, its lack of a proper module system was really a 
pain.

> > If using a language feature to make an abstraction work is "gratuitous,"
> > or seems like a "trick," then that is a telling observation of the
> > language itself!
> 
> Yes, the language has a flaw.

Unfortunately, it has many, many flaws. The real pity is that I don't
think that there are really any better languages out there in the same
language design space. Maybe one day someone will design a successor to 
Ada unencumbered by backwards compatibility (*).  

-- Brian

(*) No, Eiffel isn't even close, IMO.