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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4f316de357ae35e9 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-08-04 09:23:36 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!cyclone.socal.rr.com!cyclone3.kc.rr.com!news3.kc.rr.com!twister.socal.rr.com.POSTED!not-for-mail Message-ID: <3D4D551F.190A19C0@san.rr.com> From: Darren New X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: FAQ and string functions References: <20020730093206.A8550@videoproject.kiev.ua> <4519e058.0207300548.15eeb65c@posting.google.com> <20020731104643.C1083@videoproject.kiev.ua> <4519e058.0208010629.5e6182ca@posting.google.com> <20020801194720.Q1080@videoproject.kiev.ua> <4519e058.0208020605.5ab7e092@posting.google.com> <3D4AAF63.72782659@san.rr.com> <3D4B2382.7030209@telepath.com> <3D4B2ACD.FDA29B9A@san.rr.com> <3D4B401E.3060802@telepath.com> <3D4B4477.500088B@san.rr.com> <3D4BCEC9.9030108@telepath.com> <3D4C0ABA.F38204E3@san.rr.com> <3D4C7DE5.9060408@telepath.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 04 Aug 2002 16:23:35 GMT NNTP-Posting-Host: 66.74.216.166 X-Complaints-To: abuse@rr.com X-Trace: twister.socal.rr.com 1028478215 66.74.216.166 (Sun, 04 Aug 2002 09:23:35 PDT) NNTP-Posting-Date: Sun, 04 Aug 2002 09:23:35 PDT Organization: RoadRunner - West Xref: archiver1.google.com comp.lang.ada:27669 Date: 2002-08-04T16:23:35+00:00 List-Id: Ted Dennison wrote: > > Darren New wrote: > > In the sense that it was the OP's original question. Surely you can't mean > > "don't ask that question." > > No. The OP asked about general string processing routines in Ada, Yes. But I believe I understood what he was asking better than the Ada folks. He was asking about the string parsing routines, but the *reason* they're different in Ada is a lack of a general variable-sized array. > If the question is, "In general, how am I > supposed to deal with strings in Ada", then the answer is unfortunately > rather long. Perhaps I was reading more into it, but I believe thats what he was asking. As one poster said, "surely the lack of this one routine is not the problem." > Lisp folks had dicussions very much like the one we're having now, > before they broke down and added procedural looping constructs to the > language. :-) Yep. That's my point. :-) LISP certainly isn't what I'd call a powerhouse of popularity even *with* the procedural constructs. The answer of "change how you do things to fit our compiler" isn't a good answer, is all I'm trying to say. > That would be completely unsafe, unless you lock the data structure > somehow. Actually, I meant to say "concurrently" rather than "coherently". It has nothing to do with tasks. You can be doing several different tasks (in the sense of "things to do" rather than "concurrent program counters with independent stacks") at the same time without using Ada tasks. You can (for example) be reading input, parsing it, generating a parse tree, generating code off the parse tree, doing optimization, and writing out object code concurrently, without using tasks. It has to do with the fact that it's an inherently iterative process, not a recursive one. I don't think you want to recurse a million times to read a million lines of text from the terminal. I really suspect you don't want 1.5 million lines of text on the stack, either. If you're building up one array, it's conceivable you could do it recursively. > > on the lines of text, if you're filling in the array based on the processing > > of a state machine (like a parser), etc etc. I.e., if you have something > > that's difficult to program in a functional style. > > I think you mean a lexical analyzer, not a parser. Lexical analyzers are > usually some kind of state machine (unless they are very simple). A lexical analyzer is a simple parser. (I'm a bit of a formalist, ya see, so I tend to mean the technical definitions when I use the technical words.) > However, its usually a lot quicker to just work out of a big buffer, and > use indices to designate tokens within the buffer. That way you aren't > copying strings around until you need to. That's a good point, and something that's hard to do in many other languages. However, it's really not enough. For example, implement the Ada.Strings.Unbounded package using only recursion to allocate record sizes. I haven't tried, but I don't think it would be easy, even if possible. > But Ada programmers should teach themselves to work with perfectly sized > constant strings where feasable, as that's the language's native idiom. Agreed. And it's easier to do in Ada than it is in C. But that doesn't make Ada a good string-processing language compared to something like Perl or Tcl. :-) It's clearly a difficult idiom, given the number of newbie questions about how to do it I see here. Once you're used to doing it that way, yes, it can be done that way. I'm not disputing that. Anyway, this horse is a greasy spot on the sidewalk. You can have the last word. :-) -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://images.fbrtech.com/dnew/ ** They looked up at me like I was a T-bone steak walking into an all-you-can-eat seafood buffet.