Re: FAQ and string functions

[dewar@gnat.com (Robert Dewar)]

Darren New <dnew@san.rr.com> wrote in message news:<3D4D551F.190A19C0@san.rr.com>...
> I don't think you want to recurse a million times to read 
> million lines of text from the terminal. I really suspect 
> you don't want 1.5 million lines of text on the stack,
> either.

A very strange statement indeed. Using recursion to read
a million lines of text is perfectly natural, and with
a decent compiler that does tail recursion elimination,
you will get identical code for loops and for simple
recursion (recursive languages like Haskell absolutely
require this optimization of course). It is simply a
matter of taste whether you like the syntactic sugar
of a looping construct. That's all a loop is, syntactic sugar for tail
recursion.

>  I.e., if you have something
> > > that's difficult to program in a functional style.

None of the examples you give are even vaguely in this
category (unless you have difficulty programming in a functional
style, in which case the statement is sort of
vacuously true :-)

> 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.)

Well then unless you intend to emulate Humpty-Dumpty in
Alice, please use technical defintions the same way as
the rest of the world.

It is absolutely standard in the world of compilers to
draw a sharp distinction between lexical analysis, typically based on
type 3 (regular) languages, and parsing, typically based on type 2
(context free) languages.

It is *distinctly* unhelpful to use the term parsing for
the former, and will simply confuse other people. If that
is your goal, fine you will succeed, but if you are a "bit
of a formalist" then you will want to use formal terms in
their accepted meaning if you want to be understood.

> 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.

Of course it's possible, and easy if you have a reasonable
familiarity with writing in a recursive style. I always
like to give my students the task of writing programs in
a procedural language avoiding the use of assignments and
loops. It is definitely useful to learn familiarity with
recursion as a style of programming. I am not in favor of
forcing everyone to use ONLY this style, but I do find that
people overuse imperative constructs.

In particular, people very much overuse variables, and do
not make sufficient use of constants that are computed 
once, a powerful feature in Ada. 

(digression. I prefer Algol 68 to Ada in this respect. In
Algol-68, it is easier to write a constant declaration

    int a = expression;

than to write an initialized variable

    ref int a = loc int := expression;

and even in the shortened form:

    int a := expression;

is one character longer than the constant. In Ada, we have
to write an extra keyword to make things constant, so the
lazy path is to make an unnecessary variable)

Back on topic: the latest version of GNAT at least warns
if you write

   X : type := expression;

and never modify X (the compiler warns that you could
make this declaration into a constant declaration).

But it does not go so far as warning that if you write

   X : type;
   ..
   X := expression; 

where there are no other assignments to X, that X could
be made into a constant initialized with the expression
(the conditions for that are harder to figure out)


>  
> > 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. :-)