Re: How to get Ada to ?cross the chasm??

["Randy Brukardt" <randy@rrsoftware.com>]

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87lgd1heva.fsf@nightsong.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>> Right: "spaghetti data". Again, why is spaghetti data acceptable but
>> spaghetti code not acceptable? Data with random references to other data 
>> is
>> no more structured than code full of gotos. We never allow the latter, 
>> why
>> allow the former??
>
> Here's a complete Haskell program for printing the first 20 prime
> numbers, using cyclic data (what you call "spaghetti"):
>
>    main = print . take 20 . sieve $ [2..] where
>      sieve (p:xs) = p : sieve [a | a <- xs, a`rem`p /= 0]
>
> The idea is that sieve is a self-referential list, created by taking the
> infinite list [2,3,4,5...], and yielding its first element followed by
> what you get by (recursively) sieving the result of filtering out
> multiples of the first element from the rest of the list.  So the sieve
> output is prime numbers.  The program then just takes 20 elements of the
> sieve output and prints them.

I don't see anything "cyclic" or "self-referential" here. This is just a set 
of lists, and there is nothing particularly interesting about them (in 
partcular, there are *no* references involved in a list unless you need to 
keep a reference to a particular element, certainly doesn't happen here).

There's no particular problem implementing an infinite list in Ada; there 
isn't such a container predefined but it would be relatively easy to write 
one. We did spend some time looking at how the Ada iteration constructs 
would work with such a container and we were pretty certain that they would 
work fine. I don't think an infinite list would do much memory 
allocation/deallocation -- there wouldn't be much reason to actually 
materialize nodes (you have to materialize the elements of course, but those 
are usually copied into/out of a container, so the materialization would be 
short-lived and local).

Ada might be hamstrung here by not having useful lambas, meaning that this 
particular implementation probably wouldn't work. But it's hard to tell...

> Obviously there are more efficient algorithms and you could code
> something like the above with arrays and loops and whatnot, but the
> above was very easy to write.

Of course, only a high priest of programming could possibly understand what 
it does. (Even with your explanation, I can't quite figure how it is 
supposed to actually execute.)

...
>... Instead it just counts upwards and tests each number.  ...
>
> Despite that, the Ada code is still about 5x longer than the Haskell
> code.  Fixing the algorithm would likely bloat it by another 2x or so.

I cannot imagine a sane way to implement an infinite list that would have 
any other effect. (For that matter, any insane way, either.) Ergo, the 
underlying implementation of the Haskell code has to do something like that 
in order to figure out the answers. (There's no free lunch. :-)

> So basically it's not "spaghetti", it's having power tools and the
> ability to use them.

A lot of power tools should never be used by the untrained. (Think of all of 
the chainsaw accidents.) No one should try writing code like you have shown 
here - it's essentially write-only code, and virtually all code is read much 
more than it is written. (Assuming that your code actually gets used at 
all.) Ada, of course, is about readability and maintainability of the 
code -- the need to use tricks is always a bad thing (even when it happens 
in Ada.)

                                   Randy.