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.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a3bf872bb81a1f2b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-11 17:43:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!fu-berlin.de!uni-berlin.de!ppp-1-48.cvx5.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: ASCL a doomed idea? Date: Wed, 12 Dec 2001 01:39:06 -0000 Message-ID: <9v6cn5$dcfkh$1@ID-25716.news.dfncis.de> References: <7RQP7.4406$Yy.272014@rwcrnsc53> <9v0crv$bo2bi$2@ID-25716.news.dfncis.de> <3C13D980.748CCCDA@acm.org> <9v37s0$cdmva$3@ID-25716.news.dfncis.de> <30wR7.37506$Yy.395982@rwcrnsc53> NNTP-Posting-Host: ppp-1-48.cvx5.telinco.net (212.1.152.48) X-Trace: fu-berlin.de 1008121382 14040721 212.1.152.48 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:17803 Date: 2001-12-12T01:39:06+00:00 List-Id: "Mark Lundquist" wrote in message news:30wR7.37506$Yy.395982@rwcrnsc53... > Look, you have said that you conceive of a list as a "store" into which > things are written and out of which things are read. Are you truly saying > that if I write > > Put_Line ("Hello, world"); > > that you think of the thing I am passing as an instance of a kind such a > store? Yes indeedy! There are several programming languages in which a string is explicitly a list. Think about LISP. It seems utterly bizarre and beyond all reason to me to suggest that a string is not, in general, a kind of list. It's a list of characters. Isn't that something a four-year-old would understand? Talk about people coming from different planets! I'm not talking about somebody's esoteric academic definition of a list, I'm talking about ordinary everyday people's idea of a list. Most Ada programmers are ordinary everyday people, and it is those programmers whom I am considering when choosing names for the types and subprograms. > > and what the heck is the problem with using the same > > nomenclature for both (as far as possible) to help avoid confusing the > > poor Ada programmer? > > The problem is, as Jeff says, that they are not the same thing, and in > fact have little to do with each other. So if anything, you're going to > confuse people *more* if your nomenclature is at variance with standard > terminology for lists (assuming that there is such a thing...). I think my previous remark kills this one stone dead. A string is a kind of list, ergo any string operation (that is not character-specific) is also a list operation (this is to say nothing about the efficiency of such operations, or the representation of strings and lists). If you have an operation which does something (specifically) for a string and an operation which does the same (analogous) thing for a list, does it not make sense to give them the same name? Let us take as an example a string "ABCDE" and a list (Bob, Tom, Jim, Fred, Pete). If we have an operation called 'Head' that returns the first element of a string ('A' in the example), do you think Ada programmers are going to thank you for calling the same list operation (which would return Bob in the example) something else ('First', 'Front', even 'Cat' or 'Dog')? I don't. I can assure you that, in the big scheme of things, there is no standard terminology for lists. There are a few terms that seem to be used consistently, but only a few. Let us use the terminology already provided by existing Ada standard library packages. That is, I am certain, the best way for a container library to avoid confusion and gain acceptance. Phew! I hope I'm 'getting my message across' as they say. -- Best wishes, Nick Roberts