Non-annotation 'annotations' about eo

[yegor256]

@OneWingedShark I see what this may be useful, but my concern is always the same: why not use good old decorators? Any annotations introduce some "links" to code that is located somewhere else, outside of an object. In your Ada example, who is checking that predicate? Where is the code that runs the check? Somewhere inside Ada compiler, right? Can I get access to it? I don't think so. But I should. See my point?

[OneWingedShark]

@yegor256

I see what this may be useful, but my concern is always the same: why not use good old decorators?

Because we're not talking about different objects/types... not really.
The above is (almost[a]) exactly equivalent to Subtype Positive is Integer range 1..Integer'Last;

In set terms it's "Positive contains all values of Integer that are greater than zero" is how the first declaration could be read, while this declaration could be read "Positive contains all values of Integer in the range of 1 to the last integer". (IOW, completely equivalent for the high-level overview.)

[a] In Ada 2012, where the predicate aspects were introduced, they are treated as assertions by the error-system whereas using the normal/traditional method (range first_value..last_value) is tied directly to its own entry in the error-system raising Constraint_Error if violated. -- but this is all implementation subtlety.

Any annotations introduce some "links" to code that is located somewhere else, outside of an object.

Mostly, but not quite true.

Using aspects like Ada means that the "links" are part of the definition -- that was, in fact, one of the motivations for using aspects -- it allowed them to [re-]define SPARK, which used to use comments, in terms of these aspects (SPARK is, in addition to an Ada language subset, a set of tools.) which allows the definition's assertion (Positive_Value in 1..Integer'Last, for either of the above) to be proven and statically analyzed.

Above I noted how there's a slight difference in the semantics, well that allows you to prove the predicate w/ SPARK and turn assertions off for compiling/proving -- Thus with a single, consistent piece of program source you can have both your "debug-and-assertions-everywhere" source and your "production and optimization" source be one and the same w/o having a mess like #ifdef all over the place.

Perhaps a better example would have been from my Base 64 implementation:

 -- This type represents a valid Base-64 string; its characters are that of
-- the above character-set and therefore has no relation to the internal
-- string-type.
-- 
-- NOTE: The only reason these predicates are not function-calls to
-- functions hidden in the PRIVATE section is the presence of
-- a compiler-bug which incorrectly prohibits usage of aspects
-- in a forward-referential manner.
type Base_64_String is Array(Positive range <>) of Base_64_Character
with Dynamic_Predicate =>
    -- Base64 Strings always have a length that is a multiple of 4.
    (Base_64_String'Length mod 4 = 0
     or else raise Constraint_Error with "Illegal Base64 length:"
                                                & Natural'Image(Base_64_String'Length))
    and then
    -- Only the last two characters can be padding.
    ((for all Item of Base_64_String(Base_64_String'First..Positive'Pred(Positive'Pred( Base_64_String'Last ))) =>
     Not_Padding(Item)) or else raise Constraint_Error with "Malformed Base64 string.")
    and then
    -- Pad characters must come at the end, if present.
    (if Base_64_String'Length > 1 and then Base_64_String(Base_64_String'Last-1) = '=' then
        (Base_64_String(Base_64_String'Last) = '=' or else
    raise Constraint_Error with "Nonterminal pad character detected.")
);

The reason I didn't want to use that was because it's a lot more complicated than I prefer for demonstration -- but it does give you the nice property that a Base_64_String is a valid Base 64 encoding. (Normally I would have a Validate function and use that in the predicate, but this shows it can be done directly. )

Perhaps a bit clearer of a thrust could be given by the SPARK Manual, where you can use (eg) a Ghost aspect to indicate ghost-code/-variables -- Ada doesn't have a language-defined Ghost aspect, but it allows implementations to have their own aspects (and Spark takes advantage of that for ghost entities).. -- This allows SPARK to eliminate all the ghost-entities after proving the required properties.

In your Ada example, who is checking that predicate?

The compiler, and/or the prover. (Ada compilers have a lot of static checking built in, and the DIANA intermediate language was designed to facilitate other static-analysis tools.)
Ideally both would use the same front-end and a common intermediate form where, conceptually, the static-analyzer and provers are [optionally?] in between the parse-tree production and the code generation.

Where is the code that runs the check?

That depends.
One of the criticisms against Ada I've heard from C programmers is about having checking on all array index operations... but there's a lot of cases where all those checks can be optimized away -- the trivial example being:

-- An array of integers; size unknown.
Type Integer_Array is  Array(Positive range <>) of Integer;

-- We can access "properties" of the given Integer_Array with attributes like First and Last [index].
Procedure Zero_Array( Item : in out Integer_Array ) is
begin
    -- Index takes the values from Item'First to Item'Last because
    -- Item'range is shorthand for Item'First..Item'Last.
    For Index in Item'range loop
        Item(Index):= 0;
    End loop;
end;

Since we're generating the values of Index from Item's bounds directly we don't need to check that all those values are within Item's bounds -- and thus Item(Index) needs no checks.

These are the best sorts of checks: those that can be proven/accomplished at compile-time and therefore need not be included in emitted code. :)

Somewhere inside Ada compiler, right? Can I get access to it? I don't think so. But I should. See my point?

I thought you said you didn't want reflection...

[yegor256]

@OneWingedShark interesting idea, but we may need to get back to it later, when we start working on static analyzer.

[yegor256]

@OneWingedShark we won't have this feature, even though the idea is good.

[0crat]

Job gh:cqfn/eo#40 is not assigned, can't get performer