Re: FAQ and string functions

[Darren New <dnew@san.rr.com>]

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.