Re: FAQ and string functions

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

Ted Dennison wrote:
> > More like his problem is not having ubiquitous variable-sized arrays so you
> > could write a function that does the splitting and returns the result as an
> > array. That's the sort of thing that makes Perl quicker to put together than
> 
> But we *do*, with Ada.Strings.Unbounded.

Errr, Ada.Strings.Unbounded is character arrays. Hardly ubiquitous. I think
if there had been a generic Ada.Unbounded that exports the same sort of
array stuff that Ada.Strings.Unbounded supports, all kinds of things could
have much more obvious interfaces.

> However, you generally don't
> need to work with variable-sized arrays.

No. *You* don't generally need to work with variable-sized arrays. :-) The
kinds of work done by people who find Perl effective *do* work with
variable-sized arrays, extensively.
 
> I really don't see what the problem with fixed array slicing is.
> 
> I'll agree that there is probably some room for improvement with Ada's
> string libraries. But slicing and joining are there just fine right now.

Yes. But when you chop up a string, what do you do with the result? You
can't just declare an array in Ada and say "I'm not sure how much this will
hold" or "add one more element to the end of this array" like you can with
Ada.Strings.Unbounded.
 
> It looks like what he is talking about

... is a specific case of a wider problem.

> (in Ada.Strings.Unbounded)
> 
> type String_Pair is array (Left..Right) of Unbounded_String;
> 
> function Split (Around : String; Source : Unbounded_String) return
> String_Pair;

No, I think the issue is (in part) when you say (for example) here's a
string, return me an array of strings, where each component of the returned
array is a whitespace-delimited work from the input string. So 
  Words("one two three four")
would return an array A such that
  A[1] = "one", A[2] = "two", and so on.

The problem is that there's no Ada.* declaration for anything like A.

At least, that's one of the problems I see.
 
> And I *have* written such routines before. It doesn't always happen, but
> I've been known to learn from the experience. :-)

Sure. I think the problem is that there's a host of low-efficiency
operations in Perl that take advantage of built-in data structures. That Ada
offers fixed strings, bounded strings, and unbounded strings indicates that
it has a focus on efficiency that something like Perl doesn't. If Ada didn't
have unbounded strings, people would have to keep reimplementing it. Ada
doesn't have unbounded arrays, and people have to keep reimplementing that
(when they need it). The assign-to-a-local-in-a-declaration doesn't really
work well when you have long-lived arrays. 

I've been working in scripting languages for the last few years, and I see a
lack in Ada of basic simple data structures, like variable sized arrays,
content-addressable arrays, and a few other things like that. I can see how
someone coming from Perl could miss all that. Once you've written programs
using built-in hashtables, arrays, etc, it's difficult to look at a language
that doesn't use such things and see how to do simple things. And that it
isn't built in means it's not going to get used everywhere it should. Even
if you build a library for UnboundedArrays, the (pulls example out of left
ear) MIME-parsing library isn't going to return an UnboundedArray compatible
with the one that goes into the XML parser. The MIME library's output
strings might be Ada.Strings.Unbounded, and the XML parser's input strings
might be Ada.Strings.Unbounded, but if you want to pass the array of lines
that's the body of the message into the array of lines that's the XML
parser's input, you're going to need to do conversions.

Yes, you *could* build all that. But from a "newbie" point of view, having
multitasking with extensive typing and all that, but lacking something as
simple as a variable-length array, really slows down learning the language,
because you're constantly stumbling when you're trying to do *simple* stuff.

Of course, Ada has excellent numeric support, type support, multithreading,
etc etc etc. It also looks like the support for large-scale programming is
excellent, altho I haven't had a chance to test that out.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
   ** http://images.fbrtech.com/dnew/ **

They looked up at me like I was a slab of beef
  walking into an all-you-can-eat seafood buffet.