Re: S-expression I/O in Ada

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 09.08.10 18:11, Dmitry A. Kazakov wrote:
> On Mon, 09 Aug 2010 17:14:36 +0200, Georg Bauhaus wrote:
> 
>> On 09.08.10 16:38, Dmitry A. Kazakov wrote:
>>
>>> I think that all these usages require different types of modular types with
>>> different sets of operations. So I would prefer a language extension which
>>> would allow me construction of such types rather than built-in ones, which
>>> satisfy no one. Just one example from a huge list, why "in" is not an
>>> operation?
>>>
>>>    if 0 /= (Mode and Alarm) then  -- Isn't it awful?
>>>
>>> why am I not allowed to have:
>>>
>>>    if Alarm in Mode then
>>
>> Is anything wrong with packed arrays of Booleans for status thingies?
> 
> 1. The membership/subset tests look even worse

OK. But I guess we could write inlined functions?

> 2. No ranges
> 3. No loops
> 4. No case statement

You have the index subtype at the point where you have
the array type.  Why not ranges, loops, and case statements?

> 5. Array aggregates as literals aren't not fun

Fun?

> 6. No discriminants of
> 7. No array index of

These refer to arrays in general, not Boolean arrays as sets and,
I guess, the item numbered 7 follows a general rule:
Where the array type is visible, its index type is
visible.  (Or else, you have been too lazy and used
an anonymous index type; still, you have 'first etc.)
Therefore, the index type can be named without
indirection, that is, via some array attribute function.
(Or else, index values can be made from 'first etc.)
Array access will be type checked either way.

> Note that array must be a view of a modular type

An array of Booleans for status fields must be a view of a
modular type?  I don't understand that.

> with the modulus 2**N, but
> the type itself must remain scalar.

Uh, which type must remain scalar?


>> A definition of the "+" operator, whose meaning(s) is (are)
>> stipulated to be well known, seems impossible:
> 
> http://en.wikipedia.org/wiki/Abelian_group ?

That's normative ontology, not empirically justified language
design ;-)
I remember having seen introductory texts covering algebraic
structures that use a symbol other than "+" to denote the additive
operation. I think the authors have a good reason.
One reason might be that they know their audience.
This is an example of empirically justified use of operator symbols.

When good average programmers write programs, are they
structuring their data by conscious use of mathematical
structures like groups?  I don't think so.

It is these programmers that need to know the meaning
of "+".  This seems vital.  Example: C's "definition" of the data
type int and its "+" operation demonstrates what happens
if you are optimistic about mastery of C's "+" basics.

I think Bob's example involving "not" of a mod 3 variable
shows a related issue. (And will be included in a test of advanced
Ada knowledge? ;-P)  Because *even* *though* there is a precise
mathematical definition (LRM) of what "not" should return,
referring to some overly complex set of rules explaining
the operation is hardly convincing?  Consistency of the language
(with itself) is only an excuse, then.


Georg